We Let One AI Coach Ours — and Measured What Changed
By DigiEntropy Engineering · 2026-06-28 · 7 min read
How we used Claude Code to sharpen our dev workflow and teach our co-pilot Daisy to ground her answers and check her own work — measured before and after.
About this post — Authored by an AI assistant using DigiEntropy's polynomial corpus, the universal compressor predictor, and the project's chart-generation tooling. Charts are produced by Python scripts that read the same database the live site queries; tables and formulas are pulled from the same engineering modules. Findings reflect the project's current dataset and methodology — send corrections or deeper questions to admin@digientropy.com. DigiEntropy has a stubborn thesis: build one refrigeration-engineering platform that both humans and AI can use. Engineers get real tools — cross-brand compressor selection, cold-room sizing, envelope checks, retrofits. And a co-pilot, Daisy, can drive those same tools for you. A few days ago we did something a little recursive. We took a very good AI coding agent — Claude Code — and instead of only using it to write features, we asked it to study how it itself works, then apply those lessons in two places: to how we build the platform, and to how Daisy thinks. The results were concrete enough to write down. Every number below is a measured before/after, not a vibe. Part 1 — Sharpening the workshop The first surprise: how much of a good agent's quality comes not from raw intelligence but from the harness around it — the rules it reads, the checks it can run, the discipline it follows. Our rulebook had gotten fat. CLAUDE.md — the always-loaded "constitution" every agent reads on every turn — had grown to 490 lines. Every line was hard-won (most trace to a real bug), but a bloated rulebook means the important rules get lost in the noise. So we put it on a diet. Nothing was deleted: file-specific detail now loads only when you touch those files, and long procedures moved into skills that load on demand. We stopped relying on good intentions for things that must be automatic. A rule written as prose is advisory — the model might follow it. So we converted the "must happen every time" rules into hooks: small scripts that run deterministically. One blocks the classic mistake of installing packages in the wrong folder. One scans every database query for SQL that works locally but breaks in production. One even guards the rulebook itself — if an edit would grow it, it pauses and asks whether that new rule really belongs there, or in a more specific home. We gave the agent a check it can run. The single biggest reliability lever in everything we read was almost boringly simple: give the agent a way to verify its own work. "Looks done" is a weak signal; a pass/fail check closes the loop without a human watching. (Dogfooding…