I'm glad you liked it. Absolutely experiment and see what works. You should test the impact that "Dos and Don'ts" versus "Definition_Of_Done" has on thinking models ;)
Thanks for the post. I think I’ve been doing this in my practice but in an intuitive, non-structured way. It’s nice to see an acronym I can use to remember how to construct prompts like these when needed. Cheers!
If its a small job and especially once off then absolutely! This principle starts making a lot more sense when you do something more complex. You'd also maybe not use ALL parts of the C.R.A.F.T.E.D framework and bring in the full thing if you see you not getting the right results. Another place to think about this is in a pipeline or workflow that runs every day etc. Even if its small, if you want better success you want to add some structure and then some guardrails with checks post generation.
It may be in the very distant future, but currently, building Software is more popular than ever. With tools getting better and easier to get started -> it automatically incentivizes to create more Software.
"Software" itself is going to get generated at a pace we cannot imagine going forward. Its getting built into more and more things all the time so it's going to be around for a while. Now, the way we "create software" is going to get redefined multiple times and certain methods will go obsolete.
Thanks, Steven! This framework is super helpful.
A couple of tweaks I made on my end:
- I framed the last section as “Dos and Don’ts”.
- I swapped the XML tags for markdown headers.
I'm glad you liked it. Absolutely experiment and see what works. You should test the impact that "Dos and Don'ts" versus "Definition_Of_Done" has on thinking models ;)
Glad the article resonated! And like the tweaks!
Thanks for the post. I think I’ve been doing this in my practice but in an intuitive, non-structured way. It’s nice to see an acronym I can use to remember how to construct prompts like these when needed. Cheers!
Awesome Aaron, glad to hear that the article resonated and that you've been doing this in an intuitive way already!
Isn't this a bit overly bulky for these kind of of small jobs? I'm quicker writing the code than the prompt..
If its a small job and especially once off then absolutely! This principle starts making a lot more sense when you do something more complex. You'd also maybe not use ALL parts of the C.R.A.F.T.E.D framework and bring in the full thing if you see you not getting the right results. Another place to think about this is in a pipeline or workflow that runs every day etc. Even if its small, if you want better success you want to add some structure and then some guardrails with checks post generation.
It may be in the very distant future, but currently, building Software is more popular than ever. With tools getting better and easier to get started -> it automatically incentivizes to create more Software.
"Software" itself is going to get generated at a pace we cannot imagine going forward. Its getting built into more and more things all the time so it's going to be around for a while. Now, the way we "create software" is going to get redefined multiple times and certain methods will go obsolete.