If leaders want AI speed, they must share the production risk

A recent post on X from an engineer named v0xium took the social media by storm. He described an organisation where AI generated much of the specifications, code, tests, tickets, and reports surrounding software delivery. His deeper complaint was organisational. People were pushed to ship faster without enough time to understand the work, while engineers still carried responsibility when it failed.

Being an engineering leader running a fast paced AI powered engineering team , this problem struck close to home. That concern is legitimate. But it also describes only one side of a difficult transition. AI is changing the economics of software production quickly, and leadership cannot wait for the industry to discover a perfect operating model. So today the useful question is how can a company take larger bets without making engineers the sole owners of the resulting risk.

Both sides are responding to real responsibilities

An engineer who reviews a change has to imagine what happens when it reaches production. Does the generated test check the business outcome? Can we roll the change back? Will an incident wake the same team at 2 a.m.? If the system fails, the organisation will expect engineers to diagnose it and restore service. Asking for stronger quality controls is a rational response to that accountability.

Leadership has a different responsibility. A founder or CTO has to decide which changes could materially improve the business, how quickly the company must learn, and which risks are worth taking. Incremental improvements may keep an existing system healthy while a competitor discovers a much more efficient way to operate. Refusing every uncertain experiment can therefore be as consequential as shipping an unsafe one.

The tension becomes sharper because AI increases the amount of work a team can start. DORA's 2025 research on AI-assisted software development reported a positive relationship between AI adoption and delivery throughput, alongside a negative relationship with delivery stability. The report's broader conclusion is useful here: AI amplifies the system of work around it. Faster generation exposes weak testing, unclear ownership, slow feedback, and fragile architecture sooner.

Neither side can solve that by winning an argument about whether AI is good or bad. They need an agreement about how risk will be taken and who will carry it.

Speed without shared risk creates defensive behaviour

Suppose leadership asks a team to use an agent to change how invoices are matched to payments. The experiment could reduce manual work across finance and support. It could also attach a payment to the wrong invoice, create misleading account balances, or require a difficult correction later.

If the instruction is simply to move faster, the incentives diverge. Management receives the potential business gain. Engineers inherit the production failure, investigation, and repair. The safest personal response for an engineer is to slow the change down or resist it entirely.

The opposite arrangement also fails. If engineers can reject every experiment until uncertainty disappears, leadership remains accountable for growth without the ability to explore a new operating model. The company protects the current system at the cost of learning what could replace it.

Shared accountability changes the conversation. Leadership still decides that the experiment is worth attempting. Engineering still defines what is technically safe enough to attempt. Both sides agree on the boundaries, observe the outcome, and own the consequences.

Make the experiment reversible before making it fast

For the invoice-matching example, the first decision should not be whether the agent is accurate enough to run everywhere. The first decision should be how to learn without creating an uncontrolled failure.

The team could begin with historical records, then run the agent in shadow mode on live work without allowing it to update an invoice. Once its errors are understood, a limited/canary rollout could permit changes for one low-risk class of transactions. A feature flag or workflow switch should provide a tested path back to the previous process. High-value or ambiguous matches could remain subject to human review.

These controls do more than reduce technical risk. They make the leadership decision explicit. Everyone can see which failure modes the company accepted, which it refused, and what evidence is required before expanding the rollout.

A useful operating agreement would answer several connected questions:

• What customer or business outcome justifies the experiment?
• Which records, tenants, or workflows are inside its initial boundary?
• What must remain unchanged even if the agent makes a mistake?
• Which signals cause the rollout to pause or reverse?
• Who has the authority to stop it, and who owns the recovery?

The answers should be recorded before the rollout. A short decision record is enough if it captures the assumption, risk boundary, evidence, owner, and review date. The goal is not process for its own sake. It prevents the organisation from rewriting the original decision after seeing the result.

Reliability has to be a leadership constraint

Operational reliability cannot remain an engineering concern that leadership supports only after an incident. It has to constrain how the company takes bets.

Google's example error-budget policy shows one way to make this trade-off explicit. When a service remains within its reliability objective, releases proceed. When it exceeds the agreed budget, reliability work takes priority. The policy is not framed as punishment. It gives the organisation a shared rule for deciding when further change is acceptable.

An AI-first team can apply the same principle without copying the policy literally. Leadership can ask for rapid experiments while accepting limits on blast radius, rollout pace, and accumulated operational risk. Engineers can support larger bets while accepting that zero risk is not the goal. The boundary is agreed in advance and adjusted using production evidence.

Observability is part of that agreement. Technical metrics such as errors, latency, and failed jobs matter. The business outcome matters too. An agent that produces no exceptions while silently increasing invoice corrections has not succeeded. A dashboard should make both dimensions visible to the people who authorised the experiment.

Incident ownership must follow decision authority as well. Engineers will lead diagnosis because they understand the system. Product and business leaders should remain present for customer impact, operational trade-offs, and follow-up priority. When leadership participates in the consequences, reliability becomes a company decision rather than a burden delegated to the on-call team.

Trust requires permission to stop and permission to fail

Transparency cannot mean announcing a decision after it has already been made. Engineers need enough context to understand why the company is taking the risk and enough authority to stop a rollout when the agreed boundary is crossed. Leaders need honest technical judgement, including uncertainty, rather than a demand for guarantees that software teams cannot provide.

The same trust must run in the other direction. Founders and managers need room to test ideas that may fail. Engineers can help make those failures contained, observable, and informative instead of treating every unsuccessful experiment as evidence that it should never have been attempted.

This transition will be messy because nobody has a settled answer for how AI changes software delivery. Every side will make poor calls. The way through is to expose assumptions, define reversible boundaries, share the operational consequences, and turn each result into the next decision.

Engineers should not carry an AI strategy's production risk alone. Leadership should not carry the responsibility for transformation without room to experiment. A team can move quickly when both sides are willing to be transparent about what they do not know, vulnerable about mistakes, and accountable for what happens next.