Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture

In 2023, a Microsoft Research study reported that developers using GitHub Copilot completed a coding task 55.8 percent faster than the control group. The number traveled through vendor decks and engineering hiring plans and became the working definition of what AI does to software development. Two years later, METR ran a randomized controlled trial on experienced developers working in their own large codebases.

The expected speedup, forecast by economists at 39 percent and machine learning experts at 38 percent, was the opposite of what the trial found. Developers using AI tools took 19 percent longer. After the study, the same developers estimated AI had made them 20 percent faster. The perception gap was 39 points wide.

The gap has a recognizable shape. AI makes the first 80 percent of a feature feel dramatically faster: scaffolding appears, code compiles, tests get generated, and the demo works.

The last 20 percent is where the work returns. Integration with the existing system. Behavioral edge cases. The clunky test setup nobody remembers writing. The performance constraint nobody documented. The institutional memory of why the previous version made the choices it did. The first 80 percent is where AI is genuinely fast. The last 20 percent is where architecture lives, and the fastest part of the workflow now hides the slowest and most consequential part until it is too late to choose otherwise.

The point is not that AI-assisted development should be slower. Agents generating code at speed is a real productivity win and not the problem worth solving. The problem worth solving is the context the organization loses around that code: the intent, the behavior, the architectural reasoning that engineering systems were never asked to keep up with at this speed.

That gap is the subject of this article. AI-assisted development is doing something stranger than the productivity debate suggests. It is decoupling two things that used to happen together: writing code, and building an understanding of why the code looks the way it does. Pre-AI, a developer produced both at once. The act of writing forced the learning. AI removes that forcing function. Code now ships at machine speed. The understanding does not ship with it.

The Context Gap at Two Altitudes

The cost shows up at two altitudes. At the team altitude, Amazon's March 2026 storefront outages were traced to AI-assisted changes merged without proper review, followed by a code safety reset and a new senior-engineer approval requirement for all AI-assisted code. The approval gate addresses the procedural symptom. The structural problem, that the changes looked reviewable in the first place because nobody held the reasoning behind them, sits one layer underneath, untouched. At the leadership altitude, Google's 2025 DORA report found that AI adoption continues to correlate with increased software delivery instability even as throughput improves, exposing weaknesses in testing, version control, and feedback loops that the AI-accelerated pace of change has outgrown. CTOs reading these dashboards can see that something has shifted. They cannot tell their boards what changed at the architecture level.

Both failures are invisible until the moment they are not. A production incident exposes them. A key departure exposes them. A re-platforming decision exposes them. And in each case, the question the organization cannot answer is the same. Why does this work the way it does? Not the team that shipped it. Not the system itself.

Once the bottleneck moves off code production, the harder problem comes into view: verifying, quickly and continuously, that what is being written or generated still does what the team intends, still respects the agreed architecture, and still aligns with the executable contract the business depends on. In an AI-assisted codebase, that problem has a second face. The team and the agents it directs need to comprehend the system it is changing, not just verify it.

Evolutionary architecture has spent two decades building the toolkit for systems that must change continuously without losing coherence: fitness functions verifying architectural conformance, bounded contexts guiding evolution through explicit ownership and contracts, and architectural characteristics enforced as living guardrails rather than treated as one-time decisions. The toolkit works. What it did not anticipate is a contributor that produces code at machine speed without holding a mental model of why.

Comprehension is the dimension of evolutionary architecture that AI-assisted development has made newly visible. It joins established architectural characteristics, including availability, elasticity, resilience, and security, that teams must design for and protect. Phillip Mortimer's QCon London 2026 talk frames the underlying condition starkly: software complexity is scaling beyond the limits of human comprehension. These techniques are not contradicted by AI. They are amplified by it. When code generation becomes a commodity, the design phase becomes mandatory, and the differentiation shifts to understanding the domain and designing the guardrails that hold the system's reasoning in place across its lifecycle.

The rest of this article argues that the operational mechanics for closing the context gap already exist in the evolutionary architecture tradition. Spec-anchored specification-driven development, test-driven development, and architectural fitness functions, run together as a single verification system, produce more than verification. They produce a queryable context store: feed-forward guides that shape what is built, and feedback sensors that evaluate what was built, persisted alongside the code and versioned with it. The context store serves human reviewers, AI agents, and future maintainers equally. That is what makes comprehension a lifecycle property of evolutionary architecture rather than a pre-merge concern.

The Framework: Three Verification Disciplines as One System

