On October 28, 2026, I attended my first Platform Engineering Meetup hosted at Surly Brewing Co and put on by Tarmac. It was the first meetup that I have attended in a number of years, so I went in a little skittish and wasn’t sure what to expect. Hosted at Surly Brewing Co. in their upstairs private meeting space, they had the bar open and a few snacks for attendees. Since I haven’t been to a meetup in a while, I figured I would go, keep my head down, and see where the evening took me. A few people were already mingling, but I didn’t want to interrupt them. I decided to grab a drink, find an empty table, and finish reading an article from Anthropic about how the Claude Code team runs their pull request routine. Little did I know how much that article would play into the rest of the meetup.
The first presentation was by Mike Osbone from Blank Metal AI, “A Day in the Life of an Agentic Engineer”. In the presentation, Mike walked everyone through how he weighed risk and human time while using AI to accomplish a task and get it out to production. The slides progressed through the steps you could take after telling an agent to implement a ticket from the ticketing system until it was merged. The ultimate goal was to reduce the risk of what the AI agent produced while also lowering human involvement. Ironically, this was exactly what I was reading from the Claude Code team earlier that night. With the sheer number and size of pull requests, it’s become difficult for humans to decide whether the code is good. Yes, there may still be some AI “slop” in the codebase, but depending on the change, looking through hundreds of files and hundreds of lines of code can take humans hours, while it can also take AI minutes or seconds. Mike came to the same conclusion in his slides.
He introduced us to James Reason’s Swiss Cheese Model. The Swiss Cheese Model framework explains how accidents happen in complex systems because of layers of failure. If you can identify all the different failure points and work to mitigate those risks, you can lower your exposure to accidents. You may never reach 0 risk, but by adding different layers, you can get close. So, in Mike’s example, after telling the Orchestrator to work through a ticket, a worker would do the work, pass it off to a fresh model to review it, the next Copilot within GitHub would review it a second time, and a security scan would run. Once both passed, a PR explainer would walk through the code and provide screenshots. Finally, once those four steps are complete, a human-in-the-loop would review it, with teammates and the person who opened the PR looking it over. Once everything is validated, the code would be merged. This is something I’ve been considering for myself and my work: how I can minimize my risk when using Claude Code and other AI Orchestrators to do my work for me, and how I can spend less time trying to understand what they produce.
The second presenter of the night was Hayden Goldstien from Greenhouse Software, presenting “Building the Agentic Harness Your Business Actually Needs”. In this presentation, Hayden briefly described how Greenhouse created its own internal coding agent called Spider Plant. With many companies talking about creating software factories to replace developers and downsize their orgs, essentially, Greenhouse took a different approach when they built out Spider Plant. The goal wasn’t to be a software factory, but a maintenance factory. As a maintenance factory, its job is to do all the work developers dislike. That includes paying attention to Dependabot Alerts, fixing CVE issues, checking observability alerts, and acting on them.
By building a maintenance factory that automatically handles those areas via MCP tools, it frees developers to work on new features instead of maintaining what’s already been released. Hayden shared a slide showing how many PRs that spider plant opened in October 2026, and it was amazing to see how much work it did and how much it cost since its inception. I don’t remember the exact date, but it was only around $35 vs. the unknown number it might have cost if a developer(s) were doing it themselves. The ultimate goal for this maintenance factory is to, hopefully, at some point, do enough work to hire five new developers, I believe he said, with the time/cost savings the factory is providing.
Overall, I’m really happy that I got back out there and attended last night’s meetup. It was great to meet new people, see what people are building at their companies, and expand my knowledge. The idea of building a maintenance factory instead of a software factory sounds interesting, and combining that with what Mike discussed—minimizing human interaction to release those maintenance issues — sounds like a fun problem to solve; I’m really looking forward to the next one.