Year round learning for product, design and engineering professionals

Your weekend reading from Web Directions.

This week, there’s not quite as many links. Not that I haven’t got a long queue, just that I have had so much happening, including working on a number of articles, one of which I did publish this week, which we published earlier this week.

In it, I explored some thoughts about what happens when software can be produced in moments for very little cost by just about anyone. It’s something I think will look much more like TikTok than the App Store, and I think about some of the implications of that.

Today is also the end of our super early bird pricing for AI Engineer, AI by Design, UX Australia, and Design Research. All these are in-person and online, and there are various bundle prices if you want to attend more than one.

So save a bunch of money if you register by today, you can always pay us later, but you’ll lock in the best possible price.

AI & Development Tools

The Browser Is the Sandbox

AI LLMs Web Platform

Browser window of Co-do app showing file manager interface with various markdown files listed on the left and a summary displayed on the right

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-dothat 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.

Source: The Browser Is the Sandbox, AI Focus

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 Cowork.

One Human + One Agent = One Browser From Scratch

AI Coding Agent LLMs Software Engineering

A blog rendered in a browser window with CSS gradients and SVG icon displayed correctly but with a missing PNG image

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.

Source: One Human + One Agent = One Browser From Scratch, Simon Willison

We covered the news last week of a browser effectively built entirely by a number of code generation agents. Here is another such project—again, not something that’s necessarily 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

AI LLMs Software Engineering

Driver's hands on a vintage car steering wheel with dashboard, and text describing AI as a reference tool for developers

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.

Source: The Five Levels: From Spicy Autocomplete to the Dark Factory, Dan Shapiro’s Blog

Here, Dan Shapiro uses the analogy of the five 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

AI Economics 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? 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 debt becomes a wise investment.

Source: This Is a Time of Technical Deflation, Dan Shapiro’s Blog

The observation here about what’s happening with code generation is profound. Software engineers’ best practice has always been to try and avoid tech debt—you move fast and cut corners, and then at some point the cost will always catch up with you. 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—tech debt is inexpensive. It might not be true for everyone, every circumstance, but it’s definitely something I think well worth considering.

Design & Product Development

Why Designers Can No Longer Trust the Design Process

AI Design LLMs Product Design

Smiling person with long hair and headset speaking, holding a remote. Text reads 'Don't Trust the Process, Jenny Wen, Design Lead at Anthropic'

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.

Source: Why Designers Can No Longer Trust the Design Process, Hatch Conference (YouTube)

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.

delivering year round learning for front end and full stack professionals

Learn more about us

Web Directions South is the must-attend event of the year for anyone serious about web development

Phil Whitehouse General Manager, DT Sydney