Code is free, trust is scarce

Many say AI will eliminate software development roles, replacing them with product builders and software factory managers. I find that a reasonable prediction. But if every company has access to the same intelligence, what makes a good engineering department, and what does it mean for the future of engineering leadership? My take is that trust, internal and external, becomes the scarce currency companies learn to manage.

The pace at which AI improves keeps accelerating, and there are no signs it will stop. So I have been trying to picture the future of engineering leadership under one, increasingly realistic assumption: AGI arrives within a couple of years, and intelligence becomes something you buy by the token. If that holds, it is increasingly expected that software engineers stop developing software the way they do today:

• Boris Cherny, who created Claude Code, expects the “software engineer” title to give way to “builder”.
• Meta’s internal AI-native playbook, reported by Reuters, renames members of its new small pods “builders”, so the change is already reaching some org charts.
• Even Kent Beck, the creator of Extreme Programming and a pioneer of test-driven development, writes about his own career: “The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x.”

For software engineers, several paths are starting to emerge: reviewer, product builder, manager of agents. What about engineering leaders? As our teams and organizations fundamentally evolve, our job will as well. But it is not yet clear exactly what it could look like. In this post, I try to summarize where my thinking stands as of today. Things move fast, and engineering leadership is being redefined at an unprecedented speed, so this is still an ongoing reflection.

From software developers to agent managers

Predictions about engineers fall into two camps. While they both agree that software will be further commoditized, they have different views on the demand for software engineers:

• The first camp expects more software and more builders: when something gets cheaper, we make much more of it. Tim O’Reilly, founder of the tech publisher O’Reilly Media, argues that when automation makes something cheaper, demand usually grows enough to raise employment, and that “it is not programmers who will be out of work.”
• The second camp, however, expects more software but fewer engineers. David Jayatillake, a data and AI practitioner who writes about the economics of software, calls it the Jevons inversion: growth goes to non-specialists building their own tools, and fewer specialists remain, only for the top of the professional ladder. In this case, the ladder tends to break at the bottom.

Early data leans toward the second camp: employment of 22- to 25-year-olds in AI-exposed jobs is now about 19% below trend, according to Stanford’s Digital Economy Lab, mostly because companies hire fewer juniors. We also see a surge of people building software without an engineering or software development background. But we are still at the beginning of the transition, so it is hard to predict where and when things stabilize.

Both views agree that whoever builds software ends up managing agents. Ethan Mollick, a Wharton professor who studies AI and its impact on work, argues that this makes it a management problem: specifying goals, giving context, dividing work, giving feedback, and organizing work and resources. In other words, the work itself shifts from writing code to leading the agents doing it.

What is the next bottleneck?

When work gets automated, value moves to whatever stays scarce. Writing code is no longer the bottleneck, nor a rare, valuable skill. In their scenarios for the transition to AGI, Anton Korinek and Donghyun Suh, who study the economics of AI, show that if and once work can be fully automated, wages fall toward the cost of the compute that does it. Value then goes to capital, to resources nobody can produce more of, and to what they call “nostalgic jobs”: work society chooses to keep human even when machines could do it. Joshua Gans and Avi Goldfarb, economists at the University of Toronto and authors of Prediction Machines, add a mechanism on top, in O-Ring Automation: when tasks depend on each other for quality, automating some of them raises the value of the bottleneck tasks that remain. For an engineering leader, the practical question is therefore: once coding is automated, which task becomes the bottleneck?

A consensus is starting to emerge:

• Will Larson, CTO at Imprint and author of An Elegant Puzzle and Staff Engineer, says the biggest constraint today “is judgment”.
• Andrew Ng, co-founder of Google Brain and Coursera, argues that more of our time must go into deciding what to build.
• Margaret-Anne Storey, a computer science professor at the University of Victoria who studies how developers work, warns about cognitive debt: teams lose the shared understanding of the systems they ship.
• Kent Beck points at trust, and Fiona Fung, who leads the Claude Code and Cowork teams at Anthropic, points at verification.

