2025-11-21 AI contributes code on GitHub
========================================

I'm reading through DWARF v5 Debugging Support for OCaml Native
Compiler. It's a contribution that is very big. 40 commits touching
147 files. It's huge. The author is asking for a review by the
maintainers. They don't like it.

> joelreymont: This PR adds DWARF v5 debug information to the OCaml
> native compiler, allowing proper source-level debugging in GDB and
> LLDB. …
>
> gasche: According to the copyright headers, all the new source
> files in this PR have been written by Mark Shinwell (@mshinwell), or
> maybe are directly derived from his work. This seems plausible (a
> lot of it seems heavily inspired by the DWARF support in the oxcaml
> repository, which I suppose has been written by Mark indeed), but is
> it actually the case? (If your work is so heavily derived from
> Mark's work, maybe it would make sense to credit him in the PR
> description, or in the webpage you created specifically to advertise
> for this work?)
>
> tmcgilchrist: This seems to be largely a copy of the work done in
> OxCaml by @mshinwell and @spiessimon and others, including the
> missing features like DWARF information for OO, changes to the
> shapes constructors, the python based printers rather than built-in
> LLDB/GDB language plugin, and other things. I mentioned in #14353
> (comment) that this is still being worked on and isn't ready for
> upstreaming (in my opinion as someone working on it). With that, I'm
> hesitant to spend the time reviewing this in full.
>
> yallop: … @joelreymont, could you please explain where you obtained
> the code in this PR?
>
> joelreymont: It’s not where I obtained this PR but how.
>
> Claude Sonnet 4.5 (Claude Code) wrote most of it with ChatGPT 5
> (Codex) reviewing and Claude addressing issues in each review. Codex
> wrote the last 10% or so when Claude kept getting stuck.
>
> I did not write a single line of code but carefully shepherded AI
> over the course of several days and kept it on the straight and
> narrow.
>
> …
>
> My work was just directing, shaping, cajoling and reviewing.
>
> gasche: There is an obvious problem with copyright if you reuse
> large amounts of people's code. The fact that the tool that produced
> the code attributes its copyright to a real human is a clear sign
> that something is an issue. (You might also wonder if that human
> agrees with being described as the author of code that you yourself
> introduce in the compiler.) At this point, merging the code in the
> compiler would be a legal liability.
>
> There hasn't been a design discussion for which approach should be
> chosen to integrate this feature. We would appreciate people
> discussing design before they dump 13K-lines PRs on us. In fact,
> it's a bit worse in this case: people that are expert on this topic
> and actively working on this feature ( @tmcgilchrist above ) have
> given you design advice and made recommendations for how to
> contribute in a way that they felt would be productive. As far as I
> can tell you did not take this feedback into account.
>
> This humongous amount of code is hard to review, and very lightly
> tested. (You are only testing that basic functionality works.)
> Inevitably the code will be full of problems, and we (the
> maintainers of the compiler) will have to pay the cost of fixing
> them. But maintaining large pieces of
> plausible-in-general-but-weird-in-the-details code is a large
> burden.
>
> As you might know, the OCaml compiler codebase suffers from a lack
> of people available to do code reviews and maintenance. … Your
> approach of submitting very large relatively-low-effort PRs creates
> a very real risk of bringing the Pull-Request system to a halt,
> especially given that, in my personal experience, reviewing
> AI-written code is more taxing that reviewing human-written code.
>
> You may think that the answer to that is to also automate the review
> process, or (more plausibly) to lower our quality standards: we can
> accept PRs based on simple/lightweight tests (themselves
> AI-generated), and if users find issues we can quickly use automated
> tools to fix them, basically having our users perform the testing
> work that is missing. But so far we have not decided to work in this
> way (and this has very real costs for users of the compiler), so
> these potential solutions are not available.
>
> Finally, you seem to not give a thought about the fact that your
> contributions demand work of other people. The fact that you were
> able to generate large amount of code that passes test is
> interesting, but that's only 20% of the work, the other 80% are to
> get the feature discussed, reviewed and integrated, and this work
> will be paid by you and others. But you only focus on the initial
> writing phase and you personal success, over-communicate on this,
> and do not appear to realize that this has very real costs on
> others. For example, a few days ago you sent a PR that was a
> complete waste of our collective maintenance time (…), we wasted
> this time, and you never apologized.
>
> If your intent is to demonstrate that you personally know how to
> generate large amount of code that provide useful functionality and
> pass basic test, in a complex software project, then I think you
> have succeeded; congratulations. But if you are also hoping to
> demonstrate that they can be successfully integrated by upstream
> software projects, following the existing collaboration practices of
> the project, this is a complete failure. Maybe being a bit less
> tone-deaf and discussing things with people before you throw
> hundreds or thousands of lines at them would be a first step. But
> personally at this point I wish that you would do your "scientific
> experiments" (your words) on another software project, and I have
> personally decided that I will not invest any more time looking at
> your PRs for the next six months.
>
> joelreymont: Here's the AI-written copyright analysis …
>
> gasche: I will go ahead and close this PR. …

#AI #Programming

2025-11-25. Similar challenges. A german lawyer who tried to vibe
code some compiler fixes:

> My use of an AI tool, for example, was explicitly stated as an
> attempt to bridge a knowledge gap and assist diagnosis, offered in
> good faith, not as a finished product demanding review or intending
> disrespect. That it provoked such strong reactions yet again from
> some developers was surprising to me. -- When Compiler Engineers Act
> As Judges, What Can Possibly Go Wrong? How LLVM's CoC Committee
> Violated Its Own Code

He is unable or unwilling to minimise the steps required to reproduce
the problem and instead posts more stuff.

He did it again:

> I am not a programmer. The C and C++ that form the language of Mesa
> are as foreign to me as traditional Chinese. To pretend otherwise
> would have been dishonest and foolish. … From the developers'
> perspective, my RFC was not a helpful map; it was an abdication of
> responsibility. I had, in their view, made it their job "to sort
> through the shit ChatGPT spit out and decide what's useful and
> what's not." My explicit statement of having "no desire to actually
> learn about the Mesa code-base" was not seen as a gesture of honest
> humility, but as the central point of failure. My submission,
> therefore, was not a contribution; in Faith's stark and widely
> circulated words, it was "just burning maintainer time." -- Open
> Source Contributions in the Age of AI - A personal story that ended
> with Trial by Fire in the Digital Town Square

Reading through the discussions is painful. ms178 keeps proposing code
that works, with spurious changes, with unnecessary changes, with
explanations that are wrong, ignoring exhortations to keep patches
small, to test patches individually.

This is misunderstanding what programming means. Acknowledging that
one doesn't know how to program doesn't absolve one from the
responsibilities of programming when contributing.

@elilla@transmom.love writes:

> Reading this guy downtalk over Mesa compiler core and Vulkan
> programmer Faith Ekstrand is one of the most infuriating things I’ve
> ever read. I had to stop before I started like emanating cartoon
> fumes. I think this guy has invented a new low: the
> vibe-mansplaining, which leverages the inherently mansplainy nature
> of LLMs to put down an actual woman on her topic of expertise.