"Trust is the real bottleneck in AI-assisted software development"

A recent essay in the "Conquering Entropy" series on the Pejibaye Blog makes a deceptively simple claim: most of the friction teams feel around AI-generated code is not a technical problem at all. It is a trust problem. The author walks through the chain of questions that now sits behind every merged change — do I trust the person who wrote the ticket, the engineer who guided the coding agent, the agent's implementation, the test suite, the CI/CD pipeline, the observability stack, the AI SRE on call, even GitHub's own uptime — and lands on a point that will resonate with anyone who has shipped code alongside an AI assistant in the last two years. The tooling works fine. What teams are actually wrestling with is deciding whose judgment they are willing to rely on.

That trust chain is worth examining link by link, because each one is a place where an AI-assisted workflow quietly adds a new hand-off. In a traditional pipeline, a human reads a ticket, writes the code, and asks a human reviewer to look it over. With an agent in the loop, the engineer's relationship to the code changes — they may not have typed the diff themselves, so their confidence now depends on how well they understood the ticket and how faithfully they steered the agent toward it. Every subsequent step, from the reviewer to the deploy pipeline, is now being asked to vouch for work that no single human fully wrote. The chain is only as strong as its weakest assumption.

One insight that sits just outside the essay's own framing is that trust behaves like a compound asset rather than a fixed one. On a high-trust team, each hand-off is cheap: an engineer can accept an agent's draft quickly, a reviewer can focus on the substance instead of re-deriving the whole diff, and an incident response is fast because people assume good faith. On a low-trust team, the same pipeline pays what you might call a "trust tax" — every step re-verifies the previous one from scratch, and the theoretical speed-up from the AI evaporates into review overhead. The productivity win from AI-assisted coding is not really about lines per hour; it is about whether the surrounding culture lets the team absorb the tool's output cheaply.

The essay's recommended remedy is directness: make it unambiguous that "you are accountable for what you ship," and that if a PR you authored breaks production, you should be the one there to fix it. That is a healthy principle, but it only works in one direction if it is paired with the right culture on the other side. Accountability without psychological safety becomes blame, and blame is exactly what kills the honest reporting that makes AI-assisted code safe to deploy. Google's Site Reliability Engineering handbook makes this case in its chapter on postmortem culture: the goal is to treat failure as a systems learning opportunity, not a personal failing. Accountability and blamelessness sound contradictory, but they are actually complementary — you hold people responsible for responding to a problem, while refusing to punish them for causing one.

There is a second, deeper shift happening here that the essay gestures at but does not fully name: when an agent writes the code, the engineer's job quietly migrates from author to editor and owner. That is a real change in what "writing code" means as a craft. The skills that matter are no longer primarily about producing a correct diff — the machine does that passably well — but about specifying intent clearly, reading a diff critically, and knowing what you do not know. Trust, in this new division of labor, is not automated away. It is relocated up the abstraction stack, from "did I type this correctly" to "do I actually understand what this change does and what could go wrong."

A useful way to think about trust is as the human equivalent of an interface boundary in software. You can compose with a module you trust without re-reading its internals every time; you can compose with a teammate — or a tool — the same way. This is part of why trust is a scaling mechanism. A team that has to independently verify every claim any member makes cannot grow much beyond a handful of people before communication costs overwhelm it; a team that can rely on its members' judgment can coordinate far more work with far fewer messages. Tools that generate code at scale raise the stakes on this, because they multiply the number of small decisions being made without central review.

It is important to be precise about what trust does and does not replace, because the essay's framing could be misread as "just trust your tools and ship." Trust does not eliminate verification — it lowers its cost. The test suite, the CI/CD pipeline, and the observability stack are not substitutes for human judgment; they are the shared infrastructure that lets a team extend trust without extending risk. The difference between a mature and an immature AI-assisted workflow is not whether anyone checks the agent's work, but whether the checks are proportionate, automated, and built into the pipeline rather than ad hoc and manual. Good trust infrastructure is what lets "accountable for what you ship" remain a real, safe statement instead of a scary one.

There is a well-established research thread behind all of this. The sociologist Ron Westrum's typology of organizational cultures — pathological, bureaucratic, and generative — has been adopted by the DevOps research community as one of the strongest predictors of software delivery performance. A generative culture, characterized by information flowing freely and blame being reserved for genuine bad faith rather than ordinary error, is exactly the kind of environment where AI-assisted development can be adopted without either over-trusting the machine or weaponizing accountability against the humans. Google Cloud's DevOps research team summarizes the Westrum model and its connection to delivery outcomes, and it is the closest thing the industry has to an evidence base for the essay's instincts.

The practical takeaway is refreshingly concrete. The biggest thing a team can do to get value out of AI-generated code is not to buy a better model or a fancier agent framework — it is to invest in the trust fabric around it: clear ownership, fast feedback loops, honest postmortems, and pipelines that catch regressions before a human ever has to. The essay's core move, framing the whole problem as a matter of cultivating trust rather than optimizing tooling, is the kind of reorientation that sounds obvious in hindsight and is still rarely what teams actually optimize for.

That is the underlying irony worth sitting with: in an era of increasingly capable coding agents, the scarce resource has stopped being code production and become confidence. Models will keep getting better at writing code, but confidence is not something a model can generate for you — it has to be built, deliberately, inside a team, one accountable and blameless incident at a time. The teams that understand this will move faster with AI not because they trust it more, but because they have built an environment where trusting the right people, and checking the right things, is cheap.

Further reading:

• "Cultivating Trust", from the Conquering Entropy series on the Pejibaye Blog — the essay this post is built around.
• Postmortem Culture: Learning from Failure, a chapter from Google's Site Reliability Engineering book on blameless incident analysis.
• Westrum organizational culture, Google Cloud's summary of the culture model that underpins modern DevOps research.