Diseñar sistemas en diálogo con IA

10 min de lectura

El agente no es tu turno de noche

Las herramientas maduraron. La fantasía no.

En marzo de 2026, el desarrollo asistido por IA ya se había dividido claramente en varias familias.

Estaban los copilots integrados en el IDE, pegados al archivo, los agentes de terminal capaces de inspeccionar un repositorio y ejecutar comandos, y los agentes de mayor duración que podían trabajar a través de ramas, tickets y pull requests. GitHub Copilot, Cursor, Windsurf, Claude Code, Aider, Cline, OpenHands y sus parientes empujaban más o menos en la misma dirección: menos tecleo, retroalimentación más rápida, contexto más amplio y más autonomía.

Esa parte es real. Estas herramientas pueden leer más código del que la mayoría quiere leer, bosquejar una funcionalidad con rapidez, proponer migraciones, escribir pruebas, explicar módulos viejos y encargarse de los cambios repetitivos que antes drenaban una tarde entera.

Pero la historia popular alrededor de ellas siguió siendo infantil. La gente siguió actuando como si el prompt correcto más una especificación lo bastante larga pudieran convertir a un agente en un turno de noche confiable. No va a pasar. No estás delegando una tarea cerrada a un especialista fiable. Estás entrando en una conversación de diseño con un sistema rápido, útil, probabilístico y peligrosamente dispuesto a seguir avanzando sobre un supuesto malo.

Las capacidades no desaparecieron

Ese es el malentendido que más daño está haciendo ahora mismo. La gente ve aparecer código más rápido y concluye que las capacidades subyacentes ya sobran. No es así. Las herramientas quitaron parte del trabajo manual. No quitaron la necesidad de entender qué mantiene unido a un sistema.

Alguien sigue teniendo que razonar sobre límites, estado, transacciones, manejo de fallos, observabilidad, seguridad, rendimiento, capacidad de prueba y cambio a lo largo del tiempo. Alguien sigue teniendo que saber por qué una demo limpia puede ocultar un diseño podrido. Alguien sigue teniendo que notar cuando el código generado resolvió el prompt local mientras dañaba silenciosamente el sistema más grande.

Por eso los desarrolladores con experiencia obtienen mucha más palanca de la IA que los usuarios sin ella. La experiencia no es solo la capacidad de escribir sintaxis de memoria. Es reconocimiento de patrones construido a partir de incidentes, regresiones, despliegues fallidos, migraciones feas, condiciones de carrera y decisiones de diseño que parecían brillantes hasta que la realidad votó.

El agente puede generar diez opciones en un minuto. La experiencia te dice que ocho son trampas.

Diseñar en diálogo es el punto

El buen uso del desarrollo asistido por IA no es “dile qué construir.” El buen uso es “usa el diálogo para obligar al diseño a salir a la luz.”

Una conversación productiva con un agente deja artefactos. No vibras. No confianza. Artefactos.

• Un glosario de términos del negocio que impida que todos usen la misma palabra para cinco cosas distintas.
• Un modelo de estados que haga explícitas las transiciones válidas e inválidas.
• Contratos de interfaz y ejemplos de payloads.
• Pruebas que fijen el comportamiento antes de que la implementación derive.
• Un plan de migración, un plan de rollback y comprobaciones de monitoreo.
• Una lista breve de decisiones que todavía necesitan un responsable humano.

Esa es la parte que mucha gente se pierde cuando habla de prompting. Prompting es la parte menos interesante. La ganancia real es que puedes interrogar el diseño desde varios ángulos sin pagar el viejo impuesto de transcripción.

Puedes pedirle al agente que modele el flujo como estados. Luego preguntar dónde se fugan esos estados. Luego preguntar qué transiciones necesitan transacciones. Luego preguntar qué pasa cuando el proveedor externo hace timeout después de que ya empezaron los efectos secundarios. Luego pedir pruebas que demuestren que la invariante se mantiene. Luego preguntar qué partes siguen estando subespecificadas. Eso no es ayuda para teclear. Eso es diseño de sistemas acelerado.

Cómo suena un buen diálogo

Si quieres mejores resultados, deja de pedir primero funcionalidades pulidas. Pide estructura.

• Modela este flujo como estados y transiciones antes de escribir código.
• Enumera las invariantes. ¿Qué no debe pasar nunca, incluso con reintentos o concurrencia?
• Muestra los modos de fallo antes de mostrar el camino feliz.
• ¿Qué supuestos de este diseño son decisiones del negocio en lugar de decisiones técnicas?
• Propón pruebas que detecten una implementación rota.
• Genera el corte vertical más fino que demuestre que el diseño es viable.
• Dime qué sigues sin poder saber a partir del repositorio y del prompt actual.

Esa última pregunta importa más que las demás. Los buenos desarrolladores saben que lo desconocido suele ser donde se esconde el daño. Un modelo que responde con soltura sigue sin tener contexto sobre política interna, dependencias ocultas, reglas de cumplimiento, comportamiento del cliente, dolor operativo y las pequeñas cicatrices feas que todo sistema real acumula con el tiempo.

Por eso el diálogo vence a la delegación. Un diálogo puede hacer visible la incertidumbre. La delegación la esconde hasta que producción se encarga de la revelación.

Y ahí es exactamente donde la práctica fundamental sigue importando. Si no entiendes pruebas, diseño modular, integridad de datos, versionado, riesgo de despliegue o cómo se comportan los fallos distribuidos, el agente no te va a salvar. Solo te permitirá cometer errores más grandes a mayor velocidad.

El mito de la especificación nocturna

