84% de Desarrolladores Usa IA. 29% Confía en Ella. La Habilidad Que Falta No Es Revisar. Es Rechazar.
Hace dos días abrí mi dashboard de Claude Code. Quería ver cuántos outputs había matado (matados antes de revisión, antes del diff, matados porque tres segundos bastaron para ver que la cosa no tenía salvación...). El ratio me golpeó. La gran mayoría de outputs en bruto nunca pasaron mi primer filtro. No revisables. No arreglables. Pura basura. (admítelo, tienes el mismo gráfico esperándote)
En 2024 estaba arreglando. En 2026 me niego. Ya no es el mismo trabajo.
TLDR: Stack Overflow publicó su encuesta de 2025. 84% de devs usa AI, 29% confía en ella. Entre esos dos números, un abismo. Todos lo nombraron. Sonar lo llama el Verification Gap. Osmani lo llama el Problema del 70-80%. Todos recetaron el mismo remedio: revisar mejor, revisar más, revisar con mejores herramientas. Excepto que revisar asume que el output es revisable. Y cuando no lo es, cada minuto de revisión es un impuesto. Hay una habilidad que nadie ha documentado aún. La que ocurre antes de la revisión.
El Número Que No Quería Ver
Un amigo me preguntó cuántos outputs de Claude Code realmente conservo. Dije "la mayoría" porque eso era lo que asumía. Luego revisé /insights. La mayoría no era la respuesta.
El gráfico mostraba algo que había estado haciendo sin nombrarlo. No estaba "arreglando" outputs de AI la mayor parte del tiempo. Los estaba rechazando. Tres segundos de scroll, un vistazo a la lista de archivos, una ojeada a las firmas de funciones, y la cosa se iba a git reset --hard. Sin revisión. Sin diff. Sin investigación. Muerto.
Lo que me molestó no fue la tasa de eliminación. Fue darme cuenta de que había estado haciendo esto durante meses sin llamarlo de ninguna manera. No hay sección para esto en ningún artículo sobre AI coding que haya leído. Nadie lo enseña. Nadie lo benchmarkea. El :wq de la era AI. Nadie lo shipea como feature porque nadie lo ha visto aún.
Así que empecé a prestar atención. ¿Qué hace que un output sea rechazable en tres segundos? ¿Qué señales leo sin pensar? ¿Por qué los juniors siguen "tratando de hacerlo funcionar" cuando la jugada correcta es reset --hard?
Cinco señales siguieron apareciendo. Misma forma cada vez.
Todos Nombraron Lo Mismo
La encuesta 2025 de Stack Overflow salió con los números que todos citaron. 84% de desarrolladores ahora usa o planea usar herramientas AI, subiendo del 76% del año anterior. La mitad de la profesión las usa diariamente. La confianza en precisión cayó del 40% al 29%. Solo 3% reporta alta confianza. 46% desconfía activamente de sus propias herramientas. 66% dice que la AI les da código que está "casi bien pero no del todo". 45% encuentra que debuggear código generado por AI es más lento que escribir desde cero.
Casi la mitad de la profesión ahora gasta más tiempo debuggeando AI de lo que gastarían escribiendo la cosa ellos mismos. La adopción sigue subiendo de todas formas.
Sonar hizo su propia encuesta, publicada en enero. Muestra diferente, misma forma: 96% no confía completamente en el output, y solo 48% realmente lo verifica. Acuñaron un término para el abismo: Verification Gap. Nombre limpio, diagnóstico equivocado.
Addy Osmani teorizó el mismo fenómeno desde otro ángulo en "The 80% Problem in Agentic Coding." AI resuelve 80% del problema en minutos. El 20% restante cuesta exactamente lo que solía costar. Citó a Karpathy diciendo, "Realmente estoy programando principalmente en inglés ahora," describiendo el flip donde el trabajo humano se reduce a edits y retoques. Citó a Boris Cherney, quien construyó Claude Code, diciendo que esencialmente todo el código de Anthropic ahora es escrito por Claude mismo. Ese es el techo del paradigma actual.
Todas estas piezas apuntaban a un problema real. Todas prescribieron la misma cura. Revisar mejor. Construir herramientas de revisión. Contratar revisores AI-fluent. Agregar capas de verificación.
Excepto que la cura presume que el paciente es tratable. Escribí sobre este mismo diagnóstico erróneo cuando Bloomberg publicó su pieza de pánico de productividad el mes pasado: Bloomberg is diagnosing the wrong disease. La industria sigue nombrando los síntomas y perdiendo el tratamiento. La revisión solo funciona en outputs revisables.
La Cura de Revisión Escaló Para Un Dev. Se Rompe En 150 Agentes.
El playbook de revisión no estaba mal. Estaba bien para la forma del trabajo en 2023.
Un dev, un output, un PR, un revisor. Lees el diff. Entiendes lo que el modelo intentó. Corriges. Mergeas. El costo era lineal, y los números de Osmani dicen que creció: los PRs se volvieron cerca de 18% más grandes conforme subió la adopción de AI, incidentes por PR subieron alrededor de 24%, tasas de falla de cambios subieron cerca de 30%. Doloroso, pero manejable. Podías contratar más revisores. Podías agregar herramientas de diff. Podías endurecer templates de PR.
Todo ese playbook presupone que el dev es el cuello de botella de lectura. Cuando generas cinco outputs al día, leer es factible. Cuando generas cincuenta, ya estás ahogándote. Cuando generas más que eso, leer cada diff no es solo lento, es físicamente imposible.
Así que la cura de revisión cambia de forma silenciosamente. "Lee cada línea" se convierte en "confía en el agent-reviewer para leer cada línea por ti." Que es como terminas con /ultrareview y sus primos. Revisión delegada downstream. Pero delegación no es la misma jugada que rechazo, y volveré a eso.
El cuello de botella dejó de ser lectura. Se movió a la decisión antes de que ocurra la lectura: ¿vale la pena leer este output para nada?
El rechazo es el nuevo paso de compilación. Corre antes de la lectura.
Las Cinco Señales de Rechazo Inmediato
La mayoría de mis rechazos encajan en cinco patrones. Ninguno necesita un diff. Ninguno necesita investigación. Son señales que aprendes a leer quemando horas en los outputs que te enseñaron.
Señal 1: API Fabricada. El modelo inventa una función, un endpoint, un método de librería. Una vez que esto pasa una vez en el output, toda la cosa está estructuralmente contaminada. La llamada alucinada se sienta dentro de lógica que fue construida asumiendo que la llamada existe. La lógica por tanto está formada por una mentira. Arreglar la una línea no arregla el output, arregla el síntoma. Rechaza. Re-promptea con la superficie real de API en contexto. Toma dos minutos en lugar de veinte.
Señal 2: Contrato Roto. Escribiste una restricción en el prompt. "Solo SQL, no ORM." "No toques middleware de auth." "Funciones puras, sin efectos secundarios." Y el output lo viola. No porque el modelo olvidó. Porque el modelo decidió que su manera era mejor. No renegocías un contrato después de la entrega. El punto de un contrato es que una violación no es un bug que parcheas, es un trigger para rechazo. Escribí el framework completo de prompt contracts alrededor de exactamente esta jugada. El contrato es lo que hace el rechazo rápido. Sin contrato, sin rechazo, solo revisión infinita.
Señal 3: Tiempo-para-Entender Excede Umbral. Has estado mirando el diff por diez minutos. Aún no puedes decir qué estaba tratando de hacer el modelo. Desde Opus 4.7, outputs confiados no significan outputs legibles. Cuando tu tiempo-para-entender excede tu tiempo-para-reescribir, rechaza. Reescribir desde cero no es una falla, es una jugada. El modelo generó un scaffold que no pediste. Tira el scaffold. Pregunta de nuevo con mejor spec.
Señal 4: Escrituras Fuera-de-Scope. Pediste un fix en un archivo. El output toca otros tres. Tu cerebro va déjame solo revisar qué cambió en los otros. Esa oración es una trampa. El modelo eligió reescribir cosas que no autorizaste. La pregunta no es "¿son correctos los otros cambios?" La pregunta es "¿los autoricé?" ¿No? Rechaza. Re-promptea con scope de archivo explícito. Y sí, perderás las partes buenas que estaban en las escrituras fuera-de-scope. Ese es el impuesto por no rechazar antes.
Señal 5: "Déjame probar y ver." El modelo corre algo, lo ve fallar, luego lo "arregla" adivinando. Sin teoría de por qué el fix debería funcionar. Sin explicación de por qué el original falló. Solo parcheo estocástico contra el output de la última corrida. Esto no es ingeniería, es while true; do; pray; done. Rechaza. Promptea de nuevo con el stack trace, la causa sospechada, y una demanda de diagnóstico, no un parche.
Estos cinco cubren fácilmente nueve de cada diez kills. El resto es solo cosas raras. Modelos teniendo un mal día. Prompts en los que debería haber pensado más. No vale la pena un framework.
Cinco señales. Tres segundos cada una. Quince segundos para salvar una mañana.
Por Qué Rechazar Es Culturalmente Difícil
El reflejo del dev es "hazlo funcionar." Treinta años de ese reflejo. Print statements a las 2 AM, tabs de Stack Overflow apilados, la satisfacción de luchar con una cosa rota de vuelta a la forma. Es la identidad central de la profesión para muchos de nosotros.
La era AI rompe este reflejo de una manera específica. Antes, código roto estaba roto porque lo escribiste mal. Arreglarlo te enseñaba algo. Ahora, código roto está roto porque un modelo estocástico sampló mal. Arreglarlo no te enseña nada, porque no hay patrón repetible que internalizar. No estás debuggeando un error, estás puliendo a mano una moneda que se estampó torcida.
El reflejo senior, "siempre puedo salvar esto", es exactamente lo que te cuesta. Tu pattern matching es tan bueno mapeando código roto a "aquí está el fix" que entras en modo salvamento automáticamente. No notas que has estado salvando por cuarenta minutos en una cosa que habría tomado tres minutos re-promptear. ¿El 45% de devs que le dicen a Stack Overflow que debuggear AI es más lento que escribir desde cero? Muchos de ellos son seniors. Llegaron ahí porque su reflejo de salvamento es demasiado fuerte para dejar morir un output.
El músculo de rechazo duele porque va contra tres décadas de "buenos devs no se rinden." No estás triageando un paciente. Estás cerrando un tab malo.
Lo Que 150 Agentes Me Enseñaron Sobre la Tasa de Rechazo
Corro aproximadamente 150 agentes AI a través de mi stack. Algunos generan código. Algunos escriben copy. Algunos clasifican señales. Algunos hacen ops. A esa escala no puedes revisar todo. Ni siquiera puedes arreglar todo. Solo puedes rechazar rápido y re-promptear.
Las matemáticas son brutales. Si aceptas un output que necesitaba ser rechazado, el costo no aparece hoy. Aparece tres semanas después, cuando un comportamiento raro en prod se rastrea de vuelta a una línea que nadie entendió cuando se shipeó. El análisis multi-año de GitClear, que Osmani citó, vio duplicación de código saltar 48% y refactoring colapsar de un cuarto de todos los cambios a menos de un décimo. Esa es la deuda silenciosa. Aceptado-cuando-debería-haber-sido-rechazado, shipeado, olvidado, detonando después.
Los devs que rechazan demasiado temprano pierden victorias. El modelo puede hacer buen trabajo. Matar su primer intento en cada tarea es desperdicio. El punto dulce no es "rechazar todo" o "arreglar todo." Es rechazar rápido, re-spec, aceptar. El ciclo solía ser prompt → revisar → arreglar. En 150 agentes es prompt → triage de tres segundos → rechazar o aceptar. La revisión viene solo dentro de la rama de aceptar, y para entonces la mayoría de los outputs malos ya han sido matados.
La revisión es lo que haces después del triage. El triage es el trabajo.
La Trampa: /ultrareview como Aceptación Lavada
Anthropic shipeó /ultrareview con Opus 4.7. Revisión de código multi-agente: varios agentes leen el diff, marcan issues, reportan de vuelta. Suena como la respuesta a la explosión de revisión que Osmani describió. No lo es.
La mecánica va así. Obtienes un output. No confías en él. Corres /ultrareview. Tres agentes lo leen. Encuentran dos cosas pequeñas. Arreglas las cosas pequeñas. Shipeas. Te sientes revisado.
Excepto que ninguno de esos tres agentes puede invalidar el paradigma. Pueden encontrar bugs. Pueden encontrar issues de estilo. No pueden decirte "este enfoque está mal, rechaza toda la cosa." Están entrenados para encontrar issues, no para matar outputs. Esa es una diferencia sutil que importa enormemente en producción.
Lo que pasa en práctica: delegas la decisión de rechazo a un agente cuya arquitectura no puede rechazar. Es Karen de Contabilidad aprobando el reporte de gastos porque las matemáticas cuadran, sin revisar si el viaje debería haber pasado para nada. Los números balancean, el viaje fue un desastre.
La trampa es que /ultrareview se siente como diligencia debida. Has revisado. Múltiples agentes revisaron. Todos revisaron. Nadie rechazó.
Para ser justo, /ultrareview es útil en cambios no críticos. Tests internos, boilerplate, refactoring a nivel de formato, el tipo de cosas donde el paradigma es obviamente correcto y solo quieres ojos extra en la ejecución. Úsalo ahí. En paths críticos, dinero, auth, escrituras de data, la decisión de rechazo se queda con un humano. No porque los humanos sean más inteligentes, sino porque los humanos tienen permitido decir "empezar de nuevo" y los agentes no.
Si no puedes rechazar, solo puedes parchear. Sistemas parcheados shipean más rápido. También mueren más pronto.
La Prueba de Seniority 2026
La prueba de seniority del dev solía ser "¿puedes debuggear esto?" Después se volvió "¿puedes arquitecturar esto?" Por un tiempo en los 2020s parecía que se estaba volviendo "¿puedes promptear esto?"
En 2026 es algo más. Cuánto rechazas, y qué tan rápido.
No cuánto shipeas. No cuánto revisas. No qué tan grueso está tu PR. Cuánto matas antes de que drene tu día. Esa es la métrica que separa al dev que shipeó 22 PRs ayer del dev que pasó el mismo día puliendo a mano tres outputs que nunca iban a funcionar.
Stack Overflow dice que 69% de devs reporta que AI ha boosteado su productividad personal. Lo creo. El catch es dónde va el boost. Para la mayoría va a tiempo de revisión, porque ese es el único músculo que les han enseñado a usar. Para unos pocos va a un loop de rechazo más corto, y esos pocos shipean significativamente más que el resto.
La industria seguirá apilando herramientas de revisión. /ultrareview, diff multi-agente, AI que revisa AI. Los prompts se volverán specs, specs se volverán planes, planes se volverán ceremonias. Todos agregando una capa para sentirse tranquilos sobre lo que sale del pipe.
Mientras tanto los devs que shipean habrán soltado el reflejo "puedo salvar este código." Tres segundos de mirar el output. Matar. Re-spec. Ir de nuevo. Sin drama, sin diff heroico de las 2 AM. Solo triage, luego de vuelta al trabajo. 🔥
Stack Overflow contó lo que aceptamos. El verdadero indicador 2026 es lo que rechazamos.
Escribe menos. Revisa menos. Rechaza más. Shipea mejor.
Fuentes
- Stack Overflow 2025 Developer Survey: survey.stackoverflow.co/2025/ai
- Addy Osmani, "The 80% Problem in Agentic Coding": addyo.substack.com
- Sonar State of Code Developer Survey, January 2026: sonarsource.com