ava's blog Today

seeing the person behind the piece

Edit: This post was being rapidly upvoted by bots for some reason. The issue has been fixed and the fake upvotes removed. Something I noticed as a consequence of online culture and platform design, especially on social media: It is very common online to follow an account not for the person behind it, but the way they present and discuss a topic or niche, even if they aren’t doing this with a professional intent or style. Then when the topics shift or we get tired of the person, people try to find someone else that scratches the itch. It’s like we use people online to engage with topics by proxy, and they are rather replaceable. We don’t just watch crochet videos, we watch this specific person crochet, but not for her as a person, and so on. People seem to have roles to fill in terms of who they follow, and they’ll move on if the role is no longer adequately filled, or the roles change. Feeds are highly curated; too many posts considered off-topic and you are ruining the vibe. In my experience, on the personal web, I really enjoy the culture of people being genuinely interested in learning about someone else. Seems like the general question is “ What’s that person up to? ” There is a wish to see life from the perspective of them, read their diary, explore their interests through their lens, and an acceptance that this person doesn’t necessarily write for you, but more likely for themselves (or at least, also for themselves). From the responses I get via e-mail or blog posts, people seem to respect that this is the specific situation of a stranger, and they’ll compare it with their own. There is a distinct separation. Yet, when my posts breach containment and land on link aggregators or social media, a different crowd shows up. In my experience, people coming from, and heavily using, social media that lets you reshare (reblog/retweet etc) a post onto your own profile tend to read posts as if they are meant to be self-inserts. What I mean is: Every post or article they come across is read as if they are judging whether this crosses a threshold of when they feel like sharing it onto their profiles to be like “ that’s soooo me! ”. Because that’s what happens with, I’d say, most reshares you put your name and picture to: You adopt what this person said and say it too. People find your profile and see everything you reshared as an endorsement, as something you re-say with your own voice. And when this type of person reads my posts, it feels like they do so with tunnel vision, with completely disregarding anything that doesn’t fit into how they see themselves and their own situation. They just wanna plunder my posts for parts that fit enough, so they can plaster it across their feeds as something that represents them, and are mad when there is something in there that is too different from their experience, something they wouldn’t co-sign… and therefore just ignore it or dismiss it, or accuse me of lying. Their responses, while almost never super rude, are at least not empathetic enough in the sense that they write criticisms as if I told a lie about their own life; a life that is extremely different to mine. It seems like for this type of person, the human being behind it doesn’t count at all. Every “content” someone puts out is a meme; further ammo to use to further their view on their own situation, or as self-promotion on their own internet presences. The source is forgettable and irrelevant, because in 5 minutes, they’ll find the next thing to consume. Single use entertainment. It’s just words written by someone else to take into their mouth and spit at the feed 1 , and maybe get upvotes and likes for something they had no hand in. I wouldn’t even mind as much, if it wouldn’t result in a completely warped picture of what I wrote about or what the conclusion is, while posing self-confidently as an expert in the comments trying to give advice or “correct” my experience. And people challenging those is rare because everyone is tired of beefing with random strangers over semantics. Did all this come from the way we are expected to engage with professional content creators who decidedly make mass-appeal content you are support to insert yourself in, and we end up applying it to almost everyone online? How do we feel being treated like a TV channel or magazine? You can be an inspiration, a pastime and distraction to someone; how does that make you feel? Can you withstand the pressure to box yourself in so you are more fitting for the role? Are you beating yourself up for falling short of a label you applied to your blog? Are you already thinking of the brand you have inadvertently built? Are you ready to tear it down over and over again? Published 06 Aug, 2026 Feeds I cannot even properly access or see, because they are all on extremely locked down Mastodon instances which are either completely inaccessible or unusable (bad or no search/content navigation) without an account, which genuinely pisses me off a lot. It's similar to how much info is locked inside Discord servers. You all profit from posting easily accessible public stuff like my blog, but the people create that stuff out cannot even take a peek what you're saying about them. So much for the "better alternatives" and being "open". It's not more open to me than Instagram or X, who also wall their content to death. At least be so kind and send me a direct link via mail, since search engines don't even pick it up either. ↩ Feeds I cannot even properly access or see, because they are all on extremely locked down Mastodon instances which are either completely inaccessible or unusable (bad or no search/content navigation) without an account, which genuinely pisses me off a lot. It's similar to how much info is locked inside Discord servers. You all profit from posting easily accessible public stuff like my blog, but the people create that stuff out cannot even take a peek what you're saying about them. So much for the "better alternatives" and being "open". It's not more open to me than Instagram or X, who also wall their content to death. At least be so kind and send me a direct link via mail, since search engines don't even pick it up either. ↩

Media Culture Programming

▲ 0

0 views

Xe Iaso Today

SigV4 authentication is surprisingly complicated

