A huge weekend reading from Web Directions

Computer surrounded by vibrant red roses and lush green leaves, with a glowing screen, keyboard, and a mouse.

Latent Patterns builds Latent patterns. I’ve taken some of the ideas behind “The Weaving Loom” and inverted them, put them into the product itself and have perhaps accidentally created a better Lovable. It’s interesting because I see all these developer tooling companies building for the persona of developers, but to me, that persona no longer exists. You see, within latent patterns, the product (latent patterns) is now the IDE. If I want to make a change to something, I pop on designer mode, and this allows me to develop LP in LP. I can make changes to the copy or completely change the application’s functionality using the designer substrate directly from within the product, then click the launch agent to ship.

Source: A Sneak Preview Behind an Embedded Software Factory – Geoff Huntley

Geoff Huntley, who is very much at the forefront of exploring the deeper impact of agentic coding systems on software engineering practice, thinks that

[he] might retire most developer practices, including CI/CD.

I think he’s on to something. I think all the practices of software engineering that we have developed over the last nearly 60 years — let’s say since the software engineering crisis of the late 60s — are now contingent. And it doesn’t mean they’re wrong, but we need to recognise that they emerged in a certain environment where certain things were scarce. There was a high coordination cost of having multiple people working on the same codebase, and as agentic systems become increasingly capable, those costs shift, and so the practices we developed to manage them need to be reconsidered.

I’ll actually go a step further. I think Geoff isn’t, perhaps, sufficiently ambitious here because he still imagines a world of software, of applications. And I have a growing inclination that where we’re going we won’t need applications.

Rapid Application Development Is Back

A sneak preview behind an embedded software factory. I suspect rapid application dev is back.

Every second counts; even sixty seconds for CI/CD is too long. The natural destination from here for @latentpatterns is live editing programming memory. Sure, I could move content from the file system to the database.

But the more interesting thing is the application code. How can we kill CI/CD as it is today and instead safely live-edit the program’s memory?

Source: A Sneak Preview Behind an Embedded Software Factory – Geoff Huntley, LinkedIn

Back in the 90s, it was not at all uncommon to simply what we would now call deploy to production via FTP. We would update our HTML, our CSS, maybe a little bit of JavaScript or PHP, and then simply YOLO it (the acronym didn’t then exist) to our FTP server, where it was live in production.

Over the last 30 years or so we’ve become a bit more circumspect about this, in no small part because what we build has become increasingly complex, and our local environments have become further and further distinct from our production environments.

Here, though, Geoff Huntley of Ralph Wiggum fame is arguing perhaps we are returning to an era of deploying to production as rapid development becomes a thing once more.

Write-Only Code

Six months ago, if you had asked me how much production code would eventually be written by AI, I would have claimed a large percentage. LLMs are clearly a massive productivity boost for software developers, and the value of humans manually translating intent into lines of code is rapidly depreciating. I also believed, and still do, that humans whose primary job is to build and operate enterprise software are not going anywhere, even as their day-to-day work is fundamentally redefined by this newest abstraction.

What I underestimated was how little of that future work would involve reading code at all.

I am now convinced that for better and worse we are barreling toward a future where a large and growing fraction of production code is never read by a human. Not skimmed. Not reviewed. Not tweaked. I have taken to calling this Write-Only Code(shout-out to Waldemar Hummer of LocalStack for helping coin the term) and have been spending a lot of time thinking through what it means for us as an industry.

Source: Write-Only Code – Heavybit

This is a few weeks old now. It seems almost like ancient history. But it’s one of the first things I’ve read which started to articulate the idea that increasingly software engineers may not even be reading the code that we are responsible for.

Agentic Engineering Practice

The 8 Levels of Agentic Engineering

AI, AI Engineering, coding agent, software engineering

AI’s coding ability is outpacing our ability to wield it effectively. That’s why all the SWE-bench score maxxing isn’t syncing with the productivity metrics engineering leadership actually cares about. When Anthropic’s team ships a product like Cowork in 10 days and another team can’t move past a broken POC using the same models, the difference is that one team has closed the gap between capability and practice and the other hasn’t.

Source: The 8 Levels of Agentic Engineering – Bassim Eledath

Way back in the dark ages of October 2025, Guy Podjarny at TESSL used the model of autonomous driving and its five levels to articulate five levels of agentic coding.

Well, stand back because Bassim Eledath now identifies eight levels of agentic engineering.

I Built a Programming Language Using Claude Code

Over the course of four weeks in January and February, I built a new programming language using Claude Code. I named it Cutlet after my cat. It’s completely legal to do that. You can find the source code on GitHub, along with build instructions and example programs.

I went into this experiment with some skepticism. My previous attempts at building something entirely using Claude Code hadn’t worked out. But this attempt has not only been successful, but produced results beyond what I’d imagined possible. I don’t hold the belief that all software in the future will be written by LLMs. But I do believe there is a large subset that can be partially or mostly outsourced to these new tools.

