How I use AI

I use agents for almost all my non-trivial code writing. This doc is a non-exhaustive, unordered list of how I think about agents and use them day-to-day.

  • I find that the more experienced I am in a domain, the more effectively I can wield agents. Agents are a tool.
  • If you're working on a non-trivial problem and don't know what to tell the agents to do or what context to give them, they'll struggle and so will you. Conversely if you're an expert on a domain and can provide good context to agents, they'll FLY.
  • I find that agents are orders of magnitude faster at writing code than I am. The question is: How do you get them to write good code?
  • Getting agents to write good code requires the same skills for getting anybody to write good code. You need context, documentation, instructions, abstractions, and system design. These skills come with expertise.
  • I try not to overengineer or prematurely optimize anything the agents are doing. The adage of "make it work, make it right, make it fast" still holds weight.
  • I try and do system design and planning as much as possible ahead of time. Writing good abstractions make using agents so much simpler. Otherwise they often run into unobvious things in the codebase and end up having to coordinate or think much more than normal. Avoid letting your agents output slop.
  • You should know what your agents are doing. The more you know about the system, the better you can design the context to give future agents.
  • Keep sessions as focused as possible. This isn't always easy. Yak shaving is real. Agents can go off-script if you don't keep them on the rails. Develop a separate context system to store things you need to remember for later. Most people use text files. I like using prog. More on agent orchestration later.
  • On small sessions: Amp has a great article on 200k token context being more than enough.
  • Amp again: they have a great tool on handing off work from one session to another. I turned this into a Skill.
  • Agents get worse the more context you use. Never compact. Log relevant context to an external source, like a textfile or prog, then start a new session.
  • If an agent doesn't do what I expect it's probably because they don't have enough context on the task I gave them.
  • I interrupt agents liberally to redirect them to the right problems and right solutions. They're getting much better at using the right solutions without prompting.
  • Agents do really well with great feedback loops. Make sure they write tests, run linting, and validate their work against the requirements. I turned this into a Skill called "Land the plane," a concept I stole from beads.
  • You can use agents to grade other agents. Does their code not conform to your standards? Write a Skill or spin up an agent to audit it and make them fix it. More on orchestration and parallelization later.
  • I've started using Skills quite liberally for the repetitive procedures and instructions. Need to release a package? Skill. Need the AI to stop using em-dashes in your changelogs? Run the skill after it's done writing the draft. Creating a PR and you want a specific format for the description? Skill.
  • Agents are incredible at using local tools. They love anything with a command line. I've started making local tools for agents just because they're so much faster to use, and agents love using them.
  • Use the gh CLI for interacting with GitHub. I wrote instructions for this into ~/.claude/CLAUDE.md. It will make doing things like filing PRs, managing repos, and viewing actions workflows much more efficient.
  • Feeding agents large implementation plans is brittle. They constantly need to be updated (and thus become stale), they're slow to parse, they're not queryable, and they're context inefficient. It's better to break them up into many small tasks and let the agents get to work more granularly. This is partly why I started using a local-first task management CLI like prog instead of text files.
  • I'm trying to not fall into the productivity porn trap with agents. There's lots of people building insane orchestration tooling. It's easy to feel like I'm falling behind. I'm probably not. It's easy to spend time trying to build productivity systems instead of just doing work.
  • There's no universal workflow for using agents. Everybody works differently. Build your own systems. I tried beads and Steve Yegge's way of harnessing agents and it didn't work for me long term.
  • I think that eventually knowledge workers will build digital factories. You won't be the weaver making the bolt of cloth. You'll be the factory owner orchestrating a fleet of looms. More on that later.
  • Most people gushing about agents and AI are using the frontier models: Opus and Codex.
  • Agent harness matters. Two different tools using Opus can have widely different outputs. I find that Claude Code, Opencode, Droid, and Amp have the best outputs for Opus. I mostly use Opus with Claude Code.
  • The things that are good for engineers are good for agents. Think good error messages, good git history messages, good logging practices, good abstractions, etc.
  • Writing good git history is super valuable for agents. Make sure it has plenty of context for why problems existed and how they were solved. Mitchell Hashimoto writes great commit messages and uses AI a lot in his development.
  • I use plan mode liberally, especially for work that I know is complex, requires changes in many places, or requires lots of tribal knowledge. That being said, often you can't plan everything ahead of time. Sometimes it's better to just start exploring in code. No plan survives contact with the enemy, and something about getting punched in the face, etc. etc.

Resources

Future thinking

  • We'll eventually all be making digital factories with agents. My guess is there's some optimal number of parallelized agents to maximize uptime by reducing conflicts. Conflicts will be the number 1 productivity killer and source of bugs. Like async runtimes, we should try to avoid conflicts as much as possible.
  • Deterministic simulation testing will become the default testing environment for all agent-built systems.

Logs