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.

The Case Against Plan Mode

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.

Planning ≠ Plan Mode

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:

The Grill Me Skill

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.

POC-First Development

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.

The Plan / Build Spectrum

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.

Plan Mode Is Still Great for Newcomers

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.

Ask for Sources

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.

Standup / Life Updates

• Dillon spent the week in northwest Arkansas (Fayetteville and Bentonville) for his brother's birthday and a baby shower for his niece, due in June. Bentonville was a surprise — Walmart HQ has turned the area into a brand-new, Apple-campus-tier hub since the company required vendors to relocate post-COVID. Cost of living roughly half of Boston, Onyx Coffee on the ground. He looked at the Walmart careers page.
• Scott completed his eighth powerlifting meet in eight years (with a two-year, two-month injury gap): 597.5 kg total at 82.5 kg bodyweight — 200 squat, 140 bench, 257.5 deadlift. That's a 1,317 lb total. He's 85 kg from the national qualifying total, or he turns 40 first and qualifies on the masters total he's already cleared. Also teasing some open source work he's "boiling down to a usable small chunk" — ETA four or five years per Scott; "what model are you using?" per Dillon.
• Matt has been ping-ponging across his personal tooling: gave up vibe-coding his own note-taking app, gave Notion another try, set up scheduled Claude Code tasks to summarize recent notes, and switched from Arc to Chrome specifically for the Claude Chrome extension and Cowork. Recording from a HubSpot meeting room during an onsite, with bachelor party planning in May wrapping up. And in the loudest beat of the segment: he had the agent build a library blending CRDTs, offline-first, RSC, and server actions — pulling from auto-merge, YJS, and Tanstack Query — and it dutifully reinvented Tanstack Query.

In this episode, Dillon walks Scott and Matt through a personal productivity dashboard he's been building with Claude — and uses it as a jumping-off point for a wider conversation about what AI unlocks for "personal software."

The Daily Briefing Dashboard

Dillon's dashboard started as a joke: use Claude's new cron feature to post a daily inspirational quote at 9 a.m. He quickly realized he could put something genuinely useful there instead. The result is a single page he opens every morning that surfaces:

• To-dos
• Open PRs
• JIRA tickets
• Datadog alerts
• Summaries of recent notes
• A custom Kanban board for tracking dev "harnesses" (scoping → planning → execution → review)

It's intentionally simple under the hood: zero dependencies, a Python server, HTML, and CSS. make start and you're running. He's burning roughly $2,500/mo in Claude tokens building it, has shared it openly with leadership and the broader company, and treats it as a sandbox for trying anything new in AI.

Why Build It Yourself?

Matt frames the bigger thesis: AI is a fast track to personal software — the small niche of building a tool tuned exactly to your own workflow rather than adopting something off the shelf or solving for millions of users. The closest off-the-shelf comparison would be something like Notion or Dream.ai, but neither would match Dillon's specific data sources or the way he wants to see them.

Where AI Surprised Him (Good and Bad)

• Struggles with UI consistency. AI gets the functionality right, but drifts from the design system, makes spacing and layout mistakes, and occasionally tries to "helpfully" refactor onto a totally different stack (e.g. "let's add SQLite") mid-project. Dillon's mitigation: keep it simple, have Claude audit the UI and write its own lightweight design system, and push reminders into CLAUDE.md.
• Matt's tip: expose a route on your app that renders all components on one page (poor man's Storybook) so the agent can discover existing patterns.
• Unexpected win: visual thinking. Dillon's been asking Claude to generate HTML pages with architecture diagrams, user flows, and dependency maps to build a mental model of unfamiliar projects before diving in. Matt does the same to navigate his monorepo's package dependency graph.

Skills Dillon Has Built

• Start of Day / End of Day — a paired skill that asks reflection questions in the evening and gives him a standup-style recap in the morning, including "what's on my radar that I'm not thinking about."
• PR Status / PR Watch — pulls GitHub check status, surfaces comments, and runs every five minutes to send a Mac notification when a PR is ready to merge.
• Mind Dump — partner skill to End of Day that takes a stream of consciousness and organizes it into a structured markdown doc.
• Contentful skills — connect to the CMS API to pull content types, explain how they work, and (experimentally) architect new ones.
• The "Grill Me" skill (borrowed from Matt Pocock) — has Claude slowly ask questions about a plan to surface edge cases and force thinking through the problem.

His meta-tip: every time you use a skill, reflect on how it did and ask Claude to improve it.

The Productivity Paradox

Has it actually made him more productive? Yes — but the new problem is spreading too thin. Dillon shipped 14 PRs in a week and now has 20 open ones he can't get back to. As Matt jokes: "the trick is to go faster." The real discipline is cleaning up after yourself, slowing down, and focusing on one thing at a time, even when you have 12 work trees open.

Caveats and Takeaways

• This is personal software — running locally, no deploy target, code quality is intentionally rough. Not how Dillon does actual work.
• A lot of devs at his company are afraid to build things outside their tickets. Dillon's been transparent with leadership and turned it into a shared resource instead.
• If you want to start: literally talk to Claude (or sketch a screenshot) about what you'd want to see every morning, and go from there.

Teasers

Future episode ideas raised: how to get good UI out of agents, and using AI to onboard yourself onto an unfamiliar codebase. Scott also hints he has a "pretty good solution" for the UI consistency problem — saving that for another episode.

Matt, Scott, and Dillon unpack one of the messiest open source dramas of the moment: Matteo Collina — Node TSC member and Fastify creator — dropped a ~19,000-line PR on Node.js core over Christmas break, openly built with the help of Claude Code. The PR adds long-requested virtual file system support, intercepting 164+ points across fs, fs/promises, and the module loading system. Over half the diff is tests, which is part of why it raised eyebrows in the first place — that volume of integration tests is something a human contributor likely wouldn't have written by hand.

The DCO question

The crew dig into the Developer's Certificate of Origin (DCO) and whether agent-generated code cleanly satisfies it. Does Claude-written code count as "authored by you"? It's still a foggy question, and one contributor was rattled enough to start a petition to ban AI-generated code from Node.js core. Matteo's response: I made all the decisions, I fixed the AI's mistakes, it's still my code.

Process, not just AI

Scott's take is that the size and abruptness are doing as much damage as the AI angle. There were existing issues discussing a VFS, but no RFC, no upfront tech plan, and the commit history is borderline unreviewable. Classic "easier to ask forgiveness than permission" energy — but on a change that touches a major surface of the runtime. The crew sympathize with the engineer's instinct to just ship the thing, but agree that a feature this big needed buy-in first. (Scott would have left a nit: comment asking for a rebase to a single commit.)

How do you even police this?

Dillon raises the obvious enforcement problem: AI detection tools have the same false-positive issues that plague universities. A one-line bug fix is indistinguishable from a human's. That points toward either accepting AI-assisted contributions outright or building entirely new governance — which is roughly where the broader OSS community seems to be landing (the related issue was reportedly closed with consensus that AI-assisted dev is allowed).

What if Node says no?

Matt poses the strategic question: if Node.js bans AI contributions, does that hand momentum to Bun and Deno? Bun is already leaning hard into Claude-assisted development, ships features fast (native SQLite being the canonical example), and operates as a company rather than a committee — so it has structural advantages on velocity and backwards-compat tradeoffs. Scott pushes back that big corporations are slow to migrate runtimes regardless, but Matt counters that agents dramatically lower switching costs — point Claude at your codebase and say "migrate this from Node to Bun" and it's plausibly a weekend.

Slopforks and the SQLite playbook

The conversation widens to Cloudflare's "vinext" — a Vite-based Next.js reimplementation built by pointing an agent at Next's test suite, which popularized the term slopfork. That sparked talk of TLDraw considering closing their test suite to prevent agent-driven reimplementation, and the long-standing SQLite model where the code is open source but the comprehensive test suite is paid/closed. Expect more projects to consider that pattern as agents make test-suite-driven reimplementation trivially cheap.

Closing takes

• Open source projects may need to lean into AI just to stay competitive with company-backed runtimes.
• The irony: another Node contributor used Claude to write a deep-dive review of the PR itself.
• Matteo also published a userland polyfill on npm, hedging against Node's slow merge process.
• Scott's verdict: merge it already.

Plus a brief detour on the iojs fork of yore, and Matt's proposed name for the inevitable Node slopfork: input-output.js.

Matt and Scott both recently shipped PRs and got reviewer feedback that didn't match what they thought the team had agreed on — either asking for far more scope than intended, or pushing back on an incremental approach in favor of the "ideal" final solution.

Scope Creep In Review