Put together, each describes a human who understands the system, decides its trajectory, and answers for it. That was already part of what engineering leaders and CTOs did, alongside the human side of the job (managing expectations, helping people grow, building teams, …). But this suggests that owning the system takes a growing part of the job.

A first layer: from ticket to tested pull request

Over the last year, my first step in using AI for engineering was to automate the lifecycle of a single ticket. We built a delivery pipeline, a set of skills and agents that run in tools like Claude Code, which I described in a previous post about AI adoption. It is inspired by the traditional lifecycle of a ticket in our teams, with an orchestrator walking the agents through the sprint board:

• an agent turns the ticket into an implementation plan, and an adversarial agent challenges that plan when the risk is high;
• an agent implements the change with its tests and documentation, and opens a pull request;
• separate agents review the code and test the change against the acceptance criteria, driving the application in a browser or through API requests. Each of them starts with a fresh context, so it does not inherit the blind spots of the agent that wrote the code.

The pull request ends up ready and tested, with its evidence attached: the plan, the review findings, a QA report with screenshots, and a log of every decision the pipeline made. A human still decides whether it ships, but they can already review the intent and the proofs rather than the code, and they can often skip manual testing altogether.

This is only a first layer of automation, since it handles one ticket at a time. But it shows that, with the right skills and harness, a task can go from ticket to shippable change through AI alone, while surfacing enough evidence for a person to trust it. This approach is credible and easy to adopt because it is very close to what teams are already doing. It makes many parts of the lifecycle of a ticket faster, hence it increases the team’s throughput, and the team keeps granular control over what ships.

The pipeline is not the moat

Pipelines like ours are for rent: GitHub Agent HQ, Codex cloud, Claude Code routines, Devin and Factory all sell some version of one, so building your own is less and less a differentiator. Even maintaining one is being automated: at Ramp and OpenAI, agents improve their own harness, the scaffolding of prompts, tools, and checks around the model. Anthropic’s engineers explain why most of that harness work is temporary: “Every component in a harness encodes an assumption about what the model can’t do on its own.” Each new model makes some of those assumptions obsolete, so part of the harness a team carefully builds today will be thrown away with the next generation of models.

I believe one part of the harness behaves differently, though: the part that serves the humans. The harness also encodes how people want the work presented so they can judge it, and ultimately trust it: which summaries, which evidence, which risk flags. That part follows the people and the organization, not the limits of the model, so it will keep needing someone to design it. I come back to it below, because I believe this will be the core of the leader’s job.

Compute is also already a commodity, even if it will be a large bill: Gartner expects AI coding costs to overtake the average developer’s salary by 2028. Everyone buys the same tokens at the same price, so the spend differentiates nobody, even though how to allocate it becomes a leadership decision. If both the pipeline and the compute can be bought, the real question becomes: what stays scarce?

Trust is what stays scarce

My current guess is: trust. Kent Beck already said it best in Trust Factory: “We’re accumulating code faster than we are accumulating trust.”

By trust, I mean something specific: enough confidence that a change does what we intended, fits what the company is trying to do, and has someone who will answer for it if it breaks. Correctness can increasingly be checked by machines. Intent and accountability cannot, because they belong to the company and its people. That is the part I expect to stay scarce, and the part engineering leaders will spend more of their time on.

At group.one we already experience this. The WordPress ecosystem has been flooded with security and vulnerability reports over the past few months. AI fixes most of them very well, but validating each fix by hand is what takes the time. We see the same pattern on our internal projects built almost entirely with AI: producing a change is fast, while deciding what to build and confirming we can ship it are slow. In both cases, AI made the work cheaper, but we still spend time getting confident about it, from both quality & product/roadmap perspectives.

