Buenas prácticas de Claude Code: prompts, deterioro de agentes y 6 funciones

Descubrirá cómo diagnosticar de forma sistemática los prompts que fallan tras un cambio de modelo, cómo reconocer que su agente de Claude Code empeora poco a poco y qué seis funciones probablemente no está aprovechando. Este artículo sitúa las buenas prácticas de una conferencia de Anthropic para equipos de desarrollo y responsables técnicos de pymes y las contrasta con la documentación oficial.

Sobre la fuente: Se analiza un montaje de vídeo con varias sesiones de la conferencia de Anthropic «Code with Claude» de Londres (19 de mayo de 2026). Se pueden atribuir con seguridad Margot van Laar, Applied AI Engineer en Anthropic (charla sobre prompting), e Ivan Nardini, Developer Advocate en Google Cloud (charla de partners). Todas las afirmaciones se han contrastado con la documentación oficial (lista completa de fuentes al final del artículo).

Las cifras de demostraciones en vivo son observaciones aisladas, no benchmarks; en el texto se marcan con «(demo)». Los consejos prácticos de los ponentes sin respaldo documental se marcan con «(heurística del ponente)». Fecha de este artículo: 13 de julio de 2026. En el momento de la conferencia estaban vigentes Claude Opus 4.7 y Sonnet 4.6. Desde entonces están disponibles Opus 4.8 y Claude Fable 5 (acceso a la promoción de Fable 5).

¿Cómo escribo bien los prompts para Claude?

Antes de cualquier corrección del prompt, construya primero una suite de evaluación que le dé el diagnóstico. Un prompt que lleva meses en producción y de pronto hace fallar casos de prueba al cambiar de modelo tiene dos causas posibles (recomendación de Margot van Laar en la charla sobre prompting).

O bien el nuevo modelo simplemente se comporta de otra manera, y eso se puede corregir mediante el prompt. O bien es sencillamente menos capaz para la tarea; entonces no sirve de nada ajustar el prompt, y solo ayuda otro modelo u otra arquitectura.

Su suite de evaluación necesita tres grupos de casos:

• Control cases: deben superarse siempre, porque son indiscutibles.
• Edge cases: casos en los que el modelo ya ha fallado alguna vez de forma comprobada.
• Casos de límite de competencia: comprueban si el modelo reconoce cuándo debería escalar o rechazar claramente una solicitud, en lugar de arrogarse competencias que no tiene.

Ordene el prompt solo después, en lugar de pulir de inmediato su redacción. Los prompts que crecen durante meses acumulan lastre: parches obsoletos para generaciones anteriores de modelos, textos copiados de sitios web, instrucciones contradictorias. Regla general: si al leerlo ya no distingue entre rol, guideline, policy, tono y datos, el modelo lo distinguirá aún menos.

Separe estos elementos estructuralmente con etiquetas XML: rol, guidelines, policy, tono y datos de uso en bloques propios. Añada un output contract y, a nivel de API, stop sequences que aseguren el formato de la respuesta.

En los objetivos, nombre siempre ambos lados de una disyuntiva, nunca solo uno. En el ejemplo mostrado, el prompt de un bot de soporte decía, en esencia: evitar la escalada a una persona porque cuesta unos 8 dólares estadounidenses (demo). Después, el bot no escalaba ni siquiera cuando habría sido necesario, por ejemplo ante un error real de facturación.

La solución: nombrar ambos lados, el coste de escalar y el coste de no escalar (reembolsos, pérdida de confianza). Cuanto más capaz es un modelo, con más coherencia optimiza el objetivo mencionado de forma explícita. Un objetivo formulado de manera unilateral no se interpreta con más tolerancia, sino que se cumple con más rigor; por eso, nombrar ambos lados es cada vez más importante con modelos más potentes, no menos.

