Ten Things I Wish I Knew When I Started Coding With Agents

Lessons · Working with AI

When I started developing with AI, I thought the hardest part would be writing as many prompts possible to get what I expected back. Most of what I thought at that time turned out to be wrong. That brings me to the following ten things I would tell anyone starting today. These apply to a simple vibe-coded app over the weekend, or more importantly, customer-shipped code at your job.

1. The speed at which i could go back and forth with AI was not the problem

I wasted several months trying to come up with results that were what I actually wanted. Claude Code already writes code faster than I ever will and that initially gave me a false sense of thinking how I used AI was correct. Just because I could have a long-winded conversation with Claude, and eventually get something close to what I wanted was not even close to an appropriate use of agentic development. This led to learning 2 things that really did matter: how clearly I can say what I want, and how quickly I can check what came back. Getting good at these will instantly level up your results. A clean spec/prompt and a fast way to test the result will beat a back-and-forth session of tiny fixes every time.

2. Just because the demo works doesn't mean it's bullet-proof

Claude shows me the feature working in its most happy path, but that demo runs the one path the prompt instructed it to build. If you didn't lay out all the failure cases, account for bad input, no backend response, etc., your demo is exactly that, just a demo that should never ship. Treat demos for what they are and use them as the basis for what's left to build on top of.

3. Always review test cases

Just because the test suite passed with all green does not mean your code is covered properly. This goes for code written even without AI's help. Lots of people just write cases to prove your code works in the best scenario possible. Leaving out the negative is where defects creep up. Even some basic failure test cases could save you dozens of hours triaging defects down the road. An agent will generate tests cases for you to make the code it just wrote pass. Make sure to always instruct it to run the test suite, not just write the tests, and to also provide negative test cases asserting where methods could fail.

4. You can and most likely will get a bad response from an agent

A junior engineer who doesn't understand something will generally let you know. A coding agent gives you a wrong answer in the same manner it uses for a correct one. There's been so many times where I reviewed something Claude wrote, i called it out for not being correct, and then it just said "Oh yea, you're right. Let me fix that, my mistake." May be some day you'll be able to fully trust what you get back, but that day is definitely not here yet. Always check what's given, whether you manually review each line or you fire up another agent to validate the original agent's results in a verification loop.

5. Too much context is bad

I always thought the more info you give a coding agent, the better. This turned out to be probably the biggest mistake I used to make with agentic development. Old and off-topic context makes the answers worse. Now I specifically give it context on a very narrow need. If I feel the conversation is starting to drift on to other topics, I'll either compact the session or just simply start a fresh one. A clean context will 100% beat a cluttered one every time.

6. Run a verification loop in your specs/prompts

This follows a similar pattern as number 3. Besides test cases, you should always review the code being generated, whether you go line by line or give a verification loop instruction to the AI agent. This is always a good practice because before you continue on coding and compound multiple potential problems, Claude can pick apart it's own work before it becomes a problem. This also helps give you a better sense of confidence on what's being generated and that it's not arbitrarily moving on to the next task.

7. Starting over beats going back and forth

When you start noticing you're arguing with an agent more than getting results you expect, it's time to just start a new session. Once you start noticing significant drift, it's typically an indication that the context is too polluted. You could work your way back to a safe level of productivity in that session, but 99% of the time it's just cleaner and much more efficient to just start a new session.

8. Set the agent up for success ahead of time

I always blamed less than ideal results on bad prompts. A lot of times it was actually the initial setup of my project. The concepts mentioned above about test cases and verification loops are only effective when the agent has something configured to run them. When type checks, a linter, and test runners are in place ahead of time, you no longer need to waste precious tokens getting an agent to setup all the groundwork it needs to do its job properly. That initial time upfront making a project easy to check pays off more than rewording prompts.

9. It gets nearly impossible to maintain code you don't understand

It goes without saying that a single AI agent will write code faster than any group of human developers. That in itself is cause for having at least a basic understanding of what is being generated and submitted in pull requests. Far too often you'll see comments in a PR asking about what this new method is for and you then see a response like "Claude generated it." 300 PRs going into a repo with that same mindset is a recipe for disaster. You don't need to monitor every single line going in, but if you can't provide a summary of what you pushed, that is a big problem and it'll only get worse.

10. Your taste and judgment is worth more than you think

I thought the first time I sat down to vibe-code an app or website would be the best thing since sliced bread. Turns out, without giving the model very specific preferences, color palette, design tokens, etc., you're pretty much going to get back the same thing as everyone else who sat down to do the same thing. Your version of Claude Opus is no different than my version, so if we both give it a vague prompt like "make me a modern, polished website that stands out from the crowd", we are almost always going to get the same result. The model is trained on certain data points and if you don't instruct it with specifics, those generic prompts are all running against that base level of a website definition the model was trained on.

Agentic development has increased my productivity more than I can even keep track of. The biggest takeaway I have is that, like with most things in life, you get the best results when you put more effort and your own flavor into it.