This is a collection of tricks I've learned while using Claude Opus 5 I wanted to share. It's a powerful tool but the default behavior can be improved upon with some simple prompts.

Restrict comment generation

Prompt: "Do not generate comments longer than a sentence"

Why: To understand why, let's look at this code excerpt generated by Claude:

/* Two independent reasons to divide a group.

   Occupancy: too many instances in one draw wastes the culling that a
   split would buy.

   Extent: a batch spread wider than its own draw distance can never be
   distance-culled at all, because its bounding radius swamps the test.
   Ground cover strung along four kilometres of route with a 220 m draw
   distance is submitted every frame no matter where the camera looks,
   which is the state the previous build was in. */
Int divisions = Int(std::ceil(std::sqrt(Float(group.instances.size())/Float(target))));

This comment spans 10 lines. This comment describes C++ code to do instanced rendering for 3D models. There's nothing inaccurate in this comment but here is why it is useless:

1. This describes the complete reasoning for the implementation. This is too much to convey in a comment.
2. It uses phrases like "swamps the test". What does this mean? I happen to know distance-culling is a test but most readers will not.
3. It references specific numeric values like 4 kilometers and 220 meters. While this is accurate at present it rapidly becomes stale as code is refactored.
4. It describes the prior implementation which is just a distraction.

None of these things are worth a comment. To understand this code, you just need to understand the concept of instanced rendering. There are enough references to that on the internet. It isn't worthy of a comment at all. I'm reasonably certain Claude is tuned this way by default because it encourages spend on the generation of tokens that are effectively unfalsifiable from the perspective of software. A comment never stops code from working under normal circumstances. So by default most users are going to spend money on this but have no real awareness of it.

Ask clarifying questions

Prompt: "Ask questions if things are not specified in sufficient detail"

Why: When giving Claude an initial specification I try to be as comprehensive as possible. If you tell Claude to move directly to code generation, it will. But at the start Claude is incredibly good at forming relevant questions and taking the answers in the next prompt. You need to be capable of giving good answers to at least some of them, but even if you don't you can simply give an answer of something like "use best practices".

For example, I prompted Claude to build a 3D video game using Jolt Physics. This simulates a land train. I originally specified that this should be done using physics primitives I was already aware of. Claude came back with this:

C2 — Tire physics vs. Jolt best practice. Physics 1 says "best practices from Jolt." Physics 2–4 then specify rigid cylinder tires → attached to axles → attached to the bed by spring/damper constraints. Those are mutually exclusive. Jolt's actual best practice is VehicleConstraint + WheeledVehicleController, where wheels are not bodies — they're raycasts or shape-casts with a built-in suspension spring, and the whole vehicle is one rigid body. The articulated version means roughly 6 bodies + 6 constraints per axle, so a 1 engine + 4 trailer train with 3 axles each is ~90 dynamic bodies and ~90 constraints, all in one constraint island, at 60 Hz. That is where this design usually falls over — jitter, jackknifing, and constraint solver blowups on rough terrain.

Q2. Can I use VehicleConstraint per unit (engine + one per trailer, trailers with zero engine torque), with units linked by hitch constraints? You lose nothing gameplay-wise: Jolt's suspension exposes SpringSettings (frequency/stiffness + damping) per wheel, which maps exactly onto your configurable "spring rate" and "dampener rate," and per-wheel friction/radius maps onto tire type and tire damage. If you specifically want to see axles articulating, I can do it, but I'd want you to accept the stability risk up front.

In this case Claude had knowledge beyond my own. Jolt already has the specific features to handle vehicles, so that is exactly what should be used. Spending time to answer questions can save time with false-starts and dead-ends when you think you know the solution but are just close.

Use libraries

Prompt: "Use well tested libraries where appropriate"

Why: Claude was trained on a huge volume of data. It's trivial for a tool like Claude to emit code for a high-performance Fast Fourier Transform. There is absolutely zero reason to do this when libraries like FFTW already exist. Not only is this more maintainable, it costs fewer tokens to generate. If you already know what library should be used tell Claude explicitly. When working on a software defined radio project with Claude I advised it to use FFTW3 and liquid DSP. This worked great.

If you don't get good results, cut it loose before giving up

