There's a strange ritual happening across the industry right now. Engineers spend more time crafting the perfect prompt than they would have spent writing the code themselves. They build elaborate agent orchestration systems, maintain 2,000-line instruction files, and debate subagent architectures on Twitter - all while shipping less than they did six months ago.

I've been using AI coding agents daily for over a year now. The single biggest productivity unlock wasn't a better model, a fancier harness, or a cleverer prompt template. It was learning to just talk to the thing like a coworker.

The Overcomplicated Setup Trap

Every few weeks, someone shares their "ultimate AI coding workflow" and it looks like a NASA mission control diagram. Multiple specialized agents with role-based system prompts. RAG pipelines indexing their codebase. Custom MCPs for every third-party service. A 47-step checklist before the model writes a single line of code.

And then you look at what they actually shipped. It's a todo app.

I fell into this trap too. Early on, I spent a full weekend building a custom orchestration layer that would break tasks into subtasks, spin up specialized agents for each one, and merge the results. It was architecturally elegant. It was also slower and worse than just opening a terminal and telling the model what I wanted.

The models have gotten good enough that the elaborate scaffolding is usually overhead, not leverage. When I stopped trying to control every aspect of the interaction and started treating the agent like a capable engineer who just needs clear direction, everything got faster.

What Actually Works

My workflow is embarrassingly simple. I open a terminal, describe what I want in plain language, and let the agent work. Sometimes I paste a screenshot. Sometimes I say "look at the auth module and tell me what you think before changing anything." That's it. That's the workflow.

A few things I've learned matter more than any setup:

Think about blast radius. Before I send a prompt, I think about how many files it'll touch and how long it should take. Small, focused changes are easier to review and safer to land. If I need something big, I break it up myself rather than hoping the model will scope it correctly. This isn't prompt engineering. It's just engineering.

Watch while it works. I don't fire off a prompt and go make coffee. I watch the first 30 seconds. If it's reading the wrong files or heading in a wrong direction, I stop it early. The cost of catching a bad direction early is almost zero. The cost of letting it run for five minutes down the wrong path is a wasted context and a messy diff.

Queue, don't batch. Instead of writing one massive prompt that describes five changes, I send them one at a time. Each change gets its own clear scope. If the model finishes one and still has context space, great - I send the next. This gives me natural checkpoints to review and course-correct.

Use your eyes, not just your tests. For anything with a UI component, I keep the browser open and watch the dev server update in real time. If something looks off, I say so immediately. A screenshot with "this padding looks wrong" is worth more than a paragraph of CSS specifications.

The Prompt Length Paradox

There's a counterintuitive thing that happens as models get better: your prompts should get shorter, not longer. Early models needed extensive hand-holding. You had to describe your codebase, explain your patterns, provide examples of what you wanted. With current models, a two-sentence prompt often gets me exactly what I need because the model reads the codebase itself and figures out the patterns.

I used to write prompts like: "In the file src/components/UserProfile.tsx, add a new section below the bio that shows the user's recent activity. Use the existing ActivityFeed component from src/components/ActivityFeed.tsx. Make sure to follow the same Tailwind patterns used in the rest of the file. The data should come from the useUserActivity hook..."

Now I write: "Add a recent activity section to the user profile page."

Same result. The model finds the right file, discovers the existing components, matches the patterns, and wires up the data. All the context I used to manually provide, it now gathers on its own by reading the codebase. Every token I spend over-specifying is a token wasted - or worse, a token that constrains the model from finding a better approach than the one I had in mind.

The Refactoring Habit

I spend roughly a day per week on refactoring, all done by agents. This isn't busywork - it's maintenance that keeps the codebase navigable for both me and future model runs.

Typical refactoring prompts:

  • "Find any duplicated logic between these two services and consolidate"
  • "This file is over 400 lines, break it into logical modules"
  • "Run the linter, fix everything, and explain what was wrong"
  • "Add comments to the tricky parts of the payment flow"

Code comments are underrated. They help the model understand intent on future runs, which means shorter prompts and better results. It's a compounding investment.

What I Stopped Doing

Stopped writing spec documents before building. I used to write detailed specs and hand them to the agent. Now I start a conversation, describe the idea roughly, and iterate. The model shows me something, I react, we go back and forth. It's faster and the result is usually better because I'm making decisions based on what I see rather than what I imagined.

Stopped maintaining huge instruction files. My agent instructions are maybe 50 lines. Project context, a few patterns I care about, some guardrails. Every line in that file costs tokens on every single interaction, so it better be worth it. Most of the "best practices" people put in these files are things the model already knows.

Stopped chasing tools. Every week there's a new AI coding tool that promises to revolutionize the workflow. I tried dozens. The ones that survived are the ones that stay out of the way and let me talk to the model directly. The thinner the layer between me and the model, the better the results.

Stopped trying to eliminate all manual review. Some people want fully autonomous coding where the agent ships to production without human review. That's not the goal. The goal is to eliminate the tedious parts - the typing, the boilerplate, the "I know exactly what this should look like but it'll take 40 minutes to write" work. The thinking, reviewing, and deciding parts are still mine. That's where the value is.

The Real Skill

The engineers getting the best results from AI agents aren't the ones with the most sophisticated setups. They're the ones with the best intuition for software. They know what good code looks like. They can smell a bad architecture from the first few files. They know when a model is heading in the wrong direction because they've seen that wrong direction before, in their own code, years ago.

That intuition doesn't come from prompt engineering courses or agent configuration tutorials. It comes from years of building things, breaking things, and debugging things at 2 AM. AI doesn't replace that experience. It amplifies it.

The gap between a junior engineer and a senior engineer using the same AI tools is enormous - and it's getting bigger, not smaller. The senior ships faster because they know what to ask for, when to stop the model, and which shortcuts are safe to take. The junior ships something that looks right but breaks in production because they couldn't evaluate what the model gave them.

So if you want to get better at AI-assisted development, stop optimizing your prompts and start optimizing your engineering judgment. Read more codebases. Understand more systems. Develop stronger opinions about how software should be built. Then just talk to the thing.

It's listening. And it's better at its job than you think. The question is whether you're good enough at yours to direct it well.