Why do so many people think that code reviews are primarily about mistrust or spotting mistakes?
IMO they’re primarily about ensuring shared understanding and agreement, not just about how things are changing now, but how they’ll change in the future..
>Why do so many people think that code reviews are primarily about mistrust or spotting mistakes?
because people generally think things they are told, basic memetics.
There are a set of things code review is for, this set of things is for written information transfer and rather too large for speech, so when choosing to speak about what things code review is for people choose some, shared understanding is slightly more abstract than catching and reducing bugs so catching and reducing bugs gets repeated slightly more, and the next generation of people hearing what code review is for repeat it.
As a general rule I have seldom seen bugs get caught in review, I have caught a few bugs in review, but far fewer than the amount of code I have reviewed. I have very few times had bugs caught in review of my code, this is not because I don't make bugs, they just get caught out in testing.
Normally my experience is much of the communication I receive about code I've written is generally bike-shedding, probably 70-80%, above that it starts to become things we can absolutely agree is useful in some way (even if not at the bug catching stage), bug catching is maybe 0.01% of the comments.
2. make me understand what the agent team did, while it spinned for hours
I think no 1 will be solved by N-version coding, keeping a population of replicas which provide differential testing on fuzzed inputs or prod data. This also helps no 2 - where execution diverges it can be a bug or a missing spec. Either fix code or fix spec. The reason I think N-version approach will win is that it is easier to code again the same app than to imagine code execution and its edge cases. Let real execution flesh out the divergences. It is easier than formal verification but still complex because it requires a careful setup where randomness, APIs, databases and other external state can be controlled for comparison.
OP said they use this question "What’s the cost that made this a bad idea, and is that cost still there?" to triage. In our case it is getting cheaper to spend tokens, N-version stops being too expensive. Having a population of replicas instead of a singleton would be the safe approach. It can even be faster, you can build the replicas in parallel, while test creation would take extra time on top of implementation. It's basically unbounded testing from input side. Makes performance optimization of one replica safer too.
Having worked in SWE for two decades, I trust AI far more than humans. The top 10% of human programmers did great work when given the right environment, not under pressure by leadership to deliver too quickly, not forced to use or work with partner orgs that sucked, etc. But the majority of people I've worked with, while lovely people, produced very human code. This is why AI is able to find so many exploits.
Yes, people are struggling with status and purpose, but the reality is Opus 5.5 onwards has completely changed reality. We have to harness it.
N-version isn't a new idea. You quickly run into a problem with evaluation. Fuzzing is slow, non-deterministic, expensive. Building and verifying a test suite similarly so. Building a program that will evaluate whether an arbitrary program conforms to an arbitrary spec is an unsolved problem (consider how you would verify such a program in the first place).
People keep thinking of the coding step as a discrete, and thus also slow, expensive, non-deterministic step, but engineers did a lot to make it less so, whether it was techniques, tools, process, culture, whatever. Like, imagine an incredibly good agent working on a 2kloc PR for ~120 hours, periodically checking in with 4-5 other also incredibly good agents with near perfect knowledge of the system they're working on, constantly reevaluating the approach, periodically considering whether the existing codebase and architecture can facilitate the types of functionality you're adding, spending considerable effort to make it as easy as possible for other agents to add features, improving itself through these efforts, building ideas for new tools to help it, etc etc. It wasn't just code generation; so many useful things were happening in parallel.
You can think of it like dating in a huge city. In smaller cities incidental contact is frequent and encouraged. Dating is a bunch of meet cutes, dating in the workplace, ad hoc get togethers, etc. In huge cities incidental contact is overwhelming, oppressive, and discouraged, so if you want to meet people you have to expend considerable energy deliberately doing something you used to get relatively for free: talking to people you may want to socialize with/date/whatever. It's of course possible and people do it, but it's much harder, and we're only starting to become aware of the second order consequences of it (loneliness epidemic, growing political separation between men and women, falling fertility rates, etc). It's to the point where getting into a relationship as an adult is a part-time job, and fewer and fewer people can bring themselves to put forth the effort.
Swapping in LLMs for humans for the code generation process has the same dynamics. You can have more meetings about architecture, you can have it slop out more tools, you can have it analyze the last N PRs and have it slop out something that would've made those PRs smaller/simpler/whatever, you can have it rearchitect whatever you want (kinda) but you have to constantly push yourself to do it. You're no longer internally motivated to do it because you're no longer personally affected, fewer and fewer engineers will be able to put in the effort, and things will start to fall apart.
Maybe this won't be a problem. Maybe the code will be good enough and we'll find we don't need these higher level operations, i.e. we won't need engineers to spend weeks doing tedious tech debt sweeps every quarter in order to keep the lights on. But my guess is our ambitions will grow until we do.
Do you need to look into the code for that though? Can't you talk with your agent about the changes introduced and the direction the PR is taking your code?
P.S. Have a feeling this will get down-voted but posting since I am interested in counter-arguments for this approach.
Yes you do. Definitely not in the excruciating detail we used to. But an agent on itself typically catches only (relatively) superficial issues. It hasn't ever occurred to me to get a higher-level disagreement on the changes of the PR by an agent.
E.g. why re-implement the oauth workflow instead of using the established package of the ecosystem? Why monkeypatch an existing python method for all code instead of implementing and using where needed a context manager?
The agent can give you an assessment on such alternative approaches if you ask it, but I haven't seen it taking the initiative to radically steer a PR.
I don't think your observation is limited to programmer culture.
AFAICT, it applies to everything. Few people are exercising any thinking skills because they put in a half-formed broken thought in fractured english into the prompt, and then use the result.
Emails, general comms, problem-solving... everything is now at the point where the lazy fucks are no longer detectable in the workplace.
They also pose the question: 'Are we building the right thing?'. Which is something that is really hard to resolve when it is just you and your LLM echo chamber. You don't know what you don't know.
I probably disagree, and this sounds like coping rationalization.
Reviews ensure that the writer's hypothesis has an antithesis to create a better synthesis. It follows fairly naturally from the academic background of engineers'. Structural engineers don't have drawing reviews to ensure shared understanding and agreement; they really just want to avoid being liable for killing people. That's the structure that software engineering evolved from.
The average person in the developed world already spends the majority of their free time in front of a screen, and the share increases the younger they are.
An open process with a clear rationale is better than a secret process, e.g. company wide surveys that are later used to determine whether you keep your job…
Whether this actually leads to improved productivity and better products is TBD, of course.
That revolves around print on demand for books that are out of copyright or where the copyright has been abandoned.
>
Background
Valancourt Books is a print-on-demand independent publishing house specializing in rare and out-of-print books. Valancourt had not registered its books for copyright as the Library of Congress already had original-edition copies of the books Valancourt republishes and any new material in its publications was limited to notes and introductions.
If you want a physical copy of The Sorrows of Satan, you can buy it from them.
> The Copyright Office has stated that it would modify the language of its deposit demand letters and withdraw its demand for copies if the Copyright Office was notified of the copyright's abandonment.
> Several legislative changes have been proposed to address all elements of the case: changes to Section 407 to tie some legal benefit to the deposit, monetary compensation to copyright holders for depositing books, and regulation for a simple and costless method of copyright abandonment.
That doesn't change that if you were to publish a book today (or for that matter, have published a book in the past 100 years in the US), you are required to deposit a copy of the book with the Library of Congress.
IMO they’re primarily about ensuring shared understanding and agreement, not just about how things are changing now, but how they’ll change in the future..
reply