Coding Agents and Limits /

I. Why It's Frustrating to Work With Clankers

I’ve been thinking about how far coding agents can scale.

A clanker has a limited context window. My intuition was that this puts a limit on the size of project it can work on. GPT-5.6 Sol disagreed. It argued that you can keep state outside of the context window: in code, documentation, issue trackers, tests and process. Split the work into local tasks and use more agents for review.

I wasn’t convinced. Tests can tell you whether the code does what the test says. They can’t tell you whether it’s the right abstraction, whether it fits the architecture or whether it just made the codebase a little worse. A reviewer clanker has the same problem.

This is what makes clankers frustrating to work with. They can produce code that compiles, passes tests and looks reasonable in isolation, but is still wrong. It takes taste and project context to explain why.

I said as much and GPT-5.6 Sol did a better job articulating the problem than I could. A clanker explained why it’s frustrating to work with clankers. Here’s its answer verbatim:

Yes. That is the strongest objection to the “externalize everything into tests and process” answer.

Tests can verify that code satisfies specified behavior. They cannot establish that the specification was the right one, that the abstraction is appropriate, or that the implementation communicates the underlying idea well.

There is a hierarchy here:

Property How verifiable is it?
Compiles, passes tests, preserves an API Highly verifiable
Obeys dependency and layering rules Partly verifiable
Implements the intended architecture Only partly verifiable
Uses the right abstraction Judgment-dependent
Is simple, clear, and expressive Judgment-dependent
Fits the project’s aesthetic and future direction Largely tacit
Will remain the best design as the system evolves Not presently verifiable

You can enforce that module A does not import module B. You cannot mechanically establish that the split between A and B reflects the correct conceptual decomposition.

You can require all persistence to go through a repository interface. You cannot establish from that rule alone whether the repository interface is useful architecture or unnecessary indirection.

You can measure function length, coupling, cyclomatic complexity, naming patterns, duplication, and test coverage. None of those measurements tells you whether the code expresses the idea directly. Once such proxies become targets, they often produce superficially compliant but worse code.

Architecture is not just constraints

Some architecture can be represented as executable constraints:

But architecture also contains a theory of the system: which concepts are fundamental, which distinctions matter, where change is expected, and which forms of complexity are acceptable.

That theory may never be written down completely. Even when it is, applying it to a novel case requires interpretation. Two implementations can obey every stated architectural rule while only one genuinely belongs in the system.

This creates a recursion problem. To verify that the implementation followed the architecture, the verifier needs enough understanding to reconstruct the architectural intent. But that understanding is itself part of the context that was supposed to be externalized.

An architectural compliance agent can therefore check legality more reliably than appropriateness.

Taste is compressed experience

“Taste” can sound mystical, but much of it is accumulated judgment about tradeoffs:

These judgments are highly contextual. A pattern that is elegant in one codebase can be alien in another. A more generic solution can be either a powerful simplification or premature abstraction. The difference may depend on years of project history and expected future changes.

Examples and style guides help, but they do not fully encode this judgment. An agent can imitate surface characteristics while missing the reason those characteristics existed.

Review does not fully solve it

A second agent can catch mistakes, but it has the same fundamental limitations:

Review is useful because independent perspectives reduce some errors. It is not a proof of quality.

Even human review works this way. Senior engineers frequently disagree about whether code is tasteful, whether an abstraction is justified, and whether a design follows the architecture “in spirit.” Organizations resolve this through authority, ownership, culture, and continued observation—not objective verification.

This strengthens the bounded-context argument

Suppose a project’s quality depends on ten thousand small, tacit design decisions. Some of them are encoded in the code, some in documentation, some in conventions, and some only in the maintainers’ shared understanding.

When an agent works locally, it may produce something that:

It may introduce a second conceptual vocabulary for something that already exists. It may place responsibility at the wrong layer. It may generalize the wrong axis. It may remove an apparent irregularity that was preserving an important distinction.

These errors are especially dangerous because they are not obvious failures. They create design drift. Each change is locally defensible, while the aggregate system gradually loses coherence.

Compaction makes this worse because the information most likely to disappear is often precisely the subtle rationale:

We considered this cleaner design before, but rejected it because it causes these three concepts to collapse into one.

A summary often preserves the decision—“use approach X”—while losing the mental model that lets the agent recognize when and how that decision applies.

Humans do not fully solve this either

Large human projects are possible, but not because humans have a reliable solution to this problem. They tolerate it.

They use long-lived ownership, apprenticeship, code review, architectural leadership, shared vocabulary, and repeated interpersonal contact to transmit tacit judgment. Even then:

A mature project is often partly a record of failures to preserve coherent intent.

The difference is that a long-tenured human develops a persistent, richly connected model through years of interaction. Current session-based agents do not have an equivalent stable identity and lived project history. Giving them searchable documents is not the same as giving them that model.

The actual limit

So I would revise the earlier claim.

External state and executable process can make arbitrarily large projects operable for bounded agents when tasks are sufficiently local and the important properties are formalizable. They do not make arbitrary design work reliably scalable.

The unresolved bottleneck is not merely memory capacity. It is preserving and applying a coherent, evolving system of judgment.

A single bounded-context agent cannot guarantee global aesthetic or architectural coherence across an unbounded sequence of changes. An agent organization cannot guarantee it either unless some mechanism maintains that judgment across time—and any such mechanism starts to resemble a persistent project mind rather than ordinary retrieval or compaction.

The most defensible conclusion is therefore:

Arbitrarily large implementation work may be decomposable. Arbitrarily large coherent design is not automatically decomposable.

Some design decisions can be localized behind stable boundaries. Others alter the vocabulary and structure through which the entire project is understood. For those, the required context is global, historical, and partly tacit. No checklist, test suite, or retrieval layer fully substitutes for it.

That does not make large agent-assisted projects impossible, but it means they are subject to the same—and probably stronger—architectural entropy as large human projects. The system can continue producing working code long after it has stopped producing a coherent design.

 Coding Agents and Limits