Engineering Beyond Agile: When Decisions Move Upstream
Decisions, unlike code, are social. They carry intent, trade‑offs, and power.
In the first article, I wrote about how AI removes buffers. In the second, I explored what happens when those buffers disappear and the product role stretches under the weight of earlier decisions. This third is one most teams underestimate until it hurts.
Decisions move upstream.
Not because we suddenly became better planners. Not because we finally learned to “do Agile properly”. But because when execution becomes cheap, late decisions become socially and economically expensive.
Agile’s hidden dependency on time
Agile was never just a delivery framework. It was a way of distributing uncertainty over time.
We accepted that we wouldn’t know everything upfront. We relied on iterations, feedback loops, and incremental delivery to surface disagreements gradually. Misalignment could hide for a sprint or two. Architectural tension could be postponed. Trade‑offs could be discovered while code was already taking shape.
That worked because time absorbed conflict. AI doesn’t remove uncertainty. It removes the time we used to have to negotiate it.
When code can be generated, modified, and extended faster than humans can align, the system becomes hypersensitive. Every ambiguous requirement, every unstated constraint, every unresolved disagreement travels further, faster, before anyone notices.
This is why teams report feeling both faster and less confident at the same time. Output increases. Throughput improves. But trust erodes. What, potentially, quietly drops is psychological safety. When disagreement surfaces late and under pressure, it feels personal instead of structural. Speed doesn’t just change systems – it changes how safe it feels to disagree.
The problem is where disagreement goes when time disappears. Sit with that for a moment.
When execution accelerates, conflict concentrates
In traditional setups, many decisions were effectively diffused by process. Architecture evolved gradually. Product intent solidified over multiple iterations. Social tension was smoothened by meetings, reviews, and time between stages.
AI collapses that diffusion.
The moment an agent generates code, decisions are already being made: about structure, cost, security posture, user experience, and operational assumptions. These decisions may not be intentional, but they are real. And because the output often looks reasonable, they are easy to miss.
This is the uncomfortable shift: decisions didn’t just move upstream – conflict did too.
Disagreement that used to surface during implementation now appears earlier, when intent and constraints are still fluid. Someone has to absorb it. Someone has to resolve it. And increasingly, that “someone” is not a meeting or a ceremony, but an artifact making human judgement unavoidable.
From validating code to validating decisions
For years, we validated code. We reviewed pull requests. We tested behaviour. We inspected quality after implementation. That model assumed implementation was the expensive part. In AI‑accelerated systems, it isn’t. Execution is relatively cheap. Rework is not.
Validation has to move earlier. Not because we distrust AI, but because reasonable‑looking output can conceal unresolved decisions until they become incidents in production, security reviews, or cost overruns. The shift is fundamental: we are moving from validating code to validating decisions.
And decisions, unlike code, are social. They carry intent, trade‑offs, and power.
Why specifications re‑emerge – and why they can feel uncomfortable
This is where specifications come back into the conversation, often awkwardly. Not as documentation. Not as process. But as places where social agreement is forced to become explicit under speed.
In AI‑assisted workflows, the spec increasingly becomes the interface between human intent and machine execution. It is where ambiguity is either resolved or amplified. It is where disagreement is surfaced early enough to act on – or deferred at real cost.
This is why spec‑driven approaches resonate right now. They are not about predicting the future. They are about creating a negotiation space before code hardens decisions. What matters is not the format of the spec, but its function: to make intent, constraints, and trade‑offs visible while they are still reversible.
Meetings become inputs, not alignment mechanisms
Collaboration – meeting notes, transcripts, brainstorms – moves to the edge of the system. It becomes raw signal. Alignment no longer lives in the room; it lives in artifacts that survive speed.
This is deeply sociotechnical. But we need to talk about it.
It changes who has influence. It changes how disagreement is expressed. It changes what “alignment” actually means. When alignment lives in meetings, power flows to those who speak well and often. When alignment lives in artifacts, power flows to those who can clarify intent and constraints precisely.
That shift alone explains much of the discomfort teams feel when they try to adopt AI‑accelerated workflows without changing how decisions are captured.
Guardrails move upstream because trust must scale
The same logic applies to governance. When decisions move upstream, guardrails have to move upstream too. Otherwise they become symbolic – policy decks, late reviews, approval steps that cannot keep up with execution speed.
In fast systems, trust cannot rely on manual oversight. It has to be encoded.
This is where platform engineering quietly becomes a stabilising force. Not as a control mechanism, but as a way of absorbing routine decisions so humans can focus on the ones that actually require judgment.
Guardrails, in this sense, are not restrictions. They are delegated decisions. They represent agreement that has already been made and does not need to be renegotiated every time.
Where decisions actually move
Decisions move out of late reviews, emergency fixes, post‑incident discussions. They move into requirements and constraints, validation and planning, explicit trade‑off conversations before implementation begins.
Iteration doesn’t disappear. It relocates. Teams iterate on meaning before they iterate on code.
The human role in an upstream world
In the second article, I asked: when AI removes buffers, who carries the decision? This article adds the next layer: who decides where decisions live.
Humans still carry accountability. But they now also design the surfaces on which decisions are made, challenged, and enforced. They decide whether disagreement is discovered late or surfaced early. Whether intent is implicit or explicit. Whether speed amplifies confusion or coherence.
AI accelerates execution. Humans must shape the decision landscape that execution runs through. That is not a tooling problem. It is an operating‑model problem.
What changes in practice
If decisions are moving upstream, the most important change is not in tooling, but in attention. Teams that adapt don’t necessarily write more specifications. They change what they look for and when they refuse to move forward.
They start treating moments of ambiguity as signals, not inconveniences. When a requirement feels “almost clear,” they slow down – not to add ceremony, but to surface the decision that is about to be made implicitly. They stop asking whether something can be implemented, and start asking which assumptions will be locked in once it is.
They pay closer attention to where disagreement shows up. If conflict only appears during review or integration, it is already late. If it appears during specification or validation, it is still cheap.
And they become deliberate about which decisions are absorbed by platforms and which must remain human. Guardrails are not added to restrict teams, but to remove repetitive decision‑making so human judgment is available where it matters most.
This does require a shift in what teams consider “real work.” The work moves earlier, becomes less visible, and might feel less satisfying than shipping code. Yet this is exactly where speed becomes sustainable, and therefore we must build a system that strengthens a sense of purpose.
Why this matters
When decisions move upstream and are handled deliberately, execution becomes not just faster, but calmer. Reviews become less adversarial. Integration becomes less dramatic. Trust scales.
When they don’t, speed turns into noise. Everything looks “almost right” until it suddenly isn’t. Once decisions move upstream, the hardest questions are unavoidable: architectural trade‑offs. Security. Capacity. Cost. Not as late reviews. As early, explicit decisions that shape the system long before code is written.
That’s where we go next.