The industry numbers show the same trend. A study of more than 100,000 GitHub developers by a team of economists led by MIT’s Mert Demirer found that commits roughly tripled with AI coding agents, while shipped releases rose only about 30%. Likewise at Meta, code changes rose 220% in a year while features reaching users rose only 36%, according to internal posts reported by Reuters. In both cases, a large part of the extra code never reached users. Something between writing code and shipping it holds it back, and I believe that something is trust.

Would AGI fix this? Partly. A capable enough model will verify code better than most reviewers, and much of today’s checking will be automated. But I see three reasons trust itself stays scarce. First, a model does not know your company. Sean Goedecke, a staff engineer at GitHub who writes widely about software engineering, argues that humans working with AI will be there for alignment rather than capability: the model can out-code us, but it does not hold our organization’s values and full context. In other words, you can buy reasoning from a model, but you cannot buy your company’s judgment and culture, what makes your company specific and different from its competitors. As a result, someone inside the company still has to decide whether a change fits.

Second, our old proxies for quality broke. Sean Goedecke notes that AI is breaking our proxies for expertise: an impressive side project no longer proves skill, since everyone assumes it was vibe-coded. Pull requests went the same way: a clean one with documentation and green tests used to be sufficient proof that someone took time to understand the problem. Agents now produce all of that by default, very rapidly and mechanically, so it proves very little. Consequently, the signals we relied on to trust work have to be rebuilt. While I believe we will find new ways of approaching quality gates and evaluations, we have to reinvent it all as of today.

Third, trust has a network effect: it flows through track records and relationships, and it takes time to build. Customers trust a company they know, and its products by extension, far more than a newcomer shipping the same features. Inside a team, we trust changes from people or teams who have earned it. In both cases, we trust a system, an organization that has proven to be trustworthy. Mitchell Hashimoto, co-founder of HashiCorp, made that explicit for open source with Vouch, which lets maintainers close contributions from anyone nobody has vouched for: who stands behind the code now matters as much as the code itself. Trust is even becoming a business of its own. In February, ElevenLabs announced what it calls a first-of-its-kind insurance policy covering AI voice agents, a sign that confidence in an agent’s work now has a price. Because it compounds over time, trust is precisely what a newcomer with the same AI cannot buy.

None of this means gates can ever be perfect: even excellent gates leak, with AI in the loop or not. Anthropic published a postmortem about a bug that passed “multiple human and automated code reviews, as well as unit tests, end-to-end tests, automated verification, and dogfooding” and was eventually surfaced by users. If a team that builds frontier models can ship a bug past all of that, no gate is perfect, and customers remain the last gate. That is exactly why their trust is worth so much.

As a result, I believe trust becomes what defines a software company. When everyone can technically ship roughly the same thing rapidly, especially in web development where the work is rarely deeply technical, the difference between two companies comes from two kinds of trust.

• The first is internal: how fast you can define, verify, and ship a change without breaking things and while truly providing value to your customers. A concept of “efficiency to trust” emerges here.
• The second is external: whether customers, auditors and partners believe you, built from your track record and from someone answering when things break.

The balance between the two depends on the domain. In payments, health or infrastructure, verification is expensive, so efficiency to trust becomes the main competitive edge. In simpler domains, the edge moves to what you choose to build and how much your customers already trust you. Either way, when everyone can ship the same thing, engineering efficiency in a company is defined by how fast it can define and trust what it ships, and by how much its customers trust it.

When coding takes minutes, coordination is the cost

For decades, writing code was the bottleneck, and we organized engineering around that fact: tickets, specs, handoffs, review queues, sprints sized to coding time. That no longer holds. When I say code is free, I mean the cost of producing a change, not the cost of owning it: maintenance, incidents and attention still add up, and they are exactly what the gate has to protect. Once writing code takes minutes, the work around it dominates, and many of the usual best practices of engineering teams no longer make sense. Otto Hilska, CEO of the engineering analytics company Swarmia, writes that “communication and coordination can be the majority of time spent on these things.” Our asynchronous processes were designed for a world where coding took days; now the waiting costs more than the work. At Anthropic, CI jobs rose 25x in six months, and as merges grew more than tenfold, source control became their biggest bottleneck, to the point that they replaced git with their own version control system. Coordination and verification, not coding, now set the pace.

