Research to Reality: Bringing Frontier ML Research to Production - Vaidas Razgaitis, Higharc

What was stored

cues

104

whisperx 104

chunks

27

from 104 cues

keyframes

35

kept of 40 captured

frames with text

35

682 lines read

chapters

0

from the source metadata

keyframe bytes

2.7 MB

word timings on 104 cues

Provenance

Frames, and what the machine read

• 

  0:09 #0 done8 line(s)

  shot 0·sharpness 598.5

  1. 回0.85
  2. AI ENGINEER WORLD'S FAIR 20261.00
  3. ONLINE TRACK1.00
  4. Research to Reality0.98
  5. Turning frontier ML research into real, shipped features.0.99
  6. Vaidas Razgaitis1.00
  7. Senic0.98
  8. ineer, Labs·Higharc0.99
• 

  0:24 #1 done4 line(s)

  shot 1·sharpness 272.7

  1. 回0.93
  2. 0:021.00
  3. 国0.99
  4. 中0.87
• 

  0:27 #2 done4 line(s)

  shot 2·sharpness 301.4

  1. 回0.88
  2. Higharc1.00
  3. This is Al for homebuilding.0.99
  4. Slide 2/180.98
• 

  0:30 #3 done8 line(s)

  shot 3·sharpness 672.9

  1. 日0.53
  2. Higharc Al0.99
  3. Higharc, please generate1.00
  4. this home with pricing,1.00
  5. renders, and build ready plans.1.00
  6. slide 2/180.91
  7. D ×0.58
  8. End presentation0.92
• 

  0:38 #4 done2 line(s)

  shot 4·sharpness 1188.3

  1. Higharc Al1.00
  2. Building data model..0.96
• 

  0:59 #5 done5 line(s)

  shot 5·sharpness 908.7

  1. Higharc Al0.98
  2. Show it to me in a0.98
  3. community.1.00
  4. Rendered home in a1.00
  5. community.1.00
• 

  1:04 #6 done5 line(s)

  shot 6·sharpness 740.8

  1. Higharc Al0.99
  2. How about spring?0.99
  3. 合合0.97
  4. Rendered home in spring.0.99
  5. Side 2/18 -0.85
• 

  1:14 #7 done26 line(s)

  shot 7·sharpness 1231.1

  1. Frontier Al / ML Research:0.96
  2. Researchers ≠ production engineers0.99
  3. Computer Vision1.00
  4. ML Engineer1.00
  5. up-to-date on papers / research0.99
  6. Computer Vision0.98
  7. Model training & fine-tuning0.99
  8. Generative Building1.00
  9. Evals & Observability0.97
  10. Production-grade code0.98
  11. Model (GBM)0.96
  12. Vector DBs & RAG1.00
  13. LLMs (tokenization, prompting, context management)0.99
  14. Agent building (ReAct, tool-use, workflows, multi-agent)0.99
  15. spatial intelligence1.00
  16. Model routing (fal.ai, OpenRouter)0.99
  17. Building robust non-deterministic features (testing &0.98
  18. fault-tolerance)1.00
  19. AI Engineer1.00
  20. Backend system design1.00
  21. Streaming architectures (SSE)1.00
  22. Reactive UIs1.00
  23. In-memory state management1.00
  24. ents1.00
  25. Full-stack SWE1.00
  26. End presentatio0.87
• 

  1:52 #8 done27 line(s)

  shot 8·sharpness 1224.8

  1. Frontier Al / ML Research:0.94
  2. Researchers ≠ production engineers0.99
  3. Computer Vision1.00
  4. ML Engineer1.00
  5. up-to-date on papers / research0.98
  6. Computer Vision1.00
  7. Model training & fine-tuning1.00
  8. Generative Building1.00
  9. Production-grade code0.98
  10. Evals & Observability0.98
  11. Model (GBM)1.00
  12. Vector DBs & RAG1.00
  13. LLMs (tokenization, prompting, context management)0.99
  14. Agent building (ReAct, tool-use, workflows, multi-agent)0.99
  15. spatial intelligence0.98
  16. Model routing (fal.ai, OpenRouter)0.99
  17. Building robust non-deterministic features (testing &1.00
  18. fault-tolerance)1.00
  19. AI Engineer1.00
  20. Backend system design0.97
  21. Streaming architectures (SSE)1.00
  22. Reactive UIs0.98
  23. In-memory state management1.00
  24. ing agents0.99
  25. Full-stack SWE1.00
  26. A & D × O0.52
  27. End presentatio0.99
