because reviewers felt obligated to verify the AI’s work on top of their own
Because you arr telling the dev to sign off on code made by something that is at best, a code-writer that doesn't just do what you tell it to do.
this post was submitted on 10 Mar 2026
50 points (98.1% liked)
Programming
26022 readers
280 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
When the review bottleneck is solved by being bypassed the client/end-user becomes the "bottleneck". Why can’t he just approve whatever I’m throwing at him and call it a day? \s
Might as well just give me their money and call it a day. No real product required.
I can then "pay" that money to 10 other companies for nothing and then the govt. can pay my client for contracts of nothing.
And everyone can be a billionaire.
If review is the "bottleneck", I'd say the code needs to be optimized for review time. Ship small increments of easy to understand code, touching as small surface as possible, and make sure it passes the review with no need for corrections and re-review.
Some people are more receptive to these kinds of things than others. Not only in terms of open mind but also how they are able to apply it (or capable of applying it?).
I wish agreeing on intentions and improvements in terms of scoping and description would be met. Same with unnecessary, obvious issues showing up costing review time and iterations. I just don't get how these are issues - but they are - for or with some people.
Ideally you can do that, but even the most well designed software ends up needing a larger refactor/reorganization that will touch a large portion of the code base.
My boss likes to say "you aren't qualified to design something until you have built it once" which I do feel rings true. This inevitably leads to at least one major redesign for a significant codebase.
Writing lines of code was the bottleneck before. Vetting them is the bottleneck now, if LLMs are involved.
writing lines has never been the bottleneck, that's only something a junior would say. The bottleneck is always requirements: changing, understanding them, making sure you don't miss test cases before writing any code.
test dogmatist detected
No, the bottleneck is not always requirements. Understanding requirements is a prerequisite to writing correct code, but it takes a fraction of the time.
Obviously different domains have different complexities of requirements and code which changes the ratio
Yeah, e.g. writing UI code takes a lot of time, while it tends to be pretty simple overall and that's why we have so many UI toolkits, to reduce the amount of writing required for UI.
Writing the requirements is what takes time.
Instead of spending 4 weeks writing requirements and 1 week implementing them, have you tried spending a day guessing at requirements, half a week writing a prototype, and then asking the customer if it works for them?
Have you ever worked on a tools team where your customers are internal and your developers are also customers and so know the requirements inside-out?
Hehe! I have.
And what took the longest was for me to get used to the dual versioning of QML modules and fixing the UI code that was partially using stuff from both versions.
Business logic was pretty small for me but that was because other engineers had already written most of it in Maths.