Read the Tea Leaves

This blog has moved from WordPress.com to self-hosting. If you were following it via WordPress, you should use an RSS reader pointed at nolanlawson.com/feed instead.

WordPress has served me faithfully for 15 years, but I think it’s time to move on. A few things have nudged me in that direction:

• The recent drama surrounding WordPress has left a bad taste in my mouth and eroded my confidence that it’s a good long-term bet.
• The WordPress interface keeps nudging me away from the old-school plaintext Markdown editor (which remains excellent to this day!), and I never enjoyed the slow, clunky, click-and-drag-and-whoops-you-misclicked experience of Gutenberg.
• WordPress charges me $110/year for something that could be hosted for free on Cloudflare with a static site generator.

Of course I’m losing some things by moving off of WordPress:

• Comments and pingbacks. To be honest, this never felt super valuable to me. I already run a Mastodon instance, so I’m fine just linking to a thread there, or on Lobsters, Hacker News, etc. Plus it was a constant battle to keep up with the spambots (who have gotten incredibly convincing thanks to LLMs).
• WordPress followers. I guess WordPress has its own quasi-RSS system, and I have a few hundred followers there? Well, if this convinces some folks to go pure-RSS and avoid tying themselves to one vendor, then I won’t count it as a loss.
• The theme. I have a lot of nostalgia for my vintage early-2010s “Spring Loaded” theme. I think it gave my blog a bit of charm that I so clearly did not care about the appearance and just kept rocking a retro theme like a bad haircut. It wasn’t zero upkeep, though ‒ I ended up tweaking the CSS many times over the years to bump the font size, fix weird layout issues, improve accessibility, etc.

That said, I’m also gaining quite a bit by moving off of WordPress. Not only am I saving a chunk of change, but I also gave myself an opportunity to modernize the style, add a dark theme, and improve performance with a radical (near-)zero-JS and zero-tracking vision.

In terms of performance, I went with pure-HTML/CSS wherever possible, with JS only popping up to run the dark mode switcher, a small legacy URL redirect, the search (via astro-pagefind), and lite-youtube-embed for the odd YouTube video. Images are lazy-loaded unless they appear very early in the post, everything is the system font, and I pre-rendered all tweets (for my older posts that reference them). Speculation rules speed up navigation a bit on browsers that support it.

In terms of tracking, I decided to just drop it entirely. Of course I could use Cloudflare’s own client-side tracking, or some other provider, but 1) a lot of my readers have ad/tracker blockers anyway, so it’s inaccurate, 2) this data has gotten less useful as more and more sites have tightened their referrer policy (Google used to tell me the search terms! that people actually typed! insanity), and 3) it’s probably bad for my mental health anyway to look at these numbers. Realizing that I’m getting a Hacker News spike is slightly ego-inflating but probably does more harm than good to my anxiety levels.

As for the design, I decided to keep some of the colors and layout from the original theme while largely modernizing it: larger fonts, no gradients or drop-shadows, and no more tag cloud (although I do have some sentimentality for tag clouds!). I also improved the accessibility: my heading levels are finally consistent (I messed this up over the years mostly due to confusion about the main page versus per-post pages), there’s a “skip to main content” link, and I made various other fixes after an Axe audit.

Of course, because it’s 2026 and I’m incredibly lazy (my blog wouldn’t have kept a 15-year-old theme if I wasn’t), I used Claude to do most of the work. The prompt was basically “Here’s a WordPress export, rebuild it in Astro, go nuts.” The fact that it’s this easy to self-host should really make incumbents like WordPress nervous – I’m not sure how an aging blogging technology that still has to deal with critical CVEs in its templating engine (not to mention a wild-and-woolly plugin marketplace) can compete with a static site whipped up by agents. I wish them the best of luck, but I’m stepping off the train.

To be sure, there were issues: WordPress doesn’t export my Markdown files, only HTML, so I had to write a small script to pull them from the WordPress API. I also needed to fix some tiny differences in how Astro converts Markdown to HTML versus WordPress, and I had to set up the RSS/Atom feeds so that feed readers wouldn’t notice a difference. (How many times have I seen someone’s blog suddenly dump all their posts into my feed when they migrated from one system to another?)

Unsurprisingly, since you can just choose how many bugs you want now, the agent also found a bunch of stuff on its own, including broken links, spam comments I missed, and issues with OpenGraph images. I didn’t want to “correct the record” on too many of my older posts, but I did clean up some minor styling and linking issues.

Switching to Astro also meant I could finally get proper syntax highlighting (it’s irked me for years that my WordPress theme doesn’t support ES6 syntax), and I even wrote my own Shiki theme to match the page style. This is the kind of thing I would have considered far too indulgent (and a distraction from, you know, actually writing stuff) pre-LLMs, but these days it’s just a prompt away. For this kind of work, I particularly like Claude artifacts since I can have the agent pitch me on a few different designs.

// Random code snippet to show the colors
class Yolo {
  woot() {
    const yay = 'yay'
    return `ES6 works now! ${yay}`
  }
}

Overall, this is basically a project that I had in the back of my mind for years, and which I could finally justify thanks to coding agents. I admit that it gave me some pause to imagine that the design for my website, my entire presence on the web, would now be LLM garbage, but I realized that I just didn’t care. Similar to how, 15 years ago, I grabbed a random WordPress theme and ran with it, I don’t see much harm in having the agents give me the window dressing while I write the content. I still have a personal prohibition against LLMs touching my prose, but the design, to me, is just meh. On many blogs I read I just immediately turn on Firefox Reader Mode anyway, so honestly a lot of people’s designs are just the equivalent of a 90’s Flash splash screen to me.

Plus, if your goal is “don’t let LLMs taint anything you put on the internet,” well WordPress itself is surely eagerly gobbling up LLM code, every social media platform is doing the same, web browsers and OSes are doing it too, so… if you’re touching a computer, you’re interacting with LLM output these days. This seems to just be the direction the world is going in, and I don’t hold code so sacrosanct that I feel the need to keep my code an island of purity in a sea of slop. In any case the agents do a better job than me; I’m continually impressed by Claude’s ability to think of minor things like listening for localStorage events in the theme picker, handling forced-colors aka high-contrast mode, proper HTML formatting for RSS feed readers, etc.

So anyway, this is the new site! Unless you’re reading this while I’m still in the process of moving stuff over. Goodbye, WordPress, and thanks (sincerely!) for hosting my blog for all these years.

You can comment on the fediverse.

I was a voracious reader as a kid, and I noticed a funny phenomenon: whatever writer I had most recently read, my next paper for English class would sound like them. If I read a bunch of Stephen King, I’d sound like Stephen King. If I read the Narnia series, I’d sound like C.S. Lewis (complete with British spellings and antiquated turns of phrase).

I know I’ve carried this tic into adulthood. As much as I’ve tried to find my own consistent voice in my blog writing, I know that whatever author I last read is sitting there in the back of my head, weighing in on my word choices and sentence rhythm.

So imagine my alarm when, in my last blog post, the word “load-bearing” popped into my head. I used scare quotes and even called it out as a “Claude-ism,” but I couldn’t fight the feeling that it was le mot juste. I couldn’t find another phrase that felt more appropriate. And as Stephen King said, if you have to hunt for a word in the thesaurus, it’s the wrong word, so I went with it.

