> I'm just vibing, don't know the implications of some decisions.
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 doubt an agent-forward git should position the agent collaboration locus of data and control structures within git itself. Even when distributed, git commit messages are a one-way street if you want hash stability (critical property for agent collaboration).
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.
Worry more about the financial incentives built into every nook and cranny of our economic system to the point it permeates scientific funding, that make it an asymmetric bet to say anything even if it is proven wrong later, than to spend a lot and say in the present, "I got nothing". Modern science is more an industrial complex where errors and overstatements are often the rational outcome of perverse economic incentives. More commonly known as publication bias or the file drawer problem.
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.
A current rough rule of thumb I currently use: if private equity buys out a company I'm using, I bail for the next best competitor within a couple years. If it is a US private equity firm, within a year.
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.
> If you are delegating something to somebody that reports to you, you can just tell them off.
Coaching someone on why the perspective of the receiver of their behavior works counter-purpose to their intent due to 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.
This is when a track record of Google's "Don't be evil" motto, culture and corporate habits being literally front and center on its official code of conduct, instead of moved to the very last line in 2018, would have persuaded people to give it the benefit of the doubt. Functionally effective privacy seems to be retreating ever more exclusively into the domain of very wealthy families and behind the corporate veil (by purchasing information scrubbing services on a regular basis), and the loss by normal people of the commons of mass privacy has unfortunately not been appreciated by the common citizen. It is a more valuable commons than recognized by most citizens, and is being rapidly co-opted and monetized by commercial entities that are not aligned with individual interests.
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.
I suspect we’re at the stage of technological civilizational development where, especially with LLM-assisted gradient descent seeking upon the results, basic science, research and engineering for the pure sake of establishing search space beacons of what is found to be true and what is not, irrespective of immediate industrial applications payoff, are valuable economic inputs in and of themselves into ever-expanding training corpus. It has never been easier for people in different fields to now search knowledge spaces in LLM’s, for applicability to their problem spaces of discoveries in seemingly unrelated spaces.
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.
I sometimes wonder if we as an industry should revisit XML for those use cases where painful JSON contortions are being used, now that LLM's can plausibly support writing the syntax for XML-adjacent languages like XSLT without as steep a learning and sustainment curve. My natural inclination is to design to accommodate as complex a space as the business requirements project for, because representation data structures and languages are so incredibly painful to change late in a product's maturity cycle.
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.
I think the industry has an XML-shaped hole for sure, but XML itself was still designed before about 30 years of hard-won knowledge about smart design of data languages.
Not at all too paranoid. Just like people figured out even with elastic everything, compute from Spot instances and all the other things we're supposed to do in AWS, the data out charges between AZ's and Region's still more than made up the cost savings for true resiliency. People are going to figure out relatively similar pricing traps in Cloudflare that are difficult to design around.
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.
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.
reply