2026-06-26 · Vibecoding gets Emacs patch rejected

Transcript

Transcript. Paraphrased; sources in notes.md.

HostWelcome to the show. It is June 26th, 2026. Today we are digging into the friction points of modern development, from the philosophical gatekeeping of the GNU project to the social toll of AI-assisted coding and, finally, the promise of local-first web applications. Joining me, as always, is Tom, a maintainer who has probably spent more time in a terminal this week than in natural sunlight. Tom, how are you holding up?

GuestDaniel, I am doing fine. I spent most of the night trying to explain to a drive-by contributor that, no, I do not want to integrate a six-thousand-line library just to pad a string. The state of things, honestly, it feels like everyone is trying to build a skyscraper on a foundation of sand, and then they wonder why the roof leaks when it rains. I saw the piece about the Emacs patch today, and it just made me laugh. It is the perfect microcosm of everything I deal with on a Tuesday.

HostThat is exactly where I wanted to start. There is a developer who spent weeks working on performance improvements for Emacs, only to have the patch rejected by the GNU project. The core issue? The developer was upfront about using LLMs to navigate the codebase. It has sparked a huge debate over on Lobsters about whether this is a necessary stand against opaque training data or just a regressive policy. What is your take, Tom?

GuestLook, I get why people are frustrated. They want to contribute, they want to use the shiny toys. But from where I sit, GNU is not just protecting their ego here. They are protecting the project from a liability nightmare. A Lobsters user called nemin hits the nail on the head, pointing out that open-weights and open-source are not the same thing. If I accept a patch that was generated by a black-box model, I have no idea if that code is derivative, if it is hallucinated, or if it violates someone else's IP. When the author complains that they are holding the stick wrong, I think the response from the community is correct. It is not about honesty. It is about policy. If you know the rules, and you ignore them, you are not being a martyr. You are just creating extra work for the people who actually have to sign the release.

HostIt is interesting because the author seems to view their own labor as a gift, and they feel rejected because they were open about their method. A commenter named wink, however, put it quite bluntly, noting that pretending they would have been accepted if they had just lied about it is not a meaningful argument.

GuestExactly. And honestly, I have seen this shift. People treat these models like a magic wand, but they dump the cognitive load of verification on me. I do not have time to audit an LLM hallucination for every pull request that hits my inbox. It is the normalization of deviance. If you start accepting LLM-generated code because it looks mostly right, in five years, the codebase is going to be a graveyard of subtle, unfixable bugs.

HostThat transitions well into our second topic. There is a fascinating post about the exhaustion of talking to a tool. The author argues that LLMs feel like a social tax. They lack the consistency and speed of a tool like a keyboard or a code editor, so you end up negotiating with them instead of just working. What do you think about that idea of a social tax?

GuestI think the author is onto something profound. A tool, to me, is something I can predict. When I hit a key, the cursor moves. That is it. When I talk to an LLM, I am engaging in a performance. A Lobsters user called travisgriggs had a really sobering point about this in the thread. They mentioned they are coaching new programmers, and they have lost the ability to mentor them because they cannot tell if the work is the student's own mastery or just the output of an AI. That is the real cost. It is not just your energy; it is the erosion of the mentor-mentee relationship. If you cannot critique someone's growth because the AI is in the middle of it, what are we even doing?

HostIt is a stark way to look at it. The author contrasts this with human-to-human interaction, which is also exhausting but rewarding because there is actual growth involved. It makes me wonder if we are just trading away our agency for a slightly faster way to write boilerplate.

GuestWe are. And for what? So we can churn out features faster and maintain them longer? Every line of code I did not write myself is a line of code I do not truly understand. When I have to debug it at three in the morning, the AI is not going to be there to fix the production outage.

HostLet us pivot to something a bit more hopeful. There is an interesting piece about the browser's File System Access API, specifically window.showDirectoryPicker. The author is excited about how this could enable truly local-first web apps. You can essentially point a website at a folder on your disk, and it can interact with those files directly, bypassing the cloud.

GuestNow, this is something I can get behind. I am tired of seeing every little tool force me to upload my data to some SaaS black hole. I actually use a tiny, custom-written local script to sync my own documentation between machines, just to avoid that exact problem. A commenter on Lobsters, sourcemap, pointed out exactly why this matters. They mentioned tools like Vimium, which usually force you into a walled-off extension page. Being able to point a tool at a local JSON config file and actually manage it like a real, local file? That is how computing was supposed to work. It gives the user agency back.

HostIt feels like a return to the classic Unix philosophy, but inside the browser sandbox. The author uses the example of building a photo viewer that acts like old professional software, but it stays local. It feels like a rare instance where the browser is actually expanding what a user can own, rather than locking them in.

GuestIf it stays that way, sure. The risk, obviously, is that we start building apps that require permissions for everything and then just move the cloud into our local directories anyway. But the potential to own your own data, to have that live binding to your filesystem? That is the kind of engineering that lasts. It is not a shiny trick. It is foundational.

HostIt is a nice note to end on. I think I am going to spend my weekend clearing out some of those cloud-bound apps and seeing what I can keep local. Thanks for coming on, Tom. I know you have a mountain of issues waiting for you.

GuestI always do, Daniel. It is the life of a maintainer. The bugs do not sleep, so I suppose I should get back to it. Next time we talk, remind me to tell you about the latest batch of "AI-optimized" security patches I had to reject. It is enough to make you want to go back to pencil and paper.

HostI will hold you to that. A big thanks to Tom for joining me, and to everyone over at Lobsters for the lively discussions that made today's episode possible. We will be back tomorrow. Stay curious, and keep your local files safe.