Writing
Spec-Driven Only Solves One Part of the Problem
The adoption of spec-driven approaches is rising. Fully automated loops centralize the execution of plans and specs, allowing teams to move forward by reviewing the spec or plan instead of the actual code. This is the right direction, but it still feels like it only solves half of the problem.
We are aligned on the direction, it is well documented, and it is easy to verify, yet we have still lost an important part, sharing our methodologies. How do you know what a good prompt looks like? What is special about this system, and what might be important to know? How did the team get burned, and how does that affect the way they find a solution?
Spec-driven is great, as long as we shift left as a whole team.
We need to create a deliberate room where we as a team can converge, share, and learn from each other. Maybe from our scars, maybe from our adventures, or even better from the approaches that make us more efficient.
Use spec-driven development, but use it with your team, use it in a room. Create the environment where all of you grow and learn.