The submission reads like a confession many developers will recognize. In an Ask HN thread titled "How to deal with shipping AI-written code you don't understand?", the poster quotes a LinkedIn post by a Meta engineer: writing code now "feels like a black box," checking every line would take forever at the current pace, and "you can end up with systems you've built where you don't truly understand how all the code works." The engineer asks other developers whether they feel the same.
This post does three things: it summarizes how the early replies split, it sets out what published evidence says about verification, and it gives a playbook you can adopt this week. It is a how-to, not a verdict on whether AI-written code is good or bad.
TL;DR: the short answers
| Question | Short answer |
|---|---|
| Do you have to read every line? | Not if something else reliably catches the failures; but know which code needs a human to understand it |
| What replaces reading? | Executable checks (tests, builds, fuzzing), AI review, risk-tiered approvals, staged rollout, fast rollback |
| Biggest risk? | Code that passes functional tests but is insecure or subtly wrong |
| What should you measure? | Revert and incident rates, not just throughput |
| What should always get human understanding? | High-blast-radius changes: security, money, deletion, migrations |
What the Hacker News replies say
At the time of writing the thread is small, with only a handful of replies, so treat it as a snapshot of the argument, not a survey. The substance falls into two camps.
Trust the process. One commenter, spacedcowboy, describes coming around to "if it works, I'm good with that," comparing it to never personally checking every colleague's work. They say they work on an autovectorising compiler and have the model write a large number of tests, compile real non-trivial programs, and run a pre-release gate that takes hours across five architectures. They credit long planning sessions covering corner cases and test design as what makes it easier to let the agent run. That is one developer's report, not a verified practice.
Quality still matters. Another commenter, ORDINAND_PIZZA, pushes back on a joking reply that "quality is no longer an objective," calling the idea dangerously negligent and asking what happens if everyone adopts that attitude at scale. A third, yulaow, says that, from what they read on Blind and assuming it is true, engineers at Meta are not spending time on long planning sessions because of how many parallel PRs they must manage. That is second-hand and unverified.
There is also the half-joking "more AI" answer from pluc, who suggests agents watching agents, which another commenter, paid_dot_expert, turns into a concrete idea: have a second agent fuzz test the first, do adversarial review, or produce a video explaining the code. The disagreement is real, and it is useful: the question is not whether to trust the model, it is what evidence you require before you do.
What does published evidence say?
Three pieces of recent coverage point the same way.
A first-party process from Anthropic. In How the Claude Code team does code review, Anthropic says Claude writes about 90 percent of Claude Code's own code, and that merged pull requests more than doubled from June to September while the share reverted fell by more than 40 percent. It does not claim humans read every diff. It treats "did a human read the code?" as an imprecise proxy for "what could go wrong, and which check should catch it?" We summarized the layers in our write-up of the Claude Code review process. These are Anthropic's own numbers about its own repository.
A security warning. The LAST benchmark paper on arXiv reports six frontier coding agents passing 73.6% to 91.3% of tasks functionally but only 16.4% to 25.1% producing code that is both functional and secure; see our coverage of the benchmark. That is the strongest argument against "if it works, ship it": working is not the same as safe.
A maintainer's cost. PostgreSQL 19 slipped after reverts, with a committer saying LLM-assisted review surfaced a long tail of bugs rather than AI having written the faulty code, per our post. Linus Torvalds has similarly said AI review is improving the kernel while straining maintainers, in our coverage of his talk. Review capacity, not typing, is the bottleneck, a theme in AI coding agents produce more code, not more software.
Two reviewers inspecting one sheet and marking a green check, illustrating AI code review for AI-written code
A seven-rule playbook
These rules are our synthesis of the sources above and standard engineering practice, not a quote from any one of them.
- Make the agent prove it. Never accept "done." Require runnable evidence: test output, a build, a screenshot compared to a design. Anthropic's post puts verification before review for this reason.
- Write the plan and the tests first. The strongest HN report credits planning and test design for the confidence, not the model. Spend your human time there.
- Split code by blast radius. Write a short list of areas that need a person who understands the change: authentication, payments, data deletion, migrations, anything touching permissions. Everything else can use lighter review.
- Add an AI reviewer, and cap it. A second model with fresh context catches different mistakes. Anthropic reports reviewer noise and endless loops, and capped rounds to stop them. Set a limit.
- Add security-specific checks. Given the LAST numbers, functional tests are not enough. Use static analysis, dependency scanning and secrets scanning in CI.
- Make mistakes cheap to undo. Feature flags, merge queues, staged rollouts and one-command rollback turn an incomprehensible bug into a short incident.
- Track the guardrail. Watch revert and incident rates alongside throughput. If they rise, you have only moved the cost, not saved it.
If you use Claude Code, the files that steer this are covered in our guide to CLAUDE.md, skills, hooks and subagents, and automated approval flows are discussed in Codex Auto-Review.
"Understanding" is not all or nothing
The Meta engineer's phrasing is useful: "You understand the high level, but not every detail." That is how most engineers already treat dependencies, compilers and operating systems. The new problem is that the unknown code is yours, written this week, and nobody else has run it in production.
A practical middle path is to understand the interfaces and invariants even when you do not read the implementation. Be able to say what the function promises, what it must never do, and how you would detect a violation. If you cannot, add a test that states it. That test is the understanding you retain.
A worked example: a prompt you can paste
Suppose an agent has just written a function that applies discounts to an order. Instead of reading it line by line, ask for the contract and the evidence:
Before I review this change, give me:
1. The invariants this code must never violate (for example, total never negative).
2. A property-based test for each invariant, and the test output.
3. The three inputs most likely to break it, with the result of running each.
4. Anything you changed outside the files I named, and why.
If the answers are specific and the tests pass, review the invariants and the tests rather than the implementation. If the agent changed files you did not name, or cannot state an invariant, that is your cue to read the diff carefully or to reject it. This keeps human attention on the part that carries meaning, which is the same principle behind Anthropic's risk tiers, and it costs minutes rather than an afternoon.
For migrations or deletions, add one more step: have the agent write a dry-run that prints what would change, and read that output yourself. A person who understands the effect of a change can safely skip the implementation; a person who understands neither should not ship it.
Team-level habits that help
- Ask for a written explanation in the PR. Have the agent summarize what changed and why, then check the summary against the diff. Mismatch is a signal.
- Rotate ownership. Someone should be on the hook for each area, so that "nobody understands this" never describes a whole subsystem.
- Keep a short incident log of AI-related bugs. Patterns tell you which rules to tighten.
- Be honest in the interview loop. If your team ships agent-written code, say so, and say how you verify it.
Limits and what is not established
The Ask HN thread is early and small, and its comments are individual reports. The Meta engineer's LinkedIn post is quoted second-hand through the submission. Anthropic's numbers are self-reported for one codebase and may not transfer to yours. The LAST results are from a single benchmark. None of this proves a particular team can safely stop reading code; it shows what evidence to ask for.
Related reading
- How the Claude Code team does code review
- The AI verification tax: rework surveys and how to cut it
- LAST benchmark: how secure is vibe-coded output?
- AI coding agents produce more code, not more software
- PostgreSQL 19 delayed after AI reviewers find bugs
- Linus Torvalds on AI, vibe coding and kernel review
Details reflect the Hacker News thread and sources as of October 19, 2026; the thread is still developing.