241–250 of 329 posts
> It’s not where I obtained this PR but how. The fact that this was said as what seems to be a boast or a brag is concerning. As if by the magic of my words the solution appeared on paper. Instead of noticing that the bulk of the code submitted was taken from someone else.
https://news.ycombinator.com/edit?id=45982416 (Not so)interestingly, the PR author even advertised this work on HN.
what’s stopping the author from maintaining their own fork i wonder?
More importantly, being able to debug native OCaml binaries and actually see source code, values of variables, etc. is something that's useful to everyone.
Looking at assembler instead of source code sucks unless you are reverse-engineering.
Earlier quoted context omitted.
I wouldn't say they were dismissive of AI, just that they are unwilling to merge code that they don't have the time or motivation to review. If you want AI code merged, make it small so it it's an easy review. That being said, I completely understand being unwilling to merge AI code at all.
Why would you be unwilling to merge AI code at all? Consider my other PR against the Zig compiler [1]... I was careful to make it small and properly document it but there's a strict anti-AI policy for Zig and they closed the PR. Why? Is it not small? Not carefully documented? Is there no value it int? I'm not complaining or arguing for justice. I'm genuinely interested in how people think in this instance. If the sau…
Because AI code cannot be copyrighted. It is not anyone's IP. That matters when you're creating IP.
edit: Assuming this is a real person I'm responding to, and this isn't just a marketing gimmick, having seen the trail you've left on the internet over the past few weeks, it strikes me of mania, possibly chatbot-induced. I don't know what I can say that could help, so I'm dropping out of this conversation and wish you the best.
> Looking over this PR, the vast majority of the code is a DWARF library by itself. This should really not live in the compiler, nor should it become a maintenance burden for the core devs. I think this is a good point, that publishing a library (when possible, not sure if it's possible in this case) or module both reduces/removes the maintenance burden and makes it feel like more of an opt-in.
The Jane St (OxCaml) DWARF implementation is also tightly coupled with the compiler.
This guy's resume is quite something to behold: 1) Slummed it through the ranks of various Wall Street banks [1] 2) Became the Director of Prime Brokerage Technology at Deutsche Bank in 1999 [2] 3) Went through venture capital round in 2000 and in 9 months built a company valued at over 1,000,000 USD [0] 4) Sold license to Electronic Arts (EA) to power EA World Series of Poker (WSOP). [3] 5) Wrote, but had to cancel…
The Reddit link is from 18 years ago with people discussing almost the same thing. Damn.
I'd be interested to see how AI code review would do with this PR. This would be a great test to see if AI code review can properly identify the concerns that the humans have here (way too much code, PR creator can't answer basic questions about it, strange copyright header mentioning someone unrelated, etc.) I'll bet AI code review would fail miserably, only focusing on how the PR is formatted and if it "looks" like…
I find that ChatGPT 5.1 was much better at reviewing this code than writing it so I had it review Claude's output until the review was clean.
This is in addition to making sure existing and newly generated compiler tests pass and that the output in the PR / blog post is generated by actually running lldb through its paces.
I did have a "Oh, shit!" moment after I posted a nice set of examples and discovered that the AI made them up. At least it honestly told me so!
Earlier quoted context omitted.
Note that this PR works, was tested, etc. I was careful to have AI run through the examples in the PR, run lldb on the sample code and make sure the output matches. Some of the changes didn't make it in before the PR was closed but I don't think anyone bothered to actually check the work. All the discussion focused on the inappropriateness of the huge PR itself (yes, I agree), on it being written by AI... and on the…
I’ve been finding that the documentation the AI writes isn’t so much for humans, but for the AI when it later goes to work on the code again…well, to say AI benefits from good PRs as much as people do. You could ask the AI to break up the PR next time if possible, it will probably do so much more easily than you could do it manually.
Also, I'll try to break up the PR sometime but I'm already running Claude using two $200/mo accounts, in addition to another $200/mo ChatGPT, and still running into time limits.
I want to finish my compilers first.
Earlier quoted context omitted.
I wouldn't say they were dismissive of AI, just that they are unwilling to merge code that they don't have the time or motivation to review. If you want AI code merged, make it small so it it's an easy review. That being said, I completely understand being unwilling to merge AI code at all.
Why would you be unwilling to merge AI code at all? Consider my other PR against the Zig compiler [1]... I was careful to make it small and properly document it but there's a strict anti-AI policy for Zig and they closed the PR. Why? Is it not small? Not carefully documented? Is there no value it int? I'm not complaining or arguing for justice. I'm genuinely interested in how people think in this instance. If the sau…
Are you leaving the third-party aspect out of your question on purpose?
Not GP but for me, it pretty much boils down to the comment from Mason[0]: "If I wanted an LLM to generate [...] unreviewed code [...], I could do it myself."
To put it bluntly, everybody can generate code via LLMs and writing code isn't what defines the dominant work of an existing project anymore, as the write/verify-balance shifts to become verify-heavy. Who's better equipped to verify generated code than the maintainers themselves?
Instead of prompting LLMs for a feature, one could request the desired feature from the maintainers in the issue tracker and let them decide whether they want to generate the code via LLMs or not, discuss strategies etc. Whether the maintainers will use their time for reviews should remain their choice, and their choice only - anyone besides the maintainers should have no say in this.
There's also the cultural problem where the review efforts are non-/underrepresented in any contemporary VCS, and the amount of merged code grants for a higher authority over a repository than any time spent doing reviews or verification (the Linux kernel might be an exception here?). We might need to rethink that approach moving forward.
[0]: https://discourse.julialang.org/t/ai-generated-enhancements-...
I haven't had to deal with this in open source, but I have had to deal with coworkers posting slop for code reviews where I am the assigned reviewer. I've noticed that slop code has certain tell tale markers (such as import statements being moved for no discernible reason). No sane human does things like this. I call this "the sixth finger of code." It's important to look for these signs as soon as possible. Once one…
Earlier quoted context omitted.
Why would you be unwilling to merge AI code at all? Consider my other PR against the Zig compiler [1]... I was careful to make it small and properly document it but there's a strict anti-AI policy for Zig and they closed the PR. Why? Is it not small? Not carefully documented? Is there no value it int? I'm not complaining or arguing for justice. I'm genuinely interested in how people think in this instance. If the sau…
> Why would you be unwilling to merge AI code at all? Are you leaving the third-party aspect out of your question on purpose? Not GP but for me, it pretty much boils down to the comment from Mason[0]: "If I wanted an LLM to generate [...] unreviewed code [...], I could do it myself." To put it bluntly, everybody can generate code via LLMs and writing code isn't what defines the dominant work of an existing project an…
Well-documented and tested.