| ▲ | hliyan a day ago |
| A good thing about the "you're the author regardless of the tool you used to produce the code" policy is that if a developer repeatedly submits poor quality AI generated code, one does not blame the model or the agent, one bans/terminates the developer. |
|
| ▲ | bfgeek a day ago | parent | next [-] |
| The issue that open source projects are facing at the moment is that it takes significantly less effort to submit a patch for review. A lot of developers who are submitting these AI patches don't necessarily understand the patch, so the onus is on the reviewer/code-owner. The reviewers are getting swamped (some reviewers are receiving 100s or patches per month). If feedback is provided at lot of the time the patch author will just copy paste from an LLM, so the reviewer is essentially just coding with an LLM with more steps. Prior to LLMs reviewing code was a mentorship experience, the patch author would likely learn a bunch afterwards. Now less so. As a result a lot of projects are closing to external contributors. I'm not sure what the answer is, LLM are great at speeding up coding/understanding/etc, but the valuable/expensive piece of work has shifted to reviewing. |
| |
| ▲ | tdrz a day ago | parent | next [-] | | I'm an OSS maintainer and to me it's not just about the review itself. Being greeted by a wall of text for every little small thing is counter-productive. I hate going through 2 pages of text for each PR. It usually shouldn't take more than a couple of sentences if you understand the issue and the solution. But most important for me: lots of time the PR just adds even more code, although other options do exist (ie sometimes REMOVING some code). You have to know the codebase well in order to find those objectively better solutions. | | |
| ▲ | ahartmetz a day ago | parent | next [-] | | I've seen it. Walls of text with stereotypically worded non-summaries that just repeat all of the code in words, mutating values all over the place instead of the obvious canonical one place that touches related values... Yeah you can use LLMs, but don't let me notice it from the quality of the output. I've noticed that LLMs seem to be especially bad at things relating to space, position and movement. I guess they have to synthesize that part of human intelligence entirely, it's not in the words. | |
| ▲ | a day ago | parent | prev | next [-] | | [deleted] | |
| ▲ | othmanosx 17 hours ago | parent | prev [-] | | Give https://pyor.review a shot if you’re struggling with PR reviews on github. | | |
| ▲ | embedding-shape 16 hours ago | parent [-] | | Or, the SaaS-less approach, if a issue description is too messy/long, close it with "Please reopen with proper and concise description focusing on the issue" then lock it. Eventually people catch up and stop with the slop, just like in real life. But you have to be able to say "No ...", rather than just slapping another subscription on top of an already broken workflow. | | |
| ▲ | othmanosx 4 hours ago | parent [-] | | If you're maintaining OSS, that's understandable, and you're free to say no, but in the corporate world, that's not realistic, AI is here to stay, if they don't harness it they would just be left behind.
even if the AI gets good and stops writing sloppy stuff, it's still gonna write a lot of stuff, and you're gonna review it anyway, and take responsibility and ownership, and it's still gonna take you more time, because the bottleneck is now reviewing and understanding the code. I agree that the workflow is broken, but only on the reviewing side, AI is a tool we use to make products just like any other we used in the past, punch cards, machine code, assembly, ...etc. AI is just the new tool that sits on top of the code as the next level, no one codes with punch cards, no one writes machine code anymore, we used to write the compiled language and don't care about how it's compiled or turned into machine code, same with AI, although it's not there yet and still requires babysitting by engineers, but that's our new job now, and we need to learn how to use it and make our lifes easier. | | |
| ▲ | embedding-shape 2 hours ago | parent [-] | | > but in the corporate world Sure, but that's irrelevant when someone says "I'm an OSS maintainer" and the context is explicitly about reviewing code submitted by others in a FOSS context, where you can say "No" and don't need any SaaS in order to do so. |
|
|
|
| |
| ▲ | Loughla a day ago | parent | prev | next [-] | | The question becomes, does it take more time to create or review in the Grand scheme of the software life cycle? Because if it's still a time saver, even with the increased review load, then it's a win, correct? I'm not a coder so I have zero idea. Thoughts? | | |
| ▲ | a1o a day ago | parent | next [-] | | Nope, most of the PRs are authored entirely by agents with people instructing them to “pr famous projects in my name to increase my GitHub profile value or “hire ability”. The original authors have no idea what their agents are writing, these are mostly badly quality models (people doing this are not only cutting corners, but also using the less amount of money/tokens to do so). If the agent creates 200, 400 or whatever PRs and get 5 in the agent is still “winning” for the person instructing it. The maintainers though have to filter these out on the other side. A common case is a fix to something that was already fixed simply because the agent worked on old code assumptions. | | |
| ▲ | customguy 15 hours ago | parent | next [-] | | It doesn't help with the additional work/chores, at least initially, but someone on HN had a really good idea IMO, just take the code, and close the PR. https://news.ycombinator.com/item?id=49474708 I saw the argument that if OS maintainers "really care" about their projects, they would accept valid contributions regardless origin. Well, turn it around: if you really care so much about contributing, if you really just wanna HeLP, you don't need the credit. The warm fuzzy feeling that your contribution ended up being used should be enough. | |
| ▲ | sebmellen a day ago | parent | prev | next [-] | | Just had a thought, what if you made new contributors write a human-authored essay on why they’re submitting a patch, and then check it against Pangram? Pangram is really accurate from what I’ve found… | | |
| ▲ | aleph_minus_one a day ago | parent [-] | | >
Just had a thought, what if you made new contributors write a human-authored essay on why they’re submitting a patch, and then check it against Pangram? The problem is writing such an essay takes magnitudes more of an effort for people who are not native English (or whatever the language is in which discussions are done about the project) speakers. Also, relatedly, essays written by non-native English speakers often get considered to be AI-written by common AI detection systems, even though no AI was involved when writing them; see for example > I'm Kenyan. I Don't Write Like ChatGPT. ChatGPT Writes Like Me. > https://marcusolang.substack.com/p/im-kenyan-i-dont-write-li... | | |
| ▲ | sebmellen a day ago | parent [-] | | I’m as skeptical of the AI writing detection as anyone else, but I’ve been trying to beat Pangram v4 for the last week and it’s essentially impossible. | | |
| ▲ | sarchertech 21 hours ago | parent [-] | | Have you tried in both directions though? You need to test both sensitivity and specificity. |
|
|
| |
| ▲ | a day ago | parent | prev | next [-] | | [deleted] | |
| ▲ | newswasboring a day ago | parent | prev [-] | | > Nope, most of the PRs are authored entirely by agents with people instructing them to “pr famous projects in my name to increase my GitHub profile value or “hire ability”. I've heard this in a lot of places, don't have a way to verify this in action. Do you have any citation or just gut feel (still valid but less useful for me). | | |
| ▲ | pyreko a day ago | parent | next [-] | | Anecdotally, as someone who's been starting to get more and more agent-only/driven PRs, a good amount of the time it's by an account with little to no activity until one day they suddenly start doing 50-100+ PRs a _day_ on entirely unrelated projects... you can kind of guess what they're doing. As for motive, it probably varies, though some will loudly put that they're some agent manager or something with lots of contributions, so you can guess their motivations there. In other cases, these are instrad brand-new accounts which is a related but I guess slightly different story... not gonna say these are spam bot accounts being juiced with fake activity but well... | | |
| ▲ | newswasboring a day ago | parent [-] | | These are all fair observations, I have not personally come across these yet but I am also not looking for them. I guess someone more involved in open source collaboration would have a better lens here. |
| |
| ▲ | m4rtink a day ago | parent | prev [-] | | There was this attempt (attack?) on Fedora in June: https://lwn.net/Articles/1077035/ |
|
| |
| ▲ | sarchertech a day ago | parent | prev | next [-] | | Well historically the consensus was that it was harder to read code than to write it, but that leads to uncomfortable conclusions these days, so that bit of common wisdom has mostly been ejected. > I'm not a coder so I have zero idea. Thoughts? I’m not trying to be mean, but this comment is basically “I have no experience with this topic, but it can just be boiled down to this one simple question right?” | | |
| ▲ | Loughla 10 hours ago | parent [-] | | I don't think that's being mean at all, and it's valid. Yes that's literally why I asked it. Simple questions, here, regularly elicit long form explanations. I was interested in this topic and have no experience. So I thought I'd try a broad overview type question to see if I could learn something today. |
| |
| ▲ | 1718627440 a day ago | parent | prev | next [-] | | It's a well-known trope, that it's harder to read code than to write it, and review is more complicated than to read it, so I do not understand what you want to imply? | | |
| ▲ | blackqueeriroh a day ago | parent [-] | | Maybe it is for people who have written code all their lives, but as someone who started with reading code and has read far more code than I’ve ever written, reading code is WAY easier for me. | | |
| ▲ | sarchertech 21 hours ago | parent | next [-] | | If you have little experience writing code, do you know that you actually understand what you’re reading though? For example could you reproduce the code you read immediately after writing it? It’s very easy to “read code” if you’re just reading for surface level understanding. | |
| ▲ | 1718627440 16 hours ago | parent | prev [-] | | If it's easier for you to convert written code into mental models than the other way around, you are either a incredible smart and skilled person and a good programmer and should be able to convert that into a job and money easily, or you can't really write code at all. |
|
| |
| ▲ | bch a day ago | parent | prev | next [-] | | > The question becomes [...] "A question is...". To my mind not the most important question, if one plays-out to a logical conclusion the scenario you're proposing. > [...] if it's still a time saver, even with the increased review load, then it's a win, correct? No - and that's bordering-on (if not fully) rude disrespect of reviewers time and effort. One way to think of this is in terms of Brandolinis Law[0]. Pushing work back to submitters is going to have to happen. Low-effort "submissions" are first and foremost "low-effort" - that's going to have to be driven home. [0] https://en.wikipedia.org/wiki/Brandolini's_law | |
| ▲ | catlifeonmars a day ago | parent | prev | next [-] | | Probably a time waster because of the intermediate patch contributor. It’s like a game of telephone at worst, at best the reviewer could just use their own LLM and get the same result. Here’s my hot take: maybe code contributions are obsoleted by coding agents. No one will accept outside contributions because it’s faster to do it themselves. | |
| ▲ | pydry a day ago | parent | prev | next [-] | | It depends entirely on how much slop they are flooded with. | |
| ▲ | sgarland a day ago | parent | prev [-] | | [dead] |
| |
| ▲ | localhost a day ago | parent | prev | next [-] | | This is Amdahl's law in action. [1] Until we figure out a good way to leverage humans in all of this ("Attention is all you need" applies equally to humans as it does to models) productivity gains for the system will always be limited by Amdahl's law. Gwern has an excellent post on this. [2] [1] https://en.wikipedia.org/wiki/Amdahl's_law
[2] https://gwern.net/guardian-angel | |
| ▲ | tiahura a day ago | parent | prev [-] | | Do all of these folks get the comped Pro Max subscriptions? If not O&A should be. Or, at the very least, the community should be paying for them. |
|
|
| ▲ | lokar a day ago | parent | prev | next [-] |
| To me, that touches on the central issue. I think most people support the “I don’t care about the tool, only the outcome “ But, we have long had a stable social system for collaboration, and in particular dealing with low quality contributions. Mostly (or at least ideally) it involves taking some time to look at the contribution and provide some feedback. The time invested is not worth it on a single exchange basis, but it’s a repeat game, so you are investing in the future. LLMs, and people willing to just spam crap they don’t really understand blows that all up. |
| |
| ▲ | moring a day ago | parent | next [-] | | I'm not convinced it blows up. It might also end up placing a larger burden on contributors, and especially first-time contributors, to provide concise, high-quality documentation that justifies their contribution. I'm thinking of something like: Explain, in at most 300 characters, why we should merge your change, or at least why we should invest the time to read a longer explanation (somethings things ARE complex). If you don't do that, or those 300 characters aren't convincing, or have nothing to do with your change or the longer explanation, then you get a canned response so the maintainers waste minimal time. | | |
| ▲ | thayne a day ago | parent | next [-] | | That doesn't really solve the problem. I've gotten PRs that do do an adequate job of explaining why why something should be implemented. Then I look at the code and it doesn't fully solve the problem, or it does so in a way that will obviously break something else. | | |
| ▲ | moring a day ago | parent | next [-] | | In that case, isn't a sufficiently reasoned "why" a contribution in itself? Not trying to downplay the time wasted to reject the PR, though. | |
| ▲ | lokar a day ago | parent | prev [-] | | A colleague once setup a PR description template that asked for short sections like: - Why is this change needed (big picture) - Why are you doing it this way (small picture) - What are the trade-offs you made for this approach - How do you know this is correct, that it works the way you think it does? - What other changes or approaches does committing to this way block in the future? etc. If you had actually thought through what you were doing, it was a few min to fill it all out. People were just on auto-pilot really struggled. | | |
| ▲ | aleph_minus_one a day ago | parent [-] | | > If you had actually thought through what you were doing, it was a few min to fill it all out. ... for people who are native speakers of English. | | |
| ▲ | lokar a day ago | parent [-] | | Software engineering is a highly collaborative process. To be successful you need to be pretty good at reading and writing whatever language the team is using. I've worked with plenty of non-native speakers who were well above the average I see for natives. In the last 10 years I found the level of just basic writing for new Jr engineers has really fallen. If you can't write, you can't think |
|
|
| |
| ▲ | Keyframe a day ago | parent | prev [-] | | you know EXACTLY what would happen in such a system. | | |
| ▲ | moring a day ago | parent [-] | | I don't, please enlighten me. | | |
| ▲ | lokar a day ago | parent | next [-] | | My prediction is that many new contributors would complain loudly. Some existing contributors would sympathize. It’s I think a normal evolution of a social norm. There will be a period of competing values. | |
| ▲ | Keyframe a day ago | parent | prev | next [-] | | people would use LLMS for those summaries, defeating the purpose. You can already see it in PRs in companies where LLM code is pushed. | |
| ▲ | CamperBob2 a day ago | parent | prev [-] | | Explain, in at most 300 characters, why we should merge your change, or at least why we should invest the time to read a longer explanation (somethings things ARE complex) would simply become a prompt. The solution, of course, is to use the best available LLMs as the first line of defense against slop contributions. But if the project maintainers have issued a sweeping fatwa prohibiting an entire class of useful tools, that option along with many others is off the table. | | |
| ▲ | tiahura a day ago | parent [-] | | I wonder if some of these projects with ayatollah maintainers are looking at forks sooner rather than later? |
|
|
|
| |
| ▲ | hypfer a day ago | parent | prev [-] | | Nah, that was already blown up way before LLMs existed. Foss wasn't exactly not miserable before 2022. The dysfunction just got amplified so that we cannot fix it anymore by just throwing more human resources at the problem. | | |
| ▲ | lokar a day ago | parent [-] | | I tried to nod a bit to the inconsistency. Some projects clearly lost patience with imperfect contributions long ago. But many were still pretty supportive. This dynamic also plays out in many companies. I see a lot of posts from mid to sr engineers frustrated with plummeting code quality and unsure how to manage the reviews. They are increasingly pulling away from the idea that they should mentor people to do better. | | |
| ▲ | aleph_minus_one a day ago | parent | next [-] | | > They are increasingly pulling away from the idea that they should mentor people to do better. Two considerations on this: 1. In the USA, it is common to switch jobs often (in opposite to, for example, Germany). So, in the US-American system it is not often worth the effort to invest a lot of mentoring ressources into some employee if he will leave soon anyway. 2. I personally observe that I often do try to give less experienced programmers good hints on how to improve, but my kind of thinking about programming is often so different that my advice is often of no use for them. Or I often get the arrogant reaction by less experienced programmers that I care far too much about obscure details. I thus seriously do believe that the only way to help junior programmers to become better is to completely crush their ego and arrogance (just like a doctoral study programme in, say, mathematics does to the doctoral students), which is of course not allowed at work. :-( | |
| ▲ | Retric a day ago | parent | prev [-] | | The correct response to irresponsible AI use in the workplace is maintaining standards and rejecting poor quality. Performance improvement plans as a fair warning followed by firing people works for incompetence or laziness, AI doesn’t change anything. I’ll admit I’ve seen a spike in negative performance reviews but this is the new normal people will adapt. | | |
| ▲ | blackqueeriroh a day ago | parent [-] | | It’s almost like late-stage capitalism isn’t built to support mentorship and education and enabling human improvement! |
|
|
|
|
|
| ▲ | Keyframe a day ago | parent | prev | next [-] |
| yeah, that's fair. Problem so far has been when poor developers send massive volume of slop for review. Takes time and effort to review or at least glance and test it, especially if developer hasn't bothered. |
| |
| ▲ | notatoad a day ago | parent [-] | | that seems like two separate problems. too many patches from unknown and untrusted contributors is a triage problem - telling a known and trusted contributor they can't use AI to help work on something just because other people are sending slop for review is throwing the baby out with the bathwater. | | |
|
|
| ▲ | NuclearPM a day ago | parent | prev | next [-] |
| Terminates??? |
| |
| ▲ | smallerfish a day ago | parent | next [-] | | We need sufficiently severe penalties for vibe coding. First time out we break your legs, but if you come back with another vibed patch its around the back of the barn for you. | |
| ▲ | m4rtink a day ago | parent | prev [-] | | Nuke it from orbit. |
|
|
| ▲ | qsera a day ago | parent | prev | next [-] |
| What stops them from submitting PRs from another account? |
| |
| ▲ | jayofdoom a day ago | parent | next [-] | | Nothing. And that's the problem -- the issue isn't "should a contributor be able to use AI" it's quickly becoming "is this entire contributor an AI agent". Every actual-human who gets a bad first experience hurts the project. The contributors having to be suspicious of new people hurts the project. The whole thing just sucks, and I don't know how to fix it. I use claude-code, but the AI ecosystem and some of the autonomous tooling coming out of it -- which some people "helpfully" use irresponsibly and point at OSS projects they aren't personally invested in -- enables a LARGE amount of abusive behavior towards open source projects. This is even before we get into how many infrastructural resources crawlers eat up. Me, and most other OSS contributors, signed up to be a mentor, to create software, to work together ... not to be the equivalent of a reddit moderator banning AI agents left and right. | | |
| ▲ | kikoreis a day ago | parent | next [-] | | "Nothing" is not accurate in the context of Debian as per comments above; it's not like Github in that sense. | |
| ▲ | digitaltrees a day ago | parent | prev | next [-] | | What is a good project for a human to get human mentorship? Asking for a friend :) | | |
| ▲ | jayofdoom 2 hours ago | parent | next [-] | | I work on OpenStack, which is a project folks work on primarily due to sponsorship -- not many people who want to do security/stability work for a cloud "for the fun of it" :D. So mentees I've worked with have usually come as part of a program, such as MLH[1] or Outreachy[2]. Other projects I've helped with mentoring have come from college programs or professors[3]. I have no idea how hard it is to get through the filters to get these opportunities; I know generally we ask them to only send us the best and that's worked out really well. [1] https://www.youtube.com/watch?v=fbsI8l-MaFA is an interview done on my podcast (by the other host, Tabatha) with CID, who works with me on OpenStack Ironic. A little over 2 years ago, he was an MLH fellow (https://fellowship.mlh.com/) working with me -- now he's a maintainer on OpenStack and working on my team. This is an exceptional outcome, but he's not the only person who has found success via MLH that I know. [2] e.g. https://lists.openstack.org/archives/list/openstack-discuss@... [3] https://lists.openstack.org/archives/list/openstack-discuss@... | |
| ▲ | kikoreis a day ago | parent | prev | next [-] | | Debian itself is actually great: https://mentors.debian.net/sponsors/ | |
| ▲ | lrvick a day ago | parent | prev | next [-] | | https://stagex.tools Always happy to train up new packagers and maintainers. | | |
| ▲ | zenoprax a day ago | parent [-] | | This is the second time I've seen this project mentioned on HN. Their white paper is very interesting and aligns closely with my interests but I don't see much on the main site about how to get involved. Are they using their Matrix server to filter out drive-by/low-effort contributions? | | |
| ▲ | lrvick a day ago | parent [-] | | I am the founder of the project. We accept every contribution that solves a problem, even drive-bys. Though they may often sit for a bit as we often merge in batches. If there is something missing, make a PR by all means. Ask any questions on matrix. |
|
| |
| ▲ | hypfer a day ago | parent | prev [-] | | Usually, mentorship is a quite well paid service. |
| |
| ▲ | ls612 a day ago | parent | prev [-] | | [flagged] | | |
| ▲ | GPerson a day ago | parent | next [-] | | Good. I want open source projects which serve infrastructure to be gate kept so that only responsible people are involved. Responsible people can use AI too. Get all of those people on board, and keep out irresponsible people! | |
| ▲ | superb_dev a day ago | parent | prev | next [-] | | Most people who wrote software before AI didn’t contribute to projects like Debian because it takes a certain passion and commitment. Just being able to write code is not the bar for entrance here. | |
| ▲ | ebiester a day ago | parent | prev | next [-] | | This isn't talking about bespoke software, though. This is talking about upstreaming contributions to others. This puts a low barrier to create work and a lot more work for unpaid volunteers. | |
| ▲ | smoe a day ago | parent | prev | next [-] | | I don't care if a project uses AI or not, but I absolutely do care that they are firmly gatekept in alignment with their vision and team dynamics. Then I can choose projects whose gatekeeping policies I agree with. There is never not an alternative to something, and I can always have my AI botch together my own version if I think this is going to get me better results. | |
| ▲ | setopt a day ago | parent | prev | next [-] | | The issue at hand isn’t people using AI to make some app that they and their mom will use. That’s awesome. It’s people who insist that potentially millions of other people should be affected by their vibe-coded stuff too, by upstreaming it into Debian. I vibe coded some simple things for the family myself, but I don’t expect or require anyone else to want or use it. | |
| ▲ | overfeed a day ago | parent | prev | next [-] | | > ngl this is just gatekeeping As a beneficiary of Debian, this is good, you are praising Debian with feint damnation. I wish Debian had done more gatekeeping in the past on specific components. | | |
| ▲ | NuclearPM a day ago | parent [-] | | Did you intentionally write that like an AI as a joke? | | |
| ▲ | overfeed a day ago | parent [-] | | I'd be impressed by an AI that can go against tons of training data by reversing the polarity of a common turn-of-phrase. I was proud of that, and am slightly bummed to hear someone thinks it sounds AI-like. Also, I had a typo, its supposed to be "faint" (light) not "feint" (fake-out), though the latter worked out in context, and works by adding a homonym layer to the turn of phrase already turned on its head. 2 layers of smug, conceited cleverness - or 1 layer and a typo if you're not feeling charitable - that gets in the way of clear communication seems very human to me, YMMV. |
|
| |
| ▲ | acheron a day ago | parent | prev | next [-] | | Gatekeeping is good, actually. Not keeping your gate is how your town gets overrun by Mongols. | |
| ▲ | catlifeonmars a day ago | parent | prev | next [-] | | “This is just gatekeeping” is simultaneously true and ignoring the problem it’s reacting to. Also there’s an implicit moral judgement there against gatekeeping. | |
| ▲ | pessimizer a day ago | parent | prev | next [-] | | Ah, "icky gatekeeping." I'm convinced. | |
| ▲ | bluefirebrand a day ago | parent | prev [-] | | > ngl this is just gatekeeping Gatekeeping serves a useful purpose in any functioning organization of all scales, from a community center to a country, from an open source project to a Fortune 500. |
|
| |
| ▲ | cdata a day ago | parent | prev | next [-] | | I can't speak for all, but many mature open source communities have explicit or ad-hoc reputation schemes that are used to triage contributions. A fresh account means starting over with zero reputation, which in turn means your contributions wait at the back of the line. | | |
| ▲ | qsera a day ago | parent [-] | | ability to create low effort PR means that they can reset the reputation as much as they can.. | | |
| ▲ | b112 a day ago | parent [-] | | There are no anonymous debian developers. All have been vetted by multiple people. |
|
| |
| ▲ | kikoreis a day ago | parent | prev | next [-] | | Well. This is Debian, known for how strict they are about vetting developers. I just remembered Sladen refusing to key sign because my passport circa 2005 didn't have a machine readable slug in it. https://www.debian.org/devel/join/newmaint | |
| ▲ | tremon a day ago | parent | prev | next [-] | | What part of [0] or [1] makes you think that it is easy to have multiple accounts? [0] https://wiki.debian.org/DebianMaintainer#Becoming_a_Debian_M... [1] https://wiki.debian.org/DebianDeveloper/JoinTheProject/NewMe... | |
| ▲ | smashed a day ago | parent | prev | next [-] | | Debian is notoriously very strict on accepting maintainers and they are not anonymous. | |
| ▲ | MithrilTuxedo a day ago | parent | prev | next [-] | | Reputation, or lack thereof. Proof of authority, essentially. | |
| ▲ | ahartmetz a day ago | parent | prev | next [-] | | Presumably they are trying to farm karma / reputation, which (I think, mostly) doesn't work if they need to switch accounts all the time. | |
| ▲ | kaffekaka a day ago | parent | prev | next [-] | | What stopped them before? | | |
| ▲ | qsera a day ago | parent [-] | | Before they were not able to spam large PRs | | |
| ▲ | Supermancho a day ago | parent [-] | | Why not? I'm pretty sure a developer could spam large PRs before and regardless of AI involvement is allowed or not. | | |
| ▲ | inigyou a day ago | parent | next [-] | | How would you generate enough large PRs to count as "spam"? You could add gibberish or delete random lines of code but it was obviously not plausible looking. | |
| ▲ | zeendo a day ago | parent | prev | next [-] | | Obviously they could have. Obviously it's much easier now. | |
| ▲ | Mawr a day ago | parent | prev | next [-] | | You can cut down a tree regardless if you use a knife or a chainsaw. You can get to work each day regardless if you walk or drive. | |
| ▲ | JohnHaugeland a day ago | parent | prev [-] | | this article is about the flood of junior developers who are producing enormous prs they’ve never seen full of untrustworthy code that a human hasn’t evaluated arguing that it’s possible to make them by hand isn’t just missing the point; it’s missing the entire discussion | | |
| ▲ | Supermancho a day ago | parent [-] | | > arguing that it’s possible to make them by hand isn’t just missing the point; it’s missing the entire discussion >> Before they were not able to spam large PRs I was replying to someone insinuating that there was something I might have missed. Interjecting about the topical article, is a derail of this thread for some reason that is personal to you. Good luck with whatever. |
|
|
|
| |
| ▲ | 2Gkashmiri a day ago | parent | prev | next [-] | | In anonymous systems, where we don't use real names, your "handle" has an "age".
That becomes your most prized possession. I have a reddit account thats over 12 years old. I have left the posts/comments open. That means, my "post history" becomes a way to advertise my skills.
I can reference comments from a year ago or 6 months ago about a certain topic to show how I handled something. That does have an effect on people. As opposed to a random 1 day old account. No one takes them seriously, I guess the same is here as well | | |
| ▲ | inigyou a day ago | parent | next [-] | | Be extremely careful with that account then, because they ban accounts for the most minor things now. Stuff like posting evidence disproving something the moderator agrees with. And they ban your account from the whole site, not just from that subreddit any more. Automated algorithms also ban accounts for reasons that don't make any sense. So if you're using your account to advertise yourself and look for jobs, I'd use it only for that. All off-topic discussion should be on a different account with a different physical device and IP address (reddit checks these things and cross-bans) that have never interacted with your main account. | |
| ▲ | ipaddr a day ago | parent | prev [-] | | No one takes a 12 year old Reddit account seriously either. It's not a platform you can take anyone seriously. The biggest trolls have 12 year old accounts. | | |
| ▲ | clort a day ago | parent [-] | | the age is not the measure of quality. the GP said they left the posts/comments open. anybody can read that and check if they are or not a serious contributor |
|
| |
| ▲ | cineticdaffodil a day ago | parent | prev [-] | | [dead] |
|
|
| ▲ | ThereAreOther1s a day ago | parent | prev [-] |
| [flagged] |