The Bikeshed Pod

This is a grab-bag episode. Most of the news is bad: old software, weak keys, and patches that do not reach old versions. Some of the news is better: new personal agents and new browsers to try.

The Browser Company of New York is stopping work on Arc and moving users to its new browser, Dia. Scott is not happy. He will try Dia with the AI features off, because his work requires a Chromium-based browser. He also likes Zen, an Arc-style browser built on Firefox. Matt uses Dia at work and Helium at home, but he wants tab sync to iOS. He wants to try Yab ("yet another browser") for this. Matt says it is strange that the Atlassian CEO was a daily Arc user, but Arc still did not come back. Dillon defends Firefox. Matt says he would use Internet Explorer 8 first.

REA is a skill that tells an agent how to reverse engineer any software. People used it to make open-source versions of the Adobe Creative Suite and to make game mashups: Steve from Minecraft in Elden Ring, and Skate 3 on a Call of Duty map. Model companies now block it, because it is close to the cybersecurity work they already restrict. Copies with new names continue to appear. Dillon asks a good question: when an agent does not solve a problem, how do you know if it was blocked?

PHP had two remote code execution vulnerabilities with CVSS scores of approximately 9.2 and 9.3. The timeline is not clear. OpenAI's Patch the Planet (similar to Anthropic's Project Glasswing) found related issues, and a person outside the embargo leaked the announcement early. This made the PHP Foundation release the fix sooner. US, Japanese, German, and Dutch officials told people to take servers down. The patches cover PHP 8.2 to 8.5 only, so older versions get no fix. HubSpot runs Java, so Matt's team is safe. Matt thinks of Wayfair's PHP monolith first. Scott remembers a former Wayfair leader who said PHP is "very malleable."

The October Node.js security releases fix only Node 22, 24, and 26. Matt has local workloads on Node 12. Dillon's coworker must upgrade a service on Node 8. Dillon is upgrading four apps from Next.js 15 to 16, because Next 15 support stopped on October 21.

eMudhra, an Indian company that manages intermediate certificates, used very small numbers as private keys: 4, 11, 23, and others. All eight keys are less than 257. A simple script can find them in less than one minute. At Dillon's company, 20 people worked in one room for three days. A director said the internet is "on fire" and kept walking. Matt is on call, and he had to update a certificate bundle package. The only engineer who knew how it worked was laid off, so Matt used Opus 5.5 to help.

GitLab had the same flaw in its software for approximately 10 years. The flaw gives attackers access to GitLab servers. Matt makes a joke about GitLab's "10 customers."

Anthropic announced Claude Duet, an always-on personal agent with memory, calendar, and email access. Other products in this space are OpenClaw, Hermes, Grok bots, Poke, Instinct, Meta's Muse, and OpenAI's Dots. Matt has a Dot named Bill. He made Poke reduce its price from approximately $35 to $2 per month, but then he cancelled it. The hosts ask if non-engineers will use these agents. Scott's dad still uses the URL bar as a search engine.

Matt brings his own blog post to the table. It argues that software engineering is heading toward a kind of thermal equilibrium, where the structures we rely on today flatten out. Scott and Dillon test each of its three predictions, and they don't always agree.

Before the predictions, a detour into nostalgia: the 2016 left-pad incident. A tiny npm package was pulled from the registry, and CI broke across the JavaScript ecosystem in a world before lock files. Matt is shocked his co-hosts don't remember it. Dillon notes that he was still in high school, and that it blew up mostly because it was "such a stupid library."

Matt describes a range of libraries, from is-even to curl. Agents can already replace the small end. The question is how far up the range that ability goes in 10–15 years. Dillon points to maintainers who are drowning in vibe-coded slop PRs, which he says is "killing the fun." Scott wonders what happens to model quality if less good code goes public. He also worries that an all-proprietary world makes humans less useful when they move between jobs. Dillon's darker take: if open source dies, innovation might die with it, because AI companies will just own the solutions. Matt also brings up Google-style readability, which is really about comprehension, and asks how much of it survives when AI-written code goes straight to production.

