a2zdigia2zdigi
All posts
/Thinking

Notes on AI-assisted delivery (a year in)

What's actually working, what's still theatre, and where we're spending our time now that a lot of the boilerplate is gone.

It's been about a year since we rebuilt our workflow around AI tooling in a serious way. Not a demo, not an experiment — actual projects, actual clients, actual production. Here are some honest notes on what's worked and what hasn't.

The thing that's genuinely different is the boilerplate. Writing the first version of a form, a table, a CRUD endpoint, a migration — the stuff that used to eat the first week of any project — now takes hours rather than days. Not because the work is skipped, but because the first draft is close enough that the remaining work is review and adjustment rather than blank-page writing. A good engineer with a good toolchain in 2026 can get a working internal app standing up in an afternoon. That's not exaggerated — it's just the baseline now.

The thing that's *not* different is anything that requires judgment. Deciding what to build. Deciding what to leave out. Deciding whether a database schema will hold up when the client's business grows. Deciding whether a particular UX will feel right to a specific user who hasn't seen it yet. These are the hard parts of software, and no amount of autocomplete fixes them. If anything, they've become more visible, because all the boring work that used to hide them is gone.

So the ratio of the work has shifted. We spend less time writing code and more time in conversations — with clients, with each other, in front of the running software. Week one of a project used to be "gather requirements, write a spec." Now it's "sit with the people who'll use the thing and watch them work." That sounds soft, but it's the part of the job that actually determines whether the project succeeds.

The theatre is real too. There's a version of AI-assisted delivery that's all the surface and none of the substance: demo-perfect prototypes that fall over on edge cases, generated code that nobody on the team can actually explain, test suites that pass because they don't test anything. It's tempting because the work looks fast. The problem is that it isn't, really — the time you save in week one comes back as a bill in month three, when nobody knows how the thing is put together and every change needs a rewrite.

The version that works is more boring than that. The AI writes a draft. A human reads every line. The human makes it make sense, removes the weird bits, checks it against the actual requirements, and commits it because they understand it — not because the model said it was fine. The ratio of "typed" to "written" has changed; the ratio of "understood" hasn't.

The honest summary, a year in, is that the tools made good engineers faster and made bad engineering faster too. The difference between the two kinds of output has grown, not shrunk. If you're commissioning software right now, the question to ask isn't "do they use AI?" — everyone does — it's "who's reading the output, and would you trust them to write it by hand?"