Ingeniería agente en cinco capas: desde especificaciones y agentes paralelos hasta reglas y supervisión
Karpathy denominó al proceso anterior como “vibe coding”. Consulte las cinco capas de la ingeniería agente: especificaciones, orquestación, reglas codificadas, revisión humana y observabilidad, además de un plan semanal.
El código por onda tuvo un buen período de popularidad. Andrej Karpathy, quien acuñó el término, ha declarado que esa era ya pasó, y no solo identificó el problema: también esbozó qué lo reemplaza: la ingeniería de agentes, en la cual los agentes de IA planifican, escriben, prueban y envían código mientras un humano mantiene una supervisión estructurada. El humano establece la intención, los agentes la ejecutan y el humano verifica el resultado. Se trata de un método profesional para desarrollar con IA y no simplemente junto a ella, y está muy lejos de ser un simple prompt casual seguido de esperanza.
Un esfuerzo anterior por adoptar un desarrollo orientado a especificaciones, es decir, por detallar qué debe hacer un sistema antes de que cualquier agente genere algo, resultó abarcar solo una capa de esta disciplina. Desde entonces, los equipos en producción han añadido cuatro capas más. Lo que sigue describe todas las cinco capas, muestra cómo se ven en la práctica y finaliza con un plan de ejercicios de una semana para comenzar.
Por qué el nombre es importante
El término va más allá de ser una marca. Marca la diferencia entre dos formas muy distintas de trabajar, y Karpathy trazó esa línea con un par de preguntas. El coding de tipo “vibe” se pregunta si algo puede hacerse funcionar. La ingeniería agente se pregunta si algo puede hacerse funcionar de manera fiable, a gran escala, sin introducir vulnerabilidades.
La primera pregunta elimina las limitaciones. Ahora cualquiera puede crear un prototipo: un desarrollador de fin de semana describe lo que desea, acepta los resultados obtenidos y termina con una demostración funcional. Esto resulta realmente útil para la exploración. La segunda pregunta establece límites máximos. Los programas que procesan pagos, manejan datos de salud o administran infraestructuras siguen requiriendo disciplina profesional. El desarrollador puede escribir el código, pero alguien debe diseñar el sistema, definir sus límites y verificar los resultados.
Las propias palabras de Karpathy fueron directas: la ingeniería de agentes es una disciplina de ingeniería, y los agentes son impredecibles, estocásticos y extremadamente poderosos; por lo tanto, el verdadero problema radica en coordinarlos para que actúen más rápido sin disminuir la calidad. Ese problema, alcanzar rapidez sin sacrificar la calidad, es ahora la cuestión definitoria de este campo. No se trata solo de su punto de vista. IBM, Forrester y Anthropic publicaron cada una marcos formales para una nueva disciplina distinta en el mismo trimestre, llegando a esa conclusión de forma independiente. Cuando organizaciones que rara vez coinciden en opiniones convergen al mismo tiempo, la idea adquiere solidez.
El término se quedó porque los ingenieros necesitaban una palabra para describir el trabajo que ya estaban realizando: más estructurado que la generación de prompts, más disciplinado que el coding basado en la intuición, y aún así diferente al desarrollo tradicional. La disciplina a la que se refiere tiene cinco capas, y cada una se apoya en la que está debajo. Si se omite una, todo lo anterior se vuelve poco fiable.
Capa 1: especificación
Escriba la especificación antes de que cualquier agente genere código. Indique qué debe hacer siempre el sistema, qué nunca debe hacer, cómo saber si está funcionando y cómo saber si se ha detenido. Coloque todo esto en un único documento, mantenga ese documento actualizado y mida todo lo que construye el agente en función de él.
Diferentes especialistas en ingeniería de IA denominan esto planificación estratégica, definición de intenciones o simplemente la especificación. El nombre varía, pero la práctica no: saber qué se desea antes de pedirle a un agente que lo construya.
Hay un punto que es fácil pasar por alto. Una especificación no es un documento creado el día del lanzamiento; es un documento vivo. Cada vez que la implementación revela algo que la especificación no previó, y así ocurrirá, esta se actualiza. Los equipos cuyos miembros se alejan gradualmente de la intención original son casi siempre aquellos que redactaron la especificación desde el primer día y nunca volvieron a consultarla.
Una plantilla mínima comienza con un encabezado que declara al documento como la fuente de verdad:
# Feature Spec: [Feature Name]
## Last updated: [Date] — this document is the source of truth
Luego vienen las listas de verificación de comportamiento, una sección con los comportamientos requeridos y otra con límites estrictos, como la prohibición de procesar reembolsos superiores a 500 dólares sin la aprobación humana:
## What this must always do
- [ ] [Behaviour 1 — specific, testable]
- [ ] [Behaviour 2 — specific, testable]## What this must never do
- [ ] [Boundary 1 — e.g. "Never process refund >$500 without human approval"]
- [ ] [Boundary 2 — e.g. "Never fabricate a citation"]## Success criteria (measurable)
- Context recall: >0.85
- Faithfulness: >0.90
- Cost per query: <$0.15
- Latency p95: <2s## Failure signals (alert if breached)
- Any metric drops >5% from 7-day baseline
- Cost per task exceeds 3x expected range
- User complaint rate exceeds 2% of sessions## Decomposition (for parallel agents)
- [ ] Task A: [scope] — can be delegated independently
- [ ] Task B: [scope] — depends on Task A output
- [ ] Task C: [scope] — can run parallel with Task A
Manténgalo en una sola página. Si la especificación es más extensa, la funcionalidad es demasiado grande y debe dividirse hasta que cada parte quepa.
Incluso una especificación perfecta entregada a un único agente enfrenta un límite de rendimiento, y por eso existe una segunda capa.
Capa 2: orquestación
Considere una funcionalidad que afecta al esquema de la base de datos, a la API, a la interfaz frontal y al conjunto de pruebas. Tradicionalmente, un ingeniero trabaja en cada parte por turnos, o un equipo coordina sus esfuerzos a lo largo de un sprint. En la ingeniería con agentes, cuatro agentes se encargan de las cuatro partes al mismo tiempo: uno escribe la migración, otro los puntos de extremo, un tercero los componentes de la interfaz frontal, y el cuarto escribe las pruebas y revisa el resto en busca de problemas de seguridad. Cada uno tiene su propio contexto y restricciones, y sus resultados se combinan en un cambio coherente.
Esto no es hipotético. Stripe utiliza este patrón en producción, con un sistema interno de agentes que genera más de 1,000 solicitudes de fusión por semana; cada una es escrita por un agente, revisada por una persona, pasa las pruebas de integración y se envía al sistema. La mejora es de un orden de magnitud, no solo del doble.
El ritmo sigue un ciclo que se repite para cada funcionalidad: planificar, ejecutar y verificar. Algunos equipos lo denominan el ciclo PEV.
- Planificar. El humano escribe las especificaciones a partir de la Capa 1 y divide el trabajo en unidades que se pueden delegar de forma independiente. Una decisión importante aquí es determinar qué tareas pueden ejecutarse en paralelo, ya que no dependen de los resultados de las demás, y cuáles deben realizarse en orden.
Lo que antes requería un sprint de dos semanas ahora se convierte en una sesión de trabajo concentrada de unas horas o un día. El esfuerzo humano se concentra principalmente en la planificación y la verificación, mientras que los agentes realizan la mayor parte del trabajo entre ambas etapas.
Se necesita tiempo para asimilar una nuance: el objetivo es un paralelismo útil, no uno máximo. Tres agentes en módulos estrechamente acoplados generan conflictos cuya resolución cuesta más de lo que ahorra el funcionamiento en paralelo. Dos agentes en módulos independientes, con un tercero que revisa ambos, producen un resultado coherente. La habilidad radica en la descomposición, dividiendo el trabajo de modo que pueda delegarse sin problemas de integración posterior.
Un orquestador esquelético puede indicar el bucle en su documentación:
class AgenticOrchestrator:
"""Plan → Execute (parallel) → Verify"""
y se lleva a cabo el paso de planificación, que divide una funcionalidad en tareas delegables:
def plan(self, feature_spec: dict) -> dict:
"""Decompose feature into independently delegatable tasks."""
tasks = []
for component in feature_spec["decomposition"]:
tasks.append({
"id": component["id"],
"spec": component["scope"],
"constraints": feature_spec["must_never"] + component.get("local_rules", []),
"depends_on": component.get("depends_on", []),
"verification": component.get("success_criteria", []),
})
independent = [t for t in tasks if not t["depends_on"]]
sequential = [t for t in tasks if t["depends_on"]]
return {"parallel": independent, "sequential": sequential} async def execute(self, plan: dict):
"""Run independent tasks in parallel, sequential tasks in order."""
parallel_results = await asyncio.gather(*[
self.delegate_to_agent(task) for task in plan["parallel"]
])
for task in plan["sequential"]:
result = await self.delegate_to_agent(task, prior=parallel_results)
parallel_results.append(result)
return parallel_results def verify(self, results: list, spec: dict) -> dict:
"""Check all outputs against the spec — structural, not line-by-line."""
issues = []
for result in results:
if not self.satisfies_spec(result, spec):
issues.append(f"{result['id']}: does not satisfy spec")
if self.conflicts_with(result, results):
issues.append(f"{result['id']}: conflicts with another module")
return {"passed": len(issues) == 0, "issues": issues}
El principio rector es delimitar estrictamente el contexto. Cada agente debe recibir únicamente su sección de especificaciones, sus archivos de código y sus reglas. Incluir todo el conjunto de código en cada ventana de contexto desperdicia tokens, aumenta los costos y diluye la atención del modelo.
La orquestación mejora el rendimiento, pero un alto rendimiento sin consistencia conduce al caos. Cada agente debe conocer las convenciones del equipo, las restricciones arquitectónicas y las políticas de seguridad, así como las especificaciones de su propia tarea. La capa siguiente se encarga de proporcionar eso.
Capa 3: reglas codificadas
La mayoría de las herramientas ya cuentan con una versión de esto. Claude Code carga un CLAUDE.md al inicio de cada sesión, Cursor lee .cursorrules y Codex lee AGENTS.md. El concepto es el mismo: un archivo en la raíz del proyecto que indica al agente cómo comportarse.
En 2026, los equipos han ido aún más allá y codifican toda su cultura de desarrollo como restricciones legibles por los agentes, más allá del conjunto tecnológico utilizado. Profesionales como Paul Duvall han estado documentando los patrones que surgen en los equipos de producción, y InfoQ ha seguido su nivel de madurez. Cuatro patrones se repiten en todos los casos donde funciona la ingeniería basada en agentes:
- Desarrollo guiado por especificaciones, donde las especificaciones dirigen el trabajo (Capa 1).
- Reglas codificadas y restricciones arquitectónicas: convenciones, políticas de seguridad, patrones de manejo de errores, estándares de nomenclatura y procedimientos de despliegue, todo ello en archivos que los agentes cargan antes de comenzar a trabajar.
- Descomposición atómica con agentes paralelos: las funcionalidades se dividen en los fragmentos más pequeños que pueden ser gestionados por separado (Capa 2).
La escala es donde la mayoría de los equipos se encuentran con un obstáculo. Un CLAUDE.md funciona bien para un prototipo de 1,000 líneas. Una base de código de 100,000 líneas no puede describirse en un solo archivo, y aunque fuera posible, las reglas ocuparían toda la ventana de contexto antes de que el agente llegue a la tarea real.
Los equipos que resuelven este problema construyen sistemas de reglas jerárquicos, de manera similar a cómo las configuraciones de ESLint heredan de ajustes predefinidos de la organización y pueden ser sobrescritas según el proyecto. La estructura de carpetas se ve así:
your-company/
├── .ai-rules/
│ └── org-rules.md ← Company-wide: security, compliance, style
│
├── team-payments/
│ ├── .ai-rules/
│ │ └── team-rules.md ← Team-level: error handling, testing, deploys
│ │
│ ├── service-checkout/
│ │ ├── CLAUDE.md ← Repo-level: architecture, tech stack, builds
│ │ ├── src/
│ │ │ ├── auth/
│ │ │ │ └── .ai-rules.md ← Module: auth-specific constraints
│ │ │ └── payments/
│ │ │ └── .ai-rules.md ← Module: PCI compliance rules
En la parte superior se encuentra el archivo de la organización, cargado para cada agente en cada repositorio. Cubre aspectos como nunca guardar secretos, exigir autenticación en las APIs públicas y nunca exponer rastros de la pila en las respuestas de error:
# org-rules.md (loaded for every agent, every repo)
- Never commit secrets or credentials
- All public APIs require authentication
- Error responses must never expose stack traces
- Log every state-changing operation with user context
A continuación, un archivo del equipo hereda esas reglas y agrega las suyas propias, como el patrón de Result en lugar de excepciones lanzadas, todo el acceso a la base de datos a través de una capa de repositorio, y pruebas que cubran el camino exitoso además de al menos dos modos de fallo:
# team-rules.md (inherits org, adds team specifics)
- Use Result<T, E> pattern — never throw exceptions
- All database queries go through the repository layer
- Tests must cover the happy path + 2 failure modes minimum# CLAUDE.md (inherits team, adds repo specifics)
- This repo uses Express.js + Prisma + PostgreSQL
- Run `npm test` before suggesting any PR is ready
- Migrations are append-only — never modify applied migrations# module .ai-rules.md (inherits repo, adds module specifics)
- auth/: All token operations must use constant-time comparison
- payments/: PCI DSS requires field-level encryption on card data
Un agente carga las reglas de la organización, las reglas del equipo, el archivo CLAUDE.md del repositorio y las reglas del módulo con el que interactúa. Esto mantiene el contexto bien delimitado y sin sobrecargas. El agente encargado del módulo de pagos recibe las reglas de cumplimiento PCI, mientras que el agente del frontend no las recibe, ya que esas reglas consumirían recursos sin aportar beneficio alguno.
Las reglas indican cómo trabajar, pero la toma de decisiones sigue requiriendo juicio humano. El código puede seguir todas las convenciones y, aun así, ser arquitectónicamente incorrecto, resolviendo el problema planteado de una manera que genere uno mayor en otro lugar. Por eso la siguiente capa no es opcional.
Capa 4: supervisión humana
Tres palabras describen el modelo operativo que ha surgido: delegar, revisar, asumir responsabilidad.
Delegar. Entregue al agente una tarea bien definida con restricciones claras y déjelo trabajar. No lo supervise al detalle ni observe cómo escribe. La especificación y las reglas existen para que se pueda confiar en que el agente las seguirá.
Revisar. Trate la salida devuelta como una solicitud de integración proveniente de un ingeniero competente pero junior: rápido, capaz, y propenso a errores sutiles que solo alguien que comprende el sistema en su totalidad podría detectar. Verifique la adecuación arquitectónica y los casos límite. Confirme que se cumplieron las especificaciones, lo cual significa que se cumplió la intención y no solo que los tests pasan.
Asumir responsabilidad. El ser humano es el responsable de la calidad final. El agente realizó el trabajo, la persona dio su aprobación, y cualquier fallo en producción es responsabilidad de esa persona. Esta responsabilidad distingue la ingeniería con agentes del coding informal, donde nadie asume responsabilidad por el resultado.
El cuello de botella es real. Los agentes generan código más rápido de lo que las personas pueden revisarlo, y la tentación es relajar los estándares para mantener el ritmo. Esa misma tentación fue la causa de que se popularizara el coding vibe: los desarrolladores aceptaban los resultados porque parecían correctos, pasaban las pruebas y se acercaba la fecha límite. La ingeniería de agentes existe para evitar que ese patrón se repita.
El informe de tendencias de codificación con agentes de Anthropic describe cómo lo gestionan los ingenieros experimentados. Delegan tareas cuya corrección se puede verificar a simple vista o cuyas consecuencias son bajas. Cuanto más conceptualmente compleja o dependiente del diseño sea una tarea, mayor es la probabilidad de que la mantengan ellos mismos o de trabajar en ella conjuntamente con el agente. Saber qué delegar y qué retener es la nueva competencia fundamental. Se desarrolla con la práctica, no existe atajo alguno a través de frameworks o herramientas, y distingue al ingeniero que utiliza agentes de manera productiva del que genera resultados impresionantes pero que fallan bajo escrutinio.
Una lista de verificación ayuda antes de que cualquier contenido generado por un agente pase a producción. Su encabezado es:
## Agent Output Review Checklist
y su cuerpo, organizado en secciones que comienzan con la alineación de especificaciones (¿se han implementado todos los comportamientos requeridos?, ¿se respetan los límites?, ¿se cumplen los criterios de éxito?) y pasan luego a la arquitectura y al sentido empresarial:
### Spec alignment (does it do what was asked?)
- [ ] All "must always do" behaviours are implemented
- [ ] No "must never do" boundaries are violated
- [ ] Success criteria from the spec are met or tested### Architectural coherence (does it fit the system?)
- [ ] No new dependencies introduced without justification
- [ ] Consistent with naming, patterns, and structure of existing code
- [ ] No duplication of logic that exists elsewhere### Safety and edge cases
- [ ] Error handling covers the failure modes the spec anticipated
- [ ] No hardcoded credentials, keys, or environment-specific values
- [ ] Input validation present on all external-facing boundaries### What the agent cannot check for itself
- [ ] Does this make business sense? (not just technical correctness)
Vale la pena imprimirlo y pegarlo cerca del monitor. Los herramientas de análisis de código y los procesos CI pueden automatizar parcialmente las tres primeras secciones. La última, el sentido empresarial, es la razón por la que un humano debe seguir involucrado.
Las revisiones detectan problemas antes del lanzamiento. La lenta degradación de la calidad, las regresiones sutiles y el aumento de costos que nadie nota hasta que llega la factura solo se manifiestan después, y para eso se necesita el último nivel de control.
Nivel 5: desarrollo observable
El monitoreo y el desarrollo observable suenan similares, pero realizan tareas diferentes. El monitoreo indica que el sistema está operativo, con una latencia normal, pocos errores y un panel de control en estado verde. El desarrollo observable muestra qué hizo el sistema: qué agente manejó qué tarea, según qué especificaciones, con qué herramientas, generando qué código, y si el resultado cumplió con la intención inicial.
La diferencia se hace evidente a las 2 de la mañana. Con solo el monitoreo, se sabe que algo está roto pero se desconoce la causa, por lo que la noche se pasa leyendo diferencias y especulando sobre los módulos. Con un desarrollo observable, el rastro de la implementación muestra que el agente 3 cambió el flujo de autenticación según una especificación que ignoraba los refrescos concurrentes de tokens. Eso equivale a doce minutos de depuración dirigida en lugar de dos horas de especulaciones.
En la práctica, todo se reduce a tres hábitos:
- Cada tarea del agente genera un rastro estructurado: la especificación que recibió, las herramientas que utilizó, los archivos que modificó, la versión del modelo, los tokens consumidos y el resultado de la verificación. Cuando aparece un error tres días después, el rastro indica qué sucedió y nadie necesita acordarse.
Una configuración mínima comienza con las importaciones necesarias para un pequeño registro de seguimiento:
from dataclasses import dataclass, field
from datetime import datetime
y la clase de datos trace aplicada a cada tarea delegada:
@dataclass
class AgentTrace:
"""Minimum trace for every agent-delegated task."""
task_id: str
agent_id: str
spec_given: str # What was the agent told to do?
tools_used: list[str] # Which tools did it invoke?
files_modified: list[str] # What did it change?
model_version: str # Which model, which version?
tokens_consumed: int # What did it cost?
started_at: datetime = field(default_factory=datetime.utcnow)
completed_at: datetime | None = None
verification_result: str = "" # pass / fail / needs_review
human_reviewer: str = "" # Who signed off?
issues_found: list[str] = field(default_factory=list)
Agregue una revisión semanal de quince minutos. Su encabezado es:
## Weekly Observable Development Review (15 minutes)
y sus preguntas: cuántas tareas se delegaron, cuántas superaron la verificación en el primer intento (objetivo superior al 80%), qué categoría tuvo más problemas y cuáles fueron los tres principales problemas:
1. How many agent tasks were delegated this week? ___
2. How many passed verification on first attempt? ___ (target: >80%)
3. Which task category had the most issues? ___
4. Top 3 issues found during review:
- ___
- ___
- ___
5. Which issues should become codified rules (Layer 3)? ___→ Update CLAUDE.md with any new rules from this week's observations.
Quince minutos a la semana cierran el ciclo. Las observaciones se convierten en reglas, las reglas mejoran la orquestación, una mejor orquestación produce mejores resultados, y esos resultados generan nuevas observaciones.
Evidencia de que funciona
Dos cifras destacan. Las más de 1,000 solicitudes de integración que Stripe procesa cada semana son escritas por agentes, revisadas por humanos, pasan las pruebas de integración continua y se utilizan en producción, lo cual no es un experimento en entorno aislado. Se trata de un volumen de trabajo que no era posible hace un año. Otro grupo de expertos menciona otro número: la encuesta de McKinsey indica reducciones en los costos operativos del 20 al 40 por ciento, una cifra que convierte a la IA de una iniciativa de innovación en una infraestructura operativa, algo que exigen los directores financieros y no solo los directores de tecnología.
Qué significa para una carrera en ingeniería
El papel de los ingenieros está cambiando, pero no desapareciendo. En 2026, escribirán menos código básico y dedicarán más tiempo a orquestar agentes, diseñar arquitecturas, definir objetivos y límites, así como a verificar los resultados. La habilidad fundamental pasa de la sintaxis al pensamiento sistémico, de preguntarse cómo escribir una función a preguntarse cómo diseñar un sistema en el que los agentes puedan escribirla correctamente.
Karpathy extendió esto a la contratación: eviten las preguntas tipo acertijo y propongan un proyecto significativo, como crear una copia segura de Twitter para luego hacer que los agentes intenten vulnerarla, observando cómo el candidato maneja las herramientas, las especificaciones y la supervisión. Eso pone a prueba la disciplina y no la velocidad de escritura.
Tres competencias surgen repetidamente en las conversaciones con los líderes de ingeniería:
- Fluidez en las especificaciones. Es más difícil redactar una especificación lo suficientemente precisa como para que un agente la ejecute sin ambigüedades que escribir código. El código cuenta con un compilador que detecta errores, mientras que una especificación solo depende de la interpretación del agente. Si la especificación es vaga, el agente elegirá una interpretación con confianza, trabajará sobre ella y presentará el resultado como si fuera exactamente lo solicitado.
- Juzgamiento en la orquestación. Saber qué delegar y qué mantener, cuándo los procesos en paralelo son útiles y cuándo la integración es demasiado estrecha, así como determinar si el resultado necesita una revisión exhaustiva o solo una verificación estructural. Esto se desarrolla a través de cientos de delegaciones, cada una de las cuales enseña qué funciona y qué genera problemas de integración.
Gergely Orosz lo expresó bien: hay algo mucho más importante que la programación que hace especiales a los ingenieros, y merece ser cultivado. Lo que diferenciará a los ingenieros en 2026 serán los sistemas que diseñen, las especificaciones que redacten, su criterio para delegar tareas y el estándar de calidad al que se nieguen a bajar. Esas habilidades valen aún más ahora precisamente porque la ejecución mecánica ya se ha automatizado.
Un plan de inicio de cinco días
Cinco ejercicios a lo largo de una semana, cada uno basado en el anterior:
- Lunes: codificar los conocimientos del equipo. Escriba un CLAUDE.md o .cursorrules para el proyecto actual. Omita la lista de tecnologías y registre las convenciones: cómo se manejan los errores, cómo están estructuradas las pruebas, cómo se nombran las cosas, y las reglas no escritas que todo recién llegado debe aprender desde el primer día.
- Martes: especificar y delegar. Elija una funcionalidad del backlog y escriba su especificación utilizando el template: qué debe hacer, qué no debe hacer, los criterios de éxito y las señales de fallo. Delegue completamente la tarea a un agente, y programe tiempo tanto para la especificación como para su revisión. La proporción muestra dónde realmente se invierte el esfuerzo.
Una semana no hará de nadie un ingeniero de agentes. Sin embargo, sí muestra cómo es esa disciplina y si pasar de escribir código a orquestar agentes energiza o agota. Cualquiera de las dos respuestas es válida, pero ayuda saber cuál es la correcta.
Dónde falla una visión basada únicamente en especificaciones
Tratar la especificación como la respuesta completa, escribiéndola, siguiéndola y verificándolo en función de ella, es necesario pero no suficiente. La especificación es la entrada para un sistema de orquestación y no una práctica autónoma. Una especificación perfecta entregada a un único agente genera un buen resultado. La misma especificación distribuida entre cinco agentes en paralelo, cada uno sujeto a reglas codificadas, cada uno revisado bajo supervisión estructurada y cada uno rastreado a través de un desarrollo observable, genera aproximadamente diez veces más trabajo con la misma calidad.
También es fácil subestimar la capa 4. La especificación indica la intención, y el ser humano decide si se cumplió dicha intención. Una especificación no se aplica por sí sola, y su paso de verificación requiere tanta disciplina como el proceso de redacción. La verificación, más que el modelo, el marco o las herramientas, es donde la mayoría de los equipos cortan esquinas cuando se acercan las fechas límite.
Qué viene a continuación
Se pueden observar dos direcciones posibles: una casi segura y otra especulativa.
La opción casi segura es que la ingeniería basada en agentes se convierta en el método estándar para el desarrollo profesional de software en aproximadamente 18 meses, no porque todos conozcan este enfoque sino debido a que sus ventajas económicas son irresistibles. Tres ingenieros que lo aplican, con especificaciones claras, orquestación paralela y supervisión disciplinada, logran el mismo resultado que doce ingenieros trabajando de la forma tradicional. Cuando las cifras son tan claras, el debate termina.
La opción especulativa son los enjambres de agentes: redes de agentes que se coordinan entre sí y ejecutan flujos de trabajo completos o funciones empresariales con un mínimo de intervención humana. Algunos equipos ya están realizando pruebas al respecto. No se sabe si esto funcionará a escala empresarial con la fiabilidad requerida, por lo que es mejor combinar el interés por este enfoque con escepticismo.
Lo que no es especulativo es que el papel del ingeniero ya ha cambiado. La pregunta clave es si se están desarrollando las competencias del nuevo rol —especificación, orquestación y verificación—, o si el trabajo sigue realizándose como si la tarea principal fuera escribir código. Antes, escribir código era el trabajo principal. Ahora, el trabajo consiste en diseñar el sistema que lo genera y confirmar que lo producido sea correcto.