Building Cutlet taught me something important: using LLMs to produce code does not mean you forget everything you’ve learned about building software. Agentic engineering requires careful planning, skill, craftsmanship, and discipline, just like any software worth building before generative AI. The skills required to work with coding agents might look different from typing code line-by-line into an editor, but they’re still very much the same engineering skills we’ve been sharpening all our careers.

Source: I Built a Programming Language Using Claude Code – Ankur Sethi

Geoff Huntley, the discoverer of the Ralph Wiggum technique, used that approach — or indeed discovered that approach — while developing a programming language he called Cursed.

Over the last couple of months Ankur Sethi developed his own, probably somewhat less cursed programming language. And here he writes about his experience with that and broader experience working with large language models.

Design-First Collaboration

When I pair program with a colleague on something complex, we don’t start at the keyboard. We go to the whiteboard. We sketch components, debate data flow, argue about boundaries. We align on what the system needs to do before discussing how to build it. Only after this alignment — sometimes quick, sometimes extended — do we sit down and write code. The whiteboarding is not overhead. It is where the real thinking happens, and it is what makes the subsequent code right. The principle is simple: whiteboard before keyboard.

With AI coding assistants, this principle vanishes entirely. The speed is seductive: describe a feature, receive hundreds of lines of implementation in seconds. The AI may understand the requirement perfectly well — an email notification service with retry logic, say. But understanding what to build and collaborating on how to build it are two different activities, and AI collapses them into one. It does not pause to discuss which components to create, whether to use existing infrastructure or introduce new abstractions, what the interfaces should look like. It jumps from requirement to implementation, making every technical design decision silently along the way.

The solution, I believe, is to reconstruct the whiteboarding conversation that human pairs do naturally — making the AI’s implicit design thinking explicit and collaborative. Rather than asking for implementation directly, I walk through progressive levels of design. Each level surfaces a category of decisions that would otherwise be buried in generated code.

Source: Design-First Collaboration – Rahul Garg, Martin Fowler

Rahul Garg outlines an approach to working with LLMs that puts an emphasis on upfront collaboration to ensure the best possible design before handing responsibility to an agentic coding system to implement that design.

Humans and Agents in Software Engineering Loops

The software delivery feedback loops: An upper "why" loop connected to a lower "how" loop. The why loop iterates over an idea and working software. The how loop iterates over interim artefacts like specs, code, and tests.

We need to adopt classic “shift left” thinking. Once upon a time we wrote all of our code, passed it to a QA team to test, and then tried to fix enough bugs to ship a release. Then we discovered that when developers write and run tests as we work we find and fix issues right away, which makes the whole process faster and more reliable.

What works for humans can work for agents as well. Agents produce better code when they can gauge the quality of the code they produce themselves rather than relying on us to check it for them. We need to instruct them on what we’re looking for, and give them guidance on the best ways to achieve it.

Source: Humans and Agents in Software Engineering Loops – Kief Morris, Martin Fowler

Kief Morris advocates we adopt shift-left thinking when it comes to AI-assisted software engineering. The “why” loop is something for humans, while the “how” loop is something for agentic systems to focus on.

Start Where You Are: A Practical Guide to Building with AI

A time-blocked schedule where I have 30-minute increments for agentic tasks, such as 'triage issues to Copilot', and 2 hour blocks of time for 'development time'

Here’s the thing I want to emphasize, though: this is a really good time to get good at this. The best practices for building with AI haven’t been written yet. Builders like you and me get to write them. This is an incredible time to jump in and be part of the story that figures this whole thing out.

The framework I use to describe the different ways to build with AI is layered. Most people start with one thing, get comfortable, and then add the next. Let’s walk through it.

Source: Start Where You Are: A Practical Guide to Building with AI – Brittany Ellich

Brittany Ellich, an experienced software engineer, talks about her approach to working with agentic coding systems. Always really good tips and lessons to pick up when people share their workflows like this.

3 Principles for Designing Agent Skills

AI, AI Engineering

Wooden desk with cards featuring icons like tools, globe, and lightbulb, a coffee cup, succulent, yellow rubber duck.

Skills are an open standard supported by most major AI coding tools: Claude Code, Goose, Cursor, Amp, GitHub Copilot, Gemini CLI, VS Code, and many more.

At their simplest, a skill is a folder with a SKILL.md file with a set of instructions that an agent can discover and load on demand. Think of it like a playbook. When an agent encounters a task that matches a skill’s description, it loads those instructions and follows them. Skills can also include supporting files like scripts, templates, MCP servers, and configuration files.

The beauty is in the portability. Write a skill once, and it works for anyone across any agent that supports the format.

Source: 3 Principles for Designing Agent Skills – Block Engineering Blog

Here’s a good introduction to agent skills from the open-source team at Block.

Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?

AI, AI Engineering, coding agent, software engineering

Text titled "Evaluating AGENTS.md" with authors listed and a paragraph discussing repository-level context files for coding agents.