• 

  2:21 #9 done2 line(s)

  shot 9·sharpness 498.8

  1. 回0.53
  2. Researchers ≠ production engineers0.98
• 

  2:45 #10 done23 line(s)

  shot 10·sharpness 977.3

  1. 回0.53
  2. THE THESIS1.00
  3. Getting research to reality is a1.00
  4. systems & process0.94
  5. problem.1.00
  6. 011.00
  7. 021.00
  8. 031.00
  9. Make research legible1.00
  10. A monorepo that can0.99
  11. Decomposition as a1.00
  12. receive new research1.00
  13. design problem1.00
  14. A handoff contract maps out a0.98
  15. Modularized code and templates1.00
  16. Prototype decomposition + review1.00
  17. project so an engineer can see the1.00
  18. that give every prototype a clean1.00
  19. needs to be planned so that giant1.00
  20. shan0.93
  21. ork1.00
  22. home1.00
  23. PRs ship without big-bang risk1.00
• 

  3:03 #11 skipped

  shot 11·duplicate of #10

• 

  3:36 #12 skipped

  shot 12·duplicate of #10

• 

  3:45 #13 done41 line(s)

  shot 13·sharpness 564.6

  1. Scaling Engineering Teams1.00
  2. via RFCs: WritingThings1.00
  3. Down1.00
  4. by GergnlyOrosz0.89
  5. Homme0.83
  6. I have recently been talking at small and mid-size companies, sharing1.00
  7. Nomaktuar0.57
  8. engineering best practices I see us use at Uber, which I would recommend0.99
  9. Popular Atticien0.84
  10. The Software Engineer's0.93
  11. Guadeboo0.63
  12. My Booka0.86
  13. the most raised eyebrows, as well the mos "aha!" moments is the one on0.99
  14. how the planning process for engineering has worked since the early0.99
  15. any tech company adopt as they are growing. The one topic that gets both0.99
  16. Eadsuends0.81
  17. years of Uber.0.99
  18. Reallng Lat0.75
  19. Ethicsstanment0.75
  20. When working at large comanies like Microsoft or smaller ones like0.98
  21. Writr a guest article0.86
  22. Seanagrs0.64
  23. imatngg0.50
  24. Now0.62
  25. Gontactmme0.86
  26. built the same thing as my team. Second, the tech and architecture debt1.00
  27. approach-wise and quality-wise.1.00
  28. Skyscanner, there have been two things related to planning that have0.99
  29. always bugged me. First, the lack of visibility on others building or having0.99
  30. accumulated due to different teams building things very differently, both0.99
  31. BSS.Fend0.79
  32. hlansky0.68
  33. What if I aid there is a way to tackle both these issues pretty well, using a0.98
  34. twitts0.65
  35. few simple steps? A word of warning, one of the steps will sound a little0.99
  36. crazy. Here they are:0.98
  37. Subscribe xia.omall0.76
  38. 1. Do planning before building something new. This can be in-person0.99
  39. S Subscribe in a prader0.86
  40. whiteboarding or just talking it through with the team members, as1.00
  41. long as you're all clear on how you will get things done.0.99
• 

  4:27 #14 done26 line(s)

  shot 14·sharpness 550.8

  1. LEVER 01 THE TEMPLATE0.95
  2. What an RPT forces you to answer1.00
  3. Domain context1.00
  4. Business goal1.00
  5. Type safety1.00
  6. Parti diagrams, masks, latent spaces0.98
  7. The consumplion model: headless0.98
  8. Input/output contracts and the guardrails0.98
  9. explained for a great SWE who knows0.99
  10. microservice. standalone agent, or0.98
  11. preventing client/server schema dift0.94
  12. nothing about homebuilding.0.99
  13. embedded Studio tool? It reorganizes the0.99
  14. whole build.0.96
  15. Persistence1.00
  16. Architecture1.00
  17. Decomposition1.00
  18. DBs, model weights, checkpoints — how0.98
  19. they're versioned and where they live.0.99
  20. Map to existing serving pattemns. Describe0.97
  21. only where you depart from them.0.99
  22. prototype into reviewable, mergeable0.98
  23. A roadmap for slicing a monolthic0.97
  24. modules.1.00
  25. training.0.95
  26. inference trade offs stay with speclalists.0.94
