Someone posted about an AI-written quant script they'd been running on Bybit for about a month. Numbers attached: 31.04% return, 32 trading days, 100% win rate, one copy-trader, roughly 100U in the account. They were honest that a month on tiny capital proves nothing, and they're right. I'll go further: those figures are unverified, screenshot-only, and on an account small enough that a couple of lucky legs on a trending market explains all of it. A 100% win rate over 32 days is a red flag, not a feature.
So I'm not going to talk about the returns. What caught my eye was one line they dropped almost in passing: the program also logs every trade so they can go back and see why each position opened and closed. That's the durable half. The live execution needs an exchange connection and real risk, and it's the part most likely to blow up. The decision journal is the part that survives, teaches you something, and doesn't depend on anyone trusting a screenshot.
Separate the risky half from the reproducible half
Here's the split I'd make before writing a line of code. Live order routing to an exchange is off the table for what I'm building — that lives on the trading venue, and it's not something you rebuild casually on a general platform. VicroCode can't touch an exchange, and honestly you don't want your review tooling coupled to your money anyway.
What you *can* rebuild cleanly is everything downstream of a decision: the rule that fired, the market state when it fired, the entry and exit, and the reason attached to both. Treat the strategy as data you replay, not capital you deploy. That reframing makes the whole thing testable without a single dollar at risk.
A replay runner instead of a live bot
The first piece is a strategy-replay runner. You feed it historical candles — a CSV export, whatever you've got — and the same entry/exit logic the original script used. It walks the data bar by bar and emits a decision every time a condition triggers: timestamp, direction, the indicator values that caused it, the simulated fill, and a short reason string like "fast MA crossed slow, trend filter green."
This is a natural fit to run Python online, because it's pure computation over a dataset with no exchange dependency. The runner's job isn't to make money, it's to make the strategy's reasoning legible. When you replay across a choppy stretch and a clean trend, you find out fast whether that 100% win rate was skill or just a market that only went one way. The original poster said they were curious how it'd behave in sideways chop — a replay runner answers that in minutes instead of another month of live risk.
One boundary worth stating plainly: a replay over historical data is a simulation. It won't capture slippage, funding, or partial fills the way a real venue does, so treat its output as a reasoning check, not a performance forecast.
The ledger is the actual product
Each decision the runner emits gets written as a row in a trade-decision ledger. I'd use SQLite for this: one table for trades, columns for entry time, exit time, direction, size, the trigger reason, the exit reason, and a free-text notes field you fill in later. Nothing exotic — the value is that it's structured and editable.
That editability matters more than it sounds. Machine-generated logs are never quite right. You'll want to correct a mislabeled reason, tag a trade as "lucky, not repeatable," or annotate the three positions that would've been stopped out if the filter were tighter. Being able to open the SQLite editor and hand-fix a row, or bulk-tag a run, turns a dumb log into a journal you actually reason with. The original script recorded why it opened and closed; the missing step was giving a human a place to argue back.
A rough shape for the table:
CREATE TABLE trades (
id INTEGER PRIMARY KEY,
opened_at TEXT,
closed_at TEXT,
direction TEXT, -- long / short
entry_reason TEXT,
exit_reason TEXT,
pnl_pct REAL, -- simulated, from replay
confidence TEXT, -- your later annotation
notes TEXT
);Keep `pnl_pct` labeled as simulated in your own head. The point of the ledger is the reasons and the annotations, not to manufacture a return figure you'd then wave around.
A review board you can share without sharing your keys
The last piece is a read-and-annotate view over the ledger. A single HTML page that lists trades, filters by reason or by winning/losing, and lets you click into one decision to see the full context and add a note. Since this is a static-feeling interface backed by your data, you can run HTML online and host it as a small review board — no server framework, no exchange credentials anywhere near it.
Because the board never talks to a trading account, it's safe to share. If you want a second opinion on your logic, you hand someone the review board, not your API keys. That's the inversion I like: the original post shared a copy-trade link and a screenshot, which asks people to trust the outcome. A decision board asks people to inspect the process, which is the thing that's actually worth a peer's time.
What this buys you
You end up with three loosely coupled parts: a Python replay runner that turns a strategy into a stream of explained decisions, a SQLite ledger you can correct and annotate by hand, and a hosted page for reviewing it. None of them touch live money, so none of them can lose it. All of them are reproducible by anyone you hand the files to.
The honest takeaway from the original post wasn't the return — it was their own line that the program "at least lets you stop staring at the screen." Fine. But if you're going to hand decisions to code, the minimum you owe yourself is a record you can interrogate later. Build the journal first. If the strategy is real, the journal will show it. If it isn't, the journal is how you find out for 0U instead of learning the hard way once the account is bigger than 100.