Comment by hakanderyal a day ago
Try plan mode if you haven't already. Stay in plan mode until it is to your satisfaction. With Opus 4.5, when you approve the plan it'll implement the exact spec without getting off track 95% of the time.
i think the review cycles weve been doing for the past decade or two are going to change to match the output of the LLMs and how the LLMs prefer to make whole big changes.
i immediately see that the most important thing to have understand a change is future LLMs more than people. we still need to understand whats going on, but if my LLM and my coworkers LLM are better aligned, chances are my coworker will have a better time working with the code that i publish than if i got them to understand it well but without their LLM understanding it.
with humans as the architects of LLM systems that build and maintain a code based system, i think the constraints are different, and that we dont ahve a great idea on what the actual requirements are yet.
it certainly mismatches with how we've been doing things in publishing small change requests that only do a part of a whole
I think any workflow that doesn't cater to human constraints is suspect, until genAI tooling is a lot more mature.
Or to put it another way -- understandable piecemeal commits are a best practice for a fundamental human reason; moving away from them is risking lip-service reviews and throwing AI code right into production.
Which I imagine we'll get to (after there are much more robust auto-test/scan wrap-arounds), but that day isn't today.
It's fine, but it's still "make big giant plan then yeet the impl" at the end. It's still not appropriate for the kind of incremental, chunked, piecework that's needed in a shop that has a decent review cycle.
It's irresponsible to your teammates to dump very large giant finished pieces of work on them for review. I try to impress that on my coworkers, and I don't appreciate getting code reviews like that for submission, and feel bad if I did the same.
Even worse if the code review contains blocks of code which the author doesn't even fully understand themselves because it came as one big block from and LLM.
I'll give you an example -- I have a longer term bigger task at work for a new service. I had discussions and initial designs I fed into Claude. "We" came to a concensus and ... it just built it. In one go mainly. It looks fine. That was Friday.
But now I have to go through that and say -- let's now turn this into something reviewable for my teammates. Which means basically learning everything this thing did, and trying to parcel it up into individual commits.
Which is something that the tool should have done for me, and involved me in.
Yes, you can prompt it to do that kind of thing. Plan is part of that, yes. But planning, implement, review in small chunks should be the default way of working, not something I have to force externally on it.
What I'd say is this: these tools right now are are programmer tools, but they're not engineer tools