reference
Living

Ten paragraphs to defend one line of code

You ask a simple question in review and get an AI-written essay that sounds right and answers nothing. Here's why it happens and what to ask instead.

An explanation written after your question is built to sound reasonable, not to remember what happened. A record made at the time beats a fluent account made later.

§01 · the symptom

A simple question, an essay back.

“If you ask questions in the PR, the engineer uses AI to generate 10 paragraphs justifying that comment.” You asked a simple question. You got an essay that sounds right and answers nothing.

§02 · why it happens

The answer was written after the question.

That answer was written after your question, by a model reading the code. It's built to sound reasonable, not to remember what actually happened, because there's nothing for it to remember.

Length stands in for an answer. Ten paragraphs feel like a reason even when none of them is one.

§03 · what doesn't work

What doesn't work.

Asking again, more precisely. You get more paragraphs.

Banning AI from review replies. You can't enforce it, and it punishes the people who say they used it.

“Keep it short.” You get a short made-up answer instead of a long one.

§04 · what actually helps

What actually helps.

Most of this isn't us.

Ask for a link, not an explanation: “where was this decided?”

Trust anything written before your question over anything written after it.

Accept “I don't know why, the model wrote it” as a real answer, then fix it on the spot: decide now, and write the reason down.

§05 · the receipt

A measurement beat a confident sentence.

Our job runner writes two kinds of log line. Some say what it did. Others measure what actually happened, after the fact.

In September a line written when each job started said the job would survive a runner restart. Twenty-one seconds later, a separate check in the same log measured how many jobs had survived: none. The measurement was right, and it was caught the same day. The corrected line, and the rule since, state what was done, never an outcome the code can't guarantee.

What was measuredWhat the record says
what the start-up line claimed“survives a runner restart”
what the check measured, 21 seconds later“0 SURVIVED the restart”
the rule it produceda log line states what was done, not an outcome
recorded9 September 2026
where it's fromVinculum's own project record, which runs on Vinculum
§06 · where a shared memory fits

Where a shared memory fits.

In Vinculum every entry has a time and links to what it's about, so “was this written before or after the question?” is something you can check.

It won't stop anyone generating ten paragraphs. It gives you something older to point at instead.

§07 · common questions

Common questions.

Should we ban AI-written review replies?

You can't tell them apart reliably, and the problem isn't who typed it. Ask for the record the answer comes from, whoever writes the reply.

Is a long answer always a bad sign?

No. A long answer that points at something written at the time is fine. A long answer that points at nothing is the one to push back on.