Prompt: "If you are aware of additional software improvements which will help with performance in these operational conditions, go ahead and make all of those now"

You'll need to tailor this prompt slightly for your purposes.

Why: When I had Claude build me a software defined radio mode for use with my amateur radio, it did not work. I gave Claude guardrails and it followed them as requested. I was pushing the limits of my knowledge as to what I should be asking for. So before I gave up I gave Claude the above prompt and then repeated my testing. The code then worked. Claude had made a large number of changes that were outside my knowledge scope. Specifically Claude described its changes as:

Everything that changed on the receive side:

1. 8 hops/symbol (was 4) — halves worst-case acquisition timing error, ~0.6 dB.
2. Fine timing search at lock — ±48 samples in 12-sample steps against the 64 known sync symbols, the timing analogue of the frequency refine. Residual drops to ~±6 samples.
3. Timing tracking (above). Symbol boundaries are no longer tied to the hop grid at all — the direct DFT is happy starting anywhere, so the loop can move by single samples.
4. Frequency tracking — a slow loop probing either side of the peak tone, clamped to ±40 Hz from lock so it can't walk onto an adjacent tone. Absorbs radio drift over a 40 s transmission.
5. Square-law soft metric — the max-log metric now uses magnitude², not magnitude. For non-coherent detection the log-likelihood goes as m² at low SNR and as m only at high SNR, and you're operating at low SNR. Worth a few tenths of a dB. (If you ever want to A/B it, it's the p = mag*mag line plus kSoftGain.)
6. Erasure floors — both whitening steps now floor their divisor at a quarter of the median. Previously a tone your radios filtered away entirely would be divided by almost nothing and return as full-scale noise; now it's suppressed and behaves as an erasure, which is what Viterbi wants.

All of these concepts make sense given my limited knowledge of software defined radio. But I did not know to ask for these specifically. Doing this at most costs 1 more prompt and still allows you to start with something that is focused and narrow.

Do not generate markdown other than for installation and compilation

Prompt: "Do not generate long markdown files. Just show examples of compilation and installation."

Why: Just as with source code comments, Claude loves to generate long markdown files in a README.md or similar. Here's a great example from the 3D video game project I did:

## Build

sudo apt install build-essential cmake git libsdl2-dev libgl1-mesa-dev
cmake -B build -DCMAKE_BUILD_TYPE=RelWithDebInfo
cmake --build build -j$(nproc)
./build/trainwarfare [--assets DIR] [--seed N]


## Milestone 1 -- vehicle rig

Engine unit plus four trailers, each its own Jolt `VehicleConstraint`, chained by
six-DOF hitches. Trailers are vehicles with no engine and no differentials, so
their wheels free-roll while keeping per-wheel suspension, friction and brakes.
Dropped units re-latch when the couplings come within 1.5 m at under 2 m/s.

This goes on and on for paragraph after paragraph. The total file size is nearly 30 kilobytes. Who cares about the milestones? The entire useful section of this is steps showing someone how to get the dependencies, build it, and run it. I'm not using an LLM to generate code so I can then spend 45 minutes reading a narrative about it.

Claude is trained on a huge volume of data. A bunch of that is obviously project README files. But I really think Anthropic has tuned Claude this way to just burn up tokens.

Minimize tool usage

Prompt: "Minimize tool usage. Let me compile the code and provide feedback"

Why: Claude has a decent amount of tools available to it without any configuration on your part. Here's an example of tool usage by Claude:

cd /home/claude/z && cat src/WaterfallWidget.h && echo ================== && cat src/WaterfallWidget.cpp && echo ============== && 
grep -n "spectrumRow\|addRow" src/AudioEngine.h src/MainWindow.cpp

In this case Claude ran grep to find specific text in source files. This is an appropriate usage of a tool. By default, Claude absolutely over invests in tool usage. This leads to it hitting tool usage limits and timing out on prompts. The other thing here is that from what I understand you are billed for tool usage. It is far cheaper to just take the code from Claude, try to compile it yourself, and give Claude feedback where needed. If there are minor syntax errors those can be fixed quickly without prompting. Larger issues can be fed back to Claude to allow it to fix them. I haven't figured out the exact economics of this but it is certainly more practical than having the interface tell me Claude hit a tool usage limit.