Señors at Scale - Software Engineering & Tech Leadership

Do you actually need a JavaScript framework to build your web app, or did we forget how the web was designed to work?Carson Gross is the creator of HTMX and its predecessor, intercooler.js, the principal at Big Sky Software, and a computer science professor at Montana State University. HTMX came out around the same time as React, and for years it was the contrarian option. Then the industry started asking how much JavaScript we really need.In this episode, Carson walks through his crooked path into programming (HyperCard, Excel, a JVM language called Gosu), how frustration with Angular 1 led to intercooler.js, and how a COVID rewrite without jQuery became HTMX. We dig into what hypermedia actually is, why JSON APIs are not REST in Fielding's original sense, and which apps HTMX is (and isn't) a good fit for.We also get into HTMX 4, why AI and vibe coding may push HTMX into a niche, and why Carson went back to pencil and paper exams so his students still learn how computers work.Key Topics:- From HyperCard and Excel to building a JVM programming language- How Angular 1 and jQuery inspired intercooler.js- Rewriting intercooler without jQuery to create HTMX- Hypermedia explained through links and forms- Why government and public websites should use plain HTML- How REST came to mean the opposite of REST- What kinds of apps HTMX is good for- HTMX 4: fetch instead of XHR, explicit attribute inheritance, renamed events- AI, vibe coding, and the future of HTMX- Teaching CS in the AI era with pencil and paper exams- Advice for junior developers- Chesterton's Fence and book recommendationsCONNECT WITH CARSON💼 LinkedIn: https://www.linkedin.com/in/1cg🐦 X (HTMX): https://x.com/htmx_org🐙 GitHub: https://github.com/bigskysoftware🌐 Website: https://bigsky.softwareFOLLOW & SUBSCRIBE🎙️ Podcast: https://neciudan.dev/senors-at-scale📩 Newsletter: https://neciudan.dev/subscribe💼 Dan on LinkedIn: https://www.linkedin.com/in/neciudan💼 Señors at Scale on LinkedIn: https://www.linkedin.com/company/senors-scale/📸 Señors at Scale on Instagram: https://www.instagram.com/senorsatscale/📸 Dan on Instagram: https://www.instagram.com/neciudevADDITIONAL RESOURCES📘 Hypermedia Systems (free book): https://hypermedia.systems🌐 HTMX: https://htmx.org🧪 HTMX examples: https://htmx.org/examples📝 HTMX essays (incl. How Did REST Come to Mean the Opposite of REST, Yes And): https://htmx.org/essays🪓 Grug Brain Developer: https://grugbrain.dev💻 MTMC 16-bit teaching computer: https://mtmc.cs.montana.edu💻 BDP 8-bit teaching computer: https://bdp.cs.montana.edu🏛️ G.K. Chesterton: https://chesterton.org📚 A Philosophy of Software Design by John Ousterhout📚 The Master and Margarita by Mikhail Bulgakov📚 The Brothers Karamazov by Fyodor Dostoevsky#htmx #hypermedia #webdevelopment #javascript #softwareengineering #react #rest #ai💬 Have you shipped anything with HTMX, or are you still all in on SPAs? Tell me in the comments.

You can't optimize what you don't measure. So why do so many teams still guess?

In this episode of Señors at Scale, I sit down with Ryan Townsend, Principal Product Manager for Performance at Cloudflare. Ryan has spent 20+ years building for the web and a decade as a CTO. He co-founded Shift Commerce, an enterprise-scale headless SaaS e-commerce platform built on Ruby on Rails that handled billions in yearly revenue. Before that, he was CTO of Matalan Direct, which grew out of one of Shopify's fastest-growing businesses.

We talk about why "Rails doesn't scale" was always a myth and how learning Rails in 2005 felt like AI feels today. Ryan also explains how he learned to let go of the code as a leader, using guardrails, weekly demos, and T-shaped engineers.

