Notes

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.

I enjoy programming computers because they function on a set of precise and rigid rules. This creates a kind of fantasy world where you can gain wizard-like powers as you accumulate knowledge. Yes, programming is hard and it can be exasperating, but that makes the eventual accomplishment of mastering the skill all the sweeter. Over time, you gain fluency and dexterity as a programmer. It feels good.

Which is to say that the pleasure I get from programming is mostly about learning the underlying truths about computation and applying what I’ve learned. Always improving the craft. This, to me, is the practice of programming.

As the saying goes, the more you learn, the more you realize how much there is still to learn. I’ve spent countless hours over the last 30 years reading about, thinking about, and practicing the art, hobby, occupation, and discipline of programming computers. If only by volume, it’s a big part of who I am.

This is why I love development.

We value learning. We value the merits of language design, type systems, software maintenance, levels of abstraction, and yeah, if I’m honest, minute syntactical differences, the color of the bike shed, and the best way to get that perfectly smooth shave on a yak. I’m not sure what we’re called now, "heirloom programmers"?

Do I sound like a machine code programmer in the 1950s refusing to learn structured programming and compiled languages? I reject that comparison. I love a beautiful abstraction just as much as I love a good low-level trick.

If the problem is that we’ve painted our development environments into a corner that requires tons of boilerplate, then that is the problem. We should have been chopping the cruft away and replacing it with deterministic abstractions like we’ve always done. That’s what that Larry Wall quote about good programmers being lazy was about. It did not mean that we would be okay with pulling a damn slot machine lever a couple times to generate the boilerplate.

I like this definition that the problem lies in “never reorganizing [the code] to reflect your understanding.” In a go-go-go product cycle, that loss of understanding begins to create problems that have literal and figurative costs. A general sense of confusion builds and builds. The developer economics are fairly simple to quantify; either you slow down and pay someone to refactor and document the code after every major iteration, or you pay every developer who works on the project until the end of time to stare at the code for a few hours and wonder what the hell is going on. That dumbfounded staring at the codebase compounds over time. Organizationally, you pay in velocity and turnover; talented people are going to leave after a few rounds of bullshit.

The other major part of the job is to ensure correctness. For me, it is much harder to verify the correctness of code I didn’t write compared to code I wrote. The process of writing code helps internalize the context and is easier for my brain to think deeply about it. If I outsource this to an LLM, I skip over the process of internalizing the problem domain and I can’t be certain that the generated code is correct.

Writing the code helps you understand what it's doing. The better your understanding of code, the easier it tends to be to debug it when you're trying to track down a bug or other issue.

It is impossible to overstate the gift of security, wealth, opportunity, and sheer innovation that these six foundational pillars of the US policy achieved for both the world beyond and Americans at home. To be clear, America’s eight-decade reign atop the world order was hardly without great human cost—felt most acutely by those on the far edges of the Cold War, from Vietnam and Cambodia to Africa and Latin America. But scratch at almost any titanic achievement of humanity across the last 80 years in human history and you’ll see the traces of America’s six foundational policies, from the astounding achievements in human health and well-being to the decline of world poverty to the very invention of the internet. Pick almost any measure of business success and I can show you how that six-part recipe applied. To choose just one: All four of the world’s $4 trillion companies—Nvidia, Alphabet, Microsoft, and Apple—saw immigrants or their children play a key role in their success.

Meta’s director of safety and alignment at its “superintelligence” lab, supposedly the person at the company who is working to make sure that powerful AI tools don’t go rogue and act against human interests, had to scramble to stop an AI agent from deleting her inbox against her wishes and called it a “rookie mistake.”

I don't know about you, but this really inspires my confidence in Meta to handle AI safely and effectively.