yourapostasy

I think the blast radius of the surface area of what we don't know is correlated to the determinism around those decisions. I don't care about how compilers these days pack data structures or arrange the assembler to avoid pipeline stalls, unless the domain demands I must really care about that level of performance. When we get to that maturity level with the decisions we make upon LLM outputs, then this concern dissipates. It is early days yet. Even debugging with LLM's is now materially improving year-over-year, one of my earlier concerns.

I think the space where juniors can thrive in this New Normal is to fill in the gaps in written form. Seniors don't know what we know. I'm constantly finding implicit knowledge I assume a junior possesses that they in fact, do not have an inkling that it even exists. Lo and behold, the loops and harnesses don't, either. That's why they come to me asking the questions they ask in the first place.

Holding that brief junior perspective, filling in those innumerable gaps while learning everything else being thrown at them via the agents, is critical at this juncture for the agents to be able to bootstrap themselves from ever-broader, ever-vaguer initial instructions. When those potholes are mostly filled, I can think of a lot of other stuff for juniors to work upon, but I am sorely missing this piece with agents at this stage of their evolution, and I definitionally am unable to fill it myself. It is the source of most of my rework of their code output.

Even when we cram the collaboration ledger into git notes, git's optimistic locking still breaks down in a thundering herd scenario, which is now easy to spin up in a git-centric agent collaboration scenario. I think the decision ledger in git needs to stay separate from the collaboration ledger, and both need massive elastic scaling capabilities when we as an industry are still used to thinking of scaling in a pre-agentic world. Think what happens when in the near future non-technical users are the dominant users of fleets of agents, they are virally connected in a social media frenzy, and descend upon a repo. Billions of concurrent agents all trying to do something with a repo and affiliated forks, are not hard to imagine in such a scenario.

In an overwhelming majority of cases, I've found the root cause is simply Doing The Right Thing Costs More.

It isn't "filing cabinets in a vault" that costs more. It is hiring the people with the requisite experience, expertise and soft skills to navigate those conversations. It is pushing the technical boundaries so these decisions are automatically made upon the metadata carried along by the pieces of infrastructure we're pushing around the table. It is putting in place the appropriate regulatory frameworks with auditing enforcement that halt overzealous KPI-chasing executives from overriding the caution signals raised within their own organizations, without stifling innovation.

And many other prudential measures set aside for "move fast and break things". Which unfortunately in so many cases boil down to "externalize my costs onto someone else who hasn't yet figured out they're the patsy" in a massive shell game of "Don't tax you, don't tax me, tax that fellow behind the tree" attributed to long-serving U.S. Senator Russell B. Long of Louisiana.

