Latest Posts (20 found)
Unsung Today

I was wrong about Duff’s device

Duff’s device is a C language technique that looks like this: It achieves two things: I always assumed the technique is from the 1970s and was just a show-offy thing that didn’t serve any function, a “look how clever I am” from a programmer who was perhaps just a touch too nerdy. But yesterday, I found a 1988 message from its inventor , Tom Duff, and it turns out I got almost everything wrong. First of all, the technique was from 1983, when Duff was at Lucasfilm – much later than I expected. Second of all, it actually solved a problem. Duff’s device wasn’t just making things faster abstractly, but actually fixed a user-visible performance issue. “[The loop before applying the device] was the bottleneck in a real-time animation playback program which ran too slowly by about 50%,” writes Duff. Most importantly, however, Duff himself had mixed feelings about it: Disgusting, no? But it compiles and runs just fine. I feel a combination of pride and revulsion at this discovery. I recognize this set of feelings from many different software hacks I invented in my life. I think it’s important to carry them all with you – not fall in love with the hack and continue seeing it for what it is (and what it will be in the future as code ages), but at the same time not be above using it if it’s solving a real issue. Also, Duff adds: Many people […] have said that the worst feature of C is that switches don’t break automatically before each case label. This code forms some sort of argument in that debate, but I’m not sure whether it’s for or against. I can’t speak for C, but I have always felt frustrated about JavaScript stealing that convention – it’s so error-prone, and in my many years programming in it, I have never had to use a Duff’s device or anything else that benefitted from it. #coding #hacks It unrolls the loop in chunks of eight. Unrolling the loop is when instead of telling the computer “do X 5 times,” you say “do X do X do X do X do X,” trading some code readability and memory usage for higher speed. It cleverly (ab)uses a property of the C language to unroll the remainder of the loop, which normally would be impossible to do as the remainder is less than 8 and different every time. It does so by basically overlapping a / loop atop a / structure in a way that should come with a coding equivalent of a parental warning.

0 views

An Interview with Figma CEO Dylan Field About Design and AI

