DEV Community: Spencer Elkington

The Wild Web

Spencer Elkington — Wed, 04 Nov 2026 00:00:00 +0000

Alright, let’s get this out of the way:

You were born in 1998. You’ve always had the internet. What would you know about the old-school web?

Have I only ever known an era of version control?

Did I start my career just a couple years after robots absolutely swept the field, arguably before I got a stable footing in the industry?

I suppose so.

Have I spent the last two years getting slapped around by technical stacks older than I am?

A bit more, perhaps, than I’d care to admit.

Three knocks against me, there, but I’ve got a trick up my sleeve. A badge of honor. A stamp of approval to talk about old-school web. An undeniable bona fide:

A slice of my personal Geocities page, plucked, by luck, as part of the Internet Archive’s 2009 GeoCities Special Collection.

Unfortunately, it seems the images have been lost to time, and the actual index page of geocities.com/zipzapkidsplay, our family’s shared GeoCities account,¹ didn’t seem to make it into the Special Collection.²

The proof may be partial, but it’s proof nonetheless: I, for a brief and glorious moment, got to exist in the world of Web 1.0.

The Eras of the Web

If you’ve never heard the term Web 1.0 before, it’s important that you know where we’re coming from.

There was a period of time when websites were static: when you were on a website, there was not a whole lot that you, the user, could do to change the contents of the page for other people.

The quintessential archive example of this concept is the website for the 1996 Space Jam movie. You, the user, aren’t a factor in the website: there’s no login, nowhere to like and subscribe. You can click through to see Space Jam news, get coloring book printouts, and when you leave, there’s no trace you were ever there.³

That is Web 1.0.

Web 2.0 is the era that came after that. Funnily enough, my old Geocities site is a natural bridge, with its hyperlink to my Roblox account⁴. In a strange way, Roblox was like Baby’s First Web 2.0 experience. In its original pre-monetized form, the site was a textbook example of user-generated content. Even though I was making games, Roblox wasn’t my site. I didn’t own it. Instead, my content was being uploaded and served out of their servers.

That was the start of an era where websites were no longer just static information. They were places where you could comment and subscribe. You could place an order, or poke your friends – you know, back before Facebook’s business model was metaverse avatars and advertising eating disorders to teenagers.

Web 2.0 is⁵ the commercialization and consolidation of the internet into a core set of applications and platforms that everybody builds on top of.

Social Networks, not Social Media

Like many older members of Gen Z, I spent my fair share of the 2010s with social media accounts. Facebook, for keeping up with older family members. Twitter⁶, for shitposting with friends. I’ll even admit to using Snapchat, back when we were all too dumb and naive to think that any of that content actually self-destructed.

Of course, between swinging elections, being bought out by billionaires, and generally developing into a thin facade for shilling either bad products or even worse ideas, I largely deleted all of my social media at the turn of the decade.

The only two I have left are LinkedIn – which feels more like a professional courtesy, kept strictly at arms length – and Bluesky.

Bluesky was an interesting case. I can’t say that I even used Twitter all that much anymore before it was purchased, but I did stay up-to-date on Bluesky’s launch and initial growth because I was interested in the promise of ATProto, which creates a social network environment a bit more like old-school email.⁷

I’ve certainly outgrown the 2010s dream of becoming Twitter Famous™, but I have thought more about the concept of social networks since picking up my Season of Stamps. Part of Stamps is to be more social, building new relationships after moving across the country. Admittedly, the last ~3 months since moving have been pretty lonely⁸, and social media is, if nothing else, social.

It’s in that state of mind that I noticed something interesting, recently. I read through an interesting presentation about Boundary Objects and caught a section at the very end of the post:

Mentions around the web

It looks like a comment section, but it isn’t a comment: it’s another blog that mentions her blog post, presumably with a link. I pulled on that thread a bit, and that’s when I found something wild: IndieWeb, WebMentions, and a social network that’s practically invisible unless you know what to look for.

IndieWeb, as described by an IndieNewb

So, as I understand it, this is how WebMentions work:

I publish a blog post with a hyperlink⁹
I send a request via some service like webmention.io to the site I linked to
The owner of the site receives a notification that blog.chaoticgood.computer mentioned them
They can choose to include that mention on their site, in whatever form factor they’d like.

This is a sneaky little process, isn’t it? There’s not really a platform to speak of: there’s not a single feed anywhere to see any of this. It’s just a casual “Hey, I mentioned you!”, and a choice to acknowledge the mention.

The tricky part: it’s elegant, but invisible. I’m the type of person who gets into this kind of thing, and I’ve been reading Maggie Appleton’s blog for awhile now without ever noticing that there was some under-the-hood magic going on.

In my mind, something that’s hard to see is also hard to understand, and something that’s hard to understand is hard to jump into.

So, let’s try to see it.

The webs of the Web

Since learning about this, I’ve gone ahead and updated this site to support WebMentions:

Outgoing mentions are handled by a GitHub Action that triggers after I push out new content
Incoming mentions are handled through webmentions.io¹⁰

So: do I have any friends, yet?

Let’s crawl through my mentions to check!¹¹

This interactive content can only be viewed on the live site.

Dammit! No friends, yet. However, it is cool to see that I’ve accidentally stumbled on this in the past. My mention to Bogard’s work was March of 2024, so I’ve been orbiting around WebMentions for longer than I expected!

So, I know these three have WebMentions enabled, since my outgoing mentions were acknowledged by them. Despite being apparently easy to stumble into, I’m still not quite sure, at this point, how discoverability works for IndieWeb.

One sure-fire way to know who is using WebMentions? Going through these three and finding out who they’ve got WebMentions with!

This interactive content can only be viewed on the live site.

The web! It’s alive!

While my scrapes of Jimmy or Birgitta’s sites didn’t yield much¹², Maggie’s blog is a real hotspot of WebMention activity.

Now that we’re scraping outside of our own domain, I’ve added a bit of extra sauce. First, we can now see incoming and outgoing mentions for those sites: not just who is mentioning them, but who they are mentioning.

Second: I’ve also stolen a bit of a Twitter-ism – the idea of the mutual. On follow-based platforms, mutuals are somebody who you follow, and who follows you back. Here, I’ve highlighted mutuals specifically, with the hope to find not just chatter, but actual back-and-forth conversations happening on the IndieWeb within my immediate vicinity.

Finally, I’ve highlighted an important finding: IndieWeb itself. You’re going to see this one come up a lot more as the graphs progress. IndieWeb allows folks to mention IndieWeb in order to consolidate posts about IndieWeb. It’s a real turducken of self-reference. Compliments to the chefs: it’s a beautiful thing to see.

Now, at this point, I’m both on a roll and quickly noticing that other sites suspect my home internet of being a bot farm, so I only have the moral budget for one last scrape. I looked through many of Maggie’s mutuals and mentions, and went through some of my personal highlights:

Chris Aldrich, a.k.a. boffosocko, who seems to be a big figure in the IndieWeb/microblogging/digital gardening scene. They write about a real broad range of topics, and all of my exploring on their site has been real fun
Swyx, who has a real wacky blend of ambient co-presence strategies that I’m absolutely eating up. I’m also a massive fan of the post they made during their tenure as Head of Developer Experience at Temporal. At my dayjob, we developed and open-sourced a library called Trax with a very similar philosophy, so it’s cool to see some of the origins of the philosophy forming, there
Ton Zĳlstra, who is another central node in IndieWeb and has a great post, “Good Enough Jumps the Model Gap”, that I feel meshes super well with the model selection portions of Software Gardening
Jeremy Keith, whose music is fantastic and has inspired me to try my hand at putting some of my own music on this site¹³

There is one other who is worthy of the most honorable mention. To understand why, here’s my final map:

This interactive content can only be viewed on the live site.

The award for the Monarch of the Mutuals goes to Ana Rodrigues! They can go ahead and pile this up next to the sweep for Best Doodles,¹⁴ as well as Friendliest Feature: earned, properly, by their Guestbook feature.

This whole adventure has been fun on many fronts, but most of all because I have a whole lot of new places to read things. I like to write about what I read, and becoming part of a strange, wild, invisible social network is just very neat to me! In the spirit of “stamp, like an envelope”, knowing that something as innocuous as linking to another page means sending out a message into this weird web has me excited to write even more.

Footnotes

Another feather in my family’s established nerd cap. ↩
There are a number of efforts to properly index Geocities archives. oocities.org states that they have 200GB of archives just waiting to be indexed, which would be a very fun project to work on. Fingers crossed that Hobby Builder can point me in the right direction. ↩
The sole exception to this is the link to the Warner Brothers Store. It’s pretty funny that the only maintenance of this site is the plug. It’s like if the janitor of a museum only swept the gift shop. ↩
I’m shocked to see such a progressive bio, considering I was 10 years old – and Mormon – at the time of that snapshot. What can I say? I’ve always been an ally. ↩
or “was”, depending on if you believe NFT photos of apes truly brought on Web 3.0 ↩
X? Over my dead body. ↩
I won’t get into the particulars of ATProto here, but seriously: give it a read. ↩
I’ll concede that this is certainly correlated to the uptick of writing I’ve done here. ↩
Easy!. A friend told me recently that I use more hyperlinks in casual conversation than anybody he has ever met, and I’ve chosen to take this as the compliment it was not intended to be. ↩
Check out the new “Around the Web” section at the bottom of my notes! ↩
You can find the scraper code I’m using at the monorepo for this website. This also serves as a shameless plug for Flowthru (☞ﾟヮﾟ)☞ ↩
I’m not sure if this is actual reality, or a problem with my scraper. If it ends up being obviously my fault, I’ll update the graph and post accordingly. ↩
Jeremy – if you’re reading this, please put Deep Black Water on YouTube Music! ↩
conceding that Ana’s are in a different league compared to some of my own doodle crimes ↩

