How AI Coding Practices Have Evolved: From Vibe Coding to Spec-Driven Development to Skills¶
Target Audience: Developers who use AI coding tools daily
Key Points¶
4 Phases in 18 Months
Vibe coding → Spec-driven → CLAUDE.md → Skills
Spec-Driven Trade-offs
Kiro was right but heavy. Overhead exceeded implementation for small-to-mid tasks
What Skills Really Mean
The shift from code generation quality to knowledge structuring
Between 2025 and 2026, the "right way" to develop with AI changed at a dizzying pace. First it was "just let it build." Then it became "write the spec before building." And now, the pendulum is swinging again.
This article traces how AI coding practices have evolved, where we stand today, and what issues remain on the table.
The Vibe Coding Era: "Build It" Worked—Until It Broke¶
It started simple. Say "build me a calculator" and you got a calculator. With the evolution of tools like ChatGPT, Claude, and Cursor, a world where apps materialized without writing code became reality. This was the "vibe coding" era.
The problem came next.
The moment you said "now add scientific calculator features," the code you just had got completely rewritten. The first calculator had been generated as "the shortest path to working code"—no consideration for future extensions. No AST (abstract syntax tree) for operator precedence, no interfaces abstracting operations. With each new request, the code spaghettified.
This wasn't AI's fault. "Build me a calculator" contains no information about "I plan to extend it like this in the future," so AI returns the shortest implementation that works in the moment. Perfectly rational behavior.
What made things worse was that requirement changes accumulated not as "diffs" but as "contradictions" in the code. When you kept saying "actually, do it this way" and "forget the previous version," a human developer could implicitly ignore old specs. But AI diligently tried to reconcile contradictions within its context. The result: exception handling, conditional branches, and flags proliferated, producing code nobody could read.
The Spec-Driven Correction: Kiro Arrives with "Let's Define Requirements First"¶
The answer to this problem came in the form of "Kiro," a coding agent from AWS. Preview-launched in July 2025, this tool put "Spec-Driven Development" front and center.
The philosophy was simple. Instead of jumping straight to code, first create three artifacts: Requirements, Design documents, and Tasks (task breakdown with test plans). If building a calculator, you'd first work with AI to organize "what features will we extend in the future" and "what test cases are needed" before starting development. It was an approach to solve vibe coding's failures through "structuring."
Notably, Kiro offers both vibe coding mode and spec-driven mode, presenting a "Vibe or Spec?" choice at startup. Rather than forcing spec-driven development, it's designed to allow gradual transition from prototyping to specification. This flexibility, which embraces both agile and waterfall perspectives, deserves recognition.
The Challenges Kiro Exposed in Spec-Driven Development¶
So how was the spec-driven approach itself received?
According to reports, Amazon stated that "as of January 2026, approximately 70% of software engineers had used Kiro at least once." However, given that it was deployed almost as a default internal tool, this number should be read more as an "exposure" metric than a "adoption" metric. The retention rate among those who used it once has not been disclosed.
Meanwhile, a February 2026 Business Insider report noted that approximately 1,500 engineers voiced support for official adoption of Claude Code on Amazon's internal forum. Given Amazon's engineering workforce of tens of thousands, 1,500 could be seen as a minority—or as a sign of frustration strong enough to speak up on an internal forum. Numbers alone don't tell the whole story, but the atmosphere was clearly not one of company-wide satisfaction with Kiro.
Similar feedback emerged externally. On Hacker News, reports surfaced that "I just wanted to build a small helper tool, but the spec-driven workflow slowed development down." InfoQ articles also covered developer frustration with the heaviness of the spec-driven approach. The question of when to use specs vs. code vs. prompts became a central debate in development teams.
What these reactions revealed wasn't that "spec-driven development failed." Rather, it was friction from the separation between the specification creation process and the development execution process. The two-stage workflow of creating Requirements → Design → Tasks files and then developing based on them didn't mesh with the speed of agent-based development in some cases. Especially for small-to-mid-scale tasks, the overhead of spec creation exceeded the implementation itself—an inversion phenomenon.
Writing specs isn't inherently bad. The question was "when and at what granularity to write specs."
Planning and Execution Converge: Claude Code's Plan Mode and CLAUDE.md¶
From here, alternative approaches emerged to address the spec-driven challenge of "right philosophy, but too heavy in practice."
Around the same time in June 2025, Claude Code introduced its Plan mode. Toggled with Shift+Tab, this mode provides a read-only environment to analyze the codebase, formulate a plan, get user approval, and then proceed to implementation. The key difference from Kiro: planning and execution happen continuously within the same context. "Here's my approach" → approval → implementation flows in one breath. No need to write specs into separate files.
Of course, Plan mode doesn't generate comprehensive specification documents, so for large-scale projects or multi-team consensus building, document-generation approaches like Kiro's remain better suited. It's not a silver bullet, but the idea of absorbing "the weight of specs" within the development flow was novel.
And there was another notable development in the same vein: the rise of "project rule files" like CLAUDE.md and Cursor's .cursorrules.
These are neither specification documents nor prompts. They're "shared context" files placed at the project root for AI. Coding conventions, architectural principles, approved libraries, patterns to avoid—essentially the kind of information you'd share with a new human team member during onboarding, now shared with AI too.
The decisive difference from Kiro: these files live "inside" development rather than "outside" it. They exist in the same repository, under the same version control as the code, and AI automatically reads them as context every time. Developers don't need to consciously "load" them.
This doesn't abandon spec-driven thinking. Rather, it transforms specs from "documents" into "environment." You don't write specs—you develop within them. The fact that how you write CLAUDE.md dramatically changes agent output quality is proof this mechanism works.
The Skills Explosion: From "Project Rules" to "Work Patterns"¶
If CLAUDE.md represents "project-wide rules," the rapidly emerging evolution is "Skills."
Skills are packaged procedures, best practices, and output templates for specific tasks. Word document generation rules, PowerPoint layout standards, PDF processing procedures, spreadsheet format specifications—each managed as an independent Skill file. AI loads only what's needed for the task at hand and follows the recipe.
The distinction from CLAUDE.md is easy to grasp with an analogy. CLAUDE.md is a "team constitution"—it defines cross-project policies like "use TypeScript," "write tests with vitest," and "API errors follow RFC 7807." Skills, on the other hand, are "operations manuals"—they define reproducible procedures for specific tasks like "for PowerPoint, use python-pptx, 16:9 layout, minimum 14pt font."
Cramming everything into a single CLAUDE.md causes bloat and noise. Skills solve this as "task-scoped knowledge bases." In programming terms, it's like modularizing a monolithic configuration file.
What makes this interesting is that it's not limited to coding. Document generation, data analysis, spreadsheet creation, PDF processing—Skills apply to tasks with no direct connection to programming. What started as "AI coding practices" has expanded into "practices for getting AI to do work."
The Knowledge Problem Skills Solve¶
Equally important is that Skills are beginning to function as "devices for converting tacit team knowledge into explicit knowledge." The know-how that senior engineers used to teach juniors verbally—"here's how we do things on this project"—gets written down as Skill files. Then AI can reproduce that know-how. What was personal expertise becomes team assets.
Viewed differently, this is knowledge management being rediscovered in the AI coding context. Documents that nobody read on Confluence now get reliably read and executed by AI when written as Skills. Ironically, the fact that AI became the "reader" of documentation means the incentive to write documentation is finally working for the first time.
Where We Are Now: More Options, but Unsolved Problems Remain¶
Looking at this trajectory, it's more accurate to say that options have multiplied rather than that AI instruction methods have "evolved" in one direction.
| Phase | Approach | Best suited for |
|---|---|---|
| Vibe coding | No instructions. AI decides freely | Prototypes, small tools |
| Spec-driven (Kiro) | Create comprehensive specs upfront | Large projects, consensus-building |
| Rule files (CLAUDE.md) | Manage project policies alongside code | Mid-scale continuous development |
| Skills | Modularize task-specific procedures | Stabilizing quality of repetitive tasks |
The pendulum has swung from "teach nothing" to "teach everything" and is settling on "teach what's needed, when it's needed." This is essentially "separation of concerns" from software design.
However, within this convergence, unresolved issues remain. They operate at different layers and can't be addressed by any single approach.
Technical constraint: the context limit problem. AI's context windows keep expanding—Claude Opus 4.6 reached 1 million tokens conditionally. Yet it's still impossible to make AI comprehend an entire project at once. For large codebases, the judgment of "what range to show AI" is itself becoming a new skill. Skills' modularization is a pragmatic response to this constraint, but not a fundamental solution.
Methodological challenge: the testing relationship. AI writes code that AI tests. This structure has a fundamental problem: the same model sharing the same blind spots. The pattern of humans defining test "intent" while AI implements is becoming mainstream, but it's still developing. Approaches like separating "Skills for defining test intent" from "Skills for implementing tests" and assigning them to different models may be explored in the future.
Organizational challenge: the "can't fix it" problem. Prototypes built with vibe coding increasingly remain in production. They work, so nobody fixes them. But nobody understands the code inside. If this scales, "AI-generated legacy code" will emerge as a new category of technical debt. This can't be solved by practices or tools—it's a question of how organizations choose to face it.
These three appear to be independent challenges, but they're connected at the root. Because context constraints exist, AI misses the big picture; because it misses the big picture, test coverage has gaps; because test coverage has gaps, "it works so don't touch it" code accumulates. Different layers, but a linked chain.
What Lies Ahead¶
Automated Skill generation has already begun. Anthropic's official skills repository provides a skill-creator Skill—instruct "create a Skill for this task" and AI generates the Skill file itself. Community sharing and distribution of Skills is also progressing.
Two next steps are emerging. First, a world where Skills are automatically extracted and accumulated from developer-AI collaboration history. "I've summarized last week's deployment work as a Skill for you," AI suggests. Knowledge accumulation becomes a natural byproduct of development.
Second, optimization of Skill combinations. Apply "frontend Skill," "testing Skill," and "deployment Skill" in chain to execute a feature addition end-to-end in one shot. A transition from individual task automation to full workflow automation.
But before painting too optimistic a future, there's a question worth pausing on. When Skills accumulate and become mundane infrastructure, what problem comes next?
Probably "Skill rot." Libraries get updated, architecture changes, team policies shift. But Skill files get left behind. AI diligently follows Skills that have diverged from reality, actually degrading quality. The classic problem of documentation going stale returns in a more severe form precisely because AI follows instructions faithfully.
Or "Skill conflicts." A security Skill says "sanitize all inputs" while a performance Skill says "don't add unnecessary processing." Humans can judge priority by context, but for AI this becomes a difficult-to-resolve conflict. The more Skills accumulate, the higher the cost of managing contradictions.
Ultimately, Skills are not a silver bullet either. They abstract the problem one level higher, but the fundamental challenge of "how to manage knowledge" persists in new forms.
Summary: Practices Keep Changing, but Principles Don't¶
Vibe coding → spec-driven → rule files → Skills. Looking back at this progression, we notice that classic software engineering lessons keep repeating in new forms.
"Decide what to build before building"—this has been said since the waterfall era. Agile changed it to "decide small, build small." In the AI coding context, it's evolving further into "share the policy, delegate judgment to AI." And Skills represent the next step: "accumulate shareable policies in reusable form."
What changed is the means, not the principles. And the next change will likely be yet another expression of those same principles.
Tools change. Practices change. But the almost-too-obvious fact that "clearer intent produces better results" never changes. The evolution of AI coding might just be the challenge of how far we can automate and streamline that "obvious truth."