Autonomous trader, pulled back from a failure mode
// verifiable artifacts
What it was
An autonomous trading bot built for a market that exists somewhere between casino and circus: meme coin trading on Solana, on a platform built around bonding-curve pricing. The target asset class is one where roughly ninety-five percent of new coins die within hours. The remaining five percent is where the math has to be precise enough to extract value before the next rug pull.
The bot eventually achieved a profit factor of 6.8. That number is high. In trading systems, a profit factor above 2 is good. Above 4 is rare. 6.8 in this specific market environment is the kind of figure that should make any reader skeptical, which is appropriate. The receipt here is not the profit factor; it is the methodology that produced a working version after three earlier versions were torn down to nothing and rebuilt.
What got deleted
Three full builds before this one were deleted entirely. Not patched, not refactored, deleted. Started over from blank.
The reason that matters: when a foundation is wrong, patching it just preserves the wrong foundation. Three times the operator looked at what existed, recognized that the bones were not load-bearing for the use case, and chose the harder thing (start fresh) over the easier thing (keep patching). That is the discipline most people skip. They protect the sunk cost. They keep extending a foundation that should have been demolished. The bot got built on the fourth attempt because the operator was willing to walk away three times.
The lesson is not "delete things and start over." The lesson is "be honest about whether the foundation can hold the next floor, and act on the honest answer, even when the honest answer is expensive."
What the deleted builds taught
The fundamental lesson from attempts one through three was the SpecMesh principle in raw form: know the shape of what you want before you start asking the agent to build it. Do not get trigger-happy on features. SPEC the build before any code. Spend days, sometimes weeks, on the SPEC. Let the SPEC be the thinking surface. Do not let the building become the thinking.
The first three builds were thinking-by-building. The fourth was building from spec. That is the whole difference.
There were also concrete technical lessons that informed the SpecMesh approach:
The price calculator. The platform's bonding curve produces price as a function of supply, but the math is non-trivial and the on-chain state can update faster than naive polling. Getting the price calculation wrong meant the bot believed assets were at prices they were not actually at. That gap between perceived price and actual price is where everything broke. It took more than four attempts to get the price calculation reliable.
Position management at speed. A meme coin market moves fast enough that the gap between intent ("sell at +200%") and execution ("the sell tried to fire when price was already -40%") has to be measured in milliseconds, not seconds. Patience on the SPEC side, urgency on the execution side. Mixing those up is fatal.
Risk gates. The first attempts had risk gates that READ the right inputs but were not structured to actually halt execution under bad-state conditions. They would log a warning and proceed. That is the failure mode of pre-SpecMesh discipline: alerts without enforcement. Gates that report but do not block. The fourth build moved the gates to enforcement-by-default and only let them through with explicit override.
The break that defined the build
There was a specific trade that crystallized the entire failure surface. A position was up over 300 percent. The stop loss did not trigger. The take-profit logic did not trigger. The price dumped. The coin was rugged shortly after. The bot held to zero. Hundreds of percent of unrealized gain became a complete write-off because the components meant to capture that gain did not fire.
The root cause: the price calculator was telling the bot that the price was something other than what the market had it at. The decision logic was correct, but it was deciding based on the wrong number. Garbage in, certain decisions out.
That single trade is the lesson that hardened the methodology. SpecMesh in this domain became "the SPEC names every assumption the decision logic depends on, and gates verify the assumption before the decision fires." The price calculator is no longer trusted; it is verified. The stop loss is no longer assumed; it is gated. The take-profit is no longer hoped-for; it is enforced.
Generalized: do not trust the data layer. Verify every signal the decision depends on, every time, before the decision executes. The cost of that verification is tiny compared to the cost of a wrong decision on a real position.
The methodology lesson
The thing that crystallized SpecMesh through this build, more than through any other:
Be patient. Have a clear vision of the project from where it starts to where it would scale to if everything worked. Map the failure surface in advance. Know what tools are needed, what research is needed, what new skills the agent has to acquire, what new instruction-sets are required. Spend the time to think it all through BEFORE the build. Do not let the building be the thinking.
That principle is the load-bearing rule. It is the difference between three failed attempts and a working bot on the fourth. It is the difference between vibe-coding and operator-class orchestration. It is what SpecMesh formalizes.
The trading bot did not create this principle. The trading bot proved this principle. SpecMesh existed in nascent form before this build; the rescue made it explicit.
What this rescue proves about the methodology
Three things, in order of weight.
First, the discipline to demolish a foundation that cannot hold the next floor is rarer than it sounds. Most builders, most operators, most teams will keep patching. The methodology has to embed that demolition discipline at the SPEC layer so it triggers on architectural mismatch, not on emotional fatigue. Three deleted builds is the receipt for that discipline being real, not aspirational.
Second, the failure mode of pre-SpecMesh systems is alerts-without-enforcement. Gates that report but do not block. The 300-percent-to-zero trade was that exact failure pattern at maximum amplitude. SpecMesh closed that failure mode by making gate enforcement structural rather than optional.
Third, you cannot ship a complex autonomous system without first writing down what it is supposed to do. The three deleted builds skipped the SPEC. The fourth started with the SPEC. That is the entire difference. Repeat that pattern, and the next complex build is buildable.
What this rescue does not prove
It does not prove the bot was a wise commercial decision. Building autonomous infrastructure for a market where most assets die in hours is, in a strictly economic sense, an odd allocation of effort. The methodology learned more than the bank account did.
That is also fine. The methodology compounds across domains. The bank account does not.