Due porte, un cancello: la governance oltre l'EDD
Le regole di onboarding e l'attrito tra gli sviluppatori spesso sembrano lo stesso problema. Non lo sono.
Quando si arriva a quaranta sviluppatori, non è possibile utilizzare gli stessi metodi di formazione per tutti. Alcuni sviluppatori sono esperti di agenti AI. Altri sono nuovi. Se scrivi un unico set di regole per tutti, fallisci.
Gli sviluppatori esperti ignoreranno le regole. I nuovi sviluppatori faranno fatica a seguirle.
Devi separare il tuo approccio in due livelli distinti:
Strumenti di consapevolezza (Awareness tools) Questi strumenti cambiano ciò che una persona sa. Gli esempi includono commenti di revisione AI o avvisi di linting. Agiscono come un receptionist. Notano le cose e suggeriscono azioni. Funzionano solo se la persona ascolta.
Strumenti di governance (Governance tools) Questi strumenti cambiano ciò che una persona può fare. Gli esempi includono la protezione dei branch e i merge gate. Agiscono come un tornello. Non negoziano. Bloccano il processo se i requisiti non sono soddisfatti.
L'errore è usare un receptionist quando serve un tornello. Un suggerimento dell'AI che uno sviluppatore ignora non è governance. È solo rumore.
Per risolvere il problema, utilizza due livelli separati:
Il livello di Governance Questo livello è piccolo e universale. Si applica a tutti, indipendentemente dalle competenze. Include regole come il divieto di push diretti su branch protetti e le revisioni obbligatorie. Non si tratta di fiducia. Si tratta di proteggere il codebase dall'alto rischio dei cambiamenti guidati dagli agenti.
Il livello di Scaffolding Questo livello è personale e flessibile. Include passaggi come la pianificazione esplicita e il ragionamento dettagliato (verbose reasoning). I nuovi sviluppatori lo usano intensamente per sviluppare il giudizio. Gli sviluppatori esperti possono ridurlo man mano che crescono. Non è un premio per l'anzianità. È uno strumento che diventa superfluo all'aumentare delle competenze.
Dovresti anche considerare il rischio del cambiamento stesso. Uno sviluppatore senior che tocca un file complesso e altamente accoppiato crea più rischio di uno sviluppatore junior che to