Software engineering is dead. Implementation engineering is next.

AI agents write most of the code now. Not "can help write" — actually write it, end to end, for a growing share of everyday development work. That's not a prediction, it's already how a lot of software gets built. What's changing isn't whether this happens. It's what the person's job becomes once it does.

"The AI's output isn't good enough" isn't the argument it used to be

The most common objection is quality — the code an agent writes doesn't match what an experienced engineer would have written. That used to be a real limitation. It's a weaker argument now, because you can teach it.

Skills let you encode your own principles, patterns, and hard-won experience directly into how the agent works — the conventions you follow, the mistakes you've learned to avoid, the shape you want the output to take. Once that's written down properly, the agent writes closer to how you would. If the output still isn't good enough, that's usually a sign the standards weren't actually specified, not that the technology can't meet them.

That's an uncomfortable shift for anyone whose complaint about AI output has been "it's just not as good." Quality is increasingly on the person guiding it, not a ceiling the model itself imposes.

The loop that actually improves things

This isn't "set it and forget it." It's iterative:

1. The agent produces work.
2. A person reviews it — QA, in the plain sense.
3. Whatever the review catches gets fed back into the skill, so the same mistake doesn't repeat.
4. The next pass starts closer to right.

Each round tightens the gap between "AI output" and "what I would have written myself." It still needs review — that doesn't go away — but the amount of correction needed per round should keep shrinking if the loop is actually being run.

What the job becomes

Less time writing code line by line. More time doing two things: orchestrating — deciding what agents work on, in what order, with what guidance — and quality assurance — reviewing what comes back, catching what's wrong, and feeding it back into the system. That's a genuinely different skillset from software engineering as it's been practiced for decades, even though it still requires deep technical judgement to do well.

What this means if you're the one buying the software, not building it

For a business owner working with a development team or an agency, this changes what you should actually be evaluating. The question isn't "do they write code by hand" — increasingly, nobody fully does. The question is whether the team has a real review process: do they actually check what the AI produces, do they have standards written down somewhere an agent can be taught, and can they explain why something was built a particular way, not just point at working software. A team that's skipped the QA loop entirely is the one likely to hand you something that looks fine on the surface and breaks in the ways confident-but-wrong AI output tends to break.

The open question

Here's the part without a clean answer yet: if a junior engineer's path into the field used to be years of writing code by hand, and that's increasingly automated, how do they build the judgement to review AI output well? Reviewing well depends on having built things badly first and learned why. It's not obvious that skips cleanly.

And the honest follow-up: models in 2022 could barely hold a coherent function together. Given that pace, how many years before review itself stops being the bottleneck too? Nobody actually knows. Worth sitting with the question rather than assuming either extreme — that nothing changes, or that the answer is already obvious.