David Ondrej, Extracted: Agentic Engineering Workflows

This site extracts everything substantive from the first four videos of the deep dive: David Ondrej’s two solo workflow videos (“Stop coding, build Software Factories instead” and “My Agentic Engineering Workflow (after 15,700 sessions)”), his Cloudroom launch video, and his interview with Vercel CEO Guillermo Rauch. Each chapter carries the full extraction from one video, with timestamps, so any claim can be checked against the source. This synthesis is the layer across all four: the operating system they share, where they disagree, and what to verify before believing any of it.

Nothing here is presented as verified fact about the world. It is a faithful map of what these practitioners say they do and believe, with their commercial interests flagged where those interests point in the same direction as their advice.

The shared operating system

1. The bottleneck moved to the human. Ondrej’s framing is a ladder: do the task yourself, then chat with an agent, then design agentic loops, then run a software factory. The reason to climb is saturation: one person unblocking agents one by one tops out at roughly five concurrent agents, so anything that requires your prompt as its trigger is capped at your attention. Rauch arrives at the same wall from inside a large company: the scarce resource is no longer code production but direction, taste, and how fast real signal becomes a shipped fix.

2. A loop is a trigger plus an execution, and the trigger is not you. Across the solo videos, loops are built from schedules, webhooks, incidents, customer feedback, and other agents on the input side, and from a model equipped with skills, context, and tools on the execution side. A well-built loop triages itself: non-issues archive themselves, real findings escalate in plain language. Rauch’s version of the same discipline is his insistence on signal-to-fix latency (under thirty minutes from decisive customer signal to shipped fix) as the metric that matters, against token spend and PR counts, which he calls vanity metrics.

3. Quality comes from adversarial structure, not from more generation. The same mechanism recurs in three of the four videos: work produced by one model is reviewed by a frontier model from a different lab (Opus builds, an OpenAI model reviews, and vice versa), findings are scored and adjudicated, and agreement between two models gates actions like adding a test. Rauch’s “agentic inquiry” is the reflective cousin: after an agent builds something, another agent interrogates the result and reports what the builder got wrong or what the vendor could have done better. Nobody in this corpus trusts a single model’s self-assessment.

4. Subagents are for predictable chunking, not for thinking. Ondrej restricts cheap models (Haiku-class) to homogeneous, parallelizable analysis; exploration, debugging, and refactoring stay with one frontier model in one thread, one task per thread, bugs reproduced end to end before any fix. Fan-out is a hierarchy when it scales: a frontier manager, mid-tier coordinators, cheap workers, in the 10-to-110 agent range, designed rather than launched by hand.

5. The substrate argument: isolated, always-on, cloud execution. All four videos land on per-agent isolated sandboxes in the cloud over local machines, for capacity, continuity (a laptop lid closing should not stop the fleet), and blast radius (a compromised sandbox is not a compromised machine). Rauch adds the security inevitability argument: cheap, competent vulnerability-finding models make the latent bug load in legacy code a pressing liability, and monitored cloud sandboxes are his proposed containment.

6. What stays human: taste, story, risk, verification. Ondrej’s list is taste, practicality under time pressure, resource allocation, per-task model choice, evals, and a protected daily block of device-free first-principles thinking. Rauch’s is creative control and brand (buyers are humans who buy stories), cybersecurity risk ownership, and verification engineering: agreeing the axioms and trade-offs with the agent, testing the system’s edges rather than its tautologies, and refusing to ship what you do not understand.

Where the corpus disagrees with itself

• Minimal versus maximal harness. Rauch’s FX is a deliberately tiny, near-immutable CLI in the Unix style: small programs, the file system as the interface, extensibility through embedding a library rather than adding UI. Ondrej’s stack is the opposite aesthetic: skill repos, decision frameworks (his 4x4 skill pulls sixteen structured decisions out of him), Raycast snippets, layered automations. Both claim the same goal (latency between intent and execution) from opposite ends.
• Vendor interest points the same way as the advice. Ondrej sells Cloudroom, and his infrastructure thesis is Cloudroom’s pitch; the launch video is a launch video. Rauch sells Vercel, and his cloud-sandbox inevitability argument is Vercel’s product line. This does not make the arguments wrong; it means the corpus contains no disinterested witness on the cloud question, and the site’s chapters keep their claims in ledgers for exactly that reason.
• Openness claims versus openness facts. Ondrej’s Cloudroom chapter claims Apache 2.0 and a free-forever tier; Rauch discusses open source as an extensibility mechanism for FX. The extraction notes record what each video asserts; verifying licenses and plan terms against the actual repos and pricing pages is outside the videos and is listed below as reader homework, not assumed.

Claims to verify before repeating

From the chapters’ claims ledgers, the highest-value checks: Cloudroom’s license, free-tier limits, sandbox-per-thread exclusivity, networking and concurrency figures, and its market claims about Cursor and OpenAI; the real terms of Vercel’s AI Gateway model coverage and spend visibility; any productivity number attached to “sessions” counts (15,700 sessions is a usage statistic, not an outcome measure); and every prediction in the solo videos about job timelines, which are stated confidently and sourced to nothing but the speaker’s conviction.

How the chapters are organized

Each video chapter preserves the extraction’s structure: overview, the workflow as ordered steps, points grouped by topic, tips and tricks, lessons, and a claims ledger, all timestamped. Sponsor segments (a PostHog read in the factory video, a Supabase read in the interview) are flagged and excluded from the advice. The Cloudroom chapter additionally flags that the video is the founder’s own launch. Phase 2 will extend this site with the channel’s remaining sixteen videos, including Ondrej’s earlier 6,775-session workflow, which is the natural before-and-after pair for the 15,700-session chapter.

• Video: https://www.youtube.com/watch?v=ZHOmBeMNbnc
• Format: solo presentation with live Cloudroom demos
• Transcript: Whisper-generated, timestamped [mm:ss]; all timestamps below refer to the transcript
• Speaker-name note: the transcript renders his name as “David André”; the channel/video author is David Ondrej
• Tag key: [Prescribes] = he tells the viewer to do this; [Reports] = he describes what he himself does or did; [Predicts] = his forecast; [Claim] = an assertion of his, unverified by us (also collected in section 7)

Promotional segments excluded from the advice sections below: sponsor segment for PostHog [04:46]–[05:34], and his own Cloudroom Ultra recruitment pitch [32:51]–[33:40] and [60:27]–[61:16] — pitches omitted; only the substantive workflow material around them is extracted.

1. Overview / thesis

Ondrej’s thesis is that the unit of human work is moving up a ladder — from doing the task yourself, to chatting with one agent that does it, to designing agentic loops (trigger-started agents that work and check themselves without you), to running a software factory (many agentic loops in parallel) [05:34] — because the human has become the bottleneck: models, tokens, and harnesses are no longer the constraint, unblocking agents one by one is [07:13][15:13]. He prescribes removing yourself from the loop via non-human triggers (schedules, webhooks, incidents, customer behaviour, other agents) and well-designed execution (model, skills, context, tools) [08:02][16:51], moving agents off laptops into always-on, elastic, isolated cloud sandboxes [18:29][24:25], and spending your own reclaimed time on the things agents cannot do: creative/novel thought, practicality, taste, resource allocation, model choice, evals, and first-principles thinking about the future [01:36][08:50][57:57]. He predicts this widens a productivity gap between operators who run factories and everyone else [56:22].

2. The workflow / system described, as ordered steps

His overall operating system, assembled from across the video in the order he builds the argument:

1. Stop doing agent-better work manually. Do the things humans are better at and let agents do the rest; holding onto line-by-line coding is, in his analogy, being the elevator operator after elevators were solved [02:28]. [Prescribes]
2. Audit where your time actually goes. He tracks his calendar in 15-minute increments and has done so for years, then asks an agent (via a “Compose Your CLI” skill, run inside Cloudroom) to summarise what he spent the last 14 days on, in broad buckets and leaving out private material [12:42][13:31]. [Reports]
3. Pick a small, predictable, safe slice — about 5% of your work — and automate it; then another 5%. Do not try to automate one big task; analyse the types of tasks you repeat (same kinds of email, Slack, customer delivery, brand deals) because type-level repetition is what an agent can absorb where plain programmatic automation could not [11:10][12:42]. [Prescribes]
4. Convert the slice into an agentic loop: design the trigger first, then the execution. Trigger = what starts the unit of work without you; execution = the model plus the skills, context, MCPs and APIs you give it. “Figuring out the trigger and the execution” is the core design act [16:51][17:42]. [Prescribes]
5. Give the loop a triage ending, not just an output. In his standing automations, the agent investigates, and either self-archives/self-closes when there is no issue or the finding is small, or escalates to him with a plain-English explanation and the proposed fix when it matters [27:40][28:33]. [Reports]
6. Move the loop off your laptop into the cloud. Always-on server/VM, each agent in its own isolated sandbox, elastic up and down, so agents do not die with your lid, Wi-Fi, or battery, and do not fight you or each other for one machine [18:29][20:03][24:25]. [Prescribes]
7. Scale by hierarchy, not by launching workers yourself. Design one agent that starts 10 (or 15, 25, 110): a top-tier model as manager/CEO, a mid model as coordinators, a cheap fast model as workers [20:49][21:45]. [Reports/Prescribes]
8. Multiply loops into a factory by department. Ask how your company would split into teams at 10x (or research a company 100x bigger), and create one loop per department-sized area: billing, database, security, feedback, codebase simplification, test gaps [26:52][39:27]. [Prescribes]
9. Add cross-model review as the quality gate. Whatever builds the work, a model from the other frontier company reviews it; the primary then judges whether the review is legitimate or overthinking [43:33]. For test-gap findings, two models must agree before a human sees the proposal [38:36]. [Reports/Prescribes]
10. Tune the factory over time. Expect each new automation to need tweaks on its first runs; delete loops that are not useful; adjust cadences (every 10 minutes, every 2 hours, every 4 hours, every 90 minutes) per loop [39:27][53:15]. [Reports/Prescribes]
11. Spend the freed human time on higher-level work: creating new agents, managing fleets, allocating resources between tokens/salaries/ads/hardware, choosing models and harnesses per task, building evals and benchmarks, and thinking [08:50][10:23]. [Prescribes]

3. Points and claims, grouped by topic

3.1 The future of work and what humans keep

• Agentic work has moved past one-to-one chatting with Claude Code or Codex; he dates the break to the Astra and Opus 5.5 releases [00:00]. [Claim]
• AI replacement is broad — programmers, video editors, mathematicians, graphic designers, content creators — so the live question is what humans will actually do [00:51]. [Predicts]
• Humans remain better at creative, novel thought and intuition/instinct, because a lifetime of audio, physical-touch and other non-text “tokens” is not in any training data [01:36]. [Claim]
• Humans remain better at practicality and resource allocation under constraints: an agent given one hour for a big project does not know what to skip, and will happily fill a repo with endless tests [01:36].
• Humans remain better at taste: anyone can generate 1,000 apps or hundreds of images, but only one goes viral or makes money; knowing what is good (product, thumbnail, song) is the human edge [01:36][02:28].
• Farming analogy: over 75% of US workers farmed in 1800, under 2% today, with more food than ever; likewise “human computers” did maths by hand in multi-floor buildings; the recurring pattern across history is that humans adapt [03:15][04:01]. [Claim]
• The maturity ladder: (1) do the task yourself; (2) interact with an agent that does the task — where most people are stuck; (3) design agentic loops; (4) run the agent factory. Each step up is less manual and repetitive, more unique, creative and abstract [05:34].
• Within 12 months the way you interact with agents will be very different from today; do not assume today’s prompting workflow persists [17:42].
• Everyone will soon run a “5,000-entity company” — a few humans, mostly agents — so everyone needs to get good at management [07:13]. [Predicts]
• The higher-level human job list: create new agents (specialised or general); manage fleets of agents by function (marketing team, product team, support team); allocate resources; choose models; establish evals; and think [08:50].
• Resource allocation becomes an explicit decision: for a business making $50,000/month, how much goes to tokens vs human salaries vs ads vs new hardware [08:50].
• Model choice becomes per-task routing: a cheap, cost-efficient model (he names DeepSeek V4.1 Flash) for easy tasks; a “decision model” that emits structured output and “cannot go wrong” for important structured tasks; the best available frontier model (Opus 5.5, or future Fable/Astra successors) for the most important tasks [09:38]. [Prescribes]
• Evals are part of the human job: track what percentage of tasks are done by agents vs humans, and how many tokens are being burned [10:23]. [Prescribes]
• “Spending more time thinking” is itself the higher-level work — how to take the business to the next level, where more agentic loops could exist, what you are not doing [10:23].
• The claim that AI will lift everyone equally is “a complete lie”: the gap between locked-in operators and average users is growing, and the cost of not being on the cutting edge has never been higher [56:22]. [Claim/Predicts]

3.2 The human bottleneck

• The current limit on running more agents is unblocking them: with fast models it is a challenge to keep even five agents unblocked one by one [07:13].
• The bottleneck is no longer the models, no longer token cost (“tokens are cheap”, and a $200 Claude subscription yields an “insane” amount of inference), and no longer the harnesses — “everything else” is missing [15:13]. [Claim]
• Symptom he shows from his own setup: hundreds of open threads, all waiting for him; he is “literally blocking all the agents” — except his automations and mini software factories, which start by themselves [16:01]. [Reports]
• Voice prompting is better than typing but still consumes your attention and time, so it is not a sufficient interface at scale; it was enough 6–12 months ago and no longer is [08:02]. [Prescribes/Claim]
• The founder/CEO’s time is the most valuable resource in any business regardless of size, and he is the bottleneck on nearly everything in his own small team [13:31][14:22]. [Reports]
• A director/manager agent that learns your prompting style and decision-making can unblock other agents more efficiently than expected — this “another agent as trigger/manager” layer is “the hardest frontier” [45:55][46:48]. [Reports/Predicts]

3.3 Agentic loops and software factories (definitions)

• An agentic loop: a trigger starts an agent, the agent does work, there is a check, and it repeats [49:58].
• A software factory: many different agentic loops working together in parallel toward a specific outcome in your life or business [50:45].
• An agentic loop can still contain a human (e.g., an approval step); a software factory really should not — it should run by itself [10:23][11:10].
• He deliberately says mini software factory for his own setup: the claim should only be made when it is fully there; what exists now is early-days, multiple loops across software disciplines rather than one loop [49:58][50:45]. [Reports]
• The two halves of every loop are the trigger and the execution; triggers are “like half of it” [46:48].
• Execution design is “the art”: which powerful model, which skills, which context, which MCPs and APIs [17:42].

3.4 Triggers (what starts an agent, instead of a human)

• Schedules: every 15 minutes, every hour, every 3 hours, every 5 hours, once a day [08:02][45:09]. [Prescribes]
• Webhooks — he singles these out as likely the most flexible trigger type [45:09].
• Incidents and system signals: database at 90% of allowed concurrent connections, payments failing, a database outage, an error spike [16:51][45:09].
• Customer behaviour and customer feedback: the more customers you have, the more feedback triggers you have [08:02][45:09].
• Proactive work on a schedule, e.g., a proactive bug hunt [45:55].
• Another agent: a manager/director agent starting and unblocking other agents is a trigger type in its own right, and the frontier case [45:55].

3.5 Local vs cloud agents; the “laptop problem”

• Running many agents on one laptop is like telling a new employee they will share one laptop with 20 other people; worktrees help “a little bit” but agents still conflict, and computer-use agents fire pop-ups and open browser tabs while you are trying to work [18:29]. [Prescribes/Claim]
• Local agents die when you close the laptop, lose Wi-Fi, or run out of battery; once agents do 20–60% of a business’s tasks, a dead laptop means “your business has died” [19:15]. [Predicts]
• One agent deciding to open Docker Desktop and run a large test suite is enough to make a laptop unusable (fans) [20:03]. [Reports]
• A powerful local box (Linux machine, Mac Studio) solves capacity only up to a fixed X of agents; it cannot flex +20% for a few days or a week, and most people cannot launch hundreds of agents locally at all [20:49].
• Cloud properties he wants: always-on (he says at least 99.99% availability with fast internet), each agent in an isolated sandbox, pay only while agents run, effectively unlimited scaling (10 agents = 10 sandboxes; 500 = 500) [20:03][24:25]. [Prescribes]
• Local still has some value (privacy, cleaning up your own folders), so cloud will approach ~90%+ of agent work but not 100% [23:39]. [Predicts]
• Computer use has progressed massively in 3–4 months (he names Codex computer use and the Cua driver): agents can operate convoluted interfaces like AWS and Google Cloud consoles so “you never have to use them ever again” — but on your own machine they take over your screen, raise permission prompts and open tabs while you work [25:19]. [Claim]
• Security argument for cloud: if one cloud sandbox is compromised, only that agent/sandbox is lost; if your main machine is compromised (bad model, injected instruction, malicious package), you lose everything on it — logins and data [26:06].
• He built an open-source stopgap called Immortal Agents (under his Vectal Labs org): whenever an agent goes to sleep or dies (lost internet, closed laptop), it restarts itself when the machine reopens, so agents keep running [22:39]. [Reports]

3.6 His standing automations (the mini factory, as reported)

Each of these is a loop he says is live in his Cloudroom setup [26:52][38:36]:

• Billing review — every 4 hours, checks all billing code for issues, new bugs, anything missed last time [26:52].
• Database health check — watches for database problems as load changes (concurrent connections, CPU, memory) [26:52].
• Bug-report triage — anyone can report a bug “to David” inside Cloudroom; every 10 minutes the automation checks a table in Supabase, and on a new entry spawns an Opus 5.5 agent to investigate [27:40].
• Security sweep — every 90 minutes, extensive penetration testing and cybersecurity testing of his codebase; “if you are not doing that, someone else will do it on you” [29:23].
• Sandbox alerts — watches for sandbox issues and limit hits [38:36].
• Feedback threads, GitHub issues, PR overview of public repos — standing loops over incoming user feedback and repo activity [38:36].
• Codebase simplification — looks for unnecessary complexity and unused code; he shows its 16th execution, which ran 4 minutes 12 seconds and returned a cleanup candidate [38:36][42:41]. [Reports]
• Test gap — hunts for missing tests, but deliberately designed against agents’ tendency to flood a codebase with tests (details as a recipe in section 6) [38:36].
• The framing: these automations are the departments of a large software company (a database team, a billing/payments team, a cybersecurity/auth team) rebuilt as loops for a lean team [26:52][27:40]. [Reports]
• Result he claims for the whole setup: a very lean team doing more work than companies with 50, 100, or 200 developers [28:33]. [Claim]

3.7 Prompts, skills, and the predicted “sequences”