The most recent book I’ve been reading is Anna Karenina, and it would be much more flattering to my ego if Tolstoy’s short, punchy phrases (at least in the translation I’m reading) made their way into my writing. And maybe they did. But then there’s the obvious Claude loanword in the middle of it, sticking out like an blemish.

More and more I’ve found my brain alighting on these phrases: “load-bearing,” “belt-and-suspenders,” “earns its keep.” As much as I try to bat them away, they keep coming back. It shouldn’t be surprising: my job these days is effectively to shepherd agents, skimming their meandering robo-prose and trying to steer them towards better code. But I can’t help but be disturbed at how much they’re rubbing off on me.

Immersion

I have a degree in linguistics, so I understand the power of immersion. I mean, you don’t need to have read Chomsky to notice things like people picking up on the accents of those around them. I have a cousin who lived in England for a decade, and her accent morphed into a Translatlantic, Katharine Hepburn-esque hybrid of Kansas drawl and Bristol pep, until eventually she moved back and it wore away.

For a more dramatic example, when I visit family in France, I find that after a weeklong adjustment my brain starts thinking in French, dreaming in French. (Much to the detriment of my mental capabilities, I’m sure, since my French is much worse than my English!)

I like to imagine that reading is slightly different, though. When you’re reading a good novel and you get lost in it, the author is in some sense hijacking your brain – you visualize their world, their words become your thoughts. And I find that this affects my writing much more than my speech, which makes sense: reading/writing and listening/speaking are governed by different parts of the brain.

I think it’s also possible to resist the environment you’re immersed in. I spent years in big-tech corporate culture, where every phrase is hedged and every expression flattened into a kind of mush designed to be as inoffensive as possible. I hated this voice, but of course I noticed it sneaking into my writing over the years (“on the other hand,” “to be fair,” etc.). If you read my pre-big-tech posts, they’re a lot more wild and freewheeling. I’d like to think I’m de-programming myself now and getting closer to that original voice.

(This is actually one of the reasons I stopped asking for reviews of my drafts. The reviewers were extremely helpful – thank you all! – but I found that it made me over-think things, try to anticipate every possible negative reaction from my audience, and thus land on a kind of “both-sides” journalism that made it unclear what I was trying to say in the first place.)

At some level though, I have to accept that “you are what you eat” when it comes to your linguistic diet. The evidence of accents, language, style, and rhetoric all point toward the current Borg of LLMs being an overwhelmingly poisoned water the more you dunk yourself in it. You can resist, you can cleanse yourself in other waters, but to some degree I worry that “resistance is futile” because they will infect your speech, your writing, and even your thoughts in ways that may even be invisible to you.

Stay human

So how do we fight this horde of agents colonizing our brains? In short: stay human, friends. Resist the whispering earring. Be jealous of your time and attention, and try to find other sources of artistic and intellectual sustenance than the chatbots. As doomed as it may feel, try to keep a part of yourself that is the tiny little village of Gauls holding off the Roman invaders. Whatever your inner sanctum is, protect it from AI infiltration.

One strategy is to be deliberate about where you expose yourself to AI influence. I recently vibe-coded a silly guitar app to try to help me get better at guitar solos – I play a phrase, the AI responds to my phrase, etc. I have no concerns about my guitar-playing becoming robotic, because I’m not trying to become Eddie Van Halen; I’m starting from such a low bar that even playing a halfway-decent riff in the pentatonic scale is challenging enough for me. Elsewhere, I’m more guarded.

For example, this is why I don’t use LLMs for any of my writing – not even to spellcheck. I’d rather my prose have all the warts of my sometimes-stilted sentences, my often too-esoteric word choice, my generous sprinkling of odd English idioms, than to give it even a whiff of Claudese.

Plus, I know that as soon as I ask the chatbot for help on even a single sentence (“can you help this land better?”), it’s all over for me. I’ve already given up on keeping my own voice in my code: I used to care a lot about variable names, function arrangement, which kinds of for-loops to use… and now I just accept Claude’s little stylistic quirks because they’re not worth fighting. If I let the same thing happen to my English writing, I’d feel like it had lost some indelible stamp of me-ness.

I think there’s also something to be said for showing a courtesy to others: be clear what’s LLM-authored and what’s not. In my workplace writing, I have a habit of bookending all my Claude quotes with clear markers – <blockquote>, <details>/<summary>, etc. – to make it clear which words are Nolan-words and which are robo-words. I certainly find myself tuning out a piece of writing if it appears to be AI-generated, and the worst thing is not knowing whether someone’s sent you their robot ghostwriting or not: it forces you to do this mental classification for everything you read. So I try to spare others this cognitive strain. (Unless my bots disobey me!)

Maybe this is a losing battle, though. Maybe the kids are already growing up with their brains shaped by AI the same way they were shaped by social media. Maybe the whispering earring will win, and it will hollow out some part of our brains the same way we all forgot how to navigate once Google Maps came out. (This certainly describes me.) But personally, I’m too much of a purist to go gentle into that good night. I plan to resist in my own small ways, even as I accept that generative AI has become an inescapable fact of everyday life and in particular the life of a programmer.

Even if it’s Quixotic, to me this quest is crucial, critical, all-important, foundational, paramount for the perseverance of the human spirit in the age of AI. The only thing it’s not is “load-bearing.”

A lot of the educators I admire in the frontend web space seem to be either bowing out or dialing back their efforts: Axel Rauschmayer, Salma Alam-Naylor, Josh W. Comeau, to name a few. Other well-known luminaries like Kent C. Dodds, Addy Osmani, Rachel Nabors, and Lydia Hallie have pivoted from talking about frontend development to talking about… well, take a wild guess.

I never made a living from talking about web dev, but I do have this blog, and I’ve done conference talks and podcasts about stuff I’m excited about. Recently for example, my passion was explaining all the ins and outs of CSS performance: how shadow DOM works, how the browser’s style engine works, the traps of CSS-in-JS, etc.

Just for kicks, I decided to ask Claude Sonnet how it would handle a Chrome trace with high “Style Calculation” costs. This is one of my favorite brain-teasers, because it’s the kind of thing that I saw web devs – even experienced ones! – trip up on over and over again. Claude gave a perfectly admirable answer:

Click to see

Prompt: Answer without searching the internet: you’re looking at a Chrome trace, and you see repeated spans of high Style cost but relatively low Layout cost. What kind of things do you look for in the webapp to optimize? What do you measure next?

What “Style” cost actually represents

The Style (Recalculate Style) phase is where the browser matches CSS selectors against the DOM and computes the final computed style for each affected element. It’s expensive independent of whether anything actually moves or resizes (that’s Layout’s job). So if Style is high but Layout is low, you’re likely paying for selector matching / invalidation over many elements, not for expensive geometry.

What to look for in the webapp

1. Selector complexity and count

• Overly complex or deeply nested selectors (.a .b .c >; .d + .e), especially descendant combinators, force the engine to walk more of the DOM/ancestor chain per match attempt.
• Universal selectors or attribute selectors ([data-foo="bar"]) applied broadly.
• CSS-in-JS libraries that generate huge numbers of unique class names/rules (style recalculation has to consider the whole rule set).

2. Invalidation scope — this is usually the big one

