I don’t write code anymore or read it, either.
I still design and build software every day. I decide what I want, work with agents to get there, and verify that what they’ve built works. When finished, we commit the implementation to Git and treat it as the authoritative record of the system.
The code I neither wrote nor read becomes the thing we’re expected to understand, maintain, and preserve.
For decades, we’ve been moving implementation decisions beneath representations that are easier for people to reason about. We stopped reading the assembly produced by compilers. We write SQL and let databases choose execution plans. We describe desired infrastructure to Kubernetes and let controllers maintain it.
In each case, we preserve a higher-level representation while allowing the implementation beneath it to change.
Agents have taken us another step along this path, except we’ve neglected something important. We can now produce entire implementations without writing or reading them, but haven’t agreed on what should become the durable record above them.
A team should be able to change how its software works without accidentally changing what its software means.
The Questions We Don’t Ask
A year ago, I wrote Beyond Code-Centric, arguing that agents were moving the bottleneck in software development from implementation toward intent. At SpecStory, we began treating specifications (and the conversations required to produce them) as first-class artifacts alongside code and tests.
It has helped but specifications generally capture what we wanted before building. The working system contains everything we learned afterward, much of which never makes it back into the specification despite our trying.
Recently, we discovered that some coding sessions synchronized to SpecStory Cloud were failing because our Cloudflare worker’s TCP write path was rejecting writes above 64 KB. We fixed the problem by splitting writes into smaller chunks.
That workaround is now embodied in our implementation. It’s necessary for the software to work on its current platform, but it has nothing to do with what our session ingestion capability is supposed to do.
Another time, storage firewall rules began rejecting certain payloads based on their contents. Compressing the payloads appeared to be a reasonable fix, except two downstream services expected the original payload. I happened to know that from having built those services.
An agent can inspect our repository and reconstruct much of how the system works. But knowing what questions to ask is a different problem.
The questions we don’t think to ask are the ones that bite us.
The implementation contains behavior we explicitly requested, behavior we discovered and decided to keep, accidents nobody intended, and workarounds imposed by our infrastructure.
The code records what the system does. It doesn’t reliably tell us which of those behaviors must survive its replacement.
As agents get better at producing software, this distinction matters moreso. Otherwise, we’re asking them to preserve everything because we haven’t established what is worth keeping.
A Lesson From Armories
Two hundred years ago, gunsmiths made parts by hand, filing and adjusting individual components until they fit together. A working gun was the product of considerable skill, but replacing a broken part often required fitting a new one to that particular assembly.
During the nineteenth century, armories developed the machinery, standardized patterns, and precision gauges that made interchangeable parts practical.
A gauge established whether a part met an agreed standard. A worker could produce a replacement without having the original part or knowing every decision its maker had taken.
The knowledge needed to reproduce a fitting part no longer lived exclusively in the part itself or the craftsman’s head. It was preserved in standards that could be checked and improved.
Agents are extraordinarily capable craftsmen. They inspect existing implementations, reproduce their behavior, accommodate their dependencies, and produce working replacements.
But we’re still fitting new parts against old ones. Every accidental decision risks becoming a permanent requirement simply because it exists in the code.
We need the equivalent of the gauge.
“What is this, fundamentally? What is its nature and substance, its reason for being?” VIII. 11
A Contract Worth Keeping
Bertrand Meyer’s Design by Contract established the importance of defining software through explicit obligations and invariants. More recently, Chad Fowler’s Regenerative Software has explored how durable contracts, evaluations, and boundaries might allow implementations to be continuously replaced.
The principles and thinking is not new. What’s changed is the cost of implementation. When producing another version of a component becomes as cheap as it is today, knowing what the replacement must preserve becomes the value.
I’ve been exploring a way to give those obligations a durable identity, which I’ve been calling a Named Shape.
A Named Shape consists of a name people can reason about, obligations machines can check, and explicit relationships to the other components in the system.
Consider the worker responsible for accepting synchronized coding sessions from the prior example. Call it Session Ingestion.
Its obligations might include:
An acknowledged session cannot be silently lost.
Retrying a request cannot create duplicate sessions.
One user’s data cannot cross another workspace’s authorization boundary.
99% of accepted sessions must become readable within ten seconds.
Downstream consumers must receive the data they depend on.
Some obligations can be checked through tests before deployment. Others require continuous monitoring. Anything important that we cannot yet verify must remain explicitly unresolved.
The Cloudflare write limit is a constraint of the current implementation, not a permanent obligation of Session Ingestion. A replacement running on AWS shouldn’t inherit it.
An API tells another component how to communicate with Session Ingestion. A Named Shape defines the obligations a replacement must satisfy to count as Session Ingestion.
And since components depend on one another, their shapes form a graph. Changing the payload format exposes which consumers need to be checked. Introducing a new dependency becomes a visible architectural change rather than something buried in generated code.
None of this requires a complete description of the implementation. An agent can already produce thousands of lines of explanation for a thousand lines of code. That isn’t useful abstraction.
A Named Shape must be shorter than what it governs, useful for people to think with, and backed by checks.
The important distinction is what we make authoritative.
Today, tests, contracts, and architecture documents generally support the implementation. When they disagree, the code often wins.
With sufficiently trusted Named Shapes, the obligations become the governing record. The implementation must satisfy them. Changing an obligation requires an explicit decision.
Suppose an agent replaces Session Ingestion on AWS, but the new implementation cannot meet its existing latency target without significantly increasing cost.
The change requiring human judgment might be:
Session Ingestion
99% of sessions readable within 10 seconds.
99% of sessions readable within 20 seconds.
Anyone on the team can understand that change. It modifies what the system promises, regardless of how many lines of code were required to implement it.
The agent can change the implementation without approval of every internal decision, provided the existing obligations still hold. Changes to those obligations become explicit and reviewable.
The Moment After Yes
The obvious difficulty is knowing whether we’ve captured everything that matters.
We haven’t. A component can pass every check and still be wrong. Its consumers may depend on behavior nobody thought to specify. A dependency graph can omit relationships we haven’t discovered.
No finite collection of tests establishes complete correctness.
But there’s a moment in software development today when we have particularly useful evidence of what matters. It’s immediately after someone accepts a working result and says, “Yes, that’s what I meant.”
The accepted implementation contains our best available example of the intended behavior, including things discovered while building that never appeared in the original specification.
We can use it to establish an initial shape, then ask an agent to produce an independent implementation against that shape.
Compare the results.
If a difference breaks behavior we care about, the shape is missing an obligation. We add it and define how to check it. If the difference is harmless, the old code may contain something we never needed to preserve. If it exists only because of the platform, we keep that constraint attached to the platform.
We refine the shape and try again.
Production incidents, new requirements, and alternative implementations continue the process. The original code provides evidence for the shape, but doesn’t permanently define it.
Trust accumulates through repeated verification. A small ingestion worker may earn that trust long before an entire billing system does. Some code will remain valuable for debugging, provenance, or reproducibility, and some implementations won’t be worth replacing.
The point isn’t to regenerate everything. It’s to make replacement possible without having to rediscover every requirement from the existing code.
What Survives
As agents produce more software, the amount of code grows faster than our ability or desire to read and understand it.
Better agents will help us interrogate these systems more efficiently but the ability to retrieve an answer is different from knowing which questions matter. Teams still need a shared understanding of what their software promises and which decisions they’re responsible for preserving.
That’s what I’ve been pondering that Named Shapes may provide.
A thousand lines of changed code might preserve every guarantee a component makes. A single changed clause might weaken a guarantee that half the system depends on. The second deserves more attention, even though our development practices still direct so much of it toward the first.
We already have many of the necessary tools: contracts, tests, evaluations, monitors, and dependency graphs. What’s missing is a durable representation that brings them together and gives their verified obligations authority over the implementations they govern.
A team should be able to change how its software works without accidentally changing what its software mean. As agents have drastically reduced the cost of production, preserving the knowledge of what that software must do is becoming the harder problem.