The Discipline of Intent (Synthesis: Nicieja, Guo, Relocating Rigor)

“Certain shifts in software history feel like freedom because they remove familiar signals of control,” the author of “Relocating Rigor” writes. “In reality, they relocate rigor closer to where truth lives.” This is the master pattern that unites all three texts. Nicieja’s Specification by Example relocated rigor from upfront design documents into continuously-verified executable specifications. Guo’s analysis of AI-assisted development relocates rigor from hand-written code into explicit intent and evaluation. In every case, the removal of a familiar constraint — phase gates, static types, human-authored code — is mistaken for the removal of discipline itself. But discipline doesn’t vanish; it moves to where it can do more work. The pattern recurs because software engineering perpetually discovers that its bottlenecks are not where it thinks they are. Each relocation strips away a layer of ceremony to expose the harder, more consequential work underneath. The question is never whether rigor exists but where it has chosen to live — and whether you have followed it there.

#1 The Relocation Thesis: Rigor Never Disappears, It Migrates [Principle]

Ref. 7ADA-A

Guo observes that “as software becomes abundant, the ability to make intent clear becomes scarce. Everything that follows is a consequence of that shift.” Nicieja, writing years earlier, identified the same bottleneck in different terms: “The one and only reason teams need specifications is information asymmetry.” Both authors converge on a single claim: the hardest problem in software has never been writing code. It has always been knowing what to write — and communicating that knowledge across the gap between people who understand the domain and people who understand the machine. The IBM and Bell Labs study Nicieja cites — that 80% of defects originate at requirements definition — is not a historical curiosity but a permanent structural feature of software development. AI doesn’t dissolve this bottleneck; it makes it the only bottleneck that matters. When code is cheap, intent is everything. When execution is abundant, specification is scarce.

#2 The Intent Bottleneck: Software’s Permanent Scarcity [Principle]

Ref. C629-B

“XP compressed feedback loops until truth became unavoidable,” the “Relocating Rigor” essay declares. “Tests replaced promises. Continuous integration replaced status reports. Working software replaced narrative.” Nicieja’s living documentation operates on the same principle: “When tests keep specifications in check, they let specifications with examples evolve into a documentation system” that “changes along with the system it documents, thanks to the link between the text and the code as well as frequent validation.” Both describe systems designed to make lying expensive and truth automatic. The feedback loop is the fundamental technology of relocated rigor — not because it prevents mistakes, but because it makes mistakes visible before they compound. Guo extends this into the AI era: “If generation gets easier, judgment must get stricter.” The throughline is clear: every advance in software productivity demands a proportional advance in the mechanisms that report whether the productive output is actually correct. Velocity without verification is not progress; it is accelerated drift.

#3 The Honesty Machine: How Feedback Loops Enforce Truth [Principle]

Ref. 6AF8-C

The “Relocating Rigor” essay mourns that Extreme Programming “got absorbed into the broader ‘Agile’ movement and solidified into branding and ceremony. When the name took over, the rigor drained out. The feedback softened. The theater returned.” Nicieja catalogs the specification-world equivalent: speci-fiction, which “poses as a single source of truth but can’t be one because nobody cares to update them,” and over-specification, which paralyzes teams with analysis rather than enabling them with clarity. Guo identifies the AI-era version: “Cheap generation without strict judgment isn’t a new paradigm. It’s abdication.” All three authors are diagnosing the same disease: organizations consistently prefer the appearance of rigor over its substance, because appearance is comfortable and substance is demanding. Ceremonies feel like control. Feedback loops feel like exposure. The recurring tragedy of software methodology is that every genuinely rigorous practice eventually gets diluted into the very theater it was designed to replace.

#4 The Ceremony Trap: When Process Replaces Truth [Pattern]

Ref. 9E40-D