Junior hiring has dropped off a cliff and teams are shrinking. Matt worries that in five to ten years there will be no senior engineers left, because nobody got the chance to "fuck around and find out" as a junior. Scott says his team (14 or 15 people, "not humble bragging") is actually growing with ML engineers. He also calls out an AI-generated PR full of setState and useEffect that should have been lifted up a layer. Dillon calls the "you don't need juniors anymore" pitch a bad bet. The juniors he works with are "cracked," and companies that stop bringing in new people will slowly make themselves worse. On the human side, Scott finds talking to an agent all day draining ("Claude, cook"), while Matt has made peace with his role as a meat proxy.

Matt's claim with the biggest economic impact: models are now good enough to generate something that LARPs as a product. For example, a Raycast replacement for a few dollars of tokens instead of $200 a year. Scott connects this to Wes Bos's AI yard-sale app and to the Neovim vs. out-of-the-box trade-off. Dillon names the catch: if you don't understand the code, you can't steer it. You hand the wheel to a self-driving car and it "turns you into a tree."

Matt ends on the post's counterargument, a play on the old "you wouldn't download a car" ad. Durable services like S3, EC2, and Cloudflare Workers are much harder to replace than a desktop tool. Every product has a moat. Raycast's is a stream. Amazon's is the Atlantic Ocean.

A wave of teams dropping Tailwind for StyleX prompts a look at how the two tools think about CSS, where each wins on performance, and what "readable" means when agents write most of the code.

Matt sets up the comparison. Tailwind is a utility-first library with prebuilt class names. StyleX has you write the styles yourself and compiles them into atomic utility classes. Scott compares StyleX to styled-components, Linaria, and Vanilla Extract: the CSS lives right next to your JSX, but the work happens at build time. Matt notes that HubSpot has started to adopt StyleX at the component library level. There, the compiler dedupes identical rules into shared class names, which is more atomic than tools like Vanilla Extract, where each style block becomes one class.

Scott thinks Tailwind is still a bit ahead on build and compile speed. Matt has seen mixed reports. Some teams got a smaller JS bundle after migrating, because StyleX can merge commonly paired rules into one class. Other teams saw no change or larger output. In Matt's words, to quote Scott's favorite phrase, "it totally depends."

