Building trust: eight lessons from EdgeQuant.
How the project matured from fixing bugs to earning the right to be believed.
Anyone can ship something that works on day one. The hard problem is keeping it trustworthy on day one hundred, and knowing, honestly, when it isn’t.
EdgeQuant started as a trading system and matured into something more useful: a discipline for building AI that has to earn its own credibility. Each lesson below is a moment where the system quietly lied, or almost did, and what changed as a result.
The real achievement was never another trading bot. It was building a system that continuously verifies itself, explains itself, and learns from its own mistakes, and a team habit of refusing to call anything ‘done’ until the running system agrees.
That is the actual product these lessons represent. Not the model. Not the trades. The engineering discipline of building something that can be trusted to keep working, and to tell the truth, when no one is watching.
EdgeQuant continuously validates predictions against outcomes, monitors production health, evaluates decisions after the fact, detects failures the moment they surface, and only allows an improvement into production once historical replay confirms it would have made the system better.
The process that made the platform trustworthy.
Building EdgeQuant taught me that AI does not remove the need for engineering discipline. It amplifies it.
As the platform grew from a small prototype into a production system with multiple autonomous agents, trading engines, governance workflows, and continuous learning, success depended less on the language model and more on the engineering process wrapped around it.
Over time I developed a repeatable workflow that governed every meaningful change.
Never trust code that hasn’t executed.
A successful build, a clean typecheck, or an HTTP 200 response never counted as proof. Every meaningful feature had to execute against real runtime data before being accepted. Production behaviour always outweighed code review.
PASS means runtime evidence — not confidence.
PASS never meant the implementation looked correct. PASS required measurable proof: runtime execution, database writes, historical replay, prediction evaluation, agent execution, health verification, and business outcome validation. Only then was a phase considered complete.
The prompt became part of the architecture.
One of the biggest surprises was discovering that prompt engineering became an engineering discipline in its own right. Generic prompts consistently produced unnecessary code changes, repeated mistakes, architecture drift, and wasted tokens. As EdgeQuant evolved, prompts became structured specifications defining business objective, scope, assumptions, runtime validation, architectural constraints, and stop conditions. The prompt became part of the engineering process rather than simply a request for code.
Small validated loops outperform large AI-generated changes.
Rather than asking AI to solve large problems, every implementation followed the same disciplined workflow. Keeping each change inside a closed validation loop dramatically reduced regressions and let the platform scale without accumulating quiet debt.
EdgeQuant ultimately became more than a trading platform. It became an experiment in how AI-assisted software should be built.
The biggest lesson wasn’t how to generate code faster. It was how to build systems that continuously verify themselves, explain their behaviour, learn from outcomes, and refuse to declare success until the running software proves it.
That engineering discipline is the part of the project I’m most proud of, and the practice I’ll carry into every AI product I build.