Nicieja opens his book with a confession that resonates across all three texts: “As programmers, we’re taught to write code — algorithms, design patterns, abstractions. But when we get our entry-level jobs, our employers expect us to ‘deliver value to our clients.’” The gap between knowing how to code and knowing how to translate a domain into code is the foundational problem. Guo frames the same gap economically: “Most of the intent that matters in real systems is deeply technical: accumulated context, system knowledge, and judgment about tradeoffs.” The “Relocating Rigor” essay frames it historically: each era of software development finds a new way to pretend this gap doesn’t exist, and each era’s most rigorous practitioners find a new way to bridge it. The bridge, Nicieja argues, “can only be built with empathy — understanding other people’s problems — and inclusive communication.” In a world of AI-generated code, this bridge becomes the entire job. The two worlds still exist. Only the crossing has changed.

#5 The Two-World Problem: Translation as Engineering’s Core Challenge [Wisdom]

Ref. 4D8C-E

Guo identifies a failure mode that Nicieja’s methodology was designed to prevent: “Unacceptable code runs, passes tests, and looks reasonable, but violates the system’s implicit contract.” This is the gap between correctness — does it work? — and acceptability — would I want to own it? Nicieja addresses this by insisting that specifications be written in business-readable language, from the user’s perspective, using real-world data. His Anti-SQL Principle warns against specifications that are technically precise but communicatively opaque. The “Relocating Rigor” essay describes the same gap in terms of “invisible invariants: assumptions about idempotency, ordering, failure semantics, data integrity, or legacy coupling that were never written down because they were learned through experience.” All three texts agree: the most dangerous failures are not bugs but misalignments — code that does what you asked for but not what you needed. Closing this gap requires not better testing but better specification — making implicit contracts explicit before implementation begins.

#6 The Correctness-Acceptability Gap: Why Passing Tests Is Not Enough [Revelation]

Ref. DFAF-F

Nicieja’s architecture of executable specifications — a specification layer for human-readable intent and an automation layer for machine-executable verification — maps precisely onto the pattern the “Relocating Rigor” essay calls “probabilistic inside, deterministic at the edges.” The specification layer is the deterministic edge: precise, stable, business-readable assertions about what must be true. The automation layer is the mechanism that enforces those assertions against a running system. Guo’s framing of AI-assisted development follows the same architecture: “You write the tests and the LLM generates implementations. If the tests don’t pass, the code doesn’t ship.” The two-layer imperative is not an implementation detail of Gherkin — it is a fundamental architectural principle for any system where the entity generating behavior (human or machine) is separated from the entity specifying intent. The layers must be optimized for different audiences and different concerns, and conflating them — writing specifications that look like code, or code that pretends to be specifications — compromises both.

#7 The Two-Layer Imperative: Separating What from How [Principle]

Ref. 8887-G

“Don’t write scenarios about the UI,” Nicieja counsels. “Write about business outcomes.” This declarative discipline — describing what must be achieved rather than how it should be achieved — is the specification-layer equivalent of the “Relocating Rigor” essay’s insistence that “static promises gave way to runtime truth.” Guo reinforces the principle from the AI angle: the strongest users “specify outcomes rather than steps.” Declarative specifications survive implementation changes because they describe the stable layer — business intent — rather than the volatile layer — technical mechanism. In a world where AI agents can generate multiple valid implementations of the same intent, the declarative specification becomes the anchor that prevents drift. An imperative specification — “click the Export button in the File menu” — is coupled to a specific implementation. A declarative specification — “Vladimir saves his document as a PDF” — is coupled to a business outcome. Only the latter remains meaningful when the implementation is generated rather than hand-crafted.

#8 The Declarative Edge: Why Intentions Outlast Interfaces [Strategy]

Ref. 256A-H

Nicieja advises writers to “begin with the end in mind — the Then,” drawing a parallel to how “most good writers never start writing without figuring out the ending.” Customers “want to buy a specific outcome your product will produce. And Thens are the outcomes.” This compositional technique becomes even more critical in Guo’s framework, where the engineer’s job shifts “from typing code to specifying intent and verifying outcomes.” If you cannot articulate the Then — the observable outcome that constitutes success — you cannot evaluate whether an AI-generated implementation is acceptable. The “Relocating Rigor” essay’s core question — “where did the rigor go?” — can be operationalized as: do you know your Thens? If you can state what must be true after the system acts, you have located the rigor. If you cannot, you are operating on hope. Starting with Thens is not a writing trick; it is a discipline of intent that forces you to answer the only question that matters: what does done look like?