Abstract: A widespread practice in software development is to tailor coding agents to repositories using context files, such as AGENTS.md, by either manually or automatically generating them. Although this practice is strongly encouraged by agent developers, there is currently no rigorous investigation into whether such context files are actually effective for real-world tasks. In this work, we study this question and evaluate coding agents’ task completion performance in two complementary settings: established SWE-bench tasks from popular repositories, with LLM-generated context files following agent-developer recommendations, and a novel collection of issues from repositories containing developer-committed context files.

Across multiple coding agents and LLMs, we find that context files tend to reduce task success rates compared to providing no repository context, while also increasing inference cost by over 20%. Behaviorally, both LLM-generated and developer-provided context files encourage broader exploration (e.g., more thorough testing and file traversal), and coding agents tend to respect their instructions. Ultimately, we conclude that unnecessary requirements from context files make tasks harder, and human-written context files should describe only minimal requirements.

Source: Evaluating AGENTS.md – arXiv

These recent counterintuitive results might give us reason to rethink a very common pattern with agentic coding, which is to provide — via skills and agents markdown files — a whole lot of context for any project. The findings here are that this may actually degrade performance.

The Human Experience of AI-Driven Change

My (Hypothetical) SRECon26 Keynote

AI, o11y, observability, software engineering

Colorful unicorn with rainbow mane and hearts inside a red heart outline, above the text "SRE NOT SORRY" in bold letters.

Which means it was almost a year ago that Fred Hebert and I were up on stage, delivering the closing keynote at SRECon25.

We argued that SREs should get involved and skill up on generative AI tools and techniques, instead of being naysayers and peanut gallerians. You can get a feel for the overall vibe from the description:

What I do know is that one year ago, I still thought of generative AI as one more really big integration or use case we had to support, whether we liked it or not. Like AI was a slop-happy toddler gone mad in our codebase, and our sworn duty as SREs was to corral and control it, while trying not be a total dick about it.

I don’t know when exactly that bit flipped in my head, I only know that it did. And as soon as it did, I felt like the last person on earth to catch on. I can barely connect with my own views from eleven months ago.

So no, I don’t think it was obvious in early 2025 that AI generated code would soon grow out of its slop phase. Skepticism was reasonable for a time, and then it was not. I know a lot of technologists who flipped the same bit at some point in 2025.

If I was giving the keynote at SRECon 2026, I would ditch the begrudging stance. I would start by acknowledging that AI is radically changing the way we build software. It’s here, it’s happening, and it is coming for us all.

It is very, very hard to adjust to change that is being forced on you. So please don’t wait for it to be forced on you. Swim out to meet it. Find your way in, find something to get excited about.

Source: My (Hypothetical) SRECon26 Keynote – Charity Majors

Charity Majors is a genuine giant in the field of software engineering. One of the originators of modern observability, founder of Honeycomb, author, highly respected speaker.

Here she reflects on her transformation over the last 12 months when it comes to thinking about AI and software engineering. She captures a path that I think many software engineers have trod over the last year. And I think this should be required reading — whether a year ago you were very optimistic and positive about AI and software engineering, or like Charity, far more sceptical.

AI Is Creating an Identity Crisis for Software Engineers

The speed at which AI is reshaping software development — measured in months, not years — is stirring a mix of excitement and anxiety. Last week, the tech company Block laid off more than 40% of its workforce, saying the cuts reflected AI-driven efficiencies.

For some software developers, there is an added reckoning: If the core act of coding — long a source of status and identity — becomes automated, what does it actually mean to be an engineer?

The threat isn’t just displacement. It’s a total recalibration of identity.

Source: AI Is Creating an Identity Crisis for Software Engineers – Business Insider

Annie Vela, who is quoted in this article, wrote “The Software Engineering Identity Crisis” a year ago.

A year ago we ran our first Unconference around the topic of AI and software engineering. At that time, I felt a lot of the participants — very experienced software engineers with years, if not decades, of professional experience — were still more sceptical about AI and software engineering than I expected.

Was that a kind of defence mechanism against this coming challenge to a very important part of our professional identity?

The Human-in-the-Loop Is Tired

AI, LLMs, software engineering

Dual monitors displaying coding interfaces; left screen shows four code windows in dark mode, right screen shows a text editor.

I recently had a conversation with my colleague Douwe, who maintains the Pydantic AI framework and has been one of the most thoughtful people I know about integrating LLMs into open source workflows. He described waking up to thirty PRs every morning, each one pulled overnight by someone’s AI, and needing to make snap judgment calls on every single one. The temptation to delegate the review itself to an AI was enormous. But, as he put it: “at that point, what am I still doing here?”.

The honest truth is that in the last few months, there have been days when I have spent close to two full days writing a plan for an LLM to execute: obsessively clarifying, specifying, re-specifying, only to have it still do something inexplicably stupid. Port a React hook into a Storybook story file. Read from the wrong plan. Invent components that don’t exist. And these aren’t errors of capability; they’re errors of coherence. The models are smart enough to produce plausible code, but not always smart enough to maintain a coherent intent across a complex change.