The Wild Web was first published on Chaotic Good Computing, where you can reply to it on Bluesky or from your own site.

You can pry my dashes from my cold, dead hands

Spencer Elkington — Mon, 02 Nov 2026 00:00:00 +0000

I get it.

The em-dash has been co-opted by LLMs. Survey ten people, and nine of them will say “if there’s an em-dash, there’s AI.”

They’re wrong, but I get it.

If there’s anybody to blame, it’s my mother. For years, she has worked as a real-time captioner for deaf and hard-of-hearing students. Her specialty is PITA: pain-in-the-ass classes across a lot of really tricky disciplines. The em-dash is an important tool in writing human speech, because it represents a pause. A pause to, perhaps:

Qualify or clarify a piece of information
Pause, think, and – if necessary – pivot.¹
Take a deep breath; or
Be interrupted – perhaps, while you were taking that deep breath.

Those PITA classes she captions are full of those four cases, and so she has been writing more em-dashes than any other human being in the course of her decades of experience.

So: when you see me use em-dashes, just know that– it’s is a genetic thing. I will never escape that original sin.

I would still contend that the em-dash is a perfectly valid piece of punctuation, which is why it’s so aggravating that a) LLMs co-opted the emdash for a period of time; and b) even if they all stopped using it, it’d still live in perpetual infamy with other artifacts of early AI, like multiple fingers or sneaky gay boomer Looney Tunes.

I am willing to entertain that maybe – just maybe – I’m wrong about this. Perhaps I’m down bad with a case of Claude-code Syndrome or have a need to embrace apologisms on behalf of our robot overlords.

So: let’s check the tapes.

From The Archives

Thankfully, I do have a pretty solid baseline of writing on this site over the course of the last ~4 years. While it’d be interesting to, say, crack open my old undergraduate Canvas account to really populate the back-catalog, what we have on-hand will suffice.

Even though it was written a couple years ago, I still hold true to this site’s AI policy: this is the space for me to be bad at writing, so all of the writing in the public portions (and most of the private portions) of this blog are, in fact, my own bad writing.

As of the date you are reading this, my blog has this volume of my own writing:

This interactive content can only be viewed on the live site.

For the purposes of this work, I’m considering anything with a publication date before my post about GPTinglish to be outside of LLM influence. As best I can remember, I wrote about GPTinglish when Bing first released… whatever their first agent was called, which was the first time that LLMs and chatbots really entered the mainstream².

It’s my hope that we’ll have a solid before-and-after sample. My guarantee is that public notes are purely my own work, and that the vast majority (>95%) of private notes are also my own work. There are occasional portions where I use the private portions of my vault for experimenting with LLM use³), but I’ve done my best to filter out any of those for this data.

So, that’s the first part of this experiment: I am considering anything after GPTinglish to be culturally tainted by mainstream use of LLMs.

What is a dash, really?

This is another question worth being clear about, since I haven’t been internally consistent throughout the last ~10 years of my writing, either. The general timeline is:

Pre-GPTinglish, I typically used a single dash without realizing there was an actual difference between - and —. I know, I know: size does matter.
Post-GPTinglish, but before em-dashes became A Thing™⁴, I set up a keyboard shortcut on my computer (Opt+-) as a shortcut for emdashes during my Keyboard Shortcut Guy phase of the Season of Systems
In May of 2026, I got a new laptop. My Keyboard Shortcut Guy phase was over at that point (and em-dashes had gained their infamy), so I swapped Opt+- to be -- instead of —. I do fold to peer pressure pretty quickly.

Another one you might see in this analysis is the en-dash, which is… smaller than an em-dash, but longer than a hyphen. The only time I’ve ever seen an en-dash in the wild is Maggie Appleton’s recent post about Boundary Objects⁵. Somehow, one or two have snuck their way into my own blog. I can assure you: I don’t know how they got there. Those responsible have been sacked.

That aside: all that context is important to know, because “a dash” and “which dash” are two different questions.

As for when a dash is a dash, these are the rules:

it has a space before it, after it, or both; and
it’s in my own prose: not in a quote, code, or math.

The four kinds, then, that we’re going to see here:

Dash	Character	Counts	Doesn’t count
Single hyphen	`-`	I came - and then I went. well-known word; super- and sub-sets
Double hyphen	`--`	I came – and then I went.	An arrow, `-->`; a rule, `---`
Em dash	`—`	I came — and then I went.	A word—with no spaces (this does not come up in the data)
En dash	`–`	I came – and then I went.	A range: 2018–2024

As far as spaces go: it is a dash if there is a space after the dash. I have recently gotten in the habit of trying to justify my sins by doing the more traditional form of dashes– where they occur immediately after the word they interrupt– but I do still have plenty of history giving them space (--) on both sides.

Let’s crack into the data.

Sins per unit time

This interactive content can only be viewed on the live site.

In the graph above, you’ll be able to see all of my private notes, stripped down to my own writing where applicable, and only in cases where there is >100 words to analyze. While I have a policy of not publishing *all* of my notes, I figured that aggregate statistics would still be fine.

Remember: the goal, here, is to see if there are noticeable trends before and after GPTinglish. Admittedly, there is an uptick of dashes in the post-GPTinglish era! When I was originally compiling the data, there were some cases, like the Dice Widget, that caused the data to look like it had extremely high outliars.

Even after filtering out those, though, we can see that the emdashes are not only higher, but they increased over that period. Even going back and reading the note about APL’s Agricultural Valleys pattern, I gotta say: that guy was being pretty gratuitous with the dashes. I’d understand how somebody could say it has a slightly GPT-ish aftertaste.

One interesting pattern, though, is that period of time after my laptop broke and I reverted back to -- over true em-dashes. I think that there was something about facing even having a shortcut, with the hindsight of the bad reputation emdashes got, that did make me far more conscious of using them. While I would still contend that those four cases I state above are absolutely valid use of the mark, there is such a thing as over-seasoning.

Am I the Baddie?

Ultimately, this blog is still meant to be a practice ground to become better at writing and communication. Even if the em dash is perfectly valid punctuation in a void, the cultural context does have some weight to it. From a recent post about LLM voice from Martin Fowler:

Sometimes when I read a post, I get the growing feeling that I’m reading the output of an LLM. I can’t necessarily define why, although there are the common tells (it’s not the em-dashes, it’s the load-bearing tapestries). As I do this my desire to read on atrophies, sometimes to the point of revulsion

– Martin Fowler, LLM Voice

Another post on the other side of the coin by Jim Highsmith talks about cases where using an LLM to communicate may be necessary, so it feels dangerous to dismiss something that has hints of generative assistance. Regardless: if something about my writing takes somebody away from the point of that writing, I probably should do it less.

Sentences, paragraphs, and so on

This post is also groundwork for some other pieces I’m working on at the moment around writing structure and mechanical improvements. For the sake of exploration, I also have some of the some analysis by sentences and paragraph length:

This interactive content can only be viewed on the live site.

This interactive content can only be viewed on the live site.

Interestingly enough, I don’t actually see much of the same trend in these lengths. This is doubly surprising to me: first, because I’d have thought there would be some cultural artifact once LLMs became mainstream. Secondly, though, I’m surprised because I’ve actually been actively trying not to let my sentences and paragraphs run on as long.

Perhaps a more…

aggressive…

approach is in…

order?

The way these graphs are set up, they’ll continue to track along with future notes. I’d be interested in reviewing these in a year and seeing if any of the metrics have shifted around a bit in the “Future” era.

Footnotes

See what I did, there? ↩
I am loosely classifying “the mainstream” as “my parents could’ve accidentally used it without realizing” ↩
This isn’t a secret, either: I have notes about my experience with Obsidian Copilot in Programming as Theory Building’s annotations ↩
I think my first time acknowledging em dashes getting aped by LLMs was in the Hostage Negotiations post, which was 8 months after GPTinglish ↩
Perhaps I should start using en-dashes. it’d continue a long and fruitful journey of following along Maggie’s work from afar. ↩

You can pry my dashes from my cold, dead hands was first published on Chaotic Good Computing, where you can reply to it on Bluesky or from your own site.

Math is Dead, and Pickles are Small

Spencer Elkington — Mon, 26 Oct 2026 00:00:00 +0000

On September 8th, 2026, OpenAI announced that a fleet of 10,000 AI agents, running GPT-6 Astra and an (as of now) unreleased model at a cost of millions of dollars, discovered an analytical solution to a very specific question about the Navier-Stokes equations. In the most advanced terms I can understand, this is the question:

“To model how fluid moves in a system, we use a set of equations to approximate its behavior. The models are pretty good, but it’s possible that our approximation could give us funky results.

Will it give us funky results?”

– The Clay Mathematics Institute, The Millenium Prize Problems (2000)

OpenAI’s answer to this question– also in the most advanced terms I can understand, was:

“Yes. It will give us funky results in very funky situations.”

