¿Se puede confiar en el código escrito por IA?

La idea de dejar que una herramienta de IA monte la web provoca la misma reacción en cualquiera que sepa leer código: ¿esto está bien por dentro? La preocupación es legítima, y despacharla con «los modelos ya son muy buenos» no es una respuesta. Contemos los riesgos uno a uno y veamos después de dónde vienen, porque el problema real no es lo listo que sea el modelo, sino cuánto espacio se le dio.

Los riesgos reales

• Alucinación: llamar a una función o a un paquete que no existe
• Seguridad: entrada sin validar, una clave expuesta, una autorización mal puesta
• Incoherencia: resolver el mismo problema de dos maneras distintas en dos páginas
• Deuda de mantenimiento: código que funciona, que nadie entiende y que nadie se atreve a tocar
• Regresión silenciosa: arreglar una cosa y romper otra

Ni un solo punto de esa lista es exagerado. Cualquiera que haya trabajado con generación desde página en blanco se ha topado con al menos tres. ¿Significa eso que la IA no sabe escribir código? No: vuelve a mirar la lista, porque cada punto es un subproducto de los grados de libertad.

El riesgo viene de la página en blanco, no del modelo

Cuando le dices a un modelo «hazme la web de un restaurante», le estás pidiendo que tome miles de decisiones a la vez: estructura de carpetas, arquitectura de componentes, enfoque de estilos, gestión del estado, puntos de ruptura, accesibilidad, comportamiento de los formularios. Cada decisión es una apuesta. Aunque acierte noventa y cinco de cada cien, las cinco restantes se quedan dentro de la web como pequeños temporizadores repartidos por ella.

Y esas decisiones se atan entre sí. Al escribir la segunda página tiene que recordar exactamente qué hizo en la primera; si no lo hace, empieza la incoherencia. Por eso justamente la generación desde cero se comporta como se comporta: el primer resultado es excelente y para la tercera página se desmorona.

Una plantilla estrecha la apuesta

De aquí sale el enfoque de partir de plantilla. La plantilla resuelve la estructura de carpetas, la arquitectura de componentes, el sistema de estilos y los puntos de ruptura por anticipado y a mano humana. A la IA le queda rellenar huecos conocidos dentro de ese esqueleto y hacer el cambio que pediste en el archivo correcto.

La diferencia: el modelo ya no es el arquitecto, es el oficial de obra. Cuando las decisiones arquitectónicas están fijadas, se encoge la superficie a la que puede agarrarse una alucinación. La probabilidad de «llamar a un componente que no existe» baja cuando la lista de componentes es fija. La de «dos soluciones distintas en dos páginas» baja cuando la solución ya está definida en la plantilla.

El código escrito por IA no es peligroso; el código escrito por IA sin límites sí. La pregunta no es cuán bueno es el modelo, sino cuán ancho es el espacio por el que le dejas moverse.

Dos preguntas distintas

La discusión sobre la confianza suele atascarse en la primera pregunta: ¿sabe el modelo escribir código correcto? Pero la preocupación real de un diseñador es la segunda: ¿voy a poder hacerme cargo de este código dentro de seis meses?

Son cosas muy distintas. Un código correcto pero ilegible puede ser más peligroso que uno incorrecto, porque funciona, así que nadie lo mira, y cuando por fin hay que tocarlo nadie se atreve. En software a eso lo llaman deuda técnica, y la IA puede producirla a un ritmo nunca visto. Cinco veces más código por hora son cinco veces más deuda por hora, salvo que seas tú quien decide la forma de ese código.

La diferencia entre «funciona» y «está bien»

Lo insidioso del código escrito por IA es que, cuando está mal, no suele estallar. El código que se rompe se nota; el que está silenciosamente mal, no. El formulario parece enviarse pero el correo nunca llega. La imagen carga pero pesa cuatro megas. La página abre pero no se puede recorrer con un lector de pantalla.

Así que «¿funciona?» es la pregunta equivocada. La correcta es: ¿he mirado de verdad qué ha pasado? Como diseñador ya haces esto; la IA no hace innecesario el hábito, lo hace más necesario. Como no escribiste el código, ya no puedes dar por supuesto lo que hay dentro.

¿Y si algo se rompe?

La confianza real no viene de no equivocarse nunca; viene de poder deshacer el error. La pregunta no es «¿el modelo se equivoca alguna vez?»: se equivoca. La pregunta es cuánto tardo en volver atrás cuando ocurre.

