Resumen. Usamos la IA para escribir buena parte de nuestro código, y es una decisión deliberada, no un atajo. La razón es simple: un agente es rápido produciendo código y malo haciéndose cargo de un sistema. Así que dejamos que él teclee y movemos a nuestros ingenieros hacia arriba: a la arquitectura, a la flexibilidad, a las decisiones de sistema completo que deciden si una base de código seguirá siendo agradable de cambiar dentro de un año. El sector se puso al día con esto en 2026: el 84 % de los desarrolladores usa ya herramientas de IA a diario, y el patrón ganador es «genera con ambición, verifica con rigor». La trampa es que la IA optimiza cada archivo localmente y nadie optimiza la base de código globalmente, que es justo por lo que las bases de código que auditamos se rompen todas de las mismas seis maneras. Nuestra respuesta es mantener a una persona en la parte que la IA no puede ver: la arquitectura. Así construimos, y por qué.

El trabajo cambió, y nosotros cambiamos con él

Durante casi toda la historia del software, el cuello de botella era teclear. Convertir una idea clara en código funcionando era la parte lenta y cara, así que ahí iba el esfuerzo de ingeniería y ahí se medía la seniority.

Ese cuello de botella ha desaparecido. Como recoge el estado del mundo del desarrollo de junio de 2026, las herramientas de programación con IA han pasado de curiosidad a línea base: el 84 % de los desarrolladores recurre a ellas cada día, TypeScript adelantó a Python como lenguaje más usado en parte porque el código tipado mantiene honesta a la IA, y los ingenieros más productivos ya no escriben más código a mano, sino que orquestan agentes que lo hacen. El «ingeniero 10x» se convirtió en gestor de máquinas.

No nos resistimos a esto; nos reorganizamos en torno a ello. Si un agente puede producir una funcionalidad que funciona en minutos, entonces la habilidad humana escasa y valiosa ya no es «¿sabes escribir esta función?». Es «¿debería existir esta función, dónde encaja, qué pasa cuando cambien los requisitos y cómo se comporta cuando diez mil personas la usan a la vez?». Esas son preguntas de arquitectura y de flexibilidad. Son precisamente las preguntas en las que la IA es peor, y las que deciden si un producto vive o muere.

La línea base de 2026, en cuatro números:

  • El 84 % usa IA a diario. Las herramientas de programación con IA son ahora la línea base, no un extra opcional.
  • El 46 % desconfía, el 3 % confía mucho. Muchos más desarrolladores desconfían de la salida de la IA de los que confían, y por eso la verificación no es opcional.
  • Lo multiagente es lo normal. Los ingenieros más productivos dirigen flotas de agentes en vez de escribir más código a mano.
  • TypeScript es el número 1. Los lenguajes tipados adelantaron a Python en parte porque mantienen honesto al código generado.

Qué le damos a la IA y qué nos guardamos

La forma más clara de describir nuestro proceso es partir el trabajo en dos: la parte que delegamos en máquinas y la parte que nos negamos a delegar.

Le damos a la IA las pulsaciones. Código repetitivo, endpoints CRUD, la décima variación de un formulario, el pegamento que mueve datos, primeros borradores de tests, migraciones, las transformaciones mecánicas y tediosas que antes se comían tardes enteras: los agentes son genuinamente excelentes en todo eso. Un modelo escribe una implementación de aspecto correcto más rápido de lo que una persona tarda en describirla. Así que le dejamos. En 2026 no hay orgullo alguno en teclear a mano una vista de lista paginada.

Nos guardamos la arquitectura. ¿Dónde vive el estado? ¿Cuál es la única fuente de verdad de este dominio? ¿Qué fronteras pueden saber de cuáles otras? ¿Cómo escala esto de una instancia a doce? ¿Cuál es el modo de fallo cuando el proveedor de pagos da timeout? ¿Cómo se doblará esta forma cuando el cliente pida, dentro de tres meses, aquello que jura que nunca pedirá? Ninguna de esas tiene una respuesta de «camino más corto hasta código que funcione», y el camino más corto hasta código que funcione es lo único que optimiza un agente.

Esta división no es un compromiso. Es el uso de mayor palanca para ambas partes. La máquina hace aquello en lo que es rápida; las personas hacen aquello que por ahora solo las personas hacen bien. La frase que circula por el sector —«Codex para las pulsaciones, Claude Code para los commits»— es en realidad una afirmación sobre altitud: cuanto más te acercas a una decisión de la que depende todo el sistema, más pertenece una persona al circuito.

Por qué la arquitectura tiene que seguir siendo humana

Aquí está la verdad incómoda que vemos cada semana, y es el motor de todo lo que acabamos de describir.

