I remember sitting in a conference room years ago, watching a group of senior engineers debate with near-religious fervor over whether to use tabs or spaces for indentation. The discussion spiraled into line-wrapping conventions for function arguments, the placement of braces, and even the preferred ordering of import statements. It was a familiar scene: experienced developers locked in a battle over stylistic minutiae that, in the grand scheme of things, barely affected the software’s functionality. Yet these debates carried a weight far beyond aesthetics. They were proxies for something deeper — a shared need to establish a common language, a collective rhythm, a social contract encoded in text.

Those arguments were not just developer eccentricities. They were the rituals through which teams negotiated shared conventions, maintained design intent, and preserved a sense of belonging. Source code was the meeting place where humans aligned mental models, enforced maintainability, and encoded architectural decisions. It served two very different audiences at once: the machine that executed instructions, and the next human who would read, understand, and modify them. Code was both a technical artifact and a social contract.

What happens when humans no longer need to meet inside the code?

For most of my career that would have been a strange question. Implementation and coordination were so tightly coupled that separating them was mostly theoretical. AI makes the separation practical. The code still has to exist. What changes is who needs to understand it, and where the understanding that governs it must live.

01 Code Keeps Its Job, Loses Its Audience

Code does not vanish in this model. It remains the runtime artifact — the substrate machines execute and verification systems inspect. But its primary audience changes. For decades, readability, naming, formatting, comments, abstractions, and code review all carried a social function as well as a technical one. We optimized code not only because the machine had to execute it, but because another person would eventually need to understand why it existed.

That second audience shaped an extraordinary amount of engineering practice. Style guides reduced needless disagreement. Naming conventions compressed domain knowledge into vocabulary. Code reviews did more than catch bugs; they spread context across a team. Even familiar arguments about whether a method was too long were really arguments about the future cost of human understanding.

If implementation is predominantly produced, inspected, and repaired by agents, some of those conventions remain useful. Others may lose the economic and social justification that made them important in the first place. The question is not whether generated code should be unreadable — humans will still need to investigate failures and audit consequential behavior. It becomes harder, though, to defend source code as the primary place where an organization negotiates meaning.

Specifications take on that role instead. They stop being requirements documents sitting upstream from implementation and start carrying architectural boundaries, acceptance criteria, non-functional constraints, trade-offs, policy, and the institutional memory that used to leak across code comments, pull requests, tickets, and conversations.

When humans stop writing the implementation, specifications stop describing the work. They become the work.

That does not make specification-writing a clerical replacement for programming — quite the opposite. It makes ambiguity more expensive. A vague requirement once triggered a discussion with a developer who could push back or infer intent while implementing it. An autonomous system may instead turn that ambiguity into a perfectly coherent subsystem built around the wrong assumption. The human artifact has to become more precise, without pretending every decision can be predetermined.

02 Correct Agents, Incorrect Organization

The review room was silent but tense. A recent production incident had triggered alarms: two AI agents had deployed conflicting changes to the same service within minutes, causing cascading failures. No human had written the implementation, yet multiple agents had touched the codebase in overlapping ways. The team pored over logs and diff histories, trying to untangle the invisible handoffs between agents — who triggered what, which assumptions each agent carried, and why individually reasonable decisions had combined into a globally unreasonable result.

The pattern felt familiar. Distributed systems have taught us for decades that individually correct components can still produce incorrect systems. Concurrency, stale state, retries, partial knowledge, and poorly coordinated handoffs create failures that no single component “owns.” Agent teams inherit the same problem.

Correct agents do not necessarily produce a correct organization.

That changes what humans need to observe. They do not need to watch every generated token or inspect every diff simply because it exists. They need decision provenance: which specification was active, what context the agent received, which architectural rule constrained the choice, what evidence caused one agent to accept another agent’s output, where two branches of work began to disagree. Observability into agent behavior is not a convenience — it is governance.

Human teams had informal versions of this we rarely called by that name: architecture diagrams, design reviews, pull-request conversations, stand-ups, hallway conversations. They made coordination visible enough that someone could notice two people solving the same problem differently before the difference became production behavior. An AI development organization needs equivalent surfaces, though not necessarily equivalent interfaces. The goal isn’t a dashboard full of agent activity; it is making decisions, assumptions, and conflicts legible enough that humans can govern the system without becoming another bottleneck.

03 Different Verification, Not Less Verification

Code review sat near the center of traditional software governance because implementation was expensive and human-produced. Reading another engineer’s change was a practical place to ask whether it matched the design, violated conventions, or misunderstood the problem. That mechanism strains when implementation becomes abundant. If a team of agents can produce dozens of substantial changes in the time it once took a developer to prepare one pull request, putting human review at the end of every generated diff merely moves the bottleneck.

Specifications, architectural rules, design systems, acceptance criteria, security and privacy policies, automated verification, and evidence collection begin to form a layered control system around the agents. Human judgment remains present, but it moves toward the boundaries where interpretation, risk, or business meaning cannot safely be reduced to an automated rule.

Suppose an AI team generates five different interfaces with the same conceptual mistake — an important workflow action consistently hidden, a domain rule represented incorrectly every time. A human team could repair the five instances and solve the immediate problem. That misses the interesting question: what made that mistake valid five times? Maybe the specification was ambiguous. Maybe the design system encoded the wrong convention. Maybe a verification gate checked syntax and accessibility while missing the business behavior that actually mattered.

