I had read about them before but for whatever reason it never clicked.
Turns out I already work like this, but I use commits as "PRs in the stack" and I constantly try to keep them up to date and ordered by rebasing, which is a pain.
Given my new insight with the way you displayed it, I had a chat with chatGPT and feel good about giving it a try:
1. 2-3 branches based on a main feature branch
2. can rebase base branch with same frequency, just don't overdo it, conflicts should be base-isolated.
3. You're doing it wrong if conflicts cascade deeply and often
4. Yes merge order matters, but tools can help and generally the isolation is the important piecehttps://www.atlassian.com/git/tutorials/comparing-workflows/...
imho the plans of Claude Code are not detailed enough to pull this off; they’re trying to do it to preserve context, but the level of detail in the plans is not nearly enough for it to be reliable.
I can imagine some ideas (ask it for more detail, ask it to make a smaller plan and add detail to that) but I’m curious if you have any experience improving those plans.
Effectively it tries to resolve all ambiguities by making all decisions explicit — if the source cannot be resolved to documentation or anything, it’s asked to the user.
It also tries to capture all “invisible knowledge” by documenting everything, so that all these decisions and business context are captured in the codebase again.
Which - in theory - should make long term coding using LLMs more sane.
The downside is that it takes 30min - 60min to write a plan, but it’s much less likely to make silly choices.
Hard to keep up with all the changes and it would be nice to see a high level view of what people are using and how that might be shifting over time.
https://lmarena.ai/leaderboard/code
Also, I'm not sure if it's exactly the case but I think you can look at throughput of the models on openrouter and get an idea of how fast/expensive they are.
Can you help me envision what you're saying? It's async - you will have to wait whether its good or not. And in theory the better it is the more time you'd have to comment here, right?
Some would argue there’s no point reviewing the code, just test the implementation and if it works, it works.
I still am kind of nervous doing this in critical projects.
Anyone just YOLO code for projects that’s not meant to be one time, but fully intend to have to be supported for a long time? What are learnings after 3-6 months of supporting in production?
I do use them, though, it helps me, search, understand, narrow down and ideate, it's still a better Google, and the experience is getting better every quarter, but people letting tens or hundreds of agents just rip... I can't imagine doing it.
For personal throwaway projects that you do because you want to reach the end output (as opposed to learning or caring), sure, do it, you verify it works roughly, and be done with it.
My "first pass" of review is usually me reading the PR stack in graphite. I might iterate on the stack a few times with CC before publishing it for review. I have agents generate much of my code, but this workflow has allowed me to retain ownership/understanding of the systems I'm shipping.
To me it feels like building your project on sand. Not a good idea unless it's a sandcastle
That’s a pretty basic functionality in Claude code
I've been using that and it's excellent
As time went on I felt like the organization was kind of an illusion. It demanded something from me and steered Claude, but ultimately Claude is doing whatever it's going to do.
I went black to just raw-dogging it with lots of use of planning mode.
GSD might be better right now, but will it continue to be better in the future, and are you willing to build your workflows around that bet?
I believe bees call it "bzz bzzt *clockwise dance* *wiggle*"
Even 90 word tweets are now too long for these people to write without using AI, apparently.
Mine also rotate between Claude or Z.ai accounts as they ran out of credits
Honestly if people in AI coding write less hype-driven content and just write what they mean I would really appreciate it.
The rate at which a person running these tools can review and comprehend the output properly is basically reached with just a single thread with a human in the loop.
Which implies that this is not intended to be used in a setting where people will be reading the code.
Does that... Actually work for anyone? My experience so far with AI tools would have me believe that it's a terrible idea.
I have also started it in writing tests.
I will write the first test the “good path” it can copy this and tweak the inputs to trigger all the branches far faster than I can.
I don't mean this in a disparaging way. But we're at a car-meets-horse-and-buggy moment and it's happening really quickly. We all need to at least try driving a car and maybe park the horse in the stable for a few hours.
That's what you're missing -- the key point is, you don't review and comprehend the output! Instead, you run the program and then issue prompts like this (example from simonw): "fix in and get it to compile" [0]. And I'm not ragging on this at all, this is the future of software development.
[0] https://gisthost.github.io/?9696da6882cb6596be6a9d5196e8a7a5...
I do a fair amount of agentic coding, but always periodically review the code even if it's just through the internal diff tool in my IDE.
Approximately 4 months ago Sonnet 4.5 wrote this buried deep in the code while setting up a state machine for a 2d sprite in a relatively simple game:
// Pick exit direction (prefer current direction)
const exitLeft = this.data.direction === Direction.LEFT || Math.random() < 0.5;
1. Subagents doing work have a fresh context (ie. focused and not working on the top of a larger monolithic context) 2. Subagents enjoying a more compact context leads to better reasoning, more effective problem solving, less tokens burned.
Way too much code for such a small patch
In his second post he included a link to GitHub: https://github.com/mikekelly/claude-sneakpeek