#9 Begin with Outcomes: The Discipline of Starting with Thens [Strategy]

Ref. 4B59-I

“Humans prefer stories illustrated with examples,” Nicieja observes, demonstrating that an abstract requirement — “split the salary based on contribution” — conceals ambiguity that a concrete example — “John and Gilly wrote 100 pages each, so they get 40% each” — instantly reveals. Guo encounters the same principle from the opposite direction: “You either under-specify and get something plausible but wrong, or over-specify and spend more time writing instructions than writing code.” The solution in both cases is the same — concrete examples that anchor abstract intent to observable reality. The “Relocating Rigor” essay frames this as the shift from “static promises” to “runtime truth.” Abstractions are static promises about what a system should do; examples are runtime truths about what it actually does in specific cases. In every era of software development, the teams that succeed are the ones that insist on concreteness early — not because abstraction is wrong, but because premature abstraction conceals the very misalignments that will later become defects.

#10 Concrete over Abstract: Why Examples Defeat Generalizations [Principle]

Ref. 9C79-J

The “Relocating Rigor” essay articulates a design pattern for AI systems: “probabilistic inside, deterministic at the edges.” Nicieja’s executable specifications are the most developed example of what those deterministic edges look like in practice. A Gherkin scenario — Given a specific context, When a specific action occurs, Then a specific outcome must be observable — is a contract that any implementation, human or machine-generated, must satisfy. Guo notes that “specifying intent precisely enough that a machine can generate correct implementations is not easier than writing code. It’s a different skill, and in some ways a more demanding one.” The Given-When-Then template is a technology for making that demanding skill tractable. It provides a grammar for intent specification that is simultaneously human-readable (business stakeholders can verify it) and machine-executable (automation can enforce it). In the AI era, this dual nature transforms executable specifications from a testing methodology into an interface protocol between human judgment and machine generation.

#11 The Specification as Contract: Deterministic Edges for Probabilistic Systems [Strategy]

Ref. 8491-K

“Only working production code holds the truth about the system,” Nicieja acknowledges. “Most specifications become outdated before the project is delivered.” His solution — living documentation that “changes along with the system it documents, thanks to the link between the text and the code” — embodies the “Relocating Rigor” essay’s principle that sustainable discipline must be continuously verified against reality. Guo’s observation that “systems like CRMs or HRISs represent many thousands of engineer-years spent encoding business logic, exceptions, and constraints that were learned the hard way” points to why living documentation matters: that accumulated knowledge must be preserved in a form that remains accurate as systems evolve. Dead documentation — specifications that exist as files but are never executed — is the organizational equivalent of the “Relocating Rigor” essay’s “Gantt chart updated by a project manager.” It provides the comfort of knowledge without its substance. The only documentation that survives contact with reality is documentation that reality continuously validates.

#12 Living Documentation: The Only Documentation That Survives [Strategy]

Ref. ECDC-L

Nicieja organizes Specification by Example around a deceptively simple insight: “conversations between domain experts and the delivery team” are the foundation of the entire development process. Specifications are not authored; they are the residue of structured dialogue. Guo treats intent as something individuals possess and must learn to articulate — “the work of translating accumulated experience into explicit constraints.” The “Relocating Rigor” essay focuses on engineering teams and their internal discipline. But Nicieja reveals a dimension both others underestimate: intent is not found in any single person’s head. It is distributed across the product owner’s domain knowledge, the engineer’s technical constraints, the designer’s user empathy, and the compliance officer’s regulatory awareness. No amount of individual clarity can compensate for collective misalignment. The conversation is not a preliminary to specification; it is the specification’s generative act. In the AI era, where Guo notes that “forming the right intent in the first place” is the critical bottleneck, the technology for forming intent is not a better prompt — it is a better conversation.

#13 Conversations as the Foundation: Intent Is Collectively Constructed [Wisdom]

Ref. 7B5D-M

