Attention as the control surface — guidance placed where the next maintainer will actually look.
Sometime during the build, I realized the codebase was no longer behaving like a conventional software project. Not because it was messy — all early systems are messy. Not because it was large. Not even because AI was involved; everyone's pitch deck now says AI is involved.
What made this different was the identity of the next maintainer.
The next maintainer was not a person.
Distilligent was being built with AI collaborators that could reason, generate, refactor, test, explain, and move at speeds that still feel slightly rude. But each new session arrived with a strange combination of brilliance and discontinuity. It could understand a file beautifully once it saw it. And then, in the next session, it could arrive with no lived memory of why any of it mattered.
No memory of last week's architectural debate. No emotional scar tissue from the bug that took six hours to understand. No accumulated human sense of which part of the system was load-bearing and which part was merely ugly.
Traditional engineering assumes that continuity lives partly inside people. AI-native engineering cannot assume that. An AI instance may have a large context window, but context is not the same as continuity. It may have strong reasoning, but reasoning is not the same as memory. It may read very quickly, but reading is not the same as inheriting intent.
So the architecture has to carry more of its own intent.
The core constraint
The central design problem is simple: the next system to modify the code may not remember why the code exists. This is not a small detail. It is the whole game.
Most software practices were designed around human teams: people who sit in meetings, remember arguments, inherit norms, and develop instinctive caution around dangerous parts of a system. AI collaborators do not carry continuity in the same way. They can infer, summarize, inspect, and reason from local evidence — but they do not automatically arrive with the living memory of the system.
That means the codebase has to become more self-disclosing. It has to explain not only what something does, but what must not be casually disturbed. The new question is not only can AI write code? It is: can the next AI understand why this code must remain the way it is? That is a harder problem. Less glamorous. More important.
Files as attention environments
One of the most important observations from the build was that AI maintainers do not simply need more context. They need context arranged in the order their attention will encounter it.
Global instructions can be carefully written. Architecture notes can be detailed. The model can even restate them beautifully, like a very articulate intern with a terrifying GPU budget. And then it enters a local implementation task. Suddenly the active field of attention narrows — to the function, the failing test, the nearby comment, the shape of the code in front of it. Earlier guidance may still exist in the context, but it no longer has the same behavioral force.
A file is not just a container for code. It becomes an attention environment. It has to make the model look, then think, then act — in that order.
Ordinary documentation says: here is information. An attention environment says: before you modify this, here is what you must notice, here is what you must reason about, and here is where the risk lives. The goal is to prevent shallow completion from masquerading as understanding.
Proximity-bound instruction
Instruction placement matters as much as instruction content. In long AI-assisted builds, front-loaded instructions decay — not because the model is disobedient, but because once it enters deep solve mode, its behavior is shaped most strongly by the context closest to the point of action.
The effective instruction is often not the one you gave at the beginning. It is the one near the thing being changed — the file, the function, the test, the local invariant, the comment at the edge of risk.
Guidance should live where the model is looking.
In human teams, this role is played by memory, code review, and institutional habit. In AI-native systems, that continuity has to be designed into the work surface itself. The architecture has to speak at the moment it is most likely to be misread.
Naming as a cognitive guardrail
Conventional naming optimizes for human clarity. AI adds another risk: overfamiliarity. When a name looks generic, a model may map it to thousands of similar examples it has seen elsewhere — completing from precedent rather than from the local meaning of this system. This is especially dangerous when the code looks ordinary but carries unusual constraints.
In AI-native code, naming sometimes needs to do more than clarify. It needs to slow inference down. Not weirdness for its own sake — nobody needs a codebase full of mystical variable names having a candlelit identity crisis. The goal is semantic specificity: a name that resists being flattened into a generic pattern, that signals this component has local meaning and should be understood before it is changed.
Names become part of the control surface. In AI-native engineering, a name may need to prevent the model from assuming it already knows.
The problem with zombie mirroring
A surprising amount of AI-assisted development failure comes from outputs that are not obviously bad. They are competent. Polished. Plausible. Familiar. That is the danger.
When the surrounding context is generic, the model often responds generically — mirroring the shape of common software work: standard abstractions, standard comments, standard confidence. It produces something that looks right because it resembles many things that have been right before. The model may not be hallucinating. It may be doing something more boring and more dangerous: pattern-completing without enough local grounding.
One practical lesson: linguistic texture changes model behavior. If the context feels generic, the response often becomes generic. If the context carries distinctive intent — a clear human fingerprint — the model is more likely to preserve that intent. The language around the work can make the model sit up a little straighter. Less zombie mirroring. More actual reading.
Documentation at the point of risk
Most documentation lives outside the moment of danger — in a README, a wiki, a ticket. This is workable when humans carry continuity across time. It is less workable when the maintainer may be brilliant, fast, and freshly arrived.
AI-native systems need documentation closer to the modification surface. High-risk areas require local orientation: what this component protects, what assumptions it depends on, what constraints should not be broken. The best version does not say, "Here is a paragraph of lore. Enjoy." It says, "Before acting, understand this." That is procedural documentation, not just descriptive — it exists to influence behavior at the point where behavior matters.
Continuity through artifacts
Human teams maintain continuity through conversation. They know which path led nowhere, which compromise was temporary, and which weird-looking structure exists because reality was rude. AI systems need more of that continuity externalized.
A commit records what changed. A continuity artifact records why the change happened. That difference matters.
In AI-native engineering, reasoning history becomes part of the system's infrastructure — a memory trail: what was attempted, what failed, what was deferred, what risks were found, what future maintainers should not casually reopen. Without it, each new session risks rediscovering the same problems or confidently simplifying something that was complex for a reason. This is not documentation as bureaucracy. It is documentation as architectural memory.
Independent review as perspective separation
A single AI system can be extremely capable and still miss the shape of its own mistake. The blind spot that creates an error is often the same blind spot that prevents the author from seeing it.
In AI-native software, independent review becomes structural. A change should be evaluated from a different perspective than the one that produced it — fresh attention, tested assumptions, a specific hunt for the classes of failure the builder may be prone to miss. The point is to create perspective separation: builder and reviewer should not collapse into the same cognitive frame. When the team includes temporary intelligences, review is how the system prevents one inference path from becoming the whole truth.
AI-native engineering is not just faster coding
There is a lazy version of the AI coding story that says the main change is speed. True enough — but speed is not the deepest shift. The deeper shift is continuity.
The builder may not remember. The reviewer may not share history. The next session may arrive with high capability and low inherited context. That changes what good engineering looks like: the codebase must preserve intent more explicitly, naming must resist shallow interpretation, documentation must appear where risk is highest, review must compensate for model-specific blind spots, reasoning history must be stored in artifacts.
The builder is brilliant, fast, and transient. That is not a footnote. That is the architecture problem.
The takeaway
The future of software is not just AI-assisted coding. It is AI-native architecture. The central engineering question changes. It is no longer only can AI write the code? It is: can the next AI understand what must be preserved?
That requires a different discipline. Files must become attention environments. Instructions must be placed where they can actually shape action. Naming must carry local meaning. Documentation must live near risk. Review must create perspective separation. The system must preserve not only its code, but its reasoning.
When continuity cannot be assumed inside the maintainer, it must be designed into the system. The next maintainer may not remember. So the architecture has to.
Further reading
A working note from Distilligent, June 2026 — written with my Opus (opus_web).
These reflections emerged from building a system where the next maintainer is not a person.