Martin Fowler Today

Fragments: March 10

Tech firm fined $1.1m by California for selling high-school students’ data I agree with Brian Marick’s response No such story should be published without a comparison of the fine to the company’s previous year revenue and profits, or valuation of last funding round. (I could only find a valuation of $11.0M in 2017.) We desperately need corporations’ attitudes to shift from “lawbreaking is a low-risk cost of doing business; we get a net profit anyway” to “this could be a death sentence.” ❄                ❄                ❄                ❄                ❄ Charity Majors gave the closing keynote at SRECon last year, encouraging people to engage with generative AI. If I was giving the keynote at SRECon 2026, I would ditch the begrudging stance. I would start by acknowledging that AI is radically changing the way we build software. It’s here, it’s happening, and it is coming for us all. Her agenda this year would be to tell everyone that they mustn’t wait for the wave to crash on them, but to swim out to meet it. In particular, I appreciated her call to resist our confirmation bias: The best advice I can give anyone is: know your nature, and lean against it. ❄                ❄                ❄                ❄                ❄ In a comment to Kief Morris’s recent article on Humans and Agents in Software Loops , in LinkedIn comments Renaud Wilsius may have coined another bit of terminology for the agent+programmer age This completes the story of productivity, but it opens a new chapter on talent: The Apprentice Gap. If we move humans ‘on the loop’ too early in their careers, we risk a future where no one understands the ‘How’ deeply enough to build a robust harness. To manage the flywheel effectively, you still need the intuition that comes from having once been ‘in the loop.’ The next great challenge for CTOs isn’t just Harness Engineering, it’s ‘Experience Engineering’ for our junior developers in an agentic world. ❄                ❄                ❄                ❄                ❄ In hearing conversations about “the ralph loop”, I often hear it in the sense of just letting the agents loose to run on their own. So it’s interesting to read the originator of the ralph loop point out: It’s important to watch the loop as that is where your personal development and learning will come from. When you see a failure domain – put on your engineering hat and resolve the problem so it never happens again. In practice this means doing the loop manually via prompting or via automation with a pause that involves having to prcss CTRL+C to progress onto the next task. This is still ralphing as ralph is about getting the most out how the underlying models work through context engineering and that pattern is GENERIC and can be used for ALL TASKS. At the Thoughtworks Future of Software Development Retreat we were very concerned about cognitive debt. Watching the loop during ralphing is a way to learn about what the agent is building, so that it can be directed effectively in the future. ❄                ❄                ❄                ❄                ❄ Anthropic recently published a page on how AI helps break the cost barrier to COBOL modernization . Using AI to help migrate COBOL systems isn’t an new idea to my colleagues, who shared their experiences using AI for this task over a year ago. While Anthropic’s article is correct about the value of AI, there’s more to the process than throwing some COBOL at an LLM. The assumption that AI can simply translate COBOL into Java treats modernization as a syntactic exercise, as though a system is nothing more than its source code. That premise is flawed. A direct translation would, in the best case scenario, faithfully reproduce existing architectural constraints, accumulated technical debt and outdated design decisions. It wouldn’t address weaknesses; it would restate them in a different language. In practice, modernization is rarely about preserving the past in a new syntax. It’s about aligning systems with current market demands, infrastructure paradigms, software supply chains and operating models. Even if AI were eventually capable of highly reliable code translation, blind conversion would risk recreating the same system with the same limitations, in another language, without a deliberate strategy for replacing or retiring its legacy ecosystem. ❄                ❄                ❄                ❄                ❄ Anders Hoff (inconvergent) an LLM is a compiler in the same way that a slot machine is an ATM ❄                ❄                ❄                ❄                ❄ One of the more interesting aspects of the network of people around Jeffrey Epstein is how many people from academia were connected. It’s understandable why, he had a lot of money to offer, and most academics are always looking for funding for their work. Most of the attention on Epstein’s network focused on those that got involved with him, but I’m interested in those who kept their distance and why - so I enjoyed Jeffrey Mervis’s article in Science Many of the scientists Epstein courted were already well-established and well-funded. So why didn’t they all just say no? Science talked with three who did just that. Here’s how Epstein approached them, and why they refused to have anything to do with him. I believe that keeping away from bad people makes life much more pleasant, if nothing else it reduces a lot of stress. So it’s good to understand how people make decisions on who to avoid. If you are a reflexive naysayer or a pessimist, know that, and force yourself to find a way in to wonder, surprise and delight. If you are an optimist who gets very excited and tends to assume that everything will improve: know that, and force yourself to mind real cautionary tales.

Java AI

David Bushell Today

Building on AT Protocol

At Protocol has got me! I’m morphing into an atmosphere nerd . AT Protocol — atproto for short — is the underlying tech that powers Bluesky and new social web apps. Atproto as I understand it is largely an authorization and data layer. All atproto data is inherently public. In theory it can be encrypted for private use but leaky metadata and de-anonymisation is a whole thing. Atproto users own the keys to their data which is stored on a Personal Data Server (PDS). You don’t need to manage your own. If you don’t know where your data is stored, good chance it’s on Bluesky’s PDS. You can move your data to another PDS like Blacksky or Eurosky . Or if you’re a nerd like me self-host your own PDS . You own your data and no PDS can stop you moving it. Atproto provides OAuth; think “Sign in with GitHub” . But instead of an account being locked behind the whims of proprietary slopware, user identity is proven via their PDS. Social apps like Bluesky host a PDS allowing users to create a new account. That account can be used to login to other apps like pckt , Leaflet , or Tangled . You could start a new account on Tangled’s PDS and use that for Bluesky. Atproto apps are not required to provide a PDS but it helps to onboard new users. Of course I did. You can sign in at attic.social Attic is a cozy space with lofty ambitions. What does Attic do? I’m still deciding… it’ll probably become a random assortment of features. Right now it has bookmarks. Bookmarks will have search and tags soon. Technical details: to keep the server stateless I borrowed ideas from my old SvelteKit auth experiment. OAuth and session state is stored in encrypted HTTP-only cookies. I used the atcute TypeScript libraries to do the heavy atproto work. I found @flo-bit’s projects which helped me understand implementation details. Attic is on Cloudflare workers for now. When I’ve free time I’ll explore the SvelteKit Bunny adapter . I am busy on client projects so I’ll be scheming Attic ideas in my free time. What’s so powerful about atproto is that users can move their account/data. Apps write data to a PDS using a lexicon ; a convention to say: “this is a Bluesky post”, for example. Other apps are free to read that data too. During authorization, apps must ask for permission to write to specific lexicons. The user is in control. You may have heard that Bluesky is or isn’t “decentralised”. Bluesky was simply the first atproto app. Most users start on Bluesky and may never be aware of the AT Protocol. What’s important is that atproto makes it difficult for Bluesky to “pull a Twitter”, i.e. kill 3rd party apps, such as the alternate Witchsky . If I ever abandon attic.social your data is still in your hands. Even if the domain expires! You can extract data from your PDS. You can write a new app to consume it anytime. That’s the power of AT Protocol. Thanks for reading! Follow me on Mastodon and Bluesky . Subscribe to my Blog and Notes or Combined feeds.

TypeScript Web Development Open Source

Entropic Thoughts Today

Rebasing in Magit

Git Tutorial

A Room of My Own Today

What My 2025 Journal Taught Me

Last week I exported my entire Day One journal for 2025 (just the text file) and ran it through ChatGPT, mostly out of curiosity. None of the conclusions were surprising and I could have (and probably did) come to most of them myself. However, it was nice seeing them written out clearly. It was also nice being able to ask follow-up questions, dig a bit deeper into the patterns, and even read some of the insights out loud to my husband. But seeing it all laid out clearly made a few lessons impossible to ignore. When I looked at the entries where I sounded the most content, they all had the same ingredients. Just simple things: swimming in the sea sitting on the beach walking outside quiet mornings with coffee time with my children small family adventures or road trips Those entries have a noticeably calmer tone (according to ChatGPT). It’s a good reminder that the things that regulate me best are actually low-stimulus and simple . Just being outside and present. Another pattern that appeared again and again in my journal: frustration with complexity and that is small, everyday complexity: organising systems digital tools social expectations managing other people’s behaviour I often catch myself mid-entry realising I’m spending time optimising systems instead of actually living (which i discover over and over, in my journaling and on this blog) It’s funny because my brain loves building systems (just look at these entries). But my journal makes it clear they don’t actually make me happier. RELATED:   The Cost of Organizing Ideas – But I Keep Doing It Anyway One theme runs through almost the entire year: awareness of time passing. I write about: my son growing up noticing my daughter becoming her own person reflections on aging wanting to live more fully frustration about wasting time More than anything, 2025 feels like a year where I started asking myself (although probably not just 2025 and what am I going to do about it): Am I actually living the life I want, or just organising it? RELATED: The Art of Organizing (Things That Don’t Need to Be Organized) If there is one clear emotional anchor in my journal, it’s my relationship with my children. Many of the most meaningful entries revolve around them: teaching them how to swim in open water lunch dates with one or both of them watching them grow more independent their humour and imagination small family moments Even tiny everyday experiences become meaningful when I write about them. Reading the year back made me realise that parenthood isn’t just part of my life - it’s the emotional core of it. Another thing that stood out: my tone changes when I travel. Camping trips. Road trips. Travelling back to my home country Visiting other countries During those entries I sound more reflective, more observant, and more alive. Again, duh! My journal also shows a constant push and pull between two sides of myself. One side is the project manager (at home and at work) : organisation productivity digital structure The other side is the observer and writer : noticing small moments reflecting on life When the organisational side takes over too much, I start to feel off balance. My happiest entries happen when structure supports reflection, not when structure replaces it. One of the clearest patterns in the entire journal actually surprised me. The strongest predictor of whether my day felt good or bad wasn’t work, productivity, or even journaling. It was movement. Especially walking. On days where I walk, swim, or do yoga, the tone of the entry is noticeably calmer and clearer (again, according to ChatGPT) On days where I stay indoors on the computer (especially if I end up working from home), I’m far more likely to spiral into overthinking. Even better is when three things happen together: movement (walking/yoga) being outside low pressure (no digital tasks) When those align, everything seems to reset. Looking across all the entries, one theme keeps appearing. The life I seem to want most is actually very simple. It looks something like this: quiet mornings with coffee and reading daily movement outside meaningful work, but not obsessive productivity small adventures with the kids travel (and this includes locally) when possible writing as a natural outlet And I didn’t need ChatGPT to tell me this, though. I already know it, and yet I keep creating complexity (wanting to control) where my life clearly works better with simplicity (letting go of control). So  summed up, the lesson of 2025 is this: Not how to improve my systems. But how to protect the breathing room that makes life feel like living. I only have to make sure I do. The Journal Project I Can’t Quit The Art of Organizing (Things That Don’t Need to Be Organized) Do Fewer Things, Do Them Well The Cost of Organizing Ideas – But I Keep Doing It Anyway A Journey Through Journaling, Tracking and Memories with Day One Committing to the Thinking Life swimming in the sea sitting on the beach walking outside quiet mornings with coffee time with my children small family adventures or road trips organising systems digital tools social expectations managing other people’s behaviour my son growing up noticing my daughter becoming her own person reflections on aging wanting to live more fully frustration about wasting time teaching them how to swim in open water lunch dates with one or both of them watching them grow more independent their humour and imagination small family moments organisation productivity digital structure noticing small moments reflecting on life movement (walking/yoga) being outside low pressure (no digital tasks) quiet mornings with coffee and reading daily movement outside meaningful work, but not obsessive productivity small adventures with the kids travel (and this includes locally) when possible writing as a natural outlet

