Skip to content
Austin

Agentic Tips & Tricks

I’m productive as hell with AI. Why? I’m not really sure. Let’s see if writing it down will help.

Disclaimer: If you’re new to agentic coding, this page may help you. If you’re really experienced, I’m probably going to piss you off. This assumes you’re a working developer who knows git and is comfortable in a terminal.

Core Principles

Section titled “Core Principles”

The #1 most important thing: you will spend more time planning than prompting. That’s the whole game.

Planning up-front solves two problems:

  • The agent is less likely to go off and do its own wrong bullshit
  • You will have a better understanding of what the agent is doing

Your success with AI is a function of:

  1. Your understanding of the goal you’re trying to achieve
  2. Your ability to write down that goal clearly
  3. Your ability to plan the work in chunks that fit a context window

The agents are actually wonderful at doing all three of those with you, so don’t fret if you think you’re bad at them. But before you have an agent go off and do a thing, be sure that you can articulate what you want and there is a plan that both you and the agent agree on.

Setup

Section titled “Setup”
  • Use VSCode
  • Use Claude Code or Codex
    • Strongly recommend starting with Claude Code.
  • Consider BMAD — a framework for structuring how you prompt agents. If you’re new to agentic coding, it helps you think about prompting narratives.
  • Non-negotiable
    • If you’re on GitHub, install and configure the GitHub CLI
    • If you’re on GitLab, install and configure the GitLab CLI
    • Get comfortable with a terminal. Do not pursue UI tools.
    • Protect your master/main branch and prevent commits directly on it

Planning

Section titled “Planning”

Power move: Preparation beats everything. Plan before you let the agent run wild.

shift+tab in Claude Code cycles between “edit” mode and “plan” mode. For complex tasks, always start with planning.

Planning with Claude will produce a document covering things like:

  • Objective: What are we doing?
  • Scope: What are known future concerns?
  • Guardrails: What should I avoid?
  • Location(s): Where are the relevant files?
  • Implementation Details: Use FrameworkX, or avoid FrameworkB

When working with Claude in planning mode, do not just always Accept Plan and continue. Actually read the damn thing. If something looks off — keep iterating until it’s right.

How to Plan Even Better

Section titled “How to Plan Even Better”

Power move: Plan mode gets tedious for bigger plans. Skip plan mode for complicated features. Create a markdown document instead.

  • Create a gitignored directory in your repo, i.e., /plans
  • When you start on a complex feature, create a /plans/feature-x.md file
    • Put a LOT of description in here about what you want to accomplish, why, how, etc.
  • Go to Claude and try prompts like this:
Read /plans/feature-x.md. We are working on a feature.


Use the markdown file to track:


- Your questions and my answers
- Your implementation plan including task lists that you update as you go
- Your context, so we can recover in cases of agent termination or compaction


Review the doc, determine if you have any questions, ask me and update the doc with my answers.
Once you and I have answered all questions and the document reflects the agreed-upon plan, let's implement it.
Then, commit and push a feature or fix branch into a draft MR or PR assigned to me.


Do this all in a worktree to avoid colliding with other agents.

Context Management

Section titled “Context Management”

Power move: If you see that your conversation is being Compacted… kill that Claude session and restart. Straight up.

When context gets compacted, Claude may have forgotten the most important things you told it. And at high context utilization, Claude starts sucking anyway.

Power move: Use /context in Claude to see current context usage.

CLAUDE.md

Section titled “CLAUDE.md”

In any new project you work on, you must have a good CLAUDE.md. This should be descriptive about the architecture of the project. Open Claude and do /init. Commit the file(s) it produces.

You should have:

  • A really good CLAUDE.md
    • Don’t just “Take” what /init gives you.
    • Actually read the damn thing.
    • Propose edits or make them yourself.
  • A really good README.md
    • Humans need to remember and do work too

