AI Coding Workflows

Audita tu flujo de trabajo diario con agentes de IA: skills, subagentes y mejores configuraciones por defecto

Una guía práctica para ingenieros y PMs que quieren mejorar su trabajo diario con agentes de IA mediante una auditoría de instrucciones, skills, subagentes, herramientas y hábitos de revisión.

20 min de lectura

TL;DR

  • La forma más rápida de mejorar el trabajo diario con agentes no es agregar más agentes. Es auditar dónde están tus instrucciones y si el agente recibe el contexto adecuado en el momento adecuado.
  • Mantén las instrucciones breves, críticas y siempre relevantes en AGENTS.md, CLAUDE.md o reglas específicas de cada herramienta. Traslada los procedimientos repetibles a skills. Usa subagentes solo cuando el trabajo se beneficie de contexto aislado, investigación en paralelo o una revisión especializada.
  • Trata las skills como guías reutilizables: un SKILL.md breve, una descripción clara de cuándo activarla, archivos de apoyo opcionales, scripts para verificaciones repetibles y límites de permisos claros.
  • Trata a los subagentes como compañeros de equipo con funciones bien delimitadas: investigador, revisor, especialista en depuración, planificador de migraciones o estratega de pruebas. Evita los agentes vagamente definidos como «ingeniero sénior» que hacen de todo.
  • Agrega opciones explícitas para «no hacer nada» y «preguntar primero». El artículo de FixedBench de mayo de 2026 encontró que los agentes de programación evaluados proponían cambios no deseados en el 35–65% de las tareas que no requerían cambios, a menos que se planteara la inacción como un resultado exitoso.
  • El hábito semanal práctico: revisa los prompts que repites, las correcciones que haces, las ejecuciones fallidas de agentes y las aprobaciones riesgosas que concediste. Cada caso es candidato para una regla, skill, subagente, herramienta o punto de control humano.

Qué aprenderás aquí

  • Cómo auditar tu flujo de trabajo diario con agentes de IA sin convertirlo en una ceremonia de gobernanza.
  • Cuándo actualizar las instrucciones siempre activas y cuándo crear una nueva skill.
  • Cuándo es útil un subagente y cuándo solo agrega trabajo de revisión.
  • Un mapa sencillo del flujo de trabajo con agentes que puedes reutilizar con ingenieros, PMs y líderes de equipo.
  • Ejemplos concretos de AGENTS.md, SKILL.md y la definición de un subagente.
  • Un pequeño backlog de mejoras de alto impacto para tus agentes que puedes aplicar esta semana.

Este artículo está dirigido a ingenieros y PMs que ya usan agentes de IA en su trabajo cotidiano: programación, planificación, investigación, depuración, revisión, QA, redacción de tickets, resúmenes de PRs o preparación de notas de lanzamiento.

El objetivo no es construir una enorme plataforma de agentes. Es algo mucho más práctico: lograr que la sesión de mañana con un agente sea menos repetitiva, genere menos ruido y sea más fácil de confiar.

Este artículo se centra en el ciclo de auditoría: cómo clasificar los problemas recurrentes en instrucciones siempre activas, skills, subagentes, herramientas y puntos de control humano. Para temas relacionados de la misma serie, consulta Cuándo usar subagentes en lugar del hilo principal de chat para conocer las ventajas y desventajas de delegar, Skills frente a agentes predeterminados para tomar decisiones sobre skills respaldadas por benchmarks, y La evolución de la orquestación de agentes de IA para conocer el modelo de madurez desde prompts hasta plugins.

La idea central: audita lo que se repite

La mayoría de los problemas en los flujos de trabajo con agentes dejan huellas.

Sigues pegando la misma instrucción. El agente sigue olvidando cómo ejecutar el proyecto. Un bot de revisión sigue comentando problemas de estilo de poco valor. Un agente de programación sigue modificando archivos antes de reproducir el bug. Un PM pide un resumen de la hoja de ruta y recibe una respuesta segura de sí misma, pero sin rastro de las fuentes.

No son molestias aleatorias. Son señales sobre el diseño del flujo de trabajo.

Este es el ciclo de auditoría que me gusta usar:

Daily agent friction
        |
        v
What keeps repeating?
        |
        +--> Stable fact or team convention? -> always-on instructions
        |
        +--> Repeatable procedure? ----------> skill
        |
        +--> Long isolated investigation? ---> subagent
        |
        +--> Needs external data/action? ----> MCP/tool/integration
        |
        +--> Risky or ambiguous? ------------> human checkpoint

