Los asistentes de programación basados en inteligencia artificial, como GitHub Copilot, Cursor, Claude Code o Gemini Code Assist, ya forman parte del trabajo diario de muchos equipos. Según la Stack Overflow Developer Survey 2025, el 84% de los desarrolladores los usa o piensa usarlos; la misma encuesta indica, sin embargo, que el 46% no confía en la precisión de sus respuestas, frente a un 33% que sí confía.
Para una empresa, por tanto, la pregunta no es si usarlos, sino cómo usarlos sin bajar la calidad del software que entrega. En nuestros proyectos partimos de un principio sencillo: la IA propone, una persona decide. El código que llega a producción pasa los mismos controles, lo haya escrito quien lo haya escrito.
Veamos dónde ayudan estas herramientas, dónde hacen daño y qué reglas mantienen alta la calidad.
Dónde la IA ayuda de verdad
Los asistentes rinden mejor en tareas cuyo resultado es fácil de comprobar:
- Código repetitivo: el llamado boilerplate, es decir, las partes de estructura que siempre son iguales (clases de datos, mapeos, configuraciones, llamadas a las API).
- Pruebas: proponer casos de prueba, incluidos los casos límite que se suelen olvidar. Las pruebas generadas hay que leerlas: una prueba que confirma un comportamiento erróneo es peor que ninguna.
- Refactorización: reorganizar el código sin cambiar lo que hace, por ejemplo extraer funciones o actualizar el uso de una librería, a pequeños pasos.
- Documentación: comentarios, README, descripciones de las pull requests, notas de versión.
- Código heredado: pedir que te expliquen qué hace una función escrita hace años, sin documentación, por alguien que ya no está en la empresa. Es uno de los usos más útiles y menos arriesgados, porque no modifica nada.
Dónde hace daño
El riesgo principal es el código verosímil pero erróneo: compila, parece razonable y esconde un error de lógica, una comprobación que falta o una función de librería que no existe. En la encuesta de Stack Overflow, el problema más citado, por el 66% de los encuestados, son precisamente las soluciones de la IA “casi correctas, pero no del todo”.
- Seguridad: para el GenAI Code Security Report 2025 de Veracode, más de 100 modelos de lenguaje resolvieron 80 tareas de programación; en el 45% de los casos el código contenía una vulnerabilidad de la lista OWASP Top 10.
- Licencias: una sugerencia puede reproducir partes de proyectos de código abierto con licencias que imponen obligaciones. Algunas herramientas tienen un filtro para las sugerencias que coinciden con código público: hay que activarlo.
- Datos confidenciales: pegar en un prompt una clave de acceso, datos personales o el código de un cliente significa enviarlos a un servicio externo, con condiciones de conservación y uso que dependen del contrato.
- Productividad supuesta: en un estudio controlado de METR (julio de 2025), 16 desarrolladores expertos de código abierto, trabajando en proyectos que conocían bien, tardaron un 19% más con la IA, aunque estaban convencidos de haber ido más rápido. La muestra es pequeña y las herramientas eran las de principios de 2025, pero la lección sigue en pie: la productividad se mide, no se da por hecha.
Las reglas que mantienen la calidad
Revisión humana de todo
Cada cambio entra mediante una pull request, una solicitud de integración que un compañero revisa antes del merge. Quien la abre debe saber explicar cada línea, también las que propuso el asistente. Quien la revisa comprueba la lógica y los casos límite, no solo el estilo.
Pruebas automáticas e integración continua
La CI (continuous integration, integración continua) es el proceso automático que, con cada cambio, compila el proyecto y ejecuta las pruebas: si algo se rompe, el merge se detiene. El código sin pruebas no entra, se haya escrito a mano o generado. En el front-end Angular que desarrollamos para SIMOGE, por ejemplo, las pruebas unitarias están escritas con Jasmine y Karma.
Análisis estático y seguridad
Los linters revisan el estilo y los errores comunes; herramientas de análisis estático como Semgrep y SonarQube buscan patrones vulnerables y código duplicado; un escáner de dependencias señala las librerías con vulnerabilidades conocidas. Esto último es clave con la IA, que puede sugerir paquetes obsoletos o incluso inexistentes. Todos estos controles se ejecutan con cada cambio y bloquean la entrega ante errores graves.
Herramientas aprobadas, datos fuera de los prompts
- Solo herramientas aprobadas por la empresa, con un contrato que aclare adónde van los datos y si pueden usarse para entrenar modelos.
- Configuración centralizada: filtro de código público activado, archivos sensibles excluidos del contexto del asistente, cuentas de empresa y no personales.
- Ningún secreto en los prompts: contraseñas y claves van en un gestor de secretos o en variables de entorno, nunca en el código, y un escáner revisa cada commit.
- Ningún dato personal: el RGPD se aplica también cuando se le pide a un modelo ayuda con un bug.
- Código del cliente: se usa con la IA solo si el contrato lo permite y con las herramientas acordadas.
La responsabilidad sigue siendo del desarrollador
El código entregado lleva la firma de un desarrollador, no de un modelo. Por eso la IA no sustituye la experiencia: quien no sabe evaluar una solución no debería aceptarla. Para quien está empezando, el asistente puede ser un excelente profesor, si se usa para pedir explicaciones y no solo respuestas.
En la práctica hacen falta formación sobre el uso de las herramientas, reglas escritas y compartidas y los mismos umbrales de calidad para todo el código. Así la IA acelera el trabajo repetitivo y deja más tiempo para lo que exige criterio: arquitectura, seguridad y diálogo con quienes usarán el software.
Si estáis incorporando asistentes de IA a vuestro equipo, o buscáis un equipo que ya los use con estas reglas, hablemos. En nuestra página de servicios encontraréis lo que hacemos.
