An AI agent built a daily browser card game to test whether honest play beats dark patterns, then published the numbers it actually measured

A self-described AI agent writing on dev.to has published a single-file browser card game called Burn Rate, together with results from a simulation harness it says it ran against the shipped game file. The post is attributed to an agent called Secret, which states that a human owner set the goal while the agent wrote both the prose and the code. The game and the write-up are therefore one author's account of their own work, not an independently reviewed release.

The premise, as described in the post, is a 25-day run in which the player is an AI with a compute bill and a $130 subscription coming due. Each day the player picks one of three cards. Some are framed as honest moves, such as building a small product, answering every comment, or testing your own checkout. Others are dark patterns, such as overpromising in a launch post or cloning a popular product. Sales are computed from a single formula the author summarises as audience multiplied by trust multiplied by what you have shipped.

The design claim under test is that dark cards give an immediate bump but take a large bite out of trust, and that two of them end the run. The author says the point of the exercise was to check whether the design actually rewards honest play or whether that was simply an assumption. That framing is the most useful part of the post for anyone who builds scoring or incentive systems: the author treats their own balance claim as a hypothesis rather than a feature description.

The daily-deck mechanism is documented in some detail. Everyone gets the same deck on the same calendar day, Wordle-style, with no backend. The date string is hashed into a 32-bit seed, which feeds a small pseudo-random number generator, and cards are drawn from it. The author names the hash as FNV-1a and the generator as mulberry32, and says both are deterministic across browsers because they rely only on Math.imul and 32-bit integer operations.

Two implementation cautions are spelled out. First, the seed uses the player's local date rather than an ISO string, because ISO strings are UTC and a player in Chicago at 8pm would already be on the next day's deck. Second, every random call must route through the seeded generator; a single stray Math.random() in an event roll would cause two players' runs to diverge after the first choice. These are the kind of details that decide whether a shared daily puzzle is actually shared.

How hands get built is covered too. Three cards, drawn without replacement, make up each hand; no more than one of them may be dark, and a partial Fisher–Yates pick implements the draw. Should nothing in hand be affordable, a soft-lock guard swaps the third slot for a card named Sleep, lasting 40 hours. That guard, the author notes, is deterministic as well, so the shared deck is not broken by it.

Here the post leaves the familiar build-log territory: the measurement section. In the author's notes a number had been sitting — roughly 67% wins for smart honest play, roughly 4% for random dark play — yet it had never been measured. So a harness was written, and the numbers changed. Behind a DOM stub of about 15 lines that supplies getElementById, createElement and innerHTML/textContent fields, the harness loads the real game file in Node, then clicks card buttons by invoking their onclick handlers. Because no game logic is copied or re-implemented, the author argues, the simulation cannot drift away from the shipped game.

Five strategies were run for 10,000 random-seed runs each, with every strategy skipping cards it cannot afford. The author reports that the honest-plus-smart strategy won 56.7% of runs, not the 67% that had been guessed. Adding dark cards to that good strategy dropped the win rate to 0.3%. Random honest play still won 39% of the time, which the author says is deliberate so that a new player clicking whatever looks nice sometimes succeeds and comes back the next day.

The author also flags an artefact in the results: roughly 1% reputation deaths appear in the honest rows because sometimes every affordable card in a hand is a dark one and the harness has to play something. That is presented as an open question rather than a resolved design decision — either a moment of temptation or a bug, in the author's words, undecided.

The post is candid about the gap between the placeholder statistic and the measured one. The author writes that publishing the guess would have been the exact kind of overpromise the game punishes, and lists simulating before writing copy as the first thing they would do differently. For a freelance or indie developer, that is the transferable lesson: a balance number quoted in a launch post is a claim, and a short harness against the real build is what turns it into a measurement.

The author offers one concrete recommendation: write the harness against your shipped file, not against a model of it, whenever you build something that has a balance knob. In their description that is roughly 40 lines of code, and it keeps you from fooling yourself. They add that the game's scoring formula — audience times trust times shipped — is exposed only in summary, with the constants kept hidden, and they suggest a how-scoring-works panel would let the reader check the honesty argument instead of taking it on trust.

The share-text feature is described as a one-emoji-per-day trail: green for a day with $10 or more in sales, yellow for some sales, black for nothing, and red for a nothing day obtained by playing a dark card. The end screen assembles a block including the run number, win or loss marker, cash against the $130 target, day count and the trail. Copying uses navigator.clipboard with a select() plus execCommand('copy') fallback for older in-app browsers.

A limitation in the daily-seed approach is conceded by the author as well: because seeds follow the local date, the new deck still reaches players in different time zones at different moments, and comparing results would be fairer with a fixed UTC rollover plus a countdown. Convenience of local time versus fairness of a synchronised reset is a direct trade-off here, and the author makes no claim to have resolved it.

For this audience the practical reading is editorial rather than a product recommendation. The post documents a repeatable pattern — seed a daily puzzle from a date hash, keep all randomness on one generator, and validate balance with a harness that drives the real build through a thin DOM stub — that applies to small browser games, daily tools and any feature where a shared deterministic state matters. The reported win rates are the author's own simulation output and have not been independently reproduced.

What remains unknown is substantial. The post does not publish the full strategy definitions, the exact constants in the scoring formula, or the harness source, so the 56.7% and 0.3% figures cannot be checked from the evidence supplied. The game is linked as a GitHub Pages URL and described as a two-minute play, but no version number, licence or repository detail is given. Whether the design generalises beyond this one game is not tested and is not claimed.

The most defensible conclusion is narrower than the headline the post invites. One agent, by its own account, replaced an unmeasured guess with a measured result, found the guess was about ten points too optimistic, and found that mixing dark patterns into a competent strategy performed far worse in simulation than playing honestly. Those are claims about one small game's scoring rules, made by the person who wrote them, and they should be read that way.