Harness delgado, Skill gordo: la verdadera fuente de productividad AI 100 veces mayor

Título original: Harness Delgado, Habilidades Grasas
Autor original: Garry Tan
Traducido por: Peggy, BlockBeats

Autor original: Garry Tan

Fuente original:

Reproducción: Mars Finance

Nota del editor: Cuando “modelos más fuertes” se convierten en la respuesta predeterminada en la industria, este artículo ofrece un juicio diferente: la verdadera diferencia en productividad de 10, 100 o incluso 1000 veces no está en el modelo en sí, sino en todo un sistema de diseño construido alrededor del modelo.

El autor de este artículo, Garry Tan, actual presidente y CEO de Y Combinator, ha estado profundamente involucrado en ecosistemas de IA y startups en etapa temprana. Propone el marco de “habilidades grasas + arnés delgado”, que descompone la aplicación de IA en componentes clave como habilidades, marcos de operación, enrutamiento de contexto, división de tareas y compresión de conocimientos.

Bajo este sistema, el modelo ya no es la totalidad de la capacidad, sino solo la unidad de ejecución del sistema; lo que realmente determina la calidad de la salida es cómo organizas el contexto, sedimentas los procesos y defines los límites entre “juicio” y “cálculo”.

Más importante aún, este método no se queda en el nivel conceptual, sino que ha sido validado en escenarios reales: enfrentando tareas de procesamiento y coincidencia de datos de miles de emprendedores, el sistema mediante un ciclo de “lectura—organización—juicio—escritura” ha logrado capacidades cercanas a las de analistas humanos, y se autooptimiza continuamente sin necesidad de reescribir código. Este “sistema que aprende” transforma a la IA de una herramienta única en una infraestructura con efectos compuestos.

De aquí, la advertencia central del artículo también se vuelve clara: en la era de la IA, la brecha de eficiencia ya no depende de si usas el modelo más avanzado, sino de si construyes un sistema capaz de acumular capacidades de forma continua y autoevolutivo.

A continuación, el texto original:

Steve Yegge dice que, quienes usan agentes de programación con IA, “su eficiencia es de 10 a 100 veces mayor que la de los ingenieros que solo usan Cursor y herramientas de chat para programar, aproximadamente 1000 veces la de los ingenieros de Google en 2005.”

No es una exageración. Lo he visto con mis propios ojos y lo he experimentado personalmente. Pero cuando la gente escucha esa diferencia, tiende a atribuirla a una dirección equivocada: modelos más potentes, Claude más inteligente, más parámetros.

En realidad, las personas que mejoran en eficiencia en 2 veces y en 100 veces usan el mismo conjunto de modelos. La diferencia no está en la “inteligencia”, sino en la “arquitectura”, y esta arquitectura es tan simple que puede resumirse en una tarjeta.

El arnés (marco de operación) es en realidad el producto en sí mismo.

El 31 de marzo de 2026, Anthropic accidentalmente publicó el código fuente completo de Claude Code en npm, con un total de 512,000 líneas. Lo revisé entero. Esto confirma lo que siempre he dicho en YC (Y Combinator): el verdadero secreto no está en el modelo, sino en “la capa que envuelve al modelo”.

El contexto en tiempo real del repositorio de código, la caché de prompts, las herramientas diseñadas para tareas específicas, la compresión de redundancias en el contexto, la memoria estructurada de sesiones, los sub-agentes en paralelo—todo esto no hace que el modelo sea más inteligente. Pero sí permite proporcionar al modelo el “contexto correcto en el momento correcto”, evitando que la información irrelevante lo ahogue.

Esa capa de “envoltura” se llama arnés (harness). Y la pregunta que los constructores de IA deberían hacerse realmente es: ¿qué cosas deben colocarse en el arnés y qué deben dejarse afuera?

La respuesta concreta a esta pregunta, que yo llamo: arnés delgado (thin harness), habilidades grasas (fat skills).

Cinco definiciones

El cuello de botella nunca está en la inteligencia del modelo. Los modelos ya saben cómo razonar, integrar información y escribir código.

