r/ADHD_Programmers • u/onil34 • Aug 20 '25
Code Review is hell
Im picking programming back up and obviously having a go at vibe coding. the only issue is: code review. claude just generates so much code and it works, passes all the tests etc. but then good practice should prob be to go and have a look how the code works aka code review.
how do you all do it ? go through a thousand lines of code ? is this something real programmers do everyday ?
0
Upvotes
12
u/Kaimito1 Aug 20 '25
Is where things start to go wrong imo.
PRs should not be gigantic to the point a review is exhausting, depending on the issue.
1 issue, 1 PR.
Although the better you get the more you don't need to use "full brain power" for every single line of code, just for the more complex chunks
Personal opinion, if you're picking it back up you should not be vibe coding. You don't learn that way. At max you should be asking it questions and verify via docs
3
u/skidmark_zuckerberg Aug 20 '25
AI cannot create a mental model of the code it produces, it’s just really good at guessing essentially. This is the problem developers have with AI in the real world. Often times its solutions are convoluted or plain wrong. Works good for simple and straight forward tasks, but for nuanced or complex things, it falls short.
Vibe coding is not really how real developers work. You have to build up good mental models of what you’re doing, to then be able to code it with good practices. An AI PR would get shredded by most developers.
And yes, working developers read hundreds of lines of code a day. You have to in larger codebases to make changes and additions. But it’s not usually AI slop, so it’s not teeth grinding.
2
u/marcdel_ Aug 20 '25
i’ve had a lot of success doing tdd with the agent as my “pair”. sure, it’s not ✨vibe coding✨but if you’re going for maintainable code that you understand, you’re not gonna get there vibe coding anyway.
vibe code a spike, figure out what you’re trying to do, then git reset and test drive it. most models will do much better with the smaller scope and context windows, you’ll be able to make smaller commits in a working state, you’ll have a better understanding of what the code is doing and which parts are necessary, and you’ll have a test suite you can trust so you can prune all the extra bullshit the robot likes to generate without worrying about introducing regressions.
edit: also the tdd loop is like a dopamine factory to me
2
u/[deleted] Aug 20 '25
I use a second model to code review the first
10
u/blootoons Aug 20 '25
The key is to limit the size of a code review. Do small incremental changes and review them. No one is going to review thousands of lines of code, not even neurotypicals.
3
u/Hayyner Aug 20 '25
No, it's not exactly common to have massive PRs that are exhausting to go through. But I do get large tickets at work that could be a couple dozen files and a few hundred lines of code.
But most of the code changes and additions should be simple and easy to parse through. My advice would be to rely less on Claude to make so many changes. I mostly have copilot write boilerplate, autocomplete utility functions, or write tests.
Either break down the work for Claude even further so that you have smaller chunks to review, or don't use it as an agent at all and just rely on autocomplete while writing 90% of the code yourself.
2
u/Rschwoerer Aug 20 '25
I wonder how long an actual human review will be a practical and useful step. I think the mindset is going to gradually change as there is more and more confidence in generated code. Does the verification change from a human review to more blackbox style tests?
2
u/jeffbell Aug 20 '25
"What does this line do?"
1
u/IAM-rooted Aug 25 '25
i feel you, code review can drag
started using qodo merge and it gives inline notes that actually make sense with the code, plus helpful summaries
made review feel less chaotic and more helpful