Latest Posts (20 found)

On people writing about their use of AI

I find the trend of people posting about the way they use generative AI to be fascinating at an anthropological level. I do not remember the last time a piece of technology pushed so many different people into writing about the way they use it, or not use it, or abuse it, or misuse it. To me, this is way more interesting and intriguing than the technology itself. I obviously do not know why so many people are doing so, and I suspect they must all have their own specific reasons, but I currently have three main theories but I’m sure there are more than that. The first theory is that a good percentage is trying to capitalize on the trend in an attempt to become some sort of AI thought leader. Those people are insufferable. They usually hang out on LinkedIn, but sometimes they escape containment, and they remember that they do have a blog (and that’s often a Substack, unsurprisingly) where they can post these generic-looking blog posts filled with lists and it’s-not-this-it's-that statements. The second theory is that techies are gonna tech. A lot of the people who have blogs are also into tech, and gen AI is an interesting piece of tech and so it’s natural that those people will end up writing about how they use AI. The third and final theory is that there’s a group of people who feel the need to distance themselves from what AI represents. So those posts are not really about the technology itself, but rather a statement on the state of the world around them, and they want to make it clear if and how they participate in it. This final group is to me the interesting one. Now, if you’re a techie, don’t be mad at me, I’m not saying you’re not interesting, because you are (if instead you’re an AI bro, click here . You're welcome.) I’m saying the last group is the interesting one because to me, it’s fascinating how people feel compelled to justify or explain to strangers on the Internet how they interact with a piece of technology. And it’s especially fascinating because it’s a completely pointless exercise in my opinion. Let’s pretend you just landed on my blog for the first time (hi, welcome, nice to have you here) and you have no idea who I am. For all you know, I might not even be a real person. This entire website could be a psyop run by the Italian government. With that in mind, what’s the value of a post in which I tell you how I use or not use AI from a moral perspective? Would it make a difference if I were to tell you that I don’t use it? Or that I use it maybe once a day to answer a coding-related question? What if I told you that I don’t use AI at all, but in reality, this post was entirely generated by a swarm of AI agents while I was outside walking the dog, enjoying life? Unless you have prior knowledge of me and this blog, a post like that, in a vacuum, would be meaningless. How about the opposite case, though? Let's now pretend you weren’t new here, and you had, in fact, been following this blog since 2017. If that was the case, you wouldn't even need me to write that blog post, because by this point, you’d have all the necessary information to make an informed judgment. And you’d also know that you could ping me via email or via DM and ask me directly if you had any doubt about anything related to this topic. In both cases, a post stating my use of AI would have pretty much zero value. Which genuinely makes me wonder why so many people feel compelled to write about this stuff. If you wrote one of these posts, can I ask you why? Why do you feel the need to explain how you use this technology? Is there a specific reason? I’d love to know. Thank you for keeping RSS alive. You're awesome. Email me :: Sign my guestbook :: Support for 1$/month :: See my generous supporters :: Subscribe to People and Blogs

0 views

Google just spat in my face

It’s Google I/O week and this year’s theme is performative slop . Budding Googlers battle it out on stage vying for executive eyeballs. The prize? Exemption from the next culling . As you might know AI isn’t my cup of tea and my AI policy explains why. AI peddlers like Google have made one thing abundantly clear: their product will take your skills. It will take your profession. It will dehumanise you and you’ll pay for it. I figured Google’s Prompt API would be the most offensive attack on an open web I’d witness this month. Nope! Google’s new microsite has sent me apoplectic. Modern Web Guidance is a set of evergreen and expert-vetted skills that guide your AI coding agents across many common use cases to build modern web experiences that are accessible, performant, and secure. Build with Modern Web Guidance At first glance this is nothing more than an advertisement for the AI industrial complex. I made the mistake of engaging my brain for a closer look. Brain engagement is discouraged so I only have myself to blame for the ensuing rage. Google spits in the face of professional web development. Where do I even start? The repeated use of “modern web” implies that current development practices are out of date. Throw away all established knowledge because Google has changed the game . The entire chat-box-driven-development craze has been a long series of “you’re prompting it wrong” arguments. Are we to understand that Google’s new magic incantations have settled the debate once and for all? Which experts? Google, I assume. You are no longer an expert. You are token consumer number six. Expertise are not a privilege extended to consumers. Forgive my ignorance but I struggle to understand how AI addicts define “skills”. From what I can understand these “skills” are text prompts? “Skills” used to refer to the trained abilities required to do a professional job. I’m no prescriptivist but this is slopaganda. Google’s idea of “modern web” is a deskilling effort that should deeply offend developers to their core. It should also offend the AI apologists. Google thinks you’re too stupid to articulate your prayers coherently so just copy-paste the ten commandments. Defer to the almighty bullshitter in the cloud! What do you think a fair wage is for a professional developer who has less agency than Butter Bot? They’ll say this “democratises” web development alongside all and every profession in which AI has been violently forced . And what is the end goal? To deskill you so far down the ladder you’ll be forced into token servitude. To make a handful of billionaires even richer. Prompt boxes are not “just a tool” they are the end of your career. Implement a starter Content Security Policy (CSP) without breaking my app. Don’t break it bro! Pinky promise? Thanks for reading! Follow me on Mastodon and Bluesky . Subscribe to my Blog and Notes or Combined feeds.

0 views

How many app SDKs did Publicis add with LiveRamp acquisition?

I decided to check AppGoblin to see how many apps LiveRamp had when Publicis acquired it for $2b, the answer seems to be ~300 mobile apps out of the top 200k apps. This is based on apps found with the LiveRamp SDKs. The apps also have a particularly, older vibe to them, looking at some of the larger apps we see apps like Flipboard, Badoo and Skout using LiveRamp. The monthly installs here are likely even too high, as they are still based on some adjustments Google Play made to install counts in April that boosted many apps’ lifetime installs. Looking at the trend of market share for LiveRamp , as AppGoblin has crawled more and more apps over the past year, the marketshare for LiveRamp seems to have remained quite small and stead at ~0.13%. There was a ‘high growth’ but it was at the beginning of the data period, so this is was unlikely to be a true high growth period for LiveRamp. Overall I was surprised that the LiveRamp data was so little, though given the name brand of some of these apps, perhaps the LiveRamp deal is much more about online sites than it was mobile properties.

0 views
(think) Today

nREPL Forever

Last week I announced Port , a small prepl client for Emacs. That post focused on Port itself, but writing it left me with the itch to do a follow-up on the bigger picture, because the socket REPL / prepl story is one I’ve been meaning to write up for years. If you’ve been around Clojure long enough, you remember the chatter. Socket REPL landed in Clojure 1.8 (January 2016), prepl in Clojure 1.10 (December 2018), and for a couple of years there was a steady stream of posts, tweets, and Slack threads to the effect of “this is what we should be building tools on. nREPL is on the way out.” Some serious people put their weight behind that idea, and some of them went and built tools to prove it. Now it’s 2026 and we can take stock. The pitch was good. Socket REPL is just the Clojure REPL exposed on a TCP port. prepl wraps it with a structured printer so the bytes coming back are EDN-tagged maps ( , , , ) instead of a human-readable prompt. Both ship with Clojure itself. No external server library, no middleware, no third-party namespaces. You start a JVM, you bind a port, you’re done. The intellectual case for moving off nREPL had been made by Rich Hickey himself, most clearly in a March 2015 clojure-dev post that’s worth reading in full. Rich didn’t actually attack nREPL by name in that message. What he did was argue carefully for what a REPL is : a thing that reads characters, evaluates forms, prints results, and loops, with those streams available to user code so that things like nested REPLs and debuggers compose naturally. The money line: While framing and RPC orientation might make things easier for someone who just wants to implement an eval window, it makes the resulting service strictly less powerful than a REPL. His proposal, in the same post, was that tools should open multiple connections to the running program: one for the human-facing stream, and dedicated channels for IDE operations. The socket REPL (which landed in 1.8 the following January) and prepl (which arrived in 1.10) were the official implementation of that worldview. A handful of editor projects took the cue and built clients: It was real momentum. If you were following Clojure tooling in 2018-2020, it genuinely felt like nREPL might be the past, and the future would be some combination of socket REPL plus a thin self-installing protocol on top of it. You can find a fair number of “RIP nREPL” hot takes from that period if you go looking. I went and surveyed each of those projects recently while working on Port. The pattern is depressingly consistent: Tutkain started on prepl. In November 2021, its v0.11 release explicitly stopped using prepl message framing and switched to a hand-rolled EDN-RPC protocol that Tutkain boots onto the raw socket REPL by sending it a base64-encoded blob. The new protocol has request ids, op dispatch ( , , , , , , …), and server-managed thread bindings. In other words: Tutkain grew into nREPL, just spelled differently. Chlorine never used prepl directly. It used socket REPL plus an -style upgrade blob. Its author’s successor project, Lazuli , abandoned the whole approach in favor of nREPL. The post-mortem is worth reading and is fairly blunt: tools that attempted prepl went back to nREPL because, honestly, it’s simply better. Conjure had a prepl client in its early Rust days. The current Lua/Fennel rewrite ships only an nREPL client. The author’s reasoning in the release notes was that nREPL “has complete ecosystem adoption and brilliant ClojureScript support.” Clojure-Sublimed technically still talks to a raw socket REPL, but only after sending it an EDN-printing prelude that upgrades the REPL to a structured protocol of tonsky’s own design. His post on the topic is one of the most thoughtful pieces I’ve read on Clojure REPL design, and his conclusion is roughly: the bare socket REPL is more useful than prepl because you can install your own protocol on top of it. Which is true. But notice that everyone who reached that conclusion ended up reinventing the same wheel: ids, ops, request/response correlation, completion support, lookup, interrupts. You know, the things nREPL has had since 2010. So the trajectory looks roughly like this: Pure prepl clients are nearly extinct in the wild. The one I found that qualifies is propel by Oliver Caldwell (of Conjure fame), which is delightful, about 70 lines of Clojure, and explicitly synchronous (one outstanding eval at a time). That works! But it’s not a foundation for the kind of feature set people expect from an editor. Here’s where I land. Rich isn’t wrong that prepl is closer to a “real” REPL in the strict sense. prepl genuinely is a more faithful encoding of read-eval-print: each form goes in, each result comes out, and the semantics match what you’d get at the standard REPL prompt. The thing is, “real REPL” is not the property you optimize for when you’re building editor tooling. The properties editor tooling actually needs are: nREPL was explicitly designed for those properties. The ops, middleware, and transport abstractions exist precisely because the people building it knew the consumers are not humans typing at a prompt, they’re programs negotiating a session. Calling nREPL “not a real REPL” is technically defensible and practically beside the point. Nobody on the consuming end is confused about what nREPL is for . I wrote about nREPL’s revival in 2018 . At that point I had just finished migrating the project out of Clojure Contrib, and the goal was to give it a real home and a working development process. It was a lot of work, but in hindsight things played out pretty well. Looking at where things ended up: Meanwhile prepl is, as best as I can tell, mostly a curiosity. It got me a side project I had fun with. It did not displace nREPL. The history of tooling protocols is full of cases where “purer”, “simpler”, or “more elegant” lost to “shipped, documented, and battle-tested.” LSP beat fifteen ad-hoc language protocols. DAP beat the same fifteen debuggers. nREPL beat prepl in the (Clojure) editor space. It’s not that the simpler thing is bad. prepl is a fine, elegant little protocol, and there’s a real case for embedding it in CI scripts, ops automation, deployment pipelines, or anywhere you want to drive a Clojure VM programmatically without pulling in a server library. Use it there. But for editor tooling? The Clojure community made an enormous, multi-year, multi-tool investment in nREPL. We have the protocol, the middleware, the manual, the books, the conference talks. nREPL works, it’s actively maintained, it’s increasingly portable across Clojure dialects, and the design decisions that Rich called out as un-REPL-like are the exact ones that make it a good substrate for editors. So I’ll say what I felt awkward saying back in 2018: nREPL forever. It’s the right abstraction for the job, and it’s not going anywhere. One more thing. After finishing Port I got curious what a minimal nREPL client would look like by comparison, so I went and built one. As you can imagine, it turned out to be significantly simpler. If that sounds interesting, take a look at neat , a small, language-agnostic nREPL client for Emacs. Keep hacking! Tutkain for Sublime Text Chlorine for Atom Conjure for Neovim (in its early Rust incarnation) Clojure-Sublimed by Nikita Tonsky a steady drip of smaller experiments around , , and friends Editor decides nREPL is too heavy or an undesirable external dependency and starts on prepl. Editor discovers prepl has no ids, no ops, no interrupts, no server-side completion, no namespace tracking, no test runner integration, etc. Editor rolls a custom protocol on top of socket REPL, or… Editor gives up and goes to nREPL. A way to correlate a request with its response when output and results are interleaved. A way to multiplex – one connection, several logical conversations. Server-side hooks for the operations every IDE expects: completion, lookup, go-to-definition, find-references, test running, stacktrace structuring, interrupt. A protocol stable enough that ten different editors can target it without each one inventing its own dialect. nREPL itself is healthier than it has ever been. Active maintainers, a proper manual , a steady release cadence, an actual ecosystem organization on GitHub. Most popular Clojure editors support it. CIDER , Calva , Cursive (via its own client), Conjure, vim-iced , you name it. babashka ships with nREPL built in. You boot a and you get an nREPL server, no extra dependencies. That’s how a lot of people use nREPL in scripting contexts today, and it’s been a hit. basilisp (the Clojure dialect on Python) has nREPL support . nREPL running on Python, talking to Emacs, evaluating Clojure. Nice. ClojureCLR has a working nREPL story now, and jank (the C++ Clojure) has nREPL on its roadmap too. The middleware ecosystem ( , , , , , …) is alive, well, and continues to add features.

