yourapostasy
Joined 15 years ago
Joined 15 years ago
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.
So I've never rejected XML out of hand, but I've always been "show me" skeptical of calls for it and pushed for explanations on why the business requirements feel the justification to adopt XML. Sometimes I've seen it totally makes sense, but with the conceptual rigor it requires in those use cases, the skillset and expertise of the development team has to reach a higher than average bar. I'm cautiously hopeful LLM's might help with lowering that bar, but time will tell.
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 must be considered bullshit. Really, it should be based upon the verification requestor's historical trust score and how many human verifiers are looped in. A Verification Tax, so to speak:
The energy the creator must spend (Ec) is determined by a function of the number of reviewers requested (N) and the historical trust score of that creator's AI outputs (T).
Ec = N * (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.
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.