Hello Nick and Kirill,
Thank you for the replies, much appreciated.
I think I understand the issue -- auto-indentation and word completion
is very far from generated stuff that is usually disastrous in
quality. Having glanced at the commits they are, as you pointed
out, not the flood of unverifiable code that has crippled / ruined so
many projects.
I am also aware of, and indeed very grateful for the work of
devs, meticulously checking through every proposed commit, often several
of them at a time, and thus assure that standards of code quality /
legibility / etc. remain high.
But as it was pointed out it is a complex issue and the ext4fs
thread mostly revolved around copyright -- one part of the equation but
an important one for OpenBSD historically. I recall even an email in
that thread that said that it ought to be made clear that all code
contributions must have human authorship. This is partly the reason I
am asking.
Suppose, say, for these reasons, going forward no AI (generated /
assisted) code is allowed in the codebase -- but these already seem to
be in; what happens to these lines? So perhaps a more theoretical
question, which, I hope, in some small way contribute to thinking about
how OpenBSD wishes to tackle these things.
Thanks again
requiem
On Wed, 1 Apr 2026 15:39:47 -0400
Nick Holland <nick@holland-consulting.net> wrote:
> On 4/1/26 14:41, requiem. wrote:
> > Hello misc@
> >
> > Given the recent discussions regarding ext4fs and AI commits, can I
> > ask what the status of these two commits are?
> >
> > https://github.com/openbsd/src/commit/9c2b8e445a0bdfafdd6148b1760f00aa5429627b
> >
> > https://github.com/openbsd/src/commit/e9af5eb5a61d189327b553b24d0d31f19c64b63f
> >
> > ( Originally discovered via
> > https://mastodon.social/@mrmasterkeyboard/116329909911804392 )
> >
> > Are these going to stay or go?
> >
> > Thanks
> >
> > requiem
> >
>
> I think you are failing to understand the issue.
>
> Having automated tools find problems, and perhaps even suggest a fix,
> which is then evaluated for correctness by an Authentic
> Intelligence(*) is long established as a valid and valued process.
> But just as you don't take the output of lint as gospel, you don't
> take the word of advanced tools (including the stuff commonly called
> "AI") and assume there is a real bug, or that the proposed fix is
> "definitely" either correct or less wrong than the current code. AND
> if you take the time to read and understand the current code, you
> might find other problems or other things to improve!
>
> This is VERY different than having an automated tool scrape and steal
> OTHER PEOPLE'S WORK as the basis of "new" code.
>
> Sliding it back a few years:
> * Googling for tips on how to address a problem: good.
> * Googling for code and copying and pasting without understanding what
> the code does, how it works, where it came from, the license involved,
> claiming credit for it, and contaminating a free license code base
> with unlicensable (or improperly licensed) code: all bad.
>
> I've had the honor of getting a tiny peek at developers looking over
> the results of various code auditing tools -- They try to figure out
> why the audit tool objected to something, try to figure out if the
> issue is real or a non-issue, and if it is a real issue, they will
> try to address it in the best way possible...and sometimes, OTHER
> real problems are noted in the process of the examination. SOMETIMES
> it is an easy, "D'oh!" moment. Other times, there is a lot of
> discussion.
>
> The people who assume that so-called "AI" can replace skilled
> programmers are generally interested in AI for the same reason some
> people are interested in artificial limbs(**). But simply banishing
> a tool WHEN PROPERLY USED is foolish. When improperly used, more
> effective to banish the abusers.
>
> Nick.
>
> (*) "Authentic Intelligence" -- a small subset of the human
> population. (**) yes, that's a stolen "almost quote" that dates back
> at least 40 years.
>
No comments:
Post a Comment