Many people have heard about the Dunning-Kruger effect: people don't know what they don't know, so they inaccurately assess their own competence. Everybody puts themselves in the 99th percentile of good drivers, great programmers, or AI users, even though that's statistically impossible. Paradoxically, the truly competent rate themselves much lower. The graph👇 demonstrates the problem. (I just pulled that image off the web—if you know the author, please tell me so that I can credit them.) Dunning-Kruger is driven by social connection. You determine "correct" by talking to the people around you, which, more and more, includes social media. AI amplifies the problem because it doesn't actually know anything, but is trained off the web, so it reports the prevailing (on the internet) belief as correct, whether or not it's actually correct. It's an echo-chamber problem: "If my thinking aligns with the people around me, I must be correct!" I see this problem with terms like TDD, Agile, and MVP, among others. Many (most?) of the people with strong opinions about what those terms mean have never read the work of the people who coined the terms and did the original thinking: Kent Beck's "Test Driven Development: By Example" or his "Extreme Programming Explained" or Ries' "Lean Startup," for example. Mentions of those names are often met with blank stares. (Ironically, that applies to Dunning-Kruger as well—almost nobody's read David Dunning and Justin Kruger's original paper.) Their notion of "right" is defined entirely by their social circle. This is tribal thinking, and attempts to push back on it are almost always met with hostility directed at the outsider. People jump on "the popular belief is what defines the term" bandwagon rather than thinking "hmm, maybe I need to do some research." The tragedy is that the original thinking is lost, and we, as a profession, take a giant step backward as we move blindly towards easily preventable disaster. "Doomed to repeat it," indeed.

We don't spend enough time thinking about strategic planning around the actual cost of using an LLM. The AI companies are effectively borrowing $1,000 for every $1 of revenue. That's clearly not sustainable, and we need to be thinking strategically about how to handle the inevitable adjustment. Of course, the market may treat AI stocks like Crypto—something with zero intrinsic value and a market value determined entirely by speculation. But somebody's got to pay for all those data centers and GPUs eventually, so I doubt things will entirely go that way. The practical problem is that the actual cost of the $2,000/programmer/month some are paying for AI services is $2,000,000/programmer/month. That pays for about 60 programmers/month if I've done the math right. If we were paying full cost for tokens, nobody could afford AI. Humans are more cost-effective. Unless you are betting that we'll move to a Star Trek economy or that LLMs will become sentient and take over the banking system, we need to plan for a price hike. One alternative is to dump all AI providers and use only local models, but if we all did that, the models would rot over time. Somebody's got to pay for building them, and somebody's got to pay for data-center build-outs. That "somebody" could be a government, as is the case with the high-quality Chinese models, but I don't expect to ever see that happening outside of China. It wouldn't surprise me if, as is the case with high-quality and inexpensive electric cars, the US will ban their use to "protect" US companies' inferior products at the consumer's expense. The bottom line is that, as LLM costs ramp up and become less cost-effective when compared to humans, we need to plan for humans to take over more of the coding. If your code is "AI slop" that no programmer has ever looked at, you're in deep trouble. It's not cost-effective for "the AI to fix it" when tokens cost what they're actually worth—loading a context with a vast number of tokens to make a small change will break the bank. One LLM testing another's output (as compared to a static set of automated tests) becomes prohibitively expensive. So, "what's a mother to do?" We need to impose a solid underlying architecture on the LLM—the prompt needs to specify not just what to build, but how to build it. We need to know enough about architecture to know what to ask for. We need small components with impermeable boundaries that break the code into human-manageable chunks with a limited blast radius. We need to rigorously test with an automated test suite and not rely on the LLM to find and fix all problems. (The best way to start down that road is to develop using TDD.) We should be doing this now, even if we're using the LLM to produce 100% of the code. Nontechnical people who imagine they can vibe code their way to a product are in for a world of hurt.