I wanted to understand what happens after we ask a database to save something Here’s the journey from a simple map to an LSM tree.

The answer is in the systems built by cloud providers. Formal methods are one of the arrows in our arsenal. DRT, DST we have all these layers and I envision this like a funnel in the verification system design. Each layer catches something the previous failed to catch

All these new IDE experiences that require switching between editor and agent modes feel bad adds extra cognitive load to already fragmented attention. Need a better solution for this

Had a great conversation today with a colleague on whether compilers are dead. It left me with more optimism than I had going in. Basically the argument is this. Given a program, an agent can probably optimize the shit out of it burning a bunch of tokens. But what happens when you have multiple coordinating agents? Maybe they will discover the power of abstraction. Certainly they need to divide up work and collect it back. They would need to trust each others' work. Then we'll get greedy and ask them to optimize many programs. They can continue burning tokens on each program, but soon they'll discover they're doing the same thing over and over again. So they'll discover compilers. Then they will realize that they need to re-prove at a lower level what seemed correct at a higher level. So they will discover correct-by-construction compilers. The future will be fine. Languages may change, but the concepts will endure. The same things that humans need to collaborate will be needed when agents collaborate.

Pleased to announce my first @AntithesisHQ project: a property testing webinar! In property testing, instead of checking "this input to the function has this output", we check "given a million random inputs, all the outputs have this property". PBT has been around for a quarter century now and is fairly well known in functional programming and distributed system circles. Which is why we're gonna do something very experimental and target a community that almost never uses PBT: web developers. See, there's a thousand PBT tutorials out there, and they all use examples like "reversing a list twice returns the original list" and "add(x, y) should return the same result as add(y, x)". These are stateless properties on the code's functions, where we randomize inputs to a fixed test sequence. People have a hard time finding useful stateless properties in their systems. I've come to believe that most intuitive and useful business properties are instead stateful properties on what must always hold about the system's states. For example, "our total spend is always below our budget cap", or "two talks must never be scheduled for the same room and time", or "free users can't access premium features". We can property test these by randomizing the test sequence itself, to simulate a user doing whatever the heck they want, and testing that no matter what they do, our properties still hold. So, if you've ever had your data model get corrupted because you forgot to validate one update method, or seen a 500 when the user clicks `send` three times in a row, or gotten mad at SQL for not enforcing cross-table constraints, this webinar is for you. We'll be live on October 29. Sign up here: pages.antithesis.com/webinar…

Watching @jamesacowling’s distributed systems talk, one point stuck with me: many developers don’t care about low-level details like filesystems, CPU architecture, or how code is compiled. With AI, some are now also losing touch with how their own systems work. The highest-leverage engineers in this new AI era will care about both. There’s no shortcut Great talk, @jamesacowling and @TigerBeetleDB and excited to checkout @convex which I haven't used before :(

In 30 minutes!

company OS (org harness) vs personal agent, similarities and differences: differences: - Many principals (users), one actor (agent): will need to be multiplayer, handle multiple users (sometimes even in same thread), and as a result handle auth/memory correctly - governance: observability, auditability, admin control plane matter way more - interaction pattern: more event driven and async similarities: - should be able to write/execute code - browser use likely very important! (key difference from a coding harness) - skills/MCP as standards - core agent loop/logic what am i missing?

Can't move beyond services. We have cheap labour so throw a number of them at services and celebrate the hyperscale and mediocrity

Synchronous Core, Async Edges the new superpower

software is far from solved. a glimmer of ponderoos as to what 2026-2027 is as follows: we need better tools, compiler engineers are about to enter into a renaissance era when inferencing capacity is no longer the bottle neck, it becomes the compiler and verification tool chain problem. you want a decent amount of back prsssure on per unit of change but if that backpressure is too slow it punishes LLM mistakes thus reduces the amount of cycles per minute. what matters is being able to read a file, build an application and run tests in >milliseconds< programming language authors that focus on this and utilise llms to accelerate them and their community with an intense focus on cycle times will get ahead as it’s a safe bet that inferencing speed won’t be a limiting factor in the very very near future. it’s verification and how fast you can verify and pump the result back into the inferencing window.

I'm stoked to author another blog post with @AntithesisHQ ! Distributed Systems + AI + Mutation Testing = Vibes with High Confidence Bonus: 3 serious rqlite bugs that Fable couldn't even...

What does the future look like? Review tools, powered by LLMaaJ-style techniques, static analysis, and automated reasoning methods. Principled approaches to testing and validation (PBT, DST, model-guided fuzzing, etc). Correct-by-construction techniques.

💯

In 30 minutes!

Been there, worst nightmare for senior engineers

I'm very sensitive to this feeling, cause I've been there. Someone does something cool, gets a lot of attention, and you're frustrated cause you already did it, a while ago. It's not enough to do things, you must also tell people. Maybe it's not fair, but it's true

recommended reading, with the caveat that i think the article goes too hard on bend 2. the kernel: you often only understand a problem by experiencing the journey, i.e. building a solution for it. if you hand that journey off to an agent, you will get something. but not necessarily something good, or even correct. blog.liampwll.com/posts/bend…

I really liked @typesafeai’s onboarding experience. It tells you upfront what to expect

All I see in my tl is Jev

The "whiteboard defense:" I should be able to pull you aside at any moment and ask you to explain any customer-facing system you've shipped. You should be able to clearly explain how it works and defend the decisions you made. This is my benchmark for responsible AI usage. I don't expect line-level familiarity with the code. I don't care if you remember the exact function name or implementation detail. You may not even know it. I don't care. But if I ask "why did you do X instead of Y?", "what happens if this actor behaves maliciously?", "what data structure did you use here and why?", or "where does this fail?" you should be able to answer confidently. For PoCs, demos, experiments, whatever: I don't care. Generate 100% of it and understand none of it. Speed over quality every time in those specific scenarios. But if you're shipping customer-facing work, you can't be shipping things you don't understand at a high level.