| ▲ | totallymike 2 days ago |
| How deliciously entitled of you to decide that making other people try to catch ten tons of bullshit because you’re “learning quicker and can contribute at a level you otherwise couldn’t” is a tradeoff you’re happy to accept If unrepentant garbage that you make others mop up at risk of their own projects’ integrity is the level you aspire to, please stop coding forever. |
|
| ▲ | 0000000000100 2 days ago | parent | next [-] |
| Go look at the PR man, it's pretty clear that he hasn't just dumped out LLM garbage and has put serious effort and understanding into the problem he's trying to solve. It seems a little mean to tell him to stop coding forever when his intentions and efforts seem pretty positive for the health of the project. |
| |
| ▲ | thesz 2 days ago | parent [-] | | One of resolved conversation contains a comment "you should warn about incorrect configuration in constructor, look how it is done in some-other-part-of-code." This means that he did not put serious effort into understanding what, when and why others do in a highly structured project like LLVM. He "wrote" the code and then dumped "written" code into community to catch mistakes. | | |
| ▲ | onli 2 days ago | parent | next [-] | | That is normal for a new contributor. You can't reasonably expect knowledge of all the conventions of the project. There has to be effort to produce something good and not overload the maintainers, I agree, but missing such a detail is not a sign that is not happening here. | | |
| ▲ | anal_reactor a day ago | parent [-] | | Every hobby at some point turns into an exclusive, invitation-only club in order to maintain the quality of each individual's contribution, but then old members start to literally die and they're left wondering why the hobby died too. I feel like most people don't understand that any organization that wants to grow needs to sacrifice quality in order to attract new members. |
| |
| ▲ | StopDisinfo910 a day ago | parent | prev [-] | | Have you ever contributed to a very large project like LLVM? I would say clearly not from the comment. There are pitfalls everywhere. It’s not so small that you can get everything in your head with only a reading. You need to actually engage with the code via contributions to understand it. 100+ comments is not an exceptional amount for early contributions. Anyway, LLVM is so complex I doubt you can actually vibcode anything valuable so there are probably a lot of actual work in the contribution. There is a reason the community didn’t send them packing. Onboarding new comer is hard but it pays off. | | |
| ▲ | thesz a day ago | parent [-] | | > Have you ever contributed to a very large project like LLVM?
Oh, I did. Here's one: https://github.com/mariadb-corporation/mariadb-columnstore-e... > I would say clearly not from the comment.
Of course, you are wrong. > It’s not so small that you can get everything in your head with only a reading.
PSP/TSP recommends writing typical mistakes into a list and use it to self-review and to fix code before sending it into review.So, after reading code, one should write down what made him amazed and find out why it is so - whether it is a custom of a project or a peculiarity of code just read. I actually have such a list for my work. Do you? > You need to actually engage with the code via contributions to understand it. 100+ comments is not an exceptional amount for early contributions.
No, it is not. Dozens of comments on a PR is an exceptional amount. Early contributions should be small so that one can learn typical customs and mistakes for self review before attempting a big code change.That PR we discuss here contains a maintainer's requirement to remove excessive commenting - PR's author definitely did not do a codebase style matching cleanup job on his code before submission. | | |
| ▲ | StopDisinfo910 a day ago | parent [-] | | The personal dig was unwarranted. I apologise. > So, after reading code, one should write down what made him amazed and find out why it is so - whether it is a custom of a project or a peculiarity of code just read. Sorry but that’s delusional. The amount of people actually able to meaningfully read code, somehow identify what was so incredible it should be analysed despite being unfamiliar with the code base, maintain a list of their own likely error and self review is so vanishingly low it might as well not exist. If that’s the bare a potential new contributor has to cross, you will get exactly none. I’m personally glade LLVM disagree with you. | | |
| ▲ | thesz a day ago | parent [-] | | >The amount of people actually able to meaningfully read code, somehow identify what was so incredible it should be analysed despite being unfamiliar with the code base, maintain a list of their own likely error and self review is so vanishingly low it might as well not exist.
List of frequent mistakes gets collected after contributions (attempts). This is standard practice for high quality software development and can be learned and/or trained, including on one's own.LLVM, I just checked, does not have a formal list of code conventions and/or typical errors and mistakes. Could they have that list, we would not have the pleasure to discuss that. That PR we are discussing would be much more polished and there would be much less than several dozens of comments. > If that’s the bare a potential new contributor has to cross, you will get exactly none.
You are making very strong statement, again. |
|
|
|
|
|
|
| ▲ | jjmarr 2 days ago | parent | prev | next [-] |
| I didn't make a decision on the tradeoff, the LLVM community did. I also disclosed it in the PR. I also try to mitigate the code review burden by doing as much review as possible on my end & flagging what I don't understand. If your project has a policy against AI usage I won't submit AI-generated code because I respect your decision. |
| |
| ▲ | h4ny 2 days ago | parent | next [-] | | > I didn't make a decision on the tradeoff, the LLVM community did. I also disclosed it in the PR. That's not what the GP mean. Just because a community doesn't disallow something doesn't mean it's the right thing to do. > I also try to mitigate the code review burden by doing as much review as possible on my end That's great but... > & flagging what I don't understand. It's absurd to me that people should commit code they don't understand. That is the problem. Just because you are allowed to commit AI-generated/assisted code does not mean that you should commit code that you don't understand. The overhead to others of committing code that you don't understand then ask someone to review is a lot higher than asking someone for directions first so you can understand the problem and code you write. > If your project has a policy against AI usage I won't submit AI-generated code because I respect your decision. That's just not the point. | | |
| ▲ | overfeed 2 days ago | parent | next [-] | | > It's absurd to me that people should commit code they don't understand The industrywide tsunami of tech debt arising from AI detritus[1] will be interesting to watch. Tech leadership is currently drunk on improved productivity metrics (via lines of code or number of PRs), but I bet velocity will slow down, and products be more brittle due to extraneous AI-generated, with a lag, so it won't be immediately apparent. Only teams with rigorous reviews will fare well in the long term, but may be punished in the short term for "not being as productive" as others. 1. From personal observation: when I'm in a hurry, I accept code that does more than is necessary to meet the requirements, or is merely not succinct. Where as pre-AI, less code would be merged with a "TBD" tacked on | | |
| ▲ | jjmarr a day ago | parent [-] | | I agree with more review. The reason I wrote the PR is because AI keeps using `int` in my codebase when modern coding guidelines suggest `size_t`, `uint32_t`, or something else modern. |
| |
| ▲ | huflungdung 2 days ago | parent | prev [-] | | [dead] |
| |
| ▲ | Phelinofist 2 days ago | parent | prev [-] | | Where did you disclose it? | | |
| ▲ | Sayrus 2 days ago | parent [-] | | Only after getting reviews so it is hidden by default: https://github.com/llvm/llvm-project/pull/146970#issuecommen... | | |
| ▲ | optionalsquid a day ago | parent [-] | | Disclosing that you used AI three days after making the PR, after 4 people had already commented on your code, doesn't sit right with me. That's the kind of thing that should be disclosed in the original PR message. Especially so if you are not confident in the generated code | | |
| ▲ | anon22981 a day ago | parent [-] | | Sounds like a junior vibe coder with no understanding of software development trying to boost their CV. Or at least I hope that’s the case. | | |
| ▲ | jjmarr a day ago | parent [-] | | I graduated literally 3 months ago so that's my skill level. I also have no idea what the social norms are for AI. I posted the comment after a friend on Discord said I should disclose my use of AI. The underlying purpose of the PR is ironically because Cline and Copilot keep trying to use `int` when modern C++ coding standards suggest `size_t` (or something similar). |
|
|
|
|
|
|
| ▲ | noosphr 2 days ago | parent | prev | next [-] |
| That's no different to on boarding any new contributor. I cringe at the code I put out when I was 18. On top of all that every open source project has a gray hair problem. Telling people excited about a new tech to never contribute makes sure that all projects turn into templeOS when the lead maintainer moves on. |
| |
| ▲ | totallymike 2 days ago | parent | next [-] | | Onboarding a new contributor implies you’re investing time into someone you’re confident will pay off over the long run as an asset to the project. Reviewing LLM slop doesn’t grant any of that, you’re just plugging thumbs into cracks in the glass until the slop-generating contributor gets bored and moves on to another project or feels like they got what they wanted, and then moves on to another project. I accept that some projects allow this, and if they invite it, I guess I can’t say anything other than “good luck,” but to me it feels like long odds that any one contributor who starts out eager to make others wade through enough code to generate that many comments purely as a one-sided learning exercise will continue to remain invested in this project to the point where I feel glad to have invested in this particular pedagogy. | | |
| ▲ | noosphr 2 days ago | parent [-] | | >Onboarding a new contributor implies you’re investing time into someone you’re confident will pay off over the long run as an asset to the project. No you don't. And if you're that entitled to people's time you will simply get no new contributors. | | |
| ▲ | totallymike a day ago | parent | next [-] | | I’ll grant you that, but at least a new contributor who actually writes the code they contribute has offered some level of reciprocity with respect to the time it takes to review their contributions. Trying to understand a problem and taking some time to work out a solution proves that you’re actually trying to learn and be helpful, even if you’re green. Using a LLM to generate a nearly-thousand-line PR and yeeting it at the maintainers with a note that says “I don’t really know what this does” feels less hopeful. I feel like a better use of an LLM would be to use it for guidance on where to look when trying to see how pieces fit together, or maybe get some understanding of what something is doing, and then by one’s own efforts actually construct the solution. Then, even if one only has a partial implementation, it would feel much more reasonable to open a WIP PR and say “is this on the right track?” | |
| ▲ | riehwvfbk a day ago | parent | prev [-] | | Not getting thousand line AI slop PRs from resume builders who are looking for a "LLVM contributor" bullet point before moving on is a net positive. Lack of such contributors is a feature, not a bug. And you can't go and turn this around into "but the gate keeping!" You just said that expecting someone to learn and be an asset to a project is entitlement, so by definition someone with this attitude won't stick around. Lastly, the reason that the resume builder wants the "LLVM contributor" bullet point in the first place is precisely because that normally takes effort. If it becomes known in the industry that getting it simply requires throwing some AI PR over the wall - the value of this signal will quickly diminish. |
|
| |
| ▲ | totallymike 2 days ago | parent | prev [-] | | Unrelated to my other point, I absolutely get wanting to lower barriers, but let’s not forget that templeOS was the religious vanity project of someone who could have had a lot to teach us if not for mental health issues that were extant early enough in the roots of the project as to poison the well of knowledge to be found there. And he didn’t just “move on,” he died. While I legitimately do find templeOS to be a fascinating project, I don’t think there was anything to learn from it at a computer science level other than “oh look, an opinionated 64-bit operating environment that feels like classical computing and had a couple novel ideas” I respect that instances like it are demonstrably few and far between, but don’t entertain its legacy far beyond that. | | |
| ▲ | lelanthran a day ago | parent [-] | | > While I legitimately do find templeOS to be a fascinating project, I don’t think there was anything to learn from it at a computer science level other than “oh look, an opinionated 64-bit operating environment that feels like classical computing and had a couple novel ideas” I disagree, actually. I think that his approach has a lot to teach aspiring architects of impossibly large and complex systems, such as "create a suitable language for your use-case if one does not exist. It need not be a whole new language, just a variation of an existing one that smooths out all the rough edges specific to your complex software". His approach demonstrated very large gains in an unusually complicated product. I can point to projects written in modern languages that come nowhere close to being as high-velocity as his, because his approach was fine-tuned to the use-case of "high-velocity while including only the bare necessities of safety." |
|
|
|
| ▲ | sethammons a day ago | parent | prev | next [-] |
| Your final sentence moved me. Moved to flagging the post, that is. |
|
| ▲ | MangoToupe 2 days ago | parent | prev | next [-] |
| I think the project and reviewers are both perfectly capable of making their own decisions about the best use of their own time. No need to act like a dick to someone willing to own up to their own behavior. |
|
| ▲ | fuoqi 2 days ago | parent | prev [-] |
| Well, some people just operate under the "some of you may die, but it's a sacrifice I am willing to make" principle... |