Some teams remove this overhead by deciding and verifying while they build, together. They are merging back all the previously distinct steps of specifications, framing, reviews, etc.: Anthropic’s “campfire” puts about four people on one shared implementation; one person drives the AI while the others steer and review in real time, synchronously. When Swarmia tried it, the team went from a Figma mockup to a working prototype in five to ten minutes: what used to take a ticket, a spec and a review cycle happened in one sitting. They also found that “it’s easier to be blunt with a machine”, so criticism that would feel awkward on a colleague’s code flows freely. Steve Yegge, a veteran engineer and blogger known for his years at Amazon and Google, describes Anthropic as working from evolving prototypes instead of specs, with no operational plans beyond 90 days, because a prototype is now cheaper to produce than a document describing it. Similarly, Andrew Ng sees engineer-to-PM ratios moving toward 1:1 in co-located teams, a sign that deciding what to build is now as much work as building it. The common point is not the ritual but where trust gets built: in the room, while the thing takes shape, instead of in specifications before and queues afterwards.

Speed also creates a new risk of building too much. Simon Willison, co-creator of the Django web framework and one of the most followed writers on AI coding, compares cheap code to the Winchester Mystery House: when adding a room costs nothing, you keep adding rooms, and the design loses its coherence. Anthropic’s source control team, which built its new system largely with Claude, reported the same instinct at the code level: “Very often, we found that the role of the engineers was to tell Claude ‘no'”, when it over-engineered or broke the system’s constraints. Building too much is now cheap; shipping too much is not, because every change shipped is one more thing to trust and maintain. Leaders always had to turn down ideas to keep a product coherent. But when anything can be built in minutes, that call has to be made constantly, far too often to go up to a leader each time. It therefore has to move into the teams, and teams that make it need judgment and context, which is why I expect smaller, more senior teams, with more ownership and autonomy than ever before.

Team shape is already following among leading companies, but Meta shows that shape alone is not enough: its internal “AI-Native Playbook”, reproduced by Reuters, replaced teams of 10 to 20 specialists with pods of 3 to 5 “builders”, a direction lead from any discipline, and specialists pooled across pods. However, Meta originally changed the shape without changing how it decided what was safe to ship. An internal post in April later said unchecked AI agents were performing “large-scale, disruptive actions that humans are unlikely to execute.” The lesson I take from this is that smaller, faster teams only work if the whole system, the “gate”, is redesigned to accommodate this new way of working. Which raises the question of what that gate should be.

The human gate is not code review

What first appears as the obvious answer is that humans should review what ships. Yet some of the best practitioners are starting to disagree. On the Pragmatic Engineer podcast, Charity Majors, co-founder and CTO of the observability company Honeycomb, argued that code review is now overrated and the least valuable part of what humans add to software engineering: people are valuable at deciding what to build, not at reading code to check its correctness. Even Simon Willison, one of the most careful voices on the topic, admits he no longer reviews every line, even for production work; if he doesn’t, few people should. And when it comes to validating access for AI agents, Anthropic found that users approved about 93% of permission prompts, which is what a rubber stamp looks like. Humans make poor line-by-line gates, and at agent volume they cannot keep up anyway: this is the AI code review bottleneck.