0 views
(think) Today

neat: a language-agnostic nREPL client for Emacs

I think I’ll take my REPL neat My parens black and my bed at three CIDER’s too sweet for me… Last week I announced Port , a small prepl client for Emacs. Today I’m following it up with another small Emacs package. Meet neat , a tiny, deliberately language-agnostic nREPL client. For years I’ve been hearing some version of the same request: “could CIDER work with my non-Clojure nREPL server?”. Babashka, Basilisp, nREPL-CLR, even some homegrown servers people built on top of nREPL for languages I’d never heard of. 1 The answer was always the same kind of squishy “sort of, in theory, with caveats”, because while bare nREPL is genuinely language-agnostic, CIDER is not. CIDER was built for Clojure and assumes Clojure pretty much everywhere. I always thought the right answer was “let’s gradually make CIDER more language-agnostic.” That’s the kind of plan that sounds reasonable until you actually try it. The thing that pushed me over the edge was, oddly enough, building Port. Port is small, focused, and doesn’t try to be CIDER. Working on it for a couple of weeks reminded me how (deceptively) productive it is to start from a clean slate when the new requirements don’t match the assumptions baked into a mature codebase. Trying to retrofit CIDER into a language-agnostic shape would have meant fighting with every helper that ever assumed exists, every middleware contract defines, every project-type heuristic that knows about and and nothing else. A whole lot of “is the server Clojure, or is it the other thing?” branches. The Port experience reaffirmed that the right move for a genuinely different client is a new project , not a thousand cuts to an existing one. So was born. The name is short, says what it does (it’s neat, both in the small-and-tidy sense and in the “no deps, no special assumptions, just the protocol” sense), and conveniently leaves room for puns I haven’t fully committed to yet. I might land on a backronym one day. For now it’s just “neat”. neat is a small Emacs nREPL client. The code is split across four files: It only uses Emacs builtins. There are no external runtime dependencies, not even on , because neat doesn’t assume Clojure on the other end. If you write , , , or anything else that talks nREPL, you turn on in that buffer and it just works. The connection routing is also intentionally library-friendly. There’s a buffer-local override so downstream packages can implement their own routing logic, plus a global default for the simple “one server at a time” case that most people will want. Capability discovery is done at connect time via the nREPL op. neat doesn’t hardcode “this server has completions, this one doesn’t” assumptions. If the server reports a op, the CAPF backend lights up (with type annotations next to each candidate, when the server provides them). If it reports , eldoc starts working and jumps to definitions via an xref backend. If neither is there, you still get a perfectly serviceable raw REPL. Start an nREPL server. Anything that speaks the protocol will do. For a Clojure server: Then in Emacs: A REPL buffer pops up, the prompt follows the server’s reported namespace, and you can type expressions at it. Multi-line input works because only submits when the form parses as balanced under (Emacs Lisp syntax by default, which is close enough for any Lisp). Input history is persisted across sessions. If there’s a file in the project, the prompt defaults to its contents, so is enough to connect. To evaluate from a source buffer, turn on the minor mode: The familiar bindings are there, intentionally compatible with what CIDER users expect: ships the buffer contents as an op; uses the standard op instead, so the server can attribute file and line numbers to errors. Use the latter when you’re actually loading a file from disk and care about good diagnostics. sets the buffer-local , which gets sent as the field on every op from that buffer. For languages where the namespace is declared in the source (Clojure’s , etc.), swap in a parser via . For juggling multiple connections, opens a tabulated-list buffer with one row per live connection, where you can set the default or disconnect interactively. That’s roughly the whole user-facing surface today. There’s no jack-in command, no inspector, no debugger, no test runner. Likely there will never be, but if you need those you should probably be using CIDER anyways… If you write Clojure and CIDER works for you, keep using CIDER. It’s mature, full-featured, and supported, and I’m going to keep working on it for as long as people use it. Nothing about neat changes that. But if you find yourself in one of these situations: then neat might be a better fit. It’s small enough that you can read the whole thing in an afternoon, and the library/UI split ( and are perfectly usable from other packages) is genuinely designed for downstream consumers. neat is part of a broader push I’ve been chewing on for a while now: making nREPL a healthy multi-language ecosystem rather than a Clojure-only protocol. That push has three legs: This is also why I keep teasing a “reference CLI client” in conversations. An editor client is one thing, but a small command-line nREPL client written in a non-Lisp language would be a much sharper test of how language-agnostic the protocol really is. neat is plausibly a precursor to that. Time will tell how far I push this; for now I just wanted to get the Emacs side moving. As always, big thanks to Clojurists Together and everyone supporting my open source work. You make it possible for me to keep tweaking and improving CIDER, nREPL, clj-refactor, and friends, and occasionally try something “neat” on the side. isn’t replacing any of the existing Clojure tooling for Emacs. It’s just another tool in the box for the people who want it. Feedback, ideas, and contributions are most welcome over at the issue tracker . Keep hacking! https://github.com/clojure-emacs/cider/issues/3905   ↩︎ For a long time I planned to extract CIDER’s nREPL client code into a reusable package, but now that we have I probably will finally abandon this idea.  ↩︎ : bencode encode/decode. : TCP connections, request dispatch, the standard nREPL ops. : a comint-derived REPL buffer. : the entry point, customization group, and minor mode for source buffers. you write a non-Clojure language whose runtime ships an nREPL server, and you’ve been muddling through with a half-supported CIDER setup, you write Clojure but you value minimalism and don’t need the full CIDER feature set, you’re building an Emacs package that needs to talk nREPL and you want a small, dependency-free library to build on, 2 An actual nREPL specification. The spec.nrepl.org draft is (will be) the formal version of what today is “whatever nREPL the project does”. Reference clients. neat is one. The point of building a deliberately Clojure-free client is that it stress-tests the spec. Anywhere neat ends up needing to special-case the server, the spec has a gap. A compatibility test suite. The parameterised integration suite in neat already runs the same assertions against multiple servers and surfaces real divergences (Clojure batching into a single message where Basilisp emits two, for example). I’d like to grow this into a portable suite that any nREPL server can self-check against. https://github.com/clojure-emacs/cider/issues/3905   ↩︎ For a long time I planned to extract CIDER’s nREPL client code into a reusable package, but now that we have I probably will finally abandon this idea.  ↩︎

0 views

Prompts are technical debt too