Elijas la herramienta que elijas, hazle esa pregunta. ¿Cada cambio existe como una versión a la que se puede volver? ¿La web publicada se queda intacta hasta que tú apruebas? Esto es menos una funcionalidad técnica que una filosofía de diseño: no deberías tener que confiar en el modelo, deberías poder confiar en el botón de deshacer. Si una herramienta no tiene respuesta aquí, no pongas trabajo de cliente encima.

Dependencia: la otra pregunta que conviene hacer

El lado poco comentado del asunto de la confianza es depender no del código sino de la herramienta. Una plataforma que hoy te gusta puede cambiar de precios mañana, cambiar de rumbo o cerrar. Si la web de tu cliente vive ahí, ese riesgo es tuyo.

Así que hazle a cada herramienta que evalúes una pregunta: ¿puedo irme? ¿Puedo llevarme mis archivos, el dominio es mío, mi contenido queda secuestrado? Si la respuesta no está clara, la discusión sobre la calidad del código sobra.

¿De quién es la responsabilidad?

Debajo del debate técnico hay una pregunta práctica: si algo sale mal, ¿quién responde? La respuesta es incómoda pero clara: tú. Tu cliente no va a llamar al proveedor del modelo ni a la plataforma; te va a llamar a ti. Tú elegiste la herramienta y tú entregaste el trabajo.

No es un argumento contra usar IA. Siempre fue así: cuando un plugin que instalaste resultó tener un agujero de seguridad, la factura te llegó a ti. Lo único que ha cambiado es que la velocidad de producción puede adelantar a la velocidad de supervisión. Si produces cinco veces más rápido, tienes que apretar tus hábitos de comprobación en la misma proporción; si no, la velocidad se pone por delante del control.

Mantén el control de todos modos

Ninguna arquitectura sustituye a la revisión. Uses la herramienta que uses, conserva estos hábitos:

• Mira el cambio primero en una vista previa, no en la web publicada
• Pide una cosa por instrucción; las peticiones agrupadas producen efectos secundarios que se te escaparán
• Prueba siempre tú mismo los formularios y las vías de contacto
• Recorre la web en el móvil antes de entregarla: el desbordamiento que no ves en el ordenador está ahí
• «Funciona» y «está bien» no son lo mismo: mide velocidad y accesibilidad

Son los hábitos de un buen diseñador de todas formas. La IA no los hace innecesarios: libera el tiempo para poder cumplirlos.

¿Y si no sabes leer código?

Una pregunta honesta merece una respuesta honesta: si no sabes leer código, lo que te protege no puede ser tu capacidad de revisión. Tienen que ser los límites de la herramienta. Y eso revela la distinción real entre dos categorías de herramienta.

Con un generador desde página en blanco, tu seguridad depende de poder juzgar el resultado. Si no puedes juzgarlo, estás apostando y ni siquiera sabes si has ganado. Con una herramienta basada en plantilla, la arquitectura la construyeron personas y la superficie que el modelo puede tocar es estrecha. Para quien no sabe leer código, la diferencia de riesgo entre las dos es enorme.

Así que «no hace falta que sepas programar» es una frase honesta solo sobre la arquitectura adecuada. Dicha sobre una página en blanco significa en realidad «no hace falta que sepas qué estás aceptando», y eso no es un consejo, es un deseo.

¿Qué le dices al cliente?

Antes o después un cliente corporativo preguntará: «¿esta web la ha hecho una IA?». No te pongas a la defensiva. La respuesta verdadera ya es fuerte: la arquitectura la construyeron diseñadores humanos, la IA trabajó dentro de ella, yo revisé lo que salió y la responsabilidad es mía.

Esa frase hace tres cosas a la vez: es honesta, es técnicamente exacta y responde a la pregunta real del cliente. Porque no está preguntando por la herramienta: está preguntando «si algo sale mal, ¿a quién llamo?». Mientras esa persona seas tú, la herramienta no le importa a nadie.

En resumen: la pregunta no es «¿sabe la IA escribir código?», porque sabe. La pregunta es cuán ancho es el espacio por el que la dejas moverse. A medida que el espacio se estrecha, sube la confianza. Ese es el argumento para trabajar encima de una plantilla probada: la confianza se deposita en la arquitectura y no en la inteligencia.