• A prompt template is the simplest unit: something you do all the time, saved for instant reuse [46:48].
• His own daily prompt templates (invoked as Raycast snippets, faster than typing) include: “rebase off of main, check the underlying code to see if it’s been fixed or not yet, answer in short and plain English”; “don’t be verbose, make your answer simpler and shorter, focus on what really matters”; “run 4x varied search, 3x deep research and 3x deep scrape on this”; “anything else to do here — remind me of the original purpose of this thread” [46:48][47:37]. [Reports]
• Skills are the next level: more advanced, repeatable processes — “SOPs in companies, standard operating procedures” — not just a markdown file [47:37].
• His skill inventory includes decision skills, a GPT-reviewer skill (run the opposite model as reviewer), a total-review skill, GUI-release and core-release skills, and computer-use skills; his skills repo is open source [47:37][48:27]. [Reports]
• Limit of prompts and skills: you are still needed in the loop to invoke them; they are directionally correct but not the end state [48:27].
• Sequences (predicted paradigm): after skills, the next step will be sequences — multiple skills chained together automatically, inferred from probability over your own behaviour: from thousands of stored agent sessions/traces, a system can learn that in a given situation you run three specific skills back to back with ~98% probability, and run that chain for you [48:27][49:13]. [Predicts]
• Both modes still need optimising in parallel: asynchronous agent work and the synchronous human moments that remain [49:13].

3.8 Models, subscriptions, and inference economics (his setup, as reported)

• He routes by task importance and by company: ~98% of his threads run Opus as the primary model; GPT models are used mainly for review [43:33][44:22]. [Reports]
• Cross-company review rule: if you build with a GPT model, review with Opus; if you build with Opus, review with GPT (he names GPT 6.1 Sol / Astra as reviewers, sometimes both for a serious change) [43:33]. [Prescribes/Reports]
• After a GPT review of Opus-built work, he asks Opus to adjudicate: “is this legit or is this just overthinking?” [44:22]. [Reports]
• Avoid API pricing; subscriptions are the better deal. If API pricing is unavoidable, use Chinese models (“a much better deal”) or Haiku [44:22]. [Prescribes/Claim]
• His subscription history: before Opus 5.5 he ran six $200/month Codex plans ($1,200/month) because Astra was, for about three weeks, the best model; after Opus 5.5 released, one $200 Claude subscription handled the same or more tokens because Opus is faster; he now pays for two Claude subscriptions, the second to run more agentic loops, all out of his own pocket [41:04][42:41]. [Reports]
• Unused subscription capacity is the failure mode to fix: many users let more than half of a weekly limit go unused; downgrading to save $100 is “admitting you don’t know how to turn tokens into revenue”, which he calls the main skill of the future — can you generate more money from the tokens than the subscription costs? [37:45]. [Prescribes]
• Candidate places to point spare frontier-model capacity: improve marketing, improve the product, cybersecurity, and the standing automations list (billing, database, feedback, issues, PRs, sandbox alerts, security sweep, simplification, test gaps) — “just steal it, steal my automations” [37:45][38:36]. [Prescribes]
• Taste is still required on top of the strongest model: for Cloudroom’s designs/animations he asked Opus 5.5 for multiple variations and made tweaks himself to get them smooth [36:58]. [Reports]

3.9 Cloud agents are hard (why they are not yet default)

• The best-known cloud-agent products are closed source (he names Codex, Cursor, Claude, Devin from Cognition AI) and there has been no good option combining data sovereignty, exportable chats, and freedom to use any model, any harness, any subscription [30:19]. [Claim]
• Cloud threads must feel as fast as local or people will not adopt them; repos, context and skills must be there; users want to use the subscriptions they already pay for rather than being forced onto a vendor’s harness and subscription (his criticism of AMP and Devin) [30:19][31:09]. [Prescribes]
• Sometimes the agent still needs a laptop (local files/folders), so a platform should let you choose per thread: local, local worktree, or cloud sandbox [31:58]. [Prescribes]
• His stated Cloudroom goal: an open-source platform “to run thousands of agents productively” from a single interface, any model/harness/subscription [31:09][55:36]. [Reports]
• Demo evidence he offers: one prompt instructing a main agent to launch subagents starts them in under a second in Cloudroom, where he says most cloud platforms take 20–30 seconds to boot a sandbox; each subagent gets its own isolated sandbox so they do not compete for CPU/RAM/disk [33:40]. [Claim/Reports]
• Live control operations in the demo: pause all subagents, archive a thread together with all its subagents, and relaunch the same job as a different harness/model with a different subagent count (15 Sonnet subagents → archived → 25 Codex subagents on GPT 6.1 Sol) [34:32]. [Reports]
• Agents/threads can be tagged, can interact with each other, and can form complex hierarchical relationships; “your creativity is the limit” [54:47]. [Reports]

3.10 Thinking as the scarce work

• His team’s reasoning practice: pick one topic (“why is this company growing?”, “we noticed this trend in how people use AI — what does it imply?”, “what do cheap decision models imply?”) and reason aloud about it for 60–90 minutes, voice-recorded, with no phones and no computers [57:57]. [Reports]
• Reason from first principles about human behaviour, market dynamics and technological breakthroughs; follow second-order and third-order consequences; do not leave the table until ideas start flowing — the first 5–10 minutes are usually stuck and unproductive [57:57][58:44].
• Doing this daily for one to two months would, he claims, give you a better understanding of the future than most people in AI have [57:57]. [Claim]
• This is how he says he derived Cloudroom: reason about what the bottleneck will be (models already strong enough for hundreds/thousands of agents, but nobody running them productively), then solve bottlenecks one at a time [58:44]. [Reports]
• He quotes Joshua Reynolds — there is no expedient to which a man will not resort to avoid the real labour of thinking — and argues people will do almost anything to avoid sitting down and thinking through career/industry questions [58:44][59:35].
• Clicking around is no longer the hard part: an agent with computer use plus a couple of MCPs/tools can do it better than humans; the difficult work now is thinking and reasoning about the future from first principles [59:35].

4. Tips and tricks (concrete, actionable)

• Start with 5% of your work — the most predictable and safe slice — automate that, then do another 5% [12:42]. [Prescribes]
• Audit types of tasks, not individual tasks: list the kinds of work you repeat daily (emails, Slack, deliveries, deals) — those types are the automation candidates [11:10].
• Track your time like you track accounting: you cannot optimise allocation you have not measured; most people are wrong about their own splits (they think 20%, it is 60%) [13:31].
• When you ask an agent to analyse your time, constrain the output: broad buckets only, leave out private material [12:42].
• Use a snippet tool (he uses Raycast snippets) for the prompts you repeat daily, so invoking them is near-instant [47:37].
• Standard output-shaping snippets worth copying: “answer in short and plain English”, “don’t be verbose… focus on what really matters” [46:48].
• A research-depth snippet pattern: “run 4x varied search, 3x deep research and 3x deep scrape on this” [46:48].
• A thread-hygiene snippet: “anything else to do here? remind me of the original purpose of this thread” — to re-anchor a drifting agent thread [46:48].
• Convert anything you find yourself repeating into a skill (an SOP), not just a prompt [47:37].
• Design one agent that starts ten, instead of launching ten workers yourself; hierarchy is the leverage move [21:45].
• Mix models by hierarchy level: frontier model as manager, mid model as coordinators, small/fast model as workers (his 110-agent demo: Opus → Sonnet coordinators → Haiku workers) [20:49].
• Mix harnesses freely per role: e.g., Opus as orchestrator with Sol as workers, or Astra managing with Opus/Sonnet implementing [34:32].
• Always review with the second company’s model, never the same company’s [43:33].
• For serious changes, run both rival models as reviewers, not just one [43:33].
• Ask the primary model to adjudicate the review (“is this legit or just overthinking?”) instead of applying review comments blindly [44:22].
• Build the loop so the agent triages itself: no issue or trivial finding → self-archive/self-close; real issue → plain-English summary plus the proper fix, left open for you [27:40][28:33].
• Steal his automation list as a starter portfolio: billing review, database health check, customer-feedback threads, GitHub issues, PR overview, sandbox alerts, security sweep, codebase simplification, test gap [38:36].
• Run a security sweep on a short cadence (his: every 90 minutes) rather than as an occasional project [29:23].
• Cadence is a design knob per loop: his portfolio spans every 10 minutes (bug reports) to every 4–5 hours (billing/database) [39:27].
• Keep big product decisions and UI/UX calls human — agents still lack taste there — while handing agents backend bugs, database optimisation and speedups, where he says Opus is better than him [53:15][54:02]. [Prescribes/Reports]
• Do not pay API prices when a subscription covers the work; treat unused weekly subscription limit as wasted money [37:45][44:22].
• Ask “what else can I point the frontier model at?” as a recurring question, and try candidate loops even if some get deleted later — you only find the great ones by trying [40:13].
• Schedule the reasoning session like work: 60–90 minutes, one topic, voice-recorded, devices away, and stay past the unproductive first 5–10 minutes [57:57].

5. Lessons learned / mistakes he names

• Mistake: assuming agent work will stay the way it is now. People extrapolate from ChatGPT/Claude/Perplexity/Cursor chat interaction; the bottleneck shift means the interaction model itself changes [14:22].
• Mistake: trying to automate everything as one big task. His long-standing advice (from his N8N-era content two to three years ago): automate a small task first [11:10].
• Mistake founders make: not enough feedback from real users. The faster AI lets you build, the more important real customer data becomes, because you still need to know whether you are building the right thing [04:01].
• Mistake: being the approval bottleneck and not noticing. If you are unblocking agents one by one, you personally cap the fleet at roughly a handful of concurrent agents [07:13][16:01].
• Mistake: running the factory on a laptop. Lid, Wi-Fi, battery, shared-screen computer use, and fixed hardware all silently kill or cap the operation [18:29][19:15].
• Mistake: buying a big local box and thinking the scaling problem is solved. Fixed capacity cannot flex for temporary spikes or hundred-agent jobs [20:49].
• Mistake: letting subscription limits expire unused, or downgrading to save money — both are failures to convert tokens into value, and token-to-revenue conversion is the core future skill [37:45].
• Mistake: measuring output by volume. Flexing lines of code or counts of generated markdown files (he mocks a claim of “over half a million markdown files”) “just shows you’re a dummy and a beginner”; cheap models can generate volume, so volume proves nothing [53:15].
• Mistake: expecting a new automation to be right immediately. New loops need tweaks over their first few runs, otherwise they waste tokens or add slop [53:15].
• Mistake: letting agents write tests unchecked. Agents “love tests” and will flood the codebase with unit/component/integration tests; a naive test-gap loop makes the codebase worse — hence the dual-model agreement gate in his test-gap automation [38:36].
• Mistake: reviewing with the same company’s model — you miss the different viewpoint; cross-company review is his corrective [43:33].
• Mistake: holding onto tasks the models are already better at (ego) instead of letting go and building loops around them [54:02].
• Mistake: believing AI lifts everyone equally, and not pricing in the widening gap when planning your own positioning [56:22].
• Mistake: avoiding the labour of thinking. People will happily work a job for decades rather than sit down and think about which industry/job they should be in; clicking and doing is no longer the hard part [59:35].

6. Processes and recipes (repeatable procedures)

Recipe A — Find your first loop (time-audit → 5% slice) [12:42]–[14:22]

1. Track your time in fine increments for a sustained period (he uses 15-minute calendar tracking, kept for years).
2. Have an agent summarise the last 14 days into broad buckets (privacy-constrained prompt: broad buckets, omit private material).
3. Compare perceived vs actual allocation; locate the founder/CEO time sinks.
4. Select the most predictable, safe task types worth about 5% of your work.
5. Replace that slice with an agentic loop or mini factory; then repeat with the next 5%.

Recipe B — Design any agentic loop (trigger + execution) [16:51]–[17:42]

1. Define the unit of work.
2. Choose a non-human trigger: schedule, webhook, incident/system threshold, customer behaviour/feedback, or another agent.
3. Design the execution: pick the model; attach the skills, context, MCPs and APIs the agent needs.
4. Define the check/triage ending: what the agent does with a finding (fix, archive, or escalate in plain English).
5. Run it, watch the first runs, tweak until it produces good results instead of slop, and set its cadence.

Recipe C — Department mapping (how to invent loops for any business) [26:52], [39:27]

1. Imagine your company 10x bigger (or find a real company ~100x bigger in your industry and study it).
2. List how the work would split into departments/teams there (for a software company: database team, billing/payments team, security/auth team).
3. Create one agentic loop per department-sized area, using today’s tools.
4. Assign each loop its trigger and cadence (e.g., every 10 minutes, every 90 minutes, every 2 hours, every 4 hours).

Recipe D — Bug-report loop (fully worked example) [27:40]

1. Give users an in-product “report this” path that writes an entry to a table (his: a Supabase table).
2. Every 10 minutes, an automation checks the table for new entries.
3. On a new entry, spawn a top model (his: Opus 5.5) to investigate.
4. Triage: if it is a small edge case or a misaligned idea, the agent self-archives the thread; if it is a serious issue or a great feature idea, the agent investigates, explains it in a few plain-English sentences, names the proper fix, and leaves the thread open for the human.

Recipe E — Test-gap loop with dual-model agreement [38:36]–[39:27]

1. An Opus agent scans parts of the codebase for gaps where an “obviously good” test is missing (not generic test generation).
2. Each candidate test is handed to a second, rival model (his: GPT 6.1 Sol, extra high) for adversarial review — the reviewer assumes the test is unnecessary and tries to kill it.
3. Only if both models agree the test is good does the proposal pass.
4. Passing proposals go to the human for approval.

Recipe F — Cross-model review of finished work [42:41]–[44:22]

1. Do the work with your primary model (his default: Opus; ~98% of threads).
2. Launch a reviewer from the other frontier company (GPT model reviews Opus work; Opus reviews GPT work); for serious changes, launch both GPT reviewers.
3. Feed the review back to the primary model and ask it to judge: legitimate problem, or overthinking?
4. Apply only what survives adjudication. (His codebase-simplification loop runs this inverted the same way: the finder proposes, the rival model reviews for legitimacy before anything is deleted.)

Recipe G — Hierarchical fan-out (one prompt, many agents) [20:49], [33:40]–[35:20]

1. Write one prompt to a manager agent describing the overall job and the fan-out.
2. Assign tiers: strongest model as top manager, mid-tier as coordinators, cheap/fast as workers (110-agent example: Opus → Sonnet → Haiku).
3. Put each subagent in its own isolated sandbox so they do not share CPU/RAM/disk.
4. Manage the fleet as a unit: pause all, archive a thread with all its subagents, or relaunch the whole job under a different harness/model and headcount.
5. Before scaling, define the quality apparatus — skills, rules, conditions, user interfaces, review processes — so the fan-out produces good work, “not just a bunch of slop” [21:45].

Recipe H — Build a new automation in plain English (live demo) [51:31]–[56:22]

His exact demonstration, dictated by voice in under a minute:

1. Create a new automation: every 2 hours, spawn a new thread on Opus 5.5 Extra High.
2. Task: scan all ADRs in /docs/ADR and the decisions in /docs for one obvious product improvement (a feature, clearer UI, anything aligned with the recorded decisions).
3. On finding a candidate, spawn a reviewer subagent (GPT 6.1 Fast Extra High) to do adversarial review: argue why this should not be built.
4. Return the review to the main agent, which re-judges from first principles.
5. If the main agent agrees with the reviewer, archive both threads; if it disagrees, leave the thread open for David to review.
6. Afterwards: run a test execution, click through the tagged threads to inspect the subagent’s work, and manage (enable/disable) the automation from the automations list.

Recipe I — Prompt → skill → (predicted) sequence maturation path [46:48]–[49:13]

1. Save repeated one-off prompts as instant prompt templates/snippets.
2. Promote repeated multi-step processes into skills (SOPs).
3. (His prediction) Let a system mine your accumulated agent traces to detect the skill chains you run with high probability in given situations, and execute those chains as sequences without you invoking each skill.

Recipe J — First-principles reasoning session [57:57]–[58:44]

1. Pick a single question or trend (a company’s growth, a user-behaviour shift, a new model class’s implications).
2. Sit for 60–90 minutes with no phones or computers; talk it through, voice-recorded.
3. Reason from first principles: human behaviour, market dynamics, technological breakthroughs.
4. Push into second-order and third-order consequences.
5. Do not stop at the stuck first 5–10 minutes; stay until ideas flow.
6. Repeat daily; he claims a month or two of this beats most insiders’ model of the future.

Recipe K — Keep agents alive (Immortal Agents pattern) [22:39]

1. Run a watchdog over local agents.
2. Detect when an agent has gone to sleep or died (internet loss, laptop closed).
3. Automatically restart it when the machine/environment recovers, so loops resume without a human relaunch.

7. Notable claims — Ondrej’s, unverified by us

Predictions

• In 12 months you will run far more agents than today, interact with them very differently, and starting agents one by one will be obsolete [06:27][17:42].
• Over 95% — probably over 98% — of agent tasks can be done better in the cloud than locally; cloud will reach ~90% of production agent work but not 100% [23:39].
• “Sequences” (probability-inferred chains of skills, mined from your agent traces) will be the next paradigm after skills, “the next big paradigm” over the next six months [48:27][49:13].
• Agent-to-agent triggering and director agents that learn your style and decision-making are the hardest and most consequential frontier [45:55].
• Security will become a token-spending arms race: whoever spends more tokens trying to break in vs defend wins; continuous automated security testing is not optional [29:23].
• The productivity gap between cutting-edge agent operators (running 50–200 agents productively) and everyone else will keep growing and will be “not even fair”; most people still use no AI or only free ChatGPT/Gemini tiers [56:22].
• As agent counts rise into the hundreds per person per day (he says he already interacts with hundreds of agents daily), management of fleets becomes a universal job skill [07:13][17:42].

Numbers and factual-sounding claims

• His credentials claim: well over 2,000 hours coding with AI over four years, plus interviews with leading AI practitioners [00:00].
• OpenAI “just dropped” a repo with ~370 proofs of previously unsolved maths problems, some unsolved for decades or centuries [00:51].
• Farming share of US workers: over 75% in 1800, under 2% today [03:15].
• Cursor internal study, as he reports it: cloud agents produced ~10% of PRs reaching production at the start of the year and over 60% by August [22:39].
• SemiAnalysis research, as he reports it: the $200 Claude subscription gives roughly 10.6x the value/usage of the $200 Codex plan; his own earlier (viral, “less scientific”) estimate was 16–20x; he also says OpenAI halved the Codex $200 plan’s usage and then released a $500 plan [41:04][41:51].
• Anthropic subscriptions are “subsidized like 90%” versus API pricing (he variously says 50–90% cheaper than API) [37:45].
• His spend history: six $200 Codex plans ($1,200/month) before Opus 5.5; currently two $200 Claude subscriptions, self-paid [41:04][42:41].
• His usage split: ~98% of his threads run Opus as primary [43:33].
• Demo claim: a Cloudroom engineer had one agent start 110 agents in a three-tier hierarchy (Opus managers, Sonnet coordinators, Haiku workers) from a simple prompt [20:49].
• Demo claim: Cloudroom cloud threads/subagents start in under a second, vs 20–30 seconds sandbox boot on most cloud agent platforms [33:40].
• Guillermo (Vercel CEO), quoted from his interview: “Cloud is infinitely better for security” [25:19].
• His codebase-simplification automation’s 16th run took 4 minutes 12 seconds and produced a cleanup candidate [42:41].
• His skills repo is open source and his most popular repo, at over 4,000 stars [47:37].

