Per the article, one of the officers was evidently particularly stupid—he failed police academy once and was disciplined for entering a women's restroom because of crimes he imagined could be happening in there. No one wanted to say "you're too stupid to be making high-stakes judgment calls", so they let him keep trying until he was running into an alleged emergency "with no plan," where he shot an innocent person eight times...and then handcuffed him...

I think actuaries have a way of employing statistical realities that would, in a legislative context, precipitate too much defensiveness and bickering to ever be the basis of a rule. Like I think it was quite a while before neuroscience could fully explain why insurance companies wouldn't cover rental car drivers under 25, instead of 16 or 18.

An insurance company would give departments a reason to say "anyone who has ever failed police academy gets pepper spray and that's it." Departments can decide how to deploy that person.

(Ideally that person wouldn't be a cop at all, but departments will probably always be pushing to hire. This way the argument is between departments and the comparatively highly-informed insurance market, and not voters)

That article proposes that, soon, it will be possible to connect any online identity to its owner's other identities by analyzing stylistic details in their writing. So even niche online communities will have these problems.

I think a lot of these activists were originally fighting gentrification. Then, over time, the gentrifiers won anyway, and now most housing in hcol areas is occupied by wealthy professionals. But the activists never updated their politics (people have a hard time admitting—or, sometimes, realizing—that they lost), and now they advocate policies that shut out the people they originally set out to protect.

With Elon, I think one of his is “build it as cheaply as possible, and then you can afford to only sell to people who are purely excited about the tech.” I don’t know when he learned this (I actually wonder if it was a lesson he learned from Eberhard/Tarpenning at Tesla, who were only selling the roadster to sports car enthusiasts who cared more about 0-60 than fit & finish, or range, or cost, or anything else).

Anyway, my current interpretation is that the pizza guys shouldn’t have sold to pepepizza (or friends and family, probably). I know startups do this all the time, but whenever I’ve seen it, it always seems to turn into a distraction from the Big Idea that is the company’s thesis. Then Big Customer gets hung up on ancillary requirements and Cool Startup doesn’t really get to test their thesis at all. Maybe the key is to stay small, focus on finding people who really care about the new oven tech, and size the company to that market until you’ve solved enough problems to expand to people for whom the cool tech is concern #2 or #3.

This is all pretty vibe-y but I think that might be what the post’s author found the ability to do and is trying to teach? TFA links to this other post in a similar vein: https://commoncog.com/get-numb-get-good/

“Because of AI” indeed.

Are you referring to this part:

> I am not worried, at least in the near term, about AI creating massive, discontinuous returns on investment in the absence of engineering discipline. (Many will try, and it will be entertaining to watch.)

She's saying, "the amazing thing about LLMs isn't that they generate lots of code fast, so don't worry about people using LLMs for that taking over the industry"

She's making two points:

1. Before infra-as-code, people would be afraid to touch parts of production due to lost knowledge about how and why it got that way. Now that we have infra-as-code, you aren't allowed to change infra the old way (ad-hoc changes via dashboard/CLI), even if doing so would be faster and easier. Experienced SREs were required to abandon lots of their old skills with CLIs and dashboards and start working in a completely new way, because the knowledge captured in a terraform repo's commit history is so valuable.

2. In the past, the way code got written was through people making changes in ways that are specific to their current knowledge, the org's current problems, the current users, etc, some or all of which is not written down. Eventually, everyone is afraid to change certain things because they don't know or remember all the considerations that went into them (not just afraid to touch parts of the code, but afraid to delete seemingly-unused features, or migrate the schema, or whatever).

Charity is saying that problem 2 is a hidden/lost-knowledge problem like problem 1, and the amazing thing about LLMs is you have to write down all the knowledge you want them to have, which may lead to a better solution to the "lost knowledge" problem in software development, which would be so valuable that experienced software engineers have to abandon lots of old skills and start using it.

(Not only writing down all the knowledge you want the LLM to have, since they're flaky enough to ignore instructions and miss implications sometimes, but building test suites and tools and so on that adequately guide their solution. This is the "more discipline" she's referring to.)

Yes! I love that someone wrote this down!

This seems so obvious to me now. I often ask LLMs to cite their sources (they do hallucinate from time to time), and they often give me sources that don't say what is claimed. "How would the LLM know not to give this to me?" I wonder. They're trained to explain but not to convince, so they don't know what's convincing, and they should.

I think humans hallucinate at least as much as LLMs—arguments of any complexity are impossible to formulate without leaping at least a bit—but other humans ground us. That's why when people become socially isolated, they join cults or adopt conspiracy theories or the like.

Conversely, "this is convincing to an expert" converges on “this is true" as our collective expertise grows over time. This is the foundation of the scientific method, of progress in all engineering disciplines, etc.

When starting on a new codebase, how do you make yourself into a helpful contributor as quickly as possible? I go straight for the humans and their human docs. What problem was the system originally built to solve? What was the original design, and what were its biggest problems? Who is currently using it? If you know these, reading the code is much easier because you can guess why things were done the way they are.

Also, this blog post has gotten popular: https://blog.gpkb.org/posts/just-send-me-the-prompt/

I think Charity is observing a very old problem and expecting the new technology to lead to a new solution of some kind. I doubt she thinks even the current generation of tools are the end of the AI software development story. She's not saying we'll drop design docs right into Claude code and walk away (design docs aren't complete either, that's why when you're ramping up you also have to talk to people, read old tickets and postmortems, etc.)

What she's observing is that, in prod, people don't like infra where it's hard to tell how it got into is current state, and so infra-as-code is what we do now. She's also observing that, "it's hard to tell how it got into its current state" is the status quo with codebases, which other people have observed going back to "Programming as Theory Building" and earlier. And she's expecting that, analogous to infra, software development will somehow be done with tools focused on making "how the code got into its current state" clearer.

You know, I had a similar experience, but in my case I got an appointment with a psychiatrist afterwards, described the experience in detail, was given a computer test, diagnosed with ADHD, and then given a prescription. (Also in my case, I learned Adderall doesn’t actually feel great or help you if you take too much).

Take care of your kids. The war on drugs is stupid. Etc.

Most of LLM world is kind of anti-linux right now because the most popular LLMs are walled off by these huge companies and hella expensive. At some point, a nerd will realize they could hack together a surprisingly ok homebrew version of what everybody else is using, and do. Then a company realizes that they can build a brand on the anarchist, grassroots vibe of the homebrew thing, and capitalize its development (software development, but also community development, which is brand development for the company). Now, it’s much later, but the open source thing is competitive, and popular for being open-source.

At one point I got interested in why Red Hat handed over tens of millions of dollars in stock to Linus leading up to their IPO, in exchange for…nothing specific. Nominally it was a gift of appreciation, but handing out random gifts is somewhat opposed to maximizing shareholder returns. It’s because Linus controls merges to the Linux kernel and doesn’t have to care about Red Hat, and the board wanted him to care at least a little bit. They were stuck between “people trust our business because it’s built on this populist OS” and “this populist OS is mostly controlled by a guy who doesn’t work for us.” It’s hard to have one without the other.

I’m glad Apple is taking accessibility seriously, and I wish accessibility worked better on Linux, but I don’t think Linux is ever going to make developers “do their homework,” because the community wouldn’t trust a Linux like that. If the author is right, it’ll happen because “AI for the People, Inc.” builds a business on it and sponsors the work.

Well there’s your problem, control needs to go the other way. If you want your app to be AI-enabled, you need to make it easy for AI to control your app. Have you used OpenClaw? It’s awesome!

Most of my posts have aged terribly in the age of AI (especially the ones I didn't finish...so long, extended discussion of how to use a lab notebook when debugging, we hardly knew ye. Claude fixes our bugs now) but one job that engineers still have is the collection and retention of context that AI doesn't have and can't easily get.

What hermit wouldn't love meetings that simultaneously insist that you do more while taking away time to do it, all to avoid adjusting a pollyanna quarterly plan and budget!

Why am I awake at 1:00am, ruining my brain and body, trying to get this feature finished before the end of the week instead of three days later? Ah yes, so that we meet our quarterly OKR, and the next quarter's plan that the EM and PM negotiated without me or our customers isn't disrupted and doesn't need adjustment. That would invite reprimand from the director, and the extra work would be terrible for them, I understand.

I'm reminded of this recent thread in which Heroku left the devs in charge and suddenly features that the author had requested for years got implemented: https://news.ycombinator.com/item?id=47669749

Sometimes the problem is not enough motivation, though I think that if you hire well, that’s rare—the best engineers are intrinsically creative and motivated. Often, lack of progress is due to some other organizational problem—too much toil, unclear priorities, conflict, etc—and just adding pressure until progress happens is the manager equivalent of whining until your sister does your chores for you.

Even if it works, either

1. the team is working around the problem (which the manager doesn’t know about or understand, and isn’t dealing with it) and will eventually get fed up and leave, or

2. someone pushes extra hard and solves the problem for everybody else. Now, that person the de-facto leader, though they’re not recognized, and in fact are often penalized for getting distracted from the paper priorities, since the managers who do this are rarely interested in the mechanics of how their problem was solved. Respect for management is lost, because they don’t understand what’s happening. Eventually everyone gets fed up and leaves.

Managers can’t solve every problem themselves, of course, but the manager needs to understand what the problems are, explicitly set the priority of solving them, and understand and celebrate the solutions when they’re found.