[sothatsit]

I can tell you how I hit it: Opus and long workflows.

I have two big workflows: plan and implement. Plan follows a detailed workflow to research an idea and produce a planning document for how to implement it. This routinely takes $10-30 in API credits to run in the background. I will then review this 200-600 line document and fix up any mistakes or remove unnecessary details.

Then implement is usually cheaper, and it will take that big planning document, make all the changes, and then make a PR in GitHub for me to review. This usually costs $5-15 in API credits.

All it takes is for me to do 3-4 of these in one 5-hour block and I will hit the rate-limit of the $100 Max plan. Setting this up made me realise just how much scaffolding you can give to Opus and it handles it like a champ. It is an unbelievably reliable model at following detailed instructions.

It is rare that I would hit the rate-limits if I am just using Claude Code interactively, unless I am using it constantly for hours at a time, which is rare. Seems like vibe coders are the main people who would hit them regularly.

[vineyardmike]

This is very interesting as a workflow. How “big” are the asks you’re giving Claude? Can you give an example of the type of question you’d ask it to implement where it requires a discrete planning document that long?

Whenever I use it, I typically do much smaller asks, eg “add a button here”, “make that button trigger a refresh with a filter of such state…”

[sothatsit]

The best results I get are for things like writing a new database migration and plumbing the data through to an API endpoint. That touches a lot of the codebase, but is not particularly complicated, so this process works quite well for that. Especially because it is easy for me to review.

I have also used this for creating new UI components or admin pages. One thing I have noticed is that the planning step is pretty good at searching through existing UI components to follow their patterns to maintain consistency. If I just asked Claude to make the change straight away, it often won't follow the patterns of our codebase.

But for UI components, adding new pages, or things like that, it is usually more useful just as a starting point and I will often need to go in and tweak things from there. But often it is a pretty good starting point. And if it's not, I can just discard the changes anyway.

I find this is not worth it for very small tasks though, like adding a simple button or making a small behaviour change to a UI component. It will usually overcomplicate these small tasks and add in big testing rigs or performance optimisations, or other irrelevant concerns. It is like it doesn't want to produce a very short plan. So, for things like this I will use Claude interactively, or just make the change manually. Honestly, even if it did do a good job at these small tasks, it would still seem like overkill.

[shepherdjerred]

Here's an example of me doing a migration from Deno -> Bun, prompting with something like "migrate this, make a plan in BUN.md" and then "do step 1 and write your progress, do step 2, etc."

https://github.com/shepherdjerred/scout-for-lol/blob/6c6a3ca...

[Syzygies]

Yup. I'm on a side project trying to port the 1980's computer algebra system Macaulay I coauthored from 32-bit K&R C to 64-bit C23.

K&R C is underspecified. And anyone who whines about AI code quality? Hold my beer, look at our 1980's source.

I routinely have a task manager feed eight parallel Claude Code Opus 4 sessions their next source file to study for a specific purpose, to get through all 57 faster. That will hit my $200 Max limit, reliably.

Of course I should just wait a year, and AI will read the code base all at once. People _talk_ like it does now. It doesn't. Filtering information is THE critical issue for managing AI in 2025.

The most useful tool I've written to support this effort is a tmux interface, so AI and I can debug together two terminal sessions at once: The old 32-bit code running on a Linode instance, and the new 64-bit code running locally on macOS. I wasn't happy with how the tools for this worked, that I could find online. It blows my mind to watch Opus 4 debug.

[skinner927]

Is any of this public? It sounds very interesting.

[j-conn]

Mind sharing your detailed planning workflow and/or how you came up with it? Is it basically a detailed prompt asking it to produce a PRD?

I often find my plans for the code changing as I get into implementation. I wonder if giving the model explicit permission to change the plan would work or cause it to go off the rails for big chunks of work like this.

[sothatsit]

Here is the planning prompt, which I would usually place in .claude/commands/plan.md: https://gist.github.com/Sothatsit/c9fcbcb50445ebb6f367b0a6ca...

The implement prompt doesn't seem to matter as much: https://gist.github.com/Sothatsit/bdf2cf4ed7c319e2932a5d2d8d...

Creating these was basically just a workflow of writing out a workflow myself, getting Opus to refine it, then back to me, then back to Opus until it was something I was happy with. There is probably a lot more refining you could do with it, but it works pretty well as it is right now.

I then have wrapper scripts that invoke these using claude -p in a container, but those are pretty specific to my codebase.