¿Sustituirá la IA al desarrollador? Lo verdadero y lo falso

En LinkedIn, un debate vuelve cada semana. Por un lado: «Ninguna IA superará a un desarrollador que entiende el negocio, que rechaza una función inútil y que asume sus decisiones en producción. El código se genera; la decisión de escribirlo, no». Por otro, un comentario burlón: ya nadie lee el ensamblador, confiamos en el compilador; y un director no revisa el código de sus equipos, juzga lo que entra y lo que sale. Entonces, humanos o IA, ¿qué diferencia hay?

Ambos tienen razón en un punto. Y ambos fallan en el mismo.

En resumen

• Verdadero: la decisión de escribir código, el rechazo de una función inútil y la responsabilidad en producción siguen siendo humanos.
• Falso: la IA no es un compilador. No es determinista, y su código puede ser erróneo pareciendo correcto.
• Lo que cuesta ya no es escribir el código, sino verificarlo, y no en todas partes con la misma intensidad.
• La ganancia se elige: llegar más lejos con el mismo presupuesto, o arrancar más rápido y por menos.

Lo que es verdad

La decisión sigue siendo humana. Una IA produce quinientas líneas en treinta segundos. No se pregunta si esas líneas deben existir, si la función sirve realmente al negocio ni cuánto costará mantenerla. Es ese juicio lo que se paga, no el tecleo.

La dirección por resultados ya existía. El director técnico de un gran equipo no revisa cada línea. Juzga entregas, incidencias, plazos. Desde este punto de vista, que un equipo esté formado por desarrolladores o por agentes de IA cambia menos de lo que se dice: se dirige la entrada, la salida y los errores.

El terreno competitivo decide. Quien recorta su presupuesto porque «la IA programa» se queda estancado mientras su competidor mantiene el suyo y llega mucho más lejos.

Lo que es falso, o a medias

«Como con el ensamblador, acabaremos confiando». La comparación es seductora, pero no se sostiene. Un compilador es determinista: la misma entrada da siempre la misma salida, y décadas de pruebas lo han hecho fiable. Una IA da dos códigos distintos para la misma petición, y a veces un código erróneo que parece correcto. La confianza no vendrá de la costumbre, vendrá de las pruebas automáticas, los controles y las revisiones focalizadas.

«El equipo ya es una caja negra». Verdadero para la dirección, falso para la responsabilidad. Detrás de un equipo humano, alguien responde de una avería y sabe por qué se tomó tal decisión. Detrás de un agente, la responsabilidad recae en quienes lo conectaron, y la explicación de la decisión a menudo no existe en ninguna parte.

«Basta con conectarlo todo, la IA programa por ti». Las mediciones dicen otra cosa. En julio de 2025, un estudio controlado del laboratorio METR siguió a desarrolladores experimentados en sus propios proyectos: con la IA tardaron alrededor de un 19 % más, cuando creían haber ganado un 20 %. Las herramientas han progresado desde entonces, y el estudio solo abarcaba a dieciséis personas, pero recuerda algo: la impresión de velocidad no es velocidad.

Nuestra posición: revisar donde importa

¿Hay que revisar cada línea producida por una IA? No. Sería perder lo esencial de la ganancia. ¿Hay que no revisar ninguna? Tampoco. La respuesta correcta depende de la superficie de ataque.

Un sitio corporativo estático o headless no es genética. No tiene ni base de datos expuesta ni servidor de aplicaciones que piratear. Ahí entregamos código poco revisado, generado y luego probado, y en general sale bien: lo hacemos todos los días.

En cambio, el ojo humano sigue siendo obligatorio allí donde un error sale caro:

• la autenticación y los permisos: quién puede conectarse, quién ve qué;
• las conexiones con otras herramientas: API, webhooks, tokens de acceso;
• los secretos: una clave colada en el código enviado al navegador es pública;
• los formularios: validación de campos, antispam, datos personales y RGPD;
• el pago: importes, reembolsos, webhooks del proveedor;
• las dependencias: una biblioteca añadida por la IA, a veces desconocida o abandonada, es código de terceros que entra en su producto.

El detalle de los controles está en nuestro artículo sobre la seguridad de una aplicación, y la razón por la que un sitio estático expone tan poco, en el dedicado a la vulnerabilidad de PHP de octubre de 2026.

¿Más barato o más lejos?

Ya no estamos en 2025: las intervenciones humanas en un proyecto web han disminuido de verdad. Hay que elegir qué hacer con esa ganancia, y la respuesta depende de la situación de la empresa.

1. Llegar más lejos con el mismo presupuesto: más funciones, más pruebas, más mercados. Es la vía de quien lucha en un terreno competitivo.
2. Arrancar más rápido y por menos: un primer producto en línea en pocas semanas, para validar una idea antes de invertir más.

Proponemos ambas vías a nuestros clientes. Lo que no proponemos es la tercera, la que se oye demasiado: recortar el presupuesto y contar con la IA para hacer el mismo trabajo sin nadie que la dirija. Nuestro artículo sobre el vibe coding cuenta cómo terminan esos proyectos.

Nuestra opinión

Los «dinoprogramadores» se equivocan al creer que revisar cada línea protege su oficio. Los entusiastas se equivocan al creer que se puede conectar todo y no volver a mirar nada. El oficio se desplaza: menos escritura, más decisiones, arquitectura y verificación. Y lo que justifica el precio de un buen desarrollador no es el número de líneas que teclea. Es su capacidad para decir «estas no deben existir» y para saber cuáles revisar. Nuestro artículo sobre el papel humano frente a la IA profundiza en ese juicio.

Fuentes

1. Un estudio controlado del laboratorio METR (nueva pestaña)metr.org