Rigor-Relocation

Rigor Relocation is the principle that major paradigm shifts in software development do not eliminate discipline — they relocate it from familiar forms to less visible ones, closer to operational truth.

The Historical Pattern

The pattern has repeated consistently across software history:

• Dynamic languages: Removed compile-time type guarantees; relocated rigor to runtime test-enforced correctness. Teams that succeeded “doubled down on executable specifications: tests that described behavior precisely enough to function as a de facto type system”
• Extreme Programming: Replaced phase-gate planning with test-first development, continuous integration, and constant peer review — discipline that “didn’t look like the discipline people were used to seeing” but was far less forgiving
• Continuous Deployment: Eliminated release windows and stabilization phases; demanded observability, automated verification, fast rollback paths, and reversibility instead
• Generative AI: Moves rigor from “who writes the code” to “what the code must satisfy” — from implementation authoring to specification precision and evaluation strictness

The Probabilistic Inside, Deterministic at the Edges Model

AI-assisted development is “probabilistic inside, deterministic at the edges.” The LLM generates implementations probabilistically, but the boundaries — tests, specifications, evaluation systems — must be deterministic. This mirrors how dynamic languages use runtime checks to enforce correctness that static compilers once provided at compile time.

The Quiet Failure Risk

The most dangerous failure mode is not obvious errors — it is quiet failure: producing systems that work without ever knowing why they work. When code is accepted because it runs rather than because it is understood, rigor has not relocated — it has been lost entirely.

Lost vs. Found Rigor Framework

A diagnostic for AI-assisted development:

Lost rigor (warning signs):

• Removing hand-written code without adding explicit invariants
• Accepting generated implementations without rigorous evaluation
• Mistaking velocity for progress

Found rigor (healthy indicators):

• Precise intent specification — deliberately harder than writing code
• Rigid evaluation systems and behavioral tests
• Visibility of failures against stated intent
• Specification precedes implementation

Why This Matters

Rigor Relocation explains why Spec-Driven-Development and Regenerative-Software are not shortcuts but disciplined practices. Engineering effort does not decrease — it moves from typing to specifying. The engineer’s role shifts from code author to specification architect: defining what must be true, then verifying it.

Recognizing relocation prevents the cognitive error of confusing apparent simplicity with actual simplicity. Every major software abstraction has followed this pattern. When rigor feels absent, ask: where did it go?

Related Concepts

• Spec-Driven-Development
• Regenerative-Software
• Feedback-Loops-in-Systems
• Architecture-Fitness-Function
• Back-Pressure-Mechanisms
• Iterative-Signal-Loop

Sources

• Anonymous (2026). “Relocating Rigor.” aicoding.leaflet.pub. Retrieved March 2026.

  • Primary articulation of the pattern: “probabilistic inside, deterministic at the edges”; quiet failure; lost vs. found rigor framework; historical review across dynamic languages, XP, CI/CD, and generative AI
  • Available: https://aicoding.leaflet.pub/3mbrvhyye4k2e

• Böckeler, Birgitta (2025). “Harness Engineering.” martinfowler.com.

  • Rigor relocates to pre-generation discipline: architectural constraints, custom linters, structural tests; engineers shift to specification architects
  • Available: https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html

• Kiro Team (2025). “Property-Based Testing and the Importance of Specification.” kiro.dev.

  • Specifications as executable constraints; discipline shifts from manual example selection to property definition and systematic input generation
  • Available: https://kiro.dev/blog/property-based-testing/

• Beck, Kent (2000). Extreme Programming Explained: Embrace Change. Addison-Wesley. ISBN: 978-0-201-61641-5.

  • XP as canonical rigor relocation: test-first development and continuous integration replacing phase-gate planning; discipline intensified but in new forms

• Humble, Jez and David Farley (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley. ISBN: 978-0-321-60191-9.

  • CI/CD as rigor relocation: observability, automated verification, and fast rollback replacing stabilization phases and release windows

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.