AI 2026-09-09 8 min

The Requirements Interview and the 'SpecOps' Loop: How to Use AI Sparring and Rewrite Code Painlessly

Learn how to use AI as a sparring partner to draft EARS specs, and how the iterative SpecOps loop allows rewriting code without accumulating patches or technical debt.

Written by Samir El Azem Crovetto • Senior Backend Engineer & DevSecOps

Let's be honest: nobody wants to sit down on a Monday morning to write a thousand-line Markdown document detailing every API, every test case, and every validation of a complex development. It is incredibly boring, consumes precious time, and if you are working on an existing codebase with legacy parts (that old code nobody wants to touch but keeps the company afloat), it feels like a daunting chore.

The good news is that in Spec-Driven Development (SDD), you don't have to draft the specification from scratch manually. AI is not just a code-punching engine; its true superpower is acting as a technical sparring partner (an ultra-fast business analyst who picks your brain to extract requirements and structure them).

Today we are going to see how this interactive flow works step-by-step, what happens when the specification you've designed isn't quite right (and how the AI will rewrite the implementation without leaving dead code), and how to approach this continuous cycle in the style of a 'SecDevOps' or 'SpecOps' flow for continuous improvement.

1. The 'Interrogation' Pattern: Making AI Write the Spec for You

Imagine that in our restaurant project, we need to add a major feature: managing allergies in reservations. Instead of drafting the spec.md file from scratch, we'll let the agent do the dirty work.

First, we initialize an empty specification in the directory with Spec Kit:

specify init --here --integration agy

This leaves us ready to interact with the console or our editor's chat (in this case, Google Antigravity). Now, we open the chat and toss in this golden prompt (the 'Interrogation' pattern):

'I want you to act as an expert software development business analyst. Your goal is to help me write the specs/allergy-reservations.md file using EARS syntax. Do not assume anything on your own. Ask me multiple-choice questions, one at a time, about how the system should handle customer allergies (validations, storage, integrations). When we have enough information, you will draft the specification document.'

Sparring in Action:

The agent will start interviewing you in a super-focused manner:

AI: 'Understood! Let's go with the first question for the allergy system:

1. How should the system react if a customer enters an allergy that is not in our standard allergen dictionary (e.g., seafood, gluten)?

A) Reject the reservation with a validation error.
B) Allow free text, save it with an \'Unverified\' tag, and notify the chef via email.
C) Automatically map it using semantic similarity to the nearest allergen.
How do you see it?'

You just have to reply: 'B, but add that the notification to the chef should only be sent if the reservation is for the same day'.

In less than ten minutes and with a couple of quick chat exchanges, the AI will have extracted all the logic from your head and generated a flawless allergy-reservations.md file in EARS syntax, without you having to fight with Markdown structure.

2. The 'SpecOps' Loop: What Happens When the Spec Isn't Right?

This is where the reality of software development kicks in. You've finished implementing the allergy feature, you run the application in your test environment and... surprise! You realize the specification you designed was flawed.

For example, we specified that if there was an 'Unverified' allergy, a synchronous email was sent to the chef. But upon testing it, we realize the external email service is incredibly slow and blocks the main Node.js thread, or that the chef receives 200 emails a day and is about to kill us. The original specification had a technical design flaw.

In traditional development (and in destructive Vibe Coding), inertia pushes us to open the email.service.ts file and slap in a quick patch (a hotfix) with an async task queue or a dirty try/catch.

In SDD, the protocol is radically different. We follow an iterative continuous cycle similar to DevSecOps, which we can call 'SpecOps':

 ┌────────────────────────────────────────────────────────┐
 │                      SpecOps Loop                      │
 ├────────────────────────────────────────────────────────┤
 │                                                        │
 │     1. Detect the design flaw (e.g., blocking)         │
 │                            │                           │
 │                            ▼                           │
 │     2. Correct the specification (specs/spec.md)       │
 │                            │                           │
 │                            ▼                           │
 │     3. Update the plan (plan.md)                       │
 │                            │                           │
 │                            ▼                           │
 │     4. Regenerate tasks (tasks.md) <─── CRUCIAL!       │
 │                            │                           │
 │                            ▼                           │
 │     5. The agent REWRITES the code completely          │
 │                            │                           │
 │                            ▼                           │
 │     6. Automated validation and deployment             │
 │                                                        │
 └────────────────────────────────────────────────────────┘

The Golden Rule of the SpecOps Loop:

The specification and the code are treated as an inseparable pair. If the code is wrong, it's because the specification was incomplete or incorrect. Therefore: never correct the code locally; correct the specification and let the AI recompile the solution.

3. Practical Example: Updating the Spec and Letting AI Rewrite the Implementation

