The MVP

Summary

Shows how to leverage the constitution and completed feature specs to implement the remaining roadmap as an MVP in one large step. Demonstrates that good specs enable the agent to work autonomously on a larger scope.

Key Takeaways

• Good specs enable large-scale implementation: confidence in your constitution and feature specs allows implementing remaining roadmap at once
• MVP as extreme test of specs: if the result differs from expectations, it reveals gaps in planning
• Let the agent validate: use the agent to check specs against the implemented MVP, sharing findings with stakeholders

视频信息：The MVP

---

English Script

We made a lot of progress. Two features implemented with our spec workflow. But management just asked, of course, for an MVP. Have we made enough progress to do an experiment? Let’s do a variation of our standard feature spec prompt. This time we’ll tell it to implement the rest of the roadmap and give some guidance about existing feature specs. In general, you should only implement such a large chunk if you feel confident in the quality of your constitution and spec. The better the context you provide your agent, the more confident you can be in getting a result aligned with your intentions. And you should be sure that you can handle review and validation. But since we’ve taken this risk now, let’s view the MVP as an extreme test of our constitution and completed feature specs. If we now get something different from what we wanted, it means we need to very responsibly carry out another replanning phase to eliminate whatever led the agent astray.

The agent asked me some questions. Again, these are good questions and recommendations. A lot of spec files start as a back and forth conversation with an agent. Finished with the interview and we selected Submit Answers. Let’s write the MVP specs to disk. It’s always good to review the specs. You’ll often notice incorrect assumptions the agent made to fill the gaps. Let’s give a quick look at the plan. the requirements and the validation. As always, we like to work in small steps with frequent commits. Let’s save the planning stages feature spec. We are finished with planning. It’s time for the agent to go do a big implementation step.

The agent now does a lot of work. Once it’s finished, it’s showtime. Let’s see the MVP. We’ll go to our scripts to run the application. As you can see, each section now has much more driven by sample data queried from the database. At this point, usually we would validate the code results, but this is an MVP. Let’s ask the agent to validate the specs. As it turns out, this was useful. The agent showed places where the MVP found holes in our planning. We can share this evaluation with the stakeholders for their MVP review, then merge or archive the branch. Our spec-driven workflow succeeded. After a constitution and two features, the MVP produced a useful demo, thanks to our guidance. Of course, not all software projects involve building an MVP. Many projects are so-called brownfield. They start from an existing code base. Next, let’s see how to introduce this workflow to legacy projects.