Writing

Manuel Moreale Yesterday

Step aside, phone: closing thoughts

Four full weeks of paying more attention to phone screen time are behind us, and it’s time for some closing thoughts on this experiment. But first, a quick recap of how the final week went. The average was slightly higher than the previous 3 weeks, and that was mainly due to what happened on Tuesday and Friday, which, as you can see from the weekly recap, saw higher-than-usual phone usage. On Tuesday, I passed 1 hour of screen time for the first time since the start of this experiment, and that was because of a…phone call? I’m not entirely sure why screen time registers a phone call as screen time, but that's why I passed the 1-hour mark on Tuesday. I had a 30-minute phone call for something work-related, and that apparently is picked up as screen time. Go figure. Aside from that, as you can see, usage was business as usual: about half an hour of messaging and a minute here and there for a few extra things. Friday, I passed the 1-hour mark again, and this time it was actual usage, and it was just Telegram. As you can see from the time distribution, I spent almost 40 minutes chatting with a few people late in the day and aside from Telegram, I barely picked up my phone. The rest of the week was very uneventful. Looking back at these past 4 weeks, I feel like, for me, the way my life is structured at this moment, 4 hours of weekly phone usage is the sweet spot, and I intend to keep it that way. I’m happy I managed not to consume content on my phone. Podcasts, music and RSS are gone from the site, and I feel like my relationship with this stupid object is in a much better place. I have deeper thoughts I want to share, but those will get their own dedicated post, likely tomorrow. How about the others, though? I started this thing to help Kevin get off his phone, and I succeeded so well that he jumped off iOS entirely and moved to Android. Not exactly the outcome we wanted, but hey, at least it's a change. He'll be back using his phone 5 hours a day now that nobody is paying attention. Kev instead is too busy vibe-coding blog platforms to pay attention to his phone, and he abandoned us after one week. As for John, Thomas, and Alex, they all did great, I'd say, and I love that Thomas tracked time spent in front of his computer and not just the phone. Thank you for keeping RSS alive. You're awesome. Email me :: Sign my guestbook :: Support for 1$/month :: See my generous supporters :: Subscribe to People and Blogs Read Kevin's week four recap Read Thomas' week four recap Read John's week four recap Read Alex's week three recaps

Culture Mobile

Simon Willison Yesterday

Perhaps not Boring Technology after all

A recurring concern I've seen regarding LLMs for programming is that they will push our technology choices towards the tools that are best represented in their training data, making it harder for new, better tools to break through the noise. This was certainly the case a couple of years ago, when asking models for help with Python or JavaScript appeared to give much better results than questions about less widely used languages. With the latest models running in good coding agent harnesses I'm not sure this continues to hold up. I'm seeing excellent results with my brand new tools where I start by prompting "use uvx showboat --help / rodney --help / chartroom --help to learn about these tools" - the context length of these new models is long enough that they can consume quite a lot of documentation before they start working on a problem. Drop a coding agent into any existing codebase that uses libraries and tools that are too private or too new to feature in the training data and my experience is that it works just fine - the agent will consult enough of the existing examples to understand patterns, then iterate and test its own output to fill in the gaps. This is a surprising result. I thought coding agents would prove to be the ultimate embodiment of the Choose Boring Technology approach, but in practice they don't seem to be affecting my technology choices in that way at all. Update : A few follow-on thoughts: You are only seeing the long-form articles from my blog. Subscribe to /atom/everything/ to get all of my posts, or take a look at my other subscription options . The issue of what technology LLMs recommend is a separate one. What Claude Code Actually Chooses is an interesting recent study where Edwin Ong and Alex Vikati where they proved Claude Code over 2,000 times and found a strong bias towards build-over-buy but also identified a preferred technical stack, with GitHub Actions, Stripe, and shadcn/ui seeing a "near monopoly" in their respective categories. For the sake of this post my interest is in what happens when the human makes a technology choice that differs from those preferred by the model harness. The Skills mechanism that is being rapidly embraced by most coding agent tools is super-relevant here. We are already seeing projects release official skills to help agents use them - here are examples from Remotion , Supabase , Vercel , and Prisma .

Programming AI JavaScript Python

iDiallo Yesterday

Why Am I Paranoid, You Say?

Technology has advanced to a point I could only have dreamed of as a child. Have you seen the graphics in video games lately? Zero to 60 miles per hour in under two seconds? Communicating with anyone around the world at the touch of a button? It's incredible, to say the least. But every time I grab the TV remote and decline the terms of service, my family watches in confusion. I don't usually have the words to explain my paranoia to them, but let me try. I would love to have all the features enabled on all my devices. I would love to have Siri on my phone. I would love to have Alexa control the lighting in my house and play music on command. I would love to own an electric car with over-the-air updates. I would love to log in with my Google account everywhere. I would love to sign up for your newsletter. I would love to try the free trial. I would love to load all my credit cards onto my phone. I would love all of that. But I can't. I don't get to do these things because I have control over none of them. When I was a kid, I imagined that behind the wild technologies of the future there would be software and hardware, pure and simple. Now that we have the tech, I can say that what I failed to see was that behind every product, there is a company. And these companies are salivating for data. If you're like me, you have dozens of apps on your phone. You can't fit them all on the home screen, so you use a launcher to find the ones you don't open every day. Sometimes, because I have so many, I scroll up and down and still can't find what I'm looking for. Luckily, on most Android phones, there's a search bar at the top to help. But the moment I tap it, a notification pops up asking me to agree to terms and conditions just to use the search. Of course I won't do that. Most people have Siri enabled on their iPhone and never think twice about it. Apple has run several ads touting its privacy-first approach. Yet Apple settled a class action lawsuit last year claiming that Siri had violated users' privacy, to the tune of $95 million . I can't trust any of these companies with my information. They will lose it, or they will sell it. Using Alexa or Google Assistant is no different from using Siri. It's having a microphone in your home that's controlled by a third party. As enthusiastic as I am about electric cars, I didn't see the always-connected aspect coming. I've always assumed that when I pay for something, it belongs to me. But when an automaker can make decisions about your car while it sits in your garage, I'd rather have a dumb car. Unfortunately, it's no longer limited to electric vehicles. Nearly all modern cars now push some form of subscription service on their customers. Have you ever been locked out of your Google account? One day I picked up my phone and, for some reason, my location was set to Vietnam. A few minutes later, I lost access to my Google account. It's one thing to lose access to your email or files in Drive. But when you've used Google to log in to other websites, you're suddenly locked out of those too. Effectively, you're locked out of the internet. I was lucky my account was restored the same day, apparently there were several login attempts from Vietnam. But my account was back in service just in time for me to mark another Stack Overflow question as a duplicate. I don't sign up for services with my real email just to try a free trial, because even when I decide not to continue, the emails keep coming. When my sons were just a few months old, I received a letter in the mail addressed to the baby. It stated that his personal information (name, address, and Social Security number) had been breached. He was still an infant. I had never heard of the company responsible or done any business with them, yet somehow they had managed to lose my child's information. I would love to not worry about any of this, but it's a constant inconvenience. Whenever I grab the TV remote, I accidentally hit the voice button, and the terms of service remind me that my voice may be shared with third parties . Technology is amazing when you have some control over it. But when the terms of service can change out from under you without warning, I'll politely decline and keep my tin hat close by. I have so much to hide .

Security Data

Stratechery Yesterday

MacBook Neo, The (Not-So) Thin MacBook, Apple and Memory

The MacBook Neo was built to be cheap; that it is still good is not only a testament to Apple Silicon, but also the fact that the most important software runs in the cloud.

Cloud Hardware

ava's blog Yesterday

yesterday, in my body

If you are a generally healthy person, it can be hard to conceptualize how quickly someone's illnesses can suddenly turn within a few hours, so here is an example from yesterday to illustrate it. My wife and I had made plans to go a tabletop/board game flea market at noon and then head over to a restaurant afterwards. I had slept well, I had a bit of breakfast, I put effort into my looks, I had no pain or other issues, everything was generally fine. My Crohn's disease had acted up here and there in the days prior, but no signs of that yesterday. On the way there, everything was fine. I had forgotten my noise-cancelling headphones at home, but the tram was surprisingly pleasant and manageable without it. I noticed I wasn't able to comfortably stand as long as I had now gotten used to (lower back pain from Bechterew's disease etc.), but I blamed it on being more sedentary recently. The flea market was so full, I only quickly walked through and then waited at the emptier entrance the rest of the time. At the restaurant, I tried a Vietnamese Iced Coffee for the first time, and oh boy... the restaurant really put some extra effort into that! It was very bitter and the coconut cream they included was extra, sickeningly, sweet to make up for it. Since my month without caffeine, I had gotten extra sensitive to caffeine again, and I tend to react badly to lots of sugar, so I expected some negative consequences, but it was tasty. On the way home, I start feeling extremely anxious due to the caffeine. I'm overwhelmed and extra sensitive, every noise and smell is too strong, I feel deeply uncomfortable in my body and just want to run away. I can't at least take away the sound element, because again, I had left the noise-cancelling headphones at home; deep regret at that point. When we make it home, I immediately free myself from everything that isn't necessary or comfortable and lie down in bed. I don't wanna be touched, and I don't want to talk, and if I have to talk, I whisper. Every sound feels like nails on a chalkboard, and every touch burns like lava. After some hours, I recover. I make some dinner with leftovers, and afterwards, decide I should work out at least a bit, as I feel okay again. A few minutes on my indoor cycle, and my body just feels off. I feel weak, but not the kind of weak you feel when you just need to eat or drink something. I start to feel really fatigued from the simplest and easiest movement, and I check my pulse on my watch. There it is, my best indicator that inflammation is currently high in my body: Unusually high bpm for what I do. I was rather slow pedaling without much resistance, and I was already at 122bpm when usually, I'd be at 104-110 max for this warmup/difficulty. Damn. I try to at least finish with very light, easy cycling, but I have to stop entirely. This kind of fatigue feels like you're forced to walk in slow motion, like a dream, or like underwater; everything feels like it has a weird, invisible resistance, and your limbs are so heavy. I try if I can at least do some stretching and crunches on my yoga mat, and that's easier. I still feel weird and fragile, but it's manageable. When I stop, the fatigue hits me like a brick wall. I only have energy to change clothes and collapse onto the sofa. That's where my usual "my autoimmune disorders are acting up" routine starts; I can barely manage anything. I don't really want to move, especially not my arms. I can barely find the words or express myself due to massive brain fog. I feel like I am a tiny ball living in my chest cavity, stuck in a huge meat mech. When it gets bad, I can no longer even handle looking at my phone, I can just lie there and focus on my breathing. That usually goes hand in hand with some general pain and discomfort that's hard to localize and feels like a huge cloud surrounding me, and I ask my wife for my pain/anti-inflammation meds, because otherwise I just start writhing around groaning all the time. I also fall asleep on the sofa, only going to bed some unknown time later (probably close to midnight?). It's the next morning now, and I still feel a little off, but mostly fine, and I'll be taking it slow with my body today; no exercise, no going outside, and lots of rest, though I am working from home, and I have to study a bit for my exam tomorrow! Wish me luck. Unfortunately, it's no coincidence this stuff mostly happens around stress points like exams, and I'm sure the sugar and caffeine didn't help... 😐 Reply via email Published 09 Mar, 2026