Source: The Human-in-the-Loop Is Tired – Pydantic

I think it’s worth reading personal accounts like this and others that we have posted recently of how people are responding as software engineers to the way in which our profession is transforming at an incredibly rapid pace.

I think the anxiety folks are feeling is real and understandable. I think the fatigue, the exhaustion that many are feeling, including me, is real. Seeing other people’s responses can perhaps normalise how we might be feeling ourselves.

AI Made Writing Code Easier. It Made Engineering Harder.

AI Made Writing Code Easier. It Made Being an Engineer Harder.

AI assistants autocomplete your functions. Agents scaffold entire features. You can describe what you want in plain English and watch working code appear in seconds. The barrier to producing code has never been lower.

And yet, the day-to-day life of software engineers has gotten more complex, more demanding, and more exhausting than it was two years ago.

This is not a contradiction. It is the reality of what happens when an industry adopts a powerful new tool without pausing to consider the second-order effects on the people using it.

Source: AI Made Writing Code Easier. It Made Engineering Harder. – Ivan Turkovic

If you’re a software engineer and feel right now a lot of stress, a lot of anxiety, a lot of uncertainty, rest assured you’re very far from alone. Here are some timely thoughts on why software engineering just got a whole lot more challenging.

We Might All Be AI Engineers Now

Everyone knows the models are good now. That’s not news. But most people still miss the point. They see AI-generated code, call it slop, and move on. Sure, unguided, it is slop. But guided? The models can write better code than most developers. That’s the part people don’t want to sit with. When guided. When you know what you want. When you know what architecture to reach for. When you understand the tradeoffs and can articulate them clearly. The game goes on easy mode.

If you’ve spent years building it, understanding systems, understanding architecture, understanding why things break, you’re not being replaced. You’re being amplified.

Source: We Might All Be AI Engineers Now

This aligns with my experience and thinking — though the question is, is this for say the next few months or couple of years? Or forever?

Software Engineering Perspectives

When AI Writes Almost All Code, What Happens to Software Engineering?

Smiling robot beside a screen displaying code and a connected keyboard, with text "What happens now?" above.

The bad: declining value of expertise. Prototyping, being a language polyglot or a specialist in a stack are likely to be a lot less valuable, looking ahead.

The good: software engineers more valuable than before. Tech lead traits in more demand, being more “product-minded” to be a baseline at startups, and being a solid software engineer and not just a “coder” will be more sought-after than before.

The ugly: uncomfortable outcomes. More code generated will lead to more problems, weak software engineering practices start to hurt sooner, and perhaps a tougher work-life balance for devs.

Source: When AI Writes Almost All Code, What Happens to Software Engineering? – The Pragmatic Engineer

The Pragmatic Engineer is a blog and podcast that many experienced software engineers pay close attention to. Gergely Orosz is a deeply experienced software engineer with a track record at companies like Skype and Uber, who brings that knowledge to bear on the state of software engineering today. Here, a few weeks ago, he reflects on what has been happening since late 2025 in terms of the capabilities of AI when it comes to software engineering.

Owning Code in the Age of AI

Tower of Babel illustration with a spiraling ramp, surrounded by a vast landscape and cityscape in an antique style.

Software engineering is going through a shift that feels small on the surface but changes something fundamental: code is no longer scarce.

For decades, writing software was constrained by human typing speed and cognitive load. Engineers produced code at roughly the same pace they could understand it. That relationship shaped our entire culture: code reviews, ownership models, testing philosophies, and even how we thought about responsibility.

Today a single engineer can generate thousands of lines of code in minutes. Features that once took days can appear in an afternoon. Small teams suddenly move at the speed that used to require entire organizations. And the uncomfortable reality is this: not using AI is no longer a real option. A team that refuses AI assistance will simply move slower than a team that embraces it.

But this acceleration raises a question I keep coming back to. If AI is producing most of the code, what does it mean to “own” it?

Source: Owning Code in the Age of AI – Mozilla AI

All software engineers are at some stage of grappling with this question — who owns the code, in essence who is responsible for the code written by agentic systems at our behest?

No answers, just a lot of questions — which is as it should be right now.

Yes, Learning to Code Is Still Valuable

Every few weeks, someone shares a bold opinion: “Don’t bother learning to code, AI will do it all.” I’ve seen this from VCs, influencers, and people who have never actually shipped a production system.

In the past few weeks, I’ve written about the human-in-the-loop, the future of software engineering, and what these changes mean for enterprise organizations. The core point across all three: AI moved the bottleneck from coding to review, from doing the work to making decisions.

Here’s what many people miss: you can’t develop good judgment without first learning to code.

Source: Yes, Learning to Code Is Still Valuable – Matteo Collina

Matteo Collina, core contributor to Node.js and prolific open-source developer, argues that it’s still valuable to learn how to code.

AI and the Ship of Theseus

AI, Engineering Leadership, software engineering

