I have found that with a good plan we are able to make big refactors quite a bit faster. The approach is that our /create-plan command starts high level, and only when we agree on that, fills in the details. It will also determine in what pull requests it plans to deliver it. The size estimation of the prs is never correct, but it gives a good enough phase split for the next step. Which is letting it rip with a “Ralph loop” (just a bash script while with claude -p —yolo). This with instructions to use jj (or git) and some other must read skills. This lets us review the end result, and correct with a review. That then gets incorporated whilst having claude rework the actual small prs that we can easily review and touch up. I must say jj helps massively in staying sane and rebasing a lot. Claude fixes the conflicts fine. We have been able to push ~5K of changes in a couple days, whilst reviewing all code, and making sure it’s on par with our quality requirements. And not writing a line of code ourselves. I would have never attempted these large scale refactors, and we would have been stuck with the tech debt forever in the past.

Thanks for creating Ghostty! Is there a chance to have shorter release cycles? I switched to nightly because of the mem bug and search, but ideally would like to be on a more stable channel.

Nice, I had the same idea for a enforced TDD state machine! I wouldn’t tie it to all the other stuff though, but I might try it out.

The TDD guard is the most isolated part of the whole thing, you could just take the files involved and ignore the rest. Maybe 6-7 files all referenced from the .claude/settings.json hook config.

Would be glad to see how you go!

For upgrading frameworks and such there are usually not that many architectural decisions to be made, where you care about how exactly something is implemented. Here the OP could probably verify the build works, with all the expected artifacts quite easily.

Slow_er_. For all programs talked about in this thread it is fast enough. Especially if you don’t need to host it at Microsoft/Google scale.

docs.sprites.dev requires authentication? And what about adding /llm.txt? I want Claude Code Web to install the cli and deploy what it is working on in a sprite :)

Not if you want to run multiple agents in parallel…

Codex is even better in my experience at reviewing. You can find the prompt it uses in the repo

How do you deal with one of transactions? How do you assign them to the right account?

For checking accounts, I have a list of rules that each transaction passes through. If a rule matches it generates the double-entry transaction going from the checking account to the account listed in the rule (or vice versa if the amount is positive). Earlier rules take precedence over later rules. If no rule matches it errors and prints out the transaction so I can add a new rule.

The main account I use for day to day spending is Monzo, they correctly categorise 99% of my transactions for me (and this is included in the csv export) which makes this way easier.

Yet, you add another attack vector, something that is very willing to do stuff, as long as you prompt it right…

As Simon Wilison clearly laid out, 99% secure isn’t secure and you think you can fix it by adding mor/better prompts?

Which methods do you have planned outside of “better prompting/fine tuning”?