This brings back memories! In 93 I wrote something similar (simpler) for MSDOS, to inspect and extract pieces of binary files, GFV (still downloadable from the Hornet archive somewhere in here https://www.hornet.org/cgi-bin/ha_search.cgi?opt_s=5:Iguana). You could set the stride and show 1/n bytes, so it was relatively easy to find textures from game files and memory dumps of running games.

open one and inspect the two ways to view it, one is horizontal scan, the other is a peano curve which leads to natural square-ish areas.

I can only see the color visualization and the hex view. Maybe I can't see the curve due to lack of WebGL?

Interesting I thought it was a hilbert curve? (I don't know much about either of those though.)

Well at least you're healt... oh wait.

> my theory (which I unfortunately do not have the money to test and prove) is that a codebase designed and implemented by Fable would be substantially better than one that is designed by Fable and implemented by [others]

I don't have proof, only my anecdotal experience: I leave plenty of Fable usage on the table because I do not think its implementations of code have been better to Opus 4.8, not even close. It overengineered, obscured and picked awkward constructs all the time over plain, simple, perfectly clean and performant code patterns. Code was smarter AND worse in the kind of way that a brilliant and overeager recent grad often does. (I know I did)

As a counterpoint (data point of one code base), I had Fable lead development of a complex system recently (an end-to-end insurance claims billing system) as a test project. It blew me away. Opus could not have done the same, given the feedback Fable had to give when Opus would implement individual features.

Granted, I laid out a document with coding practices, architecture, and technical design recommendations to steer it towards good engineering. And it's a domain I know super well, so I could give very nuanced feedback on trade-offs + architecture. If it had been left to its own devices, maybe it would have over-engineered the h*ck out of it.

But the code it produced—and the implementations it guided Opus towards—were excellent.

To be fair, he's mostly saying that this is not a Claude CODE bug, but yeah I was equally shocked.

If by now you're willing to make EM the guardian of your code, nothing I can say would dissuade you.

tl;dr as the sole reply to someone IS a condemnation of what they wrote. tl;dr at the front of your message with a short summary, is an admission that the long version may not be for everyone and there's a core point for quick consumption.

I'd say that sounds about the same for ai;dr. I could see myself posting a prompt like that in front of the generated report.

I have bad stories about classic corporate architects too, but that's far from all there is. The job of a typical Staff / Principal in a modern organization is most often to lead, shepherd and conduct technical decisions and people to execute a project, very different from managing them as personnel. Having some hand in execution helps a lot, but the value of their contribution is typically not in the hands-on execution part.

> how LLMs seem to respond to the same sorts of process structures as humans

Pattern recognition to be sure, and structured communication conveyed with proper contextualization and emphasis, are common to both humans and LLMs. (at least if you want to get anything done)

I remember as a kid reading Lucifer's Hammer novel by Larry Nivel and J Pournelle, where at some point they discuss the theory that Earth was in a very different orbit and under different gravitational conditions that allowed giant dinosaurs to exist. It didn't make much sense to me at the time, but the description of muscle and bone cross-section as the core factor in their performance stayed with me.