Because code gets cheaper and cheaper to write, this includes re-implementations. I mentioned recently that I had an AI port one of my libraries to another language and it ended up choosing a different design for that implementation. In many ways, the functionality was the same, but the path it took to get there was different. The way that port worked was by going via the test suite.

There are huge consequences to this. When the cost of generating code goes down that much, and we can re-implement it from test suites alone, what does that mean for the future of software? Will we see a lot of software re-emerging under more permissive licenses? Will we see a lot of proprietary software re-emerging as open source? Will we see a lot of software re-emerging as proprietary?

It’s a new world and we have very little idea of how to navigate it. In the interim we will have some fights about copyrights but I have the feeling very few of those will go to court, because everyone involved will actually be somewhat scared of setting a precedent.

Source: AI and the Ship of Theseus – Armin Ronacher

The first-order effects of transformative technologies are the ones we think about first, and the ones that are easiest to make at least some sort of predictions about. It’s the second-order effects — the impact on economics, the legal implications — that are much harder to reason about.

That’s what Armin Ronacher is doing here when he ponders the implications of increasingly inexpensive code generation, particularly of existing systems based simply on their API, and what consequences that will have in terms of software licensing and intellectual property.

AI Economics & Adoption

Do AI-Enabled Companies Need Fewer People?

AI, economics, software engineering

About a year ago I made some predictions about the effect of AI on programming jobs. Block laid off 40% of its staff claiming AI made them more efficient. Is that really true or did they just over-hire? Let’s look at some data and see what’s really happening.

In February 2026, global venture capital hit a single-month record: $189 billionflowed into startups in 28 days. Three companies got 83% of that funding: OpenAI, Anthropic, and Waymo. Two months into 2026, startups have already raised more than half of what they raised in all of 2025. There is an unprecedented amount of money going into startups, partly because AI is capital-intensive in a way other technology boom cycles have not been. So if you looked at just “headcount per dollar raised” it would definitely look like AI startups are more headcount-efficient. But is that really what’s going on?

My read on this is: the startup economy is undergoing a structural transformation here. Startups are substituting compute for labor at an increasing rate. I still remain optimistic that this is going to result in a lot more companies doing a lot more things, but so far it hasn’t happened. But companies’ claims that they can get by with way fewer people in the age of AI does seem to be true.

Source: Do AI-Enabled Companies Need Fewer People? – Laurie Voss

Laurie Voss takes a bit of a deeper look into the impact of AI on employment levels, particularly in technology companies, in the wake of Block’s recent layoff of 40% of its staff, claiming that was due to AI efficiencies.

Is that the case?

AI Adoption Has to Be Driven from the Top

While researching my AI strategy book, it became clear that the complexities of data integration and the expense of AI sprawl means AI policies and intentions must be set and communicated from the top. That doesn’t mean an AI mandate, but ensuring everyone knows why any AI tool is important to the business.

“Make sure the ‘why’ of your AI rollout is clear, and repeat it until everyone on your team knows it by heart,” a recent report by Multitudes advises.

Source: AI Adoption Has to Be Driven from the Top – LeadDev

It’s not uncommon to see research suggest that at least enterprise adoption of AI technologies falls far short of the breathless promises we hear from CEOs at their keynotes.

In a just-published paper from the National Bureau of Economic Research,

over 80% of firms reporting no impact on either employment or productivity

And yet, at least anecdotally, developers individually report enormous increases in their productivity. So what is going on? And how can organisations adopt these technologies in ways that do deliver on the promises?

At LeadDev, Jennifer Riggins argues “AI adoption has to be driven from the top — not by mandate, but clear leadership and guidance over why AI is being adopted.”

Is the AI Compute Crunch Here?

AI, AI Engineering, economics

Anthropic status page showing degraded performance across claude.ai, platform.claude.com, Claude API, and Claude Code over 30 days

In January I wrote about the coming AI compute crunch. Two months later, I think “coming” was the wrong word.

We’re starting to see serious signs that some providers are really struggling to meet demand. I still think this is a seriously underpriced risk which has major implications for how much adoption AI can have over the next year or two.

Source: Is the AI Compute Crunch Here? – Martin Alderson

For all the talk of an AI bubble, which seems to have receded in the last few weeks anyway, what doesn’t seem to be factored in is just how much demand there really is for these tokens, this kind of “compute”.

Martin Alderson has been tracking how much computational capability there is and the demand for it, and suggests that we’ve now hit a crunch that is being reflected in downtime for in particular Anthropic, who are clearly undergoing a meteoric increase in demand.

We Are Changing Our Developer Productivity Experiment Design

Graph showing AI impact on development time from Feb 2025 to Feb 2026. Initial study shows speedup; follow-up shows selection effects.

METR previously published a paper which found the use of AI tools caused a 20% slowdown in completing tasks among experienced open-source developers, using data from February to June 2025.

To understand how AI is impacting developer productivity over time, we started a new experiment in August 2025 with a larger pool of developers using the latest AI tools.

