Título original: Arnés delgado, habilidades descomunales
Autor original: Garry Tan
Recopilado por: Peggy, BlockBeats
Nota del editor: Si bien la respuesta por defecto de la industria se ha convertido en "modelos más robustos", este artículo ofrece una perspectiva diferente: lo que realmente crea una brecha de productividad de 10, 100 o incluso 1000 veces no es el modelo en sí, sino más bien el diseño de todo el sistema construido en torno a ese modelo.
El autor de este artículo, Garry Tan, es el actual presidente y director ejecutivo de Y Combinator y lleva mucho tiempo involucrado en el ecosistema de la IA y las startups en fase inicial. Propone un marco de "habilidades sólidas + estructura ágil", que descompone las aplicaciones de IA en componentes clave como habilidades, marco operativo, enrutamiento contextual, división de tareas y compresión del conocimiento.
En este sistema, el modelo ya no representa la totalidad de la capacidad, sino que es simplemente una unidad de ejecución dentro del sistema; lo que realmente determina la calidad del resultado es cómo se organiza el contexto, se refina el proceso y se definen claramente los límites entre el "juicio" y el "cálculo".
Más importante aún, este enfoque no es meramente conceptual, sino que ha sido validado en escenarios reales: al enfrentarse a tareas de procesamiento y comparación de datos de miles de emprendedores, el sistema alcanza capacidades de análisis casi humanas mediante un ciclo de "leer, organizar, evaluar y volver a escribir", y se optimiza continuamente sin necesidad de reescribir código. Este "sistema de aprendizaje" transforma la IA de una herramienta puntual en una infraestructura con efectos acumulativos.
De este modo, queda claro el mensaje central del artículo: en la era de la IA, la brecha de eficiencia ya no depende de si se utilizan los modelos más avanzados, sino de si se ha construido un sistema que pueda acumular capacidades de forma continua y evolucionar automáticamente.
El siguiente es el texto original:
Steve Yegge afirmó que las personas que utilizan agentes de programación de IA son "entre 10 y 100 veces más eficientes que los ingenieros que solo utilizan herramientas de chat y cursor para escribir código, y aproximadamente 1000 veces más eficientes que los ingenieros de Google en 2005".
Nota: Steve Yegge es un influyente ingeniero de software, bloguero tecnológico y comentarista sobre la cultura de la ingeniería en Silicon Valley, conocido por sus artículos técnicos incisivos, extensos y muy personales. Trabajó como ingeniero sénior en empresas como Amazon y Google; posteriormente se unió a Salesforce; y luego trabajó en startups y en campos relacionados con la IA; además, fue uno de los primeros promotores del proyecto Dart.
Esto no es una exageración. Lo he visto con mis propios ojos y lo he experimentado de primera mano. Pero cuando la gente oye hablar de esta diferencia, a menudo la atribuye a factores equivocados: un modelo más robusto, un Claude más inteligente, más parámetros.
En realidad, quienes duplican su eficiencia y quienes la multiplican por cien utilizan el mismo modelo. La diferencia no radica en la "inteligencia", sino en la "arquitectura", y esta arquitectura es tan simple que puede escribirse en una sola tarjeta.
Harness (el marco de ejecución) es el producto en sí.
El 31 de marzo de 2026, Anthropic publicó accidentalmente el código fuente completo de Claude Code en npm: un total de 512 000 líneas. Lo leí entero. Esto confirma lo que he estado diciendo en Y Combinator: el verdadero secreto no está en el modelo, sino en "la capa que lo envuelve".
Contexto de repositorio de código en tiempo real, almacenamiento en caché de indicaciones, herramientas específicas para tareas, minimización de contexto redundante, memoria de sesión estructurada y subagentes que se ejecutan en paralelo: estas características no hacen que el modelo sea más inteligente. Sin embargo, le proporcionan el "contexto adecuado" en el "momento adecuado", evitando que se vea saturado de información irrelevante.
Este "envoltorio" se denomina arnés (marco operativo). La verdadera pregunta que todos los desarrolladores de IA deberían hacerse es: ¿qué se debe incluir en el arnés y qué se debe dejar fuera?
Esta pregunta tiene, de hecho, una respuesta muy específica, que yo denomino: arnés delgado, habilidades gruesas.
Cinco definiciones
El cuello de botella nunca ha sido la inteligencia del modelo. El modelo siempre ha sabido razonar, sintetizar información y escribir código.
Fracasan porque no comprenden tus datos: tu esquema, tus convenciones y la naturaleza específica de tu problema. Las siguientes cinco definiciones están diseñadas precisamente para abordar este problema.
1. Archivo de habilidades
Un documento de habilidades es un documento Markdown reutilizable que enseña a un modelo "cómo hacer algo". Cabe destacar que no le indica "qué hacer"; eso lo proporciona el usuario. El documento de habilidades proporciona el proceso.
El punto clave que la mayoría de la gente pasa por alto es que un archivo skill es esencialmente como una llamada a un método. Puede aceptar parámetros. Se puede llamar con diferentes parámetros. El mismo proceso puede presentar capacidades drásticamente diferentes según los parámetros que se le pasen.
Por ejemplo, existe una habilidad llamada `/investigate`. Consta de siete pasos: definir el alcance de los datos, crear una línea de tiempo, registrar cada documento, sintetizar y resumir, argumentar desde ambas perspectivas y citar las fuentes. Acepta tres parámetros: `TARGET`, `QUESTION` y `DATASET`.
Si se le asigna un científico de seguridad y 2,1 millones de correos electrónicos forenses, se convierte en un analista de investigación médica que determina si se ha silenciado a un denunciante.
Si se le vincula con una empresa fantasma y con los documentos presentados ante la Comisión Federal Electoral (FEC), se convierte en un investigador forense que rastrea las donaciones políticas coordinadas.
Es la misma habilidad. Los mismos siete pasos. El mismo archivo Markdown. La descripción de la habilidad es un proceso de toma de decisiones, pero lo que realmente lo traduce al mundo real son los parámetros que se pasan durante la llamada.
Esto no es ingeniería de precisión, sino diseño de software: solo que aquí usamos Markdown como lenguaje de programación y el juicio humano como entorno de ejecución. De hecho, Markdown es incluso más adecuado para encapsular funcionalidades que el código fuente rígido, ya que describe procesos, juicios y contexto, precisamente los lenguajes que el modelo "entiende" mejor.
2. Arnés (Marco de ejecución)
Harness es la capa que permite que el LLM se ejecute. Realiza solo cuatro funciones: ejecutar el modelo en un bucle, leer y escribir los archivos, gestionar el contexto y aplicar restricciones de seguridad.
Eso es todo. Esto es lo que significa "delgado".
El patrón opuesto es: arnés grueso, habilidades escasas.
Probablemente hayas visto cosas como esta: más de 40 definiciones de herramientas, cuyas descripciones ocupan la mitad de la ventana de contexto; una herramienta todopoderosa que tarda entre 2 y 5 segundos en completar una operación de ida y vuelta en MCP; o encapsular cada punto final de una API REST en una herramienta independiente. El resultado es que el uso de tokens se triplica, la latencia se triplica y la tasa de fallos se triplica.
El enfoque verdaderamente ideal consiste en utilizar herramientas diseñadas para un propósito específico, que sean rápidas y tengan una funcionalidad limitada.
Por ejemplo, la interfaz de línea de comandos de Playwright tarda solo 100 milisegundos por operación de navegador, mientras que el panel de control de Chrome tarda 15 segundos en realizar una operación de captura de pantalla → búsqueda → clic → espera → lectura. La primera es 75 veces más rápida.
El software moderno ya no necesita estar "excesivamente pulido hasta el punto de resultar inflado". Lo que debes hacer es: crear solo lo que realmente necesitas, y nada más.
3. Resolver
Un resolvedor es esencialmente una tabla de enrutamiento de contexto. Cuando ocurre una tarea de tipo X, el documento Y se carga primero. Las habilidades le indican al modelo "cómo hacerlo"; los resolvedores le indican al modelo "cuándo cargar qué".
Por ejemplo, un desarrollador modifica una solicitud. Sin un resolvedor, podría publicar la actualización inmediatamente después de realizar los cambios. Con un resolvedor, el modelo primero lee docs/EVALS.md. Este documento indica: primero ejecute el conjunto de pruebas de evaluación y compare las puntuaciones antes y después; si la precisión disminuye en más del 2 %, revierta los cambios e investigue la causa. Es posible que este desarrollador ni siquiera conociera el conjunto de pruebas de evaluación. El resolvedor, en el momento adecuado, carga el contexto correcto.
Claude Code cuenta con un resolvedor integrado. Cada habilidad tiene un campo de descripción, y el modelo relaciona automáticamente la intención del usuario con la descripción de la habilidad. No es necesario recordar si la habilidad o el barco existen; la descripción misma actúa como resolvedor.
Para ser sincero, mi antiguo archivo CLAUDE.md tenía la friolera de 20 000 líneas. Abarcaba todas mis peculiaridades, todos mis patrones y todas las lecciones que había aprendido. Era totalmente absurdo. La capacidad de atención del modelo disminuyó notablemente. Incluso decidí eliminar por completo el código de Claude.
La solución final consistió en apenas unas 200 líneas, conservando solo algunos punteros a documentos. El resolvedor cargaría únicamente el documento necesario en el momento crítico. De esta forma, las 20 000 líneas de conocimiento seguirían estando fácilmente accesibles sin saturar la ventana de contexto.
4. Latente y determinista (Espacio latente y determinismo)
En su sistema, cada paso pertenece a una categoría u otra. Confundir estas dos categorías es el error más común en el diseño de agentes.
El espacio latente es donde reside la inteligencia. Aquí, el modelo lee, comprende, juzga y toma decisiones. Procesa juicios, sintetiza información y reconoce patrones.
• El determinismo es donde reside la fiabilidad. La misma entrada siempre producirá la misma salida. Las consultas SQL, el código compilado y las operaciones aritméticas entran en esta categoría.
Un modelo de gestión latente (MLL) puede ayudarte a sentar a 8 personas en una cena, teniendo en cuenta la personalidad y las relaciones sociales de cada una. Pero si le pides que siente a 800 personas, elaborará una distribución de asientos que "parece razonable, pero en realidad es completamente errónea". Esto se debe a que ya no se trata de un problema que el espacio latente pueda resolver, sino de un problema determinista que se ha visto forzado a entrar en el espacio latente: un problema de optimización combinatoria.
Los peores sistemas siempre ubican erróneamente las tareas a ambos lados de esta línea divisoria. Los mejores sistemas, en cambio, establecen límites claros y precisos.
5. Diarización (Organización de documentos / Perfilado temático)
El paso de la diarización es clave para que la IA pueda generar valor real para el trabajo basado en el conocimiento en el mundo real.
Esto significa que el modelo analiza todos los materiales relacionados con un tema y luego elabora un perfil estructurado. Condensa las conclusiones de decenas o incluso cientos de documentos en una sola página.
Esto no es algo que puedan generar las consultas SQL. Tampoco es algo que pueda generar un pipeline RAG. El modelo debe leer los datos, tener en cuenta la información contradictoria simultáneamente, detectar qué ha cambiado y cuándo ha cambiado, y luego sintetizar todo esto en inteligencia estructurada.
Esta es la diferencia entre las consultas a bases de datos y los informes para analistas.
Esta arquitectura
Estos cinco conceptos se pueden combinar en una arquitectura de tres niveles muy sencilla.
• En la capa superior se encuentran las habilidades más complejas: procesos escritos en Markdown que contienen juicios, metodologías y conocimiento del dominio. El 90% del valor reside en esta capa.
En el centro hay una sencilla interfaz de línea de comandos: unas 200 líneas de código, que toma JSON como entrada, genera texto y es de solo lectura por defecto.
En la base se encuentra el sistema de su aplicación: QueryDB, ReadDoc, Search, Timeline; estas son infraestructuras deterministas.
El principio fundamental es direccional: impulsar la "inteligencia" hacia arriba, hacia las habilidades; impulsar la "ejecución" hacia abajo, hacia las herramientas deterministas; y mantener el sistema ligero.
El resultado es que, cada vez que mejoran las capacidades del modelo, todas las habilidades se fortalecen automáticamente, mientras que el sistema determinista subyacente permanece estable y fiable.
Un sistema de aprendizaje
A continuación, utilizaré un sistema real que estamos desarrollando en YC para demostrar cómo funcionan conjuntamente estas cinco definiciones.
Julio de 2026, Chase Center. La Startup School contó con la participación de 6000 fundadores. Cada persona presentó una solicitud estructurada, respuestas a cuestionarios, transcripciones de conversaciones individuales con mentores y registros públicos: publicaciones en X, historial de commits en GitHub y uso de Claude Code (que mostraba su velocidad de desarrollo).
El método tradicional consiste en que un equipo de proyecto de 15 personas lea cada solicitud, emita un juicio intuitivo y, a continuación, actualice el formulario.
Este método funciona con 200 personas, pero fracasa por completo con 6000. Ningún ser humano puede retener tantos perfiles en su mente al mismo tiempo y darse cuenta de que los tres mejores candidatos para la infraestructura de agentes de IA son el fundador de una herramienta de desarrollo en Lagos, un emprendedor de cumplimiento normativo en Singapur y un desarrollador de herramientas de línea de comandos en Brooklyn, y que describieron el mismo problema de maneras completamente diferentes en distintas conversaciones individuales.
El modelo puede hacer esto. El método es el siguiente:
Enriquecimiento (Mejora de la información)
Existe una habilidad llamada /enrich-founder, que recopila todas las fuentes de datos, realiza la ampliación y la creación de diarios de información, y resalta las diferencias entre "lo que dice el fundador" y "lo que realmente hace".
El sistema determinista subyacente gestiona consultas SQL, datos de GitHub, pruebas de navegador con URL de demostración, extracción de señales sociales, consultas de CrustData, etc. Una tarea programada se ejecuta una vez al día. Los perfiles de 6000 fundadores se mantienen siempre actualizados.
El resultado de la diarización puede capturar información que las búsquedas por palabras clave no pueden encontrar en absoluto:
Fundadora: Maria Santos Empresa: Contrail (contrail.dev) Autodescripción: "El Datadog de los agentes de IA" Trabajo real: el 80% de las confirmaciones de código se concentran en el módulo de facturación → En esencia, se trata de construir una herramienta FinOps disfrazada de observabilidad.
Esta discrepancia entre la declaración y el comportamiento real exige leer simultáneamente el historial de confirmaciones de GitHub, los documentos de la solicitud y los registros de conversaciones, e integrarlos en el modelo. Ninguna búsqueda de similitud mediante incrustaciones puede lograrlo, ni tampoco el filtrado por palabras clave. El modelo debe leer el documento completo y luego emitir un juicio. (¡Precisamente este es el tipo de tarea que debería ubicarse en el espacio latente!)
Pareo
Aquí es donde "skill = method call" resulta útil.
Utilizar la misma habilidad de emparejamiento tres veces puede generar estrategias completamente diferentes:
/match-breakout: Procesa 1200 personas, agrupadas por dominio, con 30 personas en cada grupo (incrustación + asignación determinista).
/match-lunch: Procesa 600 personas, emparejamiento aleatorio entre dominios, 8 personas por mesa sin repetición: los temas son generados primero por LLM y luego la distribución de los asientos se realiza mediante un algoritmo determinista.
/match-live: Gestiona a los participantes del evento en tiempo real, basándose en la incrustación del vecino más cercano, completando la coincidencia uno a uno en 200 ms y excluyendo a las personas que ya han sido vistas.
Además, el modelo puede realizar juicios que los algoritmos de agrupamiento tradicionales no pueden:
"Santos y Oram son ambas infraestructuras de IA, pero no son competidoras: Santos se encarga de la atribución de costes y Oram de la orquestación. Deberían pertenecer al mismo grupo."
"Kim solicitó herramientas para desarrolladores, pero la conversación individual reveló que estaba trabajando en la automatización del cumplimiento de la normativa SOC2. Debería ser reclasificado como profesional de FinTech/RegTech."
Esta reclasificación es algo que la técnica de incrustación no puede capturar en absoluto. El modelo debe leer la imagen completa.
Ciclo de aprendizaje
Una vez finalizado el evento, una función de mejora leerá los resultados de la encuesta NPS, registrará en un diario los comentarios que sean "aceptables" (no las críticas negativas, sino aquellas que sean "casi perfectas") y extraerá los patrones.
Luego, propondrá nuevas reglas y las reincorporará a la función de emparejamiento:
Cuando los participantes mencionan "infraestructura de IA", pero más del 80% de su código es para módulos de facturación:
→ Clasificado como FinTech, no como Infraestructura de IA
Cuando dos personas del mismo grupo ya se conocen:
→ Reducir el peso correspondiente
Priorizar la introducción de nuevas relaciones
Estas reglas se guardarán en el archivo de habilidades. Entrarán en vigor automáticamente la próxima vez que se ejecute la habilidad. Las habilidades se "auto-reescriben". En el evento de julio, la calificación "aceptable" representó el 12%; en el próximo evento, bajará al 4%.
El archivo de habilidades aprende qué significa "de acuerdo" y el sistema mejora sin que nadie tenga que reescribir el código.
Este modelo se puede transferir a cualquier campo:
Buscar → Leer → Registrar → Contar → Sintetizar
Luego: Investigar → Indagar → Anotar en el diario → Reescribir la habilidad
Si tuviéramos que preguntar cuál es el ciclo más valioso de 2026, sería este. Se puede aplicar a casi todos los escenarios de trabajo basados en el conocimiento.
Las habilidades se pueden mejorar de forma permanente.
Recientemente envié un comando a OpenClaw en X, y la respuesta fue mayor de lo esperado:
Aviso: No se permiten tareas puntuales. Si te pido que hagas algo que se repetirá en el futuro, debes: Primero, procesar manualmente de 3 a 10 muestras y mostrarme los resultados; si los apruebo, escribirlos en un archivo de habilidades; si deben ejecutarse automáticamente, agregarlos a una tarea programada. El criterio es: si tengo que pedírtelo una segunda vez, significa que has fallado.
Esta publicación recibió miles de "me gusta" y más de dos mil veces guardada. Mucha gente pensó que se trataba de una técnica de ingeniería rápida.
En realidad, no, esta es la arquitectura que describí anteriormente. Cada habilidad que escribas representa una mejora permanente del sistema. No se degradará ni se olvidará. Se ejecutará automáticamente a las 3 de la mañana. Y cuando se lance el modelo de próxima generación, todas las habilidades se fortalecerán instantáneamente: la capacidad de juicio de la parte latente mejorará, mientras que la parte determinista se mantendrá estable y confiable.
Esta es la fuente de la afirmación de Yegge sobre una eficiencia 100 veces mayor.
No se trata de modelos más inteligentes, sino más bien de: herramientas sencillas, habilidades sólidas y la disciplina para consolidar todo hasta convertirlo en competencia.
El sistema crecerá con interés compuesto. Constrúyelo una vez y úsalo a largo plazo.
[Enlace original]