Nicieja shares how he “called the user in most of my scenarios Simona. Every time I wrote a scenario, I imagined that she was anxious to get her work done as quickly as she could, because she had a sick child at home.” This practice — giving abstract users concrete identities with emotional lives — transforms specifications from technical documents into vehicles for empathy. Guo’s essay, focused on engineering productivity, doesn’t address this human dimension. The “Relocating Rigor” essay’s concern is with discipline, not empathy. But Nicieja’s insight fills a gap in both: the quality of intent is partly determined by the richness of the human models embedded in the specification process. When Guo asks “could ten people build DocuSign today?” and answers that they’d spend time “debating edge cases, compliance, trust guarantees,” she’s describing debates that are richer and more productive when the debaters have concrete users in mind — not “the user” but Simona, rushing to sign a lease before picking up her sick child. Empathy is not a soft skill peripheral to engineering; it is a technology for generating better intent.

#14 The Empathy Engine: Personas as Intent Amplifiers [Wisdom]

Ref. F538-N

Nicieja draws on domain-driven design to argue that “a ubiquitous language must grow out of blending technological expertise with business expertise in reasonable proportions.” When Peter, a new team member, discovers that “screening” and “qualifying” are used interchangeably and that “tenant leads” and “candidates” seem synonymous, the specification fails not because its logic is wrong but because its language is inconsistent. Guo identifies the same problem at the AI interface: “When you tell an experienced engineer ‘make this faster,’ they don’t hear a literal instruction. They infer context.” An AI agent cannot infer context from inconsistent terminology. The “Relocating Rigor” essay’s observation that “the discipline was more demanding than what came before, not less — it just didn’t look like the discipline people were used to seeing” applies directly to language maintenance: cultivating a ubiquitous language looks like pedantry but functions as infrastructure. Every ambiguous term is a potential fault line. Every synonym is a hidden assumption. In a world where specifications may be interpreted by machines rather than colleagues, linguistic precision ceases to be optional.

#15 The Ubiquitous Language: Shared Vocabulary as Infrastructure [Strategy]

Ref. 7550-O

Nicieja contrasts a system-oriented scenario — “When the content is analyzed, Then the sentence that is too long should be detected” — with a user-oriented version: “When Vladimir writes a sentence that is too long, Then he should be notified that the sentence could be shortened.” The shift forces questions about user experience that system-oriented language obscures. Guo’s spectrum of agent effectiveness — from “very well-spec’d” (databases, compilers) to “human-centric” (product logic, UX, naming) — reveals that the hardest specifications to write are precisely the ones that require outside-in thinking. The “Relocating Rigor” essay focuses on engineering truth but doesn’t address user truth. Nicieja fills this gap: “outside-in development forces you to think about the people who define software requirements and try to understand why they want what they want.” In the AI era, where agents excel at system-oriented implementation but struggle with human-centric design, the outside-in perspective becomes the specification writer’s most distinctive contribution — the dimension of intent that machines cannot generate for themselves.

#16 The Outside-In Imperative: Centering the Human in the System [Strategy]

Ref. DED9-P

Nicieja tells the story of a Chief Information Security Officer who emerged “seemingly out of nowhere” when Activitee’s sales team presented security scenarios to a prospective client. “New business needs usually imply that there’s a stakeholder the team hasn’t yet explicitly identified.” Guo describes a parallel phenomenon in AI-mediated development: invisible invariants — “assumptions about idempotency, ordering, failure semantics” — that represent the judgment of stakeholders who shaped the system but left no documentation. The “Relocating Rigor” essay warns that removing constraints makes hidden dependencies visible. All three texts converge on a strategic principle: when a new requirement appears unexpectedly, the most important response is not to implement it but to investigate who generated the demand. Every invisible invariant has an author. Every unstated constraint has a stakeholder. Finding that stakeholder — making the implicit explicit — is higher-leverage work than any implementation, because it prevents the scope surprises that Guo describes as the dominant failure mode of AI-assisted development.

#17 The Hidden Stakeholder: Business Needs as Early Warning Systems [Pattern]

Ref. 52D1-Q

