At this point software developers have realized Vibe Coding has its ups and downs. It’s amazing for experimentation or proof of concepts. But in the field, it can be more work than was realized. That’s because it can only build what it has seen. AI, once again, is only good at pattern recognition, which covers a wide spectrum of things.
“What’s past is prologue.” — William Shakespeare, The Tempest (Act 2, Scene 1)
But as Shakespeare says, so much of what comes before may not be as worthwhile as what is ahead. True innovation lies much in the unknown, in things that AI cannot see. And therein lies the need for Spec-driven development (SDD) where the developer has a good amount of control throughout the process of development. If they have control, then they can inject whatever innovation the app needs in a way that I never could.
Kiro is spec-driven development done well. Especially through the steering docs and spec files, the process appears at first too constricting but such wheels are necessary because it presupposes correctly that coding is mostly a standardized process.
All the steering docs and spec files can be created automatically but for truly spec-driven development where the developer is in the developer chair, one needs to edit manually where needed and not allow AI development to think for you. So manual edits are a key thing to spec-driven development. Manual edits and AI automation work and flow together as one ecosystem of programmer productivity. How and why that’s done can be considered an art form peculiar to each developer.
So the art of spec-driven development can be based on experience and talent. If it were all manual, much of it would be considered drudgery. If it were all vibe-coding, much of it would be considered as a flash-in-the-pan experiment. So the combination of manual dev and AI automation unleashes the skills of the software developer to create innovation in software applications. The drudgery (which is pernicious to the process of coming up with new ideas even in the moment) is omitted while the manual dev guides the process into innovative realms.
Spec-driven development is now everywhere so why in particular is Kiro so great? Well, in Kiro spec-driven dev is not an option. It’s baked in. It’s the Name of the Game. It’s the Big Enchilada. It’s the Top of the Barrel. It’s the Big Burger. It’s the Main Act. And the rest of this article will explore why that’s a good thing.
STEERING DOCS
Steering docs guide the whole of the app in general. This is the source of all truth for the app as a whole.
PRODUCT.MD
This is where you describe your app at a high level. The purpose, features, business objectives, etc. become documented and can be changed in this document as the process of building the app unfolds. This doc forces you to have a seen goal to move towards.
TECH.MD
This doc charts the frameworks, libraries, dev tools, tech constraints, etc. that you will use in your app. Throw in your favorite tools absolutely but you are ready to change them if they are not working out. The Steering files while they are a deep source of truth they are not written in stone. In Tech.md you have catalogued what you are using and where. You didn’t forget to do that because this doc is standardized.
STRUCTURE.MD
In this steering doc file organization, naming conventions and patterns are documented as another source of truth. Why not have these things document itself? Structure.md allows you to avoid drifting into ambiguity because the temptation is not to document these things at all. Then when something is changed that may create needless confusion, however slight. A source of truth for little things adds up.
OTHER STEERING DOCS
Steering docs that are not foundational are created by you as you see fit. Usually if there is subject matter that is very long in the foundational steering docs, then you can create it’s own steering doc for simplicity. So if you have a lot of coding standards, you can create coding-standards.md or a glossary.md if you have a plethora of unique terms and definitions used in other docs.
SPEC FILES
This can be about building your app as a whole or parts of your app. You can concentrate on one part of your app at a time. Or it can be to fix a part of your app instead of newly building it.
REQUIREMENTS.MD
Here is where you explain firstly if you are building or fixing the app. If building you will likely describe user journeys through your app and acceptance criteria of what is acceptable app use. This is more specific than the product.md file, which gives a general overview of the app, in the steering docs. If fixing something, you will describe the problems in your app.
Requirements.md and product.md is as foundational as it gets in describing your app. It becomes the source of truth as to what you app is and what it is supposed to do.
DESIGN.MD
In this file the system for the app is built. At least conceptually. In this intellectual engine of sequence diagrams and component design, the app comes together either through the intelligence of AI or the innovative intelligence of a human being, or most practically both together. In this part error handling and testing strategy is created and can be tweaked either now or later.
TASKS.MD
With tasks.md, discrete tasks are created and await implementation. They are trackable with status updates and can be run individually or all at once. Unlike in Vibe coding, this complete control of tasks segments the building of the app so that developers can really think about what they are building. They don’t lose understanding they may get in manual coding but rather their understanding is elevated even more. By forcing this segmentation, the developer realizes they can have a greater control of ensuring puzzling bugs do not enter their process.
OTHER SPEC FILES
Just like for Steering docs, other of your own spec files can be created. But the steering docs and spec files are not training wheels. They are usually deeply seated processes of software development. So that just like Steering docs, spec files usually come forth from the foundational spec files.
CONCLUSION
Why Spec-driven development (SDD)? Because you are preparing for when AI creates real innovation. And if there are new things on the horizon, AI can’t get a real grip on new things because it only perceives known patterns. Whatever is of real value will be what is innovative and those are things AI can’t see well. So spec-driven development is the future as AI expands into unknown realms.
For the software developer, SDD becomes the main driving player in their arsenal of tools. It will be both skill and art. And Kiro sits snugly at the top of spec-driven IDE’s because it has SSD baked in very well. So the constriction that Kiro gives is a virtue because by limiting AI you are allowing, in different ways, for the developer to inject innovation into the realm of coding.
