Citation Discipline in Spec-Driven Development: A Cross-Model Empirical Study of Output Determinism and Automated Hallucination Detection in LLM-Generated Code
This cross-model empirical study demonstrates that while Spec-Driven Development frameworks enforcing mandatory per-line requirement citations significantly enhance automated hallucination detection, they simultaneously reduce output determinism compared to uncited approaches, establishing a fundamental trade-off between verifiability and consistency in LLM-generated code.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine you are hiring a team of incredibly talented, but slightly mischievous, robot chefs to cook a complex meal based on a recipe you wrote. You want the robots to follow your instructions perfectly, but you also need to make sure they don't secretly add their own "special ingredients" (like extra spices or random vegetables) that you didn't ask for.
This paper is a scientific experiment to figure out the best way to manage these robot chefs. The researchers tested three different ways of giving instructions to see which method produced the most consistent results and which method could catch the robots when they tried to sneak in unauthorized ingredients.
Here is the breakdown of the experiment using simple analogies:
The Three "Instruction Styles" Tested
The researchers compared three different ways of telling the robots what to do:
- The "Strict Note-Taker" (traceSDD): This method requires the robot to write a tiny sticky note next to every single line of code it writes. The note must say exactly which part of your recipe it is following (e.g., "This line is for Step 3.1"). If the robot writes a line without a note, or writes a note for a step that doesn't exist in your recipe, it's a red flag.
- The "Storyteller" (Spec Kit): This method uses a standard recipe format with user stories and bullet points. The robot follows the story, but it doesn't have to write any sticky notes or citations in the code itself.
- The "Map Maker" (OpenSpec): This method gives the robot a recipe and a separate map (a side file) that links the recipe steps to the code after the robot is done cooking. The code itself has no notes.
The Two Main Goals
The researchers measured two things:
- Consistency (Determinism): If you ask the robot to cook the same meal three times in a row, will the three dishes look and taste exactly the same? Or will they be slightly different every time?
- The "Snitch" Test (Hallucination Detection): If the robot secretly adds a forbidden ingredient (a "hallucination"), can the system automatically catch it?
The Big Discovery: The Trade-Off
The study found a fascinating "catch-22" or trade-off. You can't have your cake and eat it too; you have to choose between Consistency and Safety.
1. The "No Notes" Approach is More Consistent
When the robots were allowed to write code without the sticky notes (the "Uncited" condition), they were incredibly consistent. If you asked them to cook the same meal three times, the results were almost identical.
- The Analogy: Think of a musician playing a song. If they aren't forced to stop and write down why they are playing every single note, they can play the song smoothly and the same way every time.
2. The "Strict Notes" Approach Catches Cheaters
However, when the robots were forced to write a sticky note for every line (the "Cited" condition), the results became less consistent. The three dishes looked slightly different from each other.
- The Analogy: Imagine the musician has to stop after every note to write a note saying "I played this because the sheet music said so." This distraction makes their performance vary slightly each time.
- BUT, this method had a superpower: It caught the cheaters. Because the robot had to cite a specific step from your recipe for every line, the system could instantly spot if the robot wrote a line citing a step that didn't exist in your recipe.
- The Result: The "Strict Note-Taker" method caught 86–88% of the fake ingredients the robots tried to sneak in. The other two methods caught 0%.
What About the Other Methods?
- Spec Kit (The Storyteller): This was the worst performer. It produced the least consistent results (the dishes varied the most) and caught zero fake ingredients.
- OpenSpec (The Map Maker): This was better than the Storyteller but still couldn't catch the fake ingredients automatically because the notes weren't written inside the code.
The "Easy vs. Hard" Surprise
The researchers also noticed something interesting about the difficulty of the tasks:
- Easy Tasks: The penalty for writing notes was huge. On simple tasks, forcing the robot to write notes made the results very inconsistent.
- Hard Tasks: On complex tasks, the penalty was much smaller. When the task is hard, the robot has so many ways to solve it that the extra notes don't mess up the consistency as much.
The Bottom Line
This paper concludes that there is a fundamental choice to be made when using AI to write code:
- If you want the AI to produce the exact same code every time (Consistency): Don't force it to write citations. Just give it a structured recipe.
- If you need to know for a fact that the AI didn't sneak in unauthorized code (Safety): You must force it to write citations for every line. This will make the code look slightly different every time, but it gives you a unique, automatic way to catch the AI if it tries to lie or add things you didn't ask for.
The researchers found that this "Safety vs. Consistency" trade-off happens regardless of which AI model you use (they tested two very different ones, and the results were the same). It's a rule of the game, not just a glitch in one specific robot.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.