It’s common and correct to say that “all code is technical debt”. Adding code is a necessary evil for developing new features: you almost always have to do it, but each line of code adds to the complexity and maintenance burden of the system. All future changes to the system have to work with the existing code, or at least avoid breaking it. Once systems accumulate enough code, they become impossible for a single person to understand: instead of reading the code and understanding what it does, you must rely on guesses, theories and heuristics 1 . Sensible engineers write as little code as possible. They write a lot of prompts, though! Many large projects now have a set of codebase-specific prompt files: AGENTS.md, CLAUDE.md, those same files in sub-directories, and skills . If you’re building a program that uses AI 2 , you’ll have separate prompts for capabilities and for each tool , as well as a whole set of system prompts . Prompts are important. Minor tweaks to a LLM’s prompt can unlock significant performance improvements. If the same model feels different across Codex, Cursor, OpenCode, and Copilot, it’s almost certainly due to subtle differences in prompting. AI companies spend a lot of time testing and tweaking their prompts, so it makes sense why engineers would spend a lot of time tweaking their AGENTS.md files 3 for their projects. I’d even call switching tools or workflows to be a form of prompting. If I start wrapping my agents in a Ralph loop , pull in a new skill file, or install an MCP server, that’s still a change to my prompts even though I’m not the one who wrote it. I think it is a bad idea to spend a ton of time tweaking a bespoke agentic coding setup. Why is that, given that prompt adjustments can deliver a lot of value? Because prompt adjustments are model-specific . Earlier I said that AI companies spend a lot of time tweaking their prompts. In fact, they spend that amount of time for each new model release. A prompt that worked great for GPT-5.4 won’t necessarily work as well for GPT-5.5. You have to “learn how to hold the model” each time. In other words, a set of prompts that you carefully crafted in January this year might be out of date or actively harmful by February. Worse still, you might not even notice. Model capabilities are already so hard to pin down (unless you’re running every problem through different models and tools), and even weak AI systems are surprisingly good at some problems. You might just think “huh, the new Anthropic model isn’t as impressive as the hype”, or “wow, Claude Code has gotten worse recently”. In this sense, prompts are a worse form of technical debt than code . When technical debt blows up, it usually causes errors or a tangible slowdown as you try to understand the code. Prompts will decay silently. Also, even janky code tends to be relatively stable when untouched, but every single model upgrade could turn a functional prompt into a non-functional one. Could you simply decide not to upgrade models? Some people are trying this, but the pace of improvement is fast enough that that isn’t really practical. A delicately-prompted agentic harness built around GPT-4.1 is always going to underperform a bare-bones harness built around Opus 4.7. This might be a sensible strategy at some point in the future, when the rate of model improvement slows down (or when models are so capable that you don’t need the extra intelligence for normal engineering tasks), but I don’t believe it’s a good strategy today. In my view, most people should just be picking an AI coding tool maintained by a third-party company (Claude Code, Codex, Cursor, Copilot, etc) and leaving it as unconfigured as possible, so they can piggyback on the work of teams of engineers who are evaluating and tweaking prompts with each new model. Avoid MCP and skills unless absolutely necessary, and keep them off by default. At least this way if one of those teams gets it badly wrong, users will notice eventually and complain about it. When you write AGENTS.md files, try to avoid behavior steering (like the now-outdated “think step by step”, “you are a skilled engineer”, or “if you get a task right I will tip you $200”). Keep them limited to specific, concrete facts about the project. Don’t let models fill your AGENTS.md with pages of barely-reviewed text, for the same reason that you wouldn’t let them fill your codebase with pages of barely-reviewed code. Write your prompts yourself, and delete them whenever you get the chance. Almost every system you might get paid to work on is in this category (if not in the code of the system itself, then in its dependencies and libraries). Instead of just using AI to build a program. This distinction was a real pain when I was working on GitHub Models . Almost every system you might get paid to work on is in this category (if not in the code of the system itself, then in its dependencies and libraries). ↩ Instead of just using AI to build a program. This distinction was a real pain when I was working on GitHub Models . ↩

0 views

Gemini 3.5 Flash: more expensive, but Google plan to use it for everything

Today at Google I/O, Google released Gemini 3.5 Flash . This one skipped the modifier and went straight to general availability, and Google appear to be using it for a whole lot of their key products: 3.5 Flash is available today to billions of people globally: As usual with Gemini, the most interesting details are tucked away in the What's new in Gemini 3.5 Flash developer documentation. It mostly has the same set of platform features as the previous Gemini 3.x series, albeit with no computer use . The model ID is . The knowledge cut-off is January 2025, and it supports 1,048,576 input tokens and 65,536 maximum output tokens. Google are also pushing a new Interactions API , currently in beta, which looks to me like their version of the patterns introduced by OpenAI Responses - in particular server-side history management. Gemini 3.5 Flash is accompanied by a notable price bump. The previous models in the "Flash" family were Gemini 3 Flash Preview and Gemini 3.1 Flash-Lite . The new 3.5 Flash is 3x the price of 3 Flash Preview and 6x the price of 3.1 Flash-Lite (see price comparison here ). At $1.50/million input and $9/million output it's getting close in price to Google's Gemini 3.1 Pro, which is $2 and $12. The Gemini team promise that 3.5 Pro will roll out "next month" - presumably at an even higher price. This fits a trend: OpenAI's GPT-5.5 was 2x the price of GPT-5.4, and Claude Opus 4.7 is around 1.46x the price of 4.6 when you take the new tokenizer into account . Given the price increase it's interesting to see Google roll it out for so many of their own free-to-consumer products. It feels like all three of the major AI labs are starting to probe the price tolerance of their API customers. Artificial Analysis publish the cost to run their proprietary benchmark against models, which is a useful way to take things like tokenization and increased volume of reasoning tokens into account. Some numbers worth comparing: Running the benchmark for 3.5 Flash (high) cost significantly more than 3.1 Pro Preview! Here are some numbers from other vendors: I ran "Generate an SVG of a pelican riding a bicycle" against the Gemini API and got back this pelican, which is a lot : From the code comments: hedgehog on Hacker News : That pelican looks like it's in Miami for a crypto conference. That one cost me 11 input tokens and 14,403 output tokens, for a total cost of just under 13 cents . 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 . For everyone via the Gemini app and AI Mode in Google Search For developers in our agent-first development platform Google Antigravity and Gemini API in Google AI Studio and Android Studio For enterprises in Gemini Enterprise Agent Platform and Gemini Enterprise. Gemini 3.5 Flash (high) : $1,551.60 Gemini 3.1 Pro Preview : $892.28 Gemini 3 Flash Preview (Reasoning) : $278.26 Gemini 3.1 Flash-Lite Preview : $93.60 Claude Opus 4.7 (Adaptive Reasoning, Max Effort) : $5,117.14 Claude Opus 4.7 (Non-reasoning, High Effort) : $1,217.23 GPT-5.5 (xhigh) : $3,357.00 GPT-5.5 (medium) : $1,199.14

1 views
Unsung Yesterday

“Some say it sounds like an alto saxophone.”

I witnessed this Siemens locomotive depart yesterday and for a second I thought I was losing my mind. Then, I smiled so hard: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/some-say-it-sounds-like-an-alto-saxophone/yt1.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/some-say-it-sounds-like-an-alto-saxophone/yt1.1600w.avif" type="image/avif"> Turns out, the startup melody was intentional in this particular model. The power converters have to adapt the current from the overhead line to convert it to the three-phase motors of the locomotive, and that generates a rising tone. The engineers decided to change the logic to increment the tone in precise few steps resembling a musical scale, rather than allowing it to rise continuously. I debated whether to include this on Unsung. I guess it is software, even if it’s attached to the hardest of hardware. And sure, it’s “just” delightful, but it is still kind of nice to see someone go extra, adding a human touch atop a technical process that had to happen anyway. But then, it reminded me of something. No, not the poor CSIRAC trying (and similarly struggling) to become a musician. Rather, a “musical road” built in Lancaster, California, where the engineers messed up the execution, creating a truly unpleasant, atonal melody. David Simmons-Duffin wrote a fun essay in 2008 analyzing the “bug” thoroughly, including useful visuals, and even replicating the problem. Subsequently, Tom Scott visited the road and made a video about it ten years later. It won’t surprise you that the cause of the bug was bad hand-off between designers and engineers, but there can be no software patch for grooves you cut in asphalt – and so at least as of last year , the embarrassingly sounding road was still there. I think I prefer my out-of-tune musical scale performed by a train. Given it’s easy to find compilation videos of Siemens locomotives booting up , it seems I’m not alone. #bugs #real world #sound design #youtube

0 views
Unsung Yesterday

Shallow breathing

Turns out that the breathing light survives, sort of, not really, in an Apple product today: The AirPods Pro case does this when charging – right at the start, or when you tap it later. But it disappears after a while, the pace is now 28 breaths a second (over twice as fast as the original iteration), and the light is orange. Is it still the same thing, reflecting on how smaller organisms breathe faster? Or is it mostly an unrelated idea, with the light fading in and out indicating activity rather than lack of it? My money is on the latter – the light turns white when pairing, too, and it cycles even faster then – but it was nice to imagine the return of the old feature for a second or two… or 2.1, to be precise. #apple #details #hardware #motion design

0 views
flowtwo.io Yesterday

PHP's Oddities

I've been coding in PHP at work for the last 5 years. My org's entire backend is written in PHP—a decision made in 2007 when the company first started. It's not a language I ever imagined myself using prior to working there, but life takes you in all sorts of directions you don't expect. PHP gets a bad rep in the industry, despite being a mature and commonly used language . But it's mostly based on out-of-date understanding of what PHP can do. Recent versions have caught up with most other languages in terms of features; by this point it's a pretty versatile general-purpose language. Certainly not just for serving HTML, as it was originally designed. I'm no longer working at the aforementioned company, so I'm reflecting on my experience with PHP after all these years and there's some things I've always found odd about it. And more than just odd, some of it's language features are really unintuitive and have been prone to cause bugs. This comes from personal experience and many previous headaches at work. I'll explain two of the biggest offenders in this post—in short: PHP's standard library basically only has one data structure: the . This was intentional; it was designed to be a general-purpose, flexible data structure that can cover a variety of use cases. It's technically an ordered key-value dictionary , not an array in the traditional sense . Unfortunately, with flexibility comes complexity. If you want to create a collection of fixed-size objects in an allocated memory block, you can't really do that. PHP pretends to support them, but the illusion breaks down in unexpected ways. Let's say I have a bunch of fruits. PHP let's me define a fruits "array" and I can do normal array things with it. Everything looks fine but you get into trouble whenever you perform a mutation on this "simple" array; it will be exposed as being a key-value store. When you use one of PHP's built-in functions for standard array operations like sorting or filtering, it will operate on the keys AND values of your array. If it mutates the array in-place or by a return value, the key order will likely become inconsistent. why can't I hold all these indices??? The only way to put these arrays back into a naturally indexed state is to use the function. You just have to know that, or else you end up with subtle bugs. It's just strange to me that PHP doesn't support simple collections of objects. It's annoying to have to manage these arbitrary numeric keys when all you really want is ordinal indexing like 99% of the time. It feels like a leaky abstraction. In PHP5, a native type system was added to the language. It was expanded over time and by PHP7 you could define the types for your class's properties. Although PHP is a scripting language, type declarations will help catch bugs during testing, or even during development with the use of static analysis tools like PHPStan . But PHP's type system has some quirks since it was built on an existing dynamically typed language. The rules had to be designed after the behaviour was already there. For class properties, there's a hidden uninitialized state that can pop up if you're not careful. Let's define a class with three properties: Here, I'm illustrating all the ways of declaring the type for a string property: Before PHP7, all class properties were (1): untyped. Since the type system is optional, it has to live alongside the "legacy" behaviour which has weird consequences. For example, what do you think the values of these three properties will be after we instantiate a object? Trick question! Only the untyped property will have a value, and that value is . That seems fine and is roughly in line with how I'd expect a language to use a value. But the other two properties will NOT have a value because they don't exist, or rather they could exist but haven't been initialized yet. This example exposes the "uninitialized" state that a property can be in, which is NOT the same as . This distinction frustratingly comes up when you try to do a null check on these properties: Not a warning—a FATAL error occurs if you try to access an uninitialized property. This comes up a lot in cases where you try to deserialize data into a PHP object. If a field's data isn't present you might not initialize the property at all. ahh yes, NULL...who was that by again? This lax behaviour for property definitions makes writing code around them harder. Especially when you take into account that any object can have properties dynamically added to them: So I feel like the class property type system does little to help you understand what a given object is composed of, and in some respects has made it less clear because it's introduced this new uninitialized state. As a developer, it's hard to write defensive code because you're never sure which checks to do for all these situations: , (), , ... it's not obvious which functions cover which states. I'd argue that uninitialized did not need to be a state at all. For nullable typed properties, just default them to the way untyped properties are. And for non-nullable types, require them to be be defined as constructor promoted parameters OR require a default value at declaration. Similar requirements already exist for the attribute, so it's certainly feasible for the PHP execution engine to enforce it. But there's probably some nuance or historical reason I'm missing here. Let me know in the comments if you know. Despite all the critiquing I've done in this article, I still think the amount of hate PHP gets is undeserved. Like any language, it has it's quirks and tradeoffs, but you can still accomplish any task using PHP that you could in another language. The more you know about a language, the better you can structure things to work "with the grain" and write more idiomatic code. Some things I do enjoy about PHP: Thanks for reading! Arrays are weird and overloaded The type system is clunky It's a string It's nullable string It's a scripting language, so development friction is low. Make a file change and it instantly takes effect. Laravel is a solid web framework with tons of extensible functionality. It's opinionated and definitely leans into the "auto-magical" framework style, but it was designed well so you don't mind. All the $ signs help remind you what you're doing it all for at the end of the day 🤑

