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

Lessons · Working with AI

When I started, I thought the hard part would be writing clever prompts. I was wrong about that, and about most of what I believed that first month. Each wrong idea cost me real time. So here are ten things I would tell anyone starting today. They apply whether you are throwing together a weekend project or shipping agent-written code to real users. The higher the stakes, the more they matter.

Here is the whole list on one card. Each lesson gets its own section below.

1. The bottleneck was never how fast I typed

I spent my first weeks chasing the perfect prompt. Wasted effort. The agent already writes code faster than I can, so how fast I type was never what held the work back. Two other things did: how clearly I can say what I want, and how quickly I can check what came back. Get good at those. A sharp spec and a fast way to test the result will beat a clever prompt every time.

2. A working demo proves less than you think

The agent shows me the feature working and I want to believe it. But that demo runs the one path the agent had in mind. The bugs are sitting in the paths nobody ran: the empty input, the second user, the request that dies halfway through. So I stopped trusting demos. Now I read the change itself, line by line, because the demo only tells me what the agent hoped it built.

3. The tests it wrote are not proof

Green tests feel like safety, and that feeling has fooled me more than once. An agent will happily write a test that checks nothing. It calls a function, confirms it returned something, and never looks at what. So I ask one thing of every test it writes: what change to the code would make this fail? When I can't name one, I throw the test out and write a real one.

4. It is confidently wrong, and that is the danger

A junior engineer who isn't sure will usually say so. The agent gives you a wrong answer in the same calm voice it uses for a right one, and nothing in its tone warns you. You have to bring the doubt yourself. I read most carefully at the moment the agent sounds surest, since that confidence tells me nothing about whether it's right.

5. Give it less context than you think you should

I used to pour everything in, every file and the whole history, figuring more could only help. It doesn't. Old and off-topic context makes the answers worse. Now I hand it what the task needs and little else, and I start a fresh session far more often than feels comfortable. A short, clean context beats a stuffed one almost every time.

6. Don't let it check its own work

Ask the agent to review the code it just wrote and it will pass itself every time. Whatever wrote the bug is poorly placed to catch it. So I hand the review to a second, fresh agent, or I do it myself. Someone who did not write the code, person or model, will spot what the author reasoned past. No single habit has caught more of my mistakes.

7. Starting over beats arguing it back

When the agent takes a bad approach, the reflex is to correct it, then correct the correction, and on it goes. That rarely pays off. Almost always it is quicker to throw the work away and start again with a better prompt. New code is cheap to generate, and a tangled approach is slow to untangle. Learn to start over without feeling you have lost something, because you haven't.

8. Set up the feedback before you polish the prompts

For a while I blamed bad output on bad prompts. Usually the real problem was the project. The agent gets much better when it can test its own work, and it can only do that when the tests, the type checks, and the linter are in place, and when the code runs fast enough to try again and again. A strong model with no feedback to work against is just guessing. Time spent making a project easy to check pays off more than time spent wording prompts.

9. You can't maintain code you don't understand

The agent adds code faster than I can read it. Keep that up for a week and the project fills with work I have never looked at and couldn't explain. Then something breaks and I am lost inside my own repo. So I read what it ships, even the parts that pass their tests. The gap between what the project does and what I actually understand is a debt, and it always comes due at the worst possible time.

10. Judgment got more valuable, not less

I worried agents would make my judgment worthless. If anything they made it matter more. When writing the code is nearly free, the hard part becomes deciding what to build and telling good from bad once you see it. Some people call it taste. The agent has no view on whether a feature should exist, or whether a design suits the people who will use it. That part is still yours, and it is now the scarce one. The craft moved from writing the code to judging it.

None of this is a case for coding less with agents. I work with them every day and would not go back. But the tool rewards whoever keeps their standards and reads what it writes, and it lets down whoever stops paying attention. It is the same tool either way; what changes is how closely you watch it.