Esa es la diferencia entre «uso mucho los agentes» y «estoy mejorando mi sistema de agentes».

Comienza con una auditoría de 30 minutos de tu flujo de trabajo

No necesitas un modelo de madurez formal. Abre las conversaciones con agentes, los PRs, los hilos de Slack, las tareas o el historial de terminal de la última semana y responde cinco preguntas.

  1. ¿Qué repetí al menos tres veces?
  2. ¿Qué entendió mal el agente más de una vez?
  3. ¿Qué contexto tuve que pegar manualmente?
  4. ¿Qué trabajo produjo un diff ruidoso o riesgoso?
  5. ¿Qué tuve que verificar manualmente?

Luego clasifica cada hallazgo:

HallazgoLugar más adecuadoPor qué
«Usa pnpm, no npm»Instrucción siempre activaSe aplica a casi todas las tareas.
«Ejecuta el build antes de los PRs de artículos»Instrucción siempre activaEs una expectativa del repositorio.
«Crea un changelog a partir de los PRs integrados»SkillEs un procedimiento repetible.
«Investiga tres rutas de migración»SubagenteEs un trabajo largo, exploratorio y que requiere mucho contexto.
«Verifica si se pueden compartir estos datos de clientes»Punto de control humanoEs información sensible y depende de las políticas.
«Consulta los logs de producción»Herramienta/MCP con aprobaciónRequiere acceso a sistemas en vivo y límites de seguridad.

Esta pequeña tabla suele ser suficiente para encontrar las próximas tres mejoras.

Las capas de contexto

Las herramientas modernas para agentes tienen ahora muchas superficies de contexto: AGENTS.md, CLAUDE.md, reglas de Cursor, skills, subagentes, servidores MCP, comandos con barra, hooks, memorias y configuraciones específicas de cada aplicación.

Puede parecer un desorden. El truco es separarlas según su función.

Always-on instructions
  Small, stable, critical expectations
  Example: setup, test commands, style rules, repo boundaries

Skills
  Reusable procedures and domain playbooks loaded when relevant
  Example: write an article, review a PR, migrate a component

Subagents
  Specialized workers with isolated context and tool boundaries
  Example: security reviewer, test planner, debugger, researcher

Tools and MCP
  Real capabilities and external systems
  Example: GitHub, docs search, browser, database, logs, design APIs

Human checkpoints
  Approval, prioritization, judgment, risk acceptance
  Example: deploy, delete data, merge risky PR, contact customer

El flujo de trabajo diario mejora cuando cada capa tiene un propósito claro.

Instrucciones siempre activas: mantenlas sencillas y valiosas

Las instrucciones siempre activas son las cosas que el agente debe saber antes de realizar cualquier trabajo.

El formato abierto AGENTS.md se describe como un README para agentes: comandos de configuración, pruebas, estilo de código y convenciones que ayudan a los agentes de programación a trabajar dentro de un repositorio. La documentación de Codex de OpenAI también describe un descubrimiento por capas: instrucciones globales, instrucciones del proyecto y sobrescrituras más específicas a nivel de directorio.

Esto hace que los archivos siempre activos sean ideales para:

  • comandos de configuración
  • comandos de build y pruebas
  • estructura del proyecto
  • convenciones que no son evidentes
  • límites de seguridad
  • áreas que «no se deben tocar»
  • cómo validar el trabajo antes de terminar

No son adecuados para:

  • documentación extensa de API
  • guías de estilo completas
  • procedimientos de varios pasos
  • todas las preferencias que hayas tenido
  • instrucciones que solo se aplican una vez al mes

El matiz importa. En una evaluación de Next.js 16 del 27 de enero de 2026, Vercel encontró que un índice comprimido de documentación en AGENTS.md de 8KB alcanzó una tasa de éxito del 100%, mientras que las skills llegaron como máximo al 79% incluso con instrucciones explícitas para activarlas, porque el agente no tenía que decidir si cargaba el contexto. Sin embargo, un artículo de arXiv de febrero de 2026 sobre archivos de contexto de repositorios encontró que los requisitos innecesarios en archivos del tipo AGENTS.md pueden reducir el éxito de las tareas y aumentar el costo de inferencia en más del 20%.

Mi conclusión: las instrucciones siempre activas deben ser mínimas, específicas y prácticas. Coloca ahí los datos que «no se deben olvidar». Lleva a otro lugar el contenido sobre «cómo hacer algo complejo». El resultado de Vercel corresponde a una evaluación específica de un framework; el artículo de arXiv es una advertencia más amplia contra los archivos de contexto demasiado extensos.