One claim that teams make is that AI coding agents write StyleX better. Scott is not fully sold on it, but he likes that StyleX puts the real CSS in front of you. He thinks it is important to review AI output and to know modern CSS (he recommends Kevin Powell's YouTube channel). Dillon says he only adopted Tailwind because he had to. For him, AI-generated UIs with 42 classes on one div are unreadable. He would "die on the hill" that long Tailwind class names are bad, because StyleX is much closer to the CSS spec.

Matt asks how well each tool supports new CSS features. Tailwind has lagged because it has to ship new class names, and it is not clear how StyleX handles CSS it does not recognize yet. If these tools get in the way, he expects more people (or their agents) to go back to handwriting CSS.

Matt mentions that Tailwind was acquired by Shopify, while the StyleX team at Meta is smaller than it was. Scott shares his spicy deets: he has heard that Meta runs an internal fork and that the open source version may depend on a single maintainer. Matt says that an internal/external split is normal for Meta projects (React was the same) and jokes that one person with unlimited agent tokens could be enough.

Dillon thinks the community respects Meta's libraries because of React, which could help StyleX grow. Matt thinks that open source is Meta's way to build a larger hiring pool of engineers who already know its stack. Compare this with an unpopular in-house framework, like Tungsten (a deep cut for longtime listeners). Dillon wants a future episode about how React became so popular.

The layer between your prompt and the model that answers it is turning into real infrastructure — and real money. Matt walks through what an AI router is, why Stripe and Ramp are both making moves in the space, and what routers look like inside a large org today.

Matt defines the term for the AI context: a router takes one prompt and decides which backing model should answer it. Every major inference company already runs one, it just isn't talked about much. His example — send a prompt to Fable in Claude Code, hit a topic the model shouldn't handle, and the request gets quietly redirected to Opus 5 behind the scenes.

Outside the big labs, a crop of startups sell a generic version: point your traffic at the router and it decides whether the request goes to OpenAI, Anthropic, or some other backend, based on your use case. The pitch to companies is flexibility — one subscription, many model types.

Two items on the table:

Matt's read on Stripe's motive: less about clever prompt-level routing, more about wanting a single gateway for all AI traffic and a single place to tune where requests go — offloading the infrastructure instead of juggling it internally.

Dillon pushes back on the valuation. Taking a prompt and picking a model doesn't sound like a hard problem — "are they just using an agent to then... ask the agent, hey, what model should we use for this?" Matt suspects OpenRouter isn't doing much intelligent per-request judging today; it's closer to percentage splits and explicit model selection. A true judgment agent at the router layer is still costly and hard to run efficiently at scale.

Matt frames a split in the ecosystem that most people don't realize they're on one side of:

Routers lean toward the second camp: they're what makes it practical to send specific requests to specific tuned models.

Scott recalls this exact theory from his Fireworks days — that catch-all models doing everything were unlikely to be realistic, and the future was small, well-tuned models plus a router that maps the right prompt to the right one. His observation now: model tuning has largely been offloaded from businesses to the AI companies themselves, because tuning is a high-cost problem space. Companies just hold an Anthropic subscription and an OpenAI subscription instead.

Dillon's practical want: pre-baked limits. At his job you can use Cursor, Claude Code, or ChatGPT, all as separate applications with different interfaces and no built-in caps — you find out you've used too much when someone tells you to chill out. He'd use expensive models more freely if he knew he had, say, a $100/week Fable allotment. Right now the ambiguity makes him avoid them.

Scott's org is similar: no hard limit, just an occasional "hey, calm down." Dillon's team had a leaderboard of AI spend by name — his strategy was staying out of the top 10. Matt's verdict: "so it's like a shame board now instead of a leaderboard." Scott got pinged as an "AI leader" at his company and didn't believe it, noting some colleagues are migrating entire codebases and taking it to extremes.

Matt describes the real setup: HubSpot runs a LiteLLM gateway deployed internally, with requests forwarded to OpenAI, Amazon Bedrock, or Base Ten depending on the model. Anthropic models go through Anthropic's enterprise offering instead. It covers both sides — engineers writing code and customers using Breeze, HubSpot's agentic surface — which lets the org control which model actually serves each request.

A finding from that setup: plenty of people assume they need Opus 5 or Fable 5 or GPT 5.6 to get the best result, but when the model is obfuscated behind the scenes, they can't tell they're getting GLM 5.2 and rate the output as good enough. Matt's careful framing — the point isn't lying to your engineers, it's that routers give orgs sane levers over cost and model policy.

Scott wonders where a routing layer would sit relative to Bedrock in his own stack. Matt's answer: Bedrock has a router, but a basic one — it honors the model you asked for rather than making a judgment call.

The clearest consumer-facing example: Cursor's auto mode, where you don't pick a model or thinking level, you just send the prompt and Cursor decides. Same pattern with subagents — Composer 2 for the main prompt, lighter models for scoped subagent work, which is how Claude Code spins up Haiku for subagents.

Matt's prediction for the back half of 2026 into 2027: routers get bigger, driven by companies employing more AI while getting fiscally conservative about AI spend. Routers are the balancing point — cap the requests hitting expensive frontier models, send the rest to something cheap that does the same work for pennies.

Dillon's (self-described not-very-hot) take: he'd prefer routing be automatic, because "I don't think we should be spending our day bikeshedding over what model to use" — the name of the podcast, by the way.

Matt agrees, but names the obstacle: engineers want to know the implementation detail and want to be using the best tool. Convincing them a cheaper open-source model is just as good for their problem is a hard sell against the branding.

Dillon's actually-hot take: he doesn't trust the providers at all. "I use Opus, they're probably using Haiku... and telling you it's Opus, charging you for Opus." Scott laughs because he kind of agrees. Both suspect it's already happening — earlier in the episode Scott predicted providers would "route you to some crappy model that you don't know you're using and tell you it's a one-tier model."

Dillon — finished a long project that made him want to quit his job, mostly from burnout, which is now cooling off after some time away. He's been playing chess on a smart chess board that grades your moves as good, bad, or an inaccuracy in real time and highlights legal moves when you touch a piece. Played his first game on it with his wife.

Scott — juggling five things at once, wrapping phase two of a project (his tech lead has replaced "phase one/two/three" with witty names). Fighting end-to-end tests that fail again every morning, and building a Buildkite CI pipeline to check against preview deploys instead of the current setup where everything fails in staging and never escalates to on-call. Calls it a nightmare. Heading to Portugal soon, and feeling re-energized after his own brush with burnout — he got to write some UI, which he doesn't do much anymore.

Matt — a teammate just left, leaving him and his principal engineer on the team, with a possible merge back into a sister team. Outside work: Big Walk, possible game of the year, maybe the decade. The Modern Warfare 4 closed beta starts today, with DMZ returning in October. Heading to Bergen, Norway with a plan to eat a reindeer hot dog — a trip Scott and Dillon learned about live, and took as a personal insult.

Three engineers, three very different answers to the same question: how much of your workflow should live in a skill file? The episode moves from a plain-English definition to the org-scale version at Scott's company, then to the small personal skills each host actually opens.

Dillon starts simple: a skill is "really just blocks of text" for common tasks you ask an agent to do. Two shapes are useful — a specific workflow you want followed, or a specific tool you interact with. His example is Contentful: he taught one skill everything about migrations, publishing, and the API, and offloaded that behavior permanently. Now he never has to open a session with "hey, can you help me with Contentful?" and watch the agent go read the docs.

Matt reframes it for anyone who has worked in ops: a skill is a runbook or a standard operating procedure, written down once and shared — except the reader is an agent instead of a coworker.

Scott reaches for skills on repeat tasks: PR descriptions, deploy confidence checks, a UI review skill that drives Chrome, takes screenshots, and posts them to the GitHub PR.

At the org level it goes much further. His company runs a skills marketplace per repo plus skills per project — multiple tiers of layers. Every unit and integration test is forced through a skill: a tag in AGENTS.md and the CLAUDE.md files invokes it whenever a test gets written, so the only way around it is writing the test by hand. The web platform team put real effort into making it robust, and Scott's read is that the forced path is a good thing because you get consistency out of it. Everything else is "choose your own adventure" — storybook stories, GraphQL, rebase-and-merge, title-tag migrations.

Matt sits at the other end. He barely loads skills at all. His repetitive prompts are short enough to live in a clipboard manager, and pasting a snippet is faster than saving a skill and loading it into a session. His hot take: the value of a skill depends on the model and the harness — some combinations do the pre-programmed work just as well without it. He notes HubSpot had a skill-writing explosion a couple of months back that has since cooled off. Scott's counter is short: "that's not the experience I have" — his are battle-tested and very clear.

Matt's whole PR-description prompt is: use ASD-STE100 Simplified Technical English. That is it. He finds the output slightly over-concise rather than verbose — the failure mode he sees from coworkers whose agents write PR descriptions that are "incredibly verbose and annoying to read." Dillon, who had never heard of the spec, said on air that he was about to run his tech spec through it. His company's PR plugin solves the same problem the long way: tell the agent not to detail every implementation choice, because "I used tailwind classes to move the div to the left" is not helpful to a reviewer who can see the diff.

Both companies are pushing past single skills into automated harnesses. Dillon's team has a workflow that cleans up a feature flag across many repos in one go — scan the repos, spin up tickets, execute them, open PRs, and pause for a human approval that unblocks the next stage. HubSpot has Mothership, built for scripted tasks like codemods across thousands of repos (they are, Matt says, "maybe infamously not a monorepo company"), and has recently added agentic missions that run a prompt across that same fleet. Matt flags a future episode: agents versus deterministic codemods, and where the line sits.

Light week. Matt's headphones kept dropping mid-record, so Dillon carried a stretch solo. Dillon fired off a live experiment — rewriting a tech spec in ASD-STE100 — and promised a verdict later. Scott's team shipped a natural-language end-to-end test platform built on aluminum, which he calls pretty cool. And the hosts agree there is enough left over for a follow-up episode on skills.

The crew puts a name to a creeping anxiety: the cost of running AI models keeps climbing, and nobody can prove the value climbing with it. What follows is part economics lesson, part group therapy for engineers drowning in model choices.

Scott lays out his prediction from the year-in-review episode: AI pricing was always going to soar. The $20/month plan was never meant to stay $20 — the playbook is to hype the tech, get everyone hooked, then raise prices once you're dependent. He draws the Uber parallel ("your ride's $6" turning into "$50 years later") and notes NVIDIA execs themselves saying models cost too much. Dillon's sharper framing: it's insane that this is a service where you pay for what you get regardless of outcome — the tokens are spent even when the AI goes off the rails.

Matt gets into the nitty-gritty: between 4.6 and 4.7, Anthropic changed the tokenizer, which effectively added a ~30% cost tax even though the model isn't dramatically better. This is why HubSpot has stuck with 4.6 rather than jumping to 4.7/4.8. Dillon's take: every new feature — like loops — is really just "a new way to burn tokens a little bit faster."

HubSpot leadership made Sonnet the default, walking back the old habit of defaulting to Opus. Matt argues you can go surprisingly far on Sonnet. Looking ahead, he and Scott revisit the intelligent router / mixture-of-models vision (echoed on The Next Token Podcast), where queries get split to cheaper models that are "good enough." The blocker: there's no sane default for how to route, and every eval and benchmark is flawed.

Contrasting notes on internal controls: HubSpot moved to the Anthropic enterprise plan and can hard-block models (e.g., a $0 budget on Fable requests so they auto-decline). Scott and Dillon's shops are still in an open trial period — the only "restriction" Dillon got was a Slack DM asking him to not use a pricey model as default. Dillon nails the meta-point: this is the epitome of the bikeshed — tabs vs. spaces, but now exploded into fifty variants. He just doesn't want to have to choose a model at all.

The emotional core of the episode. Matt calls out the Twitter hype cycle — public figures claiming each new model "completely changed everything," two weeks apart — as people blabbering for views. The real problem: software quality hasn't meaningfully improved in ~two years, yet spend keeps rising. His metaphor lands: we're all at the whetstone sharpening the knife but never actually cutting the steak. On measuring value, Matt admits HubSpot has no real KPIs (just DORA/SPACE speed metrics), and Dillon describes a dashboard that literally divides tokens spent by PRs merged into an "efficiency rating" — which once crowned him top engineer for shipping 20 config PRs in a week.

Matt's message of the day: be cognizant of how much time you spend whittling your workflow, and question whether you really need the newest new-fangled model. Scott still recommends experimenting, but in small enough chunks that it doesn't consume you. Dillon just wants to care less about which model he's using and get it out of his head entirely.

Scott has been writing a lot of automated tests at a bigger company than he's used to, mostly end-to-end and integration tests in Playwright (with past lives in Cypress and Selenium). His recurring theme: getting started takes three to four times the normal effort, especially on a product with heavy third-party permissions and multiple interacting applications where users may not have access to both. Playwright lowers the entry barrier, but rigorous permission-based flows are still intricate to set up.

Matt's counterpoint: the test harness matters more than the tool. Invest upfront in structure that makes flaky tests hard to write — e.g. preventing async operations from leaking between unit tests (a trick a former coworker used by tracking promises). Once the harness is solid, you can copy-paste-and-tweak tests quickly. He describes his own CLI's fixture-based end-to-end suite: run a command against a folder, assert the result against an expected schema.

Scott's team enforces page object models (POMs, or "palms") — a class per page with private methods to locate elements and public methods to drive reusable actions. He's not sold: it adds a layer of indirection, and when two people build POMs in parallel they clash and drift into abstract methods that just re-wrap Playwright.

Scott's crusade: smoke tests should gate code in the PR, not just run against staging after merge. He wrote ~200 smoke tests covering every page (including invalid routes) and hit friction from colleagues who argued "the end-to-end tests will catch it." His rebuttal: the e2e suite runs against staging, so a broken PR sits in master until an on-call engineer has to hunt it down and revert — killing a day's deploy. Smoke tests are cheap, fast, and fail loud before that happens.

Dillon's framing lands cleanly: every end-to-end test is a smoke test, but a smoke test is the lightweight version — a quick "is the page rendering, no crashes" check. Bigger e2e tests cost more to run and, per Dillon, flakiness scales with scope: the eight-minute single mega-test that fails in a new place every time you fix it. Keep flows small, parallelize, and balance value against breakage.

Scott's team considered editing a GraphQL query to bypass the real flow just to make a permission-heavy test easier to write. Matt flags this hard: don't build implementation pathways that exist only for tests. You diverge the test path from the user path, then catch a sev later and wonder why the test didn't fire — because it was testing something else entirely. Related: drift between spec and implementation (real-time updating dropped for a refresh button mid-project) is what QA ends up flagging, and unit tests, not e2e, are usually the right tool for those small correctness nitpicks.

The hosts riff on companies bolting adjacent products onto a core they're already good at. Google just announced a Whoop competitor (Dillon, who works at Whoop, notes the hardware looks better, the software maybe not, and that the device ships with an engraved jab at copycats — a callback to Amazon's short-lived Halo and the older Nike FuelBand). Whoop's own direction is a "health operating system" that links into clinicians and bloodwork — basically become MyChart — which drags HIPAA and product security into everything.