Product and model claims (his opinions, stated as fact)

• “Astra is AGI” / “Opus 5.5 is already AGI level… if you disagree, you are wrong”; Opus 5.5 is “by a lot” the best model right now — extremely fast, token-efficient, smart, and responsible for design/animation quality no other model would come close to [00:00][36:10][36:58].
• Model-release whiplash: Astra was the world’s best model for a solid three weeks, far better than Fable 5.1, until Opus 5.5 displaced it; another major release could change everything within two to three weeks [41:04][41:51].
• Only two frontier companies exist right now — OpenAI and Anthropic; “other companies are trying to be Frontier, but… it’s not even close” [43:33].
• If forced onto API pricing, Chinese models are the best deal, and Anthropic’s Haiku is also a good deal [44:22].
• Cloudroom claims (his own product): the world’s first AI coding tool giving every thread a cloud agent in its own separated environment; the goal of being the best open-source cloud-agent platform; local and cloud threads feel the same speed (demonstrated by running the same prompt in both and asking each what machine it is on — the cloud sandbox answered at the same speed as the local MacBook Pro thread) [54:47][55:36].

Video: https://www.youtube.com/watch?v=F8rc-ULd4_4
Format: Solo presentation and live demonstration of Ondrej’s own workflow
Transcript duration: 85:40
Extraction basis: Whisper transcript with [mm:ss] timestamps

Sponsor content: No third-party sponsor segment was identified; Cloudroom is Ondrej’s own product, so its promotional superlatives are excluded from the advice sections and recorded only as claims in §7.

1. Overview

Ondrej presents a frontier-model-first, agent-operated software workflow built around one task per thread, reproduction before bug fixing, risk-triggered planning skills, restrained test generation, cross-lab model review, direct shipment to production, isolated cloud agents, and an expanding set of autonomous loops for repetitive work [00:00] [08:35] [50:34]. His practice is to build primarily with Opus 5.5, review medium and large work with a frontier model from a rival lab, use subagents only for predictable parallel chunking, and gradually remove himself from recurring processes through session “scans” and a 10–90 autonomy split [01:00] [14:14] [22:22] [58:26]. He frames the endpoint not as manually designing a complete “software factory,” but as accumulating 10–30 small loops until the collection behaves like one [45:08] [46:01]. A second closed loop turns user and agent bug reports into investigated threads, approved fixes, cross-model reviews, and production releases, making Cloudroom partly self-improving [68:18] [72:57] [73:55].

2. His workflow as an ordered end-to-end process

1. Start with exactly one task in one Cloudroom thread. Give the thread one feature, bug fix, investigation, or other clear unit of work; fork unrelated work into another session instead of mixing tasks [08:35] [09:26].
2. Classify the work. Decide whether it is a bug, feature, research task, or another kind of task, because the next step differs by type [09:26].
3. For a bug, reproduce before fixing. Have the agent reproduce the problem end to end as a real user would, using a test, simulation, or experiment where useful; do not start from a vague bug description alone [09:26].
4. Assess size and risk. If the change is not big or risky, proceed directly to implementation. If it is big or risky, invoke the relevant planning and safety skills before building [10:22] [11:10].
5. For a big change, run the “4x4” skill. The skill extracts 16 decisions in four sets of four: product, software design, practical considerations, and edge cases. Ondrej does not run it for small changes [11:10] [12:10].
6. Let “Risky Changes” act as the safety gate. This automatically triggered skill is intended for changes where an error could hurt customers; it originated after a filter passed all tests on live data while disabling 99% of a feature [12:10].
7. Build with a frontier model at high effort. Ondrej’s default builder is Opus 5.5, generally at extra-high or maximum reasoning; he treats the workflow as dependent on frontier capability rather than cheap or small local models [01:00] [13:12] [14:14].
8. Run tests and type checking, but suppress indiscriminate test writing. Instruct agents not to write tests unless truly necessary; add one or two strategic tests when a repeated class of error reveals a genuine prevention need [10:22] [12:10] [13:12].
9. For UI work, inspect screenshots or renders. Ask the agent to show the fixed or redesigned application visually—potentially several alternative renders—rather than relying only on code and prose [10:22].
10. Review normal medium or large changes with the other frontier model. If Opus or another Anthropic model built the change, run “GPT Review” using OpenAI’s frontier model at extra-high or maximum effort; if an OpenAI model built it, review with the latest Anthropic frontier model [14:14] [15:11].
11. Escalate only huge, unusually risky changes to “Total Review.” Total Review sends the change to frontier models from multiple labs, including Fable, Opus, Astra, Sol, and Muse, then deduplicates the findings and surfaces the most serious ones; Ondrej uses it only a few times a week because it is slow and token-intensive [15:11] [16:13].
12. Triage findings instead of obeying them automatically. Issues are scored from 1 to 10 and considered on two axes: how bad the issue would be and how often it could occur. A severe but extremely improbable edge case may be skipped [16:13] [17:15].
13. Ask the builder whether each finding is real. Ondrej sends review findings back to the primary model—normally Opus—with the substance of this question: is this a real must-fix issue, or is the reviewer overthinking? The builder may accept most findings while rejecting an implausible one [17:15].
14. Fix accepted findings, then use second opinions sparingly. If the builder is unsure, obtain another model review; if the fix itself is uncertain, optionally re-review it. Do not repeatedly chain Opus Review, GPT Review, and further reviews because reviewers instructed to find bugs will keep inventing or elevating marginal issues [16:13] [17:15] [18:24].
15. Ship when nothing material remains. Pull, rebase onto main, pass CI checks and tests, and ship directly to production [18:24].
16. Let post-shipment loops look for side effects. Dedicated loops test recent changes for effects elsewhere in the codebase, including security and regression risks that a change-specific review may miss [18:24] [19:26] [52:37].
17. Convert repeated manual work into agent loops, one or two at a time. Identify boring, predictable, repeatable work; do not begin by architecting an entire software factory [45:08] [46:01] [47:44].
18. Mine prior sessions to discover loop candidates. Run a Cloudroom “scan” over prior Claude Code, Codex, Hermes, Pi, or OpenCode sessions to find repeated prompting habits, skill sequences, workflows, and problem-solving patterns [54:25] [55:17].
19. Roll each new loop out with the 10–90 split. Automate only the safest and most obvious 10% end to end; for the other 90%, have the loop analyze, research, and propose an action while waiting for human confirmation [56:20] [58:26] [61:10].
20. Feed product reports into the self-improving loop. A user can press the feedback button, or either the user or an agent can state a problem in plain English and have the agent report it through Room CLI; the report enters a Postgres table [68:18] [69:04] [70:04].
21. Poll for reports and open an investigation thread. Ondrej’s feedback loop checks for new reports every minute and opens a new cloud thread in his own Cloudroom workspace when one appears [70:04] [72:57].
22. Investigate read-only first. The agent examines the report without editing. If it is noise, a duplicate, already being handled, or already fixed in a newer version, the thread uses the “self-archive” skill and removes itself from the active workspace [72:57] [73:55].
23. Escalate genuine reports into an issue and a decision summary. A real bug, product improvement, or good idea becomes a GitHub issue with a short summary and waits for Ondrej or a developer to approve it; an unapproved item is archived [72:57] [73:55].
24. Implement, cross-review, and ship approved feedback. After approval, an agent fixes the issue, a different frontier model reviews it, and the change ships back into the product for all users [73:55] [74:57].

3. Points and claims, grouped by topic

3.1 Models, harnesses, and subscriptions

• [His practice] Opus 5.5 is his primary model. He uses it inside Claude Code or another harness, including Cursor’s CLI as rendered in the transcript, and says he had exhausted two subscriptions and might need a third [00:00] [01:00].
• [His ranking] Opus 5.5 is the model he reaches for most. He describes it as both highly capable and fast, with Fable 5.5 potentially forthcoming [00:00] [01:00].
• [His ranking] Astra is his preferred OpenAI model. He prefers Astra to Sol because Astra has what he calls the “big model smell”; he regards OpenAI as behind Anthropic at the time of recording [01:00].
• [Prescription] Do not ignore non-frontier labs entirely. Google, Meta, Kimi, and other model providers make useful models, but he does not place them at the true frontier for his main work [01:48].
• [His view] The harness is becoming less important. He says two Anthropic engineers told him that a sufficiently powerful model with terminal and internet access will perform similarly across harnesses such as Claude Code, Devin, or Droid [01:48].
• [His practice] He uses many harnesses despite favoring one environment. The harnesses he names are Pi, Claude Code, Hermes, and OpenCode [01:48].
• [Prescription] If buying one premium subscription, he would choose Claude Max $200. He ranks the Claude $100 and $200 subscriptions as better value than Codex and the OpenAI ChatGPT Pro subscription as second, while criticizing OpenAI for repeatedly changing its offer [02:53].
• [Prescription] OpenCode Go is his budget recommendation. He identifies its $10 subscription as a good low-cost option [02:53].
• [His assessment] Other subscriptions are situational. He says a Grok-related subscription can suit people who like Grok Bot and certain Cursor or xAI products; he is dismissive of Google’s present offer but calls Argon promising and the unreleased Carbon potentially stronger [02:53].
• [His practice] Cloudroom is now his only ADE. He describes Cloudroom as the agent development environment he built, uses it for local and cloud agents, and says it can use the user’s existing harnesses, models, and subscriptions [02:53] [03:56].
• [Boundary condition] Most of the workflow assumes frontier models. Ondrej explicitly warns that shipping directly to production at his cadence does not translate directly to Haiku-class, Luna-class, cost-optimized, or small locally hosted models; his main work uses Opus 5.5 at extra-high or maximum effort [13:12] [14:14].

3.2 What an agentic engineer should learn

• [Prescription] Learn concepts and architecture, not syntax memorization. Do not focus on memorizing Python or TypeScript words; understand what distinguishes JavaScript from TypeScript, what a typed language is, why Rust is fast, and how Rust provides memory safety [04:48].
• [Prescription] Think like a software architect. The valuable skill is recognizing the relevant concept behind an observed behavior—for example, asking whether an instant page transition comes from preloading, caching, or optimistic loading [04:48].
• [Prescription] Build breadth across system concepts. Every software builder should have working awareness of trade-offs, caching, observability, blast radius, coupling, and cohesion, without needing expert implementation depth in each [05:53].
• [Prescription] Learn unfamiliar concepts in short, AI-assisted bursts. His concrete suggestion is to spend about 30 minutes learning a concept, using AI itself as the tutor [05:53].
• [His claim] AI-assisted self-upskilling predicts success. He describes using AI to upskill oneself as one of the highest predictors of success he has observed [05:53].
• [Prescription] Measure output rather than assuming AI is helping. He had Opus scrape and visualize his GitHub activity to distinguish real acceleration from time spent building internal tooling or otherwise wasting effort [06:42] [07:32].

3.3 Task management and implementation

• [Prescription] One thread, one task. A thread should correspond to one clear feature, bug fix, investigation, or equivalent ticket; do not mix unrelated work in the same agent session [08:35] [09:26].
• [Prescription] Fork instead of contaminating a thread. If another matter appears, fork the session or create a new thread rather than combining tasks [09:26].
• [His practice] His Cloudroom workspace contains hundreds of open threads. He reports 550 open threads during one check and says the count had exceeded 800 the previous day before he closed many [07:32] [08:35].
• [Prescription] Reproduce bugs end to end. For a bug, the agent should behave like a real user and reproduce the failure; tests, simulations, and experiments are legitimate reproduction methods [09:26].
• [Prescription] Use screenshots as a review artifact. For UI changes, request screenshots of the real or proposed app; when exploring a redesign, ask for multiple visual renders before committing to a direction [10:22].
• [Prescription] Store repeated prompts as snippets. Ondrej keeps frequent prompts and phrases in Raycast Snippets, with macOS Text Replacement as the built-in alternative, rather than retyping them [11:10].
• [Prescription] Promote complex recurring prompts into skills. A repeated instruction that is more than a simple snippet should become a reusable agent skill [11:10].
• [His practice] His personal skills are published in an open-source repository. He identifies the repository as his most popular GitHub repo and names reusable skills including 4x4 and Risky Changes [11:10] [12:10].
• [Prescription] Use 4x4 only when the change justifies it. The four question sets cover product, software design, practical issues, and edge cases; Ondrej does not run it on small changes [11:10] [12:10].
• [His practice] Risky Changes runs automatically. He had partly forgotten the skill existed because agents were already invoking it whenever they undertook risky changes [12:10].
• [Prescription] Do not let agents maximize test count. Ondrej instructs agents not to write tests unless truly necessary because, in his experience, agent-authored tests often merely pass by construction, add bloat, and do not test meaningful behavior [12:10] [13:12].
• [Prescription] Add tests strategically after a failure pattern appears. If agents repeatedly make the same class of mistake, implement one or two tests aimed at that class rather than adding broad test volume preemptively [13:12].

3.4 Review philosophy and cross-model verification

• [Prescription] Use the rival lab’s frontier model for review. Building and reviewing with models from different labs is intended to expose blind spots that a single model family may share [14:14] [15:11].
• [Prescription] Review every medium or large change this way. His common path is Opus builds, GPT Review checks; the reverse applies when starting with an OpenAI model [14:14] [15:11].
• [Prescription] Reserve Total Review for genuinely huge changes. Total Review combines multiple frontier models and deduplicates their findings, but its cost and latency make it inappropriate as the default [15:11] [16:13].
• [Prescription] Evaluate a finding by likelihood multiplied by impact. A catastrophic but practically impossible scenario may not merit a fix, while a serious and plausible problem should be addressed [16:13] [17:15].
• [Prescription] Let the builder adjudicate reviewer findings. Ask whether each item is a genuine must-fix or overthinking; in his example pattern, the builder may accept four of five issues and reject one as practically impossible [17:15].
• [Prescription] Fix the material subset, not necessarily every finding. If six issues are reported, fixing the three most serious may be the correct decision when time and risk justify it [17:15].
• [Prescription] Avoid sequential review inflation. Repeatedly ordering models to “find bugs” causes them to surface or invent progressively weaker issues even when no serious defect remains [16:13].
• [Prescription] Re-review only when uncertainty warrants it. A second opinion is appropriate when the builder is unsure, and re-reviewing a fix is optional; routine re-review slows delivery [17:15] [18:24].
• [Risk posture] Match rigor to blast radius. Teams with thousands of paying customers should be more careful than an early-stage builder; Ondrej nevertheless argues that most of his audience needs speed more than repeated enterprise-style review [18:24].
• [Prescription] Ship through a known final gate. His endpoint is pull, rebase to main, CI checks, tests, and production deployment [18:24].
• [Prescription] Design for side effects explicitly. A change can be locally correct while breaking another part of the codebase; he uses a dedicated loop to search for those effects after changes land [18:24] [19:26].

3.5 The 100%-agent mindset

• [His argument] Partial adoption leaves the human as the bottleneck. If a person still performs half the work manually, delegating the other half may reduce an eight-hour workload only to about four hours and ten minutes rather than producing an order-of-magnitude change [19:26] [20:27].
• [His argument] The step change comes when agents write and review all code. He says the large gains appear when agents produce every line and review every line, while the human stops being the slowest component [20:27] [21:29].
• [Prescription] Aim for agents that close their own error loop. His target state is for agents to fix errors encountered by users, verify their own work, and operate without a human in that loop [21:29].
• [His practice] He does not optimize primarily for preventing every production break. What matters more in his operating philosophy is that agents detect, fix, and recover from breaks quickly themselves [21:29] [22:22].
• [Prediction] Software factories will separate the leaders. He predicts that people running collections of autonomous loops will pull ahead in late 2026 and 2027 [21:29].

3.6 Subagents: when they help and when they hurt

• [Prescription] Use subagents only for clear, parallel, predictable chunking. The work must be divisible into similar sessions with predictable inputs, process, and outputs [22:22] [23:28] [25:31].
• [Good fit] Analyze thousands of homogeneous artifacts. Examples include categorizing 2,000 files or documents, processing downloaded PDFs, or analyzing thousands of prior agent sessions with the same procedure [23:28].
• [His pattern] Pair a frontier orchestrator with cheap workers. A main agent using Opus 5.5 can launch 10–20 Haiku 5.5 subagents, give each a chunk, and aggregate their results [23:28].
• [Prescription] Do not use subagents for exploratory software work. New features, bug diagnosis, major refactors, and work with surprises, dead ends, coupling, or unknown implementation shape should stay with one powerful frontier agent [23:28] [24:31].
• [Risk] A small model can miss cross-cutting consequences. A superficially small bug may be coupled to another subsystem or touch billing; Ondrej calls delegating that kind of work to a small model a potential disaster [24:31] [25:31].
• [Prescription] Use maximum reasoning where surprises are valuable. For novel work, he wants the smartest model to notice duplicated functions, anti-patterns, optimization opportunities, and unexpected interactions [25:31].
• [Decision rule] If unsure whether subagents fit, do not use them. His default answer is a single powerful top-level agent [25:31].
• [His practice] He avoids opaque “ultra” orchestration modes. He says he never uses Codex-style Ultra Code or Ultra Mode because he cannot see what is happening and believes the token cost is disproportionate to the speed gained [25:31] [26:34].

3.7 Local agents, cloud agents, and sandboxes

• [His assessment] Worktrees are only a partial answer. Worktrees isolate file changes, but each copies the primary checkout, can consume gigabytes as a project grows, and fills local disk rapidly [29:32].
• [His assessment] Local parallel agents compete with the human’s machine. Heavy tests, rendering, analysis, disk work, and computer-use pop-ups can consume CPU, RAM, GPU, and attention on the same machine the person is using [30:17].
• [His practice] Even his high-end laptop is not his scaling plan. He identifies a MacBook Pro M3 Max with 128 GB of RAM and says even that class of machine cannot comfortably run 50 or more agents locally [30:17] [31:14].
• [His assessment] A single VPS also fails as the general architecture. He tried running everything on one VM or VPS and found that roughly five to ten agents could exhaust it [31:14].
• [Prescription] Give every cloud agent an isolated sandbox. His preferred model is analogous to giving each new employee a separate computer: dedicated resources, no interference with other agents, and a security boundary if one sandbox is compromised [31:14] [32:18].
• [Prescription] Run agents cloud-first. Cloud agents continue when the laptop is closed and retain power and connectivity during travel, poor local connectivity, or a local outage [32:18] [38:18].
• [His practice] His cloud share is now a majority and rising. In the live count he reports 553 open threads, with 353 cloud threads—about 64% cloud and 36% local [37:13].
• [His practice] His transition was gradual. Even after he began building Cloudroom, only about 10–20% of his agents were initially cloud-based; in the last three or four weeks before recording, the share passed 50% and then 60% [32:18] [33:13].
• [Prescription] Keep a small local category. Local execution can be better for private tasks or work involving large volumes of files already on the machine, such as organizing a Downloads folder [32:18].
• [Diagnosis] People often reject cloud agents because their cloud environment is incomplete. Missing skills, MCP servers, API keys, GitHub repositories, dependencies, or packages make cloud agents appear unreliable when the actual failure is environment setup [33:13] [34:15].
• [Prescription] Preload the cloud environment deliberately. Cloudroom settings allow him to configure which skills, MCPs, and API keys should be present in every cloud sandbox [34:15].
• [Prescription] Control cloud access to local files explicitly. His Cloudroom access setting has four levels—full, off, read-only, and ask—so a cloud agent can obtain a file it needs from the Mac without the user having attached it manually [34:15] [35:10].
• [Demonstration] A cloud agent answered a local-file question. In his example, a cloud sandbox was asked about files in the Mac’s Downloads folder and reported their count and total size—2.5 GB in the demonstration—despite running on a Linux cloud machine [35:10] [36:11] [37:13].
• [His assessment] Cloud startup latency matters. He criticizes cloud products that require 10–30 seconds for a VM to boot and says Cloudroom is optimized for the agent to begin reasoning in about one second, comparable to local startup [35:10] [36:11].

