← Volver al blog

Una política de pair programming con IA que tu equipo de ingeniería cumple

La mitad de los equipos adoptó un copilot por decreto: alguien enciende la herramienta y el equipo empieza a aceptar sugerencias. Sin política escrita, cada persona aplica un estándar de revisión distinto, y el tech lead se entera cuando un pull request lleno de código generado pasa seis aprobaciones sin que nadie lea la lógica. Una política de pair programming con IA cabe en una página, necesita cuatro definiciones y sirve para equipos de 5 a 40 personas.

Datos que no entran en prompt alguno

Lista escrita, con ejemplos, dentro del repositorio. Claves de API, datos de cliente, código cubierto por un acuerdo de confidencialidad, repositorio de terceros con licencia restrictiva. La documentación de servicios de IA generativa de AWS y Google Cloud trae cláusulas propias sobre datos enviados al servicio, y el texto de la política debe decir qué norma rige el contrato de la empresa. La lista vive en el repositorio de gobernanza y en el README del proyecto, lejos del canal de chat.

Revisión humana para todo cambio generado

El autor responde por el cambio. La revisión de pull request mantiene el mismo nivel de profundidad cuando el diff salió de la herramienta. Peng y colegas, en un estudio publicado en arXiv (Microsoft y GitHub, 2023), midieron ganancias de velocidad con GitHub Copilot: la ganancia aparece en la escritura inicial del código y la responsabilidad del razonamiento sigue del lado de quien subió el cambio. Aprobar un diff generado sin leerlo traslada el riesgo a producción.

Métrica de adopción sin ranking

Una línea por squad en el reporte semanal. Porcentaje de pull requests con sugerencias aceptadas, tiempo medio de revisión y defectos por release. El State of DevOps Report de DORA muestra que la métrica de ingeniería cambia comportamiento cuando el equipo discute el número junto, en lugar de recibir un ranking de arriba. Dos indicadores entran; si el número se vuelve teatro, saca uno.

Consecuencia definida antes del incidente

El paso a paso cuando sube un dato prohibido. Revocar credencial, avisar a seguridad, revisar logs y definir quién comunica al cliente. Amy Edmondson, en The Fearless Organization (Wiley, 2018), muestra que el equipo que conoce el proceso de respuesta habla antes sobre el error. Definir la consecuencia por adelantado saca el castigo de la conversación y la mantiene en la causa.

Revisión trimestral de la política

Una hora, con la herramienta, el contrato y el equipo. Saca de la lista lo que nadie sigue, agrega el caso nuevo del trimestre y publica la versión fechada. Una política que nadie actualiza se vuelve texto que el equipo ignora en el segundo mes.

¿Enfrentando este desafío en tu empresa?

Ayudo a CTOs y equipos de ingeniería a resolver problemas como este.

Agendar una conversación
Marc Reinan Gomes
Marc Reinan Gomes Staff Engineer y Consultor

14+ años construyendo productos, liderando equipos y ayudando empresas a escalar con calidad técnica.

Compartir en LinkedIn