Resuelva las tareas con restricciones duras mediante un bucle Generate-Evaluate-Repair en lugar de un único modelo grande. En una demo en vivo, un prompt sencillo fracasó al elaborar un plan semanal con restricciones duras (disponibilidad del personal, dotación mínima) (demo). Un modelo grande con thinking ampliado resolvió la tarea por completo, pero necesitó para ello aproximadamente el triple de tokens y la correspondiente latencia adicional (demo).

Lo más económico y fiable fue un bucle de tres prompts simples y separados:

1. El generador crea un borrador.
2. El evaluador lo revisa regla por regla, con una prueba por cada infracción.
3. El reparador corrige de forma selectiva solo los problemas notificados.

Resultado: todos los casos de prueba resueltos, con menor coste que el modelo grande por sí solo. Efecto secundario práctico: las reglas adicionales blandas y dependientes del caso, como «la persona A no debería coincidir con la persona B en el turno», pasan sencillamente al prompt del evaluador, en lugar de tener que modificar una función de comprobación rígida en el código.

¿Por qué mi agente de Claude empeora con el tiempo?

Cómo reconocer que su agente está inflado:

• El system prompt ha crecido durante meses y nadie se atreve ya a eliminar nada.
• Varias de sus herramientas son en realidad subagentes encubiertos con lógica propia.
• La tasa de aciertos de sus evaluaciones baja poco a poco, sin que parezca responsable ningún cambio concreto.
• El modelo asume trabajo de razonamiento para el que en realidad necesitaría una herramienta.

El primer paso: haga que Claude clasifique los fallos de sus propias evaluaciones. En un taller de la conferencia sobre descomposición de agentes, un agente de gestión de inventario sirvió como caso de estudio (demo): había crecido durante meses hasta unas 400 líneas de system prompt y doce herramientas, tres de ellas subagentes encubiertos. La tasa de aciertos de la evaluación había caído del 83 al 62 por ciento.

Los participantes del taller no hicieron el diagnóstico por sí mismos: dejaron que Claude Code clasificara los resultados de sus propias evaluaciones y extrajera los temas de los fallos. Resultado: el modelo asumía mucho trabajo de razonamiento para el que en realidad habrían hecho falta herramientas, la estructura de salida de los subagentes no estaba bien impuesta y el system prompt, demasiado largo, provocaba contradicciones.

Reconstruya el agente de forma radicalmente más ligera en cuanto el diagnóstico esté hecho. La reestructuración lo redujo a un prompt de 15 líneas, tres herramientas (Bash, Read, Write), skills para la lógica de negocio y exactamente un subagente restante para la previsión de ventas.

Una tarea que antes consumía más de 200.000 tokens porque se cargaba un archivo CSV completo en el contexto resultó drásticamente más barata tras pasar al acceso al sistema de archivos y a la ejecución de código (demo). Claude escribe y ejecuta él mismo Python, en lugar de procesar datos en bruto «de cabeza». El patrón de fondo: los agentes crecen por acumulación, nadie quita nada y, llegado el momento, el prompt carga más lastre que sustancia.

La palanca contra esto: las Agent Skills. Anthropic las define oficialmente como «packages» de instrucciones, metadatos y recursos. El principio de diseño central es la progressive disclosure: las skills se cargan en tres niveles; primero solo el frontmatter (nombre más descripción breve), luego, si hace falta, el cuerpo y después los archivos adicionales enlazados.

El contexto se mantiene ligero mientras no se necesita una skill, y las skills se pueden combinar (documentación oficial). Si quiere encargar un agente para su propia empresa, aquí encontrará el punto de partida: desarrollo de agentes de IA a medida. Un prompt ligero más skills, en lugar de un system prompt monolítico, es ya un componente central de la arquitectura profesional de agentes.

