Introducing Workers IO Agents are making it possible to turn ideas into software faster than ever. To keep up with that, we need better ways to understand how our software will behave in real-world. Workers IO runs your entire system through millions of simulated futures, exploring what happens when machines fail, networks slow down, and events arrive in the wrong order. It searches for the combinations that break your system before your customers encounter them. Every failure it encounters is perfectly reproducible, helping teams understand what happened, work on a fix, and verify against the same scenario. This ability changes what teams are willing to take on. Difficult engineering decisions become things that you can explore and verify. That’s the future we’re working toward: small teams building increasingly ambitious systems, with the evidence to stand behind. I can’t wait to see what you build with that confidence.

What we are building will change how mission-critical software is built and verified Here's Rick & Morty to tell you all about @workersio

What we are building will change how mission-critical software is built and verified Here's Rick & Morty to tell you all about @workersio

What we are building will change how mission-critical software is built and verified Here's Rick & Morty to tell you all about @workersio

Security will become a larger and larger function in software companies. Security is verification engineering (eg: “my code is probably memory-safe”), as well as capital allocation (“what surface should I throw most tokens at?”) For startups, it’s a challenge and opportunity. As the world’s paranoia grows given ever-more-sophisticated AI adversaries, how can you trust a 2-person-and-a-dog company? But conversely, given the dire state of global cybersecurity and increasing reliance on centralization, as always, there’re vast areas that small teams can now disrupt that I’m excited to invest in.

