Agentic coding no es 'hazme X'

14 min de lectura

El verdadero agentic coding comienza con límites

La manera más limpia de explicar el agentic coding no es con una demostración de producto. Las demostraciones de productos mienten para ganarse la vida. La forma más limpia es con un prompt real de trabajo y la forma de la respuesta que produce.

Un desarrollador enmarcó una tarea aproximadamente así: mantente dentro de los eventos de Spring, no te desvíes hacia la interfaz de usuario, no te desvíes hacia preocupaciones orientadas al usuario, y ayuda a definir un sistema donde emisores y consumidores puedan añadirse más adelante. Contacto, llamada o correo electrónico es sólo el primer caso. El futuro puede incluir acceso a la interfaz de usuario y herramientas de IA conversacional, pero no ahora. Empieza con la arquitectura de eventos.

Eso ya es una clase de conversación diferente a “constrúyeme un sistema impulsado por eventos”.

Nombra el límite. Nombra las preocupaciones aplazadas. Nombra la dirección futura sin exigir que el futuro se implemente hoy. Le dice al agente dónde no ser astuto.

El prompt no pidió código primero

La respuesta no escupió inmediatamente clases, interfaces y anotaciones como un becario con sobredosis de cafeína y acceso a commit. Primero redujo aún más el problema y pidió inspeccionar código cercano que ya manejaba pipelines, colas y listeners de eventos.

Eso importa.

Como muestra Cuando la IA se convierte en un compañero de pensamiento, el valor no está en la velocidad de escritura. El valor es que el modelo puede buscar localmente, comparar patrones y responder con conciencia de la base de código en lugar de alucinar una charla genérica de conferencia.

Luego la respuesta volvió con una forma arquitectónica sensata:

• separar eventos de dominio de eventos de flujo de trabajo (workflow)
• emitir eventos de negocio desde los límites del servicio en lugar de desde los controladores
• llevar de forma explícita el contexto de inquilino (tenant), agregado y correlación
• tratar los nombres de eventos como contratos estables
• mantener la mecánica de registros (logging) y colas fuera del mismo cubo conceptual que los eventos de negocio

Eso no es “hazme X”. Eso es trabajo de arquitectura colaborativo con autonomía limitada.

El modelo no estaba reemplazando el juicio. Estaba participando en una conversación con gran carga de juicio y haciendo el reconocimiento aburrido lo suficientemente rápido para que el humano pudiera concentrarse en la decisión.

Lo que “hazme X” suele producir

Ahora compare eso con el anti-patrón común.

Alguien abre una ventana de chat y escribe algo como: constrúyeme un sistema de eventos para llamadas, correos electrónicos, actualizaciones de interfaz de usuario, análisis de datos y herramientas de IA.

El modelo casi no tiene condiciones límite útiles. Así que hace lo que hacen los modelos. Redondea el problema hacia la forma estadísticamente más familiar.

Obtienes un bus de eventos genérico. Tal vez un despachador central. Tal vez una carpeta llamada events/common. Tal vez un tipo de payload base con campos que nadie analizó. El registro, los flujos de trabajo, los eventos de negocio, los reintentos y las notificaciones de la interfaz de usuario se revuelven en la misma olla porque el prompt los mezcló primero. Parece completo durante unos quince minutos.

Luego comienza el mantenimiento y llega la factura.

El desarrollo basado en especificaciones es cascada con mejor marketing

Ahora la industria ha producido un disfraz más respetable para el mismo viejo error. Se llama desarrollo basado en especificaciones (spec-driven development).

En el papel suena moderno. Escribes una especificación detallada. La IA la lee obedientemente. La IA implementa el sistema. Supuestamente esto te da rigor, velocidad y alineación al mismo tiempo.

Lo que usualmente te da es un gran diseño inicial (Big Design Up Front) con una nueva capa de pintura de GPU.

La vieja fantasía de la cascada nunca murió realmente. Sólo se cambió de ropa. Primero vinieron los documentos de requisitos lo suficientemente gruesos como para aturdir al ganado. Luego vinieron las especificaciones funcionales, firmadas por seis niveles de gestión, amorosamente desprendidas de cómo se comporta el software una vez que los usuarios reales lo tocan. Ahora el mismo impulso ha vuelto, excepto que en lugar de entregar el documento a un desarrollador resentido, se lo entregas a una máquina infinitamente paciente y llamas al resultado progreso.

Eso no es una revolución. Es burocracia con autocompletado.

La suposición oculta es la misma que en cada ritual de diseño inicial: si describimos el sistema con suficiente detalle por adelantado, la realidad tendrá la decencia de cumplir. La realidad nunca tuvo esa decencia cuando los humanos escribían el código, y no adquiere modales de repente porque el implementador sea un modelo de lenguaje.

Las especificaciones todavía se pudren al entrar en contacto con restricciones reales. Los casos límite siguen apareciendo tarde. Las reglas de negocio aún chocan. La denominación sigue ocultando malentendidos. Los puntos de integración se siguen comportando como borrachos en una boda. La única diferencia es que la IA seguirá marchando a través del documento sin poner los ojos en blanco, lo que algunos gerentes parecen confundir con fiabilidad.