What organizations actually need is a context store: a deterministic, versioned record of intent, behavior, and architectural conformance that humans and AI agents both query as the system changes. The source of truth is the artifacts themselves in the repository, not an LLM's memory of them. Teams decide per system boundary how much LLM probabilistic search they integrate against that store and where deterministic queries are required. The framework assumes a custom development surface, an executable spec, a CI harness, and a versioned repository; no-code platforms and packaged solutions sit outside its scope, and small teams on single services can run a subset of the disciplines without the full context store until growth makes the system bigger than one person can hold in their head.

The three disciplines familiar to architects, spec-anchored SDD, TDD, and architectural fitness functions, are what feed and keep that context store current. None of the three is new. What is new is the integration: three verification loops on one cadence, three social practices that keep them alive, and one context store as the shared output. Figure 1 maps this integration: the three disciplines as rows, the value-stream stages as columns, the social practices as a band above, the deterministic context store as the band underneath that humans and AI agents both query.

[Click here to expand image above to full-size]

Figure 1: The three verification disciplines (spec-anchored SDD, TDD, and architectural fitness functions) run together as one system across seven stages of the delivery value stream (Discover, Specify, Design, Implement, Verify, Release, Operate). Each discipline is operated by a non-negotiable social practice shown above the matrix; together, they produce and refresh a deterministic context store shown below the matrix, with four layers covering structure, lineage, behavior, and conformance. Color encodes each discipline's role at each stage: dark teal for primary owner, light teal for active contributor, beige for supporting role. Source: Authors.

Spec-anchored SDD establishes the intent layer. A living, machine-readable specification, capturing intent, scope, constraints, and acceptance criteria, lives in the repository next to the code and is enforced on every change. The spec is the AI coding agent's brief and the human reviewer's reference. SDD inherits from domain-driven design's ubiquitous language tradition: the spec is the ubiquitous language made machine-readable, available to humans and agents alike. The practice that operates it is straightforward but non-negotiable: the spec is authored and reviewed like code, with diffs and approval, and amended when reality diverges from intent. That last clause is what separates the practice from big design up front in modern clothing.

The failure mode is what Martin Fowler calls spec-first-then-discard: a specification generated to brief an agent and then never updated. Without the social practice, agents brief from stale intent, and the team has produced documentation theater. Early empirical support is starting to arrive; Marri's 2026 case study on a banking microservices implementation reports a 73 percent reduction in security defects against unconstrained generation when constraints are enforced at the specification layer. One case study is not a generalization, but it points to where the leverage sits. First step: commit a /specs/ file for one feature this sprint, treat it as a reviewed artifact, and reject changes that diverge from it without a spec amendment.

TDD establishes the behavior layer. A failing test is written before production code. Red, green, refactor. Tests pin behavior at the unit and feature level and enable safe refactoring, as Kent Beck established in the canonical text and Martin Fowler has continued to develop. The TDD literature is twenty years old; what AI changes is the stakes. When code arrives faster than humans can read it, the tests are the layer that catches behavioral regressions the human reviewer no longer has time to spot. The practice that operates it has two parts.

The first is the tests-first norm, with logged deviations rather than implicit waivers. The second is the system depth to know which test to write next. The tests are simultaneously the agent's brief and the verification of the agent's output, which makes the engineer's judgment about what to verify the load-bearing skill of the loop, and investing in engineers' technical depth alongside their prompt skills is what keeps the context store trustworthy as the system evolves. The failure mode is TDD as a tax: tests written after the fact to satisfy a coverage gate, producing coupling and cynicism, and a green suite that codifies whatever the engineer or the agent thought the requirement was. First step: adopt a tests-first norm for the next agent-led change. Write or approve the failing test before accepting generated production code.

Architectural fitness functions establish the structural layer. Automated, executable checks verify architectural conformance: modularity, performance, security, deployability, observability. They are the architectural counterpart to unit tests, introduced by Ford, Parsons, Kua, and Sadalage and developed into a delivery practice through Thoughtworks' fitness-function-driven development. ArchUnit in Java, dependency-cruiser in TypeScript, and equivalent libraries in other ecosystems implement the pattern. Wired into the CI pipeline, they block merge when an architectural characteristic regresses. The practice that operates them is collective ownership: teams maintain the catalog, treat violations as debt rather than nuisance, and trust the sensors as the architectural gate so that reviewers are not the bottleneck.

