Dario Amodei, CEO of Anthropic, at Davos: his engineers have already stopped writing code. They give the AI a task, then edit the output.

His prediction: within 6-12 months, AI will do “most, potentially all” of what software engineers do end-to-end.

And honestly — in the last month, we’ve built an enormous amount of features and code, and barely opened the code itself. So he’s not wrong about the direction.

But here’s what bothers me about this narrative.

Code is not engineering

Yes, AI can generate code. Complex code. Good code, even. But engineering is not syntax.

I’ve watched technically perfect solutions fail because nobody thought through how people would actually use them. Or what happens when a feature is so confusing that it becomes useless despite working flawlessly.

Engineering includes:

  • Risk assessment that nobody documented — the kind that lives in someone’s head because they’ve seen the failure mode before
  • Communication across five departments to align stakeholders who have conflicting priorities
  • Iterative refinement when requirements are unclear — and they are always unclear
  • Understanding what users need versus what they say they need

Can AI predict that launching a feature will require 42 iterations of a press release to avoid a public scandal? That’s a real case I lived through.

The “editor” role is more interesting than it sounds

“Editor” might sound like a demotion. But editing AI-generated code is actually:

  • Being a risk and applicability filter — catching the subtle bugs that are technically valid but operationally dangerous
  • Bringing structural thinking before code generation — asking whether this even solves the real problem
  • Understanding second-order effects — what happens downstream when this code ships

Work that requires deep context, strategic thinking, and understanding of second-order effects is harder to automate than syntax. Much harder.

Junior roles will feel it first

Both Amodei and the CEO of DeepMind have noted that hiring for junior engineering roles is already slowing down. This makes sense — the tasks that used to be entry-level (implement this endpoint, write these tests, fix this CSS) are exactly what AI handles best.

But here’s the counter-intuition I’ve arrived at: right now, I’d rather hire a smart, motivated junior and teach them what matters than bring on an elite-but-toxic senior.

Why? Because the skills that matter going forward — context building, risk thinking, communication, systems understanding — are trainable. Raw intelligence plus willingness to learn beats crystallized expertise plus resistance to change.

The shift is real. We felt it clearly with the latest generation of models. In a month, you can build something serious.

What engineering leaders should do now

If you lead or manage a technical team, now is the time to reassess which skills your team needs to train to remain valuable a year from now.

The focus on context, risk thinking, and communication may prove more important than syntax.

The engineers who thrive won’t be the ones who write the most code. They’ll be the ones who:

  1. Know when to trust the AI output and when to reject it
  2. Can articulate what needs to be built before a single line is generated
  3. Understand the system well enough to spot what the AI missed
  4. Communicate the “why” to humans who can’t read code

That’s not a demotion from “engineer” to “editor.” That’s an evolution from “coder” to “engineering leader.”

At Finsi, every engineer on the team operates this way already. The spec comes first. The AI implements. The human validates, refines, and owns the outcome. The role has changed. The importance hasn’t.