– OpenAI, Finite Time Blowup for Navier-Stokes (2026)

Some friends of mine– both engineers who specialize in fluids, and who are Very Into™ this type of thing– have told me that this answer doesn’t really mean a whole lot. The world on the morning of September 9th was, physically, pretty much the same. They all woke up, went to their jobs (typically in aviation or defense), and continued using the same fluid dynamics simulations that they did the day before.

Planes did not fall from the sky. Missiles, presumably, still exploded. My shower turned on! Fluids seemed to behave as they always have.

Some other friends of mine– mathematicians who specialize in proofs and are also Very Into™ thi type of thing– their reaction was (paraphrasing again):

“What the fuck?”

– Mathematicians, in general (2026)

On the morning of September 9th, everything felt different. To many of them, it was like a seismic force had shaken the very foundations of the universe.

Were humans necessary for the pursuit of knowledge anymore?

Did they invest their youth in a dead art?

Why would OpenAI do this?

On the morning of September 9th, my coworkers and I discussed, at an ironic length, the nature of very small pickles.

What I Learned About Pickles On September 9th, 2026

On December 2nd, 2024, Wikipedia contributor TrulyShruti made the following modification to the Wikipedia page for “Pickled cucumber”:

- Gherkins, or baby pickles, are small cucumbers, typically those 3 to
- 13 cm (1 to 5 in) in length, often with bumpy skin, which are typical-
- ly used for pickling.

+ Gherkins are small cucumbers, typically those 3 to 13 cm (1 to 5 in) in
+ length, often with bumpy skin, which are typically used for pickling.

(Most of the Wikipedia edits on gherkins tend to be focus on whether they are, or are not, “baby pickles”. For the sake of this essay, I will use the definition as of September 9th, 2026 and assume that they are not baby pickles– just very small ones.)

Gherkin is also a term used by the Behavior-Driven Development software testing library Cucumber¹.

Anybody who has worked as a professional software developer knows, intimately, that nobody actually knows what they want. As discussed in Peter Naur’s 1985 essay Programming as Theory Building, a large part of building software is the process of taking an idea that exists in somebody’s head– perhaps yours, perhaps someone else’s– and then translating it into instructions for a computer to understand.

Unlike deciding whether or not Navier-Stokes has only smooth outputs in three-dimensional space, consistently describing an idea you have in your head is a truly unsolved problem.

Pickle-Driven Development

In (good) software, a fair bit of effort is spent in writing tests. Tests are small, extra pieces of code that run your code and verify that it does what you want it to do. It’s a way to make sure that you don’t accidentally make bugs or change important things about what you’re building.

For example: if you wanted to make sure that the calendar app you’re building doesn’t try to give weird numbers for months, you might write something like:

def is_month_a_valid_number(month):
  '''
  Asserts that the number for a month is between 1 (January)
  and 12 (December)
  '''
  assert((month >= 1) and (month <= 12))

Cucumber is a philosophy, and code library, for writing better tests. Let’s take a look at the kind of notes that a very well-organized project manager or product engineer might write during a meeting about what a product should be able to do²:

Feature: Guess the word  

  Scenario: Maker starts a game  
    When the Maker starts a game  
    Then the Maker waits for a Breaker to join  

  Scenario: Breaker joins a game  
    Given the Maker has started a game with the word "silky"  
    When the Breaker joins the Maker's game  
    Then the Breaker must guess a word with 5 characters

Those are some good, organized notes! They’ve got a solid use of indentation to group concepts that belong together, with each line clearly labelled. There’s a pattern to the structure, yet it’s simple enough that you could easily write this out while product owners hash out their visions for what the thing you’ll be building for the next six months should look like.

But alas; you’ve been tricked! These aren’t just notes! They’re code!

Feature: Guess the word  

  # The first example has two steps  
  Scenario: Maker starts a game  
    When the Maker starts a game  
    Then the Maker waits for a Breaker to join  

  # The second example has three steps  
  Scenario: Breaker joins a game  
    Given the Maker has started a game with the word "silky"  
    When the Breaker joins the Maker's game  
    Then the Breaker must guess a word with 5 characters

That is Cucumber’s Gherkin language. It’s a structured, yet very natural, way to write out tests. The hope with using something like Gherkin is that writing tests for software isn’t locked behind the ability to code. If you’re willing to follow a few rules, just about anybody could read or write tests for your software.

Want to see just how easy it can be? Check out the gov.uk website: it’s easily the best working example I found while researching Gherkin. Even if you’ve never read a lick of code before, you could probably pop into their tests and understand exactly what their software does:

Feature: Administering Roles
  This feature allows the administration of the various different roles
  in the system

  Scenario: Adding a traffic commissioner role
    Given the organisation "Department for Transport" exists
    And a person called "Terence Traffic"
    When I add a new "Traffic commissioner" role named "Traffic
    Commissioner for Scotland" to the "Department for Transport"
    Then I should be able to appoint "Terence Traffic" to the new role

Terence Traffic.

God, they do it right at Whitehall.

Mastering the art of hearing an idea, writing it down, then showing it back to the person who had the idea to ask “Does this look right?” is pretty much a cheat code for software engineering. It makes every part of the job easier.

Once you get good at it, you’ll eventually be able to crank out a list of tests about the behavior of the thing you’re building, and describe a very clear picture of everything that’ll be needed to build it.

A collection of well-defined requirements, in many other fields, is called a spec, or specification.

Wouldn’t it be neat if we–

Spec-Driven Development

Ope! Turns out that a set of Extreme Programming folks came up with this one in Agile Specification-Driven Development (Ostroff, Makalsky, Paige) back in 2004! Damn you, University of York! They must’ve been the ones to tip off Whitehall!

If you’ve heard spec-driven development (SDD) thrown around a lot recently, you may be shocked to know that it’s not a recent development. But why might a school of thought around defining software in strong-yet-readable natural language have had a comeback 22 years later?

Oh.

Right.

It doesn’t take too long to recognize how Gherkin may have a newfound value in the new era of agentic software development. It has become common knowledge that agents work best in situations where their output is deterministic and verifiable, so there is something very elegant in the solution: what if the prompt and the test were the exact same thing?

However, a specification does not have to be easy to read or write: the only requirement is that it defines the shape of the thing being built. While many teams across the industry would benefit massively from something like Gherkin and Cucumber, if you shed the requirement of “broad readability”, you could go absolutely bananas with your specification.

“Bananas” would be a very good way to describe Anthropic’s Frontier Red Team’s recent blog post, LLMs are making formal software verification feasible at a much larger scale, where they write software specifications as mathematical conjectures– and then prove them.

Why Proofs?

I highly recommend reading through the Frontier Red Team’s full blog post. If I were to distill it into the two most important visualizations, though, it’d be these:

First, their description of “fuzzing”:

/assets/anthropic_fuzz.mp4

Fuzzing is a very specific type of software test, where you bombard a piece of an application with a bunch of random inputs in the hope of crashing it. This visualization generalizes further than just fuzzing, though. Any type of declarative testing (where you are defining specific inputs and outputs, then checking for a pass or fail) can be visualized, mentally, with this model. You’re just testing specific branches of the application to see if it generally does what you’ve specified, but that’s not a complete description of the program.

You want a full test? There is no fuller test than a proof:

/assets/anthropic_proof.mp4

The Frontier Red Team’s post was specifically about proofs for security: taking common pieces of software and generating proofs about vulnerabilities. It’s hard to appreciate the implications of what that means: a proof that a piece of software has no exploits.

I’ve seen a lot of discourse around a cybersecurity arms race: can defenders patch flaws faster than attackers can find them? The premise relies on a fuzz-description style of what software is: that it’s teams of people (or agents!) stabbing around in the dark.

That post, though, provides an alternative: a piece of software that is provably secure in certain conditions.

But ope! This also isn’t a new concept! This gem is a small part of the introduction, but absolutely rocked my world:

“However, formal verification isn’t easy. Proofs can be many times larger than the original code, and writing them requires significant effort and a niche, highly specialized skill set. For instance, it took two person-years to implement the seL4 operating system kernel, but 20 person-years to formally verify it. Accordingly, formal verification has been practical only in truly mission-critical applications, such as Airbus’s avionics code.

But LLMs are making it far easier.”

– Anthropic Frontier Red Team, LLMs are making formal software verification feasible at a much larger scale (2026)

I was already floored at the possibility that proofs of the properties of software was even possible, but to find out that it has been successfully done for decades absolutely floored me.

If we can do it, especially for things as important as cybersecurity or _keeping a plane’s autopilot from crashing _, why don’t we?

From the Airbus paper:

“Some theorem proving techniques have been successfully introduced to verify limited software subsets. However, to prove properties of complete real-size programs with these techniques does not seem to be within the reach of software engineers yet.”

– Delmas & Souyris, Astrée: from Research to Industry (2007)

Small Pickles & Autopilot

I am still a part of the world that has shifted most in the past 18 months, and finding my footing during this shift is still a daily effort. I sympathize with mathematicians, being in a space that is very sensitive to the seemingly endless wave of news that, even three years ago, would’ve been considered once-a-decade events.

Past the immediate anxiety for my own well-being, though, I am excited to see what new capabilities can be done if we, as human beings, broaden our horizons and find new ways to solve problems with new tools and a willingness to keep learning.

Footnotes

