alt Hacker News> The engineer opening a 25,000-line PR should have stopped the agent long before it got there.
So many A car is simply a faster horse arguments being made here.
The “You must review every line of code” camp are going to be in for a seriously bad time when Claude/Grok/etc starts writing machine code, and they absolutely will and you will look like a crazy person the same way as those who said we can’t trust compilers back in the 1970s.
Breaking up code into small reviewable pieces is obsolete advice from legacy software engineering. We will probably be reviewing prompts or functional simulations as a form of review. Which brings me to the point that a Senior engineer in 5 years will look absolutely nothing like a Senior engineer in 2019.
Replies
I do have a genuine question though: what value are you adding at that point?
If you don’t understand the system, don’t know what the code is doing and you’re mostly prompting an LLM to make the decisions and implementation for you, what exactly is your contribution?
The ability to operate the tool isn’t much of a moat if everyone else has access to the same tool.
I don’t review assembly produced by a compiler because the compiler isn’t deciding what my system should do. It’s translating a program whose semantics were already specified. More importantly, that translation is deterministic.
A compiler takes a human-specified program and translates it into another representation while preserving its semantics.
If in five years I can give an agent a complete specification and reliably verify the resulting machine code against it, then sure, reviewing code may become obsolete and I’d happily stop doing it.
Also, keeping changes small isn’t just about making individual lines readable. It limits blast radius, makes behaviour easier to reason about, isolates mistakes, makes changes easier to revert and so many other things. None of those properties suddenly become obsolete because code generation got faster.
> The “You must review every line of code” camp are going to be in for a seriously bad time when Claude/Grok/etc starts writing machine code, and they absolutely will and you will look like a crazy person the same way as those who said we can’t trust compilers back in the 1970s.
I'm working on this right now, will have a release probably in a week or two. Not machine code but it's essentially a custom assembler/compiler pipeline (close enough) that an LLM can operate via the CLI (you can do it too, it's just way slower) and it emits native asm optimized chunks that can then be inserted back into cpp (working on a rust et al impl). The results are _obscenely_ good. It's outright outperforming gcc vis-a-vis by a MONSTROUS margin, and it's not even close. As in, gcc can do abour 3-4 cyc/byte (arbitrary workloads on a wide variety of tests) and my tool does it in 0.5 cyc/byte if not better. It outright emits kernels that run at a flat 4 IPC for more or less _anything_. You can then have an LLM convert it back into high level C++ intrinsics (not always, gcc doesn't always expose all the levers needed to do so) if you wish. The one downside is that you need to provide fairly accurate cpu arch maps (ie agner fog instruction port/latency tables) for the tool to work right, which is what i'm focusing on right now.