Pregunte a un equipo qué salvaría si el edificio estuviera ardiendo y durante setenta años la respuesta fue el código fuente. Perderlo significaba perder las decisiones acumuladas de la empresa, los miles de pequeños juicios que hacen que un sistema encaje con su negocio. Esa respuesta está cambiando en silencio. Cuando los agentes pueden regenerar una implementación en funcionamiento a partir de un enunciado preciso de lo que el sistema debe hacer, el código deja de ser la joya de la corona. Lo es el enunciado. A la disciplina que se deriva de tomarse esto en serio la llamamos desarrollo guiado por la intención: convertir la intención - y no el código - en el artefacto que su equipo escribe, revisa, versiona y posee.
La afirmación del título necesita un matiz inmediato. «Escribir código es opcional» no significa que nadie lea código, ni que el código generado dé igual, ni que la destreza de ingeniería esté obsoleta. Significa algo más estrecho y más interesante: para una clase creciente de trabajo, teclear la implementación a mano es ya una elección y no una necesidad - y los equipos deberían decidir de forma deliberada dónde siguen haciendo esa elección, en lugar de hacerla en todas partes por costumbre.
La intención no es un eslogan
La palabra «intención» invita al abuso. Suena a algo que se podría satisfacer con una declaración de misión y un panel de inspiración. En la práctica, una intención capaz de dirigir el desarrollo es un conjunto de enunciados verificables sobre el comportamiento - enunciados que una máquina o un colega pueden contrastar con el sistema y responder «pasa» o «no pasa». «Los clientes deberían tener un proceso de compra fluido» es un sentimiento. «Un cliente recurrente completa la compra en tres pasos; un pago rechazado conserva el carrito y explica el fallo en el idioma del cliente; no es posible un cargo duplicado ni aunque se pulse dos veces el botón de confirmar» es intención. La diferencia es la comprobabilidad, y es toda la diferencia.
La intención se apila en tres capas. Arriba está la intención de producto: qué resultado existe para producir el sistema, para quién y medido cómo. Debajo viven los invariantes del sistema: las propiedades que deben cumplirse sea cual sea la implementación - el dinero se conserva, los registros de auditoría solo se añaden, los datos personales no salen del perímetro, los borrados son recuperables. Abajo están las pruebas de aceptación y las evaluaciones: la forma ejecutable, la capa que una canalización de integración puede ejecutar de verdad. Cada capa justifica a la de abajo; cada capa de abajo hace comprobable a la de arriba. Un equipo que mantiene las tres puede entregar la implementación a un agente igual que un cliente entrega la construcción a un contratista - contra planos, no contra adjetivos.
Si eso suena a primo hermano de escribir contratos para agentes de IA, lo es. El desarrollo guiado por especificación es la disciplina por tarea: un trabajo, un contrato, un ciclo de verificación. El desarrollo guiado por la intención es el aspecto que tiene el código cuando esa disciplina se acumula - cuando los contratos, los invariantes y las evaluaciones acumulados se convierten en la descripción real del sistema, y cualquier implementación concreta no es más que su compilación actual.
El código como producto de compilación
La consecuencia práctica es un desplazamiento de lo que significa «la fuente». En un lenguaje compilado nadie parchea el binario; se cambia la fuente y se recompila. Los equipos guiados por la intención empiezan a tratar el código de implementación igual: cuando el comportamiento tiene que cambiar, la primera edición aterriza en la capa de intención - una nueva prueba de aceptación, un invariante modificado, un enunciado de producto más afilado - y la implementación se regenera o se rehace para satisfacerla. El código sigue siendo legible, revisado y portante. Lo que cambia es su estatus: es derivado, y aquello de lo que deriva es lo que usted discute.
La revisión cambia de objetivo en consecuencia. Revisar tres mil líneas generadas a velocidad de lectura es teatro; el revisor aprueba lo que en realidad no puede sostener en la cabeza. Revisar el diff de la intención sí es abordable: qué comportamiento nuevo se ha prometido, qué invariantes se han tocado, ¿fijan de verdad las nuevas pruebas esa promesa, y hay algo en el diff de la implementación que exceda lo que la intención explica? La atención del ingeniero senior sube un nivel - de «¿es correcto este bucle?» a «¿es esta la promesa correcta y está garantizada?». Eso no es degradar el criterio de ingeniería. Es aplicarlo donde ahora rinde más.
El código es derivado. La intención es la fuente. Los equipos que discuten sobre la fuente entregan más rápido que los que discuten sobre la compilación.
Dónde sigue ganando el código escrito a mano
Ser honesto sobre el límite evita que esto se convierta en ideología. Parte del código debería seguir escribiéndose a mano, y las categorías son constantes. El núcleo caliente - el motor de tarificación, el algoritmo de emparejamiento, el modelo de riesgo - donde cada rama encarna una decisión de negocio y la comprensión del código por parte del equipo es en sí misma un activo. El trabajo algorítmico novedoso, donde la intención no puede enunciarse con más precisión que la implementación porque descubrir la implementación es el trabajo. Las fronteras críticas para la seguridad - autenticación, criptografía, iniciación de pagos - donde la profundidad de la revisión importa más que la velocidad de producción y usted quiere las huellas de una persona en cada línea. Y la propia capa de intención: las pruebas, los invariantes, las evaluaciones y los esquemas merecen autoría humana precisamente porque todo lo demás se contrasta con ellos.
La pregunta útil para cualquier trabajo concreto no es «¿puede escribir esto un agente?» - cada vez más, puede - sino «¿qué perdemos si no lo escribe ninguna persona?». Donde la respuesta sea «nada, siempre que la intención esté garantizada», generar es la opción racional por defecto. Donde la respuesta sea «nuestra comprensión de aquello con lo que ganamos dinero», tecléelo usted.
Cómo se pudre
La podredumbre de la intención es el primer modo de fallo. La capa de intención solo es la fuente de verdad mientras se mantiene como tal. En cuanto un equipo empieza a parchear el comportamiento directamente - un arreglo urgente aquí, una edición manual rápida allá - sin propagar el cambio de vuelta a las pruebas y los invariantes, la intención empieza a describir un sistema que ya no existe. Entonces la siguiente regeneración, compilada fielmente a partir de una intención caducada, borra los arreglos no documentados. La regla que lo evita es la misma que mantiene honestos a los esquemas: los cambios de comportamiento aterrizan primero como cambios de intención, en el mismo pull request, o no aterrizan.
Regenerar sin volver a verificar es el segundo. La regeneración no es idempotente: dos ejecuciones contra la misma intención producen código distinto con comportamiento incidental distinto, y todo lo que la capa de intención no fija queda libre para cambiar. Los equipos se queman cuando dan por hecho que la canalización en verde de ayer responde por la regeneración de hoy. No lo hace. Cada regeneración es una implementación nueva y se gana el pase de verificación completo - pruebas, evaluaciones, comprobación de invariantes - todas las veces. Si eso resulta demasiado caro de ejecutar en cada regeneración, la solución es abaratar la verificación, no espaciarla.
Tratar el código generado como desechable cuando es portantees el tercero y el más sutil. Un equipo interioriza que «el código es solo un producto de compilación» y deja de leerlo por completo - sin revisión, sin perfilado, sin familiaridad operativa. Entonces llega un incidente a las dos de la madrugada y quien está de guardia depura un sistema que nadie ha leído nunca, guiado solo por la intención que se suponía que debía satisfacer. Derivado no significa ignorable. El código en producción exige responsabilidad operativa sin importar quién lo tecleó; la capa de intención le dice qué debería hacer el sistema, pero la respuesta a incidentes sigue ocurriendo en lo que hace de verdad. Los equipos que lo llevan bien designan un responsable para cada componente generado igual que lo harían para uno escrito a mano - alguien que lo ha leído, lo ha perfilado y puede recorrerlo bajo presión.
Un camino de adopción pragmático
Nada de esto requiere una revolución, y los equipos que la intentan suelen producir un manifiesto y ningún cambio. El camino que funciona es incremental. Empiece por hacer explícita la intención del sistema que ya tiene: escriba los invariantes que cree que se cumplen, convierta el conocimiento tribal en pruebas de aceptación y sea honesto sobre dónde discrepan las pruebas y el sistema. Este paso se paga solo aunque ningún agente llegue a tocar nunca el código - no es más que la documentación y la cobertura de pruebas que el equipo ya se debía a sí mismo.
Después elija un componente acotado y bien conocido y ejecute el ciclo completo sobre él: intención escrita y revisada, implementación generada contra ella, verificación mecánica, revisión humana dirigida al diff de la intención. Mida con honestidad - tiempo de ciclo, tasa de defectos, esfuerzo de revisión - frente a la línea base escrita a mano. Amplíe por las fronteras donde el ciclo gane; siga tecleando donde no. En pocos trimestres el código se ordena solo en un núcleo escrito a mano con una periferia generada, y la escasa atención de los perfiles senior del equipo se concentra en la capa donde acumula valor: decidir, con precisión y de forma comprobable, qué debe hacer el software.
El sector ya ha pasado por aquí. Nadie echa de menos escribir ensamblador a mano; conservamos la capacidad y dejamos la costumbre, porque una fuente de más alto nivel más un compilador fiable era sencillamente un trato mejor. Intención más agentes más verificación se está perfilando como el mismo trato, un nivel por encima. Escribir código se está volviendo opcional. Saber exactamente qué debe hacer el código - y poder demostrar que lo hace - se está convirtiendo en el oficio.