As both developers and stewards of significant open source projects, we’re watching AI coding tools create a new problem for open source maintainers. AI assistants like GitHub Copilot, Cursor, Codex,…
As both developers and stewards of significant open source projects, we’re watching AI coding tools create a new problem for open source maintainers.
AI assistants like GitHub Copilot, Cursor, Codex, and Claude can now generate hundreds of lines of code in minutes. This is genuinely useful; but it has an unintended consequence: reviewing machine generated code is very costly.
The core issue: AI tools have made code generation cheap, but they haven’t made code review cheap. Every incomplete PR consumes maintainer attention that could go toward ready-to-merge contributions.
At Discourse, we’re already seeing this accelerating across our contributor community. In the next year, every engineer maintaining open source projects will face the same challenge.
We need a clearer framework for AI-assisted contributions that acknowledges the reality of limited maintainer time.
A binary system works extremely well here. On one side there are prototypes that simply demonstrate an idea. On the other side there are ready for review PRs that meet a project’s contribution guidelines and are ready for human review.
The lack of proper labeling and rules is destructive to the software ecosystem
The new tooling is making it trivial to create a change set and lob it over the fence. It can introduce a perverse system where project maintainers spend disproportionate effort reviewing lopsided AI generated code that took seconds for contributors to create and now will take many hours to review.
This can be frustrating, time consuming and demotivating. On one side there is a contributor who spent a few minutes fiddling with AI prompts, on the other side you have an engineer that needs to spend many hours or even days deciphering alien intelligence.
This is not sustainable and is extremely destructive.
The prototype
AI coding agents such as Claude Code, Codex, Cursor CLI and more have unlocked the ability to ship a “new kind” of change set, the prototype.
The prototype is a live demo. It does not meet a project’s coding standards. It is not code you vouch for or guarantee is good. It lacks tests, may contain security issues and most likely would introduce an enormous amount of technical debt if merged as is.
That said it is a living demo that can help make an idea feel more real. It is also enormously fun.
Think of it as a delightful movie set.
Prototypes, especially on projects such as Discourse where enabling tooling exists are incredibly easy to explore using tools like dv.
% dv new my-experiment
% dv branch my-amazing-prototype
% dv ls
total 1
* my-amazing-prototype Running 1 minute ago http://localhost:4200
# finally visit http://localhost:4200 to see in action
Prototypes are great vehicles for exploring ideas. In fact you can ship multiple prototypes that demonstrate completely different solutions to a single problem which help decide on the best approach.
Prototypes, video demos and simple visual mockups are great companions. The prototype has the advantage that you can play with it and properly explore the behavior of a change. The video is faster to consume. Sometimes you may want them all.
If you are vibe coding and prototyping there are some clear rules you should follow
- Don’t send pull requests (not even drafts), instead lean on branches to share your machine generated code.
- Share a short video AND/OR links to a branch AND/OR quotes of particular interesting code from the prototype in issues / or forum posts.
- Show all your cards, explain you were exploring an idea using AI tooling, so people know the nature of the change you are sharing.
Maybe you will be lucky and an idea you had will get buy-in, maybe someone else may want to invest the time to drive a prototype into a production PR.
When should you prototype?
Prototyping is fun and incredibly accessible. Anyone can do it using local coding agents, or even coding agents on the cloud such as Jules, Codex cloud, Cursor Cloud, Lovable, v0 and many many more.
This heavily lowers the bar needed for prototyping. Product managers can prototype, CEOs can prototype, designers can prototype, etc.
However, this new fun that opens a new series of questions you should explore with your team.
- When is a prototype appropriate?
- How do designers feel about them?
- Are they distracting? (are links to the source code too tempting)?
- Do they take away from human creativity?
- How should we label and share prototypes?
- Is a prototype forcing an idea to jump the queue?
When you introduce prototyping into your company you need to negotiate these questions carefully and form internal consensus, otherwise you risk creating large internal attitude divides and resentment.
The value of the prototype
Prototypes, what are they good for? Absolutely something.
I find prototypes incredibly helpful in my general development practices.
- Grep on steroids. I love that prototypes often act as a way of searching through our large code base isolating all the little areas that may need changing to achieve a change
- I love communicating in paragraphs, but I am also a visual communicator. I love how easy a well constructed prototype can communicate a design idea I have, despite me not being that good in Figma.
- I love that there is something to play with. It often surfaces many concerns that could have been missed by a spec. The best prototype is tested, during the test you discover many tiny things that are just impossible to guess upfront.
- The crazy code LLMs generate is often interesting to me, it can sometimes challenge some of my thinking.
The prototype - a maintainers survival guide
Sadly, as the year progresses, I expect many open source projects to receive many prototype level PRs. Not everyone would have read this blog post or even agree with it.
As a maintainer dealing with external contributions:
- Protect yourself and your time. Timebox initial reviews of large change sets, focus on determining if it was “vibe coded” vs leaving 100 comments on machine generated code that took minutes to generate.
- Develop an etiquette for dealing with prototypes pretending to be PRs. Point people at contribution guidelines, give people a different outlet. “I am closing this but this is interesting, head over to our forum/issues to discuss”
- Don’t feel bad about closing a vibe coded, unreviewed, prototype PR!
The ready to review PR
A ready to review PR is the traditional PRs we submit.
We reviewed all the machine generated code and vouch for all of it. We ran the tests and like the tests, we like the code structure, we read every single line of code carefully we also made sure the PR meets a project’s guidelines.
All the crazy code agents generated along the way has been fixed, we are happy to stamp our very own personal brand on the code.
Projects tend to have a large set of rules around code quality, code organisation, testing and more.
We may have used AI assistance to generate a ready to review PR, fundamentally, though this does not matter, we vouch for the code and stand behind it meeting both our brand and a project’s guidelines.
The distance from a prototype to a ready to review PR can be deceptively vast. There may be days of engineering taking a complex prototype and making it production ready.
This large distance was communicated as well by Andrej Karpathy in the Dwarkesh Podcast.
For some kinds of tasks and jobs and so on, there’s a very large demo-to-product gap where the demo is very easy, but the product is very hard.
…
For example, in software engineering, I do think that property does exist. For a lot of vibe coding, it doesn’t. But if you’re writing actual production-grade code, that property should exist, because any kind of mistake leads to a security vulnerability or something like that.
Veracode survey found that only 55% of generation tasks resulted in secure code. (source).
Our models are getting better by the day, and everything really depends on an enormous amount of parameters, but the core message that LLMs can and do generate insecure code, stands.
On alien intelligence
The root cause for the distance between project guidelines and a prototype is AI alien intelligence.
Many engineers I know fall into 2 camps, either the camp that find the new class of LLMs intelligent, groundbreaking and shockingly good. In the other camp are engineers that think of all LLM generated content as “the emperor’s new clothes”, the code they generate is “naked”, fundamentally flawed and poison.
I like to think of the new systems as neither. I like to think about the new class of intelligence as “Alien Intelligence”. It is both shockingly good and shockingly terrible at the exact same time.
Framing LLMs as “Super competent interns” or some other type of human analogy is incorrect. These systems are aliens and the sooner we accept this the sooner we will be able to navigate the complexity that injecting alien intelligence into our engineering process leads to.
Playing to alien intelligence strength, the prototype
Over the past few months I have been playing a lot with AI agents. One project I am particularly proud of is dv. It is a container orchestrator for Discourse, that makes it easy to use various AI agents with Discourse.
I will often run multiple complete and different throwaway Discourse environments on my machines to explore various features. This type of tooling excels at vibe engineering prototypes.
Interestingly dv was mostly built using AI agents with very little human intervention, some of the code is a bit off brand, that said unlike Discourse or many of the other open source gems I maintain it is a toy project.
Back on topic, dv has been a great factory for prototypes on Discourse. This has been wonderful for me. I have been able to explore many ideas while catching up on my emails and discussions on various Discourse sites.
On banning AI contributions, prototypes and similar
Firstly you must be respectful of the rules any project you contribute has, seek them out and read them prior to contributing. For example: Cloud hypervisor says no AI generated code to avoid licensing risks.
That said, there is a trend among many developers of banning AI. Some go so far as to say “AI not welcome here” find another project.
This feels extremely counterproductive and fundamentally unenforceable to me. Much of the code AI generates is indistinguishable from human code anyway. You can usually tell a prototype that is pretending to be a human PR, but a real PR a human makes with AI assistance can be indistinguishable.
The new LLM tooling can be used in tremendous amounts of ways including simple code reviews and simple renamings within a file, to complete change set architecture.
Given the enormous mess and diversity here I think the healthiest approach is to set clear expectations. If I am submitting a PR it should match my brand and be code I vouch for.
As engineers it is our role to properly label our changes. Is our change ready for human review or is it simply a fun exploration of the problem space?
Why is this important?
Human code review is increasingly becoming a primary bottleneck in software engineering. We need to be respectful of people’s time and protect our own engineering brands.
Prototype are fun, they can teach us a lot about a problem space. But when it comes to sending contributions to a project, treat all code as code you wrote, put your stamp of ownership and approval on whatever you build and only then send a PR you vouch for.
Read the original article
Comments
This is a problem everywhere now, and not just in code. It now takes zero effort to produce something, whether code or a work plan or “deep research” and then lob it over the fence, expecting people to review and act upon it.
It’s an extension of the asymmetric bullshit principle IMO, and I think now all workplaces / projects need norms about this.
By solotronics 2025-10-294:113 reply This problem statement was actually where the idea for Proof of Work (aka mining) in bitcoin came from. It evolved out of the idea of requiring a computational proof of work for sending an email via cypherpunk remailers as a way of fighting spam. The idea being only a legitimate or determined sender would put in the "proof of work" to use the remailer.
I wonder how it would look if open source projects required $5 to submit a PR or ticket and then paid out a bounty to the successful or at least reasonable PRs. Essentially a "paid proof of legitimacy".
By strogonoff 2025-10-295:232 reply The parallel between PoW and barriers to entry many communities (be it Wikipedia editors or open-source contributors) use to sustain themselves seems apt.
Unfortunately, there is no community equivalent of PoS—the only alternative is introducing different barriers, like ID verification, payment, in-person interviews, private invite system, etc., which often conflict with the nature of anonymous volunteer communities.
Such communities are perhaps one of the greatest things the Web has given us, and it is sad to see them struggle.
(I can imagine LLM operators jumping on the opportunity to sell some of these new barriers, to profit from selling both the problematic product and a product to work around those problems.)
By Frieren 2025-10-296:49 > (I can imagine LLM operators jumping on the opportunity to sell some of these new barriers, to profit from selling both the problematic product and a product to work around those problems.)
That is their business model. Use AI to create posts in LinkedIn, mails in a corporate environment, etc. And then use AI to summarize all that text.
AI creates a problem and then offers a solution.
My current approach is to look at new sources lie The Guardian, Le Monde, AP news, etc. I know that they put the work, sadly places like Reddit and such are just becoming forums that discuss garbage news with bot comments. (I could use AI to identify non-bot comments and news sources, but it does not really work even if it says that it does, and I should not have to do that in the first place either).
The community equivalent of Proof of Stake is reputation. You can't do anything until you've shown up for awhile and contributed in small ways, you gradually gain the ability to contribute in bigger ways, and if you are discovered to be malicious or corrupt or toxic, then your rights are revoked. The people who've gained this trust are presumably motivated to maintain it (although there's always the risk they sell their account/identity/soul for healthcare and do some damage before they're found out).
By strogonoff 2025-10-2920:23 Reputation is always there in a community, regardless, in members’ minds. It’s just that not every community wants explicit quantified reputation, and I’m with them on that…
By troupo 2025-10-2910:24 > I wonder how it would look if open source projects required $5 to submit a PR or ticket and then paid out a bounty to the successful or at least reasonable PRs. Essentially a "paid proof of legitimacy".
Badly. You will alienate most legitimate contributors, and only leave spam bots subsidized by revenue from other sources
By sails 2025-10-298:06 $5 could go towards a strict AI reject/review funnel as a prefilter
It feels like reputation / identity are about to become far more critical in determining whether your contribution, of whatever form, even gets considered.
By theshrike79 2025-10-2822:28 Web of Trust will make a comeback. Both personal and on actual websites.
If I can say I trust you, the websites you trust will be prioritised for me and marked as reliable (no AI slop, actual humans writing content).
By stevenhubertron 2025-10-2815:39 Perhaps it's time for Klout to rise from the ashes?
> expecting people to review and act upon it.
But why should this expectation be honored? If someone spends close to zero effort generating a piece of code and lobs it over the fence to me, why would I even look at it? Particularly if it doesn't even meet the requirements for a pull request (which is what it seems like the article is talking about)?
Because that's the definition of collaboration? Prior to the invention of LLMs, one could generally assume requests for collaboration were somewhat sincere due to the time investment involved. Now we need a new paradigm for collaboration.
> Because that's the definition of collaboration?
I don't think the definition of collaboration includes making close to zero effort and expecting someone else to expend considerable effort in return.
The problem is that the sheer volume of low-quality AI PRs is overwhelming. Just the time it takes determining whether you should pay attention to a PR or not can add up when there are a lot of plausible-looking, but actually low-quality and untested, pull requests to your project.
But if you stop looking at PRs entirely, you eliminate the ability for new contributors to join a project or make changes that improve the project. This is where the conflict comes from.
By saghm 2025-10-297:44 Since the bar to opening a PR has gotten lower, there's an argument that the bar for closing it might need to be lowered as well. I think right now, we consider the review effort to be asymmetric in part because it's natural to want to give the benefit of the doubt to PR authors rather than making a snap judgement from only a looking briefly at something; the current system seems to place a higher value on not accidentally closing a potentially useful but poorly presented PR than not accidentally wasting time on one that superficially appears like it might be good but isn't. I have to wonder if the best we can do is to just be more willing to close PRs when reviewers aren't sufficiently convinced of the quality after a shorter inspection regardless of whether we're 100% certain about whether that judgment is perfect. If "false positive" PRs that seem reasonable but turn out not to be are better at appearing superficially good, the best option seems like it might just be to be willing to throw out more "false negatives" that would be useful but aren't sufficiently able to distinguish themselves from the ones that aren't.
After a minute (or whatever length of time makes sense for the project), decide whether you're not fully confident that the PR is worth your time to continue reviewing, with the default answer being "no" if you're on the fence. Unless it's a yes, you got a bad vibe; close it and move on. Getting a PR merged will require more effort in making the case that there's value in keeping it open, which restores some of the balance that's been lost in the effort having been pushed to the review side.
By nkrisc 2025-10-299:06 PR authors blow now need to spend energy and effort to make their PR appear worthwhile for consideration. AI PRs will have the effect of shifting the burden of effort to the PR authors (the real ones).
No more drive-by PRs.
By _DeadFred_ 2025-10-2818:39 My music/Youtube algos are ruined because when I flag I don't like the 100 AI songs/videos that it presents me each day the algos take it as my no longer liking those genres. Between me down rating AI music/AI history videos, Youtube now give me like half a page of recommendations then gives up. I'm now punished by Youtube/my experience is worse because Youtube's cool with hosting so much AI slop content and I chose to downrate it/try to curate if out of my feed. The way Youtube works today it punishes you (or trys to train you not to) for flagging 'don't recommend channel' when recommended a channel of AI slop. Flag AI and Youtube will degrade you algo recommendations.
By aleph_minus_one 2025-10-298:101 reply > This is a problem everywhere now, and not just in code. It now takes zero effort to produce something, whether code or a work plan or “deep research” and then lob it over the fence, expecting people to review and act upon it.
Where is the problem? If I don't have the time to review a PR, I simply reject it. Or if I am flooded in PRs, I only take those from people from which I know that their PRs are of high quality. In other words: your assumption "expecting people to review and act upon it" is wrong.
Even though I would bet that for the kind of code that I voluntarily write in my free time, using an LLM to generate lots of code is much less helpful because I use such private projects to try out novel things that are typically not "digested stuff from the internet".
So, the central problem that I rather see is the license uncertainties for AI-generated code.
You're still getting DDoSed. If you only accept PRs from pre-vetted people you'll inevitably be left with zero contributors: people naturally leave over time, so in order to maintain a healthy ecosystem you need to accept some newcomers.
Don't throw the baby out with the bathwater.
By mnau 2025-10-2913:53 There is no healthy ecosystem. Most packages are one or two contributors. And have been for forever. Granted, it's Nuget, where MS is the giant that overshadows everything, but I have read a lot of about this and it's same everywhere.
By AndrewKemendo 2025-10-2913:30 I think people are starting to realize what the “end of work” is going to look like and they don’t like it
By softwaredoug 2025-10-2812:3110 reply Anyone else feel like we're cresting the LLM coding hype curve?
Like a recognition that there's value there, but we're passing the frothing-at-the-mouth stage of replacing all software engineers?
By mavamaarten 2025-10-2816:402 reply My opinion swings between hype to hate every day. Yesterday all suggestions / edits / answers were hallucinated garbage, and I was ready to remove the copilot plugin altogether. Today I was stuck at a really annoying problem for hours and hours. For shits and giggles I just gave Claude a stacktrace and a description and let it go ham. It produced an amazingly accurate thought train and found my issue, which was not what I was expecting at all.
I still don't see how it's useful for generating features and codebases, but as a rubber ducky it ain't half bad.
Well part of your problem is you are still using copilot. Its fully outdated compared to claude/codex. This tech moves fast.
By mavamaarten 2025-10-2919:431 reply Well, I gotta use whatever my organization whitelists and provides me a license for. I do use Claude models inside copilot (for Ask/Edit/Agent mode).
By aydyn 2025-10-302:42 Totally understand. My org only allows copilot by default. I convinced my manager to pay for claude, but it was a serious battle to point out how much better it is.
By keyle 2025-10-291:10 This is a hundred percent true. I felt the same.
What has helped has been to turn off ALL automatic AI, e.g. auto complete, and bind it to a shortcut key to show up on request... And forget it exists.
Until I feel I need it, and then it's throw shit at the wall type moment but we've all been there.
It does save a lot of time as a google on steroid, and wtf-solver. But it's a tool best kept in its box, with a safety lock.
By jermaustin1 2025-10-2813:413 reply I've been skeptical about LLMs being able to replace humans in their current state (which has gotten marginally better in the last 18 months), but let us not forget that GPT-3.5 (the first truly useful LLM) was only 3 years ago. We aren't even 10 years out from the initial papers about GPTs.
By dragontamer 2025-10-2815:401 reply > was only 3 years ago
That's one way of looking at it.
Another way to look at it is GPT3.5 was $600,000,000,000 ago.
Today's AIs are better, but are they $600B better? Does it feel like that investment was sound? And if not, how much slower will future investments be?
By jermaustin1 2025-10-2816:041 reply Another way to look at $600B of improvement was whether or not they used the $600B to improve it.
This just smells like classic VC churn and burn. You are given it and have to spend it. And most of that money wasn't actually money, it was free infrastructure. Who knows the actual "cost" of the investments, but my uneducated brain (while trying to make a point) would say it is 20% of the stated value of the investments. And maybe GPT-5 + the other features OpenAI has enabled are $100B better.
By dragontamer 2025-10-2817:25 > And most of that money wasn't actually money, it was free infrastructure.
But everyone who chipped in $$$ is counting against these top line figures, as stock prices are based on $$$ specifically.
> but my uneducated brain (while trying to make a point) would say it is 20% of the stated value of the investments
An 80% drop in valuations as people snap back to reality would be devastating to the market. But that's the implication of your line here.
By danaris 2025-10-2818:48 And yet, we're clearly way into the period of diminishing returns.
I'm sure there's still some improvements that can be made to the current LLMs, but most of those improvements are not in making the models actually better at getting the things they generate right.
If we want more significant improvements in what generative AI can do, we're going to need new breakthroughs in theory or technique, and that's not going to come by simply iterating on the transformers paper or throwing more compute at it. Breakthroughs, almost by definition, aren't predictable, either in when or whether they will come.
By troupo 2025-10-2910:32 Why are you assuming exponential or even linear growth/improvement?
E.g. OpenAI went from "AGI has been achieved internally" to lying with graphs (where they cut off graphs at 50% or 70% to present minor improvements as breakthroughs).
The growth can easily be logarithmic
By dekoidal 2025-10-2813:40 Well, when MS give OpenAI free use of their servers and OpenAI call it a $10 billion investment, then they use up their tokens and MS calls in $10 billion in revenue, I think so, yes.
I feel like we need a different programming paradigm that's more suited to LLM's strengths; that enables a new kind of application. IE, think of an application that's more analog with higher tolerances of different kinds of user inputs.
A different way to say it. Imagine if programming a computer was more like training a child or a teenager to perform a task that requires a lot of human interaction; and that interaction requires presenting data / making drawings.
When people talk about the “AI bubble popping” this is what they mean. It is clear that AI will remain useful, but the “singularity is nigh” hype is faltering and the company valuations based on perpetual exponential improvement are just not realistic. Worse, the marginal improvements are coming at ever higher resource requirements with each generation, which puts a soft cap on how good an AI can be and still be economical to run.
What are you basing that on? Haiku 4.5 just came out and beats Sonnet 4 at a third the cost.
GPT-5 and GPT-5-codex are significantly cheaper than the o-series full models from OpenAI, but outperform them.
I won't get into whether the improvements we're seeing are marginal or not, but whether or not that's the case, these examples clearly show you can get improved performance with decreasing resource cost as techniques advance.
By crote 2025-10-2911:19 > I won't get into whether the improvements we're seeing are marginal or not
But that's exactly the problem!
Right now, AI performs poorly enough that only a small fraction of users is willing to pay money for it, and (despite tech companies constantly shoving it in everyone's face) a large portion of the user base doesn't even want to adopt it for free.
You can't spend hundreds of billions of dollars on marginal improvements in the hope that it'll hopefully eventually become good enough for widespread adoption. Nobody is going to give OpenAI a trillion dollars to grow their user base 50x over the next 15 years. They are going to need to show significant improvements - and soon, or the bubble will pop.
By NewsaHackO 2025-10-2813:56 >When people talk about the “AI bubble popping” this is what they mean.
You mean what they have conceded so far to be what they mean. Every new model they start to see that they have to give up a little more.
By corytheboyd 2025-10-2813:48 Maybe, maybe not, it’s hard to tell from articles like this from OSS projects what is generally going on, especially with corporate work. There is no such rhetoric at $job, but also, the massive AI investment seemingly has yet to shift the needle. If it doesn’t they’ll likely fire a bunch of people again and continue.
It's been less than a year and agents have gone from patently useless to very useful if used well.
Useful if used well as a thought has gone from meaning a replace all developers machine to a fresh out of college junior with perfect memory bot to a will save a little typing if you type out all of your thoughts and baby sit it text box.
I get value from it everyday like a lawyer gets value from LexisNexis. I look forward to the vibe coded slop era like a real lawyer looks forward to a defendant with no actual legal training that obviously did it using LexisNexis.
The trajectory is a replace all developers trajectory, you're just in the middle of the curve wondering why you're not at the end of it.
The funny thing is you're clearly within the hyperbolic pattern that I've described. It could plateau, but denying that you're there is incorrect.
By troupo 2025-10-2910:34 > you're just in the middle of the curve wondering why you're not at the end of it.
You assume the curve is exponential.
We assume the curve is logarithmic.
We are not the same
Why you ask a stranger on the internet for PII?
I'm genuinely curious as to what's going through your mind and if people readily give you this.
I suspect you're asking dishonestly but I can't simply assume that.
Every single one of your posts from the past two weeks is hyping up AI or down voted for being highly uninformed about every topic that isn't LLM hype related. You talk like a marketer of AI, someone that works adjacent to the industry with a dependency on these tools being bought.
By catigula 2025-10-2821:04 > Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.
You should delete this comment.
By javier123454321 2025-10-2813:461 reply I was extremely skeptical at the beginning, and therefore critical of what was possible as my default stance. Despite all that, the latest iterations of cli agents which attach to LSPs and scan codebase context have been surprising me in a positive direction. I've given them tasks that require understanding the project structure and they've been able to do so. Therefore, for me my trajectory has been from skeptic to big proponent of the use, of course with all the caveats that at the end of the day, it is my code which will be pushed to prod. So I never went through the trough of disillusionment, but am arriving at productivity and find it great.
By visarga 2025-10-2911:35 There are 3 parts of the process the AI agent can't do - the start, the middle and the end :) No, really, they need humans to identify tasks worth working on, then guide the model during development and providing iterative feedback, and in the end we incur the outcomes, good or bad. We are the consequence sinks, we take the costs and risks on ourselves. LLMs have no accountability.
By deepsquirrelnet 2025-10-2813:23 I think that happened when gpt5 was released and pierced OpenAIs veil. While not a bad model, we found out exactly what Mr. Altman’s words are worth.
It feels that way to me, too—starting to feel closer to maturity. Like Mr. Saffron here, saying “go ham with the AI for prototyping, just communicate that as a demo/branch/video instead of a PR.”
It feels like people and projects are moving from a pure “get that slop out of here” attitude toward more nuance, more confidence articulating how to integrate the valuable stuff while excluding the lazy stuff.
By user-the-name 2025-10-2813:24 [dead]
By jamesbelchamber 2025-10-2812:411 reply > “I am closing this but this is interesting, head over to our forum/issues to discuss”
I really like the way Discourse uses "levels" to slowly open up features as new people interact with the community, and I wonder if GitHub could build in a way of allowing people to only be able to open PRs after a certain amount of interaction, too (for example, you can only raise a large PR if you have spent enough time raising small PRs).
This could of course be abused and/or lead to unintended restrictions (e.g. a small change in lots of places), but that's also true of Discourse and it seems to work pretty well regardless.
By warmwaffles 2025-10-2814:04 Mailing lists are used as a filter to raise the barrier to entry to prevent people from contributing code that they have no intention of maintaining and leaving that to the project owners. Github for better or worse has made the barrier to entry much much lower and significantly easier for people to propose changes and then disappear.