Lo que realmente están comprando es un sirviente digital incansable para el sueño de gestión más antiguo en el software: separar el pensar del hacer, congelar el pensamiento temprano y hacer que la implementación sea lo suficientemente barata como para que nadie discuta. Este sueño era estúpido con personas. Simplemente es más rápido con IA.

Los buenos desarrolladores no quieren un esclavo silencioso, humano o máquina. Quieren un ciclo que exponga las malas suposiciones pronto. Eso significa probar las ideas contra el código, la arquitectura existente y el comportamiento en ejecución. El desarrollo basado en especificaciones, cuando se toma como un gran método, intenta hacer lo contrario. Intenta ganar la discusión antes de que el sistema se haya ganado el derecho a estar de acuerdo.

La versión de liderazgo de ese error suena así: “Si la IA es tan inteligente, ¿por qué necesitamos todo este ir y venir?”

Porque el ir y venir es donde vive el verdadero trabajo.

La versión del desarrollador suena así: “Sólo dame el código.”

Eso es a menudo pura impaciencia llevando un bigote técnico.

Si el límite del sistema es incorrecto, obtener código rápidamente no es una ventaja. Es la forma de industrializar la decisión equivocada.

La contribución humana es el rumbo, no las pulsaciones

Esta es la parte que la dirección sigue entendiendo mal.

Cuando los ejecutivos observan una sesión agentic competente, a menudo se fijan en el milagro visible. La IA leyó archivos. La IA propuso una arquitectura. La IA identificó patrones a través de la base de código. Por lo tanto, los desarrolladores son opcionales.

No. El milagro visible es la parte barata.

La parte valiosa fue que un desarrollador sabía cómo enmarcar el trabajo:

• restringir la superficie arquitectónica
• separar el alcance presente de las ambiciones futuras
• reconocer que las preocupaciones de la interfaz de usuario contaminarían la discusión
• pedir un sistema que pueda crecer sin pretender que todo deba resolverse de una sola vez
• juzgar si la respuesta distinguía los eventos de dominio de la mecánica del flujo de trabajo de una manera que sobreviviría al contacto con una base de código real

Esas no son habilidades ornamentales. Ese es el trabajo.

Un chatbot no es una estrategia de IA importa exactamente por la misma razón por la que una demo de código no es una estrategia de software. La herramienta puede acelerar el pensamiento. No elimina la necesidad de pensar. En la práctica, castiga la ausencia de pensamiento con mayor rapidez. Por eso mismo, el teatro impulsado por especificaciones resulta tan atractivo para la gestión: promete la comodidad emocional del modelo en cascada con el coste laboral de un chatbot.

Si usted es un líder que espera que el agentic coding le permita despedir a las personas que entienden sus sistemas, lo que realmente está comprando es una máquina que puede producir respuestas incorrectas a velocidad industrial siempre que el planteamiento sea descuidado.

La contribución del desarrollador son mejores restricciones

También hay una trampa por el lado del desarrollador.

Algunos desarrolladores escuchan “agentic” y siguen usando la herramienta como una máquina expendedora con mejores modales. Entra tarea. Sale código. Tal vez un segundo prompt si el primer resultado se ve un poco maldito.

Eso no es colaboración. Eso es software de máquina tragamonedas.

Un mejor prompt normalmente hace algunas cosas contundentes:

• nombra la superficie exacta bajo discusión
• declara lo que está fuera de alcance por ahora
• explica qué extensibilidad futura importa y qué puede esperar
• apunta al primer caso de uso real en lugar de a un sistema de ensueño abstracto
• pide al agente que inspeccione los patrones existentes antes de recomendar uno nuevo

Ese último punto es donde gran parte del prompting débil se desmorona. No se debería recompensar al modelo por inventar una arquitectura paralela sólo porque puede. Se le debería empujar a buscar primero la abstracción propietaria.

Por esto también es que las pruebas vencen a las instrucciones importa. Un buen prompt establece la dirección inicial. El repositorio, las pruebas y las herramientas mantienen la sesión honesta después de eso. Sin esos bucles de retroalimentación, “agentic” se convierte en una etiqueta más respetable para el vibe coding.

Lo que es realmente el agentic coding

Despojado del perfume de marketing, el agentic coding normalmente significa cinco cosas:

1. Un humano enmarca el problema y los límites.
2. El modelo puede inspeccionar el sistema local a través de archivos, herramientas o pruebas.
3. El modelo propone o implementa el siguiente paso dentro de ese límite.
4. El resultado se verifica frente al código, las pruebas, el comportamiento en tiempo de ejecución u otra evidencia.
5. El humano restringe más el marco o acepta el resultado y sigue adelante.

Lo que no significa es autonomía mística. No significa que el modelo se haya despertado con criterio de producto. No significa arquitectura sin compromisos. No significa que “hazme X” se haya convertido en un sustituto del desarrollo de software.

Como deja claro Vibe coding no es desarrollo de software, el agentic coding sí puede ser desarrollo de software. Pero sólo cuando el ciclo contiene límites, evidencia y un humano que conoce la diferencia entre un borrador plausible y una decisión duradera.