Hacemos auditorías de código sobre un flujo constante de aplicaciones construidas con IA. Las bases de código son tremendamente distintas, pero los hallazgos casi nunca lo son: sin tests, el mismo helper duplicado cuatro veces con ligeras derivas, dos pantallas del mismo proyecto escritas como si las hubieran hecho dos equipos distintos, estado complejo colapsado en un infierno de callbacks, código que asume una sola máquina y se corrompe en cuanto corre en dos, secretos subidos directamente al repositorio. Seis problemas, una y otra vez.

Todos ellos son propiedades de sistema completo. Ninguno puede producirlo un solo buen prompt, porque ningún prompt aislado ve el conjunto. Un modelo generando código tiene una ventana de contexto estrecha y ninguna memoria de la decisión que tomó tres archivos atrás. Toma la decisión localmente óptima cada vez, y la suma de decisiones localmente óptimas es una base de código que funciona hoy y se resiste a todo cambio mañana. La deriva no es un fallo de ninguna generación concreta; es la forma inevitable de generar sin un dueño global.

Así que el papel del humano no se encogió cuando la IA empezó a escribir código. Se movió: de producir líneas a garantizar las propiedades que solo existen entre líneas. Arquitectura coherente, una única fuente de verdad, estado modelado como estado en vez de un montón de callbacks compitiendo, conciencia del entorno real de despliegue, seguridad activada por defecto. Ese es el tejido conectivo. Es la diferencia entre una demo y un producto, y un agente a solas se lo salta todo. No se lo permitimos.

Genera y verifica: cómo mantenemos seguro el código de la IA

Hay una brecha de confianza real en los datos y nos la tomamos en serio: en todo el sector, el 46 % de los desarrolladores desconfía activamente de la salida de la IA y solo el 3 % confía mucho. La respuesta madura no es dejar de usar IA, es tratar todo lo que produce como código de terceros no confiable hasta que se demuestre lo contrario. Genera con ambición; verifica con rigor.

En la práctica eso significa que cada línea que escribe un agente pasa por la misma puerta que pasaría la pull request de un colaborador externo:

  • La lee una persona, no la ojea. La trampa de confianza del código de IA es que parece terminado, así que el 20 % que no lo está es invisible. Leemos buscando las cosas que los modelos hacen mal de forma fiable: autorización ausente detrás de una pantalla de login, entrada concatenada directamente en una consulta, un endpoint que devuelve el objeto de usuario entero cuando la interfaz solo necesitaba un nombre.
  • Recibe tests, a propósito. Generar una funcionalidad y generar tests para ella son dos peticiones distintas, y la segunda rara vez ocurre sola. Hacemos que ocurra: un test de humo de que la app arranca, cobertura real alrededor del dinero y la autenticación, y un test de regresión por cada bug que arreglamos.
  • Se mide contra la arquitectura, no solo contra «¿se ejecuta?». Una funcionalidad que funciona pero se inventa su propio patrón de estado, o duplica un helper existente, o cruza una frontera que no debería conocer, se devuelve, aunque pase su camino feliz.

Es la misma disciplina que describimos para fundadores que publican prototipos de IA en qué se rompe entre la demo y producción. La fórmula a la que volvemos siempre: la IA te lleva al 80 % del camino en el 5 % del tiempo, y el último 20 % es el producto entero. Dejamos que la IA sea dueña del 80 %. Nosotros somos dueños del 20 %.

Orquestar agentes en vez de escribir más código

El otro cambio que nombra el panorama de 2026 es el desarrollo multiagente: en lugar de un asistente, agentes especializados corriendo en paralelo —uno redactando la funcionalidad, otro escribiendo tests, otro revisando seguridad, otro haciendo la migración mecánica— con un ingeniero dirigiéndolo todo.

Así es como pasan el día nuestros ingenieros ahora. Menos tiempo dentro de una función concreta, más tiempo decidiendo qué deberían construir los agentes, en qué orden, contra qué interfaces, y después comprobando que lo que vuelve encaja en el sistema. Se parece menos a teclear y más a liderazgo técnico de un equipo muy rápido y muy literal que necesita dirección precisa y revisión cuidadosa. La palanca es enorme, pero solo si quien sostiene la orquesta tiene una partitura —una arquitectura— en la cabeza. Apunta una flota de agentes a una base de código sin espina dorsal y obtendrás los seis hallazgos de auditoría más deprisa.

La palanca corta por los dos lados

Los agentes amplifican la dirección que se les dé. Apuntados a una arquitectura clara, hacen crecer más rápido una base de código sólida. Apuntados a ninguna arquitectura, enredan más rápido una enredada. La persona que decide la dirección no es un coste añadido sobre la IA: es lo que decide si la IA es un acelerador o un alud.

La flexibilidad es de lo que va todo esto

Si hay una palabra para lo que estamos optimizando, no es velocidad —la velocidad ya es barata—. Es flexibilidad: la capacidad de absorber un cambio de requisitos sin una reescritura.

