I built the same AI coding feature twice. One attempt produced 116 commits and ended in a hard reset. The other shipped. The difference was where the specification lived.

Specification Drift: Why AI Coding Workflows Stop Converging

I built the same AI coding feature twice.

The first attempt used a vibe-coding workflow with Claude Opus 4.6.

It produced:

• 116 commits
• 7 reverts
• no staging success
• a hard reset after 15 days

The second attempt used the same model, same developer, same core feature, and same repository, but with a prompt-driven workflow.

It reached staging by day 5 and merged by day 9.

The difference was not the model.

It was where the specification lived.

The failure mode

The failure mode I’m calling specification drift is this:

Specification drift is the gap between intended behavior and what AI-rewritten code actually preserves.

In the failed attempt, fixes mostly lived in generated code or chat history.

That worked at first. The early changes were fast. Bugs were visible. Fixes were obvious. Each commit felt productive.

But as the system grew more coupled, a pattern appeared:

text
fix → regress → fix → regress


    

        

          
            
          
        
      

        

          
            #aicoding #aiengineering #softwareengineering #promptdrivendevelopment #specificationdrift | Serhan Asad
          
        
          

            I spent 15 days vibe coding one production feature.

116 commits.
75 fix commits.
7 reverts.
Thousands of messages with the same AI model.

And at the end?

I deleted the whole thing.

Not because the model was bad.
Not because I didn't write tests.
Not because I didn't try hard enough.

The problem was more subtle:

The code kept changing, but the specification kept disappearing.

The failure mode specification drift.

It happens when fixes live only in AI written code.

You solve a bug. Then the next AI pass rewrites the surrounding system. The fix gets weakened, contradicted, or lost.

At small scale, this feels fine.

At system scale, it becomes a loop:

fix the orchestrator -> break the webhook
fix the webhook -> break credentials
fix credentials -> re-break the orchestrator

Every commit feels productive.

But the system is not actually getting closer to shipping.

So I rebuilt the same feature a second time using Prompt-Driven Development.

Same developer.
Same core feature.
Same model.
Same repo.
Same cloud test environment.

The difference was where the truth lived.

In vibe coding, the code was the source of truth.

In PDD, the prompts and behavioral tests were the source of truth. Code became replaceable.

That attempt reached first end-to-end staging success in 5 days and merged to production in 9.

The lesson:

When AI-assisted development stops converging, don't just add more patches. Move the fix into the artifact that survives the next generation.

For simple scripts, prototypes, and isolated features, vibe coding can still be incredibly fast.

But once the system becomes coupled enough that every fix creates another regression, the durable artifact matters.

The future of AI coding might not be "better prompts in chat."

It might be treating the specification itself as the thing we build, test, version, and regenerate from.

Full case study in comments.

#AICoding #AIEngineering #SoftwareEngineering #PromptDrivenDevelopment #SpecificationDrift

          
        

            
          linkedin.com