I think there’s a reason devs often like “building the thing that builds the thing” more than “building the thing”: a user-facing product has code that demonstrates how the dev chose to settle a few particular dilemmas, but it doesn’t say much about how the dev thinks about the entire family of similar dilemmas.

There’s something artful and political about reifying a mental model of how you should approach an entire class of problems, more than providing a one-off solution to one specific problem.

This is why I think AI in general is at odds with a large portion of what FOSS is. Building software together as a community isn’t just sharing the burden, it’s occupying a shared moral space, where to be able to navigate within a given project means having to understand the way that project resolves questions that have no single right answer but rather a spectrum of trade-offs.

Importing the default answer from a statistical sample of the internet writ large is like just not having any moral preferences other than efficiency. (And we’re all familiar with an ideology that only values efficiency — it starts with “f” and ends in “ism”.)

So telling tool-oriented devs — who, two years ago, would’ve been debating the subtleties of objects vs closures — to focus on shipping instead of building a new mental model of how to ask meaningful questions about how software is made, at a time when “how software is made” is becoming a more significant question in everyone’s lives… uh, feels myopic, to say the least.