Nicieja demonstrates how living documentation self-corrects through the story of Peter, a newcomer confused by undefined domain terms. “There’s nothing wrong with the fact that the changes are only happening now, after Peter pointed them out. That’s why we talk about a living documentation system. Such a system employs feedback loops to correct itself over time.” This is the social instantiation of the “Relocating Rigor” essay’s principle that truth emerges from continuous verification. But where the essay focuses on automated verification (tests, CI, deployment pipelines), Nicieja shows that human encounters with confusion are equally valuable feedback signals. Guo describes spending time “steering or correcting an agent” and finding that this “pointed to parts of the system I understood tacitly but had never articulated.” The pattern is the same: confusion is not a failure of the system but a signal that the system is working — surfacing tacit knowledge that would otherwise remain invisible. A system that never confuses newcomers or frustrates AI agents is probably a system whose implicit contracts have never been tested.

#18 Peter’s Problem: Why Living Systems Self-Correct Through Human Feedback [Revelation]

Ref. 2320-R

Nicieja’s coinage — speci-fiction — describes specifications that “pose as a single source of truth but can’t be one because nobody cares to update them.” The “Relocating Rigor” essay identifies the same pathology in project management: “a project manager updated a Gantt chart” that bore no relationship to actual progress. Guo encounters the AI-era variant: generated code that “runs, passes tests, and looks reasonable” but violates the system’s actual contract. All three are instances of a single anti-pattern: artifacts that provide the comfort of truth without its substance. Speci-fiction is particularly insidious because it doesn’t just fail to help — it actively misleads. Teams that trust outdated specifications make decisions based on false premises. The only cure, all three authors agree, is continuous verification: linking artifacts to reality through mechanisms that break loudly when the two diverge. In the AI era, where the volume of generated artifacts will vastly exceed human review capacity, the distinction between living documentation and speci-fiction becomes existential.

#19 The Speci-Fiction Epidemic: Documentation That Lies Comfortably [Pattern]

Ref. 5FAB-S

Nicieja opens Chapter 5 with a devastating analogy: crash test dummies modeled only on male bodies caused female passengers to face 20-40% higher risk of death. “Even the most basic placeholders can influence the results of a test in a dramatic and horrific way.” In Gherkin, fictional examples “poison your decision making” because they prevent teams from discovering domain-specific realities. Guo’s analysis suggests this problem intensifies with AI: when agents generate implementations from specifications containing synthetic data, the implementations encode the biases of the synthetic data rather than the constraints of the real domain. The “Relocating Rigor” essay’s insistence that discipline must move “closer to where truth lives” implies that truth lives in real data, not manufactured examples. The crash test dummy effect is not about data quality in the narrow sense — it is about the epistemic integrity of the specification process. Every placeholder, every “foo” and “bar,” every fictional username is a small act of abstraction that distances the specification from the reality it claims to describe.

#20 The Crash Test Dummy Effect: How Fake Data Poisons Judgment [Wisdom]

Ref. D1A1-T

Nicieja warns against writing Gherkin tables that mirror database schemas — foreign keys, publisher_ids, relational joins disguised as specification data. “There’s nothing business-y, readable, or domain-specific about database rows.” This anti-pattern represents a broader failure that all three texts address: the temptation to optimize for machine convenience at the expense of human understanding. The “Relocating Rigor” essay describes how “compiler appeasement gave way to test-enforced correctness” — a relocation from satisfying the machine to satisfying the requirement. Guo warns of a new version: engineers who accept AI-generated code because it compiles rather than because they understand it. The SQL table anti-pattern is the specification-layer instance of a universal principle: whenever you write for the machine’s convenience rather than the human’s understanding, you have relocated rigor in the wrong direction — away from truth rather than toward it. The specification layer exists to be read by humans. The moment it becomes illegible to its human audience, it has failed at its only job.

#21 The SQL Table Anti-Pattern: When Technical Convenience Destroys Communicative Value [Pattern]

Ref. B815-U

