Re: [PATCH 0/4] fdtfactor: Introduce fdtfactor to auto-factor overlays

[David Gibson]

On Fri, Oct 23, 2026 at 03:49:09PM +1100, David Gibson wrote:
> On Thu, Oct 15, 2026 at 11:21:33AM -0700, Douglas Anderson wrote:
[snip]
> > I'll freely admit that the patches in this series were pretty heavily vibe
> > coded. I'll not pretend that I have a deep understanding of the intracicies
> > of how overlays are implemented. That being said:
> > * I've spent quite a bit of time reviewing the code from a high-level
> >   perspective: confirming that functions are well documented, well structured,
> >   and make sense.
> > * I believe that what the tool is doing and how the tool is used make sense.
> > * I have had quite a number of internal "the AI reviews the AI" rounds to
> >   the point of diminishing returns.
> > At this point, I'm not embarassed to put my name behind this. While I won't
> > promise that there is zero cases of the AI doing something really stupid,
> > I'd be willing to bet that the end result is better (and cleaner / better
> > structured) than what I would have coded up if I had spend a few weeks doing
> > this on my own.
> 
> Thanks for that clear and helpful context.  My views on AI are
> complicated, leaning negative, but I do think it can be a useful tool
> and have no plans to reject patches purely because they're AI
> assisted.  A statement like that goes a long way to convincing me that
> I'm not about to waste my effort reviewing slop.  c.f. my rather
> unfriendly response[2] to a recent very sloppish bug report which
> vastly overestimated the impact of the bugs in question.
> 
> [2] https://lore.kernel.org/devicetree-compiler/as8RYmIp0pDCplpu@gractus.seuss/
> 
> Understand that all dtc maintainership is unpaid volunteer time for
> me, so I'm less responsive about reviews than would be ideal.  I am
> gradually chiping away at the backlog, though.

Fwiw, here's a follow up on this topic now that I've actually read the
series (or at least, the heart of it in 2/4).

This does exhibit some of the pitfalls of AI generated code.  Most
obviously, that patch itself is pretty monstrous - at least by
default, coding agents aren't very good at considering splitting
series for the benefit of reviewability.  It does exhibit signs of
AI-typical verbosity.  It's not too bad in terms of locally redundant
code, although there are a few examples.  It's worse in terms of
"conceptual verbosity" - most obviously it uses two quite different
ways of representing the tree being processed.  It's not really clear
why or if that's necessary or useful and it makes it substantially
more confusing to read.

I don't know what prompts you used for AI-reviewing-AI, and I don't
have a lot of experience with that, but I wonder if results could be
improved by using some review prompts not focussed on correctness or
(superficial) style.  e.g. "look for DRY violations", "look for
redundantly represented data", "look for workarounds for bugs in
pre-existing code, and fix those sepearately first".

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature