I first encountered the following concept in one of Oxide's publications; good chance it didn't originate there though:
There is an implicit social contract with writing that the writer has put more effort into writing than the reader will need to read something. Sure you get crackpots still, but there are only so many Gene Rays in this world, so the volume is limited.
I think the same applies to PRs. Pre-AI , it was usually obvious when a PR was either completely terrible or very half-baked, and the required effort to create even a shitty PR was usually more than that required to reject it.
AI makes it trivial to make a completely terrible PR, and much easier to make a not-immediately-obviously-bad PR.
Given this, you can conclude that writers should be putting in at least at much effort as readers, whether or not they use an LLM. What really seems to be the problem is writers that don't at least check their own work, and pass that burden onto the readers. This is easier than ever with LLMs.
This is toxic behavior that unfortunately rewards a selfish writer. I'm worried the AI push incentivizes this too much, to where in corporate situations a reader can't say no to doing work for a selfish writer.
Its exactly this. I have had a few LLM coding sessions where I reviewed the resulting work and thought "I don't think my team can safely PR this." I then went back and broke it down into smaller PRs, still using LLMs but at a size that is easy to review. And I reviewed the output myself before I asked a reviewer to commit their time.
The problem is that this is increasingly seen as a non-productive workflow slowing everyone else down, so the pressure is growing for writers to just shove massive PRs out the door and reviewers to use LLMs to make that tractable. I suppose those advocates have more faith in LLM output compared to humans than I do.
Thats the thing with giant PRs. They never really needed to be reviewed anyway. In cultures with strong review culture I have worked at, if you send me a thousand line PR and ask me to review it, I will look at the giant blob of text, and immediately fire off a "it's too long, can you cut it into smaller PRs?".
Because I don't trust myself to review a giant PR. It takes too much cognition to properly review it.
And now that people are making PRs with AI, this is even more important. If the AI was good enough to have coded it, please instruct it to make the changes in reviewable chunks.
> the pressure is growing for writers to just shove massive PRs out the door and reviewers to use LLMs to make that tractable
Even in these move-fast envs, it should be reasonably apparent for people to realize that the author should be using the LLM to make the PR tractable, not solely using the LLM to shovel out a giant PR + slop PR description.
And the LLMs can often do this - if you ask to restructure or break up a big change differently, they can often make quite reasonable suggestions and help with it. That's just not what you're gonna get if you're lazy. If you want a small LLM-generated change, often you have to start with a big one then ask it to figure out what it can get rid of, since many times it doesn't have perfect model of all the code in it's "head" before it starts spitting stuff out. The big companies have been doing their best to automate this for the last couple of years vs the even-more-blind attempts you used to get, but there's still the issue of the models+tools following generic advice aimed at median codebases vs being intimately familiar with this codebase.
You can go fast without being lazy. And when going fast, in some ways, it's more important than ever to put in that effort to not blowing things up.
It should be but often isn't. There's been a lot of threads on HN where the response to huge PRs wasn't "Don't do that, use AI when authoring better" but "The reviewers are actually the problem, they're missing the AI train". And I see this in industry too.
I find it can often write correct code but not maintainable, performant, or reviewable code without additional human guidance. The "solution" frequently given is that humans don't need to maintain it anymore so its not actually a problem. But the agent can't be accountable for mistakes, so unless that changes or the risk of a defect is close to zero, one still has to put forth effort to keep the code maintainable.
To be fair, there are plenty of situations where throwaway code is perfectly fine and/or defect risks are low enough to make the trade-off worth it. I don't think a lot of developers are thinking about it in that context, though.
It can write correct code, but it's still really not good at that, at least without lots of prompting. In my experience, that prompting is usually just doing the design/planning work I'd do with or without AI.
I've said this before on here, to much derision as it turns out, but I write my best code in the car. Nowhere near a computer, no distractions, just point the car along the grey stuff and away from the green stuff and think about what I want to write.
Then when I get home, it's just a case of typing it in, which is the bit I'd love to automate away.
My experience with LLMs has been a bit like rubberducking code with someone who's *really* fast at looking stuff up on StackOverflow.
> They like their cute ASCII/unicode animations, don't they?
One of the few global Cluade directives I have setup is to never use emojis - and it never has, either in chat output or in code. Don't blame the tool when you don't spend 30 seconds configuring it. It's even easier with AI since you don't have to go digging for some obscure .vimrc snippet - it's literally just plain English.
Yes I basically meant those folks weren't very good developers to begin with and now extrapolating to: "wow this is better than all devs!", when it's more like "it's you, dude"
This sounds awfully like the people who think that self-driving cars and even auto-braking systems will eliminate all accidents, because everyone else is as bad a driver as they are.
Someone pointed out[1] a while ago that LLMs look good at things you are bad at. Which is I think one of the best explanations of why so many people disagree about how good they are at programming. There are a lot of people really bad at programming, and they will look at the output if an LLM and say “Wow, it’s so much better than my code!”
I've had a guy once reply in an email with a bug report generated by ChatGPT telling me that some piece of software I wrote wasn't working. He just plopped right there the discussion he had with the confirmation bias machine confirming 100% that what he had in front was sending spurious messages. With all the information in the world at its disposal, the LLM did not consider informing the reporter that maybe his code should flush the serial device pipe before starting his processing. I stopped short from facetiously replying to him that maybe he should use another model, since his seems to be broken.
I think that this is the essence of the argument. I spent two weeks of long nights across a few different sessions with millions of tokens generated, to produce a 5 page proof. I think we have come to the age of the aesthetics of curation. At least I don’t feel like I broke this silent contract. The effort you put in driving the torrent of words before distilling it is a new art. First time I tried it and it felt more creative than slop. The judgement nevertheless lies on the eye of the beholder.
Isn't this just a continuation of the performance art of the modern corporate environment though? There's an entire industry producing pages of documents which aren't read, aren't responded to, but need to be at least X lines long for anyone to take them "seriously".
Then suddenly LLMs happened and it's like the mask is off: no one's reading them still, but also no one is writing them either.
Which is perhaps a drop in the ocean of the insanity which is "we need you to work on the Jira tasks" as basically a job title.
You're absolutely right! The modern commercial sector has been writing bullshit, bullshit, and more bullshit, and become completely disconnected from the actual outputs of its work. And it has to be, because if only useful work was done, two thirds of the population would be unemployed without benefits and would revolt so they didn't starve.
They've still put more effort into writing their crackpottery than you will put into reading it, and at worst it's entertaining. The late Ivor Catt's articles on "the death of electric current" - where he expounds the idea that current and indeed electric charge does not exist, because of stuff involving Maxwell's equations where the maths looks about right to me but I'm not a good enough mathematician to prove - were pretty damn odd, but his writing in 1989 on how it would be vital for an interconnected network of computers for information sharing to treat censorship as damage and route around it and some ideas for doing this was bang on the money (as we now see) and his writings on how American business management methods result in the worst possible outcome for everyone that's not already a billionaire have also proven oddly prophetic.
So maybe there's something in the crackpots after all.
I wonder what I'm crackpotty about? Forth, probably, although I did actually port Dave Dunfield's 6809 Forth to a mid-1980s sampler. It boots off a floppy, I know what the memory map is, if it boots off a floppy I can make it run anything, right?
How about this crackpot view? Perl vs. Python, which I guess has been replaced by Rust vs. Go - I prefer Python and Go to Perl and Rust, simply because I know them better. If you want me to work in Rust or Perl I don't really care, they're just languages. I'm not as proficient in them, expect it to take longer. Rewrite it all in Rust? Sure. I'd prefer not to, but if that's today's project then shut up and pay my invoice.
Let's see, what other things are wild crackpot ideas around here?
I don't think LLMs are very good.
I don't think self-driving cars solve the right problem.
Permaculture would be better for long-term ecological sustainability and food security than "everyone should be vegan".
Bikes would work perfectly well in American cities if you used enough of them.
if anyones got an active issues list, the maintainers should close all issues and open only ones they intend to fix. A bot should repeat this message to the issuer and point them to issues they're accepting.
So at a minimum, you could maybe fish some useful work out. PRs should be the same.
> Back in pre-LLM days, receiving an unexpected pull request (PR) from a fellow coder was a source of excitement and pride.
As a maintainer of a few FLOSS projects, this tracks.
The Pavlovian PR notification response has gone from, "Oh! What do we have here?" to "Groan. Do we have _anything_ here?"
I won't get specific but I just had to remove a contributor from a project after multiple submissions of either cutesy, fluffy bullshit (add ASCI animations!) or "rewrite entire project in other language". Not only did the PRs result in wasted time and energy but they also resulted in conversations about how to deal with this sort of spam. (Probably good to get out of the way and set policy but still...) So, this person probably spent fifteen minutes prompting together these stupid PRs and multiple maintainers had to spend hours agonizing over what to do about them.
TBH I never contributed to Open Source because of the effort needed to bring my PR from "works on my machine" to "compliant with the rest of codebase". Especially that I only want to implement one small thing.
There's one project where I need to download a new version once in a while and I just rebase my changes.
> TBH I never contributed to Open Source because of the effort needed to bring my PR from "works on my machine" to "compliant with the rest of codebase". Especially that I only want to implement one small thing.
That's a good thing; OSS projects don't want drive-by contributors, they want a community. A small bit of friction is a good thing.
After all, we can see what happens with frictionless contributions.
I some times will open a PR even if i know it will get closed, simply by because if its a bugfix or feature i want, someone else might do so too, and i have many times adopted code from PR's that were never adopted by mainstream or closed.
By pushing that PR, i might be annoying a grouchy maintainer, but at the same time helping tens or hundreds of other users of the software.
Imho the beauty of open source is as long as you're adhering to the licenses, you can do whatever the heck you want =)
If you already know it's not good enough, you can just say so by calling it a proof of concept or hack to demonstrate what needs to be done. Such code is often very useful when writing the real fix.
Yup, some of my first contributions when I was a teenager, was to an open source project where I was able to find a couple of bugs, and implement a hacky solution that I shared with the team on the forum. My code was absolutely awful, but by having done both the effort of tracking down the cause of the bug, and one possible way of fixing it (which was badly coded, but worked), made the developers able to quickly turn around and edit my patches into actual patches that got merged into the project.
And it was actually a pretty good feeling. Made me feel that even as a newbie programmer, I was adding value to the community, which I was!
I've done the same for a fix in the Gold linker, which is now obsolete due to even faster linkers being available. Shout out to Ian Lance Taylor, his behavior as the maintainer was exemplary: very gracious and very responsive.
I not trying to be mean about it, but... that's good. If your one small thing wasn't worth the effort for contribution then it probably doesn't need to be in upstream. Contrary to what many seem to believe, code existing is not inherently better than code not existing.
Actually it's good for another reason, and that's the very essence of opensource: the user can customize the software to their needs, but there is no obligation to participate in a community effort (although it's definitely cool as a side effect)
The thing is I totally, 100% get this. The other thing I can't help but see though is how excited my non-programmer friends are to finally be able to make software. The sense of pride and accomplishment from non-coders who are finally able to make something work the way they wanted to.
We almost need like ... noncanonical software? Not so much forks, but like ... Maybe software as like a cluster? an ecosystem? On-demand app store where features / forks are shared/upvoted/evolved by the community where the maintainers don't have to get burnt out, and when it inevitably becomes a ball of mud oh well it does the job? I really don't know!
I hope we can think about some answers and not get tribal though because this is really a huge problem and also a huge opportunity and so a minor reminder that there is a baby in that bathwater?
I agree. For many people, LLMs are the first time that computers do what they tell them to. Not what some big tech PM has decided is or isn’t possible.
At the same time, OP is in the right to reject contributions they don’t want. Nobody providing open-source software is under any obligations to take changes. Forking is still a viable option in 2026. And I don’t think we need an on-demand app store either because the trust issues will still exist for good reason. We can have highly produced software coexisting with LLM agents.
> For many people, LLMs are the first time that computers do what they tell them to. Not what some big tech PM has decided is or isn’t possible.
The crux is here somewhere.
A massive group of people (A), don't fully understand or care about code, but they care about arbitrary specific outcomes that serve their needs and desires VS a tiny group of people (B), who initiate, architect and maintain successful projects, who care deeply about the health and cohesion of the codebase over it's lifetime, because that serves everyone.
Group-A is now liberated for better and worse. For the first time they can force their will upon a codebase without understanding. They are making selfish changes, and that's fine, this is hacking for the masses. The problem is they still don't realise these are selfish changes, because they have not been forced to tread the path of the programmer to understand they are selfish changes.
The response from FOSS maintainers seems inevitable from this perspective... But I think what's going to be more interesting is watching how Group-A over time respond to creating their own personal hell.
As group-A accrete more and more unsupervised selfish changes into their forks - at what point will they implode and turn into LLM-token-tarpits, at what point will Group-A notice, and I wonder what their response will be.
Who gets a sense of accoplishment from prompting an LLM? Do you get a sense of accomplishment when AI draws a picture or writes a poem for you? I guess there are some minds I'll never be able to comprehend
In a pre-LLM world, a classic software team would have PMs, designers, and engineers.
Of those three, the PM wouldn't have any real role in writing code. And they would rarely contribute a ton to the design. What they would be contributing is ideas, market insights, coordination, prioritization, etc.
When the product ships, one would expect the PM to feel a real sense of accomplishment. They helped this idea become a _real thing_! All of that pride, despite not writing a single line of code nor polishing any pixels themselves. And I don't think anybody would reasonably look down on them for that feeling.
Same thing with using LLMs. Sure, you didn't write the code. But you caused the thing to exist! That's exciting!
It's more akin to someone commissioning a piece of art, where they describe the piece in varying detail and then it's the responsibility of the artist to see it through, perhaps deciphering ambiguities in the p̴r̴o̴m̴p̴t̴ commission brief.
If you want to stick with the PM analogy, it would be akin to the manager spending 30 minutes writing up a draft spec, passing it off to their employees and then spending the rest of their time watching TikTok in their office. It would be strange if they felt pride in that.
I think that's fair for certain one-shot generations. For example, sending off a single prompt to an image or music generator and just accepting the output.
But I think most of this stuff is iterative, multi-turn. You type a thing in, see what comes back, and then repeat until you have something that satisfies your desire.
Taking the manager analogy. If you spent 30-minutes writing up a draft spec, waited for the outputs, had a review meeting where you provided good feedback, and then repeated that cycle until the product was done... Again, I think that manager (assuming, of course, that their feedback was useful) should feel some pride in shaping that output!
What sense of pride an accomplishment do you get from using a library, or a high level language? You didn't write that code, you didn't hand translate into processor opcodes, etc. There are a million man hours of other people's work involved in making a simple python script run.
Given that any coding effort relies heavily on a much greater amount of work as a prior than the code you yourself are writing... Why do you feel accomplishment?
Making things is fun, using tools to make things can continue to be fun. I have fun woodworking with hand tools and I also enjoy using my CNC where the job permits. Both bring joy.
That's a poor analogy, because the intention is orders of magnitude greater on those things than with an LLM. You still need the intention to write Python instead of C, or C instead of assembly. You need an insignificant amount of intention for LLMs, which will happily spew code even for the worst, most incomplete or nonsensical commands.
I think most people feel pride when they put effort into doing something challenging and in return achieve a good result. You can use high level languages and libraries and still put effort into something that is challenging, thus feeling a sense of pride. Of course, they may feel more pride if they achieve the same result without libraries, or in a more challenging language.
Prompting an LLM neither requires comparative effort nor is comparatively challenging, thus it's would be odd to feel a sense of pride from any associated outcomes.
I cannot believe this even requires an explanation.
Developing a functional app that meets your needs with an LLM takes it's own kind of skill, and is substantially more difficult if you can't recognize when the machine is steering your architecture in the wrong direction. It takes actual, real work. It's certainly a completely different kind of work than writing most of the code yourself, but so is using Java when compared to hand writing x86 opcodes.
Prompting an LLM to produce good code isn't a lot of work for you. Writing hex without an assembler or compiler would be a lot of work for you.
People have ideas, and now they have better tools to turn those ideas into reality. They aren't doing it like you would do it, but they're getting it done all the same, getting their needs met, and enjoying the ride.
Maybe just let people have fun, and when they report that they are in fact having fun... believe them.
I'm not saying people can't have fun, I'm saying it's a misplaced sense of pride that gives me the ick when I sense it in others. I see plenty of people who readily disclose that their thing they "built" was just slopped together by an LLM and this is perfectly okay, because they aren't trying to take credit for accomplishments that they didn't put in the expected effort for.
The difference between the skill & effort required to build vs prompt your way to something is orders of magnitude different. If it took just as much effort, people would just do it by hand anyways.
I think “build vs prompt” is a false binary that frames the argument badly.
There are way more nuanced uses of LLMs than skill-free “write me a facebook clone.” Like, hey LLM, help me develop tests of X, review this design for X, help me articulate what is wrong with the code for X, give me ideas for simplifying X, suggest optimizations for X, help me debug this failure trace for X, help me apply this refactor across all of X, and on and on. Even these are stupid examples that way over simplify.
I’m super proud of the work I’ve created /alongside/ LLMs. I’ll let it build me development aides and such with little oversight and there’s no skill there. But you can use it deliberately and maintain control, and it’s amazing to have a tool that can look through your code with you from so many angles.
Yeah, there's something pathetic about being proud of something you didn't actually get challenged by making. Like, I love building Lego sets. It's relaxing, it's fun, and I enjoy having the completed model to put on a shelf and look at. But I would never in a million years say I was proud of those Lego models, or that I had a sense of accomplishment. That wouldn't be merited.
Don’t think of it as creating art, but as solving a frustrating computer problem. For people that aren’t technical, computers are often irritatingly obtuse and unclear if you’re trying to get something to work in a particular way.
1. There exists some X that you wish existed, but does not
2. The world has changed in such a way that X now exists
3. You took even a tiny action towards #2
Even if the main goal was #2, Is it really hard to see how there might not be some sense of accomplishment? Many investors take pride in the impact the companies they invested in have on the real world; this is the same thing in the small.
Back when image-gen was made widely available (2023ish, feels like eons ago), there were people who took genuine satisfaction with their art prompting skills. It did come off as a bit cringe though:
https://www.reddit.com/r/saltierthankrayt/s/KxwhqJ5hrU
That thread is hilarious. They update the model and the guy thinks his art skills has improved. Something to consider when someone tries to tell you prompting is a "skill"...
For people totally new, it can be partially understood, just as i was ecstatic having a tool create something on a computer for me in my early days.
For anybody else thought, I get that a LLM is a regression (npi) where you don't have to learn or understand anything .. therefore the personal growth value is moot (except the alleged sales if the person tries to use LLM to create a side business).
For actual devs it's disheartening and caused me real grief seeing how many of them were happy not thinking anymore.
It doesn't even matter and isn't worth arguing about what emotional state the submitter obtains. I don't care if they even achieve nirvana and ascend to permanent buddhahood.
What matters is that they are wasting the time & patience of someone who is doing good work that others benefit from.
Any happiness gained from doing that to someone is parasitic.
> Who gets a sense of accoplishment from prompting an LLM?
I have a good friend who is a VP at a telecom company who has never written a line of code. He's been using Claude to create interactive web pages to help him understand parts of the company.
He was so excited when he got something to work he called me immediately.
I'm sure the code isn't what you or I would write, but it is good enough for my friend. That said, heaven help him if he loses access to Claude. ;-)
I'm a professional software engineer and even I get excited about having an ai vibe out some throwaway software for me (two recent examples - a personal recipe site I never made time for and a video game skill tree build tool that isn't worth the time it would have taken to build).
As another commenter said, for a ton of people this is the first taste of the computer working for them and being able to dream something up then have it exist. This is very cool!
That in no way invalidates the concern of amateur slop going to maintainers! I think the problem here is we as society haven't caught up to this new idea of personal software vs community (architected, maintained) software. We're so early in this space we haven't even figured out the good ways to do such a split - even the totally new to software folks are bleeding edge early adopters.
After trying and failing multiple times to get any LLM to create exactly the picture that I was trying to make, I have to admit that, at one point, if one of them had succeeded, I would have felt a quantum of accomplishment.
But, since I'm not that much of a slot machine aficionado, I just completely stopped pulling the lever.
However, I can see that for the right people, this level of difficulty might encode or mimic, purposely or not, many of the features that are collectively termed "gamification."
I think there's a spectrum between simply writing a prompt and generating slop and using AI in a loop over many hours/days/weeks to produce something that works the way you want it to. I get a great sense of accomplishment from doing the second, and I pretty much refuse to do the first, except only in the most ephemeral of cases.
Do you think people in product design never feel a sense of accomplishment or something?
Or for another perspective, why do you think a "sense of accomplishment" is an essential, and dominantly important thing for everyone? Maybe they feel two hot shits about such a thing.
Especially when the "accomplishment" in the vast majority of cases is in the realm of "having had the patience to endure the humiliation ritual of figuring out the arbitrary abstractions some other dude came up with, and doing the plumbing to reconcile that with the requirements to the extents possible"?
When I make things, what I care about is exactly the function they provide. It's endlessly rewarding to make something useful. It's not some exercise in polishing my ego by proxy. I don't want people appreciating the things I make because they were hard to make. That's borderline condescending and pitiful.
But hey, maybe I'm mischaracterizing the way you meant "sense of accomplishment" myself. Maybe this is exactly what you meant too. But then how would people vibecoding be robbed of feeling this? Makes no sense.
If you scroll through any personal finance forum every year someone will discover the forum and excitedly share their customised budget tracking sheet they built from scratch and it works exactly as they wanted to. How many do you think even get 1 upvote?
Everyone building a software will just mean people can produce code which others might not really care for and might even be particularly be mean. That’s how the Internet works unfortunately.
The current logic seem to be confusing two things. One AI as a technology and wisdom of the crowd using AI. One might ground breaking tech and improve over time while the other might not move the needle at all.
A customized budget tracking sheet is the personal finance equivalent of a programmer showcasing their TODO webapp. Obviously it's going to be incredibly unpopular. Yet, there are popular tools people have shared in personal finance communities.
What is the kind of person who would use such software? What you’re describing is the need for a two sided market where really only one side exists.
A user would have to be someone who doesn’t have access to an LLM to make bespoke software themselves, and isn’t able to use existing software. I think that’s a vanishingly small segment of people.
Sounds like the user could just ammend the software to his need with the LLM, but instead of sending that update to the maintainer with a pull request, just keep it to himself, to the users version.
You're assuming that everybody will be equally skilled in using an LLM to create software. I don't think anything in my experience indicates that this is true.
https://www.robinsloan.com/notes/home-cooked-app/ This has never been truer than right now. What we need isn't app store ecoystems but to eliminate the friction for distributing apps to your inner circle. We're entering the WhatsApp era of software, where everyone is going to be using a home cooked version of every piece of software that can conceivably exist on an island, and it's going to be a vibe coded mess, but it's going to be lovingly maintained by the people that use it every day. This is why I'm bullish on things like https://sprites.dev/ (not affiliated, just a customer). I have a little self replicating starter template that lets me quickly stand up new sprites with all my stuff logged in, ttyd + tmux so I can run claude code in the browser from my phone, and a caddy reverse proxy so I can also host a little starter app behind the fly io relay that sprites get out of the box so I don't have to do any extra work to have a publicly accessible https url I can send to people. Using this set up I've created dozens of little silly web applications for my family and friends, none of them were more complicated than little sketches but we've gotten some real pleasure out of them. There's still quite a bit of friction here though and I think if someone can really make this seamless for people they'll have something really special.
As an example, the android options for printing to my outdated brother printer were all terrible (ad supported nokoprint for example), so I used my template to create https://print.walden-gabrielw.workers.dev/ (This one a put a cloudflare worker in front of because it's just a static html+js page and I didn't want to pay for uncached traffic but the principal is basically the same). No one will likely ever use this but me and my wife, but the cost to keep it up is basically 0, the cost to build it was very reasonable, and if it ever breaks I'm fairly confident the latest LLM will be able to debug it without too much trouble.
> The thing is I totally, 100% get this. The other thing I can't help but see though is how excited my non-programmer friends are to finally be able to make software. The sense of pride and accomplishment from non-coders who are finally able to make something work the way they wanted to.
You absolutely don't need LLMs for that.
Its the very description of most corporate JavaScript developers, and probably most Java developers. I say that as somebody who wrote corporate JavaScript full time from 2008-2023. Most of these people had no idea what they are doing. They could throw something together using their favorite abstraction library/framework but then struggled to maintain it. If there were performance or accessibility problems that came up there were only three outputs: hostility, crying, or starting over from scratch. The insecurity was real. You can still see it today. As an experiment take React away and note the response.
> I hope we can think about some answers and not get tribal though because this is really a huge problem and also a huge opportunity and so a minor reminder that there is a baby in that bathwater?
I think no answers are needed.
If anyone can build the software they need, no ecosystem will be needed. There will be no maintainers because no one will be using his thing.
If it makes sense (economical, but no limited to it), then it will progress in that direction. If it makes no sense it is a fad that eventually dies out.
There may or may not be a baby in the bathwater. In truth nothing in this bathtub matter too much.
I think this makes sense for apps, but the apps will still need infrastructure and common protocols to interoperate. It still won’t make sense to implement your own cryptography.
If you can vibecode your app, you can vibecode your cryptography as well.
You may object to it but that, too, would be elitism. And the person vibecoding has no idea why proper cryptography matters anyway. Or why proper anything matters.
This is the ultimate realization of "my ignorance is as good as your knowledge".
I do a bit in my IT classes where I show a "spectrum" of computer activities, from "changing a screensaver" to "Assembly" and then challenge people to find the line where "using a computer" stops and "programming a computer" starts.
It was already very fuzzy (Excel?). Soon, this line be non-existent.
As soon as you’re specifying instructions for the computer to do a task automatically, you’re programming it. It can be recording a macro, writing a script, describing it in something like Shortcuts,… The core thing is automation.
Copy-pasting is not programming, no more than clicking the save button is. But text expansion may be seen as such, especially when it involves dynamic elements (like current date and time). It may not be a clean delineation but, IMO, it's the difference between writing a recipe and doing the dish. Copy-pasting twice is making a dish. Creating a button that let the computer do it is writing a recipe.
...maybe some sort of "Software Bazaar", where the users of the software can edit their own software and make local modifications that they need to it, probably with NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
It'd also be really nice that if you received some such software that you'd have the right to run the program as you wish, study how the program works and change it to make it do what you wish, and the freedom to redistribute either the original, or your modifications to the software?
> The other thing I can't help but see though is how excited my non-programmer friends are to finally be able to make software. The sense of pride and accomplishment from non-coders who are finally able to make something work the way they wanted to.
There was nothing stopping them from making software before... Over the past ~15 years, the amount of resources to learn programming, and to make the whole process approachable, is staggering. It just took some time and effort. People are just excited that they can skip past the effort part now. But we've lost something in the process.
I mean, I largely agree with the sentiment (friction is important for growth/happiness, after all). But even as a developer, I'm able to quickly whip up custom personal apps that I just wouldn't be able to justify the time for previously.
Our CEO just took a design mock-up of a new landing page and threw it into Fable, and it spit out an objectively better iteration of the component's design. The hierarchy made more sense, the typography was more polished, and it naturally incorporated some elements we hadn't added yet.
We won't implement everything it changed of course, but it's the first time I've seen a model take a decent draft of a webpage mockup and improve it in a way that feels like a more evolved version of the original instead of just LLM-ifying it.
Huh? The difficulty and the cost was stopping them before. It was really difficult, took a ton of time and money, and you had to deal with another person.
Maybe building something? It doesn't matter much that the programming language was English and built by an LLM and a harness. They created something they wanted that wasn't there before.
It does matter. Drawing a stick figure and having a machine print over it with a realistic image doesn't make you an artist, and no, you shouldn't be proud of it.
No, but come on. If you insert a computer into your brain and wake up tomorrow speaking German, would you be proud you could speak German? Wouldn't you rather work diligently to learn the language and be proud of that effort?
Depends on why the person is wanting to be able to speak German.
If you only want to speak German for its own sake, then maybe it does seem silly to be proud of what the brain computer did for you.
But there are many other reasons to want to be able to speak German. Thanks to his brain computer, a French cheese maker could travel to Germany to promote his cheeses in a new market to great success without having to rely on the German speaking skills of expensive to hire people, and without wasting years to learn German on his own when all he wanted to do was to make cheeses and grow his customer base for his cheese. German in and of itself was never a goal to him.
Just like computer programming is not a goal in and of itself to a lot of people, and who would otherwise have to spend time to learn programming instead of doing the thing they want to do, or having to hire software engineers that might cost more than they could ever hope to afford.
And even though the computer is doing something for the person, they are leveraging that for something that they feel pride and accomplishment in. Such as for example to use German (done by the computer) to expand your cheese customer base into Germany (your own accomplishment that was only possible thanks to the existence of the German speaking skills of the computer).
Absolutely -- why on earth would I spend more time and effort than I have to?
Now I can focus on the reason why I wanted to learn German in the first place, like appreciating German culture or talking to German people.
Note this is not saying "why learn the language at all there's a translator" since learning a language lets you experience the culture more intimately and communicate better -- lots of things are "untranslatable". But if somehow the implant gave you that necessary context, why not?
Call me old fashioned but I take pride in things I work hard to achieve. I think it's embarrassing to be proud of AI output of any kind, be it software or art or writing.
I mean yeah? Wouldn't you be more proud of your ability to write a program in machine code than you would in assembly? Or more proud of assembly than of C? Or more proud of C than of Python?
Each stage takes greater effort, effort which creates skill. Those hard-earned skills are accomplishments to be proud of.
And I’m sure ctoth’s non-coder friends will be just devastated to hear that some random online account is embarrassed because they’re proud of a little app they created for fun.
I get where you're coming from, but for completely non-technical people, it seems to me the more precise analogy is not "building" but "ordering online". Or hiring someone to do something for you.
If you order a pizza from an app, and assume you can pick ingredients from a checklist, would you consider it "making" a pizza? Would people get the feeling of accomplishment?
That's a better analogy than my dumb drawing one. You can be happy you got your pizza and you can enjoy the taste but it is not an accomplishment to be proud of.
It's mostly that how much you decide to involve AI as a spectrum. To extend to the pizza analogy, I feel like you're telling me that because I used dough that I bought at the store, I shouldn't be proud of the pizza I made, even though I made the sauce and cut the pepperoni and the sausage and baked it myself on a peel covered with cornmeal. That's not the same as just ordering it on DoorDash.
Agreed there are nuances, but in the context of this conversation about TFA, the suspicion is that this is mostly on the "100% AI" side of dial. There's also a "high volume, low quality" aspect to the PRs, as evidenced by the fact that the bots (or humans) don't read or follow the repo's contribution guidelines.
The very concept of "reverse centaur" implies a balance towards the "order pizza online" side of the equation.
The pizza analogy smuggles in this idea of cheep/mass-produced. I'm talking about blind people who can now prompt their way to an accessibility mod for their favorite game, the sort of thing which literally would have never been written before. How you know it wouldn't've been written is by counting the accessibility mods pre and post LLM.
Now generalize this. Every tiny community, every person with a disability, everybody for whom the default software doesn't work right? Can now change it specifically for them. Not add peperoni, that's far too low-dimensional to capture what is happening. Actually build their own interface, be able to use something they simply didn't have access to before, and critically not depend on another programmer (there are like a dozen of us blind ones!) to build something for them.
It's not about cheap. It's about ordering vs building. If you tell an architect and a bunch of workers to build you a house, even if you pick some details and make some choices, it's them that are building the house, not you.
You can feel happy about the result, you can find the house useful, but you shouldn't feel a sense of building accomplishment, because you didn't build anything.
With AI & apps there's less friction, because you don't even have to hire another human being, it's just prompting. In that sense, it's definitely closer to ordering food from an app.
In any case, in the context of TFA, there's also a sense of low quality, cheaply made. The bots making the PRs aren't reading the contribution guidelines, so that's low quality all by itself. Drowning a human reviewer with a mass of PR is also a low quality way of contributing.
So I am thinking this is like an army of plebs going to Home Depot, buying power tools, and building a house with no experience. Oh what fun—we can finally build a house the barrier has been broken.
This analogy makes no sense to me and honestly skews pretty elitist in vibe. iPhone is regularly used in professional videography now. Like, 28 Years Later was shot on iPhone. Indie filmmakers have been using iPhone to break into the industry for years.
the analogy would be that your LLM/agent has a pass at a Spielberg script and peppers his inbox with inane production notes. A system like that would be untenable for all involved.
I think the attitude frequently adopted by open source maintainers - comparing themselves to Spielberg - has been a major roadblock to anyone looking to contribute to open source projects for years.
Agree that even prior to LLMs those projects weren't terribly welcoming as per Linus' famous email comments (chalk it up to cultural communication differences :) )
I don’t know if it’s just me, and these days I do understand it given the widespread adoption of LLMs, but I’ve always detested the idea that I need to reach out and have a conversation with the maintainer before opening a PR. Especially (mainly) when the PR is simply addressing an approved GH issue.
I’ve had so many perfectly acceptable PRs rejected over the years simply because they didn’t “fit the vision” of the maintainer, despite being +1’d by many members of the community or even other contributors. I don’t even mean to imply they were rude or anything, just uninterested in actually merging anything where they didn’t architect the changes themselves upfront.
On one hand I get it, you’ve spent so much time building something it’s fair to want to hold on tightly to that level of control, but to me it's just always felt antithetical to the entire idea of open source.
Makes me feel like I’m not contributing to a true open source project, just doing free labor for someone.
Why are you looking to contribute to open source projects? If you have a fix or a new feature, you can share the diff in variety of ways. The maintainers are not obligated to review, discuss, and accept your changes.
I’m not entirely following you. I generally don’t contribute anymore, but in the past I’ve found a lot of maintainers are not actually looking for collaboration, rather free labor.
I certainly understand things are different nowadays, I’m talking pre-LLM proliferation.
> I’ve found a lot of maintainers are not actually looking for collaboration, rather free labor.
Do you think that maintainers lack domain expertise? A nice bug report is way more helpful than a random pull request. A patch, even when correct, can be counterproductive, if it conflicts with the roadmap and goal of the project.
The goal of open source is to give you freedom in maintaining your own version and extending it. Collaboration is not a requirement.
If you think filming is the only skill needed to make a film, may I suggest looking at the very long list of names that appears at the end of the film of which only a few actually do filming? Takes a lot to know what to film, and how to be good at using the tools you have.
Similar is true for a lot of software. Credit list on video games… I don't want to say it "mostly" isn't coders, but only because I've not done an exhaustive study. My guess is the top will either be QA or art.
Artists of all stripes (including audio, animation, cinematographers, lighting, environment, textures, etc,) including tech artists, designers, writers, musicians… the ratio of functionality to look-and-feel is dramatically different than in non-entertainment products, and the labor involved reflects that. It’s a real shame that some of the people that contribute most to what makes a game great are often the first to get dropped when people talk about how the game is made, (but most are perfectly happy to fly under the radar when a bunch of entitled kids start raging about the “lazy devs.” ;)
Exactly - it's just a tool. So, trying to make the argument that someone's work is less-than because they used a cheaper/more amateur tool versus the tool the well-funded professionals are using _is_ elitist. You recognize that, but the comment I replied to centered on the tool, not the finer points of professionalism.
But on that- whether folks have knowledge and taste, demonstrate responsibility for their impact, pay attention to their work quality, show up to the work environment with respect, etc. are all elements at the domain of human relations. This discussion is conflating how people use tools with how people work with each other. The tools don't matter here. I think we're sayin' the same thing.
> So, trying to make the argument that someone's work is less-than because they used a cheaper/more amateur tool versus the tool the well-funded professionals are using
No. Just the fact that they have a tool does not automatically make them a professional, doesn't automatically make them skillful, and doesn't automatically make their output worth something.
This is the meaning of "When they shoot a little artistic clip with their nice modern iPhone camera, it does not mean they get to insert it into a Hollywood movie."
Using Apple’s preferred practice of using no article before iPhone (ie. never “an iPhone” or “the iPhone” or even “iPhones”) makes you come off as a shill, by the way. It’s like if you unironically put a trademark symbol after it.
You can make art with a literally piece of shit, or a toilet if you want to be more traditional, at least in 1917.
You can't be a craftsperson without mastery of your domain and its tool.
You can be a artist without craftsmanship and vice versa.
You can also be popular without any or both of these.
There is a lot to entangle there but the point is that it depends on your goal. You can judge others based on your own value system but there goals might not be yours.
I think a better analogy would be commissioning an artist to create a painting. Yes you provided instructions and decided which style you preferred, and maybe pointed some corrections you wanted. And you can be proud of owning that specific, unique painting. No you didn't create anything.
I - and many, many others - learned flask from his mega-guide that he obviously spent a lot of time working on.
I feel bad for people like him who get the brunt of dilettantes who can "code" polluting his time and focus. Reminds me of that mitch hedberg joke: "When someone hands you a flyer, it's like they're saying here you throw this away." but for PRs
I recently built a very large test bench for System Verilog.
I ran a bunch of different compilers on it, including some open source ones.
Some of them failed some tests, and it was natural to have my LLM (Claude Fable 5) root-cause the issues, and to double-check my test bench wasn't to blame.
But now I stood with all these patches that I couldn't just throw at the upstream maintainers all at once. I ended up just filing a few issues and moved on to other things.
It felt weird to just file issues when my LLM had already spent a lot of time root-causing and fixing the issues. But then, maybe they could just have their LLMs do the same.
> I ended up just filing a few issues and moved on to other things.
This is the most valuable contribution you had time for, hopefully with a minimum-viable bug reproduction.
Drive-by patches/PRs are usually a net-negative because the maintainer has to reverse-engineer the intent from GenAI code, and then make changes to have it fit in with the rest of project.
> It felt weird to just file issues when my LLM had already spent a lot of time root-causing and fixing the issues
There are countless ways to fix any issue, and only a few right ways (subjectively). The maintainers' role is to decide which ways are right for their project. You shouldn't worry too much about "wasting" code you already generated, GenAI made that step very cheap, but did little for taste and roadmapping.
> My perception is that there is less interest in open source, and in coding in general. The main reason I love coding is that it is a challenge, and I think this is actually the same reason why a lot of people prefer to give money to an AI lab and get a machine to spit out code for them, even with the risk of the code being subpar.
I maintain the hope that those technically minded who are really interested in coding and care about doing things properly using their own reasoning on all levels of detail will find each other and maybe become less diluted as a community by the coding-just-for-money crowd than in the past decade or two.
Even if this guy were not anti-AI, as the primary maintainer of OS projects, it sounds like he's dealing with a genuine problem.
> My initial task when a new unexpected PR arrives is to determine if there is a person behind it or not, and luckily this is easy to figure out in just a few seconds.
OK. How? That would have been an interesting explanation to me.
If someone goes out of their way to hide it, it probably can't be detected. But the default commit comment and PR writeup styles are pretty distinctive.
Don't blame the people who dislike AI, blame the people producing AI and using it to produce mass amounts of trash. They're the ones poisoning the public well and making all of this distrust necessary
I didn't blame anyone? I judge whether an article / repo is AI-generated by vibe too. Vibe/intuition is the essential part of our daily lives. It's the #1 think you ask yourself in an interview.
Asking contributors to first make sure there is an approved requirement before creating a PR sounds like a great idea regardless of the use of LLM.
But another issue is - AI disclosure (agent, model etc). I'm sure others tried similar approaches, but in case this is not common knowledge - I tried to see what happens if you ask agents to disclose themselves in the PR description / comments in a rule file.
It seems to work pretty well as most AI "assisted" PRs will be opened by agents using the gh cli or MCP on behalf of the user. (Of course this can be bypassed, but for someone who doesn't mind disclosing or doesn't care, this is a good step forward)
> Generative AI notice: I do not use LLMs, agents or any other generative AI tools for help with writing, coding, image creation or any other tasks related to this blog or my open source work.
This reminds me way back when you would see "Website written in Notepad" on websites.
We had a process at one company where you had to create an issue before filing a PR. I found it most non-sensical and introducing friction for no good reason. Very surprised to see the author suggesting it in the article.
Review is indeed the main bottleneck now for open source, and we need to solve it. Introducing more friction is hardly helping.
The author is describing a method for turning a low trust/no trust environment into a slightly higher trust environment.
A company is usually already a high-trust environment, where people use real names and have real reputations. So creating an issue cannot serve the purpose of increasing trust.
I think the point that he is making is that the additional friction is a good thing and necessary in this case because it's an open source project. It's too easy to do drive-by PRs that don't actually provide value and just eat up review cycles. The issue requirement simply ensures that the requester actually is invested and cares enough about this to get approval before starting work on it.
I can see why that doesn't sound great particularly on a team where everyone knows each other and is working together but it totally makes sense for me if I were maintaining a project that was large enough to get a lot of low-effort PRs coming into it.
In my opinion review will always be a bottleneck, in OS as well as in commercial development.
To my understanding Code Review is first and foremost a trust-building exercise, seeking to establish common understanding behind the piece of code which is to be delivered. That it also may lead to improvements or "catch some bugs" is a distant tertiary side-effect, not the primary goal. At least this is the vantage point I reviewed any code from in the last two decades, and found that team morale and overall quality of teamwork - and delivered software, and customer satisfaction, as a result - responds very well to such interpretation. Regardless of the side you are on and competency level of your vis-a-vis. I would put "elevating competency level of both partners" as a secondary goal of Code Review, and very closely connected to the primary.
With current crop of LLMs there simply nothing on their side to which words "trust" and "understanding" can be meaningfully applied. Hence the "review" takes drastically different shape and implies very different goals. As both the primary and secondary goals described above cannot apply too. The only remaining goal of "improving and bug-catching", in absence of trust, understanding and learning, now requires much more work, which is also much more exhausting.
And a follow-up to my comment above, as wanted to reply to "create an issue before filing a PR" remark too.
I find it actually extremely useful practice. We engineers tend to center our thoughts around "code" and with such code-centric mindset to accumulate knowledge as "code-adjacent" - in repo's commits, PRs, markdown files of all sorts. But in reality most if not all projects extends past the code, and it makes much more sense to have a "project-centered" mindset. As such, an external "issue" captures much more context and provides more useful insight about project impact than PR description alone. Love or hate JIRA, beyond microscopic solo-projects it makes full sense to use broader-scope external tools for project management.
As a nice cosmetic effect it also removes (some) bickering about whether to put "type" or "scope" first in the commit message :). Simply provide a reference to the ticket! (No, really, I hate JIRA, honestly!)
We had that process too, and I insisted on it. Any PR not matched to one or more issues gets automatically rejected. The friction this injects ensures people are not wasting company resources bikeshedding.
I'm a world champion bikeshedder, and I both hated this policy and insisted we keep it.
The article closes with the question: "Does open source matter anymore?"
I wouldn’t pretend to have an answer. of course. Opens Source means, always meant, different things to different people.
I know what always counted for me:
1. Copyleft License
2. No CLA or Copyright assignment
3. Diverse group of contributors
I sympathize with Miguels point but it bothers me it clashes with point 3 in my list. If you hand select your contributors[1] you will never reach the diversity necessary to effectively make relicensing impossible. Without that Open Source matters less to me.
[1] I admit that controlled set of known contributors has other advantages too.
Because having more powerful tools is a different problem from using them well.
When GUI apps first made it easy for anyone to use 100 fonts and colors in a document, it did not make the quality of design go up. The tools became more powerful but the average quality of design went down because lots of people with less skill could suddenly participate.
Same issue here, two things are true at once. Models and agents are very powerful, and it makes it possible for less skilled or less conscientious developers to increase volume of low quality PRs.
GitHub Issues before PRs is a great approach. The ghostty project takes that one step further: GH _discussions_ before GH issues. Only maintainers can make issues.
I totally understand the point of view from maintainers. Review fatigue of low quality slop is a legitimate issue.
The worst ones are fully autonomous AI agents looking for open source projects and adding random pull requests.
But in some cases, I find a legit bug that needs fixing. For example, I want to get a particular program working in Wine/FEX on aarch64 [1], or I find a 12 second hang in Darktable [2]. The problem is that, as a software engineer working in a totally different discipline, I have no knowledge of the low level C code to fully understand what the problem even is, or how to fix it. All I want to do is to fix the issue and help other people avoid running into the same issue. Right now, on my machine, I maintain a set of custom patches to get everything working. But I am too dumb and ignorant to figure out how to create the fix by hand, so I can't submit a pull request (or when I do, I feel really bad about it. I honestly feel like a horrible person, e.g. when a project added a "No AI" policy soon after I submitted some AI-generated PRs [3]). Going forward, I feel like this sort of scenario is going to be way more common.
Then say all of that in the issue. Say you have a real problem. Say you tried using AI. Add the human element by communicating. I dont think there is a real problem there.
People just want to know you put in the effort, and that you didnt just prompt an AI and hand over completely unchecked slop.
It seems like there is a ready solution here, have an LLM review and filter pull requests from unknown sources before you read them. My understanding is there are semi-reliable ways to detect AI writing, maybe there is an analog for code. In any case, you can filter according to criteria you set. Analysis and bug-finding is where LLMs shine, much more than their ability to generate code.
I can understand wanting to minimize your interaction with LLMs, so this might not be an attractive solution. But it seems like a worthwhile feature to have on the platform level for people who would like to continue to accept pull requests without the frustration.
"AI-detectors" are still probabilistic and none of them are exactly stellar. (No, even Pangram. It still screws up on the regular, very badly.) And some of that includes calling real people's writing "AI-generated", which isn't acceptable for this task.
A reverse centaur is just a person with a horse head right? I don’t get the analogy. I understand he’s talking about getting pushed around by an LLM, but would a normal centaur push an LLM around? It doesn’t even have any hands right? Seems like a reverse centaur is more capable of typing.
> A reverse centaur is just a person with a horse head right?
Well, no. A centaur is a normal person with stronger-than-human legs. That is, it's an augmented person who drives the powerful machinery underneath. Think of a person driving a car.
A reverse centaur is the opposite, namely, a machine making the choices and a frail human following them. In this context, a reverse centaur is an AI spitting thousands of LOC for a human to find the good ones.
The question that resonated with me was whether open source even matters anymore.
I think it does but there are weird dynamics I don’t fully understand. I’m curious about HNs thoughts.
My theories: Centralization around key projects due to AI pointing new users towards them. (At the same time this drives up the PR deluge onto these projects. Especially from newer users already heavily using llms.)
So many low effort AI-generated open source libraries that it becomes harder to tell signal from slop. More movement to the bigger projects because they are perceived as safer bets.
I think the answer to this question probably doesn't exist and opinions will remain divided. I can understand this person's feelings. But I 'won't be able to feel them' because I'm in a different position. The technology this person takes pride in is directly affected by AI.
On the other hand, there are also people who start coding with AI, and those people will love a large part of code that isn't pretty but works.
Some will say that messy code will ruin software in the long run, while others will think otherwise. This reminds me of Sturgeon's law: 90% of everything is crap. This means that for any type of thing, there are quality items and inferior ones, and quality items make up about 10%. The 10% of code created by AI will be valuable, and only 10% of human-written code was valuable. AI has just increased the amount of crap.
Whenever I think about these issues, I always think of Undertale. Undertale's code is overwhelmingly messy, yet it's a masterpiece often cited as one of the best games. I love it too. But Leaked Undertale code (its quality) is terribl
Ultimately, it seems that AI's usefulness and harmfulness are determined by the purpose for which it is used.
If someone enjoys code quality, long-term perspective, and intellectual exchange and interaction with people from these kinds of discussions, they will be hostile toward AI.
On the other hand, someone like me, who is in a community that has a hostile attitude toward on-time delivery for clients and learning (based on mockery and disregard), will be receptive to AI.
Honestly, I am a direct beneficiary of AI. I'm on the side of consuming the results managed by open-source maintainers, so I can't fully understand their position. I just think, 'That must be incredibly hard for them.'
In my case, AI writes English functions and documentation, and by using AI to refactor English function/variable names that were previously hard to use, I can now write code that's easier to read.
But since my role mainly involves assembling things using IoC on top of frameworks, I see more advantages. The downside is that my coding skill declines, I suppose. I'm a traveling contract programmer who often goes on-site to work with legacy codebases and add features to them.
Actually, my workflow hasn't changed much. It's just that the legacy codebase has become an AI-generated codebase. My workflow of debugging and tracing the flow there hasn't changed, so I'm probably in the beneficiary camp.
Conversely, people like the OP have seen a massive change in the number of PRs they need to handle, so it's understandable. The intellectual exchange with people they've always had, and the values that come from that, have been damaged.
On the other hand, there’s nothing more frustrating when I submit a hand-written issue to an open source project, happy to implement it if they approve, and then their bot closes it with some AI slop comment that indicates it has no idea what I’m talking about.
On the plus side it’s easier than ever to patch or fork projects. So at least this toxic gatekeeping behavior matters less than it used to.
Considering that the whole industry, including the big AI companies, is built on top of open source now, I would have to say it did matter. That doesn't mean every project mattered (in a larger sense), but certainly thousands of open source projects have value, and dozens have contributed enormous value. The fact that the value has been disconnected from the maintainers has been a problem for a long time, but it is getting worse, and this is one example of a maintainer near the breaking point.
To me the "open source" model implies something about community development and people sharing or otherwise using it. Otherwise what does it matter if it's open or closed source?
As a systems engineer, ive been a reverse centaur more often than not.
I have a Jira queue. It drives what work I do. I may have some leeway in how I do the work, and what tickets I pull, but Im absolutely at the behest of the ticketing behemoth.
Tickets have been my life since I started helpdesk. And future roles will also be ticketed. And they almost all are customer-facing or system-breakage (which impacts lots of customers).
Im not sure what IT roles im capable of doing wouldnt have tickets. So, yeah. Reverse centaur.. But not an AI driven reverse centaur, yet.
Reverse centaur means a machine is using you to get things done. Presumably at the other end of the ticketing system is other people. So not really the same thing at all.
I look at at reverse centaurs as a spectrum of autonomy at work.
We can now observe a complete reverse centaur. But those of us who go ticket after ticket, metrics of tickets, response times, and all of those management metrics also go directly to reverse centaurs as well.
Now, its not Marshall Brain's "Story of Manna" level each listed action at a time... But it was definitely getting to that point.
Call centers were already absolutely at that point, with completely scripted communications, that that attendant could not deviate from or be fired.
> Presumably at the other end of the ticketing system is other people.
Sometimes. As a systems engineer, tickets can also be generated by other systems as an "immune response" to detected but unfixable errors.
To respond to the ending of this piece, I think open source still matters because LLMs generate very specific code for a specific situation. Quality libraries mean solutions can be reliably shared between projects.
But how do you tell quality libraries from LLM generated ones? How do you even discover up quality libraries if you are leaving so many code decisions to LLMs? Once the LLMs train on your quality libraries how do you stop so many copies just getting pasted into people's code without your attribution and without directing people back to your library (and your very human interests in funding development on it or getting copyleft contributions back to it)?
I think there are so many hard questions right now for "Does open source even matter any more?" and many of those questions seem particularly demotivating to me right now, especially because we don't seem to be at risk of getting some, much less better, answers any time soon.
> how do you tell quality libraries from LLM generated ones?
Reputation. LLM libraries can also be high quality in theory. It's the level of effort, duration of use, stability, and test coverage. People will need to resist using LLMs to make huge transformations of their libraries all the time to avoid erasing their reputations unless they have convincing safeguards like comprehensive tests or formal proofs that are not touched.
> Once the LLMs train on your quality libraries how do you stop so many copies just getting pasted into people's code
Those copies are not reliable like a callsite. Maybe there is less advertising... but it is still better to use the library. I have to hope that at some point AI psychosis will end and engineering, which has not changed, will remain. You have to have reliable inputs to your processes. To do otherwise is insanity.
> getting copyleft contributions back to it
This is a hard question. That said, for my own libraries, I get very few contributions but people use the libraries! The more "hardcore" the library is, the higher the ratio of users to contributors because they're just not expert enough to contribute meaningfully (until your stuff becomes so valuable companies sponsor teams of contributors as in Linux).
That said, my libraries seem to have made it into the weights, so when I talk to LLMs about my problem space they shockingly frequently recommend my own libraries to me (which is kind of ego stroking not gonna lie).
I think there's a lot of reasons to feel demotivated right now, but my perhaps privileged attitude (since I don't have bosses forcing me to use AI for everything) is to use AI where appropriate and apply engineering discipline and thinking in all cases. Retain your own human skills. If expertise really does become completely devalued, we're going to have bigger problems than you can solve on your own.
I agree with the core maintainer complaint here: PR slop is bad, and maintainers should not be forced into reviewing code the submitter does not understand.
But I think the answer is not “don’t slop me, all you sloppers.” The better answer is closer to: “what problem were you trying to solve?”
There is no obligation to treat every PR as merge-ready code. A PR can also be a concrete issue report or a proof-of-concept for a bug. It can say: I found a problem, I investigated it, and code was the clearest way to show where I think the issue lives and how it might be addressed. Use or ignore the implementation as you like. Human-language descriptions are not always the best way to communicate something you've already traced through the codebase.
That can be a high-value contribution even if the code itself is not accepted. It moves the conversation from “I want X” to “here is where X touches the codebase, here is a failing case, here is a possible direction, here are the tradeoffs I noticed.”
The social contract should be that the contributor does not dump review debt on the maintainer. Mark it as a prototype. Explain the problem in your own words. Say what you tested. Say what you are unsure about. Be willing to revise or accept that the maintainer may throw the patch away.
But once framed that way, the relevant question is not whether AI was used. It is whether the PR reduces ambiguity or increases burden.
A sloppy PR that demands review is bad. A prototype PR that explains a real problem is often useful.
No one was ever stopping anyone from learning to program in the past. Don't act like there was some massive gatekeeper you had to overcome to learn to code other than your own laziness
I first encountered the following concept in one of Oxide's publications; good chance it didn't originate there though:
There is an implicit social contract with writing that the writer has put more effort into writing than the reader will need to read something. Sure you get crackpots still, but there are only so many Gene Rays in this world, so the volume is limited.
I think the same applies to PRs. Pre-AI , it was usually obvious when a PR was either completely terrible or very half-baked, and the required effort to create even a shitty PR was usually more than that required to reject it.
AI makes it trivial to make a completely terrible PR, and much easier to make a not-immediately-obviously-bad PR.
Given this, you can conclude that writers should be putting in at least at much effort as readers, whether or not they use an LLM. What really seems to be the problem is writers that don't at least check their own work, and pass that burden onto the readers. This is easier than ever with LLMs.
This is toxic behavior that unfortunately rewards a selfish writer. I'm worried the AI push incentivizes this too much, to where in corporate situations a reader can't say no to doing work for a selfish writer.
Its exactly this. I have had a few LLM coding sessions where I reviewed the resulting work and thought "I don't think my team can safely PR this." I then went back and broke it down into smaller PRs, still using LLMs but at a size that is easy to review. And I reviewed the output myself before I asked a reviewer to commit their time.
The problem is that this is increasingly seen as a non-productive workflow slowing everyone else down, so the pressure is growing for writers to just shove massive PRs out the door and reviewers to use LLMs to make that tractable. I suppose those advocates have more faith in LLM output compared to humans than I do.
Thats the thing with giant PRs. They never really needed to be reviewed anyway. In cultures with strong review culture I have worked at, if you send me a thousand line PR and ask me to review it, I will look at the giant blob of text, and immediately fire off a "it's too long, can you cut it into smaller PRs?".
Because I don't trust myself to review a giant PR. It takes too much cognition to properly review it.
And now that people are making PRs with AI, this is even more important. If the AI was good enough to have coded it, please instruct it to make the changes in reviewable chunks.
> the pressure is growing for writers to just shove massive PRs out the door and reviewers to use LLMs to make that tractable
Even in these move-fast envs, it should be reasonably apparent for people to realize that the author should be using the LLM to make the PR tractable, not solely using the LLM to shovel out a giant PR + slop PR description.
And the LLMs can often do this - if you ask to restructure or break up a big change differently, they can often make quite reasonable suggestions and help with it. That's just not what you're gonna get if you're lazy. If you want a small LLM-generated change, often you have to start with a big one then ask it to figure out what it can get rid of, since many times it doesn't have perfect model of all the code in it's "head" before it starts spitting stuff out. The big companies have been doing their best to automate this for the last couple of years vs the even-more-blind attempts you used to get, but there's still the issue of the models+tools following generic advice aimed at median codebases vs being intimately familiar with this codebase.
You can go fast without being lazy. And when going fast, in some ways, it's more important than ever to put in that effort to not blowing things up.
It should be but often isn't. There's been a lot of threads on HN where the response to huge PRs wasn't "Don't do that, use AI when authoring better" but "The reviewers are actually the problem, they're missing the AI train". And I see this in industry too.
> I suppose those advocates have more faith in LLM output compared to humans than I do.
Some of this is the funny situation where the faithful will state: "This writes better code than I do!" and miss the irony of: "yes, yes it does"
Some of this is the funny situation where the faithful will state: "This writes better code than I do!" and miss the irony of: "yes, yes it does"
"Blessed are the humble ..."
> "This writes better code than I do!" and miss the irony of: "yes, yes it does"
I guess it depends on what you consider "better". I've tried using LLMs to write code over the past couple of weeks with extremely mixed results.
The LLM certainly writes more interesting code! They like their cute ASCII/unicode animations, don't they?
It definitely writes a lot more code, none of it actually correct but some of it functionally similar to correct code.
If you like lots of code then I guess that's better. I like less code.
I find it can often write correct code but not maintainable, performant, or reviewable code without additional human guidance. The "solution" frequently given is that humans don't need to maintain it anymore so its not actually a problem. But the agent can't be accountable for mistakes, so unless that changes or the risk of a defect is close to zero, one still has to put forth effort to keep the code maintainable.
To be fair, there are plenty of situations where throwaway code is perfectly fine and/or defect risks are low enough to make the trade-off worth it. I don't think a lot of developers are thinking about it in that context, though.
(No unit tests aren't enough)
It can write correct code, but it's still really not good at that, at least without lots of prompting. In my experience, that prompting is usually just doing the design/planning work I'd do with or without AI.
I've said this before on here, to much derision as it turns out, but I write my best code in the car. Nowhere near a computer, no distractions, just point the car along the grey stuff and away from the green stuff and think about what I want to write.
Then when I get home, it's just a case of typing it in, which is the bit I'd love to automate away.
My experience with LLMs has been a bit like rubberducking code with someone who's *really* fast at looking stuff up on StackOverflow.
> They like their cute ASCII/unicode animations, don't they?
One of the few global Cluade directives I have setup is to never use emojis - and it never has, either in chat output or in code. Don't blame the tool when you don't spend 30 seconds configuring it. It's even easier with AI since you don't have to go digging for some obscure .vimrc snippet - it's literally just plain English.
Yes I basically meant those folks weren't very good developers to begin with and now extrapolating to: "wow this is better than all devs!", when it's more like "it's you, dude"
This sounds awfully like the people who think that self-driving cars and even auto-braking systems will eliminate all accidents, because everyone else is as bad a driver as they are.
Someone pointed out[1] a while ago that LLMs look good at things you are bad at. Which is I think one of the best explanations of why so many people disagree about how good they are at programming. There are a lot of people really bad at programming, and they will look at the output if an LLM and say “Wow, it’s so much better than my code!”
1: https://news.ycombinator.com/item?id=48315309
I've had a guy once reply in an email with a bug report generated by ChatGPT telling me that some piece of software I wrote wasn't working. He just plopped right there the discussion he had with the confirmation bias machine confirming 100% that what he had in front was sending spurious messages. With all the information in the world at its disposal, the LLM did not consider informing the reporter that maybe his code should flush the serial device pipe before starting his processing. I stopped short from facetiously replying to him that maybe he should use another model, since his seems to be broken.
I think that this is the essence of the argument. I spent two weeks of long nights across a few different sessions with millions of tokens generated, to produce a 5 page proof. I think we have come to the age of the aesthetics of curation. At least I don’t feel like I broke this silent contract. The effort you put in driving the torrent of words before distilling it is a new art. First time I tried it and it felt more creative than slop. The judgement nevertheless lies on the eye of the beholder.
Isn't this just a continuation of the performance art of the modern corporate environment though? There's an entire industry producing pages of documents which aren't read, aren't responded to, but need to be at least X lines long for anyone to take them "seriously".
Then suddenly LLMs happened and it's like the mask is off: no one's reading them still, but also no one is writing them either.
Which is perhaps a drop in the ocean of the insanity which is "we need you to work on the Jira tasks" as basically a job title.
You're absolutely right! The modern commercial sector has been writing bullshit, bullshit, and more bullshit, and become completely disconnected from the actual outputs of its work. And it has to be, because if only useful work was done, two thirds of the population would be unemployed without benefits and would revolt so they didn't starve.
I think this is from Sartre's "Literature & Existentialism."
I'm not a big fan of his generally, but I highly recommend this book in particular. A lot of what he wrote there really resonated for me.
> Sure you get crackpots still,
They've still put more effort into writing their crackpottery than you will put into reading it, and at worst it's entertaining. The late Ivor Catt's articles on "the death of electric current" - where he expounds the idea that current and indeed electric charge does not exist, because of stuff involving Maxwell's equations where the maths looks about right to me but I'm not a good enough mathematician to prove - were pretty damn odd, but his writing in 1989 on how it would be vital for an interconnected network of computers for information sharing to treat censorship as damage and route around it and some ideas for doing this was bang on the money (as we now see) and his writings on how American business management methods result in the worst possible outcome for everyone that's not already a billionaire have also proven oddly prophetic.
So maybe there's something in the crackpots after all.
Maybe lots of (most?) people are crackpots about something, but they lack the time and/or resolve to do something about it.
I wonder what I'm crackpotty about? Forth, probably, although I did actually port Dave Dunfield's 6809 Forth to a mid-1980s sampler. It boots off a floppy, I know what the memory map is, if it boots off a floppy I can make it run anything, right?
How about this crackpot view? Perl vs. Python, which I guess has been replaced by Rust vs. Go - I prefer Python and Go to Perl and Rust, simply because I know them better. If you want me to work in Rust or Perl I don't really care, they're just languages. I'm not as proficient in them, expect it to take longer. Rewrite it all in Rust? Sure. I'd prefer not to, but if that's today's project then shut up and pay my invoice.
Let's see, what other things are wild crackpot ideas around here?
I don't think LLMs are very good.
I don't think self-driving cars solve the right problem.
Permaculture would be better for long-term ecological sustainability and food security than "everyone should be vegan".
Bikes would work perfectly well in American cities if you used enough of them.
if anyones got an active issues list, the maintainers should close all issues and open only ones they intend to fix. A bot should repeat this message to the issuer and point them to issues they're accepting.
So at a minimum, you could maybe fish some useful work out. PRs should be the same.
> Back in pre-LLM days, receiving an unexpected pull request (PR) from a fellow coder was a source of excitement and pride.
As a maintainer of a few FLOSS projects, this tracks.
The Pavlovian PR notification response has gone from, "Oh! What do we have here?" to "Groan. Do we have _anything_ here?"
I won't get specific but I just had to remove a contributor from a project after multiple submissions of either cutesy, fluffy bullshit (add ASCI animations!) or "rewrite entire project in other language". Not only did the PRs result in wasted time and energy but they also resulted in conversations about how to deal with this sort of spam. (Probably good to get out of the way and set policy but still...) So, this person probably spent fifteen minutes prompting together these stupid PRs and multiple maintainers had to spend hours agonizing over what to do about them.
TBH I never contributed to Open Source because of the effort needed to bring my PR from "works on my machine" to "compliant with the rest of codebase". Especially that I only want to implement one small thing.
There's one project where I need to download a new version once in a while and I just rebase my changes.
> TBH I never contributed to Open Source because of the effort needed to bring my PR from "works on my machine" to "compliant with the rest of codebase". Especially that I only want to implement one small thing.
That's a good thing; OSS projects don't want drive-by contributors, they want a community. A small bit of friction is a good thing.
After all, we can see what happens with frictionless contributions.
I some times will open a PR even if i know it will get closed, simply by because if its a bugfix or feature i want, someone else might do so too, and i have many times adopted code from PR's that were never adopted by mainstream or closed.
By pushing that PR, i might be annoying a grouchy maintainer, but at the same time helping tens or hundreds of other users of the software.
Imho the beauty of open source is as long as you're adhering to the licenses, you can do whatever the heck you want =)
If you already know it's not good enough, you can just say so by calling it a proof of concept or hack to demonstrate what needs to be done. Such code is often very useful when writing the real fix.
Yup, some of my first contributions when I was a teenager, was to an open source project where I was able to find a couple of bugs, and implement a hacky solution that I shared with the team on the forum. My code was absolutely awful, but by having done both the effort of tracking down the cause of the bug, and one possible way of fixing it (which was badly coded, but worked), made the developers able to quickly turn around and edit my patches into actual patches that got merged into the project.
And it was actually a pretty good feeling. Made me feel that even as a newbie programmer, I was adding value to the community, which I was!
I've done the same for a fix in the Gold linker, which is now obsolete due to even faster linkers being available. Shout out to Ian Lance Taylor, his behavior as the maintainer was exemplary: very gracious and very responsive.
I not trying to be mean about it, but... that's good. If your one small thing wasn't worth the effort for contribution then it probably doesn't need to be in upstream. Contrary to what many seem to believe, code existing is not inherently better than code not existing.
Actually it's good for another reason, and that's the very essence of opensource: the user can customize the software to their needs, but there is no obligation to participate in a community effort (although it's definitely cool as a side effect)
The thing is I totally, 100% get this. The other thing I can't help but see though is how excited my non-programmer friends are to finally be able to make software. The sense of pride and accomplishment from non-coders who are finally able to make something work the way they wanted to.
We almost need like ... noncanonical software? Not so much forks, but like ... Maybe software as like a cluster? an ecosystem? On-demand app store where features / forks are shared/upvoted/evolved by the community where the maintainers don't have to get burnt out, and when it inevitably becomes a ball of mud oh well it does the job? I really don't know!
I hope we can think about some answers and not get tribal though because this is really a huge problem and also a huge opportunity and so a minor reminder that there is a baby in that bathwater?
I agree. For many people, LLMs are the first time that computers do what they tell them to. Not what some big tech PM has decided is or isn’t possible.
At the same time, OP is in the right to reject contributions they don’t want. Nobody providing open-source software is under any obligations to take changes. Forking is still a viable option in 2026. And I don’t think we need an on-demand app store either because the trust issues will still exist for good reason. We can have highly produced software coexisting with LLM agents.
> For many people, LLMs are the first time that computers do what they tell them to. Not what some big tech PM has decided is or isn’t possible.
The crux is here somewhere.
A massive group of people (A), don't fully understand or care about code, but they care about arbitrary specific outcomes that serve their needs and desires VS a tiny group of people (B), who initiate, architect and maintain successful projects, who care deeply about the health and cohesion of the codebase over it's lifetime, because that serves everyone.
Group-A is now liberated for better and worse. For the first time they can force their will upon a codebase without understanding. They are making selfish changes, and that's fine, this is hacking for the masses. The problem is they still don't realise these are selfish changes, because they have not been forced to tread the path of the programmer to understand they are selfish changes.
The response from FOSS maintainers seems inevitable from this perspective... But I think what's going to be more interesting is watching how Group-A over time respond to creating their own personal hell.
As group-A accrete more and more unsupervised selfish changes into their forks - at what point will they implode and turn into LLM-token-tarpits, at what point will Group-A notice, and I wonder what their response will be.
Who gets a sense of accoplishment from prompting an LLM? Do you get a sense of accomplishment when AI draws a picture or writes a poem for you? I guess there are some minds I'll never be able to comprehend
One can reason by analogy here.
In a pre-LLM world, a classic software team would have PMs, designers, and engineers.
Of those three, the PM wouldn't have any real role in writing code. And they would rarely contribute a ton to the design. What they would be contributing is ideas, market insights, coordination, prioritization, etc.
When the product ships, one would expect the PM to feel a real sense of accomplishment. They helped this idea become a _real thing_! All of that pride, despite not writing a single line of code nor polishing any pixels themselves. And I don't think anybody would reasonably look down on them for that feeling.
Same thing with using LLMs. Sure, you didn't write the code. But you caused the thing to exist! That's exciting!
It's more akin to someone commissioning a piece of art, where they describe the piece in varying detail and then it's the responsibility of the artist to see it through, perhaps deciphering ambiguities in the p̴r̴o̴m̴p̴t̴ commission brief.
If you want to stick with the PM analogy, it would be akin to the manager spending 30 minutes writing up a draft spec, passing it off to their employees and then spending the rest of their time watching TikTok in their office. It would be strange if they felt pride in that.
I think that's fair for certain one-shot generations. For example, sending off a single prompt to an image or music generator and just accepting the output.
But I think most of this stuff is iterative, multi-turn. You type a thing in, see what comes back, and then repeat until you have something that satisfies your desire.
Taking the manager analogy. If you spent 30-minutes writing up a draft spec, waited for the outputs, had a review meeting where you provided good feedback, and then repeated that cycle until the product was done... Again, I think that manager (assuming, of course, that their feedback was useful) should feel some pride in shaping that output!
Taking the art commission approach, you go back and forth with the artist until you have what you want. Should you feel pride?
I think it's much closer to the art commission than it is to a manager who is managing humans, the constraints of the business, customers, etc.
Maybe a movie producer is a better analogy?
Some artists use a brush, but others use a chisel.
And then there's the bullshit artists.
Just because we never had the option of a chisel before doesn't mean all chiselers are bullshit artists.
What sense of pride an accomplishment do you get from using a library, or a high level language? You didn't write that code, you didn't hand translate into processor opcodes, etc. There are a million man hours of other people's work involved in making a simple python script run.
Given that any coding effort relies heavily on a much greater amount of work as a prior than the code you yourself are writing... Why do you feel accomplishment?
Making things is fun, using tools to make things can continue to be fun. I have fun woodworking with hand tools and I also enjoy using my CNC where the job permits. Both bring joy.
That's a poor analogy, because the intention is orders of magnitude greater on those things than with an LLM. You still need the intention to write Python instead of C, or C instead of assembly. You need an insignificant amount of intention for LLMs, which will happily spew code even for the worst, most incomplete or nonsensical commands.
I think most people feel pride when they put effort into doing something challenging and in return achieve a good result. You can use high level languages and libraries and still put effort into something that is challenging, thus feeling a sense of pride. Of course, they may feel more pride if they achieve the same result without libraries, or in a more challenging language.
Prompting an LLM neither requires comparative effort nor is comparatively challenging, thus it's would be odd to feel a sense of pride from any associated outcomes.
I cannot believe this even requires an explanation.
Developing a functional app that meets your needs with an LLM takes it's own kind of skill, and is substantially more difficult if you can't recognize when the machine is steering your architecture in the wrong direction. It takes actual, real work. It's certainly a completely different kind of work than writing most of the code yourself, but so is using Java when compared to hand writing x86 opcodes.
Prompting an LLM to produce good code isn't a lot of work for you. Writing hex without an assembler or compiler would be a lot of work for you.
People have ideas, and now they have better tools to turn those ideas into reality. They aren't doing it like you would do it, but they're getting it done all the same, getting their needs met, and enjoying the ride.
Maybe just let people have fun, and when they report that they are in fact having fun... believe them.
I'm not saying people can't have fun, I'm saying it's a misplaced sense of pride that gives me the ick when I sense it in others. I see plenty of people who readily disclose that their thing they "built" was just slopped together by an LLM and this is perfectly okay, because they aren't trying to take credit for accomplishments that they didn't put in the expected effort for.
The difference between the skill & effort required to build vs prompt your way to something is orders of magnitude different. If it took just as much effort, people would just do it by hand anyways.
I think “build vs prompt” is a false binary that frames the argument badly.
There are way more nuanced uses of LLMs than skill-free “write me a facebook clone.” Like, hey LLM, help me develop tests of X, review this design for X, help me articulate what is wrong with the code for X, give me ideas for simplifying X, suggest optimizations for X, help me debug this failure trace for X, help me apply this refactor across all of X, and on and on. Even these are stupid examples that way over simplify.
I’m super proud of the work I’ve created /alongside/ LLMs. I’ll let it build me development aides and such with little oversight and there’s no skill there. But you can use it deliberately and maintain control, and it’s amazing to have a tool that can look through your code with you from so many angles.
Yeah, there's something pathetic about being proud of something you didn't actually get challenged by making. Like, I love building Lego sets. It's relaxing, it's fun, and I enjoy having the completed model to put on a shelf and look at. But I would never in a million years say I was proud of those Lego models, or that I had a sense of accomplishment. That wouldn't be merited.
Don’t think of it as creating art, but as solving a frustrating computer problem. For people that aren’t technical, computers are often irritatingly obtuse and unclear if you’re trying to get something to work in a particular way.
1. There exists some X that you wish existed, but does not
2. The world has changed in such a way that X now exists
3. You took even a tiny action towards #2
Even if the main goal was #2, Is it really hard to see how there might not be some sense of accomplishment? Many investors take pride in the impact the companies they invested in have on the real world; this is the same thing in the small.
Back when image-gen was made widely available (2023ish, feels like eons ago), there were people who took genuine satisfaction with their art prompting skills. It did come off as a bit cringe though: https://www.reddit.com/r/saltierthankrayt/s/KxwhqJ5hrU
That thread is hilarious. They update the model and the guy thinks his art skills has improved. Something to consider when someone tries to tell you prompting is a "skill"...
Do you think your CEO has no sense of accomplishment when your team ships a product feature?
Yeah, they created a team that accomplished something (or a team that created a team), so it's well-deserved.
I guess that's why I burned out as a manager: I do not get a sense of accomplishment when my team achieves something
For people totally new, it can be partially understood, just as i was ecstatic having a tool create something on a computer for me in my early days.
For anybody else thought, I get that a LLM is a regression (npi) where you don't have to learn or understand anything .. therefore the personal growth value is moot (except the alleged sales if the person tries to use LLM to create a side business).
For actual devs it's disheartening and caused me real grief seeing how many of them were happy not thinking anymore.
It doesn't even matter and isn't worth arguing about what emotional state the submitter obtains. I don't care if they even achieve nirvana and ascend to permanent buddhahood.
What matters is that they are wasting the time & patience of someone who is doing good work that others benefit from.
Any happiness gained from doing that to someone is parasitic.
I posit that there are people who get a sense of accomplishment from operating their laundry machine.
And people who get a sense of accomplishment from hitting the jackpot on a slot machine.
Operating an LLM is a strange combination of the two.
Amen.
I've always said that by only writing ASM can you get any sense of accomplishment from authoring software.
> Who gets a sense of accoplishment from prompting an LLM?
I have a good friend who is a VP at a telecom company who has never written a line of code. He's been using Claude to create interactive web pages to help him understand parts of the company.
He was so excited when he got something to work he called me immediately.
I'm sure the code isn't what you or I would write, but it is good enough for my friend. That said, heaven help him if he loses access to Claude. ;-)
I'm a professional software engineer and even I get excited about having an ai vibe out some throwaway software for me (two recent examples - a personal recipe site I never made time for and a video game skill tree build tool that isn't worth the time it would have taken to build).
As another commenter said, for a ton of people this is the first taste of the computer working for them and being able to dream something up then have it exist. This is very cool!
That in no way invalidates the concern of amateur slop going to maintainers! I think the problem here is we as society haven't caught up to this new idea of personal software vs community (architected, maintained) software. We're so early in this space we haven't even figured out the good ways to do such a split - even the totally new to software folks are bleeding edge early adopters.
After trying and failing multiple times to get any LLM to create exactly the picture that I was trying to make, I have to admit that, at one point, if one of them had succeeded, I would have felt a quantum of accomplishment.
But, since I'm not that much of a slot machine aficionado, I just completely stopped pulling the lever.
However, I can see that for the right people, this level of difficulty might encode or mimic, purposely or not, many of the features that are collectively termed "gamification."
I think there's a spectrum between simply writing a prompt and generating slop and using AI in a loop over many hours/days/weeks to produce something that works the way you want it to. I get a great sense of accomplishment from doing the second, and I pretty much refuse to do the first, except only in the most ephemeral of cases.
Who gets a sense of accomplishment from cheering for their home team?
You should see the non AI trash that people are proud of
Someone having pride doesn’t mean what they did has value
Do you think people in product design never feel a sense of accomplishment or something?
Or for another perspective, why do you think a "sense of accomplishment" is an essential, and dominantly important thing for everyone? Maybe they feel two hot shits about such a thing.
Especially when the "accomplishment" in the vast majority of cases is in the realm of "having had the patience to endure the humiliation ritual of figuring out the arbitrary abstractions some other dude came up with, and doing the plumbing to reconcile that with the requirements to the extents possible"?
It's like that Star Wars: Battlefront PR comment's idea of a "sense of accomplishment". Outright asinine and cynical. https://www.reddit.com/r/StarWarsBattlefront/comments/7cff0b...
When I make things, what I care about is exactly the function they provide. It's endlessly rewarding to make something useful. It's not some exercise in polishing my ego by proxy. I don't want people appreciating the things I make because they were hard to make. That's borderline condescending and pitiful.
But hey, maybe I'm mischaracterizing the way you meant "sense of accomplishment" myself. Maybe this is exactly what you meant too. But then how would people vibecoding be robbed of feeling this? Makes no sense.
If you scroll through any personal finance forum every year someone will discover the forum and excitedly share their customised budget tracking sheet they built from scratch and it works exactly as they wanted to. How many do you think even get 1 upvote?
Everyone building a software will just mean people can produce code which others might not really care for and might even be particularly be mean. That’s how the Internet works unfortunately.
The current logic seem to be confusing two things. One AI as a technology and wisdom of the crowd using AI. One might ground breaking tech and improve over time while the other might not move the needle at all.
A customized budget tracking sheet is the personal finance equivalent of a programmer showcasing their TODO webapp. Obviously it's going to be incredibly unpopular. Yet, there are popular tools people have shared in personal finance communities.
Very well framed.
What is the kind of person who would use such software? What you’re describing is the need for a two sided market where really only one side exists.
A user would have to be someone who doesn’t have access to an LLM to make bespoke software themselves, and isn’t able to use existing software. I think that’s a vanishingly small segment of people.
Sounds like the user could just ammend the software to his need with the LLM, but instead of sending that update to the maintainer with a pull request, just keep it to himself, to the users version.
You're assuming that everybody will be equally skilled in using an LLM to create software. I don't think anything in my experience indicates that this is true.
https://www.robinsloan.com/notes/home-cooked-app/ This has never been truer than right now. What we need isn't app store ecoystems but to eliminate the friction for distributing apps to your inner circle. We're entering the WhatsApp era of software, where everyone is going to be using a home cooked version of every piece of software that can conceivably exist on an island, and it's going to be a vibe coded mess, but it's going to be lovingly maintained by the people that use it every day. This is why I'm bullish on things like https://sprites.dev/ (not affiliated, just a customer). I have a little self replicating starter template that lets me quickly stand up new sprites with all my stuff logged in, ttyd + tmux so I can run claude code in the browser from my phone, and a caddy reverse proxy so I can also host a little starter app behind the fly io relay that sprites get out of the box so I don't have to do any extra work to have a publicly accessible https url I can send to people. Using this set up I've created dozens of little silly web applications for my family and friends, none of them were more complicated than little sketches but we've gotten some real pleasure out of them. There's still quite a bit of friction here though and I think if someone can really make this seamless for people they'll have something really special.
As an example, the android options for printing to my outdated brother printer were all terrible (ad supported nokoprint for example), so I used my template to create https://print.walden-gabrielw.workers.dev/ (This one a put a cloudflare worker in front of because it's just a static html+js page and I didn't want to pay for uncached traffic but the principal is basically the same). No one will likely ever use this but me and my wife, but the cost to keep it up is basically 0, the cost to build it was very reasonable, and if it ever breaks I'm fairly confident the latest LLM will be able to debug it without too much trouble.
> We almost need like ... noncanonical software?
You mean some modern version of vb or php?
That is the entire point of low-code and no-code.
> The thing is I totally, 100% get this. The other thing I can't help but see though is how excited my non-programmer friends are to finally be able to make software. The sense of pride and accomplishment from non-coders who are finally able to make something work the way they wanted to.
You absolutely don't need LLMs for that.
Its the very description of most corporate JavaScript developers, and probably most Java developers. I say that as somebody who wrote corporate JavaScript full time from 2008-2023. Most of these people had no idea what they are doing. They could throw something together using their favorite abstraction library/framework but then struggled to maintain it. If there were performance or accessibility problems that came up there were only three outputs: hostility, crying, or starting over from scratch. The insecurity was real. You can still see it today. As an experiment take React away and note the response.
An ecosystem on shared formats can exist hapily
There's a billion ways of opening a markdown and doing things with it and generally they all coexist hapily
> I hope we can think about some answers and not get tribal though because this is really a huge problem and also a huge opportunity and so a minor reminder that there is a baby in that bathwater?
I think no answers are needed.
If anyone can build the software they need, no ecosystem will be needed. There will be no maintainers because no one will be using his thing.
If it makes sense (economical, but no limited to it), then it will progress in that direction. If it makes no sense it is a fad that eventually dies out.
There may or may not be a baby in the bathwater. In truth nothing in this bathtub matter too much.
I think this makes sense for apps, but the apps will still need infrastructure and common protocols to interoperate. It still won’t make sense to implement your own cryptography.
Why not?
If you can vibecode your app, you can vibecode your cryptography as well.
You may object to it but that, too, would be elitism. And the person vibecoding has no idea why proper cryptography matters anyway. Or why proper anything matters.
This is the ultimate realization of "my ignorance is as good as your knowledge".
I don't think this is necessarily a bad thing.
Because doing enough security reviews to remove all the security bugs gets expensive, and if you use well-reviewed code, it's already been done.
I do a bit in my IT classes where I show a "spectrum" of computer activities, from "changing a screensaver" to "Assembly" and then challenge people to find the line where "using a computer" stops and "programming a computer" starts.
It was already very fuzzy (Excel?). Soon, this line be non-existent.
As soon as you’re specifying instructions for the computer to do a task automatically, you’re programming it. It can be recording a macro, writing a script, describing it in something like Shortcuts,… The core thing is automation.
Not convinced this is clear at all? I'm typing a document in, lets say -- word.
I want it to say "Come to my awesome awesome awesome party."
If I type it out, it's not programming, but if I ctrl-c + then ctrl-v twice, it is?
Copy-pasting is not programming, no more than clicking the save button is. But text expansion may be seen as such, especially when it involves dynamic elements (like current date and time). It may not be a clean delineation but, IMO, it's the difference between writing a recipe and doing the dish. Copy-pasting twice is making a dish. Creating a button that let the computer do it is writing a recipe.
...maybe some sort of "Software Bazaar", where the users of the software can edit their own software and make local modifications that they need to it, probably with NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
https://en.wikipedia.org/wiki/GNU_General_Public_License
It'd also be really nice that if you received some such software that you'd have the right to run the program as you wish, study how the program works and change it to make it do what you wish, and the freedom to redistribute either the original, or your modifications to the software?
https://en.wikipedia.org/wiki/The_Free_Software_Definition#T...
...we can dream though, can't we?
> The other thing I can't help but see though is how excited my non-programmer friends are to finally be able to make software. The sense of pride and accomplishment from non-coders who are finally able to make something work the way they wanted to.
There was nothing stopping them from making software before... Over the past ~15 years, the amount of resources to learn programming, and to make the whole process approachable, is staggering. It just took some time and effort. People are just excited that they can skip past the effort part now. But we've lost something in the process.
I mean, I largely agree with the sentiment (friction is important for growth/happiness, after all). But even as a developer, I'm able to quickly whip up custom personal apps that I just wouldn't be able to justify the time for previously.
Our CEO just took a design mock-up of a new landing page and threw it into Fable, and it spit out an objectively better iteration of the component's design. The hierarchy made more sense, the typography was more polished, and it naturally incorporated some elements we hadn't added yet.
We won't implement everything it changed of course, but it's the first time I've seen a model take a decent draft of a webpage mockup and improve it in a way that feels like a more evolved version of the original instead of just LLM-ifying it.
Huh? The difficulty and the cost was stopping them before. It was really difficult, took a ton of time and money, and you had to deal with another person.
> sense of pride and accomplishment
What? Pride of what? What accomplishment?
> What? Pride of what? What accomplishment?
The sense of accomplishment does not necessarily require much accomplishment.
https://en.wikipedia.org/wiki/IKEA_effect
and
https://en.wikipedia.org/wiki/Pygmalion_effect
Maybe building something? It doesn't matter much that the programming language was English and built by an LLM and a harness. They created something they wanted that wasn't there before.
It does matter. Drawing a stick figure and having a machine print over it with a realistic image doesn't make you an artist, and no, you shouldn't be proud of it.
is there a list somewhere that i can check what i am allowed to be proud of and what i am not allowed to be proud of?
edit: if anyone wants to enlighten me, why do you care if someone is proud of something? does it hurt you somehow?
No, but come on. If you insert a computer into your brain and wake up tomorrow speaking German, would you be proud you could speak German? Wouldn't you rather work diligently to learn the language and be proud of that effort?
Depends on why the person is wanting to be able to speak German.
If you only want to speak German for its own sake, then maybe it does seem silly to be proud of what the brain computer did for you.
But there are many other reasons to want to be able to speak German. Thanks to his brain computer, a French cheese maker could travel to Germany to promote his cheeses in a new market to great success without having to rely on the German speaking skills of expensive to hire people, and without wasting years to learn German on his own when all he wanted to do was to make cheeses and grow his customer base for his cheese. German in and of itself was never a goal to him.
Just like computer programming is not a goal in and of itself to a lot of people, and who would otherwise have to spend time to learn programming instead of doing the thing they want to do, or having to hire software engineers that might cost more than they could ever hope to afford.
And even though the computer is doing something for the person, they are leveraging that for something that they feel pride and accomplishment in. Such as for example to use German (done by the computer) to expand your cheese customer base into Germany (your own accomplishment that was only possible thanks to the existence of the German speaking skills of the computer).
Absolutely -- why on earth would I spend more time and effort than I have to?
Now I can focus on the reason why I wanted to learn German in the first place, like appreciating German culture or talking to German people.
Note this is not saying "why learn the language at all there's a translator" since learning a language lets you experience the culture more intimately and communicate better -- lots of things are "untranslatable". But if somehow the implant gave you that necessary context, why not?
would i? no.
would i care if someone else is proud in that scenario? also no.
Alright, we’re each entitled to our opinions on the matter.
Or we could, you know, let people feel proud of whatever they want?
Call me old fashioned but I take pride in things I work hard to achieve. I think it's embarrassing to be proud of AI output of any kind, be it software or art or writing.
Hope all your programs are written in machine code. Wouldn’t want to be proud of compiler output.
I mean yeah? Wouldn't you be more proud of your ability to write a program in machine code than you would in assembly? Or more proud of assembly than of C? Or more proud of C than of Python?
Each stage takes greater effort, effort which creates skill. Those hard-earned skills are accomplishments to be proud of.
When LLMs are remotely comparable to compilers, your analogy might hold water. But in the world of today, it holds none.
But you're acting like everything that you use AI to build is easy to achieve, and that doesn't seem to be true.
And I’m sure ctoth’s non-coder friends will be just devastated to hear that some random online account is embarrassed because they’re proud of a little app they created for fun.
Sure, you can feel proud of whatever you wish.
But don't share that shit with others and expect them to feel similarly proud of what you did.
lol, you’re literally talking about non-coders that GGGP said they know. No one is sharing their AI stuff here asking you to be impressed.
> No one is sharing their AI stuff here asking you to be impressed.
That actually happens all the time on Show HN these days.
I get where you're coming from, but for completely non-technical people, it seems to me the more precise analogy is not "building" but "ordering online". Or hiring someone to do something for you.
If you order a pizza from an app, and assume you can pick ingredients from a checklist, would you consider it "making" a pizza? Would people get the feeling of accomplishment?
That's a better analogy than my dumb drawing one. You can be happy you got your pizza and you can enjoy the taste but it is not an accomplishment to be proud of.
It's mostly that how much you decide to involve AI as a spectrum. To extend to the pizza analogy, I feel like you're telling me that because I used dough that I bought at the store, I shouldn't be proud of the pizza I made, even though I made the sauce and cut the pepperoni and the sausage and baked it myself on a peel covered with cornmeal. That's not the same as just ordering it on DoorDash.
Agreed there are nuances, but in the context of this conversation about TFA, the suspicion is that this is mostly on the "100% AI" side of dial. There's also a "high volume, low quality" aspect to the PRs, as evidenced by the fact that the bots (or humans) don't read or follow the repo's contribution guidelines.
The very concept of "reverse centaur" implies a balance towards the "order pizza online" side of the equation.
The pizza analogy smuggles in this idea of cheep/mass-produced. I'm talking about blind people who can now prompt their way to an accessibility mod for their favorite game, the sort of thing which literally would have never been written before. How you know it wouldn't've been written is by counting the accessibility mods pre and post LLM.
Now generalize this. Every tiny community, every person with a disability, everybody for whom the default software doesn't work right? Can now change it specifically for them. Not add peperoni, that's far too low-dimensional to capture what is happening. Actually build their own interface, be able to use something they simply didn't have access to before, and critically not depend on another programmer (there are like a dozen of us blind ones!) to build something for them.
It's not about cheap. It's about ordering vs building. If you tell an architect and a bunch of workers to build you a house, even if you pick some details and make some choices, it's them that are building the house, not you.
You can feel happy about the result, you can find the house useful, but you shouldn't feel a sense of building accomplishment, because you didn't build anything.
With AI & apps there's less friction, because you don't even have to hire another human being, it's just prompting. In that sense, it's definitely closer to ordering food from an app.
In any case, in the context of TFA, there's also a sense of low quality, cheaply made. The bots making the PRs aren't reading the contribution guidelines, so that's low quality all by itself. Drowning a human reviewer with a mass of PR is also a low quality way of contributing.
People are very proud of their prompts I guess
It's like people being proud of the AI slop art they produce
it's called plugins, lots of end user facing OSS have vibrant plugin ecosystems.
maintainers like the sense of power and it's not really more complicated than that. perfectly valid emotion to chase!
So I am thinking this is like an army of plebs going to Home Depot, buying power tools, and building a house with no experience. Oh what fun—we can finally build a house the barrier has been broken.
I don’t want software written by plebs.
When they shoot a little artistic clip with their nice modern iPhone camera, it does not mean they get to insert it into a Hollywood movie.
This analogy makes no sense to me and honestly skews pretty elitist in vibe. iPhone is regularly used in professional videography now. Like, 28 Years Later was shot on iPhone. Indie filmmakers have been using iPhone to break into the industry for years.
the analogy would be that your LLM/agent has a pass at a Spielberg script and peppers his inbox with inane production notes. A system like that would be untenable for all involved.
I think the attitude frequently adopted by open source maintainers - comparing themselves to Spielberg - has been a major roadblock to anyone looking to contribute to open source projects for years.
Agree that even prior to LLMs those projects weren't terribly welcoming as per Linus' famous email comments (chalk it up to cultural communication differences :) )
I don’t know if it’s just me, and these days I do understand it given the widespread adoption of LLMs, but I’ve always detested the idea that I need to reach out and have a conversation with the maintainer before opening a PR. Especially (mainly) when the PR is simply addressing an approved GH issue.
I’ve had so many perfectly acceptable PRs rejected over the years simply because they didn’t “fit the vision” of the maintainer, despite being +1’d by many members of the community or even other contributors. I don’t even mean to imply they were rude or anything, just uninterested in actually merging anything where they didn’t architect the changes themselves upfront.
On one hand I get it, you’ve spent so much time building something it’s fair to want to hold on tightly to that level of control, but to me it's just always felt antithetical to the entire idea of open source.
Makes me feel like I’m not contributing to a true open source project, just doing free labor for someone.
Why are you looking to contribute to open source projects? If you have a fix or a new feature, you can share the diff in variety of ways. The maintainers are not obligated to review, discuss, and accept your changes.
I’m not entirely following you. I generally don’t contribute anymore, but in the past I’ve found a lot of maintainers are not actually looking for collaboration, rather free labor.
I certainly understand things are different nowadays, I’m talking pre-LLM proliferation.
> I’ve found a lot of maintainers are not actually looking for collaboration, rather free labor.
Do you think that maintainers lack domain expertise? A nice bug report is way more helpful than a random pull request. A patch, even when correct, can be counterproductive, if it conflicts with the roadmap and goal of the project.
The goal of open source is to give you freedom in maintaining your own version and extending it. Collaboration is not a requirement.
If you think filming is the only skill needed to make a film, may I suggest looking at the very long list of names that appears at the end of the film of which only a few actually do filming? Takes a lot to know what to film, and how to be good at using the tools you have.
Similar is true for a lot of software. Credit list on video games… I don't want to say it "mostly" isn't coders, but only because I've not done an exhaustive study. My guess is the top will either be QA or art.
Artists of all stripes (including audio, animation, cinematographers, lighting, environment, textures, etc,) including tech artists, designers, writers, musicians… the ratio of functionality to look-and-feel is dramatically different than in non-entertainment products, and the labor involved reflects that. It’s a real shame that some of the people that contribute most to what makes a game great are often the first to get dropped when people talk about how the game is made, (but most are perfectly happy to fly under the radar when a bunch of entitled kids start raging about the “lazy devs.” ;)
Films aren’t open open to random contributions by casual volunteers. It’s not about iPhones.
"You are not a photographer just because you have a camera" has been a standard saying since forever, and has nothing to do with elitism.
Those professionals are professionals not because they own an iPhone and use it to shoot something.
Exactly - it's just a tool. So, trying to make the argument that someone's work is less-than because they used a cheaper/more amateur tool versus the tool the well-funded professionals are using _is_ elitist. You recognize that, but the comment I replied to centered on the tool, not the finer points of professionalism.
But on that- whether folks have knowledge and taste, demonstrate responsibility for their impact, pay attention to their work quality, show up to the work environment with respect, etc. are all elements at the domain of human relations. This discussion is conflating how people use tools with how people work with each other. The tools don't matter here. I think we're sayin' the same thing.
> So, trying to make the argument that someone's work is less-than because they used a cheaper/more amateur tool versus the tool the well-funded professionals are using
No. Just the fact that they have a tool does not automatically make them a professional, doesn't automatically make them skillful, and doesn't automatically make their output worth something.
This is the meaning of "When they shoot a little artistic clip with their nice modern iPhone camera, it does not mean they get to insert it into a Hollywood movie."
There's nothing elitist about it.
Professionals are professional because someone pays them, that is all.
The word has other meanings, too ;) E.g. "professional conduct" isn't one that is paid for:
1a. of, relating to, or characteristic of a profession
1c.1. characterized by or conforming to the technical or ethical standards of a profession
3. following a line of conduct as though it were a profession
Professionals can be unprofessional, and amateurs can show professionalism, but only one gets paid.
Using Apple’s preferred practice of using no article before iPhone (ie. never “an iPhone” or “the iPhone” or even “iPhones”) makes you come off as a shill, by the way. It’s like if you unironically put a trademark symbol after it.
Art isn't craftsmanship.
You can make art with a literally piece of shit, or a toilet if you want to be more traditional, at least in 1917.
You can't be a craftsperson without mastery of your domain and its tool.
You can be a artist without craftsmanship and vice versa.
You can also be popular without any or both of these.
There is a lot to entangle there but the point is that it depends on your goal. You can judge others based on your own value system but there goals might not be yours.
I think a better analogy would be commissioning an artist to create a painting. Yes you provided instructions and decided which style you preferred, and maybe pointed some corrections you wanted. And you can be proud of owning that specific, unique painting. No you didn't create anything.
This is so good, I wonder if op did it on purpose.
Orders of magnitude more people can now make an absolutely "Hollywood quality" movie, precisely due to their nice modern iPhone cameras.
The only question now is, how do we make it so more people can see the good ones?
I - and many, many others - learned flask from his mega-guide that he obviously spent a lot of time working on.
I feel bad for people like him who get the brunt of dilettantes who can "code" polluting his time and focus. Reminds me of that mitch hedberg joke: "When someone hands you a flyer, it's like they're saying here you throw this away." but for PRs
I recently built a very large test bench for System Verilog.
I ran a bunch of different compilers on it, including some open source ones.
Some of them failed some tests, and it was natural to have my LLM (Claude Fable 5) root-cause the issues, and to double-check my test bench wasn't to blame.
But now I stood with all these patches that I couldn't just throw at the upstream maintainers all at once. I ended up just filing a few issues and moved on to other things.
It felt weird to just file issues when my LLM had already spent a lot of time root-causing and fixing the issues. But then, maybe they could just have their LLMs do the same.
Still not sure if it was the right call?
> I ended up just filing a few issues and moved on to other things.
This is the most valuable contribution you had time for, hopefully with a minimum-viable bug reproduction.
Drive-by patches/PRs are usually a net-negative because the maintainer has to reverse-engineer the intent from GenAI code, and then make changes to have it fit in with the rest of project.
> It felt weird to just file issues when my LLM had already spent a lot of time root-causing and fixing the issues
There are countless ways to fix any issue, and only a few right ways (subjectively). The maintainers' role is to decide which ways are right for their project. You shouldn't worry too much about "wasting" code you already generated, GenAI made that step very cheap, but did little for taste and roadmapping.
This is a real problem.
I suspect that part of it is that people don’t have enough time to mentally incorporate the fix.
Is it weird to submit the MR later, after people have had a chance to digest the issues?
> My perception is that there is less interest in open source, and in coding in general. The main reason I love coding is that it is a challenge, and I think this is actually the same reason why a lot of people prefer to give money to an AI lab and get a machine to spit out code for them, even with the risk of the code being subpar.
I maintain the hope that those technically minded who are really interested in coding and care about doing things properly using their own reasoning on all levels of detail will find each other and maybe become less diluted as a community by the coding-just-for-money crowd than in the past decade or two.
Even if this guy were not anti-AI, as the primary maintainer of OS projects, it sounds like he's dealing with a genuine problem.
> My initial task when a new unexpected PR arrives is to determine if there is a person behind it or not, and luckily this is easy to figure out in just a few seconds.
OK. How? That would have been an interesting explanation to me.
I feel like these 2 sentences answer what the author is looking for:
> I do not want an LLM-generated novel with chapters, bullet points and emojis, just a simple description of the problem in your own voice.
> If I don't see proof of human involvement, then I'm not interested
If someone goes out of their way to hide it, it probably can't be detected. But the default commit comment and PR writeup styles are pretty distinctive.
> OK. How?
By vibe. That's what people who believe they can detect AI do.
Don't blame the people who dislike AI, blame the people producing AI and using it to produce mass amounts of trash. They're the ones poisoning the public well and making all of this distrust necessary
I didn't blame anyone? I judge whether an article / repo is AI-generated by vibe too. Vibe/intuition is the essential part of our daily lives. It's the #1 think you ask yourself in an interview.
You pretty quickly get a sense for it. But the author does also explicitly list a few indicators.
>OK. How?
Have you never seen vibe-slopped PRs?
Asking contributors to first make sure there is an approved requirement before creating a PR sounds like a great idea regardless of the use of LLM.
But another issue is - AI disclosure (agent, model etc). I'm sure others tried similar approaches, but in case this is not common knowledge - I tried to see what happens if you ask agents to disclose themselves in the PR description / comments in a rule file.
It seems to work pretty well as most AI "assisted" PRs will be opened by agents using the gh cli or MCP on behalf of the user. (Of course this can be bypassed, but for someone who doesn't mind disclosing or doesn't care, this is a good step forward)
Example: https://github.com/arnica/depsguard/blob/main/AGENTS.md#ai-d...
(so far worked on PRs from both Claude Code and Codex - both got a footer disclosure of the agent name and model)
> Generative AI notice: I do not use LLMs, agents or any other generative AI tools for help with writing, coding, image creation or any other tasks related to this blog or my open source work.
This reminds me way back when you would see "Website written in Notepad" on websites.
We had a process at one company where you had to create an issue before filing a PR. I found it most non-sensical and introducing friction for no good reason. Very surprised to see the author suggesting it in the article.
Review is indeed the main bottleneck now for open source, and we need to solve it. Introducing more friction is hardly helping.
The author is describing a method for turning a low trust/no trust environment into a slightly higher trust environment.
A company is usually already a high-trust environment, where people use real names and have real reputations. So creating an issue cannot serve the purpose of increasing trust.
I think the point that he is making is that the additional friction is a good thing and necessary in this case because it's an open source project. It's too easy to do drive-by PRs that don't actually provide value and just eat up review cycles. The issue requirement simply ensures that the requester actually is invested and cares enough about this to get approval before starting work on it.
I can see why that doesn't sound great particularly on a team where everyone knows each other and is working together but it totally makes sense for me if I were maintaining a project that was large enough to get a lot of low-effort PRs coming into it.
In my opinion review will always be a bottleneck, in OS as well as in commercial development.
To my understanding Code Review is first and foremost a trust-building exercise, seeking to establish common understanding behind the piece of code which is to be delivered. That it also may lead to improvements or "catch some bugs" is a distant tertiary side-effect, not the primary goal. At least this is the vantage point I reviewed any code from in the last two decades, and found that team morale and overall quality of teamwork - and delivered software, and customer satisfaction, as a result - responds very well to such interpretation. Regardless of the side you are on and competency level of your vis-a-vis. I would put "elevating competency level of both partners" as a secondary goal of Code Review, and very closely connected to the primary.
With current crop of LLMs there simply nothing on their side to which words "trust" and "understanding" can be meaningfully applied. Hence the "review" takes drastically different shape and implies very different goals. As both the primary and secondary goals described above cannot apply too. The only remaining goal of "improving and bug-catching", in absence of trust, understanding and learning, now requires much more work, which is also much more exhausting.
And a follow-up to my comment above, as wanted to reply to "create an issue before filing a PR" remark too.
I find it actually extremely useful practice. We engineers tend to center our thoughts around "code" and with such code-centric mindset to accumulate knowledge as "code-adjacent" - in repo's commits, PRs, markdown files of all sorts. But in reality most if not all projects extends past the code, and it makes much more sense to have a "project-centered" mindset. As such, an external "issue" captures much more context and provides more useful insight about project impact than PR description alone. Love or hate JIRA, beyond microscopic solo-projects it makes full sense to use broader-scope external tools for project management.
As a nice cosmetic effect it also removes (some) bickering about whether to put "type" or "scope" first in the commit message :). Simply provide a reference to the ticket! (No, really, I hate JIRA, honestly!)
Are there other companies? Where you are submitting PRs that solve no known problem?
We had that process too, and I insisted on it. Any PR not matched to one or more issues gets automatically rejected. The friction this injects ensures people are not wasting company resources bikeshedding.
I'm a world champion bikeshedder, and I both hated this policy and insisted we keep it.
The article closes with the question: "Does open source matter anymore?"
I wouldn’t pretend to have an answer. of course. Opens Source means, always meant, different things to different people.
I know what always counted for me:
1. Copyleft License
2. No CLA or Copyright assignment
3. Diverse group of contributors
I sympathize with Miguels point but it bothers me it clashes with point 3 in my list. If you hand select your contributors[1] you will never reach the diversity necessary to effectively make relicensing impossible. Without that Open Source matters less to me.
[1] I admit that controlled set of known contributors has other advantages too.
He is 'hand selecting' for people that show respect for others. Still plenty of room for diversity within that framework.
"Diversity" doesn't mean "zero thresholds for skill or respect".
The PR quality problem is legit and needs a solution.
But saying his opinion hasn’t changed on this:
“the main and most important reason why GenAI tools do not work for me is that they do not make me any faster.”
It’s been a year and agents and models have improved dramatically.
I can see for some things it doesn’t make sense, but not using it at all because there’s nothing it can help with?
Devs who don’t use models at all are a dying breed and I think it won’t be long before he’ll be forced to concede the point.
> It’s been a year and agents and models have improved dramatically.
Then why is the PR quality still a problem?
Because having more powerful tools is a different problem from using them well.
When GUI apps first made it easy for anyone to use 100 fonts and colors in a document, it did not make the quality of design go up. The tools became more powerful but the average quality of design went down because lots of people with less skill could suddenly participate.
Same issue here, two things are true at once. Models and agents are very powerful, and it makes it possible for less skilled or less conscientious developers to increase volume of low quality PRs.
This is what needs a solution with the PRs.
> It’s been a year and agents and models have improved dramatically.
It's been years of AI advocates saying that. It has never yet been true, and it isn't true today either.
Why is that any of your business?
GitHub Issues before PRs is a great approach. The ghostty project takes that one step further: GH _discussions_ before GH issues. Only maintainers can make issues.
Solution: write a markov generator (or use the cheapest AI possible) to generate plausible-looking rejections for PRs.
Let those agents bankrupt their owners in a loop of neverending improvements and changes.
I totally understand the point of view from maintainers. Review fatigue of low quality slop is a legitimate issue.
The worst ones are fully autonomous AI agents looking for open source projects and adding random pull requests.
But in some cases, I find a legit bug that needs fixing. For example, I want to get a particular program working in Wine/FEX on aarch64 [1], or I find a 12 second hang in Darktable [2]. The problem is that, as a software engineer working in a totally different discipline, I have no knowledge of the low level C code to fully understand what the problem even is, or how to fix it. All I want to do is to fix the issue and help other people avoid running into the same issue. Right now, on my machine, I maintain a set of custom patches to get everything working. But I am too dumb and ignorant to figure out how to create the fix by hand, so I can't submit a pull request (or when I do, I feel really bad about it. I honestly feel like a horrible person, e.g. when a project added a "No AI" policy soon after I submitted some AI-generated PRs [3]). Going forward, I feel like this sort of scenario is going to be way more common.
[1] https://github.com/FEX-Emu/FEX/issues/5512
[2] https://github.com/darktable-org/darktable/pull/21069
[3] https://github.com/FEX-Emu/FEX/commit/8c85096f98084ca9438b16...
Then say all of that in the issue. Say you have a real problem. Say you tried using AI. Add the human element by communicating. I dont think there is a real problem there.
People just want to know you put in the effort, and that you didnt just prompt an AI and hand over completely unchecked slop.
Yes I wrote the issue by hand and try to communicate well.
It seems like there is a ready solution here, have an LLM review and filter pull requests from unknown sources before you read them. My understanding is there are semi-reliable ways to detect AI writing, maybe there is an analog for code. In any case, you can filter according to criteria you set. Analysis and bug-finding is where LLMs shine, much more than their ability to generate code.
I can understand wanting to minimize your interaction with LLMs, so this might not be an attractive solution. But it seems like a worthwhile feature to have on the platform level for people who would like to continue to accept pull requests without the frustration.
"AI-detectors" are still probabilistic and none of them are exactly stellar. (No, even Pangram. It still screws up on the regular, very badly.) And some of that includes calling real people's writing "AI-generated", which isn't acceptable for this task.
What criteria are people using to discern if code contributions are from humans or LLM?
Are there concrete patterns that somebody could write a linter to auto evaluate for this?
A reverse centaur is just a person with a horse head right? I don’t get the analogy. I understand he’s talking about getting pushed around by an LLM, but would a normal centaur push an LLM around? It doesn’t even have any hands right? Seems like a reverse centaur is more capable of typing.
> A reverse centaur is just a person with a horse head right?
Well, no. A centaur is a normal person with stronger-than-human legs. That is, it's an augmented person who drives the powerful machinery underneath. Think of a person driving a car.
A reverse centaur is the opposite, namely, a machine making the choices and a frail human following them. In this context, a reverse centaur is an AI spitting thousands of LOC for a human to find the good ones.
> A centaur is a normal person with stronger-than-human legs.
Well also more numerous than human legs... And the whole two torsos thing
https://upload.wikimedia.org/wikipedia/commons/thumb/c/c8/Te...
Those mad about auto-rejected drive-by PRs should go fork themselves
a copy of the repo.
It's just silliness. Judge the code on the merit of the code, not deciding to reject it if you learn it was constructed with the aid of AI.
The question that resonated with me was whether open source even matters anymore.
I think it does but there are weird dynamics I don’t fully understand. I’m curious about HNs thoughts.
My theories: Centralization around key projects due to AI pointing new users towards them. (At the same time this drives up the PR deluge onto these projects. Especially from newer users already heavily using llms.)
So many low effort AI-generated open source libraries that it becomes harder to tell signal from slop. More movement to the bigger projects because they are perceived as safer bets.
I think we need to stop having open source as soon as possible to stop giving AI more material to train on.
Sucks, because open source was a really wonderful thing for many years but we should not continue to create fuel for the theft machines
I think the answer to this question probably doesn't exist and opinions will remain divided. I can understand this person's feelings. But I 'won't be able to feel them' because I'm in a different position. The technology this person takes pride in is directly affected by AI.
On the other hand, there are also people who start coding with AI, and those people will love a large part of code that isn't pretty but works.
Some will say that messy code will ruin software in the long run, while others will think otherwise. This reminds me of Sturgeon's law: 90% of everything is crap. This means that for any type of thing, there are quality items and inferior ones, and quality items make up about 10%. The 10% of code created by AI will be valuable, and only 10% of human-written code was valuable. AI has just increased the amount of crap.
Whenever I think about these issues, I always think of Undertale. Undertale's code is overwhelmingly messy, yet it's a masterpiece often cited as one of the best games. I love it too. But Leaked Undertale code (its quality) is terribl
Ultimately, it seems that AI's usefulness and harmfulness are determined by the purpose for which it is used.
If someone enjoys code quality, long-term perspective, and intellectual exchange and interaction with people from these kinds of discussions, they will be hostile toward AI.
On the other hand, someone like me, who is in a community that has a hostile attitude toward on-time delivery for clients and learning (based on mockery and disregard), will be receptive to AI.
Honestly, I am a direct beneficiary of AI. I'm on the side of consuming the results managed by open-source maintainers, so I can't fully understand their position. I just think, 'That must be incredibly hard for them.'
In my case, AI writes English functions and documentation, and by using AI to refactor English function/variable names that were previously hard to use, I can now write code that's easier to read.
But since my role mainly involves assembling things using IoC on top of frameworks, I see more advantages. The downside is that my coding skill declines, I suppose. I'm a traveling contract programmer who often goes on-site to work with legacy codebases and add features to them.
Actually, my workflow hasn't changed much. It's just that the legacy codebase has become an AI-generated codebase. My workflow of debugging and tracing the flow there hasn't changed, so I'm probably in the beneficiary camp.
Conversely, people like the OP have seen a massive change in the number of PRs they need to handle, so it's understandable. The intellectual exchange with people they've always had, and the values that come from that, have been damaged.
This is a really difficult problem.
On the other hand, there’s nothing more frustrating when I submit a hand-written issue to an open source project, happy to implement it if they approve, and then their bot closes it with some AI slop comment that indicates it has no idea what I’m talking about.
On the plus side it’s easier than ever to patch or fork projects. So at least this toxic gatekeeping behavior matters less than it used to.
> Does open source matter anymore?
Probably not, but maybe free software now matters more.
> Does open source matter anymore?
I mean, did it ever? It depends what you mean. Very few open source or free software projects are successful in any meaningful sense.
Considering that the whole industry, including the big AI companies, is built on top of open source now, I would have to say it did matter. That doesn't mean every project mattered (in a larger sense), but certainly thousands of open source projects have value, and dozens have contributed enormous value. The fact that the value has been disconnected from the maintainers has been a problem for a long time, but it is getting worse, and this is one example of a maintainer near the breaking point.
I feel like projects can be successful without being popular.
To me the "open source" model implies something about community development and people sharing or otherwise using it. Otherwise what does it matter if it's open or closed source?
As a systems engineer, ive been a reverse centaur more often than not.
I have a Jira queue. It drives what work I do. I may have some leeway in how I do the work, and what tickets I pull, but Im absolutely at the behest of the ticketing behemoth.
Tickets have been my life since I started helpdesk. And future roles will also be ticketed. And they almost all are customer-facing or system-breakage (which impacts lots of customers).
Im not sure what IT roles im capable of doing wouldnt have tickets. So, yeah. Reverse centaur.. But not an AI driven reverse centaur, yet.
Reverse centaur means a machine is using you to get things done. Presumably at the other end of the ticketing system is other people. So not really the same thing at all.
I look at at reverse centaurs as a spectrum of autonomy at work.
We can now observe a complete reverse centaur. But those of us who go ticket after ticket, metrics of tickets, response times, and all of those management metrics also go directly to reverse centaurs as well.
Now, its not Marshall Brain's "Story of Manna" level each listed action at a time... But it was definitely getting to that point.
Call centers were already absolutely at that point, with completely scripted communications, that that attendant could not deviate from or be fired.
> Presumably at the other end of the ticketing system is other people.
Sometimes. As a systems engineer, tickets can also be generated by other systems as an "immune response" to detected but unfixable errors.
To respond to the ending of this piece, I think open source still matters because LLMs generate very specific code for a specific situation. Quality libraries mean solutions can be reliably shared between projects.
But how do you tell quality libraries from LLM generated ones? How do you even discover up quality libraries if you are leaving so many code decisions to LLMs? Once the LLMs train on your quality libraries how do you stop so many copies just getting pasted into people's code without your attribution and without directing people back to your library (and your very human interests in funding development on it or getting copyleft contributions back to it)?
I think there are so many hard questions right now for "Does open source even matter any more?" and many of those questions seem particularly demotivating to me right now, especially because we don't seem to be at risk of getting some, much less better, answers any time soon.
> how do you tell quality libraries from LLM generated ones?
Reputation. LLM libraries can also be high quality in theory. It's the level of effort, duration of use, stability, and test coverage. People will need to resist using LLMs to make huge transformations of their libraries all the time to avoid erasing their reputations unless they have convincing safeguards like comprehensive tests or formal proofs that are not touched.
> Once the LLMs train on your quality libraries how do you stop so many copies just getting pasted into people's code
Those copies are not reliable like a callsite. Maybe there is less advertising... but it is still better to use the library. I have to hope that at some point AI psychosis will end and engineering, which has not changed, will remain. You have to have reliable inputs to your processes. To do otherwise is insanity.
> getting copyleft contributions back to it
This is a hard question. That said, for my own libraries, I get very few contributions but people use the libraries! The more "hardcore" the library is, the higher the ratio of users to contributors because they're just not expert enough to contribute meaningfully (until your stuff becomes so valuable companies sponsor teams of contributors as in Linux).
That said, my libraries seem to have made it into the weights, so when I talk to LLMs about my problem space they shockingly frequently recommend my own libraries to me (which is kind of ego stroking not gonna lie).
I think there's a lot of reasons to feel demotivated right now, but my perhaps privileged attitude (since I don't have bosses forcing me to use AI for everything) is to use AI where appropriate and apply engineering discipline and thinking in all cases. Retain your own human skills. If expertise really does become completely devalued, we're going to have bigger problems than you can solve on your own.
I agree with the core maintainer complaint here: PR slop is bad, and maintainers should not be forced into reviewing code the submitter does not understand.
But I think the answer is not “don’t slop me, all you sloppers.” The better answer is closer to: “what problem were you trying to solve?”
There is no obligation to treat every PR as merge-ready code. A PR can also be a concrete issue report or a proof-of-concept for a bug. It can say: I found a problem, I investigated it, and code was the clearest way to show where I think the issue lives and how it might be addressed. Use or ignore the implementation as you like. Human-language descriptions are not always the best way to communicate something you've already traced through the codebase.
That can be a high-value contribution even if the code itself is not accepted. It moves the conversation from “I want X” to “here is where X touches the codebase, here is a failing case, here is a possible direction, here are the tradeoffs I noticed.”
The social contract should be that the contributor does not dump review debt on the maintainer. Mark it as a prototype. Explain the problem in your own words. Say what you tested. Say what you are unsure about. Be willing to revise or accept that the maintainer may throw the patch away.
But once framed that way, the relevant question is not whether AI was used. It is whether the PR reduces ambiguity or increases burden.
A sloppy PR that demands review is bad. A prototype PR that explains a real problem is often useful.
This blog post had serious "old man yells at cloud" vibes for me.
The old man is absolutely pointing out a very real problem. It is too easy with LLMs to create crap PR:s.
I learned Flask from Grinberg, god bless the man.
nope, it's an old man yelling get off my lawn. And as a fellow old person with an open source lawn, I 100% sympathize.
My lawn == I'm not wasting any of my dwindling old man time on bullshit people vomit out. You want to do that, you fork and leave me out.
The priesthood doesn’t like that the peasants can read the Bible for themselves now.
No one was ever stopping anyone from learning to program in the past. Don't act like there was some massive gatekeeper you had to overcome to learn to code other than your own laziness
There hasn't been a programming priesthood for decades, now.