If your workflow is "paste code, ask nicely, copy the answer back, repeat," you're not using an AI engineer. You're using a very expensive parrot with a good vocabulary. Here's how to stop.
Here's an uncomfortable truth I had to learn about myself: for the first month, I was using a coding agent the exact same way I use a group chat. Type a thing. Wait. Read the reply. Copy the good part. Ignore the rest. Type another thing.
It worked, in the way that eating cereal with a fork "works." You get some cereal. You also spill a lot of milk and question your life choices.
The people getting genuinely absurd output from these tools aren't smarter than you and they don't have a secret prompt. They just stopped treating the agent like a chatbot and started treating it like a report — one that's fast, tireless, weirdly literal, and will absolutely drive off a cliff if you point it at one. Here are the six habits that make the difference, ranked roughly by how much they embarrassed me when I finally noticed.
1. You paste code into the chat. Tech leads let it read the repo.
The chatbot move: copy the file, paste it in, describe the other three files it needs to know about in a paragraph of English, and pray.
This is like emailing a contractor a photo of one wall and asking them to renovate your kitchen. They'll give it a heroic try. It will not go well, and it's technically your fault.
Give the agent access to the actual codebase and let it read — the neighboring files, the imports, the conventions, the thing three directories over that explains why this weird function exists. The difference in output is not subtle. Code written by an agent that read your repo looks like your repo. Code written by an agent that read your paragraph looks like it was airlifted in from a tutorial written in 2019.
An agent working from your description writes plausible code. An agent working from your codebase writes your code. Those are not the same product.
2. You ask one giant question. Tech leads give one shaped task.
We've all done it. "Build me the whole auth system with OAuth and password reset and rate limiting and also make it secure and also write the tests." Then you sit back like you've delegated, when what you've actually done is handed someone a treasure map with no X on it.
The agent will produce something. It'll be big, it'll be confident, and about 40% of it will be answering a question you didn't ask because you left a gap and it filled the gap with vibes.
Shrink the task until it has exactly one shape. "Add a rate limiter to this endpoint, 100 requests per minute per IP, return 429 with a Retry-After header." Now there's an X on the map. Now "done" means something. You can always run five small shaped tasks in a row — and unlike the giant one, you'll be able to tell which one broke.
3. You write tests to check the code. Tech leads write tests to trap the agent.
This one hurt. I used to let the agent write the implementation and the tests, watch the tests go green, and feel a warm sense of accomplishment.
Reader, the tests were green because they were testing the agent's misunderstanding against itself. It's two liars agreeing. The code did the wrong thing, and the tests confirmed — with 100% coverage and a cheerful little checkmark — that it did the wrong thing correctly.
A test suite written by the same agent that wrote the code isn't proof the code is right. It's proof the code is consistent with its own bad idea.
The fix is to write the tests — or at least the cases — before the agent touches the implementation:
| Who writes the cases | What green means |
|---|---|
| The agent, after coding | "This agrees with itself" 🙃 |
| You, before coding | "This does what I asked" ✅ |
"It must handle empty input, it must handle 10,000 rows, it must reject negative numbers." Now the green checkmark is a fact instead of a feeling. Now the tests are a trap the wrong answer can't walk through, instead of a mirror the wrong answer poses in.
4. You trust the confident voice. Tech leads verify the confident voice.
Coding agents have exactly one tone: completely sure. It writes "This fixes the race condition" with the same serene confidence whether it fixed the race condition, created a new one, or hallucinated the existence of the race condition entirely.
There is no nervous tone. There's no "look, I'm 60% on this one, maybe double-check." It is a golden retriever that has never once considered that the ball might not be there. This is delightful in a pet and terrifying in a thing writing your production code.
So you verify. Not because the agent is dumb — it's shockingly good — but because "sounds sure" and "is right" are unrelated variables, and the only one you can see is the wrong one. Run it. Read the diff. Check the edge it swears it handled. The confidence is a personality trait, not a signal.
5. You start every session from scratch. Tech leads leave the agent a note.
Chatbot habit: fire up a fresh session, re-explain the entire project, the conventions, the gotcha with the timezone thing, the reason you don't use that one library — every single time, like a detective in a movie where you're the only one who remembers the murder.
Tech leads write it down once, in the repo, where the agent reads it automatically — a conventions file, a "here's how this project works" doc, the rules and the landmines. The agent follows rules it can see. It cannot follow the rules living in your head, no matter how strongly you're thinking them, because — and this took me longer to accept than I'd like — it cannot read your mind. Truly the most disappointing limitation of the future.
The agents that magically "just get" your style aren't magic. Someone wrote the style down where they could read it. That someone can be you, once, instead of you, every morning, forever.
6. You wait and watch it type. Tech leads go do literally anything else.
If you are sitting there watching the agent generate code token by token like it's a slot machine about to pay out — I say this with love — you are not being a tech lead. You are being a very anxious spectator.
The whole point is that the work happens without you standing over it. Give it a shaped task, a repo to read, tests to pass, and go review the last thing it finished, or write the spec for the next one, or drink water like a person. The single biggest unlock isn't a prompt. It's the psychological leap of trusting the setup enough to look away — and building a setup good enough to deserve it.
Because here's the thing that ties all six together: the difference between a chatbot and an engineer was never the model. It's the same model. The difference is everything around the model — what it can read, how sharp the task is, whether the tests are a trap or a mirror, whether the rules are written down or wished for.
You don't get 10x by finding a better AI. You get it by building a better cage for the one you've got.
The one-line version
If you remember nothing else: stop chatting, start delegating. A chatbot answers your question. An engineer needs a spec, a codebase, a test, and a boss who checks the work. Give the agent all four and it stops being a parrot with a CS degree and starts being the most productive report you've ever had.
It still won't tell you when it's about to do something stupid. But at least now you'll have a test standing in the doorway.
Okay, be honest — which of these six is you? (Mine was #3, and I stand by nothing about that month.) Drop the one you're guilty of below. 👇
I write about the honest mechanics of building software with AI agents — the stuff the demos leave out. Follow me here if that's your lane. 👋
Top comments (0)