팟캐스트Hear the voice. See the shape of the thought.

이 짧은 에피소드에서 swyx는 Cloudflare 개발자 플랫폼 책임자이자 swyx가 Code Mode의 창시자로 꼽는 Sunil Pai와 대화를 나눈다. 세 가지 주제를 다룬다: AI 에이전트의 기반으로서 Durable Objects와 Dynamic Workers에 대한 Cloudflare의 인프라 베팅, Sunil이 커리어가 끝난 줄 알았던 Vercel과의 트위터 오해 사건, 그리고 코드 포킹이 공격이 아니라 존중의 행위인 이유. Sunil은 마지막에 직접적인 도전을 던진다: 점진적인 에이전트 프레임워크 대신 SF를 만들라고. ## [00:00] Code Mode는 누가 만들었나? 3초짜리 슬레이트로 시작하는 영상. swyx가 Sunil을 "Code Mode의 창시자"로 소개하자, Sunil은 어린 시절부터 이를 구상해왔다며 거창하게 공을 받아들이는 장난스러운 첫 교환이다. 두 오랜 친구 사이의 순수한 농담이지, 본편 내용의 예고가 아니다. ## [00:03] 소개 및 Sunil Pai의 배경 swyx가 Sunil을 오랜 친구이자 AIE Europe 키노트 연사로 다시 소개한다. 짧은 근황 나눔이 이후 내용의 배경을 설정한다. Sunil의 현재 관심은 Cloudflare의 AI 에이전트 플랫폼이며, 최근 Anthropic의 Cloud Managed Agents 출시가 그에게 구체적인 비교 대상을 제공한다. > *"Cloudflare에서 요즘 어떤 일이 벌어지고 있는지 이야기 나눠보고 싶었어요."* ## [00:30] 새로운 클라우드 관리형 에이전트 이야기 Anthropic이 새로 출시한 Cloud Managed Agents — 장기 실행 에이전트를 구축·배포하는 플랫폼 — 이 Sunil의 출발점이다. Anthropic 팀을 좋아하고 제품도 흥미롭다고 하면서도, 스펙을 읽는 순간 경쟁심이 발동했다고 한다. Cloudflare가 더 잘할 수 있다는 것. swyx는 그 주장을 뒷받침할 Cloudflare의 실제 강점을 묻는다. > *"제품을 보고 나서 경쟁하고 싶다는 생각이 들었어요. Workers와 Durable Objects로 더 잘할 수 있다고 봐요."* ## [01:10] Cloudflare의 핵심 인프라: Durable Objects와 Dynamic Workers Sunil은 모든 에이전트 플랫폼이 결국 필요로 하게 될 두 가지 기본 요소를 꼽는다. Durable Objects는 상태를 가진 서버리스 단위로, 유저 레벨 라이브러리가 아닌 인프라 레이어에서 구현된 세계 최초의 액터 모델이라는 것이 Sunil의 주장이다. Dynamic Workers는 LLM이 생성한 코드를 안전하게 실행하는 Cloudflare의 방식이다. 콜드 스타트 없이, API 노출 범위를 설정할 수 있고, 외부 트래픽은 기본적으로 차단된다. 이 둘이 합쳐지면 전체 VM을 띄우지 않고도 샌드박스 컴퓨팅 환경에서 에이전트 단계를 실행할 수 있다. > *"인프라 레이어에서 액터 모델을 구현한 세계 최초의 사례입니다. 유저랜드가 아니에요."* ## [02:34] Cloudflare의 AI 에이전트 아키텍처 접근법 동료 Matt Carey가 구축한 Cloudflare MCP 서버가 Dynamic Workers의 실제 활용을 보여준다. Cloudflare API는 엔드포인트가 2,600개인데, 엔드포인트마다 하나의 툴을 노출하면 어떤 LLM의 컨텍스트 윈도우도 버텨내지 못한다. 대신 서버는 모든 것을 `search`와 `execute` 두 개의 툴 호출로 압축하며, 둘 다 아이솔레이트에서 실행되는 JavaScript 코드로 뒷받침된다. 에이전트가 코드를 제출하면 아이솔레이트가 실행하고 결과를 반환한다. LLM과의 왕복 없이, 타입 체크도 된다. > *"LLM과 한 번의 툴 호출로, 왕복 없이, 타입 체크까지. 결국 LLM이 코드를 잘 실행한다는 게 밝혀진 거죠."* ## [03:40] 에이전트 소프트웨어의 미래와 "harness" 표준화 swyx는 Anthropic 스펙의 harness 개념이 크로스 플랫폼 표준이 될 수 있는지 묻는다. Sunil의 답: AI 에이전트의 React는 아직 아무도 만들지 않았다. 2013년 React 비유를 의도적으로 꺼낸다. JSConf 발표장을 걸어 나간 사람들, Facebook이 JavaScript를 싫어한다고 비판한 사람들, 그럼에도 결국 React가 이후 모든 UI 프레임워크를 정의했다는 이야기. 지금은 저마다 자기 방식으로 harness를 만들고 있고, 언어와 회사와 인프라를 가로질러 재현 가능한 것이 없다. swyx는 평범한 마크다운인 skills가 이미 통합 레이어가 될 수 있지 않냐고 제안하고, Sunil은 아이디어가 매력적이라고 하면서도 구체성의 한계를 걱정한다. > *"너무 어렵지만, 머릿속에서 이렇게 프레이밍하고 있어요. 아직 아무도 React를 만들지 않았다고."* ## [06:11] "slop forks" 현상과 오픈소스 문화 swyx가 "slop forks" — AI로 생성된 인기 프로젝트 포크 — 를 꺼내자 Sunil이 눈을 빛낸다. 그의 시각에서 포킹은 절도가 아니라 위신과 존중의 표시다. React 생태계가 포크를 통해 성장했다. Cloudflare Agents SDK와 경쟁하는 무언가를 만들려는 사람에게는 마음껏 하라고 한다. 그렇게 되면 모두가 이긴다는 것이다. > *"포킹은 내 문화에서 위신과 존중의 표시예요."* ## [06:36] Vercel / Cloudflare 소셜 미디어 오해 사건 JSConf España에서 Sunil은 Vercel의 Harvey를 만나 즐거운 시간을 보냈다. 이후 Vercel Labs의 Just Bash — Bash를 순수 JavaScript로 구현한 것 — 를 발견하고 Cloudflare에 포팅하고 싶었다. 점심시간에 Opus로 코드베이스를 분석해 5,000줄을 받았고, 월요일에 정식 PR을 보내기 전에 정리할 계획으로 잠들었다. 깨어보니 Cloudflare 경영진에게 트위터를 확인했냐는 DM이 와 있었다. Vercel CTO가 그 작업을 개인 사이드 프로젝트가 아닌 회사 차원의 움직임으로 공개 비판한 것이다. Sunil은 담담하게 상황을 설명했고, 그러자 인터넷 절반이 그를 옹호하러 몰려들었다. > *"트위터에 들어가보니 Vercel CTO가 제 작업을 깎아내리면서 '이건 Cloudflare가 한 짓이다'라고 하더라고요."* ## [09:45] 소프트웨어 개발에서 포킹의 중요성 swyx가 Vercel 사건을 더 넓은 패턴과 연결한다. 라이선스를 피하려고 Python으로 다시 쓴 유출 코드베이스 이야기인데, 법적으로는 파생 저작물로 판결났다. swyx의 핵심 주장은 slop forks를 장려할 만하다는 것이다. 의존성을 포크하고, 내재화하고, 소유하면 LiteLLM이나 Axios처럼 업스트림이 갑자기 바뀌는 문제를 피할 수 있다. Sunil도 동의한다. NPM 이전에 소프트웨어는 정확히 이 방식으로 유즈넷을 통해 퍼졌고, 포크 주기를 단축하는 것은 그 전통의 연장일 뿐이라고. > *"포킹은 우리가 소프트웨어를 만드는 방식의 근본이에요."* ## [12:04] 현대 오픈소스 저장소의 적대적 환경 Cloudflare Agents SDK는 풀 리퀘스트 기여를 완전히 차단해야 했다. 이슈만 허용된다. Sunil은 콘퍼런스에서 오픈소스 메인테이너들과 대화를 나눴는데 모두 같은 이야기를 한다. 저장소가 적대적 영역이 됐고, 가장 위험한 공격 벡터는 자세히 읽기 전까지는 완전히 합법적으로 보이는 가짜 보안 리포트라는 것이다. swyx는 Claude Code의 Peter가 오전 발표에서 한 이야기와 연결한다. 지금 가장 큰 공격 표면은 손상된 의존성이 Claude Code 안으로 들어오는 것이고, 그렇게 되면 그것을 사용하는 모든 개발자가 노출된다는 것이다. > *"오픈소스 저장소는 사람들이 인기를 얻는 것 자체를 두려워할 정도로 적대적이 됐어요."* ## [13:04] 마무리 생각과 독창성을 향한 격려 Sunil의 마지막 요청은 직접적이다. 열 번째 에이전트 프레임워크는 그만 만들고, SF를 만들라고. 가족을 위한 무언가를 만들라고. Agent SDK를 써도 좋지만, 인프라와 LLM이 거의 한계에 부딪히는 지점에서 쓰라고. 다음 단계의 변화는 바로 거기 있다고. swyx는 2018년 React Rally에서 나온 Sunil의 "alpha thought leading" 발언을 회상하며 마무리한다. > *"SF 같은 걸 만드세요. 가족을 위한 걸 만드세요. 세상을 바꿀 힘이 충분히 있는데, 그냥 독창적이었으면 해요."* ## 등장인물 - **swyx** (인물): Latent Space 호스트; Sunil의 오랜 친구; 2018년 React Rally에서 Sunil의 즉흥 발언 후 "alpha thought leading"이라는 표현을 만들었다. - **Sunil Pai** (인물): Cloudflare 개발자 플랫폼 책임자; swyx로부터 Code Mode의 창시자로 인정받음; AIE Europe 키노트 연사. - **Cloudflare** (조직): 클라우드 플랫폼 기업; Durable Objects와 Dynamic Workers를 기반으로 에이전트 인프라를 구축 중. - **Anthropic** (조직): AI 기업; Cloud Managed Agents를 출시했으며, Sunil이 경쟁 대상으로 삼는 제품이다. - **Vercel** (조직): 프론트엔드 클라우드 기업; Sunil이 그들의 AI SDK를 사용하며, 트위터 오해 사건의 상대방이다. - **Durable Objects** (소프트웨어): Cloudflare의 상태 저장 서버리스 기본 요소; 인프라 레이어에서 구현된 세계 최초의 액터 모델이라는 것이 Sunil의 주장이다. - **Dynamic Workers** (소프트웨어): LLM 또는 사용자가 생성한 JavaScript를 콜드 스타트 없이 안전한 아이솔레이트에서 실행하는 Cloudflare 기능. - **Just Bash** (소프트웨어): Vercel Labs 프로젝트 — Bash의 순수 JavaScript 구현체 — 로, Sunil이 Cloudflare에 포팅하다가 트위터 사건이 발생했다. - **MCP** (개념): Model Context Protocol; Cloudflare의 MCP 서버는 Dynamic Workers를 활용해 2,600개의 API 엔드포인트를 두 개의 툴 호출로 압축한다. - **Slop forks** (개념): AI로 생성된 기존 프로젝트의 포크; Sunil은 이를 표절이 아닌 오픈소스 포킹 문화의 연장, 즉 존중의 표시로 해석한다.

AI Engineer London 현장에서 swyx가 Omar Sanseviero — Google DeepMind 개발자 경험 총괄 — 와 30분간 밀도 있는 대화를 나눈다. Gemma 4의 아키텍처 혁신, Google의 오픈 모델 전략, DevEx 팀의 다음 성장 방향을 짚으며, Omar는 레이어별 임베딩의 내막, 파인튜닝 열풍이 식은 이유, Kaggle이 DeepMind에 합류한 것의 실질적 의미, '자동 연구'가 실체인지 과대광고인지를 솔직하게 풀어놓는다. ## [00:00] Gemma 4 소개와 팀 범위 Omar의 한 문장 요약: Gemma 4는 "지금까지 출시한 오픈 모델 중 가장 강력한 것"으로, 파라미터당 지능을 극한까지 쥐어짜면서 완전한 멀티모달 지원을 유지하되 로컬 추론이 가능한 무게를 지킨다는 원칙 아래 만들어졌다. > *"저희는 정말 파라미터당 지능을 최대한 압축하려고 노력했습니다."* ## [00:23] 유효 파라미터와 활성 파라미터 설명 Gemma 4 소형 모델의 핵심 설계는 각 트랜스포머 블록에 레이어별 임베딩 테이블을 삽입하는 것이다. 행렬 곱이 아닌 룩업 방식이므로 30억 개의 임베딩 파라미터는 GPU 메모리에 상주하지 않아도 된다 — CPU나 디스크에 머물고, 실제 연산은 20억 활성 파라미터가 담당한다. Omar는 이 기법이 온디바이스 전용이라고 솔직히 밝힌다: 대형 모델에서는 Dense나 MoE 구조가 더 낫다. > *"Gemma 4 모델은 E2B입니다. GPU에 실제로 올라가는 건 20억 파라미터예요. 전체로는 거의 50억 파라미터지만, 나머지 30억은 CPU나 디스크에 둘 수 있습니다."* ## [01:43] 온디바이스 활용 사례와 Gemini Nano 통합 Pixel 폰과 하이엔드 Samsung 기기에는 Gemini Nano가 기본 탑재되어 있으며, Gemini Nano는 Google이 스마트폰 제약에 맞게 설계한 Gemma 3N 아키텍처를 기반으로 훈련된다. Gemma 4의 파라미터 오프로딩 아이디어는 이 소형 변형에도 동일하게 적용된다. swyx가 29B–31B 수준으로 확장 가능한지 묻자 Omar는 "실험을 많이 하고 있다 — 지켜봐 달라"고만 답한다. > *"고사양 스마트폰을 사면 이미 Gemini를 바로 쓸 수 있습니다."* ## [03:14] 모델 출시 배경과 개발자 생태계 Gemma 팀은 대부분의 예상보다 훨씬 작다 — PM 두세 명, 마케터 한 명, 그리고 핵심 엔지니어와 연구자들. 출시를 복잡하게 만드는 건 외부 그래프다: llama.cpp, Ollama, MLX, Hugging Face, vLLM, Nvidia, AMD 등 50개 파트너를 동시에 조율하고, 내부적으로는 Google Cloud, Vertex, ADK, Android와 협력해야 한다. Gemma 4 출시에는 Android Studio 에이전트 모드와의 네이티브 통합도 포함됐는데, 개발자가 오프라인 Gemma 4 추론으로 코드 지원을 받을 수 있다. > *"Gemma 4 출시에 외부 파트너가 거의 50곳이었습니다. 역대 가장 복잡한 출시였어요."* ## [04:29] 오프라인 vs API 사용과 향후 모델 성장 오프라인/프라이버시 구분은 실재하지만 전부는 아니다. Omar는 더 명확한 선을 긋는다: 지금 로컬 모델은 기능(함수 호출, 지시 수행, 에이전틱 작업)에서는 탁월하지만 지식 밀도에서는 여전히 밀린다 — 틈새 사실을 안정적으로 떠올리려면 대형 모델이 필요하다. 그의 1~2년 전망: Gemini Pro급 모델이 완전히 온디바이스에서 실행되어, 지금은 API 연결이 필수인 경험을 가능하게 한다. > *"1~2년 안에 스마트폰에서 Gemini Pro 수준의 강력한 모델을 직접 실행할 수 있는 미래가 온다고 생각합니다."* ## [06:26] Gemma 4 멀티모달 기능과 한계 Gemma 4는 Gemini 3의 연구 스택을 물려받아, 2B 모델에서도 오디오 이해(음성 인식, 음성-번역 텍스트, 오디오 클립 질의응답)와 비전(객체 감지, 포인팅, 캡셔닝)을 지원한다. Omar가 명시적으로 언급한 두 가지 한계: 이미지 세그멘테이션 미지원, 그리고 단일 프롬프트에서 비디오와 오디오를 동시에 처리하는 기능 미지원 — 현재는 별도 스트림으로 입력해야 한다. 네이티브 음성 출력은 검토 중이지만 발표된 내용은 없다. > *"비디오 입력과 오디오 입력을 각각 이해하는 건 되는데, 같은 프롬프트에 시각 부분과 오디오 부분을 함께 넣으려면 아직 개선이 더 필요합니다."* ## [08:08] 다국어 토크나이저 인사이트 Gemma의 토크나이저는 Gemini를 구동하는 것과 동일하다 — 140개 언어에 걸쳐 비범한 다국어 기반을 제공하는 설계 선택이다. Omar의 구체적 발견: Gemma 3을 베이스로 베트남어 같은 동남아 언어로 파인튜닝하면, 영어 벤치마크에서 더 높은 점수를 기록한 베이스 모델보다 뛰어난 성능을 낸다. 영어 최적화된 서브워드 조각으로 비라틴 문자를 억지로 처리하는 대신, 해당 언어에 맞는 토큰을 포착하기 때문이다. > *"이 모델들을 베트남어 같은 특정 동남아 언어로 파인튜닝하면 — 다른 베이스 모델이 전반적으로 더 낫더라도 — Gemma가 더 좋은 결과를 냅니다."* ## [09:30] AI Engineer에서 만난 Google 개발자 경험팀 런던은 DeepMind의 본거지다. AI Engineer Europe에 전체 팀을 이끌고 참석한 건 의도적인 선언이었다. Omar는 Gemma 4 개발, 디퓨전 텍스트 생성, 로보틱스, 온디바이스 ML, Android에 걸친 연구자들을 데려왔다 — DevEx 로드쇼가 아니라 실질적인 연구 발표였다. swyx는 그 범위를 직접적으로 표현한다: "가장 넓은 범위를 다루는 연구소예요. 돌고래 연구까지 하잖아요." > *"로보틱스부터 연구, Android까지 전 분야 사람들을 데려왔습니다. 회사가 만들고 있는 모든 것을 보여줄 수 있어서 정말 기분이 좋았어요."* ## [10:42] 텍스트용 디퓨전 모델 연구 소개 Google은 I/O에서 Gemini Diffusion을 발표했다 — 이미지가 아닌 텍스트를 생성하는 디퓨전 트랜스포머로, 자기회귀 디코딩보다 훨씬 빠른 속도를 낸다. Omar의 솔직한 평가: 품질은 여전히 자기회귀 기준선에 못 미치고, 분포 이동이 라우팅에 다른 방식으로 영향을 미치기 때문에 디퓨전 트랜스포머 파인튜닝이 더 어렵다. swyx는 디퓨전 모델이 빠른 직관적 처리를 담당하고 자기회귀 모델이 복잡한 계획을 맡는 그럴듯한 아키텍처를 스케치하는데, Omar는 가능성은 있지만 아직 이르다고 본다. > *"현재로서는 여전히 매우 실험적입니다. 일반적인 자기회귀 모델에서 얻을 수 있는 것보다 모델 품질이 아직 조금 떨어져요."* ## [13:37] 파인튜닝의 현재와 커뮤니티 트렌드 파인튜닝 커뮤니티는 2023년을 정점으로 조수가 빠지고 있다. Omar가 목격하고 있는 풍경: Gemma 4 출시 파트너 중 여럿이 27B 비전 모델 파인튜닝을 계획했다가 중간에 포기했는데, 베이스 모델이 이미 그 일을 해냈기 때문이다. 예전엔 파인튜닝이 필요했던 범용 동작 변경이 이제는 프롬프팅으로 처리된다. 남은 것: 의료, 금융, 틈새 데이터를 위한 도메인 특화 파인튜닝 — 그리고 베이스 모델이 업데이트될 때 LoRA 호환성을 관리해야 하는 조직적 과제. > *"그런 사례를 많이 봤어요 — 요즘은 범용 대화 모델로서의 파인튜닝에 대한 열기가 식고 있는 걸 느낍니다."* ## [16:29] Dense와 Sparse 아키텍처의 트레이드오프 Gemma 4는 비슷한 파라미터 수의 대형 모델 두 가지를 출시했다: 31B Dense(가장 높은 원시 지능, 양자화하면 소비자용 GPU에 올라감)와 4B 활성 파라미터를 가진 27B MoE(동일한 하드웨어 환경에서 가장 빠른 추론). 크기 선택은 개발자 친화성을 의도한 결정이다. Omar의 파인튜너들을 향한 경고: MoE 훈련 레시피와 하이퍼파라미터는 Dense 모델에서 깔끔하게 이식되지 않는다 — 입력 분포 변화가 어떤 전문가를 활성화하는지 바꾸면서 라우팅에 아직 완전히 이해되지 않은 방식으로 분포 이동이 발생한다. > *"MoE는 파인튜닝하기 까다롭습니다. 추론에서는 잘 작동하지만, 파인튜닝하면 조금 어려움을 겪어요."* ## [18:29] 파라미터당 지능과 미래 연구 방향 Gemma 2, 3, 4를 거치는 동안 Google은 최대 파라미터 수를 약 30B로 거의 고정한 채 성능 상한을 크게 끌어올렸다 — 파라미터당 지능 향상의 직접적인 증거다. 더 어려운 비교 문제: MoE 희소성과 파라미터 오프로딩을 도입하면 파라미터 수는 더 이상 공통 단위가 되지 않는다. Omar의 솔직한 전망: 지식 한계는 구조적으로 고착될 가능성이 높다 — 3년 후 30B 모델도 정보 이론적 한계 때문에 매우 틈새적인 사실 회상에서는 여전히 실패할 것이다. > *"파라미터당 지능이란 무엇인가? 이 파라미터당 지능을 어떻게 극대화할 것인가?"* ## [20:09] Gemma Scope와 메커니즘적 해석 가능성 Google은 12월에 Gemma Scope를 출시했다 — Gemma 3 모델 전체 레이어의 활성화를 분석하는 툴킷으로, 모든 레이어를 커버하는 수 테라바이트(페타바이트 수준일 수도 있는) 규모의 활성화 데이터셋이 뒷받침한다. Omar는 메커니즘적 해석 가능성을 ML 연구 입문의 낮은 진입 경로로 소개한다: 훈련 클러스터 없이도 활성화 분석을 실행할 수 있고, 실험을 통해 트랜스포머 내부 작동 방식에 대한 실질적인 직관을 얻을 수 있다. > *"시작하는 데 많은 컴퓨팅 자원이 필요하지 않은 분야입니다. 모델이 어떻게 작동하는지 이해할 수 있게 해줘요."* ## [21:12] 연구와 엔지니어링의 교차점 연구자들을 엔지니어링 컨퍼런스에 데려온 계기: 엔지니어들은 모델이 어떻게 만들어졌는지 이해할 때 모델을 더 신뢰하게 된다, 직접 훈련할 일이 없더라도. Omar와 swyx 모두 연구와 엔지니어링의 경계가 흐릿해졌다고 지적한다 — 연구자 업무의 대부분은 이론보다 엔지니어링에 가까운 경험적 소거 실험이고, 코딩 에이전트 덕분에 엔지니어들도 예전엔 연구 배경이 있어야 가능했던 실험에 바로 접근할 수 있다. Omar는 Reddit과 Discord가 독자적으로 재발견한 기법을 연구소가 나중에 논문으로 발표한 사례로 프랑켄머지와 Axolotl 커뮤니티를 든다. > *"무엇이 효과 있고 없는지 보면서 이것저것 옮겨보는 대규모 경험적 실험 — 제게는 연구보다 엔지니어링에 훨씬 가깝습니다."* ## [23:59] '자동 연구'와 에이전틱 자동화에 대한 시각 swyx가 핵심 질문을 던진다: 자동 연구는 그냥 '에이전틱 하이퍼파라미터 스윕'인가, 아니면 아무도 찾지 않았을 37번 수 같은 발견을 만들어낼 수 있는가? Omar는 신중한 회의론자다 — AutoML의 실적은 대부분 위장한 그리드 서치였고, 심층적인 아키텍처 작업은 향후 1~2년 안에 자동화되기 어렵다고 본다. 하지만 파인튜닝 자체는 곧 완전히 에이전트 주도로 바뀔 것이라 생각한다: 사용자는 훈련 코드를 짜는 대신 에이전트에게 실험을 시작하라고 지시하게 되며, Hugging Face의 AutoTrain이나 Axolotl의 CLI 같은 도구를 활용하게 된다. > *"다음 세대 파인튜너들은 코딩을 전혀 하지 않는 사람들일 겁니다. 대부분의 사람들은 몇 가지 스킬만으로 파인튜닝하게 될 거예요."* ## [26:06] 팀 확장, 글로벌 거점, Kaggle 통합 DevEx 팀은 현재 싱가포르와 인도에서 채용 중이다 — DeepMind 연구 사무소와 같은 건물에 자리 잡아, DevRel 직원이 고립된 영업 위성 사무소에 앉아있는 대신 복도를 걸어서 연구자를 만날 수 있다. 더 큰 조직 소식: Kaggle이 DeepMind에 합류했고, Kaggle의 경진대회와 벤치마크 인프라가 Gemma/Gemini 기능 격차와 직결된다 — 커뮤니티가 만든 벤치마크가 훈련 신호로 돌아올 수 있다. Omar는 피드백 루프 모델이라고 설명한다: 팀이 소셜 미디어와 행사를 통해 개발자들이 무엇을 만들고 있는지 파악하고, 그 신호를 모델링 쪽으로 가져간다. > *"Gemma, Gemini, 그리고 저희의 모든 도구를 만드는 방식은 스타트업, 커뮤니티, 개발자들의 피드백에 정말로 기반합니다."* ## 엔티티 - **Omar Sanseviero** (인물): Google DeepMind 개발자 경험 총괄; 이전에 Hugging Face에서 DevRel 성장을 이끌었으며, Gemma 개발자 생태계를 담당. - **swyx** (인물): Latent Space 팟캐스트 호스트; AI Engineer London 2026 인터뷰어. - **Gemma 4** (소프트웨어): Google의 오픈 모델 패밀리. 레이어별 임베딩 아키텍처(E2B 유효 파라미터 오프로딩), 2B/4B/27B MoE/31B Dense 변형, 140개 언어 지원, 멀티모달 입력 탑재. - **Gemini Nano** (소프트웨어): Gemma 아키텍처 기반의 온디바이스 모델; OS를 통해 Pixel 및 하이엔드 Samsung 폰에 기본 탑재. - **Gemma Scope** (소프트웨어): Google의 메커니즘적 해석 가능성 툴킷 — Gemma 3 모델의 레이어별 활성화 분석; 2025년 12월 페타바이트 규모 활성화 데이터와 함께 출시. - **Gemini Diffusion** (소프트웨어): Google의 실험적 텍스트 생성용 디퓨전 트랜스포머(이미지 아님), Google I/O에서 발표; 주요 장점은 추론 속도. - **Kaggle** (조직): 경진대회/벤치마크 플랫폼으로 Google DeepMind에 합류; 커뮤니티 평가를 Gemini 기능 피드백 루프와 연결. - **Google DeepMind** (조직): Google의 통합 AI 연구소; Gemma, Gemini, 로보틱스, 온디바이스 ML, 메커니즘적 해석 가능성을 아우름. - **AI Engineer London** (조직): 응용 AI 엔지니어링 컨퍼런스 (2026년 에디션); 이 인터뷰 장소이자 DeepMind 본거지. - **MoE (Mixture of Experts)** (개념): 토큰당 파라미터의 일부만 활성화하는 희소 아키텍처; 동등한 파라미터 수에서 Dense보다 빠른 추론을 제공하지만, 분포에 민감한 라우팅으로 파인튜닝이 어려움. - **레이어별 임베딩 (Per-layer embedding)** (개념): Gemma 4의 아키텍처적 변경 사항 — 각 트랜스포머 레이어에 삽입된 룩업 테이블 임베딩으로, 30억 파라미터를 행렬 곱 비용 없이 GPU 외부에 두는 것을 가능하게 함. - **파라미터당 지능 (Intelligence per parameter)** (개념): Gemma 2→3→4를 거치며 총 파라미터 수를 약 30B로 유지하면서 향상시켜 온 성능 대 가중치 비율.

