¿Cuándo basta un prompt y cuándo necesitan más los agentes de IA?

TL;DR

Los LLMs de frontera están alcanzando un nivel en el que muchos viejos rituales de prompting se están volviendo redundantes. Ya no necesitas escribir una pequeña especificación de software para cada solicitud de código sencilla, explicar manualmente cómo navegar por el repositorio cuando es evidente, ni prescribir cada paso de la implementación con excesivo detalle.

Pero que los modelos sean más capaces no elimina la necesidad de diseñar agentes. Los benchmarks recientes muestran lo contrario: a medida que los modelos mejoran, la diferencia entre una buena respuesta y un trabajo terminado depende cada vez más del contexto, las herramientas, la verificación, el sandboxing, cómo se plantea la tarea y los límites del workflow.

Usa solo un prompt cuando la tarea sea pequeña, de bajo riesgo, fácil de inspeccionar y no requiera retroalimentación en tiempo real del entorno. Usa un workflow de agente cuando la tarea requiera buscar en el repositorio, ejecutar comandos, corregir tests, planificar tareas de largo alcance, interactuar con sistemas externos, aplicar criterio de seguridad o lograr un comportamiento repetible en el equipo.

Mi regla actual:

Prompt = enough when the answer can be judged from the answer.
Agent workflow = needed when correctness depends on the environment.

Probablemente, en el futuro los prompts bastarán para tareas más grandes que las de hoy. Eso no elimina la necesidad de especificaciones, evals, herramientas y revisión. La pregunta pasa de «¿Puede el modelo escribir esto?» a «¿Puede el sistema terminarlo de manera confiable sin romper algo de forma inadvertida?».

Qué aprenderás aquí

• Qué se está volviendo evidente o redundante al usar agentes de código modernos.
• Cuándo un prompt simple sigue siendo la herramienta adecuada.
• Cuándo un prompt no basta, incluso con un modelo muy capaz.
• Qué dicen los benchmarks recientes sobre la capacidad de los modelos frente al scaffolding de los agentes.
• Un framework práctico de decisión para ingenieros y PMs.
• Un pequeño ejemplo de eval que puedes adaptar antes de invertir en infraestructura para agentes.

La pregunta detrás de la pregunta

Cada mes, los agentes de código parecen más capaces. GPT-5.3-Codex, las versiones de Claude Opus y Sonnet, los modelos Gemini 3.x y los agentes especializados en código siguen elevando los resultados en los benchmarks. La pregunta natural es:

Si el LLM sigue volviéndose más inteligente, ¿seguimos necesitando algo más que un buen prompt?

La respuesta es a la vez más optimista y más aburrida que la versión promocionada.

Sí, los mejores modelos facilitan muchas cosas. Necesitan menos instrucciones detalladas. Infieren mejor la intención. Pueden trabajar en más archivos, usar herramientas de forma más confiable, recuperarse de errores con mayor frecuencia y entender mejor el lenguaje humano impreciso.

Pero no, un prompt no sustituye al resto del sistema de trabajo. Un prompt le dice al modelo lo que quieres. Un workflow de agente le da la capacidad de comprobar si lo logró.

Esa distinción importa para el trabajo de ingeniería y producto porque la mayor parte del trabajo útil no consiste en «generar código». Consiste en:

understand goal
  -> inspect existing system
  -> choose a safe change
  -> edit files
  -> run checks
  -> interpret failures
  -> update implementation
  -> explain tradeoffs
  -> package the result

Un gran prompt puede mejorar el primer y el último paso. No puede proporcionar por arte de magia el repositorio, la terminal, los tests, el esquema de la base de datos, los logs de CI, las restricciones de producto o el proceso de aprobación de la organización.

Qué se está volviendo redundante

Algunos hábitos de prompting tenían sentido en 2023 y 2024 porque los modelos eran poco fiables. En 2026, muchos son en gran medida ceremoniales.

1. Explicar en exceso conceptos generales de calidad de software

Por lo general, no necesitas:

Write clean, readable, maintainable, idiomatic code.
Use best practices.
Avoid bugs.
Think carefully.