We'll be spending a lot more time trying to understand the outputs of language models. A few thoughts, tips & tricks: Writing. Something I've had success with: Ask your LLM to explain something in ASD-STE100, it's a controlled language specification originally developed for aerospace maintenance documentation. LLMs well-versed in this language and it comes with heavy constraints on clean writing style that I often find a lot more readable. Sometimes I've tried to soften it a bit e.g. ask for "80% of the way to ASD-STE100" because the spec is quite stringent. But even better: Diagrams / images. Instead of writing, ask your LLM to create a diagram. These can be a lot easier to process, parse, and understand. But even better: Web pages. Ask for output "in HTML" to get a beautiful, interactive webpage. LLMs are getting really good at frontend and can create beautiful experiences, animations, etc. But even better: Explainer videos. The output format I am most bullish on is fully custom / bespoke explainer videos generated on any arbitrary topic. Experiment with things like "Create a 3b1b style video explainer on X. Use my ElevenLabs API key for audio narration". (you'd need an API key for the latter or you can ask your LLM to find you decent free alternatives that use your local compute). This is actually starting to work! In summary: - As LLMs get better, they will do more and more of the legwork autonomously, and a lot more of our work will rise up the abstractions into oversight and understanding. - Luckily, LLMs can help here too because as intelligence and code are increasingly abundant, you can ask for large, custom, discardable software artifacts (e.g. web apps, video explainers) that would have never made sense to create before. Push the boundaries here and you'll be surprised.

We’re organizing Vibecheck, a formal methods hackathon with some of the best folks in the space - @maxvonhippel, @qd_forall, @nolanlwin, @jessemhan, @emiyazono, and @workersio. You’ll get a weekend to build real production software, and formally verify it. We’ll have people who really know their stuff around to help, and you can come with a team, find one there, or just hack on something yourself. We are glad to have a phenomenal group of sponsors, including @harmonicmath, @mathematics_inc, @theoremlabs, @thegp, @omnicom, @primeintellect, @astriolabs, @buildwithparty, @wearerandomlabs, and @lanyon_ai, as well as some more we will announce in the coming days! If you’re a hacker, a formal methods person, or just someone who thinks “how do we know it works?” is an interesting question, we’d love to have you. Signup Now: fmxai.org/vibecheck/

I used Opus 5.5 to formally verify the Claude Agent SDK using Lean. A couple short prompts = 16 PRs fixing various bugs and race conditions. Video attached. TLA+ also works well. I sometimes combine Lean and TLA+ to look for issues around data flow, concurrency, and state mgmt. I don't know either language well, but Claude is excellent at both. This approach is super useful for formally modeling your code and finding bugs that a human probably wouldn't have spotted. Is formal verification the future of coding (or at least, bug finding)?

There's been a ton of talk about the role of humans in code review, and when and how humans should be signing off on changes. I believe that, long-term, humans have no role in routinely reviewing code.

Our product accidentally found a bug in Postgres! I always hold my company to the highest standards when it comes to software verification. One of the internal metrics we track is how often we find rare correctness issues in some of the world's most well-tested systems. Some of the customers we work with are building things where any unexpected failure could be catastrophic. That often means we verify all the upstream dependencies their products rely on in our environments, too. Sometimes, that turns up interesting findings like this one: while verifying a customer’s software, our simulation engine found a rare bug in Postgres.

Introducing pgrust v0.3: the bug-smashing release. We evaluated pgrust v0.2 and v0.3 against the same held-out corpus: 164,000 test cases from 50 open-source projects. pgrust v0.2 diverged from Postgres on 1,454 cases. pgrust v0.3 diverged on 11. pgrust is 300x faster than Postgres for analytical workloads, and we're a drop-in replacement. Held-out corpus included: @djangoproject, SQLAlchemy, Hibernate, @rails, and more. @pgrustdb is now much more Postgres-compatible and reliable than before. @JasonSeibel and I don't recommend running pgrust in production (yet), but we are successfully running it ourselves internally. - @AntithesisHQ and @workersdotio for simulation testing - Detail.dev by @danlovesproofs for LLM-assisted code analysis - Multiple home-built differential fuzzers - Kani for formal verification Our goal is for pgrust to be truly 100% compatible with Postgres. There are still bugs. You should still run Postgres for any data you can't afford to lose. But we want people trying pgrust on real workloads in non-critical environments. If you need Clickhouse performance queries in Postgres, are frustrated by the many gotchas in Postgres, or just geek out about databases and Rust, feel free to send me a DM as we would love to chat.

A decade later, I’m starting up again. I sold my first company ten years ago and have spent the years since working as an engineer. Now I’m building @workersio as a solo-founder. We’re living in a new era where an agent can write software faster than a team of 100 engineers. As software becomes more autonomous, I want us to raise our expectations and take more responsibility for what we build along the way. Software can have a long half-life, and over time it becomes critical in ways we never planned for. Businesses, and sometimes lives, end up depending on decisions (or our agents) we make. For the longest time, building reliable & verifiably correct software systems required resources that only a few teams could afford. I want to make those capabilities widely accessible, especially as more teams take on ambitious problems and build more of their own software in-house. Our ambition is to make five nines of availability and verifiably correct the default for software in the agent era, so the software running our world becomes more dependable as it becomes more capable. I’m excited to share that we’ve raised from @ycombinator, @solofounders, and an incredible group of angels - @Joshuabrowder, @tylerwillis, @ericbluewatch, @gshewakr, @jaentwistle and some friends and customers. This is the mission I’m committing to for my next moonshot; I’m grateful to everyone helping me bring it to life. If this mission excites you, I’d love to hear from you. Whether you want to work with us, help us along the way, or exchange ideas about where software is headed, please reach out.

A decade later, I’m starting up again. I sold my first company ten years ago and have spent the years since working as an engineer. Now I’m building @workersio as a solo-founder. We’re living in a new era where an agent can write software faster than a team of 100 engineers. As software becomes more autonomous, I want us to raise our expectations and take more responsibility for what we build along the way. Software can have a long half-life, and over time it becomes critical in ways we never planned for. Businesses, and sometimes lives, end up depending on decisions (or our agents) we make. For the longest time, building reliable & verifiably correct software systems required resources that only a few teams could afford. I want to make those capabilities widely accessible, especially as more teams take on ambitious problems and build more of their own software in-house. Our ambition is to make five nines of availability and verifiably correct the default for software in the agent era, so the software running our world becomes more dependable as it becomes more capable. I’m excited to share that we’ve raised from @ycombinator, @solofounders, and an incredible group of angels - @Joshuabrowder, @tylerwillis, @ericbluewatch, @gshewakr, @jaentwistle and some friends and customers. This is the mission I’m committing to for my next moonshot; I’m grateful to everyone helping me bring it to life. If this mission excites you, I’d love to hear from you. Whether you want to work with us, help us along the way, or exchange ideas about where software is headed, please reach out.