Thanks Jacopo for such an elaborate answer.
I don't think the subject can be addressed in a better way than the way
you did.
I agree on every point.
Regards, Gaetan
On 7/2/26 12:46, Jacopo Cappellato wrote:
Hi Gaetan,
Thanks for bringing this up. I share your concerns, and I think they
are important points for every committer to consider.
The copyright attribution aspect mentioned by the ASF guidance is
particularly relevant for a project like OFBiz, which is used in
production by many organizations. Having clear provenance for
contributions is not just a matter of compliance, but also of
transparency and trust.
Another aspect that comes to mind is that AI tools significantly lower
the cost of implementing new features, components, and integrations.
On one hand, this is a great opportunity, as it enables developers to
prototype and implement ideas much faster than before. On the other
hand, it also makes it very easy to add more and more code to what is
already a very large codebase. Personally, I would like to see OFBiz
evolve toward a lighter, more focused, and easier-to-maintain
codebase, so I think we should be mindful not only of the quality of
new code, but also of whether new functionality truly justifies the
additional maintenance burden.
There is also an asymmetry between implementation cost and review
cost. AI dramatically reduces the effort required to produce code, but
unless we consciously decide to embrace "vibe coding" or similar
development models, the cost of reviewing that code remains
essentially unchanged. In fact, for complex contributions it may even
increase, since reviewers still need to understand the design, verify
correctness, and ensure consistency with the rest of the project. I
can imagine this leading to frustration if reviewers feel they are
expected to spend significantly more time reviewing a contribution
than the contributor spent producing it.
While "vibe coding" may be an interesting experiment for a new project
that is built around that philosophy from the beginning, I don't think
it is currently a viable approach for OFBiz. We have a large, mature
codebase that has been carefully crafted over more than twenty years
by the collective effort of this community. Given the current state of
these tools, I believe that preserving the project's long-term
maintainability and consistency should remain our primary objective.
That said, I also see tremendous opportunities for using AI in ways
that can benefit the project without compromising those goals. For
example, I think we could further experiment with using AI to:
* create and improve unit tests;
* assist with Minilang-to-Groovy conversions;
* help modernize and upgrade parts of our technology stack;
* perform security reviews and identify potential vulnerabilities;
* automate repetitive refactoring tasks
* automate translations (localization) instead of maintaining large
language files in multiple languages in our codebase.
These are areas where AI can amplify developer productivity while
still keeping experienced contributors firmly in control of the design
and review process.
More generally, I think these tools are incredibly valuable when used
by skilled developers who understand both their capabilities and their
limitations. They can substantially improve productivity and, when
applied thoughtfully, even improve the quality of the final result.
The key, in my opinion, is to view them as assistants rather than
replacements for engineering judgment.
Best regards,
Jacopo
On Wed, Jul 1, 2026 at 9:24 AM gaetan.chaboussie via dev
<[email protected]> wrote:
Hi all,
It's a topic that's been on my mind for a while now when reviewing code.
I re-read the Official ASF position on Generative AI that can be found
here [1][2].
I think this quote is important:
"When providing contributions authored using generative AI tooling, a
recommended practice is for contributors to indicate the tooling used to
create the contribution. This should be included as a token in the
source control commit message, for example including the phrase
“Generated-by: ”. This allows for future release tooling to be
considered that pulls this content into a machine parsable
Tooling-Provenance file."
In complex changes that impacts low level code, it also raises the
question of maintainability.
I trust that every contribution has been read and understood, but if for
any reason the committer is not able to commit anymore, maintaining such
code could become quite tricky.
Any thoughts ?
Gaetan
[1] https://www.apache.org/legal/generative-tooling.html
[2]
https://news.apache.org/foundation/entry/why-generative-ai-guidance-is-essential-to-contributors-of-open-source
