Your weekly reading from Web Directions
With the Easter long break here in Australia last week, we didn't have a newsletter for the first time in quite a while–so hopefully we're making up for it this week.
Before we begin with this week's reading some news about upcoming events and more form Web Directions.
PROJECT NOOPS
As I mentioned a couple of weeks back, Mark Pesce and I have teamed up to parse the signals out of the AI transformation as it happens at Noops. Read more and sign up for free.
AI ENGINEER NIGHT SYDNEY
Last night over 150 people attended our AI Engineer Night in Melbourne. If you're in Sydney you get the chance to have a taste of what's coming up at the AI Engineer Conference next week on Thursday.
It's free, but places are limited so please RSVP!
AI ENGINEER UNCONFERENCES
Also taking place in Sydney (April 18th) and Melbourne (April 11th–that's tomorrow), AI Engineer unconferences will explore the key ideas associated with the AI Engineer Conference series. From the impact of AI on the software development process and profession to the opportunities emerging with AI for new products and services. Whether it's agents like OpenClaw or Enterprise Workloads, you set the agenda.
Again, AI Engineer Unconferences are free; just RSVP so we can plan best for the day
AI ENGINEER AND AI X DESIGN WILL SELL OUT!
Tickets for AI Engineer and AI x Design are selling incredibly well–so don't delay! Save hundreds on a full priced ticket (full pricing kicks in May 8th) and most importantly make sure you don't miss out!
THE WINCHESTER MYSTERY HOUSE ERA
Drew Breunig has given us the image we needed for where software engineering is right now: the Winchester Mystery House. Eric Raymond's 1998 distinction between cathedrals and bazaars shaped a quarter-century of thinking about how software gets built. But AI has introduced a third mode—idiosyncratic, sprawling, cobbled-together systems that work but follow no coherent architectural plan. It's a vivid metaphor, and the uncomfortable part is that it's already accurate.
The numbers tell the story. Paul Kinlan's analysis of GitHub commit data shows Claude Code alone went from 0.7% to 4.5% of all public GitHub commits in six months. All AI coding tools combined now account for roughly 5% of every public commit. That's not a trend line—it's a phase change happening in plain sight.
And it's not just volume. Two of this fortnight's stories illustrate the kind of output this tooling enables. Lalit Maganti spent 250 hours over three months building syntaqlite—a set of SQLite devtools he'd wanted for eight years but could never justify until AI coding agents changed the economics. What makes his account especially valuable is the systematic honesty: he breaks down where AI helped and where it was detrimental, which is far more useful than the one-shot miracle stories. Reco's team rewrote their JSONata pipeline in Go in seven hours for $400 in tokens, borrowing a methodology from Cloudflare's Next.js reimplementation—point AI at an existing test suite and have it implement code until every test passes. The result was a 1,000x speedup and $500K/year in savings.
These aren't toy projects. They're production systems built by experienced engineers who understood the problem domain deeply enough to direct AI effectively. And that qualifier—"deeply enough to direct AI effectively"—is becoming the central question of software engineering practice.
Rahul Garg's piece on encoding team standards makes this concrete. He observes that a senior engineer instinctively specifies architectural constraints, coding patterns, and security requirements when directing AI—while a junior developer asks for "a notification service" and gets whatever the model defaults to. Same codebase, same AI, completely different quality. His solution—treating AI instructions as versioned, shared infrastructure that encodes tacit team knowledge—is exactly the kind of systems thinking the Winchester Mystery House era needs. Without it, you get sprawl. With it, you get something closer to a cathedral, even if the construction crew is partly artificial.
For those who want to understand the machinery beneath all of this, Sebastian Raschka's anatomy of coding agents is an excellent starting point. His key insight is that much of the recent progress in practical LLM systems is not about better models but about how we use them—tool use, context management, and memory play as much of a role as the model itself. It's why Claude Code or Codex feel significantly more capable than the same underlying models in a plain chat interface. And Sam Rose's extraordinary visual essay on quantization complements this nicely, explaining how we can strip away three-quarters of a model's numerical precision and barely dent its capability—which is why increasingly powerful models are running on hardware that would have seemed absurdly inadequate a year ago.
The complicating perspective this fortnight comes from MC Dean's experiment building a design team out of AI agents. The discourse around AI and software engineering tends to treat "building with AI" as synonymous with "generating code." But Dean is exploring what AI means for design as a practice—building shared skills, creating agent teams, asking what it means when your collaborators aren't human. It's a reminder that the transformation underway isn't confined to writing code. The Winchester Mystery House metaphor applies to design, too, and every other domain where AI is making production cheap while leaving judgment expensive.
What to watch: the gap between teams that treat AI as a code autocomplete and teams that build systematic infrastructure around it—encoded standards, architectural thinking, proper observability—is about to become the defining competitive divide. The Winchester Mystery House is the default outcome. The question is whether your team is building something more deliberate.
AI & THE STATE OF SOFTWARE ENGINEERING
The Cathedral, the Bazaar, and the Winchester Mystery House
In 1998, Eric S. Raymond published the founding text of open source software development, The Cathedral and the Bazaar. In it, he detailed two methods of building software:
Drew Breunig, who has done as much as anyone to explore and popularise the ideas around context engineering, reflects on the current state of software engineering through the lens of a classic late-1990s piece, The Cathedral and the Bazaar. He argues we are now seeing a third approach—the Winchester Mystery House approach to software engineering. It's important to try to understand and reason about the profound transformations happening within software engineering, and this piece by Breunig is a valuable contribution to the conversation.
Encoding Team Standards
I have observed this pattern repeatedly. A senior engineer, when asking the AI to generate a new service, instinctively specifies: follow our functional style, use the existing error-handling middleware, place it in lib/services/, make types explicit, use our logging utility rather than console.log. When asking the AI to refactor, she specifies: preserve the public contract, avoid premature abstraction, keep functions small and single-purpose. When asking it to check security, she knows to specify: check for SQL injection, verify authorization on every endpoint, ensure secrets are not hardcoded.
The style, conventions, and patterns of a codebase are things that developers who work on it slowly internalise through experience—through exposure to code, rarely from sitting down and reading documentation. And we know LLMs are really good at taking such documentation and incorporating it into the context of how they work. Here Rahul Garg proposes treating the instructions that govern AI interactions—generation, refactoring, security, review—as infrastructure: versioned, reviewed, and shared artefacts that encode tacit team knowledge into executable instructions, making quality consistent regardless of who is at the keyboard.
damn claude, that's a lot of commits
The week of September 29 2025, there were 27.7 million public commits on GitHub. Claude Code accounted for 180,000 of them, about 0.7%. By the week of March 16 2026, total weekly commits had grown to 57.8 million (itself a 2.1x increase, likely driven in part by AI tooling), and Claude Code accounted for 2.6 million, or 4.5%. All AI coding tools combined now sit at roughly 5% of every public commit on GitHub. For context, GitHub's Octoverse 2025 report recorded 986 million code pushes for the year, with monthly pushes topping 90 million by May 2025, and that trajectory hasn't slowed down.
Firstly, how did I not know that Semi Analysis had a podcast! Here Paul Kinlan takes a deeper look at the numbers associated with coding agent commits to public repositories on GitHub. There are certainly a bunch of caveats here, but still—the numbers are remarkable.
BUILDING WITH AI
Eight years of wanting, three months of building with AI
For eight years, I've wanted a high-quality set of devtools for working with SQLite. Given how important SQLite is to the industry, I've long been puzzled that no one has invested in building a really good developer experience for it.
Stories like this are valuable because, particularly for those who aren't working extensively with AI for software development, it can be hard to even imagine the scale and capability of these systems now. If you're still a little sceptical, or perhaps you use Copilot but not an agentic system, I highly recommend reading this article to get a sense of what a capable software engineer with these technologies is now able to do in a matter of weeks—even on a very complex project—and in far less time you can certainly build very sophisticated systems.
We Rewrote JSONata with AI in a Day, Saved $500K/Year
A few weeks ago, Cloudflare published "How we rebuilt Next.js with AI in one week." One engineer and an AI model reimplemented the Next.js API surface on Vite. Cost about $1,100 in tokens.
Stories like this are data people should take on board when thinking about how they work with AI technologies and the value of them. If you're not working extensively with these technologies—and even if you are—it can be hard to fathom just how capable they are and what their implications might be.
I Built a Design Team Out of AI Agents
Then I decided to share some of the tools I've been using to learn about working with AI more deeply and to explore what it means for design as a practice. I made a set of design skills you can use with any model and a set of Inclusive design skills.
MC Dean shares a range of design skills she's built for working with AI as a designer.
UNDERSTANDING AI SYSTEMS
Components of A Coding Agent
In this article, I want to cover the overall design of coding agents and agent harnesses: what they are, how they work, and how the different pieces fit together in practice. Readers of my Build a Large Language Model (From Scratch) and Build a Large Reasoning Model (From Scratch) books often ask about agents, so I thought it would be useful to write a reference I can point to.
Sebastian Raschka brought us the books Build a Large Language Model (From Scratch) and Build a Large Reasoning Model (From Scratch). Here he turns his attention to examining how coding agents and coding harnesses work.
Quantization from the ground up
Qwen-3-Coder-Next is an 80 billion parameter model 159.4GB in size. That's roughly how much RAM you would need to run it, and that's before thinking about long context windows. This is not considered a big model. Rumors have it that frontier models have over 1 trillion parameters, which would require at least 2TB of RAM. The last time I saw that much RAM in one machine was never.
Sam Rose writes incredible visual essays that explain complex concepts in very approachable ways—like this piece on prompt caching from late last year. He returns with a long and detailed explanation of quantization, the seemingly magical property of LLMs: by reducing the precision of the floating-point numbers which capture the weights of the model substantially, we don't actually reduce the capability of the model much at all—which then allows us to run models with less memory and greater performance.