A developer recently gave Claude Code write access to a live Meta Ads account. The agent’s read-only analysis was genuinely valuable; it correctly identified the cheapest campaign as having the worst ROI. The insight was good. The judgment about what to do next was absent. The agent executed autonomously, triggered API rate limits through automated publishing, and resulted in the account being permanently banned. The read was right, the write destroyed the business relationship.

Someone needed to sit between the insight and the action. No one did.

That someone is the engineer.

The question nobody is asking cleanly

The industry has spent two years asking whether AI will replace engineers. That’s the wrong question, and it’s producing the wrong anxiety. The right question is: what does craft look like when execution is cheap?

Execution is becoming cheap; an engineer who once spent three hours writing a data pipeline can now have a working draft in fifteen minutes. That is not a threat to the profession; it is a change in where the profession’s value lives.

The mistake is assuming that because the output arrives faster, the judgment required to evaluate it has also become easier. It hasn’t. If anything, it’s harder because the output looks more finished, the surface is more polished, and the failure modes are buried deeper.

The engineer who rubber-stamps AI output isn’t fast. They’re a liability with a commit message.

What structural hardening actually is

There’s a phrase worth using deliberately: structural hardening. It’s what happens when an engineer takes AI-generated code and turns it into production-grade code. Not just testing it. Interrogating it.

Structural hardening is a practice, not a checklist. It looks like:

Questioning the assumption, not just the output. AI generates code that satisfies the prompt. The prompt is almost never the full specification. An engineer doing structural hardening asks: What did I not say, and what did the model assume? What edge case does this solution ignore because I didn’t mention it?

Tracing the logic, not just running the tests. The multi-agent orchestration failure is instructive here: Claude Opus spawned four agents to test its own code, reported 100% success, and manual testing found 60%+ failure rates. The agents were testing what the code claimed to do, not what it needed to do. An engineer doing structural hardening reads the logic. They don’t outsource verification to the system that generated the thing being verified.

Owning the boundary decisions. Where does this service end and the next one begin? What gets written to the database versus what stays in memory? What triggers a human review versus what executes automatically? These are judgment calls. They don’t emerge from the code. They have to be imposed on it. This is what the Meta Ads story is really about: the read/write boundary was never defined. The agent didn’t violate a rule. There was no rule. The engineer’s job was to establish one before granting access.

None of this is new work. It’s the same work engineers have always done. The difference is that AI compresses the timeline so aggressively that teams mistake the speed of generation for a signal that the hardening can be skipped.

It cannot be skipped. It is the job.

The two engineers in the room

Here’s a clean distinction that’s worth holding onto. In any AI-accelerated team, you will find two types of engineers working with the same tools.

The first uses AI to go faster. They prompt, review the output at a surface level, commit, and move to the next ticket. Velocity is high. The work feels productive. The problems are downstream and subtle: architectural drift that compounds over sprints, edge cases that the AI handled plausibly but incorrectly, boundary decisions that were never made explicitly, and so were made implicitly by whatever the model assumed.

The second uses AI to go deeper. They use the time the AI saves on generation to do the thinking the AI cannot do: interrogating assumptions, stress-testing edge cases, making the boundary decisions explicit, and documenting the judgment calls that future engineers will need to understand. Their velocity looks similar on a sprint board. Their risk profile is categorically different.

The JDD framework calls this the judgment layer. The engineer’s job is not to generate output. It is to own the quality of the decisions embedded in that output.

The gap between these two engineers is not in skill with AI tools. It is discipline about what the tools are for.

Craft identity is not threatened, it’s elevated

The engineers who feel most threatened by AI are usually the ones who defined their identity around execution skill: I write good code, I write it fast, I write it clean. That identity is under pressure. The AI writes code too, and for a large class of problems, it writes it adequately.

But the engineers who feel most energized right now are usually the ones who defined their identity around judgment: I understand systems, I see failure before it happens, I know when the technically correct answer is the wrong answer for this context. That identity is not under pressure. It is in higher demand than it has ever been.

The shift isn’t from engineering to something else. It’s from engineering-as-execution to engineering-as-judgment. The craft is still craft. The medium has changed.

A great engineer in 2026 looks like this: they use AI fluently, they do not trust it unconditionally, they harden everything that touches production, they make boundary decisions explicitly, and they can articulate why they made them. They are faster than the engineer who doesn’t use AI and more reliable than the engineer who uses it without discipline.

That is the role. That is what’s worth being good at.

The accountability that doesn’t transfer

One more thing, and it’s not subtle.

When the agent acts, the human is still accountable. The developer whose Meta Ads account was banned did not get to say “the AI did it.” The account is gone. The client relationship is gone. The agent executed. The engineer owned the outcome.

This is not going to change. As AI systems become more capable and more autonomous, the surface area of human accountability does not shrink; it shifts. Engineers stop being accountable for whether the code runs and become accountable for whether the system was designed to make the right decisions in the first place.

That is a harder job. It requires better judgment, not less. The engineers who understand that now are the ones who will matter most in three years.