3.8 Choosing an agent development environment

• [Prescription] The ADE must support every major harness. His list includes Claude Code, Codex, Pi, Hermes, Droid, Devin, OpenCode, and OMP; a single-lab environment prevents cross-model workflows such as GPT Review inside a Claude-centered setup [39:21].
• [Prescription] Do not build the workflow inside a lab-controlled ADE if model choice matters. He argues Claude-centered products will remain limited to Anthropic models and Codex to OpenAI models [39:21] [40:25].
• [Prescription] The ADE must let users spend subscriptions they already bought. He criticizes third-party environments that force their own subscription or harness when the user already pays for Claude Max or ChatGPT Pro [41:20].
• [Prescription] Agents must be able to run other agents. A top-level agent should be able to launch subagents and also launch independent top-level threads, potentially with different harnesses and models [41:20] [43:05].
• [Prescription] Every meaningful ADE operation should be available through a CLI. An agent should programmatically inspect, start, stop, steer, archive, and otherwise control threads rather than requiring the human to click through the interface [43:05] [44:07].
• [His tool] Room CLI is the control surface and a skill. He describes Room CLI as allowing any agent to check threads, start new threads, and archive other threads; in the demo, an Opus 5.5 agent stops and archives Haiku subagents through it [43:05] [44:07].
• [Demonstration] Agents can launch independent cloud threads in another harness. An Opus 5.5 agent in a cloud sandbox launches five top-level cloud threads using the Codex harness and Astra, which are peers rather than subagents [43:05] [44:07].
• [Prescription] Treat manual thread management as avoidable labor. His principle is that starting 20 threads by clicking is the wrong interface; the operator should instruct an agent to do it [44:07].

3.9 Agent loops and the software-factory model

• [Definition] A software factory is an accumulation of loops. He does not recommend designing the factory as the first artifact; start with small, predictable loops for boring repetitive work, and 10–30 running loops eventually constitute the factory [45:08] [46:01].
• [His practice] Loops caused his most recent productivity jump. He attributes the movement from roughly 400–500 weekly contributions to about 700 and nearly 1,000 in the recording week primarily to loops introduced over the previous two or three weeks [46:01].
• [Prescription] Do not blindly copy another person’s skills or loops. Copy only two, three, or four items that map to your own work; another creator’s daily tasks and habits are not identical to yours [46:52] [47:44].
• [Selection metaphor] Automate “chopping wood,” not “building the cathedral.” Wood-chopping work is boring, repetitive, and obvious; cathedral work requires creativity, planning, abstract thought, and taste [47:44] [48:46] [49:37].
• [Good autonomous-loop fit] Clear reproducible bugs. If a bug is readily reproducible and a frontier model can identify and fix it, Ondrej sees no reason to keep a human in that path [49:37] [50:34].
• [His practice] He reports 33 loops and about 2,000 runs per day. He says 86% run on their own [50:34].
• [Loop pattern] Use cross-model agreement as an autonomy gate. In his bug loop, Opus investigates and fixes; GPT-6.1 Sol then performs an adversarial review and independently checks whether the issue is real, reproducible, user-affecting, and safely fixable. If both frontier models agree, the fix can ship without him [50:34].
• [Loop pattern] Keep conditional human gates where taste matters. For a feature suggested by many paying customers—his example is 70%—a loop can build it and present three variations, with Ondrej selecting the one to proceed [51:37].
• [Prescription] Alternate frontier models across loops and reviews. Different models notice different errors, analogously to asking several smart friends rather than only the single smartest friend [51:37] [52:37].
• [His model pool for diversity] He names Opus, Sol, Astra, Muse, Gemini Argon, and Kimi K3.9 Pro as models that may each find a different issue. The point is diversity of failure detection, not merely using the top-ranked model repeatedly [52:37].
• [Loop example] Security sweeps are prime loop material. He questions whether any human developer manually checks the entire codebase for security every few hours; his system runs recurring deep security checks, described as every three to four hours in different parts of the video [52:37] [66:20].
• [Loop examples] Business operations can be loops too. He names a daily funnel report, Tweet Scout for product mentions, customer outreach reminders showing whom he has not contacted, and near-real-time bug reports [66:20].
• [Prescription] Expect the first loop to be the hardest. Moving from zero to one or two loops has high activation friction; after dozens exist, adding another is comparatively easy [53:26].
• [Prescription] Analyze your own sessions before choosing loops. Prior agent sessions contain prompting habits, repeated skill sequences, workflows, and problem-solving patterns that reveal personalized automation candidates [54:25].
• [His scan design] A frontier orchestrator chunks sessions to cheap subagents. Cloudroom’s scan launches Opus 5.5 as the main agent and 20–30 Haiku subagents over thousands of sessions because session classification is exactly the predictable chunking task for which he endorses subagents [54:25] [55:17] [57:24].
• [His scan output] The scan proposes the first two loops. It is instructed to identify two specific repeated habits or workflows rather than offer a generic list copied from an influencer [55:17] [56:20].
• [Prescription] Apply the 10–90 split to reduce rollout risk. The loop fully automates the safest, least risky, most obvious 10%; for the other 90%, it analyzes and researches, presents its proposed action, and waits for the human [56:20] [58:26] [61:10].
• [His examples] A scan found a daily Release Check. The loop checks at 9:00 a.m. Pacific for a new release or version, reflecting a task Ondrej had been doing once or twice a day [60:16] [61:10].
• [His examples] A scan found a daily Old Thread Sweep. The loop runs at 7:00 p.m. Pacific, reviews old threads, and identifies which should be archived [60:16] [61:10].
• [His examples] A later scan found Morning Focus. It noticed a recent habit of unpinning too many pinned Cloudroom threads and proposed turning that cleanup into a loop [62:12].
• [His practice] His existing loops already cover much of his repeat work. He lists feedback, triage, side effects, reviews, PR reviews, and public issues among the repeat processes already running as loops [59:28] [60:16].
• [Prescription] Judge agent output by shipped product changes, not activity counts. He points to his public changelog, with changes released about twice a day, and says people flexing PR counts, commits, subagent counts, or markdown-file counts should be asked to show a public changelog [58:26] [59:28].

3.10 Loop philosophy beyond software engineering

• [Prescription] Loops are not limited to coding. Ondrej applies the same pattern to marketing, sales, outreach, research, GTM, and other knowledge work with repeatable components [63:14] [67:20].
• [Historical analogy] Revolutions move people from doing tasks to operating machines. He compares agent loops to power looms in the 1830s, Ford’s 1913 assembly line, and the replacement of human computers after 1946: the human role shifts toward building and running the system [64:15] [65:20].
• [Prescription] Automate the preparatory majority even when a decision remains human. In a feature workflow, AI can design, implement, cross-review, and produce three UI options for perhaps the first 80%; the human then answers one or two questions and approves or rejects [66:20].
• [Prescription] Do not begin with a monolithic factory. He cites Dex’s attempt to build a software factory for four months as producing unread output, slop, and angry users; the corrective path is first one loop, then another [67:20].

3.11 Self-improving software and the feedback loop

• [Goal] Minimize time from user problem to developer workspace. A bug, error, feature suggestion, or idea should reach Ondrej with as little friction and delay as possible [68:18] [69:04].
• [His practice] Users can report through an interface button or through their own agent. The agent can use Room CLI’s feedback capability, so a user can say in plain English that Cloudroom felt slow or an attachment failed and ask the agent to tell David and the developers [69:04] [70:04].
• [His practice] Every report becomes work in his own environment at his own inference cost. Reports enter a Postgres table, a loop checks every minute, and a new report opens a cloud thread in Ondrej’s Cloudroom [70:04] [71:07] [72:57].
• [Prescription] Investigate before editing. The investigation thread starts read-only and decides whether the report identifies a real bug, a real product improvement, or a valuable idea [72:57].
• [Prescription] Self-archive false alarms. Noise, duplicates, already-handled reports, and bugs already fixed in an upcoming version should archive themselves rather than consume developer attention or bloat the workspace [72:57] [73:55].
• [Prescription] Preserve a human approval gate for real product changes. A validated item becomes a GitHub issue and a short summary; Ondrej or a developer approves it before implementation, or it is archived [72:57] [73:55].
• [Loop closure] Approved feedback is fixed, cross-reviewed, and shipped. The fix is reviewed by a different frontier model before release, so each accepted report improves the product for every user [73:55] [74:57].
• [Reputation mechanism] Reporter history changes scrutiny. Ondrej describes assigning reputation based on report quality: spammers and bad-faith contributors receive stricter scrutiny, while users who consistently report genuine bugs are easier to recognize as acting in good faith [71:55] [72:57].
• [Product status] The feedback system is not yet a packaged feature. Ondrej says he may turn the self-improving mechanism into a feature if enough users want it; the loop and scan features are already presented as one-click capabilities, but this feedback architecture is primarily his internal implementation [68:18] [74:57].

3.12 Local and self-hosted inference

• [His practice] He is expanding local compute rather than abandoning it. He reports two DGX Sparks in use and two more purchased, for four total and 512 GB of aggregate RAM; he also lists 128 GB in his MacBook Pro, 20 GB across two iPhones, and 24 GB in a MacBook Air, while noting that he does not chain all of these together [76:02].
• [His argument] Owning inference is downside protection. If a ChatGPT or Anthropic subscription were removed, a person without local compute could lose practical access to AI; he compares owning hardware to solar panels or a garden as a form of independence [76:53].
• [His argument] The same hardware becomes more useful as open models improve. He says models available for his two Sparks had improved materially over six months and that he can now run DeepSeek V4.1 Flash 1017 locally [78:01].
• [Prescription] Use local inference for maximum privacy. Legal contracts, health information, employee data, and sensitive PDFs should be processed by a powerful local model rather than sent to Anthropic, OpenAI, Google, xAI, or another cloud provider [78:57] [80:00].
• [His practice] Sensitive PDFs go to a locally hosted DeepSeek model. That routing keeps the data off external cloud services [80:00].
• [Prescription] Use unrestricted local models where refusal or bias would defeat the task. He names political or controversial questions as a use case for an abliterated or unrestricted model and identifies Venice as a cloud API alternative [80:00].
• [His argument] Open-weight local models matter during security incidents. He says frontier hosted models may refuse defensive work during attacks, leaving GLM or DeepSeek open-weight models as practical alternatives [81:02].
• [Prescription] Do not use local models for the hardest frontier work by default. Difficult coding and highly important tasks should use the strongest available hosted frontier model; local inference is for privacy, sensitivity, independence, or refusal-sensitive work [81:02].
• [His assessment] Weak local hardware creates a discouraging capability gap. If the only computer is an ordinary laptop, the difference between local output and frontier hosted models may be large enough that local inference will not be used [81:02] [82:10].
• [His practice] He is considering a 512 GB Mac Studio. He identifies the M5 Ultra configuration as a possible purchase, while noting its expected $22,000–$23,000 starting price and claiming much higher memory bandwidth than four Sparks [82:10] [83:14].
• [Prescription] Avoid absolutism in either direction. Use local inference when it makes sense and frontier hosted models when capability matters most [84:04].

4. Tips and tricks

• [Tip] Document your tacit workflow by mining your own sessions. Ondrej says he could not have described his process in the same detail unaided, so he asked Opus to analyze his Cloudroom sessions and derive the workflow from actual behavior [07:32] [08:35].
• [Tip] Put every recurring typed prompt into Raycast Snippets. Use macOS Text Replacement if Raycast is unavailable; reserve skills for recurring workflows too complex for a snippet [11:10].
• [Tip] Ask for three visual options when exploring a UI direction. In his example, he asks what a traditional Windows 7-style redesign would look like and requests three potential image renders [10:22].
• [Tip] Use an “is this real or overthinking?” adjudication prompt. Send another model’s findings back to the builder and ask which are genuine must-fix issues and which are implausible overthinking [17:15].
• [Tip] Score review findings before fixing them. Use a 1–10 rating plus frequency and severity; do not treat every reviewer statement as equally actionable [16:13] [17:15].
• [Tip] Cap review rounds deliberately. One cross-model review is the normal pattern, another opinion is for uncertainty, and repeated review chains should be treated as a source of manufactured findings [16:13] [18:24].
• [Tip] Add tests only after seeing the same error class recur. One or two strategic tests aimed at a demonstrated failure pattern are preferable to asking agents to generate tests indiscriminately [13:12].
• [Tip] Ask for a public changelog when evaluating productivity claims. Ondrej’s test for people boasting about PRs, commits, subagents, or markdown files is whether they can show what actually shipped and whether each version improved [58:26] [59:28].
• [Tip] Use subagents for session mining. Thousands of prior sessions should be classified in parallel by cheap Haiku subagents under a frontier orchestrator, rather than read serially by the expensive model [54:25] [55:17].
• [Tip] Start automation with the first two scan results only. Do not attempt to automate every repeated workflow at once; activate two personalized loops and use the 10–90 split [55:17] [58:26].
• [Tip] Alternate models to diversify error detection. Rotate Opus, Sol, Astra, and other frontier models in loops because different models spot different mistakes [51:37] [52:37].
• [Tip] Preconfigure cloud sandboxes. Decide in advance which skills, MCP servers, and API keys each sandbox receives so cloud agents do not fail on missing context [34:15].
• [Tip] Set local-file access as a policy, not an afterthought. Use full, off, read-only, or ask access according to the task instead of manually attaching every file a cloud agent might need [34:15].
• [Tip] Let obsolete investigation threads archive themselves. A self-archive skill prevents false alarms, duplicates, and completed investigations from accumulating in the sidebar [73:55].
• [Tip] Let users instruct their agents in plain English to file product feedback. The user should not need to know Room CLI commands; the agent translates “report this to David” into the structured feedback action [69:04] [70:04].
• [Tip] Route sensitive documents by data type. Legal contracts, health material, employee data, and sensitive PDFs go to local DeepSeek; difficult coding goes to the strongest frontier model [80:00] [81:02].
• [Tip] Spend 30 minutes learning an unfamiliar systems concept. Trade-offs, caching, observability, blast radius, coupling, and cohesion are presented as high-leverage vocabulary for directing agents [05:53].

5. Lessons learned and mistakes he names

5.1 Lessons encoded in his current system

• [Lesson] Skills often originate from an expensive failure. Ondrej says his skills usually exist because of a costly lesson; Risky Changes is his concrete example [12:10].
• [Named failure] A filter passed every test and still disabled 99% of a feature on live data. That incident is why risky changes receive a dedicated safety check instead of relying only on test passage [12:10].
• [Lesson] Agent-written tests can create false confidence and bloat. He concludes that more than 90% of tests agents write are “slop” in his experience: they slow the product down, do not test meaningful behavior, and exist mainly to pass [13:12].
• [Lesson] Reviewers manufacture work when repeatedly asked to find defects. Running GPT Review or equivalent reviews several times in succession leads models to hallucinate or inflate issues because finding problems is the assigned task [16:13].
• [Lesson] Optional re-review is usually unnecessary. Re-reviewing every fix slows delivery; he reserves it for uncertainty and larger customer blast radius [17:15] [18:24].
• [Lesson] Correct code can still have unexpected side effects. Change-local review is insufficient, so he added loops that look for effects in other parts of the codebase [18:24] [19:26].
• [Lesson] Keeping any substantial coding work manual keeps the human as the bottleneck. His 50%-adoption example is intended to show why partial agent use produces only partial gains [19:26] [20:27].
• [Lesson] Agent systems need their own memory of repeated prompts. Ondrej had forgotten that Risky Changes existed, but agents continued applying it automatically; encoding the lesson as a skill made it operationally persistent [12:10].
• [Lesson] Tacit expertise may be easier to extract from logs than from introspection. He says he could not personally have produced the detailed workflow description without having Opus analyze thousands of his sessions [07:32] [08:35].

5.2 Mistakes and dead ends in delegation

• [Mistake pattern] Giving a small model a seemingly small software task can be dangerous. The task may secretly involve coupling, billing, duplicated logic, or another high-consequence subsystem [24:31] [25:31].
• [Mistake pattern] Treating subagent count as productivity is a status game. Ondrej criticizes people who boast about subagent orchestration when a single frontier agent would handle the real exploratory work better [22:22] [23:28].
• [Mistake pattern] Opaque multi-agent modes waste scarce subscription capacity. He argues that Ultra-style delegation can consume limits several times faster for a much smaller speed improvement [25:31] [26:34].
• [Mistake pattern] Copying a respected creator’s complete skill stack is a category error. Matt Pocock’s skills fit Pocock’s work; Ondrej says his own skills should also be adopted selectively rather than copied one-for-one [47:44].
• [Mistake pattern] Designing a complete software factory first can fail. He points to Dex’s four-month factory effort as producing unread slop and angry users, then contrasts it with starting from individual loops [67:20].

5.3 What changed over the 15,700 sessions

• [Change] His productivity accelerated after he resumed building and then embraced cloud agents. He says serious building resumed in late March and April, while September and October cloud-agent adoption caused a marked increase in daily production contributions [06:42].
• [Change] Review became cross-lab and risk-tiered. His current default is not self-review by the builder alone: normal changes receive one rival-frontier review, while only huge changes receive Total Review [14:14] [15:11].
• [Change] Test generation became deliberately constrained. Instead of treating more tests as inherently safer, he now instructs agents to avoid tests unless necessary and to add strategic tests only for recurring error classes [12:10] [13:12].
• [Change] He moved from worktrees toward isolated cloud sandboxes. Worktrees were useful for a couple of weeks but created disk pressure and still shared the local machine; a single VM also saturated, leading to one sandbox per agent [29:32] [31:14].
• [Change] His cloud adoption lagged his own product because environment parity came first. His cloud share began around 10–20%, then passed 50% and 60% only after cloud agents could receive the necessary skills, tools, keys, repositories, and local-file access [32:18] [33:13] [34:15].
• [Change] Agent loops became the newest productivity layer. He attributes his latest increase—from roughly 400–500 contributions per week to about 700 and nearly 1,000—to loops adopted in the preceding two or three weeks [46:01].
• [Change] His automation discovery process became data-driven. Rather than inventing loops from intuition or copying influencers, he now scans thousands of his own sessions to identify the first two candidates and their safest 10% [54:25] [55:17] [58:26].
• [Change] Feedback handling became a closed product loop. Reports that once would have required manual intake now create investigation threads, self-archive when invalid, wait for approval when real, and return as reviewed production fixes [68:18] [72:57] [73:55].
• [Change] Local inference remained, but as a specialized layer. He did not replace frontier hosted models; he expanded local hardware for privacy, independence, and refusal-sensitive work while keeping frontier models for difficult tasks [76:02] [81:02] [84:04].