Los modelos de código modernos ya están entrenados y ajustados en torno a esas ideas. Las indicaciones genéricas sobre calidad rara vez cambian el resultado. Incluso pueden desplazar contexto más útil.

Mejor:

Add server-side validation for the invite flow.
Keep the current Zod schema style.
Run the invite tests and update only the files needed.

Las restricciones específicas valen más que las buenas prácticas expresadas de forma genérica.

2. Microgestionar pasos que el agente puede descubrir

Si el agente tiene acceso al repositorio, a menudo no necesitas decirle:

First list files.
Then open package.json.
Then search for invite.
Then inspect tests.

Eso todavía puede ayudar con una herramienta limitada o menos capaz, pero los agentes de código modernos generalmente saben que deben inspeccionar antes de editar. Usa instrucciones paso a paso solo cuando el orden importe.

Mejor:

Find the invite creation path, add validation, and verify with the relevant tests.
Do not change unrelated auth behavior.

3. Pegar prompts largos y reutilizables en cada tarea

Si pegas el mismo «superprompt de ingeniería» de 800 líneas en cada solicitud de código, probablemente sea hora de trasladar los datos estables al contexto del repositorio y los workflows repetibles a skills o comandos.

Always relevant:
  stack, architecture, generated files, test commands
  -> AGENTS.md / CLAUDE.md / .cursor/rules

Sometimes relevant:
  release checklist, PR review procedure, migration recipe
  -> skill / command / runbook

One-time intent:
  the feature you want today
  -> prompt

El prompt debe contener la tarea. El entorno debe contener el manual de operación.

4. Pedir planes cuando la tarea es mínima

Para cambios pequeños y reversibles, pedirle al agente que produzca un plan completo antes de tocar el código puede ser una pérdida de tiempo. Un buen agente puede inspeccionar, editar y verificar en una sola pasada.

Usa planificación cuando la tarea sea ambigua, arriesgada, afecte a varias partes del sistema o sea costosa de revertir. Omítela cuando el trabajo sea evidente y verificable.

Cuándo basta un prompt

Un prompt simple basta cuando la tarea está bien delimitada y una persona puede evaluar la respuesta directamente o se puede evaluar con una comprobación sencilla.

Buenas tareas para resolver solo con un prompt:

• Explicar un archivo o una decisión de arquitectura.
• Escribir el borrador de una función pequeña a partir de una firma clara.
• Convertir un fragmento de un formato a otro.
• Generar un primer caso de prueba para un comportamiento conocido.
• Crear una consulta SQL cuando el esquema ya está incluido.
• Resumir las ventajas y desventajas de una decisión de producto.
• Crear textos, notas de lanzamiento o una lista de verificación.

Para ingenieros, una estructura segura es:

Input is complete
Risk is low
Output is inspectable
No hidden environment needed
No long feedback loop needed

Ejemplo:

Write a TypeScript helper that receives a list of invoices and returns
the overdue total by customer. Use cents as integers. Include two example
unit tests.

Eso no necesita un agente autónomo. Necesita una buena respuesta.

Para PMs, un prompt basta cuando el resultado deseado es un documento para apoyar el razonamiento, no una acción operativa:

Turn these customer notes into three product hypotheses, each with
evidence, risk, and a falsifiable metric.

De nuevo, no se necesita un ciclo de agente. El trabajo es de razonamiento, está delimitado y se puede revisar.

Cuándo un prompt no basta

Un prompt deja de ser suficiente cuando la corrección depende de hechos o retroalimentación externos al prompt.

1. La tarea depende de una base de código real

«Agregar el prorrateo de facturación» no es una solicitud que se resuelva solo con un prompt. El agente necesita inspeccionar los modelos de dominio, los flujos de pago existentes, los tests, las convenciones de nombres y los casos límite.

El prompt puede expresar la intención:

Add proration when a customer upgrades mid-cycle.

Pero el workflow necesita acceso al entorno:

read billing code
  -> inspect current subscription state model
  -> find tests and fixtures
  -> edit implementation
  -> run targeted tests
  -> fix failures
  -> summarize migration risk

