Three levers for getting research into production: a handoff doc, a repo skeleton, and stacked-diff decomposition
Research to Reality: Bringing Frontier ML Research to Production - Vaidas Razgaitis, Higharc · Vaidas Razgaitis
15 min total·Actually worth watching closely: ~4 min·3 must-watch clips
- 0:01 – 1:35Skim
Why this company ends up using every kind of AI
After a quick introduction he goes straight to the business context: Higharc's home building product has to both read drawings and reason about space, so it pulls in computer vision, reasoning agents, custom transformers and diffusion models — including scanning hand-sketched floor plans and parsing them into the internal data model.
His methodology comes from a real product running four classes of models at once, not from generic agile preaching.
This stretch is illustrated with the tech stack and product scenarios; a glance to establish context is enough, since the details all come back later.▶ Jump to 0:01Speaker · Vaidas Razgaitis - 1:35 – 3:55Listen
The real bottleneck is a two-way skills gap
He traces the failure to land research back to both sides missing the other's craft: engineers can write production-grade code but do not know the methodology behind vision models or training your own LLMs, while researchers keep up with the latest papers but have never owned an API they had to maintain.
A failed handoff is an organizational and process problem, not one side being weak — so do not expect hiring to fix it.
It is a spoken argument throughout, with the screen basically parked on a title slide; fine to listen to while doing something else.▶ Jump to 1:35Speaker · Vaidas Razgaitis - 3:55 – 7:04Listen
The Research Prototype Taxonomy document: the first gate in the handoff
He names the three levers — make research legible, make the repo ready to receive it, make the prototype decomposable — and opens the first: every prototype must produce a document, essentially a technical design document with ML twists. Domain context and data representations come first, then the business goal, followed by the cross-repo type contract, the state of persistence, and the system architecture.
The bar for the document is "a software engineer we just hired from JP Morgan can follow it," and the persistence section is the best first entry point for a software engineer joining the project.
It is a section-by-section walk through the template with nothing on screen beyond what he says; listen and copy the section headings down as your own template.▶ Jump to 3:55Speaker · Vaidas Razgaitis - 7:04 – 8:50Skim
A separate Python mono repo behind a gateway
The ML code is pulled out of the core product into its own Python mono repo of fully decoupled microservices, roughly one per researcher. All of them share a single Docker bridge network, every outside request is guarded by a gateway, and clients never call a service directly.
One service per researcher plus a single gateway lets researchers iterate freely on internals without disturbing the product side.
The whole stretch is built around one topology diagram; reading it fixes the service–gateway–web client call directions in one go, far faster than following the narration.▶ Jump to 7:04Speaker · Vaidas Razgaitis - 8:50 – 11:00Skim
How one service is layered, and what the repo shares underneath
He opens up a single microservice: business logic at the services layer (calling external foundation models or pulling in the team's own weights in CI/CD), wrapped in controllers and then routers, exposed as a standalone FastAPI application, with build metadata and a Dockerfile at the root. Then three production services are shown side by side with near-identical shapes, sharing one set of GitHub Actions, Jupyter notebooks running on Modal for GPU compute, and CLI tooling.
Consistent structure plus cleanly documented specs lets AI agents navigate the repositories on their own — an accelerator handed to the researchers.
The screen shows directory trees and the layering; reading level by level beats listening line by line, and the three-services-side-by-side slide is worth pausing on for a few seconds.▶ Jump to 8:50Speaker · Vaidas Razgaitis - 11:00 – 13:10Skim
Treat decomposition as a design problem, review with stacked PRs
The third lever: once a prototype is proven out, first work out what axes to slice and dice the monolith on and what the dependency graph looks like, then land it as a stack of PRs with Graphite's stacked diffs — keep pushing at the top of the stack while the PRs below get routed, slice by slice, to the matching domain specialists across the organization.
The layers and type contracts worked out in the document directly determine how you slice it; this is the step where writing that document pays off.
There are dependency-graph and PR-stack visuals; reading them is the fastest way to grasp the slicing, while the rules for assigning reviewers are worth listening for.▶ Jump to 11:00Speaker · Vaidas Razgaitis - 13:10 – 14:08Listen
The three levers as one continuous chain
He gathers the three threads back up: prototype document, repo structure, decomposition and review form one continuous chain, and a missing link makes the next one far more expensive.
The three levers work in series — adopting just one is close to adopting none.
A purely spoken wrap-up with no new visuals; listening is enough.▶ Jump to 13:10Speaker · Vaidas Razgaitis - 14:08 – 14:56Listen
Diagnostic signals: how to tell which link is broken
Three symptoms you can check yourself: people joining a research project do not know what to focus on, which means the document link needs rebuilding; new code has no obvious home, there is no template to mimic, and you are always fighting old abstractions, which means the code base can no longer carry it; and if at the decomposition stage you cannot say who should review, the problem is actually further upstream, in how the research is coordinated or in the repository hosting it.
These three symptoms are the best thing to take away from the talk — you can score your own team against them immediately.
A closing spoken checklist with nothing extra on screen; write the three down as you listen.▶ Jump to 14:08Speaker · Vaidas Razgaitis