There is a shift happening in what makes a developer valuable, and most conversations about it focus on the wrong half of the equation.
The argument goes something like this. An AI agent can turn a system design you already hold in your head into working software faster than you could ever type it yourself. Which means the ceiling on what you ship is no longer how fast you write code. It is how well you decide what to build and how to shape it. Where state should live. Where component boundaries fall. What consequences show up months later when the thing you built needs to scale.
This is true, and it is a genuinely useful reframing of where developer value is heading. The developers pulling ahead are the ones who lead that design instead of handing it off entirely, setting the shape and then letting the agent move fast inside it.
What gets left unsaid in this framing is the actual mechanism connecting the two halves. Having the judgment is one thing. The agent actually working inside the shape you have in mind is a completely different thing, and the gap between them does not close automatically just because your judgment is good.
Judgment that stays in your head does nothing for the agent
You can have excellent instincts about how a React project should be structured. Years of pattern recognition about when state should be local versus shared, when a component is doing too much, what naming makes a codebase legible six months later, how a feature boundary should be drawn so it does not become a maintenance problem down the line.
None of that judgment transfers to an agent by existing in your head. The agent does not have access to your accumulated pattern recognition. It has access to whatever you actually communicate, in whatever form you communicate it, before or during the session where it generates something.
If your judgment about component boundaries only exists as an intuition you apply when you personally write code, an agent working inside your codebase has no way to inherit that intuition. It will make its own decision about where the boundary falls, based on general patterns from its training and whatever it can infer from the immediate context, which is not the same as your specific, hard-won judgment about this specific project.
The shape you are supposed to be setting, according to the argument, only actually gets set if it exists somewhere the agent can read it. Otherwise you have good judgment and an agent that is working inside a shape you never actually communicated, just one it guessed at.
What "setting the shape" concretely requires
Setting the shape is not a single act. It sounds like one thing when described abstractly, but it decomposes into a specific set of decisions that have to be made explicit, not just held as intuition.
It means deciding, and writing down, where state lives for different categories of data. Not vaguely knowing that some state should be local and some should be shared, but specifying the actual threshold. State used by exactly one component stays in that component. State used by two or more components within a feature moves to a dedicated hook. State needed across independent features only becomes global, and only when genuinely necessary.
It means deciding, and writing down, what a component boundary actually looks like in this project. Not a general sense of when something feels too big, but a specific line, whether that is a line count, a responsibility count, or a rule about mixing presentation and logic within the same file.
It means deciding, and writing down, what the domain vocabulary is. The specific words this project uses for its specific concepts, so that a Customer is always a Customer and never sometimes a User, sometimes a Client, depending on which session happened to generate that particular file.
Each of these is a piece of judgment that experienced developers already have, usually without having consciously articulated it as a rule. The judgment exists. What does not exist, in most cases, is the explicit written version of that judgment that an agent could actually follow.
Why this matters more now than it did before agents did most of the typing
Before agents were generating large portions of a codebase, a developer's judgment applied itself automatically, every time, because the same person who held the judgment was also the one physically writing every line. There was no gap between having the instinct and the instinct showing up in the code, because the instinct and the code came from the same source at the same moment.
Once an agent is doing a significant share of the actual generation, that automatic application breaks. The judgment and the generation are now two separate things, connected only by whatever got communicated between them. If nothing explicit got communicated, the agent generates based on its own general patterns, and your specific judgment, however good it is, sits unused in your head while the agent makes a different decision than you would have made.
This is the part of the shift that the shape-setting argument gestures at but does not fully spell out. It is not enough to have good judgment about system design in an agent-driven workflow. The judgment has to survive the transition from your head into a form the agent can actually use, every single session, not just the sessions where you happen to remember to mention it in the prompt.
The developers actually pulling ahead are doing something specific
Watch closely at what the developers who are genuinely getting more out of agents are actually doing, beyond the general description of setting the shape and letting the agent work inside it, and a specific pattern emerges. They are not relying on remembering to communicate their judgment fresh in every prompt. They are converting that judgment into a standing set of constraints that exists independently of any individual session, so that setting the shape happens once, comprehensively, rather than being re-attempted piecemeal every time a new prompt gets written.
This looks different from prompt engineering, even though the two get conflated. A well crafted prompt communicates intent for the current task. A comprehensive rule system communicates the shape for every task, regardless of how that specific prompt happens to be worded. The developers pulling ahead are not writing increasingly clever prompts. They are doing the harder, less glamorous work of articulating their judgment as an explicit, standing system once, and then letting every subsequent prompt operate inside that already-defined shape.
Here is roughly what that articulation actually looks like when you sit down and do it, rather than just intending to do it eventually:
Shape-defining rules that turn judgment into something an agent can follow:
1. State scope is decided by usage, not convenience. Local to one component by default. A dedicated hook when two or more components in the same feature need it. Global only when at least two independent features genuinely require the same data.
2. A component boundary is crossed when a single file starts handling more than one of the following simultaneously: rendering, data fetching, or business logic. When that happens, split before continuing, do not defer the split to a later cleanup pass.
3. The domain vocabulary for this project is fixed and documented. Deviations are not acceptable even when a different word seems reasonable in isolation.
4. Architectural decisions made for this project apply going forward from the date they were made, even in situations where the existing codebase still shows the old pattern in places that have not yet been touched.
None of this is complicated once written down. What makes it valuable is that it existed as judgment before it existed as a rule, and writing it down is what actually lets an agent operate inside the shape rather than guessing at one.
The risk of good judgment that never gets externalized
There is a specific failure mode worth naming directly, because it is easy to fall into precisely because your judgment is genuinely good. If your instincts about architecture are strong, the code an agent produces without explicit rules will often look reasonable to you on a quick glance, because you are mentally filling in the gaps the agent left, correcting small things automatically without fully registering that you are doing correction work at all.
This creates a false sense that the shape is being set successfully, when what is actually happening is that your judgment is doing constant, invisible repair work on an agent that never actually received the shape in explicit form. The system appears to be working because your judgment is compensating for its absence in the agent's process, not because the agent genuinely internalized anything.
The tell is usually correction fatigue that never quite goes away, even after months of working with the same agent on the same project. If your judgment were actually transferred, the corrections needed for a given category of decision would decrease over time as the agent's output increasingly matched the shape. If corrections stay roughly constant no matter how long you have been working together, the judgment was never actually externalized. It was just being applied silently, session after session, by you.
The prompt does not matter. The rules do.
Judgment about how software should be shaped is genuinely the skill that matters most right now, and that argument is correct as far as it goes. But judgment that only exists in your head does not shape anything an agent generates. It shapes only the code you personally write, which is an increasingly small share of the total output as agents take on more of the actual generation.
Setting the shape is not something you do once by having good instincts. It is something you do by converting those instincts into an explicit, standing system that exists independently of any single prompt, and giving the agent access to that system before it generates anything at all.
Your judgment is the asset. Rules are how that asset actually reaches the code.
Want to find where your architectural judgment has never actually been written down for your AI to follow?
I built a free 24 point checklist that helps you identify exactly that. The structural decisions where your instincts are strong but your AI has never received them in a form it can actually use.
Top comments (0)