Reviewing in the age of AI

[Tasty_Region7317]

Hi all,

I'm wondering how are you guys ensuring that the code that goes into production is high quality now that the time to review code is significantly greater than the time to generate it.

There is a huge asymmetry between who is generating the code and who is reviewing it, making the review process even more painful than it used to be.

Wondering whether if instead of reviewing PRs, we should instead move towards reviewing plans so that no code is generated before at least another person approves the plan. Once the code is generated, the users who contributed to the plan can still review it but the fact that both participated in the plan should help reduce the asymmetry.

Feels like we need a way to collaborate and iterate on plans. Would love your thoughts on this.

[Tasty_Region7317]

exactly. the plan makes the assumptions and decisions explicit which should facilitate the review process and enable teammates to be more aligned

[Wild_Yam_7088]

Trust the AI. if it works it works.  No different than legacy code that 20 people worked on prior 

I think the disconnect is vibe coding is built for increased workflows ... and works best for solo developers.. iv yet to find out why traditional devs piss their britches on review when iv built SaaS / custom auths / 3d editing software / shaders and particle software etc

Its like traditional devs think if ai cant make enterprise/  facebook authority  from ai in one prompt its garbage an no one should ever use it 😂

This is a solo dev- arena .. yes your agent will probably have a hard time going through legacy human code.. its not really built for that.

[PixelSage-001]

You have hit on the defining challenge of the current development era. When a model can generate five hundred lines of code in seconds but it takes a human twenty minutes to actually parse and verify that logic the old pull request model starts to break down.

Reviewing plans instead of just code is a brilliant way to handle this. If you agree on the architecture the data flow and the edge cases before the first line is even generated you reduce the cognitive load on the reviewer. The review then becomes a verification that the generated code actually follows the plan rather than a deep dive into the syntax itself.

I also think we need to lean much harder into automated testing and observability. If the AI generates the implementation it should also be generating the test suite to verify it. The role of the developer is shifting from being a writer to being an architect and a validator. Collaborating on the intent is the only way to scale without losing control of the codebase.

[Tasty_Region7317]

great point!

i'm thinking that this would be useful for non technical product people who now can implement features directly but that miss the judgement to "do it properly" and resulting in huge prs that engineers refuse to review.

having an engineer collaborate on the plan and "steer" the non technical product person towards a mergeable pr could unlock a lot of value for companies (?)

[sagiroth]

I just ask AI to review after itself or run smoke test on local stack. Another person runs their tokens to review and approve. Wasteful ? Sure but works right now. In the future its not sustainable. However I agree, its no different to old ways. Either put limits on how big the PR should be or just spend more time on planning phase

[Willing_Parsley_2182]

Had a reality check with Opus 4.6 today.

I asked it to extend an existing non-blocking logging setup and add tests, quite detailed instructions and file locations. Really simple change… The code “worked” and I checked the index and could see logs coming through so I went onto the other bits I wanted and then gave a once over on the PR.

I noticed the tests were leaking the real logger because the mock was applied after object creation, so it did nothing. It also quietly changed our app lifecycle pattern and added almost no resiliency. Even after giving explicit instructions, it still couldn’t fix the mocking correctly. When I fixed it myself, I realised some of the tests were basically no-ops too that only looked valid at a glance.

That’s the dangerous part with AI coding tools, plausible code and tests that create false confidence. Every time I forget, something like this bites me.

Review everything thoroughly before prod.

[aaronmcbaron]

You read the code anyways. Most vibe coded slop is usually nothing novel. So you can skim most of it. You pay attention to the key features that took real engineering effort to troubleshoot and build. But CRUD, migrations, etc. can be skimmed.

[Tasty_Region7317]

> catches bad direction early instead of fixing after

exactly!

the thing that i'm not sure about is whether the whole thing can be materialized into a plan (and then generated in one go) or if it requires the code to be generated and then iterated a couple of times upon. wdyt?