Replies

• 

  MaddieM4MaddieM4

  Aug 14, 2026, 6:58 PM

  So to have any longevity aspirations higher than fly-by-night Ponzi scheming, you need to internalize that the bad days will happen, and that you need to think about them and prepare for them *before* they happen. Ideally with as much lead time as you can muster. A bad day shouldn't be a last day.

  Understanding software becomes REALLY IMPORTANT on a bad day. This is one of the issues with AI, see my thread the other day about the way it sabotages post-mortems, etc. You want to be able to narrow down on the offending code quickly, and easily see why it's doing what it's doing, and how that thing is wrong, even if there are layers and layers of secondary effects meshing poorly with each other as part of the pathology. Not being able to understand a bug that's taking down production is an existential risk. Addressing that up-front isn't optional. That includes the trickiest, most hellish of bugs.

  EDIT: Post-mortem thread here! https://raphus.social/@MaddieM4/117082412027109766

  2/n

  💬 1🔄 0⭐ 7
• 

  MaddieM4MaddieM4

  Aug 14, 2026, 7:04 PM

  Now the double-edged sword of higher-level languages is that they have more going on. Not only more layers (but put a pin in that), you also have *will amplification* as a core reason to use them in the first place.

  `conn = db.connect("psql://some-connection-string")`

  Think about how much work you ask the computer to do in a line like that. That starts with parsing the connection string into some internal structure. There's probably going to be DNS involved, which itself is caches and a UDP stack and TCP fallback... look, I have a character limit, and you can play this out yourself.

  The point is you invoked all that machinery with a pretty concise expression of what you wanted. That simple expression of will was expanded into an enormous fractal of detail, implied asks, on your behalf. That's beautiful and terrifying and productive. High level: You're Welcome! (tm)

  3/n

  💬 1🔄 1⭐ 10
• 

  MaddieM4MaddieM4

  Aug 14, 2026, 7:09 PM

  But the thing about the work being done is, as a shoddy rule of thumb, it's all about equally as likely to have a bug that ruins your day. So a language that allows you to do a high work-to-word ratio is also concentrating risk (which you can see in the type systems of some languages, in how many types of exceptions or errors can come out of a deceptively simple function call).

  Most of that work is not happening within the line of your app, it's on behalf of that line, right? Like, it's kind of a miracle if the bug is in your own code, although we make that miracle happen by collaborating to polish our upstream deps. Still, some percentage of the time, when things break, the only way to make sense of the breakage is to dive... and dive... and dive.

  4/n

  💬 1🔄 0⭐ 4
• 

  MaddieM4MaddieM4

  Aug 14, 2026, 7:20 PM

  And on that kind of highly plausible, arguably inevitable bad day, you are going to have to say something like "yeah, I'm a Pythonista, but I'm going to have to read a bunch of C code today" and grow as a person while under time pressure. I have had to do this... quite a few times in my career. You do this stuff long enough, it's not an anomaly, it's a rite of passage. Like bad days more generally, you have to assume this is coming.

  So, this is something I took for granted with Prone. It is assumed that 90% of the time you don't need to look at the generated C code, but in the remaining 10%, it should be readable, and possible to cross-reference with the Prone source code that was transformed. No minified webpack soup. I have less control over how easy it is to follow the white rabbit one layer lower into assembly, but that's thankfully documented by other people and a transferable skill. Prone also has great FFI because it's transpiled, so if you need more control, you can write specific parts in C.

  5/n

  💬 1🔄 1⭐ 6
• 

  MaddieM4MaddieM4

  Aug 14, 2026, 7:25 PM

  In fact, some of the documentation nudges you to learn these skills proactively, so you can optimize this or that, or better understand how systems work, because saving all your learning for the bad day is another thing that makes bad into worse. If you're not new to diving the layers under good conditions, you won't be totally lost when you have to in panic mode. There is a cultural value being placed intentionally on insulating yourself from nightmare scenarios through the power of learning, and by none of the automation layers writing off human readability.

  So now we finally have to circle back to Elon, and I have to expose you to the cognitohazard of his tweets. Does a man who wants you to atrophy your skills at even reading high-level source code have your best interest at heart?

  6/n

  💬 1🔄 1⭐ 2
• 

  MaddieM4MaddieM4

  Aug 14, 2026, 7:34 PM

  We know by repeated demonstration that LLM vendors prefer for their customers to be addicted. Helpless without the product. A little thing called inelastic demand, which we normally hear about in the context of the broken and extortionate USAmerican health care system. If you can't live without it, you'll pay for it at any price point. For LLMs in particular, which are notoriously expensive in both initial capital outlay and ongoing operational cost (with massive debt to pay back), there really isn't a business model other than taking off your customers' limbs and renting them back at unfathomable subscription prices.

  Within that context, when a man like Elon says you don't need to know how what the source code means anymore, do you take him at his word? Do you turn off your backups and ride lean?

  7/n

  
  💬 1🔄 2⭐ 5
• 

  MaddieM4MaddieM4

  Aug 14, 2026, 7:42 PM

  This goes a little deeper and a shade more offensive, because of the second claim - that AI will generate binaries directly with no source code. This claim is mostly being made for sensational hypewank reasons, like many big claims Elon makes, but I also think he genuinely does not understand why source code is the thing allowing LLMs to cling to life as a technology that doesn't always entirely fuck up.

  Source code makes such great training material because it's full of recorded intent, and can be cross-referenced with documentation that is ALSO full of recorded intent. Sloppers learned early that having the LLM "plan" first (fill the context window with prediction-generated intent material) improves code gen quality.

  Binaries, as generated artifacts, make crappy training material, because the intent is all stripped out - quite aggressively on release builds. They are unconstrained by even the simulation of meaning. That's why nobody does this, even in Slopper Culture.

  8/9

  💬 1🔄 0⭐ 7
• 

  MaddieM4MaddieM4

  Aug 14, 2026, 7:50 PM

  That's why Claude spends your tokens on so many source code comments. It's not for your benefit - heck, if anything, it gives you more power to cancel your plan and pick up where the robot left off. It's because a couple lines of /* reasoning */ before a function makes a better function, when all you have is a predictive hammer and all source code looks like a predictable nail. The extra token spend is a nice side benefit.

  Even within the machine cult, nobody in their right mind would demolish this well-known load-bearing pillar. Which says something about what kind of mind Dr. Ket is in.

  As the cherry on top? I write C and I look at the generated assembly on a regular basis. Not just to keep my skills sharp, but also because I'm often writing code with some assumptions/intent about the instructions I want to see in performance critical code, so I need to be able to form hypotheses and check them, which is a form of literacy. I don't want to be lost when reading `perf` output, so I put in the work!

  9/9

  💬 0🔄 1⭐ 9