Behind the builder / 13 September 2026
Five days without AI credits. Plenty of unfinished business.
Five days of limited AI access made continuity urgent. The UBIKITOS diary follows unfinished work, handoff preparation, and an experiment result still to recover.
The question was simple enough
“Right now what is the main thing I have to finish so that work unlocks and I can continue R development?”
That was my opening question. Not a request for another grand vision. Not an invitation to name another department or draw another architecture diagram. I wanted to know which actual piece of work stood between where UBIKITOS was and where it needed to go next.
This sounds like something an AI assistant should be able to answer quickly. It had plenty of context. There were project files, existing prototypes, reviews, and a long trail of decisions. Surely we could find the next thing.
The conversation took a less direct route.
At one point I had to ask: “can you actually look at the architecture work?” That sentence explains quite a lot about building with AI. An answer can sound perfectly reasonable while describing a project that is slightly different from the one you are actually working on. The words fit. The advice feels plausible. Then you compare it with the work already done and realise that you are being sent back to the beginning of a road you have already travelled.
Today needed less plausibility and more looking.
A very specific door was closed
Once the status audit was brought into the conversation, the answer became much more concrete. The next dependency was Task 26, the execution-isolation design. Its preliminary checks had passed, but it still needed an independent review before implementation could begin.
In everyday terms, this was about the boundaries around automated work: where it could run, what it could touch, and what it should be prevented from doing. Those details matter when the ambition is to let software do useful things rather than merely produce suggestions about useful things.
The earlier architecture tasks had been accepted within their respective scopes. The remaining review was not a reason to pretend they had never happened. Equally, passing preliminary checks did not mean the next stage was approved. Both facts had to fit into the same answer.
That distinction is easy to lose in a long development conversation. “Almost ready” quietly becomes “ready.” A design document becomes an implemented feature. A preparation task reaches one hundred percent, and suddenly the whole programme sounds finished. The record needed to say precisely what was complete and what was waiting.
Then came the practical complication. I wrote: “I won't have astra credits until 5 days from now, what can i do meanwhile?”
Five days. A very ordinary resource limit in the middle of a very ambitious project. Apparently even the future of work has a meter.
Waiting became a list
My next instruction was two words: “Make a list.”
There was useful preparation available. The review packet could be assembled. The design and its supporting records could be checked against each other. Open questions could be written down clearly. The steps that would follow a successful review could be organised before anyone attempted them.
That is less glamorous than announcing a new capability, but it is real work. A reviewer should not have to reconstruct the entire project merely to understand the decision in front of them. A concise brief can explain what is proposed, why it matters, what remains uncertain, and what would count as an acceptable answer.
The conversation moved through those tasks. The read-only preflight reported nineteen checks passed. A review brief was created. A post-review checklist followed. There were outlines for later work and a tracker to preserve the current position.
None of those documents opened the closed door. They made it easier to approach the door with the right material when the review became available.
For a founder, that is an important kind of progress to recognise. There is a difference between doing nothing and doing preparation. There is also a difference between doing preparation and claiming delivery. If the diary blurs those together, it becomes another dashboard that makes activity look more impressive than it is.
“Continue” turned out to need a definition
Looking back through the chat, one word appears repeatedly in my messages: “continue.”
It is probably the least elaborate instruction in software development. It also carries a surprising amount of meaning. Continue the agreed list. Find the next useful step. Do not make me reconstruct the plan every few minutes. Keep the thread of the work intact.
The assistant sometimes interpreted it as a request to move beyond the blocked stage. I had to clarify: “i mean continue down the list.”
That is a small exchange, but it captures a practical challenge in AI-assisted building. The assistant needs to understand both the boundary and the available space around it. Stopping an unapproved action is useful. Treating every neighbouring task as impossible is much less useful.
There was another revealing moment when I asked whether the entire list was done. The answer was initially: not entirely. Some preparation existed, but two requested items had not been completed. Those were subsequently supplied as offline artifacts. The conversation also recorded that their tests could not be executed in that environment.
That qualification belongs in the story. A file that exists and a test that has run are different achievements. “Continue” should move the work forward, not merely improve the wording of its status update.
There was work outside the queue
Eventually I asked whether a different available model could handle an appropriate task. That attempt also encountered the usage limit. Switching the name on the request was not going to make the resource problem disappear.
So I asked a wider question: “what about other things like knowledge base, etc. Find work”.
This changed the direction of the afternoon's conversation. The knowledge-base area was inspected, and the review found concrete gaps: placeholder context documents, incomplete supporting material, and areas where retrieval and behaviour needed better tests. A work queue was written around those findings.
There was a lesson here about the assistant as much as the project. “There is nothing else to do” was too broad an answer. There was nothing further to do on a particular gated path. That still left other parts of the project that could be inspected, clarified, and prepared without pretending the gate had disappeared.
For UBIKITOS, a useful knowledge base is more than a cupboard full of documents. It should help the next working session understand the decisions already made, the evidence behind them, and the unresolved questions. Otherwise every restart becomes a miniature archaeological expedition. The founder ends up acting as the index, the search engine, and the person who remembers which confident answer was later corrected.
Today provided a fairly good demonstration of why that matters.
What actually changed
By the end of this work, the independent review was still pending. The blocked implementation had not become authorised through persistence, clever wording, or a growing collection of preparation files.
What had changed was the readiness of the handoff. There was a clearer review packet, an explicit sequence for what would follow, and a separate knowledge-base queue grounded in an inspection of the existing project. There was also a much more accurate answer to the question that started the conversation.
Building a company with AI includes days like this. No dramatic launch. No customer success story to borrow from the future. A resource limit, a few corrections, a stack of useful preparation, and repeated attempts to find the next honest step.
The part worth keeping is the insistence on a specific answer. What is blocked? What is already done? What can still move? Those questions are more useful than either unlimited optimism or a blanket stop sign.
My next step was to carry the prepared work into the independent review when it became available and keep the separate knowledge-base work properly scoped. That was the plan at the time, not a claim that either was already finished.
The credits could wait. The question “what can we do meanwhile?” had already found an answer.