La continuidad se diseña, no se espera

Hay otro detalle que separa el trabajo agentic real del teatro de prompts: la continuidad entre sesiones.

En algún momento surgió la pregunta obvia: ¿cómo se asegura que en futuras sesiones el sistema de eventos continuará en lugar de desviarse hacia otra cosa?

La respuesta no fue, “confía en que el modelo lo recuerde”. Eso sería una idiotez.

La respuesta fue anclar la decisión en tres lugares, no en uno. Primero, la intención arquitectónica se escribió en la memoria del repositorio para que las sesiones futuras comiencen con el mismo conjunto de reglas: los eventos de dominio compartidos usan un contrato, los eventos de flujo de trabajo locales de la función se mantienen locales a menos que sean promovidos. En ese caso, la nota quedó en /memories/repo/nilo-assistant-notes.md.

Segundo, la protección más fuerte se trasladó al código. La forma del evento se hizo explícita en app/src/main/java/neo/app/events/NiloDomainEvent.java, que es donde este tipo de regla pertenece una vez que deja de ser un pensamiento y comienza a ser arquitectura.

Tercero, la implementación circundante puede entonces reforzar el mismo límite a través de clases de eventos concretos, listeners, pruebas y patrones de uso. En ese punto, una sesión futura tiene que trabajar más duro para desviarse que para continuar.

Luego, la siguiente pregunta de continuación mejoró aún más el ejemplo: antes de continuar con la característica, considera ArchUnit. El repositorio ya lo tenía. ¿Podría ayudar aquí?

Ese es un movimiento agentic real también. No “por favor, continúa implementando”. Más bien: detente, inspecciona la superficie de prueba arquitectónica existente y usa la protección más estrecha que el sistema ya entiende.

La respuesta hizo exactamente eso. Verificó las pruebas de ArchUnit existentes, encontró que el repositorio ya imponía límites de paquetes en ese estilo, y añadió una prueba de arquitectura más en lugar de inventar una religión de gobernanza paralela.

La nueva guardia hizo dos cosas muy simples y muy útiles. Primero, cualquier cosa que implemente NiloDomainEvent tenía que ser un record de Java, lo que bloquea el desvío silencioso hacia clases de eventos mutables y ad-hoc. Segundo, sólo al servicio de proyección de la actividad de contacto designado se le permitió depender directamente del repositorio de la actividad de contacto, lo que significa que el código de la característica futura no puede eludir casualmente el flujo del evento y escribir en el almacenamiento de actividad desde donde le plazca.

Esa es la diferencia entre el teatro de la continuidad y la ingeniería de la continuidad. La memoria dice: “por favor, sigan haciéndolo de esta manera”. El código dice: “esta es la forma”. ArchUnit dice: “el build falla si te pasas de listo”.

La mejor parte es lo poco glamoroso que fue el seguimiento. La primera ruta del corredor de pruebas no ejecutó la nueva prueba de arquitectura, por lo que la sesión no simuló el éxito. Lo intentó de nuevo con Maven para la clase de prueba exacta, confirmó que la regla realmente se ejecutó, y sólo entonces trató la guardia como real. Así se ve el trabajo agentic disciplinado: no una especificación gloriosa, sino un cable trampa ejecutable.

Ese es el patrón real. El historial de chat es memoria débil. La memoria del repositorio es mejor. El código es aún mejor. Las pruebas son la parte que muerde.

Es por esto que la religión basada en especificaciones pierde el punto tan gravemente. El problema no es cómo escribir un documento lo suficientemente detallado como para que una IA obediente pueda llevar a cabo tu plan para siempre. El problema es cómo dejar suficiente estructura viva para que la siguiente sesión, humana o máquina, entre al sistema por la puerta correcta.

El ejemplo importa porque se ve ordinario

No hay nada teatral sobre el ejemplo del evento de Spring. Exactamente por eso es útil.

Sin interfaz de usuario reluciente. Sin gerente de producto robótico. Sin falso teatro de autonomía. Simplemente un desarrollador usando una herramienta de IA de la misma manera que una persona seria usa el apalancamiento: reducir la pregunta, inspeccionar la verdad local, separar categorías que no deben mezclarse y establecer el rumbo antes de que el código comience a multiplicarse.

Así es como se ve el agentic coding cuando es real.

No “hazme X”.

Más bien: aquí está la parte de la realidad que estamos tocando, aquí está la parte que no estamos tocando, aquí está la forma que esta decisión debe preservar, ahora ayúdame a pensar y construir dentro de esta valla.

Ese flujo de trabajo debería tranquilizar a los desarrolladores y preocupar a los gerentes perezosos.

Los desarrolladores no están siendo reemplazados por un chatbot que mejoró en el autocompletado. Están siendo desafiados a trabajar a un nivel en el que la estructura, el juicio y la verificación importan más que escribir a máquina.

Los gerentes no están comprando un sustituto para los desarrolladores de software. Están comprando apalancamiento para desarrolladores de software que ya saben diferenciar un buen límite de uno malo.

Esas son dos historias muy diferentes.

Sólo una de ellas es cierta.