Links/2026×/22 entries

I apparently can’t hold a conversation with a friend, post on social media, or even daydream idly without the topic eventually turning to bloody A.I.

It’s not always me who brings it up, but it often is; I’ve rarely known such a “sticky” subject.

This resonates. Unlike Oliver Burkeman I do use AI more or less all day every day at work. But I also find myself talking about it so much more than I need to.

One answer is that the general topic is an unusually powerful trigger for a major disease of our times: overthinking.

This is an insightful take. Whatever you think of AI, it is upending many industries very quickly and has implications one way or another for the future of society. Whether you’re for or against, whether you use it or not, it’s become very difficult to ignore its pervasiveness in day to day discourse anymore. This diagnosis of the reason being that it naturally triggers all kinds of pre-existing neuroses about our place in the economy, the nature of our relationships, even what it means to be human in the first place, seems apt. These are all heavy, anxiety-inducing topics for many people and the way AI is often discussed very nonchalantly by those creating it as though it might ruin all of our lives is a bit hard to ignore.

Whatever the details, this is where overthinking kicks in, because it feels like the solution to the anxious feelings in your body is to scurry off into your head and think some more, read some more, argue some more, maybe use A.I. some more… But scurrying off to your head doesn’t work…

I think this is one of the key things software people get wrong about the world, and the source of a lot of the friction the tech industry is running into with regards to AI adoption. There’s a pervasive tendency among us to really highly overvalue intelligence, but not every problem can be resolved by just thinking harder.

Lives immeasurably fuller and more interesting than can be dreamt of in Silicon Valley’s ideology. Lives that encompass vastly more than what software can do.

I find this vision of what a good life can be so much richer and more appealing than what’s on offer in my tech bubble. It’s important to remember this. At the end of the day computers are just tools we can use to facilitate some of the things we want to work on, but have very little to do with what it means to live a full and interesting life.

I was excited to see that this is the first module in a new Coursera course I'm doing. I've long thought that ethics are missing from software development, and I think it's more important than ever to care about the consequences of what we're doing and building in this age of AI. This course on building agents literally opens with this statement:

This module is for professionals and data scientists aiming to build responsible AI.

I'm really heartened to see that building responsibly is becoming a legitimate concern, at least in some corners of the industry.

By bridging theory and practice, the program empowers you to lead initiatives that prioritize accountability, ensuring your AI systems deliver immense value without compromising integrity or public trust.

I'm looking forward to this.

Well this is awkward. Literally yesterday I wrote “the hard part of software engineering was never writing the code.” I concede that that way of describing what’s happening to the software industry is a bit lazy and exaggerated.

Nobody knows how the AI revolution will play out in the end, but it is clear many aspects of work and life will be transformed—including programming.

This definitely feels true to me. My day to day is already completely unrecognizable compared to a year ago and I wouldn’t have known how to even begin describing the nature of my job now if you’d asked me to only a few months ago.

If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)?

This is answerable though, in terms of economics. How hard a skill is isn’t what determines its price. It’s true that a very small proportion of the labour force is willing to put up with solving abstract symbolic logic puzzles for 40 hours a week, but the main reason software engineers are so highly paid is more because the marginal cost of scaling software is effectively zero than anything to do with the work itself. Lots of jobs are harder and pay less.

I have met many programmers throughout my career, and very few of them want to talk to stakeholders, much less customers (exceptions are freelancers and founders, especially of software development shops). And, “having clarity on the priorities” boils down to “just tell me what to do and don't switch it up every two days

Relatable.

Whoever you are, don't outsource your understanding, judgement, empathy and taste to AI.

This feels like the most important takeaway for this moment. What drives me more crazy than anything else these days is people trying to pass off AI generated output as their own. It’s lazy and inconsiderate to ask someone to read piles of slop on your behalf, but that’s not even what I hate the most about it. It’s the abdication of our unique human ability to relate to other humans that gets me. I wish people would stop pretending like generated AI output could ever replace human interaction.

I’d never heard about this conference before, the talks look super interesting. I wish more people in the industry cared about working software. The bar seems to only be getting lower in this age of AI. I always love finding a batch of new people to follow and new conferences to daydream about attending.

This is a great write up about how Airbnb ships AI features that actually work. Basically, the answer is they test them. What a concept! It sounds really dumb and obvious when you say it out loud, but it’s been surprising to me how many teams are shipping LLM-based systems to production with no test harnesses or evals at all.

Expect to spend a meaningful share of your total project effort on evaluation. This is not unnecessary overhead, it’s how you build products that actually work.

