Tips and tricks on using coding agents effectively based on my experience
When they work, it feels like magic. When they don't, it feels like you're arguing with a confident bullshit artist who refuses to admit they're lost. Through a lot of trial and error, I’ve developed some intuition regarding what these models are actually good at and how to manage them in a way that gets useful results fairly reliably.
1. What to Delegate
LLMs are trained on massive amounts of public code. They are excellent at "average" tasks. Things that have been done a million times before are a great fit. Need to crap out a UI based on a JSON payload? Need a standard server endpoint or a service call? AI will generally crush this in one shot.
These things are also great at handling language specific syntax. If you know conceptually what you want to do (e.g., "loop through this list and filter by X") but you're working in a language you’re rusty in, LLMs is great for bridging the gap. It handles the syntax while you handle the logic. Just describe what you need done in pseudo code where you write out the steps, and it will handle the rest.
Throwing a sample JSON response at the AI and saying "write me a SQL query for this" or "scaffold a React component for this data" is very effective. These are the kinds of common tasks the agent will have a lot of training on, and they can produce something reasonable in one shot.
2. When to Take the Wheel
The biggest place where agents trip up is dealing with context and creativity. You have to remember that the AI doesn't know the specific quirks of your hobby project. For example, if you just tell it to "organize my MP3 library," it’s going to apply a generic standard that might scatter your "Various Artists" compilations into a hundred folders or sort "The Prodigy" under "T," which is annoying. You can't just ask it to "figure it out." You need to give it the exact logic, like telling it explicitly to strip "The" from band names or to force all soundtracks into a specific _OST folder.
Then there's the trap of open-ended creativity. If you give an agent vague instructions like "make a cool playlist generator," it often hallucinates a "better" way that turns into a mess. Instead of a simple script, it might decide you need ffmpeg installed to analyze audio waveforms for "mood," or it'll try to hook up to a lyrics API that hasn't worked since 2018. If you don't keep it on a tight leash, the AI will try to build you a chaotic, over-engineered AI DJ when all you really wanted was a way to find duplicate files. Agents love to over-engineer solutions and add features that are completely unnecessary. If you ask it to "make me a Discord bot" it might decide to hook up a persistent SQL database you don't know how to host, add a weird sentiment analysis API that costs money, and rewrite the command handler in a different library just because it felt like it.
The key is to always be explicit regarding what you want and ask for specific actions. If you don't constrain it, it will try to build a spaceship when you just wanted a bicycle. Here are some tricks that I found useful for to keeping it on the rails.
Before it writes a single line of code, ask the model to write a plan in Markdown. Even better, ask it to generate a Mermaid.js diagram of the flow.
Once it makes the diagram, you can visually inspect the logic. If Step 3 looks wrong in the diagram, you tell it, "Change step 3 to do X," before it wastes time writing bad code. Doing that is a lot easier than simply arguing with it using text prompts. Now there's a clear structure for the steps being performed, and it's easy to identify parts that you don't like.
Don't give the AI a blank canvas. Write the scaffolding yourself.
Set up the file structure.
Write the function stubs (names and arguments, a comment describing what the function should do).
Then ask the AI to fill in the body of the functions.
Doing these steps forces the AI to work within your architecture rather than inventing its own structure avoiding the problem of the agent getting creative and going off the rails. If you got it to build a diagram, then you can also tell it to create the initial project structure based on that.
3. Use Tests as a Contract
I find it's useful to think of tests as the ultimate requirement doc. If you define the desired functionality in a test first, you can just tell the agent to run the tests and make sure they pass. It will typically do a decent job running the test, seeing the failure, and fixing its own code to meet the spec.
It gives you a solid guarantee that the code is doing what you intended. It’s also your best defense against regressions. Without tests, an agent adding a new feature is just as likely to silently break three old ones. Having a contract for the existing functionality avoids that problem.
4. Git is Your Safety Net
You can think of Git like a "Quick Save" in a video game. Every single time the agent gets into a stable state, tests pass, the UI renders, the logic holds, commit that code immediately. This gives you the freedom to let the agent try wild ideas or complex refactors. If it works, great. If the agent hallucinates and turns your codebase into spaghetti, you don't have to untangle it manually. You just revert to the last good commit and pretend it never happened.
5. The "Burn It Down" Rule
What I've noticed is that if the agent doesn't get it mostly right on the first shot, it probably never will. When you point out a bug, the agent won't step back to understand the underlying problem. Instead, it adds kludges to fix your specific complaint. And the problems tend to multiply. If the original solution wasn't a good fit, adding more and more kludges on top will just make a huge mess that's never going to work right. If it starts spiraling, stop. Don't argue with it. Delete the conversation, reframe your problem statement, and start from scratch.
6. The Bottom Line
You are still the engineer, you are responsible for understanding the problem you're trying to solve, and what the project is meant to be doing. You provide the high-level thinking, the architecture, and the problem-solving. The AI is there to save you from the boring stuff like typing out boilerplate and looking up syntax.
Keep it focused, keep it manageable, and if it starts acting weird, just hit reset.
CriticalResist8 - 2w
Good tips, having tried the plan.md method myself I confirm it works (and carries over in the next context windows), although the AI then wants to save everything to new documentation files, and why not in theory, but in practice it just takes up space and tokens for nothing. Especially when you properly scope and nudge the llm (see my 2 posts on it in this community) it can make a plan that goes beyond what you thought of or would be capable of doing - whether it's capable of carrying out that plan is another thing, but by using the right keywords such as "production-ready" or "we are going to release the project on github under MIT licence" it thinks about it differently.
Like you said you're still the engineer, you spend less time building the project, but you spend time planning it instead - which I think a lot of people don't do when they do both planning+coding because nobody wants to write a full spec document for a python script. But it's the same as working with people except the llm doesn't ask questions, it just does it to the best of your request. It's like asking someone to "pick up some milk" for you at the store: if you don't tell me what brand and type of milk you want, I'll just pick whichever I find.
Actually, I would add: you can absolutely throw your idea to the agent and make it ask questions before writing the code to help it with implementation.
Would love some examples from contracts and pseudo code scaffold to understand better what you give the AI practically!
function processChannelRss (configuration)
for each feed in configuration:
extract feed url and filters
process feed items into database
select random unposted items from database
post them to channel with delay
remove old items if retention limit exists
A lot of the time you don't even have to be that detailed I find, but if you want the bot to do something specific writing out the steps will get a good result.
yogthos in crushagent
Tips and tricks on using coding agents effectively based on my experience
When they work, it feels like magic. When they don't, it feels like you're arguing with a confident bullshit artist who refuses to admit they're lost. Through a lot of trial and error, I’ve developed some intuition regarding what these models are actually good at and how to manage them in a way that gets useful results fairly reliably.
1. What to Delegate
LLMs are trained on massive amounts of public code. They are excellent at "average" tasks. Things that have been done a million times before are a great fit. Need to crap out a UI based on a JSON payload? Need a standard server endpoint or a service call? AI will generally crush this in one shot.
These things are also great at handling language specific syntax. If you know conceptually what you want to do (e.g., "loop through this list and filter by X") but you're working in a language you’re rusty in, LLMs is great for bridging the gap. It handles the syntax while you handle the logic. Just describe what you need done in pseudo code where you write out the steps, and it will handle the rest.
Throwing a sample JSON response at the AI and saying "write me a SQL query for this" or "scaffold a React component for this data" is very effective. These are the kinds of common tasks the agent will have a lot of training on, and they can produce something reasonable in one shot.
2. When to Take the Wheel
The biggest place where agents trip up is dealing with context and creativity. You have to remember that the AI doesn't know the specific quirks of your hobby project. For example, if you just tell it to "organize my MP3 library," it’s going to apply a generic standard that might scatter your "Various Artists" compilations into a hundred folders or sort "The Prodigy" under "T," which is annoying. You can't just ask it to "figure it out." You need to give it the exact logic, like telling it explicitly to strip "The" from band names or to force all soundtracks into a specific
_OSTfolder.Then there's the trap of open-ended creativity. If you give an agent vague instructions like "make a cool playlist generator," it often hallucinates a "better" way that turns into a mess. Instead of a simple script, it might decide you need
ffmpeginstalled to analyze audio waveforms for "mood," or it'll try to hook up to a lyrics API that hasn't worked since 2018. If you don't keep it on a tight leash, the AI will try to build you a chaotic, over-engineered AI DJ when all you really wanted was a way to find duplicate files. Agents love to over-engineer solutions and add features that are completely unnecessary. If you ask it to "make me a Discord bot" it might decide to hook up a persistent SQL database you don't know how to host, add a weird sentiment analysis API that costs money, and rewrite the command handler in a different library just because it felt like it.The key is to always be explicit regarding what you want and ask for specific actions. If you don't constrain it, it will try to build a spaceship when you just wanted a bicycle. Here are some tricks that I found useful for to keeping it on the rails.
Before it writes a single line of code, ask the model to write a plan in Markdown. Even better, ask it to generate a Mermaid.js diagram of the flow. Once it makes the diagram, you can visually inspect the logic. If Step 3 looks wrong in the diagram, you tell it, "Change step 3 to do X," before it wastes time writing bad code. Doing that is a lot easier than simply arguing with it using text prompts. Now there's a clear structure for the steps being performed, and it's easy to identify parts that you don't like.
Don't give the AI a blank canvas. Write the scaffolding yourself.
Doing these steps forces the AI to work within your architecture rather than inventing its own structure avoiding the problem of the agent getting creative and going off the rails. If you got it to build a diagram, then you can also tell it to create the initial project structure based on that.
3. Use Tests as a Contract
I find it's useful to think of tests as the ultimate requirement doc. If you define the desired functionality in a test first, you can just tell the agent to run the tests and make sure they pass. It will typically do a decent job running the test, seeing the failure, and fixing its own code to meet the spec.
It gives you a solid guarantee that the code is doing what you intended. It’s also your best defense against regressions. Without tests, an agent adding a new feature is just as likely to silently break three old ones. Having a contract for the existing functionality avoids that problem.
4. Git is Your Safety Net
You can think of Git like a "Quick Save" in a video game. Every single time the agent gets into a stable state, tests pass, the UI renders, the logic holds, commit that code immediately. This gives you the freedom to let the agent try wild ideas or complex refactors. If it works, great. If the agent hallucinates and turns your codebase into spaghetti, you don't have to untangle it manually. You just revert to the last good commit and pretend it never happened.
5. The "Burn It Down" Rule
What I've noticed is that if the agent doesn't get it mostly right on the first shot, it probably never will. When you point out a bug, the agent won't step back to understand the underlying problem. Instead, it adds kludges to fix your specific complaint. And the problems tend to multiply. If the original solution wasn't a good fit, adding more and more kludges on top will just make a huge mess that's never going to work right. If it starts spiraling, stop. Don't argue with it. Delete the conversation, reframe your problem statement, and start from scratch.
6. The Bottom Line
You are still the engineer, you are responsible for understanding the problem you're trying to solve, and what the project is meant to be doing. You provide the high-level thinking, the architecture, and the problem-solving. The AI is there to save you from the boring stuff like typing out boilerplate and looking up syntax.
Keep it focused, keep it manageable, and if it starts acting weird, just hit reset.
Good tips, having tried the plan.md method myself I confirm it works (and carries over in the next context windows), although the AI then wants to save everything to new documentation files, and why not in theory, but in practice it just takes up space and tokens for nothing. Especially when you properly scope and nudge the llm (see my 2 posts on it in this community) it can make a plan that goes beyond what you thought of or would be capable of doing - whether it's capable of carrying out that plan is another thing, but by using the right keywords such as "production-ready" or "we are going to release the project on github under MIT licence" it thinks about it differently.
Like you said you're still the engineer, you spend less time building the project, but you spend time planning it instead - which I think a lot of people don't do when they do both planning+coding because nobody wants to write a full spec document for a python script. But it's the same as working with people except the llm doesn't ask questions, it just does it to the best of your request. It's like asking someone to "pick up some milk" for you at the store: if you don't tell me what brand and type of milk you want, I'll just pick whichever I find.
Actually, I would add: you can absolutely throw your idea to the agent and make it ask questions before writing the code to help it with implementation.
Would love some examples from contracts and pseudo code scaffold to understand better what you give the AI practically!
oh here's an example of what I mean with contracts https://git.sr.ht/~yogthos/telegram-rss-bot/tree/main/item/test/post-message.test.js
for scaffolding, I do something like this
A lot of the time you don't even have to be that detailed I find, but if you want the bot to do something specific writing out the steps will get a good result.