Meanwhile Uber is partnering with a hotel brand and Vrbo to sell stays, nudging into Airbnb's territory, while Airbnb adds car service. The group's read: these are mostly partnerships, not new builds — a cheap way to test a market.

Dillon's framing: companies treat lack of growth as failure, so they tack on extras "like candy at the checkout counter" to customers who never asked. That tips into enshittification — Scott contrasts annoying e-commerce upsells (button hidden where you don't expect it) with Airbnb doing it well by surfacing add-ons while you're already in a curious, planning mindset. Surprise stat: Uber ~$155B vs Airbnb ~$84B market cap, roughly 2x. Underlying tension: investors still want the 10x growth of five years ago, and it's genuinely harder to stay aligned and earn trust at scale.

Both Cloudflare (~1,100, ~20%) and Coinbase (~2,000) announced layoffs framed around AI. Matt pushes back with an input → output → outcome framework (from a Twitter article): AI inflates input (more code) and output (more features), but neither guarantees outcome (more customers/revenue).

From Anthropic's Code with Claude conference (Dillon: five minutes was enough), the standout was Jared from Bun: their coding agent RoboBun has become the top committer to Bun in ~6 months, out-pacing Jared after four years of work. Scott presses on whether it's real work or minor package bumps — Matt insists it merges commits, opens PRs, and triages issues end-to-end (reproduce the bug, open a fix), in Zig no less. Best moment: CodeRabbit (an AI reviewer) flagged an edge case on a RoboBun PR, and RoboBun argued back that it didn't apply and closed the comment on its own PR. Also noted: Jared's 500+ comment Hacker News thread about a branch using Claude Code to migrate Bun's Zig codebase to Rust. Dillon's verdict: a new way Twitter tech bros flex their token spend.

