Agentic Coding Needs an Air Traffic Control Shift Model
The strangers keeping your flight alive work in short, paired, exhausting shifts. Your developers don't. That is goin...
Agentic Coding Is Not 'Make Me X'
12 min read
Real Agentic Coding Starts With Boundaries
20.07.2026, By Stephan Schwab
A lot of executives hear "agentic coding" and imagine the end of developers. A lot of developers hear it and think it means writing a fancier prompt that says, effectively, "make me X." Both pictures are wrong. Real agentic coding is narrower, more disciplined, and far more useful than the hype. A human sets the bounds. The agent explores inside them. The work gets checked against code, tools, tests, and runtime evidence instead of vibes. That difference matters because the lazy fantasy is management catnip. If "make me X" were real software development, then architecture, repository knowledge, boundary control, and verification would all become optional. They do not. They become more important, because the machine can now multiply a bad framing decision much faster than a human team ever could. Good agentic work does not start with surrender. It starts with constraints: stay in this layer, inspect these patterns, do not solve the future yet, verify against the system that actually exists. That is why agentic coding is useful to serious developers and dangerous in the hands of executives looking for a shortcut around software judgment. The story is not "developers are finished." The story is "developers with judgment just got more leverage, and everybody without judgment just got faster at making expensive mistakes." Where are you still treating "make me X" as if it removed the need for technical judgment?
The cleanest way to explain agentic coding is not with a product demo. Product demos lie for a living. The cleanest way is with an actual working prompt and the shape of the answer it produces.
A developer framed a task roughly like this: stay inside Spring events, do not wander into the UI, do not drift into user-facing concerns, and help define a system where emitters and consumers can be added later. Contact and calling or email is only the first case. The future may include UI access and conversational AI tools, but not now. Start with the event architecture.
That is already a different class of conversation from “build me an event-driven system.”
It names the boundary. It names the deferred concerns. It names the future direction without demanding that the future be implemented today. It tells the agent where not to be clever.
The Prompt Was Not Asking for Code First
"Agentic coding is not longer prompting. It is scoped problem-solving with permission to inspect reality."
The response did not immediately spray out classes, interfaces, and annotations like a caffeinated intern with commit access. It first narrowed the problem further and asked to inspect nearby code that already handled pipelines, queues, and event listeners.
That matters.
As When AI becomes a thinking partner argues, the value is not the typing speed. The value is that the model can search locally, compare patterns, and answer with awareness of the codebase instead of hallucinating a generic conference talk.
Then the answer came back with a sane architectural shape:
- separate domain events from workflow events
- emit business events from service boundaries instead of controllers
- carry tenant, aggregate, and correlation context explicitly
- treat event names as stable contracts
- keep logging and queue mechanics out of the same conceptual bucket as business events
That is not “make me X.” That is collaborative architecture work with bounded autonomy.
The model was not replacing judgment. It was participating in a judgment-heavy conversation and doing the boring reconnaissance fast enough that the human could stay on the decision.
What “Make Me X” Usually Produces
"The fastest path from prompt to code is usually the fastest path to hidden coupling."
Now compare that with the common anti-pattern.
Someone opens a chat window and writes something like: build me an event system for calls, email, UI updates, analytics, and AI tools.
The model has almost no useful boundary conditions. So it does what models do. It rounds the problem down into the most statistically familiar shape.
You get a generic event bus. Maybe a central dispatcher. Maybe a folder called events/common. Maybe a base payload type with fields no one thought through. Logging, workflows, business events, retries, and UI notifications all get stirred into the same pot because the prompt mixed them first. It looks comprehensive for about fifteen minutes.
Then maintenance begins, and the bill arrives.
Spec-Driven Development Is Waterfall With Better Branding
"A 40-page AI spec is still a 40-page fantasy. The only novelty is that the typist no longer complains."
Now the industry has produced a more respectable costume for the same old mistake. It is called spec-driven development.
On paper it sounds modern. You write a detailed specification. The AI reads it obediently. The AI implements the system. Supposedly this gives you rigor, speed, and alignment all at once.
What it usually gives you is big design up front with a fresh coat of GPU paint.
The old waterfall fantasy never really died. It just changed clothes. First came requirements documents thick enough to stun livestock. Then came functional specifications, signed off by six layers of management, lovingly detached from how software behaves once real users touch it. Now the same impulse is back, except instead of handing the document to a resentful developer, you hand it to an infinitely patient machine and call the result progress.
That is not a revolution. It is bureaucracy with autocomplete.
The hidden assumption is the same as it was in every BDUF ritual: if we describe the system in enough detail up front, reality will have the decency to comply. Reality never had that decency when humans wrote the code, and it does not suddenly acquire manners because the implementer is a language model.
Specs still rot on contact with real constraints. Edge cases still appear late. Business rules still collide. Naming still hides misunderstandings. Integration points still behave like drunks at a wedding. The only difference is that the AI will keep marching through the document without rolling its eyes, which some managers seem to mistake for reliability.
What they are really buying is a tireless digital servant for the oldest management dream in software: separate thinking from doing, freeze the thinking early, and make implementation cheap enough that nobody argues back. This dream was stupid with people. It is merely faster with AI.
Good developers do not want a silent slave, human or machine. They want a loop that exposes bad assumptions early. That means testing ideas against code, existing architecture, and running behavior. Spec-driven development, when taken as a grand method, tries to do the opposite. It tries to win the argument before the system has earned the right to agree.
The leadership version of that mistake sounds like this: “If the AI is smart enough, why do we need all this back-and-forth?”
Because the back-and-forth is where the real work lives.
The developer version sounds like this: “Just give me the code.”
That is often just impatience wearing a technical moustache.
If the system boundary is wrong, getting code quickly is not an advantage. It is how you industrialize the wrong decision.
The Human Contribution Is the Course, Not the Keystrokes
"The scarce skill is not writing syntax. It is deciding what problem exists now and which problems must wait."
This is the part leadership keeps getting wrong.
When executives watch a competent agentic session, they often fixate on the visible miracle. The AI read files. The AI proposed an architecture. The AI identified patterns across the codebase. Therefore, developers are optional.
No. The visible miracle is the cheap part.
The valuable part was that a developer knew how to frame the work:
- constrain the architectural surface
- separate present scope from future ambitions
- recognize that UI concerns would contaminate the discussion
- ask for a system that can grow without pretending everything must be solved in one go
- judge whether the answer distinguished domain events from workflow plumbing in a way that would survive contact with a real codebase
Those are not ornamental skills. Those are the work.
A chatbot is not an AI strategy for exactly the same reason a coding demo is not software strategy. The tool can accelerate thought. It does not remove the need for thought. In practice it punishes the absence of thought more quickly. That is also why spec-driven theater appeals so much to management: it promises the emotional comfort of waterfall with the labor cost of a chatbot.
If you are a leader hoping agentic coding will let you fire the people who understand your systems, what you are really buying is a machine that can produce wrong answers at industrial speed whenever the framing is sloppy.
The Developer Contribution Is Better Constraints
"Good developers do not merely ask for output. They shape the search space."
There is a developer-side trap too.
Some developers hear “agentic” and still use the tool like a vending machine with nicer manners. Task in. Code out. Maybe a second prompt if the first result looks a bit cursed.
That is not collaboration. That is slot-machine software.
A better prompt usually does a few blunt things:
- names the exact surface under discussion
- states what is out of scope for now
- explains what future extensibility matters and what can wait
- points at the first real use case instead of an abstract dream system
- asks the agent to inspect existing patterns before recommending a new one
That last point is where a lot of weak prompting falls apart. The model should not be rewarded for inventing a parallel architecture just because it can. It should be pushed to look for the owning abstraction first.
This is also why tests beat instructions. A good prompt sets the initial direction. The repository, tests, and tools keep the session honest after that. Without those feedback loops, “agentic” just becomes a more respectable label for vibe coding.
What Agentic Coding Actually Is
"Agentic coding is a supervised loop: frame, inspect, propose, verify, refine."
Stripped of marketing perfume, agentic coding usually means five things:
- A human frames the problem and the boundaries.
- The model can inspect the local system through files, tools, or tests.
- The model proposes or implements the next step inside that boundary.
- The result gets checked against code, tests, runtime behavior, or other evidence.
- The human either tightens the frame or accepts the result and moves on.
What it does not mean is mystical autonomy. It does not mean the model woke up with product judgment. It does not mean architecture without tradeoffs. It does not mean that “make me X” became a substitute for software development.
As Vibe coding is not software development argues, agentic coding can be software development. But only when the loop contains boundaries, evidence, and a human who knows the difference between a plausible draft and a durable decision.
Continuity Is Designed, Not Hoped For
"If the architecture survives only inside one chat thread, it does not survive."
There is another detail that separates real agentic work from prompt theater: continuity across sessions.
At some point the obvious question came up: how do you ensure that in future sessions the event system will be continued instead of drifting into something else?
The answer was not, “trust the model to remember.” That would be idiotic.
The answer was to anchor the decision in three places, not one. First, the architectural intent was written into repository memory so future sessions start with the same rule set: shared domain events use one contract, feature-local workflow events stay local unless promoted. In that case, the note lived in /memories/repo/nilo-assistant-notes.md.
Second, the stronger protection moved into code. The event shape became explicit in app/src/main/java/neo/app/events/NiloDomainEvent.java, which is where this kind of rule belongs once it stops being a thought and starts being architecture.
Third, the surrounding implementation can then reinforce the same boundary through concrete event classes, listeners, tests, and usage patterns. At that point a future session has to work harder to drift than to continue.
Then the next continuation question made the example better still: before continuing with the feature, consider ArchUnit. The repo already had it. Could it help here?
That is a real agentic move too. Not “please continue implementing.” More like: stop, inspect the existing architectural test surface, and use the narrowest guard the system already understands.
The answer did exactly that. It checked the existing ArchUnit tests, found the repo already enforced package boundaries in that style, and added one more architecture test instead of inventing a parallel governance religion.
The new guard did two very plain and very useful things. First, anything implementing NiloDomainEvent had to be a Java record, which blocks the quiet drift back toward mutable, ad-hoc event classes. Second, only the designated contact-activity projection service was allowed to depend on the contact-activity repository directly, which means future feature code cannot casually bypass the event flow and write into the activity store from wherever it likes.
That is the difference between continuity theater and continuity engineering. Memory says, “please keep doing it this way.” Code says, “this is the shape.” ArchUnit says, “the build fails if you get cute.”
The best part is how unglamorous the follow-up was. The first test runner path did not execute the new architecture test, so the session did not pretend success. It retried with Maven for the exact test class, confirmed the rule actually ran, and only then treated the guard as real. That is what disciplined agentic work looks like: not a glorious spec, but an executable tripwire.
That is the real pattern. Chat history is weak memory. Repository memory is better. Code is better still. Tests are the part that bites.
This is why spec-driven religion misses the point so badly. The problem is not how to write a document detailed enough that an obedient AI can carry out your plan forever. The problem is how to leave behind enough living structure that the next session, human or machine, enters the system through the right door.
The Example Matters Because It Looks Ordinary
There is nothing theatrical about the Spring event example. That is exactly why it is useful.
No shiny UI. No robotic product manager. No fake autonomy theater. Just a developer using an AI tool the way a serious person uses leverage: narrow the question, inspect the local truth, separate categories that should not be mixed, and set the course before code starts multiplying.
That is what agentic coding looks like when it is real.
Not “make me X.”
More like: here is the part of reality we are touching, here is the part we are not touching, here is the shape this decision must preserve, now help me think and build inside that fence.
That workflow should reassure developers and worry lazy managers.
Developers are not being replaced by a chatbot that got better at autocomplete. They are being challenged to work at the level where structure, judgment, and verification matter more than typing.
Managers are not buying a substitute for software developers. They are buying leverage for software developers who can already tell a good boundary from a bad one.
Those are very different stories.
Only one of them is true.
Talk It Through
Tell me what is happening. I listen, ask a few practical questions, and reflect back what I see: where the risk may sit, what may be blocking delivery, and what looks worth checking next. No pitch, no obligation. Confidential and direct.
Talk it through. Practical reflection, no pitch.
Start a Conversation
🎭 This Week's Episodes
Telenovelas show what we can't say in client meetings. The drama is heightened, but the patterns are real.
The First Confrontation
Nathan Cole thinks the Detroit tax defect has finally become visible enough to be handled like an adult problem: evidence on the screen, a bounded ...
The Live Launch
The tournament system goes live in production for the August event. When a sudden network partition splits the EU and US clusters, the team's new a...
Technical Consultancy
Embedded Delivery Partner
Embedded into your team as an active contributor, reducing delivery friction and helping important work move cleanly.
Technical Advisor
Peer-style technical assessments before far-reaching decisions; reduce architectural and product risk early.
Product & Delivery
Ship working software to real users earlier. Measure impact and adapt based on evidence rather than assumption.
Custom Software Development
High quality, maintainable software. Short-term augmentation that leaves lasting capability in your own team.
Recent Articles
- Agentic Coding Is Not 'Make Me X' (20.07.2026)
- AI Agents Make You a Software Company (16.07.2026)
- You Never Needed a Fad to Invest in Your People (11.07.2026)
- Agentic Coding Needs an Air Traffic Control Shift Model (07.07.2026)
- What Governance Actually Means (03.07.2026)