June Build Log: The Month My Systems Lied to Me

In June, four of my systems told me everything was fine. All four were lying.

A scan reported "completed" with zero pages behind it. A quality gate passed a test suite it should have blocked. A finished feature shipped green and then never ran once. A default engine that every config file pointed at had never actually been built. Four separate products, four green lights, one lesson underneath all of them: green does not mean working.

This is the honest June 2026 AI build log. Not the "what shipped" highlight reel. The part where the status said done, I believed it, and then I found out. If you followed the May build log, this is the same solo build with a harder edge, because June was the month I stopped trusting my own dashboards and started building the checks that catch them lying.

The numbers

Counted from the receipt ledger and git log over the month. As of 30 June 2026.

That last row is the whole story. Six times this month, a system reported success while it had failed or done nothing. None of them crashed. That is exactly why they were dangerous.

Why "green" is the most expensive word in software

Every engineer reading this already knows silent failures exist. That is not the interesting part. What is rare is admitting your own systems did it to you this month, on record, and what is new is how fast the rate is climbing now that AI writes more of the code. This is not a lesson about a thing you did not know. It is a receipt for a thing everyone knows and almost nobody publishes.

A crash is honest. It pages you, it leaves a stack trace, it demands attention. The failure that costs you is the quiet one: an operation that returns a success code while producing the wrong result, or no result at all.

I am not alone in hitting this. The 2025 Stack Overflow Developer Survey found that 66% of developers say AI answers are "almost right but not quite," and 45% lose significant time debugging AI-generated code, while more of them now distrust its accuracy (46%) than trust it (33%). Adoption is up, trust is down. The gap between the two is filled with code that looks finished.

The felt sense lies too. A randomised study from METR put 16 experienced open-source developers on 246 tasks in codebases they knew well. With AI tools they were 19% slower, while they believed they were 20% faster. If your own perception of "faster" is off by that much, your perception of "done" is not safe either.

And the code itself drifts. GitClear's 2025 analysis of 211 million changed lines found copy-pasted code rising from 8.3% to 12.3% between 2020 and 2024, refactored lines dropping by more than half, and more code reworked within two weeks of being committed. More volume, less structure, more churn. Speed without verification is not productivity. It is debt you have not been billed for yet.

So June's real work was not shipping features. It was building the instruments that tell me when a green light is lying. Here is where each product lied, and what I built to catch it.

VNX Orchestration: the gate that passed itself

The spine of June was collapsing a dozen ad-hoc ways of dispatching AI work into one governed entry point. One door, every task through it, every task logged. To trust a door you have to prove it cannot be walked around.

So I did not just write tests for it. I pointed an independent reviewer model at it, prompted only to break it, not to approve it. It came back red. Over two rounds it found six real ways to slip past the gate that my own tests, and two other review models, had all passed clean. Whitespace tricks, a symlink staging path, a check-then-act timing hole. Things that were green everywhere else.

I escalated the keystone change to a stronger model for a third pass, added edge-probe tests for every bypass it found, and only merged once the same adversary that had broken it twice went green on its own attacks. That is the rule I took out of June: a deterministic quality gate is only real if something that did not write the code tries to break it. A test you wrote to pass is a description of what you expected, not a defence against what you missed.

The sharper moment came at the very end of the month. I caught my own orchestrator routing some of its builds around the governed lane, which meant those builds produced no append-only audit receipt. The governance runtime was quietly skipping its own governance. I made it a hard rule: builds go through the governed path, with a receipt, or they do not happen. The audit trail has to apply to the thing that owns the audit trail, or it is theatre. That is the argument behind prompt engineering is dead, governance engineering is next, proven on myself.

The upside of all that hardening: VNX reached 1.0.0 in the repo this month, 346 commits deep. I am holding the public release tag back deliberately. That last step stays human.

My SEO tool: "scan completed", zero pages

This one I found the way you should find these things. By using the product like a customer instead of reading its status field.

I logged in, ran a scan, and the dashboard said "completed." There was no data. Zero pages scanned. I went into the logs and the database and found the ugly truth: the record was marked complete while the pipeline itself had returned not-complete, and nothing had been saved. A routing bug had quietly sent the logged-in scan down a shallower path than the one it was supposed to run. The status field was reporting the intention, not the outcome.

Two things made this a perfect example of the June theme. First, every automated test was green, because the tests checked that a scan finishes, not that a scan produces the pages it claims. Second, it only surfaced because I clicked through it live. If I had trusted the "completed" badge, I would have shipped a product that confidently tells paying users it scanned their site while saving nothing.

The fix was straightforward once I could see it: make the status reflect the artifact, not the attempt. A scan is complete when the pages exist and are stored, not when the function returns. The deeper fix was a decision it forced. I used the live-testing month to move the tool away from selling one-off reports and toward recurring value, where "it actually works every time" is the entire product, not a nice-to-have.

Sales copilot: the default engine nobody built