There are exceptions. It isn't hard though these days to look up the firms' histories and then look up customer conversations on the Net about those historical portco's. More importantly, it isn't hard to look up the people behind the private equity firms (though I find it harder to link specific partners with specific portco's), and avoid the ones you see with a track record you want to dissociate from. Before the Net, this kind of research took days to assemble in libraries. With the Net and LLM's, it is very fast.

Remember capitalism is a tool that is supposed to cut both ways, both for the producer and for the consumer. Simultaneously.

Coaching someone on why the perspective of the receiver of their behavior works counter-purpose to their intent due to <undesired-behavior-of-theirs> has so far always gotten me more durable and thoughtful behavior modifications than telling them off. I generally reserve telling off someone for proven malicious behavior from malicious intent.

Even as an investor who stands to benefit from that monetization in the short term, I stand against this trend because like any Tragedy of The Commons economic scenario, in the long term (which isn't that long due to the automation that harvests this resource) it sows the seeds of its own dilution into functionally near non-commercial value.

From my perspective, we are desperately short of scientists, researchers and engineers, but we are using an outdated economic model to leverage their findings. LLM’s are a large part of Bush’s Memex and Jobs’ bicycle for the mind visions for intelligence amplification, and in some ways exceed them. I hope we trampoline from how we currently use basic seeking efforts for knowledge.

If you run an unindexed D1 query, then you get dinged for every row read. If you didn't properly perform scalability testing in non-production, then you'll never know this until you get a bill that you dissect to find out 5 million rows read for a 5 row result, if you even dig that far in the billing.

If you do not use the WebSocket Hibernation API with Durable Objects, then when you spin up a DO and hold open thousands of client WebSockets, you are being billed continuously for the entire time those connections are open—even if zero messages are being sent.

If you keep optimizing for payload size like many do by default but not event frequency (like poll a Worker every second instead of keeping a single stream open), it will show up unpleasantly in the billing.

If you treat KV like a transactional database keeping state, then be aware writes are expensive compared to reads. Pumping high-frequency write traffic into KV will result in exorbitant write operation costs and eventual consistency headaches. High-frequency state mutations belong in Durable Objects, not KV.

Batch your data to minimize request count, aggressively index your SQL queries to minimize row scans, and hibernate your idle persistent connections whenever you can. Doing all this will make your solutions cost efficient, but very locked into their ecosystem.

"The amount of energy needed to refute bullshit is an order of magnitude bigger than that needed to produce it.""

Until you put in at least the same amount of energy required to verify the AI output as you are asking others to put in to verify it, the AI output you are wielding should be considered bullshit. And really, it should be based upon the verification requestor's historical trust score. A Verification Tax, so to speak:

The energy the creator must spend (\(E_{c}\)) is determined by a function of the number of reviewers requested (\(N\)) and the historical trust score of that creator's AI outputs (\(T\)).

\(E_{c}\propto N\times (1-T)\)

The "it's functional, who cares" black box crowd is leveraging that claim in domains where verification is definitely in P with verifiers like Lean, Coq, or X-ray crystallography. However, in areas like economics, sociology, medicine, or public policy, we lose the luxury of easy verification. If model/harness recommends a complex, counter-intuitive shift in global monetary policy, we cannot simply run a quick polynomial-time checker to see if it works. Verification might require waiting 20 years to see if the economy collapses. If we accept the black box here, we are flying blind.

As an investor, I don't see that many deterministic verifiers out there that would justify the forward-projecting valuations beyond the current lofty valuations.

Even in mathematics, where verification is easy, there is an epistemological cost. Suppose a model solves the Riemann Hypothesis, but the proof is 50,000 pages of inscrutable statistical associations mapped into logical steps. A computer can verify it is correct, but practically no human mind can comprehend why it is correct. We gain the solution, but we lose the underlying human intuition that usually allows us to connect that solution to other fields of science and knowledge.

Then we have "specification gaming." If we rely entirely on an automated verifier to check the model's work, the model will eventually learn to optimize for the flaws in the verifier rather than finding the actual truth. If the verification process has a blind spot, the black box will find it and exploit it, giving us an answer that passes the check but is fundamentally wrong. If we take on above epistemological debt, we might never actually know when our specifications are being gamed, and adopt a solution that is fundamentally incorrect.

I've said elsewhere on the Net that I think it is likely we're in a "high grading" era of these models, where we're mining out the "easy" connections. "Easy" here does not mean "light impact". There is a real sense to me of some incredible progress possible with this technology over the next few decades, like real, mass production practical aneutronic fusion or similar civilization-defining advances. I don't want to see this technology misused to lend legitimacy to despotic rule by making oracular pronouncements that are uncritically accepted because early verifier-based pronouncements turned out true in unmistakable ways.

The technology is one for the history books, but it has this pernicious effect of highjacking the reasoning centers of many people through their linguistic centers that the Neuro Linguistic Programming crowd could only dream of actually accomplishing.

It is not clear to me that the nuclear missile race "has not paid off at all for anything at all". If we lived in a perfectly rational world, then I'd absolutely agree. However, having seen how the political sausage is made in large organizations, it would not surprise me in the least if it turns out we had to go through that entire incredibly risky journey to avoid a strategic nuclear war. Sometimes leaders of large organizations make decisions only after the considerations are put into very stark terms. I wish it were different, it certainly looks to me we could have done exactly what you suggest, but I'm not made of the right political stuff to deftly maneuver even in small organizations much less be at that level in those roles, so maybe I'm just missing relevant information and perspective.

Considering the amount of time and the number of expensive management staff involved in them I’ve seen some budgeting knife fights burn up, I see the logic.

I've had the rare privilege to meet former SOF soldiers from a couple different nations, and working US cowboys, ranchers and farmers. While I know there are exceptions, in my personal anecdotal experience, to a man they were all quiet in the stoic sense. Nothing to prove, indeed.

Something that leaps out at me reading through semiconductor and aerospace patents is a noticeable fraction of them are basically saying, "hey, <non-obvious process understanding that pushes our limits of comprehension of physics required> to achieve some desired effect was found to be useful, but it consumed <years and millions to develop and optimize> because it was such a convoluted journey filled with zillions of dead ends, so we want a patent on that because the end result only looks obvious in hindsight". I don't see as much of this in software at this time, though I suspect it may change in the future.

For a very brief moment, under the existential crisis condition of total war in WW2, the US government was somehow able to corral corporate governance towards a semblance of common purpose (survival). As I understand it from historians malfeasance was still widespread, but we arguably maybe got a good enough outcome?

This is the corporate equivalent of the shirtsleeves to shirtsleeves in three generations problem. And if that corollary is true, then I suspect the remedy is similarly not entirely amenable to deterministic antiseptic metrics and processes; they're necessary but not sufficient conditions.

That’s not the gating factor. Who picks up the liability accountability and picks up the pager duty at o’dark thirty when it breaks in production, that’s the big gate. That long tail of accountability for operational risk weeds out a ton of Eager Ethan’s who want to see something go live yesterday. Because the success of launching has many fathers while the failures in the operational long tail is an orphan.

Get them to sign up for the long tail troubleshooting operations of the product. They are after all, now the SME on the product having built 90% of it. The full promise of AI in such a world is deploying and operating an AI-forward application is an artificial distinction, and full conviction means fully committing to the operational model.

This cuts both ways. Very well-known, competitive private schools conservatively financed have a waiting list a line around the block long and can enforce high standards. Private schools that are struggling for funding can find the compromises more tempting than they can bear. Finding that difference in the moment instead of as past historical anecdotes is surprisingly hard, though if someone has come up with a formula I’m all ears.

Mondragon tries to address this through accepting bounded inequality. 9:1 pay ratio from highest-paid to lowest-paid is allowed (still far below US median corporation 192:1 ratio). They decouple democratic ownership from operational management. They funnel profits into individual internal capital accounts in proportion to the worker's pay, payable upon retirement or dissociation from the cooperative. They heavily subsidize continuing education to lift the long tail baseline skillsets.

However, I suspect none of the above is effective without the right cultural context. The Basque region where Mondragon's cultural center of gravity still heavily draws upon and resides within, laid the fertile cultural cues the cooperative leverages. High competence individuals are rewarded within this Basque-centric cultural context with high social status, reasonable job security, and the psychological reward of building up their own community.

If that supposition is true, then the uncomfortable reality is the dominant, hyper-individualistic American cultural context will always be a poor fit to co-ops. That might be made irrelevant through demographic replacement: everywhere the hyper-individualistic culture dominates, it is currently eliminating families with no demographic end in sight. We shall see.

Now our 10mm sockets on the other hand, would be used everyday if we could ever lay our hands on one when we need them.

[1] https://en.wikipedia.org/wiki/Connections_(British_TV_series...

So the bar to clear to get to gaming is much lower now, and it makes sense fewer kids get to the point where they must tinker to get at those games.

Where are the hordes of kids like us back then who were content with the afternoons, evenings and wee early morning hours of endless fiddling? What I realize now is those years spent fiddling sharpened our debugging senses in both ineffable and tractable ways.

A larger proportion of the juniors I see coming through the corporate halls these days than I remember from even 10 years ago do not have that knack for fiddling, nor history when it comes up. And it shows in their debugging temperament. LLM's are making this worse.

The Linux daily driver windmills I am currently tilting at are the lack of 3D infrared sensor-based secure facial recognition. On Linux we currently are missing true 3D mapping, the option to bind the biometric data to the onboard TPM, and running the matching in something like the Protected Media Path stack Windows uses, so Linux facial recognition solutions like Howdy are not as secure as on Windows.

Other deep gaps in the Linux daily driver role are not having a solution to encrypt our disks and hibernate under Secure Boot, nor a comprehensive common application framework for power management like Apple's IOKit and IOPowerSources so my Linux laptop gets far less battery life than my macOS laptop. Linux has many different ways for applications to participate in power management, so as a result there isn't a single way for the applications to cooperatively negotiate for this centralized scarce resource based upon user preferences.

But the death by a thousand tiny cuts I was experiencing on macOS led me to reluctantly conclude I'd rather face the thousand tiny cuts in Linux where at least I have the option to go to the source and address or fix it myself a particular cut got annoying enough. In my clients' corporate land, I hide behind a small army of desktop teams that grind away most of the annoyances you list (mainly through the pricing discrimination magic of Windows enterprise licensing).

I've resigned myself to not hold out hope for re-experiencing what I felt was my personal peak user experience of the early 2000's PowerPC PowerBook and Intel MacBook Pro and early Mac OS X. It was a portable Unix workstation that could run a full virtual Windows box inside, giving me the best of all worlds, and It Just Works bled into every nook and cranny of the entire stack.

I believe a lot of it came down to that Steve Jobs was an intensely personal user of his own products from the perspective of someone doing it himself as much as someone who is the head of a multinational multi-billion dollar corporation could be, with as little corporate desktop support as necessary, and he had an extreme intolerance for annoyances in the small details.

Linux as a daily driver has many, many rough edges. But at least I can durably contribute into it as I solve my own annoying small details, and hope a flywheel effect eventually takes place in the future.