A research prototype taxonomy document gives software engineers and product managers the context, interfaces, architecture, and business purpose they need to take over a project.
2
A separate Python monorepo holds isolated ML microservices with consistent layers, deployment tooling, tests, and documentation.
3
A decomposition and pull request review plan breaks a large prototype into slices that the right subject matter experts can review asynchronously.
Summary
Vaidas Razgaitis describes the handoff between ML researchers who build novel prototypes and software engineers who turn those prototypes into production features. He treats the problem as one of systems and process. His team uses a research prototype taxonomy document to explain domain concepts, business goals, type contracts, persistence, architecture, and the planned merge. A separate Python monorepo contains isolated ML microservices, each with API, business-logic, and data layers, plus common build, test, deployment, and documentation patterns. The final step is to decompose a proven prototype into a dependency-aware stack of pull requests, then involve specialists in reviewing the slices relevant to them. Razgaitis closes with diagnostic questions about whether work is easy to assign, whether the repository has clear places and patterns for new code, and whether teams can estimate delivery and identify reviewers.
The handoff between researchers and software engineers is a systems and process problem
Higharc's labs team explores computer vision, reasoning agents, custom transformers, and diffusion models for home building. The software engineers who need to productionize this work understand production code but may not know current computer vision or LLM training methods. Researchers understand recent papers and can create novel features, but often have less experience with production APIs. Vaidas frames the transition as a baton pass that needs an explicit process rather than an informal handoff.
A research prototype needs a written taxonomy document before the handoff
Higharc requires a research prototype taxonomy document for each prototype. It is based on the technical design documents or RFCs used by software engineering teams, with additions for machine learning. The document is written in Notion, although Vaidas says any written format can work. Its purpose is to make the prototype understandable to software engineers and product managers who will join the project after the research work has been done.
Domain context and business purpose prevent avoidable confusion
The document starts by explaining domain-specific language and data representations. In architectural home building, that might include a party diagram, a graph describing circulation through a home, embedding models, or latent-space representations. Vaidas suggests imagining a software engineer newly hired from JP Morgan and listing what that person needs to understand before starting. The document also states why solving the problem matters and what value the ML tool is expected to provide.
The prototype document records interfaces, storage, architecture, and the merge plan
The remaining sections cover type safety, persistence, system architecture, and decomposition. The team documents the type contract between the core product repository and the ML repository, including how shared types stay in sync. Researchers map how far they got in the persistence layer, while software engineers can take over deeper database work later. The document also describes workflows, workflow chains, external LLM calls, and the planned way to merge and decompose the prototype.
A separate Python monorepo gives each research effort an isolated production boundary
Higharc keeps its AI and ML code in a repository separate from the core product repository. The monorepo contains cleanly isolated, decoupled microservices. Vaidas describes a roughly one-to-one relationship between a researcher and a microservice, using data-driven entity prediction as an example of a custom transformer that can evolve independently. A gateway receives requests from the web application and routes them to the appropriate service within a Docker Bridge network.
Consistent service layers and repository tooling make new projects easier to stand up
Each microservice follows a simple layered structure with an API layer, business logic, and data layer. Business logic may call foundation models or load the team's own model weights in CI/CD. Controllers wrap that logic, and API routers expose it through FastAPI applications. The repository also contains metadata, build instructions, Dockerfiles, dependency files, Poetry or UV lock files, GitHub Actions, automated tests, linting, formatting, and type checks. Jupyter notebooks running on Modal support GPU work and studies.
Prototype decomposition should follow dependencies and review ownership
The final handoff step is a design problem: a large, monolithic research prototype must be divided into production-sized pieces. Vaidas's team studies the axes for slicing the project and the resulting dependency graph. They use Graphite stack diffs to create a sequence of pull requests. This lets one person work on a later PR while a domain specialist reviews an earlier one. Once the slices are clear, the team can ask the right subject matter experts to review each part.
The handoff process can be diagnosed through assignment, repository, and delivery questions
Vaidas proposes checking whether product people, software engineers, and AI engineers can immediately see where to focus and which tasks to take. Teams should also ask whether the repository has clear places, templates, and patterns for new code, or whether old abstractions are getting in the way. Finally, they should check whether they can estimate delivery dates and identify the right reviewers during decomposition. Problems in those areas point to weaknesses in coordination or in the codebase.
"We have a separate repository from our core product repo and this is all Python based, right? It's all AI ML stuff and it's basically a mono repo of cleanly isolated and fully decoupled microservices."06:46
Who should watch
Your ML researchers produce promising prototypes, but software engineers struggle to understand the domain assumptions and the intended handoff.
You maintain several ML services and need repeatable repository structure, shared interfaces, and production tooling for new research projects.
Delivery estimates and code review ownership become unclear when a large prototype reaches the engineering team.
