Good LLM Dev and Usage Patterns | Author<br>Good LLM Dev and Usage Patterns<br>published2026-06-01<br>Introduction<br>This is a list of patterns regarding usage of LLMs (Large Language Models) that I’ve observed result in positive outcomes. I’ve split them into two categories:<br>Usage, for patterns used in systems that are partly agentic, i.e. the system utilizes LLMs during its operation. The examples given are focused on coding agents, but they are generally applicable.<br>Development, for patterns used during software development<br>If the category split feels arbitrary, feel free to ignore the (ir)relevant headings.<br>Usage Patterns<br>Criticism helps LLMs too<br>The actor/critic pattern is where input is given to one LLM agent, called the ‘Actor’, and the output of that is fed into a different LLM agent, called the ‘Critic’. The process is iterative; the Critic is instructed to be stringent in what they accept, and failure to meet their standards results in the actor being given the Critic’s feedback, and asked to produce a better result.<br>This can be an expensive way to dramatically increase the quality of output, similar to the “four eyes” method / pair programming. Note that the model(s) used, and any processing of the context, are implementation details. It is a good idea to keep track of decisions made by the system in a way that persists across iterations, such that the agents gradually refine the approach with a decreasing set of changes each time, until the Critic fully approves.<br>An alternative (or complement, if you have infinite budget) of this is to generate multiple responses to each prompt, and pick the best one. I believe that is not good practice, as it does not scale very well, and iterative improvements generally pay off better vs attempting to pick between what most often is different ways of expressing a very similar one-shot result. The tokens you spend on the critic + an additional iteration are therefore more efficiently spent than the tokens on multiple permutations of any given step.<br>Minimize the context needed to accomplish each task<br>Humans split work into tasks. Each one is a building block towards creating a bigger piece of software. Agents too should only receive the information they need to accomplish one (relatively) small task at a time.<br>In practice, this means that the documents that the agent needs to read to get up to speed are concise, the agent’s harness only has the necessary tools that the agent needs to do their job, and QA / testing / deployment are separate concerns from development. The more each agent has to do, the more opportunities they have to forget or deviate from their assigned tasks.<br>This also ties in with good privacy & security practices: You don’t need the agent to read or provide e.g. user IDs to call a tool, your software can provide that info itself when the call is made. This both makes it easier for the agent to call a tool, because less tokens are needed to call it successfully, and prevents the agent from having to handle confidential information.<br>Making sure that the agent needs to output the minimum number of tokens to accomplish something makes the likelihood of success higher (in general at least, with diminishing benefits).<br>In general, the less the agent is expected to do (at least, per invocation), the higher the likelihood of the agent producing an acceptable result. As the software being built starts to take shape, the context needed to make even a small change will naturally increase. Keeping the increase minimal ensures that agents can work cheaper (less tokens of context), faster (less tokens to process) and better (greater likelihood of producing good results).<br>Be cautious and defensive<br>On a less positive note, remember that what an agent can do, it should be expected to (eventually) do. So never give any agent enough rope to hang you with, because it is not impossible that it might.<br>It is important to expect that the agent will abuse anything given to it, especially if it ever misinterprets an instruction. Some providers suggest having a second LLM assess users’ prompts before sending them to your agent. This does make attacks harder, but not impossible, and it should not be considered a robust defense on its own. A better approach is to never give access to extremely damaging tools to agents, make the tools require user confirmation, or have the agent work in an environment where any damage that it does can be easily reverted (which technically makes the tools provided to the agent not extremely damaging, but if I don’t mention sandboxes explicitly someone might think I forgot).<br>Do note that having tools require user confirmation is not ideal if it will be frequently requested, as humans quickly get alert fatigue. If you cannot reliably alert humans to only the agents’ actions that are impactful enough to require a second set of eyes, instead opt for not giving the agent...