Aquí es donde más se nota el enfoque de arquitectura primero. Las bases de código construidas con IA que auditamos son rápidas de empezar y brutales de cambiar: se calcifican, no porque el código sea bueno y precioso, sino porque nadie se atreve a tocarlo sin tests, sin una estructura coherente, sin saber qué más se va a romper. Eso es lo contrario de flexible. Un producto que no puede cambiar está muerto el día que se mueve el mercado.

Cuando una persona es dueña de la arquitectura y la IA es dueña del tecleo, obtienes las dos mitades: la velocidad de la generación y un sistema que se dobla. Llega un requisito nuevo y hay una única fuente de verdad que actualizar en vez de cuatro copias que rastrear; un modelo de estado que extender en vez de un laberinto de callbacks que desenredar; una frontera clara que ampliar en vez de una conjetura sobre cuál de dos pantallas lo hace de la forma «correcta». Hicimos exactamente esto en Arcana, un cliente de chat con IA en streaming: el trabajo poco vistoso de acertar con la arquitectura, el streaming y el modelo de estado es lo que convirtió un prototipo rápido en algo que pudimos seguir evolucionando en vez de reconstruir.

Esa es la tesis entera: usamos IA para que nuestros ingenieros dejen de gastar sus mejores horas en pulsaciones y las gasten en las decisiones que mantienen flexible el software. El código es ahora la parte barata. La arquitectura es el producto.

Preguntas frecuentes

No, porque nunca tratamos la salida de la IA como algo terminado. Seguimos el patrón que el sector adoptó en 2026: generar con ambición y luego verificar con rigor. Cada línea que escribe un agente la revisa una persona como si fuera la pull request de un externo, recibe tests reales alrededor de las partes que importan y se comprueba contra la arquitectura del sistema antes de publicarse. La IA se encarga del tecleo; las personas garantizan la calidad. Usado así, el resultado es más rápido y al menos igual de sólido que el código escrito enteramente a mano, porque los ingenieros dedican su atención al diseño en lugar de al código repetitivo.
Se hacen cargo de todo aquello en lo que la IA es mala, que es casi todo lo que determina si el software dura: arquitectura, dónde vive el estado, la única fuente de verdad de cada dominio, cómo escala el sistema entre instancias, modos de fallo, postura de seguridad y flexibilidad para cambios futuros. También orquestan a los agentes, decidiendo qué se construye, en qué orden y contra qué interfaces, y verifican lo que vuelve. El trabajo humano se movió hacia arriba, de producir líneas a garantizar las propiedades de sistema completo que ningún prompt aislado puede producir.
Porque un modelo optimiza cada archivo hacia el camino más corto hasta código que se ejecute, y nadie está optimizando la base de código en su conjunto. El resultado es predecible: sin tests, lógica duplicada, sin arquitectura coherente, estado colapsado en un infierno de callbacks, código que se rompe en cuanto corre en más de una instancia y secretos subidos al repositorio. Vemos estos mismos seis problemas en casi toda base de código construida con IA que auditamos. Son fallos de sistema completo que no pueden emerger de prompt en prompt, así que una persona tiene que ser dueña de la arquitectura para que la IA sea segura.
Significa que pagas por criterio, no por pulsaciones. La generación es ahora la parte barata y rápida, así que el trabajo que lleva tiempo real es la arquitectura, la verificación y la flexibilidad para cambios futuros, que es exactamente el trabajo que protege tu inversión. En la práctica obtienes prototipos y funcionalidades mucho más rápido, sin heredar la base de código calcificada e inmodificable que suele dejar la generación pura con IA. Conservas la velocidad y conservas la capacidad de cambiar de rumbo después.
Casi siempre se puede salvar, y casi nunca hace falta reescribirla. Las funcionalidades funcionan y el producto es real; lo que falta es el tejido conectivo: tests, una arquitectura coherente, lógica sin duplicar, un modelo de estado en condiciones, conciencia del despliegue y seguridad. Todo eso puede añadirse en el sitio mucho más rápido y barato que reconstruir desde cero. Esa reparación enfocada es justo lo que entrega una auditoría de código IA: conservamos los cimientos que la IA hizo bien y arreglamos las partes de sistema completo que no pudo.

Construye rápido, mantente flexible

Los equipos que están ganando en 2026 no son los que rechazaron la IA, ni los que la dejaron correr sin supervisión. Son los que pusieron a la máquina en las pulsaciones y a una persona en la arquitectura. Así construimos cada proyecto: IA para la velocidad, ingenieros para las decisiones que mantienen el software lo bastante flexible como para sobrevivir a su propio éxito.

Si tienes una app construida con IA y no sabes si puede seguir evolucionando, pásala por una auditoría de código IA o reserva una evaluación gratuita. Te diremos dónde es sólida la arquitectura, dónde está a punto de morderte y qué hace falta para arreglarlo, con un presupuesto de alcance cerrado y no una conjetura.