IA vs. programadores: la guerra por la soberanía del código!
La IA escribe código en segundos, pero no asume sus consecuencias. Analizamos quién conserva la autoría, el control y toda la responsabilidad real del software.
La IA y los programadores no están librando una guerra por ver quién teclea más deprisa. La batalla de verdad es otra: quién conserva la capacidad de entender, modificar y defender el código cuando algo falla.
Una empresa puede tener el repositorio, pagar las licencias y figurar como titular del software. Pero si nadie de su equipo puede explicar por qué existe una dependencia, reconstruir una decisión arquitectónica o corregir un fallo sin volver a preguntarle al mismo proveedor de IA, ¿controla realmente su producto?
Esta es la tesis incómoda: el código que no puedes explicar no es del todo tuyo, aunque esté en tu Git. No porque una máquina vaya a reclamarlo mañana, sino porque has cedido la parte más valiosa de la propiedad: el criterio para gobernarlo.
Qué significa la soberanía del código
La soberanía del código es la capacidad efectiva de una persona o una organización para comprender, auditar, modificar, desplegar y sustituir su software sin depender de un actor que no controla. No es sinónimo de escribir cada línea a mano ni de rechazar herramientas externas.
Se parece más a la soberanía sobre una infraestructura: importa quién tiene las llaves, pero también quién conoce el plano, quién puede reparar una avería y quién responde si el edificio se cae.
| Dimensión | Hay soberanía cuando… | Se pierde cuando… |
|---|---|---|
| Comprensión | El equipo puede explicar las decisiones relevantes | El código «funciona», pero nadie sabe por qué |
| Trazabilidad | Cada cambio tiene contexto, autor responsable y pruebas | Los commits son volcados opacos generados por un chat |
| Capacidad de salida | Puedes cambiar de modelo, proveedor o herramienta | El flujo depende de una plataforma y de su memoria privada |
| Seguridad | El código generado pasa los mismos controles que el humano | La revisión se reduce a comprobar que compila |
| Responsabilidad | Una persona acepta y defiende cada cambio | La culpa termina atribuida a «lo que dijo la IA» |
La polémica, por tanto, no es IA contra ingenio humano. Es automatización con criterio contra automatización sin dueño.
La paradoja: usamos más IA cuanto menos confiamos en ella
Los datos dibujan una relación bastante más tensa que el relato comercial. En la encuesta de Stack Overflow de 2025, un 46 % de los desarrolladores declaraba desconfiar de la precisión de las herramientas de IA, frente a un 33 % que confiaba en ellas. Solo un 3 % decía confiar mucho. Aun así, el 52 % consideraba que la IA había mejorado su productividad.
No es una contradicción menor. Estamos incorporando a la cadena de producción una herramienta que percibimos como útil y, al mismo tiempo, como poco fiable. La velocidad entra por la puerta principal; la deuda de verificación se queda viviendo dentro.
La escena resulta familiar: el asistente genera en veinte segundos una función, sus pruebas y una explicación convincente. El ahorro parece evidente. Después aparecen una API inexistente, un caso límite que no estaba en el prompt y una dependencia que nadie había aprobado. Escribir fue más rápido; terminar bien el trabajo quizá no.
¿La IA programa mejor? Depende de qué midas
Quien quiera defender que la IA ya gana tiene argumentos. Quien quiera refutarlo, también. El error consiste en comparar cifras construidas sobre tareas y métricas distintas como si midieran lo mismo.
El caso a favor: más velocidad y código funcional
GitHub ha publicado estudios controlados favorables a Copilot. En uno de ellos, con 202 entregas válidas de desarrolladores con al menos cinco años de experiencia en Python, quienes usaron Copilot tuvieron un 53,2 % más de probabilidades de superar las diez pruebas unitarias del ejercicio. GitHub también cita trabajos anteriores en los que los participantes completaron una tarea hasta un 55 % más rápido.
Son resultados relevantes y sería tramposo ignorarlos. También conviene leer la letra metodológica: se trataba de ejercicios acotados y los estudios fueron publicados por la empresa que comercializa la herramienta. Eso no invalida los datos, pero sí obliga a evitar una extrapolación automática a cualquier equipo, repositorio o producto.
El caso en contra: expertos más lentos en su propio terreno
En 2025, METR realizó un ensayo aleatorizado con 16 desarrolladores experimentados, 246 tareas reales y repositorios de código abierto que conocían desde hacía una media de cinco años. Con herramientas de IA disponibles, tardaron un 19 % más. Lo más provocador fue la percepción: después seguían creyendo que la IA les había hecho un 20 % más rápidos.
Ese estudio tampoco dicta una ley universal. La muestra era pequeña, las bases de código eran maduras y los participantes tenían mucha experiencia previa en ellas: justo el contexto en el que una IA aporta menos conocimiento nuevo y exige más revisión.
En febrero de 2026, la propia METR publicó una actualización que complica el titular. Sus nuevos datos brutos sugerían aceleración, pero la organización los calificó de poco fiables por sesgos de selección y por la dificultad de medir a desarrolladores que usan varios agentes a la vez. Su conclusión prudente fue que probablemente la IA ya ayude más que a comienzos de 2025, aunque todavía no puede cuantificar cuánto con rigor.
| Estudio | Contexto | Resultado | Lo que no demuestra |
|---|---|---|---|
| GitHub, 2024/2025 | Ejercicio acotado de Python | Más probabilidad de pasar todas las pruebas; estudios previos, hasta 55 % más rápido | Que el efecto se mantenga en sistemas grandes y a largo plazo |
| METR, 2025 | 246 tareas reales en repositorios conocidos | 19 % más de tiempo con IA | Que la IA ralentice a noveles, proyectos nuevos o modelos posteriores |
| METR, 2026 | Herramientas más nuevas y uso multiagente | Indicios de aceleración | Una cifra causal fiable por los sesgos reconocidos |
| Stack Overflow, 2025 | Encuesta de percepción profesional | 52 % percibe más productividad; 46 % desconfía de la precisión | Productividad objetiva o calidad del software entregado |
La conclusión más honesta no vende tantas licencias ni tantos cursos: la IA puede acelerar la producción de código, pero la productividad depende del coste de comprenderlo, revisarlo, integrarlo y mantenerlo.
El repositorio es tuyo; el criterio puede no serlo
Hay una idea seductora: «si el código acaba en mi repositorio, ya es mío». Confunde posesión con soberanía.
Supongamos que un agente construye una funcionalidad completa: elige librerías, define el modelo de datos, crea rutas, escribe pruebas y resuelve errores. El equipo revisa el resultado mirando la interfaz y aprobando que las pruebas pasan. Seis meses después hay que cambiar una regla de negocio crítica.
El riesgo no es que la IA exija derechos. El riesgo es que ninguna persona haya construido un modelo mental suficiente del sistema. El repositorio conserva el texto, pero la justificación quedó dispersa entre prompts, respuestas no versionadas y decisiones probabilísticas imposibles de reproducir exactamente.
Esto crea tres dependencias silenciosas:
- Dependencia cognitiva: el equipo pierde práctica para diagnosticar sin asistencia.
- Dependencia contextual: parte del conocimiento vive en conversaciones privadas o en la memoria del proveedor.
- Dependencia operativa: cambiar de herramienta altera el flujo porque las instrucciones, integraciones y resultados no son portables.
La soberanía no exige prescindir de la IA. Exige que el contexto decisivo viva en artefactos controlados por la organización: documentación, ADR, pruebas, contratos de API, esquemas y revisiones de código.
Quién es autor del código generado por IA en España
Aquí conviene rebajar el volumen y aumentar la precisión. Esto no es asesoramiento jurídico, pero el punto de partida español está bastante claro.
Los artículos 96 y 97 de la Ley de Propiedad Intelectual establecen que un programa se protege si es original, como creación intelectual propia de su autor, y consideran autor a la persona o grupo de personas naturales que lo hayan creado, con los supuestos de titularidad de personas jurídicas previstos por la ley. Cuando el programa lo crea un trabajador en el ejercicio de sus funciones, los derechos de explotación corresponden al empresario salvo pacto en contrario.
La ley española no contiene hoy una fórmula específica del tipo «quien escribe el prompt posee toda salida». Cuanto más autónoma sea la generación y menor la aportación creativa humana demostrable, más difícil puede resultar sostener que cada fragmento está protegido en los mismos términos que una obra humana original. La titularidad contractual, además, no elimina el posible riesgo de reproducir material de terceros.
Como referencia comparada —no como norma aplicable en España—, la Oficina de Copyright de Estados Unidos concluyó en 2025 que el uso de IA como ayuda no impide la protección, pero que el material puramente generado por IA no queda protegido y que, con la tecnología analizada, un prompt por sí solo no aporta control humano suficiente.
El Reglamento Europeo de Inteligencia Artificial obliga a los proveedores de modelos de propósito general a mantener una política de cumplimiento del derecho de autor de la Unión y a publicar un resumen suficientemente detallado del contenido usado para el entrenamiento. Es un avance en transparencia, no un certificado automático que deje sin riesgo jurídico todo el código generado aguas abajo.
La pregunta empresarial útil no es únicamente «¿podemos registrar esto?». También es: ¿podemos demostrar quién decidió qué, qué revisó y con qué fuentes y licencias se construyó?
El nuevo cuello de botella no es escribir: es revisar
Durante años, el coste marginal estaba en producir código. Los agentes cambian la ecuación: pueden proponer más cambios de los que un equipo es capaz de comprender con rigor.
Si una organización mide líneas generadas, tickets cerrados o número de pull requests, premiará el volumen. Pero una cola creciente de revisiones superficiales no es productividad; es riesgo pendiente de contabilizar.
La Agencia de la Unión Europea para la Ciberseguridad advierte en su guía de 2026 sobre gestores de paquetes de que delegar la selección de dependencias con poca revisión puede reducir la visibilidad sobre por qué se eligieron e introducir paquetes innecesarios, desactualizados o vulnerables. También recoge el riesgo de slopsquatting: atacantes que publican paquetes con nombres que los modelos tienden a inventar.
Por eso «las pruebas pasan» no basta. Un cambio generado debe responder, como mínimo, a cuatro preguntas:
- ¿Cumple el requisito correcto, no solo el caso feliz descrito en el prompt?
- ¿Respeta la arquitectura y los límites de seguridad del sistema?
- ¿Introduce dependencias, licencias o transferencias de datos nuevas?
- ¿Hay una persona capaz de mantenerlo sin reconstruir toda la conversación original?
Si la respuesta a la cuarta es no, el equipo ha aceptado código sin aceptar conocimiento.
Los cuatro argumentos que dividen a los desarrolladores
«La IA es solo otra herramienta, como el compilador»
En parte, sí. Un compilador también automatiza y nadie propone volver al ensamblador para demostrar pureza artesanal. La diferencia es que el compilador aplica reglas deterministas conocidas; un modelo propone decisiones plausibles, puede inventar hechos y varía con el contexto, la versión y el proveedor.
Tratar la IA como herramienta es sensato. Tratar su salida como la de un compilador es concederle una fiabilidad que no tiene.
«Si revisa un humano, el problema desaparece»
Depende de qué signifique revisar. Leer un diff de 800 líneas después de que todas las decisiones ya estén tomadas favorece el sesgo de automatización: buscamos confirmar que parece correcto. Una revisión soberana incluye dividir cambios, exigir pruebas independientes y pedir al responsable que explique las decisiones sin apoyarse en la respuesta del modelo.
«Prohibir la IA protege el oficio»
No. Prohibirla por principio puede ser tan irresponsable como adoptarla sin control. Renunciar a automatizar documentación, pruebas repetitivas, migraciones mecánicas o exploración de código desperdicia capacidad competitiva. El ingenio humano no se preserva haciendo trabajo que una máquina resuelve bien, sino reservándolo para definir problemas, elegir compromisos y asumir consecuencias.
«El programador del futuro solo necesitará saber pedir»
Pedir bien ayuda, pero no sustituye saber juzgar. Un prompt puede producir una respuesta convincente sin que quien lo escribió tenga criterio para detectar que la arquitectura es frágil, la consulta escala mal o la autorización está rota. La habilidad escasa no será generar código; será distinguir rápidamente el código defendible del código simplemente verosímil.
Cómo usar IA sin entregar las llaves del producto
La política útil no cuenta porcentajes de código «humano» o «artificial». Define dónde puede actuar la IA, qué evidencia debe acompañar sus cambios y quién responde por ellos.
| Zona | Ejemplos | Autonomía razonable |
|---|---|---|
| Verde | Formato, documentación, pruebas repetitivas, boilerplate | Generación amplia con controles automáticos |
| Ámbar | Lógica de negocio común, consultas, integraciones | Propuesta de IA y revisión humana explícita |
| Roja | Autenticación, pagos, datos sensibles, borrados, criptografía | Diseño humano, cambios pequeños y validación reforzada |
Un marco mínimo de soberanía puede resumirse en siete reglas:
- Un humano firma cada cambio. No como trámite, sino como responsable capaz de explicarlo.
- El contexto importante se versiona. Requisitos, ADR, contratos, restricciones y criterios de aceptación viven junto al código.
- La IA atraviesa los mismos controles. Lint, análisis estático, pruebas, revisión, escaneo de dependencias y despliegue gradual no se relajan porque el cambio llegue más deprisa.
- Los secretos no entran en prompts. Código confidencial, datos personales y credenciales se tratan según la política y el contrato del proveedor, no según la comodidad del momento.
- Las dependencias requieren justificación. Nombre, versión, licencia, necesidad y alternativa deben poder auditarse.
- Se ensaya la salida. El equipo prueba periódicamente si puede cambiar de modelo o trabajar sin él en una incidencia crítica.
- Se mide el ciclo completo. Tiempo hasta producción, revisión, defectos, retrabajo e incidentes; no caracteres generados.
Esta disciplina encaja con una arquitectura deliberada. Elegir tecnologías documentadas y mantenibles —por ejemplo, al decidir si Next.js encaja en una web de empresa— importa más en la era de los agentes, no menos: la IA amplifica tanto una buena decisión como una mala.
Test rápido: ¿controlas tu código o solo lo alojas?
Responde sí o no:
- ¿Alguien puede explicar cada módulo crítico sin consultar el chat que lo generó?
- ¿Los requisitos y decisiones de arquitectura están versionados?
- ¿Sabes qué fragmentos o dependencias se incorporaron con asistencia de IA?
- ¿Puedes sustituir mañana el modelo sin perder contexto esencial?
- ¿Los cambios generados son pequeños y revisables?
- ¿La seguridad se valida con herramientas y personas independientes del generador?
- ¿Mides defectos y retrabajo además de velocidad?
- ¿Existe un responsable humano claro cuando el código falla?
De 7 a 8 sí: la IA es una palanca bajo control. De 4 a 6: hay productividad, pero también dependencia creciente. De 0 a 3: no has automatizado el desarrollo; has externalizado el criterio.
Preguntas frecuentes sobre IA y programadores
¿La IA va a sustituir a los programadores?
Sustituirá tareas y reducirá el valor de escribir código rutinario, pero aumenta la necesidad de definir requisitos, diseñar sistemas, validar seguridad y responder por decisiones. El puesto cambia antes de desaparecer: menos mecanografía, más juicio técnico.
¿Quién es dueño del código generado por IA?
Depende de la aportación humana, los contratos, la jurisdicción y los posibles derechos de terceros. En España, la protección del software parte de la originalidad y de una autoría humana o de los supuestos legales de titularidad empresarial. Para un caso concreto hace falta asesoramiento jurídico.
¿Es seguro programar con IA?
Puede serlo si se limita el acceso a datos, se revisa el código, se controlan dependencias y se mantienen pruebas y análisis de seguridad. No es seguro asumir que una salida plausible es correcta porque compila o supera unos pocos tests.
¿Qué tareas conviene delegar primero?
Las de bajo impacto y fácil verificación: documentación, generación de casos de prueba, transformaciones mecánicas, prototipos desechables y código repetitivo. La autonomía debería reducirse a medida que aumentan el daño potencial y la dificultad de detectar errores.
La guerra no es contra la IA
La IA no tiene que perder para que gane el ingenio humano. Tiene que ocupar el lugar correcto.
El equipo soberano no presume de escribirlo todo a mano. Usa agentes para explorar, proponer y acelerar, pero mantiene dentro de la organización las decisiones, la evidencia y la capacidad de salida. Puede apagar una herramienta sin apagar su producto.
La auténtica derrota no llegará cuando una máquina escriba el 90 % del código. Llegará cuando una empresa confunda ese porcentaje con productividad y descubra, durante una incidencia, que nadie puede defender lo que ha desplegado.
Así que la pregunta queda abierta: si la IA escribió el código, un humano lo aprobó y ninguno puede explicarlo seis meses después, de quién era realmente?
Si estás replanteando cómo integrar IA en tu producto sin convertir la velocidad en deuda técnica, cuéntanos el contexto de tu proyecto. Antes de elegir una herramienta, merece la pena decidir qué control no estás dispuesto a ceder.
Fuentes y lecturas para discrepar
- Stack Overflow, Developer Survey 2025: Artificial Intelligence, 2025.
- Becker, Rush, Barnes y Rein (METR), Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, julio de 2025.
- METR, We are Changing our Developer Productivity Experiment Design, febrero de 2026.
- GitHub, Does GitHub Copilot improve code quality?, actualizado en febrero de 2025.
- GitHub y Accenture, Research: Quantifying GitHub Copilot's impact in the enterprise, mayo de 2024.
- Boletín Oficial del Estado, Ley de Propiedad Intelectual, artículos 96 a 100.
- Unión Europea, Reglamento (UE) 2024/1689 de Inteligencia Artificial.
- U.S. Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability, enero de 2025.
- ENISA, Technical Advisory for the Secure Use of Package Managers, marzo de 2026.
¿Necesitas una web que funcione
de verdad?
Cuéntanos tu proyecto. Te decimos si podemos ayudarte y cómo, sin compromiso.