Matt is surprised Scott isn't into Pi (pi.dev — or as Matt prefers to share it, shittycodingagent.ai). His pitch: a deliberately thin alternative to the Claude Code / Codex / OpenCode CLIs — minimal system prompt, basically two built-in tools (run bash, read a file) — that you customize to your own workflow. Scott finds it unnecessary for his setup; Dillon lands the analogy: it's Arch Linux, an "operating system for running agents" that starts with nothing.

The pod quietly passed its one-year anniversary about two months ago and forgot to mention it (~2,000 minutes of yapping logged). Jokes about a five-year mark, a 10-year live reunion in front of an audience of exactly three — their wives — and Seattle in two weeks, where they might record live.

The article's core thesis: AI makes it easier to do more and harder to stop. Dillon frames the mechanism — agents get you 90% of the way, but that last 10% (the review) is where all the time goes, and the outputs pile up faster than anyone can clear them.

Pre-LLM, you'd note something as clean this up later and ticket it. Now an agent spins up a PR on the spot. Dillon's open-PR count becomes the episode's running gag — 30 → 40 → 50 PRs, "a pile of dirty laundry I need to clean up." The group debates whether shifting context left into draft PRs is actually fine, or just deferred debt.

Matt's key observation: agents sped up the development part of the lifecycle, but planning and review didn't speed up — so they become the bottleneck. He argues his own burnout comes less from overwork and more from PRs sitting unreviewed while everything else stays just as slow.