Oriol Vinyals（Google DeepMind VP of Research、Gemini 联合负责人）在 Google I/O 第二天坐下来，把 I/O 上发布的产品背后的研究路线一条条摊开：世界模型为什么是 Google 押向 AGI 的独特路径、视频 / 图像的"GPT moment"长什么样、Spark 和 agents 系统为什么必须和模型联合优化、scaffolding 终将由模型自己写、memory 应该走非参数 file-system 而不是塞进权重、当今 RL 在哪些维度上是数据受限的、为什么 math/code 上的训练能意外迁移、以及 Google 内部 Brain + DeepMind 合并后研究下注的取舍。 ## [00:00] Intro Jacob 用 60 秒铺垫了 Oriol 的背景（Gemini 联合负责人，与 Noam Shazeer、Jeff Dean 并列），以及 I/O 第二天访谈的优势：所有发布都还热乎，可以直接顺着 announcements 追到背后的研究。Oriol 进来打招呼，两人开始热身。 > *"I've been really excited for this because you're one of the people kind of most directly shaping the frontier of AI."* ## [01:36] Why World Models Jacob 先问"为什么是世界模型"。Oriol 把它拆成两层：一层是 self-improvement / coding 的角度，另一层是模型本身的对象——多模态、不止 closer 还包括 video / image 这种"world model"。Google 早就押了图像和视频路线，这次"显然押对了"，因为我们其实把整个世界都搬到了互联网上。 他也承认中间有一段时间这条路看似不性感：multimodal 模型在 LLM 风口下被边缘化过，但视频和图像里藏着语言抓不到的知识——"the GPT moment for video"还没真正发生，但拐点已经在视野里。 > *"There is lots of knowledge in videos and images, and what I would say is the GPT moment for that — I'm not sure we quite have seen that."* ## [04:21] The GPT Moment for Video Oriol 用 Omni（Google 的多模态产品线）当锚点解释：从单纯把视频喂进上下文，到能在长上下文里理解和生成视频，这段曲线已经很陡。下一步是问"能不能像 LLM 一样，在没有 paired text 的纯图像数据上预训练并依然提取出全部意义和细节"——这个 hard challenge 一旦解开，数据维度会从"被人类描述过的"跳到"所有视频"，量级差异巨大。 他特别承认现在 video 这块的标注数据相对 image 仍然稀缺，但解锁后的回报会"非常大"。 > *"Whether we agree with that or not is another question, but if it was to be unlocked, it would be massive."* ## [07:51] What Makes Omni a World Model "world model"这个词被滥用了，Oriol 给一个清晰定义：一个纯粹的 world model 必须做 representation learning——把世界压成紧致表征。在这之上，Omni 进一步成为可被语言驱动的 renderer：你用自然语言改一个 prompt，输出的视频内容随之改变，初始 image 之上能持续演化。这是从"被动建模"到"可控生成"的关键区别。 > *"The world model itself is acting as a renderer of the world, that you can really just change by language."* ## [10:04] World Models & Robotics 机器人是 world model 最直接的落地场景。Oriol 承认现在数据 mix 还在试错——sim 数据 vs 真机数据怎么配、什么时候 transfer 突然 click。世界模型本身的进步会带来一个 inflection point：一旦模型足够强，sim → real 的鸿沟会缩到 planning 和 gross motor 层面先打通，精细运动控制再慢慢跟上。 > *"At some level, maybe not at the precise motor control but at the kind of planning and gross, we are going to start seeing how things are going to fall into place."* ## [12:37] Evaluating Physics in AI 模型隐式学物理，但你怎么评估它学到没学到？Oriol 把它和无监督机器翻译做类比：如果模型内部确实表征了"重力"这个概念，应该能用某种 decode 把它翻译成显式 explanation。Stefano Gaus 等人 2014 年的早期 unsupervised translation 工作给了一条可借鉴的思路——把内部表征解码出来当 eval。 > *"You would need to somehow connect the concept of gravity which could be present or not in a world model to then decode that into an explanation."* ## [14:51] Consumer Agents & Spark I/O 发布的 Spark 是 Google 在 consumer agent 上的最新一步。Oriol 强调："action 作为一种 modality"已经被 DeepMind 早早识别为关键。但 agent 不是把模型塞进 generic scaffold 就行——模型能力必须先到某个门槛，你才能 dream 出下一阶段的产品形态。 他给一个工程判断：在 train 阶段就把"我有这些能力，怎么挑用哪些"内化进模型，比在 inference 时让外部 scaffold 临时决策更高效。 > *"It's useful to build kind of the system slightly more narrowly around something you care deeply about."* ## [18:39] Scaffolding & the Bitter Lesson Oriol 多年支持 Sutton 的 bitter lesson。Jacob 把它推到 agent 时代：scaffolding 看起来违背 bitter lesson 因为是手写的胶水。Oriol 的答案是——"scaffold 本身就是一段 code，最终应该是模型自己 on the fly 写出来"。短期内人写、长期模型写，bitter lesson 仍然站得住。同时优化 model 和 scaffold 两端，而不是把所有赌注押在一端。 > *"That system itself is a piece of code that eventually the model itself could write on the fly."* ## [22:06] Memory & Continual Learning Memory 这个话题 Oriol 谈得最深——他有 cognitive neuroscience 背景。他把 memory 分成两类：塞进权重（参数化）和挂在外部 file system（非参数化）。在 serving 规模下，把每次 user interaction 都 bake 进 weight 是不切实际的，非参数式 file-system memory 更可行。 真正的难点是"consolidate"：怎么把之前 session 的信息整合到新 session，让模型像人一样积累知识。这部分 momentum 很大但远未饱和，未来几年评估方式和工程实践都会迭代。 > *"The way that we'll see better evaluations and ways in which these models accumulate this knowledge as they go."* ## [26:54] Research Bets Inside Big Labs 在 Google 内部主导 Gemini 是什么体验？Oriol 谈三个维度的优势：TPU 联合设计（不用看 Nvidia 脸色）、广告/搜索带来的现金流稳定性、Brain + DeepMind 合并后端到端的研究强度。劣势是：组织太大没法对所有方向有全视野，必须靠直觉判断哪些早期研究值得 pull in，并接受"trade-off 不可能每次都做对"。 > *"Google is in a unique place. We have stability from hardware procurement and obviously like also investment of capital."* ## [32:30] Post-Training RL is Greenfield post-training 这块仍然是一片 greenfield。在 coding 和 math 上 LLM 已经走出指数曲线，但其他领域为什么没跟上？Oriol 的核心判断是"投入还远远不够"——相对预训练的算力消耗，post-training 至今只用了很小一部分。算法的 beauty 还在迭代，"cracking that recipe could be big"。 > *"Cracking that recipe could be big, at least in terms of the beauty of the algorithm."* ## [35:57] What Real Intelligence Looks Like 真智能长什么样？Oriol 用 2015 年的一个老 eval 来当锚——简单的 game-playing 任务，当时是 RL 的天花板，现在 LLM 一上来就能做。他想看到下一个数量级的跃迁：不是在熟悉的 benchmark 上推数字，而是在新的、人类没法立刻给出答案的问题上看到模型"主动产出洞察"。 > *"I like games."*（这句简单的自陈背后是他对 game-playing RL 长期偏爱的注脚） ## [39:11] RL Generalization 游戏曾经是 verifiable reward 的典型样板。现在的挑战是找新的 hard problem source，让 RL 在更广的领域诱发出深度推理和泛化。Oriol 抛出一个不对称观察：create solution 和 evaluate solution 之间存在 gap——如果 evaluation 比 generation 容易，RL 就有机会撬动。 让他意外的是：在 math/code 上的训练能 surprisingly 迁移到其他领域，"很多泛化能力可能其实来自 pre-training"。这是接下来几个月到几年研究者要破解的关键题。 > *"Possibly through pre-training — that's one of the quests for researchers to crack in the next few months and years."* ## [42:55] Advice for Founders 给 founder 的建议直白：evaluation 和 data 是绕不开的 moat。早期专注垂直产品、在 model 上叠一层 specialized scaffolding，等到 scale 起来再考虑 model layer 的差异化——这个路径"比较 scalable，也更适合早期玩家"。 > *"What I would tell folks is the value — and we discussed this a little bit — the value of evaluations and as a sequence of data."* ## [46:40] Can AI Truly Innovate? Oriol 2016 年加入 DeepMind 后最痴迷的方向是 meta-learning——模型自己产出 idea。但他承认到目前为止，"我没看到模型生成真正 outstanding 的 idea"。他比喻：你让一万个人尝试，挑出对的那个再 glorify，但模型真正自主提出方向的能力——quite limited。但他相信 "soon"。 > *"I don't think I've seen truly kind of outstanding ideas that a model has generated yet, but I am sure I will very soon."* ## [49:48] Recursive Self-Improvement 递归自我改进可以分层看：第一层是 researcher / engineer 用 AI 工具加速自己；第二层是模型直接自动化某些研究任务。当模型写英文比你好的那一天，下一个 ceiling 在哪里？Oriol 说："maybe there's no ceiling, or the ceiling is still far away" —— 我们甚至不一定能看到 ceiling 在哪里。 > *"At the point a model writes English better than you, maybe there's no ceiling, or the ceiling is still far away."* ## [52:14] Quickfire 最后 8 分钟快问快答覆盖了 TPU 投资历史、给年轻研究员的算力直觉、当下 AI 阶段的总体感受。Oriol 留下一句总结："I think it's a fascinating time as anything in AI"。Jacob 用 podcast 致谢和 outro 结束。 > *"I think it's a fascinating time as anything in AI."* ## Entities - **Jacob Effron**（人物）：Redpoint Ventures Managing Director，Unsupervised Learning 主持人。 - **Oriol Vinyals**（人物）：Google DeepMind VP of Research，Gemini 联合负责人（与 Noam Shazeer、Jeff Dean 并列）。 - **Gemini**（产品）：Google 的旗舰多模态 / agent 模型族；本期主要谈 I/O 第二天的发布。 - **Omni**（产品）：Google 的多模态产品线，被用作"video / image 的 GPT moment"参照系。 - **Spark**（产品）：I/O 发布的 consumer agent 产品。 - **World Model**（概念）：可被语言驱动的世界 renderer；representation learning 是其核心要素。 - **Bitter Lesson**（概念）：Sutton 的论点；本期延伸为"scaffold 长期应由模型自己写"。 - **Memory / Continual Learning**（概念）：非参数 file-system memory vs 把记忆塞进权重；consolidation 是关键难点。 - **Post-Training RL**（概念）：相对预训练的算力投入还很少，被定性为 greenfield。 - **Move 37**（概念）：AlphaGo 那一手；Oriol 用它指代"真正的 RL/research breakthrough"基准。

Reiner Pope, CEO of MatX and former Google Brain TPU architect, gives Dwarkesh Patel a blackboard-style lecture on chip design from first principles. Starting with AND and NOT gates, Reiner works up through register files, systolic arrays, clock synchronization, FPGAs, cache hierarchies, and finally the structural difference between a GPU and a TPU. The throughline is a single engineering tension: every compute unit is wasted if the chip spends its time moving data rather than multiplying numbers. ## [00:00] Building a multiply-accumulate from logic gates Reiner starts at the bottom: AND, OR, and NOT gates, wired together as metal traces on silicon. The key operation AI chips want to run is matrix multiplication, and inside that the primitive is a multiply-accumulate — multiply two numbers, add the result into an accumulator. Reiner walks through how a full adder is assembled from a handful of XOR and AND gates, and how those cascade into a bit-serial multiplier and ultimately a floating-point MAC. The precision hierarchy matters here: accumulating low-precision multiplications requires higher-precision accumulators, which is why AI chips run 8-bit multiply but 32-bit accumulate. > *"The main function that AI chips want to compute is the multiplication of matrices. Inside that, the fundamental primitive is a multiply-accumulate of pairs of numbers."* ## [16:20] Muxes and the cost of data movement Before Tensor Cores, GPUs and CPUs used the same structure: a register file holding a few dozen values, feeding into an ALU, writing back to the register file. Reiner shows that a mux — a circuit that selects between multiple inputs — is the hardware tool that lets you address arbitrary registers, and that the cost of this generality is measured in area and energy. Every read from an eight-entry register file requires a mux tree of depth three; every write requires a decoder of the same size. The bottleneck for AI workloads isn't the multiply itself but the round-trip through that register file. > *"We want to analyze the cost of the data movement from the register file to the ALU and back."* ## [25:59] How systolic arrays work The key insight behind TPUs: instead of doing one multiply-accumulate at a time and writing back to registers, bake an entire matrix-vector loop into hardware. A systolic array is a grid of MAC units where each cell passes its partial sum to the right and its input operand downward, so data flows through without ever touching a register file. Reiner explains the two wins this buys: more compute per unit of data fetched, and the ability to keep operands resident inside the array for the full inner product instead of re-loading them. The trade-off is inflexibility — you can only efficiently run the exact loop shape the hardware was designed for. > *"The idea of a systolic array is to go two levels of loops up and bake this entire loop out here into hardware."* ## [39:00] Clock cycles and pipeline registers With 100 billion transistors on a chip, synchronization between parallel units is non-negotiable. Reiner explains the clock: every nanosecond or so, the chip pauses all computation for a synchronization pulse before the next operation. Clock frequency is set by the longest combinational path — the deepest chain of logic gates that a signal must traverse in one cycle. Pipeline registers chop that path into shorter stages, letting each shorter segment run at a higher frequency, at the cost of latency: a fully pipelined 32-stage multiplier produces one result per cycle but takes 32 cycles for any single multiplication. > *"Every nanosecond or so, all circuitry in the chip will pause for a moment and synchronize. That is the clock cycle."* ## [51:40] FPGAs vs ASICs An FPGA is a sea of programmable logic blocks — lookup tables and flip-flops that can be wired together in software. An ASIC is a chip taped out for one purpose. Conceptually they're the same: AND/OR gates in a fixed clock cycle. The economics diverge at first copy: an FPGA costs $10K to program; a first ASIC tape-out costs $30M. FPGAs make sense for workloads that change monthly and need deterministic latency at high speed with less care about energy or throughput. Jane Street uses them for high-frequency trading exactly because the clock cycle is deterministic — no cache misses, no branch prediction, no interrupts. > *"The first FPGA costs you $10,000, whereas the first ASIC you make costs $30 million because it requires an entire tape-out."* ## [63:14] Cache vs scratchpad CPUs are non-deterministic partly because of the L1/L2 cache: a small fast memory that speculatively stores data the processor thinks it will need next. Cache misses — when the prediction is wrong — stall execution for hundreds of cycles. AI accelerators replace the cache with a scratchpad: explicitly programmer-managed SRAM where the compiler decides exactly what lives there and when. Groq and TPUs both advertise deterministic latency because they use scratchpads instead of caches. The scratchpad is simpler and faster but shifts the burden to the compiler. > *"Probably the most important source of non-determinism on a CPU is the CPU cache itself."* ## [67:16] Why CPU cores are much bigger than GPU cores A modern CPU has maybe 100 cores, each taking up far more die area per core than a GPU's thousands of SMs. The reason: CPU cores carry enormous out-of-order execution machinery — reorder buffers, branch predictors, speculative execution units — all aimed at keeping a single thread running fast on unpredictable workloads. A GPU SM strips most of that out. It runs many simple threads in lockstep (a warp), and when one thread stalls on a memory load, the hardware instantly switches to another warp at zero cost. The CPU pays silicon for per-thread speed; the GPU pays silicon for throughput across thousands of parallel threads. > *"If there are so few cores, what are you spending all of the die on?"* ## [71:49] Brains vs chips Dwarkesh pushes Reiner on the brain-versus-chip comparison. Two genuine differences: the brain has unstructured sparsity (any neuron can connect to any other), while hardware accelerators use structured sparsity (aligned blocks); and the brain's clock runs at tens of hertz versus gigahertz on silicon. Reiner notes that co-location of memory and compute — often cited as a brain advantage — is also present in modern AI chips: the weights sit in HBM right next to the matrix units. The energy constraint is the more interesting gap: the brain runs on 20 watts, chips on kilowatts, which may reflect fundamental differences in what the brain is optimized to do. > *"This is exactly the co-location, in some sense, of the memory and compute."* ## [75:22] A GPU is just a bunch of tiny TPUs At the top level, a TPU has a handful of large systolic arrays plus a vector unit. A GPU has hundreds of SMs, each of which contains a small matrix unit and a small vector unit — essentially a miniaturized TPU. The architectural difference is granularity: a TPU commits to a few large matrix operations; a GPU runs thousands of smaller ones in parallel. Inside each SM, Tensor Cores add a fixed-function matrix unit on top of the original scalar/vector pipeline, making modern GPUs a hybrid of the two paradigms. The "GPU is just tiny TPUs" framing collapses what seemed like fundamentally different architectures into a single continuum. > *"You can think of scaling this thing down into a really tiny unit with a smaller matrix unit and a smaller vector unit, and that is sort of what an SM is."* ## Entities - **Reiner Pope** (Person): CEO and co-founder of MatX; previously led TPU software and compiler work at Google Brain - **Dwarkesh Patel** (Person): host of the Dwarkesh Podcast; angel investor in MatX - **MatX** (Organization): AI chip startup building inference accelerators - **Google / Google Brain** (Organization): where Reiner worked on TPU architecture before MatX - **Jane Street** (Organization): high-frequency trading firm that relies on FPGAs for deterministic latency - **Groq** (Organization): AI inference chip company that advertises deterministic latency via scratchpad architecture - **Multiply-Accumulate (MAC)** (Concept): the fundamental operation of neural network inference — multiply two numbers, add into an accumulator - **Systolic Array** (Concept): a grid of MACs that passes data between cells without touching a register file, enabling high compute-to-bandwidth ratios - **FPGA** (Technology): Field-Programmable Gate Array — reprogrammable logic fabric used where workloads change frequently - **ASIC** (Technology): Application-Specific Integrated Circuit — custom silicon optimized for one workload - **TPU** (Technology): Google's Tensor Processing Unit, organized around a few large systolic arrays - **SM / Streaming Multiprocessor** (Technology): the GPU core unit, containing scalar, vector, and matrix (Tensor Core) execution resources

