Eight years ago I wrote that the compiler is the first reviewer. If the build passes, a whole class of mistakes is already gone. The compiler catches what a tired reviewer would miss.
It was right, for a team of humans whose errors the compiler could screen.
The argument came back this year with one substitution. A post from the Go team on AI-assisted engineering makes the same case about agents. “AI is your newest teammate.” The new hire whose pull request the compiler screened is now a model, and the compiler is the reason the team can trust it.
The post is specific about what the compiler catches:
If an AI agent attempts to use a non-existent method, pass an incorrect type, or leave a variable uninitialized, the code simply will not compile.
Two of those three are true. The third is not.
var m map[string]int
m["k"] = 1
That compiles. It vets. It panics at runtime, on the write to a nil map. Go checks for unused variables, declared and not used. It does not check for uninitialized ones. The article conflated the two, in its own favour.
The compiler screens type errors. That was its job in 2018, and it still is. An agent makes type errors too. A hallucinated method name is a type error, and the compiler catches it. But type errors were never the hard part. The hard part is the class the compiler never screened: code that is well-typed and wrong. The nil map. State that is locally plausible and globally broken. A human reviewer read that part. That was what review was for.
The compiler was never the reviewer. It made a human’s review affordable by screening a class of error a competent teammate would also have caught. It never touched why the code exists, which was always the hard part to read.
The post quotes a line Gophers are proud of: you can never tell who on the team wrote a particular piece of code. In 2018 that was fine. The person was on the other end, reading what the compiler could not. The compiler screens the same errors it always screened. The second reviewer is optional now.