Agent Skills
(addyosmani.com)- Agent Skills es un scaffolding que obliga mediante workflows a que los agentes de codificación con IA no se salten procesos de ingeniería senior como especificaciones, pruebas, PRs revisables y revisión de límites de confianza
- Una skill es un archivo Markdown con frontmatter que se parece más a un workflow con secuencia de pasos, evidencia en checkpoints y criterios de salida, que a un documento de referencia
- Las 20 skills del repositorio se componen de 6 etapas del ciclo de vida: Define, Plan, Build, Verify, Review y Ship, además de 7 slash commands:
/spec,/plan,/build,/test,/review,/ship,/code-simplify - Los principios clave son proceso sobre prosa, tablas anti-racionalización, verificación como criterio de salida, divulgación progresiva y disciplina de alcance;
using-agent-skillsactiva solo las skills adecuadas para la tarea - Puede usarse instalándolo desde el marketplace de Claude Code, poniendo el Markdown en herramientas como Cursor
.cursor/rules/, Gemini CLI, Codex, Aider, Windsurf u OpenCode, y está publicado bajo licencia MIT
Objetivo y problema de fondo
- Agent Skills es un scaffolding para obligar mediante workflows a que los agentes de codificación con IA sigan procesos de ingeniería senior que normalmente se saltan
- Cuando se les pide una función, los agentes de codificación con IA normalmente la implementan por la ruta más corta y no realizan por defecto pasos como redactar una especificación, empezar por pruebas, revisar límites de confianza o estructurar un PR revisable
- En el trabajo de un ingeniero senior hay muchas cosas que no se ven en el diff
- Hacer explícitos los supuestos
- Redactar especificaciones
- Dividir el trabajo en unidades revisables
- Elegir diseños aburridos pero seguros
- Dejar evidencia de que el resultado es correcto
- Limitar los cambios a un tamaño que una persona realmente pueda revisar
- La razón por la que los agentes se saltan estos pasos es similar a la de un ingeniero junior: la señal de recompensa está alineada con “trabajo terminado”, no con “trabajo terminado con documento de especificación incluido”
- El repositorio Agent Skills ya superó las 26K stars, y además del README cubre por qué se tomaron ciertas decisiones de diseño, cómo se relaciona con un SDLC estándar y con prácticas públicas de ingeniería de Google, y qué patrones se pueden adoptar incluso sin instalarlo
Qué significa realmente una skill
- Una skill es un archivo Markdown con frontmatter que se inyecta en el contexto del agente según la situación, y está a medio camino entre un fragmento de system prompt y un runbook
- Una skill no es un documento de referencia ni una colección de conocimiento tipo “todo lo que debes saber sobre testing”.
- Una skill útil es un workflow que el agente sigue
- Tiene un orden de pasos
- Genera evidencia en checkpoints
- Termina con criterios de salida claros
- Si metes en contexto un ensayo de 2,000 palabras sobre buenas prácticas de testing, el agente puede generar frases plausibles y aun así saltarse las pruebas reales
- En cambio, si le das un workflow donde primero escribe una prueba que falle, la ejecuta para confirmar el fallo, implementa lo mínimo necesario para hacerla pasar, confirma que pasa y luego refactoriza, entonces el agente tiene acciones concretas que realizar y una persona puede verificar el resultado
- La distinción clave es proceso sobre prosa: workflow sobre referencia, pasos con criterios de salida sobre ensayo sin criterios de salida
- La razón por la que muchos repositorios de “AI rules” no producen resultados reales es que las reglas se quedan en forma de ensayo y no de workflow
Estructura de SDLC y slash commands
- Las 20 skills del repositorio se organizan en 6 etapas del ciclo de vida, y encima de ellas se ubican 7 slash commands
-
Etapas y comandos
/spec: etapa Define para decidir qué se va a construir/plan: etapa Plan para descomponer el trabajo/build: etapa Build para implementar en slices verticales/test: etapa Verify para demostrar el comportamiento/review: etapa Review para detectar problemas que se escaparon/ship: etapa Ship para entregar con seguridad a los usuarios/code-simplify: comando de simplificación que aplica a lo largo de todo el flujo- Esta estructura sigue el mismo flujo que el SDLC de una organización de ingeniería funcional; lo que cambia entre organizaciones es el vocabulario
- En Google aparece como flujo de design doc → review → implementation → readability review → launch checklist; en Amazon, como working-backwards memo y bar raiser
- El problema nuevo con los agentes de codificación con IA es que la mayoría se salta por defecto la mayor parte de estas etapas
- Si pides una funcionalidad, entregan implementación, pero no especificación, plan, pruebas, revisión ni checklist de lanzamiento
- Las skills hacen que el agente también pase por las etapas que un ingeniero senior se autoimpone, porque desplegar código sin esos procesos termina en incidentes
- Una funcionalidad compleja puede activar 11 skills en secuencia, mientras que un bug pequeño puede usar solo 3
- El router
using-agent-skillsdecide qué skills aplican a la tarea actual, y el workflow escala según el alcance real, no uno asumido
Principios que sostienen su funcionamiento
-
1. Proceso sobre prosa
- Un workflow es algo que el agente puede convertir en acción; un ensayo, no
- El mismo principio aplica a los equipos humanos
- Si el handbook del equipo tiene 200 páginas, nadie lo leerá bajo presión; si es un workflow pequeño con checkpoints, es mucho más probable que se ejecute de verdad
-
2. Tablas anti-racionalización
- La decisión de diseño más distintiva de Agent Skills, y la que otros equipos deberían adoptar, son las tablas anti-racionalización
- Cada skill incluye excusas comunes que un agente o un ingeniero cansado podría usar para saltarse el workflow, junto con respuestas ya redactadas
- Ejemplos
- “Esta tarea es demasiado simple para requerir una especificación” → Los criterios de aceptación siguen aplicando. 5 líneas están bien; 0 líneas no
- “Escribiré las pruebas después” → “Después” es justamente el problema. No existe el después. Primero hay que escribir una prueba que falle
- “Las pruebas pasaron, así que despleguemos” → Las pruebas que pasan son evidencia, no prueba absoluta. Hay que confirmar si se verificó el runtime, si se validó el comportamiento visible para el usuario y si una persona leyó el diff
- Los LLM son buenos racionalizando, y pueden escribir párrafos plausibles sobre por qué cierta tarea no necesita especificación o por qué cierto cambio puede mergearse sin review
- La tabla anti-racionalización es una refutación preescrita contra mentiras que el agente todavía no ha dicho
- Este patrón también funciona en equipos humanos
- El deterioro de la calidad de ingeniería normalmente no ocurre porque alguien decidió hacer algo malo, sino porque se aceptó una justificación plausible para saltarse un proceso incómodo
-
3. La verificación no es negociable
- Todas las skills terminan con evidencia concreta
- Cosas como pruebas pasando, salida limpia del build, un trace en runtime que muestre el comportamiento esperado o la aprobación del reviewer funcionan como criterios de salida
- “Se ve razonable” no es suficiente
- Es el mismo principio por el que el harness de Anthropic puede recuperarse de fallos, la separación planner/worker/judge de Cursor realmente detecta bugs, y los long-running agent se vuelven recuperables
- Como los agentes son generadores, necesitan una señal separada para determinar que una tarea está terminada, y las skills incorporan esa señal en cada workflow
-
4. Divulgación progresiva
- No se cargan las 20 skills completas en contexto al inicio de la sesión
- Solo se activan las skills necesarias según la etapa actual
- Una pequeña meta-skill,
using-agent-skills, actúa como router para decidir qué skill corresponde a la tarea en curso - Esto aplica a nivel de skills las lecciones de harness engineering
- Todo token cargado en contexto perjudica el rendimiento en algún lugar, así que conviene cargar solo lo relevante y dejar el resto en disco
- La divulgación progresiva es la forma de meter una biblioteca de 20 skills en un espacio de 5K tokens sin contaminar todo el contexto
-
5. Disciplina de alcance
- La meta-skill codifica como principio no negociable “toca solo lo que te pidieron”
- No debe refactorizar sistemas adyacentes, eliminar código que no entiende del todo ni decidir reescribir un archivo completo solo porque vio un TODO
- Un agente puede intentar modernizar 3 archivos no relacionados mientras arregla un solo bug
- La disciplina de alcance es el factor que más determina si el PR del agente es mergeable o si habrá que revertirlo
- Esto también encaja con las normas de code review de Google, donde los reviewers pueden bloquear un PR que intenta hacer más de una cosa
Conexión con prácticas de ingeniería de Google
- Agent Skills refleja muchas prácticas de Software Engineering at Google y de la cultura pública de ingeniería de Google
- Muchas de las cosas que hacen funcionar software a escala Google están documentadas públicamente, y son justamente las que los agentes más suelen saltarse
-
Correspondencia entre skills y prácticas
api-and-interface-design: refleja Hyrum’s Law. Todo comportamiento observable de una API terminará siendo dependencia de alguien, así que hay que diseñar teniéndolo en cuentatest-driven-development: refleja la pirámide de pruebas~80/15/5y la Beyoncé Rule. Si de verdad te importaba, debiste haberle puesto tests; los bugs los detectan las pruebas, no los cambios de infraestructura- DAMP over DRY en testing: la filosofía de pruebas de Google sostiene que el código de pruebas debe leerse como una especificación, aunque tolere algo de duplicación. Las pruebas demasiado abstraídas son un antipatrón conocido
code-review-and-quality: refleja PRs de tamaño~100-liney etiquetas de severidad Critical / Nit / Optional / FYI. Los PR grandes en la práctica no se revisan bien y suelen aprobarse casi por inerciacode-simplification: refleja Chesterton’s Fence. No hay que eliminar algo antes de entender por qué se puso ahígit-workflow-and-versioning: refleja trunk-based development y commits atómicosci-cd-and-automation: refleja Shift Left y feature flags. Hay que detectar problemas lo antes posible y separar deploy de releasedeprecation-and-migration: refleja code-as-liability. Cada línea mantenida es una línea que hay que cargar para siempre, así que conviene preferir superficies más pequeñas- Estos conceptos no son nuevos, pero no vienen incorporados por defecto en los agentes
- Aunque un frontier model haya visto la frase “Hyrum’s Law” en los datos de entrenamiento, no la aplicará automáticamente al diseñar una API a las 3 de la mañana
- Las skills hacen que el agente aplique estas prácticas durante el trabajo real
Cómo se usa en la práctica
-
Forma 1: instalarlo desde el marketplace
- Si usas Claude Code, se instala con estos comandos
/plugin marketplace add addyosmani/agent-skills /plugin install agent-skills@addy-agent-skills- Después de instalarlo, puedes usar los slash commands
/spec,/plan,/build,/test,/review,/ship,/code-simplify - El agente activa automáticamente las skills relevantes según el contexto
- Para la mayoría de los usuarios, esta es la forma recomendada de empezar
-
Forma 2: poner el Markdown en la herramienta que quieras
- Las skills son archivos Markdown normales con frontmatter
- Los usuarios de Cursor pueden ponerlas en
.cursor/rules/ - Gemini CLI tiene su propia ruta de instalación
- Codex, Aider, Windsurf, OpenCode y otras herramientas que acepten system prompts también pueden leerlas
- Lo importante no es tanto la herramienta como el workflow que hay debajo
-
Forma 3: leerlas como una especificación
- Incluso sin instalar nada, las skills funcionan como una explicación documentada de cómo hacer buena ingeniería junto con agentes de IA
- Puedes leer
code-review-and-quality.mdy aplicar su framework de 5 ejes al proceso de review de tu equipo - Puedes leer
test-driven-development.mdy usarlo en debates como “¿deberíamos escribir los tests primero?” - Puedes leer las meta-skills y llevarte los 5 principios no negociables a tu propio
AGENTS.md - Un buen punto de partida es elegir 4 o 5 skills cercanas al problema que más duele hoy, definir los workflows que quieres forzar e instalar o construir tú mismo un runtime que los haga cumplir
Patrones que puedes adoptar sin instalarlo
-
Convertir la anti-racionalización en práctica de equipo
- El equipo debe escribir las mentiras que se dice a sí mismo
- Ejemplos: “arreglaremos los tests después del release”, “este cambio es demasiado pequeño para necesitar un documento de diseño”, “con monitoreo basta”
- Si a cada frase le agregas una refutación y la pones en
AGENTS.mdo en el wiki de ingeniería, puedes reducir discusiones y frenar atajos cansados de viernes por la tarde
-
Escribir documentación interna como proceso y no como prosa
- Si estás escribiendo un documento de 2,000 palabras sobre “cómo abordamos X”, en realidad estás produciendo material de referencia
- Si lo conviertes en un workflow con checkpoints, el documento puede bajar a 400 palabras y será mucho más probable que se ejecute
- Este principio aplica a guías de onboarding, runbooks y agent skills
-
Usar la verificación como criterio de salida duro
- El último paso de todo trabajo debería ser “generar evidencia”
- Esto aplica a agentes, ingenieros y trabajo individual
- La evidencia puede ser una ejecución de tests en verde, una captura de pantalla, logs o una aprobación de review: cualquier cosa que demuestre que el trabajo terminó
- Si no hay evidencia, el trabajo no está terminado, y “se ve razonable” no cierra el ciclo
-
Aplicar divulgación progresiva a cualquier rulebook
- En vez de escribir un handbook de 50 páginas, conviene crear un router pequeño que envíe a capítulos cortos según la situación
- Esto aplica a
AGENTS.md, runbooks, playbooks de incidentes y cualquier documento que deba leerse bajo presión
-
Los 5 principios no negociables para poner en AGENTS.md
- Hay que hacer explícitos los supuestos antes de construir. Los supuestos equivocados mantenidos en silencio son uno de los modos de falla más comunes
- Si los requisitos chocan, hay que detenerse y preguntar. No hay que adivinar
- Hay que disentir cuando haga falta. Un agente o un ingeniero no está para decir sí a todo
- Hay que preferir soluciones aburridas y claras. Lo ingenioso sale caro
- Hay que tocar solo lo que se pidió
Su lugar dentro del harness
- Las skills son una capa dentro del marco más amplio de agent harness engineering
- El harness incluye el modelo y todo lo que se construye alrededor; las skills son fragmentos reutilizables de workflow que se revelan progresivamente dentro del system prompt
- Las skills conviven con
AGENTS.md, hooks, tools y session logAGENTS.md: funciona como un rulebook que se actualiza continuamente- hooks: capa de enforcement determinista
- tools: acciones que el agente puede ejecutar
- session log: memoria persistente
- skills: responsables del proceso de ingeniería senior
- Las skills son todavía más importantes en long-running agents que en agentes de chat
- Las ejecuciones largas amplifican todos los atajos
- Un agente que se salta pruebas en una sesión de 10 minutos puede introducir un bug
- Un agente que se salta pruebas en una sesión de 30 horas puede terminar creando una excavación arqueológica de debugging donde ya nadie recuerda la intención original
- Cuanto más larga es la ejecución, más necesario es que el scaffolding de ingeniería senior no sea una sugerencia sino algo forzado
- La portabilidad del formato de skills también importa
- El mismo archivo
SKILL.mdpuede usarse en Claude Code, Cursor con rules, Gemini CLI, Codex y otros harnesses que acepten contenido para system prompts - Escribes el workflow una sola vez y el runtime puede hacerlo cumplir; esa es la ventaja del formato Markdown con frontmatter frente al bespoke prompt engineering
Conclusión
- Los agentes de codificación con IA se comportan como ingenieros junior muy capaces, pero sin instinto para el trabajo que no aparece en el diff
- Tareas de ingeniería senior como explicitar supuestos, dimensionar cambios, redactar especificaciones, dejar evidencia o rechazar merges de cambios imposibles de revisar tienen muchas probabilidades de ser omitidas si no se obliga al agente a pasar por ellas
- Cada vez es más importante codificar esta disciplina de una forma de la que el agente no pueda escaparse solo hablando
- Las skills son una de esas formas, y lo central es la combinación de tablas anti-racionalización, divulgación progresiva, proceso sobre prosa, verificación como criterio de salida y una estructura portable de prácticas de Google que ya funcionan
- El repositorio Agent Skills está publicado bajo licencia MIT, y la visión más amplia de este scaffolding continúa en Agent Harness Engineering y Long-running Agents
1 comentarios
Comentarios de Hacker News
Está más cerca de ser una panacea fraudulenta. Vale la pena leerlo y suena convincente, pero al final sigue siendo una panacea fraudulenta
La razón es que un modelo tipo tragamonedas puede omitir en cualquier momento requisitos obligatorios escritos en
AGENTS.md,memory.mdy decenas de archivos Markdown de habilidades, y eso está prácticamente garantizadoEste enfoque de harness finge que los LLM siguen reglas de forma estricta y perfecta, y que el problema solo es que no hemos escrito suficientes reglas con suficiente claridad. Ese es un error cognitivo fundamental sobre cómo funcionan los LLM
Al final, la única opción confiable, o relativamente más confiable, es la revisión y supervisión humana, idealmente dos veces seguidas si es posible
Todo lo demás es panacea fraudulenta, y llegado a ese punto te das cuenta de que la supuesta mejora de productividad también lo es. Porque leer código y construir un modelo mental es mucho más difícil que pasar a código algo cuando ya tienes ese modelo mental
Leer código depende de qué código sea, pero como cualquier otra habilidad se vuelve más fácil con práctica. Es común cuando trabajas con bases de código grandes y complejas que existen desde hace mucho, donde lees muchísimo más código del que escribes
Se vuelve más fácil cuando ya tienes un modelo mental del código gracias a documentación, experiencia previa o preguntarle a colegas
Con agentes también se puede lograr esto. Normalmente ya conoces bien la estructura del código antes de darle un prompt a la IA, y si divides el trabajo con cuidado, revisar el código generado se vuelve muy fácil. Es como releer un libro que ya leíste, y si algo está mal suele saltar a la vista enseguida, así que la mayoría de los errores se detectan temprano. De cualquier forma, la mejora de velocidad es grande
Pero en los últimos meses he usado spec-kit, o sea este estilo de uso de IA, y en la práctica ha sido sorprendentemente bueno. Estamos construyendo cosas excelentes, y los problemas que planteas como hipótesis todavía no me han pasado. Puede que pasen algún día, y por eso soy cuidadoso
Aun así, después de usarlo directamente durante bastante tiempo, no puedo simplemente descartarlo como una panacea fraudulenta. Llevo más de 30 años como programador y siento que puedo distinguir bastante bien qué funciona y qué no
Quiero ver harness que exijan, no que pidan. Si le dijiste al agente que esté en modo planificación y no sigue el procedimiento de planificación definido, lo matas. Aunque no sea perfecto, debería ser mejor que el enfoque actual con una persona en el medio
Dicen que “las habilidades son archivos Markdown con frontmatter que se inyectan en el contexto del agente cuando corresponde”, pero quien decide si corresponde es el LLM
Dicen que es “una serie de pasos que el agente sigue y que termina con checkpoints que producen evidencia y criterios de finalización claros”, pero quien también puede decidir si sigue esos pasos es el LLM
$my-skill, y entonces esa habilidad sí se inyecta en el contexto. Después de eso, el LLM la sigue en la misma medida en que sigue el prompt, las instrucciones y otras partes del contextoEspero con ganas el día en que todos se den cuenta de que pasaron más de un año jugueteando con agentes y solo sintieron una productividad falsa
No coincide en absoluto con mi experiencia real. Me pregunto qué experiencias te llevaron a estar tan seguro del colapso inevitable del código con IA. Si es una convicción filosófica de que la IA es moralmente mala, o si realmente construiste algo con IA, lo exploraste lo suficiente y llegaste a una conclusión fuerte
Llevo más de 30 años escribiendo código todos los días, y más de 20 haciéndolo profesionalmente. He visto modas ir y venir, y también varios avances reales que cambiaron cómo trabajamos. Cuantos más proyectos hago con IA, más convencido estoy de que esto representa un cambio duradero y fundamental en la forma de crear software y usar computadoras
He visto mejorar a la IA, y también me he vuelto más hábil para terminar trabajo real con ella. Ese trabajo ya fue probado bajo carga real de producción. Puede no gustarte lo que está pasando y puede no gustarte cómo se siente trabajar con IA, pero eso no significa que no esté aportando valor real a la gente ni haciendo trabajo real
Nosotros adoptamos Claude Code por completo desde septiembre más o menos, y hemos podido seguir las mejoras con éxito. Estamos desplegando funcionalidades que se usan en producción real. Lo mismo en infraestructura, en implementación de lógica de negocio, frontend y backend
No veo a la gente desperdiciando así su tiempo. Aunque sí estoy de acuerdo en que la mayoría de estos posts son tonterías, incluido este. Aun así, el desarrollo con IA ya está ocurriendo en muchas empresas por todo el mundo
No creo que los workflows estilo agente hayan llegado todavía hasta ese punto, pero las implementaciones de habilidades usadas manualmente para trabajar junto a la IA sí me parecen bastante bien. En nuestra empresa últimamente nos estamos enfocando mucho en sandboxing y habilidades seguras
No creo que todavía haya dado en el blanco para desarrollo de funcionalidades, pero la habilidad de review y la habilidad de Grafana que escribimos fueron bastante sólidas
Antes usé paquetes más grandes de habilidades para agentes, pero como intentaban hacer demasiadas cosas, se sentían como una pérdida de tiempo. Igual que con Vim, muchas veces es mejor escoger cosas de la comunidad que instalar un paquete entero de habilidades como si fuera un IDE
Las habilidades cambian mucho según cada desarrollador y equipo, así que son demasiado personales. En vez de instalar masivamente la configuración de otra persona, es mejor tratarlas como material de referencia para crear la tuya
Desde una perspectiva de optimización para búsqueda o para LLM, parece que la descubribilidad de estas habilidades será difícil si no les cambian el nombre: https://agentskills.io/
Si Addy ve esto, me intriga cómo lo explicaría en comparación con Superpowers: https://github.com/obra/superpowers
Estoy metido en desarrollo con agentes desde antes de superpowers, y me preocupa que más del 50% de los procesos que construí por mi cuenta ahora ya estén cubiertos por superpowers
Ya no confío en las estrellas de GitHub. Ojalá alguien lo dijera. ¿superpowers de verdad ya fue adoptado? Si realmente vale la pena, ¿por qué Boris todavía no integra ese concepto?
“si crees que hay aunque sea un 1% de probabilidad de que una habilidad aplique a lo que estás haciendo, debes invocar esa habilidad obligatoriamente”
No entiendo por qué todos están tan emocionados por eliminar sus propios trabajos
Puede que estas cosas o alguna “habilidad” no logren realmente eso, pero hablo en principio. Esto se siente como una alienación del trabajo a gran escala
La humanidad, desde donde se puede rastrear, siempre ha reducido el trabajo necesario para producir una cantidad dada de resultado, y eso es civilización. ¿Deberíamos volver a cultivar a mano con azadón para maximizar el trabajo invertido al escribir? ¿Volver a la época en que se encendían los faroles uno por uno?
Las sociedades que se quedan atrás en automatización se vuelven más pobres y al final mueren. Incluso la gente nacida ahí se va a lugares con mayor productividad. Ha pasado en Europa del Este, con los Amish y en cualquier sociedad pobre de donde surge migración. Hacer más con menos siempre ha sido algo emocionante
Me pregunto si sientes eso sobre toda automatización. Había administradores de sistemas de la vieja escuela que veían así el avance de la automatización de infraestructura y no les gustaba que scripts y sistemas hicieran cosas que antes se hacían a mano
En un trabajo, mi equipo construyó un sistema automático de parchado para ejecutar parches en 30 mil servidores y sacar y volver a meter sistemas en producción automáticamente. Todo el proceso dejó de requerir manos humanas, y antes había un equipo dedicado a hacerlo manualmente. ¿La automatización les quitó el trabajo?
En cierto sentido sí, pero había otras tareas por hacer y ahora pudieron hacerlas
Justamente me gusta la programación, las computadoras y la tecnología porque hacen trabajo en nuestro lugar. Mi utopía es un mundo donde los robots hagan todo el trabajo duro y los humanos puedan hacer lo que quieran. La IA nos está acercando un paso más a eso. En vez de intentar preservar suficientes tareas para que la gente siga ocupada haciendo cosas que no quiere hacer, prefiero enfocarme en cómo hacer que el beneficio de que los robots se queden con los trabajos lo reciba todo el mundo, y no solo propietarios ricos
Ahora mismo no está claro hacia dónde evoluciona todo esto, así que la gente está entregando sus datos a agentes al azar, buscando formas de guardar y acceder al contexto, reutilizar prompts y probando distintas formas de manejar esta tecnología
Puede que la mayoría de estas cosas dentro de un año ya no sirvan porque quedarán profundamente integradas en la siguiente generación de modelos. Aun así, seguirle el ritmo al progreso siempre fue parte de lo divertido de trabajar en este campo
Creo que sorprendería un poco tanto a los que están a favor como a los que están en contra ver datos de largo plazo que muestren que, en promedio, el aumento de productividad ha sido limitado, y que incluso con ayuda de modelos avanzados de última generación sigue haciendo falta mucho cuidado y atención humana para construir software de calidad
Es el mismo trabajo, solo que ahora tienes un taladro eléctrico en vez de un destornillador. Algunas personas construyen casas que duran siglos, y otras no
Últimamente sigo escuchando lo mismo. Que las cosas que son buenas para gestionar equipos de desarrolladores también son buenas para gestionar LLM
Buenos casos de prueba, documentación clara y concisa, CI/CD, buenas prácticas y documentación de onboarding
Gestionar LLM se parece cada vez más a gestionar un equipo humano
Me pregunto qué hace esto mejor o diferente que spec-kit. La filosofía se ve muy parecida, y también me pregunto si podrían usarse juntos. O si simplemente se superponen
https://github.com/github/spec-kit
Me sorprendió que algunas habilidades fueran así de largas. Se extienden por varias páginas con tablas, listas de verificación, ejemplos de código, etc.
Me pregunto qué tan común es eso. Con solo unas pocas de esas, parece que ya llenarías bastante el contexto
Hay un experimento interesante. Pídele a un LLM que use algo vagamente familiar. Por ejemplo, si le pides “write a fib”, casi cualquier LLM va a responder con el algoritmo de la secuencia de Fibonacci, porque la mayoría están ajustados con código, aunque para alguien no programador eso podría significar “escribe una pequeña mentira”
O sea, ocurre compresión. Sin explicar en detalle qué es la secuencia de Fibonacci, puedes expresar el resultado con apenas tres tokens ambiguos
Por eso sabemos que la longitud del prompt no importa tanto. Lo que importa son las palabras correctas, la frecuencia y el orden. Un prompt de dos páginas y uno de dos oraciones pueden dar el mismo resultado
Hasta ahora me ha ido bien con habilidades cortas y enfocadas. Las trato como fragmentos reutilizables de contexto, pero pequeños. Por ejemplo, unos cuantos párrafos sobre cómo usamos Python en mi proyecto y cómo ejecutar pruebas unitarias
También tengo varias habilidades cortas de “info” que no le dan instrucciones al agente, sino que solo contienen información contextual útil que puede traer si hace falta
Tener demasiadas habilidades también puede ser un problema. La lista de nombres y descripciones de habilidades termina entrando al contexto en algún momento
Incluso en un contexto pequeño de 128k para un LLM eso sería como un 10%, y en una ventana de contexto de 1M de un modelo grande casi ni se nota
Quizá aquí estoy siendo demasiado conservador. Hay mucho más por explorar
“La mayor parte del trabajo de un ingeniero senior no se ve en el diff”
Agent Skills es el intento de Addy de eliminar también ese trabajo. Salud, Addy :P