Miessler: escribir importa más que el código con IA

El código no es la verdad: es una abstracción

Daniel Miessler lo plantea sin rodeos: en un proyecto construido con IA, el artefacto más importante no es el código, sino la articulación escrita de lo que quieres construir y por qué. Su postura choca de frente con la de Matt Pocock, un desarrollador de perfil clásico que sostiene que el código es la fuente de verdad del proyecto y que las especificaciones son útiles, pero secundarias.

El argumento de Miessler es que el código es una ejecución, un facsímil, una representación. La misma relación que hay entre una pintura y lo que el pintor quería transmitir. Y si el código es la representación, tratarlo como la verdad es confundir el mapa con el territorio.

La consecuencia práctica es incómoda para cualquier equipo: si el código es lo único que registra lo que querías, cada accidente de la primera versión se convierte en requisito, y nadie puede decir después qué partes eran realmente intencionales.

Precisión y exactitud no son lo mismo

Miessler usa una distinción que vale la pena tener a mano. El código tiene más precisión que la escritura, pero la escritura tiene más exactitud. Precisión es agrupar los tiros en un punto; exactitud es darle al centro de la diana.

• Exactitud sin precisión: muchos tiros alrededor del centro, cada uno en un lugar distinto.
• Precisión sin exactitud: todos los tiros pegados entre sí, pero lejos del centro.

Cuando construyes con IA, lo que quieres es que el resultado coincida con lo que tenías en la cabeza. Eso es exactitud. Y según Miessler, no hay forma más cercana de capturar eso que escribir.

El problema que describe no es de capacidad del modelo. Es de comunicación. Lo llama Writer's Blindness: crees que estás capturando perfectamente lo que hay en tu cerebro y no lo estás. El receptor termina con información faltante o con una lectura completamente distinta a la que pretendías.

Qué es un Ideal State Artifact (ISA)

A finales de 2025, Miessler reorganizó todo su flujo de trabajo alrededor de un documento llamado Ideal State Artifact (ISA). No es un PRD ni un spec rígido: es una captura más profunda del estado ideal, dividida en secciones.

• Ideal State articulado: prosa. Puede ser un par de párrafos o miles de palabras de introspección sobre el problema.
• Constraints: lo que explícitamente no quieres construir.
• Decisions: el registro de decisiones tomadas a medida que el estado ideal evoluciona, con fecha y motivo.
• Ideal State Criteria (ISCs): piezas de funcionalidad atómicas y testeables, cada una con su propia evaluación asociada.

El punto fuerte del diseño es que los ISC sirven simultáneamente como aquello desde lo que se construye y como el arnés de pruebas. Si un criterio no se cumple, el código se descarta y se reconstruye contra el mismo ISA. Eso es imposible cuando el código es el único registro de lo que querías.

Miessler describe dos bucles, no uno: la intención y la escritura se moldean mutuamente, y la escritura y la implementación se moldean mutuamente. La iteración es normal en ambos. La diferencia es dónde queda registrada.

Los datos respaldan el diagnóstico

El problema que Miessler describe como "de articulación" tiene correlato en los números del sector. Según el reporte State of Developer Experience 2026 de Atlassian, que encuestó a 1.155 desarrolladores y 405 líderes de ingeniería, el 87% dice que la IA le ayuda a entregar más rápido, pero solo el 28% reporta menos fricción que antes. Y un dato central para este debate: el 65% de los desarrolladores dedica tiempo a corregir trabajo de IA que no cumplió con la intención original.

El mismo reporte señala que las mayores pérdidas de tiempo siguen siendo encontrar información (51%), las reuniones (50%) y la falta de dirección o requisitos poco claros (40%). Es decir, el cuello de botella no está en escribir código.

Otros estudios apuntan en la misma dirección. LinearB, con datos de más de 8 millones de pull requests, encontró que los PR generados por IA esperan 4,6 veces más antes de que alguien los tome, y que solo el 32,7% se acepta, contra el 84,4% de los manuales. En marzo de 2026, METR pidió a cuatro maintainers de proyectos como scikit-learn y pytest que revisaran 296 pull requests escritos por IA que ya habían pasado los tests automáticos de SWE-bench: no habrían fusionado cerca de la mitad.

El mercado ya está reaccionando. Qodo, startup de verificación de código, levantó una Serie B de US$70M liderada por Qumra Capital en marzo de 2026, según TechCrunch, para construir agentes de revisión, testing y gobernanza. Su tesis es explícita: la generación de código y su verificación requieren sistemas distintos.

¿Qué significa esto para tu startup?

Si tu equipo ya usa agentes de código a diario —y según la encuesta 2026 de JetBrains, el 90% de los desarrolladores profesionales los usa al menos semanalmente y el 68% a diario—, el cuello de botella se movió río arriba. Estas son dos acciones concretas:

• Escribe el estado ideal antes de pedir código. Antes de abrir el agente, dedica 20 minutos a un documento en prosa que describa qué tiene que pasar para que el resultado sea correcto, qué no quieres que exista y cómo se verifica. No necesitas que sea perfecto el primer día: necesitas que exista y que se actualice cuando aprendas algo.
• Convierte cada criterio en una prueba. Si un requisito no se puede traducir a una afirmación verificable, todavía no está listo. La lógica de los ISC de Miessler es la misma que la de los criterios de aceptación estilo EARS que usan herramientas como Amazon Kiro: "el sistema debe manejar bien los logins fallidos" genera una hora de discusión; "tras tres intentos fallidos consecutivos, el sistema bloquea la cuenta por 15 minutos" genera un test.

Hay una tercera decisión menos obvia: trata la obsolescencia del documento como un riesgo, no como un problema de documentación. Un spec que nadie tocó en cuatro meses mientras el código cambió cada semana es peor que no tener spec, porque fabrica una confianza falsa en quien lo lee.

La lección que Miessler toma de Sutton

Miessler cierra apoyándose en la Bitter Lesson de Richard Sutton: cuanto más inteligente se vuelve la IA, más debería moverse el esfuerzo humano hacia asegurar que la máquina sabe exactamente qué queremos, y menos hacia microgestionar los pasos para lograrlo.

Para un founder, la traducción es directa. La ventaja competitiva ya no está en escribir mejor código, sino en articular mejor el problema. Y articular es una habilidad que se practica escribiendo, no revisando diffs.

Fuentes

• Writing Is Closer to Thought Than Code (fuente original)
• Why AI makes developers faster but not their teams
• Qodo raises $70M for code verification as AI coding scales
• JetBrains Survey Finds AI Coding Agents Becoming Routine Developer Tools
• 8 Best Spec-Driven Development Tools for Software Engineers in Regulated Industries (2026)