A talk by Vaidas Razgaitis (Senior Research Engineer at Higharc) presenting three tactical tips for speeding up how R&D teams turn novel frontier ML research into customer-ready, production-grade features. # Channel Identity Observations — Research to Reality: Bringing Frontier ML Research to Production ## Video Identity Overview - **Speaker**: Vaidas Razgaitis (introduced in title; self-introduces as "Vitis"), **Senior Research Engineer** at **Higharc** (spoken as "Hyark"), on the **labs team** — the company's "research and development arm." - **Format**: A single-speaker technical talk/presentation (conference- or meetup-style), including references to slides ("that video," "this slide," "some images of..."). ## Explicit Self-Description Evidence - **Creator's stated role**: > "I'm a senior research engineer at Hyark on our labs team... our research and development arm where we have machine learning researchers who kind of explore the frontier of AI/ML... and figure out ways to apply it to home building." - **Company domain**: Home building / spatial reasoning; the talk frames Higharc's ML needs as unusually broad: "computer vision to scan hand-sketched floor plans," "reasoning agents," "custom transformers," "diffusion models for image gen." ## Claimed Scope of the Content - The talk addresses a **specific engineering problem**: the "baton pass" handoff between ML researchers and production software engineers — > "how do we facilitate that and how do we do it productively?" - Three stated focus areas: 1. **Research legibility** — the "research prototype taxonomy document" (analogous to a technical design doc) 2. **Code structure** — a Python **monorepo** of "cleanly isolated and fully decoupled microservices" 3. **Decomposition and PR review plan** — using Graphite stacked diffs and subject-matter-expert review ## Observable Presentation Patterns - **Practitioner case-study style**: Concrete internal tooling and processes are named (Notion for docs, FastAPI, Docker, Poetry/UV, GitHub Actions, Modal for GPU compute, Graphite for stacked PRs) — indicating a **first-party production experience** framing rather than theory. - **Diagnostic/checklist framing**: Closing section offers self-assessment questions ("is it obvious where they should concentrate their efforts?", "are you able to consistently estimate the timelines...") — a coaching orientation toward teams facing the same problem. - **Audience addressed**: Engineering and ML practitioners — evidenced by assumed familiarity with concepts like "request for comment," "stack diffs," "type safety," "persistence layer," and CICD, plus the closing: > "if you made it this whole way, you're probably interested in that stuff, too. And I would love to compare notes and trade ideas anytime." - **Community-engagement signal**: Explicit invitation to "compare notes and trade ideas anytime" suggests the speaker positions himself as an exchangeable peer in a practitioner community. - **External reference**: Cites "a blog from the pragmatic engineer" on technical design documents — grounding advice in external software-engineering discourse. ## Notable Boundary Evidence - The speaker deliberately withholds some content: > "even some top secret topics that I can't reveal here" — indicating selective disclosure about Higharc's internal work. - The talk mixes **personal opinion** with team practice ("we really like Graphite," "I like to say kind of picture a software engineer who just we hired from JP Morgan"). ## Audience & Scope Summary - **Intended audience**: ML researchers, AI engineers, platform/infrastructure engineers, and engineering leaders working on productizing ML research. - **Claimed scope**: Practical systems-and-process guidance for moving ML prototypes into production, grounded in Higharc's home-building ML context. - **Channel presentation implication** (observable, not inferred): The video presents the creator as a hands-on practitioner sharing internal engineering practices — but no channel-wide claims (e.g., about the channel itself) appear in this material; no curated metadata was supplied. # Delivery Observation: Research to Reality (Vaidas Razgaitis, Higharc) ## Tone & Register - **Conversational, informal technical talk**: hedging fillers ("uh," "um," "you know," "kind of," "basically") appear throughout. - **Friendly, low-pressure close**: ends with an invitation — "I would love to compare notes uh and trade ideas anytime." - Direct audience address at the end: "if you made it this whole way, you're probably interested in that stuff, too." ## Recurring Verbal Habits - **"Kind of" as an extremely frequent softener**: "machine learning researchers who kind of explore the frontier," "kind of a systems and process problem," "kind of that research project taxonomy document." - **"Basically" as a summarizing/grounding word**: "that's basically our research and development arm," "it's basically a mono repo," "that's basically it for our for our mono repo." - **Repeated self-corrections and restarts**: "this this handoff, this this baton pass"; "for our for our mono repo" — suggests spoken, unscripted delivery. - **"Right?" as a check-in**: "mapping out the business goal, right?"; "a pretty simple layered architecture, right?" ## Teaching / Structural Habits - **Explicit enumeration of three focus areas**, stated upfront and revisited: 1. "research legibility" 2. "how to structure your code base" 3. "the decomposition and PR review plan" - **Signposting transitions**: "So, taking a look at the first step," "So, going back to these kind of three levers we can pull," "So, that's basically it." - **Analogy-driven explanation**: - "this this baton pass how do we facilitate that" - "I like to say kind of picture a software engineer who just we just hired from JP Morgan" - Microservice structure as an "anatomical arrangement" with "consistent skeletal backbones" - **Concrete named examples over abstractions**: Notion, FastAPI, Docker, Poetry/UV, Modal, Graphite, GitHub Actions, "the pragmatic engineer" blog. ## Audience Accommodation - Frames concepts for both software engineers and ML researchers: "they are likely not familiar with the methodology and research... they have not really worked as software engineers." - Uses diagnostic questions as a teaching device in the wrap-up: "is it obvious where they should concentrate their efforts?"; "is it clear where these buckets lie to put in new code?" ## Uncertainty Notes - Transcript may misrender the speaker's and company's names ("Vitis," "Hyark") — likely transcription artifacts, not verifiable here. - Timestamps are fragment numbers, not verified time positions; delivery pace/pauses cannot be confirmed beyond the fillers present in the text. # Position Record: "Research to Reality: Bringing Frontier ML Research to Production" **Speaker:** Vaidas Razgaitis, Senior Research Engineer, Higharc (Labs team). All positions below are his, expressed in this talk. ## Context & Problem Framing - Higharc's **Labs team** is the R&D arm applying frontier AI/ML to **home building** and **spatial reasoning**. - Because the product is multidisciplinary, they use a broad AI stack: **computer vision** (parsing hand-sketched floor plans into an internal data model), **reasoning agents**, **custom transformers**, and **diffusion models** for image generation. - Core problem: a **handoff ("baton pass")** between two groups: - **Software/platform/backend engineers**: strong at production-grade code, but unfamiliar with ML research methodology. - **ML researchers**: current on papers and creative at prototyping, but typically lack experience owning production-grade APIs. - Framing: "we look at this basically as a **systems and process problem**," addressed via three levers. ## Lever 1: Research Legibility - Analogous to technical design documents/specs (references a Pragmatic Engineer blog on alignment via design docs as teams scale). - Higharc requires a **Research Prototype Taxonomy (RPT) document** — a technical design doc "with some specific twists" for ML: 1. **Domain context** — novel data representations (bubble/party diagrams, circulation graphs, embeddings, latent spaces). Test: "picture a software engineer who we just hired from JP Morgan." 2. **Business goal** — why the problem matters. 3. **Type safety** — the type contract between the core product repo and the ML repo; how types stay in sync. 4. **Persistence layer** — deliberately minimally specified by researchers; "probably best not to have our researcher spend too much time" here; a good first entry point for software engineering help. 5. **System architecture** — workflows, chaining, external LLM calls; the prototype's "taxonomy/anatomy." 6. **Merge/decomposition plan** — how the prototype will be split up. - Tooling: Notion, though "any written document will work." ## Lever 2: Codebase Structure (Mono Repo) - Separate **Python mono repo** of "cleanly isolated and fully decoupled **microservices**" from the core product repo. - Roughly a **one-to-one researcher-to-microservice ratio** — he states "we find that works really well." - A **gateway** guards requests; web clients call the gateway, which routes to microservices, all on one Docker Bridge network. - Each microservice: simple **layered architecture** (API layer → controllers → business logic/services → data layer), exposed via **FastAPI**, standalone application. - Services may call external foundation models or pull in custom model weights via CI/CD. - Repos have consistent skeletal backbones: metadata, Dockerfile, dependencies, Poetry/UV lock files, plus "cleanly documented specs so that agents can navigate these repositories" to accelerate ML researchers. - Supporting tooling: GitHub Actions for build/deploy, automated tests, linting, formatting, type checks; Jupyter notebooks on **Modal** for GPU compute; a CLI. All of this exists to "support our ML engineers in bundling up these microservices." ## Lever 3: Decomposition & PR Review - Treated as a **design problem**: how to "slice and dice a large research monolithic prototype," including mapping the dependency graph. - Uses **Graphite** for **stacked diffs**; valued for **asynchronous review** (working on one PR while a specialist reviews another). - Enables tapping **subject matter experts** on tightly decomposed PR slices. - The RPT (Lever 1) informs the decomposition strategy — noted overlap between the two. ## Diagnostic Frameworks (Self-Assessment) - **Research legibility**: Is it obvious where product/software/AI engineers should concentrate? Is it clear which tasks to pluck off? Ambiguity signals process needs revisiting. - **Code repository**: Is it clear where new code goes? Are there templates/patterns to mimic? Or are you "fighting old abstractions" — a sign you've outgrown the codebase/architecture? - **Decomposition**: Can you consistently estimate timelines/delivery dates? Is it clear which SMEs to tap? Problems here "probably points to the stream issues" in either the handoff coordination or the hosting codebase. ## Closing Position - Razgaitis states he enjoys finding ways to speed up moving research concepts into production and invites comparison of notes and trading ideas. # Observation Document: Speaker Roles & Provenance ## Video Metadata - **Title:** Research to Reality: Bringing Frontier ML Research to Production - Vaidas Razgaitis, Higharc - **Video ID:** `01a15ca8-e04f-7378-8475-3f5e065f6b01` - **Curated metadata:** Not supplied beyond title. ## Speaker Inventory - **Primary speaker:** "Vaidas Razgaitis" (per title), self-introduced as **"Vitis"** — **Senior Research Engineer at "Hyark" (phonetic; presumably Higharc per title)**, on the **Labs team** (research and development arm). - **Role:** Creator / sole presenter. No guests, narrators, or other speakers identified. - Speaker name discrepancy: transcript self-introduction ("Vitis") vs. title attribution ("Vaidas Razgaitis"); company name spoken as "Hyark" vs. "Higharc" in title — uncertainty noted. ## Referenced Sources & Third-Party Claims - **The Pragmatic Engineer blog article** on software engineering teams scaling and the importance of technical design documents / RFCs — cited by the speaker as an inspiration for the "research prototype taxonomy document." Specific article title/URL not given. - Mentioned tools/technologies (as claims by speaker, not endorsements): **Notion**, **Graphite** (stacked PRs / asynchronous review), **Modal** (GPU compute for Jupyter notebooks), **FastAPI**, **Docker**, **GitHub Actions**, **Poetry / UV**, **JP Morgan** (hypothetical new-hire example). - **Withheld content:** Speaker explicitly declines to share some topics — *"even some top secret topics that I can't reveal here."* ## Promotional Segments - No explicit promotional segments flagged in the transcript. The talk is an internal-process/case-study presentation about the speaker's employer's practices. ## Comment Availability - Not indicated — no curated metadata supplied; comment availability **unknown**. ## Provenance Notes - All claims originate from the single speaker; no cited third-party data, papers, or quotes from other individuals appear in the transcript. - Transcript references an unnamed accompanying **video/demo** ("hopefully that video gives you some idea") — content unavailable from this transcript. Hey, I'm Vitis and I'm a senior research engineer at Hyark on our labs team. So, at Hyark our labs team is basically our research and development arm where we have machine learning researchers who kind of explore the frontier of AI/ML uh and figure out ways to apply it to home building. Now, because we're in home building and we're in spatial reasoning, uh we pretty much end up needing to use a lot of what's out there in AI. So, computer vision to scan hand-sketched floor plans and parse them into our internal data model, \>\> \[music\] \>\> um reasoning agents to kind of carry the user through these agentic experiences, we have custom transformers, uh we use diffusion models for image gen, uh and basically a lot of kind of what's out there in AI/ML uh we end up needing to use because of the kind of multidisciplinary nature of our product. So, hopefully that video gives you some idea of the research areas that we focus on that I've mapped out here. And that kind of leads us to uh the problem, which is in this in this challenge of getting frontier research into production, uh we need to start working with software engineers, let's say platform engineers, infrastructure engineers, back-end engineers who are very familiar with building robust and production-grade code, but are likely not familiar with the methodology and research in computer vision, in training your own LLMs, uh and even some top secret uh topics that I can't reveal here. Now, you kind of have the flip side problem with our uh ML researchers who are very up-to-date with the latest papers and can uh pull together these concepts in novel and creative ways to develop new features, but they have not really worked as software engineers typically where they've been responsible for production grade APIs. So, that's kind of what I want to get into is this this handoff, this this baton pass how do we facilitate that and how do we do it productively? And we look at this basically as a systems and process problem and I want to kind of zero in on three main focus areas that you can use to improve this the velocity of teams that that are bringing research into production. So, the first thing we'll look at is research legibility. So, let's say you have a ML researcher has produced a prototype concept. How can they map that out and make it digestible and understandable for these different software engineers and product managers who are going to be jumping into the project. The second is how to structure your code base. So, we use a mono repo. How do you arrange your code and modularize it so that it's ready to receive these new prototype concepts and turn them around and stand them up quickly. And then the third thing we'll look at is basically, you know, making the jump from a mapped out proven out research prototype that's going to be going into this repo. How do you decompose that prototype and stand it up on best practices in software engineering. So, taking a look at the first step, there's a really good article that I that I want to link a blog from the the pragmatic engineer where he talks about software engineering teams as they grow and start to scale how important it is to write out technical design documents, request for comment, whatever you want to call it, specifications before building software as a way to align teams. So, we have a very analogous document um that we require from all research prototypes that we call the research prototype taxonomy document. So, it's really just a technical design document from software engineering uh with some specific twists uh that um make it more digestible given its its nature in machine learning. So, the first thing in that document, we use notion for this, but obviously any written document will work, is that we start with the kind of domain context and like what are the domain specific you know, we're in the architectural domain and home building. So, what are these kind of novel ways to represent data? Maybe it's a party diagram, maybe it's a graph to to represent the kind of circulation graph through a home, maybe it's embedding models or latent space representations. I like to say kind of picture a software engineer who just we just hired from JP Morgan. What are the kind of uh specific lingos and and data representations that they might need to know before jumping into this project. The second is kind of mapping out the business goal, right? What's the why does solving this problem matter and what's the value in this ML tool? And then the four uh remaining parts of this document are pretty kind of conventional software engineering principles you might see in a TDD. So, the type safety, so we'll see later what our machine learning repo looks like, but what is the type contract between our core product repository and this machine learning repo? How are those types shared and how do they stay in sync? Um then kind of mapping out the the persistence layer. Is there a database? Uh this is an area where uh we think it's probably best not to have our researcher spend too much time in the persistence layer and just map out how far they got and this is a great first entry point once we start bringing in software engineering help on the project. Uh then kind of mapping out the the overall system architecture. Um is this a workflow? Is this a chaining of workflows? Are there external LLM calls? Like what is the anatomy? What is the kind of taxonomy of this research prototype? And lastly, how are we going to merge this? How are we going to decompose it? Um and we'll get into that more uh later as well. So, going back to these kind of three levers we can pull, the first is kind of that research project taxonomy document. Uh the second I want to get into are how we structured our code and how we serve our existing uh features. So, we basically have a a separate um repository from our core product repo and this is uh all Python based, right? It's all AI ML stuff and it's basically a mono repo of uh cleanly isolated and fully decoupled microservices. And so, let's say data-driven entity prediction is our custom transformer model. So, that is able to up to um kind of grow and be iterated on and be fully decoupled from a different research initiative and it's pretty much a one-to-one researcher to microservice ratio. So, we find that works really well. We have a kind of gateway that that guards requests um and it's all in one Docker Bridge network. So, the core um consumers our clients in our in our web application make kind of API calls to this gateway which then routes them to the appropriate microservice. Now, uh looking a bit closer at these uh individual microservices, uh we tend to build them in a pretty simple layered architecture, right? There's an API layer, the business logic and the data layer. And then we tend to have like some really um really cleanly documented specs uh so that agents can navigate these repositories and help accelerate our ML researchers as much as possible. So, yeah, kind of taking a another way to look at this layered architecture, we have kind of the core business logic at the services layer. Uh that might, you know, make external uh LLM calls to to foundation models or we might need to pull in our own uh machine learning model weights in CICD. Then we wrap that business logic with controllers. Um then we put API routers around those and expose them in FastAPI applications. And each of those microservices is a standalone application. And like I said in the last slide, it's not really the client that makes a direct call to this microservice. It kind of goes to that uh gateway first which routes it to the appropriate microservice. And then within each of those microservices um in the root in the root directory, we have essentially metadata, build instructions, a Dockerfile on how to how to build this application, uh the the kind of project dependencies, and then poetry or or UV uh lock files um as needed. And then so I'd like to kind of map out this um anatomical arrangement of our kind of three microservices that we have in production. And we can kind of see these these trends and and consistent skeletal backbones of these projects. Uh and it's very easy to map them out and make sure that they're growing um along best practices in software engineering. So, that's basically it for our for our mono repo. We have these kind of microservices and then uh sharing basically like underneath all of that in the repository, we have some GitHub actions to to build and deploy our automated test suites and kind of linting, formatting, and type checks, all the stuff you'd you'd kind of expect. Uh we have some Jupyter notebooks that run on on Modal for GPU compute, um as well as some additional ML studies, but really the way we look at it is we have this kind of tooling layer and even this kind of fun CLI, but these all just support our ML engineers in bundling up these microservices that we uh serve in production. So, that's kind of the the RPT is the is the handoff document between an ML researcher and additional software engineering uh talent. The mono repo is is where that um research project is ultimately going. And then the only remaining step is, well, how do we get there, right? How do we jump from one to two? And the third lever I want to talk about is the kind of decomposition uh and PR review plan. Uh and we look at that really as a design problem where we need to kind of um figure out how to slice and dice a a large research uh monolithic prototype. So, here are just some images of of um an uh platform-wide agent feature where you know, we really studied what axes to slice uh and dice these projects up on, what that dependency graph would look like. And then we use Graphite um for kind of stack diffs to then uh decompose these large monolithic prototypes that have been proven out um and then get the right eyes on on review to make sure that these are ready for production. Uh we really like Graphite because it allows for asynchronous review, right? I could be working on a PR all the way up here while a domain specialist is still reviewing a different PR. And once we've kind of decomposed these PRs uh thoughtfully, we can start tapping uh subject matter experts throughout the organization on the specific slices or tightly uh decomposed PRs uh that need to look at. And so again, there's there's a lot of overlap between this initial research project uh taxonomy document where once we've mapped out these layers, these the architecture, what kind of persistence there is in the types, that tends to inform uh your decomposition strategy on how to bring it into the into the mono repo. So, to wrap things up, I want to revisit these kind of three focus areas that you can use to evaluate how well your team is bringing research into production. And I want to talk about kind of some some diagnostic frameworks to understand if you need to spend a bit more time and attention in any of these three. So, in the first step with your research legibility, as your team starts to staff research initiatives with product people, with software engineers, with AI engineers, is it obvious where they should concentrate their efforts? And is it clear uh what kind of tasks they need to pluck off to bring this prototype into production? If there's ambiguity in there, you may need to spend some time revisiting this process. In step two, your code repository. As you start getting ready to bring prototypes into your production grade code base, is it clear where these buckets lie to put in new code? Are there templates and existing frameworks and patterns that you can mimic? Or is it possible that maybe you've started to outgrow that code base and that system architecture, and every time you bring in new research concepts, you're fighting these old abstractions and having headaches from limitations of your repository. And then lastly, in the decomposition phase, are you able to consistently estimate the timelines and delivery dates for moving research concepts into your repository? Is it clear which subject matter experts you should tap for review and for productionizing this research? Uh and if you're having issues here, it probably points to the stream issues, either in uh how this research is being coordinated and handing off, or perhaps the code base that's hosting it. Uh anyway, that's about all I've got. I hope this is helpful. I love uh thinking about ways how our team can speed up how quickly we can bring research concepts into production. And if you made it this whole way, you're probably interested in that stuff, too. And I would love to compare notes uh and trade ideas anytime.