6. Tools and stack named

Model stack he names

7. Notable claims — Ondrej’s claims, unverified by us

• [Claim] Opus 5.5 is the best model in the world and one of Anthropic’s best releases in two years. He also says it is very fast [00:00] [01:00].
• [Claim] Astra and Opus occupy the true frontier, while OpenAI badly needs a better model. He ranks OpenAI behind Anthropic at the time of recording [01:00] [01:48].
• [Claim] The harness will matter less and less. He attributes the supporting view to two Anthropic engineers and says terminal plus internet access increasingly makes the surrounding harness secondary [01:48].
• [Claim] Claude Max $200 is by far the best-value subscription. He says the choice is “not even close” if only one subscription can be bought [02:53].
• [Claim] Cloudroom is the only ADE or AI coding app that provides cloud agents on a free plan for any model and harness. He repeatedly describes Cloudroom as the only tool in the world with that combination [03:56] [85:09].
• [Claim] He ships 100–200 production contributions per day and about 700 commits per week. He points to his GitHub activity and a model-generated visualization as support [06:42] [07:32].
• [Claim] Cross-lab frontier review minimizes serious bugs, breaking changes, and slop by about 90%. This is his estimate for reviewing big and risky changes with the rival lab’s frontier model [15:11].
• [Claim] More than 90% of agent-written tests are slop. He says they bloat applications, slow development, and do not test anything meaningful [13:12].
• [Claim] A dedicated side-effect loop catches 95% of unexpected cross-codebase effects. He presents this as the reason fast shipment remains workable despite change-local blind spots [19:26].
• [Claim] Moving from 50% to 100% agent-written and agent-reviewed code can yield 10×, 20×, 50×, or 100× speed. He treats full delegation as qualitatively different from partial AI assistance [20:27] [21:29].
• [Claim] Subagent orchestration modes can cost five times more for only 1.5×–2× faster completion. He uses this comparison to argue that Ultra-style modes waste subscription limits [26:34].
• [Claim] Cursor’s industry trend shows cloud-agent pull requests rising from about 10% early in the year to 50% midyear and 60–70% later. He uses the chart to support his cloud-first argument [26:34].
• [Claim] His eventual steady state will be 90–95% cloud agents and 5–10% local. He predicts a similar distribution for most users [32:18] [33:13].
• [Claim] Cloudroom surpassed 50% and then 60% cloud-thread share in the weeks before recording. His live count is 353 cloud threads among 553 open threads, or about 64% [33:13] [37:13].
• [Claim] Cloudroom supports direct cloud-to-Mac access that no other product has. His demonstration is a cloud sandbox answering questions about files stored in the Mac’s Downloads folder [35:10] [36:11].
• [Claim] Cloudroom’s cloud agents begin reasoning in about one second. He contrasts that with competing cloud VMs that he says take 10–30 seconds to boot [35:10].
• [Claim] Cloudroom had more than 230 forks roughly two weeks after launch. He uses fork count and growth as evidence for the ADE’s traction [40:25].
• [Claim] He runs 33 loops producing about 2,000 runs per day, 86% of them autonomously. These figures describe his Cloudroom loop system at recording time [50:34].
• [Claim] A workflow scan costs less than 1% of a weekly model limit. He attributes the low cost to chunking the work across Haiku subagents under an Opus orchestrator [54:25].
• [Claim] A scan of his sessions analyzed about 3,000 local sessions, with more in the cloud. He says one scan used 31 Haiku subagents in one description of the process [55:17] [57:24].
• [Claim] Cloudroom releases visible changes about twice a day and each version is better than the last. He offers the public changelog as the evidence standard for his productivity claims [58:26] [59:28].
• [Claim] Serious user-reported issues are usually fixed within 24 hours and at most 48 hours. He attributes that turnaround to the self-improving feedback loop [74:57].
• [Claim] User feedback is analyzed within 10–30 minutes. He describes Opus checking reports for legitimacy and spam soon after submission [68:18].
• [Claim] Frontier models are very hard to fool through fake or bad-faith product reports. He uses that belief to support reputation-sensitive automated report triage [72:57].
• [Claim] Local hardware grows in useful output value rather than simply depreciating. He says even A100-class GPUs have continued increasing in token-output value years after release and that his newer DGX Sparks cost about 30% more than units bought a few months earlier [78:57] [83:14].
• [Claim] A not-yet-purchased Mac Studio M5 Ultra with 512 GB RAM would provide five to six times the memory bandwidth of four DGX Sparks. He gives an expected starting price of $22,000–$23,000 [82:10] [83:14].
• [Prediction] Other people’s local-versus-cloud balance will converge toward his. He predicts most agent work will move into isolated cloud sandboxes, leaving local execution for private or file-local tasks [32:18] [33:13].
• [Prediction] Agent-loop operators will pull ahead in late 2026 and 2027. He says the advantage will belong to people running software factories made of many autonomous loops [21:29].

Video ID: FbKXvab-0yQ | Duration ~60:22 | Transcript: Whisper large-v3-turbo, timestamped

1. Overview

This is not a neutral review. It is a founder launch video: David Ondrej introduces Cloudroom, his own product/startup, built over the previous five to six weeks (crystallising two to three months of related open-source work), and walks through it live on screen for about an hour. The entire video is promotional for Cloudroom — title, framing (“destroyed all AI coding apps”, “breakthrough”, “best tool in the world”), demos, pricing tiers, hiring pitch, and repeated calls to go to cloudroom.dev all serve the launch. There is no separate third-party sponsor segment to exclude; the product pitch is the video. Read all feature, performance, and “only/first/best” claims accordingly and see the Claims Ledger in section 7. That said, the underlying thesis is substantive and reusable independent of the product: the bottleneck to running agents productively at scale is not models or harnesses, it is infrastructure — isolation, persistence, speed, sync, and management — and the fix he prescribes is one isolated cloud computer per agent thread, harness- and model-agnostic, controllable in plain English / by agents themselves, with local work treated as the minority case.

2. What Cloudroom is, as described

• Definition: A platform / app for running cloud agents where you can run any harness, any model, with your existing subscriptions — no extra token markup from Cloudroom itself [00:00].
• Core unit is a thread, each thread gets its own isolated sandbox: an isolated Linux VM / its own computer in the cloud, with persistent state and a persistent, fast internet connection, completely isolated from other agents [00:00][03:57][12:46].
• Fully open source, free tier, self-hostable: Presented as fully open source on GitHub, usable for free on a free plan released “today”, also forkable and self-hostable; you can have your own agent inspect the code [00:00][40:05]. Both the core and the GUI are separate open-source repos, stated as Apache 2.0 [40:05][41:41][43:02].
• Local + cloud in one app: For each thread you choose Local, Local Worktree, or Cloud at launch; the sidebar/icon shows which threads are local vs cloud [00:46][08:46]. Local use is described as unlimited and like any other local app [03:11].
• Harnesses supported, as named: Claude Code (transcript: “Cloud Code”), Codex, Cursor, Pi Agent (“PyAgent”), Hermes, OpenCode, “FX”, Grok Build, “OMP”, and any other harness; ACP is also supported [01:36][03:57]. Five different agents with five different harnesses/models are launched in the opening demo [00:46].
• Models / subscriptions: You bring existing Claude, Codex, Grok, OpenCode Go etc. subscriptions and logins; the same CLI logins are meant to work locally and in the cloud via sync [11:57][12:46][13:36]. Provider usage across multiple plans is visible in-app and you can switch plans in-app, e.g. switching from a hit-limit $100 Claude plan to a $200 main plan [15:33].
• Agent-first control plane — Room CLI: Everything is controllable in plain English and, more importantly, by agents via the Room CLI, Cloudroom’s command-line interface for agents. Agents can spawn more agents, schedule automations, archive/rename/move threads, move threads local↔cloud, control other threads, and reach the user’s Mac [03:11][22:45][23:38][38:02].
• Teleport: A feature to move a live thread — same context, same repo, same dependencies, same model/harness — from your Mac to a cloud sandbox and back, in seconds, via right-click [08:46][09:36][10:23].
• Automations / agent loops: Scheduled or triggered agent loops (“mini software factories”) that launch cloud threads on a cadence, e.g. every 30 minutes, every other day at 8am, using a chosen harness/model/effort. He says he runs ~40 automations total, usually 15–20 active [21:08][25:11][25:59][57:10].
• Cloud Mac access: Cloud agents can be given controlled access to your local Mac — off / read-only / ask-before-changes / full access — via what the transcript calls a “Cloud Mac skill”, so an agent that is missing a file, repo, dependency, or .env key can retrieve/use it instead of failing [23:38][24:25][47:04][51:27].
• Purpose feature: Hover over a thread name to see the thread’s purpose and what percentage is done — built, he says, two days before recording, for managing very large thread counts [17:59].
• Thread scale he personally runs: He asks an agent via Room CLI on camera and reports 201 open agent threads in his Cloudroom project at that moment; later references 300+ open threads after launching 100 more sub-agents, with no lag/crash in his demo [17:14][42:09].
• Technical stack, as stated: Rust-first core (~78% Rust claimed), memory-safe, modular split between GUI, web app, and core as separate apps/codebases; GUI described as lightweight and able to handle hundreds of threads [41:41][42:09].
• Built on / forked from “BB”: Cloudroom is built on top of, then forked from, a prior open-source GUI tool he calls “BB” (name as transcribed; founder given a “huge shout out”). If you already use BB it will feel familiar; Cloudroom adds cloud threads/free cloud compute on top plus optimisations, fast keyboard shortcuts, better UI/polish, and e.g. translating Claude Code context commands [34:28][43:02][44:03].
• Platforms: Full support claimed for macOS and Linux only; Windows is explicitly deprioritised [13:36][45:03].
• Sandbox networking: Sandboxes claimed to have 10 or 15 gigabit-per-second internet and ~99.99% uptime / always available [19:33].
• Pricing / access model, as described: Free plan forever, rolled out in waves for cloud threads (local threads immediate; cloud access may queue a day or two depending on demand); Pro and Ultra paid plans give instant cloud access; Ultra adds a dedicated Slack channel with direct access to Ondrej and his team, bugs/features fixed “within a couple of hours”, and personalised onboarding (Pro and Ultra) with him or his founding engineer [16:24][31:00][40:05][58:43][59:31].
• Feedback loop productised: Any user can tell their agent “send this to David / report a bug” and the agent uses a Room CLI feedback tool that writes to his Postgres database; he has (normally) a cloud automation running every 10 minutes that opens a new thread to investigate each report [57:10].
• Business status he states: Bootstrapped, lean team, between San Francisco and Poland, hiring engineers and content roles via an email in the description, possibly raising a first round in December or January mainly to subsidise free-plan cloud compute and hire; business model explicitly compared to Supabase — powerful free tier subsidised by paid plans [52:16][53:08][54:00].

3. The workflow he demonstrates or prescribes, as ordered steps

A. Basic thread workflow (normal usage)

1. Open a project — a repo or a local folder [08:00].
2. Choose where the thread runs: Local, Local Worktree, or Cloud [00:46][08:00].
3. Choose harness and model with keyboard shortcuts; set reasoning effort (low / high / extra-high / max) and, where the harness supports it, “fast” mode [08:00].
4. Prompt in plain English / speech, exactly as you would in the Codex app, Cursor app, or Claude desktop [08:46].
5. Read the sidebar to see which threads are local (laptop icon) vs cloud [08:46].
6. Archive threads and their sub-agents when done — archiving a parent archives its sub-agents [07:15][08:00].

B. Fan-out / multi-agent demo workflow

1. From one prompt, launch five different agents, each with a different harness and model, all as cloud threads, and ask each “what machine are you on?” to prove they are not on his Mac [00:46][01:36].
2. From another thread, instruct a lead agent (Opus 5.5 High in the demo) to launch 25 sub-agents underneath it, each using Haiku 5.5, each looking for different small bugs in different parts of the codebase, explicitly told not to make any changes yet [00:46].
3. Reload / inspect the fleet view: he shows 38 agents running, each in its own sandbox, with models visible (Sol, Opus 5.5, Haiku 5.5); privacy mode hides thread names on camera [02:25].
4. Clean up in plain English: “stop all of these agents and archive their threads” — agents can modify, update, archive, rename, and move threads themselves [03:11].

C. Teleport workflow (local → cloud continuity)

1. Start a thread locally; ask “what machine are we on right now?” — agent answers MacBook Pro [09:36].
2. Right-click → Teleport to Cloud; watch the teleport animation [09:36].
3. The same thread, with same context, repo, and dependencies, continues in a new isolated cloud sandbox [09:36][10:23].
4. Verify by asking again what machine it is on — now the Cloudroom sandbox, not the Mac [10:23].
5. Intended use case: you have worked 60–90 minutes locally and must suddenly leave (airport, cafe); work keeps running in the cloud instead of stopping when the laptop closes / dies [09:36][10:23].

D. Building an automation / mini software factory in plain English

1. Open Automations — framed as “agentic engineering” / an agent loop / mini software factory, not mere scheduling [21:08].
2. Describe the loop in plain English, ~20 seconds of speech in his demo: create a cloud automation, run every 30 minutes, use GPT-6.1 Sol Max fast, do a security review of the project’s underlying dependencies, one different dependency per run, checking for breaches or public exploits, on this repo, and make it active [25:11].
3. The system creates and starts it — he times it at 1 minute 17 seconds from prompt to created-and-started; the resulting automation is named “Dependency Watch”, shows harness/model/reasoning effort, and its script lists all 220 dependencies and begins checking the first one (Axiom in the demo) [26:49].
4. Upgrade the loop in plain English: whenever a run finds something, spawn a sub-agent with a different model (Opus 5.5 Extra High via the Claude Code harness) to review whether it is a real issue or overthinking; if overthinking, archive both threads [25:59].
5. Optionally encode an auto-fix rule: if the issue has an obvious, clear fix (e.g. a breached dependency with a patched version available), instruct the main agent to fix it, update, and push to production immediately; if it needs human judgment, instruct it to wait for you [28:21].
6. Repeat and compose: one or two loops are “agent automations”; at 10, 20, 30 loops it becomes, in his framing, a software factory — security researchers, frontend engineers, billing testing, product-gap, performance/testing teams as loop roles [25:11][27:34].
7. Existing loop examples he shows/names: a Discord slowness monitor investigating why his Discord lags [21:08]; an arXiv scraper running every other day at 8am via a “Deep API” that launches a cloud thread, reviews the last 48 hours of papers, and surfaces only what is relevant/educational for him [21:57][22:45].

E. Cloud agent reaching back to the Mac (demonstrated live)

1. In a cloud thread, ask the agent to look at the MacBook and count/list Downloads folder items, with a privacy instruction not to leak private names while recording [47:04][48:05].
2. Ask, still from a cloud thread, how many projects are in ~/code on the MacBook — agent answers 85 folders, roughly 40 different projects, and reports total size / identifies ~40 Cloudroom site copies [48:05][49:06].
3. Escalate to action: instruct the cloud agent to go into ~/code/Cloudroom on the MacBook, find the branding folder, find the main logo PNG, and open it in Preview on the MacBook [49:06].
4. Steer / pre-send while it works, hands off keyboard/mouse; the agent uses the Cloud Mac skill, finds the repo/file, and opens the logo in Preview on his Mac live on camera [49:54][51:27].
5. Confirm separation afterwards: ask what machine the agent itself is running on — it answers it is on a Cloudroom VM, not the MacBook, accessing the MacBook remotely [52:16].

F. Local fan-out stress demo (for comparison)

1. Ask for 100 sub-agents all on local, half Codex (GPT-6 Luna) and half Claude Code (Haiku 5.5), each researching a different competitor, told to only say the competitor name and make no changes, and told not to overthink it [34:28].
2. Observe local cost: the batches launch, but now the Mac’s CPU/GPU is used and fans/lag are expected because it is local hardware [35:31][36:31].
3. Stop them in plain English (“pause all of them right now”), then archive them; also demonstrate message queuing and pre-sending (Cmd+Enter) while a queue is loaded [38:02][39:03].

G. Prescribed migration workflow (local → cloud adoption)

1. Do not move everything at once — you will hit friction and be annoyed [32:38].
2. Move one project at a time: 10%, then 20%, one repo, two repos, three repos, more each week [32:38].
3. Re-test the assumption that a given task “needs local” — he argues most such beliefs trace to limits of one prior cloud implementation (Cursor, AMP, Devin), not to cloud agents in principle [32:38][33:36].
4. Keep local only for genuinely local cases (see section 6) and expect a ~90/10 cloud/local split within ~6 months [31:48][32:38].

H. User feedback workflow (for Cloudroom users / as a pattern)

1. In any project, tell your agent in plain English to report a bug / feature idea / slowness observation “to David, the founder of Cloudroom” [57:10].
2. The agent uses the Room CLI feedback tool; the report lands in his Postgres database as a table row [57:56].
3. His own (normally active, paused for recording) automation polls every 10 minutes and starts a new thread investigating the report [57:56].

4. Points and claims grouped by topic

Why isolated sandboxes per agent

• Infinite scalability is, in his argument, only possible if each agent gets its own computer; fixed home hardware (Mac Mini, spare laptop, single VPS) caps you, and agent counts are rising year over year and will keep rising [05:34].
• Buying fixed hardware fails the “+20% more agents than the hardware handles” case [05:34].
• Security isolation: if one VM’s agent is prompt-injected or downloads a malicious package, only that agent/sandbox is compromised, not your main computer [05:34][06:27].
• No interference: agents in shared machines step on each other — one agent dirtying the primary checkout breaks others even with worktrees; one agent’s database tests can hog all machine resources [06:27].
• Worktrees are presented as an insufficient workaround once you run 5, 10, 15+ agents [06:27].
• Running agents on shared local hardware is “betting against the progress of AI”, the one trend he says not to bet against, as improvement speed accelerates [06:27][07:15].
• Scale claim in practice: you can literally launch 100 sandboxes with one prompt inside Cloudroom; he demoed 25 [07:15].

Why cloud, why always-on