Unfortunately, given participant feedback and surveys, we believe that the data from our new experiment gives us an unreliable signal of the current productivity effect of AI tools. The primary reason is that we have observed a significant increase in developers choosing not to participate in the study because they do not wish to work without AI, which likely biases downwards our estimate of AI-assisted speedup. We additionally believe there have been selection effects due to a lower pay rate (we reduced the pay from $150/hr to $50/hr), and that our measurements of time-spent on each task are unreliable for the fraction of developers who use multiple AI agents concurrently.

Source: We Are Changing Our Developer Productivity Experiment Design – METR

METR’s research last year into open-source developer productivity using AI caused quite a stir because it suggested — or even demonstrated, in many people’s opinion — that the uplift in developer productivity that many developers self-reported when using AI-based coding systems was perhaps illusory.

They are returning to this particular area of research, but as with many things, it is more complicated than it originally appeared.

If you’re interested in diving more deeply into this, there is a fantastic in-depth conversation between METR’s Joel Becker and Shawn Wang at Latent Space recently.

AI & the Broader Picture

Four Observations on AI and Capitalism

AI, Design, economics

Dark background with "Praxis" in bold white text, thin lines and curves forming a minimalist abstract design.

These four pieces form a single argument, read in sequence. Each observation builds on the last, moving from diagnosis to possibility.

We imagine technological change but not economic change. The technology is new. The economics are Victorian. This is a failure of imagination we’ve chosen not to notice.

The production work compressed. What remains is thinking. Sensemaking labour has always existed, but it was buried in deliverable production time. Now it’s exposed — for better and worse.

AI promises abundance but business models manufacture scarcity. The marginal cost approaches zero. The price does not. The gap is where capital accumulates.

Source: Four Observations on AI and Capitalism – isomorphous.design

This series of four short provocations should be recommended reading. So I’m recommending you read them. Each contains what could be several essays in their own right.

A Soft-Landing Manual for the Second Gilded Age

AI, economics

Abstract smooth, metallic 3D shape with twisting, flowing curves on a black background.

AI is arriving fast, the old economic arrangements are visibly failing, and the dominant narratives about what comes next have split into 2 equally unhelpful camps: utopian accelerationists who believe the market will sort everything out if we build fast enough, and existential doomers who’ve convinced themselves that the only possible outcome is either human extinction or permanent mass unemployment. Both camps share a singular trait: they’ve decided the future is already determined and that human agency is irrelevant to whatever happens next.

Source: A Soft-Landing Manual for the Second Gilded Age – Joan Westenberg

Joan Westenberg is one of the most thoughtful and knowledgeable people I have ever had the privilege to know. Everything she writes, and she writes voluminously, is worth reading. But this in particular is a standout piece.

I simply recommend when you have a few minutes, you take the chance to read it and sit with how it makes you feel. Perhaps relief from the anxiety you might feel about how AI is upending so much of what we have taken for granted for decades. Perhaps anger and opposition. Sit with that. Ask yourself what about this is challenging to you, what do you believe that it questions.

The world does change — not often, but when it does, that change isn’t gradual.

There seems little doubt that we are in the midst of a transformation that hasn’t been seen for generations, one which will upend many things we have taken to be foundational to our society and culture. Facing those challenges honestly, including those things we held to be immutable, is the challenge of our time.

Joan holds out hope for what that transformation might bring.

Billion-Parameter Theories

AI, LLMs

For most of human history, the things we couldn’t explain, we called mystical. The movement of stars, the trajectories of projectiles, the behavior of gases. Then, over the course of a few centuries, we pulled these phenomena into the domain of human inquiry. We called it science.

What’s remarkable, in retrospect, is how terse those explanations turned out to be. F=ma. E=mc². PV=nRT.

The Enlightenment and its intellectual descendants gave us a powerful toolkit for taming the complicated. And then we made the natural mistake of assuming that toolkit would scale to everything.

The concepts they developed were descriptive rather than prescriptive. Knowing that a system exhibits power law behavior tells you the shape of what will happen without telling you the specifics. You couldn’t pick these principles up and use them to intervene in the world with precision.

Take large language models. Fundamentally, a large language model is a compressed model of an extraordinarily complex system, the totality of human language use, which itself reflects human thought, culture, social dynamics, and reasoning. The compression ratio is enormous. The model is unimaginably smaller than the system it represents. That makes it a theory of that system, in every sense that matters, a lossy but useful representation that lets you make predictions and run counterfactuals.

So perhaps there are two layers of theory here. The system-specific layer, the trained weights, is large and particular to its domain. This will likely always be true. The theory of this economy or this climate will always be vast.

But the meta-layer, the minimal architecture that can learn to represent arbitrary complex systems, might be compact and universal. It might be exactly the kind of good explanation Deutsch would champion.

Source: Billion-Parameter Theories – Sean Linehan

I’ve long been very interested in complexity theory. It had its moment back in the late 1980s and early 1990s with chaos theory and a very popular science book from James Gleick.