0 views

May 2026 blend of links

Forgive the higher-than-usual rate of direct quotes from these links, which replace a few regular comments, but as you can see, there is a general theme in my recent readings. Even though I’m trying to avoid focusing on it in these monthly collections of links, the theme is so rich, so complex and consequential (and fascinating in many ways), that I’m still not really sure what to think about all this and what I can add to these excellent takes. Your CEO is suffering from A.I. psychosis, by Jake Handy – “ An agent without a spec is a random text generator with a budget. ” A lot of quotable and relatable parts in this excellent, insightful column. The Majority A.I. View, by Anil Dash – “ One of the reasons we don't hear about this most popular, moderate view on A.I. within the tech industry is because people are afraid to say it. Mid-level managers and individual workers who know this is the common-sense view on A.I. are concerned that simply saying that they think A.I. is a normal technology like any other, and should be subject to the same critiques and controls, and be viewed with the same skepticism and care, fear for their careers. ” The Rise of the Bullshittery, by マリウス (Marius) – “ A few thoughts on how the modern economy has stopped rewarding people who know what they are doing, and started rewarding people who know how to look like they do. ” Do I belong in tech anymore? by Ky Decker – “ What I’ve gained from A.I. is a deeper appreciation for human communication, in all its messy imperfection. ” (via Kottke ) Your A.I. Use Is Breaking My Brain, by Jason Koebler – “ Our brains are now performing untold numbers of calculations per day: Is this A.I.? Do I care if it’s A.I.? Why does this sound or look or read so weird? Does this person just write like this? Is this a person at all? ” Craft is Untouchable, by Christopher Butler – “ And that’s the risk with collapsing skills into tools. I won’t always be there to do the thing I do. Inferior designs will ship. That’s bad. But what’s worse—the thing that really stings most designers’ egos—is that most people won’t even notice. ” Software as the Product of Obsession Times Voice, by John Gruber – “ It’s one thing to make something poorly designed and shrug on the grounds that it doesn’t matter. It’s another thing to make something poorly designed and hold it up as good design. ” “The Biggest Android Update Ever”, by MKBHD – Reading the comments section of this video — which I usually avoid doing at all costs on YouTube — was very revealing of the world we live in: companies pushing A.I. everywhere to please investors, but a sizeable number of users from the general public seem to be genuinely annoyed by it. I also really like this new-ish column-like video format from MKBHD (Marques, if you’re reading this, please consider adding a good old blog next to your YouTube channels and podcast?) Hyperduck, by Sindre Sorhus – Another excellent little utility from Sindre Sorhus: this one forces me to use open tabs on my Mac as my read-later list, rather than saving the link somewhere, only to forget about it. (via Loren Stephens ) Patricia, I Went on Holiday – Every now and then, I listen to Patricia and their specific bass-deep techno music that sounds like nothing else I know (my fave being Sick Day ). This song, not featured on an album, is great, but the fan-made video is very well made and it’s a nice window into the early 90s. I do need to go on holiday.

0 views
Martin Fowler Yesterday

Maintainability sensors for coding agents

In her recent article about harness engineering for coding agent users, Birgitta Böckeler laid out a mental model for expanding a coding agent harness: a system of guides and sensors that increase the probability of good agent outputs and enable self-correction before issues reach human eyes. Birgitta has now started publishing an article where she walks though her experiences using sensors to keep a codebase maintainable. This part looks at static analysis with basic code linting.

0 views

