Por qué la mayoría de los desarrolladores siguen obteniendo pocos beneficios de los agentes de programación.

Dos estudios realizados en 2026, uno por JetBrains y otro por Anthropic, proporcionan cifras sobre cómo trabajan realmente los ingenieros con agentes de programación. Según estos estudios, la diferencia entre obtener beneficios de un agente y recibir información irrelevante radica en cómo se delega el trabajo, y no en qué modelo se elige.

La conclusión principal es que la programación con IA ya no es un experimento, y la distinción importante ahora es entre pedirle a un modelo que escriba código y delegarle realmente tareas de ingeniería.

AI coding is no longer an experiment.

90% of professional developers now use coding agents at least weekly.

But there is a big difference between asking AI to write code
and actually delegating engineering work to an agent.

Por qué una app de trading es una buena prueba

Imaginemos una app de trading para iOS desarrollada para una compañía de valores. UIKit y SwiftUI coexisten junto con MVVM y Clean Architecture. En ese tipo de base de código, un número incorrecto en la pantalla de confirmación de órdenes no se convierte en un ticket de error, sino en una llamada del departamento de cumplimiento.

Para un equipo en esa situación, entregar trabajo real a un agente de programación no se trata de velocidad. Lo importante es detectar el momento en que el agente comete un error sin que nadie se dé cuenta. Estudiar ese momento enseña más sobre los flujos de trabajo de los agentes que cualquier curso, y los datos de 2026 explican por qué.

Lo que reveló la encuesta de JetBrains

Entre mayo y julio de 2026, JetBrains encuestó a más de 15,000 desarrolladores en activo. Nueve de cada diez dijeron que utilizan agentes de programación con IA en su trabajo al menos una vez por semana, y el 68% lo hace a diario.

Claude Code lidera con el 39% a nivel mundial y el 47% en Estados Unidos, casi el doble que GitHub Copilot, que registra un 21%, cifra que a su vez disminuyó desde el 29% del año anterior. Codex pasó del 3% al 16%.

Un informe complementario muestra una cifra aún más interesante. Los desarrolladores estiman que aproximadamente el 47% de su código ahora es escrito íntegramente por agentes, más de la mitad de ellos escribe a mano menos del 20% de su código, y uno de cada cinco no escribe nada sin la ayuda de la IA.

La experiencia no frenó la adopción; por el contrario, la impulsó. Aproximadamente uno de cada cuatro desarrolladores senior deja que los agentes generen más del 80% de su código, una proporción mayor que entre los junior, quienes prefieren recibir ayuda línea por línea. Esto refuta la idea de que la IA hace que los junior sean redundantes. Aquellos con mejor juicio son quienes delegan más tareas, y eso difícilmente es casualidad.

Lo que muestran 400,000 sesiones

El estudio propio de Anthropic abarcó aproximadamente 400,000 sesiones interactivas de Claude Code realizadas por unos 235,000 usuarios, registradas desde octubre de 2025 hasta abril de 2026. El desglose resulta más sencillo de lo que sugiere el marketing:

• Las tareas relacionadas con el código representaron el 56% de las sesiones, distribuidas en un 25% para escribir código, un 26% para corregirlo y un 5% para probarlo u organizarlo.
• La operación de software ocupó el 17%.
• La planificación y exploración representaron el 14%.
• El análisis y la redacción ocuparon el 13%.

El hallazgo más importante se refiere a quién decide qué. Las personas toman aproximadamente el 70% de las decisiones de planificación, mientras que Claude toma alrededor del 80% de las decisiones de ejecución. Los humanos deciden el *qué*, mientras que el agente se encarga del *cómo*.

Nadie diseñó esa división. Es el equilibrio al que llegaron independientemente cientos de miles de ingenieros, porque funciona. Muchas quejas sobre los agentes de programación provienen de personas que lo invirtieron, entregando primero el qué y luego discutiendo con el agente sobre el cómo.

La experiencia especializada cambia el resultado