Sacks is out, Gavin Baker (Atreides Management) sits in. The panel walks through Andrej Karpathy's surprise move to Anthropic, debates why the public mood on AI has flipped, tears apart SpaceX's $2T S-1, and asks why Nvidia's blowout earnings still saw the stock sold. Friedberg and Chamath also flag warning signals from inflation, oil, and bond yields, and close on what — if anything — came out of the US-China summit. ## [00:00] Gavin Baker joins the show! Jason opens episode 274 noting Sacks is out and welcomes Gavin Baker from Atreides Management for the week. They tee up the agenda: SpaceX and OpenAI IPOs, Karpathy to Anthropic, and Nvidia's earnings. > *"Sachs is out today, but we're very lucky to have Gavin Baker from Atreides Management joining us. The spicy takes must flow."* ## [00:30] Andrej Karpathy joins Anthropic; hypergrowth and profitability The Karpathy hire is read as a major strategic win for Anthropic — Chamath frames it as continuity of the Richard Sutton "bitter lesson" school of scaling that Karpathy executed at Tesla FSD and OpenAI. Gavin layers in financial context: Anthropic was EBIT-positive in the last quarter per the WSJ, which combined with hypergrowth makes the recent funding rounds look very different from a capital-burn narrative. Friedberg pushes back on the framing that models will soon "feed themselves" into context windows to self-improve, but flags that papers (one from MIT) suggest large efficiency gains are on the horizon. Chamath uses the moment to argue the podcast itself has to start telling the upside story of AI — the doctors, the scientists, the unlock — because the dominant public narrative has gone negative. > *"He was probably the first person that really commercialized the Richard Sutton bitter lesson essay when he was leading FSD at Tesla."* ## [12:42] Why Americans have turned on AI, anti-human perception Gavin shares a personal story: his daughter has a rare disease, and a Stanford scientist he funded is months away from what he believes is a complete cure, made tractable by AI-accelerated biology. He uses it to argue for an optimistic posture — a future where work is optional and disease is solvable — and warns that the people pushing for AI regulation are also shaping how the public feels about the technology. Friedberg goes deeper into the cultural mechanics: AI is being framed as anti-human in a way that mirrors anti-nuclear and anti-industrial backlashes of the 20th century. He argues the United States can't unilaterally slow down because China and others won't — and tries to separate genuine safety concerns from elite class anxiety. Chamath then makes a pointed observation that none of the survey data on AI job loss actually asks the truck drivers, package sorters, and ICU nurses themselves how they feel about the tools. > *"We're listening too much to the inventors of AI. They're geniuses. They're smart. We need to be listening to the frontline factory workers who are using AI saying, 'Wow, I was able to add a third shift.'"* ## [27:22] Trump pulls AI EO, US-China AI relationship, dystopian AI layoffs A Trump AI executive order was scrubbed at the last minute — the panel walks through what was reportedly in it (review of frontier-model training runs) and whether any pre-release regulatory framework is workable. Jason argues a state-by-state patchwork is the more likely outcome regardless of what Washington does. The conversation pivots to Meta's latest round of layoffs and the way they were communicated. Gavin and Jason agree the messaging — leaning on "AI productivity gains" as the public reason — landed badly even with people who accept the underlying logic, and Jason argues it became a case study in how *not* to message AI-driven workforce changes. > *"Because the reality is that if this is the way that you're going to message something as critical as this, I think you did a horrible job."* ## [45:19] SpaceX S-1 tear down! Breaking down the three major businesses and the case for a $2T valuation SpaceX filed its S-1 on Wednesday. Jason breaks the company into three businesses: launch (which could be hundreds of millions of paying subscribers via Starlink), Elon Web Services / xAI / Colossus compute, and rockets. The AI-cloud line item alone is around $15B and growing roughly 2x year over year, anchored by an Anthropic deal Gavin calls "extraordinary." Gavin then makes the case that Colossus matters because raw gigawatt-class data centers are now the binding constraint, and SpaceX-adjacent build velocity is the moat. He uses Cursor's Composer 2.5 release — Pareto-dominant on three or four weeks of RL training — as evidence that whoever owns the compute owns the next model generation, and walks through why rapid reusability on Starship compresses the unit economics of getting payload to orbit faster than any competitor can model. > *"If you look at who's actually capable of delivering a gigawatt data center, these guys are the closest, like an actual gigawatt."* ## [71:22] Nvidia smashes earnings but stock falls, why people are shorting chips Nvidia blew out earnings again — 20% sequential growth would be a high-growth print for any other company, the dividend was raised 25x, and the CFO committed to returning 50% of free cash flow. Yet the stock sold off, and Leopold Aschenbrenner's reported pivot away from chip exposure is being read as a smart-money signal. Gavin takes the bear case apart: at current PE Nvidia is cheap relative to growth, and the segment breakdown obscures how much the "AI clouds" line is dragging the multiple. He flags that the true useful life of a GPU is closer to two years than five, which means the reported profits of every hyperscaler running these chips are overstated — a real concern, not a stock-killer. He also notes Nvidia's CPU business is on track to do $20B this year, making it overnight one of the largest CPU manufacturers in the world. > *"The true lifespan of a GPU is more like two years and therefore the profits of all these businesses are overstated."* ## [82:25] Market update: Flashing red signals, oil, inflation, yields up The macro snapshot: May inflation expected at 4.2%+, Fed rate-hike odds back on the table, UK yields at the highest since the great financial crisis, oil and gold both moving. Chamath warns that when the currency-debasement mechanism finally breaks, the downside is non-linear. Gavin counters with relative optimism on the US: America is self-sufficient in energy, the AI build-out is structurally good for re-industrialization, and even in an ugly global scenario the US is the least-bad place to be invested. He flags AI fundamentals also have a seasonality that investors are starting to model — the same way e-commerce and subscription businesses do. > *"While it's terrible for everyone, it is relatively the best for America because we are self-sufficient in energy."* ## [92:45] China trip flops, or was progress made behind the scenes? A 48-hour US tech-CEO-plus-president trip to Beijing produced thin public deliverables: some soybeans, some H100/A200 sales to Chinese players. The panel asks whether that's the real story or just the visible surface, and whether the immediate China-Russia bonding moment afterward says more about the trajectory than any handshake photo. Gavin argues the more important read is structural: keeping America ahead in AI requires keeping the trans-Pacific relationship just stable enough to avoid a full decoupling shock, and that's a defensible strategic logic even if the optics are unsatisfying. He also paints a what-if scenario around the Strait of Hormuz to make the point that energy independence is what gives the US the option to act asymmetrically. Jason closes with thanks to Gavin and an invite back to the Summit. > *"There's sound arguments that this is stabilizing for the world and is the best highest probability path for keeping America ahead in AI."* ## Entities - **Jason Calacanis** (Person): Host, LAUNCH founder, MC of this episode. - **Chamath Palihapitiya** (Person): Host, Social Capital CEO; pushed the "listen to frontline AI users" framing. - **David Friedberg** (Person): Host, The Production Board CEO; led the cultural / historical analysis of the AI backlash. - **Gavin Baker** (Person): Guest host, Atreides Management founder/CIO; carried the investing thread across SpaceX, Nvidia, and macro. - **Andrej Karpathy** (Person): Joining Anthropic's new pre-training team; OpenAI co-founder, ex-Tesla FSD lead. - **Anthropic** (Organization): Hired Karpathy; EBIT-positive last quarter per WSJ; $15B AI-cloud deal with SpaceX-adjacent compute. - **SpaceX** (Organization): Filed S-1; three businesses (launch/Starlink, Elon Web Services compute, rockets); $2T valuation case. - **Nvidia** (Organization): Earnings blowout but stock sold off; $20B CPU run-rate; $5.3T market cap. - **Cursor** (Software): Composer 2.5 model release used as proof of fast RL-driven catch-up dynamics. - **Richard Sutton's bitter lesson** (Concept): Scaling beats clever architectures — framing for why Karpathy's move matters. - **GPU useful life** (Concept): Closer to ~2 years than ~5, so hyperscaler reported profits are overstated. - **Strait of Hormuz scenario** (Concept): Energy-independence-as-strategic-option argument for the US in the China game.

Tushara Fernando, Head of Data and AI at Man Group, explains how the firm integrates AI into systematic trading by codifying decades of institutional knowledge into "skills." She emphasizes that robust governance and shared workflows are essential for moving AI from individual productivity tools to enterprise-scale agentic platforms. ## [00:18] AI in Systematic Trading Man Group manages over $200 billion in assets, making the stakes for AI implementation exceptionally high for their institutional clients. Tushara Fernando describes systematic trading as an algorithmic process that uses historical backtesting to evaluate investment signals, much like managing a fantasy football team. > *A trading signal is really just this with stocks... We want to back the ones that would make money and we want to short the ones that won't.* > *[2, 43]* ## [04:38] The Role of AI-Generated Signals Man Group currently runs trading signals in production that were entirely researched, backtested, and proposed by AI. While humans review the final output for sensibility, AI handles the data acquisition, strategy proposal, and productionization of these investment ideas. > *There are trading signals running right now in production at Mang Group... that were researched, back tested and proposed by AI.* > *[4, 38]* ## [05:52] The Importance of Shared Workflows The success of a trading signal depends on the underlying workflows, such as data cleaning and outlier detection, which Fernando compares to the submerged part of an iceberg. Without shared workflows, different teams produce inconsistent results, making it impossible to compare the effectiveness of various strategies. > *If different teams are running different versions of those workflows, you get different answers.* > *[6, 50]* ## [08:43] Lessons in Skills Governance Early attempts at AI adoption failed because power users, rather than process owners, were building "skills," leading to local optimizations and errors like hardcoded cost centers. To solve this, Man Group created a governed marketplace where skills are owned by workflow owners, tested with evaluations, and tracked for usage. > *Treat those skills like production code because that's what they will become.* > *[17, 21]* ## [16:40] Scaling AI Across the Enterprise Man Group has scaled AI usage to nearly half its workforce by focusing on organizational context as a competitive moat. By treating skills as a library of institutional knowledge, the firm is preparing for a future where swarms of agents leverage these capabilities to find new investment opportunities. > *Skills governance really unlocks AI at that enterprise scale.* > *[19, 21]* ## Entities - **Tushara Fernando** (person): Head of Data and AI at Man Group. - **Man Group** (organization): An alternative investment manager with over $200 billion of assets under management. - **Claude** (product): An AI model used by Man Group for research, backtesting, and workflow automation. - **Anthropic** (organization): The AI company that assisted Man Group with skills workshops and implementation. - **Systematic Trading** (concept): Algorithmic trading capabilities that look across thousands of securities and hundreds of markets. - **Backtesting** (process): The process of running a trading strategy against historical data to evaluate its performance. - **Sharpe Ratio** (metric): A statistical factor that compares the volatility of a strategy versus its returns. - **Skills Marketplace** (product): Man Group's internal library for governed AI skills, plugins, and institutional knowledge.

Andrew Feldman, CEO of Cerebras, details the company's journey from a controversial 'wafer-scale' architecture to a $63 billion public valuation. He explains how their radical hardware design delivers 15-20x faster AI inference than traditional GPUs, enabling new business models and a fundamental reorganization of productivity. ## [00:00] – Cold Open Andrew Feldman compares the impact of AI speed to Netflix's transition from DVD delivery to streaming, noting that extreme speed opens entirely new business models. He predicts a fundamental reorganization of productivity as AI moves beyond basic coding and design tasks. > *that's what happens with speed and I think that's what fast AI does right now [00:10]* ## [00:41] – Andrew Feldman Introduction Host Sarah Guo introduces Andrew Feldman and highlights Cerebras' recent IPO and its current $63 billion market cap. The discussion frames the company's transition from early machine learning research to dominating the foundation model inference market. > *Serbust recently went public and is currently worth about $63 billion in the stock market. [00:54]* ## [00:48] – Cerebras’ Evolution Feldman describes Cerebras as a builder of AI-optimized computers that outperform GPUs by up to 20x in inference tasks across all model sizes. He attributes their recent success to AI models becoming smart enough for daily utility in 2025, leading to massive contracts with OpenAI and AWS. > *we're the the fastest at inference, not by little, but by a lot, 15, 18, 20x faster than GPUs. [01:39]* ## [02:17] – Wafer-Scale Bet Pays Off The conversation explores Cerebras' unique 'wafer-scale' architecture, which utilizes a single chip the size of a dinner plate. Feldman argues that radical performance improvements require radical designs, noting that critics initially dismissed the approach as impossible. > *we chose wafer scale, which means we build a 46,000 square millimeter chip, a chip the size of a dinner plate [03:39]* ## [06:38] – Challenges and Breakthroughs Feldman recounts a high-stakes period between 2017 and 2019 when the team struggled to make the technology work while spending $8 million monthly. He emphasizes that while the technical breakthrough occurred in 2019, market demand only exploded once AI became an essential daily tool. > *We had a period between about 2017... and middle of 2019 where we couldn't build it. [07:34]* ## [08:37] – Crossing the Market Chasm Feldman describes the early years where Cerebras had superior technology but struggled to find a market, eventually finding success in supercomputing labs. A pivotal $1 billion order from sovereign partner G42 provided the capital and scale necessary to battle-test their hardware and prepare for the AI explosion. > *We had a 2 or three year period where we were ahead of the market and absolutely nobody cared that we were blisteringly fast. [09:00]* ## [10:38] – Scaling Software and Hardware Scaling a hardware company involves physical constraints like manufacturing lines, power requirements, and test fixtures that software companies do not face. Feldman also highlights the long-term nature of deep tech development, noting that building a high-quality compiler takes nearly a decade of engineering effort. > *When you're building things... you have to call your manufacturing partner... Each step takes real time and effort to grow. [11:24]* ## [12:03] – Relevance of AI-Generated Coding Cerebras has aggressively adopted AI-generated coding, with token spending per engineer increasing significantly to support the use of autonomous agents. Feldman observes that certain engineers are becoming '100x' contributors by governing multiple agents for coding and QA tasks. > *They've moved their coding style to being one in which they govern agents... they've gone from being sort of 10x guys to being 100x guys. [13:12]* ## [13:31] – Leadership and Hiring Culture With a $20 billion backlog and a growing team of over 800 people, Feldman emphasizes the need to avoid corporate malaise by continuing to take extraordinary risks. He views himself as a 'professional David' who thrives on solving problems that others deem impossible while competing against Nvidia. > *We would much rather fail in pursuit of the extraordinary than succeed in the ordinary. [15:01]* ## [17:16] – When to Quit vs. Persist Andrew Feldman describes himself as a 'professional David' who thrives on competing against larger incumbents through intellectual superiority. He emphasizes that founders must guard against the 'slippery slope' of persistence by using external mentors to hold them accountable to their original hypotheses. > *The slippery slope is a beast... you have to guard against it. [18:32]* ## [19:40] – Why Cerebras Went Public The transition to a public company is framed as a way to reduce the cost of capital and gain legitimacy with large-scale corporate clients. Feldman notes that Cerebras chose the IPO path to differentiate itself as the market's only 'AI pure play' revenue stream. > *For us it was an opportunity to graduate from corporate adolescence to corporate adulthood. [23:22]* ## [22:57] – The OpenAI Deal Feldman recounts the intense four-and-a-half-week period during which Cerebras finalized a $20 billion deal with OpenAI, driven by a sudden demand for fast inference. The deal moved at an unprecedented pace, involving constant work through the holiday season to meet technical requirements. > *For a 20 plus billion dollar deal to do it in four and a half weeks was exceptional. [24:59]* ## [25:54] – Open Source and Post-Trained Workloads Andrew Feldman highlights how the open-source ecosystem sustains market interest and pressures closed-source developers to innovate. He emphasizes that seeing external developers build creative solutions on Cerebras hardware is a core motivation for the company's infrastructure goals. > *You got to love other people's ideas to take flight on on what you built. [28:04]* ## [27:37] – How Speed Opens Up New Business Extreme speed in AI enables fundamental shifts rather than just incremental improvements, using Netflix's transition from DVDs to streaming as a primary example. Feldman argues that the ambition for speed is a competitive advantage, as seen in the rapid construction of data centers. > *when the internet got fast they became a movie studio right that's what happens with speed [28:38]* ## [30:07] – Conclusion Drawing parallels to the PC and cloud revolutions, Feldman predicts that AI will move beyond replacing specific tasks to fundamentally reorganizing how work is performed. This shift is expected to trigger massive jumps in global productivity as new business models emerge around the technology. > *once we start sort of fundamentally reorganizing around this, you're going to see this sort of new business models and fundamental jumps in productivity. [29:53]* ## Entities - **Andrew Feldman** (person): Co-founder and CEO of Cerebras - **Cerebras** (organization): AI hardware company known for wafer-scale engine technology - **OpenAI** (organization): AI research organization that signed a multi-billion dollar deal with Cerebras - **G42** (organization): A sovereign AI and technology holding company that placed a $1 billion order with Cerebras - **Nvidia** (organization): Leading GPU manufacturer and dominant competitor in the AI chip market - **Sarah Guo** (person): Host of No Priors and venture capitalist - **AWS** (organization): Amazon's cloud computing division deploying Cerebras hardware - **Netflix** (organization): Used as an analogy for how speed changes business models from delivery to production

