Maybe We Shouldn't Be Reviewing All This Code
2 points by natfu
2 points by natfu
How could the author of this corpospam article be okay with the image that depicts an upside-down book peddling "ai with human face" dystopia, a mug that says "NO", a boy playing with slopbricks that are impossible to connect, and a girl cutting her finger?
Bonus points for "It's not X, it's Y" as the first sentence.
She must have clearly had intent she's boasting for not to review neither the image, nor article.
What I thought was interesting, is her challenging of what we've been using PRs for. It it's indeed knowledge transfer, senior oversight or architecture decision review; then maybe it isn't where that should happen anymore. I don't think that means code ownership disappears.
even if we do all of the things the author suggests, i still see 0 incentive to do away with code review. theses things complement each other, and nowhere in this article was a case made that teams will be better off by abandoning code review and attempts to deeper understand all the changes being made to codebases under their purview.
as with so many questions and discussions about “ai-assisted” programming, the exact same best practices still apply that always have. we should be using LLMs and such to make it easier to follow those best practices, not to try and rip out fundaments because they are a “blocker” or “bottleneck”.
are tools like code review, that help us understand our systems more fully, ever best framed as a blocker or bottleneck? why does trading some amount of “productivity” or “velocity” for increased quality have to be framed as a problem?
Right, what isn't mentioned either is how to build knowledge for teams with AI in the loop. I think we could collectively have a better time with if the AI was aimed at making decisions more legible to everyone and not just producing code. It could be starting from human written Architectural Decision Records and then raise a point in review when the design goes explicitly against it. Could be generating an interactive Q&A that links commits and ADRs together, etc. I'm not seeing too much along those lines. But the article is a good starting point at least.
Agreed. I almost stopped reading when I saw the slop image (and I hadn’t even noticed little Annie casually chopping her fingers off while mommy is lost in thought leadership). But there are some good points in the article. Code review is often overburdened with responsibilities that should be done much earlier in the process. I’m sure we’ve all experienced design-review-by-PR from both sides, and it’s never a good way of working.
i think one good approach to thinking about this is in terms of enablement: what is it exactly that LLMs have enabled us to do that now changes the calculus of software design and implementation?
some people seem to think massive PRs making complicated changes across many systems are a new ability we have gained with the advent of clankers, but it was always possible to write code like this. it just required substantially more effort.
what is enabled, then, is the ability to make these massive changes without the usual effort and understand required. seems fine for prototyping, throwaway code, or personal projects that don’t need group ownership, but seems anathema to a healthy organizational relationship with a codebase.
even if we do, as this article suggests, redouble our efforts to understand systems “to the left” of code review, i see no reason why we should trust that the mountains of newly generated code correspond to that enhanced understanding of the system.
And don’t even get me started on merge conflicts. I’ve lost too many hours of my life.
don’t even get ME started on handling incidents that are directly downstream from a massive, mostly unreviewed LLM PR: i’ve seen too many hours lost in the past 2 months.
My never-once-failed heuristic is that if the author has an AI generated image of themselves anywhere, there is absolutely nothing of value they could say.
I even do code review on my solo projects. It gives me a chance to step back and ask whether I'm about to ship something I endorse. Often I'll find some things that don't meet my quality threshold, which I fix up before merging.
It's still a little weird to me that Martin Fowler's blog is usually articles that weren't written by Martin Fowler. I guess it's more the Thoughtworks blog edited by Martin Fowler at this point.
But then https://www.rogerebert.com/ continues to publish new articles by other people 13 years after he died so maybe sometimes a person's name becomes a publishing brand in its own right.
Update: found this note on his about page (should have looked there before I posted this comment):
As the site got more popular, I felt I could use it to help other people get more visibility for their writing, so I've steadily increased publications from others here. I vet each article before accepting it - and often do a considerable amount of developmental editing too - so there isn't a high rate of publication. I do believe, however, that the quality of the articles matters much more than the quantity.
The authors’ point - that review is too late in the process for engineers to be talking to each other - is a good one, and not contingent on the use of ai.