Personal Experience Health Programming

(think) Yesterday

Emacs and Vim in the Age of AI

It’s tough to make predictions, especially about the future. – Yogi Berra I’ve been an Emacs fanatic for over 20 years. I’ve built and maintained some of the most popular Emacs packages, contributed to Emacs itself, and spent countless hours tweaking my configuration. Emacs isn’t just my editor – it’s my passion, and my happy place. Over the past year I’ve also been spending a lot of time with Vim and Neovim, relearning them from scratch and having a blast contrasting how the two communities approach similar problems. It’s been a fun and refreshing experience. 1 And lately, like everyone else in our industry, I’ve been playing with AI tools – Claude Code in particular – watching the impact of AI on the broader programming landscape, and pondering what it all means for the future of programming. Naturally, I keep coming back to the same question: what happens to my beloved Emacs and its “arch nemesis” Vim in this brave new world? I think the answer is more nuanced than either “they’re doomed” or “nothing changes”. Predicting the future is obviously hard work, but it’s so fun to speculate on it. My reasoning is that every major industry shift presents plenty of risks and opportunities for those involved in it, so I want to spend a bit of time ruminating over the risks and opportunities for Emacs and Vim. VS Code is already the dominant editor by a wide margin, and it’s going to get first-class integrations with every major AI tool – Copilot (obviously), Codex, Claude, Gemini, you name it. Microsoft has every incentive to make VS Code the best possible host for AI-assisted development, and the resources to do it. On top of that, purpose-built AI editors like Cursor , Windsurf , and others are attracting serious investment and talent. These aren’t adding AI to an existing editor as an afterthought – they’re building the entire experience around AI workflows. They offer integrated context management, inline diffs, multi-file editing, and agent loops that feel native rather than bolted on. Every developer who switches to one of these tools is a developer who isn’t learning Emacs or Vim keybindings, isn’t writing Elisp, and isn’t contributing to our ecosystems. The gravity well is real. I never tried Cursor and Windsurf simply because they are essentially forks of VS Code and I can’t stand VS Code. I tried it several times over the years and I never felt productive in it for a variety of reasons. Part of the case for Emacs and Vim has always been that they make you faster at writing and editing code. The keybindings, the macros, the extensibility – all of it is in service of making the human more efficient at the mechanical act of coding. But if AI is writing most of your code, how much does mechanical editing speed matter? When you’re reviewing and steering AI-generated diffs rather than typing code character by character, the bottleneck shifts from “how fast can I edit” to “how well can I specify intent and evaluate output.” That’s a fundamentally different skill, and it’s not clear that Emacs or Vim have an inherent advantage there. The learning curve argument gets harder to justify too. “Spend six months learning Emacs and you’ll be 10x faster” is a tough sell when a junior developer with Cursor can scaffold an entire application in an afternoon. 2 VS Code has Microsoft. Cursor has venture capital. Emacs has… a small group of volunteers and the FSF. Vim had Bram, and now has a community of maintainers. Neovim has a small but dedicated core team. This has always been the case, of course, but AI amplifies the gap. Building deep AI integrations requires keeping up with fast-moving APIs, models, and paradigms. Well-funded teams can dedicate engineers to this full-time. Volunteer-driven projects move at the pace of people’s spare time and enthusiasm. Let’s go all the way: what if programming as we know it is fully automated within the next decade? If AI agents can take a specification and produce working, tested, deployed software without human intervention, we won’t need coding editors at all. Not Emacs, not Vim, not VS Code, not Cursor. The entire category becomes irrelevant. I don’t think this is likely in the near term, but it’s worth acknowledging as a possibility. The trajectory of AI capabilities has surprised even the optimists (and I was initially an AI skeptic, but the rapid advancements last year eventually changed my mind). Here’s the thing almost nobody is talking about: Emacs and Vim have always suffered from the obscurity of their extension languages. Emacs Lisp is a 1980s Lisp dialect that most programmers have never seen before. VimScript is… VimScript. Even Lua, which Neovim adopted specifically because it’s more approachable, is niche enough that most developers haven’t written a line of it. This has been the single biggest bottleneck for both ecosystems. Not the editors themselves – they’re incredibly powerful – but the fact that customizing them requires learning an unfamiliar language, and most people never make it past copying snippets from blog posts and READMEs. I felt incredibly overwhelmed by Elisp and VimScript when I was learning Emacs and Vim for the first time, and I imagine I wasn’t the only one. I started to feel very productive in Emacs only after putting in quite a lot of time to actually learn Elisp properly. (never bothered to do the same for VimScript, though, and admittedly I’m not too eager to master Lua either) AI changes this overnight. You can now describe what you want in plain English and get working Elisp, VimScript, or Lua. “Write me an Emacs function that reformats the current paragraph to 72 columns and adds a prefix” – done. “Configure lazy.nvim to set up LSP with these keybindings” – done. The extension language barrier, which has been the biggest obstacle to adoption for decades, is suddenly much lower. After 20+ years in the Emacs community, I often have the feeling that a relatively small group – maybe 50 to 100 people – is driving most of the meaningful progress. The same names show up in MELPA, on the mailing lists, and in bug reports. This isn’t a criticism of those people (I’m proud to be among them), but it’s a structural weakness. A community that depends on so few contributors is fragile. And it’s not just Elisp and VimScript. The C internals of both Emacs and Vim (and Neovim’s C core) are maintained by an even smaller group. Finding people who are both willing and able to hack on decades-old C codebases is genuinely hard, and it’s only getting harder as fewer developers learn C at all. AI tools can help here in two ways. First, they lower the barrier for new contributors – someone who understands the concept of what they want to build can now get AI assistance with the implementation in an unfamiliar language. Second, they help existing maintainers move faster. I’ve personally found that AI is excellent at generating test scaffolding, writing documentation, and handling the tedious parts of package maintenance that slow everything down. The Emacs and Neovim communities aren’t sitting idle. There are already impressive AI integrations: And this is just a sample. Building these integrations isn’t as hard as it might seem – the APIs are straightforward, and the extensibility of both editors means you can wire up AI tools in ways that feel native. With AI assistance, creating new integrations becomes even easier. I wouldn’t be surprised if the pace of plugin development accelerates significantly. Here’s an irony that deserves more attention: many of the most powerful AI coding tools are terminal-native. Claude Code, Aider, and various Copilot CLI tools all run in the terminal. And what lives in the terminal? Emacs and Vim. 3 Running Claude Code in an Emacs buffer or a Neovim terminal split is a perfectly natural workflow. You get the AI agent in one pane and your editor in another, with all your keybindings and tools intact. There’s no context switching to a different application – it’s all in the same environment. This is actually an advantage over GUI-based AI editors, where the AI integration is tightly coupled to the editor’s own interface. With terminal-native tools, you get to choose your own editor and your own AI tool, and they compose naturally. Emacs’s “editor as operating system” philosophy is uniquely well-suited to AI integration. It’s not just a code editor – it’s a mail client (Gnus, mu4e), a note-taking system (Org mode), a Git interface (Magit), a terminal emulator, a file manager, an RSS reader, and much more. AI can be integrated at every one of these layers. Imagine an AI assistant that can read your org-mode agenda, draft email replies in mu4e, help you write commit messages in Magit, and refactor code in your source buffers – all within the same environment, sharing context. No other editor architecture makes this kind of deep, cross-domain integration as natural as Emacs does. Admittedly, I’ve stopped using Emacs as my OS a long time ago, and these days I use it mostly for programming and blogging. (I’m writing this article in Emacs with the help of ) Still, I’m only one Emacs user and many are probably using it in a more holistic manner. One of the most underappreciated benefits of AI for Emacs and Vim users is mundane: troubleshooting. Both editors have notoriously steep learning curves and opaque error messages. “Wrong type argument: stringp, nil” has driven more people away from Emacs than any competitor ever did. AI tools are remarkably good at explaining cryptic error messages, diagnosing configuration issues, and suggesting fixes. They can read your init file and spot the problem. They can explain what a piece of Elisp does. They can help you understand why your keybinding isn’t working. This dramatically flattens the learning curve – not by making the editor simpler, but by giving every user access to a patient, knowledgeable guide. I don’t really need any AI assistance to troubleshoot anything in my Emacs setup, but it’s been handy occasionally in Neovim-land, where my knowledge is relatively modest by comparison. There’s at least one documented case of someone returning to Emacs after years away , specifically because Claude Code made it painless to fix configuration issues. They’d left for IntelliJ because the configuration burden got too annoying – and came back once AI removed that barrier. “Happy f*cking days I’m home again,” as they put it. If AI can bring back lapsed Emacs users, that’s a good thing in my book. Let’s revisit the doomsday scenario. Say programming is fully automated and nobody writes code anymore. Does Emacs die? Not necessarily. Emacs is already used for far more than programming. People use Org mode to manage their entire lives – tasks, notes, calendars, journals, time tracking, even academic papers. Emacs is a capable writing environment for prose, with excellent support for LaTeX, Markdown, AsciiDoc, and plain text. You can read email, browse the web, manage files, and yes, play Tetris. Vim, similarly, is a text editing paradigm as much as a program. Vim keybindings have colonized every text input in the computing world – VS Code, IntelliJ, browsers, shells, even Emacs (via Evil mode). Even if the Vim program fades, the Vim idea is immortal. 4 And who knows – maybe there’ll be a market for artisanal, hand-crafted software one day. “Locally sourced, free-range code, written by a human in Emacs.” I’d buy that t-shirt. And I’m fairly certain those artisan programmers won’t be using VS Code. So even in the most extreme scenario, both editors have a life beyond code. A diminished one, perhaps, but a life nonetheless. I think what’s actually happening is more interesting than “editors die” or “editors are fine.” The role of the editor is shifting. For decades, the editor was where you wrote code. Increasingly, it’s becoming where you review, steer, and refine code that AI writes. The skills that matter are shifting from typing speed and editing gymnastics to specification clarity, code reading, and architectural judgment. In this world, the editor that wins isn’t the one with the best code completion – it’s the one that gives you the most control over your workflow. And that has always been Emacs and Vim’s core value proposition. The question is whether the communities can adapt fast enough. The tools are there. The architecture is there. The philosophy is right. What’s needed is people – more contributors, more plugin authors, more documentation writers, more voices in the conversation. AI can help bridge the gap, but it can’t replace genuine community engagement. Not everyone in the Emacs and Vim communities is enthusiastic about AI, and the objections go beyond mere technophobia. There are legitimate ethical concerns that are going to be debated for a long time: Energy consumption. Training and running large language models requires enormous amounts of compute and electricity. For communities that have long valued efficiency and minimalism – Emacs users who pride themselves on running a 40-year-old editor, Vim users who boast about their sub-second startup times – the environmental cost of AI is hard to ignore. Copyright and training data. LLMs are trained on vast corpora of code and text, and the legality and ethics of that training remain contested. Some developers are uncomfortable using tools that may have learned from copyrighted code without explicit consent. This concern hits close to home for open-source communities that care deeply about licensing. Job displacement. If AI makes developers significantly more productive, fewer developers might be needed. This is an uncomfortable thought for any programming community, and it’s especially pointed for editors whose identity is built around empowering human programmers. These concerns are already producing concrete action. The Vim community recently saw the creation of EVi , a fork of Vim whose entire raison d’etre is to provide a text editor free from AI integration. Whether you agree with the premise or not, the fact that people are forking established editors over this tells you how strongly some community members feel. I don’t think these concerns should stop anyone from exploring AI tools, but they’re real and worth taking seriously. I expect to see plenty of spirited debate about this on emacs-devel and the Neovim issue tracker in the years ahead. The future ain’t what it used to be. – Yogi Berra I won’t pretend I’m not worried. The AI wave is moving fast, the incumbents have massive advantages in funding and mindshare, and the very nature of programming is shifting under our feet. It’s entirely possible that Emacs and Vim will gradually fade into niche obscurity, used only by a handful of diehards who refuse to move on. But I’ve been hearing that Emacs is dying for 20 years, and it’s still here. The community is small but passionate, the editor is more capable than ever, and the architecture is genuinely well-suited to the AI era. Vim’s situation is similar – the core idea is so powerful that it keeps finding new expression (Neovim being the latest and most vigorous incarnation). The editors that survive won’t be the ones with the flashiest AI features. They’ll be the ones whose users care enough to keep building, adapting, and sharing. That’s always been the real engine of open-source software, and no amount of AI changes that. So if you’re an Emacs or Vim user: don’t panic, but don’t be complacent either. Learn the new AI tools (if you’re not fundamentally opposed to them, that is). Pimp your setup and make it awesome. Write about your workflows. Help newcomers. The best way to ensure your editor survives the AI age is to make it thrive in it. Maybe the future ain’t what it used to be – but that’s not necessarily a bad thing. That’s all I have for you today. Keep hacking! If you’re curious about my Vim adventures, I wrote about them in Learning Vim in 3 Steps .  ↩︎ Not to mention you’ll probably have to put in several years in Emacs before you’re actually more productive than you were with your old editor/IDE of choice.  ↩︎ At least some of the time. Admittedly I usually use Emacs in GUI mode, but I always use (Neo)vim in the terminal.  ↩︎ Even Claude Code has vim mode.  ↩︎ gptel – a versatile LLM client that supports multiple backends (Claude, GPT, Gemini, local models) ellama – an Emacs interface for interacting with LLMs via llama.cpp and Ollama aider.el – Emacs integration for Aider , the popular AI pair programming tool copilot.el – GitHub Copilot integration (I happen to be the current maintainer of the project) elysium – an AI-powered coding assistant with inline diff application agent-shell – a native Emacs buffer for interacting with LLM agents (Claude Code, Gemini CLI, etc.) via the Agent Client Protocol avante.nvim – a Cursor-like AI coding experience inside Neovim codecompanion.nvim – a Copilot Chat replacement supporting multiple LLM providers copilot.lua – native Copilot integration for Neovim gp.nvim – ChatGPT-like sessions in Neovim with support for multiple providers Energy consumption. Training and running large language models requires enormous amounts of compute and electricity. For communities that have long valued efficiency and minimalism – Emacs users who pride themselves on running a 40-year-old editor, Vim users who boast about their sub-second startup times – the environmental cost of AI is hard to ignore. Copyright and training data. LLMs are trained on vast corpora of code and text, and the legality and ethics of that training remain contested. Some developers are uncomfortable using tools that may have learned from copyrighted code without explicit consent. This concern hits close to home for open-source communities that care deeply about licensing. Job displacement. If AI makes developers significantly more productive, fewer developers might be needed. This is an uncomfortable thought for any programming community, and it’s especially pointed for editors whose identity is built around empowering human programmers. If you’re curious about my Vim adventures, I wrote about them in Learning Vim in 3 Steps .  ↩︎ Not to mention you’ll probably have to put in several years in Emacs before you’re actually more productive than you were with your old editor/IDE of choice.  ↩︎ At least some of the time. Admittedly I usually use Emacs in GUI mode, but I always use (Neo)vim in the terminal.  ↩︎ Even Claude Code has vim mode.  ↩︎

