What the work has taught me
Rob Nash Updated October 2026
What actually changed about building software once the agent writes the code, and what it still cannot supply.
Across every project
The craft that was already there matters more now, not less. You start with a wide vision, then narrow it to what gets delivered and when, and that was never optional. What changed is the cost of leaving it vague: an agent will build confidently into whatever the vision left open. How much narrowing is needed varies by project. Sometimes the product is obvious and most of it can be handed over. Sometimes I have to build a rough version by hand before I know what I want, and no amount of briefing substitutes for that. It is not only the product outline either. The technical approach needs the same treatment.
Handing a project over is still mostly a fiction. The choice is to curb the agent’s enthusiasm as you go, or to define sprints tight enough that there is nothing to curb. The second gets easier the longer a project runs: each completed sprint leaves a record behind it, and the more of that record exists, the better sense the agents have of where the thing is going.
The method has a running cost. The agents are billed by the token, and the more work you trust them with, the more you spend, so I price that into the work. That cost would shrink if these models ran on local hardware at the same quality, and in July 2026 I tested how close that is. A local 7B model invented details in three of eight summaries against my reference set, fluently enough that a quick read wouldn’t catch it, and the larger model that might have done better needs more memory than my machine has. So the work runs on hosted models for now. I’ve kept the test, so I can run it again when the models or the hardware change.
What Seen to Fail is teaching me
A green run looks the same whether a check is sharp or dead, and pointing this at my other projects showed how often it is dead. Mostly the check runs and is blind, green with the defect in place. Sometimes nothing runs it at all. Almost nothing had slipped through yet, which makes it insurance rather than a bug hunt.
What Quill taught me
A command line used to be a detour. With an agent it is an afternoon, so the cheapest version of an idea is now the one worth building first. I learned that by doing it last, after the app had already proved the same thing the harder way.
What the book taught me
I did not set out to write a book. Running an AI coworker generates a written record whether you want one or not, and once the same lesson had been re-learned three times the notes were most of a manuscript.
What Iris taught me
Deep links have been implemented badly, by me included, for as long as I have written apps. Claude produced something plausible at every step, and plausible is exactly the failure mode. What made the package good was having been burnt before and knowing which parts to challenge. The agent supplies the drafting; the scar tissue is still mine.
What Audient taught me
Don’t let the agent run the project. This one had no settled shape when it started, so every decision was open and the agent filled the gaps. Archive the decisions, keep the epics narrow, layer the code and stay critical about the architecture, and install hard gates.
What Hold’em is teaching me
This is the most hands-off project here and it is going the best. I gave it my own poker model and card code, defined a narrow MVP, and then largely left it alone. A game everybody knows, and clear logic already written, seem to be the conditions: the agent had a shape to work inside and very little to invent.
What TimeZone Arc taught me
I judged the idea simple, so I supervised it lightly. It turned out to be more involved than it looked, and by the time I noticed there were assumptions to walk back. How simple an idea sounds says nothing about how much attention the build will need.
What Planning Poker taught me
Very little so far. This is the only entry here that predates the agent, built by hand in 2024, so it has nothing yet to say about the thing every other entry here is about. I brought it back to carry on with an agent and then stopped almost at once. That gap is why it is still listed: everywhere else the agent shaped the work from the start, and this would be the one case of handing over a codebase I already know well.
What Birthday Sleeps taught me
This was the most design-critical thing I have built for Async Digital so far. A seven-year-old wants a screen that captivates her, and neither I nor the agent could produce one. The code was never the constraint. What I needed was a human designer, and I did not have one.
What Ordova is teaching me
It started as a way to keep my own preferences in my estate rather than a vendor’s, so the rules would travel with me. A few rules turned into a government with a charter. English is the programming language now, and English has no compiler: rules go stale, contradict each other quietly, and are never found by the thing that needed them. Most of the work here is that problem.
What adrelease taught me
I hit this once: a project with a tangled dependency graph, where bumping one package broke the others. I wanted it done in one step, so I built a tool. Building is cheap enough now that a problem you have had exactly once can still earn a whole tool, and this one is over-engineered for how often I have actually needed it.
What FourBlocker taught me
I built it to get a feel for Apple’s on-device foundation models: how fast they are, how they feel to use, whether they are useful. That I got. Shipping it would have meant a model drafting things about a user’s colleagues that I could not control and would be fully liable for, so I didn’t.