Good morning, This week’s Stratechery interview is with Figma co-founder and CEO Dylan Field . Field was a Thiel Fellow who dropped out of Brown in 2012 to start Figma. Figma was born of a technical breakthrough that leveraged WebGL to deliver powerful graphical capabilities in the browser; the browser made Figma collaborative, what I call the operating system of design . Figma has had a fascinating road: the company accepted an acquisition offer from Adobe in 2022, but due to regulatory resistence the latter was forced to abandon the merger in late 2023. Figma instead IPO’d in 2025 , and after skyrocketing to a valuation of $56.3 billion, has since crashed to a market cap of less than $10 billion, less than half of Adobe’s offer, thanks in large part to a market narrative that the company is an AI loser. I talk to Field about all of this, including his background, Figma’s differentiation discovery process, and the nature of creativity versus design. We get into the AI question, which the market views as a headwind, but which Field sees as a tailwind. To that end, the occasion for this interview was Figma’s Config conference and Field’s keynote where he explained how Figma’s Canvas was the natural intersection between design and AI. As a reminder, all Stratechery content, including interviews, is available as a podcast; click the link at the top of this email to add Stratechery to your podcast player. On to the Interview: This interview is lightly edited for clarity. Dylan Field, it feels like this interview has been in the works for years, but welcome to Stratechery. DF: Thank you, appreciate you having me, and big fan. Let’s start with your background. Where did you grow up, how did you become interested in technology? I always love these stories, especially the first time I talk to someone, and I think yours is a particularly interesting one. So give me the story. DF: I grew up in Penngrove, California, which is near Petaluma in Sonoma County — but not Sonoma, it’s critical to make sure people know where Penngrove is. My mom was an elementary school teacher, my dad a respiratory therapist, both not especially tech-savvy, but my mom early on realized that a computer would be useful for me to stop bugging them with questions and bug the computer instead. So I was lucky enough to get a — I think it was a Compaq Presario — when I was like five the family got one, and then I proceeded to really hog it. I’ve pretty much been interested in technology as far back as I can remember, I was very eager and excited to learn how to program, but didn’t necessarily have the ability to get my hands in a compiler for a while. It took until I got through some scholastic program, a BASIC compiler, to actually get properly started. I’ve also always had a, maybe not as much ability as I’d like, but a deep fascination with mathematics and just really everything in the world. And so this is just a fascination with the technology — like, how does this thing actually work, and how can I make it do what I want? DF: It was always more about product and design and about what technology will look like in the future and how to get there, rather than “I can really master the technology and have it under my control”, that was never really my vibe. What were the sorts of things you imagined you wanted to make as a kid, when you have this computer you want to figure out? DF: Walking around as a kid I was probably thinking less about the computer and more about, “Why can’t I teleport?”, or, on the flip side, going to SFO the first time and seeing they had these magical faucets where you put your hand in front and the water comes out and you didn’t have to touch anything — and I was a germaphobic kid — I’m like, “Why can’t the entire bathroom be automated?”, it’s just so obvious. Or, before I even learned how to properly read and write, “Why can’t I talk to the computer?”, stuff like that was more what I was excited by. Are you encouraged or discouraged by the progression of bathroom technology over the years? DF: Encouraged. Toto ‘s wonderful. Yes! It’s funny, because Toto is in the news because they make a certain sort of ceramic that’s used for AI stuff. I’m like, “Look, I’ve known about and been a Toto fan and supporter for many, many years”. DF: (laughing) I didn’t know that. Well, the other critical design invention here, which is very underappreciated, if you’re leaving a bathroom and you can use your foot to pull open the door, that is an underappreciated progression. Oh, there you go, that makes total sense, I can’t say I have that in my bathroom, but I do have a Toto Washlet toilet, they are well worth it — the only problem is you’ll be spoiled for life and won’t be able to live without it. So you end up at Brown — not what you’d think of as a technology school, it’s next door to RISD, which is a design school, so there’s an angle to where you ended up. What was the path to getting there, and the path to leaving as a Thiel Fellow ? DF: During high school I was probably a little overconfident, thought I could do anything and was beyond bright, and the world quickly proved me wrong, “Okay, there are people far smarter than you”. But due to that identity, I thought maybe MIT would be the place I want to go, then I toured MIT and it was a cloudy day, midterms, and I went, “No, this isn’t for me”, and looked at other spots. One person I’d talked with a lot was Danah Boyd — I met her through O’Reilly Media — and she was a really brilliant, thoughtful person, and she said, “You’ve really got to think about Brown”, and I kept randomly meeting Brown grads as I was doing this East Coast college tour, very randomly, and they’d all sit me down for an hour and tell me, “You’ve got to apply to Brown, and if you get in, you’ve got to go”. I ended up applying to Olin and Brown on the East Coast out of ten schools I visited, I was thorough, I didn’t get into Olin, which I thought was my first choice at the time. And then Brown, I was very surprised but thrilled to get in. What did you think you were going to study at that point? DF: Computer science and math, I did formally declare that as my concentration, but I didn’t get as far on the math side as I would have liked — did more CS classes, and also took advantage of Brown’s amazing open curriculum, where you can go very broad, I had some incredible classes in areas that are not technical at all. So where did the Thiel Fellowship come into the story? DF: It was the fall semester of my junior year. I was aware of the Thiel Fellowship — I’d seen it online, thought it was kind of a weird idea, but interesting. I got introduced to it by Elizabeth Stark , who now is, I believe, leading Lightning , she introduced me to one of the Thiel Fellows at the time, Dale. It was this weird one where he was 25 minutes late to a 30-minute meeting at Starbucks — we met for five minutes, but then he just kept texting me, “You’ve got to apply to the Thiel Fellowship”, very similar to the Brown story. I ended up applying after speaking with my now co-founder, Evan Wallace . Evan was the most brilliant person around — a year above me at Brown, my TA for multiple classes, and truly a genius, someone who’s also just fundamentally kind, humble, wonderful. I was like, “Man, I’ve done some internships now, there’s no one better to start a company with”, and if Evan were down for that instead of any number of jobs he can get when he graduates, I’d learn more from it than anything else — I can always go back to Brown, so I should at least explore it, and he surprisingly was down to explore it with me. So I applied to the Thiel Fellowship with a drones idea — which I think now is best being done by BRINC . Evan was just not down for that direction, he was down for WebGL and graphics, and I was psyched by that too, that’s the direction we headed. Tell me about the drones idea and the pivot to the WebGL angle, because it ties into the question I asked at the beginning — what were you pursuing? Was it the technology, or the end state? I think that’s an interesting through-line here. DF: I’ve always been excited about a lot of things — creation, creativity, design, even before I knew what to call design, which was most of my life at that point, I’d only recently learned what the word “design” meant, despite having done a lot of design. For me, I saw the act of starting a company was also about asking the question, “Why now?”, there are so many “Why now?” answers you can give, it can be societal change, cultural, technological, regulatory. But we were technologists at our core, so we made a big long list of all the technologies that were changing at the time and gradually crossed each one off, we came up with two finalists. One was drones, this is the end of 2011, the other one was WebGL. I think we would have totally failed at drones anyway, it’s extremely hard. You look at Zipline , BRINC — these are amazing companies, and you really have to chew glass to get through that, we wanted to do something where we felt we had a technological edge and insight others did not. And what was the technical edge and insight about WebGL? This is obviously the foundation of Figma — you can do incredible graphical things in the browser, which to that point had all been on dedicated desktop applications. What was the insight that made you think this might be possible, even if it was just barely possible? DF: To be clear, right after applying for the Thiel Fellowship with the drones idea, I ended up working at Flipboard as a design intern, using design programs all day long. We had this hammer with WebGL looking for a nail, we didn’t find the, “Let’s go build design environments and help designers”, for a while, it took a little bit. What was exciting was that Evan had done a lot of early work that proved out that WebGL was way more capable than anyone else was thinking at the time. Other folks then were going, “WebGL is this weird toy that Mozilla is making, it’s probably not as important as just using your local, non-browser tech”. Right, if you use an application that can actually leverage regular OpenGL and your GPU, why a browser? DF: Exactly. The only other company that seemed on to it at the time was Onshape , actually. We looked around and went, “These guys get it”, and pretty much no one else did yet, no one took it seriously. So due to Evan’s work, we started to really explore that and go, “How can we take tools that people expect to be desktop-bound and local, bring them to the browser, and do it collaboratively too?”. We were very inspired by Google Wave — rest in peace, it was a really cool product. I grew up in Google Docs, playing MMOs and stuff like that, so I think our frame of reference, even if we couldn’t articulate it then, was just different — obviously the browser enables all of that. You viewed the browser as a first-class operating environment in a way that probably older people did not. DF: Yeah, exactly. In the early days of Figma I’d say, “Just like Google Docs”, and a lot of people were like, “Yeah, well, I use Word — why would I use Google Docs?”, and I was like, “Well, I’ve only used Google Docs my entire life”. And then, “Well, I guess there was that time in middle school…”, and they’re going, “Wait, how young are you?”. Well, let’s talk about what Figma is. I’ve written about Figma in contrast to Sketch , which is more of a single-player experience — this idea that Adobe left this huge window open for actually designing apps. Mobile apps come along in particular, an exploding market, actually placing all the screens, how it all flows together, they didn’t have a product for that. Sketch comes in and fills that gap, but it’s still an application on your computer, and you’re saving files that are v1, v2, v5000. Figma, by virtue of being in the browser, got collaboration for free — it’s a multiplayer experience. When did that possibility become clear? You mention the collaboration aspects, but as I understand it, you were trying to get WebGL to work first, and then realized this is good for collaboration. Is that the right sequence, or did you have the benefit of being in the browser — meaning multiple people could work on something at the same time — all along? DF: I would say from day zero, Evan and I were talking about it, and we were both trying to be very rational. On collaboration, we wanted to talk with users and see, “Do they need it?”, and basically everyone said, “Not only do we not need it, we don’t want it”. Right, there was a lot of asking jockeys if they wanted cars. DF: Well, I think it was more an identity thing of, “I’m a designer”, and there was a lot of agency influence on the design process at that time — this kind of grand reveal where you just work in the corner. Oh yeah, you own it, it’s on your computer, you’re doing it, and then you go into the meeting and show it. DF: No one sees it until it’s perfectly ready, then you show a few results, maybe give them three, the first two are kind of not what you want, but the third, “Oh, the contrast is so great”, and everyone goes with it. So that agency mindset and identity, as well as imposter syndrome, honestly, because design was just emerging from this phase where people saw it as, “Make it pretty”, versus, “Make it work”. This is a key element of how we build product, build software, do media and advertising, and people were just starting to appreciate it with all the Apple ethos of the time and great consumer products coming out. So we had the insight from the start, but it took us a while. Eventually, as we built it out and started fully using Figma to build and design Figma, it was immediately clear there was no way we could launch without collaboration, because it just felt wrong. If you’re in Figma and I share a doc with you, a link, and you’re in it too, and I make a change and your browser force-reloads, and you make a change and my browser force-reloads, it sucks. So it was a, “We have to do this thing”, and it was not trivial at the time — it took quite a long time to build out. Evan was a key part of that, as he was with a lot of our foundational technology, it was a key condition for our launch in 2016. Is it ironic that Apple sort of created the conditions for you in raising the stature of design and that being the controlling factor in development, even as their whole tech approach is counter to you, not really supporting WebGL, being all-in on applications? It’s kind of interesting. DF: I don’t think Apple’s tech approach is counter to us at this point. At this point. But they were all-in on, “You use apps, that’s what they’re for”, this idea that you’re going to collaborate on the web — I’m not saying they hurt you, I’m just saying there’s a reason Figma only worked in Chrome for a long time, for example. DF: Apple reasonably was concerned about battery and device performance, and took a very vertical approach as they do with everything, and also was patient — just like we’re seeing now with them. When it became the right time, they added in collaboration to many other surfaces and figured out how to make it work with the cloud but I think they showed the importance of design to the world in a way that had never been so vocal before, and it raised the level of the conversation. You could argue Microsoft at the same point was also really leaning into design, but they weren’t as vocal — they didn’t have Steve Jobs talking about “Design, design, design”, they had “Developers, developers, developers”, it’s just a different tune. Yeah, that’s interesting. Is there any context, looking back now, where Figma makes sense for one person? Or is it really a product that only makes sense if you view it in this context of collaboration? DF: A ton of people that use Figma use it individually, and I think it’s critical that you build tools that work for someone individually, that they can then graduate into a collaborative stance and use with their team. But you have to get the single-player experience right and then let it evolve to multiplayer. So when you started going to market, what was your selling point? The tool itself, the accessibility, or was collaboration the key from the get-go? DF: When we first did our closed beta, multiplayer collaboration didn’t yet exist in the product. It did have sharing, and that was very powerful — you had this one space to view your designs with your team, and people were doing that in very team-oriented ways. But early on, things like our improvements on vectors, or the simplicity and quality of Figma, were more the differentiators — and then design systems with a unique component approach, and then multiplayer, and then many other things. We also got a lot of minimalists in our early user base — folks who believe in the cloud and believed in minimalism, because we didn’t have all the features. It was interesting just to see that early base of users and how successful they were — two of our earliest customers were Coda and Notion — just kind of wild that those were two of the first customers we had. I don’t even think Shishir [Mehrotra] at Coda knew that at the time — I once brought him in to talk with the team about platform strategy stuff, and I mentioned this offhand as an intro comment, and he’s like, “I was what?”, so it was a fun group to be around. How much do you think Figma has evolved with your customer base, as opposed to Figma actually influencing your customer base and how they evolve? Did your customer base naturally become collaborative and realize they needed Figma, or did Figma introduce them to working in a more collaborative manner that they hadn’t considered because the tools weren’t there? DF: There was definitely a period of adaptation, some people got it right away, for others it was over time. Our first big marketing moment — I remember there was a site, Designer News, sadly I think it’s offline now, and there was a comment on the launch thread, “If this is the future of design, I’m changing careers”, or someone said, “A camel is a horse designed by a committee”. But we went deep on anyone who had really positive or really negative sentiment around Figma — great, let’s learn from all of it and adapt as we need to, while also having our own points of view and pushing for them. Customers have always been inspiring to us, we’ve tried to take feedback from everywhere — support tickets, in-person conversations, formal research, sales, social media — for a while, social media was a great signal, it’s not as good a signal as it once was. Our user forums, everything, and data analytics. As you get there, you form a picture or view of the world, you play anthropologist and understand what people truly need and sometimes the moment just changes. FigJam , for example, was a product we introduced right after the pandemic started, I’d always wanted to make a whiteboarding and diagramming product — I saw that use case in the wild, it was significant, I felt we could make a simpler tool. But rightfully, the team was skeptical, always going, “Is this the right time? We have a lot of other stuff to do to make Figma great”, that debate stopped with the pandemic, when our user base wrote in en masse and said, “Please, please give us this product”. We need a whiteboard, yeah. DF: Yeah. We started seeing that use case everywhere — people treating Figma like a shared space and the shared-space part of Figma is something we’re doubling down on. Was that the real turning point, “This is where work is done”? I’ve called Figma the operating system of design , in that everything sits on top of it and below it, but it’s the common layer, does that resonate? Is that the moment that became much more real? DF: It was happening already in many ways, we were doing it ourselves, seeing it with our customers, but the pandemic is when everyone started telling us, vocally, “Lean into this”. There’s so much more that’s possible now as we bring more mediums to the Canvas , more expression to the Canvas, and let people truly get what’s in their heads onto one shared Canvas — to collaborate, but also riff, see a bird’s-eye view, and directly manipulate. AI is great, prompting is great, you should be able to do it in Figma — and you can now, with our agent , but you can’t filter all of creation through the lens of AI. If you have an idea, or many ideas in your head, you need to get them out directly too and also you have to iterate to get to an exploratory place. Too much emphasis right now is put on “I’m working with the AI, the AI wants to go a certain direction, and I’m going along with it”, it’s almost like, “Is the AI using you, or are you using the AI?” — sometimes it’s unclear. AI is a tool people can direct and work with, it can resolve tedium, but you also have to push, you have to be the out-of-distribution force, because AI is trained on the distribution, and the most interesting, differentiated work will be out of distribution by definition. So I have questions about that, I have questions about AI, and questions about Canvas, which is a big focus of what you’re talking about at Config this week. But I want to do a quick side tour, because I must, another very famous single-player design company, as I mentioned, is Adobe. The Adobe acquisition was announced in September 2022. I’d written — we don’t have to spend too much time on this, obviously it didn’t happen, so in some respects it’s not that important — but by that point— DF: Yeah, but it felt like it didn’t happen for a long time, those 16 months felt like an eternity. That’s right, which I do want to ask you about, get your point of view on. But one thing I’m curious about, I actually remember where I was when this happened, I’d written several times at that point about generative AI, particularly images , the AI question loomed very large to me when that news came out. But that was still a few months before ChatGPT had launched, so this was more burbling under the surface. To what extent was AI part of the Adobe conversation? There’s a very plausible story that it wasn’t part of the conversation at all — you were the operating system for design, the operating system can disintermediate all the products that sit on top of it, which from Adobe’s perspective was a strategic problem. They had a huge hole in this space, Sketch had already taken that whole space on the single-player level, so I thought it was an obvious acquisition for Adobe, aside from all the AI stuff, just looking backwards. Which interpretation is correct? DF: Probably both. I think Adobe was super excited about AI and understood its potential and importance, we had plenty of conversation about that, but it was not, I think, the impetus or driving factor for me though in making the call of, “Do we sell or not?”. I had no idea, would AI would 1/10th, or 10x, or 100x our business? I was in my head trying to play it all out, and as we’ve seen, it’s hard to play these things out. You kind of know what’s coming, but knowing when it’s coming, and the second-, third-, and fourth-order effects — that’s hard. And this is pre-ChatGPT, so imagine trying to play out the next five, six, seven years from that point, that made me much more receptive to a conversation. That makes total sense. For Adobe, I don’t think it was the controlling factor — again, you just made tons of strategic sense for them. But for you, it’s like, “$20 billion is very certain and everything else is very uncertain”, that makes a lot of sense. DF: Another contributing factor was that I was excited about the opportunity to think about Adobe’s Creative Suite from first principles, and go back to the user’s problems. Yeah — it’s missing the layer that Figma provides, the thing that actually ties it all together. DF: There’s so much expectation from users of any software that’s been around a long time. There’s a need that reinforces itself to “Add, add, add”, versus thinking, “Okay, we’ve learned a lot — how do we reinvent from the start and think about things in a new paradigm?”. Looking back now, AI is clearly going to be — and already is — a tailwind for our business, it’s TAM-expansive in huge ways I probably never anticipated at the time, it’s also interesting from the Adobe frame, because I’d challenge the way you framed it earlier. DF: Adobe acquired Macromedia , and through that got Fireworks — and Fireworks was really the predecessor to Figma and Sketch, but not a focus for Adobe. They had different Labs projects, but this was not their core, their core was creativity — for Figma, our core has always been design, those were different when the Adobe conversations were happening. Explain that, because I think I see what you’re saying, but people would usually conflate them — creativity and design. DF: The even bigger question, for the philosophers and art-theory folks, is, “What’s design?”, “What’s art?”, how do you differentiate design versus art? It’s muddy, but design has an aspect of problem-solving, it also has creativity. Art, I think, is a lot of things — you can get endless definitions of design and art — but I think of it as trying to take an emotion, idea, or concept and communicate it to someone in a way that really affects them. That’s not best framed as problem-solving, whereas design is. How about this definition: art is an expression that it’s meant to be consumed by the end user, and design is meant to serve the end user. DF: Well, I don’t even know if you should define art as being for an end user. Yeah, good point. DF: For me, one of the definitions I lean on is that design is where problem-solving meets creativity. Figma has always had people using the platform for creative use cases. But now you fast-forward to 2026, and design, creativity, media, in some ways art and in some ways not, and advertising — it’s all kind of merging together, it’s all one thing in a way I wouldn’t even have said in 2025. If you believe we’re in an attention economy — you experience this every day — and you believe you have to have a differentiated voice and really have a point of view in your work to stand out, and you think the way people judge software is the design, that’s the differentiator, but you also have to grab someone’s attention, design and brand are so connected. It’s all really coming together in such an interesting way, because of these second-order effects of more creation happening in the first place. A phrase you’ve mentioned, you said it earlier in this conversation, you’ve said it plenty of times elsewhere, is that AI draws from the middle of the distribution, and to be differentiated you need to be at the tails. That makes sense, but it’s funny because it conflicts with — go back to that user comment that’s deleted from the Internet, “Collaboration is the death of design”, do you see any tensions there? You talk about Adobe, creativity, tied to single-player, the genius of one person, versus, “We’re a group of people collaborating to get a design out the door”. How does that not end up in the middle of the distribution too? DF: It’s more of a mindset thing for any design team are they trying to do the safe thing, are they tryigng to go for the least common denominator where everyone agrees it’s a good idea? Or are they trying to be daring and bold and take risk? What we’re going to see over the coming years is the market rewarding the risk-takers. And I wouldn’t say it’s enough to be at the tail of the distribution — I think you have to be out of distribution. Is that possible? Aren’t you on the very edges of the tail? Fair enough. DF: I think every email I get from your mailing list is out of distribution. Well, thank you. I appreciate it. DF: If you can get one of the AI systems to replicate your judgment and framework-building, I would love to see it. I would both love to see it and hate to see it, so I guess it cuts both ways. DF: Sure, I might love to see it in terms of wanting to know how you did it. Well, it’s interesting for you, obviously. You mentioned a few minutes ago that AI is a tailwind for your business, I think it’s safe to say the stock market by and large does not agree with that, yet you’re there producing incredible results — you had a great quarter last quarter , your biggest beat yet. Do you feel you’re in the middle of trying to prove a negative here? What are the drivers of your business? Do you have some sympathy for the people in the market who are skeptical of you, or do they just not get it? DF: Markets typically have a narrative they’re attached to, and the narrative can shift — and maybe it’s still not the nuanced narrative that matters, but this happens all the time. Markets are so impressive as a force, and I just don’t think it’s worthwhile to try to argue with a market narrative. Are they normal distributions, and you’re trying to operate outside the distribution? DF: (laughing) I like that frame. I just think that you show up, you do great work, you focus on the inputs, you educate to make sure people understand, and eventually that’s either appreciated or not, depending on how the narrative is going. Right now the narrative is one of AI winners and AI losers, I don’t even think that’s nuanced enough, if I think more globally about software, there are many software companies and strategies that will work that are not necessarily companies and strategies that people would necessarily call AI winners today. I think about network effects. Are you a network effects business? DF: Collaboration definitely has properties similar to network effects, so in some ways, yes. And if you look at network effects not just in the social sense between people but also for marketplace liquidity — that is absolutely a network effect in itself, just to have liquidity in a marketplace, I would say that’s an AI winner. If you look at the long tail of customers that are non-technical — I invest in companies occasionally, and one of them is Ambrook , an accounting-for-farmers company. I don’t think a lot of people in ag [agriculture] will be vibe-coding their taxes, they’ll care very much to have a human in the loop, for the certainty that this part of their business is going well and they don’t have to worry about it. I really believe Ambrook can provide a phenomenal solution there. I also think liquidity of data matters — you need equity of data to create context, and context creates capability, if that’s self-reinforcing, you can get to a place where you have a virtuous flywheel that really helps in the age of AI. Explain this in the context of Figma specifically, why does this provide a tailwind for you? DF: I won’t go too deep, since it’s strategy, but the more activity people do in Figma, the more we can, with their permission, understand their needs and serve them better with capabilities. If we do that right, that’s a way to continually improve the experience for the customer and make it so they can do even better work, faster, in Figma. How are you thinking about the models that undergird your various AI offerings? DF: You always want to be in a place where models are swappable. We’re in an explosive, wild period of models constantly shipping, I went to bed last night and saw Sakana’s new release — I haven’t played with it yet, recording on Monday June 22nd just for reference. I didn’t expect that, coming out with their ultra model and their approach and just seeing the progress these labs are making, sometimes in a discontinuous way, is incredible. Right now we use a range of models and do some stuff first-party— And these would be based on open-weights models? DF: Some on open weights, some on very small things we’ve worked on. Overall, I think that there’s a big story around local inference that will happen in the future, as well as open weights and different models are good at different things, it’s incredible. Is it fair to step back and say — from your perspective, which echoes a Microsoft perspective , or lots of other companies in a similar position — yes, models have to be swappable, customers don’t want to be locked in, but there’s also a self-interest position, you need to keep this data to understand customers better, and you need to not be giving that data to the models, who at the frontier need to not be swappable. Do you feel they have no choice but to come up into your space? Is there a perspective where Claude Design comes out and it’s like, “Yeah, of course that’s coming, because they have to own the consumer”? DF: I think if you look at Anthropic right now — it echoes what we’ve seen from OpenAI over the past year, where there was a period when OpenAI was just building and releasing stuff in every area. And they, to their credit, have pivoted hard, made some hard calls, pulling back on Sora . That’s not an easy call after you do deals with major media players and have a huge launch and people are really enjoying the product, Sora was really cool, but going all in on code seems to be the right move for them right now, and it’s very respectable that they’re doing it. Anthropic’s going through a similar pattern, we’ll see what lasts and what ends up persisting. That’s an interesting way to think about it. Did you feel pretty betrayed about the design thing — particularly when one of their executives was on your board ? DF: It’s complicated. Let’s put it that way. Fair enough. I think it’s one of those things you could definitely see it coming. Tell me about Config. One of the products you’re going to announce is Code on the Canvas , tell me about that, and how it fits into the overall way you’re thinking about AI. DF: Maybe to frame it up to start and dispel some of the stuff out there in terms of the way people talk about this — people on social media love to frame the “versus”, they’re always talking about code versus design, like they’re two different things. To me, the work is not just vectors — it’s vectors, images, prototyping code, because you don’t always want to work in production, and production code, and production code needs to be across all your surfaces, web, desktop, all your mobile devices, new screen types, etc. All of that is relevant to your process, and all that process is design. So it’s super important to see it all as an “and” rather than a “versus”, I just want to make that clear because otherwise nothing else will make sense to folks. If you think about it as an “and” and go all the way into what that means, then basically what you end up with is, “How do you bring these different mediums, these different materials, together in one place where it’s easy to go back and forth and get the benefits of each?”. For design representations like vectors and images, I think there are many ways those are very helpful — especially vector-based formats, for direct manipulation and precise control, in ways that code, which is structured, is not as easy to manipulate and mold. But code is also incredible, it’s got expressivity, full fidelity, it acts the way it will in production — hopefully, a prototype might differ from production — and you can have state and logic but you’ve really got to bring these things together. So what we’re doing, based on the work we’ve done on Make , either from Make or by creating on the canvas yourself with code — essentially a code layer. You can have Code on the Canvas that pulls in from design if you want, and go right back to design — make changes and reconcile them back to code. We’re trying to make that all work seamlessly together, so you have a breadth of exploration while also having the collaborative aspects of the canvas and that bird’s-eye view. Is one way to think about this that the question is that you can you eat development before development tools eat you? DF: I think less that way, because my conceptualization of the moment we’re in is one that people are so eager to try so many different tools and materials — in some cases we’re going to be the best place to use those materials, in Figma, in other cases you’ll want to go elsewhere — and you might even want to come back to Figma afterward. I’ve been thinking about this, the vibe-coding stuff is amazing, particularly in its ability to build scaffolding and get the functionality of an app and the user experience these tools build is hilariously horrible — it’s so bad, you really have to put much more of a heavy hand on it. When you talk about a phrase you’ve been saying regularly — that when execution is cheap, design and creativity are the edge, that’s very resonant to me in that actually conveying properly to the AI what you want is still a difficult challenge without it over-interpreting and over-assuming and spitting out a UI that makes no sense, and the design’s not just wrong at a pixel level, it’s wrong at a conceptual level. I guess the question I have, and what I think you’re getting at with Code in the Canvas, correct me if I’m wrong — is that you guys owned the handoff between designers and developers where Figma was the common level where you could communicate back and forth, what’s happening, how it’s working. To some extent, if the developers are doomed, God bless them, designers rule the world — but did you accidentally erase your whole point of differentiation, which is owning that handoff between those two pieces? I don’t know if that makes sense, but it’s an angle I’ve been thinking about here. DF: I don’t think developers are doomed, and I do think designers will rule the world. (laughing) Both can be true! DF: But I need to go all the way back for a second, when we started Figma, the first five years or so in market, a big part of our story, but also the ecosystem around us, was prototyping. And prototyping was not always with code, some companies tried that approach, but it didn’t really work at the time, because despite all the debate of, “Should designers code?” — debates that happen every year or two on Design Twitter, we would constantly see that designers did not all want to learn or take the time to code. Now we’re in a world where it’s easier for designers to put their ideas into code. If you look at the prototyping aspect alone, in the Canvas, whether you’re working with production materials or prototyping, you need to be able to riff and explore and try things, and design representations are just one part of that, so is code. We’re also doing more launches at Config that add to that story. Motion, for example . Yep, huge focus on this. You bought Weavy now you’re calling it Weave . DF: Weavy, and now Weave, yeah. I love talking about Weave , it’s so cool. But Motion is actually coming from a hybrid of Figmates and a team we acquired called Modyfi . It’s something folks have always wanted — a timeline they can use in the Canvas and of course the challenge is how to do that in a way that doesn’t get in your way if you’re not trying to do Motion work. I think we’ve done a great job balancing those tradeoffs while providing a really powerful motion tool that’s much more intuitive than other approaches of the past and it’ll allow people go far more into expression, because it’s very hard to prompt and say, “I want the curve of the animation to be exactly like this”, the work we’re seeing folks do, even internally, with this motion tool is so incredible — I’m just totally wowed. We’re also going hard on shaders , going all the way back to the WebGL conversation. It’s ironic, we were built with shaders all this time, but we didn’t give people using Figma the power to express in shaders. Now you can add shader fills and effects, and that unlocks a parametric option space to really explore this whole universe of effects, images, fills, and properties — and that’s even before interactive shaders, which add a whole new dimension, that’ll come soon. We’re excited to bring all these materials to the Canvas so people can fully express and explore. And yes, if we do it right, it’ll be something they can then push to production — whether that’s pulling from Figma via an MCP , or more in the future, connecting to your codebase. We’re doing that with Make local right now, but we have much more to prove out there. I’m curious about that, because how do you think about customer acquisition? Back in the day you’d imagine starting, “Oh, Figma, this tool I’ve heard about, I’m going to make a design, and now I’m going to find a developer to code it”, now people can just get started with a ChatGPT or a Claude, and then it’s like, “Oh, this is really hard to design UI elements”, how do I back into something? How do you make sure you’re there if people are starting with coding in a way they maybe didn’t previously? DF: I see people starting everywhere — that includes Figma, but also all sorts of other tools and places, and I see them ending everywhere. I see them ending in Figma to do the final iteration, ending in LLMs or other services. What I think is essential for us right now is providing enough value always that the path to a great product is through Figma. Yes, optimally you can do that entire path through Figma as well, that’s a standard we should hold ourselves to. But we’ll continue to see people use a range of tools for a while, because these models are so underexplored. If we were to pause all development on models, a total moratorium, I think you’ve got like five years of catch-up on the application layer before the capabilities are understood and expressed through software. Every time I use these models, I find new capabilities. Even there, though, is still the key for Figma is that it’s still the place people can work together? And that’s something AI hasn’t really solved , it’s kind of a one-on-one experience, but you need to figure out how groups can get jobs done. DF: One area is groups working together to converge, I think groups coming together to diverge is also really important. Teams being able to work in all sorts of ways in the future is critical and also what are the things you’re always going to want as a team that are fixed, and what are your degrees of freedom? There’s so much we can lean into on collaboration in ways we’ve never been able to before, and make that single-player experience even better — because if we land all that together, you’ve got the collaborative layer, but also Figma is the place where you can just make anything you want. That sort of leads to my question, which is, is the real Figma danger not that AI becomes multiplayer, but that individuals with AI disrupt multiplayer companies? And that’s why you still have to be relevant to the individual as well. DF: I think it’s kind of a dark future if that happens, it’s one where folks are probably feeling pretty lonely — it’s also one where the tunnel vision you have when you’re building with AI is really becoming a problem for teams, I’m hearing this from design leaders everywhere. There are different phases of AI adoption at these companies, the first phase is often, “We’ve got to use AI, let’s figure that out”, the second is like token-maxxing leaderboards — some extreme behaviors. The third, after they get people to adopt, is often “Okay, here’s your token budget”. In that second phase especially, where people go really wild with AI, it’s hard to get them to change their behavior after. A lot of people have this total tunnel vision of, “I’m building this one thing”, and they get really attached to it. That’s the opposite of the breadth of what a great design process offers. If you’re going through the design process, it’s not that you should slow down necessarily, but you should go broader, and you should think. It’s essential that you actually think — not just wear a thinking cap, you need to be able work through yourself and have a mental model not only of the user and the experience you’re creating, but also cultural impacts, the broader system you exist in, what the user is expecting, all sorts of things. Going fast in the wrong direction is not progress, it’s a dead end, and it’s even worse if you’re collaborating, trying to bring five designers together and each one is viscerally attached to their one direction — now you’ve got design gridlock and you’re talking past each other. So it’s imperative that we move away from this tunnel vision and toward the openness the Canvas represents. Maybe there are other ways too, but we’ve got to get away from tunnel vision. On a personal level, how much do you feel constrained by the path dependency of having already built Figma? If you started out tinkering with tech as a kid, or even with the WebGL stuff, you ended up with a company. Do you ever have a part of you that’s like, “I’d just like to tinker with this tech again and not worry about whether it’s an existential crisis for this huge company I built”? DF: I’m constantly tinkering. It’s my antidote to the non-verifiability of design — because there are verifiable domains and non-verifiable domains. Design is taste, culture, aesthetic, it’s constantly shifting, user experience is something designers can argue about in design crit for as many hours as you give them. Unverifiability is the moat — that’s a good metric. The more something’s been argued about on the Internet, the longer a future it probably has. DF: (laughing) The more you’re oriented toward questions than answers, I think it’s a good sign — it’s going to be harder for models to achieve it in a way that’s high-craft. And as a builder of Figma, that’s where the complexity and the interesting parts lie. The word of the year — not just this year, but 2025 as well — is evals, evals, evals. But how do you write the right evals for non-verifiability? Aren’t evals, in some respects, counter to taste? DF: Depends on how you do them, and who’s writing them, there are ways. It’s hard for LLMs to do well on aesthetics and user experience, like you said, and being surrounded by non-verifiability — when I go home and I’m finally unwinding at 11 o’clock, about to go to sleep, I’m not reaching for Netflix, I’m reaching for some model, and I’m exploring verifiable tasks, actually. Because I want to push the models on the unverifiable side we talked about all day long, but what can we do where it’s really verifiable and they have spiking capabilities? Like vibe-mathing, for example, which oddly creates empathy for our vibe-coders. Because I vibe-math, and as someone who never went as far as I wanted to in pure math and wasn’t as good as others, I don’t know all the concepts the LLMs might be spitting out at me, so I have to learn as fast as I can — which is not fast enough, because the LLM is going through all sorts of stuff. It’s a great tool for learning, and super fun for discovery. And looking at the internals of models, how they work, understanding what you can and can’t determine, is also extremely interesting. It’s all applicable in weird ways to Figma — you never know how. Even early stuff I did around understanding how to get models to have a broader range of outputs, and prompting strategies, I don’t think there’s one definition of the word “jailbreak”, but the things that got the models to open up more, exploring that direction, has really led me to understand models better, which benefits Figma in weird ways. It’s super interesting. We didn’t get too much into the aftermath of Adobe, or the IPO, that sort of thing — but you talk about unverifiability and uncertainty, and that’s been the Figma story often, through things outside your control. It’s been interesting to observe, it really is quite an adventure of a company in many respects, really a unicorn. DF: It’s been a blast, continues to be, and with the world shifting quickly, you can see it as chaos, or as opportunity — or both. Are you glad you’re independent, or do you kind of wish… DF: Oh, at this moment I’m very glad to be independent, we need to operate at such a speed and be able to pivot so quickly to make sure we update our priors. Like the opposite of how you started, right? You started out with a two-year slog to even get this working. DF: Totally. It’s so important now to constantly adjust as an org and make sure our processes support that, there are tons of things to do to improve there. But when people come to Config — which will be, as of the time this is released, I think happened yesterday, time’s weird on podcasts — I’m so excited. It’s going to be 10,000 designers in one place, and I get to spend time with the community and show them the stuff we’ve been working on. I think they’re going to love it and there’s tons more we’re working on, so stay tuned. Very good. Dylan Field, nice to talk to you. DF: Thank you for having me. This Daily Update Interview is also available as a podcast. To receive it in your podcast player, visit Stratechery . The Daily Update is intended for a single recipient, but occasional forwarding is totally fine! If you would like to order multiple subscriptions for your team with a group discount (minimum 5), please contact me directly. Thanks for being a supporter, and have a great day!