Nicieja distinguishes illustrative examples from exhaustive examples: “An exhaustive list of examples is like a list of all the contacts on your phone. Illustrative examples contain one key example from each of your important social circles.” This distinction has profound implications for Guo’s world of AI-generated code. The temptation in AI-assisted development is to compensate for reduced human oversight by increasing test quantity — more tests, more examples, more coverage. But Nicieja shows that exhaustive specification destroys the communicative purpose of the specification layer. A specification cluttered with hundreds of test cases becomes unreadable, defeating the purpose of living documentation. The “Relocating Rigor” essay’s discipline is not about doing more — it is about doing the right things with ruthless selectivity. Three well-chosen examples that illuminate boundaries (the Goldilocks principle) communicate more than a hundred examples that merely enumerate. In the AI era, the skill of choosing the right examples — illustrative over exhaustive — becomes a form of judgment engineering.

#22 The Exhaustion Illusion: Why Comprehensive Testing Defeats Comprehensive Specification [Wisdom]

Ref. 1B18-V

“Boomerangs are functionalities that keep breaking every now and then, returning from production to development despite your team’s best efforts,” Nicieja explains. They signal deeper problems: complex domain rules, unidentified stakeholders, bus-factor-of-one knowledge silos. Guo’s concept of “unacceptable code” that “violates the system’s implicit contract” describes the same phenomenon from the generation side — AI agents will reliably produce boomerangs because they lack the tacit knowledge that prevents human engineers from repeating known mistakes. The “Relocating Rigor” essay’s discipline of feedback loops provides the mechanism: “the more often they return, the more prominence they deserve — more tests and more examples, which then become documentation.” Each boomerang is an opportunity to convert tacit knowledge into explicit specification. In a world of AI-generated code, boomerangs become the primary mechanism through which implicit invariants get surfaced and codified. The specification suite becomes institutional memory — not of what the system does, but of what it must never do again.

#23 The Boomerang Signal: Recurring Failures as Knowledge Opportunities [Pattern]

Ref. 85E8-W

Guo identifies a dimension that neither Nicieja nor the “Relocating Rigor” essay fully confronts: taste. “Much of this comes down to taste: knowing when something is technically right but still the wrong shape for the system you are building.” Nicieja’s methodology works powerfully for behavioral assertions — Given this context, When this happens, Then this must be true. But “the wrong shape” resists the Given-When-Then template because it is not a behavioral property. It is an aesthetic and structural judgment about how code should feel to maintain, extend, and reason about. The “Relocating Rigor” essay’s spectrum — from XP to dynamic languages to continuous deployment — traces relocations within the specifiable. Guo’s spectrum — from “very well-spec’d” to “hard to spec” — reveals a frontier beyond which specification cannot travel. At this frontier, the specification layer must be supplemented by something else: code review, architectural principles, design philosophy. The insight is not that specification is limited but that knowing its limits is essential to using it well.

#24 The Taste Frontier: Where Specification Cannot Follow [Revelation]

Ref. DECF-X

Guo defines “judgment engineering” as “the work of translating accumulated experience into explicit constraints, tests, and boundaries that systems and teams can operate against.” Nicieja’s entire book is an operational manual for this competency, though he calls it specification writing. The “Relocating Rigor” essay traces its history through XP, dynamic languages, and continuous deployment. What all three texts reveal, read together, is that judgment engineering has always been the core competency of effective software development — it was simply obscured by the more visible work of writing code. When the “Relocating Rigor” essay observes that “the practices that looked like chaos were actually mechanisms for enforcing honesty,” it is describing judgment engineering in action: pair programming as dual-witness verification, test-first as intent specification, short iterations as assumption testing. AI doesn’t create the need for judgment engineering; it reveals that the need was always there, hidden behind the assumption that writing code and exercising judgment were the same activity.

#25 Judgment Engineering: The New Core Competency [Principle]

Ref. F455-Y

