Your weekend reading in 2026, the year everything shifts?
This week, we kicked off our programme of conferences for 2026. A significant focus this year will be the impact of AI on software engineering—not as a side topic, but as the central question shaping our industry, regardless of your focus as a software engineer–front end, back ends, full stack–or technology stack.
Our AI Engineer Melbourne conference in Melbourne (and online) in June is where we’ll dig deepest into this, but it’s a thread running through everything we’re doing this year.
But we’ve not left our design audience out of the picture. We have three conferences in collaboration with UX Australia coming up, including a brand new ai × design a one day conference alongside AI Engineer that explores how AI, large language models, and machine learning are transforming design practice.
And mark in your calendars that Super Early Bird pricing ends January 31st, and calls for presentations for these conferences is open until February 28th.
A year ago, Dario Amodei the CEO of Anthropic said 90% of code would be written by AI by the end of 2025. To many, it’s sounded absurd. By December, it had become more than plausible. By now—a few weeks into 2026—for some of us, at least, it’s become a fact.
As I have noted more than once, late last year, a year ago this newsletter largely focused on front-end technologies and development, and associated practises.
This week’s collection of links, which I gathered over the Christmas-New Year period is 100% AI-focused. Because when I sat down to curate what matters this week, this is what mattered. We’ll definitely continue to publish Web Platform content, but even if you are a front-end developer, I think this is where a lot of your focus should now be.
That’s uncomfortable for me to say. I’ve spent 25 years caring about the craft of building for the web. Standards, accessibility, performance—these things still matter. But how they matter has changed. They’re becoming outcomes we specify, not code we write.
The progress we saw in 2025—and from significant personal experience I can attest to this—in terms of the capabilities of coding systems, was extraordinary. In particular, the acceleration of capability in the last few weeks of the year with the most recent models from OpenAI and Anthropic and others, I think took even those who’ve been paying a lot of attention by surprise.
Until then, many of us felt we might be reaching a plateau—these tools had become very useful, very valuable, but perhaps the improvements from here on would be incremental.
I feel now that may well not be the case. It’s not just about the capability of the models themselves, but the tooling, practises, and patterns we’re building around them. Specific products like Claude Code (which, if you’re not using, at least give a try). Techniques like Geoff Huntley’s Ralph Wiggum approach. The new skills-based patterns emerging in tools like Codex and Claude Code.
All of these together suggest we may see similar increases in capability over the next 12 months—which makes it hard to predict precisely how capable these technologies will be this time next year.
So, what implications does that have for you? For your team? For the code you write? That’s something I’ve been thinking a lot about, particularly in the context of programming the AI Engineer Melbourne conference, which will be running in June in Melbourne.
For Engineering Leaders
The leaders—and their teams and organisations—that figure out how to restructure around this will pull ahead. Not by replacing developers with AI, but by changing what developers do. Less ticket-taking, more judgment. Less implementation, more direction and verification.
This week’s links include pieces from Block’s engineering team on how they’re thinking about security and testing for AI agents. These aren’t theoretical exercises—they’re organisations actively restructuring their practices. The question isn’t whether to adopt these tools, but how to build the guardrails, workflows, and team structures that let you use them effectively.
For Individual Engineers
Your ability to take a ticket and ship code is becoming table stakes—because the AI can do that too. What remains valuable is the knowledge that lets you direct well and verify accurately. Diagnostic skill. Architectural thinking. Breadth.
This is a dual challenge. Not only do you need to get up to speed and keep up with the capabilities of the tools and technologies to keep abreast of the patterns and practises as they emerge, but also maintain and grow domain knowledge, perhaps not only within your existing area of capability but beyond that.
For 10 or 15 years, companies have hired for full stack engineers. Many have been sceptical about how possible it is to really be a full stack engineer. I think our knowledge increasingly needs to be full-stack and broad as well as deep.
And, as an engineering leader, you have to think about how you can help your reports, your teams, continue to grow their capabilities and knowledge.
For me
What are the implications for me? For the better part of three decades, I was extremely knowledgeable when it came to a quite narrow area of software engineering practise, front-end development. I certainly kept abreast to the extent possible in other areas, but within that domain, I really knew my stuff.
For me, as I’ve suggested for individual engineers, that’s not really enough anymore. For me, keeping abreast of all of this is a significant challenge.
This newsletter is my way of thinking out loud. Every week, I’m trying to figure out what’s actually happening and what it means. This year, that feels more urgent than ever.
So, hopefully, as I do that, my thinking aloud might be valuable for you as well. Each week, I will share what I’ve come across and not just post a link but give some thoughts as I have been doing about why I think a particular piece, interview, article, podcast, course, or whatever it happens to be, might be valuable for you.
Let’s kick off 2026. Here’s what’s caught my attention over the last few weeks—there’s plenty more in my queue, but this is a start.
AI & Software Engineering Economics
Believe the Checkbook
Tags: AI, AI Native Dev, LLMs, software engineering
Anthropic’s AI agent was the most prolific code contributor to Bun’s GitHub repository, submitting more merged pull requests than any human developer. Then Anthropic paid millions to acquire the human team anyway. The code was MIT-licensed; they could have forked it for free. Instead, they bought the people.
Publicly, AI companies talk like engineering is being automated away. Privately, they deploy millions of dollars to acquire engineers who already work with AI at full tilt. That contradiction is not a PR mistake. It is a signal.
So what do you do with this as a technical leader?
Stop using AI as an excuse to devalue your best knowledge workers. Use it to give them more leverage.
Source: Believe the Checkbook
No one knows exactly how LLMs will impact the practice of software engineering. Beyond that, no one remotely knows how they will impact other fields.
I think the things we can take as a given are: there will be, there already are, significant transformations; and very little ultimately will look like what came before.
It’s hard to even imagine which of the significant transformations in the practice of software engineering over the last 75 years the current transformation most closely rhymes with. In terms of physical form factor, the change from punch cards to screen-based coding is one place to start. But then the transformation to IDEs was similarly profound. I think what we’re seeing may actually dwarf both of these. And what does that mean? I think the difference between what happens next and what came before will be more significant than either of those other transformations.
The Economics of AI Coding: A Real-World Analysis
Tags: AI Native Dev, software engineering
My whole stream in the past months has been about AI coding. From skeptical engineers who say it creates unmaintainable code, to enthusiastic (or scared) engineers who say it will replace us all, the discourse is polarized. But I’ve been more interested in a different question: what does AI coding actually cost, and what does it actually save?
I recently had Claude help me with a substantial refactoring task: splitting a monolithic Rust project into multiple workspace repositories with proper dependency management. The kind of task that’s tedious, error-prone, and requires sustained attention to detail across hundreds of files. When it was done, I asked Claude to analyze the session: how much it cost, how long it took, and how long a human developer would have taken.
The answer surprised me. Not because AI was faster or cheaper (that’s expected), but because of how much faster and cheaper.
Source: The Economics of AI Coding: A Real-World Analysis
I’ve seen very few analyses like this, and I think it’s really important. Here Tarek Ziadé, a very experienced software engineer working on the Mozilla codebase, documents in detail his work on a real-world piece of software engineering using Claude Code. And the impact it had in terms of costs and time saved. The things that went well and the things that maybe went less well.
AI-Native Development
Why AI is pushing developers toward typed languages
Tags: AI Native Dev, computer science, software engineering
It’s a tale as old as time: tabs vs. spaces, dark mode vs. light mode, typed languages vs. untyped languages. It all depends!
But as developers use AI tools, not only are they choosing the more popular (thus more trained into the model) libraries and languages, they are also using tools that reduce risk. When code comes not just from developers, but also from their AI tools, reliability becomes a much bigger part of the equation.
Dynamic languages like Python and JavaScript make it easy to move quickly when building, and developers who argue for those languages push for the speed and flexibility they provide. But that agility lacks the safety net you get with typed languages.
Source: Why AI is pushing developers toward typed languages – The GitHub Blog
My instinct is like that of far better, more knowledgeable developers like Bret Taylor: in time, large language models and coding agents won’t write languages that have been developed for humans (whether that’s JavaScript or Python or whatever). Instead, they will develop in languages that are optimised for the output of a large language model.
In the meantime, it’s certainly the case that we are putting languages developed for humans to use. The question is, which languages should we be using? There’s certainly debate about whether or not typed vs untyped languages work better with large language models. Here is a discussion of the issues around that.
Getting started with Claude for software development
Tags: AI Native Dev, coding agent, software engineering
2025 was an interesting year in many ways. One way in which it was interesting for me is that I went from an AI hater to a pretty big user. And so I’ve had a few requests for a “using Claude” guide, so I figure new year, why not give it a shot? The lack of this kind of content was something that really frustrated me starting out, so feels like a good thing to contribute to the world.
Source: Getting started with Claude for software development
If, like it seems a lot of people did over the holiday period, you gave some serious thought to working with an agentic coding system like Claude Code, this could be a really good introduction for you. I highly recommend it. I highly recommend getting a $20 USD account with Claude, giving you access to Claude Code. I highly recommend you download the desktop app and work with it that way. At that price point, you will likely run out of tokens from time to time and have to wait an hour or two while working with it, but you can still get a tremendous amount of valuable work done. If you’re a software engineer, I think now it really is the time to be working with these tools.
Don’t fall into the anti-AI hype
Tags: AI Native Dev, LLMs, software engineering
Anyway, back to programming. I have a single suggestion for you, my friend. Whatever you believe about what the Right Thing should be, you can’t control it by refusing what is happening right now. Skipping AI is not going to help you or your career. Think about it. Test these new tools, with care, with weeks of work, not in a five minutes test where you can just reinforce your own beliefs. Find a way to multiply yourself, and if it does not work for you, try again every few months.
Source: Don’t fall into the anti-AI hype – antirez
This is a pattern we’re seeing increasingly: people who have been sceptical of or even quite resistant to the use of large language models for coding, recognising through using the tools how significant they actually are.
LLM predictions for 2026
Tags: AI Native Dev, realms, software engineering
In 2023, saying that LLMs write garbage code was entirely correct. For most of 2024 that stayed true. In 2025 that changed, but you could be forgiven for continuing to hold out. In 2026 the quality of LLM-generated code will become impossible to deny.
I base this on my own experience—I’ve spent more time exploring AI-assisted programming than most.
The key change in 2025 (see my overview for the year) was the introduction of “reasoning models” trained specifically against code using Reinforcement Learning. The major labs spent a full year competing with each other on who could get the best code capabilities from their models, and that problem turns out to be perfectly attuned to RL since code challenges come with built-in verifiable success conditions.
Source: LLM predictions for 2026, shared with Oxide and Friends
Here’s a series of predictions by Simon Willison and others about what we might see when it comes to large language models in the context of software engineering in 2026.
It’s not to say that Simon and Co are right about these things, but I think it is increasingly imperative, if we’re software engineers, to think about what might be coming because that will shape our choices and actions. The timeframes here are relatively short—months, maybe a couple of years. And typically, we don’t have to respond in such short timeframes to such very significant changes in, for example, the practice of software engineering.
Origin Story: A Tale of Two Ralphs
Tags: AI, software engineering
Origin Story: A Tale of Two Ralphs
To understand the “Ralph” tool is to understand a new approach toward improving autonomous AI coding performance — one that relies on brute force, failure, and repetition as much as it does on raw intelligence and reasoning.
Because Ralph Wiggum is not merely a Simpsons character anymore; it is a methodology born on a goat farm and refined in a San Francisco research lab, a divergence best documented in the conversations between its creator and the broader developer community.
The story begins in roughly May 2025 with Geoffrey Huntley, a longtime open source software developer who pivoted to raising goats in rural Australia.
Source: Origin Story: A Tale of Two Ralphs
Friend of Web Directions and speaker at our conferences, Geoff Huntley is, along with The Simpsons’ Ralph Wiggum, having a moment.
If you had the privilege to attend our UN conferences last year, our Code Conference, or our Engineering AI Conference, you would have heard Geoff speak about his experience of working with large language models to develop software.
Not much more than 12 months ago, he was quite sceptical about them. A little over 12 months later, he is one of the highest-profile people in the field. And here he is getting some attention from none other than VentureBeat.
AI Security & Testing
Agent Guardrails and Controls
Tags: AI, AI Engineering, LLMs, MCP, security
In our previous blog post, Securing the Model Context Protocol, we detailed the Model Context Protocol (MCP) system and discussed some security concerns and mitigations. As a brief recap, MCP provides agents with a means to accomplish tasks using defined tools; reducing the burden of using complex and varied APIs and integrations on the agent.
However, in our prior blog post we did not cover mitigations for injection attacks against LLMs that are performed by MCPs themselves. At the time, this was because we didn’t have any security advice we believed was helpful to offer.
However, that is the focus of this post where we outline a way of modelling this attack using the established threat model of browser security, and specifically CSRF (Cross-Site Request Forgery), to provide insights into novel mitigations we believe could help dramatically reduce the attack’s likelihood.
Source: Agent Guardrails and Controls | Block Engineering Blog
More thoughts from Block’s engineering team about security models for MCP-based systems, particularly cross-site request forgery (CSRF) attacks and how to mitigate those.
Block red-teamed its own AI agent to run an infostealer
Tags: coding agent, security
“Being CISO is very much about being okay with ambiguity and being uncomfortable in situations,” Nettesheim said. “We are balancing risk constantly, and having to make trade off – in the AI space in particular. Like: What is a bigger risk right now? Not taking advantage of the technology enough? Or the security downsides of it? LLMs and agents are introducing a new, very rapidly evolving space.”
Source: Block red-teamed its own AI agent to run an infostealer • The Register
Block has taken a real leadership position in the agentic coding space, particularly with their open-source project Goose.
But like anyone working deeply in this area, they recognise the potential security implications for letting an agentic system loose. Here their CISO talks about some of the implications for security and some tactics for addressing those challenges.
Testing Pyramid of AI Agents
Tags: AI Engineering, LLMs, software engineering, testing
I’m a huge advocate for software testing and have written and spoken quite a bit about the testing pyramid. Unit tests at the bottom. Integration tests in the middle. UI tests at the top. Fewer tests as you go up, because they’re slower, flakier, and more expensive.
That model worked really well as it gave teams a shared mental model for how to think about confidence, coverage, and tradeoffs. It helped people stop writing brittle UI tests and start investing where it mattered.
But now that I work on an AI agent and have to write tests for it, that pyramid stopped making sense because agents change what “working” even means.
Source: Testing Pyramid of AI Agents | Block Engineering Blog
Testing AI-based systems or large language model-based systems is challenging, in no small part because their output is unlike that of traditional software systems—not deterministic. So, how do we go about testing our AI-based systems? Here are some thoughts from Angie Jones.
Understanding Machine Learning
Introducing beginners to the mechanics of machine learning
Every year, I spend some time introducing students to the mechanics of machine learning with neural nets. I definitely don’t go into great depth; I usually only have one class for this. But I try to unpack at least some of the major concepts, so that ML isn’t quite such a black box.
Whether you’re an AI critic or enthusiast, I find that conversations can be much more specific and productive if the participants have a basic understanding of how the tools work. That way, if students hear some kind of outlandish claim—like, that ChatGPT loves them—they can compare the claim to a mental image of how the tool actually works.
Source: Introducing beginners to the mechanics of machine learning – Miriam Posner
I spent the holiday period trying to get a deeper understanding of what’s going on with machine learning and large language models, going all the way back to the 1950s and the origins of artificial neurons. This is a great list of videos, articles, and so on that could help provide a broader understanding of what these technologies are doing and how they work.
Attention? Attention!
Tags: AI, generative AI, LLMs
Attention is, to some extent, motivated by how we pay visual attention to different regions of an image or correlate words in one sentence. Take the picture of a Shiba Inu in Fig. 1 as an example.
Human visual attention allows us to focus on a certain region with “high resolution” (i.e. look at the pointy ear in the yellow box) while perceiving the surrounding image in “low resolution” (i.e. now how about the snowy background and the outfit?), and then adjust the focal point or do the inference accordingly. Given a small patch of an image, pixels in the rest provide clues what should be displayed there. We expect to see a pointy ear in the yellow box because we have seen a dog’s nose, another pointy ear on the right, and Shiba’s mystery eyes (stuff in the red boxes). However, the sweater and blanket at the bottom would not be as helpful as those doggy features.
Source: Attention? Attention!
I spent the last few weeks trying to get a deeper understanding of the technologies and theories that underlie modern machine learning. One tremendous source I highly recommend is “Why Machines Learn“, a fantastic book that is about the mathematics of machine learning—but don’t be put off by that. A lot of it you could simply skip the mathematics and understand the broad ideas and get a lot of benefit from. I couldn’t recommend it highly enough.
I also spent some time going through a reading list from Elicit, a company that I admire, that they give new hires to get them up to speed with the broad landscape of modern machine learning.
One of the key concepts of large language models is attention. Perhaps the key to making them work is this concept of attention. While this article is from several years ago now, it does a great job of giving you a sense of what attention is and how it works.
All I Want for Christmas is a Better Alt Text – Part 1
Earlier this year, I built the backend for the local alt text generation feature in Firefox. Nearly half of the images on the web still lack alternative text, creating a major accessibility barrier for screen reader users. The goal of this work is straightforward but ambitious: generate high-quality alt text entirely on device, preserving user privacy while improving access to visual content.
Source: All I Want for Christmas is a Better Alt Text – Part 1
There has been vocal pushback against Firefox for adopting AI in the browser, even as is currently the case—experimental adoption, often behind feature flags or otherwise not widely available.
Here, I think, is one very powerful and positive use case. One that I use myself, though not in Firefox, but in tools that I have built. And that is the generation of alt text for images that lack them. Firefox is working to implement this directly in the browser, helping maintain a user’s privacy and lowering the impact on resources in the environment—two things that people are often highly critical about when it comes to AI.
Here Tarek Ziadé talks about the process of implementing these in the browser. As we’ve covered elsewhere, various browser developers are looking at similar approaches to incorporating AI models in the browser directly and exposing them through APIs. I think this is an excellent use case for the technology.
AI & User Experience
“AI” is bad UX
This is in many ways a worst case scenario for user experience. An application where clicking “save” deletes your files. An icon where clicking and dragging it makes thousands of copies. A sliding control where every time you move it something different happens. Perhaps the best pre-LLM analogy for the LLM user experience is the browser game QWOP, where something immediately intuitive (in the game’s case, running), is rendered dramatically and hilariously unintuitive by the mode of interaction (in the game’s case, this is fun).
This mismatch, between this incredibly powerful user metaphor and the actual abilities of these systems, is at the heart of most of the emerging problems with ‘AI’. For most people, it is functionally impossible to break the mental connection between “this is a person you talk to” and inferences about internal states and goals. So-called ‘AI psychosis’, where the funhouse mirror agreeableness of a mindless chatbot sends people into ratiocinatory spirals of delusional ideation, stems from this failed metaphor. If somebody else is agreeing with you and expanding on and elaborating what you’re saying, it must make sense, right? They sound like they know what they’re talking about.
Source: “AI” is bad UX
It’s a very thoughtful essay on user experience and AI. It’s very hard to summarise, but I highly recommend everyone reads and gives some thought to.
Great reading, every weekend.
We round up the best writing about the web and send it your way each Friday.
