Diseño de software AI-first desde primeros principios: guía para quien construye

La mayoría de los equipos adoptó la IA sin revisar un solo supuesto de los que había debajo, y por eso el resultado se volvió más rápido y los sistemas peores.

Esta es la pregunta que la mayoría de los equipos de ingeniería todavía no ha dicho en voz alta: si el modelo puede escribir el código, ¿en qué se supone exactamente que tenemos que ser buenos ahora?

Las respuestas que oigo son mayoritariamente defensivas. Ingeniería de prompts. Revisar la salida de la IA. Saber a qué herramienta recurrir. Todas habilidades reales, todas consecuencia del cambio de fondo, y ninguna explica lo que veo una y otra vez en la práctica: equipos que adoptaron las mismas herramientas, en el mismo trimestre, con los mismos modelos, acabando en lugares completamente distintos. Un grupo lanza más rápido y el software aguanta. El otro lanza más rápido y pasa el trimestre siguiente averiguando qué rompió.

Las mismas herramientas. Resultados opuestos. Esa diferencia no viene del modelo.

El amplificador que nadie contabilizó

El informe State of AI-assisted Software Development de DORA de 2025 puso números a esto. El 90% de los profesionales de tecnología usa ya IA en el trabajo, y más del 80% cree que ha aumentado su productividad. Las dos cosas no sorprenden. El hallazgo que importa es el tercero: una mayor adopción de IA se asocia con un aumento del rendimiento de entrega de software y con un aumento de la inestabilidad de esa entrega, al mismo tiempo.

Léelo otra vez, porque es todo el argumento. La herramienta hizo a los equipos más rápidos lanzando y peores manteniendo las cosas funcionando. No una cosa o la otra. Las dos.

El encuadre de DORA es que la IA es un amplificador: magnifica cualquier práctica sobre la que aterrice. Los sistemas fuertes se hacen más fuertes. Los sistemas débiles se vuelven más rápidos en ser débiles.

Lo que significa que la pregunta interesante nunca fue “cómo adoptamos la IA”. Era “qué amplifica la IA en nosotros”. Y responder eso exige retroceder más atrás que cualquier decisión de herramienta.

Razona desde el problema, no desde la herramienta

Pensar desde primeros principios es una de esas frases que se ha repetido hasta perder el sentido, así que voy a ser concreto sobre qué quiero decir con ella y qué no.

Razonar por analogía es a lo que se pareció la mayor parte de la adopción de IA. Teníamos un flujo de trabajo de desarrollo. Llegó una capacidad nueva. Preguntamos dónde encaja la capacidad en el flujo, la añadimos en el punto de menor resistencia (normalmente la escritura de código) y dejamos todo lo demás igual. Reuniones diarias, tickets, sprints, revisión, todo preservado. El flujo se trató como un dato y la herramienta se ajustó a él.

Razonar desde primeros principios plantea una pregunta más dura. Reduce el proceso a lo que es realmente, físicamente cierto sobre construir software. Después pregunta cuáles de esas verdades cambió el modelo y cuáles no tocó. Reconstruye desde lo que sobrevive.

Haz eso con honestidad y descubres que la IA cambió exactamente una cosa, y no es la que la categoría ha estado vendiendo.

El coste de producir código se fue casi a cero. El coste de decidir cuál debería ser el código no se movió.

Todo lo útil se desprende de esa única asimetría. Abajo están las cuatro consecuencias que querría que cualquiera que construya pudiera enunciar de memoria.

Uno: el modelo de datos es el producto

La pantalla es la parte más volátil de cualquier aplicación y el lugar más tentador por donde empezar, porque es la parte que se puede ver. Es también la parte que debería ser la más barata de tirar.

El modelo de datos es lo contrario. Decide qué puedes preguntar, qué puedes indexar, qué puedes cambiar después sin una migración que asuste a todo el mundo. Toda capacidad posterior está limitada por decisiones tomadas, o improvisadas, en esa capa.

Cuando el código era caro, este orden se imponía solo. Nadie escribía a mano cien pantallas contra un esquema que no había pensado, porque escribir a mano cien pantallas llevaba un trimestre. La generación eliminó esa barrera natural. Ahora puedes producir una interfaz entera contra un modelo de datos que ninguna persona revisó nunca, y parecerá terminada.

Así que el orden tiene que volverse deliberado. Modelo primero, después contrato, después interfaz. No porque sea lo tradicional, sino porque es el único orden en el que las decisiones caras se toman mientras todavía son baratas de cambiar.

Dos: una decisión aplazada se toma igualmente

Esta es la que más se infravalora.

Toda decisión que no tomas explícitamente se toma igual. La toma el generador, en el momento de generar, a partir de un contexto que no incluye tu negocio, tu superficie de cumplimiento normativo, tu historial de migraciones ni tus planes para el próximo trimestre. El modelo no se niega a decidir. Elige algo plausible y sigue.

