Dos puertas, un acceso: Gobernanza más allá de EDD
Las reglas de onboarding y la fricción de los desarrolladores suelen parecer el mismo problema. No lo son.
Cuando escalas a cuarenta desarrolladores, no puedes usar los mismos métodos de capacitación para todos. Algunos desarrolladores son expertos con agentes de IA. Otros son nuevos. Si escribes un conjunto de reglas para todos, fracasarás.
Los desarrolladores experimentados ignorarán las reglas. Los nuevos desarrolladores tendrán dificultades con ellas.
Debes separar tu enfoque en dos capas distintas:
Herramientas de concienciación (Awareness tools) Estas herramientas cambian lo que una persona sabe. Los ejemplos incluyen comentarios de revisión de IA o advertencias de linting. Actúan como un recepcionista. Notan cosas y sugieren acciones. Solo funcionan si la persona escucha.
Herramientas de gobernanza (Governance tools) Estas herramientas cambian lo que una persona puede hacer. Los ejemplos incluyen la protección de ramas (branch protection) y puertas de fusión (merge gates). Actúan como un torniquete. No negocian. Detienen el proceso si no se cumplen los requisitos.
El error es usar un recepcionista cuando necesitas un torniquete. Una sugerencia de IA que un desarrollador ignora no es gobernanza. Es solo ruido.
Para solucionar esto, utiliza dos capas separadas:
La capa de gobernanza Esta capa es pequeña y universal. Se aplica a todos, independientemente de su habilidad. Incluye reglas como la prohibición de pushes directos a ramas protegidas y revisiones obligatorias. No se trata de confianza. Se trata de proteger la base de código del alto riesgo de los cambios impulsados por agentes.
La capa de andamiaje (Scaffolding Layer) Esta capa es personal y flexible. Incluye pasos como la planificación explícita y el razonamiento detallado. Los nuevos desarrolladores la utilizan intensamente para desarrollar criterio. Los desarrolladores experimentados pueden reducir su uso a medida que crecen. Esto no es una recompensa por la antigüedad. Es una herramienta que se vuelve innecesaria a medida que aumenta la habilidad.
También deberías considerar el riesgo del cambio en sí mismo. Un desarrollador senior que toca un archivo complejo y altamente acoplado crea más riesgo que un desarrollador junior que toca una función de utilidad simple. El sistema debe responder al código, no solo a la persona.
Finalmente, enfócate en la propiedad (ownership). Un agente de IA puede escribir el código, pero el desarrollador es el dueño del resultado. Si un desarrollador no puede explicar por qué se realizó un cambio durante una revisión, el cambio no debe fusionarse.
Deja de etiquetar a las personas con niveles. En su lugar, proporciona herramientas que les permitan gestionar su propio riesgo.
Source: https://dev.to/karlheinz_reichel_7ee08d/two-doors-one-gate-navigating-governance-beyond-edd-5clj
Optional learning community: https://t.me/GyaanSetuAi