• A class/attribute/style toggle high up in the DOM tree (e.g., toggling a class on <body> or a top-level container) can force style recalculation on large subtrees even if only a few elements’ final styles change.
• Check whether a single state change (e.g., a “theme” class, a “loading” class, a hover state) is invalidating far more elements than necessary. Chrome’s “Selector Stats” (enable in DevTools Performance settings) will show you which selectors are slow and how many elements they were tested against — this is the single most useful next measurement.

3. Frequency/amplification

• Something re-triggering style recalc many times per frame — e.g., reading a style/layout property in a loop right after a class change (forces synchronous recalc), or a JS animation using .classList.toggle() or inline style updates on many nodes per rAF tick instead of batching.
• Repeated small DOM mutations each forcing a style pass rather than being batched into one.

4. Inherited/computed property propagation

• Changing an inherited property (like font-size or color on a common ancestor) forces recompute of all descendants’ computed styles, even without layout changes (e.g., color, visibility, cursor are Style-only, not Layout-triggering).
• Custom properties (CSS variables) changed at a high-level scope — updating a --custom-prop on :root or a shared ancestor recomputes style for every element referencing it.

5. Shadow DOM / component boundaries

• If using a framework with lots of shadow roots or scoped styles, check whether style recalculation is being needlessly repeated per component instance due to non-shared stylesheets.

What to measure next

1. Enable “Selector Stats” in the Performance panel (gear icon → Enable selector stats). Re-record the trace. This gives you, per Recalculate Style event, the top slow selectors and match counts — that tells you directly which CSS rules and how many elements are responsible.
2. Check the “Recalculate Style” event’s initiator/call stack in the trace to see what JS triggered it — a class toggle, a style.setProperty, an animation frame callback, etc.
3. Count how many elements are affected per recalc — DevTools shows “Elements Affected” per Recalculate Style event in the summary pane. Compare that number to how many elements actually changed appearance — a big gap indicates over-broad invalidation.
4. Look at where in the DOM the triggering mutation happens — is it near the root (broad invalidation) vs. scoped to a small subtree (narrow, cheap)?
5. Check for forced synchronous style — look for “Forced reflow” purple warnings; even though you said Layout is low, sometimes a forced style read (getComputedStyle) interleaved with a DOM write shows up as many small back-to-back Style events rather than one batched one.

Typical fixes once you find the culprit

• Scope class/state toggles to the smallest subtree possible instead of a common ancestor.
• Simplify selectors, prefer single class selectors over descendant chains.
• Move CSS custom property updates to the smallest scope needed.
• Batch DOM/class changes so recalculation happens once, not per-mutation.
• Use content-visibility: auto or contain: style layout on independent subtrees to limit invalidation scope.

These days, given a slow-loading website, even as someone who’s written about browser performance for years and who literally worked on a browser performance team, I would probably just chuck a Chrome trace at Claude Code and have it suggest improvements. In fact I’ve done this very thing in my day job and gotten some good results.

The future of frontend

So where does this leave frontend dev education? Not in a great place obviously; I wish I had some more uplifting answers for people who (like me) used to get a lot of fulfillment out of trying to raise the bar for frontend developers everywhere. I do have some guesses though, and I think the problem is still worth puzzling through.

The core question is where frontend development itself lands in this new era. Sadly it feels to me like there are several trends pointing against increased investment in frontend knowledge:

The frontend is less risky to just hand to an agent. If you’re using an agent to write a database migration, you probably want to put it through several rounds of AI code review, scrutinize it yourself, run it on staging first, etc. If you write a React component with an agent, though, then the risk of just yolo’ing it into production is (typically) much lower.

Note I’m not saying there are zero risks: the agent could mess up accessibility, it could cause an infinite loop that blocks users, etc. But in general, frontend code is a lot more ephemeral and replaceable than other types of code. So I expect many AI coders will feel comfortable just letting their agent handle it unsupervised (for better or worse).

DevExp is becoming less critical overall. A lot of the pre-LLM discussion in the frontend space was about ergonomics versus outcomes: “The ‘developer experience’ bait-and-switch” by Alex Russell is a great example. For another example, Svelte and Solid have long argued that their ergonomics lead to better outcomes than React: less code, better performance, etc.

Meanwhile, Cursor and Viget have blogged about migrating their codebases from Solid and Lit, respectively, to React. Since rewrites are less expensive with agents, this may be a bit surprising: why not move to the more performant/less verbose framework? The answer (explicitly in Cursor’s case, and I suspect for Viget as well) is of course: “the agents know React.” For better or worse, React is heavily overrepresented in the training weights, and “agent experience” is starting to matter more than developer experience.

Standards will catch up. I’ve been out of the web standards space for a couple years now, so this is pure speculation on my part. But I imagine that a lot of the efforts to improve the ergonomics of building websites – better CSS shorthands, terser JavaScript syntax, etc. – will become perceived as less important relative to things that actually move the needle on performance, capabilities, etc. At the end of the day, it’s just not very different for an agent to write 3 lines of CSS instead of 1, and anyway using the newer syntax might actually be harder because you have to coach the agent about things that aren’t in its training weights.

In some ways this shift might have already been underway. I remember several years ago at TPAC, well before the AI coding boom, I told someone on the Chrome team that I was working on web component standards. They responded that they weren’t interested in that, because those APIs only affected the developer experience and didn’t actually make the browser more capable (e.g. Project Fugu). That stuck with me because it’s a good point: APIs like shadow DOM and custom elements don’t give web developers any new superpowers; they just change where and how the code gets authored. I expect such things will move out of the spotlight as AI coding takes over.

This doesn’t mean that standards will disappear from the topics a frontend dev needs to keep up on, but I imagine it will become less about “use this newer syntax” (an evergreen source of material for conference talks and articles) and more “here are these emerging capabilities.” And I predict the latter group will be much smaller than the former, since they tend to be more contentious for standards bodies and there’s just a smaller pool of features to draw from.

Whither frontend education?

So how can the field of frontend education adapt to this hostile future? To avoid being utterly bleak, here are some positive directions I think it could go in.

First off, the agents still need to be educated about the big picture. Agents and harnesses seem to love writing React and specifically SPAs, but SPAs are not the answer to everything. You can burn a lot of tokens having an agent write a big complex SPA for your marketing site, and then fix all the bugs with the back button, focus state, performance, etc., or you can just choose an MPA framework like Astro or Eleventy and call it a day. Maybe these frameworks will be a bit harder for the agents to work with (specifically Astro since it kinda-sorta looks like React but isn’t), but my guess is that since you’re writing ~50% less code overall it won’t matter.

Second, making websites that work well for agents is probably going to be a fruitful endeavor for the near future. Vercel’s is-agentic is a good example of this. Ironically, this points back to good fundamentals that public-facing websites should have been doing anyway: server-rendered content, proper accessibility, page speed, etc. But if slapping the word “AI” on it is what gets people to care about it then hey, I’m all for it.

Note that I’m a little bit less sanguine about this second point, because I’m not sure the web even survives in its current form as agents become more of a thing. If I want to figure out how much it costs to fly from Seattle to Paris, I’d much rather ask an agent than click through an infuriating series of buttons on a slow-loading website. The only reason I can’t is because these websites explicitly block bots, or they don’t offer an MCP, but I’m sure there are several startups champing at the bit to solve that problem. So I’m not sure how sustainable the current situation is.

