Blog

A few months with Claude

AI SLOP ALERT. This post (like most of mine) has been run through Claude! But it's mostly my words, don't let the emdashes fool you. And even where it isn't, I took the time to read and review.

Here's some stuff I've learned after using Claude in anger for a few months.

1. I never read code

When I worked at Codeglue we had the privilege of working on a very cool game: Terraria. We were in charge of porting the codebase from C#/XNA to C++ for iOS and Android. The history of Terraria is a heartwarming story — a guy teaching himself to program, making a little game along the way, and it turning into one of the biggest and longest-enduring hits there is.

I learned a valuable lesson working on that game, and it's that code quality does not matter. No shade to Red — like I said, this was effectively his first commercial game and it shows. The whole thing leans on magic numbers and conditionals, an endless wall of if (type == 512) {}; if (type == 513) {}.

I'm not exaggerating for effect, and you don't have to take my word for it — people who've gone spelunking through the decompiled source have documented it. The method that sets up every item in the game, Item.SetDefaults, is, in one modder's words, "an infinite sea of if (type == foo) { init(); }," with items "represented by magic numbers instead of enums." It got so big that it had to be physically chopped up: it's "split in 4 (!) separate methods, called SetDefaults1 through 4," because "the compiler manages to live with extremely huge methods, but the decompiler chokes on them." My personal favourite detail: "the control flow is so labyrinthine that some of the code is actually indented by 23 tabs."

But it all worked. It was fine. No. Body. Cares. About. The. Code. The game was — is — fun. And there was an elegance in the naive simplicity that let Red update fast and often. New item in the game? No problem, give it a number and add another if.

AI reminds me of Terraria. I don't care about the code. If it works, it works. If it doesn't, I tell the AI about the bug and it fixes it.

2. You still gotta kinda know how things work

This is an addendum to the above. The written code doesn't matter, but the algorithms do. I just deal with them through conversation. Implementing networking for my Zelda clone, I tell Claude to create input buffers, compare timestamps locally vs remote, re-simulate state, send remediation events when server and client disagree, and so on. I'll ask for pseudocode and comment on that. But I still don't look at the code — I just start the game and see if it works.

3. Orchestration is the key to speed

I've done a lot of 1:1 pair programming with Claude, like the networking algorithm above. But if you want to squeeze the most out of AI you have to parallelize. People are building full solutions for this — I'm enjoying Steve Yegge's blog about Gas Town, though I'm not enough of a frontiersman to actually run the thing (yet).

Here are some things that have helped me.

3a. Write your own orchestrator

Claude has an SDK that lets you spin it up programmatically. I used it to build a kinda-sorta Claude Desktop with orchestration baked in — taking "my" role as the user and inserting messages into Claude sessions. I found Claude 4.6 in particular got bad at following runbooks once they ran long, so my orchestrator would just drip-feed "and now step 2: \<do thing>" into the chat. It also used the SDK to kick off a bunch of sessions pointed at my Trello board: "do these."

The Claude SDK, however, is a sore spot for a lot of devs, me included. Anthropic is about to change it so those sessions burn special credits instead of your Pro or Max budget, which makes them wildly more expensive. Too expensive for me. If it weren't for that, I'd have tried to build a full Scrum cycle — an AI as product manager, one as scrum master, a few as devs, refinement meetings, retros, the lot. It would've been so cool. But alas.

At the same time Anthropic is building orchestration themselves — features like Workflows are showing up. But they're still pretty jank if you ask me. The big problem right now is I can't script them the way I want (my Scrum simulator), and I can't get into the sub-agents directly and talk to them. So they exist, they're okay, but they're not great. If they don't get their act together here, someone is going to overtake them.

3b. Encode your dev practices in a runbook

I called mine CONTRIBUTING.md. I still see Reddit posts going "have you heard about worktrees!?" — this stuff is table stakes, and pretty much hardcoded into Claude already. Claude ships with the knowledge and skills to do things properly, so write it down once and point it at your runbook next time you have a task. Here's mine:

  • Grab a Trello ticket
  • Create a git branch and a worktree
  • Grab latest master
  • Make a plan (if research is required, use the Research skill)
  • Implement
  • Spin up a separate code reviewer (Review skill)
  • Create a PR, merge back into master (fix merge conflicts)
  • Move the Trello ticket to Done, comment on what you did, update CLAUDE.md with anything new

I'm also thinking of adding the Simplify skill into this flow. Got a favourite skill of your own? Leave a comment!

3c. Use Trello (or JIRA if you really must)

Create cards yourself. Have Claude create them! There's a Trello MCP but it's very spammy, so I made my own CLI. I say I made it — I just told Claude to. You can use mine if you like, it's on GitHub.

3d. The combination

What I can do now is spend an evening writing feature requests and bug reports as Trello cards. Then I go "Claude, spin up subagents to implement all the tickets on Trello, use CONTRIBUTING.md for each" and watch it go brrr. No more pair programming.

This is where orchestration bites back, though: the brrr method takes me out of the loop entirely. So sometimes I'll instead just spam the "new chat" button and paste "Take the top Trello card and implement it" into every window. That way I can keep tabs on each ticket's progress, and Claude can ask me questions — which subagents seem reluctant to do.

4. Testing is key

