The Bug That Shipped Three Times Before Anyone Actually Looked

Reading Code Is Not Verifying It

Ship AI-generated code that reads correctly and you have shipped something that looks right, not something that is right. Those are different claims. Only one of them survives a customer actually opening the file.

AAA shipped this exact mistake once. A placeholder logo sat inside a PDF export function, unnoticed, for months.

What Actually Shipped Broken

Every Field Notes article on this site generates a branded PDF on request. The cover page is supposed to carry the Active A mark: two converging strokes with a Signal-orange crossbar.

For three live articles, that mark was never actually there. The export function drew a plain Ink square with an orange rectangle stamped on it. It was a leftover placeholder, not a letterform.

A fourth article’s PDF got a real look during an unrelated review. That is how the bug surfaced: by accident, not by process.

The Fix Was a Pipeline, Not a Patch

Redrawing the logo fixed one PDF. It did not fix the reason nobody caught it the first three times. The real fix had to check the output, not the code that produced it.

The pipeline now used for every Field Notes PDF runs three real tools in sequence under Node, no browser involved. jsPDF generates the actual PDF file. pdfjs-dist opens that real file and renders each page. @napi-rs/canvas turns each rendered page into a real PNG image, the same as a human would see.

That single step is the actual fix. Look at the real output. Do not just read the code that claims to produce it.

This exact pipeline ran twice already, on the piece you are reading before this one. Its own PDF export was generated and rendered to PNG before anyone called it finished. Same three tools. Same check.

A Second Example: Research That Has to Be Real

The same discipline shows up in AAA’s own published research. A Field Note about 25 real Denver restaurants needed real robots.txt files, real homepage HTML, and real review data, not invented numbers dressed up as findings.

The script that pulled that data runs real API calls against Google’s Places API and parses real JSON-LD from real homepages. Before anyone trusted its output, it ran against three known cases first: AAA’s own site, Wikipedia, and a site already known to block AI crawlers. All three matched what was already known to be true.

The script itself is not on the live site. It lives in the repository’s research folder, available to anyone on the team who wants to check it.

Where Else This Pattern Applies

Verifying real output instead of trusting code that looks right is not specific to PDFs. None of the four examples below are real AAA client work. They show where the same discipline applies outside this site.

• E-commerce. A check that renders the actual product page an AI pipeline produced, image and price included, instead of trusting that the generation step returned a 200.
• Scheduling. A check that opens the real calendar invite an AI agent sent, not just the API response confirming it sent something.
• Contracts. A check that diffs the actual clause language against a known-good contract, not a summary that says the draft looks complete.
• Data pipelines. A check that opens the real exported spreadsheet and checks the numbers, not the log line that says the export succeeded.

Each example above is illustrative, not a client engagement. The PDF pipeline described earlier is the one instance of this pattern that is real and running today.

What This Article Proves

This piece has its own Download PDF button. Before it shipped, that PDF was generated, rendered to PNG, and actually looked at, the same three-tool pipeline described above.

Active Ship is the name for this practice area: AI software development done the way AAA actually does it, not the way the term gets used in a pitch deck. The next capability up is Active Eval, the methodology this whole pattern depends on to mean anything beyond a claim.