Third, we can offer consulting services for vibe-coded monstrosities. A massive amount of AI-generated frontend code is being pumped out right now, and some of it (to use a Claude-ism) will certainly become “load-bearing.” If those websites are slow, non-compliant, and riddled with security holes, then it may not be enough to ask the agent “fix my website pls.” There could be an opportunity here for real expertise, especially if there’s money on the line and the vibe coder’s knowledge of web development doesn’t extend past “websites are apps hosted on the internet.”

(I acknowledge that this is the shakiest of my three points, since I can totally imagine the next generation of “self-healing” web apps to eclipse the average expert in 2027 or 2028. But for the time being: yes, expertise still matters.)

Conclusion

The point of this post wasn’t to make myself feel better, or to dance on the graves of all the careers that have been upended by the recent AI boom. I’m a naturally gloomy person, and this post was me allowing myself to wallow in my own gloominess. I don’t take any pleasure from noting that the huge body of knowledge I’ve built up over the years has been rendered nearly obsolete, nor am I happy to see the same thing happen to my much-more-qualified peers. But pretending that it’s not happening isn’t a valid strategy either.

There’s a mood in some of the blogs I read these days along the lines of “I’m so tired of talking about AI” or “Please don’t mention AI to me ever again.” I’m sure some of this is a kind of world-weary, above-it-all air that feels good to wear as a badge of distinction. But I think a lot of it also comes from real fear. It’s scary to admit that you don’t know what’s going to happen in a year. It’s destabilizing to imagine your career going along a certain trajectory, serenely landing at retirement, and then to see everything upset just a few years from your goal.

The metaphor I’ve been using is that an asteroid just hit the earth, and we’re still surveying the wreckage. It’s hard to predict what will happen after the dust settles (let alone which tiny rodents will usher in the Age of Mammals!), but ignoring the crater altogether seems like the worst kind of denial. Another metaphor is covid: when covid hit, I don’t recall thinking, “Ugh, I’m so tired of talking about covid” – instead, I wanted to learn everything I could about viruses, epidemiology, masking, etc. This turned out to be a good idea, since covid was going to dominate my life for the next few years (at which point yes, I did finally get tired of talking about it!).

I hardly have a crystal ball, but this post was my attempt to think through where my most cherished field might be going in the future. I admit that I have a lot less skin in the game these days: I’m out of web standards, I don’t even work on the frontend at my current gig, and my blog has mostly been a lot of wailing and gnashing of teeth about AI rather than my usual menu of browsers, performance, accessibility, etc. That said, I still have a lot of love and respect for the frontend field, and I care about what happens to it in the future. It may be unrecognizable in just a few years, but if nothing else, I hope my peers find a way to navigate all these changes and to thrive in this weird new world.

There’s a bizarre aspect of AI coding that I’ve been trying to put my finger on, and I think it’s this: you can basically just decide how many bugs you want your software to have now.

We discovered this first with security, because of course security bugs are the most non-negotiable ones. But I think once the vulnpocalypse is over, we’ll start to turn our attention to other types of bugs: correctness, performance, accessibility, reliability, etc.

Some of us are already doing this. For example, I find myself spending a lot of time these days in code review, using tools like my triple-agent code review skill as well as Geoffrey Litt’s explain-diff skill.

My experience is that, in a complex system, you can basically find as many bugs as you ask the agents for. If you get tired of tackling bugs in the PR itself, have no fear: the agent will also find plenty of preexisting bugs for you to spend time on. The question is just when you want to stop and call it “done.”

Of course the bugs are not free to fix. There are still many tradeoffs to consider: lines-of-code versus likelihood that the bug will actually occur, the risk of introducing new bugs in a complex solution, the cost of making the code harder to understand for future reviewers or agents, etc. But the finding of the bugs has become nearly free, and AI agents are also capable of finding very subtle, intricate bugs that otherwise could have flown under the radar for years. What we do with this situation is the interesting question.

As many have noted, it doesn’t seem like the overall polish of software has increased since AI coding became a thing. If anything, there is just more junk and shovelware out there, of dubious quality. I think this demonstrates that, although our ability to find new bugs has skyrocketed, our overall tolerance for bugs has not changed. There are still plenty of winds blowing in the opposite direction:

• The preventable problem paradox: if an incident occurs and you swoop in to fix it, you’re a hero. If you prevent the problem from ever occurring in the first place, then nobody knows you did anything.
• Related: the pressure inside many software orgs is to keep shipping visible results, not to fine-tune something that already “works.” With AI coding this is magnified: management often assumes that 10x productivity means 10x more visible features and apps.
• Laziness: one of the classic virtues of a programmer, this time working against us. I find myself mentally exhausted after slogging through the umpteenth AI-generated bug report, which requires me to carefully think through intricate aspects of the system and weigh the pros and cons of fixing it. I imagine many of my peers in the industry have just tuned out AI code reviews or only focus on the most critical findings.

Avoiding epicycles

There are a few ways we can approach this problem, though, that don’t require unending toil. One way is to set up the agent on a loop, e.g. “do a code review, fix all critical/high/medium issues, then repeat.” I find this can work, but it has a tendency to create lots of epicycles.

If you’re not familiar with the concept: in the pre-Copernican¹ model of the solar system, ancient astronomers “fixed” miscalculations in the planets’ orbits by simply adding more circles to their movement. This improved the accuracy of the predictions, but at the cost of making the overall model more complicated. Obviously just saying “the earth moves around the sun” greatly simplifies the whole thing, but first you need the insight to make this simplification possible.

I’ve found that AI agents are pretty bad at such dramatic simplifications (in other words, “LLMs can’t jump”). They will happily build one epicycle per bug until the code is a spaghetti mess. So a valuable part of AI code review is still to ask questions like “How can we make this simpler?” and “Is there a fundamental flaw with the codebase that we should fix before we tackle this class of bugs?”

Another technique that works well is to have good tests. (Easier said than done!) For example, when I was playing around with vibe coding the W3C IndexedDB API, it became pretty clear to me that an agent could just grind through the test suite, and if it got close to 100% then I could be reasonably certain to have a bug-free implementation. But the only reason this works is because the Web Platform Tests are a phenomenally good test suite, honed by years of independent browser implementers discovering odd bugs and adding test cases for every unlikely scenario you can think of. Most companies, in their first-party codebases, could only dream of such a test suite.

I can imagine, though, that if you’re building a system from scratch, and especially if your goal is to reproduce the output of an existing system, then you can get pretty far by just putting all your effort into the test suite and then letting the agent go nuts on the rest. PGRust seems to be having some success with this.

A third technique is to just simplify your system design so that whole classes of bugs become impossible. For example, I’ve long been an advocate for multi-page apps (MPAs) over single-page apps (SPAs), just because, with MPAs, entire bug categories simply don’t exist: breaking the back button, losing scroll state, leaking client-side memory, improper accessibility during page navigations, etc.

Of course you lose some power with a simpler system versus a complex one, and maybe a reasonable answer is to deliberately choose a more complex system while also just fixing all the bugs. I feel though that this would still have a tendency towards epicycles, and I would much rather read (or debug!) a codebase built on simpler principles rather than one built on complex ones, even if they both have the same overall bug posture.

Conclusion

