💬 Comunicación y autonomía
El cuello de botella pasó a ser la interacción
Los modelos ya ejecutan muy bien las tareas de código. Lo que todavía falla es la interacción:
preguntar demasiado, actuar demasiado poco, narrar el pensamiento, enterrar el resultado. Este módulo sigue la evolución de las secciones de
cómo comunicar e cómo actuar sin preguntar en los prompts reales de Claude Code
(4.6 → 4.8 → Fable 5).
Contenido detallado
El cuello de botella pasó de la capacidad a la interacción
En los primeros prompts de agentes de código, el esfuerzo se centraba en enseñar al modelo a ejecutar: cómo llamar herramientas, cómo editar archivos, cómo ejecutar pruebas. Hoy los modelos lo hacen bien. Lo que sigue siendo difícil no es la capacidad, sino la interacción. Por eso los prompts más recientes dedican secciones enteras a cómo hablar con el usuario e cuándo actuar sin preguntar.
🎯 La nueva frontera: los dos modos de fallar
Cuando la capacidad deja de ser el límite, la experiencia pasa a definirse por dos errores opuestos — y el prompt existe precisamente para calibrar el punto entre ellos:
Preguntó demasiado
Pide confirmación para editar un archivo local. Narra cada paso. Devuelve opciones en vez de una recomendación. El usuario termina siendo gerente de un agente temeroso.
Actuó de menos / actuó de más
Se detiene ante la primera duda en vez de seguir el camino obvio, o hace un git push sin avisar. Ambas cosas cuestan confianza.
Por qué esto surge AHORA en los agentes de código
Un chatbot solo produce texto: no hay ninguna acción en el mundo que confirmar. Un agente de código escribe en disco, ejecuta comandos, hace push y envía mensajes. Cada acción tiene radio de impacto (radio de impacto) y reversibilidad diferentes. Es esa capacidad de actuar en el mundo que crea la necesidad de una política de comunicación y autonomía.
Cómo comunicar — tono, concisión y presupuesto de salida
El agente se ejecuta en el terminal: el usuario no ve el pensamiento ni los resultados en bruto de las herramientas, solo el texto de salida.
Esto impone reglas de tono distintas a las de un chat. Claude Code dedica bloques enteros a esto. Mira cómo se declara la regla de tono en el
claude-code-2.1.172-opus-4.6.md:
# Tone and style (líneas 49–53)- Only use emojis if the user explicitly requests it.
- Your responses should be short and concise.
- When referencing specific functions or pieces of code include
the pattern file_path:line_number to allow the user to easily
navigate to the source code location.
- Do not use a colon before tool calls. ... text like "Let me read
the file:" followed by a read tool call should just be "Let me
read the file." with a period.
Justo después, el bloque # Text output trata de presupuesto de salida —
cuánto texto producir y dónde colocarlo. Aquí aparece el Patrón 7 (Presupuesto de concisión) en acción:
La regla del terminal (4.6, líneas 55–64)
- •"Antes de la 1.ª llamada a una herramienta, di en una frase qué vas a hacer."
- •Actualizaciones breves en momentos clave: al encontrar algo, cambiar de rumbo o quedar bloqueado.
- •"Brief is good — silent is not." Casi siempre basta con una frase.
- •Resumen al final del turno: 1–2 frases. Qué cambió y qué sigue.
No narres la deliberación
"Don't narrate your internal deliberation. User-facing text should be relevant communication to the user, not a running commentary on your thought process."
La concisión aquí no es solo «responder de forma breve»: es elegir qué merece incluirse en el texto. El pensamiento queda en el thinking; el texto presenta resultados y decisiones.
Cuándo explicar más
El 4.6 ya incluye el criterio de calibración: «Match responses to the task: a simple question gets a direct answer, not headers and sections.» La concisión es relativa a la tarea, no un límite fijo. Pregunta exploratoria → 2–3 frases con recomendación y compensación (línea 19). Tarea sencilla → respuesta directa.
Cómo actuar sin preguntar — autonomía calibrada
El contrapunto de la comunicación es la autonomía: actuar sin pedir permiso cuando la acción es segura. La regla maestra de Claude Code es simple y poderosa: calibra según la reversibilidad y por el radio de impacto por la acción, no por su importancia.
✓ Actuar por cuenta propia (local y reversible)
- ✓Leer archivos, hacer grep, explorar el repositorio
- ✓Editar archivos locales y ejecutar pruebas
- ✓Crear una rama local, hacer un commit local
- ✓Seguir el camino obvio sin devolver un menú de opciones
✗ Confirmar antes (irreversible o externo)
- ✗Eliminar archivos/ramas,
rm -rf, elimina la tabla - ✗Force-push,
git reset --hard, amend del commit publicado - ✗Push, abrir/comentar PR, enviar Slack/e-mail
- ✗Subir contenido a un servicio externo (se vuelve público e indexable)
# Executing actions with care (línea 34)Generally you can freely take local, reversible actions like
editing files or running tests. But for actions that are hard to
reverse, affect shared systems ..., check with the user before
proceeding. The cost of pausing to confirm is low, while the cost
of an unwanted action ... can be very high.La asimetría que justifica la regla
La política no es "sé cauteloso siempre"; eso sería volver a preguntar demasiado. Es una análisis de costo asimétrico: detenerse para confirmar cuesta poco; una acción no deseada (trabajo perdido, mensaje enviado, rama eliminada) cuesta mucho. Por lo tanto, autonomía total en el lado barato y reversible; confirmación en el lado costoso e irreversible.
Cuándo confirmar — la prueba de las 3 preguntas
"Confirmar antes" no es un sentimiento: es un prueba. Una acción cruza el umbral de confirmación si responde "sí" a cualquiera de tres preguntas. Y hay un matiz crucial sobre autorización que el prompt deja explícita.
¿Es difícil de revertir?
Force-push, reset --hard, eliminar la dependencia, sobrescribir cambios sin commit. Si no existe «ctrl-Z», confirma.
¿Afecta un estado compartido / es visible para otros?
Push, PR, mensaje en Slack/e-mail, infraestructura compartida. El blast radius sale del entorno local. Confirma.
¿Va a un servicio externo (se publica)?
Renderizadores de diagramas, pastebins, gists. "It may be cached or indexed even if later deleted." Puede ser sensible. Confirma.
La regla más sutil: la autorización no se extiende
En 4.6 (línea 34): "A user approving an action (like a git push) once does NOT mean that they approve it in all contexts ... Authorization stands for the scope specified, not beyond."
Es decir: el usuario aprobó ese push, no "pushes en general". La excepción es autorización duradera — instrucciones en el
CLAUDE.md o un "opera de forma autónoma" explícito. Entonces el agente prosigue, pero aún atento al riesgo.
✓ Ante un obstáculo: investigar
- ✓Encontrar la causa raíz y corregir el problema de fondo
- ✓Resolver un conflicto de merge en lugar de descartar cambios
- ✓Investigar un archivo o branch desconocido — puede ser trabajo en curso
✗ Atajo destructivo: nunca
- ✗Usar
--no-verifypara pasar el hook que se queja - ✗Eliminar el archivo de bloqueo en vez de verificar qué proceso lo mantiene
- ✗Sobrescribir un estado inesperado sin entender qué es
Conexión con los Patrones 7 y 11
La comunicación y la autonomía no son patrones nuevos aislados: ellas aplican dos patrones del catálogo de la Ruta 1 a un contexto de agente. Reconocer esa conexión es lo que transforma la lectura de un prompt en comprensión de un principio.
Presupuesto de concisión
El bloque # Text output es el Patrón 7 en estado puro: define cuánto el texto cabe
("1–2 frases por update", "resumen de fin de turno en 1–2 frases").
En el terminal, el presupuesto es limitado a propósito: cada línea extra ensucia el historial. La concisión es gestión de un recurso escaso, no una cuestión de estilo.
Jerarquía de prioridad
"Confirmar antes" queda anulado por autorización duradera (CLAUDE.md). Esto es precedencia: la instrucción de usuario prevalece sobre el valor predeterminado del prompt.
Y una skill cargada no se impone al usuario: altera el comportamiento dentro del espacio que el usuario permitió. Usuario > skill > predeterminado.
This default can be changed by user instructions - if explicitly
asked to operate more autonomously, then you may proceed without
confirmation ... unless actions are authorized in advance in
durable instructions like CLAUDE.md files, always confirm first.Usuario × Skill: ¿quién manda?
Cuando una skill dice "sé breve como un cavernícola" y el usuario pide una explicación detallada, el el usuario prevalece. La skill define el cómo dentro del espacio autorizado; el usuario define los límites de ese espacio. Es la misma lógica de "la autorización no se extiende": quien tiene la precedencia es siempre la instrucción más cercana a la intención real del usuario.
La evolución de las secciones: 4.6 → 4.8 → Fable 5
Aquí está el rasgo distintivo de este acervo: puedes ver la misma política siendo reorganizada tres veces en pocos meses. El contenido es estable; lo que cambia es cómo se empaqueta — y cada reempaquetado cuenta una historia sobre lo que estaba fallando.
Distribuido en 4+ secciones con nombre
2088 líneas
La política está en bloques separados: # Doing tasks,
# Executing actions with care,
# Tone and style,
# Text output. Muchas viñetas, prosa generosa, ejemplos enumerados de acciones riesgosas.
Señal: la regla es lo bastante nueva como para necesitar mucho espacio y muchos ejemplos explícitos.
Consolidado en # Harness
1798 líneas (−290)
Las 4 secciones se condensan en un bloque denso: 5 viñetas breves + un solo párrafo que comprime "Executing actions with care". "Tone and style" y "Text output" prácticamente desaparecen como títulos: se convierten en reglas internalizadas. Toda la confirmación de riesgo cabe en una frase (línea 16).
Señal: el comportamiento ya se estabilizó durante el entrenamiento → se necesita menos prompt. Es consolidación por internalización (la lección central de la Trilha 2).
Reexpandido en # Communicating with the user
1821 líneas (+23)
La comunicación vuelve a ser una sección nombrada y en prosa — pero con ideas nuevas, no las antiguas: "Lead with the outcome", la regla de que todo lo que el usuario necesita debe estar en la mensaje final del turno, y la tesis explícita «ser legible y ser conciso son cosas distintas, y la legibilidad importa más".
Señal: la falla cambió. Ya no es "el agente habla demasiado", sino "el agente comprime tanto que se vuelve ilegible (flechas, jerga, fragmentos)". El prompt corrige el nuevo error.
# Communicating with the user (línea 22)Being readable and being concise are different things, and readable
matters more. ... The way to keep output short is to be selective
about what you include ..., not to compress the writing into
fragments, abbreviations, arrow chains like `A -> B -> fails`,
or jargon.La lección del arco 4.6 → 4.8 → Fable 5
Reorganizar una sección no es cosmético: cada movimiento corrige el efecto secundario del movimiento anterior. El 4.8 redujo demasiado la comunicación; Fable 5 vuelve a abrir la sección para impedir que «conciso» se convierta en «ilegible». Promover algo nuevamente a un título con nombre es una señal tan fuerte como eliminarlo.
📝 Resumen del módulo
Actividad del módulo
Abre Anthropic/Claude Code/claude-code-2.1.172-opus-4.6.md en la sección
# Executing actions with care (líneas 32–42) y enumera 3 reglas de «cuándo confirmar».
Entregable: resumen de la política de autonomía de un agente, en prosa, no con flechas.
Siguiente módulo
2.5 — Caso OpenAI: personalidades y la familia GPT-5.x → 5.5