SigV4 looks simple: sign a request, check the signature. Then you implement canonicalization, clock skew, and a cache that isn't allowed to hold your key. Tigris is a drop-in replacement for AWS S3 (or GCS, anything S3API compatible). As such, we need to be fully compatible with both the mechanisms and semantics of S3 including the SigV4 authentication protocol . This is the lingua franca of authentication in the object storage landscape; even Google Cloud Storage has a way to enable SigV4 support so you can use existing applications against its object storage service. At first I thought that SigV4 was fairly simple. Clients sign requests, servers do the same work and make sure the result matches. The main sticking point is that the cryptography involved is symmetric cryptography, the kind where both parties need to have the same secrets. This makes some scaling issues weird, but we'll get into that in the future. Note This is only going to be talking about authentication (ensuring the identity of a remote client), not authorization (ensuring the client has the permission to do something). Authorization will come in the future for reasons that will become obvious when you see that post. We basically needed to implement a compiler. That is not a typo. At a high level when a client signs a request with SigV4 you get an access key ID and secret access key. The access key ID is functionally a username and the secret access key is functionally a password. Admins can identify keypairs by the access key ID (without special training or tools) and services use the owner of the access key or policies delegated to that access key to determine what actions that client may take. SigV4 uses HMAC (hash-based Message Authentication Code) and SHA-256 (SHA-2 with a 256 bit hash width) to do authentication by creating salted hashes based on request metadata. In order to send a SigV4 request, clients take the outgoing request, reduce it to a canonicalized form, and sign it with a symmetric key derived from the secret access key, the current date, region of the service, and service name, kinda like this Go code: As an example, let's see what a signed request to a HTTP debugging endpoint looks like on the wire with and without the signature: And when you add the signature with : Note This is not a live keypair, it was specifically crafted for this post. Breaking it down we have two extra headers in the request: On the wire, HTTP/1.1 requests look kinda like this: However the headers could be sent in any order, and changing the order of request headers doesn't result in different requests. Additionally any query string parameters could be formatted in any way a client (or server) could imagine, including the use of semicolons to separate values . All attempts to canonicalise HTTP requests MUST deal with this ambiguity and define their own rules. SigV4 canonical requests are made up of a few parts: For that example request, the canonical form would look like this: As the request has no body, the empty sha256 checksum is put as the body checksum. Note This exact approach requires clients and services to buffer the entire request body before processing it. There is a subset of SigV4 that supports arbitrary-sized bodies without having to buffer the entire request using , which requires extra logic that is way out of scope for now. If you want to learn more, give your favourite AI agent the following prompt: Additionally, when you are doing presigned URL uploads in object storage, you replace the body hash with the fixed string when canonicalizing because you have no way of knowing what data the client will upload or what the SHA256 checksum will be. To make the signature, you take the sha256 checksum of the canonical request and then HMAC it against that derived signing key: And construct the header based on your access key ID, service region, and service name: AWS has made an extension to SigV4 that uses asymmetric cryptography called SigV4a (the "a" means asymmetric). Instead of using symmetric cryptography on both the client and server in ways that means the server needs to either know the client's secret access key (or a value derived from the secret access key), SigV4a uses key derivation functions to derive a cryptographic keypair. Servers authenticating requests fetch the public key from IAM. Only the client and IAM know what the private key is, and that private key is what signs outgoing requests. I'd love to use SigV4a more because it makes adding additional services to the mix (such as a git service ) a lot safer as you can have those additional services exist in different trust domains than the core product. This is the core of how microservices end up happening. However, it's not super widely used even within AWS. The only SigV4a use I can find in Amazon is S3 Express Zones , however they may end up using it in other services I'm just not aware of. When I did my own experimentation with SigV4a (where I was implementing my own IAM server so that I really understood this all at a low level), I had to copy a lot of internal AWS SDK code into my repo in order to get it working. I'll talk about SigV4a some more another time. One of the weaknesses of using signatures for API authentication like this is the problem of replay attacks. When you make a naïve signature of a value, there's no real way to tell when that signature was created. If you sign a request to create a compute instance at time instance t0, it's still technically valid at any other time instance tN. This is why the canonical form of SigV4 requests includes the current date and time: This means that the request was signed on July 15, 2026 at 20:54:32 UTC. Time changes constantly (at least at the rate of one second per second!) and the client has to have a working clock in order for TLS to work. Servers can trivially read the contents of and reject old requests. This means that you don't need to add or store nonce (number used once) values with each request because that doesn't scale . Note A lot of the security of this authentication protocol is predicated on TLS being used to encrypt the authentication headers over the wire. If TLS is not in use or is compromised by administrative policy, you're probably in a very weird exceptional situation that is very wrong in the first place. An easy example is an enterprise network with endpoint manglement software that does deep inspection of every user action. As a side effect of this, you need to set a temporal skew window for validating requests. This window needs to be generous enough to accommodate slow clients, sloppy timekeeping on the client side, highly latent clients, leap seconds , or other exceptional temporal phenomena. In general time synchronization is a surprisingly hard problem , so it's best to just be tolerant of clients in order to make things more robust in practice. AWS uses a temporal skew window of 15 minutes for validating requests. I'm going to use a window of 5 minutes for my API because 300 seconds is a nice round number and I don't have to deal with the same amount of legacy code that AWS does. So all of this SigV4 business had been working really well for Tigris. Then we worked with a few customers who needed a local cache to fully saturate their hungry GPUs. To be fair, Tigris is plenty fast, but the real thing that kills AI training is latency and something that runs locally will always be faster than the cloud. In order to provide that sweet middle spot between making everything rely on the cloud and having everything local, we made TAG , the Tigris Acceleration Gateway. This effectively gives you most of a Tigris region in your own infrastructure. When you connect to TAG, your code uses its existing access keypairs, buckets, and code. You point your code to TAG, you point TAG to Tigris, and then everything is cached for you. But how does TAG authenticate with your code? TAG doesn't have access to all your existing API keys (and to be honest it shouldn't), but it's still able to authenticate them with SigV4 authentication. TAG and the IAM server both implement a signing key proxying feature that lets a client and TAG both prove their identity to Tigris. Once that proof is sent, then TAG gets the intermediate derived signing key and uses that for locally validating requests, kinda like this: The actual implementation in TAG involves some derived AES logic so that the derived signing keys are very much limited to the client that requested it (namely: the AES key is the SHA256 encoded form of the proxy secret access key). One of the weird parts is that the canonical form of the proxied requests differ from the normal SigV4 canonicalization process, namely looking like this: This is signed using the same SigV4 signature process as before but added differently to the request: And then TAG reads the response from Tigris, caches those derived signing keys, and then uses those in the standard SigV4 process to authenticate clients: no round trip to the cloud required. The happy path is exactly what I thought it was. Reduce a request to a canonical form, run four HMACs, compare the result. That part fits in an afternoon. Everything expensive lives in the questions around it. Which bytes count as the request? Whose clock decides that a signature is still good? Who gets to hold the key that proves any of it? Each question has an obvious answer, and each obvious answer is wrong in some specific way you only find by implementing it. That last question is the one that surprised me. I read symmetric cryptography as a hard limit: if the verifier needs your secret, the verifier has to be Tigris. It isn't. SigV4 derives its signing key through a chain of four HMACs, each one scoped tighter than the last: date, then region, then service. Those intermediate values can travel without the secret behind them. TAG rides that. The key it holds stops working when the UTC date rolls over. It covers one region and one service. You can't walk it backwards into a secret access key. We also didn't write any of this, which is its own kind of relief. SigV4 is old, widely deployed, and hammered on by every S3 client in existence. Any compatibility bugs here are ours. The protocol's bugs are everyone's. The place a protocol bends is usually some intermediate value that somebody already designed to be thrown away. If you want a Tigris region in your own datacentre, the Tigris Acceleration Gateway caches your buckets locally and authenticates your existing keypairs with the same SigV4 dance your SDK already speaks. : The fixed string to signal to the server which authentication mechanism is in use. The rest of the string is information about the request signature so the server can properly canonicalize the request. : The date and time (UTC) of the request so the server knows when the request was signed. Servers will use this request date in order to reject old requests to prevent replay attacks . The HTTP method ( , , , , etc.) The URI path of the request ( , etc.) The sorted canonical query string (you must exactly match the server-side canonicalization logic) The signed headers terminated with two newlines The sorted list of signed headers joined by semicolons The SHA256 checksum of the request body : the HTTP Host of client requests (EG: tag.default.svc.cluster.local) : the Tigris keypair used to authenticate TAG itself (must be in the same organization as the client) : the time of the request in unix timestamp format : the hex output of signing the canonical form of the request against TAG's secret access key

Go Programming

▲ 0

0 views

Unsung Today

Xcode’s clever minimap

Minimaps are an interesting UI element because they often feel very exciting – something about things being small, or responsive, or maps just being cool? – but fail to actually be useful. I find minimaps for coding particularly tricky because, at least in my world, code all looks very much the same from far away. Seeing a thumbnailed/ greeked version of it felt just like a more expensive and distracting version of a regular scrollbar, without any benefits. But Xcode does something interesting. It allows you to use to create a sort of a “header” for the minimap anywhere you want: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/xcodes-clever-minimap/1.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/xcodes-clever-minimap/1.1600w.avif" type="image/avif"> The minimap then shows those headers not greeked, but as human-readable text: I thought this was clever, allowing you to see the bird’s eye view of the code not just in the most obvious visual sense, but also as a sort of “table of contents,” adding so much more utility. This, of course, is technically no longer a “zoomed out view” but then again, it’s not that there is some sort of rule that it has to be. As a matter of fact, quite the opposite; it all reminded me of the famous London subway map by Harry Beck, which also broke the expectations in a similar way. The original, geographically accurate map of London’s tube looked like this: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/xcodes-clever-minimap/3.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/xcodes-clever-minimap/3.1600w.avif" type="image/avif"> Beck decided to take liberties with the geography and reimagine the map as a diagram to help the travellers, and ever since he’s done so in 1933, many transit maps followed suit: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/xcodes-clever-minimap/4.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/xcodes-clever-minimap/4.1600w.avif" type="image/avif"> #coding #text editing

Programming

▲ 0

0 views

Unsung Today

“It’s unclear how Sopwith escaped to the general public.”

Sopwith is a 1984 videogame made by David L. Clark for the original, seminal IBM PC model 5150 . It sports the distinctive 4-color CGA palette and an equally distinctive PC speaker soundtrack. It’s also one of the oldest videogames still in active development, and I was surprised how enthralled I was learning about it. = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/its-unclear-how-sopwith-escaped-to-the-general-public/1.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/its-unclear-how-sopwith-escaped-to-the-general-public/1.1600w.avif" type="image/avif"> (First of all, you can play Sopwith in a browser . Choose “single player” and then “novice” first for the game to tell you about its unusual keyboard control scheme.) The current maintainer of the effort is Simon Howard. He wrote about Sopwith’s interesting history ; I love appreciate this kind of approachable and caring preservation of obscure titles. The history is worth a read. From that, I learned a fascinating factoid. The game was intended as a demo for networking hardware, and the original author didn’t realize the game was “in circulation” for many years: Intended as a trade-show demo, it’s unclear how Sopwith escaped to the general public. David L. Clark didn’t even discover until around 2000 that it had “gotten out”. Little did he know, Sopwith had been circulating for years in collections of early games for the IBM PC. Only a couple of years after the first version was released, ads were appearing in magazines like PC Magazine advertising Sopwith for sale as part of collections of games for the IBM PC The modern edition started by Howard is called SDL Sopwith (SDL being a cross-platform graphics library ): SDL Sopwith is directly derived from the source code to the original DOS versions, and still includes changelog comments that date all the way back to 1984. What I particularly liked about the contemporary Sopwith is its guiding document/​philosophy page , also worth checking out in full. Here are some choice principles: There is something in all this that I feel a lot of software could learn from – not just vintage games. I appreciated Howard being thoughtful about growing Sopwith without forgetting its roots, but also with understanding that some things have changed since 1984. You could imagine remixing “The goal is to be a great old game rather than a mediocre modern game” to something like: Better be a great focused app than a mediocre sprawling app. Lastly, how did I learn about Sopwith? Howard shared this charming installation visual with me: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/its-unclear-how-sopwith-escaped-to-the-general-public/2.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/its-unclear-how-sopwith-escaped-to-the-general-public/2.1600w.avif" type="image/avif"> #change management #games #history #software evolution Sopwith has a long history that deserves to be honored and preserved. By default, the game should always play like the original DOS version. That means the gameplay in particular should be the same, without any significant differences. Someone who has just discovered the project should find it to be a delightfully accurate recreation of the game they may have played when they were younger. […] Some new features can be enabled by default, as long as they are subtle, unintrusive, carefully considered and can be turned off. An example is the medals feature. The game will never try to be “something it’s not”. This means that it will always have four color CGA graphics, PC speaker sound effects and a low resolution display. It will never add (for example) hi-res sprites or 3D models, digital sound effects or MP3 music. The goal is to be “a great old game” rather than “a mediocre modern game”. New features should be fun and recognize the comical aspects of the game. Features should be carefully considered before being incorporated, not just added arbitrarily and thoughtlessly.

Gaming Open Source

▲ 0

0 views

Kev Quirk Today

📝 2026-08-05 22:52: I have a habit of giving all our pets nicknames, there's many of them for...

I have a habit of giving all our pets nicknames, there's many of them for each of our dogs. We've Nelly for 4 days and already I have: Nells Bells Nelly Bean Nelly Furtado Man Eater (after the song) Nelly the Elephant It's anyone's guess which will stick. Our other dogs, Tia and Sid, are t-bone and squid (short for Sqidley) respectively. 🤷🏼‍♂️ Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️ You can reply to this post by email , or leave a comment .

Culture Writing

▲ 0

0 views

Evan Schwartz Yesterday

Notes from the AI Coding Transition

Like many other software engineers, my coding workflow has changed dramatically since the start of 2026. And like many others, I've felt some mix of awe, grief, frenetic productivity, atrophying skills, and understanding less while shipping more. In this moment where the field is undergoing this rapid shift, I've found it helpful to read others' takes on their processes, what they're doing to keep their brains engaged, and their genuinely mixed feelings. Before writing up my own thoughts, I went back through the relevant essays and blog posts from the last ~7 months to find the ones that resonated with me the most. Below are the posts that I especially liked and lines that stuck out from them, either because they gave me some idea about how I might want to use AI or just because they had a particularly incisive description of our field's situation. (Quotes are exact and the bold text is my added emphasis.) If you've read others that you thought were particularly on point, please send them my way! I didn’t ask for the role of a programmer to be reduced to that of a glorified TSA agent , reviewing code to make sure the AI didn’t smuggle something dangerous into production. If you would like to grieve, I invite you to grieve with me. We are the last of our kind, and those who follow us won’t understand our sorrow. Our craft, as we have practiced it, will end up like some blacksmith’s tool in an archeological dig, a curio for future generations. Even if AI agents produce code that could be easy to understand, the humans involved may have simply lost the plot and may not understand what the program is supposed to do, how their intentions were implemented, or how to possibly change it. Peter Naur reminded us some decades ago that a program is more than its source code. Rather a program is a theory that lives in the minds of the developer(s) capturing what the program does, how developer intentions are implemented, and how the program can be changed over time. Cognitive debt tends not to announce itself through failing builds or subtle bugs after deployment, but rather shows up through a silent loss of shared theory. As generative and agentic AI accelerate development, protecting that shared theory of what the software does and how it can change may matter more for long-term software health than any single metric of speed or output. the sense of psychological ennui leading into existential dread that many software developers are feeling Simon: All of the chess players and the Go players went through this a decade ago and they have come out stronger. The Shen-Tamkin study identified six distinct AI interaction patterns among developers. Three led to poor learning: full delegation, progressive reliance, and outsourcing debugging to AI. Three preserved learning even with full AI access: asking for explanations, posing conceptual questions, and writing code independently while using AI for clarification. The differentiator wasn’t whether developers used AI, it was whether they stayed cognitively engaged. metrics don’t capture what’s happening underneath. The mental fatigue of reviewing code you didn’t write all day. The boredom of babysitting an agent instead of solving problems . The slow, invisible erosion of the hard skills that made you good at this job in the first place. You stop holding the architecture in your head because the agent handles it. You stop thinking through edge cases because the tests pass. You stop wanting to dig deep because it’s easier to prompt and approve. There’s no spark in you anymore. Here is something that gets lost in all the excitement about AI productivity: most software engineers became engineers because they love writing code. Not managing code. Not reviewing code. Not supervising systems that produce code. Writing it. The act of thinking through a problem, designing a solution, and expressing it precisely in a language that makes a machine do exactly what you intended . That is what drew most of us to this profession. It is a creative act, a form of craftsmanship, and for many engineers, the most satisfying part of their day. this is different because it is not asking engineers to learn a new way of doing what they do. It is asking them to stop doing the thing that made them engineers in the first place and become something else entirely. a mid-level backend engineer is now expected to understand product strategy, review AI-generated frontend code they did not write, think about deployment infrastructure, consider security implications of code they cannot fully trace, and maintain a big-picture architectural awareness that used to be someone else’s job. That is not empowerment. That is scope creep without a corresponding increase in compensation, authority, or time . From my experience building and scaling teams in fintech and high-traffic platforms, I can tell you that role expansion without clear boundaries always leads to the same outcome: people try to do everything, nothing gets done with the depth it requires, and burnout follows. Now the only limit is your cognitive endurance. And most people do not know their cognitive limits until they have already blown past them. Set explicit boundaries around role scope. If you are asking engineers to take on product thinking, planning, and risk assessment in addition to their technical work, name it. Define it. Compensate for it. Do not let it happen silently and then wonder why your team is burned out. talk about what you are experiencing. The isolation of feeling like you are the only one struggling with this transition is one of the most damaging aspects of the current moment. You are not the only one. Computer programming is, fundamentally, about two things: I have a hard time imagining a future where knowing how to solve problems with computers and how to control the complexity of those solutions is less valuable than it is today, so I think it will continue to be a viable career even with the advent of AI tools. I try not to use LLMs to generate full solutions that I am going to need to support. Whenever I have Claude do something for me, I feel nothing about the results. It feels like something happens around me, not through me. the default output has no soul. It's correct. It's competent. It's fine . And "fine" is the enemy of everything I care about as a writer and an engineer. find it hard to believe that supervising a set of agents is going to lead to an optimal flow experience, because we are more passive, it doesn’t stretch our abilities in the same way, and it requires far less concentration. Will we find flow elsewhere? Solving problems and delivering value will always be rewarding, but I wonder if the optimal flow experience offered by programming has, for the most part, disappeared forever, and many of us will simply find less enjoyment at work. You realize you can no longer trust the codebase. Worse, you realize that the gazillions of unit, snapshot, and e2e tests you had your clankers write are equally untrustworthy. The only thing that's still a reliable measure of "does this work" is manually testing the product. Congrats, you fucked yourself (and your company). You let them run free, and they are merchants of complexity. They have seen many bad architectural decisions in their training data and throughout their RL training. You have told them to architect your application. Guess what the result is? An immense amount of complexity, an amalgam of terrible cargo cult "industry best practices", that you didn't rein in before it was too late. All of this compounds into an unrecoverable mess of complexity. The exact same mess you find in human-made enterprise codebases. Those arrive at that state because the pain is distributed over a massive amount of people. The individual suffering doesn't pass the threshold of "I need to fix this". The individual might not even have the means to fix things. And organizations have super high pain tolerance. But human-made enterprise codebases take years to get there. The organization slowly evolves along with the complexity in a demented kind of synergy and learns how to deal with it. With agents and a team of 2 humans, you can get to that complexity within weeks. And I would like to suggest that slowing the fuck down is the way to go. Give yourself time to think about what you're actually building and why. Give yourself an opportunity to say, fuck no, we don't need this. Set yourself limits on how much code you let the clanker generate per day, in line with your ability to actually review the code. When people say “taste,” what they actually mean is experience. Pattern recognition built up over years of doing the work. But calling it “taste” instead of “experience” does something subtle and harmful: it makes a learnable skill sound like a gift . Doing tasks manually naturally builds up the context required for the decisions involved later because you have time to process everything along the way and construct your mental model of the project's structure. This process requires more attention and context switching, along with way more decisions per hour. Making constant architectural, big-picture decisions while overseeing the work of a cracked junior dev is fundamentally harder than executing standard programming tasks yourself. Decision fatigue is, in my opinion, the next invisible friction point for developers. The problem is that as the coding agents get more reliable, I’m not reviewing every line of code that they write anymore, even for my production level stuff. But I’m not reviewing that code. And now I’ve got that feeling of guilt: if I haven’t reviewed the code, is it really responsible for me to use this in production? There’s an element of the normalization of deviance here—every time a model turns out to have written the right code without me monitoring it closely there’s a risk that I’ll trust it at the wrong moment in the future and get burned. When you stop fighting with hard problems directly, the mental models fade. You stop building intuition. You start pattern-matching on outputs instead of reasoning from first principles. And the worst part –> you don’t notice it happening. The code still ships. The PR still merges. Everything looks fine until the incident at 2am where you genuinely cannot reason about what the system is doing because you never really had to learn it. There’s a good analogy here from aviation. Pilots trained heavily on autopilot gradually lose the ability to fly manually and this isn’t theoretical, it’s contributed to real crashes. I think judgment is built from a specific loop: you form a view, you commit to it, you see what happens, and you update. That cycle, repeated enough times, is what builds calibration. The problem with AI is that it short-circuits the first step. You skip forming your own view and go straight to evaluating someone else’s. Do that enough and the muscle atrophies and again, not dramatically, just quietly. You become a better reviewer and a worse thinker. I did the software engineering equivalent of forwarding an email with “thoughts?” and then going to lunch . The job is the part where your fucking brain has to be in the room. You paste the issue into the machine before reading it. You accept the explanation before forming your own. You create a PR before even understanding what the problem you’re fixing is (!). You request a PR review before reading the diff. You merge because the checks passed and the reviewer approved it and the whole thing smells like progress. here’s the new hard rule I’m following after this “incident”: if I still can’t explain the change, I can’t ship it . No exceptions. many software engineers labor under a delusion that their job is to be excellent at their craft. Of course, wanting to be an excellent programmer is not a delusion; it is a completely legitimate value to hold, and a legitimate purpose to pursue. It’s just not what you’re paid to do at work. Your job , unfortunately, is producing shareholder value . This delusion has been punctured by the end of ZIRP , and again more recently by the rise of AI coding. Today, the ownership mindset defines the role. Although unintuitive, limiting the amount of work that runs in parallel is actually producing better outcomes and outputs. I believe the idea of WIP limits must be emphasised more strongly than before. moving from building features in parallel to building a single feature end-to-end faster. But for me, prolonged use becomes insidious. It's easy to become lazy and hand over thinking to the machine in looking for the next hit of cognitive offload when coding becomes even a smidge difficult. Why type your search and read half a short blog post to understand the problem when the same keystrokes give you the (possible) answer right there and then. When you ask a person to do something, you don’t expect them back in five minutes saying it’s done and ready for the next task. With an agent, that’s exactly what happens. Done. Next. Done. Next. There’s no breathing space. There’s always a next thing to think about. The work used to have a rhythm to it. You’d struggle, you’d get stuck, you’d finally figure it out, and there was this moment of joy when it clicked. Hours in the code, and then done. Figuring it out was the whole reward. That’s what AI can quietly take from me. Not the joy itself, but the sense that the thing was mine, which is where the joy was coming from all along. It hands me the finished thing, the finished thing works, and somewhere in there, I stop being the person who made it and become the person who approved it. AI didn’t take the joy out of coding, I gave it away. a quieter admission: the work isn’t teaching me much anymore, and it’s stopped being fun. That’s a description of becoming a manager . What AI did was give every engineer a small team of tireless, fast, occasionally-wrong direct reports. And with the team came the manager’s problem. The discomfort engineers are feeling right now isn’t an AI problem. It’s a delegation problem, and delegation is the oldest unsolved problem in our discipline. The good news: it’s not unsolved because nobody tried. Managers have been failing at it and slowly adapting for decades. What is in your control is small and it is everything: where you point your attention, what standard you hold, what you decide not to do, and whether you’re honest about which is which. The whole reason “there is too much” feels like drowning is that we keep trying to exert control over the size of the ocean. You can’t. You can only decide where to swim. I want to be able to explain what the system does without first having to ask a clanker to explain it to me. Present-day models tend to produce code that is too defensive, too complex, too local in its reasoning. They avoid strong invariants. They add fallbacks instead of making bad states impossible. They duplicate code, invent bad abstractions, and paper over unclear design with more machinery. If each iteration adds another small defense, the system slowly becomes less understandable while appearing more robust. we may no longer understand the whole system in the same way. We treat it, we monitor it, we stabilize it, but we do not necessarily comprehend it. Some domains will punish sloppiness and demand trust and responsibility, but a lot of software lives in a world where raw speed, quick experimentation, and vast coverage matter enormously. Better visualizations of changes or orchestration or agents will not restore our understanding. Either we need to find clever ways to jolt the human back into the loop and make the changes of the loops legible long term, or we need to find better ways to compose these ever more complex systems. In the old workflow, the creative process happened mostly in your mind. In the new process, you supervise the creative process that unfolds inside the AI’s internal machinations. Now, let’s put the historical novelist in the position of the software developer. She gets a call from her publisher saying they’ve found a way for her to bring four books to market each year instead of one book every two years. They’ve recruited a bunch of top-notch high school and college students who can each crank out five pages a day of competent writing for dirt cheap. The publisher wants the historical novels to maintain the original writer’s level of excellence, or to at least be close, so they’re retaining her services as an editor. The novelist’s job is now to edit the work of the students, each of whom has been carefully prompted to write pages that should, with a little work, be stitched together into coherent chapters. Anyone who has ever graded the work of high school and college kids knows that this is generally not rewarding work. If you’ve ever had to grade a hundred papers in a week, you know what a grind that is. The novelist, like the software engineer, is no longer deeply engaged in her work. Editing is not creating. You do not give yourself over to your imagination. You do not immerse your mind and feelings in the process of invention. Instead, you’re rooting out problems, trying to clean up clumsy wording and redundant descriptions instead. The flow state is gone. You are now a cog in a larger process that doesn’t really value your creativity or your need to exercise it. Worse still–and I have felt this personally after months of reviewing AI-generated code–your skills drop off sharply. When a new issue arises–a feature to be implemented, or a tricky bug to fix–the idea of wasting several hours on it feels insulting. Why should I dig through all that code when Claude can locate the bug in five minutes and start drafting a fix? But I think that creative people choosing to hand over their most imaginative, flow-state thinking to an army of bots will be a mistake in the long run. The feature gets delivered, but I do not really feel like I built it. Maybe this is just another evolution of our profession and in a few years it will feel completely normal. Or maybe one day we will realize that somewhere along the way we stopped programming and nobody really noticed. “I’m not sure I can do my daily job without Claude” The cost was never writing the code. The cost was owning it. A fix you cannot judge, in code nobody on your team understands, is not maintenance; it’s another spin of the roulette wheel . And when the bug comes back wearing a different hat, who do you escalate to? Your vibe-coded grid has no changelog, no support contract, and no team whose reputation depends on it. AI makes touching the code cheap; it does not make answering for it cheap. we are yet to see “mind blowing” software being churned out showing that it is still hard to build great software purely with agents. Coding using models can take you from 0 to 1 very fast. But what about 1 to 10, 10 to 100? In sufficiently large codebases, everyone operates with an incorrect theory of the program . Like many software tools, LLMs are a double-edged sword: they make it harder to construct a detailed mental theory of the software, but they allow you to build a partial theory quickly and they can help you leverage that partial theory more effectively. This is a complex tradeoff that I’m still thinking about. our field is evolving in an incredible and painful (but also joyful) direction if you control the ideas of your software, looking at the code itself is suboptimal and often pointless. large software projects have never been limited only by how quickly an individual can produce code. They are limited by how well people can coordinate their understanding of the system they are changing. The shared language of a software project is not English or Python but it is the common understanding of what its concepts mean, where the boundaries are, which invariants matter, who owns what, and why the system has the shape it does. Before agents, some of this shared understanding was maintained by friction....Some of it was the process by which your understanding became mine, and by which both of us discovered whether we still agreed about how the system worked. The most important skill in prompting is expertise in the domain you’re prompting for. A good illustration of this is Terence Tao’s conversation with ChatGPT about the recently-discovered counterexample to the Jacobian Conjecture. This is not the same ChatGPT I talk to! I couldn’t get to where Tao gets , even with unlimited tokens to burn. There’s a lot to learn about good prompting from Tao’s conversation. Here are a few observations: So why does software keep getting worse across the board? The bar for “user experience” has kept rising, but everything has become increasingly fragile. LLMs are useful for producing code that meets easily and objectively verifiable acceptance criteria which you provide explicitly I've found this simple instruction to vastly improve LLMs' output: " Never write READMEs, docstrings, or comments. I will write those myself later. And yes, I really mean this." Problem-solving using computers Learning to control complexity while solving these problems Write before you look. Before opening a tool, before asking the model, write down what you think. Not a design doc necessarily, just your current understanding of the problem, your instinct about the solution, where you think the tricky part is. Even a few sentences. This forces you to articulate your reasoning rather than pattern-match on someone else’s output. It’s also surprisingly useful as a diagnostic: if you can’t write anything, you probably don’t understand the problem well enough to evaluate any answer. Form a view before reading the suggestion. When reviewing AI-generated code or design, read it critically with your own opinion already in hand. What would you have done? Where does this differ? Why might the model have gone this direction and is it right? This sounds small but it’s the difference between passive consumption and active evaluation. One builds judgment, the other just builds familiarity with AI output. Separate ownership from authorship....You can own code you didn’t write. You cannot own code you refuse to understand. Those are different statements, and the gap between them is the whole job. Decide what you must understand deeply - then triage the rest without guilt. The discomfort is the job, not a bug in it. Acting on incomplete information, sitting with the unease of not-fully-knowing, and committing anyway - that is judgment. Managers don’t feel more certain than you; they’ve made peace with feeling uncertain and moving regardless.... Keep something you understand deeply.... Track what you’re learning, not just what you’re shipping.... Tao’s messages are very short and to-the-point. He doesn’t respond point-by-point to the model, just to the gist The model outputs are much more concise than when I try and talk to GPT-5.6 Sol about mathematics. By signalling expertise, Tao shunts the model into “talking-to-mathematicians” mode, not “explaining-to-amateurs” mode Tao pushes back when the model’s responses look wrong, but he doesn’t directly contradict; instead, he says things like “this looks more complex than I was hoping for” Tao makes several leaps and suggestions himself. He almost never takes the model’s advice about where to go next

Python Programming AI

▲ 0

0 views

Simon Willison Yesterday

One-shotting a Raccoon Heist game using Claude Fable 5

Back in 2024 I tweeted screenshots of a game concept generated by GPT-3 and some concept "art" created using DALL-E. Today, on the fourth anniversary of that tweet, I decided to see if Claude Fable 5 (running in Claude Code for web ) could build the entire game from the content of that tweet. It did a pretty good job of it! You can play the game here . Here's the GitHub repo , and a short video demo: Your browser does not support HTML5 video. This is the August 5th, 2022 tweet : My GPT-3 prompt back then was: This was in the text completion days, where you asked GPT-3 to complete the rest of the text. It completed: In "Raccoon Heist", you and your team of thieving raccoons are tasked with pulling off a series of daring heists. From robbing banks to stealing priceless art, no job is too big or too small for your furry crew. You'll need to use your wits and your skills to avoid the police and make a clean getaway with the loot. With exciting gameplay and a charming cast of characters, "Raccoon Heist" is the perfect game for anyone looking for a light-hearted caper. My prompt to DALL-E was short: Today's experiment: can I dump those screenshots into Fable 5 with a prompt telling it to write a game, then leave it to its own devices and get a working game at the end? A frustrating thing about Claude Code for web is that it can be hard to test what it's working on while it's still working. I've been using GitHub Pages to work around that limitation, and found it to work really well. Here's my process: That's all it takes! Within about 30 seconds of each push the latest content will be visible at . If you do this with a private repo, anyone who can guess the name of the repo will be able to view the published content. I don't worry much about this myself. Here's the prompt I gave Fable 5 (written in the notes app on my phone - this entire project was conducted on mobile). I accompanied it with the two images from the original tweet. I didn't make any technology choices. I assumed (correctly) that it would probably use Three.js based on previous experiments. Giving Claude access to an OpenAI key turns out to work really well for filling in gaps in its capabilities - in this case we needed some way to generate images to use as textures. Fable is very good at prompting image generators! I said "Work independently - do not ask me to make any further design decisions" because I wanted to see if it could produce a full, working game without any further input from me. I also said "Commit and push as often as possible so I can preview your work". When you use Claude Code in the Claude iPhone app you give it a GitHub repository and it works in a branch. Telling it to "push as often as possible" means commits start landing in that branch straight away. I like asking for as a bit of added flavor - here's that finished file , and the entry it made when it added the dog: New escalation: from night 3 the yards get a patrolling guard dog — a low-poly brown hound with a spiked red collar and a wagging tail. It wanders between random spots, and within 12 units it catches your scent and tracks you by smell (line of sight is irrelevant — it's all nose, shown by a 👃 over its head and barking). It gives up if you open a 17-unit gap. Getting caught messages are now source-specific: guard / headlights / hound. Verified wander → track → caught with an automated test. You can access the Claude Code shared session , and I also used my claude-code-transcripts tool to export my own HTML version which you can find here . Fable started with an index page, vendored a copy of Three.js, then wrote its own gen_textures.py script ( copy here ). It generated the textures and spot-checked them to make sure they looked OK. The metal.jpg file it generated for the trash can looks like this, though I don't think it was applied exactly right in the game itself: The raccoon, dumpster hideout, and both crew raccoons are now perfectly visible on mobile. Committing this critical fix. It decided to generate a title screen, which it did using this gen_title.py script. Here's the prompt it used for that: And the resulting image (which Claude thought was "gorgeous" ) - though I note that when it's shown on desktop it gets cropped to just the top third without the raccoon! Then my favorite change: it added the dog : And did a round of testing on it using Playwright, including another screenshot . It made a few more tweaks, then declared itself done : Raccoon Heist is built, tested, and pushed — 7 commits on , all verified with automated Playwright playthroughs on desktop, portrait-phone, and landscape-phone viewports. The game: You're a masked raccoon sneaking out of your crew's dumpster hideout into a moonlit cul-de-sac. Grab coins, gems, rings, donuts, and fish (they visibly stack on your back and slow you down), then waddle home and bank them before dawn. Each night raises the goal and the heat: night 1 has one flashlight-sweeping guard, night 2 has two, night 3 adds a scent-tracking hound that ignores line-of-sight entirely. A police cruiser sweeps the street with headlights, homeowners randomly peek out of windows, a seagull periodically dive-bombs your unclaimed loot, pizza slices trigger a 6-second speed FRENZY, and a rare golden TV is worth 120 points if you can haul its weight home. Win ranks: TRASH PANDA ⭐ → CAT BURGLAR ⭐⭐ → MASTER OF DISGUISE ⭐⭐⭐, with your best run saved to localStorage. How it's built: Vendored Three.js (no CDN), procedural low-poly characters, and a procedural WebAudio soundtrack (sneaky walking-bass jazz plus all sound effects — zero audio files). All seven ground/wall textures and the title-screen hero art were generated with gpt-image-2 and committed as static assets, so the deployed game makes no API calls. Mobile gets a dynamic touch joystick (appears wherever you touch) plus a DASH button; desktop uses WASD/arrows and Space. Testing caught two real bugs worth mentioning: the canvas rendered at 2× size on any real phone (a assignment was wiping Three.js's inline sizing — desktop DPR-1 tests masked it completely), and the win screen's star-rating div inherited the title screen's full-screen CSS and silently swallowed every tap on the "next night" button. Both are fixed and regression-tested, along with pickup, banking, chase/caught, dawn, night progression, and lose/retry flows. has the full build log. The game is live on the branch — just serve the repo root and open . It's an impressive starting point, but it's not a good game. You move your raccoon around a yard collecting items - donuts, fish, gold coins, jewels - while avoiding guards with flashlights and, in later levels, a dog. You have a limited carrying capacity, and once that's full you need to drop stuff off at the dumpster. If you pick up a pizza slice you get a temporary speed boost. There are no team mechanics at all - there are two other static raccoons next to the dumpster but they're purely decoration. It gets slightly more challenging as the levels progress - the dog introduced in level 3 is the most interesting new mechanic - but it's very, very easy to beat. It's also pretty boring - each night has a fixed duration and you can collect all of the items and then have nothing else to do while waiting for the dawn. I was impressed by the implementation. It's fully 3D, there are trash cans, the flashlight illumination cones are fun, and it has a reasonably coherent visual style. It works on mobile. The music ("a procedural WebAudio soundtrack (sneaky walking-bass jazz plus all sound effects — zero audio files)" according to Claude) is simple but feels about right. As a finished game project, it's mediocre. As a starting point from a single prompt I think it's very impressive. I've vibe coded up quite a few games now. They've all been deeply disappointing from a gameplay perspective - it turns out designing games that are fun remains a uniquely human trait, and one which requires significantly more skill and experience than either Claude or I can bring to bear. That said, I thoroughly recommend tinkering with game development projects as a way to explore the capabilities of agents. It's a fun, low-risk way to try out new things. If you stick at it long enough you might even produce something that's worth playing! You are only seeing the long-form articles from my blog. Subscribe to /atom/everything/ to get all of my posts, or take a look at my other subscription options . Create a new repository for the project at https://github.com/new - this can be public or private, the trick works equally well for both. Start a Claude Code for web session, in the Claude iPhone or Desktop apps or in the browser at https://claude.ai/code Tell Claude what to work on, and encourage it to commit an page as quickly as possible. This will create a branch with a name like Navigate to the Settings -> Pages area for the repository ( in my case), select "Deploy from a branch", pick the branch name, and hit Save.

Open Source Gaming AI CSS HTML

▲ 0

0 views

Ed Zitron's Where's Your Ed At Yesterday

News: Microsoft Disclosures Suggest OpenAI Sales Account For Around 70% Of FY26 AI Revenue, more than 7% of FY26 Revenue

Executive Summary: As I discussed in yesterday's free newsletter , analyst estimates have OpenAI and Anthropic making up over 70% of all AI revenues across Microsoft, Google and Amazon. While some might have disagreed, Bloomberg is now reporting that OpenAI "accounted for more than half, and likely about 70%, of Microsoft's actual AI sales during its most recent fiscal year." Bloomberg's maths is explained as such: The actual disclosure from Microsoft comes from its most-recent earnings: To be clear, "run rate" means a non-specific month multiplied by 12, which means that it's very possible that Microsoft actually made far less than $37 billion, but based on that maths, OpenAI would make up roughly 64.8% - that being said, I think 70% or more is a perfectly-reasonable estimate, if not far, far more. The other incredible fact from these disclosures is that OpenAI's spend and revenue share accounted for 7% of Microsoft's $331.8 billion in FY26 revenue - or around 7.26% to be specific. At this point, it's impossible to argue that Microsoft has spent $270 billion in capital expenditures to prop up a single client, and that its overall AI plays have failed to create any significant revenue growth or opportunities. We are now four years into the AI bubble, and Microsoft has little to show for it other than one very large and very unsustainable company that requires near-infinite resources to keep paying its cloud compute bills. If you liked this piece, you should subscribe to my premium newsletter. It’s $70 a year, or $7 a month, and in return you get a weekly newsletter that’s usually anywhere from 5,000 to 18,000 words, including vast, detailed analyses of  NVIDIA ,  Anthropic and OpenAI’s finances , and  the AI bubble writ large . My Hater's Guides To the  SaaSpocalypse ,  Private Credit  and  Private Equity  are essential to understanding our current financial system, and my guide to how  OpenAI Kills Oracle  pairs nicely with my  Hater's Guide To Oracle, as well as the Hater’s Guide To Oracle (Part 2). Subscribing to premium is both great value and makes it possible to write these large, deeply-researched free pieces every week. On Friday, I’ll publish the second installment of the Hater’s Guide to Nvidia — where I’ll take a look at how the AI bubble transformed the company from a pure hardware player to a purveyor of the financial dark arts.  If you want to get in touch — and especially if you have any juicy information about Anthropic, OpenAI, or any other companies in the AI bubble — hit me up on Signal at ezitron.76. I’m also on IB on The Terminal.  Microsoft disclosures and Bloomberg analyses show that OpenAI's compute spend and revenue share accounted for 70% or more of Microsoft's FY26 AI revenues, and more than 7% of Microsoft's overall FY2026 revenues. Microsoft has spent $261.3 billion in capital expenditures since the beginning of 2022. OpenAI accounted for $24.1 billion of Microsoft's FY2026 revenues.

AI Finance Business

▲ 0

0 views

Herman's blog Yesterday

Committing to creativity

There's a quote from the book City of Thieves by David Benioff where a character laments the fickleness of talent: Talent must be a fanatical mistress. She's beautiful; when you're with her, people watch you, they notice. But she bangs on your door at odd hours, and she disappears for long stretches, and she has no patience for the rest of your existence; your wife, your children, your friends. She is the most thrilling evening of your week, but some day she will leave you for good. One night, after she's been gone for years, you will see her on the arm of a younger man, and she will pretend not to recognize you. While I love this quote, as well as the book (you should definitely read it), I can't help but disagree with the premise that talent and creativity are divinely bestowed and out of your control. I've read a few autobiographies of prolific authors, and they all state the same thing: the words don't come easily and sometimes need to be dragged, kicking and screaming, into the light. The book Creativity by the winner of the most-difficult-to-pronounce-name-award, Mihaly Csikszentmihalyi, shares this conclusion and suggests that creativity is a creature to be nurtured, given space to grow, and needs commitment and a lack of distractions to thrive. The thesis is clear: relying on motivation is a losing game. Motivation is a feeling, while commitment is a decision that outlives the feeling. I've found this to be true in my own life, both in creative pursuits, and in things like relationships and exercise. It is a rare person who is amped to exercise all the time, and so it requires commitment to stick with it. Similarly, showing up well in your relationships can't depend on fleeting passions, because life is bumpy. The nice thing is that commitments become easier with time. I have near zero resistance to exercising and journalling, and have been doing both almost every day for close to a decade. The first year or two were difficult, but once they were a part of my day, they became absurdly easy to continue doing. Relatedly, when I'm in a good writing routine it is effortless to write. However, if I go a month without writing on my blog (as is currently the case), each word is a struggle. Action begets motivation, not the other way around. Creativity is like a muscle. It requires constant use to grow, and atrophies when neglected. But creativity is transferable, and so, engaging creatively has positive effects in other creative domains. This post was inspired by a comic jam I attended this past weekend. The comics were great, genuinely funny, and everyone had a wholesome time. It also made me realise how long it had been since I'd sketched. Conversely, I speculate that forgoing creative thought will lead to it "leaving you for a younger man". She doesn't leave on a whim, she leaves when you stop showing up. It hurts when I see people "brainstorming with AI". This is essentially offloading creative thought to a machine, forgoing the most human of processes. It honestly makes me sad, and I can't help but feel that collectively we’re losing something beautiful. The machines are coming for so much, but we can’t let them have this. So go do something creative. Anything. Make a zine, paint with some watercolours, come up with a song. And keep doing that, forever.

Career

▲ 0

0 views

Kev Quirk Yesterday

New Pets, Sick Pets, and Hemorrhaging Money

Wooh! The last few weeks have been absolutely mental here in Casa del Quirk. Around 2 months ago we started renovating the stables to make things better for the goats and chickens. We've had an extraction system put in so fresh air is always circulating, as chickens are very dusty and goats don't like it too hot and stuffy. While we were at it, we also had some new fencing and gates put in, as well as better hard standing around the stables. Finally we had the old, rotten windows and doors replaced with lovely new ones that have shutters so we can control the air flow depending on the weather. Our stables with the new windows and doors As you can imagine, this has been a significant expense, but we planned for it. So it's all good, but then... Around a month ago we noticed that our older (and favourite) dog, Tia, had rather smelly breath and her mouth was bleeding when she was playing with her ball. We figured it's just old age and bad teeth, so we took her to the vet to have her mouth checked and properly cleaned. Unfortunately it was bad news. Tia has a benign but aggressive tumour growing in her gum. Apparently they're relatively common in older dogs (she's nearly 14) but if left untreated it would get very painful and we ultimately end up having to have her euthanised as it would significantly effect her quality of life. So we paid the unexpected £1,000 (~$1,350) bill to have the initial tumour removed, her teeth cleaned, and a biopsy. In the meantime we were also referred to a specialist to hopefully get the issue sorted properly. Last week Tia went to the specialist to have a full body CT scan. This would give them more info about the tumour in her mouth and what our options are, but also (because she's so old) let us know if there's anything more malicious going on in her body. We have to be pragmatic about this - the treatment was going to be expensive, and we had to make a call on whether we wanted it doing if they found something like cancer lingering somewhere in her body. Luckily for us the old girl came back with a clean bill of health and the tumour was treatable. That was another £1,500 (~$2,020) down the drain, but well spent. The procedure to treat the tumour involved taking around 40mm (~1.5") of her lower jaw away. It's a significant operation and the recovery, especially for an older dog, will be difficult. On Monday she had the procedure, it went really well, and yesterday she came home a day earlier than we expected. She's a tough old girl. She's much better today, but still struggling as she's been through a lot. Having a pet that's in pain is the worst - you can't really reassure them like you can a human, so you find yourself hopelessly watching them suffer. It's heartbreaking, but it's for the best. We're still to get the bill for this procedure, but the vet has estimated an eye-watering £4,400 (~$6,000). If anyone is playing along, that's £6,900 (~$9,200) in unexpected vet bills over the last few weeks. She also isn't insured as it's prohibitively expensive for a dog of her age. So we need to foot the entire bill. Anyway, on to more positive news... Last Saturday we welcomed the newest addition to our family, Nelly the 8 week old Labrador/cocker spaniel cross. The breed is known as a Cockador apparently - very unfortunate name if you ask me. Nelly on her first visit to the vet, being very good. Like any puppy, Nelly is a lot of work. Especially if you add into the mix a very sick dog, and the kids being off school for the summer holidays. I've also been working long hours recently, so my poor wife has been juggling most of this on her own. She's at her whits end. Nelly, Tia, and our other dog Sidney are all getting on well though. Nelly is even helping distract Tia from the pain she's in. It's fair to say that all our savings are gone, and the last of Tia's treatment will need to be thrown on a credit card so we can pay it off over the next few months. Things are extremely busy and stressful at the moment. But hopefully we will have Tia for a couple more years so her, Nelly, and Sid will become a proper little pack that gives us lots of lovely memories. Pets are a gift and we wouldn't have it any other way. I just wish vets bills were a little cheaper! Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️ You can reply to this post by email , or leave a comment .

UI AI

▲ 0

0 views

Stratechery Yesterday

Google Earnings, The Frontier Case, Amazon Earnings

Google's earnings seemed to confirm the Anthropic hedge; it was Andy Jassy who explained why their — and Amazon's — capex was justifiable.

Cloud Business

▲ 0

0 views

The Universe of Joshua Blais Yesterday

Its not nostaligia

“You’re just nostalgic!” They will say when you point out the fact that everything today is crumbling around us. Where every McDonalds has transformed into a grey box without a playplace - because the playplace would mean people stay longer without paying more money, and the grey box can be sold in the future when divestment is on the table. We live in a world where the food that we eat is less nutrient dense than it was 20 years ago - and a 1/3rd the size of what it used to be, while being 3x as expensive. That the men all have half of the sperm count and testosterone they did even 30 years ago. That the car that you drive is built far worse than it was in the 90s and spying on you - because it wasn’t enough to sell you the car and the maintenance - they have to sell your data, too. That the house you live in is built with garbage materials, the corners cut so that the builder can achieve 0.025% more margin. The home is meant to get to the day after the builder’s warranty expires, not even make it to the end of the decade. That in a world of “infinite streaming”, there is nothing to watch. Where the technology you use is continually selling out your privacy and sanity, while you are not permitted to own any of the media you supposedly “buy”. Where everything is locked behind a log-in screen or a paywall. The phone you buy is manufactured to die in 2.75 years so that you must buy another. But not just your phone - your furnace, your car, your walls, your oven, your washing machine and dryer, your computer, everything is meant to /break/ - because if it lasted, you wouldn’t spend more money. Every idea just being re-hashed for corporate profit, nothing new has been said in 20 years. That the things that you have written or recorded are now training data for “AI”. The books that you could be reading are being bought up by “AI” companies, only to destroy them after ingesting them . “But we live longer!” The bugman proclaims as if the length of life is the only metric by which we can gauge life. “But there’s so many things to do!” He proclaims as he eats the slop, consooms the media, and votes for the politician he is supposed to vote for. Everything is getting more pricey, yet you get less every year. Nothing works well, and yet we are called nostalgic when we long for a time that at least we owned the things we paid money for. You essentially have to build everything yourself nowadays if you want any semblance of quality and longevity. The only way forward is radical self reliance. I refuse to pay for things that don’t last, that are meant to break on me, that are meant to trap me into an ecosystem I cannot escape. No - it’s not nostalgia. Things just really are worse. As always, God bless, and until next time. If you enjoyed this post, consider Supporting my work , Checking out my book , Working with me , or sending me an Email to tell me what you think.

Business Culture

▲ 0

0 views

Simon Willison Yesterday

New release of LLM adds support for reasoning traces, OpenAI Responses, server-side tools, and smarter logging

I released LLM 0.32 this morning, the most significant new version of LLM since the initial launch of the project. The new version includes support for visible reasoning traces, server-side provider tools, redesigned content-addressable SQLite logs, new models, and new features enabled by the OpenAI Responses API. I also released a new version of the llm-anthropic plugin with substantial updates of its own. Running LLM against reasoning models now displays their reasoning traces to standard error, so you can see what they are "thinking" without that information being included in the standard output that you might pipe to another tool. Add to turn this off. LLM includes support out-of-the-box for the GPT-5.6 model family , and the new default model used with is now the inexpensive but capable GPT-5.6 Luna . LLM calls can now use server-side tools from various providers. OpenAI provide a code execution environment as a server-side tool; LLM can now run prompts that benefit from that like so: OpenAI also gets a WebSearch tool. The llm-anthropic plugin adds WebSearch , WebFetch , CodeExecution , and AnthropicMCP , which looks like this: That causes Anthropic to execute MCP calls against my new datasette-mcp plugin as part of a single request/response interaction with their API. The new llm openai endpoint command provides a tool for executing prompts against any OpenAI compatible endpoint as a one-liner. These aren't logged, which makes this a handy tool for running one-off prompts against anything that speaks the lingua franca of the LLM API world. Here's how I use that to run prompts against Gemma 4 12B running in my localhost LM Studio API, via (no LLM installation required) and mixing in the llm-tools-quickjs tool plugin for good measure: LLM's Python API previously required you to create a conversation and then send messages to it one at a time. This was an abstraction over the true nature of LLMs, where each request carries a complete history of the messages that came before it. That abstraction started to get in the way for some more advanced cases, so the new release introduces a parameter that can be used like this: LLM previously returned an iterable sequence of strings from each prompt. This worked great when models returned a string response, but failed to predict the weird shape that models would evolve towards. Today many models return a mix of reasoning text, output strings, tool calls, and even image attachments. With LLM 0.32 you can do this instead : Combine these features and we can finally provide a robust implementation of the semi-standard OpenAI chat completions API, which I've now released as the llm-chat-completions-server plugin: Now you can run prompts against LLM via that server, using the new command! The bigger challenge with that kind of API concerns logging. If we're going to support the pattern where the message sequence is appended to on every request, ideally we can avoid logging all of that duplicate JSON for every turn. The solution is the new content-addressable message store , modeled after Git. You can see the new schema for that in the documentation , but the and commands have both been upgraded to convert that format back into something that's easy to consume. There is a whole lot more in this release. The 0.32 release notes are pretty comprehensive, and the notes for 0.32rc2 , 0.32rc , 0.32a3 , 0.32a2 , and 0.32a0 should fill in any gaps. Existing LLM plugins should all continue to work, but plugins that provide extra models will need to be upgraded to 0.32 in order to participate fully in the new streaming events system. There's a guide to implementing plugins with Structured messages and streaming events in the documentation. I've updated some of my own plugins: Quite a few of the lower-level tools changes in this release were driven by the needs of Datasette Agent . When I started work on LLM, the term "agent" had such a vague definition that I refused to use it. In September 2025 I came around to the idea that " An LLM agent runs tools in a loop to achieve a goal " is well established enough now that I could stop avoiding the term entirely. Tool chains can now pause for human approval and resume from a stored message history - both needed by Datasette Agent. Looking at LLM today it's beginning to look very agent-shaped to me. There's something neat about having a CLI utility that can mix and match different tools from different sources with different models all as a one-liner, and that includes a Python library powerful enough to build systems like Datasette Agent and llm-coding-agent . Maybe the next version of LLM will bake the concept of an "agent" into the core library. I'm still trying to figure out what that would look like. You are only seeing the long-form articles from my blog. Subscribe to /atom/everything/ to get all of my posts, or take a look at my other subscription options . llm-anthropic 0.26 adds support for the Claude 5 family of models, plus , , , and server-side tools. llm-gemini and llm-openrouter and llm-mistral are nearly there, releases coming soon.

JSON AI Programming Python

▲ 0

0 views

Gabe Mays Yesterday

4 year follow-up on buying pandemic stock dip + AI reallocation

This is my 4-year investment update following buying the dip on ‘pandemic stocks’ that declined (70%+) in 2022, then reallocating into AI stocks in 2023. I started sharing public updates once a year. Data in this update is as of June 2026. This will be a relatively short update since my thesis is relatively unchanged. See my past updates for more context: Below is…

AI Finance

▲ 0

0 views

Entropic Thoughts Yesterday

Purely functional digital circuit simulator (SICP 3.3)

I have a copy of SICP, or as it is also known, The Wizard Book . This book is widely praised, but I can’t take the time to work my way through all of it. Instead, I’m going to occasionally jump into the parts of it that look interesting. Since last week, are in the process of simulating a digital circuit. The reason this is interesting is the solution in SICP uses hidden mutable state and message-passing to make the code object-oriented. It even uses a mutable global variable for scheduling! We managed to replicate all of that in Haskell, but now we want to refactor the solution to be easier to work with. If we are going to manage the simulation in a pure functional manner, we still have to contend with the fact that during simulation, wires are objects with a fixed identity. A wire does not become a different wire just because its signal changes – the same wire is still hooked up to the same gates. Wires need to maintain their identity somehow. (Continue reading the full article on the web.)

Haskell Programming

▲ 0

0 views

Unsung 2 days ago

When commit means cancel

A strange thing happens when you press Enter on an empty item in a list in most text editors – the entire list item disappears: This feels counterintuitive. Isn’t Enter for committing and adding more things? Wouldn’t Backspace be the right key to press to break a list? Yes, and no. I am not sure who invented this pattern (I spotted it first in Word 95), but that someone understood a strange interaction contract existing in text editing – Enter is actually an escape hatch. In text editing, no matter where you are, you can always press Enter multiple times to just create more room for writing. In an app that doesn’t cancel a list on Enter, you can face a terrifying moment where you get stuck in a list, and getting stuck is never fun. This principle feels so useful that I see more and more apps apply a version of it for other things. For example, in many modern text editors pressing Enter after a headline returns you to regular text, just so it’s not as easy to get stuck in a headline style: #errors #flow #keyboard #text editing

Programming Design Frontend

▲ 0

0 views

Ed Zitron's Where's Your Ed At 2 days ago

The AI Demand Bubble

If you liked this piece, you should subscribe to my premium newsletter. It’s $70 a year, or $7 a month, and in return you get a weekly newsletter that’s usually anywhere from 5,000 to 18,000 words, including vast, detailed analyses of NVIDIA , Anthropic and OpenAI’s finances , and the AI bubble writ large . My Hater's Guides To the SaaSpocalypse , Private Credit and Private Equity are essential to understanding our current financial system, and my guide to how OpenAI Kills Oracle pairs nicely with my Hater's Guide To Oracle, as well as the Hater’s Guide To Oracle (Part 2). Subscribing to premium is both great value and makes it possible to write these large, deeply-researched free pieces every week. On Friday, I’ll publish the second installment of the Hater’s Guide to Nvidia — where I’ll take a look at how the AI bubble transformed the company from a pure hardware player to a purveyor of the financial dark arts.  If you want to get in touch — and especially if you have any juicy information about Anthropic, OpenAI, or any other companies in the AI bubble — hit me up on Signal at ezitron.76. I’m also on IB on The Terminal.  Soundtrack: Tool - Forty Six & 2   The question I want to ask anyone reading this who might have invested in or in some way backed the hyperscalers and the greater AI industry: What is it you think you’ve gotten yourself into? Because I think you’re being sold a lie .  Last week’s tech earnings saw outlet after outlet claim that Amazon, Google, and Microsoft’s AI bets were “paying off” as their respective cloud segments reported record revenue growth, casually ignoring that none of them have broken out their AI revenues . To add insult to injury, Microsoft decided, after sharing that it had a $37 billion AI run rate (about $3.08 billion a month) in Q3 FY2026 , that it simply didn’t have to share anything about its actual AI payoff in Q4 , realizing that its overall numbers would beguile reporters and analysts — especially those with little interest in what was actually going on as long as the topline stuff looked good.  To be clear, all three of these companies’ cloud platforms have many other customers paying for many other things other than generative AI services or AI GPUs, and they’ve all engaged in a combination of multiple outright price increases and changing their core subscriptions to force AI features on them as a means of boosting revenues and conning the street into believing that “AI is paying off” every time they non-consensually thrust it on their customers, framing higher prices as “better value” in a way that fucks the user to appease Wall Street.  Yet the biggest con of all is that a vast majority of this revenue growth comes from the compute spend of Anthropic and OpenAI, both of whom account for the vast majority of AI revenues and overall cloud growth we’ve seen in the last few years.  Every publication you read right now will tell you that AWS and Azure and Google Cloud are growing like wildfire as a result of the hundreds of billions of dollars they’ve invested in AI GPUs and data centers, when the truth is far simpler: their revenues are being buoyed by two unprofitable, unsustainable AI labs that cannot exist without being funneled tens of billions of dollars each year.  And a decent chunk of that money is coming from the hyperscalers themselves. In the last seven months alone, Google has sunk $10 billion (and up to $30 billion more) into Anthropic , with Amazon funnelling $5 billion to Anthropic within a week of that investment and a total of $50 billion into OpenAI . For all the concern about circular financing in the AI world, it’s astonishing that so much attention has (rightly, to be clear) centered on NVIDIA’s backstopping and funding of neoclouds, and less on the fact that hyperscalers are propping up their now biggest customers, giving them cash that will eventually migrate back to the hyperscaler.  I’d also argue that the vast majority of their capex exists to support these two load-bearing failsons. A few months ago, a Microsoft executive told the judge during the Musk-Altman trial that its OpenAI relationship had cost it “ over $100 billion ,” including both the $13 billion it sunk into the company and the associated infrastructure.  Microsoft has dedicated its Fairwater data centers (however much actually exists) entirely to OpenAI, much like Amazon has for Anthropic with however much of its massive Indiana-based Project Rainier has actually been turned on, and much like Google is in talks to backstop a $15 billion data center project for Anthropic , along with data centers with Cipher Mining and TeraWulf and a $35 billion private credit-funded Broadcom-backstopped deal where Google will sell Anthropic its TPU AI chips, put them in a Google-built data center, and rent them back to Anthropic. I want to spell this out: when you remove Anthropic and OpenAI’s compute spend, I am not confident that Google, Microsoft and Amazon have much of an AI business. While many people believe — largely because the big three refuse to break out their actual AI revenues or disclose their customer concentration — that they have AI revenues coming from a diverse set of different customers, the reality is that their largest cloud customers, let alone AI customers , are two companies that can literally not afford to pay them without a near-infinite flow of venture capital or debt. Per Ross Sandler of Barclays, Anthropic and OpenAI are estimated to make up 73% of all of Amazon’s AI revenues in both 2026 and 2027 and 75% of AI revenues in 2028 , with Anthropic spending $14.1 billion in 2026, $25.3 billion in 2027, and $35.8 billion in 2028, and OpenAI spending $9 billion in 2026, $15 billion in 2027, and $20 billion in 2028. Amazon plans to spend $220 billion in capital expenditures in 2026 and even more in 2027, and appears to be doing so almost-exclusively to provide compute for a company that had to raise $95 billion in funding in the space of six months, with $5 billion of that coming from Amazon itself.  Google is in a similar-position. Per Stephen Ju of UBS, “...Anthropic, OpenAI and Meta will account for 21%, 7% and 1% of 2026 Google Cloud revenues, respectively, and 44%, 5% and 1% of 2027 revenues,” or, put another way, 28% of all 2026 and more than 48% of all 2027 Google Cloud revenues are from Anthropic and OpenAI.   Ju also estimates Meta will make up a whopping 1% of Google Cloud revenues in each year, and does not mention a single other customer, which heavily-suggests that there aren’t really any large ones.  Based on Bloomberg Intelligence’s consensus estimates for Google Cloud’s revenues in 2026 ($105.9) and 2027 ($173.8), OpenAI and Anthropic represent $29.4 billion ($7.4bn/$22bn) in 2026 and $84.69 billion ($8.69bn/$76bn) in 2027. To be explicit here, this is all Google Cloud revenues. It is reasonable to believe that this represents at least 75% of Google’s AI revenue, if not more. What’s crazy is that these numbers are actually lower than UBS’ estimates. As the chart below demonstrates, OpenAI and Anthropic’s spend is estimated to sit at over $35 billion in 2026, larger than both its entire Google Cloud core non-AI business and Vertex AI model rental business that is largely boosted by Google’s ability to sell Anthropic’s models.  Eagle-eyed readers will also see that Google’s non-AI cloud business is estimated to be effectively flat in 2026, 2027, and 2028. I also don’t think it’s common knowledge that OpenAI is such a large customer of either Google Cloud or Amazon Web Services, spending at least an estimated $52.5 billion in 2026 and at least an estimated $125 billion in 2027.  In the Musk-Altman trial, OpenAI estimated it would spend $50 billion on compute in 2026 , and based on those estimates, that gives us about $16.4 billion across Amazon and Google, leaving a likely $33.6 billion in spend left for Microsoft Azure, though I’ll add that OpenAI continually underestimates its own compute spend and losses.  And based on a note from Michael Turrin of Wells Fargo from May 31 2026, things are just as bad for Microsoft, with 70% or more of its AI revenues coming from Anthropic and OpenAI. While Turrin “expects investments at software & models layers [to] pay off in meaningful adoption over time,” it’s difficult to argue that Microsoft has any meaningful AI strategy outside of OpenAI and Anthropic’s compute spend.  To make matters worse, based on Wells Fargo’s estimates, it appears that Microsoft 365’s AI revenues are barely — and I mean barely — beating the revenue share Microsoft gets from OpenAI’s sales. Wells Fargo also includes a helpful cheat sheet of its estimates for AI contributions, estimating that even at the very end of FY2027 (which began on July 1 2026), OpenAI and Anthropic’s spend will represent a dramatic 74% of all AI revenues. Wells Fargo also estimates that the two AI labs represented 23% of Azure revenue in FY2026, growing to 35% in FY27. Considering Azure grew 41% year-over-year, this means that 40% or more of Microsoft Azure’s growth came from them — and remember , Azure sells far more than just AI services. This is an absolute fucking scandal.   The vast majority of Microsoft, Google and Amazon’s AI revenues and revenue growth in their representative cloud platforms are from Anthropic and OpenAI, and they are blatantly, unashamedly misleading investors by not disclosing that this is the case. We’re talking 73% of AWS’ AI revenues, 74% of Microsoft’s, and likely 70%+ of Google Cloud’s considering that just Anthropic and OpenAI’s AI spend is expected to be more than 48% of all cloud revenues. This is not me being a hater, a skeptic, or a doomer, but the product of actually investigating what’s happening in the real world rather than just looking at whatever numbers the hyperscalers fart out and assuming it’s “all from AI,” and that “AI” means something more than just the two main model labs.   Investors in Amazon, Google and Microsoft have been led to believe that the $994 billion spent on AI GPUs and data centers exists to boost their existing businesses and build what amounts to the next industrial revolution. In fact, this is the line that just about any AI bull will give you about NVIDIA’s GPU sales — that all compute will be used because there’s endless, insatiable demand.   Well, other than the fact there isn’t. What hyperscalers have actually done is demolish their free cash flow and purchased hundreds of billions of dollars’ worth of GPUs, TPUs, and XPUs to support a customer base dominated by two customers that are now accounting for the vast majority of their revenue growth and quite literally cannot afford to pay their bills without a near-infinite flow of venture capital investments.  Based on these estimates, these analysts also don’t seem to believe that any other large customers are going to emerge, bringing into question both the rationale of their capital expenditures and those of basically anyone building any data center anywhere in the world.  This is all very important, so I want to spell it out really simply for you: Remember: Microsoft Azure, Google Cloud and Amazon Web Services represent a large chunk of all global cloud spend and AI compute, and thus are a representative sample of all AI compute…and if diverse, “insatiable” demand existed, it would be represented in these estimates.  This is the single-worst capital misallocation in the history of business. Every single story you’ve read about the “incredible growth” of these cloud platforms is an embarrassing misread of three companies that are misleading investors that will more than likely be forced in the next year or two to have to restate revenues, cut remaining performance obligations, and admit that they’ve drastically overbuilt capacity.  The counterargument to my warnings is always that “this is useful infrastructure that will be used in the future,” or that we’re in an OpenAI Bubble not an AI bubble ( which, I argue, is basically the same thing ), but when you remove Anthropic and OpenAI, Amazon Web Services and Google Cloud go from exciting growth-engines to chernobyls of capital expenditure.  Without these two “startups,” AI revenues are catastrophically small — for example, Sandler estimates that Amazon Web Services will make a pathetic $8.5 billion in AI revenues in 2026, or roughly 25 times less than the $220 billion Amazon intends to spend this year. While Ju estimates that Google Vertex AI model platform ( which is one of the main ways that large enterprises integrate Anthropic’s models ) will pull in $28.3 billion in 2026, that’s still a little under $10 billion less than the $35.6 billion that Anthropic and OpenAI will spend on compute.  This needs repeating. Investors and the general public are being lied to. When you remove OpenAI and Anthropic, Amazon, Google and Microsoft’s capex has likely accounted for very little revenue growth, which means that if either or both of them die, the majority of capital expenditures and debt raised as part of the AI bubble have been a waste. So, let’s go look at the non-Anthropic/OpenAI part of that Barclays note, with each column representing 2025, 2026, 2027 and 2028, with the last three being estimates. For some context, in the year 2025, Amazon spent $131.8 billion in capex, or roughly 32 times Barclays’ estimates for non-OpenAI/Anthropic revenue — a number that barely improves with the full total ($9.6 billion) to 14 times.   If Amazon has its druthers and invests $220 billion in total capex in 2026, the (pathetic) $8.5bn in non-OpenAI/Anthropic revenue will be roughly 26 times smaller, or 7 times smaller when you use the full $31.6 billion in projected AI revenue for 2026. If your counterargument here is that “the gap is getting smaller each year,” you are a mark. $31.6 billion is $22.6 billion less than Amazon spent on capital expenditures in its last quarter , or roughly $18.4 billion less than it invested in OpenAI this year . Barclays’ estimates for 2028 have Amazon’s AI revenues — 75% of which are from OpenAI and Anthropic’s compute spend — at around $75 billion, four god damn years into the AI bubble.  Amazon will have, by 2028, likely sunk over $650 billion in capital expenditures into AI, all to earn (and this assumes OpenAI and Anthropic exist and can pay) a little over $171 billion in AI revenue, with the vast majority of it contingent on two entirely venture-backed startups. Similarly, even if UBS’ estimates come true, Google will have spent roughly $408.5 billion (including consensus estimates of $120.5 billion for the rest of the year) in capital expenditures to create an AI business that makes about $80 billion a year, with most of that coming from either selling Anthropic’s compute or access to its models via Vertex.  Microsoft is in the same position. Wells Fargo’s estimates have its AI revenues for FY2026 (which just ended) at around $34.5 billion, in a year where it spent $115.9 billion in capex, with $41 billion of that in the last quarter , or roughly $6.5 billion more than its entire estimated AI revenues for the god damn fiscal year.  I realize I’m being a little repetitive, but I need you to see that without OpenAI and Anthropic, Microsoft, Google, and Amazon’s AI revenues are absolutely pathetic, and are thus entirely-dependent on their compute spend. Let’s be serious, and take the absolute kindest read of UBS’ estimates, saying that Google’s Vertex AI platform will make approximately $22.5 billion in annual revenue, and assume, wrongheadedly, that it’s not near-entirely made up of demand for Anthropic’s models… Sundar Pichai, did you spend $288 billion god damn dollars to make an annual business that makes less revenue than YouTube ? We haven’t even talked about margins or costs or whether any of this is actually profitable, largely because it’s immaterial, as there is absolutely no way to read this situation as anything other than a historic failure! Andy Jassy, is that you? Get your country ass over here ! You did NOT just go out there and spent $429.5 billion god damn dollars to stand up data centers for a pair of companies you have to literally hand the money to them to pay you, did you? I’m gonna tell momma Jassy what you’ve been up to! She’s gonna paint your back porch red! Wait, what’s that? You just gave OpenAI $35 billion dollars ? Wasn’t that dependent on it going public or reaching AGI ? Are you kidding me man? It’s almost as if you realize that the only way your largest customers are gonna pay y’all is by giving them the money to do so!  Okay, all jokes aside, there’s very clearly a problem here with AI demand, in the sense that it doesn’t really exist without hyperscalers paying themselves to do so. When you look at these numbers, you see a brutal story of unproductive capex. Looking at Wells Fargo’s estimates, it doesn’t appear that Microsoft 365 Copilot is a meaningful business, hitting a meager estimated $3.859 billion for the entire fiscal year 2026 for a product that allegedly has 30 million paid seats , suggesting massive discounts and questionable value. Wells Fargo estimates it’ll grow to an unremarkable $10 billion in annual revenue in FY2027 — barely more than OpenAI is estimated to spend in Q1FY2027.  This is an embarrassing accident of an industry with two ticking time bombs underneath it. There’re really two scenarios: And, to be explicit, the last part of that sentence is exactly what’s going on. Microsoft, Google and Amazon are have spent over a trillion dollars in capex and equity investments specifically so they can create growth engines that are entirely-dependent on Anthropic and OpenAI, who are entirely-dependent on Microsoft, Google and Amazon to either (or both) feed them money or continually build them more infrastructure. However you feel about what I’m saying, these estimates also require OpenAI and Anthropic to keep growing at the rate necessary to keep up with expectations for Amazon Web Services, Microsoft Azure and Google Cloud.  The most important question is which part of the machine breaks first.  The wind cannot fall out of the sails OpenAI and Anthropic, as both of them have to keep pace to be able to pay for all this data center capacity, which would mean they would, across Amazon and Google alone, have to produce over $125 billion in 2027, which would require both the actual demand (from customers for inference and for training) to use that much compute and the means to pay for it (from venture capital and the hyperscalers themselves).   For this to be possible, both the demand for access to OpenAI and Anthropic’s models and the money to pay for the inference to serve it must be there to realize these revenues and to keep Google Cloud, Microsoft Azure and Amazon Web Services growing at historical rates. To even have a shot at doing that, compute capacity must come online fast enough, which is an open question in and of itself. As I covered a few months ago , AI data centers are some of the single-most ambitious construction projects in history, requiring massive amounts of capital, specialist talent , and materials , and execution that includes building decades’ worth of power infrastructure in a few short years, making them take anywhere from 18 to 36 months to complete. If capacity doesn’t come on fast enough, OpenAI and Anthropic can’t pay for it.   It seems very possible that the only reason growth hasn’t stumbled for Microsoft, Google, and Amazon is OpenAI and Anthropic’s compute spend and the ability to sell access to their models, which means that they may see their capital expenditures as existential.  It kind of makes sense. If they fail to build more and more data centers and continue to sink money into Anthropic and OpenAI, growth will slow across both their cloud platforms and associated services, as the two AI labs are the only real aggressive purchasers of AI compute, which makes up the vast majority of hyperscaler AI revenues. It’s a dangerous game. Without OpenAI and Anthropic, it’s clear that the underlying businesses of the big three hyperscalers are deteriorating, and that their AI plays are a catastrophic failure, because the sheer amount of cash they’ve required to date (and the even greater pile of cash they’ll need in the months and years ahead) demands an outsized return for years to come.  Apparently things are so dire that the only way to patch over slowing growth was to fund two giant startups beholden to massive compute contracts that feed venture capital dollars to hyperscalers in a circular motion that mostly equates to eating poisoned cardboard.  Things look great right now, as long as you avoid thinking too hard about what it means that so much of this revenue growth is coming from Anthropic and OpenAI, and that their other AI plays are producing the lowest end of double digit billions of revenue for something that has cost them over a trillion dollars, their free cash flow, and burdened them with hundreds of billions of dollars of debt, along with off-balance sheet liabilities now totalling over $1.35 trillion (including Meta). I can already hear the counter-argument that “Anthropic and OpenAI are the fastest-growing companies in history,” and I certainly hope you’re right, because there does not appear to be anyone else who wants to buy compute at their scale other than hyperscalers selling it to them and whatever weird also-ran bullshit Mustafa Suleyman, Demis Hassabis, and Alexandr Wang will be allowed to do until one of the CEOs tries to make them the fall guy.  I really need to be as clear as possible: the current consensus view on AI is entirely divorced from reality. Based on what I’ve shared with you today, it is ridiculous to suggest that hyperscalers are building data centers under the belief that they will make a lot of money or that demand exists. They may believe — or hope — that’s the case, but that doesn’t make it true.  Outside of OpenAI and Anthropic, there appears to be less than $30 billion dollars of non-AI lab compute demand across Amazon, Google and Microsoft. I need to also be clear that this is almost certainly an overestimate, because it includes revenues from Azure Foundry, Amazon Bedrock, and Google Vertex, which includes both compute and API spend on Anthropic and OpenAI’s models. This means that we are likely overbuilding data center capacity at the scale of hundreds of billions of dollars. As the largest providers of AI compute with the most experience and the biggest brand recognition, it’s hard to argue that there’s pent-up AI demand waiting elsewhere that hyperscalers haven’t realized. If anything, it suggests that everybody else is completely and utterly fucked. Perhaps you’ll argue that the analyst was wrong or that my analysis is wrong or that demand will magically appear, and you’re welcome to if you want to continue burying your head in the sand. Let me spell it out for you: if Anthropic and OpenAI each had a run rate of $100 billion, they would still not have the scale to generate the compute demand to cover what their commitments are to Microsoft, Google, Amazon, and, of course, Oracle. And CoreWeave . And Cerebras . And Cipher Mining and TeraWulf . And IREN . And Nebius . And Broadcom . And AMD . And SpaceX . And maybe Meta , SB Energy , and whoever might build a $30 billion data center in Georgia . While some of these — like Cipher, IREN, Nebius and TeraWulf — will flow revenue directly to Google Cloud or Microsoft Azure, there’s still tens of billions of dollars’ worth of compute revenue that needs to get paid somehow above and beyond OpenAI and Anthropic’s spend on the major platforms. This is not sustainable. In fact, it’s pretty fucking awful. Let’s also be blunt about something: neither OpenAI nor Anthropic have worked out their business models. You can fart around claiming that Anthropic was profitable ( it wasn’t ) for a single quarter or repeat theoretical mantras about “positive gross margins” or say “they can just stop training” all you want. These companies lose tens of billions of dollars, they are horrendously unprofitable, an[d at this time do not have an actual answer to “how do these businesses function without infinite resources?” Even if they were somehow profitable — which they are not! — they would still need to grow at an impossible rate. Putting aside all of the estimates from this piece, OpenAI projects to spend $750 billion in compute in the next three-and-a-half years , which either means it will need to grow its revenue to hundreds of billions a year very soon or raise half a trillion dollars or more over the next few years , at a time when even hyperscalers are having trouble raising that much money .  And based on both these estimates and the massive amounts hyperscalers are spending on capex, I think they’re well aware that there isn’t diverse demand, and that the only path forward is to continue building capacity specifically for OpenAI and Anthropic, funding them in whatever way possible — either through backstopping the compute costs or helping organize massive private credit deals — to make sure that revenue growth never slows. This is a doomed mission.  These estimates show that Microsoft, Google and Amazon do not have meaningful AI business outside of the ones they’ve incubated, at least not ones that will pay off their capital expenditures. Consensus estimates for Microsoft’s FY2027 capex are around $186 billion in a year where its non-OpenAI/Anthropic AI revenue is expected to be $18.7 billion, meaning that even if these services had 100% net profit margins (IE: zero costs), it would take a decade of those revenues to pay back the capex.  While you might argue this is unfair — especially as OpenAI and Anthropic are unlikely to die before the fiscal year ends — it is time to start seriously discussing what happens to hyperscaler revenues once they do so. Put another way, investing in Microsoft, Google, and Amazon as part of the AI trade is an investment in Anthropic and OpenAI’s ability to both survive and grow to become companies of comparative size and revenue growth as their hyperscaler progenitors.  It is clear based on the estimates I’ve shown today that the vast majority of growth in AWS, Google Cloud and Microsoft Azure comes from two companies that can literally not afford to pay their bills.  Jensen Huang has said that he has visibility into $1 trillion in GPU sales through the end of 2027 , or, as I estimated, about 40GW of compute capacity requiring $435 billion in annual revenue. Though these estimates do not specifically break out compute demand from Bedrock, Foundry or Vertex, the combined AI revenues — including Anthropic and OpenAI’s compute spend, all API spend run through the platforms, and Microsoft 365 Copilot — for their fiscal years 2027 sits at around $304 billion, with the vast majority of that (around $197 billion) coming from AI lab compute spend. There is not enough demand. We are overbuilding data centers. If compute demand existed to justify the amount of data center capacity being built — or even close! — then analyst estimates for AI revenues would be both significantly higher and meaningfully diverse rather than centralized around two unprofitable, unsustainable companies.  To be specific, for any of this to “make sense” we’d need to see multiple different companies or groups of companies spending comparable amounts to OpenAI and Anthropic, dramatic amounts of revenue generation from Google Workspace and Microsoft 365, and revenue diversity driven by multiple customers spending billions or tens of billions of dollars at the very least in estimates for 2028.  It’s also likely much worse than I’m explaining because of how the big three bundle every single imaginable AI service inside Foundry, Bedrock, and Vertex, all of which blend direct GPU rentals with API spend on models from Anthropic and OpenAI, which I believe generates a large majority majority of revenue on these platforms rather than diverse interest in renting AI chips or other models.  Microsoft, Google, and Amazon are selling their investors a lie about their AI strategies, and in a properly-regulated market would be forced to file investor disclosures that document the heavy revenue concentration of Anthropic and OpenAI’s compute spend.  In not doing so, they continue to mislead investors and the general public into believing that hyperscalers are funding the next great growth engine in tech, when what they’ve actually done is spend a trillion dollars in capex and investments to make tens of billions of dollars of revenue, much of which came from their own equity investments. And in doing so, these hyperscalers have mangled their balance sheets, tripling their PP&E , encumbering themselves with over $500 billion in data centers and GPUs that exist mostly to support two companies that can’t afford to pay their bills long term. At the end of this hype cycle, Microsoft, Google and Amazon (and, I guess, Meta) will have left themselves in a much-worse condition than before, with revenue expectations that are overwhelmingly inflated by two unsustainable companies. As I wrote in the Rot-Com Bubble two years ago , these companies are fundamentally out of hypergrowth ideas, and these analyst estimates confirm my absolute worst fears about the condition of these companies.  AI is not working. A $10 billion or $30 billion-a-year business is not sufficient to justify either the massive capital expenditures or scars on hyperscaler balance sheets. In fact, it’s kind of hard to imagine what that might actually be at this point, because Google, Microsoft and Amazon continue to spend somewhere between $170 billion and $230 billion a year in capital expenditures, and each time they do so, they increase the size of the payback necessary.  At this point, AI would need to become — and this is without OpenAI and Anthropic — a business at the scale of Amazon Web Services ( $170 billion , though this number is inflated by OpenAI and Anthropic’s compute spend), Google Search ($200 billion), or at the very least Azure ($100 billion, again inflated by both AI labs’ compute spend) to make sense, and even then, for this to make sense, hyperscalers would have to stop spending money on capex.  Put another way, AI bets cannot “pay off” if hyperscalers continue to funnel three or more times their AI revenues every single year into capital expenditures.  I haven’t even gotten into the other vicious cycle — that the more of these data centers hyperscalers build, the more expensive they become thanks (at least, in part) to the skyrocketing costs of memory that continue to increase primarily because hyperscalers keep buying servers for their AI data centers. As discussed last week, this only increases the amount of debt they’ll need at a time when the market is getting increasingly nervous about AI data center debt . Yet as we speak, the market is ripping, because hyperscalers have swindled investors, the media, and even the analysts themselves. Article after article after article claims that AI bets have “paid off” because these companies are glazed any time they inflate their earnings using the compute spend of two unstable and unsustainable companies, in part because hyperscalers both refuse to and face no pressure to share their AI revenues, knowing that they’ll get credit as long as the topline numbers look good. I want to be clear that the air is coming out of these companies, no matter how good these earnings may look.  Everybody is taking the growth of their existing businesses and two AI labs’ compute spend as proof that all this capex is paying off, even though there is now consistent proof that the direct opposite is happening, and that their businesses are becoming increasingly-dependent on that compute spend.  I understand that nobody really wants to think about the logical endpoints of what I’m arguing, so I’m going to do it for them. To put things really simply, Anthropic and OpenAI are a way that hyperscalers can feed their revenue to themselves by spending money on capex, backstopping compute contracts, or doing direct equity investments.  Their continued existence allows the AI bubble to continue inflating, but this can only continue as long as venture capital and hyperscalers are capable or willing to invest. There is simply not the demand — not from open source, not from other AI labs, not from self-hosting, not from anywhere — to justify the capex or the massive data center buildout. And for those arguing that there would be a dot-com bubble recovery story, I must be clear that if there isn’t demand today, it won’t magically appear tomorrow. AI GPUs will cost just as much to run in five years as they do today, as will unfinished data centers cost just as much to finish, as will electricity remain expensive, and all this will be happening after it’s easy to raise venture capital to actually buy the compute.  To quote my buddy Kasey , every major cloud compute provider is solely standing on OpenAI and Anthropic.  OpenAI and Anthropic are time bombs, and when either of them explodes, everybody will ask why we didn’t see the brutality that follows coming. The truth is that nobody wanted to look.  To stare at these numbers and reconcile with their meaning is to acknowledge that the current state of the tech industry is based on mania, deceit, circular financing, and outright cons, and that the ascent of NVIDIA was primarily driven by three companies building compute capacity for two unsustainable companies that became existential to their growth, inspiring hundreds of billions of dollars of waste by obfuscating how little real demand existed. I realize it’s difficult to think about scary things, and how easy it is to dismiss me as a doomer or a catastrophist, but mine is a logical and rational argument in an era poisoned by hype and grifting at a scale unseen in history.  The greatest lie of this era is that the tech industry is building the next industrial revolution, when what they’re actually building is a monument to everything that’s wrong with modern capitalism — wasteful expenditures disconnected from any real benefits generated as a means of pursuing growth at all costs , setting up a collapse that will tear a hole in the tech industry and the markets, and leave the world full of half-built monoliths sold to local communities as job creators.  The fact we’re talking about compute futures is a joke. The fact we’re talking about AI factories is a joke. Almost every aspect of the AI bubble is a joke, and in the end, investors and the general public will be the punchline. The rich will have gotten richer, the banks will have harvested fees, the hedge funds will have traded and taken profits, the private credit funds will have gotten their fees, and anyone who didn’t have an active inside track will be fucked. All of this could’ve been avoided, but the world has a cult-like obsession with the wealthy, believing that the CEOs of the largest companies in the world could never make a bad decision, and that any executive is automatically smart by virtue of being rich and powerful.  And oh, how silly that’ll look in retrospect. If you liked this piece, you should subscribe to my premium newsletter. It’s $70 a year, or $7 a month, and in return you get a weekly newsletter that’s usually anywhere from 10,000 to 18,000 words, including vast, detailed analyses of the biggest events and companies in the AI bubble. If 73% of Amazon, Microsoft and Google’s AI revenues are from OpenAI and Anthropic, and analysts believe that this concentration will only grow in the next few years, that means there is not really that much demand for AI, and what demand it has is from two companies that they have sunk a combined $77 billion in funding into — far outpacing the actual revenue contribution that these companies provide, let alone the capex spending of the hyperscalers. This revenue also represents a meaningful slice of Google Cloud, Microsoft Azure and Amazon Web Services’ revenue, suggesting that leading cloud platforms are not growing as fast as investors have been led to believe. If 27% of all of 2026 and 48% of all of 2027 Google Cloud revenues are from Anthropic and OpenAI, that means that Google Cloud’s growth has or will potentially stall in the next year when you remove their compute spend. If there were real, meaningful demand for AI compute or AI services, we’d see it in these estimates, much like we’d see if there were other companies spending massive amounts on AI. Anthropic and OpenAI, who represent the near-totality of AI demand and revenue both as a vendor and a supplier, are perpetually held up by the venture capital industry and hyperscalers, at whatever cost that is and to what lengths it requires complete financial fealty, to degrees of circularity unseen in history,  One day, one or both of Anthropic and OpenAI die, which leads to half or more of the demand for AI compute and actual industry production evaporating, and any further ability for Google, Amazon and Microsoft to further feed themselves money.  Based on everything I’ve said today, Microsoft, Google, and Amazon’s cloud businesses are clearly incapable of delivering the kind of high growth that Wall Street analysts like, and they’re using both Anthropic and OpenAI’s compute spend and selling their AI models as a means of covering that up. This is a tangible sign that these companies are approaching their golden years, turning from hypergrowth vehicles into boring, slow-growth mainstays. The problem with this is that they’ve raised debt and spent capex at a level that requires their businesses to grow at dramatic rates, and said growth was only made possible by inflating revenues using equity investments and two AI labs incubated by the hyperscalers themselves. Without these two companies — and, to be clear, without these two companies becoming much, much larger — hyperscalers do not have meaningful AI revenues in comparison to their capital expenditures, making a payoff near-impossible based on every estimate I’ve read. This means that without these AI labs, they have very little to impress Wall Street with, and without AI itself, their businesses are increasingly-stagnant and dependent on a pro-monopoly regulatory environment and the ability to continually increase prices. All of this is to say that I believe hyperscalers are on the decline. There is not enough demand for AI compute, which means that we’re in an incredibly-large overbuild of AI data centers that are predominantly funded by project financing that can only pay investors back if the data centers actually receive revenue . This means that the vast majority of data centers will go unpaid, and those that do — and man, I am not confident there’s more than a few billion dollars of non-AI lab demand — are likely dependent on unprofitable AI startups or hyperscalers that don’t have much demand outside of the largest AI labs. Though some might challenge me about the scale of the problem, there are hundreds of billions of dollars’ worth of AI data center loans, and I believe the vast majority of them will go unpaid. This will hit bank balance sheets and private credit funds to indeterminate levels. This means that investments in CoreWeave, IREN, Nebius, Cipher Mining, and any other neocloud are effectively bets on Anthropic and OpenAI, or on hyperscalers’ continued interests in backing them. As there is not enough significant non-OpenAI/Anthropic demand for AI compute, this means that earnings for NVIDIA, Broadcom, and effectively any other semiconductor company are inflated by what amounts to speculative purchases of assets, which could eventually lead to impairments or restatements of earnings, and will certainly lead to a drop in growth once the cat is out of the bag.  This is why NVIDIA continues to do such blatantly-circular deals, especially with OpenAI, and why neoclouds continue to sign deals with hyperscalers and OpenAI/Anthropic. Without them, demand doesn’t exist at a scale that would justify their existence. OpenAI and Anthropic are both separately load-bearing companies. If either or both of them die, 40% to 73% of all AI revenue and compute demand evaporates.  While they would likely still exist as shell entities — and hyperscalers would continue to sell access to models — their deaths would kill the ability for Microsoft, Google and Amazon to monetize their ever-expanding compute infrastructure, and would immediately begin ripping giant holes in their gross margins. The value of Anthropic and OpenAI to Amazon, Google and Microsoft is that they can continue to sign big compute deals without ever exposing hyperscalers to their actual underlying economics. This makes any kind of merger or acquisition somewhat useless. As Nik Suresh argued , a great deal of demand for AI services or subscriptions comes from peer pressure and a near-religious attachment to theoretical productivity benefits, most of which would be hard to justify if either of these companies died. This would leave very little to recover post-bubble.

Shell Programming

▲ 0

0 views

Kev Quirk 2 days ago

📝 2026-08-04 15:43: Thinking about selling the 64GB RAM from my laptop and paying off my mortgage...

Thinking about selling the 64GB RAM from my laptop and paying off my mortgage... Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️ You can reply to this post by email , or leave a comment .

Finance Hardware

▲ 0

0 views

Unsung 2 days ago

“Some guy named Paul”

An interesting 20-minute Config talk from the Instagram designer Rose McManus: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/some-guy-named-paul/yt1-play.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/some-guy-named-paul/yt1-play.1600w.avif" type="image/avif"> It covers some of the same areas we recently talked about: diacritics and Polish S (and a fun video about English conventions from a while back ), but it tackles them on a higher level. McManus talks about how people express themselves via their usernames, how that changes in various countries of the world and for what reasons, how it intersects with some UI considerations, and how people use it creatively – and also, sometimes, abuse it. This is the K-pop star IU. Uh her Instagram handle is “dlwlrma.” And I think at first this maybe seems already like complete hyperreality, like it’s bearing no relationship with her Hangul name, or even with her stage name. But actually, I think this is at the third stage of Baudrillard’s theory because really “dlwlrma” is Lee Ji-eun’s Hangul name typed out on a Korean keyboard but backwards, distorted, while that keyboard is set to render Latin characters, almost like a cipher. And then her display name is her Hangul name typed out with one of the characters changed, so it’s like a pun. I didn’t feel the talk stuck the landing – in the end, I wasn’t very sure why the decision that was made was made. But there’s a whole lot of stuff before that was fascinating and thought-provoking. #conference talk #localization #youtube

Culture Design Media

▲ 0

0 views

Dangling Pointers 2 days ago

Bonsai: Compiling Queries to Pruned Tree Traversals

Bonsai: Compiling Queries to Pruned Tree Traversals Alexander J Root, Christophe Gyurgyik, Purvi Goel, Kayvon Fatahalian, Jonathan Ragan-Kelley, Andrew Adams, and Fredrik Kjolstad PLDI'26 File this under: “so elegant, why wasn’t this discovered sooner?” This paper describes a generic language (Bonsai) and compiler for efficient tree traversals. The language is structured such that a simple compiler can quickly generate efficient code. The examples from the paper fall into two buckets: SQL-like queries and spatial data structures. Here is some example code from the paper which describes a SQL-like operation on a set of points: A is a structure with two elements ( , and ). The function returns the minimum associated with any point that has an x value within the range . And here is an example from the paper which describes a ray tracing function: The function finds all triangles which intersect a given ray and returns the one that is the closest to the origin of the ray. The key point of the paper is that both types of functions can be implemented as tree traversals. A key design point that makes Bonsai feasible is metadata stored in the trees which represent sets. Tree metadata is specified separately from queries. The following snippet from the paper contains a tree data structure represented as an algebraic data type: A set of points is represented as a tree. Leaf nodes hold points. Interior nodes have pointers to and children, and four pieces of metadata ( ). The keyword is used to describe the meaning of the metadata. The expression means that the value of all x fields in all points contained in the subtree lies within the range . The expression means that the minimum value of the field in any point in the subtree is . The Bonsai compiler takes a query and a description of the tree metadata as input and generates C++ code to perform the query via traversing the tree. There are three key properties of this process. The first is that the generated code for all filter and reduction operations are fused together. In other words, there are no intermediate trees (i.e., sets) produced during query execution. Secondly, tree metadata is used to accelerate both filtering and reduction operations. For filtering, the generated code checks tree metadata to determine if all data elements in a subtree will be accepted by the filter, or if all elements will be rejected by the filter. If all elements will be rejected, then there is no need to traverse the subtree. If all elements will be accepted, then there is no need for further evaluation of the filter expression for the subtree. In this case, traversal into the subtree can be skipped if the root of the subtree has metadata containing a pre-reduced value ( in the example above). Fig. 4 shows IR corresponding to two filtering examples. In both examples, there are two types of leaf nodes in the tree. nodes contain a single value whereas nodes contain an array of values. Fig. 4a shows the IR for a single filter expression . Here is the code, annotated with some comments to describe the semantics: Fig. 4b shows the IR for the logical and of two filter expressions: : Code generation tracks a symbolic interval associated with each expression. An interval is represented by two expressions: one that evaluates to the lower bound of the expression and one that evaluates to the upper bound. This interval analysis is used to produce the code that implements and . Interval analysis is fast to compile but can produce code that suffers from false positives. Symbolic interval analysis is general enough to handle spatial filters (e.g., those used in ray tracing). Fig. 7 compares Bonsai to a state-of-the-art library ( FCPW ) for geometric queries: Source: https://dl.acm.org/doi/10.1145/3808256 Fig. 8 compares Bonsai to relational databases for range joins. The range join logically computes the Cartesian product of two relations, and then removes elements from the result which are not near each other according to Manhattan distance . Source: https://dl.acm.org/doi/10.1145/3808256 Dangling Pointers A logical extension of this process would be to automatically determine what tree metadata would be most useful for a set of queries. Thanks for reading Dangling Pointers! Subscribe for free to receive new posts.

Programming Sql C++

▲ 0

0 views