Love this. I've been saying "better specs" for AI-generated projects for at least a year. The curious thing is that I wonder how much more productive my human developers would have been had I been as committed to giving them clearer/better directions over this same period. :-)
Thanks for the thoughtful comment Ross! Would love to hear their thoughts if you point them towards SpecKit (or the other spec tools we mentioned). It’s crazy how fast things are evolving!
I went ahead and subscribed so I could see where you mentioned other spec tools. Pretty clever way to draw me in. :-) Truth is I just wanted to be one of the cool kids, anyway.
Regardless, I'm looking into SpecKit. Got it installed yesterday... baby steps, but in the right direction. I'll let you know how it goes.
Well this is certainly a step in the right direction.
The issue is that sometimes, even the devs won't know what they don't know.
In your case, you're a technologist with 20 years of experience, and so, you seem to have an encyclopedic knowledge about the actual process of developing an app, down to the programming languages involved, along with all the nooks and crannies about what could go wrong (data storage/security/governance, unit tests, etc.).
But what of this sort of paradigm assisting subject-matter experts? For instance, let's take this fitness app idea. One of my best friends is a fitness trainer, but isn't particularly well-versed in app development. Would this paradigm be able to talk him through front-end/back-end development, such as front-end login UIs, or back-end data storage, governance, security, etc.?
Suppose he says "I want users to be able to journal their meals and workouts, and here's my company logo". How well would it be able to walk him through the various elements of app building in order to build all the support that a fitness app may need?
Or is this paradigm only something that really works for someone that already knows the minutiae of software architecture, but just acts as a time-saver for the actual doing of the implementation?
Because the reason vibe coding runs into problems is that sure, the developer themselves don't know every minutiae about what they want--but shouldn't an LLM, trained on the entirety of knowledge on the internet, be able to act as a guide to present to people a checklist of the necessary elements they'd need, but may not know about?
Because you make spec-driven development sound fantastic, provided someone has the experience and skillset of a software architect. But if they're a subject matter expert as opposed to a software architect, it seems like this might as well be off-limits to them.
We were discussing this. So far I think you still need an understanding of languages and good architecture principles.
What that means for advice to people looking to get into software is that I would focus on learning about clean architecture and system design over learning how to reverse a linked list by hand.
I've come up with a four step process to vibe code using formalized best practices. It saves a ton of time and the results are both quick and reliable.
Step 1: Use ChatGPT or Claude to generate a product requirements doc (PRD) for the app you're working on. I have a template file I provide the bot so it knows what I'm looking for in the PRD. If you don't have one I recommend creating one first. There are tons on Github you can use as a starting point.
Step 2: Have Claude or ChatGPT (reverse of step 1) generate a series of prompts to create the application. The reverse is the key part here, you want to separate the functions. Basically using one of them as the product manager defining requirements and the other as the tech lead refining those to something an engineer can build from. Using different models helps avoid assumptions baked into either of them.
Step 3: Feed those prompts to Cursor and let it cook.
Step 4: Test and iterate as needed.
If you want to really go nuts, feed the same prompt or slight variants into multiple Cursor agents but have each focus on one part of the overall project. This requires setting your PRD template to include an API contract so each agent knows how to connect the various components. You don't want your frontend sending to /user and your backend listening on /u.
Love this. I've been saying "better specs" for AI-generated projects for at least a year. The curious thing is that I wonder how much more productive my human developers would have been had I been as committed to giving them clearer/better directions over this same period. :-)
Thanks for the thoughtful comment Ross! Would love to hear their thoughts if you point them towards SpecKit (or the other spec tools we mentioned). It’s crazy how fast things are evolving!
I went ahead and subscribed so I could see where you mentioned other spec tools. Pretty clever way to draw me in. :-) Truth is I just wanted to be one of the cool kids, anyway.
Regardless, I'm looking into SpecKit. Got it installed yesterday... baby steps, but in the right direction. I'll let you know how it goes.
Awesome! We are working on another post about Dagger for parallel agentic coding. Stay tuned!
This is exactly what I needed exactly when I needed it. Phenomenal post Carly!
Oh excellent!!! I’m so glad!
Well this is certainly a step in the right direction.
The issue is that sometimes, even the devs won't know what they don't know.
In your case, you're a technologist with 20 years of experience, and so, you seem to have an encyclopedic knowledge about the actual process of developing an app, down to the programming languages involved, along with all the nooks and crannies about what could go wrong (data storage/security/governance, unit tests, etc.).
But what of this sort of paradigm assisting subject-matter experts? For instance, let's take this fitness app idea. One of my best friends is a fitness trainer, but isn't particularly well-versed in app development. Would this paradigm be able to talk him through front-end/back-end development, such as front-end login UIs, or back-end data storage, governance, security, etc.?
Suppose he says "I want users to be able to journal their meals and workouts, and here's my company logo". How well would it be able to walk him through the various elements of app building in order to build all the support that a fitness app may need?
Or is this paradigm only something that really works for someone that already knows the minutiae of software architecture, but just acts as a time-saver for the actual doing of the implementation?
Because the reason vibe coding runs into problems is that sure, the developer themselves don't know every minutiae about what they want--but shouldn't an LLM, trained on the entirety of knowledge on the internet, be able to act as a guide to present to people a checklist of the necessary elements they'd need, but may not know about?
Because you make spec-driven development sound fantastic, provided someone has the experience and skillset of a software architect. But if they're a subject matter expert as opposed to a software architect, it seems like this might as well be off-limits to them.
We were discussing this. So far I think you still need an understanding of languages and good architecture principles.
What that means for advice to people looking to get into software is that I would focus on learning about clean architecture and system design over learning how to reverse a linked list by hand.
The spec-driven approach is underrated. 'Vibe coding' works best when you're clear about what you want, even if fuzzy on implementation.
I went through this evolution - from prompting for code to prompting for specs. The quality difference is dramatic.
Wrote about rediscovering the joy of building: https://thoughts.jock.pl/p/cursor-vs-vibe-coding-tools-2025
I've come up with a four step process to vibe code using formalized best practices. It saves a ton of time and the results are both quick and reliable.
Step 1: Use ChatGPT or Claude to generate a product requirements doc (PRD) for the app you're working on. I have a template file I provide the bot so it knows what I'm looking for in the PRD. If you don't have one I recommend creating one first. There are tons on Github you can use as a starting point.
Step 2: Have Claude or ChatGPT (reverse of step 1) generate a series of prompts to create the application. The reverse is the key part here, you want to separate the functions. Basically using one of them as the product manager defining requirements and the other as the tech lead refining those to something an engineer can build from. Using different models helps avoid assumptions baked into either of them.
Step 3: Feed those prompts to Cursor and let it cook.
Step 4: Test and iterate as needed.
If you want to really go nuts, feed the same prompt or slight variants into multiple Cursor agents but have each focus on one part of the overall project. This requires setting your PRD template to include an API contract so each agent knows how to connect the various components. You don't want your frontend sending to /user and your backend listening on /u.