AI Is Too Expensive

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 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 . This week, I’ll publish the second part to my ongoing series (“ What If…We’re In An AI Bubble? ”) about the factors and events that will cause the AI bubble to finally pop.  Subscribing to premium is both great value and makes it possible to write these large, deeply-researched free pieces every week.  AI is, as it stands, not economically viable for anybody involved other than the construction firms, NVIDIA, and the surrounding hardware companies benefitting from the irrational exuberance of a data center buildout that doesn’t appear to be happening at the speed we believed .  Every AI startup loses millions or billions of dollars a year, and nobody appears to have worked out a way to stop hemorrhaging cash. Hyperscalers have invested over $800 billion in the last three years, with plans to add another $700 billion or so in 2026 and another $1 trillion in 2027 , meaning that they need to make at least three trillion dollars in AI specific revenue just to break even , and $6 trillion or more for AI to be anything other than a wash. I went into detail about this (albeit at a lower, pre-2026/2027 capex number) in a premium piece last year .  To give you some context, Microsoft made $281 billion , Meta $200 billion , Amazon $716 billion , and Google $402.8 billion in revenue in their most-recent fiscal years for every single product combined, for a total of $1.599 trillion. None of them will talk about their actual AI revenues. Yes, yes, I know Microsoft said that it had $37 billion in AI revenue run rate ($3.08 billion a month or so) and Amazon had $15 billion, or around $1.25 billion a month , but both of these are snapshots of single months that are meant to make it sound like they’re going to make that much in a year but in the end, you don’t actually know anything about how much money they’ve made from AI. We do, however, now know that Microsoft has spent an approximate $100 billion on its OpenAI partnership after testimony from an executive during the otherwise-dull Musk-OpenAI trial, per Bloomberg : This is a fascinating insight for a few reasons: At the end of 2025, OpenAI claimed that it had 1.9GW of capacity (likely referring to total power draw rather than the actual critical IT of the infrastructure at its disposal), which, per analyst estimates, ( $42 to $44 million per megawatt ) works out to around $79.8 billion. This claim was made around six months before the release of Microsoft’s most recent quarterly results.  In other words, Microsoft has spent 4 years sinking (either through spending or allocating the capex in advance) nearly $300 billion into…building OpenAI? Okay, fine. Microsoft also has 20 million Microsoft 365 Copilot subscribers for an absolute maximum revenue of $7.2 billion…if every single one were paying $30 a month, which they are most assuredly not as Microsoft has been offering discounts on it for years . Based on my reporting from last year , Microsoft made around $7.5 billion from OpenAI’s inference spend and $761 million from its revenue share in Fiscal Year 2025, a year when it invested (either spent or allocated) around $88.2 billion in capital expenditures. I didn’t report it at the time, but I also had the numbers for all of Microsoft’s revenues for the first three quarters of Fiscal Year 2025 — a total of $8.9 billion of total AI revenue, with around $4.35 billion in revenues when you removed OpenAI’s inference. If we assume that Microsoft’s other AI services grew 10% quarter-over-quarter, I estimate that Microsoft likely made around $17.9 billion in AI revenue in FY2025, or a little under a fifth of its capex.  And let’s be clear: none of these numbers include the actual operating expenses. Data centers, after all, need electricity to run, and AI data centers in particular need a lot of electricity. And some — though, admittedly, not many — people to handle the things like maintenance, repairs, and operations. And then there are things like taxes, insurance, and the other day-to-day costs that, when you add them all together, make a big, scary number.  You can argue that “actually GPUs are profitable to run” ( I disagree! ), but for any of this to make sense, four things have to happen: All four must be true. If AI revenues don’t explode, capex can stop, margins can be positive, and your best-case scenario is…you maybe broke even. If capex never stops being invested, you need revenues to explode dramatically — to the tune of effectively doubling Microsoft, Meta and Google’s entire businesses, and tripling Amazon Web Services’ annual revenue ( $128 billion ) — and for said revenues to be margin-positive, because if they’re not, eventually other healthy businesses will slow, leaving AI to tear a hole in overall margins. In all cases, AI revenue must stay consistent because, well, you need to get paid . I also cannot find an economic scenario where this pays itself off.  Let’s assume that Anthropic is actually at $45 billion in annualized revenue ( I believe it’s doing some very worrisome maths to get there ), or around $3.75 billion a month. On an annualized basis, this would not be enough — assuming it had zero operating expenses (rather than losing billions) — to recover a single year of capital expenditures from Microsoft, Google, Meta, or Amazon from 2024 or 2023. Even if OpenAI’s entire cloud spend ( $50 billion ) for 2026 went to Microsoft and it doubled its Microsoft 365 Copilot revenue (at full cost) to $14.4 billion, it estimates it will invest $190 billion in capital expenditures this year. Amazon’s $15 billion AI run rate, even if it doubled, wouldn’t put much of a dent in its $200 billion in investment plans . While we don’t know Google’s AI revenues, it plans to invest $185 billion in capex this year . These AI revenues have to be completely fucking insane and they need to be that way extremely fucking soon , because otherwise the best they’ll be able to say is “our first few years of capex weren’t particularly useful but the stuff we built after it was,” which still works out to a few hundred billion dollars of waste. Things get even worse when you realize that at least 70% of Microsoft, Google, and Amazon’s compute is dedicated to Anthropic and OpenAI , two companies that burn so many billions of dollars that Microsoft, Google and Amazon have already fed them a combined $54 billion in the last three years, with $28 billion of that coming in the last month and Anthropic due another $50 billion from Google and Amazon if certain performance obligations are met. And there’s no real sign, outside of Anthropic and OpenAI’s compute spend (which is reliant on hyperscaler and venture capital money), of any real explosion in AI revenue. Per The Information (in a chart I love to share!), more than 50% of hyperscalers’ revenue backlogs comes from these companies: If massive, incredible demand for AI existed, wouldn’t these remaining performance obligations be near the trillion mark? Wouldn’t there be other Anthropic or OpenAI sized chunks of revenue? There’s allegedly incredible, unstoppable, insatiable demand for compute. Why isn’t it lining up? Let’s take a look at those RPOs! That was a lot of numbers, so let me make it simpler: outside of OpenAI and Anthropic, these three companies do not appear to be significantly increasing their revenues, and the only way to get that revenue is to feed money to one or both of these companies.   Put aside all the theoreticals and hypotheticals and metaphors and imaginary future scenarios and tell me: what, in the next year, are Microsoft, Google and Amazon going to do about this problem? How do they solve it? If we assume the absolute best-case scenario, these companies are making a combined $70 billion in annual revenue on investments that now — including the money invested in the companies themselves — total over $900 billion. Doubling that won’t be enough. Tripling it won’t be enough. In fact, to pay this off, these companies will need to be making over $100 billion each in AI revenue in the next year , because otherwise there is no covering these losses. And it all comes back to a very simple point: AI is too expensive. If the margins were good, they’d be sharing the margins. If the revenues were good, they’d be sharing the revenues (and no, run rates aren’t revenues). If the business was strong, it would be a separate category in their earnings.  But LLMs are too expensive! They cost too much to run, and said costs appear to increase linearly with revenues. The more a user uses a product, the more it costs the company to run it, and the more capacity they can take up. The only way to capture any growth is to buy and install GPUs , which in turn requires you to build somewhere to put them, which takes time and money.  I’m really struggling to see the argument in favor of continued capex investment. You’re more than $800 billion in the hole with, I estimate, less than half of that resulting in operational GPUs and capacity. Said capacity is mostly taken up by OpenAI and Anthropic, two companies that burn billions of dollars and do not appear to have an answer for how they might stop.  The more you build, the more your infrastructure becomes dependent on the continued existence of two perennially-unprofitable ultra-oafs, as your existent AI product lines are, at best, add-ons to products like Google Workspace or Microsoft 365, or further expansion of cloud compute capacity with lower margins and higher up-front costs than anything you’ve ever built.  Every quarter is an opportunity to put yourself another $30 billion or so in the hole, all in the hopes that, I assume, OpenAI or Anthropic will pay you $100 billion or $200 billion over the course of a few years, because nobody else in the entire universe is spending that much on compute. You are not recovering these investments without either a massive new product line that doesn’t exist today or three or four Anthropic or OpenAI-sized compute contracts. Put another way, Amazon needs another AWS ($128 billion a year), Microsoft another Azure ( $75 billion a year, including OpenAI’s 2025 compute spend ) and Google a business line at least half the size of search (around $200 billion a year). These businesses have grown to this size by providing extranormally large amounts of value from the very moment they were created and impenetrable monopolies — and while there are quite literally other cloud providers that can physically provide the infrastructure to OpenAI and Anthropic ( Oracle is trying to compete and may die as a result ), the actual “monopoly” here is “being able to deploy hundreds of billions of dollars.” Anthropic proved this when it took 300MW of compute from Elon Musk .  In Oracle’s case, as I’ve explained at length , it has to successfully build 7.1GW of capacity, have that capacity actually be margin-positive (doubtful!), and then actually get paid for it by the time it’s built in, oh, I dunno, 2032?  Sadly, I have bad news about Oracle, Microsoft, Amazon, and Google’s largest customers.  Here’s a fun game: ask an AI booster how OpenAI or Anthropic becomes profitable! Here’s what they’ll say: I must be abundantly clear that nobody has any proof that anyone is profitable on inference, but we have plenty of proof they’re not. They’ll likely cite known liar Sam Altman saying OpenAI is profitable on inference from a party from August 2025 , or Dario Amodei saying ( in a sentence around “stylized facts” that are “not exact” and are specifically “a toy model” and specifically not about Anthropic ) “the inference has some gross margin that’s more than 50%.”  Here’s a really simple way to dispute this: Coatue said that Anthropic’s revenues were 85% API calls in 2025 . If it’s profitable on inference, how is it still losing money? You’re gonna say “training,” but that doesn’t actually answer the question: if Anthropic’s process of providing tokens to its models is profitable, how is it losing so much money? Why offer a subscription platform at all?  As I’ll get to, Anthropic has companies paying massive amounts for tokens — hundreds of millions a year in some cases — that’s all inference . Why are you bothering with these stinky, nasty monthly subscriptions? The “inference is profitable” argument is a bedtime story told to people that can’t reconcile the logic of a company that allows people to burn between $8 and $13.50 of every dollar of their subscription revenue.   Otherwise, you have to reconcile with the fact that both Anthropic and OpenAI are both incinerating money and have no real path to any kind of sustainability other than, well, not doing that. One very, very specific counter-argument people make is that open source models are cheap, and can somehow be compared to OpenAI and Anthropic’s, despite the fact that we have no idea what the actual parameters of Sonnet, GPT, Opus, or any other of their models actually are.  What we do know is that both of these companies lose billions of dollars. What we do know is that OpenAI, per The Information , plans to burn $852 billion through the end of 2030, and that as of March 6, 2026 (per CFO Krishna Rao’s sworn affidavit), Anthropic made “exceeding” (sigh) $5 billion in revenue and spent $10 billion on inference and training.  Anthropic has done a great deal of work to obfuscate how much it actually makes or spends, but I think it’s likely it burns even more than OpenAI, given the fact that it’s had to raise $75 billion in the last 6 months ( assuming its new $30 billion round closes ), and that’s not including an additional $30 billion from Google and Amazon if certain unknown milestones are hit.  Then there’s the issue of those RPOs. Anthropic is now on the hook for $200 billion to Google, $100 billion to Amazon and $30 billion to Microsoft, I assume over the course of the next three or four years.  So let’s lay this out. Anthropic — based on its own affidavit from March — appears to have spent $3 to make $1 of revenue on a compute basis, and that’s before you include any and all other costs like staff or electricity or the vocal coach that Dario Amodei uses to add that bass to his voice.  Additionally, it needs $330 billion to pay its cloud obligations to Amazon, Google, and Microsoft over the next four years. I’d estimate it needs $5 billion a year for its compute deal xAI (so $20 billion over the total period) and an estimated $30 billion to cover its deal with CoreWeave . That brings us to a total of $380 billion. It’s hard to estimate the actual costs associated with running Anthropic because so much of the reporting no longer makes sense as a result of that affidavit. Nevertheless, I think it’s fair to assume it will need at least $20 billion of operating expenses across that four year period. We don’t even need to play in the realm of “what might Anthropic or OpenAI’s revenues be?” to understand the problem here. Both companies aggressively burn money, and neither of them have any answer as to how they might stop. Numerous reports about how Anthropic will turn “cash flow positive” in either 2027 or 2028 are fantastical, illogical, entirely driven by ridiculous projections, and should never have been reported as anything other than an attempt by companies to mislead their investors. In both cases, reporters should’ve had more asterisks on those numbers than Q*Bert reading Frank’s lines from Blue Velvet . And we have plenty of evidence that they’re losing more money over time. In January 2026, The Information reported that Anthropic’s gross margins were 40% in 2025 — 10% lower than its “optimistic” projections, specifically attributed to “...the costs of running Anthropic models from paying customers, in a process known as inference, on servers from Google and Amazon,” adding that those costs were “23% higher than the company anticipated.” In February, The Information ran another story saying that OpenAI’s gross margins fell from 40% in 2024 to 33% in 2025, a full 13% lower than its projected margins of 46%, all because (and I quote) “...the company having to buy more expensive compute at the last minute in response to higher than expected demand for its chatbots and models.” You know, exactly what Anthropic has had to do. This is what I’ve referred to as the knife-catching problem for compute demand — you either don’t order enough compute and have to rush to buy some last-minute as demand intensifies, or you order too much, and, well, to quote Dario Amodei: And right now, as I’ve covered , there’s not enough compute being built to keep up with Anthropic or OpenAI’s voracious demands, meaning that they will both be bartering to buy whatever’s available at whatever price it’s available at. This naturally will savage their already-negative margins… …and then what? No, really, and then what? One of you fucking AI boosters, answer me, how does this actual reverse course? Because even if Anthropic were making $100 billion in annual revenue, it would probably be losing $300 billion or more to get there. The fact it had to raise $30 billion in February , $15 billion in April, and now $30 billion more in May all while allegedly pulling in more than $3 billion a month in revenue suggests that its COGS are fucking horrendous, and its growth is coming at a terrible financial cost. Let’s say that Anthropic keeps growing and ( as The Information suggests ) hits $100 billion in annualized revenue (around $8.3 billion a month). How, exactly, does it afford to make that much money? Because right now it’s (allegedly) about to hit $45 billion in annualized revenue, and needs so much money that it’s absorbing (along with OpenAI) the majority of venture capital raised this year, and very clearly does not have any path to bring its costs down. The answer is simple: it can’t! There is no mechanism to do so. More compute does not make OpenAI or Anthropic’s services cheaper to offer. There is no magical silicon coming that will make any of this more affordable, and no, Anthropic is not “profitable on inference,” because if it were, that massive revenue growth would have leveled out its margins rather than require it to raise a little less than the combined value of every Major League Baseball team , or more if you add the other $50 billion that Amazon and Google have promised based on secretly-held performance obligations. The same goes for OpenAI, which “raised” $122 billion (around $45 to $50 billion in real cash, with the rest either paid in installments or on it IPOing or reaching (sigh) AGI) in February and is now already considering raising more . Somebody might counter-argue that this is companies raising as a means of boosting their valuations, I think that’s a very convenient way of looking at two extremely problematic companies.  I should also ask why neither of them appear to be seriously considering going public. While both were rumoured earlier in the year to be planning to do so in 2026, both appear poised to raise more private capital. I think the answer is simple: their CFOs know that doing so would reveal their actual margins, which are hot dogshit with sprinkles on top.  Nobody has a sensible or logical response here. Which leads us right to our next point! One important detail to keep in mind here is that as of a month or two ago, Anthropic moved all enterprise customers to token-based-billing, which will begin, I believe, a true stress-test of the true “value” of AI as costs skyrocket. Just last week I ran the first of a two (or three, potentially) part premium series called “What If We’re In An AI Bubble?” and touched on the gruesome subject of whether organizations could afford to pay for AI long-term : Earlier in the week, carnival barker and Salesforce CEO Marc Benioff said his company would spend $300 million on Anthropic tokens in 2026 , and as I discussed in my premium from Friday , unrestrained AI spending is inflating the revenues of Anthropic and OpenAI in a way that isn’t sustainable for anybody involved: The problem is simple: nobody actually knows how much AI is going to cost them in any given quarter. This means that the current token spend you’re seeing is entirely experimental, which is why organizations keep burning through their tokens so fast.  This massive growth in spend is what underpins the “massive” (I have serious questions about its accounting) growth in Anthropic’s revenue. Executives have, across the board, given their engineers free reign to burn as many tokens as they’d like, and while I severely doubt that Anthropic actually hit $50 billion in annualized revenue outside of not-quite-fraudulent non-GAAP measurements, I believe its revenue growth has come from an artificial boost from a tech industry searching for a reason to pay somebody money. To be very clear about what I mean, I think there is currently an AI token binge across both Anthropic and OpenAI. Enterprises do not know the actual value of AI, and do not know how much they should actually be budgeting, which is why Uber and others are running through their token budgets but not, it seems, spending less. We’re currently in an abundance phase — one where nobody is truly thinking about the costs outside of their fear of missing out — but there’s this nasty undercurrent of “wait, how much does that cost?” followed by “oh, fuck, well…you know I love AI but…” Put another way, the current spend on AI tokens is not something that’s indicative of lasting, reliable revenue. In some cases, the pressure to use AI for everything is turning companies’ software stacks into slop. Things are worse elsewhere. Something is wrong at Zillow. Something about LLMs has done something to its technical leadership, something that makes them talk strange and send weird slide decks with confusing, slop-ridden sentences.  The real estate tech firm spent over $1 million on AI services in the first quarter of 2026, and in April it spent $749,000 in tokens across Cursor and Anthropic’s services, as well as through AWS Bedrock. As of the end of the month, it was nearly 75% of the way through its annual Cursor token budget of $1.1 million.  As of the middle of May, its total AI spend had already crested over $300,000, and its Cursor budget sat dangerously close to the edge at 85%. This is particularly-concerning when you consider that Zillow’s net income for Q1 2026 was $46 million , and ranged from $2 million to $10 million each quarter of 2025.  Zillow is currently on course to spend at least $7 million on AI in 2026, and at its current pace might hit as much as $10 million, which would amount to a little less than 50% of its 2025 net income ( $23 million ).  You’re probably wondering how Zillow manages to spend so much on AI, and the answer — as I’ll get into in next week’s free newsletter — is that its technical executives appear to have AI psychosis, saying that the short-term goal is for “software engineers to never open a code editor again.” The reality is chaos. In a slide deck that I’ll discuss later, Zillow revealed that while engineering resources have largely stayed the same, outputs requiring human review have increased by nearly 50%. Meanwhile, code deployments and pull requests increased by 39%, and software reviewer load increased by 29,000 hours each month , creating a massive burden on the 1,500 or so engineers working at the company.  In simpler terms, that’s about 19 hours of extra work per engineer that’s literally just looking at extra code written by LLMs.  On Blind, the anonymous social network for tech workers, Zillow workers complain about Zillow’s code “slowly becoming AI slop,” with “much more code getting approved without guardrails or input due to people not being able to keep up the other’s velocity or just not caring anymore.”  One worker claimed that “the slop is job security,” adding that they “don’t want the output to be good or documentation to be clean [as] management will replace [them] with offshore/nearshore/AI agents at the slightest whiff of evidence that the slop cannon is self sustaining.” Another said that they felt “lost in the agentic world,” and that they “didn’t have full grasp of where we are going or what [their] role is,” with a “lot of overlap in what people are doing.” Another said that “people are burning tokens just to hit internal AI adoption targets,” adding that “this is what happens when leadership ties metrics to usage instead of outcomes,” saying that it “literally subsidized busywork.” This is all part of what an internal slide deck viewed by this publication called “AI-Native Engineering,” promising a “path to an agentic Zillow” and “faster outcomes for customers,” though customers are never mentioned in any other slide.  The deck — pumped full of AI-generated text — talks about “generic AI being a commodity,” saying that “Zillow-aware AI is a competitive advantage,” and at no point explains what that means. It encourages engineers to go from “AI-Assisted” to “AI-Native,” with “systems enabling org-wide leverage,” with engineers moving from being “soloists” — individual developers with AI tools — to “conductors” that orchestrate AI agents, to “composers” that “define systems AI can safely play,” adding that “2026 is the transition from conductor to composer.” Yet the strangest part is named “2027: A Tuesday,” discussing a theoretical day in the office for whoever is left at the company. This theoretical example is, apparently, a process that would take weeks, but now takes under two hours.”  Zillow intends, based on this deck, to sacrifice everything to AI — code review, vulnerability fixes, policy checks, deployments, testing, and basically having agents take over everything , no matter how small, like having an agent do dependency updates and security hotfixes that could be handled with a simple shell script. To quote Zillow: In practice, sources at Zillow tell me that there has been no actual movement toward this vision. Software engineers still open IDEs and review code manually, with one describing Zillow’s “vision” as “nonsense,” adding that “you can’t just throw buzzwords on a slide deck and change how all the engineers do their jobs.”  As for why token burn is so high, sources tell me that engineers are actively encouraged to use AI for everything , as much as possible, writing PRD (product requirement documents) in AI, then using the AI to make stuff based on the PRD, then doing a deck with AI, then writing emails with AI, using AI to brainstorm, or create weird, esoteric automations, with some managers pushing workers to have one personal AI “goal” to aspire to. Zillow’s agentic “vision” is apparently a remit from the C-suite. It’s hard to tell if this is AI psychosis or just classic Business Idiot bullshit.  Perhaps it’s a little of both. Every organization I’ve talked to has exceeded or is nearing the edge of their annual token budget barely five months into the year, which means that everybody has suddenly given themselves an extra few million dollars’ worth of operating expenses for reasons that escape effectively everybody I’ve talked to.  Every engineer tells me the same thing: “I’m being made to do this, I don’t want to do this, my managers do not seem to understand, my bosses seem to understand even less than my managers, and if I don’t use AI somebody is going to fire me.”  Put another way, CEOs and CTOs are screeching at their underlings to “use AI as much as possible” to “find its incredible benefits” without anybody really knowing what those are and how much it’ll cost to get there. This might be because Anthropic obfuscates the data that might tell customers the real costs.  Per Laura Bratton at The Information , Bratton’s article has numerous quotes from executives saying that Anthropic lacks transparency and granularity into the ways that tokens are being burned across an organization, in a way that I think sounds very, very suspicious, particularly when you add the following:  While I’m not accusing Anthropic of anything untoward, massive, multi-million dollar contracts that involve individuals burning thousands or tens of thousands of dollars’ worth of tokens with no service level agreement, transparency or true granularity into the burn is a perfect setup for a company — not saying it’s Anthropic! — to do something dastardly with those numbers.  While an individual might be able to monitor their own personal usage, in an organization of hundreds or thousands of engineers, who’s to know if, say, the particular token burn is consistent across every member of the company, or that those costs are actually matching up with what the user is doing? This is a company ostensibly worth $900 billion dollars acting with disregard for the basic measurement of “how much did this cost, and how did it cost so much?” And in the end, how do you even measure it at scale? Say you’ve got 1,500 engineers, and they’re spending a combined $1 million tokens a month. How the fuck do you actually measure the return on investment for that spend?   How many tokens does it take to do one thing? Is it consistent across every model? Is it consistent across every employee? Are you even measuring how many tokens a task costs? Because if you’re not, that token budget is basically throwing a dart blindfolded.  Okay, now you’ve measured a task, did you make sure to measure it multiple times? Because LLMs can randomly do things differently even with the same prompt and same Claude.MD file and same strictures and same data sources. You’re gonna need at least 10 samples of each task, and you’re gonna need to make sure somebody who actually knows what they’re doing can measure them, because if you get a dimwit, they’re going to say it can do something it can’t. Unless, of course, you can’t actually measure how many tokens a particular task can take with much accuracy, in which case every single AI token budget is bullshit. And each model does things differently depending on many different variables, some of them a result of the user, some of them a result of the AI labs themselves. Alright, well, maybe you just need KPIs — measurements you can aspire toward , and by pursuing them you can start working out how much it costs to do stuff.  Wait, which metric works there exactly?  In fact, it’s pretty hard to measure anything like “efficiency” or “productivity” in any business, because every metric connected to them can be gamed, leaving managers and executives with the problematic situation where they have to start learning how things work so they can see if they’re good. Before AI, this wasn’t as much of a problem, in the sense that inefficiencies and wasted hours weren’t directly connected to a chatbot that is specifically designed to burn money. Managers and executives could come up with whatever deranged, self-gratifying office bullshit they pleased, wasting hours of people’s time in the process, but doing so didn’t immediately connect to a massive, ever-increasing cost. AI is a perfect storm of failed concepts and organizations, and the apex of the Era of the Business Idiot , an epoch where we’re ruled by people so thoroughly disconnected from the actual workforce that it was inevitable that a technology would be created specifically to grift them. LLMs are dangerous for many, many reasons, but the under-discussed one is how well they play to a certain kind of executive imbecile. Generative AI is — to quote Mo Bitar — really good at doing an impression of work, much like most managers and c-suite executives, and even if it’s completely incapable of doing something, it’ll absolutely say it can and tell you you’re amazing for suggesting it. And that’s why Business Idiots love it.  Where regular human beings would say annoying things like “that’s not possible within that timeline” or “we don’t have the resources to do it,” AI will say “of course, right away!” and burn as many tokens as possible.  When it makes mistakes, it’ll apologize — as it should because it failed you — but then promise to do better next time, all while costing so much less, at least in theory , than a regular, stinky human being.  It’ll create a PRD of a theoretical software project with the confident and vigor that you need to take it immediately to a software engineer and say “build this immediately,” and when the software engineer tells you a bunch of bullshit about it not being possible , it’ll spit out several convincing-sounding responses. Fuck, why even bother talking to that engineer at all? Claude Code can mock up a prototype that you can then shove in their fucking face before you fire them for not using AI to do it themselves. Any executive-level fuckwit you’ve met in your life now has a seemingly-powerful tool that can burp up mimicry of open source software and, if you constantly prompt it, eventually get something half-functional onto some sort of web server. When you face bugs, it’ll try and fix them, sometimes also “fixing” (adding or deleting code) from elsewhere to be helpful, like when Cursor using Anthropic’s Claude Opus 4.6 model deleted an entire production database and all its backups . It will never, ever say no, even if it’s incapable, even if it has no thoughts, even if what you are asking is equal parts impossible and unreasonable in both its timescale and scope. A Business Idiot, given his druthers, can sit there and fuck around and make an LLM spit out something that makes him feel like he’s coding, which in turn makes him feel that you, a lazy and stupid engineer , could do even more with the power of AI. It doesn’t matter that it costs an absolute shit-ton of money, or that there’s no way to measure its efficacy. The Lion does not concern himself with things like “efficacy” or “productivity,” and the Lion is increasingly tired of your whining! The Lion doesn’t even understand what it is you do every day other than not doing what The Lion is asking for! You laugh, but this is genuinely how the majority of managers and executives think and act, and now they have a special chatbot that can fart out functional-enough prototypes to convince a Business Idiot they can do anything, because executives and managers do not regularly do much work and thus have no idea what it looks like other than when they look over your shoulder, which is why they wanted you back in the office! Organizations aren’t burning millions or hundreds of millions of dollars a year on AI because it’s good , they’re doing it because they are run by people who do not know what the fuck they’re doing.   In a sane world, randomly adding a massive, ever-expanding operating expense to your business with the express intent of — to quote IT firm Workato’s CIO , “eating the costs while employees experiment” — would have the board blow up your house. In our world, one dominated by disconnected, self-involved and massively-overpaid dullards, many businesses pushing their workers to use AI are doing so because the other guy is doing it, with about as much strategy and forethought as one would expect from somebody who spends 90% of their life reading emails, going to meetings, or going to lunch. The majority of those I see trumpeting the so-called benefits of AI do not appear to do anything of note. I have yet to see one so-called multi-agent orchestrator engineer psychopath ship something remarkable or impressive or even functional. I have yet to see any AI-obsessed boss write or create or author or do anything I can remember. I don’t see any of these fuckwits running a company on their own outside of those who have learned to sell stuff to other AI psychosis victims or executive midwits of varying size.  And why oh why is it always the language of inevitability and possessiveness? Nobody who’s this insistent, aggressive and violative with their language of “it’s here and if you don’t adopt it you’re stupid and dead” has ever been right about anything. Nobody this desperate, insistent and forceful has ever had good intentions, good vibes or brought good omens — they are always bearers of some kind of con.  Most technology is sold on elevating and ascending human beings. AI cheapens every interaction by creating a work-shaped product from a person that doesn’t respect you enough to give you work that’s barely fit for a human because it wasn’t made for one.  You must accept becoming a dogshit dealer that loves accepting and receiving low quality goods. You must celebrate intentionless and decaying slop, and defend it and the machine that made it with your entire being. You must sully yourself — treat its unexceptional, sloppy and unreliable outputs as signs of sentience, or at least the proof that digital sentience is possible. You must defend horrible, abrasive, ugly, loud monoliths of steel full of $50,000 graphics cards. You must say they are necessary, and you must aggressively antagonize those who do not.  Every time you defend generative AI you defend a machine of capital that has burned $1 trillion and created one of the most-wasteful products in history. If people disagree with you, you must attempt to harm them somehow — ostracize them, mock them, attack them, denigrate them. You will justify this as moral, because you have been manipulated by a technology built and sold by two of the greatest grifters of all time — Dario Amodei and Sam Altman.  Anything less is opposition to an industry with all the trappings of authoritarianism down to the media toadies, the propaganda and the seizure of land in the name of a nebulous “greater good.” But man, these men got people good.  Sam Altman helped propagate a technology perfect for conning people with potential, a larger extrapolation of Altman’s own life of taking dogshit — Loopt, for example! — and parlaying it into larger opportunities. It can make a really half-hearted demo of a lot of things, and that’s good enough to sell to Business Idiot.  Dario Amodei took this grift and perfected it. Anthropic is a company purpose-built to con people into giving it by money by making people feel smart. LLMs can do work-shaped stuff, sometimes, as long as you debase yourself to accept mediocre and often-broken stuff that you have to keep a vigilant eye on, and either use a subsided product that loses Anthropic money or pay a shit ton of money as an enterprise to Anthropic and they still lose money.  These companies were only capable of growing in an economy dominated by the gullible and work-shy. Only a capitalist culture dominated by people who don’t actually do or know stuff have let this get so far. Nobody wants this, nobody wanted it since the beginning, it was forced upon everyone, and to pretend otherwise is laughable and offensive. The amount of people who use this shit a bit and become convinced that we’re mere years from it costing over a trillion dollars to somehow making trillions of dollars and being an entirely different and good product should be aware that they are being manipulated. The more you feel compelled to defend AI the more scrutiny you must show it.  I am not your enemy! If you think that I am, you are on the side of a corporation or a product. You can try it, like it, and I don’t really care, but the second I see you trying to be condescending or judgmental or aggressive toward another person for not agreeing with your product choices I immediately feel suspicious. Can’t you see how these people act? Can’t you see how strange it is to defend a thing you pay money for that has terrible economics? If it wasn’t the “in” thing, being an AI person would be considered really weird. I look forward to the day it is. I hope you guys like having the stuff you said since 2022 repeated back to you! I’ve been saving it all. Time is running out for a graceful bow, and you better act quick!  If you feel self conscious while other people dunk on AI, that’s weird! I see people say they don’t like Macs all the time. Who gives a fuck! I’m not going to go to the mat for Tim Cook. People can make their own decisions.  Those comparing AI to AOL mailing CDs to people should feel ashamed of themselves. This is like if every single time you opened a magazine an AOL CD flew at your head, your boss told you he would replace you with a modem if you didn’t go online, and the news constantly ran segments called “I didn’t receive an email: father forgets son forever because he wasn’t online” or panels with “Internet experts” who said “I am on the Internet superhighway right now, and I’m certain that within 10 years AOL Time Warner will be able to email myself to my dad.”  Imagine if Shingy was a billionaire and went on TV every day in 1999 and told you “ the world must get ready, because you’re about to get a ICQ message from The Lord .” Generative AI was purpose-built to grift an economy run by executives and managers who don’t actually do any work. Its success has been driven by a remarkable, society-wide ignorance in the management sect, and its continued proliferation is only possible through the media’s continued trust and faith in the idea that CEOs are busy because they’re actually doing work. Yet even a Business Idiot eventually realizes that too much money is being spent, and the first one of these dimwits to cut their token budget will send the rest of them running for the doors. We should lock them. We should make everybody who obsessed over theoretical ideas about what AI can or will do ashamed for their intellectual deceit or constant ignorance.  At the end of the AI era, the only thing that will change the rot at the heart of our economy is the acceptance that the majority of companies are run by lazy, self-involved and ignorant fuckwits, and accountability for those who refused to scrutinize them. Microsoft has spent a total of $293.8 billion in capex since the beginning of Fiscal Year 2023 (which began in the back half of 2022). This means that around 30% of Microsoft’s capex ($87 billion) went to building OpenAI’s infrastructure. Based on discussions with sources familiar with Azure architecture, this is the vast majority of Microsoft’s operational capacity. AI revenues have to explode. Capex has to stop being invested. GPUs need to be margin positive, including both their cost and the debt associated with operationalizing them. AI revenue has to stay consistent both before and after you stop spending that capex. Microsoft’s RPOs jumped from $392 billion to $625 billion between Q1 and Q2 FY26 (or calendar year Q4 2025 and Q1 2026), driven by the $250 billion in “incremental Azure spend” from OpenAI (including already-existent commitments) locked up in October 2025 and the $30 billion promised as part of its deal with Anthropic from November 2025 . Based on Microsoft’s own disclosures , without Anthropic and OpenAI’s additions, RPO would have been effectively flat, as evidenced by the fact that in Q3FY26, remaining performance obligations sat at $627 billion .  Amazon’s RPOs jumped from $244 billion in Q4 2025 to $364 billion in Q1 2026, driven by its February 2026 $100 billion expansion of its $38 billion compute deal from November, and its extended partnership with Anthropic for 5GW of compute capacity unattached from any kind of dollar number.  Google’s RPOs jumped from $242.8 billion in Q4 2025 to $467.6 billion in Q1 2026, driven by ( per The Information ) $200 billion in committed spend on TPUs and compute from Anthropic, meaning that it has expanded its future revenues by an unremarkable $24.8 billion when you remove Anthropic’s spend, when RPOs had previously jumped $85 billion between Q3 and Q4, likely driven by its compute deal from October 2025 . It’s fair to assume a chunk of the remaining RPOs are from its deal to rent TPUs to Meta , announced in February 2026, which makes it likely that it accounts for the majority of the remaining $24.8 billion. Silicon will get cheaper. They’ll start selling services. They’re profitable on inference. It’s an example of a typical working day. At 8:30AM, the engineer notes that confirmation rates in Dallas dropped 3% overnight.  ‘Dallas inventory spiked; buyers went from 3 showings to 7. The agent shows the pattern: we're hitting the same buyer 7 times in 24 hours with "tour confirmed" pings. They're overwhelmed; they're muting us.’ The line before this says: “I don't open the codebase — I open the spec and eval dashboard.” Half an hour later, the engineer changes the spec, which is then tested against previous data, showing an improvement.  “The PM and I review diffs, check guardrails, approve.” Diffs are “differences” — essentially comparing two versions of the same document to see which lines have been changed.  The code is then rolled out.  At 11AM, the senior engineer mentors a junior engineer:  ‘A junior engineer's rescheduling agent is failing evals. I ask one question: "What happens if the buyer picks a slot the seller just blocked while the agent is negotiating?" We identify the race condition and add a constraint: "Always re-check availability at confirmation time." She updates the spec and evals. The agent passes.’ It is absolutely adorable they’re pretending that they’ll have junior engineers if this hellscape vision comes to life.  You can’t say “burn as many tokens as possible,” because employees will — as happened at both Amazon and Meta — deliberately create ways to burn more tokens using scripts and automations.  You can’t say “use AI every day,” because even if they do so, that doesn’t actually set up a success criteria. You can’t tell software engineers to try and “ship more software,” because that, again, emphasizes doing more, not making good stuff , and leads to an increase in velocity rather than how good the stuff is. You can’t say “pull requests” or any other metric a software engineer can manipulate, because in 100% of the situations where you give a software engineer a number to hit they will focus entirely on hitting that number.

