Blog
The Developer's Role in the Age of AI: From Executor to Director
In 2021, I wrote code line by line. In 2026, I write the spec and direct the agents that execute it — while staying in command. That's not a prediction. It's already how I work, and if you've touched an AI coding assistant more seriously than autocomplete in the last year, it's probably how you work too, whether you've named it yet or not.
I gave a version of this as a talk at GDG Brescia in July 2026. Writing it down forces a level of precision that a stage doesn't — no gestures, no slides to lean on, no room to wave a hand and say "you know what I mean." So here's the derivation, in full.
The job that's disappearing (and the one that isn't)
Start with the flow every developer recognizes: someone opens a ticket, someone else picks it up and implements it, two people review it, tests go green, it merges, it ships. Only after describing that flow do the names matter — Git, pull requests, code review.
That flow works because it splits responsibility cleanly. You own the how. Someone else — a tech lead, a PM — has already taken responsibility for the what and the why. For the person implementing, the risk is close to zero.
That split is what's moving. Not disappearing — moving up a level.
From autocomplete to autonomy
The shift didn't happen in one jump, and most of us lived through every stage of it without stopping to name any of them. First autocomplete — two years ago, "does it actually help?" was still a fair question to ask out loud in a standup. Then chat: you ask, the model answers, you decide whether any of it is usable. Then, more recently, an agent: you hand it an objective, it takes several steps on its own, and your job becomes reviewing what comes back rather than producing it.
A May 2026 Google/Kaggle whitepaper by Addy Osmani, Aditya Saboo, and Sotiris Kartakis, "The New SDLC With Vibe Coding," maps this as a progression from autocomplete through inline suggestions and chat to coding agents and, eventually, more autonomous ones — each generation keeping what came before and raising the ceiling on what a single engineer can get done. The paper's own framing is the one that matters here: this isn't a maturity ladder or a product timeline. It's a description of where human effort moves — from syntax toward intent, evidence, and judgment.
Here's the analogy that made it click for me: an agent is less like a junior you hand a line-by-line instruction list, and more like a junior you hand a goal, the tools to pursue it, and permission to get some of it wrong. Your job stops being "write every line" and becomes "write the goal precisely, and check what comes back."
Two people who work on agentic coding tools every day put this better than I can. Peter Steinberger: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." Boris Cherny, who leads Claude Code at Anthropic: "My job is to write loops." Neither is saying the work got easier. They're saying the leverage point moved.
If the AI writes more of the code, you review more of it — and the actual bottleneck shifts to decision-making: picking the right problem, making the real tradeoffs, validating assumptions, deciding what not to build.
The ticket → PR → review flow from the first section doesn't go away. It moves up: not line-by-line code review anymore, but review of specs and decisions. That's also, not coincidentally, why spec-driven development is turning into a default rather than a nice-to-have. A good technical spec today does the job a good PR did a few years ago.
The contract before the loop
Here's a sentence I'd give any team, deliberately ambiguous: "Update the frontend to follow the design guide."
Sit with it for a second and the missing decisions surface fast: which screens? Style only, or copy too? Can new dependencies come in? How do you actually verify palette, naming, and the words that aren't allowed? Hand that sentence to an agent instead of a person and none of those gaps close on their own — they just move into the generated code, invisibly.
I've started running any task like that through four questions before it goes anywhere near an agent — a framework Romin Irani has written about, and I use it as a checklist, not a sacred template. What's non-compliant right now, concretely? What are the actual requirements — naming, copy, UI, all of it? What's out of scope, and can new dependencies come in or not? And, the one people skip and the one that matters most: how do you verify it — a build that has to pass, a brand check that has to run clean, a grep for the phrases you've banned, a before/after you can actually look at.
There's a difference between "it should be fast" and an acceptance check you can actually run, and that difference is the whole game. A useful rule of thumb: if the next decision depends on seeing an intermediate result, keep it in chat. If you can pre-answer the open questions and write concrete checks instead, the task is a candidate for more autonomy.
Following the design guide doesn't remove the ambiguity — it just relocates it into the generated code. Requirements say what to produce. Checks say when to stop.
What the director actually does: loop engineering
Here's the part that made the talk's technical core, and the part I think matters most in practice.
An agent doesn't do one thing and stop. It runs a loop: investigate, implement, verify, repeat — until some stop condition is true. Designing that loop well is what Addy Osmani, in a June 2026 piece, calls loop engineering: "stop being the person who prompts the agent — design the system that prompts it for you."
It helps to see it as a stack that grows one layer at a time:
- Prompt engineering governs the single instruction. Get it wrong and the model ignores a constraint.
- Context engineering governs everything the model sees in a given turn. Get it wrong and you get a confident answer built on stale information.
- Loop engineering governs how the work continues across turns — verification, retries, budget, when to stop. Get it wrong and the loop drifts, retries forever, or stops too early.
A useful heuristic: if the context is wrong, the loop doesn't fix it — it repeats it.
What's a loop actually made of? Osmani names five pieces. Worth saying plainly, because this tends to turn into a tool war fast: both Claude Code and Codex have all five. Stop arguing about which tool. Design a loop that holds up regardless.
- Automations — the heartbeat.
/loop, cron, hooks, CI. The automation surfaces work on its own and brings you the result; you're not the one polling. - Worktrees — parallel agents that don't collide on the same files, for the same reason two developers committing to the same lines without talking to each other is a bad idea.
- Skills — project knowledge written once, so the loop doesn't reconstruct it from a confident guess on every run. The agent forgets. The repo doesn't.
- Connectors (via MCP, in practice) — the loop acting inside your real tools: opening the PR, updating the ticket, pinging the channel once CI is green.
- Sub-agents — arguably the most useful piece: separating who writes from who checks, because the agent that made something is a lenient grader of its own work.
There's a sixth, unglamorous piece underneath all of it: durable memory that outlives the single conversation. A markdown file. A board. Whatever survives after the chat window closes and still tracks what's done and what isn't.
The primitive that ties it together already has a name in some tools: a goal that keeps running until a condition you wrote is true — "all tests in this suite pass and lint is clean" — checked by a model that isn't the one that did the work. Maker and checker, applied to the stop condition itself.
"Your job is to ship code you've confirmed works." And the corollary that gets lost in the rush to ship: "done" is a claim, not proof.
This is where the director framing earns its keep. Typing the lines isn't where your value sits anymore. Defining "done" so it's executable, then actually verifying it — that is.
Stop conditions aren't optional: an iteration cap, no-progress detection, a budget ceiling on tokens or spend. Without checks and stop conditions, a loop doesn't correct bad judgment — it amplifies it, at machine speed.
Where it breaks: a real recording, not a demo
For the talk, I didn't run a live demo — I showed a real recording instead, because live demos have a way of finding the one edge case you didn't rehearse. The sequence mattered more than the tool: spec → plan → first attempt → a red check → a fix → the same suite green → a verdict.
The task was narrow on purpose: bring a small frontend in line with a design guide, fix a wrong brand name, strip out a couple of banned phrases. Small enough to watch end to end, real enough to show what "verification" means in practice — a brand-compliance check, a build, a repository-wide search for the forbidden strings, a visual diff before and after.
The first attempt wasn't perfect — it left a leftover in a footer nobody asked for. The check caught it and pointed at the exact file and line. The fix was small. The same suite went green the second time. The verdict looked at the diff and the scope, not at whether the model said it was done.
That's the whole point of the check: it doesn't prove the agent is bad. It proves the process has a sensor capable of contradicting it. Approve because of the evidence and the scope — never because the model reported success.
When one agent isn't enough (and when it's still the wrong question)
There's a genuinely funny footnote in the history of this debate: in June 2025, within a day of each other, one well-known engineering team published "Don't Build Multi-Agents" and another published an internal evaluation claiming a roughly 90% improvement over single-agent performance on a specific task. A year later, the first team shipped a feature for orchestrating multiple instances of its own agent. Both were right — the disagreement was about scale and separability, not about whether multi-agent systems work at all.
Multi-agent — many agents on the same objective, coordinated through a shared channel instead of a single call stack — is a real pattern, not a myth. It's also genuinely expensive: coordination overhead that grows faster than linearly with the number of agents, and a meaningful share of failures in multi-agent systems that structurally can't happen in a single-agent setup, per early academic work on the topic (treat the exact figures as early and worth checking against the source, not settled numbers).
The takeaway I'd defend: prompt, then context, then loop — and only then, if the problem is genuinely large and separable, multi-agent. Almost every "we need multi-agent" I've seen up close was actually a single loop designed poorly. Fix the loop before you multiply the agents.
Worth saying, since it comes up constantly: this isn't a Google-versus-Claude argument. Both Google (Gemini Enterprise Agent Platform, Google ADK) and Claude (Claude Managed Agents, Claude Code) give you real, production-usable building blocks for this — orchestrated multi-agent systems on one side, tool-using sub-agents on the other, with real tradeoffs in each direction depending on what you're building. Anyone telling you there's a universal winner is selling something.
Why this matters beyond your own terminal
What moved is where the value sits, not whether it's there at all. "How fast do I produce code" stopped being the measure of your worth a while ago. What replaced it: how well you decide what to build, and how rigorously you verify it actually got done. Ship code you've confirmed works, not code a model claims works.
Here's the image that's stayed with me since I first read it: two people can build the exact same loop and get opposite outcomes — one uses it to move faster on something they understand deeply, the other uses it to avoid understanding it at all. The loop can't tell the difference. You can.
For anyone leading a team, the competitive edge tomorrow isn't having the fastest agent. It's having people who know how to direct one well.
One developer's version of this, lived differently
I shared the stage with Nicola Luna, who came into software development through a different door than most of us in that room. He didn't start with a classical software engineering path — he started directly in the era of AI assistants, using Claude both as a tutor and as a working tool from day one.
What struck me listening to him talk about his own path isn't that AI compressed his path to writing syntax — of course it did. It's that knowing why an answer is right, and owning the result if it isn't, still had to be built the hard way, on top of that head start. AI can shrink the distance to a working answer. It doesn't shrink the distance to actually knowing why the answer is right.
The callback
Steve Ballmer's most-quoted rant is about developers being the reason a platform wins or loses. That's still true. What moved is where that edge comes from: not the lines you type, but the loops you design and the decisions you verify.
You're still the developer he was shouting about. You're just the one who designs the loop now — and stays the engineer, rather than becoming the person who just presses go.
This article is adapted from a talk originally delivered at GDG Brescia in July 2026, alongside co-speaker Nicola Luna. The full recording is on YouTube, and the rest of my speaking history is on gazzurelli.com/talks.
Questions or a different read on this? I'd genuinely like to hear it — reach me on LinkedIn or X.
Matteo Gazzurelli is a Fractional CTO and Agentic AI Consultant based in Brescia, Italy. With 25+ years in software development and multiple Google Cloud and AI certifications, he helps startups and SMBs implement multi-agent systems on Google (Gemini Enterprise Agent Platform + ADK) and Claude (Managed Agents, Code) — systems that work in production, not just in demos. Connect on LinkedIn or learn more at gazzurelli.com.