Resist the temptation to prompt
There is an old engineering proverb I still like: resist the temptation to code.
It was never anti-code. It was a warning about momentum. When a problem feels urgent, code gives you something to do. It feels productive before you have earned confidence that you are solving the right problem.
AI tools created a new version of the same trap: resist the temptation to prompt.
Prompting can hide uncertainty
Prompting feels lighter than coding, so it is easier to do too early. You can ask for an implementation, a refactor, a system design, or a test suite before you have named the actual decision in front of you.
The tool will answer anyway.
That is useful when the target is clear. It is risky when the target is still foggy, because the answer can make a weak assumption feel like progress.
Think before the prompt
Before I ask an AI tool to produce code, I try to answer a few questions myself:
- What behavior should change?
- What should stay untouched?
- Where does this responsibility belong?
- What is the smallest useful step?
- How will I know the result is correct?
Those questions do not need a long planning document. Most of the time, a few sentences are enough. The point is to make the work legible before asking the tool to accelerate it.
Use prompts to compress work, not avoid judgment
Good prompting starts after good framing.
I like using AI for the mechanical parts: reading unfamiliar APIs, scaffolding a known pattern, drafting tests, comparing implementation options, or finding places where an assumption might break.
I do not want it to decide the product boundary for me. I do not want it to hide the tradeoff. I do not want it to turn vague intent into a large diff that now needs reverse engineering.
The smallest useful prompt
The best prompt is often narrower than the first one that comes to mind.
Instead of asking for a whole feature, ask for the first boundary. Instead of asking for a full rewrite, ask for the risky edge case. Instead of asking for a complete architecture, ask what assumptions need verification.
Small prompts make small diffs. Small diffs are easier to inspect, test, and throw away.
The rule
Resist the temptation to prompt does not mean avoid AI. It means do not use a prompt as a substitute for thinking.
The engineer still owns the problem, the boundary, the review, and the merge. The tool can make the work faster. It should not make the judgment disappear.
Need help with something like this?
Send the product goal, timeline, and current blockers. I’ll help you find the smallest useful next step.
Start a conversation