Is software engineering quietly becoming implementation engineering?

I've been wondering if "software engineer" is quietly becoming "implementation engineer." Not because AI writes good code now — that part everyone's already arguing about. It's the other thing worth noticing: how much of what used to be built now just ships.

The build surface is shrinking

A concrete example: Anthropic released a Commerce Agent blueprint a few days ago — prebuilt shopping and merchant agents, catalog search, cart logic, the kind of work that used to take a team weeks to build from scratch. Now it's something you configure and adapt.

That's not an isolated case. RAG pipelines, connectors, whole categories of integration work — a lot of it is moving from "build it" to "adapt an existing blueprint." What's left looks less like writing the system from zero, and more like selecting, adapting, and implementing what already exists, then reviewing it closely enough to trust it.

On the "AI's output isn't good enough" objection

The most common pushback on AI-written code is quality — it doesn't match what an experienced engineer would write by hand. That's a fair concern, and it isn't fully solved. But in my experience it's less about the model than most people assume, and more about whether you've actually taught it your standards.

Skills let you encode your own principles, patterns, and hard-won experience directly into how an 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 noticeably closer to how you would. Models still make mistakes, and a better model genuinely helps regardless of how well you've briefed it — but a good chunk of the quality gap people blame on "the AI" turns out to be a missing set of instructions, not a hard ceiling.

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. Worth being honest about the flip side too: chaining more agent steps together, or adding more automated stages, doesn't automatically make things safer. Each step still carries its own chance of a small miss, and those chances stack rather than average out. More automation without more review at the right points is a real way to make things worse, not better.

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 increasingly, which existing blueprint fits the problem instead of building one
• quality assurance — reviewing what comes back, catching what's wrong, and feeding it back into the system.

That's a genuinely different emphasis from how software engineering has mostly been practiced, 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's worth evaluating. The question isn't "do they write every line by hand" — increasingly, nobody fully does, and that's fine. The better 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 review step entirely is the one most likely to hand you something that looks fine on the surface and breaks in the specific ways confident-but-wrong AI output tends to break.

The open question

Here's the part I don't have a clean answer for: if a junior engineer's path into the field used to be years of writing code by hand, and a growing share of that is automated, how do they build the judgement to review AI output well? Reviewing well tends to depend 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? I genuinely don't know. Worth sitting with the question rather than assuming either extreme — that nothing changes, or that the answer is already obvious.