2. La tarea tiene criterios de aceptación implícitos

Si el éxito depende de que «el dashboard se sienta ágil», «coincida con nuestro sistema de diseño» o «no rompa el SSO empresarial», el modelo necesita más que una frase. Necesita ejemplos, restricciones, capturas de pantalla, telemetría, tests o revisión humana.

Los objetivos vagos están bien para explorar. No bastan para ejecutar sin supervisión.

3. La tarea es de largo alcance

Un trabajo reciente de METR mide el «horizonte temporal de finalización de tareas al 50%»: la duración de una tarea para una persona en la que un sistema de IA tiene éxito aproximadamente la mitad de las veces. Su artículo de 2025 encontró que los horizontes temporales de los sistemas de frontera se habían duplicado aproximadamente cada siete meses desde 2019, con señales de aceleración en 2024.

Es impresionante. También nos muestra por qué importan los workflows de agentes. Las tareas largas fallan menos porque el modelo no pueda escribir una sola línea y más porque debe conservar el estado, recuperarse de errores, llamar a las herramientas correctamente y evitar desviarse del objetivo.

El trabajo de largo alcance necesita scaffolding:

task state
  -> plan
  -> checkpoints
  -> tool calls
  -> logs
  -> tests
  -> human approvals
  -> rollback path

4. La tarea puede afectar datos, dinero, seguridad o confianza

Para operaciones en producción, un prompt no es un sistema de control.

No dependas de «ten cuidado» para:

• migraciones de bases de datos
• cambios de control de acceso
• lógica de pagos
• automatización de despliegues
• respuesta a incidentes
• código sensible para la seguridad
• comandos destructivos de CLI

Usa permisos explícitos, ejecuciones de prueba, entornos de prueba, logs de auditoría, revisión de código y confirmación humana.

5. El workflow debe repetirse en todo un equipo

Si un ingeniero le pide algo a un agente una sola vez, un prompt está bien. Si veinte ingenieros necesitan el mismo comportamiento cada semana, un prompt se convierte en un documento de políticas poco confiable.

El comportamiento repetible debe vivir en:

• archivos de contexto del repositorio
• comandos
• skills
• comprobaciones de CI
• plantillas
• runbooks de producto e ingeniería
• evals

La prueba es simple: si te molestaría escribirlo por quinta vez, probablemente necesita un lugar permanente.

Qué dicen realmente los benchmarks recientes

Los benchmarks no te dicen qué herramienta comprar. Te dicen cómo están cambiando los modos de falla.

SWE-bench Verified: los agentes de código mejoraron mucho

SWE-bench Verified es un subconjunto validado por personas de 500 tareas basadas en issues reales de GitHub. La página del benchmark lo describe como un conjunto de evaluación confiable para agentes de código y modelos de lenguaje, con casos revisados para verificar que tengan descripciones claras, parches de prueba correctos y que sea posible resolverlos.

OpenAI reportó un 74.9% para GPT-5 en SWE-bench Verified en August 2025. Anthropic reportó a Claude Opus 4.5 como un modelo de vanguardia para ingeniería de software en el mundo real en November 2025, y la ficha del modelo Gemini 3.1 Pro de Google DeepMind indica un 80.6% en SWE-bench Verified hasta February 2026.

La tendencia es clara: los modelos no son juguetes. Para muchas tareas de corrección de errores en repositorios, los sistemas de frontera ahora resuelven una gran parte de los issues del benchmark.

Pero esto no significa «solo dale un prompt». SWE-bench incluye muchos tipos de sistemas: ciclos de agente simples, sistemas de recuperación, sistemas con múltiples ejecuciones y sistemas de revisión. El benchmark evalúa un modelo dentro de un entorno de tareas, no un prompt aislado en una ventana de chat.

Terminal-Bench: el scaffolding cambia el resultado

Terminal-Bench 2.0 es especialmente útil para esta discusión porque evalúa agentes en entornos de terminal reales. El artículo de 2026 describe 89 tareas difíciles con entornos únicos, soluciones escritas por personas y tests.