So the gate has to be something else if we want to make the most of AI. Humans own the intent: what we build and why; and they put their name on the result. Putting your name on the result does not mean reading every diff; it means standing behind the gate that let it through. Owning the intent also means owning where it can go wrong, so they must own the risk lines: which changes can ship on evidence alone and which need human-in-the-loop. Anthropic’s own SDLC playbook describes it this way: “The loop keeps running. Human judgement stays above it.” Anthropic’s source control team works this way: its engineers still review every change request, but they “examine the intent of the change as opposed to reading every line of code.” In other words, humans stop being the checkpoint every change passes through and become the ones who set the rules of the checkpoint. Engineering leaders were already doing this: their teams ship new versions without them having to give approval at each step; and they still trust what is shipped thanks to a trusted organization and reliable ways of working.

So we are already doing a similar job, but we need to rethink our approach as the underlying resources that we manage are different. This includes redefining what the right evidence is to ensure that what is produced can be trusted. AI and agents behave differently from humans, and therefore, the gate and the evidence should be adapted accordingly. As an example, I am revising my view about complexity scanners, a family of tools I had not much considered for years until recently: they warned about a file being too long or a function being too complex, which were rare on my projects, and occurrences were usually justified: human developers rarely produced that kind of complexity in the first place, and teams knew where their messy corners were. Then, on an internal agentic platform we built almost entirely with AI, I saw methods drift to more than 20 arguments. Bringing those linters back forced the agents to refactor and to produce code I ultimately trusted more.

Leading teams design their quality gates for AI agents with the same idea in mind:

• OpenAI writes its lint errors to tell the agent how to fix the problem, so each failure doubles as guidance.
• Anthropic found that agents asked to judge their own work respond by “confidently praising the work” even when its quality is “obviously mediocre”, so it uses a separate, skeptical evaluator.
• StrongDM, an infrastructure security company whose small AI team runs a factory with no human-written code, hides its acceptance scenarios from the coding agent, because agents learn to pass the tests they can see. In each case, the evidence is shaped for the AI use-case, and deciding how to shape it so it can be trusted is human work.

Removing the human from the gate entirely does not work yet. Dex Horthy, founder of the AI agent startup HumanLayer, ran a fully automated factory with no human review and shut it down after about four months. Production broke, the model could not find the root cause, and the fix took weeks because nobody had read the code. Meta saw a similar pattern at scale: as AI-generated code surged, its major technical and security incidents rose 40% in a year, and the time staff spent firefighting rose 70%. Both stories show what happens when output scales faster than the gates. Still, I think automated gates are where software engineering is heading. What we have to figure out is the right gates, and how humans take part in building those gates rather than running them.

That leaves an open question. If humans no longer read every line, who still understands the system? Storey proposes that at least one human fully understands each AI change before it ships. A gate where people check a risk-based sample of changes, instead of every one, cannot promise that. I don’t know yet where the line sits, and it may differ by risk level.

Moving humans from reviewing code to designing gates and delegating decision power is the first major mindset shift most organizations still have not made. For many developers, it is a bigger change than learning to prompt, because their craft and identity are built on reading, writing and answering for code. It seems nobody has the full model yet, so we will have to invent it.

Experimenting with an AI-first engineering workforce

Even if pipelines are for rent, we build our own, because building it is how we learn where our own risk lines sit, and what matters to trust our systems. I am testing these ideas on our own work through the concept of “Software Factory”: the first layer still handles one ticket at a time with our delivery pipeline described above, and on top of it we are adding a second layer that looks after everything around handling single tickets: taking action on the feedback the agents provide (such as taking actions after a sprint retrospective), grouping pull requests together to facilitate human validation with the right evidence (such as bringing an internal version to QA or to the Product Manager), and handling the frictions, maintenance and issues that come with an active repository. It works with a delivery queue and two loops around:

• The delivery queue feeds tickets to agents using our delivery pipeline skills, this is the first layer running in parallel, at scale.
• An integration loop has an agent work through the pull requests waiting for review: it merges what is low risk on its own and groups the rest in meaningful batches for a human to approve. For larger features or projects, built on their own branch, we are adding an alignment agent that checks the branch still does what the spec says.
• Finally, an improvement loop has agents turn what the runs leave behind (chores, outdated dependencies, nice-to-haves, reports, friction with the harness) into new tickets that are then fed into the delivery queue. This keeps the main branch healthy.

