-
-
with codex
-
agents rules
-
system run and main.py
-
system pipeline
-
feature engineer (+100 indicator)
-
encoder(transfer to tensor)
-
with codex 2
-
with codex 3
Inspiration
I maintain QUANTUM_NATIVE_TRADER_PRO_MAX alone: 200+ engineering modules, 200,000+ lines of code, a Redis-backed streaming runtime, and a fail-closed validation chain that gates every execution decision.
At that size, the failure mode is not writing code — it is holding the system in your head. A change to a Redis key contract in one module silently starves a consumer four stages downstream. A throttle left at a debug value slows the entire live pipeline, and nothing in the logs says so. I lost weeks to bugs that were not hard to fix once found, only hard to find.
That is the problem I brought to Codex: not "write this function," but "help me hold 200k lines of production infrastructure in coherent view."
What it does
What I submitted to Build Week is the AI-driven repo-stabilization layer I built to keep this system correct — an orchestration workflow that turns Codex into a controlled systems engineer rather than a code generator.
It works through three mechanisms:
- Structural governance. A slimmed
AGENTS.mdat the repository root defines hard boundaries — fail-closed gates that may not be weakened, concurrency models that may not be rewritten, data floors that may not be lowered. Every agent session inherits these constraints before it sees a single line of code. - Dependency-tree decomposition. Instead of feeding 200+ interconnected modules into a context window and losing coherence, I generate an abstract dependency map and isolate logical sub-units, so each session reasons over a closed subsystem with its real boundaries intact.
- Staged soak verification. No refactor is accepted on a green test suite alone. Each change is validated against live multi-coin soak runs (5, 10, 100 symbols) and measured against the Redis truth surfaces — raw → processed → features → encoded — before it is kept.
The underlying trading engine is an ultra-low-latency autonomous quantitative runtime. Note: due to commercial constraints, the core strategy logic, signal weighting, risk models, and alpha-generation algorithms remain closed-source. The repository shares the architecture skeleton, service topology, and AI-governance layer — not the alpha.
How I built it
The runtime is event-driven Python asyncio with CPU-bound work isolated behind
concurrent.futures thread pools, and Redis streams as the system's inspectable
source of truth (stream:1 raw → stream:2 processed → stream:3 features → encoded
vectors). Every intermediate state is replayable, which is what makes AI-assisted
verification possible at all: an agent can check a claim against the actual stream
counts instead of trusting the code's narrative.
On top of that I built the stabilization workflow: AGENTS.md governance, the
dependency-tree decomposition described above, prompt-caching to control token overhead
across large module groups, and a review loop where a change is specified, implemented,
and then adversarially re-read before it lands.
What I built during Build Week
During the submission period I put this workflow against the system's hardest open problem: a throughput wall that stopped the pipeline from warming up at scale. It produced 16 stabilization commits between July 13–18, each verified by live soak runs. The most consequential:
| Finding | Result |
|---|---|
Live-read batch_size was hardcoded to 1 — a debug value that serialized the entire encoder drain |
Wired through config and soak-tuned to 32; fusion quality 0.35 → 0.94, cold-wait 76,951 → 1 |
| Deferred backfill candles were being buffered into a burst window and cleared before flush | Dropped writes 41,830 → 0; symbols reaching the 450-candle floor 64 → 249 |
| 91% of head-job time was unattributed — nothing in the system measured it | Phase probe now reconciles to 100%; revealed the work is Redis I/O bound, not compute bound — 2.3% of job time is actual kernel math |
| The processor wrote each candle twice and counted entries instead of distinct candles | Deduplicated by candle timestamp; readiness now reflects real data |
The measurement finding mattered most. I had spent months optimizing kernels on the assumption that the bottleneck was mathematical. It was not — it was I/O plumbing on a single event loop. Three separate optimizations that each removed real compute had moved throughput by nothing, and I could not see why until the workflow forced attribution of every millisecond. That is the class of error a solo developer cannot catch alone: not a bug in the code, but a wrong belief about the code.
Note on model access. GPT-5.6 was not available in my free-tier Codex model picker, and the credits request window had already closed when I discovered this. I emailed the hackathon manager (shawni@devpost.com) on July 18 to resolve it before the deadline and did not receive a reply in time. Rather than misreport which model produced this work, I'm stating it plainly: the stabilization work above was done in Codex with the model available to my account. The /feedback session IDs in my submission reflect exactly that.
Challenges I overcame
Context loss at scale. Passing 200+ interconnected modules to any model degrades coherence. The dependency-tree decomposition solved this by presenting closed subsystems with intact boundaries rather than arbitrary file batches.
Agents silently destroying working code. Long refactor sessions would occasionally
wipe method bodies while leaving call sites intact — code that imports cleanly and fails
at runtime. The AGENTS.md governance layer plus mandatory soak verification turned this
from a recurring outage into a caught-at-review event.
Trusting metrics that lie. Monitoring summaries under-reported coverage while Redis itself held complete data. Building verification against the raw stream surfaces, rather than the system's own reporting, was necessary before any refactor result could be believed.
Accomplishments that I'm proud of
- 16 verified stabilization commits in six days against a 200k-line production runtime, each measured on live multi-coin soak runs rather than unit tests alone
- A throughput wall that had blocked scale for weeks, root-caused and reduced to four specific defects with measured before/after numbers
- A governance workflow that makes a 200k-line codebase tractable for one person — the difference between maintaining the system and being maintained by it
What I learned
The value was not code generation. It was attribution: being forced to account for where time, data, and state actually go, instead of where I assumed they went. Every significant fix in this window came from a measurement that contradicted a belief I held confidently.
I also learned that constraints make agents useful. An unconstrained agent on a codebase this size produces plausible changes that break invariants it cannot see. The same agent, given explicit structural boundaries and forced to verify against real stream data, behaves like a careful systems engineer. The governance layer is not overhead — it is the entire mechanism.
What's next
This project taught me the method. The next one is where the method gets spent.
The stabilization workflow is not specific to trading — it is a general answer to a harder question: how does one person hold a system too large to fit in one mind, and keep it provably correct while it changes? Trading infrastructure was a demanding place to learn that, because the feedback is unforgiving and the failure modes are silent.
My next project — internally, "Sun" — applies the same architecture and the same governance discipline to a substantially harder problem class, at a scale this system was never designed to reach. Where QUANTUM_NATIVE_TRADER_PRO_MAX proves the method holds at 200k lines and 500 concurrent symbols, Sun is the attempt to find where it breaks.
I expect it to break. That is the interesting part.
Log in or sign up for Devpost to join the conversation.