By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.
Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.
CHAPTERS
- 0:05 – 0:38
Weave’s mission: measuring engineering work to build “software factories”
The host welcomes the founders and asks what Weave is. Adam Cohen explains Weave’s core idea: using models to measure engineering work and then optimize how humans and AI agents work together.
- •The company positions Weave as a tool to turn a software company into a “software factory.”
- •Weave builds models to measure engineering work, including productivity and quality.
- •The goal is optimizing collaboration between humans and coding agents.
- 0:38 – 1:26
Who uses Weave and why demand surged with coding agents
The conversation moves to Weave’s traction and why the past year has been strong. Andrew Churchill lists customers spanning startups to large enterprises, and Adam Cohen ties growth to applying Weave’s measurement approach to coding agents.
- •Customers range from small startups to Fortune 100 companies.
- •The founders describe a “blowout year,” including a Series A raise.
- •Weave expanded from measuring humans to also measuring and optimizing coding agents as agent use exploded.
- 1:26 – 2:17
Weave Router overview: automatic model selection for each coding task
The host introduces Weave Router and asks how it saves money without hurting results. Andrew Churchill explains the routing workflow, what it integrates with, and the performance/cost claim they’re seeing in benchmarks.
- •Router sends each prompt/task to the best-fit model automatically.
- •Designed to plug into coding agents so users don’t manually choose models.
- •Integrations mentioned include Claude Code, Codex, OpenCode, and Pi via CLI setup.
- •Andrew claims benchmark results reaching “Astra-level performance” with lower cost and higher speed.
- 2:17 – 3:00
Ensuring routing doesn’t degrade quality: velocity + bug/quality tracking
The host presses on the risk of routing to weaker models that introduce bugs. Andrew Churchill argues Weave can observe velocity and quality outcomes, citing their internal use and claiming no increase in bugs while output accelerates.
- •Quality regression is framed as the biggest risk of model routing.
- •Weave’s broader product measures both velocity and quality, which they use to assess Router’s impact.
- •Andrew cites Weave’s internal data as evidence: output accelerating without increased bugs or quality issues.
- 3:00 – 4:02
Open source availability and routing across subscription “subsidies”
The host asks who can use Router and whether it’s open source, then explores how Router handles multiple paid subscriptions. Andrew Churchill says Router is fully open source and describes routing across accounts to maximize included usage before using other models.
- •Router is described as fully open source, with hosted and self-hosted options.
- •Subscription plans are mentioned (Max and Boost).
- •Router can route across multiple accounts/subscriptions to use included limits (“subsidies”) efficiently.
- •The host frames a desire to exhaust paid plans before sending traffic elsewhere; Andrew says they support this.
- 4:02 – 5:03
Practical cost/output gains: using smaller models for simpler sub-tasks
The host asks what happens in practice for “token maxers” already hitting plan limits. Andrew Churchill says Router helps users go farther by choosing smaller/cheaper models for sub-tasks like codebase exploration, reducing usage-limit burn while keeping end results.
- •Andrew claims users can “go twice as far” for the same spend on large-model plans.
- •He argues many tasks don’t need the biggest model; routing picks appropriately sized models.
- •Example given: codebase exploration can go to a cheaper model without affecting final outcomes.
- •Router can switch across different plans without manual logouts/logins.
- 5:03 – 6:31
The open-source model landscape: where they work well (and where they don’t)
The host asks about the rise of open source models and what Router uses. Andrew Churchill describes open-source models as close to frontier performance at much better cost, good for many everyday coding tasks but not for the hardest frontier work.
- •Open-source models are described as not frontier but “not that far behind,” with strong cost-performance.
- •He differentiates tasks: complex system-building vs simpler UI tweaks or CRUD work.
- •Models cited as performing well in their testing include DeepSeek, Kimi, and GLM.
- •Andrew suggests open-source models may be sufficient for many hobby projects based on his experience.
- 6:31 – 7:09
Weave Router vs OpenRouter: “gateway” vs intelligent coding-agent routing
The host asks for a comparison to OpenRouter and how Weave’s autorouting works. Andrew Churchill says OpenRouter provides access and manual choice (plus fallbacks), while Weave automatically chooses models, tuned specifically for coding agents, and he claims OpenRouter’s autorouter isn’t very strong for this use case.
- •OpenRouter is characterized as enabling access to many models with user selection.
- •Weave focuses on automatic model choice for coding-agent workflows.
- •Andrew claims OpenRouter’s autorouter “doesn’t work very well” for their benchmarked coding-agent needs.
- •Positioning: specialization in coding tasks versus general model access.
- 7:09 – 8:11
How the router is trained: learning from sessions and downstream PR/production outcomes
The host asks how Weave decides where to route a task. Andrew Churchill describes training on large numbers of coding-agent sessions and using downstream signals like PR results and production outcomes, plus additional training that rewards successful task completion.
- •Training data described as hundreds of thousands of coding-agent sessions.
- •The router considers downstream effects: PR quality, merges to production, and longer-term outcomes.
- •They run additional experimentation sending tasks down different “model paths” and rewarding success.
- •Andrew emphasizes it’s learned by a trained model rather than hand-coded rules.
- 8:11 – 10:27
Origins in YC batch: from measuring humans to measuring AI-driven coding work
The host rewinds to Weave’s earlier focus and asks what it was like during the YC batch. Adam Cohen explains they started with measuring engineering work beyond simplistic metrics, then demand shifted as tools like Cursor spread and customers wanted to quantify AI’s productivity impact.
- •Early Weave focus: measuring engineering productivity and quality, beyond lines of code/PR counts/tickets.
- •Adam describes traditional metrics as inadequate for understanding real work.
- •As AI coding took off (with Cursor noted), customers asked for AI impact measurement.
- •This became the bridge from measuring humans to measuring coding agents.
- 10:27 – 12:29
Selling Weave early: skepticism, proving with customer data, and staying ahead of the curve
The host asks what early 2025 selling was like, before widespread CLI agents. Adam Cohen describes widespread skepticism and the need to prove results by connecting customer data, plus an advantage from working with fast-moving teams adopting agents earlier.
- •Sales conversations began with disbelief that engineering work could be measured meaningfully.
- •They overcame skepticism by connecting customer data and validating results against expectations.
- •They claim an “ahead of the curve” advantage from working with fast-growing teams using agents early.
- •Adam frames a recurring question: are coding agents actually faster than a person typing code?
- 12:29 – 14:35
From adoption to optimization: what engineering leaders ask Weave now
The host asks how questions from engineering managers evolved. Adam Cohen describes a progression from benchmarking speed, to confirming AI makes teams faster, to optimizing usage (prompting, parallelization, and task handling), with startups and late-stage companies at different points on the curve.
- •Question evolution: speed benchmarking → AI impact → efficiency/optimization.
- •Optimization topics mentioned include prompting, agent parallelization, and task handling.
- •Adam outlines an adoption curve: adoption → token-maxing → optimization.
- •He contrasts startups (more token-maxing/productivity focus) with later-stage or cost-sensitive companies (optimization focus).
- 14:35 – 20:16
ROI measurement and coaching: cost per output and daily skill feedback
The host asks for concrete examples of Weave’s impact, including reactions to dashboards and how teams learn from top performers. The founders discuss identifying outliers, measuring “cost per output,” and a coaching layer that suggests behaviors like pushing back on agents and restarting sessions to control context growth.
- •Example use case: comparing a “software factory” output against human work to decide what to automate.
- •Teams often discover surprising positive outliers when seeing fully populated dashboards.
- •A central metric described is “cost per output,” relating AI spend to units of productive work.
- •Coaching insights mentioned include better task handling, pushing back when the agent is wrong, and restarting sessions to reduce growing context costs.
- 20:16 – 25:28
Building and validating software factories: PR review stacks and internal quality checks
The host probes “lights-off” software factories and how to avoid low-ROI autonomous output. Andrew Churchill emphasizes validation and iteration, explains Weave’s own agent setup (including token-efficient context delivery), mentions using multiple PR review tools, and describes internal checks to prevent issues like over-abstraction and long-term architectural drift.
- •Core challenge of software factories is validation, not generating lots of code.
- •Weave compares outcomes like bugs and customer reports to evaluate autonomous systems against baselines.
- •Weave describes using multiple PR review tools and keeping them if each finds unique issues.
- •They built internal PR checks reflecting what expert reviewers care about, including guarding against agent over-abstraction and maintaining system-level coherence.
- 25:28 – 28:36
Where model routing is headed and what “great AI engineers” do differently
The conversation closes on the future of model selection and what makes engineers effective with AI. Adam Cohen predicts routing will replace manual model dropdowns and could combine model strengths; Andrew Churchill says top AI-tool users stay grounded in understanding what they’re building and steer agents well, and he forecasts engineering leadership shifting toward effective token allocation.
- •Adam predicts model switching will become exhausting, pushing teams toward routers that choose automatically.
- •He suggests routing could aggregate model strengths and outperform any single frontier model.
- •Andrew argues the best AI-tool users don’t lose track of what’s happening, enabling better steering and avoiding “slop.”
- •He forecasts running engineering teams becoming an exercise in token allocation and deploying agent swarms toward opportunities.
