L’ANALISI
QGIS QEP 428: cosa cambia con il divieto di codice assistito da AI
Analisi pratica di QGIS QEP 428: ambito del divieto di codice assistito da AI, conseguenze per contributor e maintainer, limiti e checklist di conformità.
In breve: QEP 428 trasforma una preferenza editoriale in una regola di contribuzione: chi propone codice a qgis/QGIS deve poter garantire che non è stato prodotto con LLM, AI o workflow agentici. Per i team il punto operativo è separare nettamente esplorazione interna e patch destinate all’upstream, mantenendo una provenienza verificabile.
Che cosa vieta la policy
Il testo approvato vieta contributi di codice assistiti da LLM, AI o agenti nel repository qgis/QGIS. Non si limita al codice interamente generato: la formulazione include anche l’assistenza, quindi l’ambito operativo è più ampio del semplice copia-incolla di una risposta.
Quali conseguenze prevede
Se l’uso viene scoperto dopo l’accettazione, QGIS indica due possibili conseguenze: reversione del codice e sanzioni sui diritti del contributor. Il controllo non termina quindi al merge e la provenienza resta rilevante nel tempo.
Perché cambia il lavoro dei contributor
Un contributor deve scegliere strumenti e processi compatibili prima di iniziare una patch. Chi usa assistenti AI nel lavoro quotidiano deve creare un confine netto per le modifiche destinate a QGIS, evitando che suggerimenti, completamenti o agenti entrino nella catena di produzione del codice.
Che cosa significa per i maintainer
La policy riduce l’ambiguità decisionale ma non fornisce un rilevatore affidabile né una procedura tecnica completa. I maintainer devono quindi applicare la regola con evidenze contestuali, cronologia delle modifiche e comunicazione chiara, senza trattare classificatori probabilistici come prova definitiva.
Condizioni e limitazioni
La regola riguarda i contributi al repository principale qgis/QGIS e non dimostra che il codice generato sia sempre difettoso. Il testo pubblico è molto breve e non descrive un metodo tecnico di rilevamento, eccezioni o una procedura dettagliata di appello.
Checklist pratica
- Leggere la policy QGIS corrente prima di aprire una issue o una pull request.
- Disattivare completamenti AI, chat di coding e agenti nel workspace usato per la patch upstream.
- Separare branch e ambienti destinati a QGIS da prototipi interni assistiti da AI.
- Conservare note, commit piccoli e una cronologia che renda ricostruibile l’autore del cambiamento.
- Chiedere chiarimenti ai maintainer prima di contribuire se il proprio flusso ricade in un caso non descritto.