AI Writes Code. Humans Write Software.
AI writes code. Humans write software.
That sounds like a slogan until your agents are actually shipping. Then it becomes an operating problem.
The industry has mostly treated this as a context problem. Give the model more files. Keep the specs current. Add memory. Expand the prompt.
Context helps an agent write code.
It does not make the calls that should govern what happens next.
Software is made of decisions: customer commitments, architectural patterns, product bets, performance constraints, trade-offs, exceptions. Code expresses them. Code does not remember why they matter.
As implementation gets cheaper, the leverage moves up. The hard work is negotiating the calls above code: what changes, what holds, and what future agents build from.
And that work has almost no infrastructure.
At Google, 75% of new code is AI-generated and engineer-approved. At Anthropic, Claude Code reportedly writes 70–90% of code across some teams. And yet Stack Overflow’s 2025 survey found more developers actively distrust AI-tool accuracy than trust it.
Different measurements. Same direction.
Code is not the scarce unit anymore. Trusted judgment is.
But the infrastructure is upside down. Code has version control, branching, merging, provenance, collaboration at scale. Intent has documents, tickets, chat threads, dashboards, ADRs, PR comments, and meetings.
Not no artifacts. Too many artifacts.
A sales commitment lives in a customer thread. An architectural pattern lives in a design doc. A performance constraint lives in a review comment. A usage signal lives in analytics. An agent discovery lives in a transcript.
Five artifacts. Five systems. None connected to the service your agent is about to change.
Here is the failure mode.
A coding agent is implementing customer-signal architecture for a relevance launch. The business goal is clear: an enterprise renewal depends on better search, recommendations, and cart recovery. The architectural direction is clear too: customer-facing services should emit canonical signals into a shared customer-signal fabric.
Then the plan meets reality.
Order-level purchase events are too coarse. They tell the system that a customer bought something, but not which item should reshape search ranking, recommendations, replenishment prompts, or recovery flows. Line-item signals are better. They are also more expensive: more writes at checkout, more pressure on the event bus, more care needed around latency.
The agent does not bury this in a PR comment. It pushes back live, in the thread where the work is happening. It says, in effect:
“Order-level purchase events are too coarse for relevance-critical flows. Line-item signals help, but synchronous enrichment would add write pressure to checkout. I need a call before wiring this into the customer-signal fabric.”
The agent surfaced the tension. It did not make the software judgment.
You and the people accountable for the system did.
The call: line-item purchase signals for relevance-critical flows, batched after checkout commit, with one canonical customer-signal fabric across search, recommendations, and cart recovery.
That call should not become another note someone might find later. It should become graph-connected intent.
It should connect to the enterprise renewal goal that made relevance urgent. It should link to the customer-signal pattern, the checkout-latency requirement, and the event-bus batching path. It should change the affected set of services.
The important point is not that the next agent remembered the last one.
It did not.
The graph changed.
A different agent starting on search relevance reads a brief synthesized from that graph: the goal, the pattern, the decision, the constraint, the affected services, and the provenance behind them. Six months later, a new engineer picking up cart recovery sees the same chain.
Reality pushed back on the plan. Humans and agents shaped what should hold. The graph changed what the next agent built from.
That is the difference between context and intent.
Context is what might be relevant.
Intent is what has force.
This requirement governs that implementation. This pattern guides that service. This decision supersedes the old one. This discovery reopens the affected set. This usage signal should pull a stale assumption back into discussion.
Intent is not a bigger prompt. It is a graph of decisions, patterns, requirements, and evidence — connected to code, fresh as code evolves, shaped in real time by humans and agents.
The graph is not a diagram. It is the structure that gives decisions operational force.
And the loop is not one-way.
Humans do not sit at the top issuing commands while agents execute below. Agents bring reality back from the code path. Usage and evidence push from the outside. Humans discuss, respond, shape, and hold the lines that matter. Agents help materialize the consequences.
That negotiation has to happen while the work is live. If the agent disappears into a session and returns hours later with a diff, the richest moment to shape intent is already gone.
Direction without substrate is one-shot. You direct, the agent ships, the next direction starts cold.
The most valuable signal in development is not the plan. It is what your agent learns when the plan meets reality — because that is where intent has to be renegotiated.
Spec-driven development has the right instinct. Specs are how humans tell agents what to build.
But specs as files solve only the first half of the problem. They move intent downward. They do not carry reality back up.
A file in git does not know what it governs. It cannot tell which implementations depend on it. It cannot distinguish a hard customer commitment from a soft team preference. It cannot tell the next agent that a graph changed because reality pushed back.
Building this way requires a substrate where decisions and discoveries reshape what future agents build from: typed, connected to code, and fresh as code evolves.
Not all relationships carry the same force. A customer commitment that is a condition of signing governs differently than a pattern your team prefers. A performance constraint constrains differently than a design note. A usage signal should not carry the same weight as a signed enterprise requirement.
Without structure that distinguishes them, agents cannot reason about which decisions are hard walls, which are guidance, and which should be reopened.
That is why context is not intent.
If you run agents on a codebase that matters, pull the last 30 PRs your agents shipped. For each one, ask:
What decision did this PR implicitly make?
What constraint did it bend?
What evidence or implementation reality pushed on the plan?
Where is that decision now?
What will the next agent see before it builds?
If the answer is only the diff, you are not directing software. You are approving code.
The cost of a wrong decision scales with agent speed.
When an agent ships a feature in twenty minutes, a wrong call does not waste developer time. It ships before anyone notices. When five agents run in parallel, wrong decisions ship five different ways before anyone reads all of them.
The industry is measuring how fast agents write. The more important question is how fast teams can update the calls that guide the next build.
Speed is how fast you go. Velocity is how fast you go in a direction that compounds — where each decision and discovery makes the next one better-informed.
The industry has speed. What’s missing is the infrastructure to turn it into velocity.
This is what we’re building in Igni: the intent layer for software teams.
Not better context. Infrastructure for intent.
AI writes code. Humans write software.
Git for code. Igni for intent.