Ejemplo:

# AGENTS.md

## Project Defaults

- Install dependencies with `npm ci`.
- Run `npm run build` before opening a PR that changes source or content.
- Articles live in `content/articles/*.md` and are auto-discovered.
- Keep article frontmatter valid: `title`, `excerpt`, `tags`, and `date`.

## Review Rules

- Do not change unrelated files.
- If no code change is needed, say so and explain the evidence.
- Prefer primary sources for fast-moving AI tooling claims.

Observa lo que falta: un ensayo enorme. El agente necesita restricciones duraderas, no una biblioteca entera.

Skills: convierte los procedimientos repetidos en guías reutilizables

Las skills son el lugar indicado para los procedimientos repetidos.

Anthropic describe Agent Skills como carpetas de instrucciones, scripts y recursos que los agentes pueden descubrir y cargar dinámicamente. La documentación de skills de Claude Code deja muy claro el criterio práctico: crea una skill cuando sigues pegando la misma lista de verificación o cuando una parte de CLAUDE.md ha crecido hasta convertirse en un procedimiento.

Cursor 2.4 también agregó soporte para Agent Skills en el editor y la CLI, con archivos SKILL.md que pueden incluir comandos, scripts e instrucciones. El changelog de Cursor presenta las skills como una mejor opción que las reglas siempre activas para descubrir contexto dinámicamente y ofrecer instrucciones sobre «cómo hacer» algo.

Usa una skill cuando el flujo de trabajo tenga pasos:

  • escribir un artículo basado en investigación
  • inspeccionar un PR y elaborar una revisión
  • migrar de un patrón de componentes a otro
  • generar notas de lanzamiento
  • depurar una prueba intermitente
  • preparar un resumen de incidente para clientes
  • realizar una auditoría de analítica de producto

Una skill debe tener un punto de entrada pequeño y abundante contenido de apoyo.

article-research/
  SKILL.md              # short workflow and triggers
  references/
    source-policy.md    # how to score sources
    article-template.md # expected structure
  scripts/
    check-frontmatter.js

Ejemplo de SKILL.md:

---
description: Research and draft a source-backed engineering article. Use when asked to create or update an article with sources, TL;DR, and practical examples.
disable-model-invocation: false
allowed-tools: Read Grep
---

## Workflow

1. Inspect the article schema and two recent articles.
2. For fast-moving topics, gather primary sources first.
3. Draft with:
   - TL;DR
   - What You Will Learn Here
   - practical examples
   - source list
4. Validate frontmatter and run the project build.

## Quality Bar

- Use absolute dates for recent product claims.
- Separate source-backed claims from inference.
- Keep the tone friendly for engineers and PMs.

La skill no necesita contener todos los artículos que se hayan escrito. Necesita iniciar el flujo de trabajo correcto de forma confiable.

Subagentes: úsalos para aislar contexto, no para aparentar

Los subagentes son útiles cuando evitan que la conversación principal se llene de información innecesaria.

La documentación de subagentes de Claude Code describe asistentes especializados con sus propias ventanas de contexto, prompts personalizados, acceso a herramientas y permisos independientes. Cursor 2.4 describe los subagentes como agentes independientes que se ejecutan en paralelo, usan su propio contexto y pueden configurarse con prompts, herramientas y modelos.

Esto hace que los subagentes sean útiles para:

  • explorar bases de código grandes
  • recopilar fuentes
  • depurar problemas con muchos logs
  • revisar seguridad o rendimiento
  • definir estrategias de pruebas
  • comparar enfoques de implementación
  • obtener una crítica independiente después de la implementación

Son menos útiles cuando:

  • la tarea es muy pequeña
  • todos los agentes necesitan editar los mismos archivos
  • nadie tiene tiempo para revisar múltiples resultados
  • la tarea del subagente es vaga
  • el agente principal ya tiene suficiente contexto

Las buenas definiciones de subagentes describen funciones bien delimitadas:

---
name: evidence-reviewer
description: Reviews drafted technical claims against provided sources. Use after a research article draft exists.
tools: Read, Grep
model: sonnet
---

You review source-backed writing for accuracy.

Focus on:
- claims that need a source
- claims that overstate what the source says
- dates that need to be absolute
- missing caveats or unsupported recommendations

Do not rewrite the article. Return a concise list of issues and suggested fixes.

Las malas definiciones de subagentes se basan en impresiones vagas:

---
name: super-engineer
description: Helps with engineering tasks.
---

Be smart and improve everything.

El primero tiene un trabajo. El segundo tiene una capa y ninguna agenda.

Un flujo de trabajo práctico para el uso diario de agentes

Este flujo de trabajo funciona bien para tareas de ingeniería y producto.

1. Frame
   User/PM/engineer states the outcome and constraints.

2. Explore
   Main agent or research subagent gathers repo/source context.

3. Decide
   Human confirms the plan when risk or ambiguity is high.

4. Execute
   Main agent implements; skills provide repeatable workflows.

5. Verify
   Tests, build, browser checks, source audit, or reviewer subagent.

6. Capture
   Update AGENTS.md, a skill, or a subagent if the lesson will repeat.

El último paso es el que la mayoría de los equipos omite.

Si el agente cometió un error y solo corriges el resultado, mejoraste un resultado. Si actualizas el recurso del flujo de trabajo que causó el error, mejoras las sesiones futuras.

Qué agregar o actualizar esta semana

Este es un backlog de mejoras de alto impacto para la mayoría de los equipos que usan agentes de IA a diario.

1. Agrega un README breve para agentes

Si tu repositorio no tiene un AGENTS.md, agrégalo. Si ya tiene CLAUDE.md, .cursor/rules o .github/copilot-instructions.md, decide si AGENTS.md debe convertirse en el índice portable y si los archivos específicos de cada herramienta deben apuntar a él.

Comienza con:

  • comandos de configuración
  • comandos de pruebas
  • estructura del proyecto
  • expectativas para los PRs
  • límites de seguridad o de datos
  • dónde encontrar documentación más detallada

Mantenlo lo suficientemente breve como para que alguien realmente lo revise en un PR.

2. Crea una skill de «Resumen de cambios»

Esta es una skill básica para el trabajo diario. Debe leer el diff actual, resumir el cambio, señalar riesgos y sugerir pruebas.

---
description: Summarize current git changes, identify risk, and suggest validation. Use before committing or opening a PR.
disable-model-invocation: false
---

## Current diff

!`git diff --stat && git diff --name-only`

## Instructions

Return:
1. What changed
2. Why it appears to matter
3. Risk areas
4. Validation still needed

If the diff is empty, say there are no local changes.

3. Crea un subagente de revisión de solo lectura

Crea un revisor que no pueda editar archivos. Su trabajo es encontrar problemas, no «arreglar todo» en segundo plano.

Buenas configuraciones por defecto:

  • herramientas de solo lectura
  • enfoque estricto en bugs, seguridad, pruebas y regresiones
  • permiso explícito para devolver «sin hallazgos»
  • resultados concisos

Esto importa porque los agentes de revisión generan más confianza cuando son selectivos.

4. Agrega una regla de inacción

Agrega esto a tus instrucciones siempre activas o a tu skill de revisión:

If no code or content change is needed, treat "no change" as a successful outcome.
Explain the evidence and stop.

Esta pequeña instrucción contrarresta el sesgo hacia la acción. El artículo de FixedBench de mayo de 2026 (Coding Agents Don’t Know When to Act) encontró que los agentes de programación evaluados proponían cambios no deseados en el 35–65% de las tareas que no requerían cambios, a menos que se planteara explícitamente la abstención como un resultado exitoso. No des por hecho que el agente sabe por sí solo que actuar con cautela también es un éxito.

5. Saca la documentación extensa del contexto siempre activo

Si tu archivo de instrucciones se está convirtiendo en un manual, divídelo:

AGENTS.md
  short index and must-follow rules

docs/agent/
  architecture.md
  testing.md
  release.md

.claude/skills/
  release-notes/SKILL.md
  pr-review/SKILL.md

El archivo siempre activo le dice al agente dónde buscar. La skill le dice cómo actuar. La documentación contiene los detalles.

6. Usa worktrees para el trabajo en paralelo con agentes

Cuando varios agentes o sesiones puedan editar archivos, aíslalos.

La documentación de worktrees de Claude Code describe directorios de trabajo separados con sus propias ramas para que las sesiones paralelas no entren en conflicto. Cursor 2.0 también destacó la ejecución de muchos agentes en paralelo mediante worktrees de git o máquinas remotas. Para conocer un patrón más detallado de worktrees con múltiples repositorios, consulta Carpetas de funcionalidades para múltiples repositorios con Git Worktrees y Claude Code.

Usa worktrees para:

  • dos implementaciones alternativas
  • correcciones de bugs en segundo plano
  • borradores de artículos mientras hay una rama de funcionalidad activa
  • experimentos con subagentes que puedan modificar archivos

