Decisions Without Consequences
We automated the DevOps handoff without fixing the accountability behind it. AI is now separating construction from understanding at exactly the wrong moment.
There is a structural problem inside many modern engineering organizations, and it is not hard to see once you stop looking at the org chart and follow the work. Product decides what the business needs and how quickly it needs it, Architecture defines patterns and constraints around how it will be built, and Engineering turns those decisions into a working system. Once that system reaches production, the center of gravity shifts toward Platform, Site Reliability Engineering (SRE), and Operations, where reliability, incident response, operational cost, production behavior, and the ugly cross-layer failures begin to accumulate. The consequence and the accountability often land with the people who had the least authority over the upstream decisions that created them.
None of those boundaries is inherently wrong. Specialization is necessary, and I have spent much of my career building the abstractions that make it possible. The problem is what happens when the boundary between specialties also becomes a boundary around consequence. We have built an operating model where the right to decide can live in one place, the work of construction in another, and the obligation to explain and repair the result somewhere else entirely.
AI makes this worse, not because it suddenly makes decision-making mysterious. We usually know who decided and who built it. The new problem is that nobody may fully understand what was built, while Platform, SRE, and Operations still inherit the consequence and are still expected to answer for it.
The Chain We Actually Built
A recent Severity 1 (SEV-1) incident made the older version of this problem painfully concrete. The platform was down, and SRE and Operations were already engaged, tracing dependencies, reading telemetry, checking infrastructure, and trying to determine whether we were looking at a platform failure, an application failure, or one of those incidents where several layers are interacting badly enough that the distinction stops helping.
Eventually we reached logs from one of the affected services. We could read them, but we could not reliably interpret what they meant inside the application’s own logic. That is not unusual. Operations should not be expected to carry the internal mental model of every application running on a platform, any more than an application engineer should be expected to diagnose every network or storage failure underneath it.
We asked the service owners to join the incident, and the response was effectively that this was an operations problem and they could not help. I do not expect application developers to become infrastructure engineers because their service runs in production. I do expect someone who owns a service to be able to help explain that service when its behavior becomes part of a critical incident. Ownership that only exists while the backlog is moving is not enough to operate a real production system.
What stayed with me was not the refusal by itself. It was the organizational logic behind it. The service belonged to Engineering while it was being built, changed, and released. Once it failed in production, the consequence crossed a boundary and became an Operations problem. Platform and SRE were still expected to restore the system, explain what happened, and answer for the incident, even though they had not made the application decisions and did not hold the application context needed to interpret them.
Accountability starts to deform at that boundary. The group closest to the failure becomes accountable because it is the group present when the failure becomes visible. The upstream decision remains upstream. The architecture decision remains an architecture decision, the product tradeoff remains a product tradeoff, and the implementation becomes yesterday’s completed work. Production is left holding the result.
The Wall We Automated
One of the important promises of DevOps was that development and operations could no longer behave like separate worlds. The old model made the handoff obvious. Development wrote software, Operations received it, and each side could point through the wall when something went wrong. Development could say the software had been deployed incorrectly. Operations could say Development had produced something that could not be operated reliably.
The deeper problem was not the finger-pointing. It was that the wall interrupted feedback. Developers could make design and implementation choices without living very close to their production consequences. Operations could become expert in those consequences without having the context or authority required to change the application decisions creating them. Each side saw a different truth about the same system, and the organization treated the gap between those truths as normal.
We improved a great deal of that. Builds and deployments became automated, infrastructure became code, environments became more reproducible, and telemetry moved closer to development. Platform engineering carried the work further with self-service systems, paved roads, standardized tooling, and abstractions that let developers move quickly without understanding every layer below them. That is useful engineering because a good platform reduces cognitive load instead of forcing every specialist to carry the entire stack in their head.
But we solved the mechanics of the handoff more successfully than we solved the accountability behind it. The wall did not disappear everywhere. In many organizations, we automated it. The transfer became cleaner and faster, while the consequence still moved downstream to the teams expected to keep production alive.
You can see it in ordinary work. Product forces a deadline and reliability work falls out of scope. Months later, SRE owns the instability. Architecture requires a pattern that looks clean at design time but creates difficult production behavior, and Platform owns the operational complexity. Engineering chooses a dependency that later becomes a recurring security or reliability problem, and another team inherits the remediation. A service meets the logging standard but produces telemetry that only its developers can understand, and Operations reverse engineers the application during an outage.
None of this requires a villain. Engineering decisions age as scale changes, dependencies degrade, threat models move, and the systems around them evolve. A choice that was perfectly reasonable three years ago can become today’s operational liability without anyone having made a foolish decision at the time. The real failure is allowing the people who made the choice to become detached from what it eventually costs.
Competent operational teams make that separation easy to hide. SRE follows problems across layers, Platform engineers build another abstraction, and Operations writes another runbook. The senior engineer who understands several parts of the stack becomes the person everyone calls when a problem falls between ownership boundaries. The system keeps working because those people absorb what the formal model failed to carry, which makes the formal model look healthier than it is.
From above, that can look like a healthy organization. Incidents close, service levels recover, and roadmap work continues. What is much harder to see is how much of that apparent health depends on a relatively small number of people preventing consequence from traveling back toward the decision that created it. Their competence becomes a buffer between leadership and the cost of the operating model.
AI and the Missing Understanding
AI does not create this accountability problem. It removes one of the remaining constraints that used to keep parts of the chain connected. Historically, building software imposed a cognitive cost. Engineers had to fight with APIs, debug strange behavior, understand dependencies well enough to make them work, and accumulate a mental model of the system through the friction of building it. That process never guaranteed deep understanding, but it made total ignorance difficult to hide for long.
AI lowers that friction dramatically. An engineer can produce working code, tests, documentation, deployment configuration, refactors, and design explanations with far less direct contact with the reasoning that once had to be worked through by hand. I use AI heavily myself, so this is not an argument for ritual purity or typing every line manually. The question is whether the speed gain preserves enough human judgment to understand and operate the result.
Sometimes it does. An engineer can use a model to explore several approaches, reject weak ones, make the tradeoff, adapt the implementation to known constraints, and still understand why the system has the shape it has. In that case AI accelerated the work without displacing the judgment.
The harder case is increasingly plausible. Product or Architecture decides what needs to exist. Engineering uses AI to turn that requirement into a working implementation. The code is clean, the tests pass, the design document looks complete, the pull request is reviewed, and the service ships. Every artifact says the system is healthy enough to move forward, but none of those artifacts proves that a human being formed and retained a coherent model of how the pieces fit together.
Illegibility enters the argument here. In The Illegibility Crisis, I use the term for the gap between what our instruments show and the real distribution of understanding, judgment, and knowledge inside the organization. AI makes polished output cheaper, so the old signals become less trustworthy. Code, tests, diagrams, design documents, and even incident writeups can look better while telling us less about who actually understands the system.
Now return to the incident bridge. This time the service owner joins immediately and wants to help. Operations asks why the service uses a particular retry strategy, why a cache has a certain eviction rule, what failure an unusual branch was intended to contain, or why a concurrency limit was set where it was. The engineer can describe what the code does. What they cannot explain is why the decision was made, what alternatives were considered, or what assumption the choice depended on.
Maybe the reasoning happened across a series of prompts nobody retained. Maybe the model proposed an implementation and the engineer validated that it worked without ever constructing the whole mental model. Maybe each incremental change looked sensible and the final architecture emerged without any one person ever designing the thing that now exists. The artifact survived every step of that process. The understanding did not necessarily survive with it.
I do not mean Decision Fog in the simple sense that nobody knows who clicked Approve. We may know exactly who made the product decision, who approved the architecture, and who merged the code. The deeper break is that decision authority, construction, understanding, consequence, and accountability have become separable. Product and Architecture decide, Engineering builds, nobody necessarily understands the whole result, and Platform, SRE, and Operations still carry the production consequence and are still expected to answer for it.
The result is uglier than the old DevOps wall because at least the old wall usually had knowledgeable humans standing on both sides of it. Now the handoff can be automated, the implementation can be AI-assisted, the artifacts can look excellent, and the people receiving the production system may discover under pressure that there is no complete human model to hand back to.
Accountability Has to Run Backward
The obvious bad response is to push all accountability onto Engineering and call the problem solved. That just moves the asymmetry again. Engineering should remain accountable for engineering decisions, including service behavior it controls, but Product, Architecture, Platform, Security, and leadership also make consequential decisions. If accountability only runs downward until it reaches the person who committed the code, the organization has built blame into the hierarchy and called it ownership.
If Product forced a deadline that displaced reliability work, that tradeoff belongs in the incident story when the deferred work comes due. If Architecture mandated a pattern that creates recurring operational complexity, Architecture remains connected to that consequence. If Platform provided the only approved implementation path, Platform owns the limits of that path. If leadership held reliability expectations constant while reducing staffing or investment, the resulting strain is not an execution mystery several levels below them.
The same standard applies to Platform, SRE, and Operations. They should be accountable for the decisions they actually control. A bad failover design is an infrastructure problem. Weak incident command is an operational problem. Poor platform abstractions are a platform problem. What those teams should not become is the permanent accountability sink for every upstream decision that happens to manifest in production.
Consequence contains information, which is why this distinction matters. When the people with authority never experience what their choices create, their future decisions are made against incomplete feedback. Product learns that another feature can fit because someone always finds a way to stabilize the system. Architecture learns that the pattern works because the operational pain never returns to the design table. Leadership learns that staffing is sufficient because the strongest operators keep compensating for the gap.
The people downstream learn something too. They learn that ownership means being present when something breaks, not having authority over the conditions that made it break. They learn that competence earns more consequence. They learn that if they can fix a problem, the organization will quietly make the problem theirs.
Over time, that arrangement is corrosive. It explains why Platform and SRE organizations can become exhausted while the rest of engineering still believes the operating model is functioning. In a narrow sense it is functioning, but it is doing so by concentrating unowned consequence in the teams least able to refuse it.
Repair requires the feedback to travel backward through the chain. Product has to see the operational cost of product tradeoffs. Architecture has to see the runtime behavior of architectural decisions. Engineering has to stay close enough to production to understand what its implementation actually does. Platform and SRE need enough authority to reject recurring failure patterns instead of endlessly absorbing them. Leadership has to own the capacity, risk, and priority choices that shape all of the above.
AI adds one more obligation to that repair because somebody has to understand the system. That does not mean one heroic person memorizes every line, every dependency, and the entire stack. It means a production service that matters has enough human understanding distributed across the people responsible for it that the organization can explain how it behaves, why consequential choices were made, and what can safely be changed when reality stops matching the plan.
Stewardship
Technology organizations use the word ownership constantly, but much of the time we mean assignment. A repository belongs to a team. A service catalog names an owner. A responsibility matrix says who is accountable. Those are useful administrative facts, but they do not tell me who will still be there when the system becomes inconvenient.
Stewardship is a better test because it keeps the consequence attached to the obligation. A steward does not have to write every line of code, operate every infrastructure layer, or reject AI assistance. A steward does have to remain in relationship with what their decisions produce. That means seeing the cost, participating in repair, learning from production, and refusing to treat another team’s competence as a place to dump consequences.
For Engineering, stewardship means service ownership does not stop at deployment. For Product, it means the reliability cost of a priority decision remains part of the decision. For Architecture, it means patterns are judged in operation, not only in review. For Platform and SRE, it means owning the reliability and platform decisions they actually control while pushing application, product, and architectural consequences back toward their source. For leadership, it means the operating model itself is a decision with a cost.
AI makes stewardship more important because authorship is becoming a weaker proxy for understanding. The person who merged the code may not be the person who formed the reasoning. The design document may describe a rationale that was reconstructed after the fact. The service may be well tested and still have no human who can explain its real failure modes without asking a tool to infer them from the artifact. If the organization does not deliberately preserve understanding, it can retain all the paperwork of ownership while losing the thing ownership was supposed to mean.
The connection I think we have missed is between all three changes. DevOps tried to close the gap between building software and living with it, while Platform engineering made the technical path between those worlds cleaner. AI is making production faster still, but it is also making it easier to separate construction from understanding at the same moment many organizations have already separated decision authority from consequence and accountability.
The answer is not to reverse any of that technology. I do not want the old wall back, and I do not want engineers doing work manually just to prove they suffered enough to understand it. I want the operating model to stop pretending that consequence is ownership and start reconnecting the people who decide with what their decisions cost, the people who build with how what they built behaves, and the people who operate with enough authority to push recurring problems back toward their source instead of inheriting them forever. Somewhere in that chain, enough human understanding also has to survive that when the system fails, we are not reconstructing our own decisions from artifacts while the pager is going off.
I would draw the line here. If Product and Architecture decide, Engineering builds, and Platform, SRE, and Operations carry the consequence, then accountability cannot simply stop where the consequence lands. It has to travel back through the chain to the people who had authority over the choices that produced it. AI does not change that rule. It makes enforcing it more urgent because now we can build systems faster than we build the human understanding required to carry them.
Until those lines cross on purpose, we have not solved the old DevOps problem. We have made the handoff faster, moved more of the reasoning into tools, and left the same people holding the consequences when reality finally collects the bill.
Artifacts are cheap, judgement is scarce.
Per ignem, veritas.