11–19 of 19 posts
Is it possible to develop an intuition where it would do a decent job and use it only for these type of tasks or the result is always random?
1. Be uncomfortably explicit in prompts: Claude Code in particular is very sensitive to ambiguity. When I write a prompt, I’ll often:
Specify coding style, performance constraints, and even “avoid X library” if needed.
Give sample input/output (even hand-written).
Explicitly state: “Prefer simplicity and readability over cleverness.”
2. Break down problems more than feels necessary: If I give Claude a 5-step plan and ask for code for the whole thing, it often stumbles. But if I ask for one function at a time, or have it generate stub functions first, then fill in each one, the output is much more solid.
3. Always get it to generate unit tests (and run them immediately): I now habitually ask: "Write code that does X. Then, write at least 3 edge-case unit tests." Even if the code needs cleanup, the tests usually expose the gaps.
4. Plan mode can work, but human-tighten the plan first: I’ve found Claude’s “plan” sometimes overestimates its own reasoning ability. After it makes a plan, I’ll review and adjust before asking for code generation. Shorter, concrete steps help.
5. Use “summarize” and “explain” after code generation: If I get a weird/hard-to-read output, I’ll paste it back and ask “Explain this block, step by step.” That helps catch misunderstandings early.
Re: Parallelization and rate limits: I suspect most rate-limit hitters are power-users running multiple agents/tools at once, or scripting API calls. I’m in the same boat as you — the limiting factor is usually review/rework time, not the API.
Last tip: I keep a running doc of prompts that work well and bad habits to avoid. When I start to see spurious/overly complex output, it’s nearly always because I gave unclear requirements or tried to do too much in one message.
Earlier quoted context omitted.
That’s the problem — about 50% of the time, the result is so messy that cleaning it up takes more time than just writing it. So I wonder is there a better way to prompt or structure things so that I consistently get clean, usable code?
This is my experience as well, and that of many people I’ve talked to. The ones who breathlessly state how awesome it is seem to all be business people to me rather than engineers. It keeps throwing me into doubt.
the number one important thing: ask it to write tests first, then the code. and instruct it to not overmock or change code to make tests succeed. besides this: I have great results in combination with https://github.com/BeehiveInnovations/zen-mcp-server but ymmv of course and it requires also o3 and gemini api keys but the token usage is really low and the workflow works really great if properly used
You’re definitely not alone “AI code loot box” is a great description! I’ve been experimenting with Claude Code (and the other major models) since late last year, and my success rate seems to track yours unless I’m deliberate about “prompt engineering” and workflow. Here are a few things that have helped me get better, more reliable results: 1. Be uncomfortably explicit in prompts: Claude Code in particular is very s…
Is it possible to develop an intuition where it would do a decent job and use it only for these type of tasks or the result is always random?
This sounds like a decent work flow. What makes you think it’s ineffective?
That’s the problem — about 50% of the time, the result is so messy that cleaning it up takes more time than just writing it. So I wonder is there a better way to prompt or structure things so that I consistently get clean, usable code?
Are you using git? as in "git checkout ." or "git checkout -b claude-trial-run"
Claude successfully makes code edits for me 90% of the time. My two biggest pieces of advice blind are
1. Break down your task into smaller chunks - 30 minutes worth of human coding max. 2. On larger code bases git hints on what files to edit.