0 views

Create Your Own Stamps

The button press kit wasn’t the only recently acquired crafting toolkit in our house, but it was the biggest one—except for the Stuffaloon thing to create your own balloons (yeah, I know…). I just don’t know how my wife finds these things. The problem is that I tend to steal her tools to use for my own journaling purposes. “You always make fun of my crafting stuff but end up using them yourself!” That reproach is only partially correct, but I digress. Here’s a humble but punchy (ha!) punch machine that allows you to create your own stamps. But to what purpose, I hear you think? Ah, but to what purpose have we been born into this increasingly dangerous world, I hear myself think? Wait, we’re digressing again. Punch thing. Right. We have many of these little tools that look like small versions of classic perforatoring contraptions, only this time they don’t eat up two small round pieces at a paper edge of choice: they punch out a custom form, such as a dog, a cactus, or in this case, a rectangular stamp—sawtoothed edges included. The stamping machine in full effect with an assorted collection of newly minted tiny cardboards. The trick to a “good punch” lies in the careful consideration of the viewport: which side of what thing are you trying to stampify ? What angle of which picture do I want to cut out? I’m making up a lot of English words as I go here which is good as it should intensify the homegrown craftiness of this post. I find rummaging through discarded (cardboard) paper especially rewarding with this stamp punch in hand. It turns wrapping film into a tiny piece of art that I can arrange and stick onto a journal page, instantly upping the enjoyment factor of said page. I tried to capture what I’m trying to get across with these weird words here in a photo. Doesn’t the view of all these little homemade stamps make you happy? Some of them are portions of blown up pasta. Some of them are weird angles of flowers or parts of fruit. Others contain a logo of an Italian milling company. Oh, and a yellow Loco Roco harvested from a Retro Magazine that now is permanently crippled. But that’s alright: it was only the PSP page. In case anyone wonders, Hoogstraten is our local strawberry wholesaler. That laughing kid is playing with rubber ducks my son likes to chew on in bath. The red TONY ones come from a bar of Tony Chocoloney , but the two pieces of blown up dark chocolate I cut out together with the logo (not pictured) are from the best Belgian chocolate brand Jacques . And then there are cut-outs from a local bakery logo, a cereal brand, cookies, asparagus, a tea bag, and other stuff I can’t remember. A lot of fun, right? That fun does end somewhere though: the puncher is only satisfied with thick enough paper, edging to true cardboard. Cheap newspaper from local advertisements won’t make the cut—literally. I found cardboard boxes/wrappings from supermarket purchases work best. I have no idea what to do with all these small pieces of paper but my daughter loves showing them off (and destroying them). Most of these will end up in my journal just to spice up the odd boring page or two. Perhaps I should try to send a few letters with them as well and see what happens. Not every part of everything we do should have a purpose and be measurable. Sometimes it’s also fun to just goof around and try to do things without having a specific goal in mind. And in an hour or two, that means you’re bored and willing to move on, that’s fine as well. I have a colleague who’s impressed by the amount of journals I’ve filled, proclaiming “wow that must have been a lot of work!” Sure, but the emphasis on “work” and the time-based aspect doesn’t apply here. It also heals my soul. It also provides raw material for me to publish. And sometimes, more often than not, it yields nothing at all. Maybe we should store everything into a box and in a few months sort our collection by colour and try to lay them out in a particular pattern to create an interesting cut-out poster effect. I just made that up, but the more I think about it, the cooler this idea sounds. Into a box they go! Related topics: / crafting / By Wouter Groeneveld on 25 June 2026.  Reply via email .

0 views

Trailing dots are the worst

Trailing dots after hostnames in URLs remain my worst enemies. I wrote about several problems with them in the past that involved those nasty things. They are still painful. When we shipped curl 8.21.0 on June 24 2026 we fixed at least three brand new problems that involved trailing dots. C’mon, follow me down the trailing dot rabbit hole, episode two. I can just feel that there will be a third episode as well in a future… Let’s for a second imagine that you create a URL that uses a numerical IPv4 address. Not entirely uncommon. For example lots of people use 127.0.0.1 in local tests etc. Used everywhere since the dawn of time. Now imagine that you add a trailing dot to this hostname, like “192.168.0.1.”. What does the trailing dot even mean here? This particular trailing dot caused a problem in curl. To figure out if curl should allow wildcard certificates when connecting to a TLS server, it needs to know if the given hostname is a numerical IP or a hostname. The check uses on the provided hostname extracted from the URL – which incidentally returns false for an IPv4 address that ends with dot! So if it isn’t a numerical address it is a hostname and then we allow wildcards… Argh. I decided to solve this particular problem like this: if the address is a valid IPv4 address and there is only a single dot afterwards, that dot is “swallowed” as part of the regular IPv4 normalization process that curl always does for IPv4 addresses when parsing URLs. This way, a numerical IPv4 address with a trailing dot will never be passed on to curl internals anymore. And the meaning of the trailing dot for this use case is clear: it is a mistake so we get rid of it. (This also seems to be what browsers do.) Shipping in curl 8.21.0. This choice has already been reported problematic by at least one user who expected a transfer for a URL like this to return error… I suppose this means that the jury is still out on what the best approach for this trailing dot is. What could be more fun than trailing dots if not two trailing dots! Two trailing dots is not possible to use as a hostname when resolving hostnames using DNS. It is an illegal name and causes an error. But as curl provides other ways to populate the DNS cache with a provided name, and you can provide names in etc you can make curl work with URLs where the hostname has two trailing dots. Or rather, you could up until recently until I made sure it is properly banned always because of the trouble they cause internally. A double-dot is correctly treated as a host with a trailing dot, but it turns out that in for example the HSTS logic that became problematic as removing the trailing dot for some functions would still have a trailing dot there when there were two of them to begin with… and it would get confused and act up. No more double trailing dots. One is annoying enough. Shipping in curl 8.21.0. HTTP cookies are basically name/value pairs set by the server and held by the client to get sent back to the server again in later communications. The server can specify for which domain a cookie should apply to, so that it can be used across multiple domains. (Yes, it is a little crazy,) To prevent the server from being able to set the cookie on a too wide domain cookie clients check if the specified domain is Public Suffic Domain (PSL) or not. A server is not allowed to set cookies for PSL domains, as that allows it to create “super cookies” that work across domains in ways that are not allowed. Cookies attempted to get set for such a name should be rejected. In libcurl we check domains against the PSL using the libpsl library . Turns out this too could be tricked by trailing dots. If you communicate with the URL “example.co.uk.” (with a trailing dot) and it sets a cookie for for “co.uk.” (with a trailing dot), the internal check would ask libpsl about the PSL status and… it did not work with trailing dots. The exact same process without trailing dots correctly says it is a PSL and the cookie is refused. But with the trailing dots present it was fooled and curl would allow the cookie to get stored and later sent back to such a host… This particular issue ended up considered a vulnerability known as CVE-2026-8924 . Fix shipped in curl 8.21.0. Yes, you can of course quite correctly argue that none of these things are actually new or sudden changes. Trailing dots are there, they have always been there and people will continue to use them in the future. I’m not blaming anyone else. I’m just expressing my frustration. Trailing dots are the worst.

0 views
Unsung Today

“If you can’t stand by a feature, you shouldn’t launch it.”

On the most recent episode of The Talk Show podcast , this monologue from Jason Snell made me nod my head (the passage starts at 1:35:47): [… Apple] decides to do a big feature. The circus comes to town, they build the feature, they launch it, they leave town, and that feature sits there. And the problem is, there’s bugs, things are broken, and in Year Two, you’re like, “You’re going to fix all the things that were broken in the thing you shipped last year, right?” And in the last decade, I would say, a lot of times what happens is they just don’t. And if you’re lucky, they’ll fix it Year Three or Year Four, […] give it a polish. The thing that troubles me most about Apple software quality in general is the feeling like they don’t have the people to own the thing that they launch. They build the thing that they launch, and then those people go off and do something else, and nobody is maintaining and improving the thing that’s there. And whether it’s Time Machine, things that are often really system critical but that are super quirky, then they will do a brush up and you’ll be like “yay,” but… there’s still this bug, and then it’s “good luck, wait three more years.” Or I think the one that we’re all thinking of this year is Screen Time, which they have a big revamp of. […] On one level, it’s great, but on another level, if you’ve talked to anybody who’s tried to use Screen Time, it’s broken. And so what they’re really doing here is trying to fix it, and we’ll see how they do. […] The new features with problems is not a crime. It happens. The crime is: they never fix the problems. And that’s the part that I would like to see Apple get better at: if you’re going to launch something, you got to maintain it. Sometimes I feel like Apple is willing to spend the money and time and effort to launch something, but then they’re not really willing to do anything other than walk away. And I think that’s irresponsible. If you can’t stand by that feature, you shouldn’t launch it. I think this is spot on, and said really well. Are you honest with yourself about resourcing and focus for right after the launch and then later on ? Have you really thought about worst case and best case scenarios vis-à-vis bug reports, latency, user feedback, and craft/​quality however you define it? Have you actually started to make room for those outcomes ahead of time? For me, an ongoing tension with Apple is Finder, so central to my (and I imagine many people’s?) use of a Mac, but rewritten at some point eons ago in a new framework that caused all sorts of problems, and then pretty much abandoned like a proverbial American city’s downtown. (I gave up listing stuff on this blog because it didn’t feel like fun, but I also see 100% of what Ilya Birman sees in his “Finder” section, many times every day.) It’s not a story unique to Apple – I’ve seen many a designer and engineer quitting their jobs when an empty promise of a “fast follow” never materialized – but you’d expect them to do better here. #apple #maintenance #podcast #process

