Loading today’s stories
Build1 distinct publisher3 min readPublished
A .NET invoicing library built with Claude Code came with property tests, hand-calculated golden scenarios and green CI on three operating systems, all of it blind to the half-penny inputs where half-up and banker's rounding diverge.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
security
AI coding agents route around the repository gate, and JFrog moves the checkpoint to the agent1 distinct publisher
build
AI-written code fails the same four ways, and every gate you own reports green1 distinct publisher
build
Superpowers makes spec-driven work a precondition, then ships it to twelve harnesses1 distinct publisher
build
NVIDIA put a number on agent skills: 300+ verified, two harnesses, baselines under 50/1001 distinct publisher
Rounding policy is only observable at a boundary. Half-up and banker's rounding return the same value for every input except one that lands exactly on a half unit. A fixture set with no half-unit inputs therefore cannot tell you which policy the code implements.
The library rounds half-up, MidpointRounding.AwayFromZero, because that is what tax authorities expect, against a .NET default of banker's rounding, according to the write-up on dev.to [5]. The suite had property tests and twenty-five golden scenarios with hand-calculated values across USD, JPY and KWD [25]. None of those scenarios contained a midpoint value [7]. Flipping the mode left 197 of the 202 tests entirely unmoved [22].
The scenario that looks like it was written for this case is 995 yen at 10 percent, which yields 99.5. ToEven takes that to 100, because 100 is the even neighbour, so both policies agree and the test discriminates nothing [8].
The 3p figure has the same shape. Three lines at 3.99 is 11.97 [20], and 3p spread over three identical lines is a penny each [21]. The author does not show the working, so read the per-line split as inference: for the error to scale with the item count, each line has to land on a half penny and get pushed the wrong way. That is precisely the input class the fixtures lacked [7].
His own stopping rule did not save him either. Fewer than three failures on an arithmetic mutation counted as a hole [15], and the ToEven mutation returned five, which clears that bar [23]. All five sat in the rounding helper's own unit tests [6]. Five failures cleared the numeric bar, but their concentration in a single file meant the call sites elsewhere were still unpinned. When every failure lives in one file, the coverage stops at that function's boundary rather than extending to the code that calls it.
The discount mutation is a cleaner reading of the same fault. Pull rounding out of the invoice-level discount calculation and exactly one test fails, a generic property test asserting that all decimals get rounded, because every discount scenario used a clean percentage of a clean subtotal [9].
The culture test is the one I would frame and hang on the wall. It swaps CurrentCulture to de-DE and tr-TR, exports CSV, asserts [10]. Nothing wrong with it. Then swap InvariantCulture for CurrentCulture in the export code and it still passes, because the fixture invoice totals 100, 20 and 120, and 100m.ToString() under de-DE gives "100" [11]. Change a unit price to 10.50 and the same mutation kills three tests [12]. The fixture's invoice totals were whole numbers, so there was no decimal separator to get wrong, no matter how sound the assertion was.
This is one library's suite, so 202 is not a number about your code. The transferable part is the condition. If the same process wrote the implementation and chose the inputs, and no input sits on a boundary where the implementation had to pick a policy, then the suite documents behaviour rather than constraining it. That is the author's own framing: the agent writes both halves, they pass, and what you have confirmed is that the code agrees with itself [18].
The domain is not incidental to the bill. HMRC and the ATO both permit tax to be rounded per line instead of on the subtotal, and when the accounting system at the other end rounds per line, the totals disagree by a penny [17].
The change that actually altered the outcome was procedural. By the third phase the author had the agent answer design questions on paper first, with real numbers, before code [19]. That puts an expected value outside the implementation, which is the only place an oracle can live.
Ranked by verification strength, evidence, and original report placement.
The author built a .NET invoicing library with Claude Code over about a week, with zero dependencies, VAT and GST arithmetic, and JSON and CSV export.
By the third phase the project had 202 tests passing on two target frameworks and green CI on three operating systems.
The library would have been wrong by 3p on any UK invoice with three items at 3.99 pounds.
The author describes the fault as occurring not in a pathological edge case but on a normal invoice at the most common price point in British retail, in a way that ends up in someone's VAT return.
The library rounds half-up using MidpointRounding.AwayFromZero because that is what tax authorities expect, while .NET defaults to banker's rounding.
Flipping the rounding mode to ToEven produced five test failures, all five of them unit tests of the rounding helper itself, and none of the twenty-five golden invoice scenarios failed.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 30, 2026
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.
One witness, checkable arithmetic
The load of proof rests on a single developer describing his own project, and there is no repository, commit or package link to replay any mutation against. What saves it from being unfalsifiable is that most of the key steps are arithmetic a reader can verify unaided: 399 mod 6 is 3, ToEven really does send 99.5 to 100, 197 of 202 tests really are indifferent to a rounding-policy flip. The weakest link is the tax-authority premise — per-line rounding at HMRC and the ATO is asserted, never cited, and it is the premise the whole design decision hangs on.
A package that never shipped
The only real-world footprint on offer is a release that failed silently — 0.2.0 already on NuGet, 0.3.0 never published. No download figures, no other users, no team adopting the mutation habit, no second project reporting the same blind spots. What is being described is a solo library in its third phase, and our coverage says nothing about anyone but its author touching either the code or the technique.
Headline outruns the timeline
Framing the 3p VAT error as slipping past 202 green tests reads as a bug that survived the suite; on the author's own account it never existed in code — he asked the design question on paper, saw the periodic residual, and made the constructor throw instead. The tests were blind to that class of input, which is the real and interesting point, but they were never given the chance to miss it. Set against that, the post consistently understates itself elsewhere: it declines to recommend mutation testing, admits the fifteen minutes wasted on Stryker.NET, and volunteers that its own stopping rule would have passed the rounding call sites as pinned.
Self-promotion pointed inward
A developer post about a developer's own library and his own agent workflow carries the usual reputational upside, and Claude Code gets named while the mutation tool that failed him also gets named — neither with any disclosed relationship. But the content works against the incentive: the reader is shown a decorative test, a wasted quarter hour, a release pipeline that lied, and a threshold that would have blessed untested code. Nothing is being sold, and the least flattering details are the ones the post leads with.
Firm on mechanism, thin on reach
How half-up and banker's rounding diverge, and why a suite full of clean fixture values cannot see the difference, is nailed down well enough to act on — the specifics are internally consistent and independently checkable. How far it generalises is not: one library, one author, one agent, and no reproduction path. Treat the mechanism as reliable and the claim about agent-written tests at large as a hypothesis this story argues rather than settles.