Software has a
drift problem.
Agents made it worse.

I don’t need to tell you how smart AI models have become, or how agentic tools are ushering in a paradigm shift in the way that we write code. The distance between intention and implementation has collapsed. A developer today can produce in a weekend what previously took a month, and software has never been more approachable.

And yet the software those developers are producing is, in an important sense, less coherent than before. Not slower. Not buggier necessarily. Less coherent. The gap between what a system is supposed to do and what it actually does is wider, less visible, and growing faster than ever.

We gave agents tasks. We forgot to give them a model of the system.

01The problem nobody is naming

Ask any developer who has shipped with agents for six months: what is the hardest part? They won’t say speed. They won’t say code quality. They’ll say something like “keeping it coherent” or “knowing what the agents actually changed” or “trusting that the system still does what I think it does.”

This is drift. And it is the defining failure mode of agentic development.

Drift is the accumulating gap between the system you declared you were building and the system that actually exists in production.

Drift isn’t new. It predates agents. Every engineering team has experienced the slow erosion of intent — features built on misunderstood foundations, decisions relitigated because nobody recorded why the first one was made, new capabilities that silently conflict with old ones. The codebase stops being a reflection of your intentions and becomes an archaeological site. You excavate it to understand it.

Agents don’t create drift. They accelerate it. Because agents execute fast, in parallel, across sessions that share no memory of each other. Every session starts cold. Every agent reconstructs its understanding of the system from whatever context it can find — which is usually incomplete, sometimes wrong, and never the whole picture.

The result is a system that changes faster than anyone can track, in directions that compound away from the original intent.

02Why task-oriented tools have a ceiling

Every major agent tool in this space is fundamentally task-oriented. They answer the question: what should the agent do?

Write this function. Fix this bug. Implement this feature. The task is the unit. The agent executes the task. You review the output. Repeat.

This model works. For a while. The ceiling appears when you ask a different question: does the system still behave as intended, across all the tasks that have been executed against it? Task-oriented tools have no answer. They were never designed to have one. The task is complete or it isn’t. What the system has become after a thousand tasks is outside the model entirely.

This is the fundamental limitation. Not speed. Not intelligence. Not tool access. The missing primitive is a persistent, measurable model of what the system is supposed to be — something that exists independently of any single task, that agents can orient themselves against, and that the system actively maintains over time.

03Declarative infrastructure won everywhere else

The history of infrastructure is a history of declarative systems replacing imperative ones.

We stopped writing bash scripts that imperatively configured servers and started writing Terraform that declared the state we wanted. We stopped manually deploying containers and started writing Kubernetes manifests that declared the desired topology. We stopped writing SQL migrations by hand and started using schema declaration tools that computed the delta automatically.

In every case, the shift was the same: from here are the steps to get there to here is where we want to be. The system takes responsibility for closing the gap.

Product development never made this shift. We still manage work as a sequence of tasks — issues, tickets, stories, PRs. We describe the steps. We execute them. We hope the accumulated result is coherent with what we originally intended. We mostly find out it isn’t during incidents, during onboarding, during the conversation where someone asks “why does it work this way” and nobody can remember.

The declarative moment for product development is now. Not because the idea is new — it isn’t. Because agents finally make it tractable. A declared system state is only useful if something can continuously verify the gap between declared and actual. Agents can do that. At every commit. After every session. Automatically.

04What the model looks like

A feature is not a task. A feature is a declaration of desired system state. It describes what the system should do, how it should behave, and what the acceptance criteria are — not as a one-time specification that gets abandoned post-implementation, but as a living contract that the system is always being measured against.

Tests are not just validation. Tests are sensors. They measure the gap between declared state and actual state in real time. When a test fails, it isn’t just a broken build — it’s a specific, measurable divergence from a declared feature. The system knows exactly what drifted and by how much.

Documentation is not a deliverable. Documentation is a continuous reflection of runtime behavior. Not written once by a developer who is already thinking about the next thing. Updated automatically after every session, diffed against the declaration, surfaced as a delta that requires a decision: is this divergence a bug or an evolution of intent?

Agents don’t receive tasks. Agents receive a declared state and a measured gap. Their job is to close it. The system knows when they’ve succeeded — not because a human reviewed the PR, but because the sensors say so.

05The compounding advantage

Software built on a declarative model has a property that task-oriented software doesn’t: it gets more coherent over time, not less.

Every session closes drift. Every post-session hook runs the sensors and updates the documentation. Every agent works against a complete model of what the system is supposed to be, not a cold context window and a task description. The institutional knowledge that normally lives in senior engineers’ heads — why this decision was made, what constraint this feature operates under, what the system is ultimately trying to be — is encoded in the model and actively maintained.

The result isn’t just faster development. It’s development that doesn’t compound technical debt the way we’ve accepted as inevitable. A system that new engineers — and new agents — can onboard into in hours rather than weeks. An audit trail that answers not just what changed but why, what it was supposed to do, and whether it’s doing it.

The promise of declarative product development. Not 10x productivity. Something more important: software that remains knowable as it grows.