If AI can write code, what are you actually paying an engineering partner for?

I’ll say the quiet part first: a good chunk of what used to take a junior engineer a full day now takes an AI assistant a few minutes. Boilerplate, CRUD endpoints, a first pass at a test suite, a rough draft of a migration script. If you’ve watched a demo of any of the current coding assistants and thought “wait, why am I paying someone for this,” that’s not an unreasonable thing to think. I think it too, some days.

So let’s actually answer it, instead of pretending the question is rude to ask.

What AI is genuinely good at

It’s good at the parts of software that are mechanical: syntax, boilerplate, turning a clear specification into working code, catching the kind of bug a linter would eventually have caught anyway. Those parts were never where the expensive risk lived. They were just slow and annoying to type out by hand, and now they’re fast. That’s real, and I’m not going to pretend otherwise to protect anyone’s job, including my own.

What it hasn’t touched

Here’s what it hasn’t done: it hasn’t figured out, on its own, that the “simple” feature your product team asked for actually conflicts with how your finance system reconciles at month end, because nobody wrote that constraint down anywhere a model could read it. It hasn’t sat in a room with your compliance officer and worked out what “handle this data correctly” means for your specific regulator. It hasn’t looked at four systems built over twelve years by four different teams with four different opinions, and decided, with real accountability for being wrong, which one gets to be the source of truth.

That work was always the expensive part, because it was always the hard part, and it still is. AI tools have made the cheap part of software even cheaper. They haven’t made the expensive part cheap. If anything, they’ve made it more important to have someone good at the expensive part, because the fast, cheap part is now available to everyone you compete with too.

The code was never the hard part. Deciding what to build, how it fits with everything you already have, and who’s accountable when it breaks: that’s the job. It always was.

The accountability question nobody says out loud

Here’s what I think gets skipped over in most of these conversations. When an AI-generated integration quietly corrupts a batch of records at two in the morning, who gets paged? When a generated migration drops a column nobody double-checked, who’s on the call explaining that to your board, or to a minister? An AI assistant doesn’t carry that. A person does, and that person being good at their job, with something real at stake if they get it wrong, is most of what you were actually buying when you hired an engineering partner in the first place.

So what actually changes

My honest answer is: use the tools, don’t romanticise the typing, but be more careful, not less, about who you trust with architecture, integration and the decisions that are genuinely hard to reverse. The bar for “can produce working code” has dropped for everyone at once. The bar for “can be trusted with a system that has to run correctly for the next five years, integrated with everything you already have, with someone accountable when it isn’t” hasn’t moved at all. If anything, that’s the whole game now.

If you’re weighing that decision for something you’re building, I’d rather have that conversation directly than guess what you need.

— Ali