Senior-reviewer capacity in AI-accelerated codebases is finite, and cognitive overload slows teams down and increases failure rates. Pushing architectural conformance off the reviewer's plate and onto automated sensors is how PR review stays an interrogation of why, not a checklist for what. The failure mode is the synchronous architecture review board, or the one senior engineer who catches everything; both are slow, both burn out, and both let architectural drift surface only when production exposes it. First step: pick the top three architectural pains the team complains about and encode each as a CI-blocking fitness function within thirty days.

The three disciplines on one value stream produce the context store that this article keeps pointing at. Its four layers are structure, lineage, behavior, and conformance: the system's anatomy, the reasoning that shaped it, the behavior intended and observed, and the live status of every constraint. Two projections come out of those layers: a machine-readable knowledge graph that the agents and CI jobs query, and a human-readable system spec that the architect reads. Birgitta Böckeler's harness frame names the same shape: the spec is a feed-forward guide, the tests and fitness functions are feedback sensors.

The context store is what a reviewer queries when asking why a service rejects requests over 5MB, finding the spec, the test, and the fitness function in three different artifacts, all in the repository. An AI agent picking up the same feature next quarter starts from the same spec and fitness-function catalog the original engineer worked against, with the reasoning behind every decision since persisted alongside, which is what closes the context gap across time, across contributors, and across the boundary between human reviewers and the AI agents now writing alongside them. The context store is what makes that boundary stop mattering for the system's evolution. Concretely, this lives in the repo as a /specs/ directory, a fitness-function catalog, and a PR template that requires spec section references, a fitness-function delta, and an 80/20 hand-off note for agent-led PRs.

Conclusion

The productivity question is not the interesting one anymore. AI generates code faster; that part works. The pressing question at the moment is what happens to the context around the code, the intent, the architectural reasoning, the institutional memory that used to be produced as a side effect of human typing. Code now ships at machine speed. The context does not, and architecture is where the bill comes due. Amazon's outages at the team altitude and DORA's instability trend at the leadership altitude are reading from the same bill. The economics are familiar: cost reduction shows up in onboarding speed and reduced post-incident remediation; throughput shows up in fewer regressions blocking the next release; compliance shows up in an executable contract auditors can read. Each is a leverage on the same underlying gap.

Evolutionary architecture already contains the instruments to close that gap. Fitness functions, spec-anchored SDD, and TDD have existed for years as separate practices. Running them together as a single verification system, with the artifacts they produce persisted in the repository and queried as part of normal engineering practice, is the operational answer to a problem the evolutionary architecture tradition has been preparing for without naming. The reframe matters: the context store is not a pre-merge artifact. Before deployment, it gives AI agents the context to generate code aligned with intent and compliance, and gives reviewers the basis to interrogate what an agent changed and why. After deployment, it gives engineers the context to debug a live-site issue, the basis to plan the next refactor, the contracts to integrate one system with another, and a projection for leadership reading the architecture when deciding on technology direction. Verify, then query to understand.

The goal is not to slow AI-assisted development down. Agents generating code at speed is fine. The goal is to make the system's reasoning executable enough that humans and agents can evolve the system together without losing the plot.

References

1. Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The impact of AI on developer productivity: Evidence from GitHub Copilot (arXiv:2302.06590). arXiv.
2. METR. (2025, July 10). Measuring the impact of early-2025 AI on experienced open-source developer productivity.
3. CNBC. (2026, March 10). Amazon plans a deep-dive internal meeting to address AI-related outages.
4. DORA & Google Cloud. (2025). State of AI-assisted Software Development 2025. Google Cloud.
5. Mortimer, P. (2026, March). Complexity and creativity in software engineering [Conference talk]. QCon London 2026.
6. Westheide, D. (2026, March 18). Spec-Driven Development is Domain-Driven Design's Impatient Cousin: Why BMAD won't save you. INNOQ Blog.
7. Fowler, M. (n.d.). Exploring gen AI: Specification-driven development — tools. martinfowler.com.
8. Marri, S. R. (2026). Constitutional spec-driven development: Enforcing security by construction in AI-assisted code generation (arXiv:2602.02584). arXiv.
9. Beck, K. (2002). Test-driven development: By example. Addison-Wesley.
10. Fowler, M. (n.d.). Test-driven development. martinfowler.com Bliki.
11. Ford, N., Parsons, R., Kua, P., & Sadalage, P. (2023). Building evolutionary architectures: Automated software governance (2nd ed.). O'Reilly Media.
12. Thoughtworks. (n.d.). Fitness function-driven development. Thoughtworks Insights.
13. ArchUnit. (n.d.). ArchUnit: Unit test your Java architecture.
14. Böckeler, B. (n.d.). Harness engineering. martinfowler.com.