It’s become cliché to note that we’re in unprecedented times, and that everybody is figuring out what exactly software engineering is supposed to look like when robots can do a good chunk of what used to be “the job.” And yet, it still remains worth saying. Whatever I wrote in this blog post may become outdated in a matter of months, and the next 5 AI-related articles you read on Hacker News will probably argue 5 different opinions. It’s a cacophonous mess, and I have low confidence that I’ve figured out all the answers.

What I’ve defaulted to is focusing on the short term: i.e. what are agents good at today, and where can humans still provide some value. Some people are running with the assumption that all concerns of code quality, complexity, and maintainability will be swept away someday by agents that can easily manage whatever baroque legacy system they’re handed. That may end up true, but I’m not going to bet on it because I haven’t seen it yet. For now, I’m still concerned about things like the DRY and KISS principles, keeping a working theory of the code in my head (ala Peter Naur), and trying to steer the agent toward better code quality.

I do think it’s interesting though, that we have a much greater ability to tackle more and more subtle bugs than we ever had before. Maybe this will lead to a reliability renaissance, or maybe it will lead to the same overall bugginess, just with more apps and more features in each app. I know that my personal preference is for greater software craftsmanship, but it remains to be seen how the software industry as a whole will step up to this challenge.

Footnotes

1. Technically, Copernicus’s system still had epicycles, and only Kepler managed to get rid of them. I think in some ways this makes the analogy stronger: in software, a re-architecture sometimes isn’t obviously better right away, and only shows its value over time.

A lot of people seem convinced that the point of AI coding is to write low-quality code as fast as possible. Spew out barely-passable slop, open massive PRs, and merge them unvetted. Ship it!

But the thing is, LLMs are very flexible. And you can use them just as effectively to write high-quality code more slowly.

This statement seems completely obvious to me at this point, and I almost didn’t want to write this post for that reason. But there seem to be enough people convinced that LLMs are only good as slop cannons that it’s worth making the opposite case.

If Mythos taught us anything, it’s that LLM agents are really good at finding bugs. Throw them at a codebase enough times, and they will find so many bugs that you’ll barely know what to do with them.

Like many others, I’ve also found this is true of non-Mythos models – some may be better than others at finding subtle bugs or avoiding false positives, but the fact is that the latest public models from Anthropic and OpenAI are good enough to find plenty of bugs in an unscrutinized codebase.

The problem is not so much finding the bugs, but instead prioritizing and validating them. For this reason I have a Claude skill I adapted from this article‘s core insight, which is that the more, different models you throw at a PR review, the less likely you are to get hallucinations or bogus bugs.

The skill says (paraphrasing):

Run a Claude sub-agent, Codex, and Cursor Bugbot to find bugs in this PR ranked by critical/high/medium/low. Once they’re all done, review their findings, do your own research to rule out false positives, and write a final report.

That’s basically it. You can add your own definition of “bug” if you want – mine has stipulations about the KISS and DRY principles, writing accessible HTML/JSX, using proper indexes for SQL queries, etc.

In my experience, this skill always finds tons of bugs in a PR, and the false positive rate is near zero. It finds so many bugs that you’ll be bored senseless if you try to tackle them all. They’ll range from critical security or correctness bugs to the more mundane medium-level perf bugs to low-level “this comment is misleading”-type bugs.

My typical workflow is:

• Have an agent fix all the criticals and highs (with my guidance on the proper solution), then repeat until no criticals/highs
• Skip highs/mediums where the juice isn’t worth the squeeze (e.g. 100 lines of code to fix a narrow edge case)
• Abandon the PR if it has so many criticals that I realize the whole approach is misguided

When I use this technique, I haven’t necessarily seen my velocity go up. If anything, the review process often finds pre-existing bugs, so I end up on a tangential side-quest where I’m writing unit tests and fixing subtle flaws that pre-date the PR. This is the opposite of the “10x productivity” slop-cannon style of development that most people imagine when they think of vibe coding, but I find it very satisfying.

It’s a great way to improve the overall health of the codebase while also teaching you about the odd corners of it. In my experience, the happy-path of a complex architecture is less interesting than its failure modes. And pre-LLMs, this is usually how I got familiar with a codebase anyway: understanding where the assumptions break down, and then getting my hands dirty to fix it.

If you’re the kind of person who is skeptical that AI coding is good for anything, then I doubt this post will persuade you. But if you’re the kind of developer who uses agents to write multi-hundred-line PRs that you barely understand yourself, I’d invite you to slow down a bit and try this other, slower style of “vibe coding.” Ask an agent how your PR works and how it might fail. Have it write Markdown docs with Mermaid charts if necessary. Use Matt Pocock’s /grill-me skill until you understand the entire PR front-to-back.

You might not be more “productive” in terms of raw lines of code. You might burn a ton of tokens just to find out that your entire plan was wrongheaded from the start. But I find this style of coding to be a more super-powered version of the kind of programming I was already trying to do before LLMs: careful, methodical, quality-obsessed, focused on making things better for the next coder.

So take a deep breath, slow down, try this technique, and see if you don’t enjoy writing better code more slowly.

Programming is an art. It’s less like fine art or music and closer to architecture or carpentry – combining form and function – but it is an art.

If you don’t believe me, consider code reviews. I’ve definitely done code reviews where I admired the mastery on display, where the elegance of the solution shone out like a brilliant gem, where I felt like Salieri overcome by the symphony in his head as he reads Mozart. Conversely, I’ve mentored juniors where I read their code and immediately saw opportunities to help them mature – this bit is repetitive, this bit could be expressed more succinctly, this bit hits a performance de-optimization, etc.

When I do PR reviews of AI-authored code, I feel none of these things. I can sometimes tell whether it’s authored by Claude or Codex (Claude likes lots of Official-Sounding Comments, Codex is more to-the-point), but my mind tends to wander to the intent behind the PR, to the prompt or the plan. Nitpicking details of the code, like the type of for-loop or the names of functions, feels entirely superfluous. Sometimes the best advice is to just choose a new plan and re-prompt.

For most of my career, I’ve held two contradictory views of coding in my head simultaneously:

• Coding is an art form, but you shouldn’t get too sentimental about your code – most code eventually becomes technical debt that should be expunged
• Code can express the creativity of the author, but the best code is idiomatic, reducing the WTFs per minute
• In short: code is art, but it’s also a means to an end

With the advent of LLM coding agents, I think this contradiction has been firmly resolved in favor of function over form. Or as Les Orchard might put it, the “make-it-go people” have triumphed over the “craft-lovers.”

The craft is still there, of course, but it’s different. When I code with agents, I’m thinking at a much higher level of abstraction: architecture, resilience, systems, monitoring, testing. I used to sweat the small details – Claude starts comments with a capital letter, I rarely do; Claude names variables one way, I prefer another – but I quickly learned to stop caring. It’s simply a waste of time to nitpick, especially since the agent will likely undo your nitpicks on the next refactor.

In some ways I feel like a carpenter whose job is now to write the blueprints for the IKEA factory. Of course there is still artistry in designing the blueprints, but you don’t care if the factory spits out one or two tables with splinters in the legs. The point is to produce enough furniture fast enough that the little imperfections don’t matter. Taste and judgment still count, but they’re at the level of the overseer on the assembly line, not the master carpenter working a chisel.

Finding art elsewhere