La tabla de clasificación oficial de Terminal-Bench del June 3, 2026 muestra una amplia variación entre combinaciones de agente y modelo. Por ejemplo, GPT-5.3-Codex aparece con varios agentes, desde Terminus 2 con 64.7% hasta SageAgent con 78.4%. Claude Opus 4.6 aparece con resultados que van desde Claude Code con 58.0% hasta Terminus-KIRA con 74.7%, y otros harnesses por encima de ese valor.

Ese es el punto central: una misma familia de modelos subyacente puede mostrar resultados muy distintos según el sistema que envuelve al agente, el manejo de comandos, el ciclo de planificación, la gestión del entorno y el harness de evaluación.

Un modelo más capaz ayuda. Un mejor sistema de agentes también ayuda.

SWE-agent: el diseño de interfaces es capacidad

El artículo de SWE-agent, publicado en NeurIPS 2024, argumentó que los modelos de lenguaje son una nueva categoría de usuario de computadoras y se benefician de interfaces diseñadas para ellos. Su interfaz personalizada entre agente y computadora mejoró la capacidad del agente para editar archivos, navegar por repositorios y ejecutar tests.

Esta es una de las pruebas más claras contra la idea de que «solo hace falta un prompt». El modelo importa, pero la interfaz a través de la cual actúa puede habilitar o bloquear sus capacidades.

Agentless: a veces lo más simple supera a los agentes

También hay evidencia en la dirección contraria. El artículo de Agentless mostró que un proceso simple de tres fases —localización, reparación y validación del parche— alcanzó un 32.0% en SWE-bench Lite a bajo costo, superando a los agentes de software de código abierto existentes en ese momento.

Ese resultado es un antídoto útil contra el maximalismo de los agentes. Más autonomía no es automáticamente mejor. A veces, un pipeline estructurado sin agentes supera a un ciclo de agente que deambula sin rumbo.

Así que la lección no es «construye agentes siempre». Es:

Use the minimum workflow that can observe, decide, act, and verify
for the task's actual risk.

Advertencia sobre los benchmarks: las puntuaciones pueden exagerar su utilidad en el mundo real

Investigaciones recientes también advierten que algunas puntuaciones de benchmarks de código pueden estar infladas por la memorización, la contaminación del benchmark o el planteamiento poco realista de las tareas.

El artículo The SWE-Bench Illusion encontró evidencia de que las mejoras de rendimiento en SWE-bench Verified podrían deberse en parte a artefactos aprendidos, en lugar de a una capacidad general de resolución de problemas. Otro artículo de 2025 preguntó si SWE-bench Verified evalúa la capacidad del agente o la memoria del modelo, y encontró que los modelos eran mucho mejores en la localización dentro de SWE-bench Verified que en benchmarks de comparación.

Un artículo de 2026 sobre mutaciones de benchmarks argumentó que las descripciones formales de issues de GitHub pueden sobreestimar el desempeño de los agentes ante solicitudes de código realistas formuladas en un chat.

Esto no hace que los benchmarks sean inútiles. Significa que no debes confundir una tabla de clasificación pública con tu workflow de producción.

El framework práctico de decisión

Usa esto para decidir si necesitas un prompt, un archivo de contexto, una skill o un workflow completo de agente.

Can the task be answered from the prompt alone?
  yes -> prompt
  no  -> continue

Is the missing context stable and relevant to most tasks?
  yes -> repo context file
  no  -> continue

Is the task a repeatable procedure with a clear trigger?
  yes -> command or skill
  no  -> continue

Does success require acting in an environment and checking results?
  yes -> agent workflow with tools and evals
  no  -> prompt plus attached context

Can failure harm users, data, money, security, or trust?
  yes -> add approvals, sandboxing, tests, logging, rollback

Aquí está lo mismo en una tabla:

El ejemplo de código: medir si algo más que un prompt ayuda

Antes de construir un workflow sofisticado de agente, ejecuta una pequeña eval. Elige tareas que tu equipo realmente realiza. Ejecuta cada tarea en dos o tres modos:

• prompt-only
• repo-context
• agent-with-tools

Registra el resultado, el tiempo, el costo y la carga de revisión.

type EvalMode = "prompt-only" | "repo-context" | "agent-with-tools";

type AgentEvalResult = {
  taskId: string;
  mode: EvalMode;
  passed: boolean;
  minutes: number;
  estimatedCostUsd: number;
  reviewerFixes: number;
  notes: string;
};

function summarize(results: AgentEvalResult[]) {
  const byMode = new Map<EvalMode, AgentEvalResult[]>();

  for (const result of results) {
    const bucket = byMode.get(result.mode) ?? [];
    bucket.push(result);
    byMode.set(result.mode, bucket);
  }

  return [...byMode.entries()].map(([mode, items]) => {
    const passRate = items.filter((item) => item.passed).length / items.length;
    const avgMinutes =
      items.reduce((sum, item) => sum + item.minutes, 0) / items.length;
    const avgReviewerFixes =
      items.reduce((sum, item) => sum + item.reviewerFixes, 0) / items.length;

    return {
      mode,
      passRate,
      avgMinutes,
      avgReviewerFixes,
    };
  });
}

La métrica importante no es solo la tasa de éxito. Es la tasa de éxito después de la revisión.

Un agente que deja «casi terminadas» el 80% de las tareas, pero genera trabajo de limpieza difícil de detectar, puede ser peor que un workflow basado solo en prompts que termina el 60%, pero es transparente y fácil de completar.

Un mejor modelo mental para PMs

Para los PMs, la pregunta no es «¿Necesitamos agentes?». Es «¿Dónde está la incertidumbre?».

Si la incertidumbre está en el lenguaje, un prompt puede bastar:

What are the likely user segments?
What are the edge cases?
How should we explain this release?

Si la incertidumbre está en el sistema, el agente necesita herramientas:

Which customers are affected?
Which tests fail?
Which code path owns this behavior?
What changed between releases?

Si la incertidumbre está en la responsabilidad por el resultado, el workflow necesita gobernanza:

Who approves the change?
What evidence is required?
What is the rollback path?
What should be logged?

Por eso, los agentes de IA no son solo una cuestión de capacidad del modelo. Son una cuestión de diseño de producto.

Entonces, ¿bastarán los LLMs del futuro?

Para más tareas, sí.

La tendencia es real. OpenAI, Anthropic y Google DeepMind reportan mejores resultados en código, terminal, uso de herramientas y tareas de agentes. La investigación de METR sobre horizontes temporales sugiere que los agentes están manejando tareas más largas con el tiempo. Terminal-Bench y SWE-Bench Pro existen porque las evaluaciones anteriores se estaban volviendo demasiado limitadas o saturadas.

Pero el umbral de lo que es «suficiente» sigue cambiando.

Cuando los modelos mejoran escribiendo código, los equipos les piden refactorizar sistemas más grandes. Cuando mejoran usando la terminal, los equipos les piden desplegar, migrar, recuperar y operar sistemas. Cuando mejoran redactando contenido de producto, los equipos les piden sintetizar datos de clientes y hacer recomendaciones.

La frontera de las tareas se expande junto con la capacidad.

Así que no espero que los prompts desaparezcan. Espero que se vuelvan más pequeños, más deliberados y más cercanos a la intención de producto:

Bad future prompt:
  Here is a giant manual. Please follow every rule.

Good future prompt:
  Upgrade billing proration for annual plans.
  Preserve existing monthly behavior.
  Open a PR with tests and migration notes.

El resto debe vivir en el entorno del agente:

repo context
tools
tests
skills
permissions
observability
review gates
deployment policy

Los mejores agentes darán la impresión de necesitar menos prompts porque una mayor parte del workflow que los rodea está haciendo su trabajo.

Mi recomendación actual

Para ingenieros:

• Mantén los prompts cortos, específicos y orientados a resultados.
• Coloca los datos estables del proyecto en el contexto del repositorio.
• Usa skills o comandos para procedimientos repetibles.
• Usa herramientas y tests siempre que la corrección dependa del entorno.
• Construye pequeñas evals antes de estandarizar un workflow.

