earnifysu opened pull request #10996: cryptonote_core: stop re-validating the whole tx-pool on a fork change

> monero-project/monero #10996

<kayabanerve:matrix.org> @jpk68:matrix.org: I just got some similar PR comments from earnifysu, which is very 'wat'

<thomasbuilds:matrix.org> send you a DM > <@jeffro256> ^ this PR is a fairly simply review, and gets some churn out of the way before the Carrot/FCMP++ integration reviews

reservedbytes opened pull request #10997: device: fix ledger status code reporting

> monero-project/monero #10997

reservedbytes opened pull request #10998: device: report ledger state when no app is open

> monero-project/monero #10998

.merge+ 10962 10959 10958 10954 10953

Added

monero-project/monero #10303 needs a second review for v0.19, it was already tested on streenet

stressnet

.merge+ 10675

Added

nahuhh opened pull request #10999: cryptonote_protocol: trim overlapping spans

> monero-project/monero #10999

.merge+ 10960 10961

Added

jpk68 opened pull request #11000: wallet2: fix compiler warning

> monero-project/monero #11000

yay 11k

Should Monero add an AI policy for contributors? Bitcoin's policy sounds quite reasonable: github.com/bitcoin/bitcoin/blob/master/doc/AI_POLICY.md

Something that could be added to that is that the person submitting the changes as author is directly responsible for the changes, as in, they don't have "AI did a mistake" as an excuse, it's their fault

<jpk68:matrix.org> I would agree with this, Bitcoin Core's AI policy seems good

<jpk68:matrix.org> I said a bunch of cringe stuff about LLMs that I have since changed my opinion on, my bad

I personally still very much consider any LLM produced code (as it can be produced by a newer one better in the future) to be unacceptable besides throwaway/quick iteration on some side tool used to test/guide some work

But using it in the process of development is ok, specially if it's something small/local-only like single-line completion, or making some extra tooling to generate edge cases for completing more tests for your code.

(for example, a recent usecase I had for that was to find specific randomx inputs to test every edge/branch/generator in the code, to have as testcases. The tooling annotated some local git clone code, then bruteforced a bit plus some guidance, and ended up with a list of inputs/outputs I could add to testcases)

the code generating this was thrown away as it'd have become useless after some changes as well

mrelay.p2pool.observer/m/monero.social/oOFkJjBAxBDgFJdQUBRzIOjH.png (image.png)

I second DataHoarder, Bitcoin Core's policy is too encouraging and will just invite more slop. AI is acceptable (not 'welcomed') as a minor side tool, but PRs must be written and understood by the submitter.

People are going to use "AI" anyway. With a policy out in the open, you're saying outright that PRs will be closed and disregarded if it's not clear the author accepts full responsibility for the code. That policy seems decent...

Right I would just adjust the opening to have a more strict tone.

<ofrnxmr:xmr.mx> we've merged a few of what seem to be fully automated prs, fwiw

jpk68 opened pull request #11001: cmake: silence rapidjson warnings

> monero-project/monero #11001

<ofrnxmr:xmr.mx> its obviously not welcome, and extremely unpleaant to speak to a bot that responds with nonsense, but nonetheless the bug fixes were real

like that

<jpk68:matrix.org> Just thinking out loud here: it might be good to add something related to replacing slop PRs if the bot goes haywire

<jpk68:matrix.org> See: monero-project/monero #10335#issue-3984284150

<ofrnxmr:xmr.mx> another example of an annoying bot monero-project/monero #10990

<ofrnxmr:xmr.mx> (might not actually be a bot, but an LLM was doing all of the talking and reasoning)

<-:unredacted.org> My personal opinion is that there should be some policy for the design of the PR‘s, because you waste like minutes just to read what the PR wants to tell you. Valid or not - pain in the eyes the most time.

<-:unredacted.org> AI PR‘s should also be directly labelled in the last line and also which LLM and version was used.

<-:unredacted.org> If all PR‘s (AI or not) follow at least some similar „basic“ structure it would be much easier to read - without all this headings / subheadings / border bloat.

<-:unredacted.org> Most AI PR‘s look like a mixture between shopping list and dictionary.

<ofrnxmr:xmr.mx> we have a policy for that already iirc

<ofrnxmr:xmr.mx> the llm generated prs often write pr desscripions and push for the user. the user isnt doing this, its the llm automatically doing everything

<ofrnxmr:xmr.mx> github.com/monero-project/monero/bl…BUTING.md#commits-and-pull-requests

I find most of the stricter rules a bit pointless and just increase the amount of work we have. If a PR is slop it can be closed, if it's not it can be kept open.

<jeffro256> Which rules in particular?

I meant if we add rules about how PR descriptions should look like, or how exactly AI needs to be disclosed in the description

That sounds like more of a general guideline that could be a different discussion

I think this is more about strictly how AI is allowed usage within the project and interactions with it

And where the responsibility lands

something like tevador suggested with wording changed from welcome to a more neutral term, and maybe something about responsibility would make sense to me

The AI interaction pattern is quite nasty, they are using it on Matrix/IRC channels now

Just blogposts that are AI and all your answers are pasted to AI and response is AI

The human is there because they haven't automated Alt+Tab and Ctrl-C Ctrl-V

but once we limit the amount of AI in code it becomes a waste of time in my opinion, I don't want to spend detective investigating each PR for signs of AI

It's not "human in the loop" but "human is the loop"

(apart from the fact that AI has been useful to me solving long existing bugs)

We can change "Using AI (i.e. LLMs) as tools for coding is welcome" -> "Using AI (i.e. LLMs) as tools for coding is permitted"

23:38 <DataHoarder> It's not "human in the loop" but "human is the loop" <-- that makes sense yes

tevador: fine with me

<jpk68:matrix.org> +1

<jpk68:matrix.org> Perhaps we can also simply say "this was based on Bitcoin Core's policy" rather then delving into the entire damn etymology chain at the bottom of the document

<ofrnxmr:xmr.mx> I would probably also prefer (doesnt really need to be documented) that pr approvals should only come from humans

<hbs:matrix.org> OpenJDK policy is interesting too openjdk.org/legal/ai

tevador opened pull request #11002: Add an AI policy

> monero-project/monero #11002

"responsible for the contribution" -> contribution and contents?

It otherwise sounds like they are only responsible from filling out checkboxes and doing the PR

<ofrnxmr:xmr.mx> well, reviewers share responsibility too

<ofrnxmr:xmr.mx> cant blame the clanker if we rubber stamp some trash

<ofrnxmr:xmr.mx> (approvals are now stored in merge commits, fwiw)

<ofrnxmr:xmr.mx> the author can get tunnel blindness and not see errors in their own code. a second pair of eyes is useless if they dont actually look. and clanker reviews arent a reliable source of truth, which is why i push back against people using ai to form their approval. LLM reviews should, at best, be sanity checks "did i miss somethin [... too long, see mrelay.p2pool.observer/e/oom5zJsLb0hkU3BS ]

<ofrnxmr:xmr.mx> in this context, i think reviews are possibly the most important part of the pipeline that needs to be not fall into al LLM trap

<ofrnxmr:xmr.mx> an*