Aquí las cifras refutan a quienes creen que “ahora cualquiera puede programar”. Las sesiones se evaluaron según la aparente experiencia del usuario en el área, a través de tres indicadores: cuán precisas eran las instrucciones, qué era lo que el usuario pedía a Claude que revisara y cómo se realizaban las correcciones. Luego se compararon los resultados uno al lado del otro.

Comience con las dos primeras filas. Los expertos no escriben más. Una sola instrucción de un experto genera más del doble de trabajo en comparación con uno realizado sin supervisión; doce acciones frente a cinco por parte de un principiante, aunque el modelo, la herramienta y el precio sean idénticos. El mensaje del experto contiene suficiente contexto como para que el agente nunca tenga que detenerse a adivinar.

La última fila es igualmente importante. Después de que una sesión se desviara del rumbo, alrededor del 19 % de los principiantes abandonaron sin producir código alguno, frente al 5 al 7 % de los expertos. La habilidad determinante no es la forma en que se redacta la instrucción, sino la capacidad de devolver una sesión desviada al camino correcto.

Una frase del artículo lo resume: con los principiantes, Claude tiende a corregir al usuario, mientras que con los expertos es el usuario quien corrige a Claude. Esa es la línea que separa usar un agente de ser gestionado por uno.

El bucle de tres pasos que falla

Una rutina común se ve así:

Bad:
Prompt → AI writes code → Accept

Dos de esos tres pasos corresponden al agente. No hay requisitos, ni contexto, ni plan, ni verificación. Eso no es delegar trabajo de ingeniería; es completar automáticamente a un nivel más detallado con la esperanza de que el resultado sea correcto.

Un bucle de siete etapas que funciona

La rutina que sobrevivió al uso en una aplicación de trading en producción tiene siete etapas:

Better:
Requirement
↓
Context
↓
Plan
↓
Agent implementation
↓
Build
↓
Tests
↓
Human review

El ingeniero es responsable de las tres primeras etapas y las dos últimas, mientras que el agente se ocupa de lo que está en medio. Esta proporción refleja los resultados de la investigación, con una división del 70/30 en la planificación y del 80/20 en la ejecución, representada como un pipeline. Cada etapa conlleva su propio costo.

Requisito

Una instrucción como “Agregar una hoja de confirmación al flujo del pedido” cuenta como una tarea. Un agente puede crear algo que técnicamente esté correcto pero funcionalmente fallido. Un requisito válido implica mucho más:

Order confirmation sheet, SwiftUI, presented from OrderEntryViewController.

Must show: instrument code, side (BUY/SELL), quantity in lots,
limit price, estimated total including fee, and account buying power
AFTER the order.

Buying power must be recomputed, never passed in from the entry screen.
If recompute fails, disable confirm and show the retry state.
Never show a stale number next to a confirm button.

La última línea de esa especificación se refiere al conocimiento del dominio, y ningún modelo lo posee. Es lo que diferencia una pantalla que funciona de una que genera una constatación regulatoria. Esto se corresponde con la señal de “precisión de dirección” de la investigación, y es la más económica de solucionar.

Contexto

Cuando UIKit y SwiftUI coexisten bajo la Arquitectura Limpia, un agente creará su propio patrón si no se muestra ninguno, y cada patrón inventado se convertirá posteriormente en un comentario de revisión. Por eso, primero se le muestran al agente ejemplos reales: el protocolo del caso de uso actual, una implementación de repositorio, el ViewModel que realiza la tarea más cercana y el archivo CLAUDE.md del módulo con sus reglas de capas. Tres archivos y un documento de convenciones superan siempre a tres párrafos de explicación. Casi todos saltan esta etapa, aunque es la que más beneficios aporta.

Plan

Solicite un plan antes de cualquier código, indicando qué archivos cambian, qué capa se encarga de cada cambio, qué expone el ViewModel y qué recibe las pruebas. Úselo como si fuera una descripción de PR. Rechazar un plan lleva unos noventa segundos. Rechazar una implementación toma veinte minutos y deja un diff que debe descartarse mentalmente.

