What actually changes when you ship with an AI pair

I build and ship software with AI assistance every week, alongside a full-time job. I should be upfront about what that means: I do not hand-write the code. I direct it. What I bring is fourteen years of SDLC, DevOps and AWS, and enough product judgement to know when a thing is actually done.

Most of what gets written about working this way is either a sales pitch or a eulogy. Here is the honest ledger.

Where it earns its keep

The boring eighty per cent. Scaffolding, wiring, migrations, the fourth CRUD screen, the test you know you should write and would not have. This is genuinely transformative, and anyone telling you otherwise has not tried it seriously.

Unfamiliar territory is the other big one. You can ask the same naive question ten times without burning a colleague’s patience, which means you venture into stacks you would previously have avoided. Several of the things I have shipped exist only because the cost of starting dropped far enough that a weekend was enough to find out whether the idea had legs.

The honest summary is that it collapses the distance between “I could build that” and “I built that”. For anyone with more ideas than evenings, that is the whole game.

Where it quietly costs you

The failure mode is not gibberish. If it were, this would be easy. The failure mode is confident, well-formed, plausible, and wrong.

Rebuilding these two sites recently, in one working day, the following all happened. A career timeline came back with specific employment date ranges that were invented outright — not wrong dates, invented ones, filling a gap to make a section look complete. A product was listed as live and clickable when its domain had quietly stopped resolving months earlier. A partner tier was asserted that nobody could verify. And a config file passed a local parser cleanly while the real build had been rejecting it for the best part of an hour.

Every one of those was confident. None of them looked like an error. That is the tax, and it is not small: the work moves from producing to verifying, and verifying is the harder skill.

The check that passes while the thing is broken

The config failure is the one I keep thinking about, because it was not really an AI failure. The file parsed fine locally. It was the build system that rejected it, using a stricter parser. The local check was green and meaningless.

That is a rule worth writing down: if a check can pass while the thing is broken, the check is the bug. It was true before any of this, but AI assistance multiplies it, because you are now generating far more things to check and the temptation to accept a green tick is proportionally larger.

What I actually do now

• Verify against the real system, not a local approximation of it. The approximation is where the lie hides.
• Prefer things that fail loudly over things that fail politely. A build that stops is a gift.
• Treat every specific — a date, a number, a name, a URL — as unverified until something mechanical confirms it. Specifics are exactly where fabrication is most confident.
• Make claims checkable in the first place. A number with a source can be tested; an adjective cannot.
• Ship nothing I cannot check. If I cannot construct a test for a claim, it does not go out.

None of this is a reason not to work this way. I would not go back. But the pitch that AI removes the need for judgement has it precisely backwards. It removes the need for typing. Judgement is the part you now do all day.

It has not made me a faster typist. It has made me a slower, more suspicious reader — and on current evidence that is the skill that actually matters. The value was never in producing the lines. It was always in knowing which ones are wrong.