Directing an AI that writes code is a skill, not a shortcut

The first stop on my AI roadmap is not about building AI features. It is about the thing most people already do every day and almost nobody learns properly: using an AI to write code. It looks like a shortcut. It is actually a skill, closer to directing than to typing, and the people who get great results from it are doing a few specific things that the people who get a mess are not.

From autocomplete to an agent that touches your files

There is a big difference between the two kinds of AI coding, and the word for the second kind is agentic. Autocomplete suggests the next line while you type. An agentic coding tool reads your whole project, edits files, runs commands, checks the result, and keeps going until the task is done. Claude Code, Cursor, and Codex CLI all work this way.

The useful mental picture: you have hired a junior developer with superhuman speed and a short memory. They can produce a working feature in minutes. They will also confidently build the wrong thing, forget a convention you mentioned an hour ago, and never notice a test they broke, unless you set things up so they do. Everything in this stop is about that setup.

The loop that stops it solving the wrong problem

The single most useful habit is to separate thinking from typing. The common shape has four phases, and the mistake beginners make is jumping straight to the third.

flowchart LR
  E[Explore: read the code] --> P[Plan: agree what to change]
  P --> I[Implement: make the edits]
  I --> C[Commit: save a checkpoint]
  C -->|next task| E

Explore means letting the agent read the relevant code before it changes anything. Plan means asking for a plan and reading it, so you catch “I was going to rewrite the whole login system” before it happens. Only then implement, and commit as soon as something works, so the next experiment has a safe place to fall back to.

The one file that saves you every session

A junior developer with no memory needs a briefing every morning. For an agent, that briefing is a project context file, usually named CLAUDE.md or AGENTS.md. Most agentic tools read it automatically at the start of every session, and in 2026 AGENTS.md became a shared standard across Claude Code, Cursor, Codex, Copilot, and others.

What belongs in it is the stuff the agent would otherwise have to guess:

• How to build, run, and test the project.
• The architecture in a few lines, so it does not propose something that breaks it.
• The conventions: naming, folder layout, the things you always want done a certain way.

# Project
Astro site with content collections. Blog posts live in src/content/blog.

# Commands
- npm run dev
- npm run build (must pass before a commit)
- npm test

# Rules
- Never edit node_modules. Never commit .env.
- New pages need a matching entry in src/consts.ts.

Managing what the agent can hold in its head

An agent works inside a context window, a finite amount of text it can pay attention to at once. Every file it reads, every wrong turn, every long error message fills it up, and once it is full of dead ends the quality of what it produces drops. Handling this is called context engineering, and two habits cover most of it.

First, correct a bad turn early. If the agent heads the wrong way, stop it and redirect immediately, rather than letting three more steps pile onto a wrong assumption. Second, give it fewer, sharper tools. Agents can connect to external tools through MCP (Model Context Protocol, a standard way to plug tools in), but mounting every tool you own at once just fills the window with menus. Connect what the task needs.

Review it like you would any junior’s work

Here is the part that separates a professional from someone who got lucky. Speed is the agent’s job. Judgment is yours, and it does not transfer.

• Give clear constraints up front, and demand a plan for anything non-trivial.
• Insist on tests, and read the result yourself. “The agent said it passed” is not evidence.
• Gate changes: the agent proposes, you approve. Especially for anything touching data, money, or security.
• Do not let the worker grade its own homework. If you can, have a fresh pass verify the result rather than trusting the one that wrote it.

The tools you actually reach for

Speed is theirs, judgment is yours

The lesson from this first stop is the frame for the whole roadmap. An AI that writes code makes building fast, and that speed is real. But what you get out of it is decided by the setup around it: a plan before the build, a lean briefing file, a managed context, and a human who actually reviews the result. Skip those and you get a pile of confident, fast, wrong code. Do them and you get a tireless partner. That is why this comes before building AI into anything: you need to be good at directing it before you can trust anything it helps you ship.

Let the AI type. Keep the thinking.

Sources

• Claude Code docs: best practices for plan mode, CLAUDE.md contents, and the verification loop
• OpenHands: 10 Claude Code best practices for agentic coding (2026) for the explore, plan, implement, commit loop and treating the agent as a fast junior
• Augment Code: how to build your AGENTS.md (2026) for AGENTS.md as the cross-tool standard and keeping it lean
• Sourcegraph: context engineering, a practical guide (2026) for the finite context window and fewer, sharper tools