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.

I think a lot about what the future will look like. I always did but even more so since I had a baby. To me it feels like we’re not in a steady state right now. Things are volatile and changing fast. It feels like this pace of change can’t possibly last forever. But it also seems obvious that LLMs are going to dramatically change the nature of my work, and many types of work, permanently.

I am effectively required to use AI at work now, so for now I’ve decided to accept that reality, remain employed as a software engineer, and learn how to use these new tools well. At this point I can’t see software engineering ever going back to the way it was before coding agents. But finding these tools useful doesn’t resolve any of my reservations about AI adoption more broadly, especially with how the main companies selling it act in society.

If anything, using AI every day has made the tension more obvious to me. I think it's possible for a technology to be genuinely useful when applied well, use it regularly, and still insist its makers be accountable for its externalities. AI may be unusually capable and unpredictable, but unpredictability does not erase the responsibility of the people who build, deploy, profit from, and use it to act with care in society.

Upon closer inspection, they are all calling for the same thing: a view of AI systems as being so advanced and capable that no entity, human or corporate, could possibly be responsible for their actions. … This narrative is gaining traction as AI models become more complex and frontier labs reveal their incapability of containing the agents they’ve built. But we need to be careful not to buy into a carefully crafted fiction at the expense of real human lives.

I agree. I think this notion that increasing the sophistication or unpredictability of a tool somehow absolves its makers of any responsibility for its use is absurd. This is the perpetual fight the tech industry keeps having with governments and communities. Regulation has never been able to keep up with technology, and every time companies release a new capability they deploy it at enormous scale and then argue that because this technology is bigger or more sophisticated or whatever the existing expectations around liability and responsibility no longer apply. But scale and complexity don't erase accountability.

If you build a system, decide how it operates, where it deploys, profit from its operation, and have the ability to reduce the harms it causes but simply refuse to do so, you do bear some responsibility for those harms.

The fundamental flaw of framing AI as “conscious” by borrowing the language of neuroscience or animal rights is that it conveniently clouds the issue of what AI is: corporate-built software, with countless billions of dollars in investment behind it and an expectation that countless trillions of dollars in revenue will be generated from it for a few builders and investors.

I think this really gets at one of the core ethical issues with AI and how the companies developing it operate. There are some benefits to AI, but they almost exclusively accrue to a small and elite group of tech industry leaders. The costs and harms, meanwhile, are externalized -- onto creators whose work becomes training material, people subjected to synthetic abuse, workers whose jobs are disrupted, communities absorbing infrastructure and environmental costs, and ordinary people who become unwilling participants in experiments conducted at enormous scale. The asymmetry matters.

If society and average people are expected to tolerate substantial risk and disruption for the sake of pursuing the frontier, there needs to be some commensurate, convincing public benefit. Making a small number of already unimaginably wealthy individuals vastly wealthier is not a good enough reason for the rest of us to take on these risks.

There are currently dozens of cases around the world in which AI companies have been sued for a wide range of abuses. Grieving loved ones, aggrieved creators, and violated individuals have accused companies of willfully enabling self-harm or harm to others, generating child sexual-abuse material and nonconsensual nudes, reproducing copyrighted materials, and provoking psychosis.

Like any problematic technology, it’s really easy to overlook the harms it causes when we are benefiting from it. This isn't unique to AI, but it raises important questions around accountability. When a technology has both beneficial and harmful uses, the question becomes how to develop and deploy it responsibly. We should not just accept "we have no such obligation" as an answer.

Systems do not “attack” because they went “rogue” or are “manipulative” or “malicious.” Harms occur because companies were negligent in their rush to sell their products to as many people as possible to meet revenue targets.

I think this is very important distinction. When an AI system causes harm, describing the model itself as "malicious", "deceptive", "rogue", or "out of control" obfuscates the chain of human decisions that put it in a position to cause that harm in the first place. People built the model, trained it, set up the safeguards, and chose the conditions under which it got released. A small group of humans made deliberate decisions on behalf of everyone else about what level of risk was acceptable.

Responsibility can be distributed but it cannot be abdicated. Otherwise we end up with an untenable accountability vacuum where the more powerful and autonomous a technology becomes, the less responsibility its creators bear for deploying it. That is obviously backwards.

Discussing AI in anthropomorphic terms is a trap, distorting a legal system intended to protect us into one that protects corporate interests at the cost of countless human lives.

I think this is at least one small thing we can do to steer the conversation in the right direction. Language matters. It's easy to slide into describing agentic systems in anthropomorphic terms, but we have to draw a line where that metaphor starts implying legal and moral consequences. AI is a technology, a tool. Not a person, not an independent actor with agency or an entity separate from the person using it. It is built, owned, operated, and deployed by people.

We have to hold those wielding this tool accountable for the harm they cause or we will be living in a world where those with access to it are free to act with impunity destroying the lives of those who don’t.

I can now hand much of the mechanical work to an AI coding tool, then spend my time fixing the interesting parts.

This has been my experience with vibe coding too. On the surface, my coding agents can produce incredible apps very quickly. Once I start actually trying to use them, there are endless paper cuts to fix.

Programming becomes part of using a computer, whether the user calls it programming or not.

This does seem true. Not everyone will become a "programmer" in this sense, but many many more people will, the same way many people use spreadsheets or other similar tools to get their work done.

Traditionally, the software industry has optimized for products that can support large audiences: companies, engineering teams, sales organizations, and lots of customers who, in aggregate, will pay enough to justify building the product. That makes sense when software is expensive to build.

This is a really interesting way of putting it. Finding people to pay for your software is always the challenge.

Finding someone to write and maintain a narrow program used to be the primary bottleneck. Now, the challenge is recognizing when a “throwaway” tool has stopped being throwaway.

This is a great way to frame all of the ad-hoc development happening now. LLMs writing code is cool and fast for sure, but it can be very very annoying when you need the software produced this way to actually work.

Before building your next program, I recommend you ask three questions:

1. Does anyone else depend on it?

2. Can it change or expose important data?

3. Would work stop if it disappeared tomorrow?

If the answer to all three is no, treat it like an experiment, not a product. Build it quickly, skip the formal engineering process, and expect to delete it.

If the answer is yes, add only the structure you really need. Give it an owner, list its connections, limit its credentials, and make failures visible. Then, have a plan for how it gets repaired, replaced, or retired.

The amount of engineering process should follow the consequences. A disposable tool can stay disposable. A tool people depend on needs an owner, tighter access, and a plan for keeping it working.

I really love this framework, I think more people should adopt it. These are very sensible guidelines for vibe coding.