0 views
Unsung Yesterday

“If you just ignore those pesky impossible details, the demo looks deceptively simple.”

This DOS demo called Wake Up! is astonishingly small – only 16 bytes: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/if-you-just-ignore-those-pesky-impossible-details-the-demo-looks-deceptively-simple/yt1.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/if-you-just-ignore-those-pesky-impossible-details-the-demo-looks-deceptively-simple/yt1.1600w.avif" type="image/avif"> The demo doesn’t just make QUOD feel gargantuan. Output this one solitary emoji, “Woman Technologist with Light Skin Tone” – 👩🏻‍💻 – and you spent all your 16 bytes, too. ( Proof !) The creator’s write-up is a bit hard to follow, but there are some interesting aspects to it: “stealing” the beauty from math itself, the reliance on the environment being set up properly (to avoid wasting precious bytes on initialization), and the tight connection between the hardware, the visuals, and the sound. Oh yeah, in case you haven’t noticed, this has sound! Two out of 16 bytes are devoted to its production, using an existing BIOS function that slots nicely into the existing graphics routine. This is another recent demo that caught my attention: NINE , from about a year ago: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/if-you-just-ignore-those-pesky-impossible-details-the-demo-looks-deceptively-simple/yt2.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/if-you-just-ignore-those-pesky-impossible-details-the-demo-looks-deceptively-simple/yt2.1600w.avif" type="image/avif"> The platform here is a computer of a similar vintage as the early DOS machines, Commodore 64. C64, like many other home microcomputers, supported special graphical entities called “ sprites ,” which were used for gaming since the rest of the graphics couldn’t move very fast. (Today, your mouse pointer is conceptually similar to a sprite, being imbued with special powers unavailable to anything else.) C64 could output up to 8 such sprites. The demo inexplicably has… nine. The NINE demo didn’t focus on absolute minimalism, but instead employed a barrage of ghostly (and ghastly!) trickery to achieve something that was thought impossible. This time around, the explainer from the author – a 22-minute YouTube video – is filled with great storytelling, and absolutely worth a watch: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/if-you-just-ignore-those-pesky-impossible-details-the-demo-looks-deceptively-simple/yt3.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/if-you-just-ignore-those-pesky-impossible-details-the-demo-looks-deceptively-simple/yt3.1600w.avif" type="image/avif"> I think both of these showcase two things that I appreciate and that translate to great UX design as well. The first demo shows tight integration between design and the capabilities of software and hardware. Let’s pick the sound routine that needed just 2 bytes. If there wasn’t a way to output sound within this extremely tight budget, the author likely wouldn’t fight to their death to get sound… they would instead focus on what else was possible within two bytes. This is getting as close to full understanding of the medium you’re working in as possible. The second demo highlights how sometimes you can use absolutely horrid sleights of hand to achieve something beautiful – and how you can perhaps find beauty in those sleights of hand, too. It reminds me of the quote attributed to Teller (of Penn & Teller): Sometimes magic is just someone spending more time on something than anyone else might reasonably expect. Penn & Teller talk a lot about how there are only two keys to their success: going further than others would think, and not worrying about employing inelegant tricks in service of something that would appear to be of utmost elegance. Today’s computing limitations are different than the ones from the 1980s. But a lot of this attitude can still be helpful, even four decades in, and even if your work seems as far away from the demoscene as you can imagine. #graphics #hacks #youtube