For me, coding always occupied an odd place on the artistic spectrum. Some code is firmly art – Jenn Schiffer, for example, has been an artist-in-residence and has had numerous projects devoted to the intersection of art and programming. Whereas other code is purely functional: I’m sure many programmers have spent their entire careers pumping out glue code for enterprise CRMs without ever wondering if what they were making was “art.”

One worry I have for my entire generation of programmers is that many of us have been getting our artistic “fix” from coding: taking craftsmanship seriously, reviewing others’ code with the eye of a literary critic, trying to elevate the profession. Now the profession has been turned into an assembly line, and many of us are eagerly jumping into our new jobs as blueprint-designers without questioning what this will do to our souls. I believe art is necessary for a rich and full human life, so this isn’t an idle concern.

My advice to other coders, or at least the advice I’m taking myself, is that if you’re looking for art in coding: stop looking. If you’ve never taken an interest in poetry, or painting, or dance, or whatever, now would be a good time. In an era where the internet is increasingly full of bots pumping their bland bot ideas into everybody’s brains, seeking out distinctly human forms of expression has become vital.

It might sound corny (or like I’m going through a mid-life crisis), but I’ve done the following lately:

• started painting (Bob Ross is of course an easy stepping stone)
• gone to several ballets / contemporary dance performances
• started reading more fiction (The Sun Magazine is a longtime favorite of mine, but I’m even reading the poetry now)
• picked up my guitar again

You might have also noticed that this blog has gotten a lot more sentimental and experimental lately. I’ve never used LLMs to help with my writing (not even to spellcheck!), but lately I’ve tried to fight my own tendencies to write bland, predictable prose. In a world of machines that “predict the next token,” what’s the best reaction? Be less predictable. At least that’s what I hope I’m doing.

I don’t think coding is dead as an art form, and I do think that the “new” craftsmanship will have its own masters, its own styles, its own expressiveness. Heck, maybe I’ll be surprised and there will be an artist-in-residence somewhere wielding agent orchestrators like a paintbrush! But I kind of doubt it. If you’re not knitting, then you’re making clothes on an assembly line, and if the clothes are disposable, then it’s just fast-fashion. There’s artistry there, perhaps, but the end product is much less interesting artistically because there’s less of the human touch to it.

In my view, we’re firmly in the fast-fashion era of coding: software is vibe-coded, used up, thrown away, vibe-coded again. This is not a fully bad thing, and I’m sure many non-coders especially are giddy at the superpowers they’ve acquired. But as coders, we shouldn’t lose sight of what we’ve lost, and we should seek to make up for it with new sources of artistic sustenance.

You had a story you used to tell yourself about how you got here in life.

You’d share the story with others. Maybe you’d be at a party, and someone would ask what you do, and you’d say, “I’m a programmer.” And their eyes would perk up and their mind would fill with images of ball pits and propeller beanies and that funny movie with Jesse Eisenberg, and they’d say, “Oh yeah, like you build apps?”

And you’d proudly brush it off and say something like, “Yeah I work on the backend, you don’t know what that is, but it’s basically the magical thing in the cloud that makes your apps work.” Or you’d say, “Yeah I work on the frontend, it’s the thing you touch all day long on your phone, I make it look good and run fast.”

And if you thought about what it took to get there, you’d think of the lines of code, fuzzy green text in a black terminal, the mystical incantations that lit up the glowing rectangles that everyone else was staring at all day. They didn’t know the effort, the raw-adrenaline flow of code bursting from your fingertips as you wove dreams into pixels. Or the writer’s block of the showstopper bug that nagged you on your jog and in the shower until suddenly the answer came to you when you awoke, as if from a dream, and you rushed to the keyboard to pound out the solution, the pure exhilaration of making the computer obey you.

Then someday somebody took that story from you. They told a different story: one where someone on a stage, in a business suit that you’d never wear, with a smug grin that you’d never wear, talked words into a computer and, the little traitor, it obeyed him. He talked words like you or I would, like any simpleton would, and it obeyed him. And the crowd cheered because they knew that now the glowing rectangles belonged to them as well, and not just you, with your wizardly spells that took years of study to master.

When you see your brother at Thanksgiving, he’s excitedly showing your parents an app he built to track football scores. Except he didn’t really build it, you think to yourself bitterly. He’s not a programmer, he’s a mechanic, and maybe he knows his way around cars, but he never grinded LeetCode to pass an interview, or stayed up late studying Data Structures and Algorithms to pass an exam. “Let you brother have this one,” your dad chides you after an outburst at the dinner table. “It’s just an app.” Just an app, you scoff with amazement.

When you go home, you pour yourself a stiff drink and wonder what kind of story you can tell yourself now. You were Superman, and now every schmuck puts on a cape and thinks they can fly. The fools! They’ll fall. They’ll fall and crash, you reassure yourself as you take a swig.

Your friends agree. “This stuff will never work,” they say, as if with bored detachment. “Remember low-code? Remember no-code? What a joke.” But you notice something: a fear in their eyes that you’ve never seen before. You don’t feel reassured.

Eventually you find that your own colleagues are warming to the stuff. “It’s actually pretty useful,” they say. “Give it a shot.” You’re astounded by the pure treason. Don’t they realize this is a rejection of everything they’ve done their entire careers, an insult to their very dignity as a programmer? They shrug. “Sure, but times change. I want to have a job in five years.”

Five years. Your retirement is looming. And you were looking forward to leaving at the top of your game, maybe to tinker on some side projects after money is no longer an issue. But now you don’t know about the money, or the side projects, or whether you’ll be at the top of your game anymore or just a washed-up has-been. The panic is really starting to set in now, and you’re looking for an out.

You approach the tool out of resentment – cautiously, like a cursed artifact. You hold the dead thing at arm’s length, as if its very aura might poison you. You try it out, and it chirps happy success but everything it spits out is failure. You close the laptop lid. Vindication! The thing truly is dead, a fraud, a sham. You can return satisfied to your beloved craft.

Except your craft doesn’t feel right anymore. More and more, you read about astounding feats created with the accursed tool. Colleagues you trust and admire are now reconfirming, in more strident tones, that it actually works. The treason is all around you, choking your joy, ruining what once gave you so much meaning. You can barely stand to look at the blinking cursor in your text editor anymore, which has also betrayed you with its daily offers to steal your voice, retire your fingers, extinguish your spark.

You start to wonder if this industry is even right for you anymore. How can it be right when everything around you feels so wrong? And always, there is the fear: fear that you are losing ground, fear that you won’t make it past the next layoffs, fear that you’ll be joining your brother in the auto shop and he’ll be showing you the ropes, you with your fumbling fingers that can barely hold a wrench, and oh by the way did you see the app he built to replace his content management system?

Where the story goes next is for you to decide. Maybe you can skate by for a few more years in a sinecure, holding onto a payslip for dear life, while the world moves whooshing around you. Maybe you’ll give in and learn the new tools, but with a kind of detached ambivalence, going through the motions but no longer feeling joy or meaning or like you have something worth talking about at a dinner party.

Or maybe you’ll look around and study those who have adapted to the new world and are thriving. Maybe you’ll notice the coworker who brushed off all the doom and gloom and just says, “Hey, look at this cool thing I built.” And maybe you’ll notice that this coworker has their own kind of mastery, their own tools and workflows with odd names that turn you off at first but ultimately pique your curiosity. Maybe you’ll wonder if it makes more sense to hang out with the people building and sharing and having fun instead of those who mope and whinge and cry for a lost golden age. Maybe instead of being ruled by fear, you’ll find your creative spark again.