Para elegir herramientas, siga este orden (heurística del ponente): primero primitivas integradas (Bash, sistema de archivos, búsqueda web), después, si hace falta, custom tools y, solo cuando varios clientes o agentes deban compartir el mismo conjunto de herramientas, servidores MCP. La idea básica cuenta con respaldo documental: el blog de ingeniería de Anthropic recomienda ejecutar los servidores MCP mediante código («Code execution with MCP»), lo que aporta ventajas de tokens y latencia frente a tener muchas definiciones de herramientas MCP directamente en el contexto.

Use los subagentes de forma selectiva, no por defecto. Merecen la pena sobre todo cuando hay una paralelización real: muchas instancias de Claude trabajando a la vez en un mismo problema, por ejemplo en la exploración de una base de código. O cuando necesita un contexto «fresco» y sin lastre: un revisor que no sea el mismo agente que el autor. Todo lo demás suele resolverse con más sencillez directamente en el agente principal, complementado con una skill adecuada.

¿Qué funciones de Claude Code pasan por alto la mayoría de los equipos?

Según los ponentes, muy pocos equipos usan seis funciones pequeñas pero eficaces en el día a día. Una comprobación rápida para ver cuáles faltan en su flujo de trabajo:

1. Esc+Esc / /rewind: con la línea de entrada vacía, pulsar Escape dos veces abre un menú de rewind con el que puede devolver el código y/o la conversación a un punto anterior. Cuando un agente se ha perdido, suele ser más rápido que ordenar a mano (documentación).
2. Jerarquía de CLAUDE.md: al iniciarse, Claude Code carga por completo el CLAUDE.md del directorio de trabajo actual, además de todos los archivos CLAUDE.md de los directorios superiores y el global ~/.claude/CLAUDE.md. En cambio, los CLAUDE.md de las subcarpetas no se cargan automáticamente al inicio, sino solo cuando hacen falta. Con la sintaxis de rutas con @ se pueden importar además otros archivos. Contenido recomendado: comandos de build, estilo de código, flujos de trabajo recurrentes; cosas que, de otro modo, habría que explicar de nuevo en cada chat nuevo (documentación).
3. /model y /config: el modelo y la configuración se pueden cambiar en cualquier momento directamente en la sesión (documentación), sin abrir una sesión nueva para subtareas de distinta exigencia.
4. Interleaved thinking: ya no «think hard»: desde la generación Claude 4, Claude sigue pensando también entre llamadas a herramientas, y no solo una vez al principio de una respuesta (Anthropic lo llama interleaved thinking). En el vídeo de la conferencia se mencionaba todavía «think hard» como desencadenante; eso está desfasado. Según la documentación actual, únicamente «ultrathink» es la palabra desencadenante que Claude Code reconoce para el extended thinking; otras formulaciones como «think hard» se tratan ahora como texto corriente (documentación de Extended Thinking, documentación de Model Config).
5. Regulador de esfuerzo y Auto-Mode: cinco niveles oficiales (low, medium, high, xhigh, max), conmutables con /effort, y además un modo /fast independiente. Con Shift+Tab se recorren los modos de permisos, entre ellos el Auto-Mode. La documentación recomienda el Auto-Mode de forma condicional: cuando confía en la dirección de la tarea, no de manera generalizada (documentación de Model Config, documentación de Interactive Mode):

6. Sesiones paralelas mediante Git worktrees: no es una solución improvisada, sino una buena práctica documentada oficialmente: varias sesiones trabajan a la vez en ramas distintas sin estorbarse (documentación de Best Practices). Para equipos sin experiencia en paralelo, suele ser el paso más sencillo hacia un mayor rendimiento, sin tocar la arquitectura de prompts ni de agentes.

¿Qué son las Routines, los Memory Stores y los Dreams?

Revise estos cinco componentes de plataforma si quiere operar agentes de forma duradera y con memoria, y no solo de forma interactiva en una única sesión. Constituyen el segundo gran bloque temático de la conferencia. Importante de antemano: todos los componentes mencionados aquí tienen oficialmente el estado Beta o Research Preview; no son productos de disponibilidad general y plenamente maduros, sino funciones en evolución.