Because the code doesn't matter but your app does, you need good tests. I'm honestly a bit rubbish at this, but if I were making something that mattered rather than toys for myself, I'd pour a lot of time into the test harness. One thing I recently made is a QA-Bot skill for Claude that really amounts to "use Claude-in-Chrome to run my app, raise bugs on Trello, keep a log of what works and what doesn't."

5. I don't understand how people run out of context

I don't even have memory enabled. All you need is:

  • Your Trello board as a history of what was done when
  • Save plans in a folder (more historical knowledge)
  • Keep CLAUDE.md up to date (I just tell Claude to do that in my CONTRIBUTING)
  • One session per Trello ticket! Don't keep grinding away in a single massive session! What are you doing!?

Claude is incredibly good at figuring out what happened by looking at code changes or tickets. You don't need to hoard 500K tokens of context.

6. Desktop is about as good as the TUI

Claude Code Desktop is roughly on par with the TUI — there are some flavour differences. But really, the TUI is going to die soon. This is the normal progression of apps: it's bending over backwards more and more to do things that really want a graphical UI. I had to press j and k to scroll a Workflows subwindow. I'd suggest just moving to Desktop.

I do wish they'd fix the one thing the TUI still does better: it lets you insert messages to Claude mid-turn, whereas Desktop waits for the whole turn to finish first. (True as of writing — the kind of thing that gets patched quietly.)

Which gets at something bigger. Because coding is so easy now, I've gotten used to just adding my own features and tools whenever I need them. So the fact that I can't go "Claude, make the Desktop app insert messages mid-turn rather than at the end" feels surprisingly limiting. I never used to feel this — but now I crave it. Give me your GitHub "compile this yourself" open-source stuff! I used to hate those. Who has time to spend a few evenings wrestling someone else's code into building, sorting the dependencies and the weird compiler errors? But now I'm like YES, A GITHUB APP. "Claude, steal this repo." It's great — but it don't work on Claude itself. It should. See also the closing note in this post.

7. Pick your settings

There was a good Reddit post the other day comparing settings. As I recall it, the Anthropic folks used a logarithmic scale on their graph to show off the gap between Claude versions and effort levels, which flatters the differences more than a linear axis would. The best bang for my buck has been Opus 4.8, High, Fast.

Worth noting for anyone who assumes "fast = dumber": Fast mode is still Opus, just with faster output — it doesn't quietly swap you down to a smaller model. So High + Fast isn't a quality trade, you're getting the big brain either way.

8. You don't need a wall of plugins

You don't need a ton of plugins to save tokens. Caveman is a fun meme but — please, what are you doing. I do use RTK, because it makes sense to me.

9. Don't put all your eggs in Anthropic's basket

Local LLMs are coming. Another thing Anthropic will have to contend with.

So let's talk about Anthropic generally. Don't get locked in. Right now Claude is top dog — partly because the models are genuinely good, partly because the harness is good. But ironically the product may be its own undoing. Everyone's making harnesses. PewDiePie built his own thing (ChatOS, a self-hosted UI sitting on top of local models) — and he's even got OpenCode running inside it. I just made a harness. Claude's harness locks you in: no local LLMs (already very good if you have the VRAM, though still at the toy level — not for long), no ChatGPT, no Gemini.

I'd recommend taking a look at OpenCode. Personally I'm still on Claude, but that's just because I'm a fool. Don't be like me. Be better. Especially if you're not a hobbyist: be able to jump between LLMs, so you don't get caught out when subscription terms change, and so you can add your own features to the tools you use.

Appendix A: tools I lean on

Use all of these. The beautiful part is you don't need a setup guide — just ask Claude how to wire each one up and it'll walk you through it.

  • GitHub (gh CLI) — let Claude open PRs, merge, and read issues straight from the terminal.
  • Trello — my whole ticket workflow runs on it. There's an official MCP, but it's spammy, so I use my own TrelloCLI.
  • Google Workspace — the connector for Gmail, Calendar and Drive is pretty nice too. Hand Claude your inbox and calendar and let it do the boring bits.
  • RTK (Rust Token Killer) — wraps noisy commands and trims their output. Saves a pile of tokens on builds, tests, and git.
  • Research skill — the anti-hallucination researcher I used to dig up the Terraria details in section 1. I made it by pointing Claude at Anthropic's own Reduce hallucinations guide and saying "make it a skill."
  • Review skill — spins up a fresh agent to review your diff with no prior context. Part of my runbook in 3b.
  • My own blog skill — yes, this very post was written and published through a skill I made. Meta.
  • pyright-lsp — gives Claude real LSP smarts (go-to-definition, find-references) on Python instead of grepping around.

Appendix B: keep a global CLAUDE.md of fixes

Goes back to point 5. Hit a quirk, figure out the fix, write it in the global CLAUDE.md — the one that loads everywhere. Now I never debug it twice, and neither does Claude. A few of mine:

  • The Edit tool mangles em-dashes on Windows (there's a whole glut of open issues about it). So I wrote a helper script and told Claude to use it and stop fighting the tool. (Writing this in a post full of em-dashes is not lost on me.)
  • "Sibling tool call errored." One call in a batch dies, the harness kills the rest (known bug). Looks like the tools are broken. They're not. Don't re-run the bad one in another batch.
  • Small stuff: python not python3, PYTHONIOENCODING=utf-8 or emoji blow up, LSP over grep, TLDR after every change.

Write it down once.

Claude almost never tells me to go to bed.

Comments (0)

No comments yet. Be the first!