Next Level Coding with Amp: Planning Before Prompting

I recently started using Amp, and it feels different from any AI coding tool I’ve used before. It’s a coding agent that lives in your terminal (and editor), and the way you work with it matters more than anything it can autocomplete.

The real shift: planning vs. execution

The biggest realization I had while using Amp (and reading about others’ workflows, like Boris Tane’s) is this:

Do not let the AI write code until you have a plan.

We often treat AI like a magic wand, throw a vague prompt at it and hope for the best. But that leads to hallucinations, wrong architecture choices, and wasted tokens.

With Amp, the workflow shifts. You become a technical architect first, and a coder second.

1. Research: I ask Amp to read my codebase deeply. It doesn’t skim; it understands the context.
2. Planning: I ask it to write a plan.md. I review the plan, tweak it, and correct assumptions before a single line of code is written.
3. Execution: Once the plan is solid, I tell Amp to implement it. And it just works.

Some prompts I actually use during planning:

• “Plan how to add a blogroll page to this Astro site, but don’t write code yet”
• “Read the codebase and explain how the content collections are structured”
• “Take a look at git diff and analyze what changed”

The planning step feels slow at first, but it saves you from going back and forth fixing things the AI got wrong because it didn’t understand your codebase.

Here’s a trick I picked up: do your planning and context gathering in one thread, then start a new thread for implementation. Amp lets you reference previous threads, so the implementation thread can pull in the plan without carrying all the back-and-forth exploration that led to it. This keeps the context window clean and focused. A bloated thread full of research tangents makes the agent worse at following through on the actual work.

Agent modes

Amp has three modes, and picking the right one matters more than you’d think:

• smart: The default. Uses the best models without constraints. This is what I use for most work, planning, refactoring, writing new features.
• rush: Faster and cheaper, but less capable. Good for small, well-defined tasks like “fix the TypeScript error in this file” or “rename this variable everywhere.”
• deep: Deep reasoning with extended thinking. I reach for this when I’m stuck on a complex bug or need to think through architecture decisions.

I usually start in smart for the planning phase, switch to rush for quick fixes, and pull out deep when something is genuinely hard to reason about.

Teaching Amp your codebase with AGENTS.md

This is something I wish I’d set up earlier. Amp reads AGENTS.md files in your project to understand your codebase conventions, build commands, and project structure. Think of it as onboarding docs for the AI.

For this blog, my AGENTS.md tells Amp things like: use Bun, not npm. Run bun run build to verify. Posts go in src/data/blog/. Notes use timestamp filenames. Tags are arrays. That kind of thing.

You can also put AGENTS.md files in subdirectories for more specific instructions. The agent picks them up automatically. Beyond that, Amp supports a .agents/ directory in your project where you can store custom tools, skills, and code review checks. It’s a single place to keep all your AI-related project config. Once you have this set up, you stop repeating yourself in every prompt.

Features that actually matter

A few tools make this workflow work well in practice:

The Oracle

Amp has a built-in “second brain” called Oracle (powered by GPT-5.2 with reasoning). I can ask the main agent to consult the Oracle for complex logic or architectural decisions. It’s like having a senior principal engineer on speed dial who doesn’t mind being bothered every 5 minutes.

For example: “Ask the Oracle to review this API design and suggest improvements.” The Oracle looks at the code, reasons about it, and gives you a second opinion.

The Librarian

This one changed how I approach the research phase. The Librarian can search my entire codebase (and even external repos on GitHub) to find context. It doesn’t look at just the open file; it understands how everything connects. That makes the research phase way more useful than manually grepping around.

Subagents

For repetitive or parallel tasks, Amp can spawn subagents. They work independently and keep the main context clean. A prompt like “Convert these 5 CSS files to Tailwind, use one subagent per file” actually works. Each subagent handles one file without polluting the main conversation.

Code review

You can run amp review in the CLI and it reviews your staged changes for bugs, security issues, and style problems. You can even define custom checks in .agents/checks/ to codify your team’s conventions. Things linters don’t catch, like “don’t use raw SQL in the API layer” or “every new endpoint needs rate limiting.”

Skills

Skills are reusable instruction packages that teach Amp how to do specific tasks. Amp ships with some built-in ones (like code review and commit message generation), but you can create your own. I have a custom skill for scaffolding new blog posts and another for proofreading drafts. You can also share skills across projects by putting them in ~/.config/amp/skills/.

Thread sharing

Every conversation with Amp is a thread, and you can share them. If I figure out a tricky migration or debug a weird issue, I can share the thread URL with someone and they can see exactly what happened, prompts, tool calls, code changes, everything. You wouldn’t code without version control, same idea.

CLI piping (amp -x)

This is for the power users. You can pipe terminal output directly into Amp for quick one-off tasks without starting a full session.

Generating a commit message from staged changes:

git diff --staged | amp -x "Write a concise commit message. Output ONLY raw text." | git commit -F -

Finding specific files:

amp -x "what files in this folder are markdown?"

Renaming files intelligently:

ls *.jpg | amp -x "Generate bash commands to rename these to photo_001.jpg, etc." | bash

These one-liners are surprisingly useful for scripting and automation.

Wrapping up

Amp rewards structured thinking. If you treat it like a junior dev who needs clear instructions, it performs like a senior dev who never sleeps.

Plan first, code second. The code is just the implementation detail.