With AI as the workforce, one person with the right architecture and enough experience can build a system that used to take a team. That is what this project showed me.
Foundry is the engineering system I designed to build and run Tide Wave, an intraday trading assistant. Claude agents write the code. My part is the architecture: how work is specified, handed out, tested, merged, released and watched. Most of it comes from what I learned in twelve years at Microsoft leading test and engineering teams. The tools are new; the discipline is the same. The agents supplied the typing speed, and the experience supplied the structure that makes their output trustworthy.
This note describes that architecture. It contains no trading logic.
| What I did at Microsoft | What it became in Foundry |
|---|---|
| A build verification tool so each developer could test on their own box before submitting | Crucible, a gated check-in farm: no change reaches master without passing the full suite on a clean machine |
| Stress tests on idle dev boxes, with a daily stress score | Idle machines pull work from a shared queue; dashboards show the system's rhythm, so a part that has gone quiet stands out |
| Model-based testing | Minute-by-minute replay of stored market days; every real incident is pinned as a regression case that must fail before the fix and pass after it |
| Find bugs as early as possible | The bug database is the centre of the system; every finding from every source becomes a tracked bug with its origin recorded |
| Building and running a team: hiring, roles, test plans | Ten AI manager roles with separate authority, written specs as the contract, and capacity treated as headcount |
Every unit of work is a bug: a defect, a feature step, a study. A bug moves through a guarded state machine (open, claimed, in Crucible, resolved, reviewing, closed), and every transition is written to an audit trail and published as an event. Agents subscribe to events instead of polling. One bug is one step. Bigger work is split into steps linked by dependencies, so each agent gets a task it can finish and verify.
A Project Manager agent reads the open bugs, decides what to do next and dispatches a coding agent into its own isolated git worktree. The workforce is outsourced AI from more than one vendor (Claude, MiniMax). A lesson I learned the hard way: the quality of the spec decides who can do the work. An agent builds from what the bug said when it started and shares none of the context the author had. A quality gate rejects a bug that is not specific, measurable and testable before any agent picks it up.
Each decision has one owner: the Project Manager decides what work to do, the Release Manager what ships, the Test Manager what is adequately tested, and the Risk Manager what size the system trades, within limits I set. Further roles cover what the operator sees, client communication, infrastructure, expenses, tax, and compliance and security. Keeping authority separate is what stops agents from overruling one another.
There is no central dispatcher. Each machine runs a small service that pulls from the queue, so a machine that reboots simply resumes. I chose this design after many agents running the suite on one machine kept colliding and producing flaky results.
Diagram and measured numbers: Crucible: the machine farm and its distributed tasks.
Every feature ships behind a live switch that can be flipped without a deploy. A trading change ships on only after a recorded before-and-after study on real recent days, judged against fixed release criteria. The machine proposes trade entries and keeps the record; a person approves entries and owns exits. Safety checks stay mechanical, never left to a model's judgment.
Strategies are replayed minute by minute against stored market history on a Ray cluster. Each of the twelve strategies has its own regression gate. Every run is stamped with its code version and parameters, so a result can be traced to the exact code that produced it.
The project did not start with AI. I wrote the first trading bots by hand in March 2020, and for almost six years every commit was mine; in 2024 I also built my own code generator that wrote Python from historic trading scenarios, which is why that year has the most commits. The first AI-written commits appear in August 2025; from January 2026 the agents took over most of the writing, and by October 2026 they made more than 80% of the commits. The git history records the shift:
I did not write Foundry's code by hand. I built it through architecture: I decided how the work flows, where the gates are, who owns which decision, and what counts as evidence, and then I directed AI agents to build inside that frame. The numbers above are the result of that design, not of typing. Without the experience, the agents would have produced a large amount of code that nobody could trust. With it, they produced a working system.
As a Forward Deployed or AI Platform engineer, the job is the same one I have been doing here: put reliable scaffolding around LLMs so a team can trust what they produce. That means clear specs, isolated work, gated testing, evidence before release, and a human where judgment matters.
More: the Foundry design page (diagrams of the bug lifecycle, a check-in's path through Crucible and the machine farm), the Tide Wave repository, and my LinkedIn profile.
Figures are taken from the system's own records (git history, the Crucible queue and the bug database) on 28 October 2026.