The Problem with Vibe Coding
AI has dramatically accelerated software development. We can describe what we want, let an AI coding agent implement it, review the result, and continue iterating. For prototypes and small experiments, this approach, often called vibe coding, can work surprisingly well. The difficulty appears when the project becomes larger and needs to survive for months or years. The original conversation with the AI eventually disappears from the active context. Decisions made during early development may exist only in old conversations. Requirements evolve. New developers become involved. Bugs appear months later. The AI working on the project today may no longer have the context that existed when the original code was generated. The real challenge is therefore not merely how quickly AI can generate code. It is how we preserve the knowledge required to understand, maintain, extend, and repair that code. This is where Spec-Driven Development changes the model.
The Spec-Driven Development Methodology
Instead of allowing requirements, architecture, and implementation decisions to live primarily inside temporary conversations, we maintain them as persistent project artifacts. Kiro implements this approach through steering files and Specs. Its Specs formalize development around requirements, design, and executable implementation tasks, while steering files provide persistent project context across interactions. When life michael asked ChatGPT to compare the leading tools supporting Spec-Driven Development, Kiro received the strongest overall evaluation for developers looking for a complete, integrated SDD workflow. The comparison also makes clear that different tools have distinct strengths and that no single tool is universally superior in every situation. You can read the full comparison here: Detailed Comparison of Spec-Driven AI Tools.
From Steering Files to Deployment-Ready Software
The development model recommended by life michael separates the project into clearly controlled phases, that are based on the very same phases recommended by the Kiro IDE.
Start with The Steering Files
Before asking AI to develop the system, we establish its persistent context. The project owner collects the relevant business, product, operational, technical, and organizational information. This information is organized and incorporated into the project’s steering files. Kiro uses steering files to give its AI persistent knowledge about the project. Its standard project steering can describe the product, technology stack, and project structure, and additional steering files can define project-specific standards, policies, conventions, and other constraints. This gives the AI something much more reliable than an old chat conversation: a maintained body of project knowledge that can continue guiding development.
The Project Specifications
Once the steering documents are ready, we move forward with the most important part of the process: The Specification.Kiro Specs normally maintain three central artifacts: requirements.md, design.md, and tasks.md. Together they describe what the system should do, how it should be designed, and how the implementation should be performed.
The first step is preparing the requirements. The project owner appoints a project manager who understands the business requirements and can make product decisions. With assistance from life michael and AI inside Kiro, the project manager transforms those needs into detailed, structured requirements. Particular attention is given to EARS-style requirements and testable acceptance criteria. Kiro’s Requirements-First workflow explicitly supports system behavior written in EARS form and emphasizes reviewing requirements for completeness, edge cases, and testability before moving to design. This is arguably the most important stage of the entire project. If the requirements are incomplete, ambiguous, or incorrect, faster AI development only allows us to build the wrong system faster. The requirements should also describe the expected UI/UX in sufficient detail, including user flows, important screens, states, interactions, validation behavior, and relevant edge cases.
Once the requirements are sufficiently mature, the project moves into the design document phase. This is where life michael provides significant technical input. Based on the business requirements and steering documentation, we finalize the technology stack, architectural structure, components, interfaces, data models, integration strategy, testing approach, and other major technical decisions. Kiro’s design phase is specifically intended to translate approved requirements into system architecture, components, interfaces, data models, technology choices, error handling, and testing strategy.
After the design is reviewed, the project moves to the task list. Kiro transforms the requirements and design into discrete implementation tasks. These tasks can be reviewed, adjusted, tracked, and then executed by AI. At this point, AI performs much of the implementation work step by step. The project manager remains responsible for monitoring the process, reviewing results, making business decisions, and identifying deviations. life michael assists when architectural, technical, specification, or implementation questions arise.
Testing is part of this process. The task plan includes automated testing, including unit tests and, where appropriate, property-based testing. Kiro derives testable properties from EARS-formatted requirements and uses property-based testing to evaluate implementation behavior across many generated inputs.
Poject Fine Tuning
Once the AI has completed the implementation tasks, the project should be running as a coherent system. Development then enters a fine-tuning phase. At this point, most changes should be relatively small: UI/UX adjustments, wording changes, behavioral refinements, small missing features, integration corrections, and small bug fixes. The project owner (or project manager) handles this process with assistance from life michael where required. Because the specification remains available, later fixes do not need to rely exclusively on reconstructing the intent of old AI conversations. Kiro also provides dedicated Bugfix Specs that distinguish current incorrect behavior, expected behavior, and behavior that must remain unchanged, helping structure fixes and regression prevention. Once this phase is complete, the software is ready to move toward deployment.
Deployment Requires Dedicated DevOps Ownership
Application development and production operation should not be treated as the same responsibility. The deployment phase should be managed by a dedicated DevOps engineer appointed by the project owner. The DevOps engineer should take responsibility for the production environment and its long-term operational quality: cloud infrastructure, deployment pipelines, environments, secrets, observability, backups, security controls, scaling, logging, monitoring, recovery procedures, and related operational concerns. life michael can work closely with the DevOps engineer on the architecture and deployment process, but the project owner should maintain dedicated DevOps responsibility for the system. This becomes increasingly important after the initial development ends. AI may dramatically accelerate software construction, but a production system still requires disciplined operational ownership. Maintaining this separation contributes to stability, security, maintainability, and long-term quality.
Having More Control and Better Value
This model was designed to achieve a strong value-for-money ratio. AI performs a significant portion of the implementation work. The project manager concentrates on product requirements, validation, decisions, and supervision. life michael provides expertise where it creates the greatest value: requirements methodology, architecture, technology choices, AI-assisted development practices, troubleshooting, and technical guidance. Just as importantly, the project owner remains in control. The specifications do not belong to an external development company. The steering documents, requirements, architecture, tasks, source code, tests, and operational knowledge remain part of the project itself. This matters both during development and afterward.vThe goal is not to make the project owner dependent on life michael. The goal is to establish a structured process in which the organization can understand what is being built, why decisions were made, what remains to be done, and how the system can continue evolving. AI becomes an implementation force multiplier rather than a replacement for ownership.
Practical Step-by-Step Consulting Process
We, at life michael, have started to build software using the Spec-Driven Development methodology, long before Kiro IDE was available to the public. We got early access to this IDE. We developed all ventures you can find at zindell.com with Kiro and in accordance with the Spec-Driven Methodology principles. The following lists the steps we recommend following. This is not a final list. Changes might take place in accordance with changes that take place during the development (e.g., a decision to add a new feature that wasn’t mentioned in the original specs).
[1] Introductory Meeting
We begin with a meeting (sometimes, more than one meeting is needed) in which we examine the project together. The objective is to understand the business problem, scope, major components, constraints, existing assets, dependencies, and expected results. We then establish a general plan for moving forward. The discussion also considers changes that may be needed inside the business itself, including documentation practices, responsibilities, workflows, decision processes, and other adjustments required to make the organization better aligned with AI-assisted development. The introductory meeting(s) also include(s) a short practical introduction to working with Kiro IDE and the Spec-Driven workflow.
[2] Preparing the Steering Documents
Following the introductory meeting, the project owner collects and organizes all relevant existing documentation. Additional documents should be created where the introductory meeting revealed missing business rules, policies, terminology, workflows, standards, technical constraints, or other important project knowledge. The relevant information is then incorporated into the project’s steering files inside Kiro. These documents become part of the persistent context guiding subsequent AI-assisted development.
[3] Fine Tuning Meeting
We meet again after the initial steering material has been prepared. During this meeting, we review the available information, resolve inconsistencies, clarify expectations, identify missing documentation, and verify that the project is sufficiently defined to begin formal requirements work. Where important information is still missing, the project owner prepares it before proceeding.
[4] Preparing The Requirements
The project owner, or the project manager appointed by the owner, then prepares the requirements directly within the Kiro IDE. The steering documents provide the background context. AI inside Kiro assists with transforming business intentions into precise requirements, while life michael provides additional methodological and technical assistance where necessary. Requirements should cover functionality, business rules, error conditions, edge cases, integrations, security-related behavior, and detailed UI/UX expectations. Whenever appropriate, requirements should be expressed using clear EARS-style acceptance criteria so that expected behavior remains explicit and testable.
[5] Preparing the Design Document
Once the requirements are sufficiently complete, life michael takes the lead on the design phase. Based on the steering information and approved requirements, the technology stack and overall architecture are finalized. This includes the major technologies, application structure, services, components, databases, APIs, external integrations, architectural patterns, security considerations, testing strategy, and other significant technical decisions. The objective is to ensure that AI does not independently make fundamental architectural decisions simply because they were never specified.
[6] Completing the Task List
After the design document is finalized, the implementation plan is transformed into a detailed task list. AI can then work through these tasks one by one, or execute independent tasks concurrently where the workflow permits, while maintaining their relationship to the requirements and design. The project owner or project manager monitors implementation, reviews the results, and approves important decisions. life michael remains available for assistance when technical, architectural, specification, or implementation issues arise. Tasks should also incorporate automated testing, including conventional unit tests and suitable property-based tests, so that testing becomes part of implementation rather than an activity postponed until the end.
[7] Alpha Version of the Project
When AI completes the planned implementation tasks, the project reaches its alpha stage. The complete application can now be reviewed as a working system. The remaining work typically involves smaller changes: UI/UX refinements, behavioral corrections, integration adjustments, missing edge cases, and bug fixes. The project owner or project manager drives this finalization phase, with assistance from life michael when needed.
[8] Beta Version and Deployment
Once project finalization is complete, the project enters beta testing. At this stage, the DevOps engineer appointed by the project owner deploys the application to the selected cloud environment. The DevOps engineer works with life michael where necessary to ensure that the deployment architecture properly reflects the application’s technical requirements. Beta testing then provides the opportunity to validate the system under realistic conditions before production release.
The result is not simply software generated by AI. It is a software system developed through a documented, controlled, maintainable Spec-Driven process, in which AI accelerates implementation while the project owner retains control over the product, specifications, architecture, and future direction.
