Most of the code on this site was written by Claude Code. I reviewed every diff, rejected some of them, and redirected the work more than once, but the typing was largely not mine. That has been my daily workflow for a while now, on client projects and my own, and it has changed my picture of where the time in software development actually goes.
The work that gets faster
The agent is fastest where I already know what the code needs to look like and the cost used to be typing and file hopping. Wiring a new endpoint through the same layers as the last one, renaming a concept across a codebase, scaffolding tests, writing a migration, and gluing in an unfamiliar library all fall into that category. None of that work was ever hard. It was just slow, and now it is not.
Another less obvious win is reading. Pointing an agent at an unfamiliar codebase and asking how a request flows from the route handler to the database is often faster than tracing it myself, and I can ask follow-up questions along the way. When I pick up a client project I have never seen, the orientation work compresses noticeably.
Where the saved time goes
Review absorbs a lot of it. The agent produces plausible code, which is dangerous because it builds and passes the tests. I have seen agents write code that calls APIs that do not exist, and write tests that hide errors instead of surfacing them, just to get a passing test. These do not look wrong at a glance, so some of the time I used to spend typing now goes into reading diffs carefully. I think the trade is still worth it, but it is not free, and anyone who merges agent output unread is going to find out why.
Ambiguous prompts eat time too. If I cannot explain what the correct code looks like, the agent cannot easily infer it. A vague request gets me a plausible guess followed by a correction loop. Writing the task down precisely, with the constraint and the reason for the constraint, costs a few minutes up front and usually saves the loop.
Knowing what to build
The tagline on this site says that AI writes code quickly, and that knowing what to write takes experience. Daily agent use has only sharpened that for me. The agent optimizes for the stated request. It will not tell me the feature is wrong, that the data model will hurt in six months, or that the whole thing should wait until there is traffic to justify it. Those calls come from having been responsible for the consequences, and they happen before the prompt is written.
The same applies to judging output. On a marketplace I built, Stripe once replayed a cached idempotency failure after a key rotation, and my retry logic faithfully resubmitted the same key while payouts kept failing. My code was correct and the system was broken. I later wrote up the full debugging story and the payout guards that came out of it. An agent has even less context about those sharp edges than I did at the time, so integration code with third party services is where I review hardest, because the failure modes live in behavior no diff can show.
The workflow that came out of it
I begin with a quick round of UX iteration with the agent, working out what the feature should do and how it should behave for the person using it, because that shapes everything after it. Then I hand the work to skills that walk the agent through planning in stages. It writes a spec, then a build plan against that spec, each as a markdown file I read and approve before the agent touches the code. Planning in plain text, where I can see the shape of the work and change it cheaply, is a good place to make the real decisions.
I keep conventions written down in the repo, because instructions the agent reads every session beat instructions I repeat in every prompt. Every project I work on now has a file describing the stack, the commands, and the rules that are not negotiable, and the difference in output quality is easy to notice. Once the plan is approved, the agent executes it mostly on its own through subagent-driven development and a self-review loop.
I don't delegate the final read to an agent. I go through the diff myself, checking that the code follows the patterns already established in the codebase, and then I run the feature to see whether it actually works for the person it's for. Even with Playwright letting the agent drive a real browser and see the result, it still does not understand how people actually interact with their devices, so I run the feature the way the end-user would before I trust it.
It still takes time to build good software, even though I can now do in a month what a team of us used to spend half a year on. The calls about what to build and when still have to be right. You can waste time and resources chasing the wrong things; we just get an answer sooner now, with fewer engineers (though keep an eye on your token budgets).
About the author
Graham Morley , Software engineer and technical leader
I have built and delivered production software since 2011, including SOC 2 Type 1 and ISO 27001 certified platforms, DeFi systems that held more than 20 million dollars with zero exploits, and AI products that raised private equity funding. I build, review, and lead engineering across the stack, and I work with AI coding agents every day.
Get in touch