BugBash 2026 - We have won, now let's keep winning
I. We have won, what now?
Meeting your 'internet' people in real life is bizarre. You've been following them on the interwebs, potentially for years, and always rationally knew that they are real. But still, when you see them in the flesh for the first time, it's like they finally emerge from Narnia, come to Earth, and your brain reclassifies them into the 'indeed exists' category.
Last week I was at BugBash 2026 and it was a blast. I learned a bunch, added loads of folks to my 'indeed exists' folder1, and heard we had won?
Winning in the sense that all the software correctness nerds can exclaim 'I told you so!'. As Will Wilson opined in his opening keynote, with the onset of code-slinging AI agents, the crux of the thing is now in verification. After all, you can only progress as fast as the slowest step in your process.
If code authoring is faster and/or cheaper, more pressure is felt elsewhere - product discovery, prioritization, maintenance, and of course, testing and verification.
All of a sudden, niche techniques like property-based testing and formal verification are penetrating the general developer's mind.
Google Search trends for property-based testing showing a flat line (little interest) for years, up until a sudden spike at the end of 2025 and beginning of 2026.
So here come the masses, hungry for our humble fiefdom of software correctness. It might be jarring, says Will, as with growing popularity comes money and with money comes grift2. However, we should approach this with kindness, teach the newcomers and even hope to convert the midwit to our ways.
Personally, I think we have won. The slop factories gave the software correctness cause a good boost and fresh wind in the sails. My hope is that we can keep winning. That we can harvest this newfound interest to inspire folks to increase quality, rather than make code go brrrrrr even faster.
The more you know, the more you know you do not know
Even though I was comfortably beyond the Dunning-Kruger peak of confidence when it comes to software correctness, I can report there are many more things I now know that I do not know.
- From Peter Alvaro, I first heard about metastable failure, continuous time Markov chains, and Descartes.
- From Deb Chachra about the 'social license' to operate infrastructure and relational ethics.
- From corwin about goodput (haha) and building systems with throughput in the petabytes per second.
- From Gabriela Moreira about Quint and formal verification.
- From Steve Klabnik about being Pittsburgh (... or Steve's dad?).
- And much more from more folks!
II. What about the noobs?
Naturally, being an inexperienced engineer (certainly relative to the crowd at BugBash), I was eager to hear any takes on development and junior engineers.
The presentation that struck closest here was from Ben Eggers of OpenAI. In short, Ben made a point that engineers should still 'do the lead work' - designing interfaces, contracts, and components - only letting AI agents fill in the implementation blanks.
After this presentation, I got to ask him what he thinks this means for junior engineers.
Juniors would normally learn how to design good interfaces by first using them when doing the grunt implementation work. With this work delegated to agents, how do juniors progress to being able to 'do the lead work'?
Ben offered that 'the lead work' is a different skill than the implementation, so perhaps juniors can skip straight to 'the next level'.
Personally, I wonder if that is possible. To me it seems that the pain of having to use and implement the interfaces you (and others) design is a key step in learning what a good interface looks like.
With LLMs optimized for sycophancy user engagement, I doubt we will get to a point where an LLM will push back when tasked with implementing a crappy interface. One can certainly iterate with the agents, ask for feedback and alternatives, but in the end, I don't think you can develop the same intuition and taste this way.
Time will tell. Personally, I plan to keep writing code by hand, probably most of the time3.
III. Buildings do not fall down
Like the presentation from Deb Chachra about physical infrastructure, Brian Potter's keynote about buildings (not) falling down was such a treat. After all - if we care about reliability, why not hear from experts in industries with actually reliable products?
One of the reasons for the reliability in construction is the conservatism of the structural engineering profession. They use the same materials, maintain skepticism toward new building techniques, and eschew devitations from established design patterns. In sum, structural engineers choose boring tech.
And a fun fact - the design budget is only ~2% of the overall cost of construction.
IV. Thank you and until next time!
I would not have been able to come if it were not for the generosity of the organizers - thank you Antithesis and the organizing team, thank you Carl and TW!
It was a blast, a pleasure to meet everyone, and I hope to be back!
Antithesis' Snouty hanging out with Heihei and Stitch on my work desk at home.
Ping me on Bluesky or LinkedIn.
I had breakfast with Kyle Kingsbury on the first day. Whaaat. Surreal to meet someone whose work greatly contributed to my interest in software correctness.↩
Reminds me of Master Yoda: "Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering."↩
Further reading on this - here, here, here, here, here and here.↩