0 views
Kartik Agaram Yesterday

Updating a mantra from 2007

Me in 2007: Building something is easy. Evaluating what you build is hard. Iterate between the two as fast as you can. Stefan Lesser in 2023 (paraphrased): Building helps understand ourselves through the world, and understand the world through ourselves. Me now: Building things is easy. Evaluating what you build is hard. It requires lots of attention. Therefore, build things that you want to pay lots of attention to.

0 views

AppGoblin App Ecosystem Report 2026 Q1

The 2026 Q1 App Ecosystem Report is here with a special section for those attending MAU in Vegas this week. Ad Networks were led by Verve once again after its strong Q4 2025, with other notable breakouts from Snap Inc. , TaurusX , adjoe , and Moloco . Business Tools were led by small but super fast growing Luciq . PayPal also posted strong mobile growth, while emerging companies like AppHarbr stood out. In attribution analytics, growth was broadly healthy across the category and was led by Tenjin . Open source product analytics platform Matomo also looked great heading into 2026. One notable absence from the growth list was AppsFlyer , which has historically been one of the category’s largest and most consistent performers but saw a small down tick in tracked market share. For Development Tools, Divkit posted solid growth. The framework launched in 2025 and is backed by Yandex . Report is totally free and the raw data is available as a free dataset download for the top 1000 app companies / ad domains to see their quarter-over-quarter 2026 Q1 growth: https://appgoblin.info/reports/app-ecosystem-report-Q1-2026

