Coding Agents Don't Scale Themselves. Neither Do Your Teams. — Patrick Debois, Tessl

Patrick Debois heard continuous delivery dismissed as crazy in 2009. He now hears a similar objection to the “dark factory,” where software work becomes substantially autonomous: “It will not work here.” His interpretation is that the organization is not set up for it yet. That does not prove every technical obstacle will disappear; it redirects attention to the team structures, shared systems, and operating practices required if agent capability continues to improve.

The argument begins with a consequential assumption: loops, harnesses, and related agent machinery will become broadly available, perhaps even as services from frontier labs. If that happens, assembling an agent loop will no longer distinguish one organization from another. The differentiator moves outward to how teams collaborate, how platforms spread reliable practices, and how quickly the organization learns. This commoditization remains a forecast, not a demonstrated outcome.

Conway’s Law supplies the organizational lens. A coding agent used by one developer can remain a personal productivity tool. The same agent introduced across a team changes planning, review, knowledge sharing, platform responsibilities, and the flow of work to people upstream and downstream. That is the scale problem the rest of the talk follows.

The popular “developer as conductor” framing creates real identity friction. Managing agents may involve writing prompts and specifications rather than directly implementing code. Context engineering makes that work more systematic—prompts can be tested, evaluated, distributed, and optimized—but some developers still find the activity detached from the technical craft that drew them to engineering.

Harnesses and loops reopen a programmatic path. Instead of merely asking an agent to do better, engineers can build tools that control what it sees, which checks it runs, how it retries, and what evidence it must produce. The abstraction moves implementation work upward: engineering now happens partly in the system that enables the agent to work.

The loudest skeptics can be especially useful here. A developer angry about a vanilla agent’s poor output usually knows what is missing: a convention, a test, architectural context, a tool, or a constraint. Asking that person to encode the missing knowledge turns criticism into an improvement that can affect future runs. Resistance becomes actionable when the engineer can change the conditions that produced the bad result.

The central shift is simple: “stop fixing the code” an agent produced and improve the system producing it. An immediate code correction resolves one artifact. Encoding the lesson in reusable context, a harness, or an agent loop can change later artifacts as well. Debois describes this as moving from autocomplete and closely supervised prompting toward system thinking—building the thing that builds the thing.

Consider a recurring authentication failure. An agent implements a shared authentication path but omits the organization’s expected tests, documentation update, linter, or security check. A developer can repair that pull request manually. If the omission appears again, the more valuable response is to add the authentication convention to shared context and place the common checks in the harness. Later runs can then arrive with those obligations already included, reducing the same human correction and extending the improvement to every user of that system.

Fewer human touches must not mean abandoning engineering discipline. Agents should be instructed and equipped to write tests, update documentation, and follow the other practices expected of human engineers. A prompt that produces plausible code once is not a maintained development system. Tests and documentation preserve the ability to change that system and evaluate whether later behavior is actually better.

Team rituals change when repeated failures become system inputs. A retrospective can ask where the agent hit the same obstacle over and over, then assign a context or harness improvement. The code failure still matters, but the learning target is now the recurring condition behind it. This is how one repaired authentication change becomes a reusable authentication path rather than another isolated fix.

Planning develops a corresponding split. Work that is sufficiently scoped and well defined can go directly to an agent, especially as the harness improves. Ambiguous work remains a conversation among people because the team still has to decide what it wants. Agents can execute a settled task; unresolved product and architectural choices still require collective judgment.

Team leads must set the pace instead of telling every developer to experiment independently. A team may progress from prompting to better specifications, reusable context, harnesses, and loops. A lead can make each stage a shared expectation—for example, “stop prompting; make the context reusable”—before advancing to the next capability. That constraint prevents useful knowledge from remaining trapped in personal workflows.

Faster implementation also exposes constraints elsewhere. Go-to-market teams and users may struggle to absorb a higher release rate, while requirements may arrive too slowly to keep development supplied with clear work. The harness therefore cannot end at code generation. Automation and workflow redesign must also help gather inputs and carry completed work through downstream communication, adoption, and feedback.

At 9:24, Debois proposes two practical measures. Human touches count how many interventions are still required before an agent reaches the right result; that number should fall as context, guidelines, and harnesses improve. Reuse asks how broadly an improvement spreads. A change to a common harness can help everyone who uses it, creating a multiplier through shared infrastructure rather than through one celebrated “10x” individual.

These measures describe improvement in the agent system, but the talk does not define a counting method, numerical target, or demonstrated relationship to overall developer productivity. They are most useful as directional operational metrics: preserve the correct result while reducing intervention, and increase the number of people or teams benefiting from each correction.

What does the scaling path make visible? The diagram follows a recurring correction as it moves from one developer’s intervention into shared context and harness components, then through a maintained platform registry to multiple teams. Feedback from those teams supplies the next round of improvements. The multiplication effect comes from this loop, not from merely giving more people individual agent licenses.