Then we get deep into performance: why real user data beats Lighthouse on your MacBook, how one "no performance impact" personalization script cost seconds at P90, and how Shift hit 99%+ cache hit ratios using inventory tiers and edge personalization.

Key Topics:
- Why "Rails doesn't scale" was always a myth
- Resume-driven development and why startups over-hire CTOs
- Why deep experience plus AI is a superpower, and the junior talent pipeline problem
- Letting go of the code: guardrails, weekly demos, and async leadership
- T-shaped engineers and spreading context across teams
- Adopting Scrum properly, training with Jeff Sutherland, and removing impediments
- Cutting CI from 40 minutes to 3
- Real user monitoring vs synthetic testing
- The render-blocking personalization script that cost seconds at P90
- 99%+ cache hit ratios, inventory tiers, and personalizing cached pages at the edge
- Preparing for Black Friday traffic spikes

CONNECT WITH RYAN
💼 LinkedIn: https://www.linkedin.com/in/ryantownsend/
🦋 Bluesky: https://bsky.app/profile/twnsnd.com
🐙 GitHub: https://github.com/ryantownsend
🌐 Website: https://twnsnd.com

FOLLOW & SUBSCRIBE
🎙️ Podcast: https://neciudan.dev/senors-at-scale
📬 Newsletter: https://neciudan.dev/subscribe
💼 Dan's LinkedIn: https://www.linkedin.com/in/neciudan
💼 Señors at Scale LinkedIn: https://www.linkedin.com/company/senors-scale/
📸 Señors at Scale Instagram: https://www.instagram.com/senorsatscale/
📸 Dan's Instagram: https://www.instagram.com/neciudev

ADDITIONAL RESOURCES
📘 The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford
⚡ Cloudflare Speed docs: https://developers.cloudflare.com/speed/
🐢 Ryan's slowest site in the world (web perf practice repo): https://github.com/ryantownsend/slowest-site-in-the-world

#WebPerformance #Cloudflare #RubyOnRails #Ecommerce #CoreWebVitals #EngineeringLeadership #SeniorsAtScale

💬 What's the biggest performance win you've found by actually measuring instead of guessing?

What does it take to run a design system that 2,000+ applications depend on, when every team is free to walk away from it?
a Software Engineer on Netflix's Hawkins team, which uses the design system
In this episode of Señors at Scale, Dan sits down with Szymon Chudy, Software Engineer at Netflix on the Hawkins team, the design system used by thousands of engineers across Netflix's internal tools. Before Netflix, Szymon grew from Senior to Staff Frontend Engineer at Lokalise, where he co-owned the design system and led frontend direction across teams. Before tech, he was a professional guitarist with over a thousand concerts and two platinum albums.

Szymon explains why he sees a design system as enablement rather than a component library, why he believes the source of truth lives in code and not in Figma, and how Netflix's "freedom and responsibility" culture forces the Hawkins team to think like a product team that has to earn adoption. We get into the UI paved road, shipping codemods and AI skills with every breaking change, running an alpha, beta and GA release across thousands of apps, and what an on-call incident looks like for a design system.

We also talk about when you should not build a design system, what a visual refresh really involves under the hood, and whether the Netflix culture from No Rules Rules holds up from the inside, including informed captains, farming for dissent and the keeper test.

Key Topics:
- What a design system really is: enablement, not just components
- Source of truth: Figma, code, or a separate component definition
- Why markdown specs and LLMs don't solve the determinism problem
- Hawkins Consumer vs Hawkins Professional at Netflix
- Design police vs full freedom, and the case for a paved road in the AI era
- Why design systems are slower than product, and why that's a feature
- "Legal hacking": letting teams diverge with clear boundaries
- Shipping skills, MCPs and context so agents can use your design system
- Adoption rate as the success metric
- Codemods, AI skills and human in the loop for major migrations
- Alpha, beta, GA: releasing breaking changes to thousands of apps
- On call for a design system: what counts as an incident
- You may not need a design system
- Netflix culture: freedom and responsibility, informed captains, the keeper test

