Your project is brittle because your coding agent knows too much!

At some point coding agents began gathering huge amounts of context. This reintroduced a wonderful human failure mode I wrote about here. At the time I called it behavioural coupling but in AI dev people call it “brittleness”.

When a coding agent (or any programmer!) can see beyond a unit’s declared interfaces, it will sometimes make implementation choices that implicitly and invisibly depend on another part of the system behaving just so. Eventually you can’t change anything without something else breaking.

Code Mak Naa is a 2-year-old research project that I polished up because its context management demonstrates a solution to brittleness that I wanted to share. (Visit here to see its other interesting ideas)

Code is generated only with knowledge of what is strictly guaranteed, and then discarded when those guarantees change. Anything that is not guaranteed is unknowable to the generator, such that no relevant coupling is possible.

Concisely: The context boundary of the generator must match the invalidation boundary of the unit being generated.

Code Mak Naa achieves this using outside-in graph traversal. Generators for each function only see what is guaranteed by the harness, working outside-in from a partial design, namely:

  • Their own specification.
  • Interfaces of any already-specified children (but not their implementations).
  • Implementations of any ancestors (the chain of functions that will actually consume them).
  • Current database schema.

This approach worked reliably all the way back at Claude 3.5 pre-reasoning, because the context boundary of the generator matches the invalidation boundary of the unit being generated.

Real example of this approach to context management here.