People, the context-bearers, have experience and capabilities that machines might never understand encoded in our muscles and memory. I’m on record saying I despise nuance –and I do– but it’s more important than ever to be able to connect to our fellow humans over this nuance so our world is not paved over by contextless opinions from ill-informed robots. Empower and believe people over machines.
Let me try to define the Good Web. The Good Web is any part of the internet built in good faith, which I mean in the specific, contractual sense. The maker is not optimizing against the user. No dark patterns. No retention schemes. No bloated scripts designed to keep you scrolling past the point of nourishment into the territory of compulsion. Nobody on a bbCode forum is selling your reading habits to an insurance company. The Good Web is not a technology, not a protocol, not even a community—though it contains all of those things. It's a disposition toward the person on the other end of the connection. It's the difference between a neighbour who bakes you bread and a supermarket that puts the bread at the back of the store because they know you'll buy chips on the way. Both are offering you something. Only one of them gives a shit whether you leave full.
More of this please.
You simply cannot breathe without seeing, hearing, or engaging in any kind of technical conversation about AI. AI has dominated the Zeitgeist so catastrophically that the only way to escape is to turn off the WiFi and delete all the apps. Every single piece of fucking software has some kind of shitty AI add-on, forced into your face at regular intervals whilst you’re trying to go about your life or do your job or check your email or write an email or read an email or talk to a human support agent or read a recipe or open an issue on an open-source project or watch a YouTube video or open your IDE or do a fucking internet search. The cognitive overload of AI trying to Make You More Productive™️ whilst you’re actually trying to be productive is so shockingly absurd. And yet, we are being made to feel like we are stagnating, being left behind, not good enough, that we are luddites should we not adopt this imposing technology. We are being told we’re missing out, even though we’re probably doing just fine. The technology is gaslighting us.
It's all opt-out (if you're lucky enough to be able to turn it off) too.
What’s even more personally terrifying: what if I need to find a new job in the near future? There are seemingly no non-generative-AI-centred options left for someone like me. I’m afraid that every opportunity will either be for a company building some kind of generative AI experience, or one that mandates the use of generative AI in your daily responsibilities, or one that refuses to use AI at the expense of their financial success and the stability of my employment. At this point I cannot escape. I am at the mercy of the profession I chose. I have a family to feed and a mortgage to pay. Retraining is not an option right now. I must force myself to adapt.
This was a fantastic conversation bringing in a bunch of the nuance that is so often missed.
No one was particularly optimizing for engagement or time-on-site or conversion. People made websites because they had something to say, or something to show, or just because they could. The web was weird and slow and full of bad tiled backgrounds, bad fonts and dumb ideas.
It was also weirdly, wildly, wonderfully human.
I almost feel like this is one benefit of Musk's takeover of Twitter/X. More people seem to have started building or resurrecting their own personal sites.
There are still people building the web by hand, very much like we did it in the early days. They know all about what's possible using modern tooling, yet they choose to expend their time and attention to the craft of doing it by hand. They care about the craft, and they care about what they're making. They believe in their unique skill and vision over engagement strategies and analytics and content algorithms. They don't need a platform, or they'll build their own.
But agentic coding is about more than moving upwards in abstraction. The compiler gave us abstraction without ambiguity. You wrote C, and it became assembly, deterministically. The layers were clean, and you remained a programmer in the traditional sense of how we’ve always understood the word.
What’s happening with agentic coding might better be captured by a term coined by Venkatesh Rao: “oozification.” Oozification, as Rao describes it, is the tendency of technological systems to evolve from structures built of large, rule-heavy building blocks to ones composed of smaller, more fluid, less constrained components.
Imagine, if you will, the difference between a man-made, plantation forest and a swamp. The forest has legible structure: tidy rows, canopy, understory, floor. The swamp is murkier, richer in evolutionary possibility, but also much harder to read. Oozification is the transformation of the forest into the swamp. The number of possibilities increases, while the number of certainties decreases, and that combination tends to make people downright nervous.
A natural language prompt doesn’t compile into code. Instead, it gets interpreted, completed and sometimes second-guessed by a probabilistic system. Intent blurs into elaboration and precise control gives way to fuzzy suggestion. It’s oozy and messy programming, and the role of the programmer blurs as well into something with unclear boundaries—part orchestrator, delegator, babysitter, designer, reviewer. People have always struggled to call software development honest-to-goodness “engineering,” and with the oozification of the practice, that highly-esteemed label has only become more ill-fitting.
Complexity looks smart. Not because it is, but because our systems are set up to reward it. And the incentive problem doesn’t start at promotion time. It starts before you even get the job.
I've learned so much over the years, and while it is always helpful to think about how features might be used in the future, it's even more helpful to know when to worry about it now, and when to leave it for later...if later ever comes.
The actual path to seniority isn’t learning more tools and patterns, but learning when not to use them. Anyone can add complexity. It takes experience and confidence to leave it out.
I've heard the term cognitive debt being bandied about. Having to deal with larger PRs, especially with a good deal of AI-generated code can be taxing.
This, I believe, is why reviewing AI-generated code feels so much more exhausting than reviewing a colleague's work. When a human pair submits code after a whiteboarding session, I am reviewing implementation against a design I already understand and agreed to. When AI generates code from a single prompt, I am simultaneously evaluating scope (did it build what I needed?), architecture (are the component boundaries right?), integration (does it fit our existing infrastructure?), contracts (are the interfaces correct?), and code quality (is the implementation clean?) — all at once, all entangled.
That is too many dimensions of judgment for a single pass. The brain is not built for it. Things get missed — not because I am careless, but because I am overloaded.
There’s no mention of how these tools are causing corporations to blow past their already tepid climate goal; no mention of how the affluent, surveillance-obsessed exec dictating its trajectory enthusiastically cozied up to fascists; no mention of how Elon Musk and Mark Zuckerberg’s data centers are funneling pollution directly into black neighborhoods; zero mention of the technofascist plan to leverage AI to decimate unions; no mention of the weird and precarious financial shell games powering the sector.
I don’t like using code that I haven’t written and understood myself. Sometimes its unavoidable. I use two JavaScript libraries on The Session. One for displaying interactive maps and another for generating sheet music. As dependencies go, they’re very good but I still don’t like the feeling of being dependant on anything I don’t fully understand.
I can’t stomach the idea of using npm to install client-side JavaScript (which then installs more JavaScript, which in turn is dependant on even more JavaScript). It gives me the heebie-jeebies. I’m kind of astonished that most front-end developers have normalised doing daily trust falls with their codebases.
I don’t think I’m as adverse to dependencies as Jeremy, but I’ve definitely shifted more to his views over the years. I’ll definitely write my own code more readily than I would’ve several years ago.
I do get the appeal of building in React, really, I do. It’s a fun programming model, and there are inherent organisational benefits to the component paradigm it pushes so hard. There’s also a lot you can reuse out there, and maybe that gives you the confidence that you’ll spend less time in the initial implementation, leaving you longer for improvements and polish.
And that’s fair, you probably won’t find a larger ecosystem of components, libraries, and complementary frameworks, ready to use! But beyond generally poor performance, they come with another pretty big caveat: they don’t seem to last very long. In my experience, there isn’t much in the way of stability in the React ecosystem, or even the JS ecosystem as a whole. Perhaps that’s changing lately, but historically, I’ve seen multiple large applications end up rewriting massive portions of their code after a while, not because of product reasons, but because of dependencies
It is easy to find a library for anything you need in React. It's what it makes it easy to quickly build things. But building quickly doesn't mean building well.
It’s time to stop lying to ourselves that JS-heavy client-side approaches are the way to develop a web app nowadays. We really should stop reflexively reaching for JS frameworks for everything we build, and to stop basing our architecture decisions on the stack we’re most familiar with.
"How we've always done it" is so often too easy to say and do.
We really owe it to our users to do better as an industry, because right now we’re often building the way we want to, not the way they need us to.
This is a phenomenal deep dive into all the different ways you can customize the HTML list elements.