LLM side quests
In the previous post, Domain-Driven Agents, I talked about ways we can improve our codebase to maintain better quality for ourselves and the agents we use on a daily basis. I mentioned analyzing the codebase from the strategic point of view and pushing the tactical part to agents when it comes to implementation. I mentioned how I operate on GitHub issues, and that's true.
From time to time, I lock some time for a general cleanup of my codebase. I run audits with agents, and I also explore the codebase manually, like in the old days, to look for things which went wrong, far from the quality I need. I use skills to catch DRY violations (so common for LLMs to produce) or check test quality, looking for cases where tests are not testing real behavior but just some simple assertions. Strong coupling, in situations where I aim for deep modules with small public interfaces to communicate with each other. And it helps. I have GitHub issues. Agents can implement fixes according to the target I defined in the given issue, and my code is cleaner. With agents' help, I can improve the health of the codebase much faster.
What if we could also push that part to the LLMs? What if we could just use their reasoning during every implementation to find problems in our codebase - tech debt, bugs, smells - without a dedicated audit? Let me show you.
So simple, so powerful#
If you want the quick answer and to see the results for yourself, drop this line into your CLAUDE.md or AGENTS.md file.
If you spot a bug or a needed improvement unrelated to the current task, do NOT fix it inline. Run
gh issue createdescribing the finding, its location and why it matters, then continue.
The model's reasoning has a lot to offer#
You create a prompt and send it to the LLM:
Implement a handler that adds a new patch operation for the purchase entity, using domain functions from
<domain module path>. Implement the needed operations in the database layer.
Model reasoning
Jumping to the domain layer, seeing many different files, reading one file. Oh, this is not it. I don't need that, but wait, why is there a copy-pasted chunk of a function that is already implemented elsewhere? Could we reuse it? Nah. I don't need it to achieve the goal of the prompt. Let's jump to the next file. Oh, there you are! I just need to update this domain function and can reuse it in the new handler. Jumping to the DB layer...
You see? To achieve the goal you set, the LLM checks many things. Not all of them are needed to fulfil your request, but the model still reasons about them. It notices and analyzes code that is not used for the handler but reveals something about your codebase. Most of the time, this information is lost.
The outcome#
Check the simple diagram about the handler we just discussed. This is how the model behaves now, with the line added.
The finding is no longer lost! You have a GitHub issue you can analyze. Maybe you just run your standard workflow to address it with agents, or maybe you include it in the next feature implementation, where the related code will be updated anyway.
Do all those GitHub issues describe real problems with your codebase? No, of course not. Some of them will be just small things you don't even want to address because they will impact a part of the code you don't want to touch now. Or maybe the bug reported by the LLM is not a bug. It's a feature ;) So not everything will be useful, but it's the same with the dedicated audits I described at the beginning. Trust me, most of those issues will be real findings which will help you maintain a healthier codebase. Simple as that. Follow for more.