🔗 FOLLOW SZYMON
💼 LinkedIn: https://www.linkedin.com/in/szymonchudy/
🐦 X/Twitter: https://x.com/szymonchudy
🦋 Bluesky: https://bsky.app/profile/chudy.me
🌐 Website: https://chudy.me

🎙️ FOLLOW & SUBSCRIBE
📸 Instagram: https://www.instagram.com/senorsatscale/
📸 Instagram: https://www.instagram.com/neciudev
🎙 Podcast URL: https://neciudan.dev/senors-at-scale
📬 Newsletter: https://neciudan.dev/subscribe
💼 LinkedIn: https://www.linkedin.com/in/neciudan
💼 LinkedIn: https://www.linkedin.com/company/senors-scale/

📚 ADDITIONAL RESOURCES
- Szymon's blog: https://chudy.me/blog
- Lenny's Podcast with Elizabeth Stone (Netflix CPTO) on systems thinkers: https://www.lennysnewsletter.com/p/netflix-cpto-on-ai-and-the-future
- No Rules Rules by Reed Hastings and Erin Meyer
- The Culture Map by Erin Meyer
- Grokking Web Application Security by Malcolm McDonald
- Grokking Algorithms by Aditya Bhargava
- The Pelican Brief by John Grisham

#DesignSystems #Netflix #Hawkins #Frontend #React #Figma #PlatformEngineering #DeveloperExperience #AIAgents #Codemods #WebDevelopment #SoftwareEngineering #SenorsAtScale

What does an agentic AI system look like when it has to work 100% of the time for millions of travelers, not just in a demo?

Vilva Athiban is Lead AI Engineer at Omio, one of Europe's leading travel platforms. In June 2024, Omio picked him and one other engineer to start an AI team reporting directly to the CEO and CTO. He had no ML background. All he knew was how to call an LLM API. Since then he has built Omio's internal AI platform, the MCP integrations that connect agents to company systems, and Omio.ai, a consumer-facing agent product built entirely on MCP with no agent framework.

In this episode Vilva walks through the full evolution of the architecture: LangChain, then LangGraph for control, then no framework at all. He explains the difference between supervisor and orchestration agents, why bigger models turned out cheaper than mini models at scale, how they cap tool calls and cache prompts to control cost, why guardrails ended up with the legal team, and why he thinks loop engineering will die in a few months. We also cover harnesses and context compaction, whether RAG is dead, how to pick models in 2026, fine-tuning, and what a JavaScript engineer should learn to move into AI.

Key Topics:
- From JavaScript engineer to Lead AI Engineer with no ML background
- LangChain vs LangGraph, and why Omio's backend is now 100% MCP
- Supervisor agents vs orchestration agents
- Bigger models with medium thinking were cheaper than mini models
- Capping tool calls, summarizing tool responses, prompt caching
- Guardrails are subjective: the whale hunting debate
- The agent is only as powerful as the tools you give it
- What MCP is and why it replaced RAG for Omio
- Harnesses, memory, and context compaction in Claude Code
- Loop engineering: a sugar-coated while loop
- How to choose models in 2026 (big, mini, nano)
- Why fine-tuning is coming back in 2027
- Are developers cooked? The autocomplete that writes 15 files
- How JavaScript engineers can become AI engineers
- The token bubble, budgets, and the move to open source models

CONNECT WITH VILVA
💼 LinkedIn: https://www.linkedin.com/in/vilvaathiban/
🐦 X: https://x.com/vilvaathibanpb
🐙 GitHub: https://github.com/vilvaathibanpb
🌐 Website: https://www.vilvaathiban.com/

FOLLOW & SUBSCRIBE
🎙️ Podcast: https://neciudan.dev/senors-at-scale
📧 Newsletter: https://neciudan.dev/subscribe
💼 Dan on LinkedIn: https://www.linkedin.com/in/neciudan
💼 Señors at Scale on LinkedIn: https://www.linkedin.com/company/senors-scale/
📸 Señors at Scale on Instagram: https://www.instagram.com/senorsatscale/
📸 Dan on Instagram: https://www.instagram.com/neciudev