¿Qué puede seguir viendo un usuario con la suscripción cancelada? ¿Qué pasa cuando dos personas editan el mismo registro? ¿Es única una dirección de correo, y única respecto a qué? Nadie hizo esas preguntas en un prompt, así que nadie las respondió, y la aplicación tiene ahora una respuesta a las tres, elegida por inferencia, descubrible solo al chocar con ella en producción.

Este es el mecanismo detrás de lo que las comunidades de constructores bautizaron como el problema del 70%. El progreso se estanca no porque el trabajo restante sea difícil, sino porque está bloqueado por decisiones que se tomaron en silencio, varios cientos de generaciones antes, y que ya no se pueden cambiar sin desarmarlo todo.

La práctica que arregla esto ya tiene nombre: desarrollo guiado por especificación. Escribe primero los requisitos, las restricciones y los criterios de éxito. Trata ese documento como la fuente de verdad. Deja que el agente construya contra él. GitHub publicó Spec Kit, AWS publicó Kiro, y la convergencia no es casualidad.

Tres: cuando generar es gratis, las restricciones hay que escribirlas

Durante décadas, la corrección la sostenía en parte el coste de escribir código. Quien implementaba una regla tenía que sostener la regla en la cabeza. El conocimiento tácito en una cabeza humana era un lugar aceptable para almacenar una restricción, porque siempre había una persona en el circuito.

Ese lugar de almacenamiento ya no funciona. Si una restricción no está expresada en algún sitio legible por máquinas (una restricción de esquema, un tipo, una regla de validación, una prueba, una línea explícita en una especificación) no existe en lo que concierne al generador. Existe solo en la memoria de quien está a punto de sorprenderse.

Este es el núcleo práctico del diseño AI-first, y no tiene ningún glamour. Empuja los invariantes hacia abajo, a la capa que puede hacerlos cumplir. Not-null y unique en la base de datos, no en un manejador de formulario. Tipos en los límites, no en un comentario de código. Autorización como una política que el sistema evalúa, no como una condición que alguien se acordó de escribir en un endpoint.

Cada restricción que externalizas es una decisión que el modelo ya no puede equivocar.

Cuatro: ahora construyes para dos consumidores

La última es la más nueva, y la que la mayoría de los equipos no ha interiorizado en absoluto.

Tu aplicación tiene ahora dos tipos de usuario. Uno es una persona mirando una pantalla. El otro es un agente llamando a una API, que nunca ve tu interfaz y al que no se puede persuadir con buen diseño. Si una capacidad existe en tu interfaz pero no en tu API, entonces, en lo que concierne a la economía de los agentes, no existe.

Eso tiene una consecuencia de diseño: la paridad no es un extra deseable. Cualquier cosa que una persona pueda hacer a través de la interfaz debería ser alcanzable a través de una superficie definida, documentada y descubrible. Que es también por lo que GraphQL ha encajado mejor que REST para el consumo por agentes: un esquema autodescriptivo es algo que una máquina puede explorar sin que una persona escriba antes notas de integración.

Construye para el agente y la interfaz humana se simplifica como efecto secundario. Construye solo para la persona y acabarás retroencajando una API bajo presión de plazos, que es el peor momento posible para diseñar una.

Cómo se ve saltarse esto en los datos

GitClear analizó 623 millones de cambios de código entre 2023 y 2026, y la imagen de mantenibilidad es consistente con todo lo anterior.

Contra la línea base de 2023, los bloques de código duplicados están un 81% arriba. El copiar y pegar dentro de un mismo commit subió del 9,4% en 2022 al 15,7% en la primera mitad de 2026. Las construcciones que enmascaran errores están un 47% arriba. Mientras tanto, las llamadas a funciones entre archivos (la señal más clara disponible de reutilización de código) están un 35% abajo, y la actividad de refactorización se desplomó del 21% de los cambios en 2022 al 3,8% en lo que va de 2026.

Quienes desarrollan tienen ahora unas cinco veces más probabilidades de copiar y pegar que de refactorizar. En 2022 esa proporción iba en el sentido contrario.

Nada de eso es un problema de calidad del modelo. Duplicación en lugar de reutilización, gestión de errores que se los traga en lugar de sacarlos a la superficie, refactorización que deja de ocurrir: eso es lo que obtienes cuando generar es barato y la estructura no es el trabajo explícito de nadie. El resultado es localmente plausible y globalmente incoherente, que es precisamente el modo de fallo que un flujo que empieza por la pantalla no puede detectar.

Cómo trabajar así, empezando esta semana

Nada de esto requiere una reorganización. Requiere cambiar el orden de cuatro o cinco hábitos.

