In March we fixed a problem on coredna.com where pages briefly appeared without their styling. The fix made each page wait for its main stylesheet before drawing anything. Claude wrote it with me, and it worked.
On this page:
A fix we shipped in March came undone in May
In May I directed a round of speed work. One of the changes, also written with Claude, made that same stylesheet load later so pages would appear sooner.
In August we ran a lab test on a blog post. Its layout shift score, Google's measure of how much a page jumps around while it loads, came out at 0.64. Google rates anything above 0.25 as poor. Making the stylesheet load first again brought the score down to 0.0005.
The failure was where our code met the way a browser draws a page. Nothing in the May change looked wrong on its own. One incident proves little, so we counted.
Most of our silent failures happened where our code met another system
Agents now co-write most of our commits to this site's code. In 2022, a complex client project at Core dna could take a year. Now agents help us build working prototypes for clients to approve. That is the setting for what follows.
When something goes wrong on our site, we write down what we learned so the AI doesn't repeat it. More than one in five of those lessons describe a step that reported success and didn't do what it said. A save came back as successful and stored nothing. An update to one part of a page quietly cleared the rest of it. A filter didn't recognise what it was given and returned everything. A setting saved correctly and never appeared on the page.
Each time, the step reported success. The only way to find the problem was to check the result: reload the page, read the record back, look at what a visitor actually sees.
We sorted those lessons by where the failure happened. Most were at the edges, meaning the data, other systems, caches and rules that software touches outside its own code. The content management system's rules about what a save replaces. Caches that kept serving an old version after the new one was live. The browser's security rules. A background job that rewrote fields a few seconds after we saved them. Some of those systems are our own platform, and having built it didn't stop us getting caught.
Developers will recognise these as integration problems. Several of those systems behaved exactly as designed, and the gap was in what we knew about them. Teams hit them before anyone used AI to write code. The label doesn't change who has to find them.
Regenerating the code doesn't bring back what a bad update cleared
Chad Fowler argues that "instead of maintaining code, we can regenerate it". For the code itself, he may be right. Take the update that cleared the rest of a page. Regenerate the code that sent it and you get better code. The content it cleared stays gone until someone notices it's missing and knows where to look. Fowler also writes that "the system is the asset". The edges are part of that system, and you can't regenerate them.
Somebody has to own the edges
The May change had nobody responsible for the edge it touched, me included. I directed the work and checked the results I had asked for, and the edge sat outside every one of them. The check that found it in August was a layout shift measurement on a blog post. Nobody had that job in May.
My rule for what we build next is one named person for the edges of anything AI-built. That person checks results rather than messages, before it goes live and for as long as it runs.
Summarize with