Benoit Mandelbrot, he of the famed Mandelbrot set and one of the originators of the science, was something of a rock star.

In this long but very readable and I found engaging essay, Sean Linehan argues that large language models — attention-based models — are a new science. I highly recommend reading this, even if it’s not something you’ll apply in your everyday work.

AI Infrastructure & Models

AMI Labs: Real World. Real Intelligence.

AI, AI Engineering

Our main goal is to build intelligent systems that understand the real world.

Real-world data is continuous, high-dimensional, and noisy, whether it is obtained through cameras or any other sensor modality.
‍
Generative architectures trained by self-supervised learning to predict the future have been astonishingly successful for language understanding and generation. But much of real-world sensor data is unpredictable, and generative approaches do not work well.

AMI is developing world models that learn abstract representations of real-world sensor data, ignoring unpredictable details, and that make predictions in representation space.

Action-conditioned world models allow agentic systems to predict the consequences of their actions, and to plan action sequences to accomplish a task, subject to safety guardrails.

AMI will advance AI research and develop applications where reliability, controllability, and safety really matter, especially for industrial process control, automation, wearable devices, robotics, healthcare, and beyond.
‍
Founded by a globally distinguished team of scientists, engineers, and builders, AMI is a frontier AI research lab operating across three continents from day one.
‍

Source: AMI Labs

Yann LeCun is a genuine giant in the field of machine learning and AI who developed techniques that are at the heart of modern machine learning.

Until recently the head of the AI efforts at Meta, he’s long expressed scepticism that current large language model-based techniques are a pathway to AGI.

He, like a number of other researchers, believes that world models — models that have a genuine understanding of the world, rather than simply of human language — are that path. And today he announced a new company with a billion dollars in funding to further that work.

Is Harness Engineering Real?

AI, AI Engineering

Diagram showing a loop of LLM models labeled "Workflow / Agent Loop," emphasizing user context and engineering.

A common debate in my finance days was about the value of the human vs the value of the seat: if a trader made $3m in profits, how much of it was because of her skills, and how much was because of the position/institution/brand she is in, and any generally competent human could have made the same results?

The same debate is currently raging in “Harness Engineering”, the systems subset of Agent Engineering, and the main job of Agent Labs. The central tension is between Big Model and Big Harness. [An AI framework founder you all know] once confided in me at an OpenAI event: “I’m not even sure these guys want me to exist.”

Source: Is Harness Engineering Real? – Latent Space

If you work with Anthropic’s models or OpenAI’s or Google’s or other models, particularly as a software engineer, you’re almost certainly doing it with an environment like Claude Code or OpenAI’s Codex. And the release of Claude Cowork caused quite a stir a few weeks ago.

These harnesses or environments that enable us to work more effectively with models are considered by some to be the secret sauce in the explosion in capability of these kinds of tools in the last few months.

But do they matter that much? Is the work largely being done in the models, or is there something special that can be added by these kinds of harnesses? The folks over at Latent Space reflect on this today.

MCP Is Dead. Long Live the CLI.

AI, AI Engineering, MCP

I’m going to make a bold claim: MCP is already dying. We may not fully realize it yet, but the signs are there. OpenClaw doesn’t support it. Pi doesn’t support it. And for good reason.

I tried to avoid writing this for a long time, but I’m convinced MCP provides no real-world benefit, and that we’d be better off without it. Let me explain.

LLMs are really good at using command-line tools. They’ve been trained on millions of man pages, Stack Overflow answers, and GitHub repos full of shell scripts. When I tell Claude to use gh pr view 123, it just works.

Source: MCP Is Dead. Long Live the CLI.

For several months last year, MCP seemed to be all the rage when it came to AI engineering. But the last few months have definitely seen a cooling of the enthusiasm. Does that just mean they’ve become absorbed into people’s everyday work? Or are new practices and patterns emerging that minimise their impact?

This piece echoes things I’ve heard from quite a lot of developers in recent weeks — that they are in effect overkill in many circumstances, and there are more lightweight and better solutions available.

The Illusion of “The Illusion of Thinking”

AI, AI Engineering, LLMs

Graph showing accuracy vs. complexity for DeepSeek-V3 and DeepSeek-R1.

Very recently (early June 2025), Apple released a paper called The Illusion of Thinking: Understanding the Strengths and Limitations of Reasoning Models via the Lens of Problem Complexity. This has been widely understood to demonstrate that reasoning models don’t “actually” reason. I do not believe that AI language models are on the path to superintelligence. But I still don’t like this paper very much. What does it really show? And what does that mean for how we should think about language models?

I have a few issues with this paper. First, I don’t think Tower of Hanoi puzzles (or similar) are a useful example for determining reasoning ability. Second, I don’t think the complexity threshold of reasoning models is necessarily fixed. Third, I don’t think that the existence of a complexity threshold means that reasoning models “don’t really reason”.

Source: The Illusion of “The Illusion of Thinking” – Sean Goedecke