Brian Halligan interviews Notion co-founder Ivan Zhao on his journey as a 'refounder' who navigated the company through its 2015 Kyoto restart and the 2023 generative AI pivot. Zhao details Notion's transition from a traditional SaaS structure to an AI-native 'jazz band' model that prioritizes technical versatility, taste, and agency over rigid hierarchies. The discussion explores how AI acts as the 'steel' for modern organizations, enabling flatter structures and faster, more reversible decision-making. ## [00:00] Introduction Brian Halligan introduces Ivan Zhao as the 'refounder' of Notion, highlighting his unique ability to restart the company during critical junctures in 2015 and 2023. The conversation sets the stage for Zhao's transition from a traditional SaaS management model to an AI-native organization. Halligan compares Zhao's approach to other tech visionaries like Jack Dorsey, emphasizing the importance of personal style and 'taste' in building a lasting brand. > *I like to think of him as the refounder... he's the canonical example of how a SAS company can move and become an AI company. [00:52]* > *We want to be a jazz band, not a marching band. [00:02]* ## [02:22] From Founder Mode to AI Org Ivan Zhao discusses his detour into traditional delegation and professional management before returning to a hands-on 'founder mode' necessitated by the AI shift. He explains that building with language models is less like predictable bridge engineering and more like 'brewing beer,' where the underlying technology dictates the development path. Zhao emphasizes hiring 'jazz band' people—versatile individuals like designers who code—to navigate the experimental nature of AI integration. > *Building with language model... is like brewing beer. You can't truly predict the things the underlying thing. [06:33]* > *The spirit is technology first-driven development rather than customer-driven first development. [07:01]* ## [11:00] Hiring for Taste and Agency Notion utilizes a 'barbell' hiring strategy that targets both super-junior and super-senior talent while avoiding the 'middle' of traditional SaaS experience. Zhao defines talent as the product of capability, taste, and agency, noting that AI has democratized basic capabilities like coding and writing. Consequently, the company now optimizes for 'agency' and 'taste,' qualities that remain difficult to automate and serve as the primary differentiators for the brand. > *capability got normalized democratized and taste becomes still important [11:53]* > *So the shape it's not it's more like the barbell barbell shape, right? [12:35]* ## [24:28] Refounding Notion in Kyoto In 2015, facing potential failure and low morale, Zhao and co-founder Simon Last laid off their entire staff and relocated to Kyoto, Japan, to rebuild Notion from scratch. This 'Kyoto Reset' allowed them to focus entirely on craft and coding while living a minimalist lifestyle. Zhao chose Kyoto specifically for its status as the 'craft capital of Asia,' which provided the spiritual inspiration needed to view software as a fundamental human tool. > *So my co-founder and I said let's just lay off everybody just go by the two of us. That's the Japan story. [25:41]* > *The story we tell ourselves is like Kyoto is a special place. If you can pull off anywhere, you can pull off from Reborn in Kyoto. [28:05]* ## [30:27] Craft Versus Commerce Zhao views Notion as part of a historical lineage of 'tools for thought,' tracing back to pioneers like Douglas Engelbart and Alan Kay. He criticizes modern Silicon Valley 'tinker culture' for ignoring the history and humanity behind technology. For Zhao, the goal is to find an equilibrium between the pure craft of an artist and the commercial viability of a business, ensuring the product has a 'soul' that resonates with users. > *Tech is like industry doesn't know its past. If you don't know his past you don't know history which is humanity. [31:52]* > *I need to be in equilibrium with my own value of what this company I want to build... [51:33]* ## [32:26] When to Refound For founders whose companies are stagnating, Zhao suggests listening to the 'inner urge' to take drastic action rather than wasting years on ventures without momentum. He argues that refounding is often harder than starting fresh because it involves taking a significant step back to pivot toward a new growth engine. Zhao believes the current AI-driven market is wide open, making it an ideal time for founders to be risk-seeking and follow their intuition. > *For me it's like there's you just feel you have to do something drastic... then you feel liberated once you land in Japan. [32:56]* > *The refounding is harder than it looks. It typically involves like a big step back and two steps forward. [59:57]* ## [34:07] GPT-4 Refounding Shock Zhao describes gaining early access to GPT-4 as a 'full body religious experience' that signaled a fundamental shift in the world. This realization forced a second refounding of Notion, as Zhao felt any work not involving this technology would soon become meaningless. The transition included a grueling 18-month period of low morale while the team waited for the underlying AI models to catch up with their ambitious product vision. > *GBD4 is a religious experience for me. It's like holy [ __ ]... anything you do if you don't do this it will be meaningless. [34:27]* > *that was like a year and a half just go with no error and morale is definitely low [35:50]* ## [45:35] Leadership and Founder Energy Despite being naturally introverted, Zhao explains how he forced himself to master one-to-many communication to build trust within Notion. He maintains a disciplined daily routine, starting at 7 AM and often working until midnight, while using 'guilty pleasure' reading to recharge. To prevent organizational calcification, Notion aggressively acquires startups to bring in 'founder energy,' currently employing over 50 former founders who lead critical domains. > *To lead the group of human you need to do one to many communications otherwise people don't trust you. [46:17]* > *founders are are kind of this kind of like little decalcified meatthead machinery just trying to break things [39:10]* ## [53:17] Sales Culture and Closing Thoughts Notion's transition to enterprise sales involved moving away from 'first-principle' experimentation toward established playbooks, pairing system thinkers with high-energy sales leaders. The conversation concludes with a vision of the 'AI-native' CEO playbook, which replaces traditional 'triangle' hierarchies with a 'circular' model. In this structure, a centralized AI system saturated with company context enables smaller teams to move at breakneck speed with reversible decision-making. > *You should only have each company should only preserve your innovation point to few places... [54:54]* > *All of those kind of one-way doors that Bezos used to talk about are really two-way doors... [62:39]* ## Entities - **Ivan Zhao** (person): Co-founder and CEO of Notion, known for his 'refounder' mindset. - **Brian Halligan** (person): Co-founder of HubSpot and interviewer. - **Notion** (organization): A productivity software company that pivoted to an AI-native model. - **Simon Last** (person): Co-founder of Notion who helped rebuild the company in Kyoto. - **Kyoto** (location): The Japanese city where Notion was restarted in 2015. - **GPT-4** (technology): The AI model that triggered Notion's second refounding. - **Steve Jobs** (person): Former Apple CEO cited as an inspiration for refounding and craft. - **Jack Dorsey** (person): Tech leader mentioned for his AI-centric organizational redesign. - **Douglas Engelbart** (person): Computing pioneer in the 'tools for thought' lineage. - **Erica** (person): CRO of Notion and former CRO of GitHub. - **SaaS** (concept): Software as a Service, the industry context for Notion's evolution. - **Jazz Band** (concept): Metaphor for a flexible, high-agency organizational structure.

Ivan Burazin, CEO of Daytona, discusses the massive shift from building developer environments for humans to providing composable computers for AI agents. With 74% month-over-month growth and 850,000 daily runs, Daytona provides the bare-metal infrastructure required for stateful, high-performance agentic workflows. This conversation explores the technical challenges of spiky compute, the $10 trillion computer-use market, and why the future AI cloud will look more like Stripe than AWS. ## [00:00] Hook Ivan Burazin describes the intense, direct demand for Daytona's infrastructure, with potential users calling him personally to request access. This level of interest signaled a massive, untapped market for providing execution environments to every future AI agent. The team realized they had identified a critical missing piece in the AI development stack. > *I've never experienced this that people literally call you if you do not give them access. Like they want access right now.* > *[0, 0]* > * ] }, { * > *title": "Introduction* > *{'start': 72.0, 'summary': "Host swyx introduces Ivan Burazin, noting their shared history in the developer experience and 'end of localhost' movements. Ivan recalls reaching out to swyx years ago for advice on developer experience while working at a previous role. They reflect on how their early interactions and mutual interests in cloud-based development tools eventually led to their current collaboration.", 'quotes': ['I was one of the co-founders of code anywhere... we were thinking a long time of like local host should die.', [1, 36], '\n ]\n },\n {\n ', 'title": "CodeAnywhere', 'Shift', 'and the end of localhost', {'start': 195.0, 'summary': 'Ivan discusses his long history with his co-founder, dating back to early 2000s virtualization and the creation of CodeAnywhere. As the first browser-based IDE, CodeAnywhere predated modern infrastructure like Docker and Kubernetes, which provided the team with deep foundational knowledge. After a successful run with the Shift developer conference, they returned to their infrastructure roots to launch Daytona.', 'quotes': ['We originally started stacking stacking servers doing like virtualization in the early 2000s... and that was a services company which we sold.', [3, 38], '\n ]\n },\n {\n "title": "What Daytona is: composable computers for AI agents",\n "start": 358.0,\n "summary": ', "Ivan defines Daytona as a provider of 'composable computers' for AI agents", "moving beyond the limited industry term 'sandboxes.' He explains that agents require diverse computing environments tailored to specific tasks", 'much like different hardware setups for human professionals. This API-driven infrastructure allows agents to execute code in production-grade environments rather than just temporary test boxes.', {'quotes': ['What Daytona is today is essentially composable computers for AI agents... the market calls them sandboxes which [is] misleading.', [6, 41], '\n ]\n },\n {\n ', 'title": "The pivot from dev environments to AI sandboxes', {'start': 487.0, 'summary': "Ivan explains how observing early agents like Devon and OpenHands led to a realization that AI agents require a dedicated compute runtime. While their initial SaaS offering for human automation saw low traction, it attracted developers who specifically needed sandboxes for their agents. This feedback loop revealed a massive, underserved market for agent-specific infrastructure that standard cloud providers weren't addressing.", 'quotes': ['a lot of people reached out that were building agents and they were like hey my agent needs a compute sandbox runtime', [8, 50], '\n ]\n },\n {\n ', 'title": "The New Year’s Eve MVP and customers begging for API keys', {'start': 617.0, 'summary': "On New Year's Eve, Ivan 'vibe-coded' the first MVP of what would become the new Daytona. Although the CTO initially dismissed the code as 'garbage,' the core idea was strong enough to warrant a two-week professional rebuild. When they demoed this version to previous skeptics, the response was immediate and overwhelming, with users demanding API access before the calls even ended.", 'quotes': ["I've never experienced this that people literally call you if you do not give them access.", [12, 18], '\n ]\n },\n {\n ', 'title": "Bare metal', 'stateful sandboxes', 'and Daytona’s scheduler', {'start': 776.0, 'summary': "The team approached the technical architecture from first principles, deciding to run on bare metal rather than traditional VMs. They aimed to combine the speed of AWS Lambda with the stateful, long-running nature of an EC2 instance. This allows agents to 'pause and come back' to their work, much like a human closing a laptop lid, without losing state or performance.", 'quotes': ["agents will be like humans in the sense of you don't want your laptop to be shut down until you're done with work", [13, 57], '\n ]\n },\n {\n ', 'title": "60ms startup', 50, 0, 'sandboxes', 'and 850K daily runs', {'start': 1048.0, 'summary': "Daytona's infrastructure is optimized for both individual speed and massive concurrency, with a single instance spinning up in just 60 milliseconds. This scale supports high-volume customers who perform nearly 850,000 runs daily, with some requesting capacity for half a million concurrent CPUs. The system utilizes a custom scheduler and local NVMe drives to eliminate network latency and maximize IOPS.", 'quotes': ['Our time to spin up one is 60 milliseconds with network latency... if you want to spin up 50,000 at once, we are now at about 75 seconds.', [17, 40], ',\n ', 'The biggest customer of ours does like about 850', 0, "every single day is sort of where they're where they're just shy of a million.", [18, 17], '\n ]\n },\n {\n ', 'title": "Spiky RL/eval workloads and the new agent infra problem', {'start': 1313.0, 'summary': "The 'spiky' nature of AI workloads presents a major challenge for compute providers, leading to a mean utilization rate of only 15% despite peaks hitting 90%. Workloads are categorized into 'background agents' that follow human cycles and 'evaluations/RL' which fire off massive bursts of activity at unpredictable hours. To manage this, Daytona must use capacity commits to handle sudden bursts of 100,000 or more CPUs.", 'quotes': ["Daytona's mean utilization is 15%... because it's very spiky. But it's very spiky but we get up to 90%.", [23, 1], '\n ]\n },\n {\n ', 'title": "RL workloads', 'Kubernetes pain', 'and dynamic resizing', {'start': 1692.0, 'summary': "Daytona competes primarily against managed Kubernetes services like EKS and GKS, positioning itself as a more ergonomic 'Twilio or Stripe' for compute. Unlike Kubernetes, Daytona offers a seamless API for spinning up sandboxes with significantly faster startup times. A key advantage is the ability to dynamically resize sandboxes on the fly to prevent out-of-memory (OOM) errors, a feature difficult to implement on other platforms.", 'quotes': ["Daytona although it's a compute provider it's more akin to a Twilio and Stripe from a consumption perspective than it is an AWS", [29, 46], '\n ]\n },\n {\n ', 'title": "Why every AI agent needs a computer', {'start': 2011.0, 'summary': "Ivan outlines the massive scale of knowledge work, estimating a $50 trillion global salary pool, much of which is locked in legacy Windows applications. He argues that true automation requires 'human emulators' that can interact with these legacy systems via GUIs when APIs are incomplete. By automating 40% of this work, the market opportunity for agentic computer use reaches approximately $10 trillion annually.", 'quotes': ['If you take 40% of that, you get to essentially like 10 trillion dollars a year.', [35, 20], '\n ]\n },\n {\n ', 'title": "macOS sandboxes and Apple’s licensing problem', {'start': 2328.0, 'summary': "The discussion shifts to the difficulties of hosting Mac OS sandboxes compared to Windows and Linux. Apple's restrictive licensing only allows two parallel VMs per machine and requires a 24-hour lock-in for users, making per-second billing economically unfeasible. Furthermore, security restrictions prevent moving memory snapshots between physical machines, severely limiting the scalability of agentic workloads on Mac hardware.", 'quotes': ['Apple is shooting itself in the foot... if it would just enable a concurrency model similar to what you can get on a Windows.', [40, 52], '\n ]\n },\n {\n ', 'title": "Why CLI may matter more than MCP', {'start': 2668.0, 'summary': "The discussion compares the Model Context Protocol (MCP) to the Command Line Interface (CLI) for agentic action. While MCP acts as an interface for APIs, the CLI allows agents to execute scripts and perform deep data analysis within a sandbox. This layer of indirection enables more complex agentic workflows beyond simple data retrieval, allowing agents to actually 'do things' rather than just integrate.", 'quotes': ['the MCP is an interface against an API whereas the CLI is like you can actually go do things... the difference between integrations and actually running scripts.', [45, 34], '\n ]\n },\n {\n ', 'title": "Open source', 'GitHub stars', 'and agent integration', {'start': 2891.0, 'summary': "Ivan details Daytona's transition to an AGPLv3 license for its sandbox product to balance openness with commercial protection. This 'copyleft' approach allows enterprise use but prevents competitors from building proprietary forks without contributing back. Keeping the core engine transparent builds trust with users and allows large enterprises to bypass lengthy security audits by providing agents with full context.", 'quotes': ["in the new sandbox product we did add a AGPL3... you essentially can't make a competitor without open sourcing your stuff.", [49, 49], '\n ]\n },\n {\n ', 'title": "Git', 'CI/CD', 'and agent collaboration bottlenecks', {'start': 3191.0, 'summary': 'Current versioning systems like GitHub are often too slow for the high-velocity output of AI agents, leading to bottlenecks in CI/CD pipelines. Some developers are creating makeshift solutions like dumping codebases into JSON files on S3 to bypass Git overhead. There is a growing need for an agent collaboration layer that precedes the traditional Git-based pipeline to handle companies generating over 1,000 PRs per day.', 'quotes': ["GitHub as-is was an overhead... it wasn't fast enough what they needed.", [54, 3], '\n ]\n },\n {\n ', 'title": "Founder life and building a 25-person infra company', {'start': 3495.0, 'summary': "Daytona's success stems from a core team of 13 people who have worked together for over seven years, fostering a high-trust culture. Ivan acknowledges the difficulty of the founder journey, including being away from family, but posits that growth requires 'pain.' He views his work as building the spiritual successor to serverless and Kubernetes for the agent era, requiring radical responsiveness as a differentiator.", 'quotes': ['Of the 25 people in Daytona, I think about 13 of them we have worked with seven years plus.', [58, 57], '\n ]\n },\n {\n ', 'title": "AI SaaS', 'token resale', 'and API-first business models', {'start': 3764.0, 'summary': 'Ivan presents a critical take on the SaaS ecosystem, arguing that the market is incorrectly applying a premium to vendors who simply resell AI tokens. He points out that these models have significantly worse margins than traditional SaaS. Instead, he advocates for companies to expose their data via APIs and charge for consumption, allowing for actual revenue acceleration through increased agentic usage.', 'quotes': ["The market is adding premium to SAS vendors that are reselling tokens. And I think that's incorrect.", [62, 54], '\n ]\n },\n {\n "title": ', 'GPU sandboxes', 'data centers', 'and compute growth', {'start': 3970.0, 'summary': 'Daytona plans to introduce GPU sandboxes to support workloads like 3D rendering and reinforcement learning on CAD, rather than focusing on inference. While the company currently runs on bare metal via colocation providers, Ivan notes they are architected to potentially own data centers in the future. He currently avoids the high capital risk of building data centers for single-digit margin gains.', 'quotes': ['We will [offer GPUs], but not for inference. Like essentially what we think about is like the GPU sandbox.', [66, 21], '\n ]\n },\n {\n ', 'title": "Why the AI cloud may look more like Stripe than AWS', {'start': 4188.0, 'summary': "The conversation concludes by imagining the 'AWS for AI Agents,' which Ivan suggests might look more like Stripe than a traditional cloud provider. This future 'AI Cloud' will integrate sandboxes, web search, and databases as fundamental primitives. While companies like Cloudflare and OpenAI are competing for this space, Ivan hints that many more infrastructure primitives for agents are yet to be developed.", 'quotes': ["There will be a cloud built out specifically for agents and so that cloud will have sandboxes and it will have web search and it'll have databases.", [70, 47], '\n ]\n },\n {\n ', 'title": "Closing thoughts', {'start': 4286.0, 'summary': 'The discussion ends with the observation that the AI infrastructure market is growing at an unprecedented baseline of 40-75% month-over-month. Ivan and swyx reflect on the race to secure hardware and the shift toward specialized agent clouds that will define the next decade of computing.', 'quotes': ["The entire infrastructure market is growing 40% plus or minus month over month... if you're not growing 40%ish... you don't have to come to work.", [68, 23], '\n ]\n }\n ],\n ', 'entities": [\n {\n "name": "Ivan Burazin', {'type': 'person', 'description': 'CEO of Daytona and co-founder of CodeAnywhere.'}, {'name': 'swyx', 'type': 'person', 'description': 'Host of Latent Space and early investor in Daytona.'}, {'name': 'Daytona', 'type': 'organization', 'description': 'A company providing composable computers and sandboxes for AI agents.'}, {'name': 'CodeAnywhere', 'type': 'organization', 'description': 'The first browser-based IDE, co-founded by Ivan Burazin.'}, {'name': 'Devon', 'type': 'product', 'description': 'An early AI software engineer agent.'}, {'name': 'OpenHands', 'type': 'product', 'description': 'An open-source AI agent project formerly known as OpenDevin.'}, {'name': 'Kubernetes', 'type': 'technology', 'description': "Orchestration technology mentioned as a competitor to Daytona's ergonomic API."}, {'name': 'Apple', 'type': 'organization', 'description': 'Mentioned regarding restrictive Mac OS virtualization licensing.'}, {'name': 'Salesforce', 'type': 'organization', 'description': 'Cloud-based software company mentioned for its API-first strategy.'}, {'name': 'GitHub', 'type': 'organization', 'description': 'Developer platform noted for being a bottleneck in agentic CI/CD workflows.'}, {'name': 'Nvidia', 'type': 'organization', 'description': 'The primary provider of GPUs whose supply constraints dictate market growth.'}, {'name': 'Stripe', 'type': 'organization', 'description': 'Used as a comparison for the consumption-based model of the future AI cloud.'}], 'tags': ['ai-agents', 'infrastructure', 'sandboxing', 'bare-metal', 'cloud-computing', 'developer-tools', 'computer-use', 'saas-growth'], 'seo_title': "AI Agents Need Computers: Ivan Burazin on Daytona's Pivot", 'seo_description': 'Ivan Burazin explains why AI agents need composable computers and how Daytona pivoted from dev environments to 850K daily agent runs.', 'confidence': {'score': 0.98, 'rationale': 'The summary synthesizes multiple detailed chunks covering technical metrics, business strategy, and market philosophy with high fidelity to the source.'}}]}]}]}]}]}]}]}]}]}]}]}]}]}]}]}]}]}]}* ## [01:12] Introduction ## [03:15] CodeAnywhere, Shift, and the end of localhost ## [05:58] What Daytona is: composable computers for AI agents ## [08:07] The pivot from dev environments to AI sandboxes ## [10:17] The New Year’s Eve MVP and customers begging for API keys ## [12:56] Bare metal, stateful sandboxes, and Daytona’s scheduler ## [17:28] 60ms startup, 50,000 sandboxes, and 850K daily runs ## [21:53] Spiky RL/eval workloads and the new agent infra problem ## [28:12] RL workloads, Kubernetes pain, and dynamic resizing ## [33:31] Why every AI agent needs a computer ## [38:48] macOS sandboxes and Apple’s licensing problem ## [44:28] Why CLI may matter more than MCP ## [48:11] Open source, GitHub stars, and agent integration ## [53:11] Git, CI/CD, and agent collaboration bottlenecks ## [58:15] Founder life and building a 25-person infra company ## [1:02:44] AI SaaS, token resale, and API-first business models ## [1:06:10] GPU sandboxes, data centers, and compute growth ## [1:09:48] Why the AI cloud may look more like Stripe than AWS ## [1:11:26] Closing thoughts

This session introduces Claude Managed Agents, a suite of API endpoints designed to help developers build and deploy production-ready AI agents with built-in tools, security, and observability. The speaker outlines how core primitives like Agents, Environments, and Sessions enable complex workflows such as multi-agent coordination and human-in-the-loop controls. ## [00:00] Introduction to Managed Agent Primitives Anthropic introduces Claude Managed Agents as a suite of API endpoints providing production-ready primitives like tool calling, error recovery, and memory management. The architecture relies on 'Agents' as templates for skills, 'Environments' for sandboxed execution with granular permissions, and 'Sessions' to maintain ongoing conversational context and state transitions. > *Claude Managed Agents at a high level is just a set of API endpoints that we've developed and released... that give you access to scaled ready, production ready agent. [01:35]* ## [07:54] Secure Connectivity and Sandboxing The platform supports self-hosted sandboxes, allowing developers to use private containers and VPCs to keep sensitive data secure while maintaining model access. Additionally, new MCP tunnels facilitate safe connections to internal Model Context Protocol servers, and Credential Vaults protect authentication tokens by keeping them out of the model's context window. > *Claude can directly connect to that safely without those MCP servers ever being exposed on the internet. [09:40]* ## [10:02] Multi-Agent Orchestration and Implementation A demonstration of a multi-agent architecture shows a coordinator agent spawning specialized sub-agents for complex tasks like financial analysis and macro trend research. Developers can implement these workflows using the Anthropic SDK and tools like Claude Code, which is specifically optimized to help developers implement and iterate on managed agent APIs. > *One agent is like in charge of figuring out macro trends... whereas another one is like really good at like financial analysis. [11:36]* ## [19:28] Observability, Memory, and Infrastructure The Claude Console provides robust observability, including agent versioning, session monitoring, and the ability to edit memory stores to correct agent context. By providing integrated state transitions and durable storage out of the box, the service eliminates the need for developers to build complex custom agent loops and sandboxing fleets manually. > *With cloud manage agents, we kind of were able to get all of these things out of the box. [26:54]* ## Entities - **Anthropic** (organization): The AI research and safety company that developed the Claude model family. - **Claude Managed Agents** (software): A suite of API endpoints for building and hosting production-ready AI agents. - **MCP** (protocol): Model Context Protocol used for secure authentication and tool integration. - **Claude Code** (software): A developer tool optimized for implementing and managing Anthropic APIs. - **Bun** (software): A fast JavaScript runtime used for the technical implementation demonstrations. - **Cloudflare** (infrastructure): A cloud provider mentioned as a host for private sandboxes and environments. - **Credential Vaults** (feature): A secure storage system for authentication tokens that prevents exposure to the model. - **Memory Stores** (feature): Persistent storage allowing agents to retain and retrieve information across sessions.

