When agents write the code, HN says review the boundaries, not every line

Adrian Quiroga's Here Be Monsters asks what an engineer still needs to know when agents write the code. The post's answer is breadth: a map of the system and enough depth to know where to dive. The Hacker News thread reached 87 comments, and we sorted all 22 top-level ones. Our view: the most useful answers in it were not about knowledge at all. They named where to put the checks, and that is a decision you can write down today.

What the post argues

The post opens with a CI failure. SonarQube flagged App.tsx for cyclomatic complexity: about 30 lines, 15 of them entire components that Codex had written "each on a single line". Quiroga read the logic, found it correct, and "told Codex to make SonarQube happy". It split the file into ten, CI passed, and the change shipped. "This was, after all, code I had never seen before."

From there the post argues that owning a system will depend less on having written it and more on "knowing just enough to know when something is wrong", and on diving deep when needed: fundamentals, breadth, and depth on demand.

How the thread split

We sorted each top-level comment by the position it takes. One reader's classification, so treat the edges as soft.

Five of 22 is not a majority. It is where nearly all the actionable advice sat, and the best of it came in replies.

The answers that name a check

Review the expensive boundaries. CGamesPlay described a rule worth copying: "I review all changes that touch persisted data formats, wire protocol, and/or public API surface". Those are the things "with bad consequences if they are wrong", and once they are fenced off, "I can really relax about the other parts of the code, because I know they will be cheap to fix if wrong."

Own the schema. smallerfish wrote that LLMs "make awful normalization decisions" and that they "pause feature development every few days for code & schema review". bob1029 went further: "Just do the schema by hand." Not knowing what the schema should be is, in their words, "the dead canary in the vibe coding coal mine".

Write the expectations down. lordnacho does "a lot of black box testing: take the solution, see if it does what I expected, then bake in those expectations in a document." The agent writes unit tests unprompted; the expectations come from the person.

Prove it. tkz1312 argued for proof systems, which let you "review and iterate on a contained and simple system model" and use the guarantees across the code. It is the strongest version of the same move: shrink what a person must check to something small enough to check.

The objections worth keeping

The example proves less than it claims. guitarlimeo pointed out that "diving in" ended with a prompt: "make SonarQube happy". That is the move we tested the day before, when a lint config went green on five live bugs after the cheapest edits that satisfied it. A green tool after "make it happy" says the tool is satisfied, and that is all.

Discomfort is not the failure. trjordan said the failure that matters is "Angry users. Security incidents. Downtime. Broken workflows", and offered anecdata of companies where developers are stressed, shipping more, "and incidents are down". If that holds, a developer's unease is a poor gauge, and the gauge has to be the product.

Skills decay. ArcHound noted the post mentions maintaining expertise once: "How do you maintain your expertise when you stop doing technical work? It'll hold for a while on its own, but then it falls."

One story from outside software makes the stakes concrete. aethelgard-syst described an assistant that said it had made doctor's appointments and calendar entries. The first sign it had not was a phone call at 07:30 from the doctor.

The takeaway

The thread asked what you need to know. Its best answers said where you need to look. That is easier to act on, because a boundary can be written into a repository and enforced: changes to migrations, protocol definitions, public types and money paths get a human review and a test written from the requirement, every time. Everything else can move at agent speed.

B4uler5 added a warning that fits the boundary idea: agents "defensively code for cases that have no chance of happening", when "a panic/crash if they do happen might be the best option". A crash inside a reviewed boundary gets noticed. A quiet fallback outside one does not.