For the life of me, I do not understand why software developers name things like this, or where they get it from. I will never forgive the Kubernetes team, either for the name itself, or for k8s as the abbreviation. ↩
These examples are taken directly from the Cucumber docs, which are among some of the most helpful docs I have ever read. ↩

Math is Dead, and Pickles are Small was first published on Chaotic Good Computing, where you can reply to it on Bluesky or from your own site.

Chipotleware

Spencer Elkington — Wed, 30 Sep 2026 00:00:00 +0000

This is a side note that I carved out of Agronomic Software Development. I’m a stream-of-consciousness writer, and this… ended up being a slightly longer stream. It was cut from the portion about software factories.

What is a software engineer, anyway?

I’ve been trying to remember where exactly I read this sentiment about how ridiculous software engineering hiring is¹, but it has stuck in my head for years:

The technical interview for a junior software engineering position is like being asked to prepare a Michelin star meal for your interview at Chipotle

At a large company, a junior engineering position truly is line-worker style. The general process is:

You get a ticket to fix a bug
You investigate the bug; you write a fix
You submit a pull request
You get a ticket to fix a bug…

Don’t get me wrong: I’m not trying to understate how much intellectual work can go into charting a path between the problem and the solution. I’m also not here to claim that it’s easy, especially when you don’t have an effective manager to simplify that “get a ticket” bit. Being a junior engineer without an effective manager is like being expected to roll a burrito for a customer while the kitchen is burning behind you, none of the kitchenware is clean, the card reader isn’t working, and the customer is telling you that they never would’ve had to deal with this mediocrity when they were VP of Vice Presidents at Metabook in the 2010s.

What I am claiming, though, is that the factory-style ticket assembly line is hardly an act of intellectual or creative expression. It isn’t the brooding dorm-room hacking of The Social Network or the rag-tag star coder faux-prestige of Silicon Valley. It’s not a work of art or a stroke of genius; it’s a ping at 4:45pm on a Thursday:

Hey, could you take another look at my PR? I changed those variable names, so I need a new review.

That burrito analog isn’t necessarily the case, though. I’ve only worked at a couple of those factory line-style positions in my life; the rest of them have been at companies that are just a little bit too small that are a little bit on fire all of the time. Those are the types of jobs where everything that comes at you down the pipeline is the highest possible priority, so you get to choose which dumpster fire looks like the most fun that day, and nobody above you will look too closely at how you did it because they’re focused on the other dumpsters on fire in front of them.

They come with a tradeoff – at the burrito job, there’s clean metrics that show how much work you’ve done, and whether you’ve earned your lot that month. At the dumpster fire job, after awhile, you can either stretch yourself too thin trying to put out too many fires or let the fires burn; either way, that little bit of freedom comes at a cost to either your job security or satisfaction.

Either way, as a junior engineer, you’re in a position where you’d like security, satisfaction, and sanity, and all three seem out of reach.

Footnotes

The implosion of Arc Browser has really put a dent in my bookmark-and-recall game. ↩

Chipotleware was first published on Chaotic Good Computing, where you can reply to it on Bluesky or from your own site.

Software Gardening

Spencer Elkington — Wed, 30 Sep 2026 00:00:00 +0000

The start of every year is a magical time. So many possibilities, so much excitement about what the new year might hold. At my day job, my team was coming off the success of rolling out a large product release in 2024, so our slates really were clean heading into 2025. That’s when a question came my way: a question that started with an ominous phrase:

How would you feel about…

A little intonation on the word “feel” is always a canary out of the coal mine. It’s the confession that, even though this is the first time you have heard the question, it’s certainly not the first time the question’s been asked. The only difference is that, this time, it’s yours to answer. In this case, it was:

You’ve played around with using LLMs for software development. We have this product that really needs an update, but we don’t have the time or expertise to work on it.

How would you feel about picking it up and using LLMs to speed up development?

The stack was entirely out of my wheelhouse. It was a mission-critical piece of Visual DB2K software that we had some of the source code for, but not enough to build from. The only complete copy we had was an .exe file that we couldn’t get running on any computer or VM except the one it was initially installed on, delicately transferred from one version of Windows to the next, over the course of the last 25 years. The source code we had on-hand was a series of progressive patches made over that period to keep the thing afloat until the only maintainer – a long-term contractor – could do… something to upgrade it to a modern stack.

That contractor had died a few years prior, so somebody became me.

Hostage No Longer

In March of 2018, “agent” wasn’t quite a thing yet. It’s easy to forget just how fast agentic development has moved. Claude Code was still a closed research preview using 3.7 Sonnet – hell, Anthropic wasn’t even a major player. To the extent that developers were using AI, it was largely:

Enhanced autocomplete;
Copy-and-pasting snippets back and forth out of ChatGPT; or
if you were on the cutting edge, using a harness like Cline directly in your IDE.

That said, given the timeline I was given, how little I had to work from, and how out-of-water I was on the stack (db2k was released when I was about 19 months old, and superseded by dBase PLUS when I was 3), the name of the game was to leverage whatever I could to dig out of the hole we were in. I saw the role of LLMs go from content indexing and vectorization, into light “summarize these files” Markdown generation, into full-fledged code writing over the course of maybe 6 months. An important inflection point happened about 8 months after I got the question: most of the code on the project had been written by LLMs.

By the time true agent-based development approached many of my peers’ radars, I’d been trying to keep ahead on how development might look at this point we’re at today. The first wave was the purely technical approach: my LLM primer presentation was built out of understanding Anthropic’s first wave of agentic documentation. “How to Run Your Own Hostage Negotiation” came once agents got up to the skill that you might see from, say, a very green software development intern and the vibe shifted from “how do these work?” to “will they replace us?”.

When I wrote the primer, I intentionally didn’t fill in the last section. It posed a question that, at that point, would’ve been sheer conjecture to try and answer at the time. However, I think it is time to give it a good, college try:

Software as a Factory

What I’m about to say will be brutally obvious to many, but easily forgotten by my generation of software engineers: there was a time when computers were a far cry from general-purpose or universally accessible. The ENIAC’s invention in 1945 was the first time any computer could run program s (plural), but swapping the program meant rewiring the thing, and it was hardly anything you could fit in your garage, nevermind your desktop. The landscape stayed that way until home computers became a conceivable idea in the 70s. At that point, I’d say that software was an artisan good : developed in-house, for specific use cases. Hell, the earliest reference to any general operating system I could find was with IBM’s OS/360, released in 1964.

When I say artisan, I mean it in the most literal sense. Imagine digital homesteading: if you needed a program, you’d better be ready to write it yourself. This was a period of time when people were sharing BASIC games in the back of magazine distributions. If you wanted to play the game, you had to type the physical printed text into your terminal and run it yourself.

Once high demand for computer hardware came, high demand for computer software came hand-in-hand. Like any other market, increased supply must follow, and artisan production of anything is fundamentally incompatible with high supply of it. Artisan production of physical goods was superseded by the factories of the Industrial Revolution, so you might imagine some kind of software factory as the replacement to artisan development. Software isn’t car axles or pinheads, though – so what would a software factory even look like?

This is about the time that papers like Programming as Theory Building start coming into play: engineers that aren’t thinking about software in terms of data structures and algorithms, but in terms of how ideas progressively become runnable software. We do also get the traditional management structure that you might see at a factory floor: line workers, managers, and executives:

This is 3-layer structure would put a company around Phase 2 in their growth – it’s no longer a handful of executives directly doing work, and there are enough disparate pieces or initiatives to warrant multiple teams. It is no longer artisan ; it’s now the start of a factory layout:

Executives, who have ideas about their product, its position in the market, and how it could sell better to users
Managers, who are responsible for coordinating work in their specific domain; for example, frontend applications or backend infrastructure.
Engineers, whose work is coordinated by the managers and move towards implementing the ideas.

At this point, the concerns of software engineering and production engineering start to collide. Schools of thought like Waterfall and Lean/Agile start to come into play, and project boards like GitHub Projects, Jira, etc. become staples across the company. The goal is simple:

Executives express their ideas
Managers plan out how to express those ideas as tickets, and plan out how to delegate them out
Engineers pull tickets, complete them, and merge them into the product.

Rinse, repeat. Even at companies that claim to not have hierarchies like this, you’ll still find this operating structure somewhere in the core of every modern software factory.

And then…

Claude Cometh

I’m going to try my best to correctly express this opinion:

LLMs are better than humans at writing code.

I expressed this same sentiment nearly a year ago in Hostage Negotiations, and they certainly haven’t gotten worse in that time. I’m drawing the boundary, here, at writing code , and writing code ≠ software engineering. I won’t re-hash that in this post: if you are interested, my thoughts on Programming as Theory Building cover that ground already.

The fact that even other engineers seem to miss that distinction, though, means that the actual jobs are at some risk: even if the act of software engineering isn’t automated (and probably not going to be anytime soon), what the job actually looks like is dramatically different than it was even a year ago.

The technology has moved incredibly fast, and I feel that many at the executive and management layers are uncertain of how to react. The discourse around the whole ordeal is confusing and polarized; LinkedIn is a perpetual, inhospitable hellscape of horrible takes.

To try and get a feel for the situation, let’s game out some org chart options.

Do Nothing