Let's simulate the chef's email problem. Our original specification in specs/allergy-reservations.md said this:

# INCORRECT:
IF the reservation contains an unverified allergen, THEN the system SHALL send a synchronous email to the chef with the details.

To solve the execution thread blocking, we directly open the specs/allergy-reservations.md file in the editor and update it with the proper solution (an asynchronous event pattern):

# CORRECT (EARS Syntax):
WHEN a reservation contains an unverified allergen, THEN the system SHALL publish an `AllergyNotificationRequested` event to the local message queue.

WHEN the message queue processes the `AllergyNotificationRequested` event, THEN the email service SHALL dispatch the notification to the chef asynchronously.

Once the physical specification file on our disk is modified, we open the Antigravity chat (or your Spec Kit-compatible editor) and run the logical update phase:

/speckit.plan

The agent will read the new specification, compare it with the existing code in the repository, and propose a clean refactoring plan:

'I have detected that the synchronous email dispatch in reservas.service.ts violates the new specification. The plan is to remove that direct coupling, create a simple in-memory event bus (or use the project's event library), and implement the asynchronous consumer in notifications.consumer.ts.'

The Mandatory Sync Step: Regenerating Tasks

Here comes the big production secret that many tutorials ignore: you must never proceed directly to implementation without first updating the checklist. If you execute the implementation directly, the agent will have an amnesia attack and read the old task list still saved in tasks.md, ignoring the architectural restructuring you just designed.

Therefore, strictly execute:

/speckit.tasks

This will update the tasks.md file, crossing out old tasks that no longer apply and adding the new technical subtasks for the asynchronous migration.

Having the task checklist synchronized, we finally execute the implementation phase:

/speckit.implement

How Does the AI Rewrite What Was Implemented?

This is where the magic of SDD happens. Since the code is a transient byproduct, the AI doesn't just stick a patch over the old code. The agent will delete the obsolete synchronous implementation and write the new asynchronous architecture from scratch.

There will be no 'dead code', no orphaned variables in services, no useless dependencies imported in the header. The codebase remains as clean, cohesive, and professional as if a senior developer had carefully rewritten it over a whole weekend.

4. The Existing Codebase Challenge: Dealing with Legacy Code

It's all well and good to see how this works in a fresh restaurant project where everything is shiny. But what happens when you join a company with a five-year-old monolith full of legacy code and not a single unit test?

Trying to specify that whole monster at once to use SDD is a utopia. In production, the smart strategy consists of applying the 'Delta Spec' (Specification of Delta) pattern:

Leave the legacy code alone (Read-Only): Do not try to document the past. The old code remains in the repository as read context for the AI. SDD tools are perfectly capable of reading legacy code to understand how to integrate with it, without needing it specified in Markdown.
Specify only the change (The Delta): If you are asked to add a discount coupon system to that legacy checkout, create a small spec (specs/discounts.md) detailing exclusively the coupon rules.
Define the touchpoints: In your delta specification, clearly define how the new functionality hooks into the old system:

'IF the legacy checkout processes the payment, THEN the coupon system SHALL mark the entered coupon as redeemed in the database.'

Isolate the new code: Try to have the agent implement the new development in separate, clean modules, using design patterns like Wrappers or Adapters to communicate with the legacy part. This way you'll keep the new code under a top SDD quality standard, while the old monolith keeps running in its corner without being disturbed.

Learning Summary

If you want to master the practical SDD loop in your daily life, burn these guidelines into your mind:

Use AI Sparring: Don't break your head writing endless specs by hand. Ask the agent to interview you with multiple-choice questions and draft the Markdown for you.
Adopt the 'SpecOps' mindset: If you discover a logic or performance flaw in your testing, patching the code is forbidden. Modify the spec, update the plan, mandatorily regenerate the tasks with /speckit.tasks, and let the AI cleanly regenerate the module.
Respect legacy code: Don't waste time documenting old systems. Use Delta Specs for your new features and let the agent read the existing legacy code only as integration context.

In the next article, The Challenge of Existing Code (Brownfield) and Managing Multiple Specs with Jira/Git of the series, we will step up to resolve the great dilemma that arises when a project truly grows: How to manage multiple specs coexisting in parallel without the AI suffering from amnesia or stepping on tasks? We will see how to organize your flow if you work with strict Git conventions based on your Jira or Agility tickets (for example, branches with nomenclature feature/S-143562_pasarela-pago), and how to use reverse engineering to document complex old systems. See you in the next article!

📚 Spec-Driven Development (SDD) Series

Extra: 🚀 CHEATSHEET: The SDD Cycle in Google Antigravity with Spec Kit