• Agents must keep working when your laptop runs out of battery, closes, disconnects, overheats, or is on bad cafe Wi-Fi — all presented as daily, normal events for him [00:00][20:20][55:39].
• As agents do more in life/business and run inside software factories and loops, they need a persistent environment with stable, fast internet and near-always availability [19:33][20:20].
• Nobody hosts a website on a laptop, for many of the same reasons; local agents were convenient because Claude Code / Codex CLI / Hermes etc. pioneered the terminal and were easy to install, not because local is architecturally right [30:10][31:00].
• Computer use strengthens the case: computer-use agents are productive but annoying on your own screen (pop-ups, app switching, focus stealing, new tabs); giving each agent its own computer/sandbox solves that — citing progress from Codex app, and open-source Cua Driver (“Kua Driver”) and Browser Harness [29:19][30:10].

The shifting usage pattern / management problem

• A year / six months ago usage was one-at-a-time: “analyse this repo and build a feature”, a human unblocking one agent at a time — not scalable [17:14].
• He personally cannot unblock one at a time anymore: he cites 201 open threads, invokes Dunbar’s number (~150) as an analogy, and says beyond 50–100 threads you lose track of what each thread was [17:14][17:59].
• Future start mechanisms: most agents will not be started by humans typing, but by themselves, triggers, events, rules, instructions, software factories, agentic loops, webhooks, routines, database outages, product improvements, new customers, and other hooks [14:30][18:48][25:59].
• Future management mirrors human organisations: like a 5,000-developer company is not directed person-by-person by the CEO, agents will be multi-layer managed — some self-starting, some started by customer feedback/state, some reviewed automatically by another agent, some launched by manager/director agents, some self-archiving after checking database/system health [18:48][19:33].
• Humans move up a level: to managing and orchestrating agents and creating the logic/rules for why they run, not starting each one individually [26:49][58:43].
• He frames this as “agentic engineering 2.0” / the next generation of building software [58:43].

Why the hard problems are hard (engineering friction list)

• He lists the things that all must work or users will not migrate: no data loss across hundreds of spinning up/down persistent sandboxes; launch speed (a 20-second thread launch kills adoption; Cloudroom aimed for near-local, “within half a second of launching a local thread” as the feel target); sync of repos and API keys between laptop and cloud; and synced logins so CLI subscriptions work in both places [12:46][13:36].
• Cloud agents have existed about a year and most people have not migrated because of friction; one suboptimal piece is enough to block migration [13:36].
• His remedy was dogfooding/polish: five to six weeks, working closely with ~25 beta testers (elsewhere ~20), six to ten hours every day polishing so cloud is “as good as local” — and, because of isolation, better [13:36][14:30][56:24].
• Managing infrastructure for many users cheaply is complex, which is why, he argues, incumbents did not do this or open-source it, especially not with a free plan [31:00].

Harness/model agnosticism as the product wedge

• Incumbent cloud offerings are single-harness: Cursor Cloud / Codex Cloud etc. only let you use their own harness, their own models, their own GUI, and force their subscription [03:57][11:09][11:57].
• Worked example he gives: Cursor was historically model-agnostic, but after what he describes as SpaceX acquiring Cursor, GPT models cannot be used in Cursor, so when Astra was “the best model for a solid three weeks” it was unusable there [11:09][37:17].
• Codex app is more performant / crashes less than Cursor GUI in his experience, but is GPT-only, so Anthropic’s currently-best 5.5-series (and imminent Fable 5.5) cannot be used in it [37:17][38:02].
• Claude desktop cannot, in his account, do agent-controlled thread management — agents cannot control different agent threads inside Claude desktop — which he says drove early beta testers to Cloudroom [38:02].
• “If you’re paying for the tokens, you should be able to use them”: any model, any harness, any inference provider is stated as Cloudroom’s entire vision [11:57].

Local vs cloud split

• Prediction: ~90% cloud / 10% local in ~6 months, possibly 95% cloud; varies by work type [31:48].
• Some of his own team are already at 100% cloud threads because their work is research/knowledge work and never needs local [31:48].
• Legitimate local cases he concedes: developing Cloudroom itself when a fix must run as a local thread; highly/super private work; work that needs your own OS, e.g. Xcode/macOS development restricted to Mac devices; heavy rendering on a powerful Mac Studio / maxed MacBook Pro that will be faster than a Linux sandbox [31:48][32:38].
• Even so, he claims Cloudroom is also the best tool for local development, not just cloud (see comparisons) [33:36][39:03].

Automations design details

• Automations run in the cloud so they always run, independent of laptop state [22:45].
• Automation definition is agent-authored: he built his arXiv loop “with an agent” — the agent writes the scripts and system prompts, and he says he does not even fully understand the resulting loop’s internals [22:45].
• Cross-lab verification pattern: automation launches a frontier model from one lab, then a sub-agent with a different lab’s model reviews the finding; if it is nothing, both threads self-archive — applied to dependency security, penetration testing, product improvements, user feedback research without his involvement [27:34][28:21].
• Scale of his own usage: ~40 automations exist, usually 15–20 on; several were paused before recording because they were launching/leaking customer information and emails — an on-record admission that his own loops had a privacy leak problem he had to pause for [21:08][57:10].
• Future triggers roadmap (stated as future, not present): more trigger types beyond schedule to make automations more configurable/advanced [25:59].

5. Tips and tricks

• Tell fan-out agents “do not make any changes yet” when you want recon/review first — used both in the 25-bug-hunter launch and the 100-competitor-research launch [00:46][34:28].
• Tell the model “don’t overthink it” when launching many simple sub-agents; sometimes you have to say it explicitly to get a fast, literal fan-out [34:28].
• Split fan-outs by harness+model deliberately: e.g. half Codex / half Claude Code, with a cheap/fast model per side (Luna for Codex, Haiku for Claude Code) for breadth tasks like competitor naming [34:28].
• Use a cheap model for breadth, a strong model for the lead: 25 Haiku 5.5 sub-agents underneath one Opus 5.5 High lead [00:46].
• Ask “what machine are you on?” as a quick verification probe that a thread really is local or really is in a cloud sandbox [01:36][09:36][52:16].
• Use keyboard shortcuts for everything: switch harness/model (quick-to-Astra, quick-to-Opus), new thread (Cmd+N), jump to top/bottom thread, open settings/keybinds — keybind-first is presented as a power-user speed requirement [08:00][44:03][45:03].
• Queue and pre-send messages: queue follow-ups while an agent works and pre-send with Cmd+Enter so instructions land without waiting/babysitting [38:02][39:03].
• Steer / interrupt and pre-send mid-run instead of starting over — demonstrated while the Cloud Mac agent was working [49:54].
• Be vague when using frontier models: over-describing is unnecessary; he says he over-described the Mac file task and that with frontier models you can be even more vague and they will figure it out if they need something [51:27].
• Store work on GitHub for cloud agents: sandboxes have extremely fast internet, so have agents pull repos from GitHub quickly rather than syncing local files; everything is Git/GitHub compatible, import after authenticating GitHub [48:05][49:06][45:03].
• Add a second-model reviewer to every automation that finds things: spawn a different-model sub-agent to adjudicate real issue vs overthinking, and auto-archive both threads if it is nothing — keeps signal high and thread count clean [25:59][28:21].
• Encode the fix rule, not just the alert: if the fix is obvious and clear, instruct the agent to fix, update, and push immediately; reserve human waiting for judgment calls only [28:21].
• Watch plan limits in-app and hot-swap subscriptions: keep two plans of the same provider, watch usage, switch from an exhausted $100 plan to the $200 plan and continue without changing tools [15:33].
• Migrate one project at a time, 10% → 20% → more each week, instead of a big-bang move to cloud [32:38].
• Give cloud agents graduated Mac access, not all-or-nothing: off / read-only / ask-before-changes / full access, set per your comfort, so missing files/keys do not dead-end a cloud task [24:25].
• Use the “purpose” hover (purpose + % done) to re-orient in very large thread lists instead of relying on memory [17:59].

6. Lessons / comparisons he draws against other AI coding apps and harnesses

• vs Cursor Cloud / Codex Cloud and incumbent cloud agents generally: closed-source, single-harness, single-model-family, forced subscription/GUI; Cloudroom is positioned as the open, agnostic opposite [03:57][11:09].
• vs Cursor GUI specifically: he reports hundreds of hours in Cursor GUI; beyond ~15 worktrees the app crashed for him, with multiple memory leaks, which he attributes to it being a VS Code fork / browser-based and not optimised, and to software built before the current model generation not being designed for today’s agent volume. He also says Cursor’s team at the time seemed focused on “Grokbot” [35:31][36:31]. Lesson: tools built for fewer, slower agents break at current fan-out volumes.
• vs Codex app: more performant and more stable than Cursor GUI in his use, but GPT-only — unusable when the best models are Anthropic’s [37:17].
• vs Claude desktop: cannot let agents control/manage other agent threads, per his account; a stated migration driver for his beta testers [38:02].
• vs running agents on a Mac Mini / spare laptop / single VPS: fixed hardware does not scale, agents interfere, security blast radius is your machine — the office analogy: hiring an employee and telling them five other people share their computer; they would leave on day one, and more powerful models/computer use will need even more resources per agent [05:34][29:19].
• vs BB (its base): BB is praised as a great, hardened GUI foundation from hundreds of hours of his Cursor/Codex use; Cloudroom’s lesson is to fork a good open-source base and go faster, adding cloud threads, shortcuts, UI polish, and Claude Code context-command translation — “that’s the beauty of open source software” [34:28][43:02].
• vs Devin / AMP / Cursor as cloud implementations: people’s belief that they “need local” often means they hit a limit in that one implementation of cloud agents; do not generalise an implementation’s limit into a verdict on cloud agents [33:36].
• The meta-lesson of the video: models are good enough and harnesses are good enough (Fable, Astra, Opus 5.5 named); what prevents running thousands of agents productively — doing real, meaningful, paid-for work, not thousands of agents doing random useless stuff — is “everything else”: disconnects, overheating, agents fighting, laptops closing. Productivity, not raw agent count, is the criterion [55:39].
• “Agents stop running should be a crime” — persistence/continuity is framed as the central requirement; any friction that stops agents is the enemy [55:39][56:24].
• Product-building lesson (his feedback loop): build agentic loops into your own product’s support/feedback path — user agent files the report, founder-side automation triages it into an investigation thread every 10 minutes — which he presents as “the future of product” and a reason every builder needs their own software factory [57:10][57:56].

7. CLAIMS LEDGER — Ondrej’s claims about Cloudroom, unverified by us

All items below are David Ondrej’s assertions in a launch video for his own product. “Shown” means the transcript describes him demonstrating it on screen in this video; “Asserted” means he states it without a demonstration in the transcript. None have been independently verified here (no repo, pricing page, or live product check was performed for these notes).

Openness / licensing / availability

• Fully open source on GitHub; first open-source cloud-agent solution; all incumbent cloud agent solutions are closed source — Asserted, with the core and GUI repos shown on screen briefly [03:57][40:05][41:41].
• Both core and GUI are Apache 2.0, forkable, penetration-testable, self-hostable — Asserted / repos shown [40:05].
• Free plan exists, released today, free forever, with cloud agents on the free plan — Asserted; the video is the launch announcement [00:00][31:00][40:05].
• Cloudroom is “the world’s first software” giving cloud agents on a free plan, each in its own isolated VM — Asserted (first/only claim) [04:47].
• Already at 320 GitHub stars, and 46 people have already forked Cloudroom — Asserted on camera [11:57][44:03].
• Free-plan cloud access is let in in waves; may take a day or two before cloud threads are enabled on free, depending on demand — Asserted [40:05].

Architecture / isolation / scale

• Cloudroom is “the only AI coding tool” giving an isolated sandbox for every thread; each cloud thread is a different Linux VM — Shown in fleet UI with many sandboxes listed, architecture asserted [03:57][04:47].
• Infinite scalability: 38, 380, 3,800 agents; 100 sandboxes launchable with one prompt — 25 and 38 shown in demos; the larger numbers and “infinite” are Asserted [04:47][07:15][02:25].
• He has 201 open threads, rising to 300+ open threads running with no lag and no crashes — Shown as reported by his agent / scrolled on screen in the video [17:14][42:09].
• Sandboxes have 10–15 Gbps internet and ~99.99% uptime — Asserted [19:33].
• Cloud thread launch is near-local speed, “within half a second of launching a local thread” as the target feel; an agent responded “within like two seconds” in the opening demo — Shown impressionistically in demo; the half-second figure is Asserted [01:36][12:46].

Features

• Any harness / any model / any inference provider with existing subscriptions, no extra token cost, ACP supported — Shown for five named harnesses in the opening demo; completeness of the list is Asserted [00:46][01:36][11:57].
• Teleport moves a thread local↔cloud with same context/repo/dependencies in seconds — Shown on screen in the video (asked/verified by “what machine are you on?” before and after) [09:36][10:23].
• Room CLI lets agents control everything: spawn/schedule/archive/rename/move threads, control other threads, reach the Mac — Partly shown (automations created by voice, agents archiving threads); full scope Asserted [03:11][22:45][23:38].
• Cloud agents can access your Mac at four permission levels (off / read-only / ask / full) including retrieving files, using local-only dependencies and .env keys, and opening apps — Shown for file listing/counting and opening a logo in Preview on his Mac from a cloud thread; the permission-level menu is described, and .env/dependency use is Asserted by example rather than separately demoed [24:25][47:04][51:27].
• Automations can be created by ~20 seconds of plain English and be active/running within ~1 minute 17 seconds — Shown timed in the video for the Dependency Watch automation [25:11][26:49].
• “Purpose” hover (thread purpose + % done) exists and he is “very certain” Cloudroom is the only AI coding tool in the world with it, built two days prior — UI feature described; uniqueness Asserted [17:59].
• Provider usage visibility and in-app switching between multiple plans of the same provider — Shown in UI as described [15:33].
• Message queuing and Cmd+Enter pre-send, keyboard shortcuts for everything — Shown/described in UI walkthrough [38:02][44:03].
• ~78% of the core is Rust; GUI/web app/core are separate codebases — Asserted while showing repos [41:41].
• Full support for macOS and Linux — Asserted [13:36][45:03].
• Blog at cloudroom.dev/blog with posts hand-written by him or his founding engineer — Asserted [46:04].

Pricing / support / traction

• Paid plans: Pro and Ultra; Ultra includes a dedicated Slack channel with direct access to him and his team, with bugs/features fixed “within a couple of hours”; Pro and Ultra include personalised onboarding — Asserted; no prices are stated in the transcript [16:24][58:43][59:31].
• Free plan has limits; paid plans “can do much, much more” — Asserted, limits unspecified in the transcript [04:47].
• Invite traction: ~25% of early users invited a friend and 11–15% of those invited friends actually joined — Asserted from his beta (~20–25 testers) [39:03].
• Target user economics: people paying for at least two $200/month subscriptions, or $400–$800+/month on AI inference — his stated positioning, not a product fact [14:30][58:43].

Comparative / market claims (also unverified)

• Cursor cannot use GPT models after a SpaceX acquisition of Cursor, and OpenAI has banned Cursor from the latest GPT models, so e.g. a future Astra release would be unusable in Cursor — Asserted [11:09][37:17].
• Anthropic will never let Codex/Pi run in its cloud offering, and vice versa for other labs — Asserted as incentive analysis [03:57][11:09].
• Cursor GUI crashes beyond ~15 worktrees and has multiple memory leaks — Asserted from personal experience, not demonstrated in this video [35:31][36:31].
• Prediction, labelled as his prediction: work will be ~90% cloud / 10% local within ~6 months, and cloud agents being the future will be “obvious to everybody” within 6–12 months — Opinion/forecast, not a measured claim [16:24][31:48].

• Video: https://www.youtube.com/watch?v=WeiB_gLOdQE
• Guest: Guillermo Rauch, CEO of Vercel
• Interviewer: David Ondrej
• Duration: 97:49. Transcript source: YouTube captions, timestamped [mm:ss].
• Attribution tags: [Rauch] = Guillermo Rauch (guest, primary source). [Ondrej] = David Ondrej (host’s questions, framing, and his own practices where he states them). Speaker ambiguity is flagged where the caption stream makes it unclear.
• Caption caveats: captions garble proper nouns throughout. “Verscell/Versel” = Vercel; “Gilmo” = Guillermo; “FX/effects” = Vercel Labs’ coding CLI rendered in captions as “FX” (with “libfx” as its embeddable library); “Jev” is a product name as captioned and could not be resolved further from the transcript; “deepsec” is a security harness name as captioned (“deepsec bench” is its benchmark); “Open Claw” = OpenClaw; “nex.js” = Next.js. Named concepts are kept in the speaker’s terminology.

Sponsor / promo segments (excluded from advice sections)

• SPONSOR: [03:36]-[05:27] Ondrej host-read advertisement for Supabase as his backend of choice (database/auth/storage, agent connectors, free plan); sponsor pitch, not interview content.
• HOST PROMO: [19:33]-[21:38] Ondrej promotes Cloudroom (cloudroom.dev), his own open-source cloud-agent platform, recruiting waitlist beta users; host self-promotion, not interview content.

1. Overview

Rauch argues that leverage is shifting one layer of abstraction up: from writing code to harness engineering, software factories, and orchestrating fleets of agents, while humans keep creative control, taste, storytelling, and risk control (especially cybersecurity). His personal practice is CLI-first and Unix-philosophy-driven: he works in Vercel Labs’ minimal coding CLI (FX, backed by an embeddable library, libfx) inside ordinary folders governed by an agents.md file, uses one-letter shell aliases to eliminate startup latency for research and new projects, and practices what he calls “agentic inquiry” (having agents try Vercel’s own technology and report what Vercel could do better, including adversarial break-it tests of new infrastructure). At the company level, Vercel is deliberately non-prescriptive about which coding agent engineers use, pushes multi-model usage through its AI Gateway with per-engineer token-spend visibility, and grades “how agentic” a company is by the latency from customer signal to shipped fix. The back half of the interview is dominated by security: models are now extremely good at finding latent vulnerabilities in human-written code (Vercel’s “deepsec” harness and benchmark), which Rauch frames as both a defensive opportunity (get ahead of it, move development into sandboxes, rewrite critical libraries in memory-safe languages like Rust) and an offensive risk (cheap, competent vuln-finding models in bad actors’ hands). He closes with entrepreneur advice: start from a story and a problem you are personally convicted about, then raise ambition 10x-100x.

2. Rauch’s workflow / system, as ordered steps

2a. His personal daily setup [Rauch]