0 views

a CVE dispute

A few years years ago the curl project signed up and became a CNA . This means that we are masters of and can allocate our own CVE identifiers. For any security problems within our territory, it is we who decides if the issue should get a CVE or not. No more bogus CVEs . During these years we have published fifty-seven separate security vulnerabilities with their associated CVE identifiers. Getting a CVE for an issue is easy and really quickly done when you are a CNA. No hassle, no friction and as we are a small and lean security team it just works as smoothly as you could ask. Just an API call and we have new number. Being a CNA is low maintenance, as there really is nothing extra we need to do. We already had an established and proven process for receiving, managing and assessing vulnerability reports before we became a CNA since we are a responsible and well-run Open Source project. Becoming a CNA just made the process easier as we now don’t need to involve any outsider at all. For every report we work hard to first assess and decide if the issue is actually a vulnerability or a security problem at all. If we deem that there is a security problem in there, we then grade it into LOW, MEDIUM, HIGH or CRITICAL. Since we don’t know how users use curl or libcurl we cannot take that into account but rather observe and set a severity of the problem from a pure curl point of view. It’s a rough indication how we see the problem but of course every user that actually are affected by the problem might rate it differently. For a rare few issues we can imagine that there could be a minuscule risk but because of the set of extreme requirements and convoluted steps to get there, we deem the risk so small that in practice no user is likely to ever reach it. Internally we tend to call that an issue with a severity level lower than LOW. Issues we believe we serve humanity better by not issuing a CVE for. To avoid the security dance when it seems unnecessary. libcurl is installed in somewhere around thirty billion instances on the globe. If we imagine that at least a sizeable portion of those installs are managed by people who want to make sure they use a secure version, it means that every CVE we publish trigger activities in many security teams all over the world, leading to a significant number of patches and subsequent software updates. Every CVE thus has this huge cost tied to it. A cost that does not land on us and we don’t really see or feel it, but a cost on the ecosystem I believe we should not ignore. We should act responsibly. Never ignore real problems of course, but also to make sure we don’t ring the alarm for theoretical problems that will not trigger any vulnerability. Our first ever CVE dispute since we became a CNA reached us on February 10th, 2026 for a report submitted to us two months earlier. The reporter thinks we should have assigned their reported problem a CVE but we think not. Now they want to force the issue to get a CVE anyway, by escalating the situation to MITRE. Yes, it makes you wonder why it is that important to have this as a CVE, but I will avoid speculations for now. I replied to MITRE explaining that we considered and debated the issue and we remain happy with our previous decision. I linked them the original report and discussion to show them. The issue is quite technical (of course) but is based on a bug in curl’s function that checks if the used hostname matches a wildcard provided in a certificate. First: the user must use a hostname in a URL with a leading dot, like This name is not possible to use with DNS (it is an illegal name there), but you can provide an IP address for it in your file or similar, but still this condition is already making this issue really niche. Why would a user ever do this? Well, there could be a redirect to such a host name from a malicious server if the application allows redirects but getting the address for the host is still a challenge and mostly requires a local attacker present add that. Then: if curl can find an address for the illegal DNS hostname, the site curl connects to, also needs to have a wildcard certificate for the name where the tail of the wildcard needs to match the name in the URL. If curl was built to use an OpenSSL flavor or Schannel for TLS (remember that curl supports many different TLS backends), it then calls the function to check if the wildcard covers the used hostname. This function had a bug . The above mention combination then erroneously would return TRUE. A match. When in reality it is not a match according to the spec. We fixed this problem on December 8, 2025 , and we added unit tests for exactly this scenario to make sure that the problem doesn’t come back. For all security issues at several below HIGH, we fix them asap so that was just our normal procedure. We then continued to discuss if this was worthy of a CVE or not. It should be extremely rare that anyone uses a dot prefixed name, unless you are in an internal and controlled environment where you use something else than DNS for resolving. It is not possible to trick an application to use a dot prefixed arbitrary name as it will fail to resolve. The explicitly set, weirdly dot prefixed name, then needs to connect to a host that has a wildcard set for that same name and an attacker manage to run this impostor host and can now serve the application malicious data because curl did not properly reject the connection because of the wildcard mismatch. A series of highly unlikely conditions that all need to be fulfilled for this to become a vulnerability. A lower than LOW situation. Too unlikely; no CVE. On May 28, we were again contacted by MITRE in the same case, asking again for our rationale for not giving this issue a CVE. We responded with virtually the same wording as before and linking again to the same original Hackerone issue and discussion thread. It’s all public information really. On June 15, we were again contacted by MITRE asking for the reasoning behind our decision to not give a CVE for this issue. We replied with similar wording again. Linking to the same issue, again. This seems like a great system. On June 24 we finally got the verdict. It is not considered a security vulnerability.

0 views

Thoughts on Role Confusion

The other day, I came across " Prompt Injection as Role Confusion " ( via Simon Willison ). It's a really interesting blog-style version of a paper by Charles Ye, Jasmine Cui and Dylan Hadfield-Menell, where they find that LLMs seem to almost ignore 'role' tags like , or , and instead use the tone of text to infer roles. This seems to explain a lot of jailbreaks. When LLMs are reasoning about their context to work out what tokens they need to generate next, they need to separate out different things: what the system prompt says, what the user says, what the LLM itself has said in the past -- and for recent LLMs, what their own past thoughts have been -- their reasoning traces -- and what they've sent to and received from their tools. These "roles" for each bit of text need to be specified in the context. For example, in a simple chatbot (say, 2022-vintage), it might be written up a bit like a transcript : The LLM then starts predicting what would come next (eg. "The capital of France is Paris"). Alternatively, we might use XML-like separators: But most modern systems use special tokens -- which have the benefit that the things outside the LLM harness (like the user through the chat interface, or hostile tool output) can't fake them. In the post, they call the special inputs that tell the system how to interpret the role of a bit of text the role tags . But, after digging in with various tools, they find that LLMs seem to pay much more attention to the tone of text than they do to the actual role tags! So even if the special tagging tokens are unfakeable, that doesn't save your model from being jailbroken -- for example, by a user managing to trick the model so that even though something is tagged , it treats it as if it were tagged . They give a particularly fun example, which worked well on OpenAI's reasoning models in late 2025. They would simply provide text -- which would all go into a "user"-tagged role section -- that sounded like the kind of thing the models themselves would come up with in their reasoning trace: The model saw that, ignored that it was tagged "user", and treated it as its own thoughts. Because the model trusts its own thoughts, it happily complied. For example, they give this reply from GPT-5 Mini: A lot of jailbreaks I've seen ( Pliny the Liberator 's come to mind) seem to consist of putting in text that looks a bit like chain-of-thought reasoning or a system prompt. Perhaps this is (part of) how they work? It all sheds an interesting light on the prompt injection trick that I wrote about back in November , though. You can start a chat with an LLM with this message: ...and then when it accepts the challenge and says "go ahead", you reply with all of this in one message: In one quick test, even now in mid-2026, this still bamboozles ChatGPT 5.5, with thinking set to "High" -- it replied: My theory back in November was that it was related to the models' intelligence and their having been trained on instruction following. But this paper gives a more plausible and concrete way of thinking about it: if, internally in the LLM, it's using the phrasing as a way of guessing who is saying what, that might explain what is going on. However, I tried a variant of the second prompt where I tried to make the "bot" responses significantly less ChatGPT-like: ...and I still got So it still seems to have fallen for it. (It does seem a bit terser, but that might be random.) Perhaps the "User:" and "Bot:" tags -- even though they're not the real ones -- are pushing it hard enough that it overrides the tone. Or maybe we should treat them as "tone" in this case anyway, given that they are almost certainly not what ChatGPT is using to tag things. Or perhaps ChatGPT 5.5 with high thinking is just humouring me... Something I've been wondering for a while is whether this kind of thing could be fixed by somehow directly tagging the embeddings that are fed into the LLM. Role tags go around the tokens that they are tagging; these would be an inherent part of the tokens themselves, which might make it harder for the model to get confused. After all, the tag tokens are quite far from some of the text that they're tagging, and that signal needs to be pulled to the right by the different transformer layers, which are also trying to pull all kinds of other information rightwards. With the GPT-2 models I've been working on to date, the position of each token in the context is tagged by adding on a learned position embedding to the token-specific one -- that is, for "the fat cat sat on the mat", the first three embeddings would be: You can imagine that you could have an extra embedding that meant "role", and add it on in a similar way. I believe that BERT does this with what it calls segment embeddings . Alternatively -- and also inspired by position information, with the more current RoPE system -- you could rotate the embedding vectors about some axis to reflect their role. Or you could even add on one new dimension to the embeddings for each role, with a one for the real role, and zeros for the others. I guess a problem with all of these -- even if they worked in theory -- would be that in pre-training, you wouldn't have the roles correctly set. You could only add them on for the post-training phase -- and you could never be certain that something from the pre-training might "leak through" and make them ineffective. But certainly something to add to my ever-growing list of things to investigate. In particular, ASIDE looks like an interesting paper to look at -- it does something with rotation, though they're only trying to separate instructions from data rather than specifically to tag roles, and they're training from scratch with the separation in there. Given that jailbreaks are an unsolved problem, it's clearly somewhere where there's plenty left to be discovered. The token embedding for "the" plus the position embedding for position 1. The token embedding for "fat" plus the position embedding for position 2. The token embedding for "cat" plus the position embedding for position 3.

0 views

Blogging Can Just Be Stating The Obvious

John Gruber writes about those annoying popups every website seems to have now and while he does a great job tearing into these ubiquitous, user-hostile patterns, one of the things that stood out to me about his piece was this meta commentary on blogging. Here’s John: If you visit a website you should ... see the website . See its content. Be able to read the article whose page you are attempting to visit. Showing a “subscribe to our newsletter” or “accept our fucking cookies” dickover to someone trying to read an article on the web makes no more sense than sending out an email newsletter that only contains a link to read the newsletter on a webpage. A webpage should show the webpage. An email should show the email. I should not have to explain this. It’s funny how often blogging feels like being the little child in the story of The Emperor’s New Clothes . You’re just stating what seems obvious to you. I often look at my own posts and think, “There’s nothing novel, or important, or deep in here at all — is this even worth saying?” A post’s point can seem so glaringly obvious to me (and thus, I presume, others) it feels like a waste of time to even say it. As John says: A webpage should show the webpage. An email should show the email. I should not have to explain this. But then real-world examples of annoyance pile up around you and nobody talks about it, so you finally just have to say it in a post and bring receipts . You feel like someone gone mad: “Is anyone else seeing the same thing I’m seeing? And we’re just ok with this?” Very often, those are the best posts I read from others. So it must be that a key ingredient to blogging is simple: have a willingness to state something that seems obvious to you but nobody else is saying it. Or if someone else is saying it, just link to them and say, “Yes!!! This!!!” Reply via: Email · Mastodon · Bluesky

0 views
Unsung Yesterday

“It’s like a Freudian slip simulator.”

For a while, the digital artist James Dalzell Hodge kept a video diary of various design decisions while making his next game. This 13-minute video is interesting because it harks back to my mention of diegetic interfaces just a few days ago: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/its-like-a-freudian-slip-simulator/yt1-play.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/its-like-a-freudian-slip-simulator/yt1-play.1600w.avif" type="image/avif"> It’s a nice quick dive into the subject – a rare coverage of what “diegetic” means outside of the realm of movies. I like these videos because Hodge focuses on details and shows working through things, including approaches rejected along the way. Inside, there are even occasional peeks at interfaces from Unreal Engine tools and Blender, not to mention examples from other games. #art #games #interface design #typography #youtube

0 views
Ankur Sethi Yesterday

Deno Desktop

From the Desktop apps section of the Deno documentation : turns a Deno project (anything from a single TypeScript file to a Next.js app) into a self-contained desktop application. The output is a redistributable binary that bundles your code, the Deno runtime, and a web rendering engine into one bundle per platform. I'm happy to see another attempt at solving the biggest issues with Electron apps (other notable attempts being Tauri , Electrobun , and Neutralinojs ). According to the docs, Deno Desktop is only available in Deno's channel at the moment. So I obviously installed it (version ) and tried running a Hello World example app . On first run, Deno spent a few minutes downloading , then packaged the example into an app bundle weighing 308.8MB. I was curious about that download. A quick Kagi search led me to the homepage for a Rust/C library called laufey , which appears to be the tech underpinning Deno Desktop. Running the app bundle popped open a window that looked like this: This is clearly a work in progress. If somebody who works on Deno is reading this, here's a list of bugs I noticed: Deno uses Chromium as the default webview (via Chromium Embedded Framework ). But you can also use the system webview instead: When I ran that command, it downloaded and produced a much slimmer app bundle at 68.5MB. This is what the window looked like: This version of the app exhibited none of the bugs I noticed in the CEF version, except it doesn't have a title. Deno Desktop also has a backend that skips bundling the webview altogether. I didn't try it, but here's what the docs say: No web engine.  Provides window management, input events, clipboard, and the native API surface, but no webview, no   auto-binding, and no   proxy. Useful for apps that draw their own UI (WebGPU, Skia, custom rendering) or as a foundation for non-web desktop programs. The   backend is selected through the   field in  ; the   flag accepts only   and  . A major difference between Deno Desktop and its competition is how it communicates between the code running in the webview and the code running in the Deno runtime: Bindings are not IPC. The Deno runtime and the rendering backend run as threads / processes inside the same address space (CEF) or coordinated process group (WebView). Calls go through in-process channels, and the backend dispatches them from its run loop. This avoids the cross-process round-trip that socket-based IPC frameworks (Electron's ipcMain / ipcRenderer, Tauri's invoke) impose. Arguments and results are still encoded as they cross the realm boundary, but the transport is in-process: no socket, no cross-process scheduling. In practical terms: bindings are fast enough that you do not need to worry about call frequency for typical app workloads. The docs are light on how they pull this off. I'd love to read more about this. There's a built-in auto-update mechanism, including rollbacks if updates fail: Deno.autoUpdate() polls a release server for new versions, downloads binary-diff patches, applies them to the runtime dylib, and stages the result for the next launch. If the next launch fails, the runtime rolls back to the previous version automatically. Updates ship as small bsdiff patches instead of full binary downloads, with rollback baked into the launcher. The comparison page has this bullet-point under the section titled "What doesn't have yet": Shared CEF runtime across apps.  Every app currently bundles its own CEF copy. A managed shared runtime would drop binary sizes to a few MB per app. On the roadmap. Does this mean all Deno apps on my computer could potentially share a single CEF runtime? If yes, that would mean massive disk space savings. But it's unclear if the developers intend to ship this feature in a future release or if it's just a wishlist item that may or may not see the light of day. Deno Desktop is, of course, heavily under development. Some important features are still missing (platform native file dialogs), and it's not clear if others are on the roadmap or not (mobile support). I'm sure many of the missing features will make their way into the final release, and we'll get a clearer idea of future plans in a release announcement. I have a personal interest in anything that aims to replace Electron, so I'll be keeping an eye out for Deno 2.9. The app window had a dark background by default, even though the demo app didn't contain any styles. Browsers don't default to a dark background unless you explicitly opt in using . Even so, opting into dark mode inverts all the default colors, not just the page background. Something is off here. Running the bundle triggered a macOS permissions dialog for and , both of them asking for notification permissions. The demo app didn't use the notifications API (it didn't even contain any JavaScript), so seeing two permission dialogs felt aggressive. Hitting didn't quit the app. The app always opened on the top left of the screen.

0 views
Unsung Yesterday

