Specification Talk Structured

An overview of how to preserve business intent in AI-driven software development.

AI agents interpret instructions, consult files, propose changes, generate Code and run tests. This reduces the effort to implement, but does not guarantee that the The solution corresponds to the problem that should be solved.

When the agent binds tasks, an incomplete interpretation crosses several Artifacts before anyone could see it. The risk is not just the wrong code: it is a interpretation not yet validated to become an apparently consistent implementation. In legacy systems (old systems that follow in production), business is spread between code, integrations, outdated documentation and the memory of few people.

Not even the speed gain is consensus. In a controlled task, developers with AI finished faster (Peng et al., 2023). In a study with 16 developers experienced and 246 real tasks, the use of AI increased time by 19% (Becker et al., 2025, preprint, still no peer review). This page is not about speed, and What's lost between the conversation and the code.

The scenario, built for this page, is the modernization of a commercial system with over 15 years: proposals, commercial conditions, approvals, contracts and integration With the billing. Changes take weeks, and few people know all rules. The board asks:

The phrase expresses a legitimate intention, but it does not say what to preserve, what to change or how to measure success. It gathers symptoms, needs to investigate, goals and a solution already chosen, and each category requires a different treatment.

There is a second cause, decisive in legacy: the current behavior of the system does not It's necessarily the desired behavior. A rule can be preserved, corrected, replaced or discontinued, and the decision depends on evidence and Business authority, not what the code executes today.

The request then becomes a sequence of decisions. At each stage there is one point where the AI help and another in which it can distort, mapped into Step by step.

The model can ask, summarize, propose scenarios, point contradictions, recover context and prepare changes. By default, you don't get the authority to decide value, risk, compliance, acceptance or truth of domain. The position is compatible with elicitation, analysis, validation and management activities described in ISO/IEC/IEEE 29148 and in SWEBOK (the IEEE Computer Software Engineering Knowledge Guide) Society). The proposal explores how the AI can support these activities without replacing them.

Those who know Design Thinking recognize four of the five stages. The fifth, specify and evolve the artifacts, is the addition of requirements engineering. At each stage the Win comes along with a known risk and a control. It's a cycle, not a sequence: any step returns to the previous when new evidence arises. The Vocabulary of Design Thinking serves as a map; it is not presented as proof of anything.

In this proposal, the contribution of the model only counts when its outputs can be examined and contested. Start with a representative flow, not the entire system. On the set, the approval of a proposal with exceptional discount.

It is not bureaucracy for every sentence: it is to be able to distinguish what is known, what is supposed to be and what you've decided. And validating understanding is not validating the result. The conversation can reveal if people understand the rule in different ways, not that the modernization will reduce incidents.

The matrix separates assistance authority. It is a proposed governance policy, the adjust to the structure of responsibility of each organization, and not a requirement of standard.

When the agent also executes tools, changes files or triggers pipelines, the controls begin to cover permissions, scope of execution, revision of changes and Break conditions: generate a suggestion and perform an action are different levels autonomy. The line of acceptance criteria links this section to TDD: the AI may write the test code, but the expected result comes from those who have authority over The rule.

Each artifact has a responsibility and a limit. Business rules register adopted policies, but do not guarantee implementation. The characterization tests record the legacy, including defects and obsolete rules. The code implements a version, but does not prove adherence to intent. There is no universal source of truth.

The divergence (in English, drift) is the situation in which artifacts should Saying the same thing starts to say different things. The proposed policy has five steps, shown below in the discount example.

The reverse: if the new code does not meet an approved criterion, change the criterion requires explicit decision. Editing the test for him to pass is a decision without registration. A traceability is valid in both directions (decision → criterion → test → component; failure → rule to review), with depth proportional to criticality and the requirement of audit. The goal is not to prevent all divergence, but to make it detectable, Explicable and treatable.

A term before following: acceptance criteria are the source of the expected result with which the test compares the observed behavior.

The difference between approaches is the control unit. The TDD (write a test that failure, minimum code for it to pass, and then refactor) answers “what’s next smaller increment and how do I find that it continues to work?”. The specification answers “what problem, for whom, with what rules, restrictions and criteria?”. The TDD makes feedback cheap; does not make the acceptance criteria correct. Without intention and scope, TDD can test the wrong thing efficiently. No executable acceptance criteria, the specification can document a wrong intention.

There is a specific risk of agents: when the same model writes the specification and tests, a green test can only confirm the error of the model itself. Control is the expected result is defined or validated by people before the test is generated (the line of criteria for acceptance in Who decides what?), and each criterion critical have at least one test that was not born from the same prompt or from the same context.

In legacy, three types of tests have different roles: characterization (what legacy today), acceptance (the approved criteria) and TDD (local implementation). One possible sequence: characterize the legacy, validate the rules with whom it decides, write acceptance tests, implement with TDD, compare results and release with monitoring, interruption and reversal criteria.

The evidence about the TDD is greater than that of this workflow, and contextual. Rafique & Mišić (2013), in a meta-analysis of 27 studies, found small effect on quality and little or no in productivity. Tosun et al. (2017), with 24 professionals, no found statistical difference in external quality and saw a drop in productivity in the complex task in existing code. Nagappan et al. (2008), in four IBM teams and Microsoft, observed defects density 40–90% lower and 15–35% longer development, with threats to validity declared by the authors. Liu et al. (2023), EvalPlus) showed that expanded tests find errors that the original tests Let them through. The conclusion is that the proposal does not claim superiority over the TDD nor replaces it: provides context and decisions; TDD provides local feedback and protection against regression.

Modernisation is not complete because the code has been rewritten. Indicators below need operational definition, baseline and observation period; more documents or tests do not prove, alone, that the system has become more sustainable. As complete definitions (recall of requirements, residual ambiguity per 100 requirements, precision and recall of links, DORA metrics) are in the kit.

Climbing a step requires new evidence; the bottom step does not prove the top step.

LLMs show partial capacity in controlled bidding tasks, generation of specification and detection of ambiguity, with flaws in domain terminology, interfaces and restrictions. The research is mostly laboratory, and LLMs as requirements reviewers had inconsistent results. No study was found controlled or longitudinal workflow complete against a baseline aligned to ISO/IEC/IEEE 29148 and SWEBOK.

Choose a representative flow, apply the five practices, register the first divergence and decide who solves it. No promise of outcome: the goal is to have something which may be examined and contested.

Standards and guides are the foundation of the design, not experiment: none of them validates this workflow. References are grouped by the type of evidence.