1. Escribe el modelo de datos antes de la primera pantalla. Entidades, relaciones, cardinalidad, qué hace única a una fila, qué se propaga al borrar. Una hora aquí es la hora de mayor apalancamiento del proyecto, y es la que las herramientas te invitan activamente a saltarte.
2. Haz que la especificación sea el artefacto que revisas, no el diff. Si la especificación es correcta y la generación es fiel a ella, revisar miles de líneas de código generado es teatro. Revisa el documento que las produjo. Discute sobre la especificación mientras discutir sigue siendo barato.
3. Externaliza toda restricción que puedas nombrar. Antes de generar, lista las reglas que nunca deben violarse y pon cada una en algún sitio donde el sistema la haga cumplir. Todo lo que se quede en una conversación acabará siendo violado por algo que nunca participó en esa conversación.
4. Diseña la API como la superficie del producto. Después trata la interfaz humana como uno de sus consumidores. Esto es más una decisión de secuencia que de ingeniería, y secuenciarlo tarde es lo que lo hace caro.
5. Instrumenta para la inestabilidad, no solo para el rendimiento. El hallazgo de DORA es que la velocidad y la fragilidad subieron juntas, así que medir solo la velocidad te mostrará la mitad buena de tu propia tendencia. La tasa de fallos por cambio y el tiempo de restauración son los números que te dicen si el amplificador está trabajando a tu favor.

Qué cuesta esto

Quiero ser directo sobre el compromiso en lugar de pretender que no existe.

Trabajar así es más lento durante la primera semana de un proyecto y sensiblemente más rápido en todas las semanas siguientes. Ese es un coste real, pagado por adelantado, exactamente en el momento en que el impulso parece más valioso y un competidor está lanzando algo visible. Habrá sprints en los que el equipo que se saltó todo esto parezca ir ganando.

Tampoco es gratis en disciplina. Escribir restricciones es menos divertido que ver aparecer una interfaz. Revisar una especificación es menos satisfactorio que revisar código. Estos hábitos se degradan bajo presión de plazos, que es la misma presión que los hace importar.

Y parte de esto genuinamente no aplica. Si estás validando una idea este fin de semana con intención de tirar el resultado, tíralo: nada de lo anterior merece la pena para software con dos días de vida. El argumento aquí es sobre las aplicaciones que sobreviven a su demo.

La parte que nunca fue automatizable

Algunos roles construidos alrededor de la producción de código se encogerán. Algunos desaparecerán. Pretender lo contrario no ayuda a nadie a prepararse, y quienes te dicen que todo puesto de ingeniería está a salvo no te están haciendo ningún favor.

Pero mira qué hizo realmente la asimetría. Automatizó la expresión de las decisiones y dejó las decisiones en sí completamente intactas. Qué construir. Qué no construir. Qué invariantes se sostienen. Qué no debe hacer nunca el sistema. Dónde están los límites y a quién se le permite cruzarlos.

Ese trabajo siempre fue la parte difícil. Solo estaba escondido debajo de la labor de teclear, que era lo bastante caro como para parecer el trabajo.

Teclear nunca fue el trabajo.

Lecturas relacionadas

La práctica en profundidad: desarrollo guiado por especificación. Si estás eligiendo una herramienta: los mejores constructores de aplicaciones con IA en 2026.

Preguntas frecuentes

¿Qué significa “diseño de software AI-first”? Diseñar una aplicación partiendo del supuesto de que la mayor parte del código se generará en lugar de escribirse a mano, y de que algunos consumidores serán agentes en lugar de personas. En la práctica significa que el modelo de datos, las restricciones y el contrato de la API se definen explícitamente de antemano, porque esas son las decisiones que la generación no puede tomar por ti.

¿En qué se diferencia el diseño AI-first de simplemente usar herramientas de IA para programar? Usar herramientas de IA añade una capacidad a un flujo de trabajo sin cambiar. El diseño AI-first cambia el orden de las operaciones del flujo: modelo y contrato antes de la interfaz, especificación como artefacto revisado, restricciones empujadas a capas que las hagan cumplir. La investigación de DORA de 2025 encontró que la adopción de IA elevó a la vez el rendimiento y la inestabilidad, que es lo que pasa cuando cambia la herramienta pero no la práctica.

¿Cuáles son los primeros principios del diseño de software en la era de la IA? Cuatro se sostienen: el modelo de datos es el producto y la pantalla es una vista de él; cualquier decisión que no tomes explícitamente la toma el generador de forma implícita; las restricciones deben vivir en algún sitio que las pueda hacer cumplir una máquina y no en la cabeza de alguien; y tu aplicación sirve ahora tanto a una interfaz humana como a una API de cara a agentes, que necesitan paridad.

¿Diseñar así frena a los equipos? Adelanta el trabajo en lugar de añadirlo. Las decisiones capturadas en un modelo de datos y en una especificación son decisiones que alguien toma de todas formas: o deliberadamente al principio o de forma implícita por un modelo que adivina después. El segundo camino es de donde viene el retrabajo, y el retrabajo no es más rápido.

¿El desarrollo guiado por especificación es lo mismo que el diseño AI-first? El desarrollo guiado por especificación es la práctica; el diseño AI-first es el conjunto más amplio de consecuencias arquitectónicas. La primera cubre escribir la especificación y generar contra ella. El diseño AI-first cubre además el orden del modelado de datos, dónde se hacen cumplir las restricciones y diseñar para consumidores agénticos además de humanos.

¿Cuándo está bien saltarse todo esto? Prototipos, demos, cosas internas de una sola vez y cualquier cosa que planees descartar. La sobrecarga solo merece la pena para software que tiene que sobrevivir a usuarios reales, datos reales y cambios en el tiempo.