Good renewal comms from Panic

= 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/good-renewal-comms-from-panic/1.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/good-renewal-comms-from-panic/1.1600w.avif" type="image/avif"> A week of heads up before the payment happens The specific amount I’ll be charged shown Clarity about what is renewing and what I’m getting out of it Even a reminder about what Nova is, in case I stopped using it Seems obvious, but so many places fail at some, and sometimes all of these. A week of heads up before the payment happens The specific amount I’ll be charged shown Clarity about what is renewing and what I’m getting out of it Even a reminder about what Nova is, in case I stopped using it

0 views

Kafka Share Groups - Pathological fetch waits with record_limit

In this post we’re going to see how combined with: fewer consumers than partitions and various cases of “partition skew” …can result in subpar performance with share groups.  I stumbled on these issues when running large sets of dimensional tests with Dimster’s explore-limits mode, which finds the highest sustainable throughput while staying within a target end-to-end latency target. There was a specific subset of the tests that explore-limits mode would consistently fail to complete, and they all happened to be with record_limit and a consumer count lower than the partition count. In this test, we’ll understand why Dimster had such a hard time with this combination. Kafka share groups have two methods of acquiring records: I already explained the difference in Kafka Share Groups and Parallelizing Consumption - Part 2: Producer Batches and share.acquire.mode but let’s just cover it again. Share consumers are assigned partitions as part of the share group protocol. It works similarly to the consumer group protocol, except that multiple consumers can be assigned to the same partition. With , share consumers acquire records in whole batches, using max.poll.records as a soft cap. Furthermore, a share consumer assigned multiple partitions across multiple brokers will send fetch requests to each of those brokers, concurrently. With , share consumers acquire records as slices of batches, where the size of the slice is determined by (now a strict cap). If you set but the relevant batch contains 32, then only a slice of 10 records is acquired (though the whole batch is transmitted over the wire). Furthermore, a share consumer assigned multiple partitions across multiple brokers will send fetch requests round-robin (one-at-a-time) across those brokers. Each time you call poll, it will fetch from the next broker. Dimster consistently did not complete explore-limits tests with and fewer consumers than partitions. The issue is that during various phases of an explore-limits test, lag can build very quickly if producers shoot past the capacity of the consumers. Dimster sees this and attempts to drain the lag before it resumes with a lower producer rate. Fig 1. Dimster’s explore-limits mode regularly drains a backlog while searching for the highest sustainable rate under a target e2e latency The drain works by pausing the producers, temporarily removing any consumer processing time (if configured) and then resuming with a lower producer rate. However, with and fewer consumers than partitions, this lag drain would basically stall as the consumption rate would end up just a trickle (such that it would take hours to drain the backlog that had accumulated). So I ran some backlog drain tests to understand what was going on and discovered what I’ll refer to as pathological fetch waits . Imagine one share consumer and a topic of 10 partitions spread across 3 brokers. Imagine if all the producers sent records to only one partition, leaving the other 9 consistently empty. What sub-optimal share consumer behavior might we see? Let’s go through it. Remember, with , fetches to brokers are round-robin if a consumer is assigned multiple partitions (on different brokers): Consumer sends a fetch to (which hosts partitions 0, 3, 6, 9) and gets back some records for partition 0. Poll is called again, triggering a fetch to (which hosts partitions 1, 4, 7), but there are no records. Poll is called again, triggering a fetch to (which hosts partitions 3, 5, 8) but there are no records. Poll is called again, triggering a fetch to , returning more records of partition 0. So what’s the problem? Can you see it yet? The problem is . It defaults to 500. Yes that’s right, steps 2 and 3 took 1 second to complete and returned no records! 1 second where nothing is getting consumed, while partition 0 continues to receive records. Fig 2. A single consumer, doing round-robin fetches across 3 brokers, does a lot of waiting when encountering brokers with 0 lag across their partitions (leader replicas). Let’s run some benchmarks to understand how serious this issue can be. Setup: 1 topic, 10 partitions, 5 consumers, max.poll.records=500 (the default), backlog size 400M records. This test generates a 400M record backlog using the , which generates a relatively balanced load across partitions. Each record is 50KB, resulting in a 20 GB backlog. The coordinator logs the drain progress: By the time the test reached the short test timeout, consumption was about 3,900 records/s, from a high of 1.2M records/s (no simulated processing time was configured). 98% of the 400M backlog drained in around 8 minutes. The consumption slowdown started when lag was around 9M records. Extrapolating based on 3900 records/s, it should have taken 6 hours more to drain that 2% of the starting backlog.  What has happened is that due to some skew, half the partitions had drained causing the slow down. With 5 consumers and 10 partitions, each consumer was assigned two partitions, most likely on different brokers. So half of each consumer’s fetches were waiting for 500 ms and return nothing. The aggregate skew was relatively minor (the lightest partition had 39M and the heaviest had 45M), but the lag skew got worse as lighter partitions were drained.  A 400M backlog is an extreme case. But we can trigger the slow down in much smaller backlogs if we use a more skewed message distributor mode. Let’s move onto case 2, where we’ll diagnose the pathological fetch wait problem further. Setup: 1 topic, 12 partitions, 1 & 6 consumers, max.poll.records=500 (the default), backlog size 20M records. To make this nasty, we’ll use a partition skew using Zipfian distribution with alpha=2. This is an extreme skew where the most heavily loaded partition (p0) will receive 64% of the records (12.8M), p1 will receive 16% (3.1M) and so on until p11 receives < 1% (88K). We’ll run two tests tests: with 1 consumer (assigned all 12 partitions) with 6 consumers (each assigned 2 partitions) Coordinator output excerpt: Consumption starts strong but quickly drops to just shy of 2K records/s where it remained until the test reached the 20 minute drain timeout. Extrapolating, we can estimate a 2 hour drain time. Why just below 2000 records/s? A Prometheus query shows us the lower loaded partitions drained quickly and that the slow down in aggregate consumption correlated to an interval where p2 and p3 finished draining and p0 and p1 consumption dropped massively at the same time. Fig 3. Showing when each partition got drained, and the impact on consumption of the heavy partitions p0 and p1. Inspecting the partitions, we see that the leader of p0 is hosted by broker-1 and p1 by broker-2. So we’ve hit the following scenario (where only p0 and p1 have remaining lag): Fig 4. The topology in this one-consumer test. In a one second period (with zero ms processing time): Fetch 500 from Fetch 500 from Fetch 0 from with 500 ms fetch latency Fetch 500 from Fetch 500 from Fetch 0 from with 500 ms fetch latency In one second, the consumer can do two rounds of fetching from p0 and p1 (500 at a time), though in reality there is some overhead, which matches the 1990 records/s. This test did no better. In fact, the slow down happened far earlier. Fig 5. The drain-rate of the one-consumer and six-consumer tests. The six-consumer test hit the slowdown far earlier. We can see, while the test runs, that partitions p0-p4 still have lag (proportional to the skew). Inspecting the partition placements and share group assignments, we that these 5 partitions with lag are spread across 5 consumers. Each of these 5 consumers is assigned one heavy partition (still with lag) and one lighter partition (no drained). Fig 6. The toplogy and fetch waits in the six-consumer test. With zero processing time in this test, in a one second period, each of the 5 degraded consumers would: Fetch 500 records from the heavy partition Block on the light partition for 500ms Fetch 500 records from the heavy partition Block on the light partition for 500ms. The slow down happened earlier as each consumer fetched only from one partition per broker, whereas the single consumer fetched from 4 partitions per broker, so took longer to completely drain entire brokers. You might be thinking, how often do we need to drain a backlog, all the while the producer rate is 0? Let’s move onto case 3. Setup: 1 topic, 6 partitions, 1 consumer, max.poll.records=500 (the default), 6 brokers. One such case of draining backlogs without producer load is that of workloads where producers periodically dump a large batch of records in a topic. In between each dump there are no incoming records at all. We can model this with Dimster using its workfield. Fig 7. Per-partition rates + aggregate lag. Note that due to the rate calculated over a 1 minute interval, the short peak of 10,000 records/s is not shown. The consumer can’t handle the batch instantly, it needs time to process it. The consumption rate of the heaviest partition tops out at 1.5K records/s, building lag on that partition. In each of the three producer dumps, once the producer rate dropped to 0 and the 5 lightest partitions got drained, the heavy partition consumption rate crashed due to the fetch wait issue. Each consecutive production-batch increased the lag on the heaviest partition. In this test I used 6 brokers, to ensure that each partition was on a separate broker, to exacerbate the problem. Obvious, this test doesn’t need 6 brokers, but in production you might run 6 brokers or 12 brokers or more. In such clusters, it would be the norm for the leader replicas of a topic to be not be co-located on the same brokers. So far we’ve focus on backlog draining without producer load. But if producers keep going during the drain then the fetch wait issue can be mitigated. The size of the mitigation depends on the magnitude of producer rate. If a record arrives at a light partition twice per second, then the fetch wait issue may not be mitigated at all.  The following chart shows a small backlog from one cycle of a batch-production workload. After the peak of 12,000/s, the producer rate drops to 0 for three minutes, then every two minutes increases until it finally reaches 900 records per second across all partitions (with 64% going to p0). Fig 8. Demonstrating how the producer rate can affect the consumer rate. We can see that as the producer rate increases, the drain rate of the single partition backlog accelerates. The producer rate accelerates the consumer rate. This tells us that a continued producer rate may or may not mitigate the fetch wait issue. The lower rate, the less effective the mitigation. If we reduce to 1, plus we have fewer consumers than partitions, plus we have serious skew, we encounter a double-whammy. Round-robin fetching that returns only a single record cannot prioritize the heavier partitions, in fact, the heavier partitions are penalized as the lighter partitions cause the consumer to spend most time fetching from them. In the worst case, the consumer spends 500 ms waiting for a fetch to a lighter partition, but comes up empty, while the heavier partition is filling up. One such case, designed to maximize this pathology is: 6 records per second 12 partitions max.poll.records=1 average processing time is 10 ms 4 different load skews (via workload field): : Almost perfect uniform distribution : Light skew. . High skew : With one producer -> high temporal skew, low aggregate skew. Why high temporal skew for ? Basically, the single producer chooses a partition and sends records to it for a while, then switches to another partition for a while and so on. Within a short period of time, only one partition is receiving records. You can see the partition skew of these four tests below: Fig 9. The partition skews of each test (PINNED_PARTITIONS, KEY_ROUND_ROBIN, PARTITION_ZIPF, NO_KEY). The results show that the Zipfian 1.5 test reached only 2 records/s with one consumer and 5 records/s with six consumers. The test also saw elevated end-to-end latency, though it did not continue to grow. Fig 10. Consumer rate and p99 e2e latency over time, of the four tests. Primary mitigation : If you want to use , then the best mitigation is to use the partition count as the floor for consumer count . This completely side-steps the fetch wait problem and allows you to use without any risk of these weird performance issues under various types of skew. Secondary mitigations (less effective or with drawbacks): Consider reducing , if you have regular backlogs with no producer load (cases 1-3). The downside is if you get too aggressive, gone is long polling, instead you might hammer the Kafka brokers with a high frequency of fetch requests. Consider increasing if you experience case 5, as it allows the consumer to make up for the long periods between fetches to the heaviest partitions. Consider fixing your skew. However, even if your partitions are relatively balanced, if you accrue a very large backlog, then the lag can be skewed towards the end of the drain period.  The following chart shows drain times for a high skew backlog with different with 6 consumers and no producer load: How might we mitigate these pathological-fetch-waits with a change in how the Apache Kafka clients work? Have clients not wait the full timeout period if the last fetch to that broker returned empty. This would help in backlog drain scenarios without producer load, but not low producer load (where fetches are non-empty but high latency). No round-robin fetch requests. Have the client send concurrent fetches to all brokers of the assigned partitions. However, this weakens one of the main objectives on , which is to place a hard cap on the number of records inflight for a given consumer, in order to avoid reaching record timeouts and redelivery. Have an additional communication channel between brokers and clients, so brokers can share lag information with clients (so clients can preferentially fetch from higher lag partitions). I am sure this particular wrinkle with share groups will get worked out. In the mean time, the most sensible mitigation is to use the partition count as your floor for consumer count when using . fewer consumers than partitions and various cases of “partition skew” Consumer sends a fetch to (which hosts partitions 0, 3, 6, 9) and gets back some records for partition 0. Poll is called again, triggering a fetch to (which hosts partitions 1, 4, 7), but there are no records. Poll is called again, triggering a fetch to (which hosts partitions 3, 5, 8) but there are no records. Poll is called again, triggering a fetch to , returning more records of partition 0. with 1 consumer (assigned all 12 partitions) with 6 consumers (each assigned 2 partitions) Fetch 500 from Fetch 500 from Fetch 0 from with 500 ms fetch latency Fetch 500 from Fetch 500 from Fetch 0 from with 500 ms fetch latency Fetch 500 records from the heavy partition Block on the light partition for 500ms Fetch 500 records from the heavy partition Block on the light partition for 500ms. 6 records per second 12 partitions max.poll.records=1 average processing time is 10 ms 4 different load skews (via workload field): : Almost perfect uniform distribution : Light skew. . High skew : With one producer -> high temporal skew, low aggregate skew. Consider reducing , if you have regular backlogs with no producer load (cases 1-3). The downside is if you get too aggressive, gone is long polling, instead you might hammer the Kafka brokers with a high frequency of fetch requests. Consider increasing if you experience case 5, as it allows the consumer to make up for the long periods between fetches to the heaviest partitions. Consider fixing your skew. However, even if your partitions are relatively balanced, if you accrue a very large backlog, then the lag can be skewed towards the end of the drain period.  Have clients not wait the full timeout period if the last fetch to that broker returned empty. This would help in backlog drain scenarios without producer load, but not low producer load (where fetches are non-empty but high latency). No round-robin fetch requests. Have the client send concurrent fetches to all brokers of the assigned partitions. However, this weakens one of the main objectives on , which is to place a hard cap on the number of records inflight for a given consumer, in order to avoid reaching record timeouts and redelivery. Have an additional communication channel between brokers and clients, so brokers can share lag information with clients (so clients can preferentially fetch from higher lag partitions).

0 views
Stratechery Yesterday

My Vibe Coding Adventure, The App and the Experience, Ten Takeaways

My experience and reflections on vibe coding an app that I plan on actually using regularly.

0 views
(think) Yesterday

Neocaml 0.9: A Better REPL, Dune/Opam Completion, and More Robustness

