This really resonates with me. I’ve found myself reading less and less code and spending more and more time building what could broadly be described as verification systems. I wonder sometimes if that’s crazy, but at the same time I’m getting better results than ever.

Throughout history, we’ve written code so that it is clear and concise; so that it’s easily read and maintained. We do this to be nice to the people who come after (including ourselves). We do this so that we can write tests and make sure they work and so that when something fails, we can troubleshoot it.

It’s worth reflecting on why we cared so much about code quality. I always cared more than anyone on any of my teams. I was the biggest advocate for open standards and best practices and idiomatic code. I still am, though, I just don’t think I need to see the source code to judge these things anymore.

The idea of an AI generating code that is reviewed by another AI that is then possibly deployed by yet another AI terrifies me…

I’ve learned to conquer that fear by releasing more often. By automating things and releasing more frequently, I have to build code that I trust.

I’ve come to the same conclusion. Shipping more frequently forces a discipline it was easy to get by without before. It used to be so slow to write code that preparing a release and shipping it used to be a relatively minor extra step. Now you can have new releases ready to verify and ship as frequently as you want, so it really forces us to be specific and clear about how we know the release is ready. It’s not feasible to manually QA every release end to end — it never was — so we have to invest in automated verification.

If the code does what it’s supposed to, it does it as fast as it’s supposed to and as reliably as it’s supposed to, and it deploys properly and holds up to stress and fuzz testing and benchmarks… do I still care what the code looks like?

This is where I’ve landed too. If the code demonstrably works, do I need to personally review every line? I’d say no.

If we can automate confidence measuring in human-generated code, then we can do the same for AI-generated code.

I’ve basically accepted that this is my job now, i.e. building these automated verification systems. In a way it’s not all that different than before, it’s just a much bigger part of the job. We use closed-source software and systems in our software all the time, sometimes on critical paths. I thought about how I used to handle integrating some database or other proprietary library or third party service. There are many ways I would convince myself it was doing what I wanted. I don’t see this way of working as all that different.

I’m looking forward to reading this series by Tim Pratley. He’s an author and engineer I have a lot of respect for and I’ve grappled with a lot of similar thoughts he raises here. I always appreciate data-driven arguments and an approach to topics like this based on convincing your audience with evidence.

When everyone has a chance to participate in the economy we get more ideas, more productivity, and more opportunity. Extreme wealth concentration blocks innovation and limits broad prosperity.

This only makes sense to me. I think disagreement arises around what we mean by “participate in the economy”. I’d argue that working for wages to survive is not meaningful participation. When people aren’t free to pursue their ambitions or desired careers for whatever reason (sometimes education is too expensive, or maybe they’re stuck at a current employer because they need to retain certain benefits, maybe they can’t afford to move to where the opportunities are, maybe the job market isn’t recognizing their skills, whatever), that limits their potential contributions to society in ways that only limit innovation and degrade overall prosperity.

My nephews and nieces have entered a workforce that offers none of the opportunities I had. Humanity is on a long-term positive trajectory, driven by knowledge creation and sharing, yet we are clearly self-inflicting unnecessary pain in the short term.

This has been on my mind a lot more since a had a kid earlier this year. The world is already unrecognizable to me relative to when I entered the workforce. The way I got into tech and built my career would never work for someone starting out today. I wonder what the world will be like by the time my child reaches working age. I really hope we’ve figured out some of these problems by then and want to be part of the solution.

This is a cool example of the kind of problem that Clojure makes so much simpler to solve. Having a coherent model of time and not sharing mutable state makes parallel computing so much easier, because you’re not trying to coordinate multiple mutators contending for a shared resource. If you just don’t share the resource and let the language level primitives handle serializing operations for you, you can stop worrying about entire classes of bugs and just focus on your problems.

The ideas parallel servers reinvent by hand - immutable snapshot, pure read phase, changes as data - are the language's defaults. If writing from many threads is difficult, then don't write: all game logic is pure functions (fn [world events]) that read the snapshot in parallel and return changes as deltas, merged in one place. The merge preserves order, so the parallel run is bit identical to the sequential one, and no mechanic cares how many cores it runs on.

I think it’s so cool when people experience the benefits of Clojure’s paradigm in real projects. It’s often a tough sell at first but it really is amazing how far you can get with pure functions operating on immutable data. My favourite way to fix bugs is to just make them impossible by default, which often means rethinking the way your program models the world and time. It can be a bit trippy at first but it pays off.

AI is everywhere now and most people hate that, at least in the West. I can understand why. I have to use AI daily now for my work as a software engineer, and increasingly many things I build are effectively some version of “use an LLM to make this feel like magic”. I can appreciate the sentiment behind this in the sense that LLMs appear remarkably capable when asked simple questions about a number of topics, but it is also way too easy to just throw an LLM into the mix and actually end up making everything worse. The industry has vastly underestimated the amount of engineering discipline it takes to make LLMs actually complete tasks reliably or do anything useful from a normal person’s perspective. Which IMO is a big part of what is behind the general disapproval of AI outside the tech industry (among many other reasons).

The overarching principle I wish all product engineers would adopt in their approach to integrating “AI” is that it should always remove friction, not create it. If your “agent” is effectively just throwing up walls of text for me to review, that is not helpful. Other things that are not helpful:

• making decisions that I have to figure out how to go double check or undo
• doing things on my behalf that I have to correct
• impersonating me

Hopefully you get the idea. If you are embedding AI into a product that people use, please ask yourself before you ship “does this make my user’s life better or worse?” If it adds friction to their experience in any way, do not ship it. Fix it first so that your users genuinely benefit from this new integrated “intelligence”, such as it is, and make sure it’s not just another thing they have to work around or figure out how to disable to use your product.

One of my summer jobs in university was working in an analytical chemistry lab. I spent countless hours pipetting liquids from tube to tube, scanning labels, manually entering data into spreadsheets, and operating fancy machines. Even way back then (please don’t ask exactly how long ago 🙈) I couldn’t help but think “we must be close to automating most of this work”. Turns out we were not, but with this announcement I think its closer than ever.

MHS enables AI agents to operate multiple lab and manufacturing instruments, such as microscopes, liquid handlers, and robotic arms, in parallel, and perform intricate tasks ranging from routine drug discovery experiments to laser calibration on a quantum computer.

This is a really cool development and one way I could imagine AI having some genuinely beneficial impact on society. I think we’re arguably living in the bad timeline right now and unless public opinion shifts pretty dramatically somehow it will be difficult to get to a place where AI does more good than harm. Part of getting there is delivering some credible public benefit for all the cost and risk the public is expected to bear as a result of its development and deployment. I think meaningful progress in drug discovery is a potential area where that could happen.