Agent coding tips
A list of ideas on how I improved my productivity using coding agentsHere’s a few things I do consciously to improve my productivity. While I wrote it in a prescriptive way for
terseness, take what suits you.
Infrastructure
- Get a high performance low cost linux i7 (or i5) server. Don’t get a i9.
- Chinese companies like Aoostar, Beelink,
GMKtec, MinisForum, etc.
- or take a free 4 core ARM64 VM from Oracle (!)
- Whatever that works, I use an old Intel NUC and a Dell on Ubuntu.
- You can work directly on a laptop, but I don’t. Otherwise it won’t work while on sleep.
- Setup Tailscale (free up to 100 nodes)
- Run your dev server via systemd user service, have it auto-restart on build. Nothing fancy, just has to
work.
- Use
<hostname>.<tailnet>.ts.net for your oauth callback URL so you can test from anywhere, including you
phone. Serve your dev server via tailscale serve --bg 8080 - Make changes remotely. Either via the “Remote - SSH” extension in VSCode/Cursor/Antigravity or via a ssh server.
Setup
- Use tmux sample config to quickly
navigate between multiple sessions, including F11/F12 to navigate panes. It enables you to not lose work
when ssh tears down. I use
alias s='if tmux has; then tmux -2 attach -d; else tmux -2; fi'
sample config - Use a way to contain your coding agents. I use md github.com/maruel/md for
containment, especially important for tests. Many don’t. It’s your choice.
- Make sure to configure git properly (sample config) and get comfortable with git
rebase and git mergetool. See my vim4way merge tool in my config. Use
noprefix,
dimmed-zebra,
pager = less -S -R -F -X. - Use something like
git-squash (github.com/maruel/git-maruel) so
you feel empowered to take a ton of snapshots but don’t pollute the git history in the main repo - Store your config in git, like my
bin_pub repository. I also have a private bin repository and an
agents repository that stores my coding agent configuration and skills. This way when a coding agent
edits my global skills, I can easily diff and revert if it’s not good.
Coding agent
- When you hit a small bug, start a parallel coding instance (e.g. a md
container). Ask it to first write a unit test to confirm the bug, only then fix it. This matters,
having the test confirming the broken behavior helps steer the model. Do all that while you continue on
your main task.
- When your coding agent find and correct a bad pattern in the code, immediately ask it to update AGENTS.md/CLAUDE.md or a relevant
skill with a one liner within the context window so the following coding agent doesn’t make the same mistake again.
- Regularly (every 10~20 changes or so) ask to do one of these and make a plan to fix these, as there’s
generally multiple independent tasks to complete.
- Investigate if there’s any structural issues or design mistakes (layering violation, poor separation of
concerns, security issues, etc).
- Investigate performance issues in various parts (database, bundle sizes for frontend, etc).
- Semantics matter. Take the time to rename variable, function, file and directory names when the purpose changes.
- Create auto-descriptive code. For example I asked my coding agent to add a one-liner comment to every
source file that describe the purpose of the file and to keep it updated. Then I have a script that runs on
each build that updates the AGENTS.md/CLAUDE.md file with a simple “file: description” bullet point list.
It’s very token efficient and really help steer the agent.
- If you are quota limited (hi Claude Max!), set up a cron job to run something like
claude --model haiku -p 'say hi' at 5:30am to start the quota a bit earlier in the day.
This is a very “local-first” list of recommendations. Claude Code Web is great and totally use it if
it fits your needs.
I hope you found a thing or two valuable!
Any tips to recommend? Ping me on Bluesky or Twitter!