When faced with a complicated problem, it’s always best to take a deep breathe and ask if the best reaction is no reaction. It’s a fair pause to take; the tech space is famously hyperreactive to The Next Big Thing. Let us not forget; just five years ago, Mark Zuckerberg rebranded Facebook into “Meta” in the hopes of pivoting humanity into the Matrix, only to divert billions into a VR fad that lasted all of two years – billions that could’ve been spent refining their core business model of advertising eating disorders to teenagers.

However, LLMs have proven their worth (certainly more worth than VR ever did).

This interactive content can only be viewed on the live site.

The genie’s out of the bottle, then. I use the term “genie” deliberately: they’re infamous for giving you what you wish for, and wreaking absolute havoc if you’re not careful. Doing nothing, in this case, is a good way to let your capacity to do more work completely outpace your ability to organize and maintain that work.

The proliferation of the technology has hardly been a quiet revolution. I’m sure that, if you were to think about it, or go online anywhere, “do nothing” is a difficult option to justify. I’d recommend ruling it out. So, what else can be done?

Fire the Eggheads

It’s an option, isn’t it? I’ll try to put my personal bias aside, here, and entertain the option in good faith (despite my desire to continue earning an income).

Laying off engineers seems like a reasonable solution. After all, LLMs are extraordinarily good at doing almost the same thing as them. They write code pretty damn well, and have far less reservations about writing something hacky if it’s needed ASAP. I wouldn’t say that their quality is that of a senior engineer, but LLMs have inarguably passed the point point where they could beat out an intern.

If LLMs can do the engineering, can your managers simply manage LLMs instead, and pick up whatever engineering slack is left over?

I’d caution against this, though, because of a concept that’ll come up a lot in the rest of this post: judgement. Not a Christmas Carol-style judgement of three ghosts and a Dickensian street urchin, but judgement about whether or not the internal mechanisms of a project are going in a good direction or a bad one. Anybody who has ever done a full rewrite of a project knows just how much time a series of bad decisions can cost you in time and resources.

While software development is immune from almost all physical laws, the inexorable increase in entropy hits us hard. Entropy is a term from physics that refers to the amount of “disorder” in a system. Unfortunately, the laws of thermodynamics guarantee that the entropy in the universe tends toward a maximum. When disorder increases in software, we call it “software rot.” Some folks might call it by the more optimistic term, “technical debt,” with the implied notion that they’ll pay it back someday. They probably won’t.

– The Pragmatic Programmer, 2nd Edition (2019)

An important thing to remember about these LLMs is that they don’t live for very long. As of writing, frontier LLMs like Claude Opus 5.5 have a context window of 1 million tokens. However, it’s generally accepted that the first ~150k tokens are where they work at their highest quality. Once you get past that point, quality drops off until you start a new session.

Without diving into the technicals of what “a new session” entails, the lifecycle of an LLM session is effectively:

0 tokens: You have hired a reasonably smart intern who knows literally nothing about your product.
100k tokens : The intern has learned the basics about what your product does and its general structure.
150k tokens : The intern has done a reasonably good job at writing the code you asked for.
250k tokens: The intern is still working pretty well, but has been awake for awhile and is having trouble focusing on a good solution or remembering small details about what you asked them to do.
500k tokens: The intern is starting to trail off and get distracted. They probably need to sleep.
/clear: The intern got too sleepy on the job, so you shot them. This is now their replacement.

Life is beautiful, isn’t it?

Ultimately, what you gain in efficiency with an LLM, you also get a bit of entropy – it’s not one long-lived engineer made of flesh and bone and whatever they had for breakfast that morning: it’s a constant stream of very talented new hires who don’t quite get the bigger picture. You lose the long-term technical thread that is required to keep a product that doesn’t become an unmaintainable nightmare after the first month.

You can write down, in ridiculous detail, everything about your product, its internals, your business motivations, etc., but there’s a level of un-capturable human understanding of the bigger technical picture that a rotating cast of repeatedly-slain interns can’t quite capture.

But hey – we’ve got bloodlust on our minds, so what else could we do?

Fire the Suits

This one seems to be a recent favorite of the largest tech companies: taking an audit of middle managers and asking “…so, what do you do, anyway?” Project managers certainly got some bad PR after a TikTok was deluged with management influencers taking stand-up calls from the sides of resort pools. Shareholders may rejoice at the announcement of those types of layoffs, but what good does it do for the product?

The engineers are basically managers to a bunch of bots, anyway. Couldn’t they – or the LLMs – pick up the management tasks instead?

I’ve seen sentiments swirling around engineering circles, especially on the release of zero-shot classifiers like Jev, that the judgement calls made by PMs for prioritization might be something automatable. I’d, again, lean towards “how can the new tools improve this job” rather than “can this job be replaced.”

For one: those managers are your bridge between executive idealism and vision and the rubber-hits-the-road engineering challenges and limitations. As an engineer, I’ve been in calls with fantastic project managers, where both executives and engineers leave feeling understood, and been in calls with poor (or, god forbid, no project managers) where engineers and executives seem to talk past each other in different languages.

I have also been in environments where no project manager is present, and where engineers are individually harangued by folks all over the company who believe that their specific need is the absolute highest priority, with no cross-channel communication. When everything is the highest priority, nothing is the highest priority, and the actual direction of development is aimless.

Lastly, the project manager is likely the one with the most experience in the products being sold. They’re closest to sales, to marketing, to the actual users who use the thing. When you’re in the code, it is very easy to forget what something looks like from outside the window. It’s grounding to have a human being say “don’t worry about that – it’s not the thing that people will notice”.

We’re quickly running out of bloodlust solutions. The last tier of people to lay off would be the executives, but that seems highly unlikely. We may need to reach for a more peaceful solution. Something old, all-natural, and proven at scale in the modern economy.

Software Gardening

After spending a lot of time trying to find better ways of coexisting with agents, the approach I’ve bumbled my way towards for the past two years has been something akin to gardening. It came up in the Hostage Negotiations post:

The tomato plant/trellis is the analogy I’ve settled on the most — it reminds me of digital gardening. Human beings have figured out how to wrangle things we don’t fully understand for thousands of years, and reading LLM research and model cards can start to feel more like a natural science like biology than something like an applied math paper. We can prod a taught model to check its behavior, but for folks outside of the research side, it falls on us to accept that something we don’t fully understand can still be useful.

What we are responsible for, though, is making sure that this new addition to our lives is handled with care. It’s on us to build systems for handling its use — there’s a long history of intentionally, and irresponsibly, introducing invasive species into our environments to solve one problem only to create a hundred more in its place. This is the distinction I make between engineering and the act of (*vomit*) vibecoding.

A massive amount of humanity’s advances in technology, process, and economics comes from farming and agriculture. In the modern era, farming and food processing is done at an unimaginable scale. There’s millennia of case studies to work from: how can we take something unpredictable, and harness its benefits¹?

Picture, in your mind, a trellis : the wooden scaffolding on which plants can grow vertically.

Across the industry, we all build our apps on stable, thoroughly-vetted libraries that make up the stack we work in. These are sliced into layers: data, business logic, API, and client are all examples of layers on the stack.

A program, in the end, can only be reliable as the weakest link on the stack. It doesn’t matter if you write a Windows program that will never crash, because Windows itself may crash eventually. The most beautiful, stable frontend in the world is still limited if the framework it’s built on is flaky, or if the API it’s hitting goes down. In this model, the stack acts as the trellis: your software can only be as stable as these critical backing pieces.

Your software, though, isn’t just your stack. It’s also how you develop a feature through your stack. Thinking about software as gardening, then, this is the most organic piece: it’s the part that differentiates what you’re creating against what everybody else using the same stack is creating as well.

Here, we illustrate that these features are not always clean shots through the layers. Perhaps they start from similar places, or they intersect along the way. This is one misconception I had early on when learning about vertical slice architecture (VSA): I assumed that layers and slices were a pure a 2D matrix, where two columns (features) could never touch. In the the real world, and in the programs most useful in the real world, are simply more complicated than that.

This is where the scaffolding and the features intersect: they both inform each others’ design. The scaffolding must enforce certain patterns for a feature to properly fit on it and latch on, but should be a good fit for the features being created. The features should do their best to fit the needs of the application, but must utilize the scaffolding to avoid becoming a spaghetti, tangled mess rotting on the ground.

Garden Teams

The agricultural metaphor fits well: as software development teams, we cannot get the benefits of LLMs without knowing how we’ll manage their drawbacks. The biggest drawback is that their quality is hard to guarantee, and that trying to micromanage them into doing exactly what we would do means spending more time watching over their shoulder and dictating to them than we’d otherwise spend doing the task ourselves. If we can learn to manage unpredictability, rather than fight tooth and nail to force conformity, then we can start to get actual benefits to both quality and velocity.

In software gardening, I’d define two primary roles:

Stack Engineering: Reinforcing the layers of the stack so that each is stable in its own right, flexible to the demands of the requested features, and procedurally well-documented.
Feature Engineering: High-level design and specification of the required features, framed in terms of how they must pass through the stack in order to accomplish their goals.

Splitting up the stack this way means that neither engineers nor managers are left out in the cold. Instead, both take on a role that blends management with engineering, but with a focus on specific strengths:

Engineers primarily take on stack engineering. Stack engineering is inherently built on hyper-specialized knowledge into each layer of the stack, and how features of that stack’s technology can be utilized to enforce good behavior from the features that are growing on it. Engineers begin thinking less in terms of “pull a ticket, complete a ticket, make a PR for the ticket” and more on the frameworks used by the product. It’s a reinforcement task: making sure that, for upcoming planned features, each layer of the stack has a clearly and singularly defined path to completion.