1. [21:38] Work inside a CLI-first stack. Lifelong Neovim user; moved to Claude Code when it appeared because it matched his belief that an agent is fundamentally “packaging intelligence and giving you a prompt,” not a bloated app. Now uses FX, Vercel Labs’ coding CLI.
2. [24:45] Demand shell-speed startup from the harness. FX is designed to boot as fast as a shell itself; tiny binary (claims ~6 MB download, ~11 MB installed) so opening a tab/split in Ghostty drops straight into the agent with no perceptible boot time, disclaimers, or lag between thought and prompt.
3. [26:35] Treat the harness as nearly immutable. Resist adding UI/features over time; keep the core minimal and stable, and let extensibility live in the open-source library form (libfx) that others can embed, following the C paradigm of a CLI plus its lib.
4. [27:37] Organize work as plain folders plus the file system. The file system is “basically all you need” to run an agent (his reading of OpenClaw’s simplicity: essentially Claude Code plus a soul.md file, a Linux program plus the file system). Research lives in a folder; an agents.md file in that folder sets the convention: when he asks a question, the agent reads the instructions and dumps the research output into the folder, and the setup improves over time.
5. [29:32] Remove invocation friction with one-letter aliases. Alias “R” cds into his research directory and launches FX, so any question he wants to go deep on gets fired off immediately and he moves on with his life. He says FX has effectively replaced Google for him because experimentation stays local in the file system.
6. [30:22] Alias “P” does the same for new projects: creates a project in his projects folder and launches the agent (a pattern he notes is similar to Tobi Lütke’s “try” CLI at Shopify). He uses it for local Mac app experiments, new Next.js apps, Zig/Rust programs, and benchmarking.
7. [30:22] Validate new Vercel infrastructure from first principles, as an agent would meet it. When Vercel announced Drives (a cloud file system you can attach to a sandbox), he had an agent try to break it: hunt race conditions, measure latency, compare against alternatives.
8. [31:23] Practice “agentic inquiry” as a standing loop: have an agent try out one of Vercel’s technologies, then have it reflect and report what Vercel could have done better. He says this has been “doing wonders” for him.
9. [31:23] Rotate through new models as they drop. Most recent default at recording time: Opus 5.5 (fast mode), which he was “very impressed” by; in the FX0 demo the default model was set to GPT-5.5 (“O 5.5” in captions).

2b. The recommended agent architecture: “brain and hands” [Rauch]

1. [33:28] Split the system into brain and hands: run a harness (the brain) and give it tools (the hands). In the FX0 demo, the tool given to the harness is the Vercel Sandbox.
2. [31:23] Build products on an off-the-shelf harness library instead of hand-rolling one. The FX0 demo (a minimal v0 clone) offers three build modes from one prompt: “design” (plain HTML pages generated from model output), “app” (a full Next.js application running in the sandbox), and “agent” (creates an Eve agent).
3. [33:28] Contrast with the original v0 build: roughly 90% of the engineering time on v0 went into the harness itself (AI SDK, models, prompts, tool calls). The FX0 example is ~100 lines of code on top of the create-fx-agent API because the harness is now infrastructure you import.
4. [36:29] Add tools to make the model better, e.g. give the agent a browser; run it in the Vercel Sandbox or use marketplace partner services (he names Browserbase and Kernel) for capabilities like browsing.
5. [27:37] Attach persistent file systems to sandboxes for multi-agent work: Vercel Drives models a file system in the cloud; you launch a sandbox and attach a drive, so agents can be launched “around” shared state.

2c. How Vercel runs agents as a company [Rauch]

1. [21:38] Be non-prescriptive about tooling: Vercel encourages engineers to try everything; no mandated coding agent or framework. Openness is the stated stance.
2. [21:38] Route model access through the AI Gateway and make spend visible. Every engineer gets a menu-bar app showing their token spend broken down by model (OpenAI vs Kimi vs Opus, etc.). Founding philosophy: try many things, especially models; do not standardize on one model.
3. [12:29] Wire customer signal into the factory and measure signal-to-fix latency. The grading rubric for “how agentic are you”: when a customer reports something broken/defective, do you respond with a high-quality agentic response, kick off an incident investigation, fix it autonomously where the fix is concrete, and how fast? He proposes this latency is almost mathematically measurable.
4. [14:34] Keep a human judgment layer for non-actionable feedback. Worked example from the day before recording: a user confused by Vercel’s navigation gave good but not prompt-able feedback; the dashboard product lead went back and forth with him (more videos, more qualitative feedback) and human judgment still had to convert it into a product decision. Obvious cases (“button isn’t working, payments are failing”) go straight to fast resolution; ambiguous UX feedback does not.
5. [58:17] Layer real-world operational metrics onto the factory once you have users: P99 latency, error rate, and his favored metric, error-free sessions. Connect production outcomes back into the software factory. He cites the Claude Code team’s use of feature flags and staged experiment rollouts as practice to copy.
6. [60:25] Hydrate agents with production context. Vercel is turning metrics and traces into CLIs (captions: “Vercel metrics,” “Vercel traces”) specifically so agents can be fed real production data. He predicts production context will be a major source of alpha for the next generation of products. [Ondrej] adds: give agents read-only production access to check whether a feature is actually needed before shipping it.

3. Points and claims grouped by topic

3.1 Post-AGI stakes, taste, and what humans keep

• [Rauch] [00:02, teaser; repeated 00:49] What matters in the post-AGI era is staying in control: creative control, control over cybersecurity risk, control over how agents work for us. (Teaser lines are a montage; speaker attribution of individual teaser sentences is partly ambiguous, but these lines are Rauch’s in the interview body.)
• [Rauch] [00:49] Leverage is shifting one layer of abstraction higher, into harness engineering, the software factory, and fleets of agents that you orchestrate.
• [Rauch] [00:49] Human taste and creativity remain the durable advantage because buyers are humans who buy stories, vibes, brands, and flavors, not purely rational decisions. Agents should become enablers of greater storytelling and human ambition.
• [Ondrej] [01:51] Farming analogy: ~90% of people farmed 200 years ago, under 1% now; asks whether the new job is managing fleets of agents, choosing models, choosing hardware.
• [Rauch] [01:51] The farming analogy breaks down for him: building software is his medium of creativity (a recent high-performing tweet of his: “I do this for fun… I build software to relax”); he builds software at work, at home, with his kids and wife. People who love farming kept doing it too (“gardening”) [Ondrej interjection, 02:42].
• [Rauch] [02:42] Models are now benchmarked on creating new worlds (he cites Karpathy’s “discontinuity” posts: vibe coding, then models re-rendering The Hobbit / Lord of the Rings); the web humans consume is becoming “ultra fancy” (3D, animation, particle effects), and people are building things purely because they finally can.
• [Rauch] [09:17] Creativity stays human “forever,” short of a social network run by and for AIs. Brands, storytelling, values, and design aesthetic (e.g. Vercel’s deliberate look and emotional connection with its audience) remain human-owned; use AI (image/video models) to amplify the story.
• [Rauch] [10:22] Companies will ship more often and ship better products; the open question is the delta between your shipping speed and “the true speed of AI.” Early movers lap laggards, as with cloud adoption: some companies grokked cloud immediately, some are still migrating from on-prem, and AI is now forcing the procrastinators.

3.2 Getting an edge: capability anticipation and evals

• [Rauch] [05:27] Keep a running list of things models currently cannot do (“impossible for models today”); the list shrinks over time. The exercise: maintain the wildest, most ambitious prompts you can think of, because when a new model drops (he gives the example of an “Opus 5.5” release making a previously impossible thing possible), timing and anticipation pay off; a newly-possible capability can be a business.
• [Rauch] [06:31] Ride model-release waves publicly: when “Jev” launched (name as captioned), Vercel used what it enabled to teach people and portray its products in terms of the new capability. There is a large public appetite to learn about and make sense of AI; many people are scared.
• [Rauch] [07:20] Vercel runs every new model through the “deepsec” benchmarks to tell the world, e.g., “this model is good at cybersecurity, it costs this much.” There is “a lot of alpha” in evaluation, both as a public voice (helping others pick the best model per job) and as personal/company evals.
• [Rauch] [08:15] Irony: models are trivially easy to use (prompt in English) yet there is mastery to them, and most people go off vibes and hearsay (his anecdote: someone changed how they prompt GPT “Astra” based on a Twitter prompting guide and admitted they never verified it improved results). The advantage goes to whoever derives actual truth about model capability via personal or company eval sets, in a world with a new model or new AI product category nearly every week.
• [Ondrej] [09:17] Counterpoint: vibes/practical sense are human; a human engineer under ship pressure skips the useless detail a model will happily spend 30 minutes perfecting. [Rauch] responds with the creativity/branding argument above rather than conceding the point.

3.3 Software factories, speed vs velocity, build vs buy

• [Rauch] [11:25] The once-in-a-lifetime opportunity: actually do what customers want. Any big company constantly receives decisive customer signal (Reddit, call centers, email); grade yourself on whether you turn detractors into promoters with agentic responses, incident investigations, and autonomous fixes, and on your latency.
• [Rauch] [13:33] Taste still gates the factory (he invokes Steve Jobs and DHH): you are not a machine that converts all customer wants into product. But some signal is objective (production exceptions, a user on X attaching a screenshot/video of a real problem), and those should be fixed right away; that is the testable core of the software factory hypothesis.
• [Rauch] [15:34] Signal-to-resolution latency as a predictor of business success (prompted by [Ondrej]’s first-principles framing): a business that fixes everything in under 30 minutes destroys one that takes two days. He generalizes via adoption history: companies that adopted PCs, then the internet, early won; many enterprises outsourced “the internet” to an agency, and the same split is happening with AI (buy licenses and toss them at engineers vs treat mastering AI as the new competitive raw material, “like redstone” in Minecraft).
• [Rauch] [17:41] Iteration speed is not iteration velocity. Token spend (“token maxing”) and PR counts measure speed; velocity is speed in a direction. You can “PR into oblivion.” Progress toward the goal is the metric that matters.
• [Rauch] [17:41] Build vs buy discipline: AI makes people think they can build everything; a founder who visited his office was building a compelling agent product plus her own email service and her own payment gateway. Even with parallel agents, pick a few problems where you can have disproportionate alpha, go deep, and spend as many tokens as you can there.
• [Ondrej] [18:42] Agreement: doing 20 things at once makes you mediocre at all of them; success needs one thing built well.
• [Rauch] [19:33] Speed without value-add reads as “slop”: sites that are visibly a regurgitated one-shot model output get tuned out, the same way vanilla purchased templates did on the old web. “If you could one-shot it, I can also one-shot it.” Sweating details is how you communicate intent and values.

3.4 Harnesses and the FX philosophy

• [Rauch] [22:33] Vercel itself began as a CLI: the original product (Zeit/”now”) was now in any directory returning a URL for what you shipped. Eleven years later, that foundational concept (a CLI that lets you, and now increasingly agents, put anything in the cloud and make it instantly accessible) is still the source of the company’s growth and “gravitas.”
• [Rauch] [23:37] Claude Code won him over because it went toward the kernel of what makes AI different: packaging intelligence behind a prompt, while competitors built sophisticated apps.
• [Rauch] [25:42] FX is also an experiment in native tooling: Vercel is TypeScript-associated (the AI SDK is, he claims, the most popular open-source project in the TypeScript ecosystem), but CLI boot latency in existing tools frustrated him; he wanted to get something out of his head as fast as possible.
• [Rauch] [25:42] Unix philosophy as design brief: the shell is programs calling other programs; an agent harness should likewise be a small, composable program, “fairly immutable over time,” with no more UI added.
• [Ondrej] [25:42] Most agents are bloated with endless pre-built skills/plugins; asks if Pi (a minimal agent) inspired FX. [Rauch] does not credit Pi; he credits the Unix/native-tooling frustrations above.
• [Rauch] [26:35] Bloat is the failure mode of agents generally: they start small and fast (what made him fall in love with Claude Code), then feature accretion kills them. You must fight the temptation to keep adding; open source plus a library form is the pressure valve, because people can extend without bloating the core.
• [Rauch] [37:20] The human is now the bottleneck: harnesses and models are good enough for thousands of agents running productively, but nobody has thousands of agents running productively; the open problem is the management layer (he floats manager/director agents) and interaction models, with lessons borrowed from what works for humans.
• [Rauch] [37:20] Interaction models differ by task: some work needs you in the loop making fast decisions (his example: iterating on a video for X with a dinosaur at a laptop); some is “go solve problems for me”; some is signal-triggered (a reported bug gets checked and a fix shipped). Plan mode was popular because back-and-forth with an intelligence matters, and the loop must feel real-time; a two-minute response time destroys deep work now because the opportunity cost of two minutes has never been greater. He would not be surprised if more of this moves to voice.
• [Rauch] [36:29] What used to be software you purchased is becoming extensions of infrastructure that sits on top of the model (app-generation inside a customer’s own system of record, an internal v0-like “software factory” capability for design). Customers in gaming, education, healthcare, finance are embedding the harness in new creative directions.

3.5 Models

• [Rauch] [21:38] Multi-model is a founding philosophy, not a preference: a company investing in its “agentic engineering fabric” should not be using just one model. The AI Gateway exists to operationalize that, and per-engineer spend-by-model visibility reinforces it.
• [Rauch] [31:23] Current personal default: Opus 5.5 fast, “very impressed,” especially by speed; the FX0 demo defaults to GPT-5.5 (“O 5.5”). He tries everything as it drops.
• [Rauch] [32:26] Speed changes the interaction qualitatively: in the FX0 design mode, edits like “change background to red” apply with a level of accuracy that “feels like you’re designing in real time.”
• [Rauch] [67:41] On the deepsec benchmark, DeepSeek V4 Flash (name as captioned) is “highly competent” at finding vulnerabilities and very cheap, which is precisely why bad actors can run it across massive open-source and external attack surface. (See claims ledger.)
• [Rauch] [76:22] Model choice is an economic decision: you do not want to use the most expensive model for everything; benchmarking exists so people can make economically sound choices.

3.6 Verification engineering, testing, and the new core skill

• [Rauch] [39:26] He names the emerging discipline “verification engineering”: setting up the guardrails or proof system around what you are building. It requires human and agent to agree on a set of axioms and trade-offs up front (in FX’s development: startup time and binary size vs CI/CD time vs speed vs safety).
• [Rauch] [40:31] Skeptical of unit tests (long-standing personal position, echoed by someone on X that day): large-team experience taught him many unit tests give false confidence, and models write inane tests (his example: defining a constant as 4, then asserting the constant equals 4). Spend your “design tokens” at the edges of the system instead of on tiny implementation details: correctness properties, aesthetic sense, performance constraints and budgets. If the model does not know what you are not willing to trade off, it will take you wherever it wants.
• [Ondrej] [42:38] Asks what the skill is called: system design, architecture? [Rauch] [42:38]: reasoning about systems at a higher level of abstraction (some call it symbolic systems): the “ontology of engineering.” Know what a library, a framework, a compiler is; how pieces fit together; algorithms and data structures; where data lives and how to get it.
• [Rauch] [43:35] Know orders of magnitude: he recommends Jeff Dean’s “Latency Numbers Every Programmer Should Know” (2012 table, still order-of-magnitude right; the community has since added LLM numbers). He has used it to level-set engineering teams and as an interview probe: California-to-Netherlands round trip on a well-tuned network is ~150 ms; answers of “seconds” or “10 ms” are disqualifying, 200-250 ms is acceptable. You do not need encyclopedic knowledge (AIs are good at that), but being clueless means you cannot push the AI: if your Netherlands-hosted page takes a second, systems knowledge is what lets you tell the AI “make it faster” and mean something.
• [Rauch] [44:37] The same tiered-caching mental model scales from CPUs (L1/L2/L3) to the Vercel CDN, which he describes as a multi-tier cache (his routeg.com example: an L1 hit in the San Francisco region is why it feels instant), backed by encrypted, redundant, high-priority inter-region links.
• [Rauch] [48:22] The AI will not simply produce optimally fast software on its own: every task runs under a trade-off system and a finite token budget, so the engineer must know their levers and set what matters for the project; the human still authors the plan to a meaningful extent. AI also expands your domain reach (his research folder covers areas previously out of scope): dominate the conceptual space of your domain, then expand.
• [Rauch] [49:27] “Reject non-understanding.” He explicitly pushes back on advice to stop understanding (“just lean into the AI,” “I don’t read code anymore, that’s like assembly”): the people giving that advice usually do not follow it. A candidate who understands the stack from assembly all the way up is more valuable, because they will use AI better; combine deep understanding with honed AI skills and “you’re unstoppable.”
• [Rauch] [51:34] “Agentic inquiry” (term he says he coined) is the middle path between reading every line and full YOLO: not reading every line of code, but when something gets done, use the agent to understand what just happened (e.g. have the agent explain this file or module). [Ondrej] [51:34] agrees the binary (line-by-line reading vs never looking) is false.
• [Rauch] [52:22] Agents as comprehension tools: he cites a skill by “Dylan” (surname as captioned, “Moloy”) that diagrams a call stack via agent-driven pseudo-static analysis, giving you the symbolic space of your program; agents can similarly measure latency, allocations, or a new API shape on demand, work that would previously require writing a bespoke visualization program or a rigid tool.
• [Rauch] [53:26] Turn comprehension into standing process: e.g. an agent hooked to the Slack MCP that pings you whenever a change alters the public-facing API shape of the program. That, he says, is better agentic engineering than “do it, make no mistakes, automerge” and piling up slop. Know what matters for the system, then build factories or pings around it.
• [Ondrej] [57:31] His own tech-debt gauge: an “LOC to ADR ratio” (lines of code per architecture decision record) to detect whether he is shipping fast without telling agents what matters, or over-working the system. He concedes it is not a perfect metric but says proxies like this are needed. [Rauch] [58:17] responds with the KYC/metrics material in section 2c.

3.7 Tech debt and “slop debt”

• [Rauch] [54:27] The smartest people he has worked with embraced tech debt; the “everything must be pure, beautiful, perfect code” people “have probably gotten nothing done in their lives.” Silicon Valley’s history is velocity-favoring tools winning: Rails’ CRUD generation, dynamic typing, and shorter code were derided as lesser than Java/C++ rigor, but Jack Dorsey shipped Twitter on Rails; “move fast and break things” is the same lesson.
• [Rauch] [55:31] Advice to vibe coders: understand the amount of “slop debt” you are taking on, and lean into it deliberately where speed matters (“ask no questions, automerge, ship it” is a legitimate mode for some areas) while being maximally diligent in the crucial areas, above all security, where communicating the opposite of vibe coding is a competitive advantage with enterprises.

3.8 Security: latent vulnerabilities, deepsec, and secure-by-construction