Anthropic engineers Michael and Harrison introduce Claude Managed Agents, a platform designed to simplify the infrastructure, security, and observability required for deploying autonomous AI agents. By handling complex backend tasks like sandboxing and identity management, the system enables developers to transition from simple tool use to long-running, outcome-oriented agentic workflows. ## [01:10] The Evolution of Agentic Infrastructure Michael and Harrison trace the progression of AI from basic function calling to autonomous agents capable of managing full feature development and PRs. They argue that infrastructure, rather than model intelligence, is now the primary bottleneck for achieving productivity where months of work are completed in hours. > *where we think we're seeing things going in the future is entire quarters worth of work being able to be getting accomplished within a couple of hours.* > *[2, 34]* ## [04:22] Core Primitives and Configuration The platform provides composable primitives for context management, observability, and secure sandboxing, allowing developers to define agents via system prompts and MCP tool configurations. Features like the 'Ask Claude' button and event streams provide real-time transparency and optimization suggestions for agent sessions. > *we did all of that platform work so that you don't have to so that you can kind of pick and choose the primitives that we have available.* > *[5, 26]* ## [10:05] Advanced Orchestration and Memory Beyond single-task execution, the platform supports multi-agent orchestration where Claude can spawn sub-agents to delegate work. Advanced features like 'Dreaming' allow agents to reflect across thousands of sessions, improving long-term memory and task performance through autonomous reflection. > *It allows Claude to spawn other agent threads with their own context windows in order to delegate work to them.* > *[10, 55]* ## [11:56] Sandboxing and Secure Connectivity Anthropic offers self-hosted sandboxes and MCP tunnels to give enterprises control over network policies and audit logs while exposing private data securely. Partners like Vercel, Modal, and Cloudflare provide specialized infrastructure, ranging from lightweight isolates for rapid scaling to high-performance GPU clusters. > *MCP tunnels are basically just a way for you to get your private MCPs in your network exposed to cloud manage agents.* > *[13, 25]* ## [20:19] Real-World Automation and Optimization Companies like DoorDash and Modal are using agents for complex technical tasks, such as autonomous account management and inference tuning. By running tools like the Nvidia profiler, agents can autonomously 'hill climb' performance benchmarks to optimize workloads without human intervention. > *Claude can optimize training loops... it'll run like the Nvidia profiler. It'll read the profiles and uh it'll just go ham and and make things better.* > *[20, 39]* ## [25:23] Future Challenges: Identity and Collaboration As agents become primary users of compute, the industry faces new hurdles in identity management, egress filtering, and task resumability. The future of AI involves moving from rigid execution to collaborative 'multiplayer' environments where agents and humans dynamically pivot based on feedback. > *how do we properly assign identity all the way down the chain such that it's only getting access to the right data* > *[25, 55]* ## Entities - **Anthropic** (organization): The AI safety and research company behind the Claude model family. - **Claude Managed Agents** (product): A platform and infrastructure suite for building and deploying autonomous AI agents. - **Michael** (person): Member of Technical Staff at Anthropic working on managed agents. - **Harrison** (person): Member of Technical Staff at Anthropic working on managed agents. - **MCP** (protocol): Model Context Protocol used for tool configuration and secure tunnels. - **Cloudflare** (organization): A cloud services provider focusing on sandboxing technologies like MicroVMs and isolates. - **Modal** (organization): A compute platform specializing in high-scale GPU sandboxes and AI workloads. - **Vercel** (organization): A partner providing fluid compute infrastructure for agent sandboxes.

Chris Merrick, CTO of Omni, details the development of 'Blobby,' an agentic analytics harness powered by Anthropic's Claude models. By combining a robust semantic layer with internal dogfooding of Claude Code, Omni enables users to translate natural language into complex data visualizations while maintaining high engineering velocity. ## [00:07] Engineering Velocity with Claude Code Chris Merrick explains how Claude Code has transformed Omni's internal development, allowing a small team of 25 to maintain high commit velocity. Even as CTO, Merrick uses the tool to stay technically involved, leveraging the efficiency of the Claude Opus model to contribute code alongside his team. > *I thank Claude very much for making me uh still able to do some software engineering from time to time. [01:12]* ## [03:14] The Semantic Layer and Business Context To bridge the gap between general LLM knowledge and specific business data, Omni utilizes a semantic layer that provides essential context like fiscal definitions and table relationships. This layer acts as a permissions and curation tool, ensuring the AI agent understands the unique nuances of a company's data environment. > *Claude is incredible at answering questions, but you need to tell it more about your business if you want it to answer questions about your business. [04:03]* ## [11:15] Architectural Evolution and the 'Blabbotomy' The team evolved their AI agent, Blobby, from a simple Q&A tool into a sophisticated harness by upgrading from Claude Haiku to Sonnet for better multi-turn performance. They addressed 'split-brain' errors—where sub-agents and outer agents failed to communicate—by consolidating all tools into a single, unified agentic brain. > *You want to be careful not to have a split brain between any sort of sub agent system and outer agent system. [15:57]* ## [16:23] Leveraging SQL and CTE Proficiency Omni shifted its query strategy from a proprietary JSON format to standard SQL to better leverage Claude’s inherent proficiency with complex Common Table Expressions (CTEs). This transition allowed the agent to handle difficult data questions in a single pass, significantly improving the accuracy of generated reports. > *Claude really likes to write SQL with CTE, common table expressions... and our parser was really good at parsing those [18:27]* ## [19:09] Evals, Observability, and UI Validation Merrick emphasizes that rigorous evaluation systems and raw trace observability are critical for ensuring the predictability required by executive users. Omni follows a 'build with AI, validate with UI' philosophy, where Blobby generates the initial dashboard and users use a workbook interface to refine and troubleshoot the results. > *Our philosophy from a product perspective is AI to build, UI to sort of validate and troubleshoot and refine. [23:21]* ## Entities - **Chris Merrick** (person): CTO and Co-founder of Omni who leads the engineering team and advocates for AI-driven development. - **Omni** (organization): An AI analytics platform that enables users to query data using natural language. - **Claude** (ai-model): The family of LLMs from Anthropic that powers Omni's analytics and internal engineering. - **Claude Code** (software): An AI-powered coding tool that significantly increased Omni's development velocity. - **Blobby** (ai-agent): Omni's AI data analyst agent designed to interpret and answer complex data questions. - **SQL** (technology): The query language that Omni's semantic layer generates to interact with data warehouses. - **Claude Sonnet** (ai-model): The specific Anthropic model used to unlock performance gains in complex agentic conversations. - **GitHub** (platform): The source of pull request (PR) data used in the agent's demonstration.

Sid Budhiraja, a founding engineer of Claude Code, gave this keynote at Anthropic's Code with Claude conference to address a specific waste pattern: engineers spending most of their time staring at a screen waiting for Claude to finish, or acting as a "glorified QA tester." The talk lays out three escalating strategies—verification, parallelization, and background loops—that together let Claude run largely unsupervised. No captions existed on YouTube; transcript generated via Gemini Flash transcription (paragraph-level only, no word timestamps). ## [00:02] Opening & prerequisites Sid frames the talk as a "Claude Code 301" class and opens with a quick audience poll. Three things he calls table stakes: a high-quality CLAUDE.md file ("the single highest leverage thing you can do"), connecting external tools like Slack, Linear, and BigQuery to Claude Code so it can stitch together richer context, and setting up Claude Code on the web so that sessions are decoupled from the engineer's laptop and keep running even when the machine is closed or offline. He then lays out the structure for the rest of the talk: verification, multi-Clauding, and background loops—each building on the previous one. > *"A good rule of thumb is that if a tool is useful for you in your day-to-day life, it will also be useful for Claude. So things like Slack, Asana, Linear, Datadog, BigQuery—all of these things help Claude stitch together a much richer context for itself."* ## [05:14] Teaching Claude to verify its own work Sid asks the audience to recall how they personally verified their last feature: write code, build, run, check side effects, check logs, check the database, run unit tests, deploy to staging. That exact playbook, he argues, is also what Claude can run—if given the right tools and instructions. The key mechanism is the **loop**: an autonomous circuit where Claude writes code, hits a failure, debugs, writes more code, and keeps cycling until it reaches a success state. Once in a loop, Claude hill-climbs on a task without the engineer in the hot path. The loop works across front-end (browser-driven smoke tests), back-end (API checks), and full end-to-end flows—the principle is identical in each case. To package and distribute a verification loop, Sid recommends a **skill file**—a markdown document that stores the instructions and tool configuration for a specific verification task. Skills can be made self-improving: if you instruct Claude to update the skill every time it hits a new blocker, the document grows into a self-documenting playbook that benefits the whole team. > *"A loop essentially is an autonomous circuit that you can complete for Claude. And it allows Claude to hill climb on a given task or a given success criteria."* ## [15:46] Demo: building a verification loop live Sid demos against MonkeyType, an open-source TypeScript/Express/MongoDB/Redis typing-test application, chosen because it represents a realistic full-stack production app. Starting from a fresh Claude Code session, he tells Claude to spin up the dev server, then instructs it to use the `/chrome` Chrome MCP tool to navigate to localhost, type some text, and change a settings value—manually walking it through a basic smoke test. Once that hand-held session is complete, he tells Claude to take everything it just learned and write it into a skill file at `.claude/demo-verification`. Claude produces a skill with three sections: bring up the stack, load Chrome MCP tools, run a smoke test. He then asks Claude to build a new feature—a confetti animation on every mistype—and use the newly created verification skill to verify its own work. Claude writes the feature, hits ESLint errors, fixes them, reloads the app, and keeps cycling until the confetti appears. > *"You see the verification loop in action now where it's—it wrote some code, it encountered some issues, it fixed those issues by writing some more code, and it kind of went in a circle doing that until it came to a good state."* ## [26:38] Multi-Clauding without losing your mind Running multiple Claude instances simultaneously taxes attention, Sid's personal limit being four or five sessions before cognitive load becomes unmanageable. He covers four tools for scaling past that ceiling. The **Claude Code Desktop app** provides a unified sidebar showing all sessions across local terminal, cloud, and GitHub—sessions sorted by attention demand, color-coded, renamable. The terminal alternative is **Claude Agents** (`claude agents`), released roughly a week before the talk, which surfaces the same session list inside the terminal and sorts by urgency so the sessions that need a decision bubble to the top. **Claude Code on the Web** (claude.ai/code) runs sessions in Anthropic's cloud, fully decoupled from the engineer's hardware. And **Remote Control** (`/remote-control`) mirrors any running session to the mobile app with push notifications, so the engineer can answer Claude's questions from a car or between meetings without opening a laptop. > *"Remote Control essentially gives you the option to control any session running on any surface with your phone. If Claude needs some help from you or needs your input, your phone will buzz and you could be in your car, doing whatever you want, and you could just give Claude the input that it needs."* ## [32:41] Background loops and routines Even with good multi-session tooling, the engineer still decides when to start each session and what goal to give it. Background loops remove that last manual step. Sid describes the `/loop` command: `/loop 10 minutes "babysit my open PRs"` wakes up a Claude Code session every ten minutes, runs that prompt autonomously, and handles review comments, merge conflicts, and CI failures without the engineer watching. **Routines** are `/loop` running in Anthropic's cloud infrastructure—the same remote containers that power Claude Code on the Web. The Claude Code team itself runs two routines: one that updates docs daily, and one that scans issues and feedback and posts a summary to their Slack channel every six hours. With verification ensuring Claude's output is reliable, multi-Claude tools protecting attention across parallel sessions, and routines handling recurring bookkeeping, the engineer's role shifts from babysitter to delegator. > *"You can kind of spend your attention and your time on the tasks that you care about, and everything else can just be delegated to Claude—with high reliability and a high degree of confidence."* ## Entities - **Sid Budhiraja** (Person): Founding engineer of Claude Code at Anthropic; presenter of this keynote. - **Anthropic** (Organization): Creator of Claude and Claude Code; hosted the Code with Claude conference. - **Claude Code** (Software): Anthropic's agentic coding tool; central subject of the talk. - **Verification loop** (Concept): An autonomous write-check-fix cycle that lets Claude iterate on a task until it reaches a defined success state without human intervention. - **MonkeyType** (Software): Open-source TypeScript typing-test app (Express + MongoDB + Redis) used as the live demo target. - **Chrome MCP** (Software): Model Context Protocol tool (accessed via `/chrome`) that gives Claude programmatic control of a browser for UI verification. - **Routines** (Concept): Cloud-side scheduled Claude Code sessions with time-based or event-based triggers, enabling fully autonomous recurring tasks. - **Remote Control** (Concept): Feature (`/remote-control`) that mirrors Claude Code sessions to the mobile app with push notifications, enabling async oversight from anywhere.

Fabian Hedin, Cofounder and CTO of Lovable, walked through two production systems his team built to stop non-technical users from getting permanently blocked: Lovable Overflow, a self-maintaining corpus of issue-solution pairs injected into the agent's context at inference time, and a "vent" tool that lets the agent itself flag platform failures and auto-open PRs for engineers to review. Together they cut the platform's stuck rate by 5% — an improvement on par with a full model generation upgrade — and now drive roughly ten merged fixes per day from agent-filed pull requests. ## [00:20] From GPT-Engineer to 600 million monthly visits Lovable's lineage traces back 35 months to GPT-Engineer, a terminal program co-founded by Anton that briefly became the fastest-growing repository on GitHub. The demo — asking for a snake game, watching the model generate and execute the code end-to-end — signaled what LLMs could do for software creation, but the abstraction wasn't ready for a non-developer audience in mid-2023. Fabian marks a turning point around eighteen months ago when the chat-plus-preview model started clicking, and every three months since then a new foundational model has pushed the envelope further. Today the platform hosts 15 million projects. More telling: the sites built on Lovable collectively receive 600 million monthly visits, far more than Lovable's own traffic — evidence that users are shipping things with real reach. > *"We have 15 million projects built on the platform. We have 600 million monthly visits to the sites built on Lovable. And I think this is an interesting statistic because it's significantly more than what Lovable has itself."* ## [04:22] Production software for the 99%: why non-technical users get stuck Lovable targets the 99% of people who can't code — and deliberately holds itself to production-grade quality, not just prototyping. That combination makes the job harder than building for expert developers. When an expert gets stuck they can read the error, switch the library, or escalate to a developer-experience team. A non-technical user working at Lovable's abstraction layer — where the code is mostly out of sight — has none of those escape hatches. Fabian applies the classic software maxim: the first 90% of code takes 90% of the time, and the last 10% takes another 90%. The pattern holds in the AI era: vibe-coding gets you to a first version fast, but finishing, bug-free, takes even longer. Getting "hard stuck" in that final stretch is the worst possible user experience Lovable can deliver. > *"If they get stuck, it's a very bad experience for them. It's kind of the worst thing that can happen to them because it's much harder for them to get unstuck."* ## [09:55] Defining stuck: the is_stuck metric and three failure buckets Lovable's `is_stuck` flag fires when a user asks for the same thing three times in a row, when they explicitly complain about the output, or when they prompt and then abandon the session. A small classification model evaluates each conversation to set this signal. The team maps stuck scenarios into three buckets. The first is promptable — a differently-worded message, or slightly more context, would have solved it; Lovable's goal is to fix these before the user even realizes they need to re-prompt. The second is a platform gap: something the agent should handle but a missing or broken tool prevents it. The third is a large infrastructure investment — for example, Lovable shipped only client-side-rendered SPAs for a long time, which hurt SEO-conscious builders; they shipped server-side rendering the week of this talk. Each bucket demands a different fix, but all three share the same core vision. > *"Really our vision with Lovable on the technical side is that every app that is built on the platform should help improve the next."* ## [13:15] Lovable Overflow: fleet knowledge that routes around errors Named in honor of Stack Overflow, Lovable Overflow is a growing corpus of problem descriptions paired with solutions, harvested from real user sessions. When a user reports laggy scrolling, a lightweight retrieval model searches the corpus for similar descriptions, and if a match is relevant it injects a synthesized fix into the main agent's context — not as raw text but reformatted to fit the current situation. The harder engineering problem is keeping the corpus honest. Knowledge grows stale when a JavaScript package ships a fix, or when a new foundational model already has the fix baked into its weights. Lovable tracks a success ratio for every entry and prunes records that stop working — including entries whose embedded knowledge is now redundant in a newer model. The tension between adding new knowledge and retiring old knowledge turned out to be as important as the retrieval mechanism itself. > *"For every knowledge file we'll track its success ratio and we'll actually just remove it and prune it from the knowledge if it is outdated. So we'll continuously review every piece of knowledge in our system and make sure that it's pruned when it's no longer helpful."* ## [17:45] Venting: letting the agent report its own frustrations The second self-healing mechanism inverts the feedback loop: instead of Lovable engineers watching for failures, the Lovable agent itself files a report when it's blocked. A tool called `vent--send_feedback` is in the agent's toolset with a prompt asking it to call the tool "once per user message when tooling, docs, or platform behavior materially slows or degrades your work." The agent's complaint lands in a Slack channel, a monitor agent de-dupes and investigates, and if the issue is real, it opens a pull request for an engineer to review. About 50% of the auto-generated PRs make sense and get merged. One example: the agent hit a space-in-filename bug in the `code--copy` tool, tried URL encoding and other workarounds, then vented — and a fix was in production ten minutes later. A second example went further: the Lovable agent complained about Framer Motion's TypeScript easing types, implying the open-source library itself could benefit from a PR. Fabian floated the idea of letting the agent contribute fixes upstream to the wider JavaScript ecosystem. The vent channel also became an unexpected early-warning system. Production incidents — inference downtime, missing sandboxes, network-level failures — show up as spikes in vent volume before conventional monitoring alerts fire. In one meta case, the agent vented 43 times in a session, then filed a PR suggesting de-duplication logic to stop spamming its own creators. > *"Several times now this Slack channel with the agent venting has been kind of the first signal for us to identify a production incident. And even if it's not the first signal, it has actually become a very helpful tool for engineers to debug what is going on."* ## [26:12] Results, lessons, and what comes after self-healing Lovable Overflow reduced the stuck rate by 5% and lifted the publish rate by 2% in its first version — before incremental tuning since then. Fabian frames the 5% number in context: that's roughly the improvement Lovable sees when it upgrades to an entirely new model generation. The venting pipeline merges about ten platform fixes per day. Three lessons stood out. First, failure-mode knowledge is model-specific: when a new foundational model ships, existing Lovable Overflow entries need revalidation because some will be redundant and others will need rephrasing for the model's different behavior. Second, knowledge has a half-life — even fixes that were correct become wrong as libraries evolve. Third, an earlier attempt at this system failed not because the idea was bad but because the success signals were too coarse to tune against; 15 million apps and 200,000 new projects per day give Lovable enough signal to make it work now. Beyond these two systems, the team is fine-tuning on fleet data and building out eval coverage to gate every model release. Fabian's closing frame: Lovable users arrive with strong intent to ship real products, and when they leave stuck, that's a failure Lovable owns — the entire self-healing apparatus exists to close that gap. > *"The stuck rate is reduced by 5%. That might not sound like a big number, but in reality that is on the same order of magnitude in what we would see this metric move if we had a new generation of a foundational model in our system."* ## Entities - **Fabian Hedin** (Person): Cofounder and CTO of Lovable; delivered this keynote at Code with Claude 2026 - **Lovable** (Organization): AI software builder for non-technical users; 15M projects, 600M monthly visits to hosted sites - **Claude** (Software): Foundational model powering Lovable's agent at consumer scale - **GPT-Engineer** (Software): Open-source terminal tool co-founded by Anton (Lovable co-founder); became the fastest-growing GitHub repo in 2023 and evolved into Lovable - **Lovable Overflow** (Concept): Fleet-learning knowledge corpus — problem/solution pairs harvested from real sessions, injected into the agent's context, and continuously pruned by success ratio - **Venting / vent--send_feedback** (Concept): Agent-side tool that files platform failure reports to Slack; a monitor agent de-dupes and auto-opens PRs for engineer review - **is_stuck** (Concept): Binary metric that flags when a user has repeated the same request three times, complained about output, or abandoned a session after prompting - **Framer Motion** (Software): TypeScript animation library; cited as an example of an open-source dependency the Lovable agent identified as having a suboptimal type API