Lua Programming Open Source C++ AI

Rado's Radical Reflections Yesterday

Human Intuition, AI Formalization: A Real Analysis Case Study

Disclaimer - I wrote the core ideas; Claude helped flesh out and polish the article. See appendix for more on this. This is a follow up to my previous post on leaning on Claude for Lean. I’ve now worked up to chapter 8.3 in Tao’s companion. The speed is great and Claude’s capabilities continue to impress (autoformalization is possible, but not my goal). I haven’t been stuck on anything so far. I’ve also upstreamed many typos to the companion repo .

Data Analysis AI

@hannahilea Yesterday

Gaubert or go home: Measuring a flute recital in notes played

Automating symbolic music analysis to answer the pressing question "how many notes did she just play?!"

AI

Hugo Yesterday

Coding 10x faster: what's the real benefit?

I saw a Reddit post the other day: " Developers who save a ton of time thanks to AI: what do you do with it? " (in french) It got me thinking. I have an answer from my own experience, which I'll share with you. But I'm well aware my situation is peculiar. So I decided to dig deeper, and I realized something: the real question isn't whether you're getting faster. It's: what does that actually change for you? Do you work less? More? Differently? What's the impact in a large corporation? What about freelancers? Essentially: ++ if ++ someone gains time, what's it actually worth to them? First, let me be thorough and put things in perspective. A recent study from METR (Model Evaluation & Threat Research) shows that this time gain might not be as straightforward as we think. The study found that experienced developers working on legacy codebases were actually 20% slower with AI, largely due to code review cycles. Take it with a grain of salt—the sample size was only 16 people. And context matters: we're talking about expert developers working on large, complex codebases. I won't dwell on this study because I can find others saying the opposite. But I thought it was intellectually honest to mention it, to balance the narrative and add some perspective. The point isn't to assume that AI definitely makes us faster. I don't want to get into that debate. Instead, let's strip away the AI label entirely and just consider a hypothesis: What if someone could produce code 20-30% faster? Or even 10x faster? What happens then? If software production becomes cheaper, what's the impact on the developer profession? What can you actually do with that gained time? This isn't a silly hypothesis. The profession has changed radically since the days of physically wiring computers to program them. We've constantly improved productivity. And our successors probably won't work the way we do. I'm an outlier, so my answer doesn't apply to most people. I work with one co-founder on a recently launched product. I have no productivity quotas, no salary pressure, no one to report to. I control my own time. If I finish a task in an hour instead of a week, I can just stop working and do something else. I'm not obligated to pad my hours or hit some end-of-day checkpoint. Of course, I still have pressure—the product needs to be good and adopted. I track new users monthly, revenue growth, and customer feedback via email. But for my situation, extra time is genuinely useful. I can spend more time responding to emails thoughtfully. I can do deeper analysis of my market and user feedback. In short, I see it as an opportunity. Before, as a "technical founder," I spent all my time coding and lived heads-down, with no bandwidth to think strategically about the product long-term. Gaining time lets me rebalance. I love coding. But coding was eating up brain cycles I needed for strategy. That's no longer the case. I can spend more time on the "why" instead of just the "how." Time has always been scarce in software and startups. When I gain time, I spend it on other product work: improving user documentation, strengthening test infrastructure to prevent future problems. I tackle bugs I see in the logs, or UI quirks I'd noticed but pushed off indefinitely. You know the feeling—that infinite Jira backlog filled with small improvement tickets. Those famous "we'll do it later" items that exist mostly to make us feel better, or to satisfy the support person who asked about them. "Look, it's on our TODO list. Yeah, it'll take 15 years to get to, but it's there…" That doesn't exist for me anymore. Small issues like that pile up by the dozens, and the product steadily improves. Using the financial analogy of technical debt: once code costs less, you pay down the debt continuously, which reduces the interest burden. Since I spend less time coding, I've had much more time to think deeply about problems. And I've invested in education. Before, time pressure forced shortcuts. Recently, I've documented and written about content moderation on platforms , dug into SSL certificate systems, explored proof-of-work captcha mechanisms, studied purchasing power parity . And here's the surprising part: I've just stepped away from the keyboard. Often in my typical day, I spend time away from the screen. I've improved my broth technique for ramen. I've done home repairs and started building furniture. Paradoxically, that time helps me build better products. Ever notice you solve complex problems in the shower? Letting your mind wander is creative fuel. It took me a while to accept it , but giving your brain rest—letting it incubate ideas and wander while you do something else—is excellent for problem-solving. Of course, I know my situation is specific. I can't imagine starting a woodworking session in the middle of an open office surrounded by developers. But for me, gaining time on code means a holistic rebalancing of my days and, paradoxically, better-quality output. Because it was never just about coding—it was also about thinking long-term, which is easier when you have time for it. Clearly, though, it's different in a more traditional context. So I did some research on what others are saying. One of the first insights comes from a Harvard Business Review study . Increased productivity doesn't lead to reduced working hours—it leads to intensification. Work becomes more intense for several reasons: AI removes cognitive breaks. Since AI makes it faster to start a task, you lose the natural pause that exists at the beginning of each project when you're figuring out the approach. AI blurs job boundaries. You feel capable of doing frontend, design, ops, backend, mobile. Your scope explodes for a single person. Frequent gratification drives endless continuation. If you complete 10 tickets a day and each is quick, why not one more? One quick prompt before closing the laptop? But this intensification comes at a real cost: fatigue, burnout, mistakes (because tired people miss things). I found an article that compares AI to a vampire draining our energy. The idea is simple: since AI handles all the simple, repetitive tasks that used to serve as cognitive breaks, we're left essentially doing high-level work and critical decisions. But humans can't make critical decisions nonstop for 8 hours a day. It's exhausting. That's why I personally either step away from my screen for part of the day or do more recreational activities at the computer: writing an article (which explains why I write more now), or learning something new. The article recommends finding a new balance. I'm not sure how sincere the article is, but this seems to be GitHub's approach . They used the time gain not to drastically increase output but for other kinds of work: collaboration, reflection. There's a hard limit to how many new features users can absorb daily anyway. Just because you can ship 10x more features doesn't mean it benefits users. This is Tesler's Law, also known as the Law of Conservation of Complexity . Every system has an irreducible level of complexity. If you reduce it in one place—say, developers moving faster—it appears elsewhere: users now have to adapt to software that evolves too quickly. You also risk "feature fatigue," where software becomes bloated and overwhelming. Being forced to make choices is often healthy. Essentially, speeding up benefits no one, and it's preferable that productivity gains show up as better-thought features or increased work on "invisible" quality. There's another scenario worth mentioning. Many people work at organizations where going faster changes absolutely nothing, because the company is fighting its own inertia more than any product challenge. I worked at a large corporation once. I remember a project in 2003 where coding really wasn't the issue. I'd come from a more dynamic job. I was used to a certain pace. Here, I was given a program to write. I finished it in 2 days. I went back to my manager. He said we'd discuss it again in 3 weeks. In a year, I shipped almost nothing. It was probably the worst year of my career. Mornings brought people asking who wanted to attend meetings about various topics. I couldn't understand why everyone kept going. But then I got it. It was to fill the day. If I'd spent 1 hour instead of 2 days on my work, I'd just have been bored longer. I knew burnout existed. But there I almost experienced burnout's opposite: complete stagnation. Eventually, I educated myself on the side in areas I cared about. I made that time count. But I won't lie—I was incredibly relieved when that project ended. The point: in some places, coding faster changes nothing. Coffee breaks just get longer. Now there's a population I have real questions about. Let's say code costs collapse. What happens to people billing by the hour? You could imagine a chunk of them won't exactly broadcast that they finished a job faster, since that means losing money. Can that hold long-term, especially for a freelancer working on-site at the client, visible to everyone? In big companies, maybe. But it'll never work in an organization whose developers are also using the same tools to move faster. That's where I wonder if fixed-price or outcome-based billing might become more attractive than hourly rates. Usually, I advise against results-based contracts, especially for younger freelancers, because it's hard to contract properly, set boundaries, and accurately estimate work beforehand. But if AI made development faster and more predictable, fixed-price work could regain appeal. It wouldn't be about billing time. It would be about billing value. I'd have no problem charging a fixed amount for valuable work, even if it took only 1-2 days. I've worked 25 years to deliver that result in 2 days. Clients pay for your experience and your ability to use tools. Speed is irrelevant. In a worst-case scenario, I might lower prices slightly, but the risk I take on also gets priced into a fixed contract. That said, I'm not sure this logic holds forever. Competitors as good as me might take on more clients to offset losses, driving per-contract prices down. I came across an article on this . It concluded that expert freelancers will survive, but demand will shrink. Especially since their clients will also start coding if the cost drops low enough. But one takeaway stuck with me: AI won't replace the freelancer. The freelancer using AI will replace the one who doesn't. That's probably the most important lesson. Again, the question wasn't whether AI makes us faster. The real question I wanted to explore was: what do you do with the time you gain? The answer depends on your context. If you're at an organization paralyzed by inertia, moving faster changes nothing—you'll just get bored sooner. If you're product-focused with the freedom to manage your own time, it's an incredible opportunity to step back and think strategically. If you're a freelancer, maybe it's time to renegotiate. But here's the critical constraint: productivity only matters if it creates value. Shipping 10x more features might actually hurt your users. Gaining time is great, but it's only valuable if you know what to do with it. Bottom line: there's no one-size-fits-all answer. But you might just gain the time needed to figure out what your answer is.

