The author also used GPT-5.6 to write the prompt. This did involve giving GPT-5.6 access to his previous work and a back and forth process (so definitely still used the author's expertise to some degree), but the prompt itself is also largely AI generated.
What's the difference between using GPT to write the prompt to GPT, and "thinking"? The LLM uses the first tokens to predict more tokens, and then uses those tokens to predict even more tokens.
Roughly speaking it is the difference between having a contractor go out and do some work and having that same contractor first come up with a plan to do some work, run that by you, and then go out to do that work.
Part of it is as a another comment in this chain mentions the chance to review the prompt. Part of it is that it forces the AI system to plan things in a certain order, in much the same way that forcing the contractor to write the plan out first forces the contractor to proceed in a certain predefined order that may (or may not!) be better at getting to a final answer.
Certainly. This feels similar, to me, to how building complex software with LLMs works today in practice. You need to know a lot to set up goals and guardrails and verify outputs. For me, making the bits change was always the fun part, not tangling with text in my editor, though that had its moments.
We're also at the point where you can roll out context to your entire organisation. I created an app for our m365 Cowork and deployed it to everyone who develops software. It does a couple of things, but it main knows our compliance policies and can guide developers through writing the documentation needed for NIS2 compliance. It also guardrails against non-approved packages, and helps developers find alternatives, or if none can be reasonably found, how to get a new package/dependency approved (or rejected).
A few months back this would be something every developer kind of did on their own. Maybe they shared skills, we certainly encouraged it and tried to do all the change management things, but nobody really had the same versions of the skills. Which was horrible in the deployment pipelines, something like the compliance documentation often had to go back and forth several times before it could be approved. Now it's just there, for everyone.
In a year or two, I expect a lot of these things to have become even more standardized. So that we don't even really have to build our own apps, but can simply use the ones in the catalog with minimal configuration (and that config will likely only be necessary because I'm from a tiny country that nobody will maintain standards for).
This made me chuckle because it's so true. So much detailed steering and finagling in the past, now I point the agent to a bunch of information sources, skills, similar repositories that might hold useful input and tell it very roughly what I need and off it goes, I'll grab coffee.
The author also used GPT-5.6 to write the prompt. This did involve giving GPT-5.6 access to his previous work and a back and forth process (so definitely still used the author's expertise to some degree), but the prompt itself is also largely AI generated.
What's the difference between using GPT to write the prompt to GPT, and "thinking"? The LLM uses the first tokens to predict more tokens, and then uses those tokens to predict even more tokens.
Roughly speaking it is the difference between having a contractor go out and do some work and having that same contractor first come up with a plan to do some work, run that by you, and then go out to do that work.
Part of it is as a another comment in this chain mentions the chance to review the prompt. Part of it is that it forces the AI system to plan things in a certain order, in much the same way that forcing the contractor to write the plan out first forces the contractor to proceed in a certain predefined order that may (or may not!) be better at getting to a final answer.
The ability to correct the plan/prompt.
Certainly. This feels similar, to me, to how building complex software with LLMs works today in practice. You need to know a lot to set up goals and guardrails and verify outputs. For me, making the bits change was always the fun part, not tangling with text in my editor, though that had its moments.
Yeah, back to the gold-in-gold out use of LLMs.
I was thinking this past week I have gotten so lazy w my prompting via CLIs.
Back in the before I had put such discipline into my prompting and supporting context.
Now I’m like, “look here and here and here are some tools, and /skill /skill okay go.”
Or “restate this request in your own words and enrich it as appropriate handling any gaps. Okay go”
We're also at the point where you can roll out context to your entire organisation. I created an app for our m365 Cowork and deployed it to everyone who develops software. It does a couple of things, but it main knows our compliance policies and can guide developers through writing the documentation needed for NIS2 compliance. It also guardrails against non-approved packages, and helps developers find alternatives, or if none can be reasonably found, how to get a new package/dependency approved (or rejected).
A few months back this would be something every developer kind of did on their own. Maybe they shared skills, we certainly encouraged it and tried to do all the change management things, but nobody really had the same versions of the skills. Which was horrible in the deployment pipelines, something like the compliance documentation often had to go back and forth several times before it could be approved. Now it's just there, for everyone.
In a year or two, I expect a lot of these things to have become even more standardized. So that we don't even really have to build our own apps, but can simply use the ones in the catalog with minimal configuration (and that config will likely only be necessary because I'm from a tiny country that nobody will maintain standards for).
1 reply →
This made me chuckle because it's so true. So much detailed steering and finagling in the past, now I point the agent to a bunch of information sources, skills, similar repositories that might hold useful input and tell it very roughly what I need and off it goes, I'll grab coffee.
1 reply →