Niklas Gustavsson, Spotify's Chief Architect and VP of Engineering, walks through how a 3,000-person engineering org went from 0 to 99% AI tool adoption in months — and what that does to your product development constraints. The talk covers three concrete systems Spotify built: FleetShift for fleet-wide automated migrations, Honk as a background Claude-powered coding agent, and Backstage as the structured environment that makes agents reliable at scale. The central argument is that the same standardization practices that made human teams fast now make agents fast too. ## [00:18] Spotify's AI adoption surge Spotify's adoption of AI coding tools didn't grow gradually — it inflected sharply around the Claude Opus 3.5 release in November 2024. Within months, 99% of engineers used AI tools weekly, 94% reported meaningful productivity gains in the latest internal survey, and PR frequency jumped 76%. Niklas notes he had to update the PR frequency slide while preparing it because the numbers kept rising. The volume shift is also qualitative: by now, the majority of PRs shipped at Spotify are co-authored by an AI agent together with the developer, not written by a human alone. > *"Today more than 99% of our engineers use AI coding tools every week. And in the latest [survey], 94% of our engineers reports that using AI tooling has helped them become more productive."* ## [03:52] FleetShift: automating fleet-wide maintenance before AI Spotify's pre-AI problem was that its production codebase was growing seven times faster than the engineering headcount. That meant engineers spent progressively more time on maintenance — version bumps, API deprecations, security patches — leaving less capacity for new features. The answer was FleetShift, a fleet management system that treats those changes as coordinated mutations across thousands of repositories rather than per-component manual work. By the time AI entered the picture, FleetShift had already automerged 2.5 million maintenance PRs with no human in the loop: automation creates the PR, validates it in CI, and merges it. That infrastructure became the orchestration layer that Honk would later plug into. > *"Today up until today we've now merged two and a half million of those automated maintenance PRs. Work that our developers did not have to do."* ## [07:38] Building Honk — a background coding agent on Claude's Agent SDK Simple rule-based scripts work fine for config changes and dependency bumps, but fall apart on anything involving actual code modifications. Code has, as Niklas puts it, a very wide API surface — there are many ways to call the same method, and when you run a migration script across millions of lines and thousands of repos, you hit every corner case (a phenomenon with a name: Hyrum's Law). That brittleness was the forcing function for Honk. Honk is today a Claude-based coding agent wrapped inside a Kubernetes pod, scheduled by FleetShift, and equipped with CI tools so it can run builds, catch compile errors, and self-correct before opening a PR. A Java version migration that previously took multiple teams months now takes a single engineer three days. > *"Instead of writing these deterministic scripts to do these code modifications, can we use an LLM for this? [...] Out of this came a tool that we now called Honk."* ## [11:34] Honk V2 and multiplayer agent sessions Developers at Spotify quickly figured out how to invoke Honk over Slack — at-mentioning it mid-conversation and getting a PR back. That grassroots pattern pushed the team toward a more interactive product model. Honk V2, released in alpha during Hack Week the day before this talk, adds two layers on top of the original batch-migration use case. The first is integration with Chirp, Spotify's internal agent orchestration layer, which lets developers run many concurrent Honk sessions and coordinate them. The second is multiplayer: shared sessions where multiple developers can give feedback to the same agent instance simultaneously — described as "Google Docs but for Claude." Projects group those sessions into a shared workspace tracking a longer-horizon goal. > *"Basically imagine, uh, Google Docs or something similar, but for Claude."* ## [14:43] Standardization as agent infrastructure Spotify has operated for more than a decade on the principle that fewer technologies means faster execution. Limiting the stack reduces decision fatigue, makes cross-team collaboration easier, and lets engineers go deep on a smaller surface rather than maintaining breadth. That same principle, Niklas argues, directly improves agent performance. The mechanism is empirical: Spotify sees Claude produce noticeably worse outputs in their more fragmented codebases and better outputs where the stack is uniform. Backstage — their developer portal and software catalog — is the enforcement layer. It exposes component ownership, technology radar recommendations, and a "Golden State" spec for each component type. A Soundcheck UI lets teams self-assess compliance. Critically, all of these are also exposed as MCP servers and CLI tools so agents can query them directly. When Honk makes a code change, lint checks give it immediate feedback if it's using an off-radar pattern, and Niklas watches Claude self-correct against those checks in real time. > *"If Claude has a lot of other code to look at and that code looks roughly consistent, Claude will do better job. That's what we're seeing. And we actually have codebases that are more fragmented, and we can actually see Claude perform worse in those codebases."* ## [22:15] What happens when coding stops being the bottleneck The sprint Niklas closes with is a reframing: the AI transition hasn't removed constraints from product development, it has relocated them. Coding used to be where time went; now that constraint is loosening, the bottlenecks are moving to human decision-making — which ideas to pursue, which PRs actually need a human reviewer, which prototypes are worth fleshing out. On the PR review side, 76% more PRs means developers are drowning in review requests. Spotify's response is to auto-approve the low-risk ones and focus human attention where it matters. On the prototyping side, Spotify now lets anyone — including executives — open Claude in the client monorepo with a set of skills and infrastructure, prompt a feature, and get an installable app back in minutes rather than days. The talk ends with Niklas noting that in six months, Spotify's entire product development process will look fundamentally different from anything they've done before. > *"Claude and agents allows us to allow anyone to prototype in our actual production codebase. [...] This has brought prototyping for something that could take days or weeks to literally taking minutes now."* ## Entities - **Niklas Gustavsson** (Person): Chief Architect and VP of Engineering at Spotify; delivered this keynote at Anthropic's Code with Claude conference - **Honk** (Software): Spotify's internal background coding agent, built on Anthropic's Agent SDK running in Kubernetes pods; integrates with FleetShift for fleet-wide migrations - **FleetShift** (Software): Spotify's fleet management and migration orchestration platform; schedules and tracks automated PRs across thousands of repositories; has automerged 2.5 million PRs - **Backstage** (Software): Spotify's open-source developer portal and software catalog; exposes component ownership, Golden State compliance, and MCP/CLI interfaces consumed by agents - **Chirp** (Software): Spotify's internal agent orchestration layer; allows running many concurrent agent sessions and coordinating multi-developer shared sessions - **Hyrum's Law** (Concept): Principle (named after a Google engineer) that any observable behavior of a system will be depended on by some user — explaining why generic migration scripts break at scale across large codebases - **Golden State** (Concept): Spotify's per-component-type specification of recommended technologies and practices; the standard Soundcheck measures compliance against

Prof. Michael I. Jordan challenges the anthropomorphic framing of AI, arguing for a view of intelligence rooted in collective human systems and economic theory. He critiques "superintelligence" narratives as demoralizing distractions and advocates for a shift toward viewing AI as an ecosystem that facilitates human collaboration and job creation. By integrating microeconomics, game theory, and statistical rigor, Jordan proposes a new engineering discipline focused on system-level safety and social welfare. ## [00:00] Cold open: A demoralizing message to young builders Michael I. Jordan criticizes the trend of anthropomorphizing AI, calling it a distraction from real-world problem-solving. He expresses concern that "doomer" narratives about humanity's extinction are demoralizing to young engineers who want to build helpful technology. He argues that these leaders lack economic thinking and are detached from the reality of how systems are built. > *I think this anthropomorphizing of intelligence and understanding all that is not necessary, not appropriate, and is is a distraction [00:21]* > *It's gonna wipe out humanity with a with a high probability... That is so demoralizing. [01:12]* ## [02:04] CyberFund sponsor read Host Tim Scarfe introduces CyberFund, a venture firm looking for "AI native" founders. They are launching a "monastery" program designed for rapid execution and focus, offering significant funding to teams operating at the frontier of AI technology. The section concludes with a brief transition into a discussion about the term AGI. > *CyberFund believes the future belongs to AI natives who want to achieve the impossible [02:12]* > *AGI to me is just a bit of it's a it's a PR term. [02:45]* ## [02:50] From symbolic AI to machine learning systems Jordan clarifies that he identifies more as a statistician and cognitive scientist than a traditional AI researcher. He explains that while early AI focused on logical inference, the real industrial impact came from machine learning methods like logistic regression and decision trees. These methods, rooted in statistics and operations research, powered the growth of the cloud and global supply chains. > *I've never actually thought of myself as an AI researcher... The term was coined in the fifties... and they had particular methods in mind [03:29]* > *Supply chains and commerce and transportation systems all used, and still to this day, vast amounts of machine learning. [04:04]* ## [05:42] Why AGI is mostly a PR term Jordan describes "AGI" as a distortionary term that confuses the next generation of researchers. He notes that the "AI" buzzword resurfaced primarily due to the success of Large Language Models (LLMs) in mimicking human fluency. He argues that this focus on human-like language has distracted from the necessary development of robust business models and social-scale technology. > *The AI buzzword returned because of LLMs... it's been a distortionary effect on the path of research [05:01]* > *The role of humans as producers and consumers in these emerging systems should respected, amplified and thought about. [05:33]* ## [08:48] A collectivist, economic perspective on AI Jordan introduces his perspective that intelligence is a social and collective phenomenon rather than just an individual or computational one. He argues that smart action is contextual and often involves interacting with others through collaboration or competition. By incorporating economic and game-theoretic principles, he aims to build safer, more effective systems. > *We are social animals, and a lot of our intelligence comes by the fact that we aggregate. [07:20]* > *The society provides a context for our intelligence. Smart action in 1 context is not in another context [07:31]* ## [11:33] Why LLMs need system design, not hype Jordan compares the current state of AI development to early chemical engineering, where trial and error led to dangerous "explosions" and social harm. He critiques Silicon Valley's reliance on scaling LLMs without considering the displacement of jobs or the mental health impacts already seen in social media. He calls for a more rigorous social science and mathematical foundation rather than relying on metaphors. > *If you were a chemical engineer... saying we're just gonna throw a lot of stuff together... you'd get a lot of explosions. [12:12]* ## [14:50] Predictability beats faux understanding While some researchers focus on 'mechanistic interpretability' to understand AI's internal logic, Jordan argues that full internal understanding isn't strictly necessary. Drawing a parallel to human behavior, he suggests that predictability and 'rules of thumb' are more important for safe interaction. In practical scenarios like bank loan denials, users need contextual explanations based on similar cases rather than a map of internal neural circuits. > *I don't think it's bad to build systems you don't understand. But then you've got to kind of put things around it. [15:14]* ## [17:55] AlphaFold, bias, and prediction-powered inference Jordan examines AlphaFold as a successful, targeted application of machine learning that revealed significant biases. While the model provided the statistical power to reject null hypotheses, it lacked error bars for specific scientific questions. To address this, Jordan introduces prediction-powered inference (PPI), a methodology that merges small amounts of ground truth data with massive model outputs to produce trustable error bars. > *It doesn't give you out error bars and it doesn't specifically on the question you're asking. That's where I want the error bars. [20:14]* > *We developed something called prediction powered inference that does exactly that... it'll cover the truth just like in a classical statistical setting. [20:38]* ## [21:48] Stop anthropomorphizing intelligence Jordan rejects the necessity of applying terms like 'understanding' or 'intelligence' to machine learning systems, calling such anthropomorphizing a distraction. He cites Amazon's supply chain systems, which optimized global logistics without any human-like understanding. These systems are valuable because they reduce uncertainty and enable planning, not because they possess cognitive traits. > *Why say it understands? This anthropomorphizing of intelligence understanding all that is not necessary, not appropriate, and is a distraction. [22:51]* > *Even though we don't have a clue what understanding intelligence means, we and our researchers realize we don't care or need it. [24:23]* ## [27:44] Drug discovery as an incentive problem The conversation shifts to how economics provides a framework for analyzing complex, multi-agent systems like pharmaceutical regulation. Jordan explains that statistical problems become economic ones when data is provided by self-interested parties seeking profit. Effective systems must be designed to incentivize truthful behavior to control error rates in high-stakes environments where information is hidden. > *Now you've a kind of tangled web of scientists and pharmaceutical companies, not just 1 but many, many of them, and proteins. [28:49]* ## [32:29] The three-layer data market Jordan introduces a three-layer model involving users, platforms, and data buyers to illustrate how privacy and utility reach an equilibrium. He suggests that platforms could offer tunable levels of differential privacy as a competitive feature. This approach shifts the focus from simple optimization to equilibrium-based systems to design more robust social welfare structures. > *So let's think about a data market because data is not just now something you analyze to build a big LLM, it's also something you would sell and buy [32:54]* > *The platforms would say, well, we'll offer you a tunable level of differential privacy for some cost. [35:02]* ## [38:07] Social knowledge, markets, and culture Jordan distinguishes between raw data and social knowledge, which he describes as ephemeral and context-dependent. He argues that markets and cultures naturally create abstractions that are promoted from individual insights to collective knowledge. AI systems should facilitate the emergence of these new cultural abstractions rather than just reinforcing existing ones. > *Human culture creates abstractions... and when those abstractions are kind of useful enough... they kind of get promoted into the culture. [41:52]* ## [45:39] Creator economics beyond Spotify Using Spotify and YouTube as examples, Jordan discusses the failure of current digital markets to properly reward creators. He advocates for ecosystems that empower musicians to maintain ownership and connect directly with brands, citing United Masters as an alternative. He argues that platforms often become monopolies that necessitate a broader macroeconomic view of AI's role. > *I'm not against Spotify, but it should be part of an ecosystem that actually rewards the artist more. [46:56]* ## [48:30] How science-fiction AI narratives mislead young builders Jordan addresses warnings of agential, self-improving AI as "science fiction" that demoralizes young builders. He argues that framing the future as a binary between superintelligence or extinction ignores economic realities and stifles innovation. He dismisses the idea that LLMs replicate the human brain, calling the comparison a "cartoon" or metaphor. > *It's gonna wipe out humanity with a with a high probability... That is so demoralizing. [49:33]* ## [51:45] AI should improve humans, not replace them Jordan defines the true purpose of AI as aiding information flow to help humans make the decisions they actually want to make. He highlights the imperfections of human systems and argues that AI should address the gaps where evolution failed to prepare us for modern complexity. Rather than replacing humans, technology should serve as an aid to human creativity and emotion. > *AI is about helping the things that were too hard for humans* ## [56:42] Safety is a property of the whole system ## [58:12] Silicon Valley gurus and the cream off the top ## [1:00:47] Game theory, mechanism design, and contracts ## [1:04:39] Conformal prediction, e-values, and anytime inference ## [1:08:11] A new liberal arts triangle for the AI era ## [1:11:30] The Bayesian duck and markets as uncertainty reduction

