Build1 distinct publisher3 min readUpdated
A coffee roaster in Taiwan building an ERP with Claude Code turned three audit rules into a push-blocking CI script. The bug that motivated it was a spec his code had quietly stopped obeying.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A developer who describes himself as a coffee roaster in Taiwan, eight months into teaching himself to code with AI, has published the prompt log of the day he stopped asking his assistant to fix bugs and started asking it to block them [1]. By his own account the shift was from "fix this" to "fix this and prevent it from happening again" [18], and the thing that came out of it was a CI script that blocks pushes on rule violations [6]. That is the right shape, and it is worth looking at closely because the log also shows how far the shape still is from the promise.
The timestamps are unusually precise. At 11:41 on April 21, 2026 he asked whether three audit rules should go into something called governance-guard, then be used for a targeted scan [3]. At 15:08 the same day he chose the CI option: scan all relative and alias import paths, fail equals block [4]. At 01:12 the next morning he asked whether the fixes and rules could be saved as a reusable "skill", because he expected the work to be forgotten once his attention returned to the MVP launch and to turn into hidden risk [5]. That is thirteen and a half hours from idea to enforcement policy [15], inside one session, which produced governance-guard.mjs, a TECH-DEBT-BACKLOG.md where known violations get queued rather than fixed, and skill files meant to survive across projects [6].
The motivating defect is the interesting part. On April 29 he wrote that a previous balance was still showing zero after five or six versions of fixes [8]. The cause, as he describes it: the docs said single_price was the single source of truth, the code used a five-layer fallback, and the UI was still recalculating, so fixing one site left four others in place [9]. It became one of fourteen data-drift debugging records and produced a written instruction, Rule 17 Step 0, that value-mismatch bugs must begin with a SQL query against the database rather than a guess in code [10][11]. April was his heaviest month at 348 commits, the project's single-month high [7], roughly 11.6 a day [16].
So the diagnosis is a docs-versus-code divergence, but the executable check that shipped is an import-path linter [4]. The account does not describe an automated test that compares the written spec to the implementation, and publishes no before-and-after defect numbers [17]. The SSOT rule stayed prose; the enforcement went to a different, cheaper rule. That gap is the honest state of this idea generally. Import paths are trivial to assert in CI. "The code has exactly one price authority" requires the spec to name the authority in a machine-readable way, and the check to fail when a second path appears. Nothing here says that was built.
Two things to watch. First, whether the skill files actually carry rules into a second project, which is the claim that separates a governance primitive from one repo's lint config [5]. Second, whether Rule 17 Step 0 ever becomes a test [11], or whether the backlog file [6] simply absorbs violations at the rate a solo developer can triage them.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
The author describes himself as a coffee roaster in Taiwan who taught himself to code with AI over the past 8 months, and built a full vertical-integration ERP for his coffee brand covering green bean inventory, roasting orders and e-commerce checkout.
The author's stated goal is a workflow in which the prose he has written (docs, specs, governance rules) and the code he has shipped audit each other.
At 11:41 AM on April 21, 2026 the author first wrote governance-guard into a prompt to Claude Code, asking whether three audit rules should be put into governance-guard and then used for a targeted scan reporting potential errors back to him.
At 15:08 the same day he prompted: "Option B (CI layer): governance-guard adds a rule to scan all relative / alias import paths... fail = block --> do this."
At 1:12 AM on April 22 he used the word "governance" for the first time, asking whether the fixes and rules discussed could be saved as a "skill" for reuse in future projects, because he worried that once his attention returned to the MVP launch the governance work would be forgotten and turn into hidden risk.
In the same Claude Code session (70aa7ce0), within those 14 hours, three governance artifacts were created: governance-guard.mjs, a CI script that blocks pushes on rule violations; TECH-DEBT-BACKLOG.md, where known violations are queued for triage rather than fixed immediately; and skill files, to make rules survive across sessions and projects.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Single first-person log, no artifacts published
All claims rest on one dev.to post written by the practitioner himself. It is unusually specific for a personal log — verbatim prompts with minute-level timestamps, a Claude Code session id, named files, a 348-commit month — but nothing is externally checkable: no repository, no code for governance-guard.mjs, no commit history, no second observer, and no measurement of effect. Specificity raises the floor; absence of any independent or machine-readable trace keeps the score low.
One self-reported single-person project
Observed adoption is exactly one deployment: the author's own ERP repository, where a push-blocking CI script, a tech-debt backlog file and skill files are said to be in use. Claude Code usage is disclosed for that same single developer. There is no team, second project, downstream user, package release or third-party report anywhere in the supplied material.
Framing outruns the shipped mechanism
The essay promises prose and code that 'literally audit each other' and a phenomenon 'nobody on the internet seems to be writing about', while the mechanism actually described is a lint-style CI rule scanning relative/alias import paths with fail=block, a markdown backlog, reusable skill files, and prose instructions in CLAUDE.md. Docs-versus-code drift and SSOT enforcement are long-standing, widely discussed engineering concerns, and no automated comparison of specs against shipped code is shown. The underlying practitioner detail is genuine and useful, which keeps this well short of the maximum, but the claim-to-artifact distance is substantial.
Self-promotional practitioner essay
The author is writing about his own methodology, his own codebase and his own coffee brand on a developer-community platform that rewards engagement, and he presents the dual-attitude workflow as 'the most precious methodology' of his eight months — a clear reputational and personal-brand incentive to present the approach favourably. Countervailing factors: no vendor sponsorship, funding, product sale or paid relationship is disclosed anywhere in the source, and the post volunteers unflattering material (repeated failed fixes, 348-commit thrash), so the incentive is promotional rather than commercial.
Low: unverifiable, single account, n=1
Confidence is limited by structure, not by internal contradiction. One publisher, one author, one project, no corroboration, no published code and no outcome measurement; the supplied text is also truncated mid-sentence during the Layer 6 episode. What can be stated with reasonable confidence is what the author says he did and when; what cannot is whether the approach works, generalises, or differs from established drift and SSOT practice.
build
AI-written code fails the same four ways, and every gate you own reports green1 distinct publisher
build
The failure modes of AI agents in low-level code have names, and names can be gated in CI1 distinct publisher
build
Thirteen tasks green, then "give up (Recommended)" on the one that needed understanding1 distinct publisher
build
Your reviewing model is reading the diff when it should be reading the session1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 16, 2026