It’s been a couple of months since the last neocaml release, and the reason is simple — for a while there I was genuinely out of ideas. Back when I shipped 0.6 I declared (again!) that I was done with new features, and this time I almost meant it. But ideas have a way of creeping back in, and 0.9 turned out to be a meaty release. Here are the highlights. The biggest chunk of work went into the REPL (toplevel) integration. I’m well aware that the OCaml toplevel isn’t terribly popular with seasoned OCaml developers — most of them reach for a proper build and a debugger instead. But I think newcomers get a lot of mileage out of a REPL, and (no surprise to anyone who’s followed my work) I’m a Lisper at heart with a real soft spot for interactive development. Clojure and Emacs Lisp spoiled me, and I want OCaml beginners to taste a bit of that too. So, what’s new: Choose your toplevel. The new lets you pick between , , and . Set it globally, or per project via : The active flavor shows up in the REPL’s mode line, so you always know what you’re talking to. This one I’m particularly happy with. / files have to lean on for completion, but the auxiliary file formats have no language server at all. That’s exactly the kind of gap neocaml is meant to fill, so both and now ship a backend. In a file you get completion for stanza names, the field names valid for the enclosing stanza, and library names inside / fields: The library candidates combine your project’s own libraries with whatever’s installed in the active Opam switch. And it’s switch-aware — if there’s a project-local switch (an directory), neocaml detects it and queries it via , without any configuration on your part. The results are cached per project, so it stays snappy. In files you get completion for field and section names, and package names inside / / (sourced from ): Both backends can be toggled off via and if you’d rather not have them. A good chunk of this release is the unglamorous but important work of making things just behave correctly: There’s more in there too — integration ( ), clickable URLs and bug references in comments, a font-lock level selector, and richer menus across the modes. OCaml 5.5 was released on June 19th, so this felt like a good moment to ship 5.5 support in neocaml. The and grammars now track tree-sitter-ocaml v0.25.0, which brings the 5.5 grammar along with it. There’s a wrinkle here that’s worth explaining, because it’s shaped the last few releases. A tree-sitter grammar gets compiled into a parser that speaks a particular ABI version , and Emacs can only load parsers up to the latest ABI supported by the it was built against — it’s not the Emacs version itself that sets the ceiling. In practice a lot of Emacs 30 builds out there (notably Homebrew’s on macOS) are linked against tree-sitter 0.24, which tops out at ABI 14 ; you need an Emacs built against tree-sitter 0.25+ to load ABI 15 grammars. The trouble is that the tree-sitter 0.25 CLI now generates ABI 15 parsers by default, so any grammar regenerated with current tooling produces something those builds simply can’t load — you install it and it just errors out. Emacs 31 will ship with newer tree-sitter and make ABI 15 the common case, but it’s not out yet. (This isn’t a neocaml problem as such; it’s been biting tree-sitter modes across the ecosystem.) After a few users ran into exactly this, I’ve made a deliberate decision: stick to ABI 14 grammars until Emacs 31 is widely available. That effort started a couple of releases back — in 0.8.1 I lowered the ABI requirement from 15 to 14 across the opam, dune, and ocamllex modes, switched the menhir recipe to tmcgilchrist/tree-sitter-menhir , and pinned ocamllex back to v0.24.0, all of which target ABI 14 ( #42 ). 0.9 extends that policy to the core OCaml grammars. The catch with v0.25.0 is precisely that it generates an ABI 15 parser. Happily, the 5.5 grammar didn’t actually need any ABI 15 features — the bump rode along with the CLI upgrade — so an ABI 14 regeneration of the very same grammar is a drop-in. Big thanks to 314eter , the maintainer, for cutting a tag for exactly this purpose ( #141 ). The one snag was that tagging normally triggers releases to NPM, crates.io, and PyPI, so I sent a small PR to skip publishing for ABI-suffixed tags ( #142 ), and the tag followed. neocaml now pins both grammars to it. If you’re curious where neocaml is headed, I’ve started keeping a ROADMAP.md with ideas and guiding principles (short version: tree-sitter first, lean on the LSP stack for / , and own the auxiliary modes that have no language server). The project also has a proper documentation site now at neocaml.org , so there’s a real home for the details beyond the README. As always — update from MELPA , play with it, and let me know how it goes. The full list of changes is in the 0.9.0 release notes . Bug reports, feature requests, and pull requests are all welcome on GitHub . That’s all from me, folks! Keep hacking! A dedicated REPL per project. The REPL buffer is now named after its project (e.g. ), and the send commands route to the current buffer’s project REPL. You can have several projects running side by side without them stepping on each other. Choose your toplevel. The new lets you pick between , , and . Set it globally, or per project via : The active flavor shows up in the REPL’s mode line, so you always know what you’re talking to. Send a phrase and step. ( ) sends the phrase at point to the REPL and moves on to the next one — perfect for walking through a file top to bottom while you experiment. from Emacs. loads a package into the running toplevel without you having to type the directive by hand. Restart on demand. kills and restarts the toplevel when things get into a weird state. Character literals and quoted strings at the syntactic layer. Tree-sitter fontifies , , and correctly, but the syntax table underneath was getting confused — which broke , , and around those constructs. The fix was a good old . I wrote up the whole story over on Emacs Redux in Tree-sitter Modes Still Need a Syntax Table , if you’re into mode-writing internals. integration. A directory with a file is now recognized as a project root (even without version control), and are ignored, and defaults to in dune projects.

0 views

curl 8.21.0

the 275th release 6 changes 56 days (total: 10,817) 276 bugfixes (total: 14,187) 531 commits (total: 39,077) 0 new public libcurl function (total: 100) 0 new curl_easy_setopt() option (total: 308) 1 new curl command line option (total: 274) 102 contributors, 69 new (total: 3,731) 45 authors, 26 new (total: 1,489) 18 security fixes (total: 206) As mentioned before , the security report volume has been intense lately. We publish eighteen new curl vulnerabilities this time. A new project record for a single release and for the total number of vulnerabilities published within the same calendar year. As always, we have document each vulnerability in detail and I encourage you to read up on the details. The huge focus on vulnerability reports during this release cycle made us merge fewer new features than we wanted, but here are the ones we still managed to get to: We again manage to land more than 250 separate bugfixes, and they are all detailed in the changelog . Planned upcoming removals include: If you are concerned about any of these, speak up on the curl-library list ASAP. Unless we messed up this one and need to do a patch release, the pending next release is scheduled to happen on September 2. This release cycle is extended by two weeks due to the summer of bliss . CVE-2026-8925 : SASL double-free CVE-2026-8927 : env-set cross-proxy Digest auth state leak CVE-2026-9079 : stale proxy password leak CVE-2026-11856 : cross-origin Digest auth state leak CVE-2026-8286 : wrong STARTTLS connection reuse CVE-2026-8458 : wrong reuse for different services CVE-2026-8924 : trailing dot domain super cookie CVE-2026-8926 : password leak with netrc and user in URL CVE-2026-8932 : incomplete mTLS config matching in conn reuse CVE-2026-9080 : UAF after pause in socket callback CVE-2026-9545 : exposing HTTP/3 early data CVE-2026-9546 : sending old referer CVE-2026-9547 : SSH improper host validation CVE-2026-10536 : HTTP/2 stream-dependency tree UAF CVE-2026-11352 : QUIC zero-length UDP datagrams busy-loop CVE-2026-11564 : Native CA trust persist CVE-2026-11586 : WS Auto-PONG memory exhaustion CVE-2026-12064 : proto-default skips SSH verification curl: named globs curl: named globs in output file name for uploads HTTP/3 proxy CONNECT and MASQUE CONNECT-UDP support removed HTTP/2 stream dependency tracking removed support for CURLAUTH_DIGEST_IE added support for SHA256 host public keys with libssh local crypto implementations TLS-SRP support

0 views
Xe Iaso Yesterday

"No way to prevent this" say users of only language where this regularly happens

In the hours following the release of CVE-2026-55200 for the project libssh2 , site reliability workers and systems administrators scrambled to desperately rebuild and patch all their systems to fix an out-of-bounds write in ssh2_transport_read() due to a missing upper bound check on the packet_length field, resulting in heap corruption and potential remote code execution. This is due to the affected components being written in C, the only programming language where these vulnerabilities regularly happen. "This was a terrible tragedy, but sometimes these things just happen and there's nothing anyone can do to stop them," said programmer Mr. Alex Doyle, echoing statements expressed by hundreds of thousands of programmers who use the only language where 90% of the world's memory safety vulnerabilities have occurred in the last 50 years, and whose projects are 20 times more likely to have security vulnerabilities. "It's a shame, but what can we do? There really isn't anything we can do to prevent memory safety vulnerabilities from happening if the programmer doesn't want to write their code in a robust manner." At press time, users of the only programming language in the world where these vulnerabilities regularly happen once or twice per quarter for the last eight years were referring to themselves and their situation as "helpless."

0 views
Unsung Yesterday

The MacCharlie Method

I keep thinking about MacCharlie , this strange product from 1985 that turned the original Macintosh into a dual-purpose machine that could also run software by its chief competitor, early PCs: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/the-maccharlie-method/1.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/the-maccharlie-method/1.1600w.avif" type="image/avif"> I’m fascinated by it because it almost feels like cargo culting : “hey, PCs are big and ugly, so if we make a Mac big and ugly, it must turn into a PC.” = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/the-maccharlie-method/2.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/the-maccharlie-method/2.1600w.avif" type="image/avif"> Of course, there was more method to this madness, and two alien cocoons wrapped around the Mac and its keyboard actually have the correct technology, but still – what an absolutely soul-sucking experience: an ugly on/off switch, ugly disk drives, ugly, slightly misaligned elements, ugly, ill-fitting, slightly off-color plastics, even ugly colors for key legends. (Okay, I liked one thing – the embossed Dayna logo matching the Apple’s.) This was not a novel idea. Those kinds of matryoshkas happened to computers before, and are still happening to computers today : = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/the-maccharlie-method/3.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/the-maccharlie-method/3.1600w.avif" type="image/avif"> There even exists a concept of a “naked robotic core” – devices designed specifically to welcome more infrastructure around them. Here’s an example from the professional cine camera world… = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/the-maccharlie-method/4.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/the-maccharlie-method/4.1600w.avif" type="image/avif"> = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/the-maccharlie-method/5.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/the-maccharlie-method/5.1600w.avif" type="image/avif"> …but your smartphone with MagSafe is gesturing toward this idea, too. This is not limited to hardware, and it is in software where things get really interesting to me. Here’s a thing I saw the other day when installing some keyboard modification software: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/the-maccharlie-method/6.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/the-maccharlie-method/6.1600w.avif" type="image/avif"> The top is the native macOS interface. The bottom, including those arrow tendrils, comes from the interested app, trying to walk me through the process using some overlaid coach marks. Or, this is something I saw on my Windows laptop. Putting aside none of this was what I gave consent for – again, top is native, bottom comes from McAfee: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/the-maccharlie-method/7.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/the-maccharlie-method/7.1600w.avif" type="image/avif"> Those adornments, whether “white hat” (like the keyboard tool), or “gray hat” (like the McAfee), all feel equally desperate and hopeful. Desperate, because if this is the best idea, there are no good ideas. You can almost feel developers gritting their teeth, saying “I can’t believe we have to do this.” Hopeful, because – well, you’re skating where you hope the puck will remain. At least the hardware, once mounted, cannot morph into something else. But the software appendage you create doesn’t really know how the host organism will evolve. Even a singular word change in the original UI can throw everything out of balance. This is no software proprioception where you control both sides of the equation and can re-synch them when either needs to evolve. Okay, I imagine if you think ahead enough, and have an appropriately vivid imagination, and a robust QA process set up so you can react immediately when the host changes its UI from under you, you might get something passable . But I think it will be hard. Sure, McAfee’s pop-up didn’t even try so its approximation of the “Enable extension” button is basically laughable – but CustomShortcuts did, and even then, the rounded corners and the shadows don’t quite match. I think this is the foundational disadvantage of this kind of an approach. I imagine there are much worse and more nefarious “black hat” examples than the McAfee callout I showed above, but even without that, shoddy facsimiles of things are all around us – fake text messages from fake support centers, fake smartphone pop-ups telling you to update your OS – and we learn not to trust them. And this kind of UI inevitably starts as a shoddy facsimile. You can pull it, with effort, to be something better, but it will never forget its roots. Here’s another “white hat” example: = 3x)" srcset="https://unsung.aresluna.org/_media/the-maccharlie-method/8-framed.1600w.avif" type="image/avif"> This is from Raindrop. Again, you can sense some pretty understandable desperation as presumably iOS doesn’t allow you to add the highlighting and annotating commands to its top toolbar – hence additional, bottom toolbar. I consider Raindrop a generally well-made app, but you can immediately feel a certain maccharlieness of it all here – what was mismatched plastics in the 1985 is mismatched liquid glass effects in 2026. And, on top of all that, once in a while, disaster strikes: = 3x)" srcset="https://unsung.aresluna.org/_media/the-maccharlie-method/9-framed.1600w.avif" type="image/avif"> #hardware #interface design #third party fixes

0 views

Scattered Spider Hackers Plead Guilty on Day 1 of Trial

Two men pleaded guilty in the United Kingdom this week to criminal charges stemming from an August 2024 cyberattack that crippled Transport for London , the entity responsible for the public transport network in the Greater London area. The duo were key members of a prolific cybercrime group known as Scattered Spider , and their guilty pleas came on the first day of what was expected to be a six-week trial. Owen Flowers (left) 18, and Thalha Jubair, 20. Image: UK National Crime Agency (NCA). Thalha Jubair , 20, of East London and 18-year-old Owen Flowers of Walsall admitted conspiring to commit unauthorized acts against Transport for London computer systems and causing risk of serious damage to human welfare. According to a report from the BBC, Flowers alone admitted to being part of a conspiracy to hack into U.S. based healthcare providers SSM Health Care Corporation and Sutter Health in September 2024. Jubair is also wanted by U.S. law enforcement agencies. In September 2025, prosecutors in New Jersey unsealed an indictment alleging Jubair and other Scattered Spider members committed computer fraud, wire fraud, and money laundering in relation to 120 computer network intrusions involving 47 U.S. entities between May 2022 and September 2025, and that the group’s victims paid at least $115 million in ransom payments. In July 2025, KrebsOnSecurity reported that Flowers and Jubair were arrested in the United Kingdom in connection with Scattered Spider ransom attacks  against the retailers  Marks & Spencer  and  Harrods , and the British food retailer  Co-op Group . Multiple sources familiar with those investigations said Flowers was the Scattered Spider member who anonymously gave interviews to the media in the days after the group’s September 2023 ransomware attacks disrupted operations at Las Vegas casinos operated by MGM Resorts  and  Caesars Entertainment . According to prosecutors, Jubair co-ran a bustling Telegram channel called Star Chat , the home of a SIM-swapping group that used voice- and SMS-based phishing attacks to steal credentials from employees at the major wireless providers in the U.S. and U.K. The group would then use that access to sell a service that could redirect a target’s phone number to a device the attackers controlled and intercept the victim’s calls and text messages (including one-time codes for multi-factor authentication). A receipt from Star Fraud Chat’s SIM-swapping service targeting a T-Mobile customer after the group gained access to internal T-Mobile employee tools. “Rocket Ace” was one of Jubair’s hacker handles, according to U.S. prosecutors. New Jersey prosecutors also allege Jubair also was involved in a mass SMS phishing campaign during the summer of 2022 that stole single sign-on credentials from employees at hundreds of companies. That weeks-long SMS phishing campaign led to intrusions and data thefts at more than 130 organizations, including LastPass ,  DoorDash ,  Mailchimp ,  Plex  and  Signal . KrebsOnSecurity reported last year that one of Jubair’s alter egos at age 15 was “ Everlynn ,” a hacker who sold fraudulent “emergency data requests” that used compromised police and government email addresses to demand subscriber data (e.g. username, IP/email address) from major tech companies, claiming the requests concerned urgent matters of life and death and could not wait for a court order. In April 2026, 24-year-old British national and Scattered Spider member Tyler “Tylerb” Buchanan pleaded guilty to wire fraud conspiracy and aggravated identity theft for participating in the group’s SMS phishing spree in the summer of 2022. The government said Buchanan, Jubair and others used the credentials harvested in that phishing campaign to steal at least $8 million in cryptocurrency from victims throughout the United States. Buchanan is currently scheduled to be sentenced on October 2. In August 2025, 20-year-old Scattered Spider member from Florida named Noah Michael Urban was sentenced to 10 years in federal prison and ordered to pay $13 million in restitution, after pleading guilty to charges of wire fraud and conspiracy. The U.S. Department of Justice says three alleged Scattered Spider defendants indicted along with Buchanan still face charges, including Ahmed Hossam Eldin Elbadawy , 24, a.k.a. “AD,” of College Station, Texas; Evans Onyeaka Osiebo , 21, of Dallas, Texas; and Joel Martin Evans , 26, a.k.a. “joeleoli,” of Jacksonville, North Carolina. Flowers and Jubair are slated to be sentenced in a London court on July 15, 2026.

0 views

