QGIS: No A contributions permitted

The root comment argues AI adoption is objectively good because it will improve code quality long term. A reply qualifies this by pointing to open-source bugs left unfixed for decades that LLMs could fix quickly and by saying good LLMs can be more diligent about updating comments and tests. Another reply challenges the premise that better code quality matters: rewriting a product like Windows with cleaner code would not make it more useful unless 'better code' translates into better features.

A comment asks why HN appears consistently pro-AI and lists possible explanations: HN users overestimating their cleverness, astroturfing or positive-sentiment manufacturing amid AI money, defensiveness among AI enthusiasts, and pedantic readings of the complaint. Replies develop the astroturfing point by saying the amount of sentiment manufacturing and denial is unsurprising, and by noting Y Combinator's and Sam Altman's financial ties as reasons to question HN as unbiased tech news. Another reply pushes back that the explanation is rude and not in good faith, arguing people use these tools因为

One comment suggests it is time to clone projects from scratch using AI. Replies ask why not fork the repository and continue with AI, and argue that a clone or fork can be made quickly but will struggle for traction because the original team has a proven track record and community problem focus. Another reply compares cloning to starting a child in 15 minutes, asking whether the creator will support it for decades; a follow-up says such forks often last only until they hit the HN front page and are then abandoned. One participant dismisses traction concerns and says they hate AI-haters.

A comment worries that open contributions are ending because maintainers are overloaded and contributors rarely save time compared with a maintainer using an LLM and reviewing it themselves. Replies debate whether contributors must prove value, whether rejected contributions can simply fork, and whether open-market competition will judge their worth; one notes that good work can still get zero traction if nobody knows about it. Another reply says the maintainer bottleneck worsens if outside contributions are rejected, and suggests detailed issues may now be a better contribution path than PRs,

A comment frames the problem as human-side alignment: the bottleneck is no longer writing code but staying aligned with it, knowing what it does and whether it matches intent, especially when maintainers review large stranger PRs. Replies expand on how hard it is to know what software does, arguing LLM-generated code can erode mental-model shortcuts and trick developers into thinking they understand code. One cites code-review studies suggesting limited impact after a few hundred lines per hour, while another says the bottleneck was never writing code but that writing forces awareness of

One reply proposes making contributors pay a small fee for review of their PRs, even as little as $1, to deter AI-generated slop. It acknowledges this could exclude students or low-wage contributors but is optimistic that a very small fee would be enough.