• 

  4:53 #15 done27 line(s)

  shot 15·sharpness 552.8

  1. 回0.72
  2. LEVER 01 THE TEMPLATE0.95
  3. What an RPT forces you to answer1.00
  4. Domain context1.00
  5. Business goal1.00
  6. Type safety1.00
  7. Parti diagrams, masks, latent spaces0.97
  8. The consumption model: headtess0.98
  9. Input/output contracts and the guardrails0.97
  10. nothing about homebulding.0.99
  11. explained for a great SWE who knows0.99
  12. microservice, standalone agent, or0.99
  13. embedded Studio tool? It reorganizes the0.99
  14. preventing client/server schema drit.0.87
  15. whole buld.1.00
  16. 41.00
  17. Persistence1.00
  18. Architecture1.00
  19. Decomposition1.00
  20. DBs, model weights, checkpoints — how0.97
  21. Map to existing serving pattems. Describe0.99
  22. A roadmap for slicing a monolithic0.98
  23. they're versioned and where they live.0.99
  24. only where you depart from them.0.96
  25. prototype into reviewable, mergeable0.99
  26. modules.1.00
  27. inference trade ofts stay with specialiats.0.93
• 

  5:23 #16 done28 line(s)

  shot 16·sharpness 554.6

  1. 回0.68
  2. LEVER 01 THE TEMPLATE0.97
  3. What an RPT forces you to answer1.00
  4. Domain context1.00
  5. Business goal1.00
  6. Type safety1.00
  7. Parti diagrams, masks, latent spaces0.94
  8. The consumption model: headless0.99
  9. Input/output contracts and the guardrails0.98
  10. explained for a great SWE who knows0.97
  11. microservice, standalone agent, or0.99
  12. preventing client/server schema drit.0.90
  13. nothing about homebulding.0.99
  14. embedded Studio tool? It reorganizes the0.99
  15. whole buld.0.95
  16. 41.00
  17. Persistence1.00
  18. Architecture1.00
  19. Decomposition1.00
  20. DBs, model weights, checkpoints — how0.98
  21. Map to existing serving pattems. Describe0.99
  22. A roadmap for slicing a monolthic0.98
  23. they're versioned and where they live.1.00
  24. only where you depart from them.0.98
  25. prototype into reviewable, mergeable1.00
  26. modules.1.00
  27. training.selection,0.94
  28. inference trade offs stay with apeclalists.0.91
• 

  6:03 #17 done28 line(s)

  shot 17·sharpness 554.2

  1. 日0.53
  2. LEVER 01 · THE TEMPLATE0.94
  3. What an RPT forces you to answer1.00
  4. Domain context1.00
  5. Business goal1.00
  6. Type safety1.00
  7. Parti diagrams, masks, latent spaces0.96
  8. The consumption model: headless0.98
  9. Input/output contracts and the guardrails0.99
  10. nothing about homebuilding.0.98
  11. explained for a great SWE who knows0.98
  12. microservice, standalone agent, or0.98
  13. embedded Studio tool? It reorganizes the1.00
  14. preventing client/server schema drift.0.99
  15. whole build.0.97
  16. Persistence1.00
  17. Architecture1.00
  18. Decomposition1.00
  19. DBs, model weights, checkpoints — how0.97
  20. Map to existing serving pattems. Describe1.00
  21. A roadmap for slicing a monolithic0.96
  22. they're versioned and where they live.0.99
  23. only where you depart fom them.0.99
  24. prototype into reviewable, mergeable0.99
  25. 41.00
  26. modules.1.00
  27. training.0.98
  28. inference trade offs stay with speclaliate.0.96
• 

  6:13 #18 skipped

  shot 18·duplicate of #16

• 

  6:48 #19 done21 line(s)

  shot 19·sharpness 733.1

  1. THE THESIS0.98
  2. Getting research to reality is asystems & process1.00
  3. problem.1.00
  4. 011.00
  5. 021.00
  6. 031.00
  7. Make research legible1.00
  8. A monorepo that can1.00
  9. Decomposition as a0.98
  10. receive new research1.00
  11. design problem1.00
  12. A handoff contract maps out a0.99
  13. Modularized code and templates1.00
  14. Prototype decomposition + review0.99
  15. project so an engineer can see the1.00
  16. that give every prototype a clean0.99
  17. needs to be planned so that giant1.00
  18. shape of the work1.00
  19. home1.00
  20. PRs ship without big-bang risk0.99
  21. 40.99
• 

  7:18 #20 done18 line(s)

  shot 20·sharpness 749.0

  1. Architecture & Services1.00
  2. Client requests from the Higharc application are routed through an Al Gateway that behaves as a reverse proxy,0.98
  3. performing JWT authentication before routing the request to the appropriate backend Al/ML microservice.1.00
  4. Microservices are built as isolated Docker containers, which join the same bridge network called higharc-network.0.99
  5. The bridge network allows the gateway to use Docker's internal DNS resolution, referring to other containers by1.00
  6. their service name rather than their IP address.1.00
  7. DDEP1.00
  8. Embeddings1.00
  9. Higharc1.00
  10. Al Gateway0.99
  11. web clients1.00
  12. Auto-translate0.98
  13. portB00.97
  14. (future-services)0.99
  15. docker network: higharc-network0.98
  16. stide/180.61
  17. ×0.53
  18. End presantatio0.89
• 

  7:43 #21 done16 line(s)

  shot 21·sharpness 740.4

  1. 回0.50
  2. Architecture & Services1.00
  3. Client requests from the Higharc application are routed through an Al Gateway that behaves as a reverse proxy,0.99
  4. performing JWT authentication before routing the request to the appropriate backend Al/ML microservice.1.00
  5. Microservices are built as isolated Docker containers, which join the same bridge network called higharc-network.0.99
  6. The bridge network allows the gateway to use Docker's internal DNS resolution, referring to other containers by1.00
  7. their service name rather than their IP address.0.99
  8. DDEP0.99
  9. Embeddings1.00
  10. Higharc1.00
  11. Al Gateway0.98
  12. web clients1.00
  13. Auto-translate1.00
  14. portB800.86
  15. (future-services)0.99
  16. docker network: higharc-network0.99
• 

  8:00 #22 done18 line(s)

  shot 22·sharpness 934.1

  1. Architecture & Services0.98
  2. Higharc1.00
  3. Client requests from the Higharc application are routed through an Al Gateway that behaves as a reverse proxy,0.99
  4. web clients0.96
  5. performing JWT authentication before routing the request to the appropriate backend Al/ML microservice.0.99
  6. Microservices are built as isolated Docker containers, which join the same bridge network called higharc-network.0.99
  7. The bridge network allows the gateway to use Docker's internal DNS resolution, referring to other containers by1.00
  8. their service name rather than their IP address.0.99
  9. DOEP0.89
  10. Embeddings1.00
  11. Higharc1.00
  12. Al Gateway0.98
  13. web clients1.00
  14. Auto-translate1.00
  15. (future-services)0.97
  16. docker network: higharc-network1.00
  17. 8×0.53
  18. End presentatic0.82
• 

  8:08 #23 done13 line(s)

  shot 23·sharpness 805.8

  1. 回0.71
  2. Higharc1.00
  3. Microservice API0.99
  4. web clients1.00
  5. V0.75
  6. Pydantic schema1.00
  7. Service layer1.00
  8. V0.84
  9. Data layer1.00
  10. database1.00
  11. Microservice Application0.98
  12. Slide 10/180.99
  13. End presentatio0.96

Transcript

104 cues· 2,193 words· 12,213 chars