Generative AI is changing software engineering — but not, I think, in the way the loudest version of the story suggests. The story usually goes: models get better at writing code, so engineers write less of it, so engineers matter less. That’s the wrong axis. The interesting change isn’t how good the model is at producing a function. It’s how much of the work you can hand over in one go.

The step change nobody announced

We’ve moved through three modes already, and each one quietly enlarged the unit of work.

AutocompleteTHE NEXT LINE AssistantTHE NEXT EDIT AgentTHE WHOLE TASK WorkforceTHE BACKLOG SCOPE OF WORK HANDED OVER
Each step doesn't make the model smarter — it hands the model a bigger unit of work.

Autocomplete finished your line. The assistant answered your question and wrote a block. The agent takes a task and comes back when it’s done. Each transition felt incremental from the inside, and each one was actually a change in what you delegate: a keystroke, then an edit, then an intention.

The next step is the one worth preparing for: AI as a software engineering workforce — not one agent doing a task for you, but a set of agents working the way a team works, with all the coordination problems that implies.

What a coding agent already does end to end

Strip away the marketing and look at the loop an agent can actually close today. It can find its way around an unfamiliar codebase. Break a requirement into tasks. Change several files at once. Run the test suite. Read the failure, form a theory, and try again. Open a pull request. Review someone else’s — including another agent’s.

Read the codebase Break into tasks Change files Run the tests Read the failure Try again ITERATE Open a PR Review a PR TESTS PASS
None of these steps is new. What's new is that the whole loop runs without a person in the middle of it.

Every one of those steps is something a junior engineer does. None of them is impressive alone. What’s different is that the loop closes without a person standing in the middle of it, which means it can run more than once, in more than one place, at the same time.

That’s the moment the shape of the job changes. One agent finishing a task is a productivity tool. Ten agents finishing tasks concurrently against a shared codebase is a distributed system, and it needs to be designed like one.

The question the job is now asking

For most of my career the implicit question behind an engineer’s day was some version of: how fast can I get this built? Speed of production was the constraint, so speed of production was the skill.

THE OLD QUESTION How fast can I write code? THE ONE THAT REPLACES IT How well can I design,orchestrate and govern? Typing speed stops being the constraint —judgement about the system becomes it.
The scarce skill moves from producing code to deciding what should be produced, and proving it's safe.

When production capacity stops being scarce, the constraint moves upstream. It lands on the decisions that are hard to delegate: what should exist, how it should be carved up, what “correct” means precisely enough to check, and what an automated system must never be allowed to do on its own.

Ask the new question out loud and you can hear what it demands. Design means boundaries and interfaces that a machine can work behind without needing the whole picture in its head. Orchestrate means decomposition, sequencing, and knowing what can run in parallel. Govern means evaluation, permissions, audit, and a human signature on the things that can’t be undone.

Architecture gets more important, not less

I keep hearing that agents make architects redundant. My read is the opposite, and it’s not sentimentality about the job title — it’s what actually breaks.

An agent is only as good as the context it’s given, and context is a design artefact. Clear module boundaries mean an agent can change one thing without reading everything. A test suite that genuinely encodes intent turns “it compiled” into “it’s correct.” Explicit conventions turn ten agents into a coherent codebase instead of ten dialects of one. Every property that makes a system pleasant for humans to work in makes it tractable for agents — and every ambiguity a human would quietly paper over becomes a defect a machine reproduces at scale.

Requirement Orchestrator Context packSPECS · CONVENTIONS GuardrailsSCOPE · SECRETS Implement Test Review Gates — tests · policy · security scan Human review, then merge
The agents are the cheap part. The context, the gates and the last human signature are the design.

Notice where the actual engineering sits in that picture. Not in the boxes doing the implementing — those are increasingly commodity. It’s in the context pack that tells them what good looks like, the guardrails that bound what they may touch, the gates that decide what earns a merge, and the human review reserved for what’s irreversible. That’s an architecture problem with a security problem wrapped around it, and neither of them is going away.

Some things I’d treat as non-negotiable once you run more than one agent at a time:

  1. Least privilege by default. Read broadly, write narrowly, and never let an agent hold a credential it doesn’t need for the task in front of it.
  2. A gate that isn’t the model. Tests, type checks, linters, security scans — deterministic checks the agent cannot talk its way past.
  3. Bounded scope per task. An agent given an unbounded goal will find an unbounded amount of code to change.
  4. A trail you can read afterwards. Which agent, which prompt, which diff, which run. Debugging a fleet is archaeology unless you build for it up front.
  5. A human on the irreversible. Merges to main, schema migrations, anything touching production data or money.

So: better models, or better architectures?

Which brings me to the question I find genuinely open. The next real productivity leap — does it come from better models, or from better agent architectures?

ONE LEVER YOU RENT A bigger model FIVE YOU OWN Decomposition Context management Evaluation Security and guardrails Human oversight
Model quality arrives on someone else's release schedule. The other five ship whenever you decide to build them.

I lean toward the latter, for a fairly unromantic reason. Model quality arrives on someone else’s schedule, and it arrives for your competitors on the same day it arrives for you. Decomposition, context, evaluation, guardrails and oversight arrive when you build them, and they compound with whatever model you happen to be running. They’re also the levers that decide whether a stronger model makes your system faster or merely makes it fail in more creative ways.

The engineer of the near future probably spends less time implementing individual functions and more time designing the system that lets multiple agents safely build, test and evolve software. That’s not a smaller job. It’s the same job it always was — decomposition, contracts, verification, blast radius — finally with enough leverage behind it to matter.