The Spectre of Emergent Knowledge
The current shift toward AI-assisted software delivery is often framed through an individual lens. Will engineers lose relevance? Will coding still matter?
In reality, the more interesting, and arguably more consequential question does not concern individuals at all. The demand for engineers who deeply understand systems is unlikely to disappear. If anything, it may grow as the volume of generated software increases and begins to exhibit failure modes that require real reasoning.
The more subtle risk lies elsewhere, at the level of organizational capability.
From Implementations to Intent
We are witnessing the early institutionalization of a new way of building software. Instead of reviewing implementations, teams increasingly review prompts, instead of validating code, they validate execution plans. Peter Steinberger describes environments where reviewing prompts instead of code becomes part of the development workflow. Compound engineering reframes engineering work around plans that agents execute rather than implementations that humans construct.
None of this is irrational. On the contrary, it is a logical continuation of decades spent raising the abstraction layer of software work. However, this shift changes something fundamental: where knowledge lives.
Knowledge That Appears, But Does Not Accumulate
In traditional engineering environments, knowledge accumulates through friction.
- Debugging teaches causality.
- Failure builds intuition.
- Repeated exposure forms mental models.
- Decisive action in chaos creates the conditions for sense-making.
Those ideas aren’t new. For over 25 years, the Cynefin Framework has articulated the same insight at the human–system level: causality, intuition, and mental models emerge through interaction with complexity, not from upfront understanding. Over time, organizations do not merely produce working systems, they develop understanding of why those systems behave the way they do.
Agent-mediated environments operate differently:
- A production issue emerges.
- An agent analyzes the system.
- Retries are introduced.
- Caching is adjusted.
- Timeouts are tuned.
- The system stabilizes.
Yet the organization may never form a durable understanding of the root cause because the resolution exists, but the explanation does not. Knowledge is emergent rather than accumulated.
A Familiar Pattern Outside Software
This dynamic is not unique to software.
Over recent decades, the semiconductor industry evolved toward a separation between design and manufacturing. While chip design capabilities remained widely distributed, advanced manufacturing capability became concentrated in specialized foundries such as TSMC.
The physics of semiconductor production did not become unknowable. What diminished was the operational knowledge required to execute it at the highest level, knowledge that is difficult to preserve without continuous practice. Designing chips and fabricating them are related, but distinct capabilities. One can persist while the other fades. The abstraction layer works, until strategic autonomy is required.
The Organizational Consequence
An organization that fully optimizes for agent-driven delivery may become extremely effective at producing working systems.
Plans are validated. Agents implement. Agents debug. Agents even remediate production issues. Delivery accelerates.
But understanding may no longer deepen at the same rate due to the fact that root-cause reasoning becomes episodic rather than institutional. The organization becomes adept at generating solutions, yet gradually less capable of explaining them.
This distinction is invisible under normal conditions where systems continue to function, and incidents are resolved.
The difference becomes visible only when the organization encounters something genuinely new:
- a scaling ceiling,
- an unfamiliar regulatory constraint,
- an unexpected performance collapse,
- a systemic security issue.
At that point, the challenge shifts from fixing behavior to understanding it. Over time, the issue is not that systems stop working, but that the organization’s ability to produce engineers who truly understand them begins to erode…
The Disruption of the Apprenticeship Path
Historically, junior engineers acquired craft by engaging directly with the mechanics of systems. Writing code was not merely a means of delivery, it was the pathway to building mental models.
Agent-mediated environments reshape this pathway. Juniors are expected to produce outcomes rather than develop understanding. Their effectiveness is judged by orchestration rather than construction.
Because they lack the depth required to supervise complex agent behavior, they are incentivized to prioritize delivery speed over comprehension. Over time, this weakens the apprenticeship layer through which deep engineers traditionally emerged.
The environment no longer requires (or rewards) the slow accumulation of craft in the same way.
The Spectre
None of this is an argument against agent-driven development. Accelerating software production is a natural evolution, but in a world where the volume of generated code grows exponentially, the preservation of engineering craft becomes more, not less, important.
The spectre of emergent knowledge is subtle precisely because it does not disrupt delivery; it lingers at the edge of organizational awareness, growing only as understanding quietly decouples from output. If your organization is embracing agent-mediated delivery, the question is not whether you should do so, but whether you are equally intentional about ensuring that understanding continues to accumulate alongside production.
Do you know who ultimately owns the reasoning behind the systems being built — and who will be accountable for their failures when the people who helped generate vast portions of their logic are no longer there?
Are you preparing for the moment when millions of lines of generated behavior must be understood rather than merely maintained?
And does your organization still offer a path through which a junior engineer can grow into full craft, rather than being asked to jump straight into orchestration?
Agent-driven development changes how software is produced; it does not remove the need for those who understand it. The real challenge may not be how to generate more software, but how to ensure that the capacity to comprehend it does not quietly fade under the spectre of knowledge that appears when prompted — yet is never truly retained.