Duas Portas, Um Portão: Governança Além do EDD
Regras de onboarding e fricção de desenvolvedores muitas vezes parecem o mesmo problema. Não são.
Quando você escala para quarenta desenvolvedores, não pode usar os mesmos métodos de treinamento para todos. Alguns desenvolvedores são especialistas em agentes de IA. Outros são novos. Se você escrever um conjunto de regras para todos, você falhará.
Desenvolvedores experientes ignorarão as regras. Desenvolvedores novos terão dificuldades com elas.
Você deve separar sua abordagem em duas camadas distintas:
Ferramentas de conscientização (Awareness tools) Estas ferramentas mudam o que uma pessoa sabe. Exemplos incluem comentários de revisão de IA ou avisos de linting. Elas agem como uma recepcionista. Elas percebem coisas e sugerem ações. Elas só funcionam se a pessoa ouvir.
Ferramentas de governança (Governance tools) Estas ferramentas mudam o que uma pessoa pode fazer. Exemplos incluem proteção de branch e gates de merge. Elas agem como uma catraca. Elas não negociam. Elas interrompem o processo se os requisitos não forem atendidos.
O erro é usar uma recepcionista quando você precisa de uma catraca. Uma sugestão de IA que um desenvolvedor ignora não é governança. É apenas ruído.
Para corrigir isso, use duas camadas separadas:
A Camada de Governança Esta camada é pequena e universal. Ela se aplica a todos, independentemente da habilidade. Inclui regras como não realizar pushes diretos para branches protegidas e revisões obrigatórias. Não se trata de confiança. Trata-se de proteger a base de código do alto risco de mudanças impulsionadas por agentes.
A Camada de Andaime (Scaffolding Layer) Esta camada é pessoal e flexível. Inclui etapas como planejamento explícito e raciocínio detalhado. Desenvolvedores novos usam isso intensamente para desenvolver discernimento. Desenvolvedores experientes podem reduzir isso à medida que crescem. Isso não é uma recompensa por senioridade. É uma ferramenta que se torna desnecessária conforme a habilidade aumenta.
Você também deve observar o risco da mudança em si. Um desenvolvedor sênior mexendo em um arquivo complexo e altamente acoplado cria mais risco do que um desenvolvedor júnior mexendo em uma função utilitária simples. O sistema deve responder ao código, não apenas à pessoa.
Finalmente, foque na responsabilidade (ownership). Um agente de IA pode escrever o código, mas o desenvolvedor é o responsável pelo resultado. Se um desenvolvedor não conseguir explicar por que uma mudança foi feita durante uma revisão, a mudança não deve ser mesclada.
Pare de rotular as pessoas com níveis. Em vez disso, forneça ferramentas que permitam que elas gerenciem seu próprio risco.
Fonte: https://dev.to/karlheinz_reichel_7ee08d/two-doors-one-gate-navigating-governance-beyond-edd-5clj
Comunidade de aprendizado opcional: https://t.me/GyaanSetuAi