Para PMs:

• Trata los prompts como expresión de intención, no como control del proceso.
• Pregunta qué evidencia necesitará el agente para demostrar que terminó.
• Define qué significa «terminado» mediante comprobaciones observables.
• Mantén a las personas involucradas en las decisiones de producto, legales, financieras, de seguridad y que afecten a los clientes.
• Mide la carga de revisión, no solo la velocidad.

La versión más sólida no es «prompt vs. agente». Es:

prompt for intent
context for facts
tools for action
evals for evidence
humans for judgment

Vacíos y secciones de seguimiento que valdría la pena agregar después

Este artículo se enfoca deliberadamente en agentes de código y workflows de software y producto. Algunas secciones útiles para ampliar el tema serían:

• Una comparación más profunda de Claude Code, Codex, Cursor, Gemini CLI y OpenHands en las mismas tareas de repositorio.
• Una plantilla práctica para AGENTS.md, CLAUDE.md y .cursor/rules.
• Una sección de seguridad sobre permisos, sandboxing, inyección de prompts y manejo de secretos.
• Una rúbrica de evaluación específica para PMs que cubra PRDs, síntesis de investigación y tareas de analítica.
• Un modelo de costos para determinar cuándo la autonomía del agente es más económica que la revisión humana y cuándo no.

Lista de fuentes

• OpenAI: Presentación de GPT-5 para desarrolladores - Resultados de GPT-5 en código y SWE-bench Verified.
• OpenAI: Presentación de GPT-5.3-Codex - Benchmarks de Codex de 2026 en SWE-Bench Pro, Terminal-Bench 2.0, OSWorld y GDPval.
• Anthropic: Presentación de Claude Opus 4.5 - Posicionamiento de Claude Opus 4.5 para código, agentes y uso de computadoras.
• Google DeepMind: Ficha del modelo Gemini 3.1 Pro - Tabla de benchmarks de February 2026 que incluye SWE-Bench Verified, SWE-Bench Pro y Terminal-Bench 2.0.
• Google DeepMind: Gemini 3.5 Flash - Tabla actual de benchmarks de Gemini 3.5 Flash para código, terminal, MCP, control de interfaz y tareas de expertos.
• SWE-bench Verified - Contexto del benchmark de 500 casos validado por personas y su tabla de clasificación.
• Tabla de clasificación de Terminal-Bench 2.0 - Tabla de clasificación oficial que muestra combinaciones de agente y modelo hasta June 3, 2026.
• Artículo de Terminal-Bench - Artículo de 2026 que describe 89 tareas difíciles de terminal y el diseño de la evaluación.
• METR: Medición de la capacidad de la IA para completar tareas largas de software - Métrica de horizonte temporal y evidencia sobre el crecimiento de la capacidad para realizar tareas largas.
• SWE-agent: Las interfaces entre agentes y computadoras permiten la ingeniería de software automatizada - Evidencia de que el diseño de interfaces afecta el desempeño de los agentes.
• Agentless: Una explicación de los agentes de ingeniería de software basados en LLMs - Evidencia de que pipelines estructurados más simples pueden superar a agentes autónomos más complejos en algunas tareas.
• La ilusión de SWE-Bench - Investigación sobre las preocupaciones por la memorización y la contaminación en evaluaciones del estilo de SWE-bench.
• ¿SWE-Bench-Verified evalúa la capacidad del agente o la memoria del modelo? - Estudio de 2025 que cuestiona si la localización en SWE-bench Verified refleja una capacidad general.
• Salvando SWE-Bench - Enfoque de mutación de benchmarks que muestra que las descripciones formales de issues pueden sobreestimar el desempeño de los agentes de chat en el mundo real.
• SWE-Bench Pro - Benchmark más exigente diseñado para tareas realistas y de largo alcance de software empresarial.
• TerminalWorld - Benchmark de 2026 construido a partir de grabaciones de terminales reales, que muestra las dificultades que aún existen en workflows auténticos de terminal.