Ask HN: How to deal with shipping AI-written code you don't understand?

Oct 19, 2026•rzk•View Original

TL;DR Highlight

Developers share how they ship AI-written code: design it yourself, let LLMs implement, and test heavily.

Who Should Read

A backend developer anxious about merging PRs written by AI agents that they could not fully read.

Core Mechanics

The thread has no article body, only comments
- The original post text was not provided.
- The title asks how to deal with shipping AI-written code you don't understand.
No source facts can be verified here
- All methods are commenter opinions, so they are summarized in the community reactions section.

Community Reactions

Human designs, LLM implements
- One commenter designs abstractions and interactions at the UML level and has the LLM fill in only the gaps.
- They said LLMs write poor abstractions, causing heavier refactors as requirements change.
Invest in tests and verification
- A compiler-project commenter writes tons of tests and runs a release gate taking hours on 5 architectures.
- Another commenter adds fuzzing, chaos, and mutation testing to trust the tests themselves.
Match review depth to risk
- One commenter writes the SQL schema by hand and mostly vibe-codes HTML/JS/CSS.
- Another spends more review time on dangerous decisions that are hard to roll back.
Counterargument: you must read the code
- One commenter said at least one person at the company must be able to explain the code, and tests can be wrong too.
- Another argued that not coding yourself erodes tacit understanding, so there is no middle ground.
Make agents prove their work
- One commenter requires screenshots, videos, code reviews, and architecture diagrams per PR.
- Another has the LLM write a change template and leave review comments on untested assumptions.

How to Apply

Add a second AI reviewer to your next PR
- Pick a PR you are about to merge and have a different AI than the author review it.
- Ask it to explain, rate, and propose alternatives to the design choices.
Write a design doc before agent work
- At the start of a feature, write module responsibilities and interactions yourself, then let the LLM implement.
- Keep updating that doc as the basis for later refactors.
Require a change template from the agent
- For every PR, have it write external integrations, happy path, corner cases, and a deploy checklist.
- Have it leave code comments on assumptions it could not verify.
Set review depth by risk
- Write or fully read hard-to-reverse areas like DB schemas.
- For easily rebuilt areas like UI, rely on tests and requirement checks.

Try It

copy & run

# Paste into Claude Code or ChatGPT (simplified version of ideas from the thread comments)

You just implemented the change below. Answer in this format for a reviewer who will not read the code.

{{change diff or PR description}}

1. Interactions with external systems
2. Happy path sequence
3. Corner cases
4. Deploy checklist and settings changes
5. List of untested assumptions: for each, "what could not be tested / what you think / what happens if released unchanged"

Next step: pick the riskiest item from #5 and write a test that verifies it.

Terminology

UMLA notation for drawing how classes and objects connect. Like a blueprint, it fixes the structure before coding.

Tacit understandingA feel for the code that is hard to write down and builds up by working in it. Like riding a bike, it fades unless you practice.

Mutation testingDeliberately injecting bugs to see whether your tests catch them. It is a test of your tests.

FuzzingFeeding random or odd inputs in bulk to see whether the program breaks.

Related Resources

Ask HN: How to deal with shipping AI-written code you don't understand?

Oct 19, 2026•rzk•View Original

TL;DR Highlight

Developers share how they ship AI-written code: design it yourself, let LLMs implement, and test heavily.

Who Should Read

A backend developer anxious about merging PRs written by AI agents that they could not fully read.

Core Mechanics

The thread has no article body, only comments
- The original post text was not provided.
- The title asks how to deal with shipping AI-written code you don't understand.
No source facts can be verified here
- All methods are commenter opinions, so they are summarized in the community reactions section.

Community Reactions

Human designs, LLM implements
- One commenter designs abstractions and interactions at the UML level and has the LLM fill in only the gaps.
- They said LLMs write poor abstractions, causing heavier refactors as requirements change.
Invest in tests and verification
- A compiler-project commenter writes tons of tests and runs a release gate taking hours on 5 architectures.
- Another commenter adds fuzzing, chaos, and mutation testing to trust the tests themselves.
Match review depth to risk
- One commenter writes the SQL schema by hand and mostly vibe-codes HTML/JS/CSS.
- Another spends more review time on dangerous decisions that are hard to roll back.
Counterargument: you must read the code
- One commenter said at least one person at the company must be able to explain the code, and tests can be wrong too.
- Another argued that not coding yourself erodes tacit understanding, so there is no middle ground.
Make agents prove their work
- One commenter requires screenshots, videos, code reviews, and architecture diagrams per PR.
- Another has the LLM write a change template and leave review comments on untested assumptions.

How to Apply

Add a second AI reviewer to your next PR
- Pick a PR you are about to merge and have a different AI than the author review it.
- Ask it to explain, rate, and propose alternatives to the design choices.
Write a design doc before agent work
- At the start of a feature, write module responsibilities and interactions yourself, then let the LLM implement.
- Keep updating that doc as the basis for later refactors.
Require a change template from the agent
- For every PR, have it write external integrations, happy path, corner cases, and a deploy checklist.
- Have it leave code comments on assumptions it could not verify.
Set review depth by risk
- Write or fully read hard-to-reverse areas like DB schemas.
- For easily rebuilt areas like UI, rely on tests and requirement checks.

Try It

copy & run

# Paste into Claude Code or ChatGPT (simplified version of ideas from the thread comments)

You just implemented the change below. Answer in this format for a reviewer who will not read the code.

{{change diff or PR description}}

1. Interactions with external systems
2. Happy path sequence
3. Corner cases
4. Deploy checklist and settings changes
5. List of untested assumptions: for each, "what could not be tested / what you think / what happens if released unchanged"

Next step: pick the riskiest item from #5 and write a test that verifies it.

Terminology

UMLA notation for drawing how classes and objects connect. Like a blueprint, it fixes the structure before coding.

Tacit understandingA feel for the code that is hard to write down and builds up by working in it. Like riding a bike, it fades unless you practice.

Mutation testingDeliberately injecting bugs to see whether your tests catch them. It is a test of your tests.

FuzzingFeeding random or odd inputs in bulk to see whether the program breaks.

Ask HN: How to deal with shipping AI-written code you don't understand?

TL;DR Highlight

Who Should Read

Core Mechanics

Community Reactions

How to Apply

Try It

Terminology

Related Papers

Related Resources

Ask HN: How to deal with shipping AI-written code you don't understand?

TL;DR Highlight

Who Should Read

Core Mechanics

Community Reactions

How to Apply

Try It

Terminology

Related Papers

Related Resources