The technical lead no longer fixes the output. The technical lead fixes the system that produced the output.

In an AI team, recurring defects are rarely only implementation problems. They are governance defects. There is a danger here, and it is not small: governance can become an elaborate bureaucracy written in machine-readable form, and teams can end up trusting gates because they are automated rather than because they are meaningful. Good governance doesn’t reduce innovation; it reduces improvisation — but that tension does not disappear simply because the new process is faster.

04 The Backlog Becomes a Living Corpus of Intent

Backlogs tell us something about the economics of the old model. When demand exceeds implementation capacity, work has to wait somewhere, so we turn that waiting into a queue and call the resulting artifact a backlog. If AI radically increases implementation capacity, the backlog does not become useless — organizations will still have more ideas than they should pursue, and attention, capital, and risk tolerance remain finite. But the meaning of the queue changes. The scarce object is less often “developer time required to type this feature” and more often “organizational confidence that this is the right thing to build under these constraints.”

A backlog in that environment starts to resemble a living corpus of intent: desired outcomes, domain constraints, unresolved questions, trade-offs, and rejected alternatives. Execution begins to look less like ticket processing and more like a control loop — human intent becomes specification, agents execute against it, automated systems verify the result and assemble evidence, humans examine the evidence where judgment is required, and the cycle begins again.

A loop without specifications simply automates improvisation.

This is not merely a faster version of Agile. Speed changes the failure mode as much as the delivery rate. A poorly governed loop can drift from intent faster than a human team ever could, generating internally consistent implementations, tests, documentation, and migrations around an assumption that should never have survived the first design conversation. The important loop is not the one that generates the most software. It is the one that can repeatedly return to intent.

05 Software as Organizational Participant

A product leader opens the system on Monday morning. Over the weekend it has analyzed a large body of support conversations, noticed a recurring regression, correlated the complaints with a recent release, and compared the behavior against the current specification. Several agents have explored possible changes. Relevant tests have run. The system has assembled the evidence and highlighted the trade-offs.

It has not quietly changed the product. Instead it presents something closer to: here is what I observed, here is what I propose, here are the consequences.

Traditional automation executes a process we already understand. This kind of system participates in the feedback loop through which the organization decides what the process should become. That distinction matters because participation requires context. A system acting inside finance must understand more than numbers; compliance cannot be reduced to checking whether a field exists. Without domain knowledge, an autonomous organization can become extraordinarily efficient at producing nonsense.

Efficient nonsense is still nonsense.

Accountability cannot be delegated to the agent. A recommendation may be machine-generated, but the organization that chose the specification, constraints, evidence thresholds, and decision boundaries still owns the consequence. That is one reason the “co-worker” metaphor is useful only up to a point: software can participate in organizational work without becoming morally responsible for it.

06 What Is a Software Engineer, Then?

Take the premise seriously for a moment: no human on the development team needs to touch production code. Then what exactly is a software engineer? What is an architect when implementation is no longer the primary medium through which architecture becomes real? What is a technical lead when there are no human pull requests to approve?

The roles do not vanish, but their center of gravity moves. Engineering work shifts toward specifications, architectural boundaries, verification strategy, evidence evaluation, domain trade-offs, and institutional memory. QA becomes concerned with whether the evidence actually demonstrates the promised behavior, not merely whether a test suite is green. Architecture becomes less about drawing the structure humans will code and more about defining the constraints within which autonomous implementation can safely vary.

That is appealing until we ask where engineering judgment comes from. Most experienced architects I know did not learn architecture by reading architecture documents. They learned it by living with consequences — debugging race conditions that should have been impossible, watching migrations fail halfway through, inheriting abstractions that looked elegant on a diagram and became unbearable under real change. Implementation was painful, but the pain taught us something. We may eventually discover that implementation was not merely labor. It was also how engineers learned.

Perhaps some of that learning can move elsewhere: engineers may investigate failures deeply even when they did not author the implementation, evidence reviews may become richer than code reviews ever were, some people may still descend into generated implementation when consequences justify it. But I do not think we know yet. A profession can automate part of its work faster than it understands what that work was teaching — and that may become one of the most important limits of fully AI-based development teams.

I suspect engineers will continue arguing about software. We always have. But perhaps the arguments will move somewhere else — not tabs or spaces, not where the brace belongs, not whether a function call should fit on one line. The arguments that remain will be harder: what did we actually mean, which constraints matter, what are we unwilling to trade away, what evidence is enough, and how do we know that a system built by machines still represents the intentions of the people responsible for it?

Code was never the product. Shared understanding was.

If that understanding moves out of source code and into specifications, governance, evidence, and institutional memory, we have not eliminated the human part of software engineering — we have concentrated it. That concentration brings its own risks. Teams may lose implementation instincts they did not realize they depended on. Governance may become opaque precisely because it is automated. Specifications can drift while every agent continues behaving correctly against an obsolete interpretation.

So I am less interested in whether AI can build an application without a human touching the code. That question is rapidly becoming ordinary. The more interesting question is whether we can design an engineering system that preserves human intent while allowing implementation to become almost entirely machine work. Perhaps the hardest problem in software engineering was never teaching machines how to build what we describe. It was learning to describe, precisely enough, what we actually mean.