How to Actually Use AI Agents (Stop Treating Them Like Magic Wands)

This is Part 2 of the AI Agents series. If you haven't read Part 1 on the real cost of AI coding tools and why you're overpaying, start there.

The Real Problem With How People Use Agents

Most junior developers use agents. A lot. But there's a pattern I see over and over: they treat the agent like a magic wand.

"Build me a website."

"Make me a fullstack app."

"Write a complete ..."

One-shot prompts, no precise context, massive scope, long context windows. The agent spits out hundreds of lines. Half of it doesn't compile. A junior dev aka the true vibe coder gets frustrated and blames the model. They try a different model. Same result. They conclude "agents don't work."

Bro... Are you serious?

The developers who get real value from agents aren't the ones asking for the moon. They're the ones who are intentional. They say:

• "I wrote this function that takes these parameters. Fix this section's performance."
• "Plug this endpoint into that service."
• "Refactor this component to use the new API shape."

Surgical, specific, contextual. The agent isn't being asked to build something from scratch — it's being asked to do a job within an existing codebase that it can read and understand.

The best way to use an agent is not to ask it to build you a house. It's to hand it a blueprint, point at a specific wall, and say "move this window three feet to the left."

Most people aren't intentional with their agents. They don't give them enough context. They don't frame the task narrowly enough. They don't let the agent read the surrounding code before asking it to make a change. They treat it like a search engine that generates code instead of like a teammate that needs a clear brief.

The Models Are Already Good Enough

The OpenCode data proves it. DeepSeek v4 Flash — the top model by a landslide — is a fraction of the cost of the frontier alternatives. It's definitely not the most capable model on the bench. But it doesn't need to be, because the workflow around it does the heavy lifting.

The agent has access to the project. It reads the context, runs the tests, iterates on failures. The model just needs to be good enough to write code that passes those tests. And at $0.05/session, it's good enough to do that all day.

Supervised Collaboration

The real paradigm, as DHH put it, is supervised collaboration. The agent does the grunt work. You review the output, guide the direction, make the calls. This only works when the agent has real tools — terminal access, file editing, build execution. And it works best when you give it a specific job, not a vague ambition.

The model race is a distraction. The data is clear: real developers don't use the most expensive models. They use the ones that are cheap enough to run constantly and good enough to get the job done. What separates a productive agent session from a frustrating one isn't the model. It's whether you told the agent what to build, or whether you told it what problem to solve.