There are plenty of tutorials covering the first ten minutes. This is about the next stage, where the tool works but the results are inconsistent and you cannot tell why.
Stop asking for the whole thing
The most common mistake is scope. Someone asks for a feature end to end, gets back a large diff that is eighty percent right, and then spends longer auditing it than the implementation would have taken.
Work in loops small enough to verify. Ask for one change, check it, move on. This feels slower and is dramatically faster, because you never end up unwinding a large plausible-looking change built on a wrong assumption made ten minutes earlier.
The unit of work should be the largest change you are still willing to read carefully. If you would skim it, it is too big.
Define done before you start
Vague requests produce vague results, and the fix is not more elaborate phrasing. It is a verifiable target. Instead of asking it to fix a bug, ask for a failing test that reproduces the bug, then ask to make the test pass.
That reframing does two things: it forces the problem to be understood before it is solved, and it leaves you with proof rather than an assurance.
Keep the instruction file short
Instruction files grow by accretion. Every time something goes wrong, a line gets added. After a few months it is a thousand lines, and the important rules are buried among conditional advice that applied once.
Prune it regularly. If a rule has not prevented a mistake recently, it is costing you attention without earning it. A short file where every line matters beats a long one nobody reads, including the model.
Know when to restart
Sessions go bad. A wrong assumption early gets built on, and after a while every response is subtly shaped by something that was never true. The signal is having to correct the same misunderstanding twice.
When that happens, do not keep negotiating. Start fresh and bring forward only the conclusions worth keeping. People resist this because the session feels like invested effort, but the invested effort is exactly the problem.
The thing that separates people
After watching a lot of people work this way, the difference is not prompt craft. It is whether someone can tell good output from output that merely looks good.
That judgment only comes from reading what gets produced, closely, for a while. You can outsource the typing. You cannot outsource knowing whether it is right, and anyone selling you a workflow that skips that step is selling you a way to accumulate problems faster.