Lo que falla es que no entienden tus datos—tu esquema, tus convenciones, la forma específica de tu problema. Y estas cinco definiciones precisamente están diseñadas para resolver ese problema.

1. Skill file (archivo de habilidades)

El archivo de habilidades es un documento markdown reutilizable que enseña al modelo “cómo hacer una cosa”. Atención, no le dice “qué hacer”—eso lo proporciona el usuario. El archivo de habilidades proporciona el proceso.

La clave que muchos ignoran es que: el archivo de habilidades es como una llamada a método. Puede recibir parámetros. Puedes llamarlo con diferentes parámetros. La misma secuencia de pasos puede mostrar capacidades muy distintas dependiendo de los parámetros que le pases.

Por ejemplo, hay una habilidad llamada /investigate. Incluye siete pasos: definir el alcance de los datos, construir la línea de tiempo, diarizar cada documento, resumir e integrar, argumentar desde ambos lados, citar fuentes. Recibe tres parámetros: TARGET, QUESTION y DATASET.

Si lo diriges a un científico de seguridad y 2.1 millones de correos de evidencia, se convierte en un analista de investigación médica que determina si un denunciante fue silenciado.

Si lo diriges a una empresa offshore y a los informes de la Comisión Federal de Elecciones (FEC), se vuelve un investigador forense que rastrea donaciones políticas coordinadas.

Es el mismo skill. Los mismos siete pasos. El mismo archivo markdown. La descripción del proceso de juicio, pero lo que realmente lo hace útil en el mundo real son los parámetros que se pasan al llamarlo.

Esto no es ingeniería de prompts, 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, el markdown incluso es más adecuado que el código rígido para encapsular capacidades, porque describe procesos, juicios y contexto, que son precisamente los lenguajes que el modelo “entiende” mejor.

2. Harness (marco de operación)

El arnés es la capa que impulsa la ejecución del LLM. Solo hace cuatro cosas: hacer que el modelo funcione en un ciclo, leer y escribir archivos, gestionar el contexto, y aplicar restricciones de seguridad.

Eso es todo. Eso es “delgado” (thin).

El modo opuesto sería: un arnés gordo, habilidades delgadas.

Seguramente has visto esto: más de 40 herramientas definidas, con instrucciones que ocupan la mitad de la ventana de contexto; una herramienta omnipotente, que tarda entre 2 y 5 segundos en hacer un ciclo completo; o convertir cada endpoint de API REST en una herramienta independiente. El resultado: triplicar el uso de tokens, triplicar la latencia, triplicar las fallas.

La mejor práctica es usar herramientas diseñadas para un propósito, rápidas y con funciones limitadas.

Por ejemplo, un CLI de Playwright, que realiza cada operación del navegador en 100 ms; en lugar de un MCP de Chrome, que toma 15 segundos para hacer una captura, buscar, hacer clic, esperar y leer. El primero es 75 veces más rápido.

El software actual ya no necesita ser “exquisitamente elaborado y pesado”. Lo que debes hacer es construir solo lo que realmente necesitas, y nada más.

3. Resolver (resolver)

El resolver, en esencia, es una tabla de enrutamiento de contexto. Cuando aparece un tipo de tarea X, carga primero el documento Y. Las skills enseñan “cómo hacerlo”; los resolvers enseñan “cuándo cargar qué”.

Por ejemplo, si un desarrollador modifica un prompt, sin resolver, puede lanzar la versión y listo. Con resolver, el modelo primero lee docs/EVALS.md, que indica: ejecutar la suite de evaluación, comparar puntajes; si la precisión cae más del 2%, hacer rollback y investigar. El desarrollador ni siquiera sabía que existía esa suite de evaluación. Es el resolver quien en el momento correcto carga el contexto adecuado.

Claude Code tiene un resolver incorporado. Cada skill tiene un campo description, y el modelo automáticamente combina la intención del usuario con la descripción del skill. Ni siquiera necesitas recordar si existe /ship—la descripción misma funciona como resolver.

Sinceramente, mi CLAUDE.md anterior tenía 20,000 líneas. Todos los trucos, patrones y lecciones aprendidas estaban allí. Era absurdo. La calidad de atención del modelo se deterioró claramente. Claude Code incluso me llevó a eliminarlo.

