When we talk about “organization,” it’s easy to think in terms of roles: architect, frontend engineer, backend engineer.
But that may not be the point.
What really matters is not what a role is called,
but what scope of context it is allowed to hold.
Imagine a project of moderate complexity that requires long-term development and maintenance.
We could assume the existence of an individual who is:
-
sufficiently capable
-
able to retain a large amount of context
-
able to switch freely across modules
-
and skilled at searching for and extracting key information
Even so, this individual still needs to understand and care about the entire system at once.
The alternative looks very different:
-
decompose the system into multiple responsibility units
-
strictly constrain each unit’s context to the code it owns
-
whether it’s called an “architect” or a “frontend engineer” is irrelevant
-
what matters is that it cannot — and does not need to — understand the rest of the system
Up to this point, this is still a classic engineering organization problem.
But under the assumption that AI-assisted coding has become nearly low-cost, a new tension emerges:
The ongoing human cost of designing, maintaining, and adjusting these responsibility boundaries
may now exceed the cost of writing the code itself.
If what’s truly expensive is no longer “implementation,”
but deciding who should be responsible for what — and who should not need to know what,
then the question shifts:
If agents can write code, can agents also organize other agents?