What used to be a conversation with a teammate — bouncing ideas, sanity-checking a plan — now happens alone with an agent. Matt: you become "a team of multiple teams of one," which may make the work feel less meaningful (and a little like "AI psychosis").

You're rewarded with more work, not more pay. The group lands on a rough 70/30 split (let the agent do ~70%, but look at 100% of the code), and Scott's bug-fixing tip: write the failing test first, then let AI fix it. Counterpoint from a Whoop director of engineering — the aspirational endgame is prompt → outcome → KPI check → ship with no human review. Everyone agrees: crazy, and not where we are yet.

Matt's company (HubSpot) defines AI adoption in tiers: beginner (legacy workflow, tab-autocomplete, 90%+ code by hand), intermediate ("single agent operator"), and advanced ("tech lead of agents" — managing a swarm). Everyone's expected to hit intermediate by end of Q2, but there's no rubric and no guidance on keeping quality high. The hosts' worry: you're being graded on process, not results — "I want to make the button blue, but now I'm going to use 10 agents."

Token spend is its own theme: Matt cites reports of Uber burning its entire 2026 AI budget in Q1. Scott connects it to feature bloat — churning out a six-image carousel nobody uses and burning a million dollars in tokens to do it. Shareholders get faster output and don't care about process; the people delivering get squeezed.