La fantasía del agente nocturno suele empezar con un instinto respetable. La gente por fin entiende que el prompting vago es inútil, así que decide escribir una especificación seria. Bien. Deberían hacerlo.

Luego dan el salto fatal: una vez que la especificación es lo bastante detallada, el agente puede trabajar solo.

No. Ahí es donde la lógica se rompe.

Las especificaciones escritas en prosa están llenas de trampas:

• Términos del negocio que parecen resueltos hasta que dos stakeholders los definen de forma distinta.
• Flujos que suenan lineales hasta que aparecen reintentos, cancelaciones y fallos parciales.
• Requisitos de seguridad y cumplimiento que nunca se escribieron porque “todo el mundo lo sabe”.
• Restricciones heredadas que viven en la memoria de un desarrollador senior y en ningún otro sitio.
• Realidades operativas como rate limits, datos rotos y atajos del soporte que ningún brief de producto captura.

La especificación no es inútil. Es la jugada de apertura.

Las siguientes jugadas son las que importan: desafiar el lenguaje, convertir afirmaciones en pruebas, convertir flujos en estados explícitos, convertir interfaces en ejemplos, convertir el manejo de fallos en comportamiento observable y seguir preguntando dónde el diseño todavía depende de adivinar. Si el agente te ayuda a hacerlo más rápido, bien. Si le entregas el documento y desapareces, no estás automatizando desarrollo. Estás automatizando negación.

Lo que el agente sí puede hacer durante la noche

Hay trabajo autónomo útil. Solo no la versión mágica.

Un agente puede pasarse horas generando alternativas, cartografiando una base de código, resumiendo dependencias, redactando pruebas, construyendo spikes desechables, comparando esquemas o preparando planes de refactorización para revisión. Ese es un excelente trabajo de fondo. Amplía el espacio de opciones antes de la siguiente conversación de diseño.

Lo que no puede hacer de manera responsable es decidir con qué trade-off debería vivir tu negocio.

No puede decidir si la consistencia eventual es aceptable para reembolsos. No puede decidir si tu equipo de soporte puede sobrevivir a un fallback manual. No puede inferir qué segmento de clientes importa más cuando dos flujos chocan. No puede cargar con la culpa cuando la ventana de migración es demasiado pequeña y el rollback era falso. Esos no son problemas de programación. Son problemas de decisión.

La herramienta puede ayudar a enmarcarlos. No puede heredarlos.

El flujo práctico que funciona en 2026

Un flujo sensato para desarrollo asistido por IA en 2026 se ve aburrido. Por eso funciona.

1. Empieza por el resultado de negocio más pequeño que de verdad importe.
2. Usa el diálogo para definir términos, estados, invariantes y modos de fallo.
3. Pídele al agente pruebas, ejemplos y un corte fino de implementación.
4. Ejecuta las comprobaciones. Lee los diffs. Cuestiona los supuestos.
5. Afina el diseño con otra ronda corta en lugar de escribir un prompt más grandilocuente.
6. Conserva los artefactos resultantes: pruebas, diagramas, notas, scripts y registros de decisiones.

Este bucle encaja con el paisaje real de herramientas de marzo de 2026. Los modelos ya son lo bastante buenos para ser útiles en cada ronda. No son lo bastante buenos como para saltarse las rondas.

Por eso las pruebas superan a las instrucciones para agentes de programación con IA y vibe coding no es desarrollo de software importan las dos. Cuanto mejores se vuelven los modelos, más caro sale pensar de forma descuidada, porque ahora la máquina puede convertir ese pensamiento descuidado en muchísimo código muy rápido.

El malentendido detrás del hype

Ese es el cambio real.

El flujo anterior tenía huecos largos entre intención y retroalimentación. Describías el cambio, escribías el andamiaje, buscabas en la base de código, revisabas la documentación, ejecutabas las pruebas, corregías los errores obvios y solo entonces volvías a la pregunta real de diseño. El desarrollo asistido por IA comprime esos huecos.

Esa compresión es valiosa. También es fácil leerla mal. La iteración más rápida se siente como pensamiento terminado. No lo es.

Quienes más provecho le sacan a estas herramientas no son quienes intentan escapar del diseño de sistemas. Son quienes usan el diálogo para hacer más de ese trabajo, antes y con menos fricción. Tratan al agente como un colaborador agresivamente rápido que necesita supervisión, no como un sustituto del juicio.

Quienes se queman suelen perseguir la fantasía contraria. Quieren el resultado sin el oficio. Quieren calidad de sistema sin disciplina de diseño. Quieren mantenibilidad sin pruebas. Quieren cambio fiable sin entender qué puede romperse. El desarrollo asistido por IA no concede nada de eso. Sobre todo expone si ya estaba ahí o no.

La parte dura sigue teniendo dueño

Sigues necesitando a una persona capaz de oler una simplificación falsa, detectar restricciones ausentes y hacer la pregunta que nadie quería hacer.

Eso no es una limitación temporal que desaparecerá con el siguiente lanzamiento de modelo. Es la naturaleza de construir sistemas dentro de organizaciones. Los sistemas viven dentro de presupuestos, hábitos, incentivos, rencores, incidentes de producción y promesas medio cumplidas. El código es solo una capa.

Así que sí: usa las herramientas que existían en marzo de 2026. Úsalas a fondo. Déjalas leer el repo, esbozar el módulo, redactar la prueba, explicar el desastre heredado y proponer tres caminos a través del pantano.

Solo no confundas diálogo con delegación.

Si la conversación produce mejores restricciones, mejores pruebas y mejores decisiones, el desarrollo asistido por IA es una ventaja seria. Si la conversación se reemplaza por una entrega y un deseo, no es más que teatro caro.