This second layer has real decision power: it decides what can reach the main branch without a person. When it cannot decide, it escalates to a single place where every question, approval, and decision waiting for a human lands, with the right evidence to facilitate the decision. That “when it cannot decide” is the hard part to tune:

• If it escalates too often, people drown in requests. They either approve them without looking, which is the rubber stamp again, or they end up reviewing almost every pull request, basically making the second layer useless.
• If it escalates too rarely, we are back to Dex Horthy’s HumanLayer factory with a project that goes out of control, gets too costly to get back on track, and ultimately misses its goal.

Getting that line right is exactly the trust system I described above, and it is the part I am still learning.

Even considering such a second layer seemed delusional to me a year ago. I am now close to being convinced the technology already allows us to do so, with results at least as reliable as if it were fully human-driven, and at a much faster pace. Given that AI keeps improving with no signs of slowing down, I feel like I am already very late.

Anthropic’s source control team reports that its monorepo went from under 1,000 code changes merged per day in January 2026 to a record of 30,401 on September 9, with the weekly average near 18,000. That is roughly twenty times more in eight months, most of it since June, and so much that source control itself became their biggest bottleneck. Whatever exactly counts as a “change”, a curve like that tells us that what most companies produce today, and even what Anthropic produced a few months ago, is an order of magnitude below what is already possible. Elsewhere, Stripe’s agents produce over 1,300 pull requests a week. At these companies, agent-written code is being orchestrated at a scale such that their human workforce cannot keep reviewing the code of every change. At least a “second layer” is therefore needed to reach such scales.

It is also hard to get right. Will Larson, who is trying the same pattern at Imprint, found that “the pieces here compound only to the extent that you have the other pieces”: a queue, agents, specs, checks, gates and evidence system only pay off together.

An engineering leader’s job may now be to build, enable, and run such an AI-first engineering workforce that captures the productivity gains of this new technology while ensuring it keeps building trust.

The future of engineering leadership: owning what ships

Accountability does not move to the LLM. Will Larson calls out the “agentic passive voice”: a sentence like “Claude made an error in my writeup” hides the person who is responsible. A leader who accepts that framing has given away the one part of the job that cannot be automated. If generation is cheap, the pipeline is not a moat, trust is scarce and the gate is what builds trust, then the engineering leader’s job concentrates on five things:

1. First, ensure product intent can be translated into something agents can be held to: specs, acceptance scenarios, and quality bars, so that what product decides gets built as intended.
2. Second, own the trust system: where the risk lines sit, what evidence each change needs, and when a human needs to have a look.
3. Third, manage engineering resources by allocating the budget and workload between compute and people, and across activities such as implementation, validation, maintenance, etc.
4. Fourth, shape how teams work, with smaller pods, fewer handoffs and more decisions made live.
5. Fifth, grow the people who can sign. If the junior ladder keeps shrinking, someone still has to become the senior who understands the system, or at least, its intent. Anthropic’s analysis of about 400,000 Claude Code sessions found that success depends on “how well a person understands the problem”, so growing people’s understanding is what makes the agents productive.

Ultimately, what the leader manages is understanding. Charity Majors quotes a line many great engineers have repeated: “The real product of a software team is shared understanding.” Julie Zhuo, former VP of Product Design at Facebook and author of The Making of a Manager, adds that you cannot mandate an AI transformation; “you earn trust in an agent through evaluations.” Trust in agents, like trust in people, is earned with evidence. That is why the unit we need to look at is the fully loaded cost per accepted change: tokens, plus human review time, plus rework and incidents. It captures both what a change costs to produce and what it costs to trust. Up until recently, the cost to produce dominated so we optimized for it. It is no longer the case, so we must re-learn how to optimize for the cost of trust.

Code is free, trust is scarce.