I propose adding a few simple and enforceable rules: https://github.com/apache/fineract/pull/6366
Aleks wrote: do we really think we master these tools like using an IDE and are > confident of the outcome...? This is a great point. No, not in terms of deterministic/reproducible outcomes--I agree AI-assisted / agentic coding doesn't work that way. *And* AI is useful regardless. (better yet: *sometimes useful and sometimes terribly dangerous*, similar to any powerful tool) I'd argue then why even have points 2. and 3. in the policy... if the use > of the AI tools seems to be unavoidable then the enforcement of these rules > will be difficult at least or impossible. More than our other "rules"? Our "PR checklist"? Nah, I think we've got this. The "1. 2. 3." ideas from fory make sense together, and I like them for Fineract too. We get thoughtfully authored AI-assisted contributions from responsible human contributors today. And we also get some slop. AI-specific rules will help with the slop. And the rules may be incomplete and hard to enforce. That is as it always is. Aleks, if you haven't already, please check out https://www.apache.org/legal/generative-tooling.html (updated since the Dec 2025 AI policy discussion <https://lists.apache.org/thread/xxoqt3jn8trhwo1lnxjy46r1dkolfg1h>) in detail. It agrees with much of what you're saying, and includes specific recommendations such as including Generated-by: , and what to do if/when a copyright violation is discovered. Here's an excerpt: 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. > > Also note section 8 of the ICLA. If you later learn something that makes > these representations inaccurate, you agree to notify the Foundation. For > example, you may discover that a tool's output reproduced code under an > incompatible license. If that happens, contact And Aleks, I agree with much of your "I'm ok with: / I'm not ok: / I'm on the fence with:" bullet points, except: I'm not ok: ... > • ... nor mark the parts of the results that were generated without any > human involvement I'm definitely not going to bother specifically marking those, nor would I expect anyone to. Maybe we need to be specific about how *much* AI use we're OK with? e.g. how many lines of code/docs generated with little to no guidance? I don't know the right answer here nor if it's useful to dig further, but maybe that's where we're reaching some friction. I don't vibe code anything important, personally. I try to only include small chunks of AI-generated code/docs in my Fineract contributions, and I feel I must understand every line--even every character--before proposing a patch. The way I use AI feels quite similar to re-using snippets of public domain code. I'm not ok: ... > • use these tools without pinning down (agreeing on) certain architectural > rules; without this we just add more technical debt Of course. We need these rules regardless. I'm not ok: ... > • dropping changes/PRs with more than 100 files changed is even more > tempting now Agreed. We're not going to suddenly welcome "code dumps". All our existing contribution guidelines still apply. I'm on the fence with: ... > • security scans Separate topic. (FWIW, I agree...) So... what are the concrete rules...? Here's my proposal <https://github.com/apache/fineract/pull/6366>.