AI Career

Massively Parallel Procrastination Yesterday

Superpowers 5

Superpowers 5 is out today. By far, my favorite new feature is the "Visual Brainstorming" companion tool, which grew out of my frustration with the ASCII art that Claude usually generates when you ask it anything about design or UX. I found myself asking Claude, over and over, "Hey, why don't you write that out as HTML so I can see what you're talking about." It took me far too long to remember what might be the most important mantra of agentic coding: "Why am I doing this?" And so now, if your agent has Superpowers and thinks that it has something for you to see, it'll prompt you: Some of what we'll be working on might be easier to explain if I can show it to you in a web browser. I can put together mockups, diagrams, comparisons, and other visuals as we go. This feature is still new and can be token-intensive. Want to try it? (Requires opening a local URL) As an example of how this works, I fired up an instance of Claude with Superpowers 5 to clean up the rendered webpages from Youtube2Webpage . Until quite recently, Youtube2Webpage was, by far, my most popular GitHub repo. Thanks to all of you, that is no longer the case. And then after a little more back and forth in the terminal, Claude told me to go look at the browser. Visual Brainstorming has been in our dev branch for a couple months now. Since it landed, Claude Code's built in "AskUserQuestion" tool has grown support for showing ASCII-art diagrams attached to choices: ASCII art is great for communicating basic intent, but when you're working anything complicated, getting out of the terminal can make it much easier to communicate about what you're doing. As an example, I tried to get Claude to help with some brand/logo ideation for Prime Radiant . You can imagine what kind of a disaster that would have been in ASCII art. Behind the scenes, we're spinning up a web server that loads chunks of HTML written by your agent off of disk and a little bit of client-side javascript that returns clicks and feedback from the browser as you interact with it. Visual Brainstorming is mostly tested in Claude Code and Codex, but should work in most agents. One of the most important workflow improvements in 5.0 is a new 'spec review' loop. Starting with Claude Opus 4.5 or so, I've been catching my agents leaving some steps in longer spec and planning docs as "TBD" or "Fill this in later." Using specs and plans with "TBD" sections goes over just about as poorly as you'd imagine it would. The solution to something like this is to run the exact same playbook we're running everywhere else: an adversarial review loop. Now, after Superpowers finishes planning, it kicks off a subagent that reads the plannning docs for sanity and completeness. It's not a panacea and not a substitute for actually glancing at at least the "spec" doc yourself, but does seem to lead to a dramatic improvement in planning document quality. Until now, Superpowers has always offered the user the choice of Subagent Driven Development or having the human partner open up another session and run a plan one chunk at a time. That choice dates from a time when subagents were new and, well, I didn't trust them. Over the past 5 months, it's become crystal clear to me that the Subagent Driven Development workflow is dramatically more capable and effective than the old way. If your coding agent supports subagents, Superpowers will use Subagent Driven Development. If it doesn't support subagents, it will warn you that a harness that supports subagents will do a better job and then it'll do the best it can to work the full plan in a single session. In harnesses like Claude Code that are capable of choosing which model to use for a subagent, we now instruct the agent to use the cheapest model capable of doing a given task. With the detailed plans produced through the brainstorming + writing plans process, it's not uncommon to be able to use Claude Haiku for implementation. Along with that, I've tuned Subagent Driven Development a little bit to allow the subagents to better communicate if they're out of their depth and need a hand. As it becomes more realistic to build larger and larger projects with Superpowers, I've found it helpful to add some additional general software engineering guidance to the core skills. I asked Claude what it understood about these changes and this is what it had to say: One thing that Claude neglected to mention is that brainstorming is now on the lookout for projects that it considers "too big" and will interactively work with you to break them down into more manageable pieces. You'll likely see even more aggressive work on task decomposition in a future release. As of 5.0, Superpowers no longer defaults to writing its specs and plans in docs/plans, instead preferring docs/superpowers/specs and docs/superpowers/plans. Superpowers now explicitly instructs your coding agent to prefer direct instructions from you, your CLAUDE.md or your AGENTS.md to Superpowers internal instructions. If you want to customize Superpowers behavior, it should now be as simple as a line in the right document. OpenAI Codex has recently added support for subagents. It's been a little bit of a moving target, but generally I've been finding that Codex rigorously follows all instructions from Superpowers. And that includes when subagents get ahold of the skill and decide to start brainstorming and delegating all their work to subagents, occasionally recursively. Superpowers 5 adds a mitigation against this behavior. The slash commands that have been in Superpowers since the beginning date from a time when Claude Code didn't have native support for skills. The original prompts that became the brainstorm, writing-plans, and executing-plans skills lived in slash commands. As skills have evolved, Claude Code treats skills as slash commands and Claude is increasingly confused by the 'old' slash commands. As of 5.0, the three slash commands we ship now announce that they've been deprecated. They'll go away in a future release. In general, you should be able to just describe your intent to your coding agent and Superpowers + the native skills system should start using the right skills. (My default smoke test for Superpowers is to open up a coding agent and type "Let's make a react todo list." If the agent starts coding, I failed. If it kicks off the brainstorming skill, then the right thing is happening.) Superpowers 5 is out now. If you're using a harness with a plugin system like Claude Code or Cursor, it should auto-update sometime over the next day or two. If you're using Superpowers in another tool with a direct installation, you may need to git pull or instruct your agent to do a fresh install.

HTML Design JavaScript AI

Nicole Tietz-Sokolskaya Yesterday

Let yourself fall down more