Feature engineering, then, caters to both engineers and managers coordinating how LLMs grow features through the stack. The knowledge is broad, rather than deep: they trade deep expertise on how each layer operates under-the-hood for a broad understanding of each layer’s API surface. Their deep understanding is in the product specifications, coordinating work done on features, and maintaining a rapid agile feedback loop for both product and stack improvements.

Both sides take on management responsibilities in the way that they work with each other. The stack engineers must keep up-to-date on the rolling quality of features being developed and triage points of friction: areas where features get cluttered, conflicted, or generally confused. In turn, feature engineering must triage their work based on new capabilities created by the stack engineers, occasionally managing refactors of previous work based on new capabilities of the stack.

Feedforward & Feedback

All of the work managed by humans is ultimately done to make sure that the conditions in which features are “grown” by agents is high-quality. Part of this is rapid iteration of the system.

Think about a houseplant, and understanding what conditions it’d thrive best in: what direction of window should it be facing? What kind of soil is the best for it? What temperature or humidity should the room be at? It will always be a case of monitoring the growth, checking for issues, and reacting accordingly.

When introducing something vaguely organic, like code “grown” by an LLM, the principle is the same. The goal of a software development team is to make sure that what we’re creating is of good quality and completed in a timely manner. This takes the rapid feedback cycle promoted by management frameworks like Agile and applies them one layer up the development abstraction: not just to the code we’re writing, but to the environment that code is being written in.

This requires strong systems for both feedforward and feedback to accomplish²:

Feedforward contains all of the environmental tools available when an agent starts with zero context. It’s the tools available to them, as well as what they can get through those tools. This will change depending on your harness, but think in terms of the scaffolding that’s been built, the quality of previous code, the documentation available, and the quality of the prompts they’re given.
Feedback contains all of the tooling, both deterministic and non-deterministic, that are used to evaluate the quality of an agent contribution. The faster, the better: anything that can be done to rapidly confirm quality gates and evaluate the work done in a timely and inexpensive manner has critical value.

Once quality can be accounted for, the feedforward and feedback loops can, themselves, be iteratively improved on. The miracle of modern agriculture is not the amount of food we grow: it’s the technology we’ve built around something unpredictable to make sure we harness the most benefit, and least harm, from a chaotic process.

The major shift in this framework is that human beings aren’t as involved in the nitty-gritty, line-by-line details of the product code. The product code is what’s being grown, derived from:

The quality of the stack
The accuracy of the specifications; and
The feedforward and feedback loops of development

In my own experience adopting this approach, you get more than just a high-quality product out of the other side. Out of this, your team can generate strong frameworks on which to build future work and a well-defined system for creating other products.

The system isn’t without its drawbacks, though. Because its byproducts are stable framework libraries and a system for developing more products, it doesn’t work well in isolation. If your team is responsible for just a single product or service, I wouldn’t recommend this; the shift in mindset and responsibilities likely isn’t worth the benefit you’d get out of the byproducts. However, if your team is responsible for many products, where libraries can be re-used elsewhere and the garden loop can be repurposed for other initiatives, I highly recommend giving this approach a try.

If you want to give this a try, I’d recommend seeding the process on a backlog project; something that your team has wanted, or needed, to do for awhile but never had the prior time, resources, or direct working knowledge to pull. Once you start to develop a feedback loop and stack libraries, those are perfect candidates to cross-pollinate the process upwards to other products you’re working on.

In the end, you’ll get what many other engineering teams are scrambling for at the moment: a system where LLMs have a clearly defined and managed role in your development process, and the people on your team can focus in on the judgements and vision that actually move you towards a better output.

Footnotes

The irony is not lost on me that both require massive amounts of water and land, although a square mile of farmland is probably of more intrinsic value than a square mile of data center. ↩
I cannot take credit for the concepts of “feedforward” and “feedback” – all credit goes to Birgitta Böckeler, from her post “Harness engineering for coding agent users” ↩

Software Gardening was first published on Chaotic Good Computing, where you can reply to it on Bluesky or from your own site.

Working with Valves: Understanding the Structure of "Flat" Organizations

Spencer Elkington — Thu, 26 Mar 2026 00:00:00 +0000

It’s seems a bit out of left field to annotate a random company’s employee handbook. I’m not an employee at Valve — never have been, likely never will be — but among engineers, Valve has a somewhat mythic status as a company with an unorthodox approach to management: just… don’t manage.

This annotation relates specifically to Evolutions and Revolutions as Organizations Grow, which pertains to general management structures across companies. The entire field of management research is an investigation into how best to coordinate human efforts and enterprise, and there are many solutions across that spectrum that work well. Take a look at two successful companies, and you’d certainly find differences in the structure of their org charts — sometimes subtle, sometimes not, but differences nonetheless.

However, it’s obvious that Valve’s solution to management (“manage yourselves!”) is novel on the surface, to say the least. I’ve seen it hailed in a few places, now, of the potential for decentralized teams. It’s no secret that tech companies have spent the last few years “flattening” their hierarchies, usually by gutting management roles.

Reading through the handbook, though, you see that Valve’s solution is not the colloquial “no managers!”

Are you hoping you can flatten your organizational hierarchy for efficiency by shitcanning the entire middle management of your company, close your laptop, and come back tomorrow to an efficient paradise?

You’ve got another thing coming.

Source document: media.steampowered.com

This interactive content can only be viewed on the live site.

Working with Valves: Understanding the Structure of "Flat" Organizations was first published on Chaotic Good Computing, where you can reply to it on Bluesky or from your own site.

Agentic Programming as Theory Building

Spencer Elkington — Thu, 12 Feb 2026 00:00:00 +0000

If you ever need an endorsement of trying to chase citations all the way back to their sources, look no further! I recently read a post by Steve Krouse, Vibe code is legacy code, where it mentions the refrain:

Programming is fundamentally theory building,

That one has been rattling around my brain for weeks, now. My industry is still in a massive shake-up brought on by how good LLM agents have gotten at producing code. Needless to say, there are a lot of opinions on LLM usage. Trying to negotiate out my own relationship with the technology and overcome a growing pit in my stomach that represents the question "Am I cooked?" is something I'm actively working on.

Steve Krouse's quote digs into this citation — a paper by Peter Naur, who was influential in the earliest years of computer science as a forming discipline, and was married to Christiane Floyd, who was heavily involved in the production of the first coding IDEs.