Evítalos cuando la tarea sea únicamente una investigación de solo lectura.

Métricas accesibles para PMs sobre la calidad diaria del trabajo con agentes

Los PMs no necesitan entender cada configuración del modelo para mejorar los flujos de trabajo con agentes. Hagan seguimiento de señales sencillas:

SeñalQué indica
Cantidad de correcciones repetidasInstrucciones ausentes o insuficientes
Ejecuciones de agentes abandonadasDefinición deficiente de la tarea o demasiada autonomía
Aceptación de comentarios de revisiónSi se confía en los agentes de revisión
Tiempo hasta obtener un borrador verificadoSi los agentes están acelerando el trabajo útil
Cantidad de veces que se pega contexto manualmentePosibles skills o índices de documentación
Tiempo de limpieza después del trabajo del agenteSi los resultados generan demasiado ruido

El objetivo no es la vigilancia. Es identificar qué flujos de trabajo vale la pena convertir en productos.

Una auditoría mensual sencilla de agentes

Una vez al mes, dedica 45 minutos junto con un ingeniero y un PM.

Inputs:
  - last 10 agent-assisted PRs
  - last 10 repeated prompts
  - last 5 agent failures
  - current AGENTS.md / CLAUDE.md / rules
  - current skills and subagents

Questions:
  - What should be always-on?
  - What should become a skill?
  - What should become a subagent?
  - What should require approval?
  - What should be deleted because nobody uses it?

Outputs:
  - 1 instruction update
  - 1 skill update
  - 1 subagent/tooling experiment
  - 1 thing removed

Ese último resultado es importante. Los sistemas de agentes se deterioran cuando solo agregas cosas.

Errores comunes

Error 1: convertir las instrucciones en un cajón de sastre

Si tu archivo siempre activo tiene cincuenta reglas, las menos importantes compiten con las más importantes. Mantén el archivo enfocado.

Error 2: crear una skill para información que el agente siempre debe conocer

Si el agente debe saber algo antes de tomar cualquier decisión, coloca una versión breve en el contexto siempre activo. Las skills solo son útiles cuando el agente las activa en el momento adecuado o tú las invocas directamente.

Error 3: crear subagentes antes de tener capacidad de revisión

El trabajo en paralelo no es gratis. Cada resultado adicional de un agente requiere revisión, integración o rechazo.

Error 4: dar acceso a herramientas sin límites

MCP y las integraciones de herramientas son útiles porque conectan a los agentes con sistemas reales. Ese también es el riesgo. La propia especificación de MCP enfatiza el consentimiento, la privacidad de los datos y la seguridad de las herramientas. Trata los permisos de las herramientas como acceso a producción, no como configuraciones de autocompletado.

Error 5: olvidar registrar la lección

Cuando un agente comete un error, pregúntate: ¿debería convertirse en una regla, una skill, un cambio en un subagente, una prueba o un punto de control humano?

Mi stack inicial recomendado

Si empiezas desde cero, yo lo mantendría sencillo:

Repo root:
  AGENTS.md
    setup, tests, conventions, safety rules, docs index

Skills:
  summarize-changes
  pr-review
  research-article
  release-notes

Subagents:
  read-only-code-reviewer
  source-auditor
  debugger
  test-strategist

Tools:
  GitHub
  browser
  docs search
  issue tracker

Human gates:
  dependency additions
  destructive commands
  production data access
  deploys

Eso basta para mejorar notablemente el uso diario de agentes sin construir una plataforma interna sobrediseñada.

Limitaciones

Este artículo es intencionalmente práctico, pero vale la pena dejar claros algunos límites desde el principio:

  • No compara directamente herramientas específicas mediante benchmarks. Cursor, Claude Code, Codex, Copilot y otras herramientas evolucionan rápidamente.
  • No cubre en profundidad la gobernanza empresarial: los logs de auditoría, la configuración administrada, la retención de datos y la aplicación de políticas merecen un artículo propio. Para conocer los controles de seguridad en torno a la programación con agentes, consulta Generación segura de código con agentes.
  • No incluye una lista de verificación completa de seguridad de MCP para producción.
  • Se centra en flujos de trabajo de conocimiento y software, no en agentes autónomos orientados a clientes.
  • El stack inicial es una plantilla. Los equipos deben evaluar cada recurso según sus propios patrones de fallos, en lugar de copiarlo íntegramente.

Lecturas relacionadas

Fuentes