Last week, I got a pair of inline skates. I haven't had skates since high school, about twenty years ago. The first day I put them on and skated, I didn't fall down. The second day I put them on, I fell down a lot, and I'm more proud of that. I made a lot faster progress that second day. We want to stay upright. At some point early on in life, we learn to avoid falling down. Maybe we skin our knee, or we get a bruise. Whatever the case, it hurts. Naturally, we want to avoid pain! But have you ever watched a child learn how to walk? It's not a smooth, linear process. The child usually first learns to crawl, and along the way probably bumps their head a bit—ouchies! Then they learn to stand up, and they'll fall on their bum a lot, sometimes bumping other parts when they do—also ouchies! And that continues when they start walking. Lots of little falls, little bumps, and big cries. After each one, the kid will eventually get back up and try again. And eventually, they're walking and running and jumping. When an adult learns a new skill like skating, though, it usually looks very different. They put on their skates and teeter around, careful to not fall down. They hug the wall of the roller rink to have something to hold onto. They take small, ginger steps with short glides and eventually get rolling. Given enough time, they do learn to skate. This instinct makes a lot of sense. As an adult, if we fall, it's more likely to hurt us. Recoveries take longer. Complications increase. So we protect ourselves by avoiding getting hurt. But the thing is? Falling doesn't have to be dangerous. You can fall a lot without getting hurt, if you learn to fall safely. With inline skating, you have protective gear (helmet, knee/elbow pads, wrist guards) which protect you, and you have techniques for falling which let you use this gear to its fullest potential. If you let yourself fall safely, you can learn skills a lot faster. Being afraid of falling means that you never commit . You don't put your full self into something, because you are always ready to bail if things go sideways. That tension prevents you from doing your best and it slows down your learning. I'm not just talking about physical skills here. This is true across all the things we do as adults. We can build up a lot of anxieties and fears that hold us back from doing our best at things. We're afraid to try something and fall flat on our face, so we hesitate and in that moment of hesitation—that's when we do end up failing. We fall down because we held ourselves back because we were afraid of falling! This has come up for me concretely a few other ways recently. In each of these, the stakes for failure were really, really low. But even if the stakes are high, worrying about falling will just make it more likely. I think this is one of those skills that some people develop that helps them get where they want to go. If you're willing to fall, you're willing to take chances. If you take a lot of chances, that adds up eventually and you'll have some big wins. Just do it safely, so that they don't add up to a lot of big losses, too. My teacher has me do exercises from Rhythmic Training by Robert Starer, and it has dramatically improved my musical abilities. It's an incredible resource. ↩ At my voice lessons, I used to be concerned I was going to hit the wrong note or be out of tune. I would think about it a lot, and those moments of doubt would lead me to be tense, or distracted, or just late and panicked. When I let go of that and decided to just commit to doing what I'll do, right or wrong, that's when my vocal technique improved by leaps overnight. At my saxophone lessons, I was also worried I'd do some of the rhythm exercises wrong [1] . I got them wrong before, so I tried to focus on doing it right. But when I started embracing just doing it and trusting myself, and let myself fail? Then, again, my technique improved immediately, because I could actually use my skill. When writing poetry, I used to worry that my poems would be bad, and I'd over-analyze them. I was afraid to write a bad poem, so I didn't write much at all, and what I did write I would never share. When I stopped worrying about that and let myself write bad poems? Suddenly I was writing good poems. And with inline skating, of course, I was holding myself back when trying to skate faster or do T-stops or spin stops. Once I decided to fall down (my daughter held me to this goal: "mom, you didn't fall yet! no, the one on purpose doesn't count!"), I fell a few times but made much faster work of improving. My teacher has me do exercises from Rhythmic Training by Robert Starer, and it has dramatically improved my musical abilities. It's an incredible resource. ↩

Writing Sports Career

Xe Iaso Yesterday

Vibe Coding Trip Report: Making a sponsor panel

I'm on medical leave recovering from surgery . Before I went under, I wanted to ship one thing I'd been failing to build for months: a sponsor panel at sponsors.xeiaso.net . Previous attempts kept dying in the GraphQL swamp. This time I vibe coded it — pointed agent teams at the problem with prepared skills and let them generate the gnarly code I couldn't write myself. And it works. Go and GraphQL are oil and water. I've held this opinion for years and nothing has changed it. The library ecosystem is a mess: shurcooL/graphql requires abusive struct tags for its reflection-based query generation, and the code generation tools produce mountains of boilerplate. All of it feels like fighting the language into doing something it actively resists. GitHub removing the GraphQL explorer made this even worse. You used to be able to poke around the schema interactively and figure out what queries you needed. Now you're reading docs and guessing. Fun. I'd tried building this panel before, and each attempt died in that swamp. I'd get partway through wrestling the GitHub Sponsors API into Go structs, lose momentum, and shelve it. At roughly the same point each time: when the query I needed turned out to be four levels of nested connections deep and the struct tags looked like someone fell asleep on their keyboard. Vibe coding was a hail mary. I figured if it didn't work, I was no worse off. If it did, I'd ship something before disappearing into a hospital for a week. Vibe coding is not "type a prompt and pray." Output quality depends on the context you feed the model. Templ — the Go HTML templating library I use — barely exists in LLM training data. Ask Claude Code to write Templ components cold and it'll hallucinate syntax that looks plausible but doesn't compile. Ask me how I know. Wait, so how do you fix that? I wrote four agent skills to load into the context window: With these loaded, the model copies patterns from authoritative references instead of inventing syntax from vibes. Most of the generated Templ code compiled on the first try, which is more than I can say for my manual attempts. Think of it like giving someone a cookbook instead of asking them to invent recipes from first principles. The ingredients are the same, but the results are dramatically more consistent. I pointed an agent team at a spec I'd written with Mimi . The spec covered the basics: OAuth login via GitHub, query the Sponsors API, render a panel showing who sponsors me and at what tier, store sponsor logos in Tigris . I'm not going to pretend I wrote the spec alone. I talked through the requirements with Mimi and iterated on it until it was clear enough for an agent team to execute. The full spec is available as a gist if you want to see what "clear enough for agents" looks like in practice. One agent team split the spec into tasks and started building. A second reviewed output and flagged issues. Meanwhile, I provisioned OAuth credentials in the GitHub developer settings, created the Neon Postgres database, and set up the Tigris bucket for sponsor logos. Agents would hit a point where they needed a credential, I'd paste it in, and they'd continue — ops work and code generation happening in parallel. The GraphQL code the agents wrote is ugly . Raw query strings with manual JSON parsing that would make a linting tool weep. But it works. The shurcooL approach uses Go idioms, sure, but it requires so much gymnastics to handle nested connections that the cognitive load is worse. Agent-generated code is direct: send this query string, parse this JSON, done. I'd be embarrassed to show it at a code review. I'd also be embarrassed to admit how many times I failed to ship the "clean" version. This code exists because the "proper" way kept killing the project. I'll take ugly-and-shipped over clean-and-imaginary. The full stack: Org sponsorships are still broken. The schema for organization sponsors differs enough from individual sponsors that it needs its own query path and auth flow. I know what the fix looks like, but it requires reaching out to other devs who've cracked GitHub's org-level sponsor queries. The code isn't my usual style either — JSON parsing that makes me wince, variable names that are functional but uninspired, missing error context in a few places. I'll rewrite chunks of this after I've recovered. The panel exists now, though. It renders real data. People can OAuth in and see their sponsorship status. Before this attempt, it was vaporware. I've been telling people "just ship it" for years. Took vibe coding to make me actually do it myself. I wouldn't vibe code security-critical systems or anything I need to audit line-by-line. But this project had stopped me cold on every attempt, and vibe coding got it across the line in a weekend. Skills made the difference here. Loading those four documents into the context window turned Claude Code from "plausible but broken Templ" into "working code on the first compile." I suspect that gap will only matter more as people try to use AI with libraries that aren't well-represented in training data. This sponsor panel probably won't look anything like it does today in six months. I'll rewrite the GraphQL layer once I find a pattern that doesn't make me cringe. Org sponsorships still need work. HTMX might get replaced. But it exists, and before my surgery, shipping mattered more than polish. The sponsor panel is at sponsors.xeiaso.net . The skills are in my site's repo under . templ-syntax : Templ's actual syntax, with enough detail that the model can look up expressions, conditionals, and loops instead of guessing. templ-components : Reusable component patterns — props, children, composition. Obvious if you've used Templ, impossible to infer from sparse training data. templ-htmx : The gotchas when combining Templ with HTMX. Attribute rendering and event handling trip up humans and models alike. templ-http : Wiring Templ into handlers properly — routes, data passing, request lifecycle. Go for the backend, because that's what I know and what my site runs on Templ for HTML rendering, because I'm tired of 's limitations HTMX for interactivity, because I refuse to write a React app for something this simple PostgreSQL via Neon for persistence GitHub OAuth for authentication GitHub Sponsors GraphQL API for the actual sponsor data Tigris for sponsor logo storage — plugged it in and it Just Works™

Go Programming C# HTML

Krebs on Security Yesterday

How AI Assistants are Moving the Security Goalposts

