How I work with Agents

Tip 1 of 15

Use the latest and greatest models.

Everything else is potentially a waste of time. If a model is wrong 10% of the time, you don't know which 10%, so you end up making multiple attempts. When do you really want to hire a generalist who's 50% cheaper but also randomly 20% dumber? Who's still using Opus 4.5? Exactly.

— Thorsten Ball, “How I work with Agents” on X ↗

Tip 2 of 15

Stop worrying about accumulating slop.

"It'll turn your codebase into an unmaintainable mess." Maybe that was true six months ago. Now? I'm not convinced it adds slop. And even if it does, I'm not convinced the result is unmaintainable.

— Thorsten Ball, “How I work with Agents” on X ↗

Tip 3 of 15

Prompt the What, not the How.

Describe What you want, now How you'd do it. You'll often get better results. "Make the bytecode compiler and VM AS FAST AS YOU CAN. Do not stop until it's 2x faster." "Here's how it should work in the end"

— Thorsten Ball, “How I work with Agents” on X ↗

Tip 4 of 15

Make the whole SDLC legible to the agent.

What stopped hallucinations? Tool calls. They let agents touch our reality. If the agent can't see something, it makes it up. So let it run what it builds end to end, let it read production logs, deploy, watch the rollout, cut the release, flip the flag, triage the bug report and email the customer. Anything you can see, the agent should see too.

— Thorsten Ball, “How I work with Agents” on X ↗

Tip 5 of 15

Give it tools for the SDLC.

We have custom plugins for bug reports, emailing users, "Is our system healthy?" and granting featuer flags.

— Thorsten Ball, “How I work with Agents” on X ↗

Tip 6 of 15

Eval agentic knowledge.

Knowledge piles up in the codebase: AGENTS.md files, skills, scripts, docs. But do agents actually use it? Spawn five blind agents, control vs. treatment, and find out. Agents are really, really good at running experiments.

— Thorsten Ball, “How I work with Agents” on X ↗

Tip 7 of 15

Local dev feels yucky now.

Each agent should be able to install and run whatever it needs to get job done. Easy in remote machines, yucky in local dev. Hard to not run into resource conflicts locally when you want agents testing stuff end to end.

— Thorsten Ball, “How I work with Agents” on X ↗

Tip 8 of 15

Don't iterate with the agent. Let it build tools to iterate.

Not "let's try this. ... ah no, let's try that." Instead: "Generate 20 variations and a little page that lets me combine and test them." Not only applies to solution space, but also problem space: "Give me 4 theories on why this is slow, then check all four."

— Thorsten Ball, “How I work with Agents” on X ↗

Tip 9 of 15

Ask for irrefutable proof.

Biggest game changer. Agents are really good at producing proof: end-to-end walkthroughs, demo videos, before/after numbers. You have to build up trust and an instinct for this. Put "this is not evidence" in your AGENTS.md.

— Thorsten Ball, “How I work with Agents” on X ↗

Tip 10 of 15

Don't wait for your agents. Let them wait on you.

If you worry about TTFT, you're probably doing something wrong. Lean into async. Give them bigger tasks, be more ambitous. Batch instead of back and forth.

— Thorsten Ball, “How I work with Agents” on X ↗

Tip 11 of 15

Automation/schedules/wake-up/heartbeat are killer feature.

Didn't realize it, but missed it dearly once it was off. Use it all the time. "Check the logs in 2hrs." "Let me know once this is live" "Check every day at 9am".

— Thorsten Ball, “How I work with Agents” on X ↗

Tip 12 of 15

Stop manually managing context.

Every thought you spend wondering about "is it using 300k or 380k tokens?" is wasted time. Compaction works incredibly well. Don't manage context by hand. One thread = one task. Some threads are 46 messages, some are 3,714.

— Thorsten Ball, “How I work with Agents” on X ↗

Tip 13 of 15

Threads are your company memory.

(In Amp) "Why did we do this?" The more team uses Amp the more knowledge multiplies. Threads are connected to git commits. Game changer. Avoids duplicate work.

— Thorsten Ball, “How I work with Agents” on X ↗

Tip 14 of 15

Don't let agents write for humans.

Except: debugging steps, inicident reports, some docs. Mechanical stuff where human on other end doesn't matter that much.

— Thorsten Ball, “How I work with Agents” on X ↗

Tip 15 of 15

Review only code with high blast radius.

There are <5 central files -- those I review. Database migrations, yes. Closure vs. class, a neater type, variable names, even duplication: I don't care anymore. Does it work? Do I understand it at the arrows-in-a-diagram level? Did the agent test it end to end? Can I change it in a month? If yes, might review code.

— Thorsten Ball, “How I work with Agents” on X ↗