Software Madhouse

Software Madhouse — an unfiltered, occasionally unhinged podcast about building software, the people who build it, and the chaos in between.

Play

Open in

9 episodes
weekly
Avg 31 min
English

Episodes 9

Newest Oldest Longest

All9 Unplayed9 In progress0 Played0

S1 · E9
Tuesday · 33 min
AI Is Finding Your Vulnerabilities Before You Do
Last week a cluster of critical vulnerabilities landed on the same day. PHP2Shell and Node2Shell both allowed unauthenticated remote code execution. GitLab shipped a CVSS 10.0 flaw in the Ruby regex engine that affected every self-managed release back to version 7.0. A Python CVE rounded out the set. Some people started calling it Black October. Matt and Robert talk through how these issues arrived together, why so many landed on a Wednesday, and what CVSS scores actually mean when they hit 9 and 10. They look at how AI models found some of the bugs with short prompts, how coordinated embargoes are fraying, and how the time from public disclosure to active exploit attempts has collapsed from weeks or months down to hours. They also cover what this does to organizations that still patch on a monthly or quarterly cycle, why some teams took sites offline rather than risk exposure, and the practical trade-offs for open source maintainers and the people who depend on their projects. The episode ends with a question for listeners: if AI keeps getting better at finding issues, does open source become safer overall, or do we just run a permanent high-speed patch race? Links Dan Lorenc (Chainguard) on the PHP embargo and using AI to find the vulnerabilities: https://www.linkedin.com/feed/update/urn:li:activity:7518756994284077056/ PHP2Shell: https://www.php2shell.com/ Node2Shell (Node.js October 2026 security releases): https://nodejs.org/en/blog/vulnerability/october-2026-security-releases GitLab critical patch release (CVE-2026-110264): https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/ CVSS scoring system: https://www.first.org/cvss/ XKCD 2347 (Dependency): https://xkcd.com/2347/ Watch this episode on YouTube: https://www.youtube.com/watch?v=lb0KHFFCPpI
S1 · E8
October 20 · 30 min
Coding with AI and Coding for AI
Coding with AI is not the same thing as coding for AI. One is using agents and assistants to write software. The other is building the infrastructure, pipelines, and systems those models run on. Matt and Robert separate the two, cover what works and fails with coding agents (context, model choice, subtle bugs, security issues), why fundamentals still matter, and the open source and operations side of running AI workloads. Watch this episode on YouTube: https://www.youtube.com/watch?v=ze5R5fMKwVY
S1 · E7
October 13 · 32 min
Source on the Shelf vs a Build You Can Actually Run: Open Source, Open Build, and Who the Community Is Really For?
The repo is public and the license says MIT, so it must be open source. But can you actually build a working binary without private toolchains and closed blobs? Matt and Robert examine what an open source license really guarantees and where common expectations go further. They walk through the differences between permissive and copyleft licenses, separate open source from open build, and contrast open communities with closed ones. Using examples such as Curl, SQLite, and company-backed projects, they show why some projects publish source yet remain hard to rebuild or unwilling to accept outside contributions. They also discuss practical signals for judging a project’s long-term health and whether it is worth depending on. Watch this episode on YouTube: https://www.youtube.com/watch?v=DS-Dh3AhiIA
S1 · E6
October 6 · 34 min
Darren vs Programmers vs Developers vs Software Engineers
Robert’s line from last time did not land: developers use code to solve business problems, and software engineers use code to create them. So Matt and Robert brought Darren Shepherd in to argue it. Darren created Rancher and k3s, and he is now chief architect at Obot. Matt restates the roles from episode 3 and drops computer scientist. A programmer writes the code someone else specified. A developer owns the lifecycle. A software engineer is supposed to own requirements, design, and reliability. The Bureau of Labor Statistics has programmer employment on a long decline, with hiring mostly replacements. It groups developers and engineers together and calls that work growing. Darren does not fit the list. He calls himself a bad programmer and an agent of chaos. He cares about the system, how the pieces fit, and the compromise in an architecture. He does not care about the process, and he does not want a perfect design. Robert treats architect as a level inside any of those jobs. Darren pushes back: some engineers optimize a widget and ignore the business problem, which is how engineers end up creating business problems. Matt splits the work another way: people who go deep on one component, people who go wide on the user problem, and people who see a problem and run off to invent something. WordPress and Longhorn come up as cases where the useful question is what you are optimizing for, not whether the code is pretty. Then AI. Darren does not accept the claim that training on open source destroys it. Rancher sold support and never licensed the software, and he still treats the value as the relationship, not the repo. He wants open source projects to hand the toil to AI, and he thinks code quality goes up once the process is less immature than the last year. Remix 3, which just shipped a stable release and left React, is his example of work a model will not originate: a new idea about simpler JavaScript, not another React app. Robert hates drive-by pull requests and still uses AI for syntax he does not want to keep in his head. Matt compares the model to the crew that lays pipe and cable after the house is designed, and notes that some contributors liked that work. Senior engineers can guide a model because they already know how the system is put together. People in their twenties are being told to start with the model. Darren’s advice is to copy the seniors who are actually doing the work, and to ignore the posts that claim one prompt built the app. A Rust-to-Bun port, he says, was hours of skilled guidance, not a sentence. Links Episode 3: https://softwaremadhouse.com/episodes/episode-3/ Obot: https://obot.ai Remix: https://remix.run k3s: https://k3s.io Longhorn: https://longhorn.io Watch this episode on YouTube: https://www.youtube.com/watch?v=U6xkSQUhQds
S1 · E5
September 29 · 33 min
You’re Not a Coder Anymore, Welcome to Management of Agents
The internet is arguing about a new claim: developers no longer write code, they manage agents. Does that mean we have all been promoted to management? Robert and Matt start with the talk that set it off. At Rails World last week, DHH said he has retired from professional programming and now calls himself an “Energized Professional Maker.” We go through his main points. He says the old 10x-programmer debate is obsolete, because the gap between a weak programmer without agents and a strong one with them is closer to 100x to 1,000x. In about 20 months he produced roughly half as much code as in the previous 21 years. 37signals is moving Hey from a web app to a Rust backend service, written without reading the code, with native apps on six platforms. And according to DHH, your app needs a CLI, not excuses. We also cover his recent work on Omarchy and compare all of this with Gallup polling that shows optimism about AI is uneven around the world and lower in the West. Is running agents like being a manager? We look at Denise Schannon’s take on that comparison and at a four-level model of agentic software development in the enterprise. Then we look at developers taking the opposite path, such as the proposed no-AI policy from some GNOME developers. Rob explains why some developers want AI out of their work and what that could mean for them. We finish with DHH’s claim that slop is “an executable idea” and return to the question from our previous episode: where do development and engineering fit now? Links DHH’s talk: https://www.youtube.com/watch?v=vDjW_dRyKXY Gallup, global optimism about AI: https://news.gallup.com/poll/714593/optimism-globally-widespread-despite-uneven.aspx Denise Schannon on managing agents: https://www.linkedin.com/feed/update/urn:li:activity:7508548991379484672/ Four levels of agentic software development: https://kasparvongruenberg.substack.com/p/four-levels-of-agentic-software-development The GNOME LLM policy proposal: https://blogs.gnome.org/alatiera/2026/09/23/the-gnome-llm-policy-that-i-want/ DHH on slop: https://x.com/dhh/status/2103454839086706746 Watch this episode on YouTube: https://www.youtube.com/watch?v=SuKX0EnULr8
S1 · E4
September 22 · 26 min
Testing the Negative: Why Happy-Path Tests Lie
Your tests pass, your coverage is high, and your code still breaks in production. That’s what happens when you only test the happy path. In this episode, Matt and Robert take on one of Robert’s biggest pet peeves: unit tests that never cover the negative, or sad, path. They break down what the sad path actually is, why developers naturally skip it (code is written for the success case, negative tests feel like extra work, and coverage tools don’t tell the whole story), and where the gaps show up in production, from partial failures in multi-service architectures to untested catch blocks, else branches, early returns, retries, and fallbacks. They close on a practical note: with today’s tooling, including AI assistance, writing tests for both the positive and negative cases is easier than it has ever been. There’s no good excuse left. Watch this episode on YouTube: https://www.youtube.com/watch?v=PpQwkBuPxy8
S1 · E3
September 15 · 28 min
Programmers vs Developers vs Software Engineers
Matt and Robert walk through four roles that get mixed together on job boards and resumes: programmer, software developer, software engineer, and computer scientist. They look at what each job actually covers, where “engineer” is a regulated title and where it is just a pay-band label, how ACM/IEEE CC2020 draws the line between computer science and software engineering, and how much of the “requirements” work now sits with product managers. They also pull Bureau of Labor Statistics outlooks for programmers, software developers, and computer and information research scientists, and talk about what BLS is saying about AI and IT employment through 2034. The practical question underneath the titles: what do you actually own on a team, and what should you put on a resume when the words keep sliding. Links ACM Computing Curricula 2020: https://www.acm.org/media-center/2021/march/computing-curricula-2020 BLS - Computer programmers: https://www.bls.gov/ooh/computer-and-information-technology/computer-programmers.htm BLS - Software developers: https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm BLS - Computer and information research scientists: https://www.bls.gov/ooh/computer-and-information-technology/computer-and-information-research-scientists.htm BLS -Artificial intelligence, information technology, and employment, 2024–34: https://www.bls.gov/opub/ted/2026/artificial-intelligence-information-technology-and-employment-2024-34.htm Watch this episode on YouTube: https://www.youtube.com/watch?v=Gf9na-uU-qU
S1 · E2
September 8 · 32 min
What Is A Forward Deployed Engineer?
Matt and Robert unpack the Forward Deployed Engineer: a Palantir-coined, customer-facing role that parks an engineer at a customer site for a set stretch of time. They trace the name to military “forward basing,” ask whether an FDE is just a consultant with better branding (or a one-person Pivotal-style embed), and look at why vendors bake these unicorns into the price of the software — so the product actually gets used instead of sitting on the shelf until next year’s renewal. Links & mentions FDE on Wikipedia: https://en.wikipedia.org/wiki/Forward_deployed_engineer A Day in the Life of a Palantir Forward Deployed Software Engineer: https://blog.palantir.com/a-day-in-the-life-of-a-palantir-forward-deployed-software-engineer-45ef2de257b1 Watch this episode on YouTube: https://www.youtube.com/watch?v=CxIBrEyJO-k
S1 · E1
September 1 · 28 min
Welcome to the Madhouse
Matt and Robert launch Software Madhouse with the AI open-source firehose: drive-by slop PRs flooding projects like Helm, extra maintainer load, and how communities are fighting back with policies, GitHub caps, kernel Assisted-by: trailers, and tools like Vouch and Good Egg. Links & mentions Kubernetes: Open source maintainership in the age of AI — https://www.kubernetes.dev/blog/2026/06/26/open-source-maintainership-in-the-age-of-ai/ GitHub: Limit open PRs for users without write access — https://github.blog/changelog/2026-06-17-limit-open-pull-requests-for-users-without-write-access/ Linux kernel coding assistants — https://docs.kernel.org/process/coding-assistants.html Vouch (Mitchell Hashimoto / Ghostty) — https://github.com/mitchellh/vouch Good Egg — https://github.com/2ndSetAI/good-egg Watch this episode on YouTube: https://www.youtube.com/watch?v=oRGkEQvsIGo

Showing 1–9 of 9 episodes