Rigour is Velocity: The New Engineering Mandate
Why AI scales ambiguity, why Scrum's feedback loops are failing, and how 'Intent Fidelity' becomes the only metric that matters.
The software industry is currently misdiagnosing its productivity problem. We are celebrating a massive acceleration in coding output while ignoring a compounding crisis in systemic reliability.
AI tools have successfully commoditised syntax. Implementation (the act of translating logic into code) is no longer the primary constraint. However, empirical data reveals a disturbing trend. While implementation speeds have increased by up to 55% (Kalliamvakou, 2024), code churn (the frequent rewriting of recently committed code) is rising significantly (GitClear, 2024). This serves as a leading indicator of rework, particularly in projects where specification is weak.
The reason is structural: Ambiguity no longer gets "smoothed out" by human interpretation; it gets scaled by AI.
A vague requirement like "optimise the trade execution flow" used to be a conversation starter. Today, it is a prompt. The Large Language Model (LLM) will happily generate a statistically probable solution that may violate compliance rules, break idempotency, or introduce subtle data leaks.
This is not a coding problem. It is an intent fidelity crisis.
Intent fidelity is the degree to which implemented behaviour matches the original, constrained intent of the system owner.
The Scaling Law of AI Ambiguity
A vague requirement is no longer a conversation starter; it is a prompt for hallucination. In a human team, ambiguity is queried. In an AI workflow, ambiguity is implemented.
The Core Insight: Rigour is Velocity
For the last decade, "Velocity" was synonymous with "Shipping Speed." In the AI era, this definition is dangerous. True speed is Value Delivered ÷ (Rework + Risk Exposure).
Teams that invest upfront in executable specs, lightweight Architecture Decision Records (ADRs), and Test-Driven Development (TDD) are finding that Rigour is not overhead: it is the only way to maintain velocity.
| Metric | Low-Rigour AI Team | Rigour-First AI Team |
|---|---|---|
| Time-to-Production | Faster (-20%) | Slightly Slower (+5-10%) |
| Rework Rate | High (35-60%) | Low (<15%) |
| Failure Mode | Silent drift, compliance gaps | Failures caught pre-commit |
| 6-Mo Feature Retention | < 50% | > 85% |
Defining Rigour: Rigour is not about heavy documentation. It is the degree to which system behaviour is Predictable, Auditable and Reversible.
Why Scrum Fails the AI Test
We often blame "sprint cadence" for burnout, but the issue is deeper. It is about the structure of our knowledge.
Scrum assumes that failure is cheap and feedback is fast. It was designed for exploratory work where you build, deploy, measure and fix.
- Pre-AI: Defects were often caught in peer review or local testing and fixed within hours.
- With AI: The LLM generates a complex, "technically correct" implementation that may contain subtle, high-consequence logic errors that are not detected until months later.
In AI-augmented development, feedback is delayed and failure is expensive (Majors, 2025).
We need to segregate our workflows. Exploratory UI work can remain iterative. However, core system logic requires a deterministic workflow: one where the spec is an executable contract before the first line of syntax is generated.
The New Mandate: Upstream Stewardship
This shift in physics demands a shift in leadership. The engineering manager (EM) can no longer simply be a "delivery unblocker."
Delivery management (sprint planning, burndown tracking) is becoming commoditised by AI agents. The non-automatable value of an EM is now context architecture, managing how the team defines and uses AI (Larson, 2025).
1. From "Sprint Velocity" to "Spec Validation"
The EM must move upstream. The primary deliverable is no longer the ticket; it is the Context. The EM must ensure that no prompt is written until the intent is clear, the constraints (compliance, security) are defined and the consequences of failure are understood.
2. Technical EMs vs. Delivery Leads
We must acknowledge that engineering manager is becoming two distinct roles:
- Delivery Leads: Focus on timelines, budget and stakeholder comms.
- Context Architects (Technical EMs): Focus on the integrity of the system intent.
While ideal as distinct roles, in constrained teams the same EM must time-box between delivery coordination and intent stewardship, explicitly signalling which hat they are wearing. Organisations that fail to specialise (or time-box) these roles will burn out their leaders.
3. Escalation Fluency over "Universal Judgment"
We often say, "We need Juniors to have better judgment." This is unrealistic. Judgment comes from scar tissue: from experiencing failure. A Junior engineer hasn't failed enough to know that a specific auth pattern is risky.
Instead of expecting universal judgment, we must train for escalation fluency.
- The Goal: Train engineers to identify uncertainty, not just solve problems.
- The Skill: "I don't know if this generated code handles the edge case of a leap year. I need to escalate this for review."
- The Outcome: we replace false confidence with explicit verification.
The Execution Risk: Why Culture is Not Enough
It is naive to assume that engineering teams will voluntarily "slow down" for safety. History shows that in the absence of constraints, local incentives (shipping fast) always dominate global incentives (system stability) (GitHub, 2024).
Rigour cannot just be a cultural value; it must be an enforcement mechanism.
We cannot rely on manual code review alone. We need automated rigour pipelines within our Continuous Integration and Continuous Deployment (CI/CD) workflows:
- Spec Linters: Tools that reject ambiguous requirement tickets before work begins.
- ADR Traceability: Pipelines that fail if a major architectural change lacks a linked decision record.
- Compliance-as-Code: CI gates that strictly enforce regulatory constraints on generated logic.
Pragmatism in Practice: Rigour at Every Scale
This isn’t an all-or-nothing mandate. An "executable spec" can be as simple as a contract test or a set of OpenAPI constraints, not a 50-page document. Rigour scales with context:
- In a regulated core system? Enforce executable specs, ADRs and CI gates; these are non-negotiable.
- In a lean startup? Start with one rule: “No AI prompt without a one-sentence constraint.” (e.g., “Must not log Personally Identifiable Information (PII).”)
- In a team with no dedicated EM? Rotate “context duty” weekly: one engineer owns clarifying intent and constraints before any prompt is written.
The goal isn’t perfection; it’s making ambiguity explicit. Even a 30-second conversation that surfaces a constraint (“Wait, does this touch user data?”) breaks the hallucination pipeline.
Rigour isn’t overhead. It’s the tax you pay to avoid compounding interest on AI debt.
Conclusion: Minimum Viable Safety
The cost of ignoring this shift is not just technical debt: it is technical insolvency. This is the point where the cost of fixing AI-generated mistakes exceeds the value of the software itself. AI debt (prompt rot, unversioned RAG contexts and hallucinated logic) is harder to refactor than legacy human code because it lacks human reasoning history.
The question for leadership is no longer "How fast can we move?" but "How much risk are we unknowingly absorbing?"
"If you wouldn’t let an intern deploy code without a PR review, why would you let an LLM deploy logic without a spec review?"
The mandate for the coming year is clear: We must stop optimising for the speed of writing code and start optimising for the fidelity of understanding it. The leaders who survive this transition will be the ones who realise that in a world of infinite generation, clarity is the only scarce and non-renewable resource.
References
GitClear. (2024, January 16). Coding on Copilot: 2024 Data Suggests Downward Pressure on Code Quality. GitClear. https://www.gitclear.com/coding_on_copilot_data_shows_ais_downward_pressure_on_code_quality
Kalliamvakou, E. (2024, May 21). Research: Quantifying GitHub Copilot’s impact on developer productivity and happiness. GitHub. https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/
Larson, W. (2025). Crafting Engineering Strategy: How Thoughtful Decisions Solve Complex Problems. O'Reilly Media.
Majors, C. (2024, January 25). It’s Time to Version Observability: Introducing Observability 2.0. Honeycomb.io. https://www.honeycomb.io/blog/time-to-version-observability-signs-point-to-yes
Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press.