Jake Cooper, CEO of Railway, details the platform's evolution from a high-burn startup to a sustainable, bare-metal cloud infrastructure powering 3 million users. He argues that the rise of AI agents necessitates a fundamental rebuild of the cloud, moving away from human-centric tools like Kubernetes and pull requests toward high-density CLI handles and production forking. This conversation provides a roadmap for building modular, high-scale systems capable of supporting the next generation of automated software development. ## [00:00] Intro Jake Cooper argues that developers should stop writing code by hand and instead focus on reviewing agent-generated code to maintain architectural integrity. He emphasizes that while AI tools have improved significantly, underlying architectural patterns matter more than ever in an automated workflow. The hosts introduce Jake as the 'Conductor' of Railway, setting the stage for a discussion on the future of cloud platforms and developer experience. > *you should be reviewing the code that you are writing instead of trying to go and write it by hand.* > *[0, 10]* ## [01:19] What Is Railway? Railway is described as a platform that allows users to deploy applications and databases instantly via a canvas or AI prompts like Claude. Jake explains that the goal is to manage software versioning and environment cloning to reduce the complexity of traditional tools like Docker and Kubernetes. By tracking all changes, Railway enables developers to fork production environments into parallel universes for safe validation without reproducing staging environments manually. > *railway is the easiest way to ship anything.* > *[2, 29]* > *we want to make it really easy for not just to like deploy things, but for you to almost like evolve applications over time.* > *[2, 49]* ## [03:26] Jake’s Path to Railway Jake details his professional journey from front-end work at Wolfram to building distributed systems for Jump bikes at Uber using Cadence. He describes his engineering philosophy as a willingness to 'swim to the bottom of the pool,' which includes writing kernel patches to ensure the best possible user experience. Additionally, he critiques GitHub's architecture, specifically the 'broken pointers' created by cloning, which complicates upstream contributions. > *we will swim to the bottom of the swimming pool to go and get the experience* > *[4, 35]* > *GitHub's original sin is that it's like almost a series of broken pointers.* > *[6, 2]* ## [07:32] Railway’s Six-Year Growth Story Jake presents a growth chart illustrating the rapid increase in daily signups for the Railway platform, which has transitioned from a 'slow grind' to adding 100,000 users weekly. Early growth was driven by high-touch interaction on Discord and a determination to acquire the first 100 core users manually. This visual data serves as a transition into the company's history of scaling and its move toward becoming a primary cloud provider. > *so I just wanted to like pull up this glorious chart you say which is basically your usage or number of daily signups* > *[7, 34]* > *Trying to get those initial like first 100 users to like actually kind of come back to it.* > *[8, 21]* ## [10:11] Rebuilding the Business After the Free Tier At one point, Railway was losing $500,000 a month while only generating $50,000 in revenue, despite having $20 million in the bank. Cooper realized this was an unsustainable business model and chose to prioritize long-term viability over vanity metrics, temporarily closing the free tier to rebuild. The company now maintains a lean team of 35 people, preferring to build automated systems rather than throwing headcount at problems. > *We basically had to kind of close off the the free kind of users for a little while, rebuild the business.* > *[11, 47]* > *We're 35 people right now... we don't want to just like add headcount for the sake of headcount.* > *[10, 52]* ## [12:36] Agents as the Next Software Platform Over the last six months, Railway has prioritized 'agentic' development as the primary mechanism for building and deploying software. Cooper believes the industry is moving from assembly and high-level languages to 'words' as the primary interface. He envisions a future where thousands of agents run in parallel, requiring new tools for coordination and version control to manage the super-exponential growth of workloads. > *We've moved from assembly to C to C++ to JavaScript to now like words.* > *[13, 23]* ## [14:48] Railway’s Infrastructure Philosophy Jake Cooper explains that Railway prioritizes control over low-level primitives like network, compute, and storage to optimize for AI agent workloads. By avoiding Kubernetes in favor of custom orchestration, the team can place workloads with high precision to ensure memory efficiency. This level of control is necessary to prevent cost structures from ballooning as agent usage increases and requires thousands of parallel instances. > *you have to be very very efficient with these agents... or you're going to massively massively blow up your cost structure* > *[15, 10]* > *How do you get agents to coordinate? How do you go and get them to be able to like safely version changes?* > *[14, 28]* ## [17:01] Bare Metal, Cloud Economics, and the Compute Crunch Cooper describes the transition to bare metal as highly lucrative, reporting a payback period of just three months compared to cloud rental costs. This strategy allows the company to achieve 70% margins while leveraging hardware that remains viable for several years. He also notes the surprising appreciation of hardware assets, such as RAM, due to the global compute shortage and supply chain constraints. > *our payback period when we go to to metal... if we rent it in the cloud, our payback period is about 3 months.* > *[17, 2]* > *hardware and all of this stuff is... appreciated in value because RAM has gone up* > *[17, 50]* ## [18:41] Cloud Bursting and Five-Cloud Networking To maintain growth without being compute-constrained, Railway utilizes a hybrid cloud strategy for bursting capacity across AWS, GCP, and Oracle. This required building a custom network overlay capable of straddling five different cloud environments simultaneously. While this complexity led to past reliability challenges, it now allows Railway to scale rapidly regardless of individual provider quotas or hardware availability. > *I spent a weekend rebuilding our entire like network like overlay essentially so that we could straddle uh five different clouds* > *[19, 41]* > *we still maintain like cloud presence for like bursting essentially* > *[18, 52]* ## [21:39] Data Center Debt and Infra Financing Cooper highlights the strategic use of data center debt, secured against hardware, as a more efficient alternative to venture capital for infrastructure expansion. By treating compute capacity as a linear driver of revenue, Railway can scale as quickly as they can deploy new hardware. He encourages infrastructure startups to explore diverse financing tools rather than relying solely on expensive venture equity for physical assets. > *we can scale revenue as basically as quickly as we can scale compute* > *[21, 20]* > *our margins on metal are like quite high for the like 70%.* > *[20, 46]* ## [24:50] Data Centers in Space Jake Cooper and the hosts explore the technical challenges of placing data centers in space, specifically the issue of heat dissipation in a vacuum. Cooper expresses skepticism toward current proposals that ignore fundamental thermodynamic laws, comparing the 'figure it out later' mentality to science fiction. He highlights the difficulty VCs face in distinguishing between visionary ideas and technical 'grifts' in the space-tech sector. > *I haven't seen anybody like prove how you're going to go and dissipate that much heat in a vacuum* > *[25, 16]* > *how do you know what's like basically not possible and like is a grift versus like uh is possible but like sounds completely insane* > *[26, 16]* ## [26:43] What Agents Need From Infrastructure Cooper outlines the infrastructure needs of AI agents, noting they require versioning, observability, and storage similar to humans but at a 1000x scale. He predicts that current industry standards like Kubernetes and Envoy will become bottlenecks as agentic workloads compress development cycles. To support this growth, infrastructure must be modular enough to allow for the rapid replacement of failing components without human intervention. > *the workload profile doesn't change so much as it gets like massively massively compressed because you need to do thousands of these things* > *[28, 28]* > *you just need at a thousandx scale* > *[29, 13]* ## [29:43] CLIs, Canvas, and Agent-Native UX Cooper explains that while humans prefer simplicity, agents benefit from high-density CLI interfaces with numerous flags that serve as 'handles.' The Railway Canvas is also evolving into an output mechanism and 'context anchor' rather than just an input tool. This hierarchical view of infrastructure prevents critical knowledge from being siloed as teams scale complex 'hyperstructures' using automated agents. > *If you hand it to an agent and you say, 'Hey, that's 40 arguments and 600 flags.' Like, oh yeah, this is excellent.* > *[30, 35]* > *It has to be almost like an anchor for your context. It has to be like a port in the storm.* > *[34, 27]* ## [36:34] Central Station, Incidents, and Responsible Disclosure Railway utilizes an internal tool called Central Station to aggregate feedback and user context, moving away from static communication channels like Slack. The team emphasizes transparency by exposing real-time metrics and detailed incident reports, operating under a core value of 'honor.' This approach involves over-disclosing issues to users rather than providing vague or misleading information during outages. > *We'd rather overdisclose and know that you know that something is wrong versus almost like having your provider gaslight you.* > *[40, 22]* > *If you can dynamically aggregate that information and dynamically route it to the right person... this is no longer a manual process.* > *[37, 10]* ## [41:49] Safe Rollouts, SRE Agents, and Production Forks To mitigate the impact of bugs, Railway employs incremental rollouts and makes it easy to test behaviors in safe, shadowed environments. Cooper argues that production should not be treated as 'sacred' to the point of stagnation; instead, infrastructure should allow for trivial production forks. This is essential for AI agents, which face a 'stacking entropy' problem without safe iteration primitives to prevent system drift. > *We've built so much ceremony around like production is sacred... we need to get to a point where it's just trivially easy to test different behaviors.* > *[41, 33]* > *I think if you don't have the primitives to make iterating in production safe, it becomes very very difficult.* > *[44, 3]* ## [46:19] AI SRE, Specs, Code, and Tests Jake Cooper reflects on his transition from an AI skeptic to a believer, noting that the safety of AI SREs depends on infrastructure primitives. He advocates for the 'Holy Trinity' of software engineering: a clear specification, the code, and the tests. By aligning these three, developers and agents can reconcile discrepancies and maintain system integrity during rapid, automated iteration. > *If you just unleash an AI SRE on your production infrastructure... it's going to nuke your production database.* > *[46, 37]* > *You need three points essentially which is you need a clear spec... you need the code and then you need the tests.* > *[48, 22]* ## [49:43] Self-Replicating Infrastructure and the New Serverless The speakers explore the concept of agents using the Railway CLI to modify their own infrastructure, creating a self-replicating loop. This shift necessitates a move away from expensive, static virtual machines toward cheap, instantaneous 'atomic units of deploy' like isolates or sandboxes. The goal is to make throwaway copies of production as trivial and cost-effective as possible for agentic experimentation. > *The agent can like modify its own infra which I think is... yeah it's nuts.* > *[50, 4]* > *How do you go and make those throwaway copies like as trivial as possible to spin up run super cheap etc.* > *[50, 53]* ## [54:37] Heroku, Temporal, and Workflow Engines Cooper attributes the decline of Heroku to Salesforce's lack of focus on compute as a core business, leading to product stagnation. Railway positions itself as a 'fluid compute' provider, leveraging Cooper's decade of experience with Temporal (and its precursor Cadence) for durable workflows. Railway is a power user of Temporal, using it to manage complex, long-running infrastructure tasks at scale. > *The business of Salesforce is to build a really really good CRM... and then you acquire this business as a compute business that's kind of an offshoot* > *[55, 33]* > *I have used Temporal for almost like 10 years now, right? Because like Cadence, all of us other things.* > *[60, 5]* ## [1:05:26] Railpack, Nixpacks, and Lazy-Loaded Filesystems Railway is developing Railpack, an engine for determining source code dependencies, which evolved from their earlier Nix-based tool, Nixpacks. While Nix offers theoretical benefits for versioning, Railway found it caused significant image bloat and scaling issues for real-world workloads. They are now exploring content-addressable file systems to enable lazy loading of data into memory for faster deployments. > *If you want version X and version Y, you end up bloating a lot of your kind of like package like space.* > *[66, 2]* ## [1:07:20] Coding Agents, Token Spend, and Roadmap Acceleration With a monthly cloud spend reaching $300,000, Railway heavily incentivizes the use of AI coding agents among its employees. Cooper argues that manual code generation is an inefficient use of time, urging developers to focus on architectural patterns and code review. This allows the team to 'speedrun' their product roadmap by automating complex infrastructure tasks and test generation. > *If you are writing code by hand you are doing this wrong... you should be reviewing the code that you are writing.* > *[67, 37]* > *If you're not using the AI systems to almost like speedrun your road map... then you're kind of missing a large point.* > *[69, 12]* ## [1:12:15] The Pull Request Is Dying The traditional SDLC is undergoing a radical transformation where the pull request and manual code review are losing relevance. Impact is increasingly measured by the 'percentage of tokens that end up in production' rather than lines of code. As AI systems handle more reconciliation and validation, the focus shifts from the PR to the initial prompt and final deployment. > *The pull request is dying... it's going to be the prompt... and beyond that code review is also kind of dying.* > *[72, 23]* > *The really naive way to go in and measure this is almost like your percentage of tokens that end up in production.* > *[71, 40]* ## [1:13:47] Feature Flags and the Agent-Era SDLC Jake Cooper discusses the critical role of feature flagging in managing the 1000x compression of the SDLC driven by AI agents. He argues that incremental rollouts and blast radius management through flagging will become even more essential for safety as deployment speed increases. This culture of flagging allows for rapid experimentation without compromising system stability for enterprise customers. > *Everything's just going to get compressed by like a thousandx so that everybody can go and do that.* > *[77, 21]* ## [1:17:34] Cattle, Pets, and Cloning Machines Jake offers a contrarian view on the 'cattle not pets' philosophy, suggesting that snapshotting allows developers to treat infrastructure like 'pets' again. By snapshotting every frame and lazily loading file systems, the overhead of traditional DevOps tools like Dockerfiles is reduced. Railway even modifies the kernel to support persistent connections during these system snapshots. > *I think you can move towards having pets so long as... you have a cloning machine for your pets.* > *[78, 2]* > *If you can snapshot every single thing at every frame, then like it actually doesn't matter if you know that obliterated.* > *[78, 12]* ## [1:20:48] Solo Founder Lessons Jake reflects on his path as a solo founder, contrasting it with the Silicon Valley consensus of finding a co-founder. He emphasizes the need to be obsessed with every layer of the stack, from kernel-level changes to go-to-market strategies. He argues that having two co-founders can often lead to deadlocks without a clear tiebreak, whereas solo leadership allows for singular vision. > *Two is the worst number of co-founders is because you have no tiebreak... you basically are like, well, I disagree on this thing.* > *[82, 49]* ## [1:25:31] Focus, GPUs, and Building a New Cloud Railway is intentionally avoiding the GPU provider market for now to maintain its core mission, though Cooper admits GPUs are an inevitable part of their long-term roadmap. He stresses that companies are defined as much by what they choose not to do as by what they execute. The ultimate goal is full vertical integration to ensure a seamless experience from logic to execution. > *I think you're you're defined almost more by the things that you don't do than the things that you do* > *[86, 8]* > *I can tell you for a fact that we will not be doing GPUs now, but we 100% will be doing GPUs at some point.* > *[86, 50]* ## [1:29:39] Closing Thoughts Cooper reveals that Railway is moving toward 100% ownership of its data centers to avoid copying the infrastructure of legacy hyperscalers. By inventing their own infrastructure from scratch, Railway aims to support 'vibe coding,' where the friction between a thought and a live application is completely removed. This approach empowers a new generation of 'citizen developers' to build at the speed of thought. > *there should be no friction in between what your thought is and reality that kind of comes out.* > *[89, 4]* > *we've been very very deliberate to like invent our own infrastructure from scratch.* > *[88, 30]* ## Entities - **Jake Cooper** (person): CEO and 'Conductor' of Railway. - **Railway** (organization): A cloud platform designed for easy deployment and environment management. - **Uber** (organization): Jake's former employer where he worked on distributed systems for Jump bikes. - **Temporal** (software): A workflow orchestration platform used by Railway for reliable infrastructure tasks. - **Salesforce** (organization): The CRM company that acquired Heroku, leading to its perceived stagnation. - **Heroku** (organization): A pioneer PaaS platform that Railway is often compared to. - **AWS** (organization): Amazon Web Services, used by Railway for hybrid cloud bursting. - **GCP** (organization): Google Cloud Platform, one of the five clouds Railway straddles. - **Claude** (software): An AI model mentioned as an interface for deploying on Railway. - **GitHub** (organization): A code hosting platform discussed regarding its architectural flaws in versioning. - **Kubernetes** (software): An orchestration system Railway chooses to avoid for higher-order control. - **Central Station** (product): Railway's internal tool for aggregating user context and support feedback.

Two engineers from Anthropic's Applied AI team — Ash Prabaker and Andrew Wilson — walk through what it actually takes to keep a coding agent productive for five-plus hours: a year of model and harness co-evolution that took runs from 20 minutes to 12+ hours, and the internal harness recipe behind their one-shot app demos — a planner that writes deliberately vague specs, a generator and an adversarial evaluator that negotiate "done" into testable contracts, taste rubrics that make design gradable, and a debugging loop that is mostly reading traces by hand. A 35-minute audience Q&A covers Ralph loops, agent teams, traceability, and human-in-the-loop trade-offs. ## [00:00] Introduction and speakers Ash Prabaker opens with introductions: he and Andrew Wilson are engineers on Anthropic's Applied AI team, and the session grew out of a blog post the team published a couple of weeks earlier on agents that keep working for extended stretches. Companies love showing one-shotted-a-browser demos, he notes, but rarely share what's inside the harness — that gap is the agenda. Andrew takes history and shipped primitives; Ash returns for the experimental half. > *We're talking 5 6 hour plus kind of runs.* ## [01:21] Overview of long-running agents Andrew, a solution architect based in London, frames the year with a quote from Boris, Claude Code's creator, on the tool's first anniversary: a year ago Claude struggled with bash commands and string escaping; now nearly all of Claude Code is written by Claude Code, with runs lasting days. > *it could run for, you know, maybe 20 minutes at a time.* ## [02:29] Challenges: Context, Planning, and Judgment Three buckets explain why long runs are hard. Context: windows are finite, new sessions start with amnesia, coherence rots as the window fills, and models near the limit exhibit "context anxiety" — rushing to finish. Planning: models try to one-shot everything, build half a feature and stop, or run out of context mid-app. Judgment, the least intuitive: models are poor critics of their own output, declaring a half-baked feature done or shipping a button with no backend behind it. > *models are really bad at judging their own output* ## [04:14] Two approaches: Model updates vs. Harness evolution Fixes come from two directions. Bake ability into the weights — the METER chart (how long an agent completes 50% of tasks on a minimal scaffold) went from about 1 hour on Opus 3.7 to 12 hours on Opus 4.6 a year later. Or change the harness: the Agent SDK ships the core primitives — the agent loop, MCP tools, sub-agent delegation, claude.md, skills, slash commands, the permission system. Andrew's running observation: every model release shipped harness changes alongside it. > *when we've released a model we've always also released a lot of harness changes alongside the models* ## [05:58] Prehistory: Sonnet 3.5, Computer Use, and MCP Before Claude Code existed there were artifacts on Claude.ai, and Sonnet 3.5 — the first model that showed real coding promise because it could look at what it had built and iterate. Computer use added clicking, screenshots, and self-testing; the MCP spec gave it tools. > *That was quite an aha moment sort of pre-Claude code.* ## [06:34] The evolution of Claude Code February 2025: Sonnet 3.7 lands state-of-the-art on SWE-bench and Claude Code ships as a research preview — explicitly to learn how developers use Claude for coding and feed that back into the model. That sets the recurring trend: as models improve, harness pieces become unnecessary or evolve. By May, Opus 4 and Sonnet 4 manage their own context better and reach task completion without reward hacking; Claude Code goes GA with an SDK. > *the goal of Claude code was to better understand how developers use Claude for coding to inform future model improvements* ## [07:55] The Ralph loop technique An interlude on the Ralph Wiggum technique — Jeffrey Huntley published it last July, traction arrived around December. The simple version: feed a prompt into the CLI on a loop until the tasks are done. The real version has phases — plan the prompt into features, pick one task, start a fresh session with a clean context window. Its appeal is captured in Huntley's "deterministically bad in an undeterministic world." Anthropic's own plugin runs inside a single session instead, relying on compaction, max iterations, a safe word, and a stop hook. > *it's better to fail predictably than it is to succeed unpredictably* ## [09:49] Sonnet 4.5, Agent SDK, and checkpoints Sonnet 4.5 starts tracking its own token consumption — context-aware enough to manage the end of its window instead of panicking. Claude Code 2.0 introduces checkpoints for rewinding a session. The Claude Code SDK is renamed the Agent SDK because the team realized the harness generalizes beyond coding. Runs reach roughly 30 hours. > *we realized it's much more general purpose than actually just for coding* ## [10:49] Opus 4.5 and the role of sub-agents Haiku 4.5 and Opus 4.5 complete the family, and the economics shift: many sub-agents become affordable, and Opus 4.5 plans well — so Opus plans while Sonnet executes. Skills arrive with progressive disclosure (only frontmatter loads up front), and programmatic tool calling lets the model write code to chain tool calls and return just the final result instead of dumping everything into context. > *all of a sudden running many sub-agents became really economical* ## [12:05] First long-running agent patterns Around November the team published its first long-running-agents blog post. A human writes something vague — "create a Slack clone" — and an initializer agent breaks it into persistent artifacts: a feature list stored as featurelist.json (models overwrite markdown more readily than JSON), a progress file, a git repo, an init script. The harness loop then runs in fresh context windows: get bearings, run the init script as a smoke test, pick exactly one unfinished feature, implement, verify with Puppeteer, commit, repeat. > *the models might overwrite markdown files, whereas they're they're less likely to just overwrite JSON files* ## [14:20] Opus 4.6, Agent Teams, and server-side compaction Sonnet 4.6 offers near-Opus intelligence at Sonnet pricing and becomes the workhorse; Opus 4.6 is "very much an agentic model" — the METER figure jumps from ~4 to 12 hours on a minimal scaffold. Agent teams ship: sub-agents coordinate directly with each other and report to the main agent only when needed. Server-side compaction means sessions can effectively run indefinitely, and 1M context goes GA — nudging the design question toward fewer fresh sessions and one big window. Andrew's closing point: the harness doesn't vanish as models improve; gaps get filled by the harness, the model trains on that, and pieces get deleted. > *the harness doesn't just disappear as the models get better* ## [17:28] State-of-the-art harness patterns Ash polls the room — only two or three people have agents running in the background right now — then lays out the core pattern, borrowed shamelessly from GANs: a generator builds, a standalone evaluator grades, with adversarial pressure between separate context windows, system prompts, and jobs. The evaluator doesn't read diffs; it opens live pages with Playwright, clicks around, and hands critique back. Why doesn't an LLM evaluator just rubber-stamp LLM output? The gap they exploit: tuning a standalone critic to be harsh is tractable; tuning a builder to be self-critical is not — same as humans, where critiquing a meal is easy and cooking it is hard. > *The evaluator here isn't just reading diffs, but it's actually using playwright, um, to open live pages, click around, try things out* ## [21:30] Evaluating subjective output with rubrics Most people say you can't grade taste; the team disagrees — if you hold a strong enough opinion, write it down. Their rubric scores design, originality, craft, and functionality, weighted toward the first two since Opus 4.6 already handles functionality — the real fight is purple gradients and AI-slop aesthetics. Few-shot examples on reference sites calibrate the evaluator's taste to their own. The distinctive behavior this unlocks: when the generator keeps scoring low on originality, the GAN-style harness throws everything out and restarts — where a single loop would keep patching the same thing. > *most people say you can't grade taste, but, you know, we think you can if you have a a strong enough opinion on it and you just kind of write it down* ## [23:44] Introducing the 'Planner' role To go from nice pages to working apps they added one more role. The planner turns a one-line prompt into a deliberately high-level spec — a series of sprints — and explicitly does not plan granular technical details, because a wrong detail cascades through every sprint and magnifies over multi-hour horizons. Squint and it's a PM/IC/QA org chart. > *We just kind of gave each role its own kind of context window.* ## [25:04] The generator-evaluator contract The glue between generator and evaluator: before a single line is written, the two agents negotiate what "done" means. The generator proposes a feature and tests; the evaluator pushes back — scope too big, tests too weak, missed edge cases — via markdown files on disk until both agree. Grading then happens against that contract, not the planner's original spec. Ash calls this the key innovation the Ralph loop never had: nobody argues with the main loop. The proof is a "build a retro game maker" prompt run both ways. Solo loop: pretty screens, but in play mode the arrow keys and space bar do nothing. With the harness (~$200, 6 hours): the app names itself Retro Forge, builds a 54-color sprite editor, turns a vague "AI features" spec line into a working AI level assistant, and play mode has a live debug HUD, a running physics loop, and real collisions — the difference is entirely scaffolding. > *we have the two agents basically negotiate what done actually means* ## [31:28] Specificity in contracts and debugging traces What the evaluator actually catches is unglamorous: a FastAPI route-ordering bug that passes unit tests but breaks in prod, a Boolean logic bug on the delete key — found only because it uses the app. For the game maker, the agents settled on 27 contract criteria; vague criteria produce vague critiques the generator shrugs off. Ash is candid that out of the box, Claude is a bad QA agent — the same sycophancy that plagues LLM-as-judge had early evaluators filing "fix it later, might take 2 weeks" and moving on. There was no secret fix: the art was reading traces, finding where the model's judgment diverged from theirs, and tuning prompts — plus piping transcripts to files and having another agent grep them to close the loop. > *If you have vague criteria, you have vague critiques* ## [34:14] Adjusting harnesses as models evolve Is harness design dead? Ash's answer: learn each model's spiky behaviors and fill the gaps. Moving from Opus 4.5 to 4.6 they dropped context resetting entirely (4.6 has no context anxiety; one continuous session plus compaction suffices), dropped forced sprint decomposition (4.6 holds a 2-hour continuous build coherently), and moved the evaluator from every sprint to the end of each one-shot generation. The harness wasn't wrong — it was right for 4.5, and the frontier moved. Today's setup keeps the planner-generator-evaluator core, shares state through the file system, and runs at roughly half the previous cost — demonstrated by a DAW the harness built whose music was, by Ash's admission, trash, but whose app was thoroughly fleshed out. > *it was right for 4.5, the frontier moved* ## [37:56] How to build your own agent harness None of this requires Anthropic's internal harness. Auto mode covers the safe middle ground; custom sub-agents already exist as a primitive — give your evaluator a harsh system prompt and a detailed rubric; Playwright MCP or Claude for Chrome handles web apps, computer use handles native; skills package grading rubrics into the dev flow. > *there's nothing stopping you from just going ahead and building something similar to this kind of on your own* ## [39:01] Key takeaways for long-running agents The photo slide: self-evaluation is a trap — use an adversarial evaluator. Compaction does not equal coherence — lossy summaries drift; structured handoffs and clean contexts work. Subjective quality is gradable if you force yourself to write the standard down. And sit with the model reading traces — only then do you know which scaffold pieces to delete when the frontier moves. > *self-evaluation, very much a trap* ## [40:05] Q&A session Eleven audience members take the mics for 35 minutes. Highlights: evaluator tuning generalizes across projects when you target common model weak points (calibrate with "this is AI slop" examples). On Ralph loops and the model's "smart zone": with 1M context GA and 4.6's coherence, the team moved to one continuous session with compaction — but use your own evals. On watching agents work: Ash sees wanting to watch as a trust gap; the model now reads console errors and spots overlapping text itself. The 4.6 generation is strikingly willing to throw ten passes away and restart when it can't hill-climb the rubric — one evaluator got fed up and told the generator to delete everything. The planner stays out of the inner loop deliberately; the spec is re-inserted as a reference instead. For products that outlive the run, the harness leaves breadcrumbs — a learnings JSON ("tried this, found this bug, fix worked") plus high-level docs — enough for a human with Claude Code to pick up. Feeding the generator's context to the critic was tried and rejected: judging output alone beats muddying the two streams. Traceability remains mostly reading traces by hand ("you got to read the whole thing"), with Claude-over-traces as a first pass. And on human-in-the-loop sprint reviews: hooks can inject one, but the team optimizes for full autonomy — run ten generations, read the seven failures, tune the harness prompts, repeat. > *you got to read the whole thing* ## Entities - **Ash Prabaker** (Person): Engineer, Anthropic Applied AI team; presents the state-of-the-art harness patterns and Q&A. - **Andrew Wilson** (Person): Solution architect, Anthropic Applied AI (London); presents the model/harness history. - **Anthropic** (Organization): The speakers' employer; ships Claude models, Claude Code, and the Agent SDK. - **Claude Code** (Software): Anthropic's coding agent CLI whose one-year evolution frames the talk. - **Agent SDK** (Software): Renamed Claude Code SDK; ships the agent-loop primitives the harness builds on. - **Generator-evaluator pattern** (Concept): GAN-inspired split of builder and adversarial critic with separate contexts; core of the harness. - **Ralph loop** (Concept): Jeffrey Huntley's loop-a-prompt-until-done technique; precursor lacking an arguing counterparty. - **Playwright MCP** (Software): Browser-automation tooling the evaluator uses to test live apps.

