Your agent has architecture. It still needs a reason.
Consider a pull request that looks exemplary. Clean diff, right file, approved in four minutes. The agent's retry logic lands in checkout/payment, exactly where the architecture model says it belongs. Every seam holds. You've reviewed a hundred PRs like it. This is the one that should worry you.
Because nobody asked for configurable retry counts on the payment step. Users weren't tuning retries. They were leaving, bouncing off a screen that sat silent for four seconds and looked dead. The agent built a knob for a problem that didn't exist, placed it perfectly, tested it thoroughly. You'd have approved it too. There was nothing to catch.
That is unjustified code: perfectly placed, completely wrong. The structure is immaculate; the failure is that the thing should never have existed, and nothing in your stack is built to catch that.
Structure is not judgment
Agents can read your system now. Architecture-as-code, exposed over MCP, lets an agent query where a module sits, what it owns, what it must not touch. LikeC4 is a very good How feed: your architecture, legible, queryable, and live. It still cannot answer the missing question.
How without Why produces confident, well-structured mistakes, and those are the expensive kind. A broken build fails loudly and gets fixed in an hour. Unjustified code passes every review except the one that matters, ships, and quietly steers the product toward something nobody wanted. Nothing sounds an alarm.
The agent knew where the code goes. It had no way to know whether the code should exist.
Four feeds an agent wants
- Where. Architecture, ownership, boundaries.
- What must hold. Contracts, tests, behavioral specs.
- When. Task state, queue, priority.
- Why. Evidence-backed intent.
Three are already being wired in. Repos expose structure. Test suites assert behavior. Issue trackers carry state. Why is the one still missing, and it decides whether running the other three was worth it.
Two feeds, one agent
The difference appears in a concrete thought experiment. Give a coding agent two MCP feeds. The first is the architecture feed: where the code goes, what must not break. The second is the Pathmode feed: why this work exists, the evidence behind it, the outcome it's chasing, what "done" actually means.
Give it the task "improve the checkout payment step" and ask it to plan. These are illustrative plans, not the output of a recorded run.
An architecture-only plan could reasonably read:
Add retry state to
PaymentStep. Update timeout handling. Keep changes isolated tocheckout/payment.
It's a good plan. The boundaries are respected. The blast radius is contained. An architect could sign off. But it is untethered from any reason. The agent improvises a plausible improvement because nothing says which improvement matters. It invents a rationale (retries fail sometimes, probably) and builds against that. Nothing in its inputs can correct it. This is unjustified code one planning step before it gets written.
With the Why feed, the same agent still knows the boundary and what must not break. It also reads the abandonment data, the support tickets, and the outcome the team is chasing. Its plan could instead read:
Evidence shows users abandon checkout because silent waits over 3s feel broken. Add a visible processing state by 1s. Recover from timeouts at 3s. Allow retry without risking a double charge. Do not redesign the payment provider flow.
The evidence changes the plan. "Retry state" becomes "retry without a double charge" because the problem is abandonment, not retries. "Update timeout handling" becomes "visible processing state by 1s, recovery at 3s": specific thresholds from the hypothetical evidence, not invented implementation detail. The architecture feed could not have produced do not redesign the payment provider flow. That is a scope boundary drawn by intent, not module ownership.
The first plan was scoped by a folder. The second was scoped by a reason.
The Why feed does not tell the agent which file to open. The architecture feed already did that. It tells the agent which of the infinite valid changes to that file is worth making. The two feeds don't overlap. They intersect, and the intersection is where good code gets written.
The Why feed does not make the agent smarter. It makes the agent accountable to something.
Architecture tells the agent where the code goes. Intent tells it whether the code should exist.
Now everyone is the agent
The risk scales beyond one developer. When anyone with an idea can ask an agent to open a pull request, execution stops being the bottleneck. An idea from the morning can become code by the afternoon.
This is genuinely good, and it is the unjustified-code problem with the safety catch removed. The lone agent at least had an architecture feed aiming it at the right file. The marketer shipping a fix has even less of the Why than the agent did: the symptom they saw this morning, and not the abandonment data, not the outcome the team is chasing, not the reason the last person decided not to touch the payment flow.
The reasoning still disappears. The argument gets settled in the Slack thread where it started: someone pulls the metric, someone agrees, the PR opens, an engineer approves it because the diff is clean. The change ships. By Tuesday the reasoning that justified it has scrolled off, buried in a thread no future agent and no next teammate will read. The product moved; the only record of why is a conversation nobody can find.
At team scale, the distinctive risk isn't simply more bugs. Bugs at least have tests, crashes, and review comments. Unjustified code can be clean, correct, and still wrong for the product. The volume of code goes up. The volume of recoverable judgment stays flat.
A codebase observatory can make a fifth feed visible: How much. Production and test lines over time give a careful account of how much a repository changed. That is useful. The chart still cannot say which changes trace back to a decision, which shipped without a reason anyone recorded, or whether any intended user outcome moved. Git already contains the volume data, so this is the feed everyone can build first. It is also silent on whether the growth was worth having.
Build mode without a durable record of judgment is just a faster way to build the wrong thing.
Why not put it in the prompt?
Fold the Why into the prompt, or model it as another node in the architecture graph. One feed, fewer moving parts. That fails for three reasons.
Different clock. Architecture changes when you restructure the system. Intent changes when you learn something: a support ticket, a churned account, a metric that moved. Couple them into one model and every time you learn something you're editing the architecture, and every refactor drags your reasons along behind it. One clock ends up lying.
Different owner. Architects own structure. The people holding the evidence own why. One model with two authors is a standing merge conflict, and the why always loses, because it's the softer thing to overwrite. A prompt is worse: it has no owner at all, just whoever typed last.
Different grounding. Architecture is derived from the system; you can read it off the code. Intent is derived from evidence: tickets, interviews, behavior, the things that justify a decision. Force intent into a structural DSL and you strip out the evidence underneath. What's left is an assertion with no backing. Intent is judgment under evidence, not a contract you compile. Drop the evidence and it stops being judgment and becomes opinion with good formatting.
The agent is the consumer. It is not the home.
Pathmode isn't where intent goes to fossilize into another spec the agent ignores. It's the Why feed sitting next to your How feeds, authored from evidence, served over MCP, read at plan time alongside the map and the guardrails. The agent reads what the system is and what you're trying to do, then writes code that answers both. Structure keeps it from breaking things. Intent keeps it from building the wrong thing well.
You already have feeds for where the code goes. Point your agent at the one for why it should exist. Hand it the same checkout task and read its plan. The difference shows up before a single line is written, which is the only place unjustified code was ever going to be caught.