was a very hot topic a few years ago. This is where you would tweak your prompt, even just a bit — for example, the format of your prompt, what the last sentence of your prompt is, and so on. You could achieve vastly different results with LLMs. However, in the years since, the LLMs have become a lot stronger and smarter, and are now much less likely to change outputs just based on the format or text order or similar things in the prompt.
However, prompting is still very important, and the knowledge on how to effectively prompt LLMs is still incredibly important. It just requires a different skill set and a different way of thinking to effectively prompt agents nowadays.
It’s worth noting that, likely, in the next year or two, the way you prompt your agents will have evolved further, and you just have to keep track of all the changes happening to the models in order to know how to prompt them effectively and get the best results out of the models.
In this article, I’ll discuss how I prompt the LLMs I’m working with to make them effectively perform a lot of work, and I’ll essentially discuss my workflow to get engineering tasks done.
Why optimize the way you prompt
First of all, you might think that the way you write prompts doesn’t really matter that much anymore because the LLMs have become so strong that they can understand you anyway. To a certain extent, I agree with this way of thought. However, there are still good and bad ways to prompt models.
For example, a good prompt would be:
- Be explicit about what you want
- Include how to test the implementation
- Clarify any ambiguities
While a bad prompt would, for example be:
- Be vague
- Make assumptions that don’t fit with the existing codebase
Furthermore, prompting is not just a singular thing you do for a specific thread. Prompting is also the science of iteratively working with the model to make a plan to implement the feature, for example. So, a good prompt could also include stuff like asking the model to discover any ambiguities and discuss them with you. Or telling the model which assumptions to make.
How I prompt Claude Code
Now I’ll move on to how I prompt Claude Code specifically. I’ll talk you through a few of the techniques that I use to prompt effectively and get the most out of Claude Code, though these techniques are very general and also apply to all other coding agents, basically, such as Codex as well.
Transcription
The first topic I’d like to cover is that I use a transcription tool to get all my thoughts into the coding agents. Currently, I’m using a transcription tool called FluidVoice, which is a model you can run locally for free that is incredibly good, both fast and accurate for transcribing English text.
Now, the transcription tools are obviously very valuable because they’re faster than typing by hand. Of course, how much faster depends on how fast you can actually type by hand, but it’s fair to assume that you can talk, on average, two to three times faster than you can type on your computer. And of course you get the benefit of not straining your hands and not having to focus on the typing.
However, another benefit I’ve noticed is that I’m more willing to include all the context that my coding agent needs to perform a task. When I had to type everything by hand, there would be times when I didn’t want to write out all the context, simply because it took a lot of time to type. This is, of course, very bad because if you don’t give Claude Code the context it needs to solve a task, it’s very hard for it to actually solve that task. However, now that I transcribe instead of type, it’s way easier for me to actually include all the context that I need to include, and it’s very low effort as well.
So all in all, transcription tools are very good because they save you a lot of time, and it makes it easier for you to include all the context you actually need to provide the coding agent for it to perform the task effectively.
Telling the model how to test
Another very important point is telling the model how to test. So let’s say you tell the model to implement feature A. This is of course great. You tell it what the feature includes; you should include why you want to build this feature. You should include any context around the feature, how the feature ties into other parts of your application, and so on.
However, you also need to tell the model how to test the feature. For example, if you implement a chat feature into your application, you should tell the model that it should open the chat in Chrome, type in a query itself, and ensure that the AI responds properly and that the tokens stream in, for example.
Essentially, you need to tell the model how it can know that it implemented the feature correctly. Doing this will save you a lot of time because you don’t have to test the feature as much yourself, and the model will present you with a more working feature right away.
Having a discussion with the model
A common misconception when it comes to prompting coding agents is that you just provide them a singular prompt and fire it off, and then you let them work until they’re done. If you have the perfect prompt setup, this is possible because the agents are very capable of working for many hours and getting a lot of work done. However, this doesn’t take into account how to build the perfect prompt.
For a human, it’s basically impossible to build a perfect prompt, and the simple reason for that is that you, as a human, cannot have full context of the entire codebase, and there’s simply too much code, too many things to think about, and context you might forget, which is not possible to have in your short-term memory. However, for the coding agents, they are actually capable of storing all of this in their memory, which makes them a very good discussion partner.
Basically, what you should do whenever you start off with a coding agent, whether it’s implementing a new feature, resolving a bug, or anything else, is that you should have a discussion with your coding agent. You should ask your coding agent to research the topic, check the logs, search online if there’s anything relevant there, etc. And have the agent ask you any questions about anything that is ambiguous.
When the coding agents write code for you, they make a ton of assumptions. Way more assumptions than you’re even aware of. The reason for this is that there are way too many decisions within coding for the coding agent to ask you every time. When humans code as well, they also have to make a bunch of assumptions that they sometimes think of, and sometimes it’s just unconscious assumptions. However, when planning, you want the model to at least share any significant assumptions it makes.
An example of such an assumption could be whether to implement infrastructure directly through a CLI, for example for AWS, or to implement it as CDK, so as code. This is not a perfect example because in almost all cases the correct answer is that you should implement it as code and not directly through the CLI. But this is an example of a decision that you as a human want to be aware of so that the coding agent doesn’t do anything you don’t want it to do. You basically have this discussion with your coding agent to align the implementation in your head with what the coding agent will actually implement.
You had a discussion with your coding agent to ensure that you are aligned on which task to implement and how to implement it.
HTML reports
One last thing I want to cover in this article is HTML reports. So when coding agents work, and there’s of course a lot of information. The agent will write a lot of output to your terminal, where most of it is not relevant to you, for example, tool calls or just thinking tokens and so on. However, sometimes you need to review what the coding agent does. This could, for example, be the plan that it made in the last task where you want to have a discussion with a model about how to implement a feature. In these cases, you should almost always make the model create HTML reports to visualize what you’re discussing, which makes it a lot easier for you as a human to give your feedback to the model.
Let me be very specific here. Let’s say I’m implementing feature A, but there’s a bunch of decisions the model wants to discuss with me before starting the implementation. If so, what I do is that I make the model generate an HTML report with each decision listed, including context such as:
- What the different options are for that decision
- What the decision is about
- Pros and cons of the decision
- A simple button for me to decide which option to choose for the decision
This makes it incredibly simple for me to understand what the different options are for each decision and gain an overview of the overall decisions that are to be made. And it’s much easier than reading and understanding this through the terminal, for example. Another benefit of HTML reports is that you can create visuals, for example, diagrams, flow charts, SVGs, and so on.
Another note here is that I also make HTML reports for testing. So let’s say that the model has implemented a feature I asked for or fixed the bug. I make it create an HTML report containing the following:
- Each part of the implementation that I need to test
- Direct links into the product to exactly where to test it. For example, if I’m testing a chat, it gives me a link directly to that chat, so I don’t have to navigate the product myself
- Two buttons, one for approving the feature and one for saying that it needs more work
- An input field where I can give my feedback on how to fix it and what’s wrong
I then also have a copy button on the HTML report so that I can just copy the output of the report, i.e., what I answered for the different parts of the report, and I can simply paste it into Claude Code again, have it continue working, and then present me a new HTML report so I can continue like this until everything is tested and approved. If so, I can of course merge everything and get it into production.
Conclusion
In this article, I discussed how to prompt Claude Code and other coding agents effectively. The science of prompting coding agents has changed a lot over the years; in the beginning, how you worded your prompts or the order in which you had the text in your prompt mattered a lot. Nowadays that stuff doesn’t really matter at all, but prompting is still a skill that you need to master. You, for example, need to tell the agents how to test their implementations. You should discuss with the agents how to do an implementation, resolve any ambiguities, and so on. I think the way you prompt the agents will change again over the next year or two, and I will just keep updated on the most effective way to work with agents and post another article once I believe the way I interact with my agents has changed enough since this article.
👉 My free eBook and Webinar:
🚀 10x Your Engineering with LLMs (Free 3-Day Email Course)
📚 Get my free Vision Language Models ebook
💻 My webinar on Vision Language Models
👉 Find me on socials:
💌 Substack