Because isn’t that the point in the first place? Isn’t that why you got into programming? Wasn’t it to make something, to put it out in the world and bring joy to others with your creation? Wasn’t it to make a song out of sand, a painting out of pure thought, a miracle out of nothing, regardless of how you did it?

If it is, then you might find that the story you need to tell about yourself, about who you are and where you came from and why you create, was right there all along. The story has been told hundreds of times throughout history – only the characters and the scenery change – and you still have it in you. You found it once before, and if you search for it with curiosity and an open heart, you’ll find it again. It never really left you.

Oprah Winfrey and I have something in common, which is that our favorite album is Paul Simon’s Graceland.

I’ve been thinking a lot recently about the opening track, “The Boy in the Bubble”. The song can be read a few different ways, but I read it as an aging man amazed by modernity but also kind of frightened by it, and comforting his loved one with:

These are the days of miracle and wonder, and don’t cry baby, don’t cry, don’t cry

If these are “the days of miracle and wonder,” then why would anyone want to cry about it? Well, a few different reasons:

These are the days of lasers in the jungle, lasers in the jungle somewhere

Staccato signals of constant information

A loose affiliation of millionaires and billionaires

Sound familiar? It was written in 1986, but it could have been written today.

One thing I’ve noticed during our recent technological turbulations is that some people seem to have lost the capacity for wonder, or are willfully ignorant of the wonders around them. And if you can’t acknowledge that something extraordinary has happened, then you can’t start grieving for what has been lost (the subject of my last post). To me, this is the opposite of what Paul Simon is advocating: awe for the future combined with reverence for the past.

For example, I have a lot of conversations on Mastodon that start with me acknowledging some flabbergasting feat that coding agents have accomplished lately, like one-shotting a browser API that passes 77% of the relevant Web Platform Tests, or building a rudimentary browser that can render basic web pages, or building a C compiler that can compile the Linux kernel, etc. Then the interlocutor says something like, “Sure, but are the Web Platform Tests really representative of a working browser?” (Short answer: yes, it’s the entire basis of cross-browser projects like Interop.) Or: “Well sure, but is the code maintainable and bug-free?”

I find these conversations kind of baffling. It’s as if you’ve been shown a talking dog that can also sing the blues and play steel-string guitar, and your first response is, “Yeah, but the second verse was a bit off-key.” I understand skepticism – being skeptical is good, and there is a ton of hype and hogwash out there in the “AI era,” but like… can we just take a moment to be amazed? None of this was imaginable even three years ago, and now it’s practically worthy of the snooze button.

In fact, some of my more AI-adept colleagues are actually not much impressed with these stories, precisely because they know that even more amazing stories are likely around the corner. The lasers in the jungle have become so commonplace that we hardly notice them anymore.

Personally, I’m trying to maintain my skepticism as well as my sense of wonder. There’s so much breathless hype out there that it clouded my judgment for a while, but I’m also humbled by how fast things have moved, defying my early expectations.

I don’t consider myself a tech optimist – I seriously doubt we’ll ever travel to Mars, let alone colonize it, and I think predictions of the singularity or uploading our brains into the cloud are fun science fiction but hardly a bet I would take on the optimists’ side. But I have to admit that I was wrong on AI coding, so I’m prepared for my expectations to be defied again.

In many ways, I feel like the last year has been a victory for the techno-optimists – LinkedIn bros, Elon Musk stans, former NFT-peddlers – over artists, tech critics, and left-leaning intellectuals, which has been a bitter pill for me to swallow, since I identify with the second group much more than the first. This is what I was trying to get at with “AI tribalism”, although in retrospect I was a bit clumsy about it.

So if you’re feeling like me, and a bit bitter that the tech bros are taking a victory lap right now, and maybe hoping that they realize their shoelaces are untied and fall flat on their faces, I’d suggest taking a different tack. Disregard the hype, ignore the breathless prognostications of eternal abundance, and just look around and ask yourself if you would have been impressed by any of this three years ago. If so, take a moment to be amazed. It doesn’t make you a stooge or a credulous mark; it just makes you human.

And if you have to grieve, grieve. Technology is changing in scary and unpredictable ways, and not all the changes are positive. (Far from it – I wonder if someday we’ll look back on the invention of LLMs like the invention of the atom bomb.) But eventually we should move on from our grief, because the world is not ending; it’s just turning, as it always has.

In other words:

These are the days of miracle and wonder, and don’t cry baby, don’t cry, don’t cry

I didn’t ask for this and neither did you.

I didn’t ask for a robot to consume every blog post and piece of code I ever wrote and parrot it back so that some hack could make money off of it.

I didn’t ask for the role of a programmer to be reduced to that of a glorified TSA agent, reviewing code to make sure the AI didn’t smuggle something dangerous into production.

And yet here we are. The worst fact about these tools is that they work. They can write code better than you or I can, and if you don’t believe me, wait six months.

You could abstain out of moral principle. And that’s fine, especially if you’re at the tail end of your career. And if you’re at the beginning of your career, you don’t need me to explain any of this to you, because you already use Warp and Cursor and Claude, with ChatGPT as your therapist and pair programmer and maybe even your lover. This post is for the 40-somethings in my audience who don’t realize this fact yet.

So as a senior, you could abstain. But then your junior colleagues will eventually code circles around you, because they’re wearing bazooka-powered jetpacks and you’re still riding around on a fixie bike. Eventually your boss will start asking why you’re getting paid twice your zoomer colleagues’ salary to produce a tenth of the code.

Ultimately if you have a mortgage and a car payment and a family you love, you’re going to make your decision. It’s maybe not the decision that your younger, more idealistic self would want you to make, but it does keep your car and your house and your family safe inside it.

Someday years from now we will look back on the era when we were the last generation to code by hand. We’ll laugh and explain to our grandkids how silly it was that we typed out JavaScript syntax with our fingers. But secretly we’ll miss it.

We’ll miss the feeling of holding code in our hands and molding it like clay in the caress of a master sculptor. We’ll miss the sleepless wrangling of some odd bug that eventually relents to the debugger at 2 AM. We’ll miss creating something we feel proud of, something true and right and good. We’ll miss the satisfaction of the artist’s signature at the bottom of the oil painting, the GitHub repo saying “I made this.”

I don’t celebrate the new world, but I also don’t resist it. The sun rises, the sun sets, I orbit helplessly around it, and my protests can’t stop it. It doesn’t care; it continues its arc across the sky regardless, moving but unmoved.

If you would like to grieve, I invite you to grieve with me. We are the last of our kind, and those who follow us won’t understand our sorrow. Our craft, as we have practiced it, will end up like some blacksmith’s tool in an archeological dig, a curio for future generations. It cannot be helped, it is the nature of all things to pass to dust, and yet still we can mourn. Now is the time to mourn the passing of our craft.

My first blog post was published just under 15 years ago in March of 2011. Since then, I’ve published 151 posts, including this one. (If I was a numerologist, I’d think it had something to do with Pokémon.)

