Claude Code: Optimizing Prompts for Maximum Efficiency

LLM Applications

Maximizing Efficiency with Claude Code

In the world of AI-assisted programming, the way requests, or "prompts," are worded for coding agents like Claude Code can make a big difference. Although large language models (LLMs) have become extremely powerful, the accuracy and effectiveness of their answers still depend largely on the quality of the prompts they are given.

Why Optimize How Prompts Are Worded

First of all, one might think that the way prompts are written no longer really matters, because LLMs have become so powerful that they can understand anyway. To some extent, this idea is understandable. However, there are still good and bad ways to word prompts.

A good prompt would be explicit about what is wanted, would include how to test the implementation, and would clear up any ambiguity. A bad prompt, by contrast, might make assumptions that do not match the existing codebase.

Moreover, prompting is not just a one-off action carried out for a specific conversation thread. It is also the science of working iteratively with the model to draw up a plan for implementing a feature. A good prompt might therefore also include things like asking the model to uncover ambiguities and discuss them, or telling it which assumptions to make.

How to Write Prompts for Claude Code

How prompts are worded for Claude Code specifically is addressed here. A few techniques are explained to get the most out of Claude Code, although these techniques are very general and apply equally to all other coding agents, such as Codex.

The first topic is the use of a transcription tool to convey all thoughts to coding agents. A transcription tool called FluidVoice is currently used. It is a model that can be run locally for free and is incredibly effective, both fast and accurate at transcribing English text.

Transcription tools are obviously very valuable because they are faster than typing by hand. Of course, speed depends on typing ability, but it is reasonable to assume that people can speak, on average, two to three times faster than they can type on a computer. In addition, it spares the hands from fatigue and makes it possible to concentrate on the input.

Another advantage noticed is a greater inclination to include all the context the coding agent needs to carry out a task. When everything had to be typed by hand, there were times when all the context was not written out simply because it took a lot of time. This is of course very bad, because if Claude Code is not given the context needed to solve a task, it will be very hard for it to solve it. However, now that transcription is used instead of typing, it is much easier to include all the necessary context, and it takes very little effort.

Overall, transcription tools are very beneficial because they save a lot of time and make it easier to include all the context that needs to be given to the coding agent so that it can perform the task effectively.

Telling the Model How to Test

Another very important point is to tell the model how to test. Suppose the model is asked to implement feature A. That is fine, but it must also be told how to test that feature. For example, if a chat feature is implemented in an application, the model must be told to open the chat in Chrome, type a query and make sure that the AI responds correctly and that the token streams work.

Basically, the model has to be told how it can know that it has correctly implemented the feature. This will save a lot of time, because it will not be necessary to test the feature manually as much, and the model will present a more functional feature right away.

Having a Discussion with the Model

A common misconception about prompting coding agents is that it is enough to provide a single prompt and let the model work until it is done. If the perfect prompt setup is in place, this is possible, because agents are able to work for many hours and accomplish a lot of tasks. However, this does not take into account how to build the perfect prompt.

For a human, building a perfect prompt is practically impossible, because it is impossible to have the full context of the entire codebase. There is simply too much code, too many things to take into account, and context that might be forgotten, which cannot be held in short-term memory. Coding agents, however, are able to store all of that in their memory, which makes them a very good discussion partner.

Basically, what should be done every time a coding agent is used, whether to implement a new feature, fix a bug or something else, is to have a discussion with the coding agent. The coding agent should be asked to research the topic, check the logs, look online for anything relevant, and so on. And the agent should be made to ask all its questions about ambiguous elements.

When coding agents write code, they make a bunch of assumptions. Many more assumptions than one could even be aware of. The reason is that there are too many decisions to make in coding for the coding agent to ask a question every time. When humans code, too, they have to make a number of assumptions, sometimes conscious, sometimes unconscious. During planning, however, it is desirable for the model to share at least the significant assumptions it is making.

An example of such an assumption might be whether to implement infrastructure directly through a CLI, for example for AWS, or to implement it as a CDK, that is, as code. This is not a perfect example, because in almost every case the right answer is that it should be implemented as code and not directly through the CLI. But it is an example of a decision worth being aware of so that the coding agent does nothing that is not wanted. Essentially, this discussion with the coding agent makes it possible to align the implementation as envisioned with what the coding agent will actually implement.

HTML Reports

One last topic is HTML reports. When coding agents work, there is a lot of information. The agent will write a lot of output in the terminal, most of which is not directly relevant, for example tool calls or simply reasoning tokens, and so on. Sometimes, however, it is necessary to examine what the coding agent is doing. This could be, for example, the plan it drew up during the last task, when a discussion with the model about how to implement a feature is wanted. In these cases, it is almost always recommended to ask the model to create HTML reports to visualize what is being discussed, which makes it much easier to give feedback to the model.

To be very specific, suppose feature A is being implemented, but there are several decisions the model wants to discuss before starting the implementation. In that case, the model is asked to generate an HTML report with each decision listed, including context such as:

• What the different options are for this decision
• What the decision is about
• Pros and cons of the decision

This makes it incredibly simple to understand what the different options are for each decision and to get an overview of the decisions to be made. And it is much easier than reading and understanding this through the terminal, for example. Another advantage of HTML reports is that visuals can be created, such as diagrams, flowcharts, SVGs, and so on.

HTML reports are also produced for tests. So, say the model has implemented a requested feature or fixed a bug. It is asked to create an HTML report containing each part of the feature or bug, with details on how it was tested and the test results. This makes it possible to see clearly what was done and how it works, which is essential to make sure everything works as expected.