La solución final, aproximadamente 200 líneas, solo mantiene algunos punteros a documentos. Cuando se necesita un documento, el resolver lo carga en el momento clave. Así, las 20,000 líneas de conocimiento siguen disponibles, pero sin contaminar la ventana de contexto.

4. Latent y determinista

En tu sistema, cada paso pertenece a una de estas categorías, y confundirlas es el error más común en el diseño de agentes.

·Latent space (espacio latente), es donde reside la inteligencia. Aquí el modelo lee, comprende, juzga y decide. Aquí se trata de: juicio, integración, reconocimiento de patrones.

·Deterministic (determinismo), es donde reside la confiabilidad. La misma entrada produce siempre la misma salida. Consultas SQL, código compilado, cálculos aritméticos, pertenecen a esta categoría.

Un LLM puede ayudarte a organizar una cena para 8 personas considerando sus personalidades y relaciones sociales. Pero si le pides que arme una lista para 800 personas, te dará una “lista de asientos” que parece razonable pero está completamente equivocada. Porque eso ya no es un problema del espacio latente, sino un problema de optimización combinatoria, que debe resolverse en el espacio determinista.

Los sistemas peores confunden mal las funciones en esa línea divisoria. Los mejores la respetan con precisión.

5. Diarization (organización de documentos / perfil temático)

La diarization es la verdadera clave para que la IA aporte valor en el trabajo del conocimiento.

Significa que el modelo lee todo el material relacionado con un tema y produce un perfil estructurado. Resumir en una página las decisiones tomadas en decenas o cientos de documentos.

No es algo que pueda hacer una consulta SQL ni una línea de RAG. El modelo debe leer completo, mantener en la memoria información contradictoria, notar cambios, y consolidar todo en una inteligencia estructurada.

Esa es la diferencia entre una consulta a base de datos y un informe de analista.

Esta arquitectura

Estas cinco ideas pueden combinarse en una estructura muy simple de tres capas:

·La capa superior son habilidades grasas: procesos escritos en markdown que contienen juicios, metodologías y conocimientos del dominio. El 90% del valor está aquí.
·En medio, una capa delgada de arnés CLI: unos 200 líneas de código, que recibe JSON, produce texto, y por defecto solo lee.
·En la base, tu sistema de aplicaciones: QueryDB, ReadDoc, Search, Timeline—infraestructura determinista.

El principio central es tener una dirección: empujar la “inteligencia” hacia arriba en las habilidades; empujar la “ejecución” hacia abajo en herramientas deterministas; mantener el arnés liviano.

El resultado es que, cada vez que el modelo mejora, todas las habilidades también mejoran automáticamente; y los sistemas deterministas en la base permanecen estables y confiables.

Sistemas que aprenden

A continuación, mostraré cómo estos cinco conceptos trabajan juntos en un sistema real que estamos construyendo en YC.

Julio de 2026, Chase Center. Startup School con 6000 fundadores inscritos. Cada uno con materiales estructurados, respuestas a cuestionarios, transcripciones de conversaciones 1:1 con mentores, y señales públicas: publicaciones en X, commits en GitHub, registros de uso de Claude Code (que muestran su velocidad de desarrollo).

El método tradicional sería que un equipo de 15 personas lea cada solicitud, juzgue por intuición y actualice una hoja de cálculo.

Este método funciona hasta unos 200 participantes, pero a 6000 se vuelve completamente inviable. Nadie puede mantener en la cabeza tantos perfiles y darse cuenta de que los tres mejores candidatos para infraestructura de IA son: el fundador de herramientas de desarrollo en Lagos, un emprendedor de cumplimiento en Singapur, y un desarrollador de herramientas CLI en Brooklyn—y que en diferentes conversaciones 1:1 describen el mismo problema con expresiones completamente distintas.

El modelo puede hacerlo. La estrategia es:

Enrichment (enriquecimiento)

Hay una habilidad llamada /enrich-founder, que extrae todos los datos, realiza diarization, y marca las diferencias entre lo que dice el fundador y lo que realmente hace.

