AI tooling audit

What I actually use. Last audited Sept 5, 2026.

Before November 2025 I did not trust an agent to write large chunks of code, or to have the best answer to a small problem every time.

Not as a position. As a verdict, and a narrower one than it sounds. They were already very good at the things around the code: learning something new, documentation, discovery, and getting close enough to the right answer that a good programmer could tap it in from there, especially if you were disciplined about working in small hunks. What none of them were worth yet was the cost of checking code they had written on their own.

Opus 4.5 was the first model I would let work at larger scope without hand-holding, and even then I kept it on manual mode for most of it, approving each action rather than turning it loose. From 4.7 on, I review instead. The agent works and I check the output.

What changed there is worth being precise about, because it is easy to read as me relaxing. The verification did not go away. It changed granularity. Manual mode was checking every action. Review is checking every outcome. What moved was where the check is cheapest to apply, not whether one happens.

What let me get there was not only better models. It was containment. I run each agent in its own branch and workspace now, so it can work as hard as it likes and nothing reaches the real branch until I have passed it. Per-action approval is what you do when the blast radius is your working tree. Review is what you can afford once a bad run is something you can throw away.

None of that is new technology. Branches and worktrees have been there the whole time. The combination of that workflow with agents that grew more capable and more trustworthy over time hit a tipping point.

That is the whole of my position on these tools, and it is why this page exists. Everything below earned its place or lost it on the same standard.

@@ unchanged @@Use daily

Claude Code: Primary development environment. Custom slash commands, hooks, subagents, CLAUDE.md as the per-repo contract, headless patterns. Slash commands, not skills: see the Cursor row.
Conductor: In-repo work. Parallel Claude Code sessions, one git worktree per workspace, GitHub issues as the unit of work. The unlock is branch and workspace integration: auto mode can run hard because nothing reaches the real branch until review passes, which makes a hallucination disaster fully recoverable.
Tiered model routing: Frontier model orchestrates, cheaper models do mechanical work. Used in production on the Warmongers reboot and the grading pipeline. Cost split runs roughly 60/30/10.
MCP servers (built and consumed): yt_transcript_mcp, written in Swift 6 against the InnerTube API, in daily use since Mar 2026. Video is the slow path for information, so it gets turned into text first.
Database-backed tracking via MCP: Submission, feedback, and design-doc tracking behind an MCP integration.
Plannotator: Annotation review loop over plans and diffs, so review comments come back into the session instead of living in a chat scroll.
git and GitHub issues: Issues are the review trail, not a formality. Findings get issue numbers, and the closing commit references them. LFS for game assets.
cmux: Non-repo work, and anything a single terminal instance can do. Still in the rotation and deliberately scoped rather than replaced, which is why it is NOT in the skipped column below. Standing gripe: it packages its own Claude Code binary instead of working with the first-party one.
Cloudflare Pages and wrangler: Deploy target for static sites. Already hosting the annual review site and the course platform.

@@ added @@Just adopted

Conductor: Sept 2026 Chosen over cmux for in-repo work. Running several agent sessions at once was the bottleneck, and branch plus workspace integration solves more than collisions: auto mode can run unsupervised because nothing reaches the real branch until review passes, so a hallucination disaster is fully recoverable. Unproven: whether the issue-per-workspace discipline holds up past a dozen parallel workspaces. Listed in both columns on purpose, it is in daily use and still new.
/tailor-cv, self-built: Sept 5, 2026 Built as an agent skill rather than a script, on the finding that the tailoring judgment does not survive being frozen into code. Regenerates from the master document on every run, with a mechanical validator and a one-page render gate behind it.

@@ removed @@Evaluated and skipped

These share a shape: each tool demoed well and failed on the specific work. A tool that is right most of the time is not the same as a tool that is ready, and where it goes wrong matters more than how often. A voice model that is right 98 percent of the time fails hardest exactly where the technical terms are.

Cursor: Rejected in the summer and fall of 2025, while first investigating AI tools, and while the consensus ran the other way Too thin. The alternative shipped a programmable extensibility surface: custom slash commands, per-repo CLAUDE.md instruction files, and hooks. Cursor read as a chat window docked in an IDE. Useful, not a change in kind. The bet was on which tool could be programmed to hold a project's rules, not which had the nicer chat. My read as of Sept 2026: it played out and I would make the same call again.
AI animation tools, the landscape rather than a shortlist: Spring 2026, alongside the Warmongers animation work Reviewed the landscape and found nothing viable. Some looked able to produce spritesheets given existing art to learn from, and maybe simple animations. The game needs unique animations for feel. If every character has the same walk, or the same attack regardless of weapon, it feels flat. I assessed the category, not a shortlist.
Animation libraries such as Mixamo: Same evaluation, spring 2026 Rejected on the identical criterion, and this is the row that proves the criterion is real. My own read is that libraries could arguably do better than the AI tools at the time, which made the AI-versus-not comparison a bit moot. I turned them down anyway, because a library hands the same motion to many different entities and lands in exactly the same sameness problem. Landed on Spine 2D and hand animation.
ElevenLabs: Evaluated 2024, re-evaluated 2025, rejected both times Impressive in general and unusable in the specific. One-off mispronunciations and odd inflection are obvious enough in technical copy to break it, and it could not say "Xcode" correctly through repeated correction and fiddling. A voice that is right 98 percent of the time fails hardest exactly where the technical terms are. Re-checked a year later rather than rejected once and forgotten, which is the audit discipline this page is claiming.
Unity's native 2D animation tooling: Dropped Jun 12, 2026, one day after the second unit rig was finalized The rigs worked. What did not survive was the projection to a full roster: animating at that scale in the native tooling was not viable for one person. Moved to Spine 2D.

Where AI assistance stops

I reviewed the AI animation tool landscape for the game I am building and did not find anything viable. A few looked able to generate spritesheets from art you give them to learn from, and probably some simple animations. But that game needs unique animations to feel like anything. If every character on screen has the same walk, or the same attack regardless of what they are holding, it feels flat.

That is where the tools were when I looked, not where they will stay. The space moves fast and my radar is up, so I expect to run this evaluation again.

That is exactly what AI in creative work can squash. No one cares if AI wrote the audio manager. Everyone cares if the game feels bland and same-y.

This site is the same argument turned on itself. You do not care that it was stood up with Claude Code, and the footer on every page says so. What would feel off is if I had stopped there.

I pushed past the first good idea, guarded the design against Claude-ness, the house look an AI reaches for when nobody pushes back, and took a polish cloth to every section over several passes. That is the part that makes it mine.

So the line I draw is not about the category, it is about the output. Where something only has to be correct, help is close to free. Where it has to be distinctive to work at all, the same help costs me the thing I was making.

To be fair to the AI tools, they were not even the strongest option. Animation libraries like Mixamo could arguably do better than the AI could at the time, which made the whole comparison a bit moot. I turned those down too. A library hands the same motion to a hundred different entities and you end up in exactly the same place.

And I hold myself to this before I hold it against anyone's tool. Months earlier I turned down sharing one skeleton across every unit, which is standard practice, entirely workable, and has nothing to do with AI. It would have made everything move the same way. Same objection, three times, and only one of the three was about AI.

One honest caveat, because this page is not worth much if I only put the flattering half on it. The animations still are not finished. The choice I am describing is the slow one and I have not paid for it yet. Maybe there is a point about AI I am still learning here. A game with unique animations that never ships is worth less than a game with same-y animations that does, and I have picked a side without yet proving it was the right one. The open question I actually enjoy is which lands first: me shipping hand-made animations, or AI catching up to this use case before I get there. I do not know, and I want to find out.