# Armin Ronacher Armin Ronacher's personal blog about programming, games and random thoughts that come to his mind. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Interpreting Pangram DevFeed: [Interpreting Pangram]() Original publisher: [Read original article]() Author: Armin Ronacher Published: 2026-09-14T00:00:00Z Content type: opinion Language: en Sources: [Armin Ronacher]() Topics: [Artificial Intelligence](), [Large Language Model](), [datasets](), [Training AI Models]() Tags: [ai](), [llm](), [model](), [openai](), [training](), [training-data]() ### AI overview The article discusses Pangram, an AI-text detector that classifies passages as human-written, AI-generated, or mixed. It explains that Pangram manufactures training data from human-authored text and LLM-generated rewrites and edits, then describes an experiment using Opus 5 to generate text intended to read as entirely AI-generated. ### Source excerpt Yesterday David Sacks wrote a tweet and within a few minutes people did, what they usually do, and they asked Pangram if it was AI. And Pangram said it's entirely AI generated. To which David replied that these AI detectors are bogus. Now Pangram has a pretty low false positive rate, but if you have ever used an LLM as a writing assitant, you will have probably noticed that it claims your posts 100% AI, even though you don't feel like they are. Pangram itself is a trained model, that attempts to detect segments of text as being definitely human, definitely AI and a mixture of the two. If you want to know how it works, they published a paper. The short summary is that they are manufacturing its own training data by starting from collections of known human authored text. An LLM is then tasked to understand the text and write a fresh new text on the same topic. They also let the LLM perform partial edits on that original human text and through that they can pick up on these co-authored details. Pangram claims their model to have rates of 0.0041% false AI accusations and 0.34% missed AI text. So now that we know this I figured it might be fun to have an LLM re-create David's tweet. I first came up with a prompt. And when I say I came up with that prompt I in fact used an LLM to propose to me from that tweet what I might want to say for the structure. I'm sure if you ask Pangram about if the above text is AI, it will probably say so, but that's not really the point. The point is that I then used Opus 5 to generate a text which reads entirely AI generated. If you are curious, this is the prompt I used: Original prompt to generate a David Sacks like tweet Please write an 8 paragraph tweet about "Pacing the Frontier", not longer than 350 words. Context of this tweet is this post by Dario: https://darioamodei.com/post/we-must-pace-the-frontier And this tweet by Sam Altman: "I agree with Dario that we need to pace the frontier. This has been a primary topic of discussions we' ## Why Persistent Botnets and Human Impacts Matter in AI Risk DevFeed: [Why Persistent Botnets and Human Impacts Matter in AI Risk]() Original publisher: [Read original article]() Author: Armin Ronacher Published: 2026-09-12T00:00:00Z Content type: opinion Language: en Sources: [Armin Ronacher]() Topics: [Artificial Intelligence](), [anthropic](), [OpenAI]() Tags: [agents](), [ai](), [anthropic](), [openai]() ### AI overview This opinion article responds to arguments about AI risk and pacing frontier development. It focuses primarily on persistent botnets, the difficulty of monitoring large-scale AI systems, and the potential effects of advanced models on people. ### Source excerpt This week some flavor of "AI is going to kill us all" went viral. In particular one where an employee put his personal probability of that happening above 10%. Which made me go to the Wikipedia page of P(doom) and I realized that Dario Amodei's apparent probability of something bad happening seems to be between 10-25%. And well, Dario then wrote about pacing the frontier . And Sam read it and wants to pace too. And well, so does Musk. I encourage you strongly to read the post, because I think it's a good one. And yet, when I read the post I could not help but feel in strong opposition to it, despite the fact that I think I'm on the same page with regard to all observations and, to a large degree, the concerns. I thought it might be interesting to write down my present-day thoughts on this, even if for no other reason than for myself to look back at it a year or two from now. What Is Doom? What I really appreciate about Dario's post is that he lays out a scenario that is not a huge stretch but also one that describes a clear, unfortunate outcome we should fight: persistent botnets and other forms of nuisance. And well, we don't have to look very far to see the issues left and right. Wikipedia has a page called 2026 OpenAI agent cyberattacks which gives you at least some overview of what we figured out agents have hacked up to this point. Except I know it's not up to date, because for instance they also poisoned RubyGems. Today these systems might be annoying, but they can be turned off when we figure out where they are. Except, it seems like OpenAI and Anthropic are operating at such a scale that they seemingly can be completely blind to what their systems are doing. I don't think we are anywhere close to a world where an agent might decide to hack into core inference infrastructure to upload weights to other GPUs to survive. But simultaneously it's entirely in the realm of possibility and primarily curtailed by the labs probably being particularly careful about thei ## GPT 6 Astra's performance in a software-engineering workflow DevFeed: [GPT 6 Astra's performance in a software-engineering workflow]() Original publisher: [Read original article]() Author: Armin Ronacher Published: 2026-09-07T00:00:00Z Content type: opinion Language: en Sources: [Armin Ronacher]() Topics: [Artificial Intelligence](), [AI Engineering](), [Software Engineering](), [computer-use](), [ChatGPT](), [Python](), [Concurrency]() Tags: [agent](), [ai](), [ai-engineering](), [chatgpt](), [computer-use](), [python](), [software-engineering](), [thoughts]() ### AI overview The author argues that AI engineering can intensify effort without improving productivity and examines GPT 6 Astra's usefulness for software engineering. A self-managed software factory using Astra produced substantial code and prompts over 35 hours but, according to the author, delivered nothing of value and provided no clear lessons for improving the workflow. ### Source excerpt I'm more and more convinced that all of AI engineering is Neijuan (内卷, meaning curl inwards). In China it describes a system that demands ever more effort and competition without improving output. The way in which it sometimes shows up in the West is the 996 nonsense. The English term for Neijuan is "Involution" from the book Agricultural Involution. Agricultural involution describes the intensification of farming that raises productivity per square meter while leaving productivity per head unchanged. That's how I feel about AI right now. Which brings me to GPT 6 Astra. Astra is by all accounts an incredibly impressive model. There is really not much I can say against this. It's amazing at computer use, understands images and complex topics, and it's relentless in its pursuit of completion. It is absolutely impressive; these types of models are going to change the world in one form or another. But at least for the moment I don't know how to work with it for actual software engineering. Since that got quite a bit of attention on Twitter, I figured I might summarize my thoughts and just share what kind of code comes out of this thing. My Slop Factory "Armin, you should run a software factory!" I've heard that a few times now, so I figured I might celebrate the release of it by running a little software factory over the weekend. If everybody builds slop 3D games, then I should do something useful with it. My software factory was intentionally set up to let the model decide the how of the workflow entirely. It was free to manage its own context and could maintain its own records in an agent-notes folder. Then it spun off subagents to work on stuff. The goal? What if we had a Python with virtual threads and lexical scoping. And well, I burned a full reset's worth of ChatGPT tokens on this which appears to be around 4 billion tokens. 35 hours later, the factory has delivered absolutely nothing of value and also not taught me anything about how to operate a better one. But ## Latent Powers DevFeed: [Latent Powers]() Original publisher: [Read original article]() Author: Armin Ronacher Published: 2026-09-05T00:00:00Z Content type: opinion Language: en Sources: [Armin Ronacher]() Topics: [Dongle](), [Hacking](), [Rust](), [Embedded Software Dev](), [Protocol (disambiguation)](), [Raspberry Pi]() Tags: [ai](), [dongle](), [firmware](), [hacking](), [protocol](), [raspberry-pi](), [rust](), [soc](), [thoughts](), [usb]() ### AI overview A developer experiments with modifying a cheap CarPlay dongle to run custom code while preserving regular CarPlay functionality. After receiving a different SoC than expected, they use LLM-assisted discussions to flash the device and compile CatPlay, a Rust reimplementation of the CarPlay protocol, for the hardware. ### Source excerpt A few weeks ago I felt like it would be fun to see if I can make one of those cheap Chinese CarPlay dongles run something other than the stock firmware. The idea was that rather than just forwarding CarPlay, why not do something more interesting with them? They all work quite similarly: they act as bridges between your car and the phone. From there they deal with video and audio streams and pass some other data through. Most of them also bring up a custom UI for pairing and have a web interface that your phone can reach for updates. Long story short: I had a conversation with Fable and Sol via Pi about what could be done with such a dongle or whether I should use a Raspberry Pi instead if I wanted to do my own thing there. I figured it might be quite fun to run my own code while still allowing regular CarPlay to pass through. Through working with the LLM I learned about CatPlay, which is a Rust reimplementation of the CarPlay protocol that can run on Carlinkit devices. In particular, it can run on the Carlinkit Mini Ultra, which I figured would be easy enough to buy. I do have a few CarPlay adapters around, but I did not have that particular model, so I bought one on Amazon. Twenty-four hours later, I had a device in my hand that was branded as a Carlinkit Mini Ultra, but instead of being the Ingenic device that the original author used, it turned out to be something else. This is normally where the story would stop. However, it's 2026. Armed with a bit of knowledge about how these systems work, I managed to have some fruitful discussions with Kimi K3 and Sol and figure out how flash the device and in turn, how to make CatPlay compile for that SoC. I guess that hacking these USB devices is not necessarily hard, but it's laborious and you can easily end up bricking your devices. It also just sucks because sometimes you need to work with someone else's code that does not itself run on your machine. In the past, I would abandon many such projects for lack of tenacity. ## Anger, Anxiety and Agency DevFeed: [Anger, Anxiety and Agency]() Original publisher: [Read original article]() Author: Armin Ronacher Published: 2026-08-24T00:00:00Z Content type: opinion Language: en Sources: [Armin Ronacher]() Topics: [Artificial Intelligence](), [context]() Tags: [agents](), [ai](), [emotion](), [thoughts](), [work]() ### AI overview The author argues that anxiety and uncertainty are more constructive responses than anger to AI and agents' effects on the technology industry. They discuss concerns about changing professional skills, how productivity gains may be distributed, and tensions between companies and large AI labs. ### Source excerpt Sean Goedecke wrote a post arguing that you should never be angry at work -- a post with which I strongly agree. Anger can be a useful signal, but being angry at work rarely improves the situation. More often, it makes life worse for the people around you, many of whom have no more power over the source of your anger than you do. I did learn that lesson, but it did not come naturally. One thing in particular that I learned is that in a company there is a shared vision, and if you don't agree with it and are not in a position to change it, you should not start a mutiny, not even a small-scale one. Nothing good comes from that. In the discussion around that topic, one of the most upvoted comments on the Lobsters thread asked a question I had to think about quite a bit: How can you work in tech right now and not be angry? In the context of the thread, this was clearly also about AI and agents. For me, the emotions I would expect in tech vis-a-vis these new developments are disorientation and anxiety, but not anger. Anxiety as an emotion does not require someone to blame. Right now, I find it reasonable to feel anxious about an uncertain future. Who knows what our professions will turn into and what kind of world my kids will find themselves in when they enter the workplace? And if you've been in the industry for a long time, will the skills you've spent years acquiring still matter? But anger is different from anxiety because anger needs to be directed somewhere. The feeling of anger suggests that somebody or something is doing something to you. Who are you going to be angry at and why are you angry in the first place? One narrative that is pretty pervasive is that if AI will usher in productivity gains, those gains are going to benefit companies rather than employees. And well at least someone at Meta wants that. Yet I also find that plenty of people in leadership positions express doubt about AI. They see that an increasing share of their costs is being funneled direc ## Fast and Hard Code DevFeed: [Fast and Hard Code]() Original publisher: [Read original article]() Author: Armin Ronacher Published: 2026-08-22T00:00:00Z Content type: opinion Language: en Sources: [Armin Ronacher]() Topics: [Rust](), [LLMs](), [Zig](), [Artificial Intelligence](), [Programming](), [WebAssembly](), [Cloudflare](), [Vercel](), [eBPF]() Tags: [ai](), [cloudflare](), [ebpf](), [llms](), [performant](), [programming](), [rust](), [thoughts](), [vercel](), [webassembly](), [zig]() ### AI overview An opinion article argues that LLM-assisted programming makes language choice less consequential, allowing developers to use unfamiliar or traditionally difficult languages. It focuses on growing interest in fast, small software built with Rust and Zig, while noting examples involving WebAssembly, Cloudflare, Vercel, and other demanding technologies. ### Source excerpt One of the memes on Twitter is that "programming is solved now." I'm not sure to what degree it is, but one thing is pretty clear: the act of familiarizing yourself with a language no longer matters and some of the friction that mattered for humans does not matter for agents. As a result, LLMs make language choice much less consequential than it used to be. If you don't like the choice, you can seemingly rewrite it in another language and you can make it pick a language that you, as a programmer, are entirely unfamiliar with. Which in turn means that people can, and do, choose based on the marketing of languages much more. As a long-term Rust programmer I found it quite fascinating to see people now ship Rust code who previously might not have chosen it. I attribute at least one part of this to two recent vibe shifts: there is a lot more talk about wanting fast software, and about LLMs being exceptional at optimizing code without regressing behavior. Folks like Mitchell Hashimoto, Charlie Marsh, Jarred Sumner, Daniel Lemire and quite a few others always carried a certain level of obsession with fast and performant software and they also all happen to be receptive to agents writing code. Maybe as a result, or unrelated others are now joining in. That's because with things like autoresearch you don't even necessarily need to know all the tricks: you just need to put an agent on it -- though knowledge greatly helps! If you look around, there are plenty of projects that want to be fast and small, and they increasingly pick "hard languages". And it's not just Rust that is benefiting. Even Zig -- despite the fact that the creators and parts of the core community are pretty negative on the whole AI thing -- is too. For instance Cloudflare's new Artifacts service uses a pure-Zig Git-protocol engine, compiled to a roughly 100 KB WebAssembly module and Vercel released fx, a Zig coding agent advertised to be small and fast. From what I can tell, all these projects are largely LLM ## How Reasoning Traces Work in Language Models DevFeed: [How Reasoning Traces Work in Language Models]() Original publisher: [Read original article]() Author: Armin Ronacher Published: 2026-08-19T00:00:00Z Content type: article Language: en Sources: [Armin Ronacher]() Topics: [Chain-of-thought](), [gpt-oss](), [Parser](), [API](), [Cache]() Tags: [ai](), [api](), [chain-of-thought](), [gpt-oss](), [reasoning](), [token]() ### AI overview The article explains reasoning traces as text emitted by a model into a scratchpad before its final answer. It discusses how GPT-OSS uses channel markers and a parser to route analysis into a separate stream, and argues that reasoning effort is shaped by system prompts and training rather than being solely a sampling-process property. ### Source excerpt A few weeks ago a paper was shared that showed how to extract reasoning traces from closed-weight models. Together with online discussions about tricking models into leaking them, it made me investigate it more out of curiosity. Twitter seems full of half-truths and confusion about how this works, so perhaps this helps some to understand what is happening. Hiding Traces Reasoning traces are usually hidden from us. We have lamented this, but mostly have to accept it. Open-weight models thankfully reveal them, and from their behavior you can see that their traces can be long and confusing. This is probably a good reason to separate them from what is normally shown to users. At minimum, UIs need to detect them. The industry has done a good job at making reasoning traces sound special and exotic, but they really are just text: the model is trained to emit its thinking into a scratchpad as part of its response, before its final answer. GPT-OSS's Harmony response format makes this easy to see: <|channel|>analysis<|message|> I need to work this out ... <|end|><|start|>assistant<|channel|>final<|message|> The answer is ... <|return|> The markers are special tokens, but the reasoning between them uses "the same text" as the final answer (just that GPT chain-of-thought text sounds really funny). When the model samples the analysis channel token, a parser routes the following text into a separate stream exposed through the Responses API. For closed models, presumably a simple model redacts and summarizes it. Reasoning Effort How much budget goes to reasoning? Earlier APIs exposed reasoning token budgets, making it seem like a property of the sampling process. In reality, reasoning effort is baked into the system prompt. GPT-OSS puts this into the system prompt: Reasoning: low That's it. Training produces the resulting behavior, such as emitting the token sequence that switches to the analysis channel. This also explains why changing the effort invalidates the KV cache. I think ## Codeberg's Generative AI Policy and the Future of Open Source Hosting DevFeed: [Codeberg's Generative AI Policy and the Future of Open Source Hosting]() Original publisher: [Read original article]() Author: Armin Ronacher Published: 2026-07-24T00:00:00Z Content type: opinion Language: en Sources: [Armin Ronacher]() Topics: [Open Source](), [Large Language Model](), [Generative AI](), [GitHub]() Tags: [ai](), [generative-ai](), [github](), [llms](), [open-source](), [open-source-software](), [thoughts]() ### AI overview The article examines Codeberg's new terms excluding projects mostly written by generative AI tools. It argues that the policy is vague and may be difficult to enforce, and suggests that clearer rules targeting spam or abusive resource consumption could be preferable. The author argues that well-used LLMs should remain welcome in the Open Source community. ### Source excerpt Codeberg recently changed its terms to exclude projects that are largely written with generative AI. Considering I want GitHub to get some competition I have thoughts about this. GitHub's governance has never been democratic and there is plenty about the platform that I dislike. Yet I do not need my infrastructure to be democratic but I need it to be predictable and reasonably neutral towards the Open Source software hosted on it. A democratic provider without a clear constitution can be worse at those things than a corporation is. Codeberg is entirely within its rights to do run the platform like they want. It is a German association with members and a democratic process, and that process produced a result. But a democratic vote says nothing about whether the decision is a good one, particularly for the people already depending on the platform. A majority can still decide that certain projects and people no longer belong. The new terms prohibit projects that mostly consist of code written by generative AI tools. That's fine, but these days I could not assign authorship percentages to my recent projects. For me this rule is quite vague and I would bet that it makes it hard to enforce. In practice my assumptoin is that the center will leave. If anything a harsher line would probably be preferable. If Codeberg wants no LLM involvement, it should say so. On the other hand if the objection is just spam and abusive resource consumption, it should write rules for those instead. Now it defers the details of the policy to moderators and the communit which already draws a much harder boundary than the text does, judging by the tone of the discussion around it. It is a shame that the Open Source and Free Software communities are splitting this deeply over LLMs and agents. These systems have problems, but these tools are also becoming part of how software is made. The Open Source world needs to figure out how to engage with that future. More importantly, LLMs if used well, sho ## AI-Assisted Programming and Shared Understanding in Software Projects DevFeed: [AI-Assisted Programming and Shared Understanding in Software Projects]() Original publisher: [Read original article]() Author: Armin Ronacher Published: 2026-07-13T00:00:00Z Content type: opinion Language: en Sources: [Armin Ronacher]() Topics: [Artificial Intelligence](), [engineering-culture](), [Documentation](), [Code review]() Tags: [ai](), [ai-assisted-programming](), [code-review](), [documentation](), [thoughts]() ### AI overview An opinion piece arguing that AI-assisted programming can make individual developers faster, but large software projects still depend on teams coordinating a shared understanding of the system. ### Source excerpt I feel that some vibecoded software changes somewhat randomly and unexpectedly. That made me think about Bruegel's "The Tower of Babel" which shows an already quite chaotic depiction of the Tower of Babel. The story is one of pride and ambition and ultimately why people no longer speak the same language. But it is also a story about the unity that makes technological progress work. The text begins with a technology upgrade: And they said one to another, Go to, let us make brick, and burn them thoroughly. And they had brick for stone, and slime had they for morter. They use it for a civilizational project: let us build us a city and a tower, whose top may reach unto heaven But when God assesses the situation the bricks are not what concern him: the people is one, and they have all one language, [...] and now nothing will be restrained from them.1 They get their power through coordination which they have because they share a language. They can use this to coordination to combine their powers and build something no one of them could build alone. God does not take away the bricks or their knowledge of how to make them but their ability to understand one another. With AI-assisted programming we should get better tools which lets us build more ambitious software. That is certainly true at the level of the individual and without doubt a developer with an agent can change a codebase dramatically quicker. But large software projects have never been limited only by how quickly an individual can produce code but they are limited by how well people can coordinate their understanding of the system they are changing. The shared language of a software project is the common understanding shared among its developers. This language is rarely written down in one place but it lives in documentation and code. It can also just be something that comes up in code review or watercooler conversations or when one engineer has to explain a change to someone else. It can be about the architecture ## Newer Claude Models Produce Invalid Fields in Pi Edit Tool Calls DevFeed: [Newer Claude Models Produce Invalid Fields in Pi Edit Tool Calls]() Original publisher: [Read original article]() Author: Armin Ronacher Published: 2026-07-04T00:00:00Z Content type: opinion Language: en Sources: [Armin Ronacher]() Topics: [Claude](), [anthropic](), [Large Language Model](), [API](), [JSON]() Tags: [ai](), [anthropic](), [api](), [claude](), [llm](), [payload](), [pi]() ### AI overview The article examines a Pi issue in which newer Claude models, including Opus 4.8 and Sonnet 5, sometimes add invented fields to the nested edits[] array when calling a file-editing tool. The resulting arguments fail schema validation even when the edit itself is usually correct. It also explains how tool calls are represented and validated as text-based structured payloads. ### Source excerpt A very strange Pi issue sent me down a rabbit hole over the last two days. The short version is that newer Claude models sometimes call Pi's edit tool with extra, invented fields in the nested edits[] array. And not Haiku or some small model: Opus 4.8. The edit itself is usually correct but the arguments do not match the schema as the model invents made-up keys and Pi thus rejects the tool call and asks to try again. That alone is not too surprising as models emit malformed tool calls sometimes. Particularly small ones. What surprised me is that this is getting worse with newer Anthropic models as both Opus 4.8 and Sonnet 5 show it but none of the older models. In other words, the SOTA models of the family are worse at this specific tool schema than their older siblings. In case you are curious about Fable: I intentionally did not test it because I was not sure if the classifiers they are running might downgrade me to Opus silently. Tool Calls Are Text If you have not spent too much time looking at LLM tool calling internals, the important thing to understand is that tool calls are not magic and use some rather crude in-band signalling. The model receives a transcript, a system prompt and a list of available tools. The server munches that into a large prompt with special marker tokens. Because the model was trained and reinforced on examples of that format, at some point during generation it emits something that the API or client interprets as "call this tool with these arguments". For a file edit tool, the intended invocation payload might say something like this: { "path": "some/file.py", "edits": [ { "oldText": "text to replace", "newText": "replacement text" } ] } A harness then validates the arguments, performs the edit, and feeds the result back into the model. If validation fails, the model sees an error and usually tries again. How exactly that formatting happens is not known for the Anthropic models, but some people have gotten out "ANTML" markers and they