El sistema determinista en la base se encarga de: consultas SQL, datos de GitHub, pruebas en navegadores de URLs de demos, captura de señales sociales, consultas a CrustData, etc. Un trabajo programado que corre una vez al día. Los perfiles de 6000 fundadores permanecen siempre actualizados.

La salida de diarization puede detectar información que ninguna búsqueda por embedding puede encontrar:

Las diferencias entre “lo que dicen” y “lo que hacen” requieren leer el historial de commits en GitHub, materiales de solicitud y registros de conversación, y consolidar todo en la memoria. Ninguna búsqueda por similitud de embeddings ni filtrado por palabras clave puede lograr esto. El modelo debe leer completo y juzgar. (¡Justamente esa tarea pertenece al espacio latente!)

Matching (coincidencia)

Aquí es donde el “skill = llamada a método” realmente brilla.

La misma habilidad de coincidencia puede usarse tres veces para estrategias completamente distintas:

/match-breakout: para 1200 personas, agrupar por dominio en clústeres de 30 (embedding + asignación determinista)
/match-lunch: para 600 personas, hacer “coincidencias aleatorias” entre dominios, 8 personas por mesa sin repetir—primero generar temas con LLM, luego asignar asientos con algoritmo determinista
/match-live: para participantes en vivo, hacer coincidencias 1:1 en menos de 200 ms usando embedding de vecinos cercanos, excluyendo a quienes ya se han visto

El modelo también puede hacer juicios que los algoritmos tradicionales no pueden:

“Los Santos y Oram pertenecen a infraestructura de IA, pero no compiten entre sí—Santos hace análisis de costos, Oram hace orquestación. Deberían estar en el mismo grupo.”
“Kim aplicó como desarrollador de herramientas, pero en la conversación 1:1 muestra que trabaja en automatización de cumplimiento SOC2. Debería reclasificarse en FinTech / RegTech.”

Estas re-clasificaciones no pueden captarse solo con embeddings. El modelo debe leer toda la perfil completo.

Ciclo de aprendizaje (learning loop)

Al terminar una actividad, una habilidad /improve lee los resultados de NPS, realiza diarization en los comentarios “pasables”—no en los malos, sino en los “casi” buenos—y extrae patrones.

Luego propone nuevas reglas y las escribe en la skill de coincidencia:

Si alguien dice “infraestructura de IA”, pero su código es más del 80% en módulos de facturación: → clasificar como FinTech, no IA Infra

Si en el mismo grupo dos personas ya se conocen: → reducir peso en coincidencias, priorizar nuevas relaciones

Estas reglas se guardan en el archivo de skills y se activan automáticamente en la próxima ejecución. La skill se “auto-mejora”. En julio, la calificación “pasable” fue del 12%; en la siguiente actividad bajó al 4%.

El sistema aprende qué significa “pasable” sin que nadie tenga que reescribir código.

Este patrón puede aplicarse a cualquier campo:

Buscar → leer → diarizar → contar → integrar

Luego: investigar → encuestar → diarizar → reescribir skill

Si buscas la mejor ciclo en 2026, esa es esta. Se puede aplicar a casi todos los escenarios de trabajo del conocimiento.

Las habilidades se actualizan permanentemente

Recientemente, en X, compartí una instrucción para OpenClaw que tuvo más impacto del esperado:

Esa publicación recibió miles de likes y más de dos mil guardados. Muchos pensaron que era una técnica de ingeniería de prompts.

Pero no, es la misma arquitectura que mencionamos antes. Cada skill que escribes es una actualización permanente del sistema. No se degrada, no se olvida. Se ejecuta automáticamente a las 3 de la mañana. Y cuando salga la próxima generación de modelos, todos los skills se vuelven instantáneamente más fuertes—mejorando la capacidad de juicio en la parte latente, mientras que la parte determinista sigue siendo estable y confiable.

Esa es la fuente de la eficiencia 100x que Yegge menciona.

No es que los modelos sean más inteligentes, sino que: habilidades grasas, arnés delgado (Thin Harness, Fat Skills), y una disciplina para solidificar todo en capacidades.

El sistema crece por interés compuesto. Se construye una vez y funciona a largo plazo.