Remix.run Logo
▲ dirtbag__dad 2 days ago

I don’t believe that nobody is doing it well. May I ask who is doing it well? Either in house or with an AI reviewer vendor.

For me, what works is highly templated directory structure and rules that linters can quickly check and enforce. Every PR is a cookie cutter design filled in. There are only a handful of things you need and they’re all just CRUD at the end of the day. You can employ the same very few design patterns and primitives across a lot of your stack. Review is so fast, if you trust your CI to do its job and the developer to actually QA their own work.

What isn’t working is the sheer volume of PRs. Even with CODEOWNERS directing attention to only high impact changes, it is a constant distraction. I’m not sure how to handle SOC2 where we need a human reviewer on all code. Lastly, agents shit the bed when they touch spaghetti, esp when it’s sitting next to structured patterns. IME, the best way to get around this is to just rewrite features from scratch. But in this current world of instant completion and reward, it’s been challenging to convince people to commit to more ambitious lifts.

Finally, I want review more than ever. A team can’t keep up with the pace of change even if it was all perfect. I like the idea of more up front planning, but the code is ultimately what matters.

▲NewJazz 2 days ago | parent | next [-]

There are only a handful of things you need and they’re all just CRUD

Idk why everyone says this. Yeah crud is tedious and common. No it is not the majority of my time spent, implementing, fixing, or reviewing.

▲dirtbag__dad 2 days ago | parent [-]

what do you work on that isn’t CRUD?

▲NewJazz 2 days ago | parent [-]

Well I have signed an NDA so I can't be too specific... But generally business logic, heuristics, event correlation.

Essentially applying institutional knowledge and rules to stabdardized processes.

Either that or integration between different systems in nontypical ways.

▲eddythompson80 2 days ago | parent | prev [-]

I’m waiting to see someone who has any sort of reasonable way, but I have yet to see one. Code review was always a difficult part of the job. However, it was self regulating because the people who would do very large code dumps frequently were very very few high throughput individuals and they were either legitimately good and knew what they were doing, so you trusted them, or were quickly told to not do that. The process had natural breaks on it, and particularly large PR would be expected to take few days or week(s) to review.

This all has changed. I’ve only seen gaslighting (in the form of “of course we expect you to read the code LLMs is generating”), lying along the same lines, or the realistic people who acknowledge they don’t read any of it. The former camp is mostly traditional engineers, and the later is mostly new or traditional non-engineering roles like recent product management coding converts. I think it would help everyone if we just normalize the fact that no one if reading code much anymore. It’s just not feasible. Write a bunch of creative reviewing bots or SKILLs and just leave it at that. It’s not a great answer, but like I said I haven’t seen any alternatives.

> if you trust your CI to do its job and the developer to actually QA their own work.

I trust the CI, but the CI is doing what the CI is written to do. I don’t know how you can achieve the second part in a large team/corporate setting or an open source setting.

▲ivanjermakov 2 days ago | parent | next [-]

> of course we expect you to read the code LLMs is generating

Yes! I think a lot of struggle comes from not having the same reliance on LLMs across the team. If developer A is not opening IDE and not reading the code to do work and developer B does not use LLMs, types code letter by letter and reads every text they encounter - it will not go well for the team. I also think many devs rely on LLMs more than they're willing to admit to the management and the rest of the team.

▲nkohari 2 days ago | parent | prev [-]

With Theseus, we've been trying to approach the problem from a couple of standpoints:

1. Code review is now less about mechanical validation (which often happens in linting, AGENTS.md, etc.) and more about education and understanding what's changing 2. Engineers need a tool which allows them to focus their attention on parts of changes, without having to review everything all at once

Would love to hear what you think!

[0] https://theseus.dev

▲matltc 2 days ago | parent [-]

Chill