Sean Goedecke critiques a widely cited paper from Apple’s research team from around a year ago, which questions whether reasoning models actually reason. This critique undermines the central argument of that piece.

A Dream of Spring for Open-Weight LLMs: 10 Architectures from Jan–Feb 2026

AI, LLMs

Two model architectures, MiniMax-M2.5 in red and GLM-5 in blue, with bar chart showing group comparisons below.

In this article, I will walk you through the ten main releases in chronological order, with a focus on the architecture similarities and differences:

Since there’s a lot of ground to cover, I will be referencing my previous The Big LLM Architecture Comparison article for certain technical topics (like Mixture-of-Experts, QK-Norm, Multi-head Latent Attention, etc.) throughout this article for background information to avoid redundancy in this article.

Source: A Dream of Spring for Open-Weight LLMs – Sebastian Raschka

Open-weights models, even when very large, offer the prospect of running our own inference locally, saving money, and addressing privacy issues. But are they up to scratch? Here is a detailed overview of 10 high-profile open-weights models in early 2026.

Demystifying Evals for AI Agents

AI, LLMs, software engineering

Comparison diagram of single-turn LLM with prompt response and agent with tools, environment, task, and grading logic.

Good evaluations help teams ship AI agents more confidently. Without them, it’s easy to get stuck in reactive loops—catching issues only in production, where fixing one failure creates others. Evals make problems and behavioral changes visible before they affect users, and their value compounds over the lifecycle of an agent.

As we described in Building effective agents, agents operate over many turns: calling tools, modifying state, and adapting based on intermediate results. These same capabilities that make AI agents useful—autonomy, intelligence, and flexibility—also make them harder to evaluate.

Through our internal work and with customers at the frontier of agent development, we’ve learned how to design more rigorous and useful evals for agents. Here’s what’s worked across a range of agent architectures and use cases in real-world deployment.

Source: Demystifying Evals for AI Agents – Anthropic

Evals are the key quality assurance technique of working with agentic systems.

Here Anthropic talk about how to work with evals for AI agents.

Becoming a Web AI Practitioner: A Map of the Emerging Stack

AI Engineering, LLMs, web AI, webMCP

Glowing orange computer code displayed on a dark screen, with text lines overlapping and slightly blurred.

I quickly became fascinated with all the latest “Web AI” technologies, such as WebMCP, MCP Apps, MCP-UI, OpenAI’s Apps SDK, Google’s A2UI, and more. You’ll notice that MCP — the Model Context Protocol — is part of the name for some of these new technologies. That’s because MCP is a key connective protocol between AI agents and the Web. It allows agents to access web content, tools and services in a structured way.

I’ve also become extremely interested in on-device AI, using web browser technologies like LiteRT.js (a JavaScript runtime for running AI models in the browser using WebGPU) and Chrome’s built-in AI APIs, which provide access to on-device models like Gemini Nano.

Source: Becoming a Web AI Practitioner: A Map of the Emerging Stack – Richard MacManus

When we think of AI and LLMs, we essentially think of very large systems running in the cloud that perhaps we access via APIs.

But there’s a whole slew of AI technologies that run in the browser, that run on devices. Broadly speaking these have come to be known as Web AI. Here, Richard MacManus gives an overview of the landscape of Web AI.

Design & the Future of the Web

Do Websites Need Pages?

AI, software engineering, UI, web design

Until now, they’e been the most efficient way we’ve had to communicate information. But what actually are they?

They are a vestige of the past. Prior to websites, we had books. At the dawn of digital, we needed familiar metaphors to ease the transition. Books had pages, so we converted them into the digital domain.

Over the last two decades, we’ve made them more sophisticated. We now have entire systems of templates and flows and componentry. But the fundamental architecture of what a website is very clear.

But here’s the question underneath: do people need pages, or do they simply need intuitive ways of finding and exploring information?

Source: Do Websites Need Pages? – Fantasy

So close and yet — people as users are still central to this way of seeing. I’ll suggest that increasingly not people, but rather agents acting on their behalf, will be the primary audience for web “sites”.

AI-First Design Is a Culture Shift, Not a Tooling Upgrade

AI, Design

Six people sitting at a table with drinks and papers, laughing and interacting in a bright room with plants.

What interests me is something far less theatrical and far more consequential: how AI fundamentally changes the way product organisations learn. Over the past 6 months, we have invested deeply in AI-first design workflows, not as a side experiment or a hackathon, but as a serious shift in how we build.

The results have been tangible. We have significantly reduced the time to go from idea to validation. What previously took weeks now takes days, and traditional handoffs between design and engineering are starting to look a little different. Most importantly, we are getting through the build, measure, learn loop more often.

Source: AI-First Design Is a Culture Shift, Not a Tooling Upgrade

Just as the practice of software engineering is undergoing a transformation, so too is design. And just as right now we don’t really have answers, just a lot of questions in software engineering, in design people are asking those questions as well. So here are some thoughts about how design practice is transforming now that ostensibly things are easier to make.

Filesystems Are Having a Moment