La base son los Claude Managed Agents (Beta): un agent harness prefabricado en infraestructura gestionada, ya sea en el sandbox en la nube de Anthropic o autoalojado. Ventaja frente a un agent loop construido por uno mismo: sin sandboxing propio, sin escalado ni gestión de sesiones propios; usted se concentra en herramientas, skills y subagentes.

Sobre ellos se apoyan las Multi-agent sessions, que en el vídeo todavía se llamaban «callable agents» y oficialmente son Multi-agent sessions. Un coordinador delega en hasta 20 agentes, cada uno como hilo de sesión propio con eventos integrados y observabilidad. Esto aborda un problema conocido de las configuraciones multiagente caseras: la comunicación entre el orquestador y los subagentes se pierde con facilidad y el registro de logs entre varios agentes resulta laborioso.

Para tener memoria más allá de las sesiones individuales existen los Memory stores (Beta): almacenamiento persistente y versionado bajo /mnt/memory/, a elección read_write o read_only a nivel de sistema de archivos. Cada cambio genera una versión nueva e inmutable como pista de auditoría, gestionable por API, CLI o Console. Límites: ocho Memory stores por sesión, 2.000 memories por store.

Como estos almacenes se vuelven confusos con el tiempo, existen los Dreams (Research Preview, acceso bajo solicitud). Un trabajo asíncrono genera, a partir de un Memory store y de 1 a 100 transcripciones de sesión, un Memory store nuevo y separado: verificado, deduplicado y reorganizado. El store de entrada permanece sin cambios.

Para ejecuciones proactivas, controladas por tiempo o por eventos, existen las Routines (Research Preview): sesiones completas de Claude Code en la infraestructura en la nube de Anthropic, activadas por una programación (intervalo mínimo de una hora), un API trigger (HTTP POST con Bearer token) o eventos de GitHub como pull requests o releases, incluidos filtros. Se crean con /schedule y están disponibles para cuentas Pro, Max, Team y Enterprise.

Tres patrones de equipo de la charla:

• Una pareja generador-crítico: una Routine abre pull requests y una segunda los revisa automáticamente.
• Un verificador de despliegues mediante webhook de CD.
• Una priorización semanal automatizada del backlog.

Para situar estos cinco componentes, aquí tiene un resumen compacto:

¿Cómo verifico lo que ha construido Claude?

Construya su verificación de modo que no solo las personas, sino también los agentes puedan comprobarla de forma fiable. Un equipo interno de Anthropic prepara así los cambios de frontend: mediante Storybook fixtures, atributos de datos del DOM que reflejan hacia fuera, de forma legible por máquina, el estado de un componente, y el Playwright MCP oficial de Microsoft.

Idea central: tres vías de comprobación equivalentes hacia el mismo resultado.

• Una persona recorre la aplicación haciendo clic manualmente.
• Un agente controla el mismo flujo en el navegador.
• El mismo flujo se ejecuta headless en la CI.

Cada ejecución se graba y se archiva como prueba.

Construya las especificaciones como artefacto HTML con elementos clicables, no como un documento Markdown largo. Es más denso en información y más fácil de valorar que un texto corrido que, de todos modos, casi nadie lee por completo.

Haga que Claude le entreviste activamente mediante el mecanismo AskUserQuestion (Claude plantea preguntas estructuradas con opciones de respuesta, en lugar de ponerse a trabajar de inmediato) en vez de tener que formularlo todo usted mismo de antemano. En las decisiones de diseño, haga además que se generen varias variantes en paralelo y compárelas visualmente.

Esto se ha vuelto más viable porque, según Anthropic, Opus 4.7 procesa bastante más resolución de imagen que su predecesor: hasta 2.576 píxeles de longitud de lado (unos 3,75 megapíxeles, tres veces más que Opus 4.6). En el benchmark de visual acuity, el modelo alcanza el 98,5 % frente al 54,5 % de Opus 4.6 (Anthropic).

