Review is indeed the main bottleneck now for open source, and we need to solve it. Introducing more friction is hardly helping.
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)
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.
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.
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?
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.
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 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.
Let those agents bankrupt their owners in a loop of neverending improvements and changes.
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
Are there concrete patterns that somebody could write a linter to auto evaluate for this?
a copy of the repo.
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 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.
> 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 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.
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...
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.
I mean, did it ever? It depends what you mean. Very few open source or free software projects are successful in any meaningful sense.
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.
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 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.
I'm a world champion bikeshedder, and I both hated this policy and insisted we keep it.
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 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
Have you never seen vibe-slopped PRs?
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?
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.
So at a minimum, you could maybe fish some useful work out. PRs should be the same.
It was already very fuzzy (Excel?). Soon, this line be non-existent.
There's one project where I need to download a new version once in a while and I just rebase my changes.
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.
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.
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.
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.
You mean some modern version of vb or php?
That is the entire point of low-code and no-code.
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.
There's a billion ways of opening a markdown and doing things with it and generally they all coexist hapily
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.
I learned Flask from Grinberg, god bless the man.
Sucks, because open source was a really wonderful thing for many years but we should not continue to create fuel for the theft machines
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.
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.
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.
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.
People just want to know you put in the effort, and that you didnt just prompt an AI and hand over completely unchecked slop.
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.
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.
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.
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.
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.
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.
I've always said that by only writing ASM can you get any sense of accomplishment from authoring software.
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.
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.
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.
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.
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.
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!
Well also more numerous than human legs... And the whole two torsos thing
https://upload.wikimedia.org/wikipedia/commons/thumb/c/c8/Te...
About a year ago I wrote on this blog about how coding with LLMs would not work for me, even if there were no ethical or environmental concerns preventing me to use them. I'm not going to repeat the arguments I made that time because my views on the subject haven' t changed. What has changed, however, is that the number of contributions I receive on my open source projects has gone up, and nearly all are now made with LLMs.
The other day I had a very depressing thought regarding this. All these people who submit drive-by pull requests to my projects are pushing me to spend more and more of my time reviewing and merging code that was extruded by machines. Cory Doctorow refers to people that perform this function as reverse centaurs. He calls these "frail and vulnerable people being puppeteered by uncaring, relentless machines." Ouch!
Am I a reverse centaur now? Is my new purpose as a seasoned software engineer and open source developer to spend my days reviewing LLM code, in spite of having decided that I do not need nor want this technology myself? As you can guess from the title, I'm never going to become a reverse centaur. Let me tell you how I resist the forces that want me to be one.
Back in pre-LLM days, receiving an unexpected pull request (PR) from a fellow coder was a source of excitement and pride. It meant that some random person decided it was worthwhile to invest their time and effort to improve a project of mine and share the result, not just with me but with all of its users.
Today, an unsolicited PR is a red flag. Too many people lazily prompt an LLM code generation tool and ask it to alter the behavior of one of my open source projects to meet their specific needs, without any care or consideration for what is being changed or how it might affect other users. Sometimes these changes make sense and improve the project, but often enough they do not. The submitters rarely care though, they just slap a long LLM generated description and send the PR over, leaving me with the task of figuring out if the change makes any sense at all or is pure slop.
I have decided that I have more important things to do with my life than to spend my days reviewing code produced by LLMs. If you want to contribute to one of my projects, I expect you to be the direct contributor, and to have a genuine interest in improving my project.
The contribution guidelines I include in all my open source projects have these instructions for contributors.
If you are interested in contributing a change to this project, please first introduce the change you wish to make to the maintainer in an issue. Pull requests that are submitted without a previous discussion in an issue may be closed at the maintainer's discretion.
Once the maintainer accepts your proposed change and allows you to work on it, feel free to submit a pull request.
With this process I get to know the contributor and their proposal before there is a big time investment on either side, so it is a win-win for everyone.
In spite of this I still get unsolicited PRs, so clearly some users (or more likely their LLMs) do not read contribution guidelines. 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. If I don't see proof of human involvement, then I'm not interested, so the PR gets immediately closed with no questions asked.
You may argue that with this attitude I'm likely to miss useful improvements or bug fixes to my projects, and I guess that is possible. I really have no way to know without spending time reviewing these unsolicited PRs to separate the good from the bad. When I was sure that every contribution had the effort of a person behind it this review work was justified and I even enjoyed it. In today's slop-filled world this is reverse centaur work and it is not for me, so I only pay attention to PRs that come from engaged contributors.
My advice if you can only code with the help of an LLM and need fixes or improvements in a project of mine is that you don't waste your tokens on a PR, since I will ignore it. Instead, describe the problem in an issue, and let me handle the work. 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. Since you will be saving some of those expensive tokens, you could also consider a donation, which will likely motivate me to prioritize your problem!
This is a question that I constantly ask myself, and I do not have a clear answer yet. I still do a lot of coding, both for work and for fun, but in the last few years I have been less interested in sharing the things that I make. I still have enough interest to keep my current open source projects updated, but I have a bunch of recent projects that I can't bring myself to make public.
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.
Will this trend continue to the point that nobody codes anymore and it is only machines doing it? I hope not, but we'll have to wait and see. I will continue to oppose a future in which we all have to be reverse centaurs, with the machines (and their billionaire owners) calling the shots.
Thank you for visiting my blog! If you enjoyed this article, please consider supporting my work and keeping me caffeinated with a small one-time donation through Buy me a coffee. Thanks!
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.
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.
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 =)
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"
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.
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.
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.
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.
"Blessed are the humble ..."
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.
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.
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.
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!
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!
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.
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)
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.
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.
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.