跪拜 Guibai
← All articles
Android · Android Jetpack · Kotlin

Spec-Driven Development Stops AI-Generated KMP Code from Drifting

By 稀有猿诉 ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

AI coding tools produce clean single features but no mechanism keeps a multi-screen codebase coherent over time. Making architecture a file-system-level constraint and giving the model a structured spec to read before every edit addresses the root cause of AI-generated drift—not intelligence, but missing memory and enforcement.

Summary

AI-generated features drift because nothing remembers the architecture between prompts. By the fifth screen, state conventions diverge, layers leak, tests vanish, and designs no longer match. KMPilot treats architecture as a physical constraint: a hook blocks direct edits to feature files, parallel agents each own a single layer, and every feature gets a versioned spec.md that the model reads before making changes.

A feature starts with a design built in Google's Stitch, from which a token-extraction script pulls exact color, radius, font, and spacing values into a blueprint. The /create-feature command then generates a complete module—data layer, UI, integration, and platform code—across 32 identically structured files. The same command writes a spec capturing goals, non-goals, design decisions with rejected alternatives, and GIVEN/WHEN/THEN requirements.

Later changes go through /modify-feature, which reads the spec first, plans against recorded decisions, and writes back a new version with a dated changelog. Verification, testing, and architecture review skills act as gates that can hand work back. Applied to Kickoff26, a 2026 World Cup companion app, the approach produced no architectural drift across multiple features.

Takeaways
AI-generated codebases drift because the model has no persistent memory of architecture decisions and no mechanism stops it from working differently each prompt.
KMPilot uses a hook to physically block raw edits to files under feature/, so the model cannot quietly reshape the structure.
Every feature gets a versioned spec.md with a metadata header, goals, non-goals, a design decisions table with rejected alternatives, and GIVEN/WHEN/THEN requirements.
A token-extraction script pulls exact color, radius, font, and spacing values from a Stitch design mockup, producing a blueprint that code builds against token-by-token.
Parallel agents each own one layer (data, UI, integration, platform), so they never collide and return a complete wired module, not a sketch.
The /modify-feature command reads the existing spec first, plans changes against recorded decisions, and writes back a new spec version with a dated changelog.
Verification, testing, and architecture review skills run as gates after every change and can hand work back for correction.
Kickoff26, a 2026 World Cup app, was built entirely this way and showed no architectural drift across multiple features.
Conclusions

Prompt engineering alone cannot solve codebase drift because drift is a memory and enforcement problem, not a reasoning problem. The model needs external constraints that persist across sessions.

Physically blocking file writes is a stronger guarantee than any prompt instruction. Asking the model to follow architecture is a suggestion; a hook that rejects edits is enforcement.

Extracting design tokens programmatically from a mockup, rather than eyeballing values, closes the gap between what was designed and what ships—a gap that compounds across screens.

Writing a spec after the code, and keeping both in lockstep, gives the model a structured memory it can read before making changes. This is what prevents a modification from silently reshaping an existing design.

The parallel-agent structure mirrors Clean Architecture's layer separation: each agent owns one layer, so the model cannot take shortcuts that leak concerns across boundaries.

Concepts & terms
Spec-Driven Development
A workflow where a structured specification file (goals, non-goals, design decisions, requirements) is written alongside the code and version-controlled. AI reads the spec before making changes, so architecture decisions persist across sessions rather than living only in a scrolling chat history.
Clean Architecture
A layered software architecture pattern that separates code into concentric rings (entities, use cases, interface adapters, frameworks) with strict dependency rules. In KMPilot, it is enforced structurally: every feature gets the same folder layout, and a hook blocks edits that would violate the separation.
Design Tokens
Programmatic representations of design decisions—colors, radii, fonts, spacing values—extracted directly from a mockup rather than estimated by eye. They become a machine-readable blueprint that code builds against, ensuring the shipped UI matches the approved design.
Kotlin Multiplatform (KMP)
A Kotlin technology that allows sharing business logic across Android, iOS, desktop, and web while writing platform-specific UI code. KMPilot targets KMP projects, generating shared data and domain layers with platform-specific Compose UI.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