Hi everyone,
In response to Fred, I think you meant LLMs are trained exclusively on
public data and do not use private information except when companies run
training workloads on their own private data.
Worth noting before we debate whether to adopt AI in Fineract, Fineract
already has one guideline (AGENTS.md), and it is already our chosen
mechanism for governing AI behavior but the gap is in scope, not policy.
Today that file governs exactly one behavior (security triage) with exactly
one pointer.
It says nothing about:
- build/test/lint commands and how a PR gets verified
- architecture pointers (modules, tenant model, COB, REST conventions)
- coding and testing conventions
- commit/PR workflow rules
The practical cost of a minimal AGENTS.md is that it governs different
agents inconsistently. A security scanner gets told to consult the threat
model; a coding agent gets no equivalent instruction and falls back to
whatever it finds in README or its own training. Two AI contributors can
therefore behave differently in the same repo — which is exactly the
inconsistency we should close.
Finally, AGENTS.md (governed by Linux Foundation AI Foundation) is the
standard at Apache and most open source projects and it is read by over 30
AI Agent tools except Claude which still uses .CLAUDE.md but a one line
import in Claude.MD solves this.
Recommendation (two layers: Overall Agent guidance and one-skill-per-task
for the reusable know-how):
1. Improve on existing AGENTS.md to become the canonical source:
build/test/lint commands (from the README), architecture pointers,
SECURITY.md link, testing conventions, RAT/license-header note. CLAUDE.md
reduced to an import.
2. skills/SKILL.md — one skill per task. AGENTS.md can only hold
pointers and where to look (project context). The how-to for recurring task
types belongs in Agent Skills — this is now a standard under the same Linux
Foundation, *already in mifos-web repo* (skills/SKILL.md). The format is
a directory of SKILL.md files, each with YAML frontmatter (name,
description) and a procedural body, loaded on demand only when the task
matches the description.
3. Some starter skills could be
1. skills/code-review/SKILL.md
2. skills/database/SKILL.md
3. skills/cob-batch/SKILL.md
4. skills/testing/SKILL.md (For example: New integration tests MUST
use the Feign-based Fineract client (fineract-client-feign), NOT
RestAssured)
5. skills/security/SKILL.md
Regards,
Tofunmi Paul Oguntibeju.
On Tue, Sep 1, 2026 at 7:35 PM Fred Amaral via dev <[email protected]>
wrote:
> thanks, alek. my point will always be: these LLMs ARE TRAINED on private
> data. there is no single one that has not broken out to media regarding
> that. however, the capacity of someone claiming propriety over a snippet of
> code within an open source codebase is clearly zero. snippets of code are
> not a codebase. it does not carry a stamp.
> i dont like to mention (cause seems to be an argument of authority), but
> the last messages from linus paint very well the scenario: it is inevitable.
>
> disclaimer: i'm biased, since i invest a lot on hardware to run LLMs on my
> own. my take is more to try to show that it's not a discussion about
> opening the can. it's already opened.
>
>
> On Tue, Sep 1, 2026 at 1:28 PM Aleksandar Vidakovic <
> [email protected]> wrote:
>
>> @Fred Amaral <[email protected]> the difference is that when you copy
>> and paste it's YOUR (the human's) choice and responsibility. If your
>> argument is that you can copy and paste while ignoring the rules then this
>> is certainly true, but even if no one knows then YOU still know that
>> something was not right; if no one detects you then congratulations, but if
>> someone does then you are the last to hold the bag.
>>
>> When you delegate all this to a machine then you are in a whole different
>> space: when you copy and paste you know what's going on, when an LLM does
>> this for you (and it does... however indirectly) then you don't know if
>> something wrong happened (was the LLM trained with GPL licensed data?), but
>> it doesn't exempt you either (see Adam's proposed policy point no. 2); so
>> how can you be accountable if you don't know how the results were put
>> together? OpenAI isn't (or doesn't want to be, see disclaimer). Try to open
>> 2 separate prompts and enter the same (non-trivial) text... is the result
>> reproducible? Claiming to not know doesn't make this problem go away
>> suddenly.
>>
>> On Tue, Sep 1, 2026 at 7:08 PM Fred Amaral via dev <
>> [email protected]> wrote:
>>
>>> in the old world, was taking a snippet from elsewhere a copyright
>>> infringement? (really a question, dont know).
>>>
>>> On Tue, Sep 1, 2026 at 12:56 PM Aleksandar Vidakovic <
>>> [email protected]> wrote:
>>>
>>>> ... this sounds like there is a standard... there is not. This is
>>>> already hard to achieve with classic development... there are a ton of
>>>> different approaches and (actual) standards (development on embedded
>>>> components in the automotive industry and similar)... to really make an
>>>> informed decision here we would need to make sure that two people that run
>>>> the same tool setup create the same results... I'd say: impossible, but
>>>> happy to change my mind if you point to an example where this ever happened
>>>> with AI tools.
>>>>
>>>> On Tue, Sep 1, 2026 at 6:17 PM Prashant Rahulkar <
>>>> [email protected]> wrote:
>>>>
>>>>> I think we should adopt the best industry framework to integrate with
>>>>> the Development agent.
>>>>>
>>>>> Thanks,
>>>>> Prashant Rahulkar.
>>>>>
>>>>> On Tue, 1 Sept 2026 at 17:10, Ádám Sághy <[email protected]> wrote:
>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>>
>>>>>> My two cents:
>>>>>>
>>>>>>
>>>>>> Since AI is already being used, having rules and a playbook would be
>>>>>> beneficial to avoid any misunderstandings.
>>>>>>
>>>>>>
>>>>>> Considering its widespread adoption across various fields such as
>>>>>> development, debugging, testing, brainstorming, and PR reviewing, we
>>>>>> don’t
>>>>>> need to debate whether the Apache or Fineract community wants it. It’s
>>>>>> already in use, and contributors will continue to use it (*I don’t
>>>>>> believe there’s a way to prevent it, nor should it be!*). Let’s
>>>>>> focus on determining appropriate boundaries and its intended use.
>>>>>>
>>>>>>
>>>>>> Disclaimer: I am not up to date with latest “recommendations” of
>>>>>> Apache on this topic.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Adam Saghy
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sep 1, 2026, at 8:53 AM, Sujan <[email protected]> wrote:
>>>>>>
>>>>>> Hi Aman,
>>>>>>
>>>>>> +1 to having some clear boundaries around AI-assisted development.
>>>>>>
>>>>>> I think there are valid positives and negatives here. AI can
>>>>>> definitely help with productivity, debugging, and refactoring, but
>>>>>> contributors should still understand and take ownership of the changes
>>>>>> they
>>>>>> submit. If PRs become mostly AI-generated, it also makes them much harder
>>>>>> to review effectively.
>>>>>>
>>>>>> I think a lightweight, project-specific policy would be a good middle
>>>>>> ground rather than completely discouraging AI or allowing unrestricted
>>>>>> use.
>>>>>>
>>>>>> On Tue, 1 Sept, 2026, 11:42 VICTOR MANUEL ROMERO RODRIGUEZ, <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Aman,
>>>>>>>
>>>>>>> Thank you for starting this important topic.
>>>>>>>
>>>>>>> *+1 to starting a dedicated discussion and adopting a lightweight,
>>>>>>> project-specific AI policy.*
>>>>>>>
>>>>>>> I support the direction because AI-assisted development is already
>>>>>>> happening (it is very noticeable this year before the GSOC and the
>>>>>>> increasing numbers of PRs submitted and merged) and clear, practical
>>>>>>> guidelines (for developers and reviewers) will help us benefit from it
>>>>>>> without creating problems for maintainers or the project’s legal
>>>>>>> posture.
>>>>>>> An optional disclosure approach plus a short *AI_POLICY.md*
>>>>>>> inspired by Apache Fory’s is a sensible starting point. It can be
>>>>>>> adapted
>>>>>>> for Apache Fineract rather than copying it wholesale.
>>>>>>>
>>>>>>> To address the concerns raised earlier (including those from Aleks)
>>>>>>> I think is good to stay aligned with the ASF Generative Tooling Guidance
>>>>>>> https://www.apache.org/legal/generative-tooling.html
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Victor Romero
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> El lun, 31 ago 2026 a las 23:44, Aman Mittal (<
>>>>>>> [email protected]>) escribió:
>>>>>>>
>>>>>>>> Hi everyone,
>>>>>>>>
>>>>>>>> I want to revive the discussion based on
>>>>>>>> https://lists.apache.org/thread/xxoqt3jn8trhwo1lnxjy46r1dkolfg1h
>>>>>>>>
>>>>>>>> and Concerns raised by Aleks in
>>>>>>>> https://lists.apache.org/thread/oq25gyjsx0wry4jf58odds9z92pfx6bj
>>>>>>>>
>>>>>>>> Regarding the usage and guidelines of AI, I think we need to
>>>>>>>> discuss AI-assisted development a bit more, so I'm creating this
>>>>>>>> dedicated
>>>>>>>> thread on the dev list.
>>>>>>>>
>>>>>>>> As per my understanding, using AI is fine if contributors
>>>>>>>> understand their work and can explain their reasoning for each line.
>>>>>>>>
>>>>>>>> So, I'm thinking we can start with an optional disclosure policy on
>>>>>>>> that.
>>>>>>>> I think we can add a AI_POLICY.md for each repo. One policy we can
>>>>>>>> take inspiration from is
>>>>>>>> https://github.com/apache/fory/blob/main/AI_POLICY.md
>>>>>>>> While we do not need to copy it entirely, we can take inspiration
>>>>>>>> from it and modify it for FINERACT and all the repos based on community
>>>>>>>> feedback.
>>>>>>>>
>>>>>>>> I suggest that it should include Commonly used AI setups that
>>>>>>>> contributors did not declare in an AI usage disclosure.
>>>>>>>>
>>>>>>>> What does the community think about this?
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Aman
>>>>>>>>
>>>>>>>>
>>>>>>