(I did just attach his name to the term "computer science", but it is worth noting that he didn't like that term. He preferred — and coined — the term "datalogy", which still sticks as the term for the discipline in his native Denmark.)

Lemme level with ya — this is going to get real heady, real fast. As background, Naur rejected the idea that computer science was itself a direct descendant from raw mathematics. This paper builds on that idea, and talks about the interface between actual programmatic processes/development and the human beings who create them. Many of the citations on this paper are philosophical essays and excerpts — one of them seeks to distinguish human thought from hydrogen atoms.

Stick around, though! If you share my anxiety about the role of humans in a world where LLMs have pretty much beaten us out in the act of writing code, this paper may be as cathartic for you as it has been for myself.

This is an inline annotated PDF. You can see the annotations at the live site

A Pattern Language, and a Beautiful Day in the Neighborhood

Spencer Elkington — Sun, 01 Feb 2026 00:00:00 +0000

The world is too complicated a place to be understood, wholly, exactly how it is. With each passing day, it becomes more complicated. Not even a century ago, the general term “scientist” could be somebody’s wholesale job title; a person who in general, does science. The amount that we know has grown exponentially since then. In any given field, even among broad categories of science — biology, computing, chemistry, economics — nobody could ever hope to fully understand even a subsection of how the world works. Broad strokes, rules-of-thumb, and statements with many, many asterisks are required to even begin to understand the many forces that govern our lives.

These are patterns, and they’re our greatest tool in comprehending the basics of the incomprehensible.

Patterns are prevalent in my main interest and occupation of software engineering. Software is made up of lines of code in the same way that a building is made up of bricks and beams. They are the basic building materials, but random scatterings of code make as successful a piece of software as a random scattering of bricks would make a home. To make anything of use, you need to step back and see the bricks for what they build, or code for what process it defines; we use the phrase design patterns to describe the larger structures we build.

For a long time, I had assumed that “design patterns” was a term coined by software engineers, most famously in the 1990 book Design Patterns: Elements of Reusable Object-Oriented Software — even if they did leverage terms from other fields. Especially in object-oriented programming, many creational and structural patterns actually do borrow, directly from physical spaces¹. Factories, builders, bridges, facades — they may deal with data and information instead of physical structures, but the patterns’ purposes do match fairly well to their real-world analogs. Thinking in design patterns is, I think, what differentiates the role of software development — laying down the bricks of code — from software architecture — using patterns and theory to lay out the superstructures of the software.

Patterns are such an important cornerstone of computing that it had never even crossed my mind that we yoinked it from somebody else.

A Pattern Language — of another field

A few years ago, I stumbled on the 1977 urban planning and architecture reference manual A Pattern Language while researching more about design patterns for software. What I stumbled into, though, was a bit of hubris: software engineers didn’t invent design patterns! We could hardly be credited for coming up with the term, never mind the concept. Other fields had been using design patterns decades before the phrase ever got close to computing.

February 2nd, 2026 — while editing this note, I (re?)discovered that A Pattern Language isn’t just an earlier use of the term “design patterns” — it’s apparently the original source. I’ve had the book floating around my life for three years now, so I can’t recall if going back to the root was the result of an intentional investigation, or just dumb luck.

(It was probably dumb luck.)

A Pattern Language is, specifically, a series of patterns related to the physical development of structures and communities — homes, neighborhoods, towns, cities — using design patterns that can begin to describe the organic way we, human beings, have decided to organize ourselves over the course of the last few thousand years.

The text is broken into a few volumes:

Volume 1: The Timeless Way of Building
Volume 2: A Pattern Language
Volume 3: The Oregon Experiment

Volumes 1 and 2 are very closely related. A Pattern Language even states — in the first sentence, of the first paragraph, of the first page — that itself and The Timeless Way of Building “… are two halves of a single work.” I would describe the system as:

This interactive content can only be viewed on the live site.

This separation between the language and the instructions is not far off, conceptually, from how much software development is divvied up. We have the language — the way we express what we’re creating; the instructions — how those expressions are mechanically laid out; and the application — the way the language and instructions interact to create the final product:

This interactive content can only be viewed on the live site.

Once again, software engineering co-opting concepts that existed long before we did. Classic!

Superstructures and substructures

Obviously, where A Pattern Language differs is that the patterns here, while varied in how abstract they are, never stray too far from the physical world. Some are very direct, neighboring literal construction practices, such as:

Pattern 191: The Shape of Indoor Space;
Pattern 200: Open Shelves; or
Pattern 251: Different Chairs.

I will call these sub structure patterns — patterns dealing with details smaller than a single home, shop, or other structure.

As we move forward in the pattern listing, concepts begin to abstract away and describe super structures — full streets, towns, neighborhoods, or cities. They rise above the purely physical and describe less tactile details, such as:

Pattern 12: Communities of 7,000;
Pattern 10: Magic of the City; and
Pattern 8: Mosaic of Subcultures

The most abstract — Pattern 1 , fittingly — is Independent Regions: a case that independent regions should be… well, independent.

That is all to say: A Pattern Language seeks to cover a wide-ranging set of patterns to encapsulate all levels of structure that human beings could possibly dwell in. There are some patterns I agree with more than others. The amount of effort, however, that the authors have put into 253 separate rules seeking to cover the entirety of human habitat while being generalizable enough to cover many cultures? It’s herculean.

Earth: The World’s Biggest Graph

Although my initial interest in A Pattern Language started with software design pattern research, reading the patterns has bubbled up a different interest: the representation of our world, and the many communities that make it up, as graphs.

When I say graphs, I don’t mean a line graph on an X-Y plot — I mean it in the most abstract sense — dots that represent things, and lines that connect those things. This is the foundation of graph theory. Maps as graphs feels like an apt return to form — the study of graph theory itself formed in 1736 when Leonhard Euler (of the number _ e _), solved a puzzle about seven bridges in the city of Königsberg:

Maps are simply graphs of the real world. In fact, whenever a device shows you a map, gives you directions, it’s not seeing left turns and right turns, streets and buildings — it’s seeing nodes on a graph, and the edges that connect them.

My hope with A Pattern Language is to learn more about the relationship between nodes on the graph — a language not just to better understand how our towns, cities, and communities are set up, but to more richly analyze the relationships between super- and sub-structures on the graphs we use to describe them.

Understanding The Neighborhood

This ultimately lends itself to another project that I’ve been hoping to work on for a very long time — The Neighborhood. What form this project will take is, to put it mildly, a bit up-in-the-air; it will really depend on how well I can analyze maps as graphs. The goal, though, is simple:

We have so much data about the world around us. We’ve learned that it’s, all things considered, fairly straightforward to simply collect everything, always, all the time:

However, you and I don’t see our communities as nodes and edges. We see them as alive — they’re the places we rest, where we work, the friends in our lives, our connection to others. The literal places and the ways they’re connected are all in the raw data, but their meaning — the semantics of data, to each of us — is a superstructure. The deeper connections are not the lines on the graph — they’re somewhere hidden between them.

My hope is to understand and apply the language to create a system that can process the raw data and boil it down to something smaller, but representative. Given an area of data, The Neighborhood’s first goal is to understand the abstract, conceptual relationships and generate a toy model of the area — a simpler graph that maintains complex structures and relationships, but is simple enough that it could be printed on one of those old-school Playskool Village rugs for kids.

I have many amorphous thoughts on what form of a game The Neighborhood will take — thoughts that I’ll spare you from, until they take some more concrete, actionable and playable form — but I consider the graphical analysis of real map data to be at the core of the concept.

How the `#annotations/a-pattern-language` project will work.

Unfortunately, I won’t be able to truly annotate the work in the same way I made the public annotations for College Admissions and the Stability of Marriage or The LLMs Starter. I lack, at the current time, a good way to automatically trim PDF or EPUB texts into preselected chapters. Additionally, the online source from Cornell is, unfortunately, missing quite a bit of the text (only 313 of the full 1169-page text — a bit over 25%).

Nonetheless, I’ll be annotating my physical copy of the book and moving those annotations, piecemeal, into this blog under the pattern-language tag. I’ve already pre-generated 255 notes, one for each pattern (as well as an intro and conclusion note). The reason for pre-generating them is simple: the patterns form a graph, themselves. Each pattern references other patterns. This is most clear in the first portions of each pattern entry. For example, the introduction to Pattern 62: High Places:

… according to Four Story Limit (21), most roofs in the community are no higher than four stories, about 40 or 50 feet. However, it is very important that this height limit be punctuated, just occasionally, by higher buildings which have special functions. They can help the character of the Small Public Squares (61) and Holy Ground (66); they can give particular identity to their communities, provided that they do not occur more frequently than one in each Community of 7,000 (12).

The amount of explicit links between patterns is practically begging to be graphed out like the other pages on this site. To better learn this information for understanding the graphs formed by maps of the world, I also want to understand the graph of these patterns’ connections to one another.

Process

As I complete annotations for patterns within A Pattern Language, I’ll do two things:

I will update the date of the post to reflect the day I wrote the annotation; and
I will move the note from my private vault to my public one.

This is a very solid piece of work, and I don’t anticipate that anything from the completed annotations would spoil any additional work on The Neighborhood. The book itself is fantastic — if any note inspires anybody to pick up a paper copy of the text, it’d have been well worth my time.

Pacing

With 253 patterns to annotate, this will doubtless be a long-running project (the scope has already annihilated the organization of my site graph). Even at a very generous estimated pace averaging one pattern a day, that’d make for an completion date eight months in the future — October of this year. While I have every intention, as of writing this, to read back through the text and have at least some annotation for each section (if only just to complete the link connections between a pattern and its neighbors), I will need to triage the pacing a bit.

Above, I define the terms substructure to mean “structures smaller than a whole building” and superstructure to mean “structures larger than a whole building”. I’ve created two subtags — pattern-language/sub and pattern-language/super — to sort patterns into these two categories. I’ll be prioritizing the #super patterns first, as they relate more to what I’d like to get out of this reading. The book does a preliminary grouping into Towns, Buildings, and Construction:

Towns: Independent Regions (01) to Sleeping in Public (94)
Buildings: Building Complexes (95) to Secret Places (204)
Construction: Structure Follows Social Spaces (205) to Things From Your Life (253)

For now, I’ve designated anything in Towns to superstructure patterns, and anything from Buildings and Construction to substructure patterns. However, I can already see that these categories will be fluid, with some current superstructure patterns being better suited to substructures (e.g. Bus Stops (92)) or some current substructures being better suited as superstructures (e.g. Paths and Goals (120)). Those re-categorizations will track here with time, but don’t expect my distribution or classification to be as clean-cut as the book itself makes them out to be.

Finally: the text itself groups patterns into broader categories — for example, a transit category composed of the rules between Looped Local Roads (49) and Children in the City (57). I may do larger composite notes for these groups, especially as they relate to the graph introspection goals of The Neighborhood.

Conclusion

This will certainly be the largest notes collection on this site thus far. A Pattern Language is certainly a worthy candidate of it. If you are interested in urban design, civil engineering, or public policy, I would highly recommend purchasing a copy of the text yourself and giving it a read. Its authors — Christopher Alexander, Sara Ishikawa, Murray Silverstein, with Max Jacobson, Ingrid Fiksdahl-King, and Shlomo Angel — deserve credit for the work they put into researching, organizing, and publishing these thoughts.

Footnotes

This melts down a bit more when you get into functional programming. If I had to give a TL;DR: software exists in a space between pure information and the real world. Object-oriented programming takes the angle of going from physical concepts into information space, and functional programming takes the angle of going from pure math into the information space. Functional programming does also have design patterns, but they are far more derived from mathematical concepts than object-oriented programming’s physical analogs. ↩

A Pattern Language, and a Beautiful Day in the Neighborhood was first published on Chaotic Good Computing, where you can reply to it on Bluesky or from your own site.

The Advantages of Advantage: Intro to Probability Convolutions

Spencer Elkington — Mon, 19 Jan 2026 00:00:00 +0000

Statistics is a hell of a drug — like a higher-than-healthy dose of Benadryl, it may cause hallucinations, delirium, sleep. It becomes a bit more palatable, though, when it sneaks its way into the rules of a game. It can give a bit of zest and unpredictability to board games, card games, and the narrative ups and downs of tabletop RPGs.

Players and gamemasters of Dungeons and Dragons knows that it can be tricky, but rewarding, to tune the odds of skill checks and random encounters — either to provide a satisfying outcome for the players you DM for, or to rig the odds minmaxing characters for successful outcomes. Things get real fun when you start mixing dice together. Advantage, _dis_advantage, or the thrill of rolling out eight or nine dice on a damage roll — it raises the unpredictability, but can also get tricky to calculate out the odds.

If you’d like to mess around with the dice roll widget, you can find a copy and how-to at its dedicated page

Single Dice: No Convolution

It’s not too bad to roll a single dice. In a fair die, where each side has equal odds of coming up on top, the probabilities don’t get too complicated. Take, for example, a simple six-sided die (a d6):

Roll	1	2	3	4	5	6
Chance	1 in 6	1 in 6	1 in 6	1 in 6	1 in 6	1 in 6
Percent	16%	16%	16%	16%	16%	16%

Not too bad, right? It’s simple enough to do all of the math in your head. It can be subdivided easily — 3 or less and 4 or more each cover half the possible outcomes, so each has a 50/50 shot. If you wanted to, you could go as far as to graph out the odds, however boring and flat the graph would be:

This interactive content can only be viewed on the live site.

What happens, though, when you need to roll two six-sided dice and add the results? Calculating the odds becomes a bit trickier, but it’s not anything that can’t be drawn out. By placing the outcomes on a grid and adding them together, a pattern emerges:

		1st `d6`
		1	2	3	4	5	6
2nd `d6`	+ 1	2	3	4	5	6	7
	+ 2	3	4	5	6	7	8
	+ 3	4	5	6	7	8	9
	+ 4	5	6	7	8	9	10
	+ 5	6	7	8	9	10	11
	+ 6	7	8	9	10	11	12

Outcome	Odds	~Chance
2, 12	1 in 36	3%
3, 11	2 in 36	6%
4, 10	3 in 36	8%
5, 9	4 in 36	11%
6, 8	5 in 36	14%
7	6 in 36	17%

We can see, here, that the sums stay the same through the diagonals of the grid. With seven sitting on the longest diagonal, it means that rolling two six-sided dice (2d6) has the highest odds at roughly 17%. Adding that with the odds of rolling a 6 or an 8, getting 7-ish comes in ~45% odds. That’s the reason why, in standard versions of Monopoly, the general advice is to buy the orange set of properties if you have the chance. With folks rolling their way out of jail, there’s a hotspot of probability 6-8 spaces away — smack dab in that neighborhood, with the Community Chest as an island of socialist reprieve.

I think that’s where statistics can get weird in people’s heads. The inclination is that adding two flat things together should give you another flat thing, but the way it spits out a curve feels off. That’s why taking the problem and putting it out on a grid can help — it helps work out why the numbers come out that way.

This interactive content can only be viewed on the live site.

In probability and statistics, that idea of combining the two random outputs is called a convolution. There are certainly more intense definitions for the term, but at its root, it all comes back to that idea of taking a few possibilities and doing the same bit of math, again and again.

Working Out Advantage

In playing D&D, it’s not uncommon to roll a dice at advantage : you roll two dice, and have the good luck of getting to take the higher number and ignoring the lower one. It’s a nice boon — outweighed by the occasional dis advantage, where you roll the same two dice but keep only the lower one — and can feel like a massive improvement wherever you can get it.

I’ve heard, in the past, that getting to roll a twenty-sided die (d20) at advantage is roughly equal to getting +5 on a roll. When you have to think quickly about it, that’s not a bad rule-of-thumb to go with. However, it can’t be exactly like that. After all, no matter how many pure d20 you roll, you’ll never come out with a natural 25.

Looking at the actual odds, though, this ends up being another weird curve. Twenty sides is a bit much — but what does rolling a d6 at advantage (adv(d6)) look like?

Performing the convolution, we can just take the higher of the two dice rolls:

A/B	1	2	3	4	5	6
1	1	2	3	4	5	6
2	2	2	3	4	5	6
3	3	3	3	4	5	6
4	4	4	4	4	5	6
5	5	5	5	5	5	6
6	6	6	6	6	6	6

Outcome	Odds	Chance
1	1 in 36	3%
2	3 in 36	8%
3	5 in 36	14%
4	7 in 36	19%
5	9 in 36	25%
6	11 in 36	31%

This interactive content can only be viewed on the live site.

This shows us the clear benefits to advantage. On the high end, we’ve doubled the odds of getting a six out of our single d6, and see that there’s a general upward curve to the odds of numbers on the higher end of the scale.

Bringing it back, then, to the d20 — what is the difference between d20 + 5 and adv(d20)?

This interactive content can only be viewed on the live site.

This interactive content can only be viewed on the live site.

It’s that slight curve towards the upper end at the spectrum that makes the difference. It makes sense that +5 became the shorthand, since that’s roughly the difference in the median roll (although +4 would be a bit more accurate, lining up the medians almost-perfectly). If you’re worried about rolling a 20 or above, +5 is very generous, giving you almost three times the probability. In the D&D sense, then, mechanics like proficiency or mastery may give you more bang for your buck (or XP) than, say, the chance to roll advantage more often.

Odds at Odds

These calculations can be incredibly helpful when randomness stacks on randomness, and especially when the choices you make in a game depend on the distributions of outcomes. In the last year, I’ve gotten into the game Magic: The Gathering to an extent that… I wouldn’t call it fiscally irresponsible, but I certainly won’t call myself a titan of finance, either.

The deckbuilding aspect of the game is one of the greatest parts. Recently, to really shake things up, I’ve been building a wildly fun deck with Mr. House, President and CEO as the commander.

The card is phrased in a way that assumes you’re rolling six-sided die, but in a real “the house always wins” mentality, these odds can also apply to other dice — including our beloved d20.

There’s plenty of cards in Magic that allow you to roll dice to determine the outcome, but I can only fit 100 cards in a Commander deck. The hard part becomes: which to put in? Which to take out? If my goal is to roll higher than 6 as often as possible, is it better to keep a card that rolls 1d20, or a card that rolls 2d12? How many cards that grant advantage would it take to make a d6 as valuable as a d20?

The 2d12 is a bit more complicated than these widgets handle, since we have to take into account the chance of getting to roll higher than 6 with a single card, but it ends up being:

P(no rolls ≥ 6): 25%

P(1 roll ≥ 6): 50%

P(2 rolls ≥ 6): 25%

Some of the questions require different computation, but we can at least compare values. These types of visualizations can show the world of difference between the chance to roll a d6 and a d20. Aiming for a 6 or higher, the d20 is 4.5x as likely to net the result than a d6 (75% vs 16%).

This interactive content can only be viewed on the live site.

This interactive content can only be viewed on the live site.

Funnily enough, the target number does matter here — while the adv_8(d6) has roughly the same odds for rolling a 6, it actually has higher odds of rolling a 4 than the d20. If my goal was to maximize robots, it wouldn’t be as bad — it’s the goal of “roll as high as possible, as often as possible” that changes the game. Not that it matters — there’s only three Commander-legal cards that allow you to roll advantage, and only two fit with Mr. House, so the most I could ever get out of a d6 would be triple advantage — 42% (zeep zorp), not even a 50/50.

This interactive content can only be viewed on the live site.

None of that, though, takes into account the additional effects of the card, or the occasionally insane amount of dice some cards let you roll at once. It also doesn’t take into account the psychological game. Even if the odds aren’t optimal, wouldn’t it still be satisfying to play Clown Car at 15d6?

This interactive content can only be viewed on the live site.

The Advantages of Advantage: Intro to Probability Convolutions was first published on Chaotic Good Computing, where you can reply to it on Bluesky or from your own site.

DEV Community: Spencer Elkington

The Wild Web

The Eras of the Web

Social Networks, not Social Media

IndieWeb, as described by an IndieNewb

The webs of the Web

Footnotes

You can pry my dashes from my cold, dead hands

From The Archives

What is a dash, really?

Sins per unit time

Am I the Baddie?

Sentences, paragraphs, and so on

Footnotes

Math is Dead, and Pickles are Small

What I Learned About Pickles On September 9th, 2026

Pickle-Driven Development

Spec-Driven Development

Why Proofs?

Small Pickles & Autopilot

Footnotes

Chipotleware

What is a software engineer, anyway?

Footnotes

Software Gardening

Hostage No Longer

Software as a Factory

Claude Cometh

Do Nothing

Fire the Eggheads

Fire the Suits

Software Gardening

Garden Teams

Feedforward & Feedback

Footnotes

Working with Valves: Understanding the Structure of "Flat" Organizations

Agentic Programming as Theory Building

A Pattern Language, and a Beautiful Day in the Neighborhood

A Pattern Language — of another field

Superstructures and substructures

Earth: The World’s Biggest Graph

Understanding The Neighborhood

How the #annotations/a-pattern-language project will work.

Process

Pacing

Conclusion

Footnotes

The Advantages of Advantage: Intro to Probability Convolutions

Single Dice: No Convolution

Working Out Advantage

Odds at Odds

How the `#annotations/a-pattern-language` project will work.