Si quiere implantar estos flujos de verificación y de entrevista en su propia empresa, en nuestro curso de certificado de IA encontrará una introducción práctica a esta forma de trabajar con Claude.

¿Funciona Claude Code también en Google Cloud?

Sí, y para las empresas con infraestructura de Google Cloud ya existente es algo más que una nota al margen. En la charla de partners, Ivan Nardini, Developer Advocate en Google Cloud, mostró cómo funciona Claude Code en la Agent Platform de Google Cloud (antes Vertex AI). Tres cosas cambian en la configuración:

• Autenticación: Application Default Credentials en lugar de API key, activadas mediante la variable de entorno CLAUDE_CODE_USE_VERTEX=1; sin una clave aparte que rotar.
• Facturación: usted paga por consumo de tokens o contrata Provisioned Throughput, con capacidad reservada para aplicaciones de producción.
• Gobernanza: sus solicitudes pasan por su propio proyecto de GCP, con sus permisos IAM, cuotas y facturación; Google documenta por separado la gobernanza de datos y la Zero-Data-Retention (documentación de Claude Code, documentación de Google Cloud).

A esto se suman endpoints globales y regionales, según los requisitos de disponibilidad y de residencia de datos. Para el acceso a bases de datos, la charla mencionó MCP Toolbox for Databases, de código abierto y desarrollado por Google (googleapis/mcp-toolbox), que conecta los agentes con BigQuery y Looker.

Para las pymes con infraestructura GCP existente, esto significa en concreto: integrar un agente de Claude Code en su estructura de gobernanza y de costes actual sin gestión de claves adicional, en lugar de montar un mundo de facturación paralelo.

Para responsables de decisión: ¿qué significa esto para los equipos de desarrollo?

El cuello de botella del desarrollo de software se desplaza: deja de estar en escribir código y pasa a la revisión, la verificación y la coordinación (tesis de la charla de clausura).

Si programar ya no es el factor limitante, los cuellos de botella se trasladan adonde antes sobraba capacidad. ¿Quién revisa el código generado? ¿Quién coordina a los miembros del equipo y a los agentes que trabajan en paralelo? ¿Cómo se transmite el conocimiento cuando alguien ya trabaja de forma productiva con agentes en su primer mes?

Dentro de Anthropic, estos puntos cambian así (señalado expresamente como práctica interna, no como recomendación de validez general):

• La revisión de código ya no se hace de forma generalizada, sino a criterio humano, en función del riesgo del cambio.
• La planificación se hace just-in-time en lugar de en una larga hoja de ruta que, de todos modos, se queda obsoleta al cabo de unos meses.
• Los debates técnicos de fondo se resuelven cada vez más mediante varios pull requests competidores y realmente generados, en lugar de en la pizarra; se decide sobre el código terminado, con su efecto en todos los llamadores, y no según la argumentación más convincente de una reunión.
• Una actualización semanal de estado en una hoja de cálculo ha dado paso a una skill de standup propia, que recopila el estado de forma automatizada.

Renuncie al mero volumen de código como indicador de éxito: «X por ciento del código generado por IA» dice poco sobre calidad o utilidad. Mida, en cambio, el tiempo de incorporación, el tiempo de ciclo de los PR hasta el merge y la proporción de commits asistidos por IA como señal de contexto.

Estos indicadores no son un fin en sí mismos, sino que muestran si la revisión, la CI y el despliegue siguen el ritmo del rendimiento. Por eso, compruebe primero si su proceso de revisión y verificación está a la altura de lo que Claude Code entrega hoy, antes de invertir en más herramientas para agentes.

Preguntas frecuentes

¿Cómo paso mis prompts antiguos a ultrathink?

