FOUNDING ENGINEER: AN AI RESEARCH PLATFORM, EMPTY REPO TO TEN ENGINEERS
Founding Engineer / Technical Lead - Data & AI Platform Architecture
Client: an AI research platform for public-market investors
Engagement: contract, 16 months · first commit through handoff
Stack: Python · TypeScript · AWS CDK · Kafka · Airflow · document, relational and columnar stores · LLM agent tooling and evals
Sole engineer at the first commit. I set the architecture, the data contract and the review standard, then held that bar as the team grew to around ten engineers. Features I built end to end are in the product today, and the tool layer I authored became the platform's primary AI tool surface.
Where it started, where it ended
| At the start | At handoff | |
|---|---|---|
| Data sources | none - empty repository | one vendor lane I owned from API to contract, then the shared pattern later sources were built on by other engineers |
| Adding a data source | a bespoke script per source | a pattern a new hire can follow |
| Core architecture | did not exist | CDK app, job registry and orchestration shapes from month one - unchanged at handoff |
| Engineering team | 1 (me) | around 10 engineers, on patterns I established and they extended |
| Data architecture | none | one event-driven ingestion contract feeding three production stores - document, relational, columnar |
| Correctness of AI-generated artefacts | did not exist | publication blocked by invariant checks, including one against the source filing |
Scope: first production versions of the platform's AI research features, three of them customer-facing, plus the tool layer the platform's AI agents run on.
The client retained me for four things: more data sources, new features, faster data onboarding, and a review standard for the team's work.
Three systems I owned end to end
1. Data architecture - getting the data in, and keeping it trustworthy
Every feature sits on third-party financial data. Late, wrong, or misattributed data is worse than no data, so the ingestion contract has to make correctness provable rather than likely.
What I built. The ingestion lane for the platform's fundamentals data, owned from the vendor API to the downstream contract: polling, company attribution, restatement handling, and a guarantee that AI workflows only fire once the data is provably durable and queryable. Event-driven, and the containment boundary is the point: vendor-shaped code stops at the ingestor, and every consumer downstream inherits one definition of ready.
That readiness barrier is the design decision I would defend: it fires not when the writes are acknowledged, but when the data reads back out of the store. Acknowledged-but-not-yet-visible is what lets a downstream pipeline generate confident output from a half-loaded company, and it is invisible to every check that only asks whether the write returned. I also planned a phased zero-downtime store migration and ran its first phases, including a full production backfill alongside live writers, with no data incident.
Proof point - the monitor that had no false positives to hide behind. I replaced fixed-threshold consumer-lag alerting with a relative measure, which is what lets it stay quiet through a legitimate backfill and still fire on a writer that has genuinely fallen behind. The tell it was built to catch is throughput shape: one writer pinned to a flat rate while the producer swings freely - a stuck consumer stalls, a pinned one is doing a network round-trip per message.
2. Auto-generated earnings diagrams - a customer-facing feature
The product renders a company's income statement as a flow diagram with written commentary - high value to buy-side users, and demanding to ship, because the output is generated, so correctness has to be enforced by construction rather than caught by review.
On pace. The work arrived as a goal rather than a design, and nine days later the page was serving real diagrams - design included, because splitting an LLM that proposes structure from a deterministic resolver that owns the arithmetic was my call inside that window, not a spec I was handed.
How it stays correct. Validators block publication, including a check against the source filing, because a diagram can balance perfectly against itself and still be built from the wrong inputs. The governing policy is judge a diagram against itself, never against the latest data - restatements mean disagreement with today's figures is expected, so only internal invariants may block. That distinction is what makes a gate trustworthy enough to stop a release rather than be routed around. I built the measurement before the fix, so the validators hold the line permanently rather than a one-time pass holding it once.
On cost. I rebuilt the commentary agent to cut its per-company cost - numeric work moved into pre-computed inputs, the static prompt kept in the provider's cache across a batch. Token usage confirmed the drop; dollar spend was never instrumented, which is the measurement I would insist on first if I ran this again.
3. Per-company KPI series - a customer-facing feature
Analysts want the handful of operating metrics that move this business - subscriber counts, units shipped, same-store sales - not a generic template, and the AI agents had been digging these out of a vendor taxonomy far too large to put in front of a model.
What I built. A pipeline that discovers, defines, computes and ranks the operating metrics for each company - charted in the research surface and exposed to the AI agents as a tool, over a taxonomy pruned to fit an agent's context so discovery cannot silently degrade without the degradation being visible.
Proof point. The design admitted a concurrency hazard: interleaved runs could leave a company's definitions standing with no values behind them. Rather than thread a run identifier through the fifteen places that would each have to remember it, I replaced the flag with a type that carries its own scope, so the omission becomes impossible to express. I documented the two cheaper designs I rejected, and accepted the residual cost explicitly: duplicate runs cost duplicate LLM spend, a cost problem rather than a correctness one.
How the team used me
- 245 pull-request reviews for colleagues.
- A written quality standard for the shared AI tool layer - a cost bar per call, and how each owner should improve, debug and evaluate their own tool. The bar: could a human verify this answer correct from the raw data the tools returned?
- The evaluation harness the team writes tool tests into. Each case declares what must appear in a correct answer; a judge model sees those criteria and not the agent's tool calls. I wrote the harness and the first suites; the team extended it well beyond what I wrote.
- Around forty issues scoped, filed and assigned to other engineers, and delivered by them.
- Onboarding material and work briefs for incoming engineers; four domains handed over with consumer inventories and handover notes.
- On-call in the final phase, plus the operator dashboards and monitoring behind it.
What I review for. I verify a claim by re-deriving it against production, never by reading the diff. Now that first-pass scrutiny is largely automated, the human's job moves to what a model will not converge on unprompted: whether a change does what was actually asked rather than what the prompt drifted into, whether it is three times the size the problem needed, and whether it will still be right in six months.
The leverage story
This is the part I would argue hardest for. The first data integrations were one bespoke Python script per source on a timer - including the ones I wrote. I moved that onto Airflow, then spent the following year turning it into reusable patterns rather than one-off pipelines - a shared job registry, consistent orchestration shapes, common conventions for logging, retries and configuration.
- New data sources stopped being design problems. Later integrations, built by other engineers, follow the shapes I established.
- Six components I originated are now maintained by other people.
- Repetition became a throughput argument, not a style preference. Consistent patterns are what junior engineers copy from - and what their AI coding tools copy from.
On how I work. I moved to agent-assisted development early and deliberately. When the first draft is not yours, quality is decided by the design you aim the agent at and the verification that the result is true rather than merely green.
Judgment, including where it failed
Identity never stays cheap - I found that out late. I keyed on a vendor's symbol because it was already there and it was unique the day I looked. A symbol like that is mutable and non-unique, and by the time that mattered it had spread into every store, topic and join built after it - so the fix I could have shipped in two days had become a multi-week unwind, run while live writers kept producing. I own that call. The continuous check on entity resolution that would have caught it was an afternoon's work. I now treat entity resolution as week-one work rather than a later hardening pass.
I distrust a green check. The failure modes I hunt: a gate that passes on offsetting errors; a task that exits successfully having written nothing, which an orchestrator reads as success; a parameter that reports success while silently discarding itself. The false signal is the real finding. My first question of any check is: what input makes this go red? If nobody can answer, it isn't a check. The same applies to AI review - fast, tireless, and wrong in one particular way: it checks that a thing is consistent with itself.
I measure before building, and cancel work that measurement proves unnecessary. A backlog of proposed fixes, adjudicated case by case rather than in aggregate - most did not need the fix proposed for them. Two pipelines descoped after one conversation rather than two weeks of code.
I check the baseline before I trust the lift. Asked to evaluate a model that looked like a clear win, I added a stronger baseline; the apparent edge was mostly in the choice of comparison. A model that only beats a weak baseline has not been measured.
I got a failure mode backwards. An ingestion job kept wedging because it advanced its checkpoint only on a fully successful run; my fix was to advance it unconditionally. Review caught what I had not - advancing past a failed window would have silently dropped data that the source would not offer again. I had turned stuck and visible into advancing and quietly incomplete. I closed my own pull request.
References on request.