“Cheap generation without strict judgment isn’t a new paradigm. It’s abdication,” the “Relocating Rigor” essay declares. Guo echoes: “If you removed hand-written code but didn’t add explicit invariants, you lost rigor.” Nicieja’s methodology provides the most granular account of what strict judgment looks like in practice: context questioning that asks “is there a context that produces a different outcome?”, outcome questioning that asks “is there another outcome that also matters?”, the exploratory paths taxonomy (angry, scary, embarrassing, delinquent, stressful, greedy, forgetful, desolate, indecisive) that systematically imagines failure. In the AI era, these are not specification techniques — they are evaluation techniques. Every question Nicieja teaches specification writers to ask is a question that should be asked of AI-generated code. Did the agent consider the angry path? The embarrassing path? The indecisive path? The specification writer’s checklist becomes the AI evaluator’s checklist. The discipline of writing great specifications and the discipline of evaluating AI output converge into a single practice.

#28 The Evaluation Imperative: Generation Without Judgment Is Abdication [Strategy]

Ref. 1363-A

In Nicieja’s culminating architectural vision, specification suites are organized according to the structure of the business itself — core domains, secondary domains, generic domains — with bounded contexts preventing terminology collisions between teams. Guo writes that “value accrues less to individual tools and more to whoever decides which decisions get automated, and under what constraints.” The “Relocating Rigor” essay argues that “control doesn’t disappear — it moves closer to reality.” Read together, they suggest that the specification suite of the AI era will be isomorphic with the organization it serves — not just a test suite but a map of business reality that determines what gets generated, under what constraints, and for whose benefit. The ten people who could theoretically build DocuSign would spend their time, in Guo’s framing, debating “edge cases, compliance, trust guarantees.” In Nicieja’s framework, those debates would be captured as executable specifications organized by domain — a living, verified, continuously-updated representation of what “signing” means across legal contexts. The specification suite becomes the organization’s judgment, made durable and scalable.

#29 The Isomorphic Suite: Specifications as Organizational Maps [Wisdom]

Ref. E677-B

“When something looks like recklessness, look for where the discipline moved,” the “Relocating Rigor” essay counsels. “If you can’t find it, that’s when you should worry. If you can find it, you’re probably looking at the future.” Guo operationalizes this: “If you’re working with generative AI now, the question to ask yourself is: where did the rigor go?” Nicieja provides the toolkit for answering: executable specifications that make rigor visible, living documentation that keeps rigor current, and a social practice of structured conversation that generates rigor collaboratively. The deepest insight of the synthesis is that these three texts, written at different times for different audiences about different problems, are all telling the same story. Software engineering is a discipline that perpetually rediscovers the same truth: the hardest work is not building systems but specifying what systems should do and verifying that they do it. That work looks different in every era — phase gates, then test suites, then executable specifications, then intent engineering — but its nature never changes. It is the work of making judgment explicit, making truth unavoidable, and refusing the comfort of artifacts that lie. Every generation of software engineers must learn this lesson anew, because every generation is offered a new temptation to believe that execution alone is enough.

#30 The Permanent Lesson: When Something Looks Like Recklessness, Find Where the Discipline Moved [Wisdom]

Ref. 0E7E-C

“When something looks like recklessness, look for where the discipline moved,” the “Relocating Rigor” essay counsels. “If you can’t find it, that’s when you should worry. If you can find it, you’re probably looking at the future.” Guo operationalizes this: “If you’re working with generative AI now, the question to ask yourself is: where did the rigor go?” Nicieja provides the toolkit for answering: executable specifications that make rigor visible, living documentation that keeps rigor current, and a social practice of structured conversation that generates rigor collaboratively. The deepest insight of the synthesis is that these three texts, written at different times for different audiences about different problems, are all telling the same story. Software engineering is a discipline that perpetually rediscovers the same truth: the hardest work is not building systems but specifying what systems should do and verifying that they do it. That work looks different in every era — phase gates, then test suites, then executable specifications, then intent engineering — but its nature never changes. It is the work of making judgment explicit, making truth unavoidable, and refusing the comfort of artifacts that lie. Every generation of software engineers must learn this lesson anew, because every generation is offered a new temptation to believe that execution alone is enough.

#30 The Permanent Lesson: When Something Looks Like Recklessness, Find Where the Discipline Moved [Wisdom]

Ref. 0E7E-D