I’ve found that Claude code has a smart pre work process where it converts anything you say into a structured to do list. It’s a great reinforcement for how you should already approach what you tell it to do
I’ve found a similar rule of thumb: the quality of the spec determines the quality of the autocomplete. Feeding the model rich scaffolding (error, intent, expected output) feels like onboarding a junior eng who never sleeps.
Half of these are fine. Most of the rest are just "be specific" wearing different hats.
The real test isn't whether you can write a prompt that works on your laptop at 2am with infinite retries. It's whether it holds up in a 5 minute round with someone else's prompt aimed at the same task. Spoiler: most don't. The number of times my "clean" 200 word prompt has been smoked by someone who just wrote "do X. don't be stupid." is embarrassing.
We made http://clashofprompt.io because reading playbooks only gets you so far, its free to play
Though it is true that there are some prompts that are truly bad (like fix these two bugs and add these three features) some of the tips in this post are only correct on the day they were written.
This is because AI is improving all the time.
I gave some of the "bad" prompts to Gemini and got exactly the responses I expected.
Coming to this a bit late but your debugging formula (expected vs got vs input) translates directly to Codex CLI. Terminal agents need even tighter scoping than chat prompts though. A compound task that ChatGPT handles fine will send Codex sideways; it processes things sequentially and loses the thread. Ended up documenting the six patterns I keep coming back to for CLI prompting: https://reading.sh/how-to-actually-get-good-results-from-codex-cli-98d412eb3ff7?sk=be1b8b631f39c5ac4edec722c9eb111d
In the unlikely event anyone is reading this: the "React Hook dependency issues" section lead me down an interesting rabbit hole. Namely, it didn't seem like there was actually an infinite re-render loop there - but had quite a few LLM models insist that there actually is one.
The real answer is: of course there isn't. The useState setter functions are guaranteed to be the same reference each time, so while including them in the dependency array is pointless, it also doesn't cause any issues.
One thing is missing here. Prompt your LLM to ask for context it deems relevant and remind it that yourself might make errors that it should point out. o3 regularly asks for clarification and specific files it suspects should be in my codebase since I added the personification in ChatGPT.
For frontend testing and debugging, Browserbase MCP will be really helpful as it can show the coding agent issur with a screenshot.
I’ve found that Claude code has a smart pre work process where it converts anything you say into a structured to do list. It’s a great reinforcement for how you should already approach what you tell it to do
I’ve found a similar rule of thumb: the quality of the spec determines the quality of the autocomplete. Feeding the model rich scaffolding (error, intent, expected output) feels like onboarding a junior eng who never sleeps.
This is awesome! I built a tool that checks prompts against these and suggests improvements: https://promptchecker.withcascade.ai/
Half of these are fine. Most of the rest are just "be specific" wearing different hats.
The real test isn't whether you can write a prompt that works on your laptop at 2am with infinite retries. It's whether it holds up in a 5 minute round with someone else's prompt aimed at the same task. Spoiler: most don't. The number of times my "clean" 200 word prompt has been smoked by someone who just wrote "do X. don't be stupid." is embarrassing.
We made http://clashofprompt.io because reading playbooks only gets you so far, its free to play
Though it is true that there are some prompts that are truly bad (like fix these two bugs and add these three features) some of the tips in this post are only correct on the day they were written.
This is because AI is improving all the time.
I gave some of the "bad" prompts to Gemini and got exactly the responses I expected.
For instance
```
// converts array of users to a map by ID
function mapUsersById(users) {
const userMap = {};
for (let i = 0; i <= users.length; i++) {
const user = users[i];
userMap[user.id] = user;
}
return userMap;
}
// Example usage:
const result = mapUsersById([{ id: 1, name: "Alice" }]);
```
Why isn’t my mapUsersById function working?
Came back with
The issue with your mapUsersById function is a classic "off-by-one" error in your for loop condition.
With two correct fixes.
Coming to this a bit late but your debugging formula (expected vs got vs input) translates directly to Codex CLI. Terminal agents need even tighter scoping than chat prompts though. A compound task that ChatGPT handles fine will send Codex sideways; it processes things sequentially and loses the thread. Ended up documenting the six patterns I keep coming back to for CLI prompting: https://reading.sh/how-to-actually-get-good-results-from-codex-cli-98d412eb3ff7?sk=be1b8b631f39c5ac4edec722c9eb111d
In the unlikely event anyone is reading this: the "React Hook dependency issues" section lead me down an interesting rabbit hole. Namely, it didn't seem like there was actually an infinite re-render loop there - but had quite a few LLM models insist that there actually is one.
The real answer is: of course there isn't. The useState setter functions are guaranteed to be the same reference each time, so while including them in the dependency array is pointless, it also doesn't cause any issues.
One thing is missing here. Prompt your LLM to ask for context it deems relevant and remind it that yourself might make errors that it should point out. o3 regularly asks for clarification and specific files it suspects should be in my codebase since I added the personification in ChatGPT.
readable code is more important here:
const sortedProducts = [...filteredProducts].sort((a, b) =>
sortOrder === 'asc'
? a.name.localeCompare(b.name)
: b.name.localeCompare(a.name)
or if you want to get technical make it a hashmap :)
const sortedProducts = [...filteredProducts].sort((a, b) => sortedOrder[var_here])
sortedOrder = {
asc: a.name.localeCompare(b.name)
dec: b.name.localeCompare(a.name)
}
forget the conditional altogether