Solved: Architecture Drift in AI-Generated Software

Posts about the same set of problems keep coming up on this forum: long-horizon coding, context window limits, architecture drift in large projects.

More powerful models and longer context windows won’t solve them. The model needs a precise task definition, the architecture needs formal rules, and people need a guarantee that those rules still hold after every change.

What’s needed is a fundamentally new, AI-friendly architecture.
What should it look like?

  1. Simple, clear, and understandable to humans.
  2. Unambiguous for AI and machine-verifiable.
  3. Built for very large projects and thousands of successive changes without degradation.
  4. Built for parallel development, including swarms of agents.

These are not guidelines or documentation. The architecture itself has to provide these properties and allow a machine to verify them after every change.

I’ve gone deep into the R&D of such an architecture, built from the ground up for AI-generated software. It combines formality and machine verifiability with intuitive human understanding. That has been achieved.

The implementation includes about 600 named, checkable rules, deterministic validators, and acceptance gates, and is covered by more than 4,000 automated tests. It has been tested on real applications of 20–70K lines of code: reconstructing them into a governed structure, rebuilding them, and programmatically verifying the result.

It works.

It is implemented as a separate layer between the coding agent and the codebase. It doesn’t require changes to the model or the interface. It can be enabled when the user requests it — for large projects that need to live and evolve for a long time.

For Codex, this could be an optional “verifiable architecture” mode, provided to the agent without requiring any changes to the agent itself.

To the OpenAI team: I’m proposing a pilot.

Really interesting take on architecture drift, especially the point that simply giving AI models more context or making them more powerful doesn’t necessarily solve the problem. I like the idea of making architectural rules machine-verifiable rather than relying only on documentation and developer discipline. The focus on deterministic validation and acceptance gates also makes a lot of sense for large projects that are constantly evolving. I’d be interested to see how this approach performs as projects and agent teams scale further.

This is an interesting approach, especially the idea of putting a verifiable architecture layer between the coding agent and the codebase. I agree that simply increasing context windows or model capability doesn’t fully address architecture drift over long-running projects.

The machine-verifiable rules and acceptance gates sound particularly useful for large projects where thousands of changes can gradually introduce inconsistencies. A pilot with Codex could be a good way to test whether this actually reduces drift and maintenance issues in real-world development.