Ukraine produced 4 million FPV drones last year; China could produce 4 billion. That asymmetry frames two hours of unusually concrete conversation between Yaroslav Azhnyuk — serial tech founder turned AI-drone builder at The Fourth Law — and economist Noah Smith, who has been writing about the economics of drone warfare since before most Western policy circles took it seriously. They cover the full tech stack (cameras, autonomy modules, fiber optic links, interceptors, a semiconductor fab under construction), a five-level autonomy taxonomy, an eight-dimension autonomous-battlefield framework, and China's manufacturing edge that has no near-term Western answer. The through-line: the West is still planning to fight the last war, Ukraine is the defense valley where the next war is already live, and the gap is widening faster than most people realize. ## [00:00] Cold Open: China's 4 Billion Drones and the Cameras-to-Explosives Pipeline Yaroslav opens cold with a single arithmetic comparison that structures the rest of the episode. Ukraine, not an industrial powerhouse, built 4 million FPV drones in a year. China, with an order-of-magnitude larger manufacturing base and a consumer electronics supply chain already producing the same cameras, motors, and chips, could produce 4 billion. Noah immediately asks whether that makes China the supreme conventional military power on earth right now. Yaroslav won't claim certainty, but won't rule it out either. > *"I don't think we have all the information to claim that, but we cannot count it out. And that alone should be, you know, a big warning sign."* The cold open also plants the personal pivot that the rest of the episode unpacks: Yaroslav went from making cameras that fling treats to pets to cameras that fling explosives to occupiers. ## [01:04] Introduction: Brandon, Noah Smith, and Yaroslav Azhnyuk Guest host Brandon normally runs a science podcast; this episode is the exception. Noah Smith — Noahpinion Substack, economist focused on industrial policy and geopolitics — is co-host and co-interviewer. Yaroslav sets the personal context: on February 23rd, 2022, he and his then-fiancée landed in Kyiv at 11 p.m. on what turned out to be one of the last flights into the city. Eight hours later, the bombs fell. The 17-hour drive west that followed — empty streets, gas stations out of fuel, pouring diesel into windshield-washer canisters — reads like a scene from an apocalyptic film because, for the people living it, it was exactly that. > *"We basically packed our belongings and got in the car and spent 17 hours riding west. That was exactly like that. I, you know, missiles are falling, like there was smoke in Kyiv."* ## [05:41] From Tech Entrepreneur to Defense: PetCube, Brave One, and the D3 Fund Yaroslav's path from pet-tech to defense wasn't a straight line. In San Francisco from 2014 to 2020 building PetCube (one of the leading pet-camera companies), he had never taken military coursework and considered wars a thing of the past. Day one of the invasion he knew he would fight back with everything he could — but weapons weren't the first instinct. Early efforts included lobbying U.S. Congress on Lend-Lease (passed May 2022, underdelivered), co-founding Brave 1 (Ukraine's defense-innovation cluster, analogous to DIU), and helping seed the D3 Fund co-started by Eric Schmidt. By 2023, two things became undeniable: the war would last, and drones had permanently redefined warfare — the first software-defined weapon platform in history, where a battlefield capability upgrade can be pushed overnight like a software update. > *"It's like if you were able to push a software update and get all of your Roman legionaries a new helmet. That has never been possible before."* ## [10:42] The Ethics of Building Weapons: Dual-Use Technology and the Wolf at the Door Brandon raises the dual-use problem: the technology won't stay in Ukrainian hands. Yaroslav's answer is pragmatic rather than philosophical. Every technology from fire to large language models is dual-use; the question for a maker is whether the marginal risk of their contribution outweighs the immediate need. Ukraine is in a forest with a wolf. You deal with the wolf first, then consult Greenpeace. He's clear-eyed that no technology stays contained — the parallel concern about LLMs freely available in North Korea and Russia applies equally to drone autonomy — but frames his own company's responsibility narrowly: they supply to the Ukrainian government and armed forces, not to arbitrary buyers. > *"When you're in a situation where you're in a forest in front of a wolf, you know, you first going to deal with a wolf that wants to eat you and then you're going to go consult Greenpeace."* ## [14:01] The Tech Stack: Cameras, Autonomy Modules, Interceptors, and a Semiconductor Fab The Fourth Law's structure is three interlocking business units. Cameras (daytime and thermal, sold to 200+ Ukrainian drone manufacturers). Drone autonomy modules (sold to the same ecosystem). And UAV products sold direct to the armed forces: FPV strike drones, bombers, Shahed interceptors, and ISR interceptors — drones that hunt Russian reconnaissance drones before they can relay targeting data. The thermal-camera arm is about to start construction on two semiconductor fabs to manufacture sensor chips in-house, driven by the realization that dependence on foreign sensor supply chains is a strategic vulnerability. > *"We're about to start construction of two semiconductor plants to make sensors for thermal cameras. That's super exciting for me as a computer science guy — doing semiconductor, super cool."* ## [18:47] Fiber Optic vs. AI: The Radio Horizon Problem and $32/km Cable The chapter is really about why radio-only FPV drones fail at long range — not just from jamming, but from the curvature of the Earth. Below roughly 60-100 meters altitude at 30-40 km range, a drone enters a radio shadow behind hills, forests, or the horizon itself. The pilot loses video and control precisely when closing on a target that is, by definition, on the ground. Fiber optic cable ($32/km, spooled from the drone) solves the shadow problem but adds weight, limits range, and reduces maneuverability. AI fills the gap differently: terminal guidance lets the drone complete the last few hundred meters autonomously even after the radio link breaks. The two approaches aren't mutually exclusive — you can run AI on top of a fiber optic link to command hundreds of drones with fewer operators. > *"If your drone goes low — and usually Russian infantry and vehicles, they're on the ground and you want to hit them, you need to go low — lower you go, maybe you'll get behind a hill or behind a forest, and if you're far enough you'll just get behind the curvature of the Earth."* ## [25:32] FPV Drones: The New God of War — 70–80% of Frontline Casualties Artillery was historically called "the god of war" because it caused 80% of battlefield casualties. On the current Ukrainian front line, 70-80% of casualties are inflicted by FPV drones — the same fraction, a different weapon. Tanks, designed to dominate land warfare for decades, are now routinely destroyed by $400 consumer-grade quadcopters because armor was never built to defend against attacks from directly above. The trajectory follows the same curve as calculators becoming irrelevant once smartphones arrived: not a linear substitution but an exponential displacement where the new technology's influence grows nonlinearly. > *"They used to say that artillery is the god of war because artillery used to cause like 80% of casualties, and now on that ranking FPV drones rule."* ## [28:28] The Five Levels of Drone Autonomy: From Terminal Guidance to Full Autonomy Yaroslav lays out five autonomy levels describing where the field stands and where it's heading. Level 1 is terminal guidance — the drone flies under human control and locks onto a target only in the final seconds. Level 2 is bombing — dropping munitions from altitude without directly ramming a target. Levels 3-4 introduce increasing target-selection and navigation independence: the drone can identify radio-emitting equipment, track vehicles, or navigate through GPS-denied environments. Level 5 is full autonomy — launch-and-forget, no human in the loop for any mission phase. Current battlefield deployment sits mostly at Levels 1-3. The jump to higher levels isn't primarily a technical problem anymore; it's a deployment, doctrine, and trust problem. Human confirmation remains in the loop at every stage involving lethal targeting decisions — for now. > *"Technology progresses and its influence grows nonlinearly. It's all exponential."* ## [41:37] The Eight Dimensions of the Autonomous Battlefield The five autonomy levels describe a single drone's capability. The eight dimensions describe the full battlefield context those drones operate in. Dimension 1: level of autonomy (the five-level scale). Dimension 2: platform type (quadcopter, fixed-wing, missile, naval drone). Dimension 3: environment (day/night, urban/forest/open terrain). Dimension 4: target type (moving vehicle, static structure, radio emitter). Dimension 5: swarm size and coordination. Dimension 6: command-and-control architecture. Dimension 7: sensing modality (optical, thermal, RF). Dimension 8: infrastructure (simulation, data pipelines, security, deployment tooling). Each dimension interacts with every other. A Level-4 autonomous drone performing well in open daylight terrain may fail completely in a forest at night. Battlefield AI systems have to be evaluated across all eight dimensions simultaneously, not just on the single axis of autonomy level. > *"I say dimension because each of them works with another. It's crucial to understand how autonomy evolves in a modern battlefield environment."* ## [45:32] AI Safety and the Morality of Autonomous Weapons Yaroslav's position flips the standard AI-safety framing: in five to ten years, it will be *immoral* to use weapons *without* AI, because human-only weapons produce more collateral damage and friendly fire. He draws the analogy to manually driven cars — once autonomous vehicles are the norm, letting a human drive on a public road becomes the dangerous choice. Noah pushes to the logical endpoint: a Level-6 "AI general" — one large model that ingests all battlefield data and agentically selects targets, with humans reduced to repairing drones. Yaroslav says technically it could be done now. The constraint is deployment and trust, not capability. He references what was publicly described about AI-assisted target designation in the Iran operation: AI surfaces 127 targets, human reviews the list and presses okay. That's already close to an AI general with a rubber-stamp layer. > *"I think 5 to 10 years from now it will be immoral to use weapons without AI because weapons without AI will be more likely to cause collateral damage or unwanted damage."* ## [51:31] The End of the Rifleman? Noah's 2013 Prediction vs. Battlefield Reality Noah revisits a prediction he made in 2013: the rifleman is obsolete, replaced by standoff weapons. Ukraine both confirms and complicates it. FPV drones have unquestionably displaced the rifle as the primary instrument of attrition — but infantrymen haven't disappeared. They dig trenches, hold terrain, conduct logistics, and survive for months in dugouts under continuous drone threat by adapting: better camouflage, smaller movement signatures, drone-awareness drills. Yaroslav extends the timeline question to humanoid robots. The world is built for bipedal humans; there's genuine utility in a platform that can operate a rifle, open a door, or crew a vehicle. He puts a Terminator-style scenario — humanoid combat robots — at 10 years out, not science fiction. But modern warfare, they agree, is a multi-dimensional problem — dozens of drone types, land ops, reconnaissance, psychological operations, aviation, tanks, logistics — and the press focus on whichever technology is newest understates how much every layer still matters. > *"Modern warfare is really very complex and the fact that drones are the latest coolest thing doesn't mean that now it's that and only that."* ## [01:05:13] China's Manufacturing Advantage and Western Vulnerabilities This is where Noah Smith's economics background drives the conversation. The U.S.-China drone comparison isn't about unit price or autonomy level — it's about manufacturing throughput at scale. China's consumer electronics supply chain already produces the motors, cameras, chips, and battery cells that go into FPV drones. Switching that capacity to military production requires regulatory will, not retooling. Ukraine builds fixed-wing drones with 10 km range from hobby components; China can build fixed-wing drones with 200-300 km range at the same cost curve. The West's vulnerability isn't just quantity. It's thermal cameras (overwhelmingly sourced from China), semiconductor fabs (two generations behind on drone-relevant sensors), and procurement speed (a Western defense contract takes years to award; Ukraine iterates weekly). Yaroslav is optimistic about Western human capital — the engineers exist — but openly frustrated with European institutional inertia and uncertain about whether the U.S. has fully absorbed the lessons from Ukraine and the Middle East. > *"We don't have all the information to claim that, but we cannot count that out. If we want to keep the resemblance of our good past life, we have to do something about it."* ## [01:24:21] Policy Advice for Western Defense: Defense Valley and the Widening Gap Yaroslav's top policy prescriptions are framed around the William Gibson quote he attributes to Arthur C. Clarke: the future is already here, just not evenly distributed. Kyiv is Defense Valley — the place where the future of war arrived first, with hundreds of specialized companies, battle-tested commanders at every rank, and a government that learned to move at startup speed. Priority 1: deep integration with Ukraine's defense ecosystem, not just procurement but embedded learning. Priority 2: procurement reform — the drone-dominance initiative is the right direction and needs to scale 10x. Priority 3: long-range drone readiness for contested maritime environments (Shahed-class drones with 2,000 km range cover the entire Pacific island chain). He worries that the U.S. learned less from Ukraine than it should have and may be repeating the pattern with Iran. > *"Kyiv and Ukraine is sort of the defense valley. It's the point where the future of defense has already arrived, and there's a ton of things to learn from that."* ## [01:32:54] The Drone Race: Who's Ahead, Category by Category Russia was at parity or ahead in drone capability 18 months ago; Ukraine has since pulled ahead on FPV and autonomy. But Russia has a 4x population advantage and significantly more industrial capacity than Ukraine alone — scale disparity is why Western supply matters. The race breaks down by category: FPV strike (Ukraine leads), ISR reconnaissance (contested), glide bombs (Russia leads, dropping from bomber aircraft at scale), deep-strike drones (Russia leads on volume), and interceptors (Ukraine innovating rapidly, Russia catching up). Russia uses helicopters to intercept Ukrainian deep-strike drones — a costly but effective countermeasure revealing how each new offense spawns a tailored defense, at weekly iteration cycles. > *"Everyone says Russia's behind right now in the drone war. But that wasn't true a year ago."* ## [01:41:57] Countermeasures: Shotguns, Jammers, Lasers, and Fishnets Shotguns work — they're the primary kinetic countermeasure against incoming FPV drones — but only for a trained soldier who can hit a 20 cm target moving at 100 km/h under combat stress. Electronic jammers are the most widespread defense: block the radio or GPS link and the drone loses guidance. The catch is that the same spectrum the jammer blankets is often used by your own forces, and jammers are being defeated by frequency-hopping and fiber optic links. Russian tanks now look like porcupines — improvised metal cages and electronic-warfare antennas bolted on top to defeat top-attack drones. Ukraine's answer is shaped charges specifically tuned for the gap between the cage and the hull. Lasers are effective but expensive ($10M+ per system to kill a $400 drone) and slow to slew onto fast-moving targets. Fishnets — literally mesh nets — are being deployed around static positions because they're cheap, snag rotors, and require no power. > *"Then the tanks — if you look at Russian tanks and sometimes Ukrainian tanks or equipment — they all look like porcupines."* ## [01:58:19] The Wedding and Final Takeaway: Be Prepared for War Brandon closes with two questions. First: did Yaroslav actually get married in that chapel on February 23rd? They got legally married, but postponed the reception until the war is over. Second: one takeaway for the audience. Yaroslav's answer is a restatement of the Roman proverb: *si vis pacem, para bellum*. > *"You want peace, be prepared for war. Got to invest in defense and security."* ## Entities - **Yaroslav Azhnyuk** (Person): Founder of The Fourth Law (AI drone autonomy + thermal cameras, Ukraine); previously co-founder of PetCube; co-founder of Brave 1 and D3 Fund; born and raised in Kyiv. - **Noah Smith** (Person): Economist; author of the Noahpinion Substack; co-host for this episode; focus on industrial policy, manufacturing economics, and geopolitics. - **Brandon** (Person): Regular Latent Space host (science podcast background); guest host for this episode. - **The Fourth Law** (Organization): Yaroslav's AI-guided drone company; three business units — thermal cameras, drone autonomy modules, UAV products (FPV strike, bombers, interceptors). Leading drone-AI team in Ukraine. - **PetCube** (Organization): Consumer pet-camera company Yaroslav co-founded in San Francisco (2014–2020); the origin of the "cameras that fling treats / cameras that fling explosives" pivot. - **Brave 1** (Organization): Ukraine's defense-innovation cluster; analogous to DIU (Defense Innovation Unit) in the U.S.; co-founded with Yaroslav's involvement. - **D3 Fund** (Organization): Defense-tech investment fund co-founded with Eric Schmidt (ex-Google CEO) to accelerate Ukraine's drone ecosystem. - **FPV Drone** (Concept): First-Person-View drone — pilot sees through onboard camera in real time; currently responsible for 70-80% of frontline casualties; dominant tactical weapon of the Ukraine conflict. - **Five Levels of Drone Autonomy** (Concept): Yaroslav's taxonomy from terminal guidance (Level 1) to full autonomous operation (Level 5); most current battlefield deployment is Levels 1-3. - **Eight Dimensions of the Autonomous Battlefield** (Concept): Yaroslav's framework for evaluating drone systems across platform type, environment, target class, swarm scale, C2 architecture, sensing modality, and infrastructure. - **Defense Valley** (Concept): Yaroslav's term for Kyiv/Ukraine as the global hub where the future of defense tech is already live — analogous to Silicon Valley for consumer tech. - **Radio Horizon** (Concept): Earth-curvature effect that cuts radio/video links to low-flying FPV drones at 30-40 km range; primary technical driver for fiber optic drone adoption. - **Shahed** (Concept): Iranian-designed loitering munition used by Russia; fixed-wing, up to 2,000 km range; archetype for long-range drone threats to Western bases and Pacific-scenario planning.

a16z general partner David Ulevitch sits down with Col. Jeffrey Glover (Arizona Department of Public Safety) and Rahul Sidhu (Flock Safety board member) to walk through how drones, sensors, and AI are quietly rewiring American policing. Sidhu lays out Flock Safety's layered sensor network — license plate readers, gunshot detection, and drone dispatch — while Glover details an Arizona DPS ecosystem built around officer wellness, body-cam analytics, and an international fusion-center play timed to FIFA and the Olympics. The throughline: the next decade of police work will look more like analyst work than door-kicking, and founders who want in need to spend real time on the beat first. ## [00:00] Drones and the Future Beat The episode opens with a stitched-together preview: Sidhu's punchy maxim that cops hate both change and the status quo, Glover sketching how a patrol officer's skill set has to get more investigative and nuanced, and Ulevitch teeing up the central scenario — a 911 call, a drone responding ahead of officers, a fleeing shooter pursued from the sky. The pitch isn't abstract: keeping five helicopters airborne 24/7 to do that job is impossible, but drones make it almost inevitable. > *"You hear a gunshot go off and the drone finds a shooter getting into a car and driving off, and then pursuing the vehicle."* ## [00:32] Founders Building for First Responders Ulevitch asks Sidhu what advice he'd give founders who care more about saving lives than optimizing ad clicks. Sidhu, who sits on Flock Safety's board, points to companies like Skydio and walks through the kind of inbound he gets daily — alerts about kidnapped children recovered, situations de-escalated, technology used to read a scene before officers do. The story he keeps coming back to: a 911 caller reports a man in an alley with a shotgun, a drone arrives first, and the "shotgun" turns out to be a janitor holding a broom. > *"It turned out the drone provided, you know, situational awareness and said, 'Wait, there's just a janitor with a broom.' That's not a guy with a shotgun. And it totally de-escalates the situation."* ## [01:38] Flying Robots Meet Sensor Networks Sidhu reframes drones as flying robots that fit into the same automation wave reshaping every industry. Public safety will get more drones — including more hostile ones to defend against — and Flock Safety's pitch is the layer beneath them: license plate readers, gunshot detection, and drone dispatch tied together so that an Amber Alert vehicle or a shot-spotter ping can dispatch a drone automatically, even pursuing suspects onto highways with state DPS. Ulevitch closes the segment with a joke about it being a bad time to be an enemy of America, then hands off to Glover. > *"And Flock Safety, you know, we — it's not just about drones for us. Like, we have multitudes of sensors in the communities. We have license plate reading cameras. We have, you know, gunshot detection capabilities. All of this is coming together."* ## [03:17] Officer Wellness and Body Cam Analytics Glover details what an integrated Arizona DPS deployment actually looks like. Officers start their shift with a Vitanya "Heal the Heroes" brain scan to check baseline wellness. During the shift, Truleo runs analytics on body-worn-camera audio — not just scoring trooper interactions with the public, but flagging cumulative stress that should put a supervisor on alert before burnout becomes a problem. Ulevitch picks up the thread on how public sentiment around body cams flipped once people saw they protect officers as much as they document them, and draws a parallel to the same hype-cycle pattern with tasers. > *"You can do a scorecard for how the trooper is interacting with the public, but it also gets that information for, hey, do they need additional support?"* ## [05:47] Fusion Centers and Global Intelligence Sharing Ulevitch turns to intelligence-gathering and Glover walks through the Arizona Counterterrorism Information Center (TIC) and the wider US fusion-center network. The near-term push: a TRX program that most agencies are running for FIFA. The longer play: Arizona standing up an international presence with embedded intelligence officers from Mexico, the UAE, Liberia, and other partners, so unclassified threat signals can flow across borders before incidents become local. Ulevitch points to Austin and NYPD counterterrorism as proof the model works. > *"Being able to condense that down and distill it to where we can have good information sharing that's unclassified — be able to share with one another — is going to be huge."* ## [07:37] Advice for Innovators and Closing Thoughts Ulevitch turns the closing question back to Sidhu — a former paramedic and reserve officer — for advice to founders. Sidhu name-checks Ben Curley of Chart Performance (sitting in the audience) as an example of the kind of operator already doing the work, and lands his thesis: the gap looks intimidating but if you can describe an inevitability the way drones now feel inevitable, the field will pull you in. The non-negotiable: spend real time on the beat — ride-alongs, reserve duty — so you actually know what to build. Glover closes by echoing the call to jump in, and predicts the next ten years will fundamentally shift the profession away from kicking in doors toward parsing video, AI signals, and analyst work. > *"If you can picture something that feels like an inevitability, in the same way that, you know, we talk about drones — it'll come because it's the best thing for them. It's the best thing for the communities."* ## Entities - **David Ulevitch** (Person): a16z general partner, host of The a16z Show; long-time enterprise/security investor. - **Col. Jeffrey Glover** (Person): Colonel/Director at the Arizona Department of Public Safety, leading the agency's tech and intelligence modernization. - **Rahul Sidhu** (Person): Flock Safety board member, former paramedic, founder/operator background in public-safety technology. - **Flock Safety** (Organization): Builds a layered public-safety sensor network — license plate readers, gunshot detection, and drone dispatch. - **Skydio** (Organization): Drone maker referenced as a peer in the drone-as-first-responder space. - **Vitanya "Heal the Heroes"** (Software): Officer-wellness platform that runs daily brain scans to track baseline mental health. - **Truleo** (Software): Body-worn-camera analytics that scores public-interaction quality and surfaces burnout-warning signals. - **Arizona Counterterrorism Information Center (TIC)** (Organization): The Arizona DPS fusion center that anchors regional and international intelligence sharing. - **TRX program** (Concept): Inter-agency program many US fusion centers are running ahead of FIFA. - **Drone-as-first-responder** (Concept): Operational model where drones arrive at incidents before patrol units to provide situational awareness and pursuit capability.