Revise de forma sistemática sus bibliotecas de prompts y plantillas en busca de la expresión «think hard» y sustitúyala por «ultrathink». El motivo: según la documentación actual de Claude Code, solo «ultrathink» es una palabra desencadenante reconocida para el extended thinking; «think hard» se trata hoy como texto corriente y ya no desencadena razonamiento adicional. En el vídeo de la conferencia, «think hard» aún se mencionaba como desencadenante; eso era correcto en el momento de la grabación, pero está desfasado.

¿Merece la pena para un equipo pequeño o solo para grandes organizaciones de desarrollo?

Lo básico (depuración de prompts basada en evaluaciones, higiene del CLAUDE.md, rewind, niveles de esfuerzo, skills ligeras en lugar de prompts inflados) funciona con independencia del tamaño del equipo y no cuesta nada adicional. La plataforma de agentes (Managed Agents, Routines, Memory Stores, Multi-agent Sessions) está ligada a cuentas Pro, Max, Team o Enterprise y tiene estado Beta o Research Preview, respectivamente. Para un equipo de cinco personas suele bastar al principio con lo básico, y los componentes de plataforma pueden esperar a una necesidad concreta.

¿Cuándo necesito un servidor MCP en lugar de una custom tool?

Según la heurística del ponente, apueste por MCP cuando varios clientes o varios agentes deban usar el mismo conjunto estandarizado de herramientas, por ejemplo cuando la misma herramienta del sistema de tickets la usan el agente de soporte y la configuración de Claude Code de los desarrolladores. Para un proyecto de agente individual suelen bastar las primitivas integradas, como Bash, sistema de archivos y búsqueda web, y, si hace falta, custom tools sencillas.

¿Necesito infraestructura de servidores propia para las Routines?

No. Las Routines se ejecutan como sesiones completas de Claude Code en la propia infraestructura en la nube de Anthropic y se inician mediante una programación, una llamada a la API o eventos de GitHub. La función tiene actualmente el estado Research Preview y está disponible para cuentas Pro, Max, Team y Enterprise.

¿Por dónde empiezo mañana?

Construya primero una pequeña suite de evaluación con casos de control, edge y de límite de competencia para su prompt más importante; sin evaluaciones, cualquier cambio en el prompt sigue siendo una adivinanza. Revise en paralelo que su CLAUDE.md esté actualizado y haga que Claude clasifique por sí mismo, a partir de los fallos de las evaluaciones, a un agente inflado.

Fuentes

El punto de partida de esta entrada fue un vídeo de @ajitcodes en X (https://x.com/ajitcodes/status/2076501882319810994) con grabaciones de sesiones de la conferencia Code with Claude; todas las afirmaciones se contrastaron y completaron con las siguientes fuentes primarias:

• Code with Claude London – página oficial de la conferencia
• Anthropic: Claude Opus 4.7
• Anthropic: Claude Sonnet 4.6
• Documentación de Claude Code: Interactive Mode
• Documentación de Claude Code: Memory (CLAUDE.md)
• Documentación de Claude Code: Commands
• Documentación de Claude: Extended Thinking
• Documentación de Claude Code: Model Config
• Documentación de Claude Code: Best Practices
• Documentación de Claude: Agent Skills Overview
• Anthropic Engineering: Equipping Agents for the Real World with Agent Skills
• Anthropic Engineering: Code Execution with MCP
• Documentación de Claude: Managed Agents Overview
• Documentación de Claude: Multi-agent Sessions
• Documentación de Claude: Memory Stores
• Documentación de Claude: Dreams
• Documentación de Claude Code: Routines
• GitHub: Microsoft Playwright MCP
• Documentación de Claude Code: Google Vertex AI
• Documentación de Google Cloud: Partner Models
• GitHub: Google MCP Toolbox for Databases

Las funciones Beta y Research Preview pueden cambiar en cualquier momento; todos los datos se basan en la documentación del proveedor, sin garantía.