in making a quick start. However, now that coding has become a commodity, one of the main problems I see is the transfer of information between the human brain and the coding agent.
If the idea is properly presented to the code agent, it is more efficient in implementing the solution, testing it, and ensuring correct implementation.
However, most of the time, there are many details, and it is really difficult to make sure that all the details are included when you tell the agent to write the code.
This is where alignment comes in, and in this article, I'll discuss how you can make sure your goals are aligned with your coding agents, and I'll present strategies you can use to do this.
Why match with coding agents
First, I always want to discuss why you should care about a particular topic. In this case, that's why you should match coding agents like Claude Code.
Coding agents are incredibly good at implementing things when given a well-defined spec.
However, creating this well-defined feature is harder than you might think. First, you have to define exactly what you want to use, when you have an idea in your head of what you want to do. However, there are always many nuances that are difficult to include in such a way when defining them in the code agent.
- You may forget to mention certain parts that should be used
- You may not be aware of the decision you have to make regarding use
- There may be some ambiguity in your explanation
These points are often things that you do not see before, because, of course, as a person, you cannot have a complete context of what you want to use, which, in most cases, is something that you use because someone else told you what you need, for example, a customer or a product manager.
Second, you don't have the full context because you don't fully know everything in the codebase, especially now that more code is being written by AI. It is difficult to have a complete view of everything in advance, and as a result, you lose the complete context.
That's why code agent alignment is so difficult, and in this article, I'll cover how to successfully align your scripting agents so that your scripting agents are more efficient and better at firing the implementation you're asking them to do.
How to connect with your coding agents
In this section, I'll include some strategies I use to align with my coding agent, as well as an idea of how I align with my coding agents.
Each section will include a specific concept, way of thinking, or method that you can use in your work as a programmer to successfully align with your coding agents.
Agents often go to automatic the solution
The first concept I want to dispel is that coding agents always go to the default solution whenever they try to do something.
What I mean by this is that the code agent will usually look for previous uses of the same object in your endpoint, replicate that, and do it again.
This means that if your code repository is not well organized and you ask the coding agent to implement a new feature, the coding agent will probably continue the bad pattern from before and put the new feature in a low order.
Let me give you a specific example:
Most codebases have many LLM calls, naturally. In an ideal codebase, you have one service, which is one file or folder called LLM service, where you have all your LLM calls. You have career options that determine how the LLM call is made. For example, deciding which LLM to use, whether to use structured output or not, high output tokens, and so on.
However, a poorly structured codebase will not have this as a single file, but rather define LLM call providers in many separate files, and each file will contain a separate call to LLM.
This is called bad separation anxiety.
Now, if you're in a well-organized codebase and you ask to make another LLM call, LLM will default to the native solution, which is, of course, to use the standard LLM shared service file, which is great.
However, if you are working on a poorly organized codebase, where LLM calls are made separately in many different files, the agent will likely continue this behavior and make another new separate LLM call, exacerbating the pattern of bad separation of concerns.
The point I'm trying to make here is that the code agent will simply follow the natural pattern in your codebase, whether that's a good pattern or a bad pattern. That's why it's so important, if you want to successfully align with your coding agent, to ensure that your codebase has good patterns throughout and that you refactor your code regularly.
If you want to learn more about refactoring your code, you can read my TDS article in the article below:
How to Code with Claude's Code
The great thing about refactoring now is that you can simply ask coding agents to do it for you.
Effective use of program mode
An important way to align with your coding agents is to use edit mode whenever you interact with them. The edit mode is great because it helps you see the ambiguity between the implementation you envision and describe for LLM and the current codebase. You may have forgotten that if you make one change to the codebase, this affects other parts of the codebase that you didn't think about, and you need to decide whether to continue with the change or change the implementation details.
You should not expect yourself to have full knowledge of the codebase beforehand, simply because codebases are now written mostly by coding agents, and it is impossible to have a complete view of the codebase.
However, you don't really need a full overview of the codebase because you can just ask your LLM about the codebase itself. Tell it to help you identify the ambiguities in the implementation you want and how that might conflict with the current codebase.
In short, whenever you want to use a new feature, you must use program mode with your agent. You have to spend a lot of time in program mode, talking back and forth with the model about:
- What do you think
- What problems can LLM see with what you want to use
- How to solve those problems
Give the code agent as much context as possible
Another reason I often see a mismatch between what the developer wants to implement and what the coding agent does is that the developer has context that was not provided by the LLM.
Imagine, for example, that you are asked to use a feature to classify images into one of 10 categories. You want to use the latest Claude Opus model because you know that's the best model, and of course, you want to use the best model to achieve the highest possible accuracy.
However, in a recent meeting with your manager, he told you that we cannot use the Claude Opus model because it is too expensive, and we need to find a solution that is 10 times cheaper.
Then, when the developer asks the encoding agent to implement the solution, the developer simply tells the encoding agent: “Hey, we need to use this feature when we classify images into one of these 10 categories. Please fix that for me right now.”
The problem here, of course, is that the developer has given the LLM or scripting agent context for the problem to solve, and of course, it's a problem that the code agent can easily solve now. However, the developer forgot to give the LLM all the context it needs, i.e. it cannot use an automatic solution, which would be to use the latest and greatest LLMs, such as Claude Opus. He must find a solution that is at least ten times cheaper.
This is, of course, a major disagreement between a coding agent and a developer. What will happen is that the encoding agent will do the initialization. After the implementation is complete, you, the developer, will probably find that the solution is not really feasible due to cost. You have to spend time coming up with another solution, which means that all the time spent using the first solution is wasted.
Of course, the example I gave here is not possible, because I hope you will remember to tell your coding agent the essence of cost reduction. However, the same thing happens every time, when you forget to tell the LLM or coding agent a certain piece of context. It starts running something, and that's wrong, and the developer has to do another run.
To prevent this from happening, you need to give the code agent as much context as possible. For example, you should give the code agent access to:
- Meeting note documents
- Loose channels and DMs
- Concept notes
And everything else that can be useful information and context for the LLM or coding agent when doing the implementation. This prevents problems where the writing agent has no context, which makes it worse for decision making.
The conclusion
In this article, I discussed how to successfully synchronize with coding agents. The most common problem I see with developers and coding agents is that they are not completely aligned with what they want to implement. A developer has one image in their mind of what they want to use and how it will look. Another developer may have another image in his mind, and finally, a code agent may have a third image of what the implementation will look like.
This is, of course, very problematic and should be avoided at all costs. So, I've provided some tips and ideas to keep in mind and think about and actively use whenever you're dealing with your coding agents to make sure you're as aligned as possible, making coding more efficient.
👋 Touch
👉 My Free eBook and Webinar:
🚀 10x Your Engineering with LLMs (Free 3-Day Email Course)
📚 Get my free ebook Vision Language Models
💻 My webinar on Vision Language Models
👉 Find me on social media:
💌 Stack
🐦 X / Twitter