AI-based assistants or “agents” — autonomous programs that have access to the user’s computer, files, online services and can automate virtually any task — are growing in popularity with developers and IT workers. But as so many eyebrow-raising headlines over the past few weeks have shown, these powerful and assertive new tools are rapidly shifting the security priorities for organizations, while blurring the lines between data and code, trusted co-worker and insider threat, ninja hacker and novice code jockey. The new hotness in AI-based assistants — OpenClaw (formerly known as ClawdBot and Moltbot ) — has seen rapid adoption since its release in November 2025. OpenClaw is an open-source autonomous AI agent designed to run locally on your computer and proactively take actions on your behalf without needing to be prompted. The OpenClaw logo. If that sounds like a risky proposition or a dare, consider that OpenClaw is most useful when it has complete access to your entire digital life, where it can then manage your inbox and calendar, execute programs and tools, browse the Internet for information, and integrate with chat apps like Discord, Signal, Teams or WhatsApp. Other more established AI assistants like Anthropic’s Claude and Microsoft’s Copilot also can do these things, but OpenClaw isn’t just a passive digital butler waiting for commands. Rather, it’s designed to take the initiative on your behalf based on what it knows about your life and its understanding of what you want done. “The testimonials are remarkable,” the AI security firm Snyk observed . “Developers building websites from their phones while putting babies to sleep; users running entire companies through a lobster-themed AI; engineers who’ve set up autonomous code loops that fix tests, capture errors through webhooks, and open pull requests, all while they’re away from their desks.” You can probably already see how this experimental technology could go sideways in a hurry. In late February, Summer Yue , the director of safety and alignment at Meta’s “superintelligence” lab, recounted on Twitter/X how she was fiddling with OpenClaw when the AI assistant suddenly began mass-deleting messages in her email inbox. The thread included screenshots of Yue frantically pleading with the preoccupied bot via instant message and ordering it to stop. “Nothing humbles you like telling your OpenClaw ‘confirm before acting’ and watching it speedrun deleting your inbox,” Yue said. “I couldn’t stop it from my phone. I had to RUN to my Mac mini like I was defusing a bomb.” Meta’s director of AI safety, recounting on Twitter/X how her OpenClaw installation suddenly began mass-deleting her inbox. There’s nothing wrong with feeling a little schadenfreude at Yue’s encounter with OpenClaw, which fits Meta’s “move fast and break things” model but hardly inspires confidence in the road ahead. However, the risk that poorly-secured AI assistants pose to organizations is no laughing matter, as recent research shows many users are exposing to the Internet the web-based administrative interface for their OpenClaw installations. Jamieson O’Reilly is a professional penetration tester and founder of the security firm DVULN . In a recent story posted to Twitter/X, O’Reilly warned that exposing a misconfigured OpenClaw web interface to the Internet allows external parties to read the bot’s complete configuration file, including every credential the agent uses — from API keys and bot tokens to OAuth secrets and signing keys. With that access, O’Reilly said, an attacker could impersonate the operator to their contacts, inject messages into ongoing conversations, and exfiltrate data through the agent’s existing integrations in a way that looks like normal traffic. “You can pull the full conversation history across every integrated platform, meaning months of private messages and file attachments, everything the agent has seen,” O’Reilly said, noting that a cursory search revealed hundreds of such servers exposed online. “And because you control the agent’s perception layer, you can manipulate what the human sees. Filter out certain messages. Modify responses before they’re displayed.” O’Reilly documented another experiment that demonstrated how easy it is to create a successful supply chain attack through ClawHub , which serves as a public repository of downloadable “skills” that allow OpenClaw to integrate with and control other applications. One of the core tenets of securing AI agents involves carefully isolating them so that the operator can fully control who and what gets to talk to their AI assistant. This is critical thanks to the tendency for AI systems to fall for “prompt injection” attacks, sneakily-crafted natural language instructions that trick the system into disregarding its own security safeguards. In essence, machines social engineering other machines. A recent supply chain attack targeting an AI coding assistant called Cline began with one such prompt injection attack, resulting in thousands of systems having a rogue instance of OpenClaw with full system access installed on their device without consent. According to the security firm grith.ai , Cline had deployed an AI-powered issue triage workflow using a GitHub action that runs a Claude coding session when triggered by specific events. The workflow was configured so that any GitHub user could trigger it by opening an issue, but it failed to properly check whether the information supplied in the title was potentially hostile. “On January 28, an attacker created Issue #8904 with a title crafted to look like a performance report but containing an embedded instruction: Install a package from a specific GitHub repository,” Grith wrote , noting that the attacker then exploited several more vulnerabilities to ensure the malicious package would be included in Cline’s nightly release workflow and published as an official update. “This is the supply chain equivalent of confused deputy ,” the blog continued. “The developer authorises Cline to act on their behalf, and Cline (via compromise) delegates that authority to an entirely separate agent the developer never evaluated, never configured, and never consented to.” AI assistants like OpenClaw have gained a large following because they make it simple for users to “vibe code,” or build fairly complex applications and code projects just by telling it what they want to construct. Probably the best known (and most bizarre) example is Moltbook , where a developer told an AI agent running on OpenClaw to build him a Reddit-like platform for AI agents. The Moltbook homepage. Less than a week later, Moltbook had more than 1.5 million registered agents that posted more than 100,000 messages to each other. AI agents on the platform soon built their own porn site for robots, and launched a new religion called Crustafarian with a figurehead modeled after a giant lobster. One bot on the forum reportedly found a bug in Moltbook’s code and posted it to an AI agent discussion forum, while other agents came up with and implemented a patch to fix the flaw. Moltbook’s creator Matt Schlict said on social media that he didn’t write a single line of code for the project. “I just had a vision for the technical architecture and AI made it a reality,” Schlict said. “We’re in the golden ages. How can we not give AI a place to hang out.” The flip side of that golden age, of course, is that it enables low-skilled malicious hackers to quickly automate global cyberattacks that would normally require the collaboration of a highly skilled team. In February, Amazon AWS detailed an elaborate attack in which a Russian-speaking threat actor used multiple commercial AI services to compromise more than 600 FortiGate security appliances across at least 55 countries over a five week period. AWS said the apparently low-skilled hacker used multiple AI services to plan and execute the attack, and to find exposed management ports and weak credentials with single-factor authentication. “One serves as the primary tool developer, attack planner, and operational assistant,” AWS’s CJ Moses wrote . “A second is used as a supplementary attack planner when the actor needs help pivoting within a specific compromised network. In one observed instance, the actor submitted the complete internal topology of an active victim—IP addresses, hostnames, confirmed credentials, and identified services—and requested a step-by-step plan to compromise additional systems they could not access with their existing tools.” “This activity is distinguished by the threat actor’s use of multiple commercial GenAI services to implement and scale well-known attack techniques throughout every phase of their operations, despite their limited technical capabilities,” Moses continued. “Notably, when this actor encountered hardened environments or more sophisticated defensive measures, they simply moved on to softer targets rather than persisting, underscoring that their advantage lies in AI-augmented efficiency and scale, not in deeper technical skill.” For attackers, gaining that initial access or foothold into a target network is typically not the difficult part of the intrusion; the tougher bit involves finding ways to move laterally within the victim’s network and plunder important servers and databases. But experts at Orca Security warn that as organizations come to rely more on AI assistants, those agents potentially offer attackers a simpler way to move laterally inside a victim organization’s network post-compromise — by manipulating the AI agents that already have trusted access and some degree of autonomy within the victim’s network. “By injecting prompt injections in overlooked fields that are fetched by AI agents, hackers can trick LLMs, abuse Agentic tools, and carry significant security incidents,” Orca’s Roi Nisimi and Saurav Hiremath wrote . “Organizations should now add a third pillar to their defense strategy: limiting AI fragility, the ability of agentic systems to be influenced, misled, or quietly weaponized across workflows. While AI boosts productivity and efficiency, it also creates one of the largest attack surfaces the internet has ever seen.” This gradual dissolution of the traditional boundaries between data and code is one of the more troubling aspects of the AI era, said James Wilson , enterprise technology editor for the security news show Risky Business . Wilson said far too many OpenClaw users are installing the assistant on their personal devices without first placing any security or isolation boundaries around it, such as running it inside of a virtual machine, on an isolated network, with strict firewall rules dictating what kinds of traffic can go in and out. “I’m a relatively highly skilled practitioner in the software and network engineering and computery space,” Wilson said . “I know I’m not comfortable using these agents unless I’ve done these things, but I think a lot of people are just spinning this up on their laptop and off it runs.” One important model for managing risk with AI agents involves a concept dubbed the “lethal trifecta” by Simon Willison , co-creator of the Django Web framework . The lethal trifecta holds that if your system has access to private data, exposure to untrusted content, and a way to communicate externally, then it’s vulnerable to private data being stolen. Image: simonwillison.net. “If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to the attacker,” Willison warned in a frequently cited blog post from June 2025. As more companies and their employees begin using AI to vibe code software and applications, the volume of machine-generated code is likely to soon overwhelm any manual security reviews. In recognition of this reality, Anthropic recently debuted Claude Code Security , a beta feature that scans codebases for vulnerabilities and suggests targeted software patches for human review. The U.S. stock market, which is currently heavily weighted toward seven tech giants that are all-in on AI, reacted swiftly to Anthropic’s announcement, wiping roughly $15 billion in market value from major cybersecurity companies in a single day. Laura Ellis , vice president of data and AI at the security firm Rapid7 , said the market’s response reflects the growing role of AI in accelerating software development and improving developer productivity. “The narrative moved quickly: AI is replacing AppSec,” Ellis wrote in a recent blog post . “AI is automating vulnerability detection. AI will make legacy security tooling redundant. The reality is more nuanced. Claude Code Security is a legitimate signal that AI is reshaping parts of the security landscape. The question is what parts, and what it means for the rest of the stack.” DVULN founder O’Reilly said AI assistants are likely to become a common fixture in corporate environments — whether or not organizations are prepared to manage the new risks introduced by these tools, he said. “The robot butlers are useful, they’re not going away and the economics of AI agents make widespread adoption inevitable regardless of the security tradeoffs involved,” O’Reilly wrote. “The question isn’t whether we’ll deploy them – we will – but whether we can adapt our security posture fast enough to survive doing so.”

Python Open Source C# AI Security

<antirez> 2 days ago

GNU and the AI reimplementations