Each layer solves a different problem. A developer discovers the failure. A team turns the correction into reusable context or tooling. A platform owner makes the component discoverable, testable, secure, and maintained. Multiple teams then reuse it and generate broader evidence about where the shared system still fails.

Scaling beyond one repository brings platform work into view. Existing platform teams may focus on cloud infrastructure or an MCP gateway, but coding agents add skill registries, context evaluation, guardrails, and agent identities. The work does not fit neatly into one existing department: developer-experience teams may lack infrastructure ownership, while infrastructure teams may be removed from daily development. Debois leaves the departmental answer open but insists on a named owner for the shared program.

The goal is a set of paved roads. Authentication knowledge should not be rediscovered by every team. Common linter and security-tool integrations should not be rebuilt in every harness. A registry can package these supported components so the maintained route is also the easiest route.

A repository where anyone publishes anything is not yet a platform. It quickly produces similar skills, uncoordinated forks, and uncertainty about which component to trust. Maintained components need owners who make them testable, modular, extensible, and security-scanned. The difference is operational responsibility, not simply centralized storage.

Standardization has a human cost. Teams disagree about how work should be done, sometimes with the energy of a tabs-versus-spaces argument. The practical result may be three or four supported roads rather than one universal solution. Teams can still choose another route, but they assume its maintenance budget while the central options remain supported.

The platform should also reveal spending and iteration counts. A final successful artifact hides whether the agent needed one pass or many expensive retries. Visible cost gives teams an optimization target: choose a suitable model, reduce unnecessary iterations, and improve context or harness behavior. This turns cost control into systems improvement rather than a blind cap on usage.

Lunch-and-learns, Slack channels, success stories, and champions programs may help people discover the tools, but they do not create this operating system. Nor does buying licenses and letting “a thousand flowers bloom.” Leadership must give team leads and platform owners an explicit mandate to establish the shared practices and maintained paths.

New job titles—AI product engineer, forward deployed engineer, agentic engineer, AI engineer—signal what kind of candidate an organization hopes to attract. They do not validate maturity or skill in a young field. Hiring therefore needs to examine capabilities separately rather than infer them from the label.

Debois describes a three-part assessment: AI use, demonstrated by openly letting a candidate use AI aggressively on an exercise; engineering judgment, tested by asking the candidate to explain what happened and why the decisions are sound; and collaboration, shown by a willingness to share, improve reusable work, and operate as part of a team. A finished AI-assisted artifact establishes little about the second and third dimensions without the walkthrough.

One person may not excel at all three. Someone can be highly capable with agents but need mentoring in engineering judgment, or be a strong engineer who is still learning agent workflows. A single junior-or-senior label hides those differences and makes development plans less precise.

Engineering leaders face the same measurement problem when defending the investment. License counts are easy to report, while faster delivery and improved quality are difficult to prove. Human touches, agent turns, and reuse offer more inspectable evidence that the operating system is improving, though they do not by themselves establish a net productivity gain.

High vendor bills should trigger optimization before blanket restriction. Model choice matters, but so do context and harness quality because repeated, avoidable iterations consume resources. The platform’s job is to make that relationship visible and help teams reduce waste while preserving useful work.

Agent capability also does not automatically reduce every team to one or two people. A strong individual may still need complementary product or design skills, holiday coverage, production support, and capacity for incoming bugs. Junior engineers still need opportunities to learn what good work looks like. Team size remains constrained by the work the organization must carry, not just by implementation speed.

The dark factory becomes a “dim factory” at the end of the talk. Autonomy should vary by feature and risk rather than become a universal destination. Higher autonomy calls for auditing who changed code, verifiers that check whether the result is useful, and enough situational awareness to investigate failures. Organizations can choose positions along a spectrum from close supervision to autonomous approval.

The lasting advantage is the knowledge captured in skills, context, harness constraints, and business rules. Models and agent products may change, but an organization that has made its operating knowledge explicit can teach the next system how work should be done. That turns continuous delivery into continuous learning.

The sharper test is not whether the organization can freeze the system into perfect reliability. It is whether the organization can swap components in and out, change more of the system, and keep it reliable while doing so. Reusable knowledge, evaluations, paved roads, and feedback loops make that adaptation possible.

Debois closes by describing a website he is building to collect agent-enablement patterns that did not fit into the talk. He invites practitioners to identify missing patterns and contribute stories about how agent adoption is unfolding inside their organizations. No destination for that project is supplied here, but the invitation reinforces the mechanism: organizational practice improves when teams compare concrete experience rather than treating one framework as finished.

The final judgment follows from every preceding layer: “the solo player” does not win this game. Individual agent skill matters, but scale comes when teams improve the generator, platforms maintain shared paths, and leadership gives the organization permission and responsibility to learn together.