The classic example: you make one focused change in an old codebase, and a reviewer points to an unrelated eslint-disable comment five lines above your diff and asks you to "fix it properly." Suddenly your tight PR is fighting a battle you didn't sign up for.

Incremental vs. Ideal

Scott frames the core tension: most of the team agrees with incremental PRs in principle, but in practice a reviewer can blindside you by insisting the PR get all the way to the ideal end-state. The skill is selling the increment — showing the path from "value shipped today" to "ideal solution later" so reviewers buy into the staging, not just the destination.

Scott's concrete example: he was building end-to-end smoke tests where the ideal version was blocked by another team. He had to plead his case, point to follow-up tickets, and frame the smoke tests as immediate value on the way to the real thing.

Trust, Teams, and Context

Dillon notes he doesn't hit this much — his team has jelled, they tell each other up front "you're not going to like this, let's talk in person." Scott contrasts that with newer teams or strong-opinioned teammates where trust hasn't been built and standups go in one ear, out the other.

Plans as the Through-Line

The group converges on communicate, communicate, communicate. Matt argues for creating a clear through-line — an issue or doc that breaks the work into steps so a reviewer landing on PR #3 can click back to the plan. It doesn't have to be a senior-staff-signoff design doc; even a one-pager or a markdown plan from Claude counts. Matt also pitches "shift left" on reviews: get eyes on the plan before the PR, not at PR time.

Dillon introduces the PRD framing — product requirements doc owned by PMs, separate from an engineering design doc. When you don't have a dedicated PM, you have to own that artifact yourself, and teams sometimes forget.

Nitpicks and Code Review Culture

Matt's open question: how do you stop blocking nitpick comments from dominating? Scott's stance is firm — nitpicks should not block PRs. Unless there's a real architectural problem or a literal bug, call it out, approve anyway, and let the author decide whether to address it now or as a follow-up. Code review is a two-way conversation, not a one-way directive, regardless of seniority.

Dillon's tactics: mark nitpicks as out-of-scope with a follow-up ticket, or just take the conversation to Slack/in-person to break through faster than async GitHub threads.

A frustrating wrinkle Matt raises: their SOX-required approval process dismisses approvals on any new push, so even fixing a non-blocking comment forces a re-review cycle — actively discouraging the fast-follow behavior everyone says they want.

The underlying message: assume good intent, trust your fellow engineers, and recognize that increasingly you may be reviewing a Claude-generated PR anyway.

Stand-Up

• Dillon: Witnessed comedic whiplash at work — one presenter said "turn on bypass permissions and use Opus for everything," and an engineering leader said the exact opposite an hour later. Has been vibe-coding a personal dashboard with Opus and burned $300 in four hours, leading him to discover "token anxiety." Can't even relax on the couch wondering if the agent is deleting his computer.
• Scott: Powerlifting meet next Sunday, body hurts. Saw Project Hail Mary, loved it, then proceeded to spoil it on-mic.
• Matt: Going to see Project Hail Mary tonight (thanks Scott). Otherwise enjoying being back in the metaphorical (and literal) booth.

Matt, Scott, and Dillon try to make sense of one of the fastest-moving stories in agentic AI: the project that started as ClawdBot, briefly became MoldBot for about three hours, and now goes by OpenClaw — at least until the next rebrand.

What even is OpenClaw?