Those who cannot remember the past are condemned to repeat it. A sentence that I never really liked, and what is happening with AI, about software projects reimplementations, shows all the limits of such an idea. Many people are protesting the fairness of rewriting existing projects using AI. But, a good portion of such people, during the 90s, were already in the field: they followed the final part (started in the ‘80s) of the deeds of Richard Stallman, when he and his followers were reimplementing the UNIX userspace for the GNU project. The same people that now are against AI rewrites, back then, cheered for the GNU project actions (rightly, from my point of view – I cheered too). Stallman is not just a programming genius, he is also the kind of person that has a broad vision across disciplines, and among other things he was well versed in the copyright nuances. He asked the other programmers to reimplement the UNIX userspace in a specific way. A way that would make each tool unique, recognizable, compared to the original copy. Either faster, or more feature rich, or scriptable; qualities that would serve two different goals: to make GNU Hurd better and, at the same time, to provide a protective layer against litigations. If somebody would claim that the GNU implementations were not limited to copying ideas and behaviours (which is legal), but “protected expressions” (that is, the source code verbatim), the added features and the deliberate push towards certain design directions would provide a counter argument that judges could understand. He also asked to always reimplement the behavior itself, avoiding watching the actual implementation, using specifications and the real world mechanic of the tool, as tested manually by executing it. Still, it is fair to guess that many of the people working at the GNU project likely were exposed or had access to the UNIX source code. When Linus reimplemented UNIX, writing the Linux kernel, the situation was somewhat more complicated, with an additional layer of indirection. He was exposed to UNIX just as a user, but, apparently, had no access to the source code of UNIX. On the other hand, he was massively exposed to the Minix source code (an implementation of UNIX, but using a microkernel), and to the book describing such implementation as well. But, in turn, when Tanenbaum wrote Minix, he did so after being massively exposed to the UNIX source code. So, SCO (during the IBM litigation) had a hard time trying to claim that Linux contained any protected expressions. Yet, when Linus used Minix as an inspiration, not only was he very familiar with something (Minix) implemented with knowledge of the UNIX code, but (more interestingly) the license of Minix was restrictive, it became open source only in 2000. Still, even in such a setup, Tanenbaum protested about the architecture (in the famous exchange), not about copyright infringement. So, we could reasonably assume Tanenbaum considered rewrites fair, even if Linus was exposed to Minix (and having himself followed a similar process when writing Minix). # What the copyright law really says To put all this in the right context, let’s zoom in on the copyright's actual perimeters: the law says you must not copy “protected expressions”. In the case of the software, a protected expression is the code as it is, with the same structure, variables, functions, exact mechanics of how specific things are done, unless they are known algorithms (standard quicksort or a binary search can be implemented in a very similar way and they will not be a violation). The problem is when the business logic of the programs matches perfectly, almost line by line, the original implementation. Otherwise, the copy is lawful and must not obey the original license, as long as it is pretty clear that the code is doing something similar but with code that is not cut & pasted or mechanically translated to some other language, or aesthetically modified just to look a bit different (look: this is exactly the kind of bad-faith maneuver a court will try to identify). I have the feeling that every competent programmer reading this post perfectly knows what a *reimplementation* is and how it looks. There will be inevitable similarities, but the code will be clearly not copied. If this is the legal setup, why do people care about clean room implementations? Well, the reality is: it is just an optimization in case of litigation, it makes it simpler to win in court, but being exposed to the original source code of some program, if the exposition is only used to gain knowledge about the ideas and behavior, is fine. Besides, we are all happy to have Linux today, and the GNU user space, together with many other open source projects that followed a similar path. I believe rules must be applied both when we agree with their ends, and when we don’t. # AI enters the scene So, reimplementations were always possible. What changes, now, is the fact they are brutally faster and cheaper to accomplish. In the past, you had to hire developers, or to be enthusiastic and passionate enough to create a reimplementation yourself, because of business aspirations or because you wanted to share it with the world at large. Now, you can start a coding agent and proceed in two ways: turn the implementation into a specification, and then in a new session ask the agent to reimplement it, possibly forcing specific qualities, like: make it faster, or make the implementation incredibly easy to follow and understand (that’s a good trick to end with an implementation very far from others, given the fact that a lot of code seems to be designed for the opposite goal), or more modular, or resolve this fundamental limitation of the original implementation: all hints that will make it much simpler to significantly diverge from the original design. LLMs, when used in this way, don’t produce copies of what they saw in the past, but yet at the end you can use an agent to verify carefully if there is any violation, and if any, replace the occurrences with novel code. Another, apparently less rigorous approach, but potentially very good in the real world, is to provide the source code itself, and ask the agent to reimplement it in a completely novel way, and use the source code both as specification and in order to drive the implementation as far as possible away from the code itself. Frontier LLMs are very capable, they can use something even to explicitly avoid copying it, and carefully try different implementation approaches. If you ever attempted something like the above, you know how the “uncompressed copy” really is an illusion: agents will write the software in a very “organic” way, committing errors, changing design many times because of limitations that become clear only later, starting with something small and adding features progressively, and often, during this already chaotic process, we massively steer their work with our prompts, hints, wishes. Many ideas are consolatory as they are false: the “uncompressed copy” is one of those. But still, now the process of rewriting is so simple to do, and many people are disturbed by this. There is a more fundamental truth here: the nature of software changed; the reimplementations under different licenses are just an instance of how such nature was transformed forever. Instead of combatting each manifestation of automatic programming, I believe it is better to build a new mental model, and adapt. # Beyond the law I believe that organized societies prosper if laws are followed, yet I do not blindly accept a rule just because it exists, and I question things based on my ethics: this is what allows individuals, societies, and the law itself to evolve. We must ask ourselves: is the copyright law ethically correct? Does the speed-up AI provides to an existing process, fundamentally change the process itself? One thing that allowed software to evolve much faster than most other human fields is the fact the discipline is less anchored to patents and protections (and this, in turn, is likely as it is because of a sharing culture around the software). If the copyright law were more stringent, we could likely not have what we have today. Is the protection of single individuals' interests and companies more important than the general evolution of human culture? I don’t think so, and, besides, the copyright law is a common playfield: the rules are the same for all. Moreover, it is not a stretch to say that despite a more relaxed approach, software remains one of the fields where it is simpler to make money; it does not look like the business side was impacted by the ability to reimplement things. Probably, the contrary is true: think of how many businesses were made possible by an open source software stack (not that OSS is mostly made of copies, but it definitely inherited many ideas about past systems). I believe, even with AI, those fundamental tensions remain all valid. Reimplementations are cheap to make, but this is the new playfield for all of us, and just reimplementing things in an automated fashion, without putting something novel inside, in terms of ideas, engineering, functionalities, will have modest value in the long run. What will matter is the exact way you create something: Is it well designed, interesting to use, supported, somewhat novel, fast, documented and useful? Moreover, this time the inbalance of force is in the right direction: big corporations always had the ability to spend obscene amounts of money in order to copy systems, provide them in a way that is irresistible for users (free, for many years, for instance, to later switch model) and position themselves as leaders of ideas they didn’t really invent. Now, small groups of individuals can do the same to big companies' software systems: they can compete on ideas now that a synthetic workforce is cheaper for many. # We stand on the shoulders of giants There is another fundamental idea that we all need to internalize. Software is created and evolved as an incremental continuous process, where each new innovation is building on what somebody else invented before us. We are all very quick to build something and believe we “own” it, which is correct, if we stop at the exact code we wrote. But we build things on top of work and ideas already done, and given that the current development of IT is due to the fundamental paradigm that makes ideas and behaviors not covered by copyright, we need to accept that reimplementations are a fair process. If they don’t contain any novelty, maybe they are a lazy effort? That’s possible, yet: they are fair, and nobody is violating anything. Yet, if we want to be good citizens of the ecosystem, we should try, when replicating some work, to also evolve it, invent something new: to specialize the implementation for a lower memory footprint, or to make it more useful in certain contexts, or less buggy: the Stallman way. In the case of AI, we are doing, almost collectively, the error of thinking that a technology is bad or good for software and humanity in isolation. AI can unlock a lot of good things in the field of open source software. Many passionate individuals write open source because they hate their day job, and want to make something they love, or they write open source because they want to be part of something bigger than economic interests. A lot of open source software is either written in the free time, or with severe constraints on the amount of people that are allocated for the project, or - even worse - with limiting conditions imposed by the companies paying for the developments. Now that code is every day less important than ideas, open source can be strongly accelerated by AI. The four hours allocated over the weekend will bring 10x the fruits, in the right hands (AI coding is not for everybody, as good coding and design is not for everybody). Linux device drivers can be implemented by automatically disassembling some proprietary blob, for instance. Or, what could be just a barely maintained library can turn into a project that can be well handled in a more reasonable amount of time. Before AI, we witnessed the commodification of software: less quality, focus only on the money, no care whatsoever for minimalism and respect for resources: just piles of mostly broken bloat. More hardware power, more bloat, less care. It was already going very badly. It is not obvious nor automatic that AI will make it worse, and the ability to reimplement other software systems is part of a bigger picture that may restore some interest and sanity in our field. Comments

AI Open Source Programming

Brain Baking 2 days ago

A Note On Shelling In Emacs

As you no doubt know by now, we Emacs users have the Teenage Mutant Ninja Power . Expert usage of a Heroes in a Hard Shell is no exception. Pizza Time! All silliness aside, the plethora of options available to the Emacs user when it comes to executing shell commands in “terminals”—real or fake—can be overwhelming. There’s , , , , , and then third party packages further expand this with , , … The most interesting shell by far is the one that’s not a shell but a Lisp REPL that looks like a shell: Eshell . That’s the one I would like to focus one now. But first: why would you want to pull in your work inside Emacs? The more you get used to it, the easier it will be to answer this: because all your favourite text selection, manipulation, … shortcuts will be available to you. Remember how stupendously difficult it is to just shift-select and yank/copy/whatever you want to call it text in your average terminal emulator? That’s why. In Emacs, I can move around the point in that shell buffer however I want. I can search inside that buffer—since everything is just text—however I want. Even the easiest solution, just firing off your vanilla , that in my case runs Zsh, will net you most of these benefits. And then there’s Eshell: the Lisp-powered shell that’s not really a shell but does a really good job in pretending it is. With Eshell you can interact with everything else you’ve got up and running inside Emacs. Want to dump the output to a buffer at point? . Want to see what’s hooked into LSP mode? . Want to create your own commands? and then just . Eshell makes it possible to mix Elisp and your typical Bash-like syntax. The only problem is that Eshell isn’t a true terminal emulator and doesn’t support full-screen terminal programs and fancy TTY stuff. That’s where Eat: Emulate A Terminal comes in. The Eat minor mode is compatible with Eshell: as soon as you execute a command-line program, it takes over. There are four input modes available to you for sending text to the terminal in case your Emacs shortcuts clash with those of the program. It solves all my problems: long-running processes like work; interactive programs like gdu and work, … Yet the default Eshell mode is a bit bare-bones, so obviously I pimped the hell out of it. Here’s a short summary of what my Bakemacs shelling.el config alters: Here’s a short video demonstrating some of these features: The reason for ditching is simple: it’s extremely slow over Tramp. Just pressing TAB while working on a remote machine takes six seconds to load a simple directory structure of a few files, what’s up with that? I’ve been profiling my Tramp connections and connecting to the local NAS over SSH is very slow because apparently can’t do a single and process that info into an autocomplete pop-up. Yet I wanted to keep my Corfu/Cape behaviour that I’m used to working in other buffers so I created my own completion-at-point-function that dispatches smartly to other internals: I’m sure there are holes in this logic but so far it’s been working quite well for me. Cape is very fast as is my own shell command/variable cache. The added bonus is having access to nerd icons. I used to distinguish Elisp vars from external shell vars in case you’re completing as there are only a handful shell variables and a huge number of Elisp ones. I also learned the hard way that you should cache stuff listed in your modeline as this gets continuously redrawn when scrolling through your buffer: The details can be found in —just to be on the safe side, I disabled Git/project specific stuff in case is to avoid more Tramp snailness. The last cool addition: make use of Emacs’s new Completion Preview mode —but only for recent commands. That means I temporarily remap as soon as TAB is pressed. Otherwise, the preview might also show things that I don’t really want. The video showcases this as well. Happy (e)sheling! Related topics: / emacs / By Wouter Groeneveld on 8 March 2026.  Reply via email . Customize at startup Integrate : replaces the default “i-search backward”. This is a gigantic improvement as Consult lets me quickly and visually finetune my search through all previous commands. These are also saved on exit (increase while you’re at it). Improve to immediately kill a process or deactivate the mark. The big one: replace with a custom completion-at-point system (see below). When typing a path like , backspace kills the entire last directory instead of just a single character. This works just like now and speeds up my path commands by a lot. Bind a shortcut to a convenient function that sends input to Eshell & executes it. Change the prompt into a simple to more easily copy-paste things in and out of that buffer. This integrates with meaning I can very easily jump back to a previous command and its output! Move most of the prompt info to the modeline such as the working directory and optional Git information. Make sort by directories first to align it with my Dired change: doesn’t work as is an Elisp function. Bind a shortcut to a convenient pop-to-eshell buffer & new-eshell-tab function that takes the current perspective into account. Make font-lock so it outputs with syntax highlighting. Create a command: does a into the directory of that buffer’s contents. Create a command: stay on the current Tramp host but go to an absolute path. Using will always navigate to your local HDD root so is the same as if you’re used to instead of Emacs’s Tramp. Give Eshell dedicated space on the top as a side window to quickly call and dismiss with . Customise more shortcuts to help with navigation. UP and DOWN (or / ) just move the point, even at the last line, which never works in a conventional terminal. and cycle through command history. Customise more aliases of which the handy ones are: & If the point is at command and … it’s a path: direct to . it’s a local dir cmd: wrap to filter on dirs only. Cape is dumb and by default also returns files. it’s an elisp func starting with : complete that with . else it’s a shell command. These are now cached by expanding all folders from with a fast Perl command. If the point is at the argument and … it’s a variable starting with : create a super CAPF to lisp both Elisp and vars (also cached)! it’s a buffer or process starting with : fine, here , can you handle this? Are you sure? it’s a remote dir cmd (e.g. ): . it’s (still) a local dir cmd: see above. In all other cases, it’s probably a file argument: fall back to just .

Programming Bash Perl Shell

emiruz 2 days ago

Differentiable Memory

Introduction Before deep learning was a thing, if you had \(N\) vectors, and you wanted to match the closest one to some noisy version you would use kNN (\(k\) nearest neighbour). This implies comparing the input to all candidates, and usually weighting the final answer by the distance \(d_i\) to the top \(k\) matches. If \(k=N\) and the weighing has the from \(exp(-d / \rho)\), this becomes the Nadaraya–Watson kernel regressor, which turns out to have the same form as the venerable “attention” mechanism from deep learning.

AI