🔁 We’ve Been Here Before Link to heading
Every few decades, the job of a developer gets redefined by a tool that does part of the work for you.
AI coding agents feel unprecedented. I don’t think they are. I think they’re the same kind of shift as high-level languages and the IDE — and that comparison tells us something useful: what’s missing.
This is a speculative post. I’m not predicting products; I’m describing a gap.
🏗️ The First Time: “Automatic Programming” Link to heading
In the 1950s, the tools we now call compilers were sold as “automatic programming.” The pitch was that the machine would write the program for you.
Programmers were skeptical, and they had reasons. John Backus, who led the FORTRAN team at IBM, later wrote that early automatic programming systems often slowed programs down by a factor of five to ten, and that the claims made for them were overstated. Hand-written code was simply better.
FORTRAN won because its team treated that skepticism as the requirement. Their goal was generated code that could compete with what a good programmer wrote by hand. When the compiler shipped in 1957, by most accounts it often did.
Notice what happened to the job. The skill of hand-allocating registers didn’t disappear overnight, but it stopped being the center of the work. The center moved up — to algorithms, data structures, program design.
🖥️ The Second Time: The IDE Link to heading
The IDE was a quieter version of the same shift.
Turbo Pascal, in 1983, put the editor, the compiler and the error list in one place. You compiled, it showed you the error, and it put your cursor on the line. That sounds trivial now, but it changed how fast you could learn — and how fast you could iterate.
Then IntelliJ IDEA, starting in 2001, made automated refactoring normal for Java developers. Rename a method across a codebase. Extract a method. Change a signature. Work that used to be careful, error-prone, manual editing became a menu action.
And again, the job changed. I’ve been writing Java for a long time, and I don’t miss memorizing APIs or doing a rename across forty files by hand. The skill moved from “can you do this mechanical change correctly” to “should this change be made at all.”
🤝 Why We Trusted Those Tools Link to heading
Here’s the part that matters for AI.
We came to trust compilers and IDEs for specific reasons:
- They’re deterministic. The same input gives the same output. A compiler that produced different code on every run would never have been accepted.
- They’re specified. A language has a spec. A refactoring has defined semantics. You can reason about what “rename” will do.
- They show you before they act. A good IDE refactoring shows you every usage it’s about to change, and you approve the change as one unit. You don’t approve each edit — and you don’t approve blindly either.
That last point is the one I keep coming back to. The IDE found the right level at which to ask for approval: it asks about the decision, not about every keystroke that follows from it.
⚡ What’s Different This Time Link to heading
AI agents break all three of those trust properties at once.
They aren’t deterministic — the same request can produce a different change tomorrow. They aren’t specified: there’s no spec for what “add validation to this endpoint” will do. And they don’t just transform text. They act. They run commands, install dependencies, edit many files, call networks, open pull requests.
Today’s tools mostly offer two approval levels, with allowlists in between:
- Ask for everything. Every command, every file write. It’s safe in theory. In reality it trains you to click “yes” without reading, which is worse than not asking.
- Ask for nothing. Let the agent run and review the result. It’s fast. It also pushes all the judgment to the end, where the diff is large and the decisions are buried. I wrote about that failure in Review Early.
Neither is the right granularity. Approving ls is noise. Not approving a database migration is negligence. IDEs took years to get this right for refactoring — we’re at the very start of getting it right for agents.
🧰 The Tools That Don’t Exist Yet Link to heading
Here are the tools I think we need. Some have early versions; none are mature.
🎯 Approval by Consequence, Not by Command Link to heading
The question shouldn’t be “may I run this command?” It should be “this action does X — is that OK?”
Reading code, running tests, and editing files in a working branch are cheap and reversible. Writing to a shared database, touching auth, changing a public API, pushing to a remote, spending money — those are consequences. A good supervisor asks about consequences and stays out of the way for the rest.
That means the tool has to understand what an action does, not just what it’s called. rm in a temp folder and rm in a data directory are the same command with very different consequences.
🗺️ A Plan You Approve, Like a Refactoring Preview Link to heading
Before an agent writes a thousand lines, it should be able to show me the shape of the change: which files, which interfaces, which behaviors change, which decisions it made on my behalf. I approve the plan the way I approve a refactoring preview. Then the mechanical work runs without asking.
🔬 Semantic Diffs Link to heading
A line diff tells me what text changed. I want to know what behavior changed. “This endpoint now returns 409 instead of 400 for duplicates.” “This field is now nullable.” “This job now retries three times.” That’s what a reviewer actually needs — and today they have to reconstruct it from the diff.
🐞 A Debugger for Decisions Link to heading
When a compiled program misbehaves, I’ve got stack traces and a debugger. When an agent does something wrong, I’ve got a long transcript. I want to see which instruction — or which piece of existing code — led to a decision, so I can fix the cause instead of the symptom.
🧾 Provenance Link to heading
Which lines did an agent write, from which request, reviewed by whom? For regulated work, that becomes an audit question. I raised it in the CodeSpeak post, and it still doesn’t have a good answer in everyday tooling.
📈 Trust That Grows Link to heading
We don’t give a new developer production access on day one. They earn scope by showing judgment. Agent permissions should work the same way: narrow at first, wider in areas where the track record is good, and narrow again after a mistake. Today, most permissions are static settings.
🧠 The New Skills Link to heading
If the tools change, the skills change. The developers who do well in this shift will be good at:
- Stating intent precisely. Not prompt tricks. Clear requirements, constraints and non-goals.
- Designing tests as oracles. Tests that would actually fail if the behavior were wrong are what let you trust code you didn’t write.
- Reviewing at the right altitude. Approving plans and contracts, not reading every generated line with equal attention.
- Knowing which actions matter. The core of the approval problem. Experienced developers already have this instinct — it just isn’t encoded in any tool yet.
- Delegating. This looks a lot like the job of a working tech lead: set the intent, define the box, check the result, keep the risky decisions. If you’ve managed people, you’ve got a head start. I wrote about that side in Leading Without Letting Go.
None of these are new skills. What’s new is that they move from “senior developer” to “every developer.”
🤔 Where I Could Be Wrong Link to heading
The obvious counterargument: maybe models get reliable enough that we stop supervising them, the way no one reads compiler output anymore.
I don’t think that’s the near-term path. We stopped reading compiler output because compilers are deterministic and specified, not just because they got good. Agents are getting better quickly, but “usually right” isn’t the same property as “defined behavior.” Until something closes that gap, the trust has to come from the tooling around the agent — what it asks, what it shows and what it records.
It’s also possible the tools I’m describing get built into the agents themselves rather than into the IDE. Honestly, I don’t much care where they live. I care that they exist.
✅ My Take Link to heading
High-level languages took the machine out of the center of the job. IDEs took the mechanics out. AI agents are taking a large share of the typing out.
Each time, the work moved up a level, and each time the industry needed new tools before it could trust the new layer. The compiler needed to prove it could match hand-written code. The IDE needed refactoring previews and real error lists. The agent needs a supervision layer — one that asks about the decisions that matter and gets out of the way for everything else.
We haven’t built that layer yet. Whoever does will define how the next generation of developers works. And if they get it right, I suspect we’ll look back on today’s “allow this command?” prompts the way I look back on renaming a method across forty files by hand — with a little nostalgia, and no desire at all to go back.
Sources
Related Posts