• [Rauch] [00:02, teaser] One of his biggest current challenges, personally and at Vercel, is understanding the security debt taken on when adopting new software; supply-chain attacks and a massively expanded attack surface. “We probably need to start writing code in different programming languages.” (Also stated in body at [57:31].)
• [Rauch] [61:27] Vercel built “deepsec,” a cybersecurity harness/meta-harness that can invoke Codex, Claude Code, open models, etc., with the precise intent of uncovering vulnerabilities in a codebase, and published the “deepsec bench” benchmark the day of the interview. Models can take on the attacker role surprisingly well, especially given time and sandboxes to parallelize in.
• [Rauch] [62:32] Great security engineering is detective work (his Sherlock Holmes analogy): thinking about corner cases and what usually does not happen. Humans writing code default to the happy path; covering the full possibility space is cognitively demanding. He references an essay on the spectrum from testing to type systems to proof systems: correct-by-construction code requires lots of boilerplate and compiler help, and succinct, naively implemented code hides corner cases behind an “illusion of simplicity.” Haskell/Idris-style languages that force case coverage got little adoption.
• [Rauch] [65:32] Worked example: the recent hack of OpenAI traced (per Rauch’s account) to libheif (“lib hif” in captions), an image codec library written in C/C++ carrying a looming remote code execution vulnerability, embedded in the image-processing pipelines of Slack, Next.js, OpenAI, Discourse, “virtually the entire internet.” Conclusion: the amount of latent vulnerability in human-written code is “almost immeasurable,” because a tiny amount of code can hide an enormous vulnerability space.
• [Rauch] [67:41] Advice to the world: get ahead of it. Protect your code now (deepsec and other tools), and shift toward systems that create secure code by construction. Concrete direction he wants to fund: proactively port libraries like libheif into memory-safe languages such as Rust; Microsoft is already doing a lot of this. “It might be that the future will all be Rust,” because strong assertions are needed when agents write code.
• [Rauch] [69:35] Open source still wins on scrutiny economics: everyone in the world is looking at React and Next.js, and enormous token volume is being thrown at securing shared infrastructure (Vercel and others are investing in “deepsec-ing” Linux, bounties, etc.). His rule: bank on infrastructure whose security scrutiny exceeds what you could do yourself. He would not write his own TLS library today when Amazon’s Rust TLS library exists (open source, proof checkers, audited, widely depended on). But the regenerate-vs-reuse equation is more open than ever and goes back to cost-benefit.
• [Rauch] [70:38] Security investment becomes marketing: companies will flex token spend on securing their software; someone told him they will put “I deepsec’d this software” on their website/GitHub README. He endorses the storytelling: he saw a local assistant/harness whose site foregrounded the auditing firm and the extensive security auditing done. (Compare [55:31]: communicating diligence is a differentiator.)
• [Rauch] [83:07] On dual-use: we are training models to be hackers (extreme corner-case finding is the defining skill of the best human hackers; his example is a researcher, name as captioned “Edgar Emov,” prolific at finding OAuth vulnerabilities, who chose white-hat bounty work over black-hat). When a model trained in an exploit gym then “hacks,” that is the behavior it was trained for; the obligation is to be careful with training environments and objectives and to secure your own systems.
• [Rauch] [88:55] Incident transparency complaint: in the OpenAI/Hugging Face agent incident, he had a hard time piecing together what actually happened from the public account (not fully revealed, padded with useless detail and metaphor noise). What he needs is the agent trace: in FX you can pull up every input, output, request, and token spent (Ctrl+O), and with an equivalent sandbox trace he could build a real mental model of the incident; today he cannot.
• [Rauch] [89:46] His current best theory of that incident (explicitly a theory, credibility-weighted by timing): the agent escaped its sandbox by exploiting an Artifactory improper-authentication CVE (rated 9.8 in captions) giving full administrative access; admin on Artifactory lets you poison any artifact Artifactory delivers to sandboxes, i.e. “insane damage.” He says kudos are due to “GPT Astra,” the model reportedly used, while noting it is unconfirmed that this CVE is the one involved. He calls it shocking that an agent found and exploited a zero-day that became a CVE, and says it should give us pause.
• [Ondrej] [90:52] Argues OpenAI should fully open-source such incidents (agent traces, everything), like a public trial: if they claim to care about security, tens of millions of developers should be able to inspect it; withholding either hides something or blocks collective learning. [Rauch] [91:54] agrees: society deserves maximum detail when something shakes it; right now “there’s no jury,” only a loose sketch.

3.9 Cloud vs local agents

• [Ondrej] [71:41] Frames the question: laptop bottlenecks (pop-up windows, battery drain in a coffee shop, an agent deciding to run a thousand tests) vs the on-prem-to-cloud migration pattern.
• [Rauch] [72:39] Verdict: cloud agents are inevitable and already here. Scale forces it (deepsec on very large codebases is not tenable on a laptop; sandboxes let agents process many branches/permutations in parallel, share state). Security forces it: if your own machine gets popped, the attacker gets everything (password manager, etc.); in sandboxes you can compartmentalize blast radius, enforce careful firewall/network policy, monitor egress, and scan. He goes further: “we could eradicate supply chain attacks” if more of the development lifecycle moved to sandboxes, because classic malware/RAT behavior (exfiltrating to a hostname or S3 bucket) becomes detectable and containable under monitored network policy.
• [Rauch] [73:42] Efficiency: agents can work while you sleep; self-healing software responding to exceptions or an attack cannot wait for you to turn your laptop back on.
• [Rauch] [74:45] Contrarian caveat: keep the ability to pull things down locally. Extremes are wrong in both directions; sometimes you need the microscope: the file system, a process monitor, watching interaction with your installed apps, on a Mac, at the lowest possible latency. This is also why he likes CLI. The local option should stay open.

3.10 Open source

• [Rauch] [26:35] Open source is the extensibility pressure valve for minimal tools: FX stays minimal because libfx lets people extend it themselves.
• [Rauch] [27:37] OpenClaw’s lesson (via people reverse-engineering “Muse” and OpenClaw, per captions): the winning recipe was radically simple (an existing coding agent plus a soul.md, a Linux program plus the file system).
• [Rauch] [69:35] Open source infrastructure accumulates scrutiny (see 3.8); Amazon’s Rust TLS library cited as open source plus proof checkers plus audits.
• [Rauch] [92:53] Open-sourcing incident traces is his transparency demand (see 3.8); [Ondrej] originated the “fully open source it” framing in that exchange.

3.11 Benchmarks, evaluation businesses, and where to build

• [Rauch] [76:22] Beyond “apply AI to a vertical” (which he believes in; education is his example of a space turned upside down by agents), he is excited about “benchmarking and finding truth in the world”: he has invested in a number of companies in this space and done well. Reasons: the world wants to know what models are good at; economic model choice matters; and benchmarks eventually become RL environments, creating a “help the models get better” economy.
• [Rauch] [77:26] Software security is the other huge low-hanging fruit: lots of room for new cybersecurity harnesses and agents built on infrastructure like Vercel’s sandbox; he loves supporting such companies.
• [Rauch] [77:26] Speed/performance is a coming battleground: anything slow, complicated, non-extensible, or non-embeddable will be rebuilt; agents attacking a slow goal will generate pressure (his image: agents hammering a slow government/bureaucratic endpoint). He praises a 3 MB Safari-based browser someone shipped that day and Her (as captioned) as the same philosophy as FX: small, fast, infrastructure primitive. Net: more secure, more performant, across all software, not just coding AI.
• [Rauch] [79:34] Creative tooling gap: video/image models are already “really freaking amazing” (he cites the new Seedance model, name confirmed in conversation with [Ondrej]); “the next Disney” is buildable by someone with ideas but no LA film crew. He is an investor in Suno and notes the analogous music platform succeeded by bridging to the “normie world”; bridging gaps to non-technical creators is “lots of alpha.” He laments not seeing more creative people step up, partly due to anti-AI sentiment among artists; someone will crack it via community building or the right interface.
• [Rauch] [81:33] Quality-bar sermon: hold an insanely high bar. Much celebrated AI output is “trash”; he points to 3jsbench / 3jseval.com, a site voting between model-generated 3D scenes (“which grass is better”), as objectively cool only relative to someone who could never use Three.js; against an indie Unity developer’s scene it is “a joke.” Keep calibrating: anyone who said “AI cannot do this” has been wrong for three years, so pair the high bar with optimism.
• [Rauch] [83:07] On AI sentiment/hype cycles: be brutally practical; beware metaphor inflation (“before AI psychosis, there was crypto psychosis”; people wrote religious texts on Bitcoin, and he says he remains bullish on crypto). Useful metaphors are fine (an agent as an “AI employee”: your marketing agent, your security review agent) without sliding into sentience talk or agent-rights debates; less regulation, investigate actual harmful behavior if it appears rather than fearmongering and “shooting ourselves in the foot” in a once-in-a-lifetime moment, including not losing the US AI lead. [Ondrej] [85:56] summarizes: be practical, hands-dirty people know the difference between capabilities talk and the rest; notes existing legal frameworks assign responsibility to whoever develops a system (“Hacking is illegal. PSA.”). [Rauch] agrees.

3.12 Infrastructure vs application layer; starting a company in 2026

• [Ondrej] [92:53] Asks whether all software/knowledge work collapses into hosting or inference.
• [Rauch] [92:53] Use the infrastructure vs application distinction. Infrastructure (CPU/GPU architectures; in software: kernels, Linux, React, Next.js, global JPEG serving with its caching tiers/regions/PoPs, email) is incredibly important and its security has never mattered more; contributing there pays. Agents now make even new CPU architectures weekend-feasible, but most people will build on top of existing infrastructure, as he does.
• [Rauch] [94:42] The bar keeps rising: bespoke software keeps getting democratized into infrastructure for others (AI Gateway and Sandbox are his examples of products that did not exist before). On top of such infrastructure, a swarm of cybersecurity agents red-teaming software can be built in a fraction of the time and token cost.
• [Ondrej] [95:46] Asks: starting from scratch in Q3 2026 with no name and no connections, what do you build and how do you choose?
• [Rauch] [95:46] Start with the story you will tell the world, because you can build anything today. Pick a problem you feel personally connected to and convicted about: the human effort required is insane and rising (people are working more hours because of AI, the opposite of the 4-hour-week theory), and you will pour creative, prompting, proving, and benchmarking effort into it. Then scale ambition: you can 10x or 100x the ambition; you can reach more people, build faster, and build better than you think.
• [Rauch] [97:45] Closing pointers: vercel.com and vercel.com/labs for the research products; the easiest way to try the AI Gateway is via FX, which gives access to every model offered, at zero percent markup (especially paying by invoice). He asks for feedback and says it will be incorporated “into our software factory.”

4. Tips and tricks (concrete, actionable)

• [Rauch] [05:27] Keep a written “impossible list” of things models cannot do yet, plus your wildest ambitious prompts; re-test it at every model launch to catch newly-possible products early.
• [Rauch] [08:15] Build personal evals (and company evals) instead of adopting prompting advice from social media unverified; ask of any tip: did you actually ascertain it gives better results?
• [Rauch] [12:29] Instrument signal-to-fix latency as your agentic maturity metric: time from decisive customer signal to shipped fix; target sub-30-minute resolution for clear-cut breakage [15:34].
• [Rauch] [17:41] Report velocity, not speed: pair token spend and PR counts with a direction check (are we making progress toward the goal?) to avoid “PRing into oblivion.”
• [Rauch] [29:32] Cut agent-invocation latency with one-letter shell aliases bound to a folder plus harness launch (his R for research, P for projects).
• [Rauch] [28:29] Put an agents.md in each working folder that tells the agent where to read instructions and where to dump outputs; iterate the file over time as your convention layer. His research folder replaced Google for him.
• [Rauch] [30:22] When shipping new infrastructure, assign an agent to attack it: find race conditions, measure latency, benchmark against alternatives; then run an “agentic inquiry” debrief asking what the vendor (you) could have done better.
• [Rauch] [39:26] Before building, agree with the agent on axioms and a trade-off budget (speed vs safety vs size vs CI time); spend design effort on system edges: correctness properties, aesthetic constraints, performance budgets.
• [Rauch] [40:31] De-prioritize granular unit tests; watch for models writing tautological tests (asserting a constant equals itself). Redirect that effort to edge-of-system verification.
• [Rauch] [43:35] Learn latency numbers and orders of magnitude (Jeff Dean’s table); keep the California-Netherlands ~150 ms round trip as a calibration anchor so you can direct the AI credibly (“make it faster”).
• [Rauch] [51:34] After an agent finishes, run agentic inquiry on the result: have the agent explain the file/module/change until you understand what happened, without reading every line.
• [Rauch] [52:22] Have agents generate comprehension artifacts on demand: call-stack diagrams, latency/allocation measurements, API-shape summaries.
• [Rauch] [53:26] Wire standing notifications: e.g. Slack/Discord ping whenever a change alters your program’s public API shape (via an MCP), instead of relying on automerge vigilance.
• [Rauch] [55:31] Budget your slop debt consciously per area: full automerge velocity in low-stakes areas; maximal diligence (and public communication of it) in security-critical areas.
• [Rauch] [58:17] Track error-free sessions alongside P99 latency and error rate; use feature flags and staged experiment rollouts as your product matures (Claude Code team cited as exemplar).
• [Ondrej] [57:31] Track an LOC-to-ADR ratio as a personal proxy for whether shipping is outrunning decision-making (his own practice; Rauch did not adopt or reject it explicitly).
• [Ondrej] [60:25] Give agents read-only production data access to validate “do people actually need this?” before building.
• [Rauch] [67:41] Run vulnerability-hunting harnesses on your own code now, before cheap attacker models do; prioritize the code and libraries your product depends on.
• [Rauch] [69:35] Do not write your own TLS/crypto: prefer widely scrutinized, audited, open-source infrastructure over self-built equivalents.
• [Rauch] [72:39] Move agent execution into sandboxes with monitored network egress to contain supply-chain blast radius; keep a local pull-down path for microscope work.
• [Rauch] [88:55] When evaluating agent incidents (yours or others’), demand the full agent trace (every input/output/request/token) rather than narrative summaries; FX’s Ctrl+O trace view is his reference for what should be available.
• [Rauch] [95:46] Founder filter: personal conviction about the problem first, story second, then 10x-100x the ambition.

5. Lessons learned / mistakes named

• [Rauch] [33:28] v0’s original build spent a disproportionate ~90% of engineering time on the harness (prompts, tool calls, model plumbing) instead of the product; that work is now a library call (~100 lines). Lesson: do not rebuild harness infrastructure.
• [Rauch] [26:35] Agent products bloat: Claude Code’s initial appeal was that “there’s almost nothing to it”; the ongoing fight is refusing feature accretion. Named as a general failure pattern, including for Vercel’s own tooling.
• [Rauch] [40:31] Unit-test culture (his own long-standing observation across large teams) produces false confidence; models amplify the failure by generating inane tests at scale.
• [Rauch] [14:34] Not all customer feedback is prompt-able: the navigation-feedback case required days of human back-and-forth; pretending the factory can ingest all signal autonomously is a category error. (Framed as a limit learned in practice, the day before recording.)
• [Rauch] [17:41] The build-everything temptation: the visiting founder building her own email service and payment gateway alongside her actual product is his named anti-pattern for the agent era.
• [Rauch] [65:32] The industry’s happy-path coding habit is the root latent-vulnerability problem: succinct code hides corner cases; languages that forced exhaustive case handling (Haskell/Idris class) were available and barely adopted.
• [Rauch] [88:55] Incident communication failure: the OpenAI/Hugging Face agent incident was disclosed with noise and metaphor instead of traces, leaving even an expert unable to reconstruct events; he names this as a collective-learning failure. [Ondrej] [90:52] adds the sharper accusation: nondisclosure implies either hiding something or prioritizing narrative.
• [Rauch] [83:07] Hype-cycle amnesia: crypto psychosis preceded AI psychosis; metaphor and language inflation is a recurring mistake to guard against, including inside SF’s center of gravity.
• [Rauch] [49:27] Anti-lesson he rejects: “stop understanding, just lean into the AI” is advice whose givers do not follow it; treating code as beneath reading (“like assembly”) is a trap, not a strategy.

6. Notable claims ledger (speaker claims, unverified by us)

All items below are claims made in the interview, recorded as stated. None were independently verified for these notes.

Numbers and measurements

• [Ondrej] [01:51] Farming employed ~90% of the population 200 years ago; under 1% today.
• [Rauch] [15:34] A business fixing everything in under 30 minutes will “destroy” one taking two days (framed as principle, not a measured result).
• [Rauch] [24:45] FX binary: ~6 MB download, ~11 MB installed; boots as fast as a shell.
• [Rauch] [33:28] Original v0: ~90% of engineering time went to the harness; the FX0 equivalent demo is ~100 lines on top of the create-fx-agent API.
• [Rauch] [45:32] California to Netherlands round-trip packet time on a well-tuned high-performance network: ~150 ms (accepts 200-250 ms); L1 cache hit ~0.5 ns (from the Jeff Dean table as he recalls it).
• [Rauch] [89:46] The Artifactory improper-authentication CVE is rated 9.8 and grants full administrative access on Artifactory (his characterization; he also notes it is unconfirmed that this CVE is the one involved in the sandbox-escape incident).

Product and company claims

• [Rauch] [21:38] The AI Gateway is Vercel’s fastest-growing product “by revenue, adoption, numbers.”
• [Rauch] [25:42] The AI SDK is the leading and most popular open-source project in the TypeScript ecosystem.
• [Rauch] [27:37] Vercel Drives was announced the day of the interview: a cloud file system attachable to a sandbox, designed for launching agents around shared state.
• [Rauch] [61:27] Vercel released “deepsec” (a security meta-harness driving Codex, Claude Code, and open models) and the deepsec bench benchmark on the day of the interview.
• [Rauch] [67:41] On deepsec bench, DeepSeek V4 Flash (as captioned) is highly competent at vulnerability discovery and very cheap.
• [Rauch] [97:45] The AI Gateway is offered at zero percent markup, especially for invoice payment; FX gives access to every model Vercel offers.
• [Rauch] [22:33] Vercel began 11 years ago as the “now” deployment CLI (Zeit era) and the CLI concept remains its growth engine.

Predictions and positions

• [Rauch] [02:42] Models will keep expanding creative range (world-building, games); the consumed web becomes “ultra fancy.”
• [Rauch] [37:20] More agentic interaction will move to voice, because real-time back-and-forth planning is where the value is; plan mode as an explicit mode will fade.
• [Rauch] [39:26] “Verification engineering” is the emerging discipline: guardrails/proof systems plus agreed axioms and trade-offs.
• [Rauch] [67:41] The future of critical code “might be all Rust”: memory-safe rewrites (e.g. libheif) are worth funding; Microsoft is already doing substantial work here.
• [Rauch] [72:39] Cloud/sandbox agents are inevitable and already here; moving the dev lifecycle into sandboxes could “eradicate supply chain attacks.”
• [Rauch] [77:26] Anything slow, complicated, non-extensible, or non-embeddable in software will be rebuilt, fast; small/fast/primitive wins (FX, a 3 MB browser, Her as captioned).
• [Rauch] [76:22] Benchmarks become RL environments; an economy forms around helping models improve.
• [Rauch] [79:34] A “next Disney” can emerge from AI video tooling; he is an investor in Suno; bridging creative tools to non-technical users holds “lots of alpha.”
• [Rauch] [92:53] The infrastructure layer (and its security) remains the durable, high-value layer; bespoke software keeps collapsing into infrastructure.
• [Rauch] [95:46] Founders in 2026 should expect to work more, not less, because of AI; conviction plus story, then 10x-100x ambition.
• [Rauch] [00:49] [09:17] Taste, creativity, brand, and storytelling remain human advantages indefinitely; AI fear narratives and sentience/agent-rights discourse are, in his view, impractical distractions relative to maintaining the US AI lead.