ADDITIONAL RESOURCES
- Anthropic Learn: https://www.anthropic.com/learn
- Model Context Protocol: https://modelcontextprotocol.io
- Omio: https://www.omio.com

#AIEngineering #MCP #AgenticAI #LLM #LangChain #LangGraph #SoftwareEngineering #AIAgents

💬 Have you hit the point where a bigger model was cheaper than a mini model in production? Tell me in the comments.

What if every app's data lived in one shared, open database that no company owns? Dan Abramov says that future already exists, and he spent two years building it.

Season 3 of Señors at Scale opens with one of the most recognizable names in frontend. Dan Abramov is the co-creator of Redux, spent nearly a decade on the React core team at Meta, writes overreacted.io, and spent the last couple of years as an engineer at Bluesky working on the app and the AT Protocol. He is now at Vercel working on Next.js.

In this episode Dan explains AT Protocol from first principles: why it is a specification and not a framework, how it splits hosting from apps, why your followers are not your data, and why he thinks Mastodon is a feudal kingdom passing messages on horses. He walks through migrating his own hosting to Eurosky, what it costs to run your own data server, and where a developer should start building. Then we get into Next.js, Turbopack vs Vite, the React Compiler, and why the creator of Redux has not needed a state manager in five years.

Key Topics:
- What AT Protocol is and why it is being brought into the IETF
- The "everything folder": one repository per user, shared across all apps
- AT Proto vs Mastodon and why message passing between instances does not scale
- How a post from someone with 10 million followers actually flows through the network
- Hosting, relays, PLC identity and the three things in your "passport"
- How the Bluesky app itself is built (Go backend, React Native web frontend)
- How companies make money when users own their data
- Migrating your data hosting to Eurosky and the paper cuts along the way
- did:plc vs did:web and what happens if you lose your domain
- Why followers, likes and reposts are just links between JSON records
- Running your own PDS on a VPS or Cloudflare Workers for close to free
- Getting started: PDSLS, Tap, Constellation and building without a backend
- Apps Dan wants to see on AT Proto and why cloning existing products is not enough
- Vercel, Next.js and what Dan wants to fix
- Turbopack vs Vite and the "no bundling in dev" bet
- React Compiler as fine grained reactivity
- Redux as a to-do list: where state should actually live
- Book recommendation: Terence Tao's Analysis I (and its Lean companion)

CONNECT WITH DAN
🦋 Bluesky: https://bsky.app/profile/danabra.mov
🐙 GitHub: https://github.com/gaearon
🌐 Blog: https://overreacted.io
🌐 Website: https://danabra.mov

FOLLOW & SUBSCRIBE
🎙️ Podcast: https://neciudan.dev/senors-at-scale
📧 Newsletter: https://neciudan.dev/subscribe
💼 Dan's LinkedIn: https://www.linkedin.com/in/neciudan
💼 Show LinkedIn: https://www.linkedin.com/company/senors-scale/
📸 Show Instagram: https://www.instagram.com/senorsatscale/
📸 Dan's Instagram: https://www.instagram.com/neciudev

ADDITIONAL RESOURCES
- AT Protocol: https://atproto.com
- "There are no instances in AT Proto" (Dan's blog post): https://overreacted.io
- PDSLS repository explorer: https://pdsls.dev
- Tangled (GitHub on AT Proto): https://tangled.org
- Terence Tao, Analysis I Lean companion: https://github.com/teorth/analysis

#ATProtocol #Bluesky #DanAbramov #React #Redux #NextJS #Decentralized #OpenWeb #WebDevelopment #SoftwareEngineering #SeñorsAtScale

💬 Would you move your data hosting off Bluesky's default servers? Or does owning your own JSON not matter to you? Let me know below.