3 ms·

> It seems that everyone loves agentic Claude code things these days but I don’t understand how you can review what it did and remain as much in the flow as you

> It seems that everyone loves agentic Claude code things these days but I don’t understand how you can review what it did and remain as much in the flow as you do with cursor. The way I review it is to let it finish a PR sized slice and then I review the whole diff in a separate terminal as if it’s a PR from someone else. Then I very impolitely list the shit that needs fixing, let the LLM grind out a new batch and repeat the process. When the code is good enough I throw it into a commit and push a PR out for other humans to review. Clicking around in a UI would just waste time and if the change is too large to review in a terminal window the change is too large for another human to review.

imtringued 28d ago
Considering the amount of rejects I do every single day I'm not sure I agree. Now that I cannot reject I am unable to do any agentic coding anymore.
- jurgenburgen 27d ago
  You’re reviewing at the wrong layer if you’re approving / rejecting each individual tool call that modifies source code. Look at the finished piece of work and then treat the agent as if it’s that colleague you really hate and nitpick the shit out of the change it wrote. Usually the agent writes some over-engineered garbage which you then “help it” whittle down to something you would be okay approving if another human wrote it.
kaashif 28d ago
There is a step missing. Impolitely list what's wrong and try to incorporate any persistent themes into a markdown file so that the agent stops making the same mistakes. Put any rules into linters and static analysis and sanitizers and ... I sometimes see people reviewing LLM code leaving the same review comments multiple times, or worse, after some time they just give up reviewing.
- pennomi 28d ago
  Yep, if you’re not building guardrails, using an LLM is effectively just gambling until you get a non-broken output.
- jurgenburgen 27d ago
  I 100% agree on the automated guardrails. The part where you add instructions into a document is a bit of hit and miss. If they’re general enough it works but at my employer they have gone all out and have LLMs writing instructions that are committed to repos. There’s also a bunch of tools enforcing security instructions that usually just make the model confused (it starts arguing against the instructions randomly in the middle of performing a task). The agents are “stuttering” on most tasks because of the bloated instructions.
  - kaashif 26d ago
    Yeah, workflows like ruff then ruff --fix are ideal, or just outright banning certain libraries, or having policies like dependency cool downs. It's funny because we're once again speed running what the best practices already are!
RetpolineDrama 28d ago
>The way I review it is to let it finish a PR sized slice and then I review the whole diff in a separate terminal as if it’s a PR from someone else. Insanely inefficient. It's 10x more productive to watch the thinking traces and edits in real time and steer the model appropriately. If your workflow is typical no wonder my team members who use claude code are so much less productive.
- hamdingers 28d ago
  Do you never have agents working on multiple tasks in parallel? You'll become much more productive when you figure out how to stop micromanaging.
  - robben1234 28d ago
    More productive in what way? Letting agents burn tokens to produce garbage output is not productive. And letting teammates read code that wasn't reviewed by a human submitting it also isn't productive. If I work with one agent / few subagents on one feature I can steer it as soon as I notice it drifting into the direction of waste. This way I only review the total diff 1.5-2 times. And I also don't waste my own mental energy on context switching between tasks agents are producing diffs for in parallel.
    - jurgenburgen 27d ago
      > And letting teammates read code that wasn't reviewed by a human submitting it also isn't productive. If that’s what you got from my comment then you need to review it again.
- stefan_ 28d ago
  I don't think this is something anyone who has ever read a "thinking trace" would unironically say. Not that you can even see them in Claude. When thinking first started and you would still see the whole "thinking process", I thought it was a ploy to 10x token use because it was just the most inane bullshit. "But wait, the user is asking me to" in loops.

imtringued 28d ago

Considering the amount of rejects I do every single day I'm not sure I agree. Now that I cannot reject I am unable to do any agentic coding anymore.

jurgenburgen 27d ago
You’re reviewing at the wrong layer if you’re approving / rejecting each individual tool call that modifies source code. Look at the finished piece of work and then treat the agent as if it’s that colleague you really hate and nitpick the shit out of the change it wrote. Usually the agent writes some over-engineered garbage which you then “help it” whittle down to something you would be okay approving if another human wrote it.

kaashif 28d ago

There is a step missing. Impolitely list what's wrong and try to incorporate any persistent themes into a markdown file so that the agent stops making the same mistakes. Put any rules into linters and static analysis and sanitizers and ... I sometimes see people reviewing LLM code leaving the same review comments multiple times, or worse, after some time they just give up reviewing.

pennomi 28d ago
Yep, if you’re not building guardrails, using an LLM is effectively just gambling until you get a non-broken output.
jurgenburgen 27d ago
I 100% agree on the automated guardrails. The part where you add instructions into a document is a bit of hit and miss. If they’re general enough it works but at my employer they have gone all out and have LLMs writing instructions that are committed to repos. There’s also a bunch of tools enforcing security instructions that usually just make the model confused (it starts arguing against the instructions randomly in the middle of performing a task). The agents are “stuttering” on most tasks because of the bloated instructions.
- kaashif 26d ago
  Yeah, workflows like ruff then ruff --fix are ideal, or just outright banning certain libraries, or having policies like dependency cool downs. It's funny because we're once again speed running what the best practices already are!

RetpolineDrama 28d ago

>The way I review it is to let it finish a PR sized slice and then I review the whole diff in a separate terminal as if it’s a PR from someone else. Insanely inefficient. It's 10x more productive to watch the thinking traces and edits in real time and steer the model appropriately. If your workflow is typical no wonder my team members who use claude code are so much less productive.

hamdingers 28d ago
Do you never have agents working on multiple tasks in parallel? You'll become much more productive when you figure out how to stop micromanaging.
- robben1234 28d ago
  More productive in what way? Letting agents burn tokens to produce garbage output is not productive. And letting teammates read code that wasn't reviewed by a human submitting it also isn't productive. If I work with one agent / few subagents on one feature I can steer it as soon as I notice it drifting into the direction of waste. This way I only review the total diff 1.5-2 times. And I also don't waste my own mental energy on context switching between tasks agents are producing diffs for in parallel.
  - jurgenburgen 27d ago
    > And letting teammates read code that wasn't reviewed by a human submitting it also isn't productive. If that’s what you got from my comment then you need to review it again.
stefan_ 28d ago
I don't think this is something anyone who has ever read a "thinking trace" would unironically say. Not that you can even see them in Claude. When thinking first started and you would still see the whole "thinking process", I thought it was a ploy to 10x token use because it was just the most inane bullshit. "But wait, the user is asking me to" in loops.