I don’t know why this week became the tipping point, but nearly every software engineer I’ve talked to is experiencing some degree of mental health crisis… Many people assuming I meant job loss anxiety but that’s just one presentation. I’m seeing near-manic episodes triggered by watching software shift from scarce to abundant. Compulsive behaviors around agent usage. Dissociative awe at the temporal compression of change. It’s not fear necessarily — just the cognitive overload from living in an inflection point.
Living in the inflection point
AI, career development, software engineering
If, like, pretty much everyone, you're feeling overwhelmed, anxious, even if you might also be feeling excited at the possibility and capabilities of emerging AI technologies for you as a software engineer, I highly recommend this piece.
A lot of it very much resonated with me, in particular the observations about the importance of glue work and of learning as a way of coping.
What Wall Street Gets Wrong About SaaS – Roger Wong
AI, LLMs, software engineering
Last week, B2B software companies tumbled in the stock market, dropping over 10%. Software stocks have been trending down since September 2025, now down 30% according to the IGV software index. The prevailing sentiment is because AI tools like Anthropic’s Claude are now capable of doing things companies used to pay thousands of dollars for.
But investors are wrong. Nvidia CEO Jensen Huang calls this line of thinking “illogical.” Mark Murphy, an analyst at JPMorgan uses the same word to describe the “expectation that every company will hereby write and maintain a bespoke product to replace every layer of mission-critical enterprise software they have ever deployed.”
Right now, the market seems very bearish on the prospect of software as a product category. I tend to share that outlook, but others don't, so here is a very well-thought-through argument by Roger Wong as to why this may not be the case.
Does AI already have human-level intelligence? The evidence is clear
In 1950, in a paper entitled ‘Computing Machinery and Intelligence’1, Alan Turing proposed his ‘imitation game’. Now known as the Turing test, it addressed a question that seemed purely hypothetical: could machines display the kind of flexible, general cognitive competence that is characteristic of human thought, such that they could pass themselves off as humans to unaware humans?
Three-quarters of a century later, the answer looks like ‘yes’. In March 2025, the large language model (LLM) GPT-4.5, developed by OpenAI in San Francisco, California, was judged by humans in a Turing test to be human 73% of the time — more often than actual humans were2. Moreover, readers even preferred literary texts generated by LLMs over those written by human experts3.
I've been working extensively with most of the major models—from Google, OpenAI, Anthropic, and others—for several years now. I've got a great deal of value from them in all kinds of ways. But until December last year, I would have characterised these as often valuable, sometimes problematic, power tools.
With the release of the most recent models from OpenAI, Google, and Anthropic, and new harnesses like Anti-Gravity, Co-Work, and now Codex from OpenAI, I wouldn't characterise them as power tools anymore.
I've been doing technology stuff for the vast majority of my life—well over 40 years. In all that time, I've had perhaps three truly jaw-drop moments when I saw something that pointed in a completely new direction.
Two of them have happened in the last four to six weeks. Working with Claude Code and Co-Work, we now have systems that are autonomous, that take responsibility, that interact the way intelligent, educated, capable humans would. And in the last two weeks or so, Claude Clawdbot has brought something different: an immediacy, an always-on quality.
I'm not fooled into thinking it's a person. But if you took one of these systems back to November 2022, when ChatGPT first became widely available, I'd argue that everyone you showed it to—including researchers in the field, people who'd been working on machine learning and AI for years or decades—would have said this is intelligent.
I'm not sure the conversation about whether it is intelligent even matters that much, except perhaps as a relatively abstract philosophical one. But I think it's quite extraordinary that Nature—one of the longest-running and highest-profile science publications, with a history going back over 150 years—is essentially saying that this contemporary set of technologies has human-level intelligence.
Hamish Songsmith – Blog & Links
AI, LLMs, software engineering
A growing chasm separates those building around AI from those still debating it—and it has nothing to do with model size or vendor choice.
On one side: people who aren’t fixated on measuring or justifying it first. They have experimented enough and understand that, applied well, AI generally means more productivity. They’re already building tools like Ralph loops, OpenClaw, and AI factories such as GSD and Gas Town.
If those names sound like “random internet projects,” that’s exactly the problem: capability is moving outside your organisation faster than you recognise.
The transformation of software engineering—and more—has kind of already happened. Like the future, it's not evenly distributed, but it has arrived.
What it actually looks like in months and years to come, no one knows. All we can do is experiment and explore. The waterfall methodology held sway for the first half of my software engineering and technology career. Agile has held sway for the second half.
These things weren't brought into being with a click of the fingers. They emerged from lessons software engineers were learning. The mistakes they were making. The errors they saw—human and structural. And over time, a set of practices, a set of patterns, and built on top of them, tools and even programming languages, emerged over years and decades.
Just as Agile eclipsed Waterfall, a new set of practices will eclipse Agile. It's happening already, driven by a profound change in what computation is—one that has happened more quickly than we've ever seen before.
You have the opportunity to be part of that conversation, to help shape what happens next. But that window of opportunity is closing.
The Coherence Premium
In 1937, the British economist Ronald Coase asked a question that seems almost embarrassingly simple: why do firms exist at all? If markets are so efficient at allocating resources, why don’t we just have billions of individuals contracting with each other for every task? Why do we need these hulking organizational structures called companies?
His answer, which eventually won him a Nobel Prize, was transaction costs. It’s expensive to negotiate contracts and coordinate with strangers, to monitor performance and enforce agreements. Firms exist because sometimes it’s cheaper to bring activities inside an organization than to contract for them on the open market. The boundary of the firm, Coase argued, sits wherever the cost of internal coordination equals the cost of external transaction.
We’re in a Coasean inversion. The economics that made large firms necessary are reversing. But most people are looking at this transformation through the wrong lens. They see AI as a productivity tool, a way to do more faster. They measure success in hours saved or output multiplied, and this misses the point entirely.
I've been thinking a lot about exactly this, without putting it in nearly as good a framing as J.A. does here. Computing since 1980 has largely done one of two things:
1. It's made large existing enterprises and organisations more productive
2. More recently it's opened up new kinds of consumer products like social networks and streaming
What J.A. argues here and what I've been thinking quite a bit about is what happens to large organisations when in order to take advantage of the promise of AI, they need to transform their own structure. Large organisations treat change as a virus, they have antibodies against it. So when we see these studies from the likes of MIT about how some huge percentage of all AI projects have no ROI, perhaps that's right. But it's telling us something about the capability of large organisations to benefit from adopting AI.
Hierarchical memory management in agent harnesses | LinkedIn
AI, coding agent, LLMs, software engineering
We’ve seen incredible momentum toward files as the memory layer for agents, and this has accelerated significantly over the last year. But why use the file system, and why use Unix commands? What are the advantages these tools provide over alternatives like semantic search, databases, and simply very long context windows?
What a file system provides for an agent, along with tools to search and access it, is the ability to make a fixed context feel effectively infinite in size.
Bash commands are powerful for agents because they provide composable tools that can be piped together to accomplish surprisingly complex tasks. They also remove the need for tool definition JSON, since bash commands are already known to the LLM.
It's fascinating that a well over 50 year old operating system and approach to operating systems that are the Unix seems to empower agents to work autonomously. Here Aparna Dhinakaran looks why Unix commands and the Unix approach of small pieces loosely coupled and piping from one function to the next is so effective.
Is Learning CSS a Waste of Time in 2026? – DEV Community
With modern frameworks, component libraries, and utility-first CSS, it’s a fair question.
Most frontend developers today rarely write “real” CSS. Layouts come prebuilt. Responsiveness is handled for us. Accessibility is supposed to be baked in. If something needs styling, we tweak a variable, add a utility class, or override a component token.
I'm going to take a stab at this question, and I think my answer is completely the opposite. I'll state my biases upfront. I think CSS is a profoundly important language that many, many software engineers have spent the better part of at least 15 years trying to abstract away the nuances and complexities of.
The argument in a nutshell is that developers use Tailwind and CSS in JS of various flavours and never need to actually write CSS, so they never really need to understand it.
I've argued, and I increasingly believe that the tower of abstractions we've built to hide the underlying capabilities and complexities of the web platform in CSS, in the DOM, in JavaScript, in HTML, in ARIA–that tower is no longer relevant.
LLMs understand the DOM. They understand JavaScripts. They understand CSS incredibly well. These are really incredibly well-documented technologies. There are huge codebases out there. It astounds me that anyone would think it made any sense to get LLMs to generate anything of a higher level abstraction than the underlying platform capabilities because those abstractions are written for humans, not in LLMs. They get in the way, they come at a really high cost. We made the trade-off to get better developer experience at the cost of in particular performance by complex build tools and on and on.
So, that means you should all learn CSS right? Well, yes and no. I think, increasingly, what good software engineers will do is they will understand the capabilities of the technology. They won't have a hammer and use it incredibly effectively every time they have a problem. They won't use Flexbox all the time or whatever tool they particularly want to use. Instead, they will know the subtleties and complexities and capabilities of their platform, their toolset, or their language, so they can guide code generation tools to use the right tool at the right time. They will know when Flexbox or Grid or absolute positioning or whatever it is, is the right layout choice.
So forget everything above the layer of the core technology.
You won't be writing "real" CSS. Your large language model will be writing that, but it shouldn't be writing Tailwinds. That's a technology created to abstract away the complexities and, in many cases, the power of CSS on the web platform. It's a uniquely bad decision when you're working with code generation to choose a tool like that.
What should you do as a developer? Learn the concepts. Have an encyclopaedic knowledge of the capabilities of the language and platform that you use. But you're not going to be writing the code. You're going to be guiding the tool that you use to write the code. And increasingly you will use specification documents, plan documents to shape the scope of what the code generation tool will produce.
AI open models have benefits. So why aren’t they more widely used? | MIT Sloan
A new paper co-authored by Frank Nagle, a research scientist at the MIT Initiative on the Digital Economy, found that users largely opt for closed, proprietary AI inference models, namely those from OpenAI, Anthropic, and Google. Those models account for nearly 80% of all AI tokens that are processed on OpenRouter, the leading AI inference platform. In comparison, less-expensive open models from the likes of Meta, DeepSeek, and Mistral account for only 20% of AI tokens processed. (A token is a unit of input or output to an AI model, roughly equivalent to one word in a prompt to an AI chatbot.)
Open models achieve about 90% of the performance of closed models when they are released, but they can quickly close that gap — and the price of running inference is 87% less on open models. Nagle and co-author Daniel Yue at the Georgia Institute of Technology found that optimal reallocation of demand from closed to open models could cut average overall spending by more than 70%, saving the global AI economy about $25 billion annually.
I'll admit to also being guilty here. I use extensively multiple closed models, but very little by way of open ones. It's not a particularly thought-through choice. That's what I've gotten used to in terms of API setups and workflows and muscle memory. There's no network effects here, but those big closed expensive models keep getting the mind share and user share.
There's a sense that in particular the Chinese Frontier Labs who often produce open models are more than nipping at the heels of the American Frontier lab companies. So perhaps this is something we'll see change over the coming months.
How Product Discovery changes with AI – by David Hoang
In Jenny Wen’s talk at Hatch Conference in 2025, “Don’t Trust the Process,” she raises an important point: the processes we’ve established are rapidly becoming lagging indicators. Process is important, but it should work for you, not the other way around.
People worshipped the process artifacts, not the final result. We’re in a moment where the moment you document a process, it becomes irrelevant. I don’t believe it’ll be like this forever, but until software is completely rewritten with AI as a core capability, it’s going to be like this for a while.
So, where does Product Discovery change? Let’s revisit those four risks.
Last week, we referenced Jenny Nguyen's talk at Hatch Conference where she revisited the product design process that has been widely adopted over the last decade or so. She asked the question: Does this still make as much sense in an age of AI? The answer, for the most part, is probably not.
It's something we're seeing elsewhere, particularly with software engineering, where that long-term software engineering or software development life cycle that we've evolved over the last 15 or 20 years perhaps doesn't make as much sense in a world of Ralph Wiggums and Gas Towns and, of course, other approaches to AI-generated software.
Here, David Huang asks a similar question about product discovery. We had a talk at our recent Next conference, the video will be available soon, which also considers this particular issue. In short, we've developed processes and approaches that made sense in terms of the scale and capability of humans and human teams across design, product, and engineering. That when AI large language models are a part—indeed, often a significant part—of our process now may not make as much sense. I don't think folks like David or Jenny have so much as answers right now but more are thinking about existing processes and the sorts of things that might change.
Whatever your field, I think it's well worth considering these challenges, which also represent opportunities.
One Human + One Agent = One Browser From Scratch
AI, coding agent, LLMs, software engineering
One Human + One Agent = One Browser From Scratch (via) embedding-shapes was so infuriated by the hype around Cursor’s FastRender browser project – thousands of parallel agents producing ~1.6 million lines of Rust – that they were inspired to take a go at building a web browser using coding agents themselves.
The result is one-agent-one-browser and it’s really impressive. Over three days they drove a single Codex CLI agent to build 20,000 lines of Rust that successfully renders HTML+CSS with no Rust crate dependencies at all – though it does (reasonably) use Windows, macOS and Linux system frameworks for image and text rendering.
We covered the news last week of a browser effectively entirely built by a number of code generation agents. Here is another such project - again, not something that necessarily is going to take on Google Chrome any time soon, but increasing evidence of just how capable these tools are.
The Five Levels: from Spicy Autocomplete to the Dark Factory – Dan Shapiro’s Blog
AI, LLMs, software engineering
If you are just using ChatGPT to write your regex, you aren’t really getting the benefits of deflation. You’re just typing faster.
I’ve now seen dozens of companies struggling to put AI to work writing code, and each one has moved through five clear tiers of automation. That felt familiar, and I realized that the federal government had been there first – but for cars.
Here, Dan Shapiro uses the analogy of the 5 levels of autonomous driving to write about how developers and organisations are approaching code generation tools. This is a very useful framing of the challenge.
This is a Time of Technical Deflation – Dan Shapiro’s Blog
AI, economics, realms, software engineering
Now economists have this thing they call deflation. For an economy, it’s a nightmare. Prices drop day after day, creating a psychological trap where consumers stop spending. Why buy a washing machine today when it will be cheaper tomorrow?1 The whole economy grinds to a halt.
But what is a ‘trap’ for a nation is a miracle for a codebase. Usually, deflation is bad for debtors because money becomes harder to come by. But technical debt is different: you don’t owe money, you owe work. And the cost of work is what’s deflating. The cost to pay off your debt – the literal dollars and hours required to fix the mess – is diminishing. It is cheaper to clean up your code today than it has ever been. And if you put it off? It becomes cheaper still. This leads to a striking reversal: technical debt2 becomes a wise investment3.
The observation here about what's happening with code generation is profound, as software engineers' best practise is always to try and avoid tech debt. You move fast and cut corners, and then at some point, the cost will always catch up with this. There are many examples of companies who've reached a point where their codebase essentially no longer allowed them to innovate. Sometimes there are exogenous forces that cause this. Apple's transition from classic Mac to Mac OS X on a smaller scale, the introduction of iOS 7 with its move away from skeuomorphic design language to a much simpler design language are two such moments.
But here Dan Shapiro argues for the opposite: because we're in a moment of the collapse in the price of producing code, a deflationary cycle, then tech debt is inexpensive. It might not be true for everyone, every circumstance, but it's definitely something I think well worth considering.
Why Designers Can No Longer Trust the Design Process
AI, Design, LLMs, Product Design
For years, designers have been told to trust the process.
Research first. Personas. Journey maps. Problem statements. Then solutions.In this talk from Hatch Conference, Jenny Wen, Design Lead at Anthropic and former Director of Design at Figma, explains why that model no longer fits the reality of modern design work.
With AI accelerating prototyping, smaller teams doing more, and craft becoming a key differentiator, rigid processes are failing designers. Jenny shares real examples from Figma and Anthropic that show how great work actually gets made today. Starting from solutions, caring deeply about details, building intuition, skipping steps, and designing for delight.
This is not a rejection of research or strategy.
It is a call to stop worshipping process artifacts and start trusting designer judgment again.
The field of design has developed and refined processes over the last 20 years or so for designing digital products. Here, Jenny Wen, the head of design at Anthropic, asks whether these well-known, tried and true, trusted techniques are still fit for purpose in an era when AI is so increasingly involved in our product development life cycles.
the browser is the sandbox | AI Focus
This got me thinking about the browser. Over the last 30 years, we have built a sandbox specifically designed to run incredibly hostile, untrusted code from anywhere on the web, the instant a user taps a URL. I think it’s incredible that we have this way to run code that you’ve no clue what it will do when you see a little blue link or a piece of text that looks like
https://paul.kinlan.me/– I mean, who would trust that guy?Could you build something like Cowork in the browser? Maybe. To find out, I built a demo called Co-do that tests this hypothesis. In this post I want to discuss the research I’ve done to see how far we can get, and determine if the browser’s ability to run untrusted code is useful (and good enough) for enabling software to do more for us directly on our computer.
Paul Kinlan here looks at the features of the web platform, such as file system access and network security features, and asks if the browser could be the sandbox that we need for systems like Claude Code and co-work.
How To Use AI for the Ancient Art of Close Reading – fast.ai
Close reading is a technique for careful analysis of a piece of writing, paying close attention to the exact language, structure, and content of the text. As Eric Ries described it,“close reading is one of our civilization’s oldest and most powerful technologies for trying to communicate the gestalt of a thing, the overall holistic understanding of it more than just what can be communicated in language because language is so limited.” It was (and in some cases still is) practiced by many ancient cultures and major religions.
It might come as a surprise that a technique associated with such a long history could now see a revival with the use of Large Language Models (LLMs). With an LLM, you can pause after a paragraph to ask clarifying questions, such as ‘What does this term mean?’ or ‘How does this connect to what came before?’
At university, decades ago now, I studied English Literature among many other topics and was introduced to the concept of close reading. So this from FastAI caught my attention.
We often see concerns that AI and large language models are reducing people's capacity to reason deeply and think extensively. There are many concerns about the impact on education, and I don't think those should be dismissed out of hand. But approaches like this—using a large language model as a tool to aid processes like close reading—give me some optimism for more positive outcomes.
In my own experience over the last few weeks, I've been reading Anil Ananthaswamy's wonderful Why Machines Think, about the mathematics of machine learning and AI.
Now, I also studied mathematics—indeed got a degree in the subject—at university, again decades ago. And while the mathematics in that book doesn't go into real depth, I wanted to make sure I really understood the key concepts, particularly Bayes' theorem, of which I had a general understanding but which Ananthaswamy looks at in some detail.
I used the technique of photographing each section of the book as I read it, uploading it to Claude, and then having a conversation about that section. When I wasn't clear on a particular aspect, I asked for more detail and clarified my understanding.
It certainly took longer, but I came away with a much deeper understanding than I would have if I'd simply worked through it in my own head.
We're at the very early stages of these models' capabilities. I believe they will get significantly better than they are today, even though by 2023 standards they're already remarkably capable. But beyond that, we'll develop new techniques, new approaches, new patterns. We'll learn how to work with these tools, and this is one of what I think will be many examples.
Will people lazily use these tools to churn out slop? Hastily write essays about topics they don't really understand? Yes, all of the above. But will this enable people who work intelligently with these technologies to learn more, to understand more deeply? I absolutely believe so.
Electricity use of AI coding agents | Simon P. Couch – Simon P. Couch
AI, environmental impact, LLMs
Throughout 2025, we got better estimates of electricity and water use of AI chatbots. There are all sorts of posts I could cite on this topic, but a favorite is this blog post from Our World in Data’s Hannah Ritchie. On the electricity front:
The average American uses 1600 liters of water per day, so even if you make 100 prompts per day, at 2ml per prompt, that’s only 0.01% of your total water consumption. Using a shower for one second would use far more.
Generally, these analyses guide my own thinking about the environmental impacts of my individual usage of LLMs; if I’m interested in reducing my personal carbon footprint, I’m much better off driving a couple miles less a week or avoiding one flight each year. This is indeed the right conclusion for users of chat interfaces like chatgpt.com or claude.ai.
For a while now, there have been very serious concerns about the energy and water use impacts of large language models. Given we face a genuine climate crisis, it's certainly important to consider this issue. But we've seen very few and certainly very few disinterested studies of this issue.
This suggests that the concerns are somewhat overstated. Although it must be noted that this has to do with inference and that training, at least for now, seems to consume the majority of energy associated with large language models.
Some Thoughts on the Open Web
“The Open Web” means several things to different people, depending on context, but recently discussions have focused on the Web’s Openness in terms of access to information — how easy it is to publish and obtain information without barriers there.
…
In other words, we have to create an Internet where people want to publish content openly – for some definition of “open.” Doing that may challenge the assumptions we’ve made about the Web as well as what we want “open” to be. What’s worked before may no longer create the incentive structure that leads to the greatest amount of content available to the greatest number of people for the greatest number of purposes.
Mark Nottingham has been heavily involved in the development of standards like HTTP at the IETF for many years. We've also had the privilege of having him speak multiple times at our conferences. Here he brings together some thoughts about the open web and its future, which many are perhaps not without some reason expressing concerns about.
Publishers report very significant drop-off in referral traffic from search engines in the last year or so. Frontier model developers have freely used open web content to train their models, which have turned several of them into some of the biggest and certainly most fast-growing companies in history. So, what future does the open web have, and what can you do about it? Well worth a read here from Mark.
jordanhubbard/nanolang: A tiny experimental language designed to be targeted by coding LLMs
computer science, software engineering
A tiny experimental language designed to be targeted by coding LLMs
Brett Taylor, among others, has speculated that if increasingly large language models rather than humans write software, then the current programming languages we have, which are designed for humans for readability, writeability, maintainability, type safety, memory safety, and so on, will not really make sense.
This is an experimental language designed for a world of large language model code generators. Sure, it won't be the last, but it's the first that I've heard of.
I was a top 0.01% Cursor user. Here’s why I switched to Claude Code 2.0. | Silen
AI Native Dev, software engineering
You have 6-7 articles bookmarked about Claude Code. You’ve seen the wave. You want to be a part of it. Here’s a comprehensive guide from someone who’s been using coding AI since 2021 and read all those Claude Code guides so you don’t have to.
I've been working with several major models and products from Google and Throw-Up being an OpenAI to write software going back the better part of three or indeed more years now. But in recent weeks, I found Claude code is just a step function change in capability.
So while this is very product-centric, I think, particularly if you are working with Claude code at all or considering it, this is highly recommended. The more ideas you have about techniques for working with these technologies, I think the more you get out of them.
Scaling long-running autonomous coding
AI Native Dev, LLMs, software, software engineering
In my predictions for 2026 the other day I said that by 2029:
I think somebody will have built a full web browser mostly using AI assistance, and it won’t even be surprising. Rolling a new web browser is one of the most complicated software projects I can imagine[…] the cheat code is the conformance suites. If there are existing tests that it’ll get so much easier.
I may have been off by three years, because Cursor chose “building a web browser from scratch” as their test case for their agent swarm approach:
I'm surprised this hasn't gained more notice over the last couple of days. I know a thing or two about web browsers and web technology. I've splunked the source code of mobile browsers going back over many years. I'm not even remotely capable of contributing a line of code to any modern browsers, but I do have a sense of what they have to do to render even the most basic web page. From the network layer all the way up to the rendering layer and beyond.
Now, this is not going to compete with Google Chrome. It's not going to be your daily driver, but it's an extraordinary example of just how capable modern large language model code generating systems have become in a very short period.
I don't think we've begun to digest the implications of this. Not as software engineers for our practise and profession, but for the economy. A decade or so ago, Mark Andresen said "Software is eating the world." What's happening now? And what will happen in the coming months and small number of years?
Code Reviewing AI-Generated JavaScript: What I Found – Schalk Neethling – Open Web Engineer
AI Native Dev, debugging, JavaScript, software engineering
I recently had an AI agent build a JavaScript utility for calculating road distances using a third-party API. The task was complex: batch multiple API requests, validate inputs and outputs, handle errors gracefully, and manage timeouts. The agent delivered working code that passed its own tests.
The code worked, but several issues ranged from minor inefficiencies to a critical bug that would break production. Here’s what I found and how we fixed each one.
I think this is worth a read, despite being very light on some details such as which model and harness was used.
Part II, where he'll look at the commonalities here and techniques for catching these issues during the development process, may well end up being more valuable. I look forward to seeing that.
The year everything changed – Network Games
In popular imagination, “AI” has come to mean the cheap version of ChatGPT, prattling in a grating tone with too many emojis, variously misleading and making things up.
AI, in this view, is a stupid machine that makes stupid text. LLMs can certainly be this thing.
Software circles aren’t much better: LLM-enabled development is about code generation. Tell it to extrude code for a purpose, and maybe it will, and maybe it will work.
The truth of things is far, far stranger than either conception. By the close of 2025, it was possible to know the true purpose of LLMs: to act as the engines for a previously-impossible category of software.
The reason that this piece grabbed me was its opening.
If you asked me in 2024 what my biggest fear was, I’d have told you: I was afraid my best years were behind me, as someone who builds things.That speaks to me. I've made and built things with software for the better part of 40 years, professionally for 30 or more. Even as my primary focus increasingly became communicating, organising conferences, and connecting people, it remained important to me to make and build things. Often they were tools we used internally to run our conferences and other systems better, but sometimes they were just ideas I wanted to explore. Clearly something has shifted over the last few weeks. Perhaps people took time off over the holiday period to spend a bit more time working with ChatGPT, Claude, or Google's large language model offerings, all of which released significantly improved models in terms of capabilities—particularly when it comes to code—in the latter part of last year. People who gave these models a go 6, 12, or 18 months ago and found them underwhelming came back and realised how much more capable they've become. My timeline across social media, in blog posts, and on podcasts is full of people now thinking more deeply about the implications of all this. So over the coming weeks you'll see here, as you have in recent days, a collection of pieces I think are valuable in helping explore these ideas.
Ralph Wiggum Loop Explained
AI, AI Native Dev, software engineering
The Ralph Wiggum Loop is getting a lot of attention in the AI agent space, but there’s still confusion about what it actually is and what problem it’s trying to solve. In this video, we break down the real failure mode behind long-running agent loops. Context accumulation, why retries make agents worse over time, and why common fixes like compaction can be lossy. The Ralph Wiggum Loop is one response to that problem. Not as a magic trick, but as a pattern that resets context while preserving progress through external memory and review. This video uses goose as the concrete environment to explore the idea, but the concepts apply broadly to agentic workflows.
It's a very good, succinct, and short overview of the Ralph Wiggum loop, which is all the rage right now. If you want to know where the fuss is about, set aside a handful of minutes and get up to speed with this.
As AI coding agents take flight, what does this mean for jobs?
AI, LLMs, software engineering
But if AI is doing more of the software building grunt work, what does that mean for the humans involved? It’s a question that’s front-of-mind for just about everyone in the industry. Anthony Goto, a staff engineer at Netflix, addressed this matter directly on TikTok a few weeks back. The most common question that he hears from new graduates and early-career engineers, he said, is whether they’ve made a mistake entering software development just as AI tools are accelerating. “Are we cooked?” is how he succinctly summed up the concern.
Clearly, this is a question that is front of mind for a lot of folks in Software Engineering right now. In this piece from TESSL, there's a useful roundup of what some prominent and well-known software engineers have been saying recently about the impact of AI and large-size models on Software Engineering.
Code as Commodity
Thanks to generative AI, code is following a similar pattern. Projects that would have been uneconomic through traditional software development are now just a prompt away. Those 500+-products-per-day on Product Hunt? Not all of them are good, but that’s what abundance brings.
But this doesn’t mean developers are obsolete. It means that the locus of value is broadening as this exclusive skill becomes more widely accessible.
Thus, the real question isn’t “will we be replaced?” but, “what becomes valuable when code itself is cheap?”
Over the course of the last three years, I've worked extensively with large language models to write code. I started in late 2022 when ChatGPT first emerged, working with it to help write Bash scripts that would allow me to better take advantage of FFmpeg to automate aspects of a workflow that had been very manual—getting clips from videos at particular timestamps.
Looking back, I probably could have done this just as quickly without using the LLM, certainly not a lot more slowly. But something about it felt compelling. Over the last three years, I've continued and increasingly worked with these tools and have seen them get better and better, sometimes on exactly the same task.
Somewhere around the middle of 2025, I started to feel that we might be on an S-curve with the capabilities of the models, at least when it comes to coding. An S-curve is one which looks exponential in growth but then plateaus—it approaches an asymptote. And it felt like we might have been plateauing. We had very good models, and even if they never got much better, they would still deliver a tremendous amount of economic value.
Toward the end of 2025, particularly with the launch of Opus 4.5 and Claude Code (which is how I now work with that model), it felt like we had a huge leap forward in capabilities—not just in what the models could do step by step, but in their longer-term approach to solving a problem. It was no longer a turn-by-turn affair; I could set up a task and the model could run for an extended period and, more or less in a single shot, create something that even six months before might have taken hours of turn-by-turn work to refine and ensure it worked the way I wanted.
At the beginning of 2025, Dario Amodei, one of the founders of Anthropic, predicted that by the end of the year 90% of code would be written by large language models. Midway through the year, that looked like a ludicrous prediction, and there were numerous mocking references to it. By the end of last year—certainly by now—I think it's plausible. Anthropic themselves claim to have built their new Cowork feature in ten days largely this way, and certainly in my experience, 90% of the code I would have written by hand three years ago is now written by a large language model. I know as much as almost anyone about front-end development and the code that goes behind it: best practices, accessibility, performance. I wouldn't hand-write just about any of this anymore, except when it comes to maintaining legacy systems. The next step for me is to see how well Claude Code and Opus 4.5 will do at helping me maintain some quite significant legacy systems I built over a period of as much as twenty years.
The assumption underlying this essay by friend of Web Directions Chris Messina—that code is essentially a commodity now, and not just code but actually software, and indeed entire products are—is at least a decent working hypothesis to explore. For someone who has invested 40 years of their life getting pretty good at writing all kinds of code, this could be terrifying. My work is commodified; my knowledge is a commodity.
If we look through history, when these things happen—a famous example being the weavers in the first part of the 19th century, who went from being artisans, incredibly well paid by the standards of the day for manual labour, to being commoditised within years by mechanical steam-powered looms—history teaches us we should perhaps be concerned.
Here Chris asks the question: "What can be our value when code itself is a commodity?" If you write software, or design software, or work in the development of these systems as a product manager, you should sit down and read this essay and explore that question for yourself.
AI-Assisted Development at Block | Block Engineering Blog
AI, AI Native Dev, LLMs, software engineering
About 95% of our engineers are regularly using AI to assist with their development efforts. The largest population is at Stage 5, running a single agent mostly outside of an IDE. The second largest population is at Stage 6 and is running 3-5 agent instances in parallel. Then there’s a small population that is actively building our internal agent orchestrator in preparation for the inevitable.
So how does an engineering organization move from Stage 1, where engineers are just starting their AI-assisted coding journey, to an advanced stage where they are managing so many parallel agents that they now need an orchestrator? Here’s how we’re doing it at Block.
I think it's very valuable to read about the experiences of not just individual software engineers but larger organisations in their adoption of machine learning and generative AI in their software engineering practises. Here Angie Jones from Block's open source team talks about how Block is adopting these technologies. This is a large organisation doing serious work in the financial technology space, and so I think it's very valuable to pay attention to what teams like this are doing.
Porting MiniJinja to Go With an Agent
AI Native Dev, software engineering
Turns out you can just port things now. I already attempted this experiment in the summer, but it turned out to be a bit too much for what I had time for. However, things have advanced since. Yesterday I ported MiniJinja (a Rust Jinja2 template engine) to native Go, and I used an agent to do pretty much all of the work. In fact, I barely did anything beyond giving some high-level guidance on how I thought it could be accomplished.
I've been posting a few pieces like this from really experienced and knowledgeable software developers, sharing how they have been working with code generation and the lessons they've learned.
I think there is a couple of values in paying attention to things like this:
1. These are not randos on LinkedIn pontificating about the future of coding. These are seasoned software engineers who often have expressed, like Armin has in the past, scepticism.
2. About the value of these tools and it's also about real-world work they are doing and at least some lessons they've learned along the way of doing it.
So you may need proof points or convincing about the capability of these technologies. Or you may already be using them and could learn valuable lessons from people on a similar journey.
Mike Olson – Managing AI Like You Manage People
AI Native Dev, software engineering
With the release of Claude Opus 4.5 (and the pace of improvement in frontier models), we’ve reached the point where AI coding assistants can handle tasks that would previously require a team of skilled developers. The capabilities are impressive enough that drawing parallels between managing AI agents and managing human teams feels less like a thought experiment and more like practical advice.
As someone who has spent years in engineering management and who has more recently been working extensively with AI coding tools, I’ve noticed that the skills transfer remarkably well in both directions. Here are some patterns that work for both.
Working with Agentic coding systems like Claude Code is a significant change, particularly for software engineers used to writing most if not all of the code they work with. As an increasing number of people have observed, working with these systems is much closer to managing developers than being the developer.
This piece takes lessons from working as an engineering manager for with people and applies them to working with Claude code.
The Economics of AI Coding: A Real-World Analysis
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.
I've seen a 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.
Agent Guardrails and Controls | Block Engineering Blog
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.
More thoughts from BLoC's engineering team about security models for MCP-based systems, particularly cross-site request forgery (CSRF) attacks and how to mitigate those.
Why AI is pushing developers toward typed languages – The GitHub Blog
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.
My instinct is like that of far better, more knowledgeable developers like Brett Taylor is that 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. 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.
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.
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é it 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.
Testing Pyramid of AI Agents | Block Engineering Blog
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.
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 system? Here are some thoughts from Anthropic’s Angie Jones
Introducing beginners to the mechanics of machine learning – Miriam Posner
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.
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.
Block red-teamed its own AI agent to run an infostealer • The Register
“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.”
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 there CISO talks about some of the implications for security and some tactics for addressing those challenges.
“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.
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.
Attention? Attention!
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.
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.
Getting started with Claude for software development
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.
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 US account with Claude, giving you access to 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.
Origin Story: A Tale of Two Ralphs
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.
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 Jeff 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.
LLM predictions for 2026, shared with Oxide and Friends
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.
Here’s a series of predictions by Simon Wilson 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 practise of software engineering.