Power move: Expect to update CLAUDE.md all the time. If you find something about your codebase, coding preferences, or tech stack — ask Claude to document it for future reference. Find Claude doing something stupid you hate? Tell it to update CLAUDE.md to avoid doing that stupid thing in the future.

Power move: Reference other files in CLAUDE.md. For example, create a /docs/coding-standards folder and tell Claude to respect coding standards. Or reference skills that you might use in your repo.

Worktrees

Section titled “Worktrees”

Power move: Have multiple Claude instances open and work on multiple things at the same time in the same repo.

A git worktree is kind of like a “branch” in git, but it’s also isolated from other worktrees. You can’t have two branches checked out at the same time and work on them in parallel. But you can have two (or more) worktrees at the same time, working on changes in parallel.

Begin your sessions by saying something like:

In a worktree, let's start planning or doing X


When finished, commit and push a feature or fix branch and MR/PR assigned to me.

When you’re done, tell Claude to destroy that worktree.

GitHub/GitLab CLIs

Section titled “GitHub/GitLab CLIs”

Power move: Create PRs from the CLI. Add comments to PRs from the CLI. Create issues from the CLI. Search for issues from the CLI. Everything from the CLI.

Claude works best with CLI tools. The GitHub and GitLab CLI tools are invaluable for effectively working on PRs, issues, and comments.

Update CLAUDE.md and tell it which tool you’re using and to always use the CLI when interacting with GitHub/GitLab.

Power move: Use Claude to quickly create issues in your backlog:

I'm going to describe various things to you (fixes and features and ideas) and I want you to create GitLab issues for them to resolve in the future.


Do whatever code exploration you want to do to make the ticket meaningful.
Ask clarifying questions. My goal is to create a backlog of shovel-ready work.

Why PRs Even If I’m Solo?

Section titled “Why PRs Even If I’m Solo?”

Using Pull Requests even on solo projects does several things:

  • You can start and stop work at will — the agent is very good at picking up where you left off
  • You can create test plans as comments on the PR
  • It’s easier to do a legit code review in GitHub or GitLab
    • Like “Hey Claude I’m lazy. Make a PR for this so I can use the nice GitHub UI to see your diff”

Power move: The most important aspect of having a PR is /review from a separate Claude instance. Yes, you can /review without a PR, and yes you can /review in your own execution instance but:

  • When Claude creates a PR for you it will say what it’s doing, why, what the outcome should be, and how to test it
  • When you /review against that PR, it evaluates that context and compares it to the implementation

Workflow:

  • 1 worktree (or just a single branch)
  • 2 Claude instances
    • Claude 1 -> implement code, produce PR
    • Claude 2 -> review PR with /review
    • Human -> Take feedback from Claude 2 and put it into Claude 1. Update PR.
    • —> Loop <—

When Things Go Wrong

Section titled “When Things Go Wrong”

This will happen. The agent will produce garbage, go in circles, or confidently do the wrong thing. Some patterns:

  • Kill the context and start fresh. If the agent is stuck or confused, don’t keep throwing prompts at it. Start a new session with a clear prompt. Your /plans doc and CLAUDE.md will get it back up to speed fast.
  • Get smaller. If a task keeps failing, break it into smaller pieces. The agent probably can’t hold the full problem in context.
  • Read the diff before you approve. Every time. Don’t get lazy just because the last 5 changes were good. The 6th one might rename your database.
  • Don’t let it “fix” things you didn’t ask about. Agents love to “improve” nearby code. If you see unrelated changes in a diff, reject them.

Skills & MCP Servers

Section titled “Skills & MCP Servers”
  • Skills let you define reusable prompts and workflows.
    • Power move: For work that is custom to your project, create custom skills.
    • Skills.sh has community-built skills — install ones relevant to your project in project scope and commit them so all agents and users get them.
  • MCP Servers let agents talk to external systems — logs in AWS, metrics in Posthog, designs in Figma, etc. Invaluable when your work spans multiple tools.