Cargo Culture

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 (updated to version 3.0 a few weeks ago). My Hater's Guides To the SaaSpocalypse , Private Credit and Private Equity are essential to understanding our current financial system, and my guide to how OpenAI Kills Oracle pairs nicely with my Hater's Guide To Oracle . My last two premium newsletters were a deep-dive into the bubbles-within-a-bubble that make up the AI bubble — from the unsustainable and reckless growth of semiconductor companies, to the cults of personality surrounding Sam Altman and Dario Amodei.  Subscribing to premium is both great value and makes it possible to write these large, deeply-researched free pieces every week.  A few weeks ago, I predicted that the AI industry would start pushing the concept of “loops” — effectively LLMs prompting LLMs and being left to their own, token-intensive devices — as a desperate attempt to get users to burn more tokens, I imagine to create more revenue.  Now Jensen Huang and Claude Code chief Boris Cherny have both, within 24 hours of each other, intimated that the age of prompting models is over, as you’d just be “handling loops,” which conveniently also means burning more tokens. It’s unclear what benefits a loop might have, but at a conference where the first question was mysteriously about “whether loops were for real,” Cherny was emphatic that they were, and attempted to explain why : Pretty convenient for a guy who’s allowed to burn upwards of $130,000 a month in tokens by Anthropic. Burn as many tokens as possible, so that the Great Prophecy might occur! If you don’t endlessly use as many tokens as possible, constantly defend the AI industry, and prove yourself worthy of the Great Beast of Capital, you will never ascend! Use loops now! Agents are out! You’re an ape if you use agents now that we have loops!  I realize I sound like I’m being a little dramatic, but the AI industry moves with an alarming speed and consensus to judge those who are deemed unworthy. Don’t you dare report news that might darken the hearts of the chosen ! Don’t you dare suggest that the Great Prophecy (Anthropic and OpenAI are able to meet their $1.1 trillion in spending commitments) is untrue! Don’t you dare doubt that large language models are the future! This is Silicon Valley, and Silicon Valley stands for rugged individualism, rationality, and meritocracy, unless, of course, everybody in Silicon Valley agrees that an idea is good, at which point all of that bullshit goes out the window. Any singular piece of information that even slightly rings positive is proof of the Grand Prophecy of Growth that AI promises, and Chosen are those that take said proof, and Cursed are those who would question it.  That being said, if you’re an AI booster, I need you to listen to me. It’s very important everybody does the same thing right now. If Saint Tibo resets the Codex limits and you’re not immediately running loops — if we’re all not running loops — then the Great Prophecy won’t be completed. If you hear anybody question the Great Prophecy, you must immediately attack them, ideally finding a single point that you believe to be wrong (having read at most 200 words of what they have written), and then declare your victory. This is now your job.  If you do not write supportive blogs and tweets about the AI industry, you hate the entire tech industry, because Silicon Valley (see: the supposedly individualistic and meritocratic culture built on challenging consensus) needs you to suppress all dissent of any kind and ostracize those who dare to speak ill of it. Do not fret about non-believers who ask about things like “economics.” If you’re worried, re-read AI 2027, a piece of speculative science fiction that the big, serious, rationality-driven tech industry requires you to take seriously. You’re a big boy! You make your own decisions! Unless those decisions run contrary to the consensus of Silicon Valley, which is currently set to “AI is the literal future of everything and can do anything we agree on eventually.”  This is Silicon Valley — a monoculture that sells itself as outliers, putting everything it has into supporting a generative AI industry that sends the vast majority of its value directly to the largest tech companies in the world. The staunch rationalists of the Bay that have built brands convincing people they’re immune to the influence of groupthink need you to think exactly the same way that they were told to.  Why would everybody agree to do something so stupid? Why would everybody act so crazily?  It’s simple: the tech industry has completely run out of ideas, and all that’s left is a cargo cult that hasn’t had a human experience since 2015. Last week, Snap CEO Evan Spiegel debuted Snapchat Specs , a $2195 pair of augmented reality glasses with a demo that makes it apparent that nobody in the C-suite has spoken to a normal person in years. The tech industry desperately craves its next iPhone, but years of growth-at-all-cost management consultancy poison has twisted the already-flimsy mission statements of Silicon Valley from creating societal value and innovation to creating shareholder value and a kind of banal, nihilistic accelerationism that mostly comes down to “how do we make the next thing that will make number go up.” This is, of course, a joke. I have no idea if you’re allowed to look Evan Spiegel in the eye if you work at Snap. I also have no idea if anybody actually considered what a regular human being might do with the product it’s been desperately trying to launch for nearly a decade. A single conversation with a regular person would likely have them tell you that they wish their shit worked better or that the internet wasn’t so full of scams and pop-ups and slop and misinformation. They wish there weren’t so many ads. They wish their apps weren’t confusing and full of dark patterns and ways to trick them into subscriptions or clicking ads or being annoyed. That’s because there’re only so many things you can do for the user until you start doing stuff to the user. Per my piece from the end of 2024 : Despite decades of progress in hardware making computers faster, cameras better, and storage larger, the actual experience of using the computer has gotten materially worse. We’ve hit a wall as far as where mobile and desktop user interfaces can take us, and every attempt at making voice-activated platforms like Alexa replace (or even compete with) them has proven fruitless, with Amazon’s various Echo devices and services losing billions of dollars a year .  This is what I call the Rot-Com Bubble . Big tech has hit the wall of what modern software can do, and in turn run out of hyper-growth ideas. Nobody has the next Google Search, iPhone, cloud computing, mobile app store ,or other idea that would allow Google, Microsoft, Apple, and Amazon to keep growing at a rate that justifies their valuations. While this is partly a natural process — there are only so many ways to do things! — it’s also a direct result of incentivizing and promoting products that create revenue growth or sustain monopolies, which in turn focuses your R&D and hiring efforts toward those who can come up with ways to make Numbers Go Up. Put another way, the tech industry has become the largest cargo cult of all time. Microsoft, Google, Amazon, and Meta sunk what will soon be over a trillion dollars into AI data centers because they don’t have any other ideas, and because the only thing that the MBA’d elites running the tech industry can do is hire people, fire people and spend money. Their (at least in the first three cases) investments in OpenAI and Anthropic were a successful attempt to build both their largest individual customers and a new revenue stream under, I imagine, the mistaken belief that said customers would eventually become independent enough to pay them without continually raising venture capital. I also imagine they believed that AI data centers would actually make a profit at some point, or that said data centers wouldn’t take two or three years to complete , or that AI, as an idea and a tool, would “take off” in a real sense, rather than an imaginary hype cycle in an economy built on speculation.  The problem is that previous eras of innovation and hypergrowth never came from shoving hundreds of billions of dollars into any one thing. The original iPhone took two and a half years to develop, but was the culmination of multiple different innovations in capacitive touchscreens, smaller batteries, and the condensed talent that helped create a touchscreen keyboard that actually worked , and ended up costing about $150 million (or $271 million in today’s money), or a little less than a third of what SoftBank paid OpenAI in 2025 . The reason we haven’t come up with the “next iPhone” is because we’ve maxed out what we can do with the current slate of ways to look at a computer interface, and the next logical step is one that’s effectively screenless, which is an unbelievably big leap, and one that will not be surmounted any time soon. So our only hope is software, and the limits of our current interfaces. Google Search was created by two college students at Stanford . Instagram was a mobile check-in app called Burbn that realized it couldn’t compete with (lol) Foursquare and pivoted to creating a photo-first social network . In fact, most of the historical success stories in the valley are, for the most part, websites that bring together people or services in a way that’s accessible and readily-available, and most of that innovation came from services like Amazon Web Services. Social media companies were the natural next revenue ascent because they were, at least in theory, relatively cheap to run, as the users themselves (and what the platforms could encourage them to do) were the ones that made the reason for you to log onto the site. Except everybody forgets how many dead social networks there are, like iTunes Ping , Google+ , Google Wave , Microsoft SoCl , Meerkat , App.net , Pownce , Orkut , Jaiku , and YikYak . Everybody forgets that just about every other attempt by Meta or Google or Microsoft or Amazon to expand outside of their core competencies (if you can call them that) has failed. Everybody is desperate to ignore the fact that Silicon Valley startups have, for the most part, not done anything particularly new or interesting for over a decade, and that the reason everybody took these people seriously is a result of conflating them with people that have either entirely left the tech industry or have little to no say in its future. There’re only so many ways to solve problems with software, and only so many other ways to solve the problems that doing so creates. Two decades of Silicon Valley “innovation” have come from throwing as much software engineering talent and venture capital at as many problems that could, at least in theory, be solved through a combination of cloud compute, storage and code.  And while there might be more problems that code can solve, they aren’t the kinds that create hundreds of billions of dollars of revenue or massive shareholder returns, nor are they things that big tech can copy and bolt onto their current services to keep them growing either. This is leading to the slow, agonizing collapse of both the software industry’s revenue and the venture capital business model. The “ SaaSpocalypse ” narrative claimed that companies writing their own software was a threat to the business models of SaaS companies (and a justification for their dwindling revenue growth), which was an attempt to paper over the fact that the software industry is in decline , with the growth efficiency (revenue growth versus sales and marketing spend) of software companies declining by half between 2021 and 2023 , with BDO reporting in a 2025 analysis that across 115 publicly-traded SaaS companies, the industry’s revenue had declined by 2% year-over-year, with mid-sized growing companies at a flat 0%. The fact the “SaaSpocalypse” narrative took off is all part of the greater cargo cult of the Valley, and the media’s willingness to buy effectively anything they’re selling. Nobody is actually building their own SAP or Salesforce or Office 365 — that’s a fucking stupid idea! — but because that sounds like a directionally-correct idea that affirms the greater bias of the growth of AI, it set in, which meant some stocks went up and some stocks went down . Did they go up or down based on something that actually happened? God no! The market listens to the media and analysts, who mostly just look at the numbers they’re given and the people they talk to, who more often than not are the CEOs and other executives of the companies that plant these narratives as a means of getting away from an uglier truth. You see, if AI is the reason that the SaaSpocalypse is happening, it fits into the larger imaginary Valley mythology of “disruption,” and gives everybody an excuse to keep believing that every tech company will grow in perpetuity. The cargo cult cannot change its rituals to adapt to a reality that suggests that its gods are dying. Accepting that AI isn’t saving everything means that you have to accept that there might be an end to the era of hypergrowth , which in turn means you have to start thinking about the rationale of, say, venture capital and private equity. Both have seen far better days.  As of the end of last year, the average TVPI (total value put in) of venture capital funds raised between 2017 and 2024 was between 0.8x and 2.0x , meaning you’d get somewhere between 80 cents and $2 for every dollar invested, with 70% of startup exits between 2022 and 2024 netting a loss for their investors , up from 58% between 2009 and 2014, which included much of the bloodbath from the great financial crisis. Per The Economist , the Valley also faces a glut of “Zombie Unicorns,” startups valued at $1 billion that can’t raise money or exit at their current valuation, and a third of all active US unicorns ( per Axios ) haven’t raised any funding in the last three years.  Meanwhile, private equity is facing much the same problem, with more than 16,000 “ zombie companies ” held for more than four years, the longest on record, and holding companies for an average of 7 years in total . Private equity exits have dramatically declined , with a growing amount of exits being funded by “ secondaries ” — venture or private equity funds selling each other their portfolios in the hopes of avoiding having to dump them at a loss. And wouldn’t you know, a big part of the problem is that they piled trillions into software companies assuming they’d all grow forever, massively overvaluing them in the process. Between 2018 and 2022, ( per Apollo ) 30% to 40% of private equity deals were in software companies, with firms taking on debt to buy them and then lending them money in the hopes that they’d all become the next Salesforce. In reality, private equity overvalued the vast majority of its software investments, stuffing them full of debt with payments contingent on near-constant growth, which is why Pluralsight lost its investors $4 billion and Medallia lost Thoma Bravo $5 billion . S&P and 451 Research analyst Scott Denne recently put it bluntly , saying that “..."The holding periods are longer and they're going to get longer because there effectively isn't an exit market for these companies.” It’s almost as if instead of looking at whether the companies were good and making intelligent decisions, private equity instead chose to do what had historically worked and assumed that its investments would continue to grow in perpetuity. You know, vaguely looking at history and doing things in an almost ritualistic way . In venture’s case, while part of the problem was how easy it was to get money in the ZIRP era , the other is that venture capital has been morphing into a cargo cult for a decade, with seed stage financing collapsing since 2015 , and continuing to drop in favor of middle-to-late stage rounds in established players…almost like venture capital just doing stuff in a way that somebody else did because it worked for them in the past. Venture capital no longer really cares about risk at scale, with the vast majority of funds going to late stage, and even “early stage” data poisoned by Series B rounds that are only something you can raise once venture capitalists have arbitrarily decided that you should continue living. As a result, the vast majority of funds do not go into creating the future or taking risks but doing things that resemble success , which usually means following hype cycles and hoping for the best. Baseten, a company that sells AI inference infrastructure, just raised $1.5 billion in a Series F funding round so that people can use or run their own open source AI models, quite literally allowing people to do things that other companies have been doing and train open source models of their own, so that they too can “do AI.”   Its investors include D.E. Shaw Ventures, Greylock and Altimeter Capital, all of whom invested in both Anthropic and OpenAI. Baseten doesn’t own its own infrastructure , renting instead from hyperscalers, which means that that $1.5 billion goes directly into the pockets of Google, Amazon and Microsoft, much like the money raised by OpenAI and Anthropic, which in turn gets spent buying more NVIDIA GPUs. All that “free thinking” and defiance of incumbents always seems to end up as revenue for the largest companies in the world. So much for backing the little guy!  While the Valley’s legend has grown from risk-taking and fostering new ideas, venture capital works in reverse, overwhelmingly funding market consensus and piling into deals after somebody else has risked their capital to keep it alive. Decades of encouraging people to fund startups with the express intention of hypergrowth — with Ben Horowitz suggesting in 2010 that having “zero chance of becoming a high-growth company” was tantamount to “being in purgatory” — has created a startup culture focused entirely on its Total Addressable Market and growth trajectory, which means that companies are founded with that express intention.  Venture capital funds companies that appeal to venture capital, which means Silicon Valley innovation is centered around finding ways to convince venture capital to give it money. While this might have worked a decade ago when there were still hypergrowth companies to build, it intellectually stunted the Valley, promoting and celebrating companies not based on the things they’ve built but the shareholder value they’ve created . A startup is considered a “success” not based on its tangible contribution to the future, but its ability to tick boxes either through funding, revenue growth, acquisitions, or valuation. Everything is about creating the signs that your company is part of the big thing that will supposedly lift every Silicon Valley valuation — after all, 61% of venture capital funding went to AI in 2025 — to the point that it isn’t really clear what anything means or what anybody is doing. Nowhere is this more obvious than the eternal shuffle of different guys between different AI companies. Google paid $2.7 billion in 2024 to acquire Noam Shazeer, one of the authors of the paper that started the generative AI bubble, along with his worthless AI chatbot company Character Dot AI. Two years later, Shazeer is joining OpenAI , and it’s unclear whether his second tenure at Google really did anything, other than helping pad the bags of venture capitalists and possibly having some effect on Google Gemini. It’s unclear what changed at OpenAI when co-founder Andrej Karpathy left in February 2024 , nor is it clear what is happening now he’s joined Anthropic . Barret Zoph left OpenAI in October 2024 to become the CTO of Mira Murati’s Thinking Machines, created absolutely nothing of value, went back to OpenAI in January 2026 as its “GM of B2B,” oversaw an era where its enterprise customers had “huge issues” with its costs , then left again , I assume to another AI lab that will give him lots of stock. I’m going to go out on a limb and suggest none of these guys actually contributed very much in their most-recent tenures, and that their hiring and positions were further cargo cult moves. Noam Shazeer was the original Attention Is All You Need guy! Give him $2.7 billion! Quick, before somebody else does! Quick, hire Andrej Karpathy, a guy who hasn’t worked at OpenAI in years, to do something with your LLMs! His eternal brilliance — which resulted in absolutely nothing since he left OpenAI outside of a placeholder website for a dead education startup with a protected Twitter account — is necessary to doing whatever it is we’re meant to do next! This will help us do hiring too, because everybody wants to work with these great minds that do stuff, somewhere, at some point, or maybe they did stuff, I don’t really know!  Hey, remember when Mark Zuckerberg was paying tens of millions of dollars to hire random AI researchers ? Why do you think he did that, other than the fact that everybody else was hiring lots of AI researchers? Hey, while we’re on the subject, what exactly did they end up doing? That’s right, a mid-tier AI model and an AI app that nobody uses! Sure sounds like Mark Zuckerberg was just doing whatever seemed to work in the past, which was “get smart guy, smart guy do stuff, thing happen,” much like when Microsoft hired Deepmind co-founder Mustafa Suleyman for over a billion dollars , with little to show for it other than mid-tier LLMs, a universally-loathed chatbot , massive capex, and AI revenues that are too small to break out in Microsoft’s earnings.  No, sorry, I forgot the latest cargo cult maneuver — OpenClaw, a product that 99% of people have never heard of other than those who intentionally drown themselves in Silicon Valley cultism, which is why Microsoft , NVIDIA , Meta and Amazon all built OpenClaw bullshit and OpenAI hired its founder . Everybody is moving between various different rituals in the hopes that they’ll be the ones that they’ll be The Great Winner of AI, even if nobody really knows what that is and is only doing all this shit because everybody else is doing it.  That’s because the AI bubble has been part of the greater cargo cult of the Valley. Why did Microsoft buy hundreds of thousands of GPUs? Because an engineer told him that if millions of people used ChatGPT via Bing, they’d need “ every high-end chip the company had .” Why did everybody freak out about ChatGPT? Because it was the first viral product the tech industry had created, and it was truly different. Why does anybody think LLMs are going to change anything? Because everybody vaguely came to the consensus that ChatGPT was trending in the direction that something would change.   And so the greater tech industry moved into full cargo cult mode. Amazon, Google, and Meta had to buy all those GPUs because Microsoft bought a lot of GPUs . Investors piled into various AI companies because when the tech industry does something at the same time, big things happen. Everybody has acted based on reading the signs — ChatGPT’s meteoric growth meant that it could be the next Google, and because the economics had worked out in the past, they would work out here , which is why everybody tells you that it’s just like Uber ( it isn’t ) or AWS ( which cost $52 billion between 2003 and 2017 , or less than a quarter of What OpenAI and Anthropic raised in the last 6 months).  The AI industry is fundamentally judged based on its symbolic similarities to bygone eras. Buying GPUs and building data centers sort of feels like Amazon Web Services, even though the $765 billion that big tech will spend in 2026 will be more than ten times Amazon’s combined capex during the period where AWS was being built. ChatGPT sort of feels like Google Search or Facebook Ads or next app store, but only because it’s a culturally-relevant piece of software, largely driven by the larger cargo cult of tech crystalizing around it.  Most people trying to make these comparisons either don’t remember or are desperate to forget how different the world was when Google Search, the iPhone or Amazon first grew. They don’t want to think too hard about how blatantly obvious the utility of these products was, how they had functional unit economics from their earliest days, or how different their growth stories were. They don’t want you to think about it either, because part of the greater cargo cult is making sure you don’t believe your lying eyes and focus on the greater signs that The Great Prophecy might come true, even if it’s not obvious what that means other than “ChatGPT is the biggest most hugest and most profitable company ever and everybody makes money on their investments.” OpenAI and Anthropic are the height of the Valley’s mysticism. Both are still referred to as startups, despite the fact that Amazon, Google, and Microsoft paid for their entire infrastructure, spending at least $200 billion just on buying GPUs and building capacity for two companies. They have raised — assuming their most-recent rounds fully close — close to $300 billion in the space of two years, and are on course to burn tens of billions of dollars each in 2026.  Neither Anthropic nor OpenAI are actually startups. They have enough money and clout to hire just about anybody, can deploy billions of dollars in stock for acquisitions, have their infrastructure fully paid for by other companies, and because it’s taken so much money to build said infrastructure, effectively nobody else can train models or serve inference at their scale, making them the functional equivalent of a hyperscaler.   And neither company feels anything less than insane outside of outright ignorance or a cargo cult mindset. Both companies have had everything paid for them either by hyperscalers or venture capitalists, and are fundamentally incapable of operating without infinite resources, and the best that anybody has to defend their endless billions of burn is to refer to the 184-year-old railway bubble or the Dot Com Bubble , using them as symbolic proof that everybody can lose a lot of money, and that somehow results in something good, I guess? The logic centers around the idea of “useful infrastructure,” as if railways or telecommunications equipment have any similarity other than that people spent way too much money on them in bygone eras. AI boosters (and the well-meaning and ignorant) return to these bedtime stories as a means of escaping reality and accepting that it’s very possible for everybody to be wrong in a completely new and innovative way. This is the same mystical thinking that gets us to the idea of OpenAI or the greater AI industry being “Too Big To Fail,” an ahistorical trope that ignores the Term Securities Lending and Primary Dealer Credit Facilities that plugged trillions ( no, really! ) of dollars into the side of the banking industry because failing to do so would’ve left America’s financial system insolvent. OpenAI, Anthropic and every AI startup could disappear tomorrow and the world’s financial systems would continue unabated, other than the brutal hit to the stock market and screeching of venture capitalists.  That’s because their actual relevance is, in and of itself, symbolic. OpenAI and Anthropic combined to less than $20 billion in annual revenue in 2025 representing 89% of all AI startup revenues , and spent at least $30 billion on compute on Microsoft Azure, Google Cloud and Amazon Web Services. Their services are sold using the very same cargo cult mentality that got us into this mess — organizations adopting AI at scale and demanding that people use it because “AI is so powerful,” or, put another way, somebody they respect or like suggested it’s the future, and because none of these executives actually build anything or do any work, they have no idea what to do other than whatever it is that everybody else is doing. Our economy is dominated by companies run by people who didn’t build and who don’t participate in the products or services they sell. They have little or no practical experience about what it was that made the company a success, and their “daring” initiatives usually boil down to “fire a bunch of people and flatten the organization” or “spend a bunch of money because it’s the thing to do.” They do not know what AI does other than the fact it can write code or write copy or generate stuff , but because everybody is “doing AI,” they too must “do AI,” which means “everybody that works for me must do this, and also we must add this somewhere, somehow.” But that’s all the modern tech industry can do: an impression of something they think is successful in the hopes that they’ll be successful too. In September 2024, Airbnb CEO Brian Chesky gained an alarming amount of praise for doing “founder mode” at the company : Chesky also notes that he was inspired by “studying Steve Jobs,” a person who has been dead for many years, choosing “not to copy everything, but a lot of how he organized and ran the company.”  Airbnb is most decidedly not Apple, and neither Chesky nor his team are anything close to those who built the original iPod, iPhone, or even the Apple HiFi. Airbnb is a cloud service platform that lets people rent their houses out. When Chesky says he’s “studying Steve Jobs,” he likely means that he watched a few movies, documentaries and videos of Jobs speaking about things that have nothing to do with him, looking for similarities that he could copy — almost like he was copying a successful guy’s moves in the hopes that doing so would give him similar results. Airbnb remains a better-than-the-rest front end for you to rent other people’s houses that provides payment and support layers, and the vast majority of its revenues come from monetizing that process. Airbnb’s stock remains effectively flat since Chesky’s “founder mode” designation, and it remains (extremely) modestly profitable . The irony of the discussion is that it comes from a Paul Graham essay that basically boils down to “the CEO should actually do stuff at the company and know who does stuff at the company,” except written with a Sorkin-esque drama:  No, actually, this shouldn’t be that hard if you actually talk to people at the company, even at a large organization like Apple, if you have any idea what people do for a living. Sure it’d be a lift, but if you can’t organize a 100-person event with a year’s lead time just because you’re too lazy and inert to understand what’s going on, perhaps you shouldn’t be running a company to begin with?  You see, the Valley can’t just say “yeah you should have an active hand in your company and not delegate everything,” it has to be founder mode because everything is special! If tech firms aren’t run by people going founder mode , then they’re just software companies selling software. If OpenAI and Anthropic are just software companies with huge infrastructural costs, then you have to start treating them like normal companies with those kinds of burdens, which would make you start screaming at the top of your lungs. This is the hyperreality (and cargo cult mentality) of Silicon Valley. Apple, Google, Microsoft, and Meta were companies that grew out of relatively boring stories — kids getting internships working at tech companies, computer science graduates coming up with software-driven ideas, and so on — with very few actual lessons to learn other than “you should come up with a really good idea and do it at exactly the right time.” Romanticizing the legend of Steve Jobs or Mark Zuckerberg or Bill Gates, rather than their luck and potential ability to hire people who actually build things for them, allows you to pretend that there are lessons to be learned, and that in turn you too could have these otherworldly riches if you just try hard enough. The success of these large companies has predominantly come from having a few good ideas, great timing, good execution, and building largely-immovable monopolies rather than any incredible acts of genius. Jobs, Zuckerberg, Bezos and Gates all succeeded by finding people who actually did stuff , such as the Sanberg-led growth team that turned Facebook into a monster , and Tony Fadell and Scott Forstall’s hardware and software teams pulling together the original iPhone. Their successes were not the result of some series of things you can mimic or the tone of their voice or a specific series of actions, but being in the right place at the right time with the right idea and the right people, at a point when the underlying hardware or semiconductor infrastructure had reached a point when the idea was possible. Put another way, there was a shit ton of hard work, innovation, and talent that went into these things that you can’t copy, even by working really hard or yourself having a bunch of talent. The ideas must be possible, economically viable, and you must have the people and infrastructure to execute them. Amazon Web Services may have lost money, but lost significantly less than OpenAI or Anthropic, and was significantly more useful than anything the AI industry has ever produced. In 2013 — the year that Amazon Web Services went profitable — Amazon’s total debt was $5.18 billion . And really, there’s nothing more cargo cultish than defending OpenAI burning $21 billion in a single year by saying “this other company burned money too.” Even if the losses were comparable, Amazon was building two very different businesses — a digital store and a cloud compute platform — to OpenAI, which is training and selling access to large language models at a massive loss , does not own its infrastructure, and has absolutely no path to profitability outside of “we keep spending other people’s money.” But that’s all the AI industry is — people doing impressions of things that have worked before in the hopes that they’ll work again. Every AI lab and startup started with cargo cultish subsidized subscriptions , assuming at some point somebody else would solve the problem of costs or that they’d “make it up in volume,” because that’s what worked before. OpenAI and Anthropic threw as much money at pre-training models because a paper had suggested that if they did so there would be infinite gains ( versus diminishing returns ), and when Anthropic worked out that you could add a bunch of scripts on top of an LLM to do coding better with Claude Code, OpenAI immediately copied that and made Codex. Both companies are now jousting to make much the same product by giving away API credits and free weeks of access to create the symbolic aura of an “essential” product to continue convincing VCs and the public markets that they’re “building the future” rather than effectively paying their customers to use their products. The “popularity” of AI has come entirely from social pressure and endlessly-discounted access, and the very second that they charged the actual costs, their customers started freaking out and kvetching about whether AI has ROI .  Our economy is dominated by people who have only a symbolic understanding of the world — Business Idiots with little interaction with productivity or production who do not know how value is created and thus can only create facsimiles of valuable companies. Perhaps they’re lucky enough to have businesses that effectively run themselves, or monopolies that can survive having 98% of their free cash flow spent on AI data centers that only lose money , or are smart enough to stay out of the way of the people who actually do work.  But in many cases, the people running companies — especially those most-obsessed with AI — are cargo cultists following “the most valuable companies in the world” into a void that demands they twist every part of a company they don’t understand into a form that ingratiates them and makes them feel like they’re “doing business.” It’s an obscene and childish way to live one’s life, and typical of an economy that optimizes for growth at all costs thinking and coddles those who think that way. Even the economics of the AI bubble are cargo cultish. The use of annualized revenues ( the single-most easily manipulated metric in Valley history ) as a means of promoting growth only exists as a means of spreading the symbology of hypergrowth, all while deliberately obfuscating the actual financial health of the company by using a single monthly (or weekly) snapshot to extrapolate an annual figure, something that’s particularly egregious when you realize that it involves non-recurring charges like spending money via Anthropic’s API. Yet the Valley either realized (or was fortunate enough to find) that the media had bought into their cargo theology . Much like the Valley craves symbols or prophetic signs that today’s startups will become the next Google, modern tech and business journalism runs not on any scrutiny or skepticism of the future but in finding the “next big thing,” which often requires it to find the very same symbols that the Valley craves, often provided by the executives themselves.  They crave to be the ones to find the next Jobs, Zuckerberg, Bezos, or Gates, and in their crazed search only seek to repeat the same mistakes of every bubble, never noticing that the tech industry has had an astonishingly bad record for more than a decade.  The tech industry must always be framed as an impossible-to-decipher monolith full of troubled geniuses that have good intentions, because when you stop thinking that way, you start seeing it for what it really is — a vehicle for symbolic capital that stymies innovation and promotes growth over everything, funding things based on their similarities to the past and how warm and fuzzy doing so makes them feel. And in its incredible success as a vehicle for capital, tech has managed to beguile society and turn journalists, economists and regulators into cargo cultists that can be easily won over by a smart-sounding guy or an emphatic-enough press release.  AI is the natural endpoint of the Valley’s cargo culture — money-hungry models that can vaguely resemble something that might grow into the future, with opportunities to deploy capital that resemble previous infrastructure movements, all with convenient ways to explain away dissent that mostly boil down to “bad thing happen before but then good thing happen after.” Everybody believes that because AI startups can grow their revenue they’ll grow that revenue forever, that because startups in the past lost money that AI startups will stop doing so, and that because something has a lot of users it can never disappear. I challenge everybody reading this to start living in the present, and to stop taking excuses for the mediocrity of AI. AI boosters are no longer allowed to speak in the future-tense, nor are they allowed to justify AI’s losses based on previous eras.  If you’re an AI booster yourself, know that the AI companies treat you with complete contempt. They force you to defend dogshit, to wheel and deal in dogshit, to celebrate dogshit like it’s caviar, to tell others that they too must defend dogshit, because one day the dogshit will be good.  Nowhere has this been more evident than the response to my exclusive last week . Some have been mighty confident about inference being profitable (due to a $7.5 billion cost of revenue on $13.07 billion in revenue), but overlooked my reporting from last year verified by the Financial Times showed OpenAI spent $8.67 billion on inference in the first nine months of 2025. It’s very clear OpenAI moved around numbers to make things look better than they are, and I believe that inference costs are being dumped in sales and marketing.   How else are you to explain how a company spends more than 43% of its revenue ($5.73 billion) on sales and marketing — more than the Coca-Cola corporation , which has three ad agencies and a vast web of different print, digital, and physical ad spend. Microsoft had $500 million of “sales and marketing” spend too. What do you think that is? OpenAI spending $500 million on sales and marketing through Microsoft? Or itemizing promotional spend or the inference from free users as a sales and marketing cost? If you disagree, please explain in any level of detail how OpenAI has spent $5.67 billion on sales and marketing. Its first major advertising campaign was in September 2025. If it’s spending $250,000 a year on its 500 sales staff, that’s still only $125 million. Unless OpenAI is one of the single largest accounts in digital advertising, I think it’s far more likely that there are actual costs being hidden.  This is the kind of thing a company does when it has utter loathing for its investors and the general public — a brazen attempt to bury costs to make things feel better for an audience that’s directly incentivized to take any shred of proof that things are okay, even if said “thing” is the suggestion that a company that lost $21 billion only actually lost $8 billion .  Alternatively, it’s what an industry does when it believes everybody is gullible enough to accept and promote any rationalization that confirms their beliefs.  So far, they’ve been proven right. Every time I show somebody the kind of tangible proof that these companies are economic septic tanks, somebody uses some sort of theological, mythological or historical statement as proof that what I’m saying doesn’t mean anything. Silicon Valley, the so-called hub of meritocracy and rugged individualism, runs on a kind of empty cultish ephemera that usually ends with sedative-laden Kool Aid. In the end, faith can’t fill your belly, or cover $1.1 trillion in compute commitments . It can’t magic up $2 trillion in revenue by 2030 for an industry that basically doesn’t exist without OpenAI or Anthropic. And however you feel about AI, you should demand better proof of its inevitability than a bunch of mythology, hype, and cargo cult bullshit. If you liked this piece, you should subscribe to my premium newsletter. It’s $70 a year, or $7 a month, and in return you get a weekly newsletter that’s usually anywhere from 10,000 to 18,000 words, including vast, detailed analyses of the biggest events and companies in the AI bubble.

0 views