En los últimos 18 meses, la mayoría de tu equipo empezó a usar alguna herramienta de IA en el trabajo: GitHub Copilot, ChatGPT, Claude, Cursor. La empresa no lo pidió, el equipo no esperó permiso y nadie lo prohibió.
En muchas organizaciones el resultado es uso fragmentado, estándares inconsistentes, código generado entrando sin revisión crítica y un líder técnico sin visibilidad de lo que se acepta en los repositorios.
Estado de la adopción
La Developer Survey de Stack Overflow de 2024 registró al 76% de los respondentes usando o planeando usar herramientas de IA en desarrollo. Sida Peng, Eirini Kalliamvakou, Peter Cihon y Mert Demirer midieron en "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot" (2023) una tarea terminada 55% más rápido con Copilot activado.
Usar cubre un espectro amplio: autocompletar un import hasta generar un archivo entero de lógica de negocio. El riesgo aparece cuando cada ingeniero trabaja a su manera, sin revisión crítica.
- Código generado que funciona y que nadie entiende lo suficiente como para mantenerlo
- Estándares inconsistentes que frenan el code review y el onboarding
- Una vulnerabilidad aceptada sin análisis
- Una dependencia innecesaria agregada por el generador
- Un test que cubre el camino feliz y salta los casos borde
Cuatro prácticas de equipo
1. Define dónde entra la IA
En código repetitivo, transformaciones bien definidas, tests unitarios de funciones puras y documentación de API, la herramienta acorta el tiempo. Reserva revisión humana activa para lógica de negocio crítica, código de seguridad y decisiones de arquitectura.
2. Una regla de revisión para código generado
El código generado pasa por los mismos criterios que el código humano. Quien abrió el PR responde por lo que está ahí, sin importar quién lo produjo. Escribe la regla: parte del equipo trata la salida de la herramienta como un borrador que no pide revisión.
3. Prompts de referencia del repositorio
Un prompt ajustado al patrón del repositorio y al estilo de test del equipo produce código coherente y recorta retrabajo. Queda documentado y cambia cuando cambia el patrón.
4. Medición del efecto
Mide el tiempo de ciclo de las features antes y después, bugs por sprint y tiempo medio de code review. Velocidad igual con calidad peor apunta a la práctica del equipo, y la herramienta sale del proceso de decisión.
Seguridad en código generado
Un modelo de lenguaje aprendió de código público, código inseguro incluido, y devuelve un patrón que funciona con una falla conocida. SQL injection, XSS y exposición de datos sensibles aparecen en la salida de herramientas populares.
OWASP listó estos riesgos en Top 10 for LLM Applications (2023), con inyección de prompt y fuga de datos entre los ítems. El State de DevOps de DORA 2024 mostró adopción alta entre los respondentes y un efecto contradictorio: más productividad individual junto con caídas de throughput y de estabilidad en la entrega.
Mantén corriendo las capas existentes: code review, pruebas de seguridad y SAST. Entrena al equipo para reconocer el patrón de riesgo más común en el código generado.
Quién conduce la adopción
La dirección técnica elige la herramienta aprobada para el contexto de la empresa, publica una guía para los usos más comunes, fija criterios de revisión y abre espacio para que el equipo comparta práctica. Un equipo con esa estructura saca más valor de la herramienta y produce menos retrabajo. Un equipo sin ella discute la herramienta todas las semanas.