This is anathema to the way of working that the types of people who love AI default to. The industry is overrun right now with enthusiastic “builders” who care much more about velocity than quality. AI has made a lot of people think shipping software is easy because shipping vapourware demos has become 1000% easier than it used to be. But a prototype is not a product. Making software that works for you on the happy path is genuinely easy now. But making it work for someone else on the actual wild internet is still extremely difficult. As a user of many software products, I can say I wish people cared a bit more about whether their AI features worked in production.

To understand what a swarm of tens of thousands of automated actions did…

This is a really interesting preview into the scale and type of attacks that are bound to become more common in this age of ai.

Thanks to this approach, we were able to do in hours what would usually take days, and match the adversary's speed.

Useful perspective, if you’re not already using AI to secure production, you’ll have to start. It makes sense that there would be no way for a team of unassisted humans to keep up with the sheer scale of a frontier-model-driven attack.

When we started the log analysis, we first used frontier models behind commercial APIs. This did not work: the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker. We ran the forensic analysis instead on GLM 5.2, an open-weight model, on our own infrastructure.

This is the inevitable result of the so called “guardrails” frontier labs have placed on their models. It’s also a bit egregious that they themselves are free to let their most powerful models run in the wild with no such guardrails in place. I don’t think we want to live in a world where the people currently deciding who has access to these tools are the ones who currently do.

This experience points to a gap worth planning for. We do not know which model powered the attacker's agents, whether a jailbroken hosted model or an unrestricted open-weight one; either way, the attacker was bound by no usage policy, while our own forensic work was blocked by the guardrails of the hosted models we first tried. The practical lesson for defenders: have a capable model you can run on your own infrastructure vetted and ready before an incident, both to avoid guardrail lockout and to keep attacker data and credentials from leaving your environment.

This is an extremely important takeaway. If your plan for responding to these incidents is to use a frontier LLM via their commercial API, you are screwed.

This was a great read. I also believe this to be true and am equally concerned about the consequences.

The reality is thus: the people in charge either have no plan, or see no path forwards other than keeping their heads down.

This is interesting and unsurprising, it seems like it’s just human nature to fall in line, regardless of how absurd the groupthink is. I’ve definitely seen it in every project I’ve been a part of over the last 3 years or so since LLMs became mainstream. Suggesting that we are not, in fact, on the brink of a revolution and should just focus on building something that actually works is heresy.

Frequently the failure is not related to AI itself, but rather that companies are terminally bad at running software projects effectively, and as I have remarked previously, AI projects are subject to all the failure modes of normal projects plus you can get everything right and then still fail because of the method's novelty.

This is what people like me have been saying since the very beginning. The first DORA report on AI adoption came to the same conclusion — AI is just another tool. It will amplify whatever practices you already have in place, good or bad. Most companies have no idea how to ship software and AI doesn’t change that.

They cannot buy sensible software, hire competent talent, communicate honestly with executives about the state of projects, or undertake any sort of sensible initiative.

It’s a shame to hear from someone who has sat at many tables with the big wigs that it has come to this. Again, not really surprising, but it’s unclear what the path forward is.

The intersection of AI tooling and open source projects is interesting to me. I’ve also come around to the reality that LLM-powered coding agents like Claude code or codex are pretty clearly game changing when it comes to how software gets produced.

AI is a tool, just like other tools we use. And it's clearly a useful one.

It may not have been that "clearly" even just a year ago, but it's no longer in question today.

I also agree this wasn’t true even a year ago, but the last couple of generations of models have seen some sort of threshold crossed that we didn’t know was there and they are legitimately very useful in my day to day work now.

They also fundamentally change the nature of open source software development. Now that writing code by hand is virtually an obsolete skill, where does that leave maintainers? And what is the point of open source?

Sure, the social angle of working on open source is important and often a very motivating part of the project, but in the end that's a side benefit, not the point of the project.

This was part of it, and a big part of what I love about it. To me it’s really enjoyable working on interesting projects with a globally distributed team of people who also enjoy the work. Part of it was also performative, a way to demonstrate publicly that you could write decent software. I think that is mostly over.

In the kernel community we do open source because it results in better technology, not because of religious reasons.

Maybe that just leaves us with this — writing open source because it produces better results. This doesn’t strike me as universally true though. I guess it depends what you mean by “better”, but I can think of many examples of software where the proprietary version is much better than the OSS one.

I really love seeing more and more serious engineering being put into making LLMs actually work in production. They’re too cool a tool not to use or integrate into consumed software, but nobody actually wants more shitty chat bots. Making them work reliably to actually make software better requires structure and effort, and this is one cool way of thinking about it I hadn’t come across before.

Without additional artifacts beyond what human-driven CD requires, agent-generated code accumulates drift and technical debt faster than teams can detect it.

This is undeniably true at this point and it’s cool to see frameworks and systems emerging for addressing it. This is the first time I’d heard of “agentic CD” and it’s super interesting!