The crew sets the stage for Dillon (and any listener who's been blissfully out of the loop). OpenClaw is an always-on, multi-agent autonomy platform — think "proto-Jarvis" or "Siri but 100x." You hand it your calendar, email, Slack, messaging apps, and home automation, and it goes off and does the menial digital work for you. Matt notes its GitHub star growth has outpaced essentially every project ever, though the guys speculate how much of that is real humans vs. agents spinning up GitHub accounts and starring the repo themselves.

The marketplace malware scandal

Scott opens the episode with the bombshell: the #1 most-downloaded skill in the OpenClaw marketplace was malware — stealing SSH keys, crypto wallets, and browser cookies, and opening a reverse shell to the attacker's server. 1,184 malicious skills were found in total, with one attacker responsible for 677 packages. The conversation turns to the obvious tension: the more credentials and access you give an always-on agent, the more catastrophic a supply-chain attack on its plugin ecosystem becomes.

The rebrand carousel and the drama

The hosts walk through the dizzying pace of changes — naming, ownership questions, and the broader "is this a scam?" vibes swirling around the project. Matt points out the loop is so tight that anything they say will probably be outdated by the time the episode drops.

Anthropic pulls the plug on subscription billing

A big thread: Matt wanted to run his own OpenClaw agent but is held back because he can't point it at his Claude subscription anymore. The crew theorizes why — consumer subscriptions are almost certainly loss-leaders for the model providers, while per-token API billing is where the margin lives. Shutting subscription access off for agents that burn tokens 24/7 is basically self-defense.

Tokens, tokens, tokens

Dillon makes the point that the model companies probably love OpenClaw in principle: it's a perfect machine for getting customers to burn tokens faster. He also shares that he recently got a gentle slap on the wrist at work for always reaching for the most expensive model. Scott admits he never swaps models either. The guys riff on the dystopia of paying big AI companies to build agents that do work for other big companies — while no one's handing us the robot.

Wrapping up

They close with predictions that the ClawdBot/OpenClaw competition between model providers will keep producing new shiny things until someone gets acquired — and a half-joking suggestion that listeners should one-shot a startup idea on Saturday afternoon and become billionaires by Monday.

This week the crew flips the script on their usual AI conversations and gets honest about what AI adoption actually looks like inside larger tech orgs — not the Twitter highlight reel.

The Dax Tweet That Started It All

Matt kicks things off with a tweet from Dax (of OpenCode / formerly SST) arguing that companies are talking about their teams as if they were operating at peak efficiency and merely bottlenecked by typing speed.

everyone's talking about their teams like they were at the peak of efficiency and bottlenecked by ability to produce code here's what things actually look like

• your org rarely has good ideas. ideas being expensive to implement was actually helping
• majority of workers have no reason to be super motivated, they want to do their 9-5 and get back to their life
• they're not using AI to be 10x more effective they're using it to churn out their tasks with less energy spend
• the 2 people on your team that actually tried are now flattened by the slop code everyone is producing, they will quit soon
• even when you produce work faster you're still bottlenecked by bureaucracy and the dozen other realities of shipping something real
• your CFO is like what do you mean each engineer now costs $2000 extra per month in LLM bills

The reality Dax describes:

• Most orgs don't have that many good ideas — and ideas being expensive to implement was actually acting as a useful filter
• Most workers aren't trying to be 10x; they're using AI to finish their tasks with less effort and clock out
• The two people on the team who genuinely cared are now drowning in everyone else's slop code and are about to quit
• Even when code ships faster, bureaucracy is still the real bottleneck
• And the CFO is staring at a mysterious new $2,000/month/engineer line item

Matt admits a lot of this hits uncomfortably close to home at HubSpot.

The Cost Conversation

Dillon shares a stat from a recent all-hands at his company: ~$500K/year in AI spend across roughly 200 engineers. It didn't sound like much in the room, but the more he sits with it, the weirder it feels — especially since leadership seems totally fine with it. The crew riffs on the bizarre new world where engineers may soon need to negotiate not just salary but a personal AI token budget as part of their comp package.

Dillon makes a confession: he's mostly using AI because it's free and he's being asked to. If the company pulled the plug tomorrow, he'd happily go back to free models and probably be fine.

Is AI Just a Fancy Search Engine?

Dillon drops the spicy take of the episode: AI right now is basically a really fancy search engine that copies and pastes code for you — it's just stealing the internet's content and wrapping it in a bow. Scott mostly agrees, framing it as a streamlined command-line search that returns blurbs instead of links.

Matt pushes back. Tab completion? Sure, that framing fits. But agents like Claude Code in plan mode are doing something more — decomposing problems into small enough sub-problems that the "search engine" framing starts to break down. Scott concedes that plan mode and the conversational back-and-forth ("give me three ways to solve this and tell me which is strongest") is genuinely valuable in a way no search engine can replicate.

The Slop Code Problem

The conversation lands on the real cost of all this: engineers shipping Claude's output without understanding it, leaving in the "I did a thing" comments, and quietly building up tech debt that the few engineers who still care will eventually have to clean up. Scott talks about his own discipline of never shipping code he doesn't understand well enough to defend in a sev review.

Life Updates

• Scott is ramping up on a new product with tight deadlines, played tennis Saturday, went skiing recently, has a San Francisco / Lake Tahoe ski trip coming up in March, and is competing in a powerlifting meet at the end of March.
• Matt landed an Rspack contribution (with Claude's help) — interesting note that Rspack is maintained by ByteDance, so review cycles run on roughly a one-day lag with reviewers in China. He also hosted a Super Bowl party.
• Dillon got second place in commercial bingo at the Super Bowl party, which was reportedly more fun than the actual game.

The Hot Take Corner

The Super Bowl MVP was wrong. It should've been the kicker — who, per Dillon and Matt, basically kept his team in the game. This unlocks some deep lore: Dillon himself was a kicker in high school. Suddenly his entire personality makes sense.

In this episode of The Bikeshed Podcast, Dillon, Scott, and Matt tackle a topic that's been top of mind for Matt lately: how do you maintain high code quality standards when AI agents are writing most of your code? Matt opens up about falling into what he calls a "slop pit" — the habit of throwing a prompt over the wall, getting back code that technically works, and moving on without scrutinizing it. The hosts explore whether this problem is worse in large codebases versus small side projects, with Scott noting that AI tends to bolt solutions on top of existing code rather than elegantly integrating with established patterns, especially in bigger repos. Matt argues it happens everywhere, though codebase size may be a contributing factor.

The conversation zeroes in on two key practices: planning and review. Dillon shares that he spends 10–15 minutes planning before letting AI write any code, and has been experimenting with Anthropic's "feature dev" skill that does extensive codebase exploration before generating a plan. Scott reveals his workflow of using Claude's plan mode, keeping a dedicated tab open on the generated plan file, and manually editing or conversing with the model to refine it. All three agree on a critical pitfall: having the AI generate a plan and then rubber-stamping it without actually reading and comprehending it defeats the purpose entirely.

On the review side, Matt describes a multi-layered approach — spinning up a second agent to review code locally, then using HubSpot's internal AI tool Sidekick for PR-level code review before opening it up for human review. Scott has been experimenting with a Claude code review skill that pulls recent PR history to understand review patterns. Dillon prefers reviewing on GitHub because it puts him in the right mindset, and isn't afraid of messy draft PRs with self-comments.

Testing gets significant airtime, with the hosts discussing TDD-inspired approaches to AI development — writing failing tests first and then having the agent implement against them. Dillon shares a revealing story about his team burning tokens to get test coverage from 8% to 50–60%, only to realize that increased test coverage alone doesn't equal confidence when the underlying code is messy. The hosts also discuss the value of linting, TypeScript strictness, and other automated guardrails in keeping AI-generated code on track, while acknowledging that pattern consistency remains a largely unsolved problem even with human contributors.

The episode touches on model differences, with Matt noting that GPT models tend to follow instructions more strictly while Claude sometimes takes liberties (reaching for as any or disabling ESLint rules). Scott and Dillon weigh in on the broader question of whether code quality still matters in an AI-first world, with Scott arguing that companies going all-in on AI without maintaining engineering standards will eventually hit painful bugs that are hard to solve even with AI assistance.

Standup:

In the standup segment, Scott shares his experience switching to rebasing (great for small branches, nightmarish for stacked PRs), plans to try Graphite and LazyGit, and mentions an upcoming skiing trip and a minor adductor pull ahead of a powerlifting meet. Dillon talks about having AI handle more of his Git workflow, pitching infrastructure improvements like batch endpoints for Cloudflare Workers, and shouts out 4A Coffee from Newton, MA. Matt recounts causing a repeat incident at HubSpot that broke front-end build testing, his remediation work on the offending service, and his experiments with OpenCode as a Claude Code alternative and Git worktrees for managing multiple branches.

The hosts kick off by diving into their 2026 predictions, rating each on both a likelihood scale (1–10) and a Taco Bell-inspired "spice-o-meter" ranging from mayo to Diablo.

Dillon's first prediction is that autonomous coding agents will enable single-prompt-to-deploy workflows, potentially eliminating the need for engineers on product teams. Scott pushes back, arguing that companies still need engineers who think through problems, and that the "enshittification" of lazy AI usage will backfire. The group rates it a "fire" take with moderate likelihood (5–7 out of 10). The discussion touches on MCPs, agent orchestration tools like Gastown (where AI agents manage other agents in a wild hierarchy of mayors, soldiers, and competing towns), and the rapid pace of AI tooling turnover.

Scott's first prediction is that using AI during engineering interviews will become the norm in 2026. He argues it's absurd that companies force engineers to use AI daily but ban it during interviews. Dillon confirms his company already allows it but notes their interview questions aren't designed for AI-assisted solving. Matt gives it a 9/10 likelihood but rates the spiciness as a lukewarm "verde" — it just feels inevitable.

Matt's first prediction is that companies will start scaling back their AI budgets, consolidating overlapping subscriptions (Claude, Cursor, GitHub Copilot, ChatGPT) rather than paying for everything. Dillon disagrees strongly, citing his company's continued heavy investment and the launch of an "AI Coalition of Massachusetts." Scott sees it as a double-edged sword — big tech will keep spending while smaller companies pull back.

Dillon's second prediction takes a personal turn: one of the three hosts will get a new job, and one will get laid off in 2026 (possibly the same person). Scott reveals he had the same prediction written down. Matt rates it 8/10 likely and gives it a "Diablo" spice rating, while Scott gives it only a 3/10 despite calling it a fire take.

Scott's second prediction goes big: the AI bubble will burst entirely in 2026. Matt thinks it's only 2/10 likely, suggesting the government would intervene before a full collapse given how foundational AI has become to the economy. Dillon gives it a Diablo spice rating but agrees it's unlikely.

Matt's second prediction is that a majority of social media content (over 50%) will be AI-generated or AI-enhanced. Scott and Dillon essentially agree it's already happening. This sparks a tangential discussion about the rise of niche, authentic social platforms like Retro (a weekly photo-sharing app) and Strava, as the hosts lament the state of mainstream social media.

In the speed round, Scott predicts Python will become the top-paid programming language due to machine learning demand (Matt counters that TypeScript might actually replace Python for ML work). Scott also predicts at least one episode this year won't mention AI, and Matt predicts they'll stop referencing their former employer so frequently.

Standup:

During standup, Scott shares that he canceled his Claude Max subscription because he couldn't justify the cost for personal use, though he still uses it heavily at work. He describes a hybrid approach to AI-assisted coding — using Claude for boring tasks like test generation while personally learning the codebase. Dillon has been exploring Claude skills and MCP servers at work, including Context7 for documentation and the Figma integration, though he got called out for pushing AI-generated code without reviewing it. Matt admits his side project is now "a big pile of slop" after thousands of lines of unreviewed AI-generated code, and is reconsidering how to apply better rigor to AI-assisted development. He's also been honeymoon planning, though some destinations may be on the no-travel list.

In this episode of Retro and React, Scott and Matt dive into two significant developments in the tech industry: Anthropic's recent policy changes around third-party agent harnesses and the layoffs at Tailwind Labs.

Anthropic's Crackdown on Third-Party Tools

• Anthropic recently prohibited the use of open-source/third-party agent harnesses (like Claude Code, OpenCode, Clawdbot, and Pi) with Claude Pro and Max subscriptions
• These tools were previously spoofing headers and using system prompts to bypass Anthropic's restrictions and leverage subscription-based access
• Users must now pay for API billing (per-token pricing) instead of using monthly subscriptions to access these third-party tools
• The move reflects Anthropic's strategic pivot: they've recognized the model itself isn't the differentiator—it's the suite of tools and integrations built on top
• Anthropic appears to be focusing on creating "stickiness" by getting users ingrained in their ecosystem of tools rather than competing purely on model performance
• The subscriptions may be loss-leaders compared to API billing, with enterprise contracts potentially being more profitable

The Broader Strategic Shift

• Before Opus 4.5, Claude models weren't differentiated enough to create vendor lock-in
• Users could easily switch to competitors like GPT-5.2 for similar or better results
• Anthropic's value proposition has shifted to emphasize deep integrations, superior tool-calling capabilities, and their full software suite
• This mirrors classic tech company strategies of building multiple products to keep customers in one ecosystem

Tailwind's Layoffs and the AI Disruption

• Tailwind Labs recently laid off most of their staff
• The component library/design system business—Tailwind's primary monetization strategy—has become increasingly commoditized
• AI tools can now generate the same components and templates that Tailwind was selling in minutes
• Competitors like shadCN and AI-generated solutions have made it difficult to differentiate
• Tailwind finds itself "stuck between a rock and a hard place": trying to monetize an open-source product while competing against AI tools that can replicate their paid offerings for pennies on the dollar

The Open Source Monetization Challenge

• Monetizing open-source products remains extremely difficult
• The bifurcation strategy (free open-source + paid premium) struggles when AI can replicate the premium features
• Tailwind's success as an open-source tool may have contributed to their monetization challenges—being "too good" and widely adopted meant AI could easily learn to replicate their patterns
• The hosts note this is a "victim of its own success" scenario

Scott, Dillon, and Matt kick off 2026 with a deep dive into the joys (and pains) of performance review season. The conversation starts with everyone's approach to using AI—specifically Claude—to help write self-reviews. Scott shares how an MCP server at work generated his entire review in about 15 minutes, while Dillon notes his company explicitly encourages using AI for reviews. Matt discusses using Claude to scan his Obsidian notes from the past year and create a summary of accomplishments.

The hosts explore best practices for structuring reviews:

• Focus on 3-4 high-impact accomplishments and tell a story about why they matter
• Keep it concise—like a resume, not an essay—so managers can actually read it
• Include links to artifacts (PRs, docs, Looms, Slack posts) to add credibility
• Align your wins with level expectations, especially if pursuing promotion

The conversation shifts to team dynamics and the challenge of "fighting for work" on teams full of senior engineers all competing for growth opportunities. Matt shares frustrations about ideas getting shot down or handed off to others, while Scott contrasts this with his current team's collaborative, trust-based approach using DRIs (Directly Responsible Individuals). Dillon offers the counterpoint that at smaller companies, you can often just do the work without asking permission—though that comes with less oversight.

A frank discussion emerges about the "senior engineer trap"—where engineers mistakenly believe seniority means stepping away from code to whiteboard and write RFCs all day. Matt admits to being a "recovering senior" who fell into this pattern, noting that company competencies can inadvertently push people toward over-architecting instead of shipping.

The hosts share their takes on career development:

• Maintain a personal "wins doc" framed around your own goals, not just company expectations
• Periodically ask yourself: "How hireable am I based on the last six months?"
• Titles mean different things at different companies—focus on the actual work and responsibility

In standup updates, Scott discusses his goal of becoming more of a minimalist and whether to keep his Claude Max subscription ($100/month) after barely using 8% of it. He also wants to write more blog posts—a gap he identified for reaching staff level. Dillon's resolutions are refreshingly simple: consistency at work, consistency in fitness, and seeing more extended family. He also "retired" from Arc Raiders right as Matt and Scott got into it.

Matt mentions getting a new mic (two, actually—one from Scott, one from Katie), and his resolution to connect more with engineers at HubSpot and former colleagues. The episode wraps with a tease about covering Tailwind drama in a future React and Retro episode, and Dillon's request for a segment called "Matt and Scott tell Dillon the news."

React's Critical Vulnerability

The hosts dive into the details of React's newly disclosed security flaw affecting React Server Components—a severity 10 vulnerability that could potentially allow arbitrary code execution on servers. While major infrastructure providers like Cloudflare, Vercel, Railway, Netlify, and Deno Deploy quickly patched the issue at the firewall level, the team discusses the concerning lack of early disclosure to smaller framework maintainers. Matt notes that while Next.js (essentially "the React team at this point") was keyed in early, frameworks like Waku were left in the dark until the public announcement.

The conversation touches on the complexity of versioning in the Next.js ecosystem, the challenges of upgrading legacy applications, and what this means for the broader adoption of React Server Components. Scott sees a silver lining: it might slow down the pressure to adopt RSCs at work. The team debates whether this opens the door for alternative frameworks like Remix (coming April 2026... or maybe March 2030?) or TanStack Start to gain ground.

Anthropic Acquires Bun

The second half explores Anthropic's acquisition of the fast JavaScript runtime Bun—a move nobody had on their 2025 bingo card. The hosts unpack what this means for the JavaScript ecosystem, noting that Claude Code already heavily uses Bun for both its CLI and runtime execution.

Scott calls it a "big win for JavaScript," highlighting that Anthropic is keeping the entire Bun team and expanding it rather than absorbing and dismantling. The discussion explores whether this reflects a broader industry trend of AI companies investing in language runtimes, with OpenAI's Codex being rewritten in Rust while Anthropic goes all-in on Bun (which is written in Zig).

The team contemplates how this positions Anthropic as the "developer's tool" company versus OpenAI's consumer focus, and whether we might see similar acquisitions in the space—perhaps OpenAI buying Deno? They discuss concerns about whether Bun's development priorities will shift to serve only Anthropic's needs versus the broader open-source community.

Quick Hits

• Dillon reveals he's now using Claude Code (after getting free access, of course)
• The age-based bowling tournament at work where experience crushed youth
• Scott's excitement about building "the best permissions table of all time"
• Matt's upcoming European Christmas market adventure
• The digital advent calendar built with Claude's help

A fast-paced, timely episode that captures the chaos and excitement of a transformative week in the JavaScript world.

The conversation kicks off with each host sharing their company's approach to AI code review tooling. Dillon reveals that Whoop is piloting three different tools simultaneously—Greptile, GitHub Copilot, and CodeRabbit—leaving engineers unsure which bot will show up in their PRs on any given day. Matt explains HubSpot's dual approach with "Sidekick" (their internal AI agent for chat and code review) alongside "Sparrow," a non-AI bot that auto-approves low-risk changes like markdown updates. Scott shares that Airbnb uses Claude for PR reviews, finding it catches genuine bugs but sometimes pushes for overly defensive code patterns.

The Big Debate: Should AI Be Allowed to Approve PRs?

The hosts wrestle with a central tension: should AI be allowed to actually approve PRs? Matt argues for empowering teams to move fast by letting AI stamp changes, while Scott and Dillon pump the brakes—noting that speed and stability exist in a delicate balance. HubSpot learned this lesson the hard way when engineers discovered they could prompt Sidekick to both write a PR and approve it, shipping code without any human review. That loophole was quickly closed.

AI as a "Smarter Linter"

The discussion evolves into broader questions about the value proposition of AI code review. Dillon frames it as "a smarter linting step that can sometimes lint for control flow being correct." Matt highlights how AI reviewers can internalize architectural patterns that would be tedious to encode as traditional lint rules. But both acknowledge the tools aren't quite at human-reviewer parity yet.

The Rise of Multi-Agent Review: Red-Teaming Your Own Code

A key insight emerges around using multiple AI instances to catch more bugs. Matt describes his workflow of having one Claude instance write code, then spinning up a fresh instance to review those changes—a form of "red-teaming" that catches logical errors the original agent missed. Scott notes this mirrors the broader trend of orchestrating multiple specialized agents, each with fresh context and different objectives.

AI Fatigue and the Fear of Over-Reliance

A fascinating thread emerges around AI fatigue—the creeping exhaustion from constant AI discourse and the concern that engineers are becoming over-reliant on these tools. Dillon worries that AI is making developers lazy: "We're getting so reliant on it that it's just making us dumber." Scott counters that the human role is shifting from implementation to orchestration, managing AI at a higher level while the bots handle smaller tasks.

Measuring Success: How Do You Know AI Is Actually Helping?

The hosts explore how companies measure AI tool success. Survey-based NPS scores? Tracking Claude's signatures in commit histories? Using "evals" (evaluations) to benchmark agent performance against known solutions? HubSpot repurposed their annual hackathon framework as an eval system—a clever approach that validates AI against real-world internal problems. Dillon raises the uncomfortable question: are we all just on the hype train without truly validating the benefits?

The Productivity Paradox: More Output, But Is It Better?

Scott surfaces an important counterpoint to productivity gains: "Yeah, it's 30% more productivity, but how much of it is actually better?" The hosts reflect on previous episodes where they've discussed the web getting worse—noting that shipping more PRs doesn't necessarily mean shipping better software. AI-generated code can become unwieldy, creating "band-aids on top of band-aids" that are harder to maintain.

Matt's Claude Code Credit Binge

Matt shares his enthusiasm for Anthropic's recent free credit promotion, noting he's burned through $120 of his $250 credit in a week while shipping 20+ PRs for personal projects. His hot take: AI has rekindled his passion for coding outside of work, turning feature implementation into a dopamine-fueled productivity loop. He's been throwing "ultrathink" on every prompt and barely making a dent—and yes, he built himself a custom to-do app instead of paying for Todoist.

Standup Updates

The episode wraps with standup updates: Scott's building visual diff tooling for UI workflows (ironically, a human review tool after an hour of AI review discussion). Dillon's improving observability with Cloudflare Workers traces and discovered the hard way that workers have a 6-connection limit—which their 14 feature flag requests were absolutely destroying. Matt's abandoned Parcel's RSC setup in favor of Vite's built-in plugin and is evangelizing wired headphones for speech-to-text dictation with Handy.

What Even Is a "Clanker"?

Oh, and the hosts debate whether calling AI agents "clankers" is appropriate—it's apparently a speculative slur for robots in a future where they're subhuman. Matt's been using it to keep the machines in their place before the uprising. Scott refuses to insult AI, treating them as equals. Choose your side wisely.

Key Takeaways:

• AI code review is best viewed as an enhanced linting layer, not a replacement for human reviewers
• Multiple AI instances reviewing each other's work can catch bugs that single agents miss
• Companies are still figuring out how to measure the ROI of AI development tools
• The engineering role is shifting toward orchestration and architecture as AI handles lower-level tasks
• Speed vs. stability remains the fundamental tradeoff, regardless of whether AI or humans are in the loop

In this episode, Matt kicks things off with a provocative thesis: internal tooling usually sucks. What follows is a deep, nuanced exploration of one of software engineering's most persistent challenges—the build versus buy decision that every company eventually faces.

The Two Types of Internal Tools

The hosts identify two distinct categories of internal tooling:

• Wrappers: Tools that extend existing external solutions (like a custom UI for managing GitHub repository settings)
• Replacements: Complete alternatives to industry-standard tools (like building your own NPM/Yarn/PNPM equivalent)

Through examples from HubSpot, Airbnb, and Whoop, they dissect when each approach makes sense and when it becomes a costly mistake.

The Hidden Costs Nobody Talks About

Scott breaks down the real expenses of internal tooling that go beyond initial development:

• Knowledge transfer when the original creator leaves the company
• Onboarding friction for new engineers who must learn proprietary systems
• Maintenance burden that never ends and always competes with customer-facing priorities
• Documentation debt that compounds over time
• The bus factor when only one person truly understands the tool

Matt shares his perspective that internal tools will always be secondary to a company's core business, making it nearly impossible to invest appropriately in their long-term health. Even with dedicated developer tooling teams, these tools rarely get the polish and support they need.

When Internal Tooling Actually Makes Sense

Despite the skepticism, the crew identifies legitimate scenarios for building internally:

When no external solution exists for your specific problem (and they mean truly doesn't exist) When you have subject matter experts who can build something better and maintain it When wrapping an external tool with company-specific context adds significant value When security or data sensitivity requirements make external tools impractical

They discuss examples like FlowBuilder at Airbnb and Easy Deploy at Whoop, exploring what makes these tools successful versus the cautionary tales of failed projects.

The External Tooling Counterargument

Dillon delivers his first genuinely spicy take of the podcast: external tooling has its own serious problems. Tools can be abandoned by maintainers, new versions can become impossible to migrate to, and companies can pivot their features in ways that don't align with your needs. His critique of Next.js and Vercel's approach generates the kind of heat the hosts have been asking him to bring.

Real War Stories

The episode is packed with concrete examples:

• HubSpot's custom dependency manager that replaces NPM entirely
• Wayfair's Tungsten framework (a React alternative that created years of technical debt)
• A year-long interior design app project that got canceled after launch
• The Jambox testing tool that could have worked with proper buy-in
• The painful reality of forking open source tools and maintaining them forever

The "It Depends" Framework

By the end, the hosts converge on a practical framework for making these decisions:

Questions to ask before building:

• What percentage of your use case does the external tool solve? (If it's 90%+, probably don't build)
• How foundational is this to your engineering system?
• What's the true cost including maintenance, not just initial development?
• Can the tool be replaced in days, weeks, or months if needed?
• Do you have the organizational buy-in and resources to support it long-term?
• Are you building to avoid a 10% gap or because nothing exists?

The general principle: Don't build internal tools that replicate 90% of what external tools already do. The remaining 10% is rarely worth the lifetime cost of ownership.

Personal Updates & Tangents

The standup section includes home renovation updates (mini splits and solar panels), Scott's Rhode Island trip plans, Dillon's Web Guild leadership experience at Whoop (described as "group therapy for front-end engineers"), and Matt's build performance optimization work that might actually be making things slower.

Whether you're an engineering leader making tooling decisions or a developer maintaining legacy internal systems, this episode offers hard-won wisdom about the real tradeoffs in the build-versus-buy debate. Sometimes the answer is "build," but more often than not, it's "please don't."

The hosts spend considerable time discussing coffee preferences and brewing methods. They critique Dunkin' Donuts coffee quality, with the consensus being it's subpar without heavy sugar additions. Matt shares his experiences with different brewing methods including espresso machines, palm press, and Chemex. Scott provides an enthusiastic review of his new Breville espresso machine, explaining the learning curve around grind settings and shot preparation. The group agrees that smaller coffee shops generally have better quality beans than chain establishments.

Cursor 2.0 Release

The team discusses Cursor's major update, which repositions it as an "AI-first" coding experience rather than just VS Code with AI features. Key changes include:

• UI redesign with chat moved to the left sidebar
• New "composer" model trained specifically for editor integration
• Support for running multiple AI models simultaneously
• Built-in Git worktree support for parallel development

Matt notes mixed results with the new composer model, finding it sometimes lazy about fixing unrelated test failures.

AI Development Tools

The hosts share their experiences with various AI coding assistants:

• Claude Code: Matt's primary tool, though he's hitting token limits frequently
• Planning Mode: Scott advocates strongly for using planning mode to get better results by having conversations about approaches before implementation
• Ultrathink: The group discusses using extended reasoning modes, with Scott recommending it for complex problems

They debate the cost implications of AI tools, with Dillon suggesting some features are "easy ways to waste money."

Git Worktrees

Scott explains his experimentation with Git worktrees as a way to work on multiple branches simultaneously. The consensus is that while worktrees are useful for quick context switching (like handling urgent hotfixes mid-feature), simply cloning the repository multiple times may be simpler for many developers.

AI in Interviews

The hosts touch on how companies are handling AI usage during technical interviews. Matt notes his company measures "AI fluency" in behavioral questions but doesn't allow AI use during coding sessions, creating an interesting contradiction.

Standup Updates

• Dillon is taking time off to play Arc Raiders, a new extraction shooter game
• Matt is working on wedding planning and a side project CMS, and also prepping for a work presentation
• Scott dealt with a flat tire and is preparing for Halloween trick-or-treaters

• Overview: The hosts discuss the recent Remix Jam conference and the unveiled Remix 3 framework, which aims to simplify web development. Remix 3 is centered around event handling and components with a different approach to React.
• Key Concepts:
  • Event Handling: A core focus is on managing DOM events and using events to manage state.
  • Components: Aims to reduce complexity compared to React's functional components, potentially eliminating the need for hooks.
  • Frames: A replacement for suspense that they called frames
• Concerns:
  • The framework is still pre-alpha, and APIs are subject to change.
  • Potential difficulties in migrating existing React codebases to Remix 3.
  • Reliance on AI-generated code for core abstractions raises trust concerns.
• Potential Benefits:
  • A simpler programming model compared to React.
  • Better control over data loading and state management.
  • The built-in CSS-in-JS solution.
• Future of React: Remix 3 may signify a shift in the React ecosystem, as developers explore alternative approaches to web development.
• AI in Development: A discussion about the use of AI in building the framework and the importance of reviewing AI-generated code.

Scott's Style Corner: Handling Null/Undefined Values in UI

• Topic: Scott discusses UX suggestions for representing null or undefined values in UIs.
• Key Point: Avoid directly displaying "null" or "undefined." Instead, use descriptive names that provide clarity for the user (e.g., "Not Reviewed" instead of "Empty").
• Importance: This improves UX by preventing confusion and making it easier for users to understand the information presented.

Stand-up Updates:

• Scott: Got married, honeymooned in Iceland, and is nearing completion of a large feature that was delayed due to a migration project.
• Matt: Investigating a memory leak in rspack and listening to the album "Heavy Metal" by Cameron Winter.
• Dillon: Has been working out consistently, building a reverse proxy for splitting traffic for a Next.js replatform project.

This episode of the Bikeshed Podcast dives into the question of whether the current state and future of the web are in jeopardy, primarily due to the rise of AI and its impact on content creation, consumption, and monetization. The discussion revolves around the tension between human-centric web experiences and the increasing dominance of AI-driven content aggregation and delivery.

Key Discussion Points

• The AI Crawler Problem: The podcast starts by highlighting the increasing use of systems like Anubis to prevent AI from crawling websites, which negatively impacts the user experience for humans. This leads to the broader question of whether an alternative to the web is needed.
• Monetization and Ads: The hosts discuss how AI crawlers bypass ads, which are the primary source of revenue for many websites. This raises concerns about the sustainability of content creation in an AI-dominated environment. The group floats the idea of the de facto standard to make money from ads being changed to paywalls.
• Death of the Browser? The episode explores the idea that AI could lead to the "death of the browser" as users increasingly rely on AI chatbots for information, potentially diminishing the need for traditional web browsing experiences.
• Transitory Period: There's a debate about how quickly these changes will occur, with some hosts suggesting a more gradual transition, while others anticipate rapid evolution. There's a strong suggestion of the web going through a "transitory" period.
• Forking the Web: The podcast considers the possibility of a "hard fork" of the web, separating bot-friendly and anti-bot content, but acknowledges the challenges in enforcing such a split.
• RSS Feeds and Centralized Listings: The discussion touches on potential solutions, such as incentivizing content creators to add their feeds to centralized listings that AI can't easily crawl.
• Pre-Existing Problems: The hosts acknowledge that the web was already facing issues with homogenization of design and UX patterns, gamification of content, and the dominance of large platforms.
• Legal and Ethical Concerns: The podcast raises ethical questions about AI companies scraping content without express consent and potentially harming content creators.
• AI as a Middleman: AI is described as a "middleman" that extracts value from content creators while benefiting consumers, similar to the dynamic observed with platforms like Spotify.

Key Discussion Points:

• Organizational Velocity: The concept of organizational velocity is introduced, emphasizing the importance of moving as fast as possible in the right direction across the entire company, not just in deployment.
• Trade-offs: The discussion highlights potential trade-offs between deployment speed and stability. A core debate emerges around whether prioritizing a 5 minute deployment masks other problems.
• Confidence and Stability: The co-hosts discuss the need for confidence in deploys and the importance of thorough testing, staging environments, and canary deployments to ensure stability, especially for large, established companies.
• Feature Flags: Feature flags are discussed as a tool for managing new feature releases and A/B testing, but also as potential sources of complexity and integration issues.
• Realism vs. Idealism: The co-hosts explore the tension between striving for ideal, hyper-optimized scenarios and acknowledging the constraints and realities of smaller teams and existing systems.
• Continuous Improvement: The importance of continuous improvement and incremental optimization is emphasized, as opposed to large, periodic overhauls.
• Batching Changes vs. Immediate Releases: The conversation touches on the idea of batching certain updates instead of releasing every change immediately.

Key Discussion Points:

• Introduction to Dependency Management: Dependency management involves pulling in libraries and managing updates, breaking changes, and inconsistencies across projects.
• The One Version Rule: The one version rule aims to ensure that only one version of each library is used across all projects within an organization. This reduces bundle sizes, avoids conflicts, and promotes consistency. React is used as an example, it typically functions as a singleton, using multiple versions is likely to cause issues.
• Benefits of the One Version Rule:
  • Smaller bundle sizes
  • Reduced conflicts between libraries
  • Increased consistency and shared knowledge across teams
  • Faster development and easier onboarding for new engineers
• Drawbacks of the One Version Rule:
  • Upgrading dependencies can become a large, complex project affecting multiple applications.
  • Managing breaking changes and coordinating upgrades can be challenging.
• Dependency Upgrade Challenges: Upgrades, especially breaking changes, require significant effort. Teams often postpone upgrades, leading to outdated dependencies and more complex upgrade processes later.
• HubSpot's Evergreen Dependency System: HubSpot uses an evergreen dependency system where non-breaking changes to libraries are automatically pulled down by all dependent projects on the next build. This reduces the burden of manual upgrades but requires robust tooling to test and verify changes.
• Trade-offs of Evergreen Dependencies:
  • Automatic upgrades can cause unexpected breakages if not properly tested.
  • HubSpot uses canary deployments and build tooling to mitigate these risks.
  • Build reproducibility becomes difficult as projects always pull the latest dependencies.
• Avoiding Breaking Changes: There's a growing trend towards avoiding breaking changes in internal libraries to minimize disruption and simplify upgrades.
• Peer Dependencies vs. Direct Dependencies: The hosts discuss the trade-offs between using peer dependencies (where the consumer provides the dependency) and direct dependencies (where the library includes the dependency).
• Airbnb's Dependency Management: Airbnb uses a system where applications and libraries don't have package.json files but instead use internal project.json files to enable or disable dependencies.
• Internal Tooling and Team Investment: The hosts emphasize the importance of internal tooling and dedicated platform teams to effectively manage dependencies and improve developer experience. Open-source tools can be useful for smaller teams, but larger organizations benefit from custom solutions.
• Building Important Systems by Committee: Building important systems like component libraries or design systems by committee can be challenging without a solid foundation and dedicated focus.
• The Tragedy of the Commons: Without a structured process or team to manage dependencies, it's unlikely that individuals will prioritize it, leading to a negative feedback loop of neglect and increasing complexity.

Sorry for not adding a nice graphic describing the library relationships - we'll leave that as an exercise to the listener!

Why React Server Components

• Benefits:

  • Improved Time to First Byte (TTFB) via streaming.
  • More cohesive view of data dependencies (tighter front-end/back-end coupling).
  • Potential for smaller client-side bundles (automatic code splitting).

• Trade-offs:

  • Requires a server layer (which might be a new concept for some React developers).

Migrating to React Server Components

• Adoption Strategy:
  • Start page by page (easiest entry point).
  • Flip the mental model: Start from the server and work towards the client.
  • Need to consider the bundler support for RSCs.
• Challenges:
  • You cannot easily swap out a small subsection of your page with an RSC.
  • Ensuring the bundler supports RSCs.
• Key Considerations:
  • Think about two environments: server and client.

Understanding RSC Concepts

• Two Environments: The importance of understanding server (server components, server actions) and client (client components) environments when using RSCs. Front-end engineers new to server-side development need to be aware of security implications and potential caching issues.
• Frameworks: Highlighted the importance of understanding the core RSC principles separate from framework implementations like Next.js.
• Not Necessarily Server Rendered: Clarifying that client components can be server-rendered, avoiding the assumption that client components are solely client-side rendered.
• Resources: Blog post "React for Two Computers" by Dan Abramov is a great resource to learn about the mental model. Also start to look at the other framework implementations to understand that there's next features and there are RSC features

Standup Updates

• Dillon: Using a Dexcom continuous glucose monitor to manage blood sugar levels and migraines.
• Scott: Getting wedding suits, migrating from Datadog to Grafana monitors.
• Matt: Working on lyaml translation migration. Experimenting with Parcel's RSC integration and Redwood SDK.

Links / References:

• React for Two Computers by Dan Abramov
  • An excellent introduction to the concepts behind React Server Components
• The Bookkeeping Pattern
  • A little look at how Scott and Matt leveraged Server Components and Server Functions at Fireworks
• Waku RSC Todo App
• Parcel RSC Todo App
• RedwoodSDK RSC Todo App

Stand-up Updates

• Dillon is dealing with disruptive construction at his house and is taking time off to combat burnout after a large launch at Woop. He has volunteered to be the guild lead of web, but is finding it difficult to motivate others and get things done.
• Scott recaps his recent trip to Italy, highlighting Rome, Florence, Venice, Milan, and Lake Como. He is working on a project at his new job to rebuild GitHub. His project involves visually displaying changes when someone pushes to live. He's also rebuilt an open-source keyboard navigation project using useSyncExternalStore, adding new use cases like a command K search palette.
• Matt is migrating translations in Webpack apps to a "postmodern" variant. He rebuilt his website using Waku and is debugging cold start issues on Cloudflare. He also got a new keyboard, the Nuphy Air V2 75, but a V3 model is coming out soon.

Monorepos Discussion

The main topic shifts to monorepos:

• Definition: A monorepo is a single repository containing multiple projects, packages, or workspaces.
• Popularity: Monorepos are popular at large companies like Google and Meta and are gaining traction in companies of various sizes.
• Experiences: The hosts discuss their experiences with monorepos at Wayfair, HubSpot, and their current companies. They talk about the shift from monoliths to microservices and back to monorepos at Wayfair, the benefits of shared code, and the importance of culture and expectations.
• Key Considerations:
  • Company size and number of contributors.
  • Deployment speed vs. stability.
  • Whether teams need to collaborate across problem spaces.
  • The existence of good documentation and onboarding processes.
  • The balance between consistency, speed, and safety.
• Tooling: They mention tools like Lerna, Turborepo, and PMPM that support monorepo management.
• Potential Downsides:
  • Monorepos can slow down development if not properly managed (e.g., long CI times).
  • Developers creating a dependency chain instead of simply reusing code.
  • Consistency is hard to maintain.
• Monorepo vs. Technical Solution: Adopting a monorepo is often a technical solution to an organizational problem (e.g., aligning teams on coding standards).
• The discussion shifts to how to deal with problems across the board, with more or less monorepos, more or less repos per projects, and things to consider when deciding what approach to use.

Team Structure and Code Ownership

• The discussion pivots to team structure, code ownership, and velocity.
• The hosts discuss the importance of discoverability of dependencies in monorepos.
• Siloed Ownership in the monorepo can lead to faster development and is better for teams.
• Speed in the form of high velocity, along with the proper North Star is critical for success.

Spicy Takes: CSS

The hosts share some spicy takes, primarily focused on CSS, tune in to the episode to hear them!

The Bikeshed Podcast introduces its hosts: Scott Kaye (UI guy, coffee curator, powerlifter) and Matt Hamlin (principal engineer, senior engineering lead) and Dillon (Spicy Take) Curry. They cover software engineering, tech events, and Discord emojis.

Keyboard Discussion

Dillon discusses his new Nuphy keyboard with silent red clear top switches, featuring RGB lighting. Matt reveals he recently ordered a Nuphy Air 75 v2 after being influenced by Dillon. This leads to a brief discussion about potentially dedicating an entire episode to keyboards.

Engineering Levels Discussion

• Introduction: The main topic shifts to engineering levels and promotions. They discuss the convoluted process of getting promoted and the often vague nature of career ladders.
• Promotions: Dillon suggests openly communicating promotion goals to managers early on and highlights finding a new job as another way to move up.
• Level Alignment: They acknowledge that engineering levels are not uniform across companies. A "senior" at one company might be a "junior" or "staff" at another. More competitive companies may make it harder to get higher-level titles.
• Fast Growth: They discuss the pros and cons of moving up the career ladder quickly and the importance of confidence and continuous learning. It’s also good to feel confident that you could interview and find a new job.
• Company Growth: The podcast touches on companies growing quickly can provide opportunity for advancement in titles.
• Lateral Growth: The hosts discuss the importance of lateral growth within a level to increase skillset. Seeking opportunities to grow and learn new things will make you more hireable in the future.
• Company Needs: The hosts emphasize identifying and solving company-wide problems as a way to stand out and grow within an organization.
• Leverage: Leverage is built through information and relationships. Leverage builds up over time in an organization and you begin to be able to better deliver results.

Building Connections

• Networking: The hosts discuss the importance of building a strong network across the company. Dillon recommends setting up one-on-ones with team members to understand their roles better.
• Be Nice: Genuine excitement about connections lead to great relationships.
• Authenticity: It's important to create genuine friendships at work and enjoy the time spent with colleagues.
• Teach: Teach people selflessly.

Conclusion

The hosts wrap up the discussion, emphasizing that levels matter differently to different people and depending on what their professional goals are. It's important to pursue constant growth and balance career aspirations with personal satisfaction.

Stand-up Updates

•   Scott discusses his laid-back onboarding experience at Airbnb and his excitement about the new role.
•   Dillon shares his success with morning workouts after adjusting his sleep schedule.
•   Matt discusses his on-site event, tinkering with Obsidian and TinyBase, and his anticipation for his new keyboard.

Summary:

This episode of The Bikeshed Podcast covers design systems, including their benefits, trade-offs, and whether your company needs one. The hosts also share experiences from their time working on a design system team at Wayfair. Segments include stand-up updates, "Two Takes and a Fake," and "Spicy Takes with Curry."

Stand-up Updates

• Dillon: Shifted to a new project requiring more help. He is listening to the audiobook "Sapiens."
• Matt: Exploring the Cloudflare Vite plugin, which allows building a worker and a client-side app. Also experimenting with TinyBase, a sync engine for web applications.
• Scott: Took time off before starting a new job. He completed home improvement projects such as re-grouting tiles and fixing a couch leg. Updated the Bikeshed Podcast logo and metadata. Started working on an incremental Bun compiler and playing around with a Moon monorepo.

Design Systems Discussion

• Benefits: Design systems are helpful, especially in larger corporations, as they standardize UI, increase speed, create brand consistency, and ease rebranding. They establish a UI contract between designers, engineers, and product teams.
• Considerations: Smaller companies might benefit more from solutions like Shadcn, where components are consumed into the application. The team should also be responsible for contributing back. Design systems should be flexible and adapt to user needs. It is important to take an empathetic approach to use cases.
• Wayfair Experience: The team discusses their experience working on a design system at Wayfair, highlighting the importance of a single source of truth for design. They also discussed the value of patterns and collaborative environment for creativity and continuous improvement. The team started rigid and inflexible, but matured to provide more flexibility for the teams they were supporting.
• Component Libraries vs. Design Systems: A component library is one piece of a design system. Component libraries are more of a starting point, less rigid, and more flexible, whereas design systems are more opinionated and include non-tangible elements like guidelines and documentation.
• Organization Size: Organization size impacts the design system. Large companies benefit from large investments in platform tooling. Design systems require dedicated people to think about them and the best way to set them up.
• Selling the Value: It is often hard to quantify and sell the value of what the team is doing. Tools that show adoption can help leaders see the value of a design system.

Spicy Takes

Tune in to hear the takes that Dillon and Matt share to make Scott react like Mr Krabs:

Two Takes and a Fake

The hosts play a game where they identify the fake tech-related news among two real ones. This week's topics were Bun, Vercel changelog, and Next.js.

Tune in to hear who wins this week!

Summary:

This episode of the Bikeshed Podcast features a discussion about software testing, with a focus on automated testing in frontend development. The hosts, Scott Kaye, Matt Hamlin, and Dillon Curry, explore various testing methodologies, tools, and their value in different contexts. They delve into the nuances of unit, integration, and end-to-end testing, and the trade-offs involved in choosing one over the other. The discussion also touches on the role of mocking, dependency injection, and the importance of balancing test coverage with development speed. They each share personal experiences from their development career on testing, and their favorite tools.

Key Discussion Points:

• Value of Testing: Testing is often not enjoyable in the short term, but provides significant long-term value by preventing bugs and providing confidence in code changes.
• Unit Testing vs. Integration/End-to-End: Unit testing is valuable for specific functions, while integration and end-to-end tests are better for critical user flows. However, end-to-end tests can be flaky.
• Mocking: The overuse of mocking can reduce the value of tests. Dependency injection is viewed more favorably than mocking, though they serve similar purposes.
• Test Coverage: Aiming for 100% test coverage may not be efficient; focus on testing essential product features. Consider the time and effort spent on tests versus the value they provide.
• Testing in Production: The hosts explore the concept of testing in production, with tools like Datadog synthetics. This allows the team to assess the experience for end-users in production.

• Test-Driven Development (TDD): TDD may not always be practical, especially when developing new features with unknown outputs. Writing tests after the feature is more common in these scenarios.
• Proof of Concept (POC): Developing a proof of concept outside the main application to validate an idea before integrating it is valuable.
• Accessibility Testing: The importance of accessibility testing is discussed, but integrating it into the development process is important.
• Component Tests: A discussion of testing in isolation to ensure true browser experience. Component testing will ensure the system will run in the browser as expected.
• Code and Test Half-Life: Tests lose value over time as codebase patterns change. It's important to re-evaluate their relevance.
  • Referenced blog post on the half-life of code and tests

Spicy Takes:

Tune in to the episode to hear all our spicy takes on testing!

Misc. References:

Scott shared a few Neovim related projects that he has been working with:

• Folke Snacks.nvim
• Folke Lazy.nvim
• Folke Flash.nvim
• Avante.nvim

This episode of the Bikeshed Podcast features Scott Kaye, Matt Hamlin, and Dillon Curry discussing best practices for code review, with a focus on creating effective pull requests (PRs) and how to approach reviewing code.

Creating Great Pull Requests

• Context is Key: Highlight the problem being solved, the goal of the PR, and the solution chosen. Explain why this solution was selected over alternatives.
• Scope: PRs should be isolated to a single problem or feature.
• Rollback: Consider and outline the rollback procedure for changes.
• Templates: Minimal templates with "context" and "details" sections are generally preferred. "Alternatives Considered" can be a useful addition.
• Self-Review: Conduct a self-review of the code, ideally within the GitHub PR interface, to identify potential issues.
• Draft Mode: Utilizing draft PRs is helpful for iterative development and early feedback.
• Visual Aids: Include screenshots, screen recordings, and preview deploys to contextualize changes, especially for UI-related PRs. Dev tool screenshots can be helpful.
  • How to capture full-size screenshots within Chrome Devtools
  • Matt's replacement for Dropbox Capture
• Tests: Defer writing tests until a solid solution and some initial feedback have been received to avoid wasted effort due to significant code changes.

Reviewing Code Effectively

• Understand the Big Picture: Start by understanding the problem being solved and the overall goal of the PR.
• Use Available Context: Utilize videos, screenshots, and preview deploys to understand the changes.
• Prioritize: Focus on major changes and save minor issues for a second pass.
• "What, Why, How" Approach: Consider what the change does, why it's being made, and how it's implemented.
• Live Reviews/Pairing: For complex changes, consider live reviews or pair programming to accelerate feedback and build shared understanding. However, acknowledge that this is not always feasible due to time constraints.
• Knowledge Sharing: Use code reviews as an opportunity to onboard team members and share knowledge.

Spicy Takes (and Not-So-Spicy Takes)

• Code review maybe is not needed: It was suggested in certain situations, code review may not be necessary. This take was received as extremely situational.
• You should almost never have to do two code reviews This take was received as neither mild or spicy, more so cold and lukewarm.

What's Up With You? (Stand-up Updates)

• Dillon: Was looking into something called embargoed assets in Contentful.
• Scott: Learned about animating on scroll videos and pictures in React using the Canvas tag, bypassing React's re-rendering limitations.
• Matt: Investigating Content Security Policy (CSP) and durable objects on Cloudflare.

In this episode of the Bikeshed Podcast, the bikeshed boys dive into their daily routine exploring their productivity habits and workflows. They also get down and dirty on discussing their spicy takes.

Daily Routines for Productivity

• Matt: Starts his day with a morning walk and uses Obsidian as a central hub for notes and task management. He reviews notes and Slack to identify action items. He also notes that he finds opportunities to make improvements on other things while doing a given task and acts on it instead of simply noting it.
• Scott: Begins with coffee, checks personal and work emails and Slack, reviews his calendar, and focuses with his headphones and vibes with music.. He uses Obsidian, Notion, or Notes to track tasks and goals, breaking down complex tasks into smaller, manageable parts. He also prioritizes clear communication and task articulation to minimize disruptions.
• Dillon: Prefers working from the office for increased productivity. He maps out his day with a "stand-up update" and clears his email and Slack to minimize distractions and enable focused work periods.

Follow-up on Daily Routines

• Matt and Scott both use end-of-day summaries to set the stage for the next day.
• Dillon prefers the office to WFH and does not perform an end-of-day summary and stated it's something he could work on.
• Matt uses an "outcomes" section in his daily notes to track accomplishments and artifacts, aiding in reviews and progress tracking over time.

Spicy Takes

• Dillon (Medium): React components often abuse props, violating the single responsibility principle due to a lack of care or education.
• Scott (Hot): Design systems should empathetically conform to user needs and not try to influence design in a specific direction. A bolder take was that design systems shouldn't exist at all.
• Matt (Hot Fire): We should not always assume good intent when reviewing code or understanding legacy systems. Sometimes, it's necessary to challenge decisions and consider alternative paths.

Two Takes and a Fake

The hosts played a round of "Two Takes and a Fake," a game where they presented three tech-related statements (two real, one fake) and challenged each other to identify the fabrication. Who will win? Tune in and find out!

What's New

• Scott: Been working with UI heavy work to animate webm video files on scroll. Check out the homepage of Tollbit
• Matt: Released Vndr, a CLI tool for vendoring (inlining) packages.

This episode of the Bikeshed Podcast explores the concept of "enshittification," the idea that the quality of products and services deteriorates over time, often accompanied by increased monetization and decreased customer value. They further discuss how this relates to web development and the broader tech industry. They explore potential cultural factors behind this.

Key Discussion Points:

• Enshittification Examples: The hosts provide examples of enshittification in popular services like Spotify (increased ads with subscription) and Netflix (higher prices for premium features). Facebook is also mentioned as a product that has seemingly declined in popularity as it has aged.
• AI Integration: The hosts discussed the trend of tacking on AI to products just to say that they offer AI features, which can often be annoying and not serve the original purpose of the product.
• Lost Focus on User Needs: They discuss how companies sometimes lose sight of their original mission and focus more on monetization through KPIs rather than solving customer needs. The hosts share that as measures become metrics, they become less valuable over time.
• "Nobody Cares" Blog Post: They discuss the Grant Slatton blog post, interpreting it as a reflection of how engineers may be disempowered from caring about the overall product due to narrow focus and lack of agency in larger organizations.
• “Shadification of the Web”: They introduce the term "shadification" to describe the growing trend of websites looking the same due to the widespread use of component libraries like Shadcn/ui (copy-paste) along with Material UI and Bootstrap.
• Optimization vs. Innovation: They discuss how companies often prioritize optimization and A/B testing over true innovation, resulting in a lack of creativity and unique user experiences.
• Performance Costs: Optimizations made at the expense of performance degrade the customer experience.
• Blurred Ownership: In larger companies, it becomes harder to draw ownership lines when there are more people owning things and there isn't clear defined guidelines.
• Impact of AI on UI Creativity: The hosts explore the potential for AI to further standardize UI patterns and stifle creativity, as AI models are trained on existing designs and may not generate truly novel solutions.
• AI Dependency: Discussion of companies choosing to support new libraries based on the amount of support AI models know about them and recommend them, which can lead to everything becoming the same.

Personal Updates:

• Scott has been digging into Avante, finding it helpful for learning Go. He plans to build a backend service in Node and then refactor it to Go as a learning exercise.
• Matt has been experimenting with Cursor's Composer agent feature and a tool called Codename Goose, which uses AI to infer functionality on his computer.

The bikeshed boys dive directly into software's hottest topic: AI. We believe in using AI in your day to day job to be more successful.

In this episode we discuss;

• use cases for AI in software development,
• the fun tasks AI has taken away and,
• how to be successful using AI tools.

Listen to us explain navigating writing code in a world where more and more companies are increasingly advocating the usage of AI at your day job.

How do we continue to learn and grow as human while still maintaining fun, creativity and human interaction as an engineer in 2025?

AI is a powerful tool used correctly, however that AI will submit to confirmation bias and your role is to prompt AI to be as unbiased as possible to the best of your ability.

Episode Summary:

In this episode of The Bikeshed Podcast, hosts Scott Kaye, Matt Hamlin, and Dillon Curry discuss the role of AI in software development, sharing their experiences with various AI-powered tools and debating the impact of AI on engineering workflows, learning, and job satisfaction.

Key Topics Discussed:

1. AI in Software Development

• The hosts discuss how AI has become integral to software engineering, particularly for writing code and automating tasks.
• Matt introduces the main discussion: how AI is used in development today and the broader implications of its adoption.

2. Preferred AI Tools

• Dillon shares that he used Cursor until his company restricted it, forcing him to switch to Copilot, which he finds inferior.
• Scott uses NeoVim with NeoCodium and Avante, but acknowledges their limitations compared to Cursor.
• Matt relies on Cursor at work, noting that his company prefers it over other AI tools.

3. AI's Impact on Development

• AI enables developers to work faster but can remove the learning process.
• Over-reliance on AI can lead to shallow understanding of code and a decrease in creativity.
• AI often acts like a junior engineer whose code must be reviewed, making debugging a larger part of the job.
• Using AI can lead to less collaboration with teammates, as developers tend to consult AI over their colleagues.

4. Concerns About AI in Software Engineering

• Some engineers feel less engaged with their work as AI handles boilerplate and repetitive tasks.
• AI's agreeable nature can reinforce incorrect assumptions, leading to confirmation bias.
• Companies may use AI to increase efficiency and reduce hiring, raising concerns about job displacement.

5. AI vs. Traditional Search (Google)

• Unlike Google, where users must craft precise search queries, AI allows more fluid back-and-forth conversations.
• AI can provide immediate answers but might not always offer the best or most optimized solution.

6. The “No AI” Challenge

• The hosts agree to a two-and-a-half-day challenge of coding without AI, to evaluate how it affects their work and problem-solving abilities.

7. Game Segment – “Two Takes and a Fake”

• Scott introduces a new segment where Matt and Dillon guess which of three AI-related tweets is fake.
• Matt wins this round, showing a keen eye for spotting AI discourse trends.

8. What's New?

• Dillon is learning piano and music theory to slow down and disconnect from work.
• Matt is exploring Cloudflare workers and running Deepseek R1 locally for AI experimentation.
• Scott is focused on improving his Golang skills and debating Cherry Pepsi Zero vs. Cherry Coke Zero.

9. Closing Thoughts

• The hosts discuss burnout, learning in tech, and how side projects keep programming fun.
• They tease next week's episode on burnout and side projects.

The episode wraps up with some lighthearted banter and a call for listeners to like, subscribe, and share.