Matt launches a new drama segment ("I monitor the situation"). This week's tea: TanStack Start shipped what it branded React Server Components support — and the ecosystem pushed back that it doesn't follow the actual RSC spec.

Matt revisits a hot take from a year ago that he believes more strongly now: you shouldn't be using plan mode in your AI coding agents. The conversation lands on a more nuanced position — planning still matters, plan mode just isn't the right tool for it anymore.

Matt argues that plan mode in Claude Code and Codex has degraded over the past month or so. Where it used to ask a ton of clarifying questions, it now spins for 30 minutes and hands back a full markdown plan without ever pinging you for context. The on-rails experience has stopped doing the part that made it valuable.

Scott pushes back gently: plan mode still has a place, especially for big architectural changes where one-shotting will leave you with a context provider sprinkled across multiple files (his real example from the previous Friday). But he agrees the out-of-the-box version isn't the only way to plan, and often isn't the best one.

The real takeaway: planning the activity is still incredibly valuable. Plan mode the feature is just one — increasingly mediocre — implementation of it. The crew walks through the alternatives they're actually reaching for:

Matt surfaces the grill-me skill Matt Pocock shared (and Dillon dropped in the Discord): a one-line skill that tells the agent to keep asking questions until it actually understands what you're trying to build. Strong fit for feature work where you don't yet know the shape of the problem space.

Dillon describes his current workflow on a big work project: POC the entire user flow first, then POC each piece of the flow before building anything for real. He's been using Superpowers (the most popular Claude Code skill) and its brainstorming sub-skill, which builds mock interfaces so you can compare options. He'd rather over-plan than have to tell a coworker "Claude thought it was a good idea" when they ask why something works the way it does.

Matt frames plan mode and build mode as two ends of a spectrum where you actually want to land somewhere in the middle — exploring three or four ideas, spinning off agents to POC each, bringing findings back, iterating. He hasn't found a skill that nails this loop yet, and invites listeners with a working setup to share it in the Discord.

Dillon's softer take: plan mode is genuinely useful when you're new to agentic tooling. It gives you a clear default workflow before you know what you actually need. You grow out of it as you discover the specific checks — codebase exploration, TDD, edge-case enumeration — you want before any code gets written.

Dillon's quick aside: when you're using the agent to learn something, ask it for sources. It'll mash concepts together, and being able to cross-check against the actual docs catches the seams.