Loading today’s stories
Build1 distinct publisher3 min readUpdated
An automated trading system needed a human three times in thirty days. None of the guards involved was broken; none of them could see that a pending order had been pending for days.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A budget cap that refuses an order is not wrong at the moment it refuses; it is a rule doing its job on one round of one day [5]. The defect lives in the sequence, and nothing in the system was keeping the sequence. Reordering rounds could not help either, because the binding constraint was size rather than order: the remaining sell budget was always smaller than this one position's order [4].
The drawdown guard had the same shape at a different scale. It was written to measure decline from a peak, a quantity with memory, and compared that peak against an intraday snapshot, a quantity with none [8]. The evidence was already sitting in the system's own numbers, a nearly flat index next to a much larger loss reading [8]. A person noticed the mismatch. No code was comparing the two, and by the operator's own account none of the three faults raised itself [1].
The third case is the interesting one, because it is the intervention path. A classifier with three branches and a default accepts everything [11]; when a hand-placed buy opened a position that had never existed in the ledger, the default swallowed it and a real asset read as outside the system [12]. It happened while the operator was cleaning up after the second fault [10], which is when intervention tooling actually gets used: on a disturbed account, by someone carrying a half-finished repair.
Count what was stopped. One sell and two buys, three orders that reached the market only because a human sent them [2], and in both order-level cases the automation erred toward not acting rather than acting wrongly [3]. The remedies all went into the rules: the allocation rule reworked [6], the drawdown guard re-based on closes with a faster guard split off for intraday falls [9], and one classification branch still unwritten [13]. Each is worth doing. None of them notices the next assumption that quietly stops holding.
What would have caught all three is duller than a rule. An age on every pending intention, so a sell nominated four days running raises its own hand [3]. A guard trip checked against an external reference before it is honoured [8]. The ledger-against-account comparison that confirmed the repair [13], run on a schedule rather than after the fact. Counters and a diff, not more policy.
The two writeups do not land in the same place. The English version ends on keeping a last-minute human path and warning that the path is a component like any other [15]. The Korean original, which came first [16], adds requirements: log the intervention automatically so the human is not the system of record, enumerate the kinds of intervention before building the path, and repair the root rule instead of the instance [17]. Its closing position is the stronger one, that automation aims at making intervention safe and recorded rather than at removing the person [18]. That is a build requirement, and the third case is where it failed.
The operator says he did not know in advance where the automation would miss, only afterwards [14]. That is a poor argument for more rules written from imagination, and a good one for instrumenting the states a working system should never be able to sit in.
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 designed the system to judge and trade on its own without needing human approval for each decision, and built the order execution and safety-guard layer around that goal.
Over the past month there were three separate moments where the author had to step in and act directly on the live account, each failing for a structurally different reason.
A particular ticker had a sell plan queued for several days running and was nominated as a sell candidate every day, but the order never reached execution.
The cause was the rule splitting the daily trading budget across multiple rounds: this position's order size was consistently larger than whatever sell budget remained that day, so no reordering of rounds could clear it.
The budget cap itself was working exactly as designed; the failed element was the assumption that if an order did not clear this time it would clear next time, which never held for this position.
The author executed the one blocked order by hand, an irreversible sell on the live account, and afterwards reworked the allocation rule so the same starvation pattern could not recur.
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.
Detailed but wholly self-reported
The mechanisms are unusually specific for a devlog — order size versus remaining round budget, cumulative-versus-instant metric mismatch, a three-branch classifier defaulting an unmatched case — and the English and Korean items agree in full. But both items are the same author on the same platform, so there is no independent corroboration, no logs, no trade or balance figures, and the reconciliation result ('ledger matched the live account exactly') is asserted rather than shown. One outstanding fix is disclosed, which slightly raises credibility of the account.
One personal live deployment
The only adoption visible is the author's own system trading a live brokerage account, plus the post-incident rule and guard changes he made to it. There are no other users, no released tooling, no third parties reporting the same pattern, and no disclosed capital or volume, so adoption is real but confined to a single hobbyist deployment.
Mildly overstated generalisation, restrained specifics
The incident reporting is modest and self-critical, names an unfinished fix, and pitches no product, which pushes the gap toward zero. The overstatement is confined to the framing: three anecdotes from one personal system are generalised into design principles about intervention paths for automated systems in general, and the claim that no automated alerting caught the faults is an inference the sources never actually make.
Devlog audience-building, no commercial stake disclosed
The author is publishing a bilingual cross-post that links to his own algorithmic trading devlog and to his earlier write-up on the execution and safety-guard layer, which is a reputational and audience-building incentive to present the system as thoughtfully engineered. There is no product for sale, no funding, no vendor or sponsor mentioned, and the post volunteers failures rather than wins, so the pull toward flattering framing is limited.
Coherent single-author account, unverifiable
Confidence in the engineering narrative is moderate: the mechanisms are plausible, internally consistent, and consistently stated across both language versions, and the author's incentive to distort is low. It is capped by the structure of the cluster — one publisher, one author, no numbers, no external check, and one derived claim about alerting that the sources do not support.
build
Six MariaDB versions, one real difference: the only reason to leave 10.6 is the July 2026 clock1 distinct publisher
build
Force the tool call, then hand Lightsail a long-lived key1 distinct publisher
build
AI-written code fails the same four ways, and every gate you own reports green1 distinct publisher
build
CSA's 2026 threat list is a flat line, so ask which threats a config snapshot can prove1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
2 articles · August 22, 2026