Aproximadamente un tercio de los planes se modifican, casi siempre por cuestiones relacionadas con la estructura en capas, como cuando el agente coloca un cálculo en el ViewModel cuando debería estar en un caso de uso. Corregirlo en texto plano es sencillo, pero hacerlo en Swift no lo es.

Implementación

Una vez acordado el plan, quédense al margen. Aquí es donde se toman el 80% de las decisiones de ejecución: la denominación, el flujo de control, cómo estructurar una diferencia entre versiones y qué herramienta auxiliar utilizar. Interrumpir para criticar el nombre de una variable es lo que hace que una sesión con doce acciones se convierta en una con cinco. Además, consume la atención de los ingenieros senior para obtener resultados de los ingenieros junior.

Verificación

La instrucción con el mejor resultado indica que el trabajo no está terminado hasta que el código se compila y las pruebas pasan, siendo el agente quien ejecuta ambas tareas por sí mismo. La investigación describe esto como lo que el usuario pide a Claude que verifique, y es la señal que más se subestima. Un agente capaz de ejecutar xcodebuild y los objetivos de prueba cierra su propio ciclo. Uno que carece de esa capacidad devuelve un borrador y lo etiqueta como una función.

En cuanto a la hoja de confirmación, superar las pruebas implica que se cumplan los comportamientos concretos listados previamente. Es necesario volver a calcular el poder adquisitivo al presentar la hoja; el botón de confirmación debe permanecer desactivado mientras se realiza ese cálculo, y los cálculos de las tarifas deben coincidir con los parámetros ya establecidos en el repositorio.

Revisión

Cada línea se lee detenidamente. Esto no se debe a que el código sea generalmente deficiente, ya que normalmente no lo es. La revisión es donde la experiencia humana sigue siendo necesaria en el sistema. La lectura busca detectar aquello que una compilación sin errores no puede identificar: si el cambio respeta los límites de las capas, si la regla de redondeo es la misma que realmente utiliza el departamento financiero y si la máquina de estados puede manejar la interrupción de la conexión en medio del proceso de confirmación.

Esta etapa también representa el verdadero límite en la capacidad de procesamiento. Un agente puede generar más trabajo del que cualquiera puede revisar de manera responsable, y la tendencia a hacerlo de forma superficial es el verdadero peligro de todo el flujo de trabajo. El riesgo no radica tanto en las alucinaciones como en el cansancio.

La dirección que toma el trabajo

La tendencia de siete meses dentro de las 400,000 sesiones merece cierta atención:

• La proporción de sesiones dedicadas a la depuración disminuyó, pasando de un tercio (33%) a 19%.
• La ejecución de software en funcionamiento aumentó al 21%, después de comenzar en el 14%.
• La redacción junto con el análisis de datos se duplicó aproximadamente, pasando de alrededor de una décima parte a alrededor de una quinta parte de las sesiones.

La búsqueda de errores lleva menos tiempo, mientras que operar y razonar sobre los sistemas en ejecución requiere más tiempo. En el mismo período, el valor estimado de las tareas aumentó aproximadamente un 25%, y las tareas de desarrollo subieron alrededor del 43%. El trabajo no está desapareciendo; simplemente se está trasladando a un nivel superior, lejos de la escritura directa de implementaciones hacia su especificación, orquestación y verificación, lo cual coincide con la forma en que siempre ha trabajado un ingeniero senior con un equipo.

El cuello de botella es el bucle

Nueve de cada diez desarrolladores utilizan estas herramientas todas las semanas, pero solo del 15 al 33% de las sesiones terminan con éxito verificado. Por lo tanto, el modelo nunca fue la limitación real. La mayoría de las personas simplemente aplican un bucle de tres pasos con una herramienta diseñada para siete.

Mejorar el prompt no solucionará el problema. La solución consiste en establecer criterios de evaluación donde se genera el problema, es decir, definir qué se considera “correcto” desde un principio y confirmar al final que se ha cumplido. El agente se encarga de la parte intermedia y lo hace bien, en proporción a cuán claramente estén definidos los límites.

En 2026, quienes obtienen el mayor beneficio de los agentes de programación no son aquellos que crean prompts más ingeniosos, sino quienes deciden qué significa “terminado”.