This blog has covered a wide variety of topics, including Pokémon in fact (I wrote the first Pokédex app for Android). The topics largely followed the trajectory of my career: starting with machine learning, veering into Android, taking a detour into Solr/Lucene, and eventually settling on JavaScript and web development. Later I wrote about web performance, accessibility, web components – basically whatever topic crossed my desk. You’re reading the unfiltered output of my brain here, more or less.

I don’t publish a lot – less than one post per month apparently. My main guiding principle is that I don’t write unless some topic is itching to get off my chest, or I think I have something novel to say. There are no ads on this humble WordPress blog, and I don’t have anything to sell you, so there’s nothing motivating me except my own desire to explore an idea, make a point, or just stretch the old writing muscle.

As you can tell, I’m too lazy to even update the vintage WordPress theme – odd for someone who pretends to be a professional web developer! I’ve always felt like that was a distraction, though. I know some bloggers who spend more time tweaking their CSS than writing content, and that’s fine, but it was just never my goal for this blog. If I want to scratch that itch, I write an oddball project like Pokedex.org or Pinafore instead.

The biggest challenge of the early days of this blog was just getting anybody to read it. The biggest challenge later on was dealing with the overwhelming anxiety of realizing “Oh shit, people are actually reading this”, followed by the inevitable fears of:

• blowback (I got too controversial)
• audience capture (I got soft)
• being ignored (I got boring)

I feel like I’ve careened between all of these extremes over the past 15 years. Overall my writing was a lot more freewheeling in the past, and I’ve tried to recapture some of that lately, but having an audience just naturally gnaws at your mind in a way that (I find) I can’t totally ignore.

Quitting Twitter (and wasn’t that a weird story arc on my blog!) helped a lot, although there’s still of course Mastodon and Lobsters and Hacker News and all the rest where the comments can be a vicious cesspool if you spend too much time there. (If you’re reading this from RSS: you’re my favorite readers, and they can take my RSS reader from my cold dead hands!)

Not that this blog has a ton of readers. There’s actually a list of the most popular blogs on Hacker News, and mine hit #631 last year. This puts me somewhere between “I think I’ve seen his face on the internet once” and “never heard of him.” Although based on my WordPress stats, my best days are somewhat behind me, with my all-time most popular posts being:

• 2015: Safari is the new IE (I will never be able to escape this one; it’ll be in my damn obituary)
• 2016: The cost of small modules (I’m very proud of this one – I got the bundlers to optimize their implementations!)
• 2015: IndexedDB, WebSQL, LocalStorage – what blocks the DOM? (Horribly out of date by now, but somehow perfect SEO-bait so people seem to land on it)
• 2020: Linux on the desktop as a web developer (Really?)
• 2022: The collapse of complex software (My favorite thing I’ve ever written)

Although rounding out the top 10, we do get some more recent hits:

• 2023: Let’s learn how modern JavaScript frameworks work by building one (I loved this one! It was so much fun to do a bunch of research and write a nice breezy tutorial. Makes me wonder if I should have tried my hand at educational writing.)
• 2020: Fixing memory leaks in web applications (Oh man, we’ll never be free of this scourge, will we? Better buy more RAM.)
• 2022: The balance has shifted away from SPAs (One of my favorite series on this blog, and I think I totally called it. Cloudflare buying Astro really proves that it’s time for a new model.)
• 2012: Better synonym handling in Solr (One of my earliest stabs at open source, and surprisingly I’ve gotten a lot of emails about this one.)
• 2017: What it feels like to be an open-source maintainer (Maybe one of my more timeless posts, getting quoted in Nadia Eghbal’s Working in Public, getting me a somewhat emotional podcast interview, and probably making a lot of people remember me as “that open source burnout guy.”)

Interestingly to me, though, the work that I’m most proud of didn’t get a lot of traction. It wasn’t a polemic, or a thinkpiece, or a perhaps-too-glib takedown of a major browser vendor (sigh) but instead my work on performance optimizations, benchmarking, etc. A lot of my blog posts are basically: “People say this thing is fast. Is it though? Let’s run some numbers.” For example:

• 2022: Style performance and concurrent rendering (“Is CSS-in-JS actually fast?” Answer: “No.”)
• 2022: Style scoping versus shadow DOM: which is fastest? (“Is shadow DOM fast?” Answer: “Kinda!”)
• 2024: Improving rendering performance with CSS content-visibility (“Is CSS content visibility fast?” Answer: “Yes, but not as much as I wish!”)

This is the kind of stuff that (I like to think) really moves the needle in the web development space, because words are cheap but numbers talk. I’ve heard from some folks that a post of mine immediately short-cutted some internal discussion about whether they should choose Strategy A or B for their web app. I love having that kind of impact!

This experience has taught me that the page stats aren’t everything. Sometimes it’s not about how many people read your post, but whether the right people read it. One example is my recent post on the js-framework-benchmark. This was a sleeper hit: barely touching any of the socials, never high on Hacker News or Lobsters, and yet I know from personal anecdotes that performance experts read it and appreciated it. Not every post needs to be a thrilling dimestore paperback: some can be a ponderous Tolstoy or Joyce.

Conclusion

When I first started this blog, I was early in my career and didn’t really know what I was doing. I made a blog because I guess I thought it was the cool thing to do, and that maybe it would help me land a job someday.

I named it “Read the Tea Leaves” because I thought you were supposed to have a punchy title like “Daring Fireball” or “Coding Horror”. If I were starting it today, I’d probably just call it “Nolan Lawson’s blog” and be done with it (although I do love tea).

Keeping this blog has been a great source of passion for me, and it has indeed opened doors in my career. I landed my most recent job in no small part thanks to this blog (good foresight, 2011 me!), and it’s also just really fun to get recognized at a conference or have a coworker mention that they enjoyed one of my posts.

I’ve found though that the greatest value is just the act of writing itself. That’s one reason I don’t use AI for any of these posts (heck, I don’t even use Grammarly – all the spelling mistakes are mine!). The act of writing is also the act of thinking, and my thoughts are (usually) sharpened by typing words into a blank page.

And if nothing else, I can put an idea out there, let it get tossed in the wind, and see if anybody picks it up to do something useful with it (even if that something is just to denounce or refute it). For that reason, I don’t even regret my most controversial posts, and not even the ones I disagree with today, because I think there’s still value in being wrong in public and at least trying to stimulate people’s minds in the right direction.

Would I recommend that young coders take up blogging? Absolutely. Start up a blog anywhere – WordPress, Squarespace, a file server of HTML files, whatever. Write all the time, even if you don’t always hit “publish.” (I certainly don’t – 63 unpublished drafts!)

Get yourself in the habit of being brave in public, and try to ignore that voice that says “This isn’t good enough” or “You’re not smart enough” or “People will hate you for this.” I’ve sacrificed a lot of sacred cows over the years, and maybe even burned some bridges (man, my recent AI posts may have done that). But if I hadn’t tried to speak my mind, put my thoughts out there, and find the courage to be vulnerable in public, then I would have just felt limp and cowardly and boring. That’s what I regret most: all the blog posts I didn’t write.

Still, I do have a high bar for this blog (despite what some haters may believe!), so I don’t intend to become one of those “post-a-day” kind of people. It’s just not my style. But I do hope to be the kind of person who has more ideas worth expressing and worth putting into cyberspace. Here’s to 15 more years of blogging.