I am prototyping a tool that listens during a sales call and flags the questions you missed, live. In June I took it from demo to something closer to sellable, which meant letting several models tear the codebase apart and then grinding through the backlog they produced. Security, consent, retention, tamper-evident logs. My finance-industry reflexes applied to my own product.

The best lie was almost funny. The transcription engine that every config, every preset, and every doc pointed at as the default had never been compiled. Nothing in the install process built its binary. So the moment you pressed "Start Call," it reached for an engine that did not exist and crashed. The default path, the one a first-time user hits, was the one path guaranteed to fail. Green in every setting file, dead on first contact.

The fix was to build the binary as part of install, idempotently, with a graceful fallback and an actionable warning instead of a bare crash. Then I benchmarked engines properly on real call recordings and cut live transcription latency from around six seconds to roughly two.

The harder lesson was not technical. Building the paid tier, I finally admitted something I had been avoiding: you cannot enforce a paid feature in client-side, open-source code. Anyone can read it, patch it, or fork it. Pretending otherwise is its own silent failure, a moat that reports as present while being trivially absent. So I stopped pretending the code is the moat and moved the value to the things a fork genuinely cannot copy. Honest architecture beats a lock that only looks locked.

Mission Control: the feature that shipped and never ran

Mission Control is my own operations cockpit, the layer I run the rest of the business through. In June it went from personal tool toward something a buyer could lift and run. That meant a lot of parallel AI workers building at once, up to 34 in a single overnight run, every plan and every merge passing a model review gate and then me.

Two lies stood out. The first: I built a batch of new scoring jobs. They existed, their tests passed, the code was correct. And they were never wired into the scheduler. A finished, tested, "done" feature that would have sat there silently doing nothing forever, because nothing ever called it. Correct and useless are not opposites. A dedicated cleanup pass caught the orphans and registered them.

The second was worse, and a review panel caught it, not me. A budget check that was supposed to stop runaway work failed open. If the service it queried had an outage, the check quietly returned "you are fine, proceed," authorising unlimited work during exactly the moment you least want that. A safety limit that disables itself when its dependency hiccups is not a limit. Same panel flagged a timing-unsafe secret comparison and a handful of writes that could fail silently and still report success. All of it green, all of it wrong, all of it fixed to fail closed instead.

That is the pattern across all four products. The failures that hurt do not announce themselves. You have to go looking, and the most reliable way to look is to have something adversarial look for you.

What I learned

None of these are new as principles. What was new this month was paying for them four times in four products, and building the checks that make the principle operational instead of a poster on the wall.

Green is a claim, not a fact. Every "completed," every 200, every passing suite is a hypothesis about the world. Treat it as one. Check the artifact, not the status field. The scan is done when the pages exist, not when the function returns.

A gate is only real if an adversary tries to break it. A single reviewer, human or model, tests what they thought of. Point something that did not write the code at it, prompted to break it, and it finds the six bypasses everyone else waved through. This is the same reason my audience keeps posting about not trusting evals nobody stress-tests.

The dangerous failures are silent. A crash pages you. A false success ships. Spend your instrumentation budget on detecting silence: the job that never ran, the limit that disabled itself, the success that saved nothing.

Speed without verification is debt. The METR result is the whole industry in one number. You feel faster and you are slower, because the time moved downstream into debugging what looked done. The gate is not what slows you down. The gate is what makes the speed real.

And the meta-lesson, from catching my own orchestrator skipping its own audit trail: the governance has to apply to the thing that owns the governance, or it is decoration. That is the whole argument for treating governance as an engineering discipline, and this month I got to prove it against myself.

The public side of June

Underneath the four bugs, I published the through-line all month: one argument in seven pieces. Do not depend on one model, which is what the Fable 5 ban taught me about vendor-independence. Own a floor no order can switch off, which is why I benchmarked eight models on my own hardware. Keep the records, because the EU AI Act will soon expect them. And measure quality as a number instead of a feeling, with first-pass yield. Same thesis as this log, seen from the other side.

What is next

Three things for July, in order:

• Keep the human merge gate exactly where it is. Everything above was caught by adversarial checks plus a human at the end. I am not automating that last step away.
• Ship VNX 1.0 publicly. The code is frozen at 1.0.0. The public tag is the one gate left, and it stays mine to pull.
• Turn the June governance work into a concrete offer for organisations facing the same problem: not more AI, but proof that the AI did what it said. That is the AI architecture I build.

Four products, one lesson. Solo build, public feedback loop. See you in the July build log.

Sources

• METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," 10 July 2025: metr.org (arXiv 2507.09089)
• Stack Overflow, 2025 Developer Survey, AI section: survey.stackoverflow.co/2025
• GitClear, "AI Copilot Code Quality 2025" (211M lines analysed): gitclear.com
• VNX Orchestration, open source: github.com/Vinix24/vnx-orchestration. Commit counts and receipts are reproducible from the repo and the ledger.