0 views
<antirez> Yesterday

Alternatives for the EDIT tool of LLM agents

EDIT: of course this was already done in the past! I had little doubts but people just confirmed me about it on Twitter :) But, keep reading: the CRC32 compromise at the end is an interesting tradeoff, and this is a good discussion to have in general. Right now I'm working to an agent for my DS4 project. Local inference is token-poor, it's a battlefield where optimizations count. I was quite surprised by the fact the EDIT tool everybody is using right now forces the LLM to emit the old version of the text verbatim. This CAS (check and set) mode of operation, where I say EDIT old="foo" new="bar", is needed because there are often colliding edits (the user is editing as well, or checked out a different branch, and so forth) and because the LLM can just hallucinate that a given line had a given content. This means, basically, that just using line numbers is very fragile: to say, change line 22 with new="foobar" is not good. Yet I don't want my local LLM to throw away tokens rewriting the old text each time, also because certain times the old text has a lot of special chars and spaces that the model may get wrong; in this case the tool would fail, forcing the LLM to do the same edit again. So I (re)designed a tag-based EDIT tool that is still CAS style, but more tokens efficient. The READ and SEARCH tools return something like that: 10:Q8fA int count = 10; 11:rA3_ if (count > limit) { 12:Kq9z count = limit; 13:PX0b } So there are line numbers and tags. The tag is 4 chars, on average 2.5 LLM tokens, representing a checksum of the line. Now the LLM can edit like this: { "tool": "edit", "path": "/tmp/example.c", "line": 10, "tag": "Q8fA", "new": "int count = 11;" } Or, multi line, like this: { "tool": "edit", "path": "/tmp/example.c", "lines": "11:rA3_\n12:Kq9z\n13:PX0b", "new": "if (count > limit)\n return limit;" } The saving is significant especially when the agent is deleting big amounts of text, but also in the general case. However, there is some overhead due to the fact we have line numbers and tags. There are potential tradeoffs, maybe the tag should be 8 chars and include the line number in the hash, there is to check exactly collisions possibilities and tokenization to see how much this is a win, but I like the line:tag format as later the LLM is often able to exploit the line information in many ways, like to get ranges in successive tool calls. Maybe there are other ways to exploit the tag, too, like: is this line still dj4_? The interesting thing is that DeepSeek v4 Flash is able to use this tool in a very effective way, so apparently it is natural for it. And while I did't measure the exact savings I saw in the field that edits are much faster and even more reliable. The alternative to this is to return just the whole file CRC32 each time (basically the tag becomes a file tag, even for partial reads). So that we can only work with line numbers + CRC, the edit would just specify 11,12,13,14. Less tokens, of course. This forces, however, to recompute the CRC32 of the file each time, but for reasonably sized files this is cheap enough. But this approach has limits: we fail the edit even if *unrelated* changes happened, so there is a strong tradeoff at play. To be fair to the whole file method, there is to say that it allows to specify ranges as 10:23, which is a huge win. I have the feeling I can decide which is better only with enough practical evidence, by using ds4-agent over multiple sessions with the two systems. For now maybe a command line to switch the edit mode is the first right step to do. Comments

0 views
Unsung Yesterday

“Accents are an opportunity, not a burden.”

The iOS 26 update introduced a bug in the Czech keyboard. Instead of the customary háček (ǍǎĚěǦǧǏǐǑǒǓǔY̌y̌) in the bottom row, another key was duplicated, removing access to the accent character (or, a diacritic ) very popular in that language. Here is the before and after of this situation: = 3x)" srcset="https://unsung.aresluna.org/_media/accents-are-an-opportunity-not-a-burden/1-framed.1600w.avif" type="image/avif"> = 3x)" srcset="https://unsung.aresluna.org/_media/accents-are-an-opportunity-not-a-burden/2-framed.1600w.avif" type="image/avif"> Ordinarily, this can be frustrating but not insurmountable; you can always copy/​paste, rely on autocorrect to help out, or even add some topical text replacements for common phrases. The problem is that this bug only appeared on the keyboard used for logging on, and at least a few people used that character in their password. There, none of these workarounds were available – and so those people were now completely locked out of their iPhones. The Register reported on this on April 12 , and a few days later suggested that Apple was working on a fix. I won’t keep you in suspense; I just verified that the fix landed with the recent May 11 update. This is, in an of itself, not a fascinating story, but with interesting things to talk about at its periphery. First of all, The Register never showed a single screenshot. This led to a lot of confusion and speculation in the comments. Turns out, screenshots are valuable not just with bug reporting, but also with bug reporting . Second, check out this Czech keyboard. Even within the limitations of the ancient QWERTY, there’s a lot of cool stuff happening here. Two new accented keys just appear on the top layer when you switch to Czech. Both have magical properties, too. They’re the modern “ dead keys ” that either stand alone, or get combined with the previous letter if that makes sense. This is the stuff typewriters, and even desktop keyboards, could only dream of. But, as always, more software means more bugs, including some with unforeseen consequences; a typewriter could never break this way. Thirdly, there is this interesting tension between us being led to believe “more interesting passwords are safer,” but then sometimes being penalized for actually making them interesting. A decade ago someone used emoji in their password without realizing they won’t be able to input it, and I’m sure there were other examples. But the most interesting, to me, part? It’s the diacritic itself. Under one of the posts, a commenter wrote: Stick with the 7-bit ASCII subset. You will never go wrong. 7-bit ASCII basically means “26 Western letters and nothing else.” I hate this. I know it’s objectively true – in the late 1980s I felt a sense of relief my name didn’t have any of Polish language’s nine diacritics, which would complicate my life. Even just yesterday in Germany, I spotted this: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/accents-are-an-opportunity-not-a-burden/4.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/accents-are-an-opportunity-not-a-burden/4.1600w.avif" type="image/avif"> = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/accents-are-an-opportunity-not-a-burden/5.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/accents-are-an-opportunity-not-a-burden/5.1600w.avif" type="image/avif"> Software still struggles beyond ASCII. But this is why we need to keep pushing. Diacritical characters are to be found everywhere in the world. They’re detailed, and varied, and filled with histories. Umlaut is not diaeresis . Kreska is not the acute. A háček is not a breve. They’re rarely optional decoration, and often not even decoration at all; learning about Turkish dotless i might completely upend your understanding of what’s an accent and what is not. If you don’t have a favourite diacritic , you are missing out. Even the names – grave! ogonek! horn! – are beautiful. (Háček is also known as caron and a wedge depending on context, and in other regions referred to with beautiful words kvačica and strešica.) If you’re interested, here is David J. Ross’s 22-minute talk about getting to love diacritics from the perspective of a type designer. It’s filled with craft and playfulness: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/accents-are-an-opportunity-not-a-burden/yt1.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/accents-are-an-opportunity-not-a-burden/yt1.1600w.avif" type="image/avif"> My favourite accent is, obviously, ogonek. Just looking at Adam Twardoch’s guide on how it should be drawn fills my heart with joy: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/accents-are-an-opportunity-not-a-burden/6.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/accents-are-an-opportunity-not-a-burden/6.1600w.avif" type="image/avif"> #bugs #david jonathan ross #localization #security #typography #youtube

0 views