"7 Consejos de Claude Code + Opus 4.7 de Boris Cherny"

"## 7 Consejos de Claude Code + Opus 4.7 de Boris Cherny\n\nEstaba a mitad de una build de un clon de Linear cuando el nuevo video de siete consejos de Boris Cherny apareció en mi feed, y casi lo ignoré.\n\nMi excusa sonaba razonable. Llevo más de un año usando Claude Code a diario. He escrito más de ochenta publicaciones al respecto en este blog. He probado cada nivel de esfuerzo, cada actualización de modelo, cada plugin que pasó por mi terminal. ¿Qué podría decirme el tipo que construyó Claude Code que yo no hubiera descubierto ya por mi cuenta?\n\nEntonces dijo una frase que me detuvo en seco: "Con Opus 4.7, ya no toco el interruptor de extended thinking. Desapareció." Pausé el video, abrí mi consola de API y lo confirmé. Tenía razón. El parámetro thinking: {type: \"enabled\", budget_tokens: N} que había estado ajustando durante meses ahora devuelve un error 400 en Opus 4.7. Anthropic lo eliminó silenciosamente. El pensamiento adaptativo es ahora el único modo de "thinking activado", y se controla con la redacción del prompt, no con un interruptor.\n\nEso fue una sola frase. El video tenía siete consejos. Si ya estaba tan equivocado sobre uno de ellos, claramente le debía a los otros seis una escucha justa.\n\nAsí que pasé los siguientes cuatro días reconstruyendo mi clon de Linear desde cero, aplicando cada una de las técnicas de Boris en trabajo real, no en prompts de juguete ni en scripts de demo. Proyectos, tareas, estado, prioridad, responsables, una UI en Next.js. La misma especificación que él demostró. Y registré qué cambió, qué no, y qué consejos me quedo de forma permanente versus cuáles estoy descartando en silencio.\n\nEsto es lo que aprendí. Los siete consejos. Las cosas que estaba haciendo mal. Y la redacción exacta que hizo que Opus 4.7 se comportara.\n\n## Una nota rápida sobre la fuente: realmente es Boris Cherny\n\nAntes de entrar en materia, las transcripciones de esta charla que circulan por ahí lo llaman "Churnney", "Cherny" y varias formas intermedias. La persona que creó Claude Code es Boris Cherny, exingeniero de Meta y actualmente Head of Claude Code en Anthropic. Se unió a Anthropic en 2024, lanzó Claude Code como proyecto paralelo en su primer mes, y el producto cruzó los $1 billion en run-rate de ingresos a principios de 2026. Cuando habla sobre cómo usar esta herramienta, vale la pena detenerse a escuchar, porque también es la persona que decide qué se lanza a continuación.\n\nUna corrección más de fuente mientras somos cuidadosos: la segunda herramienta con la que Boris compara Claude Code en la charla es OpenCode, no "OpenClaw", que es como yo lo escuché primero en la transcripción. OpenCode es el agente de terminal de código abierto que enruta a más de 75 proveedores de LLM. Mantén ese nombre claro; volveremos a él.\n\nAhora, los siete consejos, probados de nuevo.\n\n## Consejo 1: Auto Mode es el predeterminado ahora. Deja de luchar contra el ciclo de permisos.\n\nLo admito: he sido un usuario de "plan mode → acceptEdits → aprobar manualmente" durante la mayor parte de 2025. La idea de dejar que Claude Code ejecute comandos bash sin que mis ojos estuvieran en cada uno de ellos me parecía imprudente. Como entregarle las llaves del servidor de producción a alguien con el motor encendido.\n\nAuto mode terminó con esa hesitación.\n\nAquí está la mecánica real. Claude Code tiene cuatro modos de permisos por los que se cicla con Shift+Tab: default → acceptEdits → plan → auto. La ranura de auto mode solo aparece en el ciclo si tu cuenta califica y lo has habilitado. En un plan Max o Team, claude --enable-auto-mode lo activa, y a partir de ahí una tercera pulsación de Shift+Tab te lleva a auto.\n\nLo que hace diferente a auto mode de acceptEdits no es la interfaz, sino el clasificador. Antes de que se ejecute cada llamada de herramienta, un modelo de seguridad separado basado en Sonnet 4.6 revisa la acción. Si huele a eliminación masiva de archivos, exfiltración de datos o escalada impulsada por inyección de prompts, la bloquea. Todo lo demás se ejecuta. Anthropic lanzó este modo el 24 de marzo de 2026, específicamente para manejar la clase de fatiga de permisos con la que la mayoría de los usuarios avanzados habían estado lidiando con listas de permitidos personalizadas.\n\nCuando probé de nuevo la build del clon de Linear de Boris en auto mode, la diferencia no estaba en la calidad del código, sino en mi atención. No estaba mirando el terminal. Estaba en la app de escritorio de Claude redactando el copy de la UI para la página de tareas mientras Claude Code conectaba el esquema de Prisma, ejecutaba migraciones, sembraba datos de prueba y levantaba el servidor de desarrollo. Veintitrés llamadas de herramienta ocurrieron sin un solo prompt de permiso. Ninguna me necesitó.\n\nEl único punto donde matizaría el planteamiento de Boris: auto mode no es el predeterminado correcto para todos los proyectos. Si estoy tocando el repositorio de producción de un cliente, o cualquier cosa donde un rm -rf accidental costaría dinero, sigo en acceptEdits. El clasificador es bueno, pero "bueno" a esta escala todavía significa fallos ocasionales. Para builds en proyectos nuevos, para mis propios proyectos personales, para cualquier cosa donde un git reset sea barato, auto mode es donde vivo ahora.\n\nSi has estado ciclando con Shift+Tab entre default y plan durante los últimos seis meses, ese es el hábito a romper. Una pulsación más y estás en un modo diseñado para el flujo.\n\n## Consejo 2: Frontloada toda la especificación. Opus 4.7 te recompensa por ello.\n\nEste es el consejo que más mejoró la calidad de mi output, y el que más activamente resistí.\n\nMi hábito, y probablemente el tuyo también, era hacer prompts de forma incremental. Construye el esquema de base de datos. Luego las rutas de API. Luego la UI. Luego conéctalas. En cada paso, revisaba el output, ajustaba y pasaba la siguiente instrucción. Se sentía como control. Se sentía responsable.\n\nNo era ninguna de las dos cosas. Era un hábito heredado de los modelos de la era GPT-4 que no podían mantener una especificación grande en mente.\n\nLa demo de Boris fue una refutación directa. Abrió Claude Code y le entregó a Opus 4.7 algo así, aproximadamente, como un único prompt:\n\n> Construye un clon de Linear. Los proyectos contienen tareas. Cada tarea tiene un estado (todo, in-progress, done), una prioridad (low, medium, high, urgent), un responsable (de una tabla de usuarios) y soporte para etiquetas. Usa Next.js App Router, Prisma con SQLite para desarrollo local, Tailwind para estilos y componentes de shadcn/ui. La UI debe tener una barra lateral de proyectos, una vista de tablero de tareas y un modal de detalle de tarea. No me hagas preguntas: elige valores predeterminados razonables y lánzalo.\n\nSeis minutos después tenía un clon de Linear funcionando. No un esqueleto. Una app funcionando, corriendo en localhost, con datos semilla, un tablero Kanban funcional y un modal de detalle de tarea que se abría limpiamente.\n\nCuando lo probé en mi retest, entré escéptico. Mi primer intento tomó unos siete minutos y medio. Mi segundo intento, con una especificación más ajustada, tomó menos de seis. En ambas ocasiones el output era genuinamente utilizable. No perfecto; tuve que arreglar una ruta de importación de shadcn y una clase de Tailwind que referenciaba un token de color indefinido, pero al 85-90% listo para producción en el primer intento.\n\nLa lección que Boris transmite aquí es sutil. La ventana de contexto de Opus 4.7, combinada con su pensamiento adaptativo, significa que puede mantener toda la arquitectura en mente mientras construye cualquier pieza individual. Cuando haces prompts de forma incremental, le estás ocultando información. Lo obligas a reconstruir el contexto en cada mensaje. Peor aún, le estás señalando que las piezas son independientes, lo que significa que las construye como si lo fueran, y la fase de integración se convierte en su propio caos.\n\nFrontloading significa: escribe la especificación completa antes de presionar enter. Incluye el framework de UI. Incluye el modelo de datos. Incluye lo que no debe hacer. Incluye la dirección estética. Cada pieza de contexto que proporcionas por adelantado es una pieza que Claude no tiene que adivinar.\n\nMi regla general ahora: si mi primer prompt tiene menos de 150 palabras, no he pensado lo suficiente en lo que estoy pidiendo.\n\n## Consejo 3: Claude Code vs OpenCode — Usa la herramienta adecuada para el trabajo\n\nEste es el consejo donde Boris es sorprendentemente honesto para alguien cuyo trabajo es vender Claude Code.\n\nNo dice "usa Claude Code para todo". Traza una línea. Claude Code, en su planteamiento, es para trabajo profundo, complejo y de calidad de producción, el tipo de build donde te importa que el output sea de calidad de producción, donde las decisiones arquitectónicas importan, donde querrías que un ingeniero senior hubiera tomado las decisiones. OpenCode es para prototipos rápidos y herramientas de agente ligeras donde la velocidad de iteración importa más que el pulido del output.\n\nHe estado usando ambas durante un par de meses, y su planteamiento es acertado.\n\nOpenCode, el agente de terminal de código abierto, no Codex, no la propuesta de OpenAI, tiene una ventaja real para los prototipos. Enruta a más de 75 proveedores de LLM, así que puedo lanzar un agente desechable en un modelo económico para iteración rápida y pagar por token en lugar de comprometerse con una suscripción. Cuando estoy construyendo una herramienta de línea de comandos de un solo uso que usaré durante una semana y luego descartaré, OpenCode llega a un estado funcional más rápido porque no me importa la calidad del código de algo que nunca mantendré.\n\nClaude Code es el tradeoff opuesto. Es exigente con la calidad. Está optimizado para los modelos de Anthropic, lo que significa que obtiene el mejor output de Opus 4.7 por defecto. Tiene el ecosistema de plugins más profundo, el sistema de hooks maduro, el framework de habilidades del que dependo diariamente. Cuando estoy construyendo algo que mantendré durante seis meses, esa exigencia es una característica.\n\nEl consejo dentro del consejo: deja de intentar encontrar El Único Agente Verdadero. Quieres dos. Uno para "necesito que esto funcione antes de cenar y no me importa si el código es feo". Uno para "estaré depurando esta app a las 2 AM dentro de seis meses, y las decisiones arquitectónicas que tome hoy me perseguirán". Adapta la herramienta al trabajo.\n\n## Consejo 4: /recap — El comando que no sabías que necesitabas\n\nEste lo había perdido genuinamente. De alguna manera. Lleva disponible desde abril de 2026, está en la documentación y nunca lo había escrito.\n\n/recap es un slash command que imprime un resumen de una línea por acción de todo lo que ocurrió en tu sesión actual de Claude Code. Qué archivos se tocaron. Qué comandos se ejecutaron. Qué pruebas pasaron o fallaron. Es configurable en /config, y hay una variable de entorno CLAUDE_CODE_ENABLE_AWAY_SUMMARY que controla si se activa automáticamente cuando regresas a una sesión inactiva.\n\nLa razón por la que importa no es la característica en sí, sino el flujo de trabajo que desbloquea.\n\nTengo un hábito que sospecho que muchos de ustedes comparten. Inicio una larga sesión de Claude Code, me alejo, vuelvo cuarenta minutos después con un café frío y tengo que pasar tres o cuatro minutos leyendo el scrollback para entender dónde estábamos. ¿Qué había terminado Claude? ¿Qué seguía roto? ¿Esa migración realmente se ejecutó? ¿Cuál era el archivo de prueba que estaba fallando?\n\n/recap responde todo eso en unos dos segundos. Una línea por acción. Lo escaneo, sé dónde estamos, instruccionó el siguiente movimiento.\n\nEl otro lugar donde me salvó esta semana: estaba manejando tres sesiones paralelas de Claude Code (un hábito que el propio Boris ejecuta a 5-10 instancias paralelas en un día normal). Cambiar de contexto entre ellas estaba arruinando mi flujo. /recap en cada ventana se convirtió en mi equivalente de acercarme a una pizarra para reorientarme. Menos de diez segundos para saber qué había estado haciendo una sesión.\n\nSi no lo has escrito todavía, pruébalo la próxima vez que regreses a una sesión en ejecución. La primera vez se sentirá como encontrar una característica que no debería existir.\n\n## Consejo 5: Niveles de esfuerzo — Extra High y Max son reales y son herramientas diferentes\n\nAquí tengo que corregir un error que cometí en mi propia mente antes de este retest.\n\nHabía asumido que "max effort" y "extra high effort" eran distinciones de marketing. No lo son. Son modos genuinamente diferentes con diferentes tradeoffs, y el planteamiento de Boris me lo aclaró.\n\nClaude Code tiene cinco niveles de esfuerzo: low, medium, high, xhigh (extra high) y max. En Opus 4.7, el predeterminado es xhigh para todos los planes y proveedores, aunque Anthropic bajó silenciosamente el predeterminado de high a medium en las suscripciones Pro y Max en marzo de 2026, lo cual vale saber si tu output se ha sentido un poco más delgado este año de lo que solía ser.\n\nLa diferencia entre xhigh y max importa. xhigh persiste entre sesiones. Es el nivel que puedes establecer de forma permanente y olvidar. max no persiste: es un modo solo para la sesión actual, a menos que lo fijes con la variable de entorno CLAUDE_CODE_EFFORT_LEVEL. Max elimina todas las restricciones de tokens en el pensamiento. No hay límite. Claude gastará todo lo que la tarea parezca necesitar.\n\nLa regla de Boris, que coincide casi exactamente con mi retest:\n\n- Low / Medium: trabajo trivial. Ediciones de un solo archivo. Refactorizaciones pequeñas. Planes de los que estás seguro son correctos.\n- High: trabajo estándar de características donde quieres un razonamiento sólido sin gastar de más.\n- Extra High (xhigh): trabajo de características donde la arquitectura importa, o donde el primer instinto de Claude suele ser sutilmente incorrecto.\n- Max: prompts grandes y frontloaded. Mi build del clon de Linear. Migraciones de sistemas completos. El tipo de tarea donde le estás entregando a Opus 4.7 una especificación y esperas un output casi completo.\n\nPara el retest del clon de Linear, ejecuté tres versiones. Una con high, una con xhigh, una con max. High produjo una app funcional con tres bugs obvios. Xhigh produjo una app funcional con un problema cosmético. Max produjo una app funcional sin problemas en el primer intento, pero tardó un 40% más y gastó aproximadamente 3x los tokens.\n\nLa curva de costos es real. No ejecutes max en todo. Pero no le tengas miedo para las tareas que lo justifican; un prompt de build frontloaded es exactamente ese tipo de tarea.\n\nSi prefieres que alguien realice este tipo de build con arquitectura primero por ti, ya sea una herramienta interna tipo Linear, un prototipo de SaaS o un producto integrado con AI, acepto builds personalizados a través de fiverr.com/s/EgxYmWD. Pero absolutamente puedes lograrlo tú mismo con el flujo de trabajo de esta publicación.\n\n## Consejo 6: Notificaciones — Deja de vigilar el terminal\n\nEste consejo es de una simpleza absurda y arregló más de mi flujo de trabajo de lo que tenía derecho.\n\nBoris configura notificaciones de finalización de tareas para poder dejar corriendo trabajos largos de Claude Code sin mirar el terminal. Luego trabaja en otra cosa: hacer brainstorming en la app de escritorio de Claude, escribir especificaciones, prepararse un café, hasta que su Mac le avisa que Claude terminó o necesita input.\n\nEl mecanismo es un Stop hook en el sistema de hooks de Claude Code. Los Stop hooks se activan cuando Claude termina su tarea actual. Puedes adjuntar cualquier comando de shell que quieras, incluyendo osascript para activar una notificación de macOS, un webhook de Slack, o una llamada a terminal-notifier. También hay un Notification hook que se activa en prompts de permiso, prompts de inactividad o diálogos de elicitación, lo cual es útil si estás en un modo que aún solicita aprobaciones.\n\nAquí está el fragmento mínimo de ~/.claude/settings.json que estoy usando:\n\njson\n{\n \"hooks\": {\n \"Stop\": [\n {\n \"matcher\": \"\",\n \"hooks\": [\n {\n \"type\": \"command\",\n \"command\": \"osascript -e 'display notification \\\"Claude finished\\\" with title \\\"Claude Code\\\" sound name \\\"Glass\\\"'\"\n }\n ]\n }\n ],\n \"Notification\": [\n {\n \"matcher\": \"permission_prompt\",\n \"hooks\": [\n {\n \"type\": \"command\",\n \"command\": \"osascript -e 'display notification \\\"Needs your input\\\" with title \\\"Claude Code\\\" sound name \\\"Ping\\\"'\"\n }\n ]\n }\n ]\n }\n}\n\n\nDos sonidos diferentes. Dos estados diferentes. Sé cuál es cuál sin mirar la pantalla.\n\nLos hooks asíncronos que Anthropic lanzó en enero de 2026 también importan aquí: permiten que los comandos de notificación se ejecuten en segundo plano sin bloquear la ejecución de Claude, lo que significa que no hay pausas extrañas cuando se activa una notificación a mitad de una tarea.\n\nEl punto meta que Boris está planteando con este consejo no se trata de la notificación en sí. Se trata del cambio de modelo mental. Si estás mirando Claude Code trabajar en tiempo real, tú eres el cuello de botella. No estás haciendo otra cosa. No estás pensando por adelantado. Eres un espectador en tu propio trabajo. Las notificaciones te permiten pasar de espectador a director, y un director que ejecuta dos o tres sesiones de Claude en paralelo es genuinamente un tipo diferente de desarrollador que uno que trabaja en un solo terminal en tiempo real.\n\n### El multiplicador de flujo de trabajo: hacer brainstorming en la app de escritorio de Claude mientras Claude Code corre\n\nBoris menciona esto como un detalle al margen en el video, pero es una de las piezas de mayor apalancamiento en toda la charla.\n\nMientras Claude Code ejecuta un trabajo largo, abre la app de escritorio de Claude, un producto totalmente separado, no Claude Code, y la usa como superficie de brainstorming. Sin llamadas de herramientas. Sin ediciones de archivos. Solo un contexto de chat donde está pensando en la siguiente característica, redactando lenguaje de especificación, verificando decisiones de arquitectura.\n\nCuando su Mac le avisa que Claude Code terminó, tiene un próximo prompt completamente formado listo para disparar. Sin tiempo muerto de "déjame pensar en qué preguntar a continuación".\n\nCopié este patrón para el retest. Mi build del clon de Linear tuvo tres puntos de pausa naturales. En cada uno, en lugar de mirar el terminal, abrí la app de escritorio y redacté la siguiente especificación. El tiempo total de reloj para la build bajó de lo que habría sido un proyecto de medio día a aproximadamente una hora y cuarenta minutos de trabajo real.\n\n## Consejo 7: Pensamiento adaptativo — El interruptor murió. Viva el prompt.\n\nEste es el que tuve mal. Déjame explicar qué cambió realmente.\n\nEn Opus 4.6 y anteriores, controlabas el extended thinking con un parámetro explícito: thinking: {\"type\": \"enabled\", \"budget_tokens\": N}. Establecías un presupuesto de tokens. Claude pensaba hasta ese presupuesto. Directo.\n\nEn Opus 4.7, ese parámetro devuelve un error 400. Los presupuestos de extended thinking desaparecieron. Reemplazados por pensamiento adaptativo, un modo donde Claude mismo decide cuándo pensar más profundamente y cuánto gastar, basándose en la complejidad de cada solicitud.\n\nEl pensamiento adaptativo está desactivado por defecto en Opus 4.7. Lo activas con thinking: {type: \"adaptive\"} en la API, o, y este es el punto clave para usuarios de Claude Code, lo diriges con la redacción del prompt.\n\nDos frases que realmente marcan la diferencia:\n\n- "Think carefully step by step" — le señala a Claude que esta es una tarea que vale la pena quemar tokens de razonamiento. Gastará más en razonamiento por paso.\n- "Prioritize responding quickly" — señala lo contrario. Claude acorta su razonamiento y responde más rápido, a costa de algo de profundidad.\n\nAquí está el matiz que me tomó un día internalizar completamente: el esfuerzo y el pensamiento son ahora perillas separadas. El nivel de esfuerzo es el presupuesto total de recursos para una tarea, cuánto trabajo está dispuesto a hacer Claude en general, a través de llamadas de herramientas, lecturas de archivos y reintentos. El pensamiento es la profundidad de razonamiento por paso, qué tan duro piensa Claude antes de tomar cualquier decisión individual.\n\nPuedes tener alto esfuerzo con bajo pensamiento (muchas acciones, cada una decidida rápidamente) o bajo esfuerzo con alto pensamiento (pocas acciones, cada una considerada cuidadosamente). Para mi retest del clon de Linear, max effort + la frase "think carefully step by step" produjo el output más limpio. Para una corrección rápida de bug en una ruta de API, xhigh effort + "prioritize responding quickly" terminó en aproximadamente un tercio del tiempo sin sacrificar la corrección.\n\nEl otro cambio que vale conocer: a partir de Opus 4.7, el contenido de pensamiento se omite de la respuesta por defecto. Los bloques de pensamiento todavía aparecen en el stream de respuesta, pero su contenido está vacío a menos que te suscribas explícitamente. Ese es un cambio silencioso, sin error, sin advertencia, y mejora ligeramente la latencia de respuesta. Si tenías herramientas que analizaban el output de pensamiento, verifica si todavía funcionan.\n\n## Lo que me quedo y lo que descarto\n\nCuatro días de retesting. Mi puntuación honesta.\n\nMe quedo de forma permanente:\n- Auto mode para builds nuevos y trabajo personal. El clasificador es suficientemente bueno. El flujo vale la pena.\n- Especificaciones frontloaded para cualquier build que no sea una edición trivial de un solo archivo. Este fue el mayor salto de calidad.\n- /recap como memoria muscular en cada reanudación de sesión. Una ganancia sin costo.\n- Notificaciones via Stop hooks, siempre. Me avergüenza no haberlo configurado hace un año.\n- Redacción de prompts para pensamiento adaptativo porque no tengo elección: el interruptor desapareció.\n\nMe quedo con matices:\n- Nivel de esfuerzo Max, pero solo para las tareas correctas. No es un ajuste de "más es mejor". Úsalo cuando la tarea lo justifique.\n- El planteamiento Claude Code vs OpenCode: estoy de acuerdo con la división, pero sigo recurriendo primero a Claude Code la mayoría de los días, porque el ecosistema se acumula.\n\nLo que descarto:\n- Nada, honestamente. Cada consejo resistió el trabajo real. Por eso estoy publicando esta entrada en lugar del artículo "aquí está donde Boris se equivoca" que a medias esperaba escribir cuando empecé el retest.\n\nSi has leído mi análisis profundo anterior sobre el flujo de trabajo diario de Boris Cherny o mi desglose del impacto práctico de Opus 4.7, notarás que estos siete consejos se superponen con los principios que Boris ha estado compartiendo públicamente durante meses. Lo nuevo es el comportamiento específico de Opus 4.7, el pensamiento adaptativo, el interruptor de extended thinking eliminado, max effort como un nivel real, y la forma en que auto mode ha madurado de un flag experimental a algo que ahora recomiendo como predeterminado para trabajo nuevo.\n\n## El test del clon de Linear — Lo que realmente se lanzó\n\nDe vuelta a la build con la que empecé.\n\nCuatro días, tres retests, siete técnicas aplicadas limpiamente. El clon de Linear con el que terminé tiene proyectos con tareas anidadas, un tablero Kanban de arrastrar y soltar, campos de estado y prioridad, responsables de usuarios extraídos de una base de datos semilla, soporte de etiquetas, una barra lateral de proyectos y un modal de detalle de tarea, exactamente la especificación que Boris demostró. Next.js App Router, Prisma con SQLite, Tailwind, componentes de shadcn/ui.\n\nTiempo total de edición humana: aproximadamente cuarenta minutos, distribuidos en las tres builds. Tiempo total de Claude Code: aproximadamente tres horas y media en todas las ejecuciones. Tokens totales en la mejor ejecución: alrededor de 450K de entrada y 180K de salida. La mejor ejecución fue la que usó max effort, especificación frontloaded, auto mode, redacción de prompt consciente del pensamiento adaptativo y notificaciones de Stop hook.\n\nCada uno de los siete consejos de Boris contribuyó algo. Elimina cualquiera de ellos y la build empeora, se vuelve más lenta o más interrumpida.\n\n## Preguntas frecuentes\n\n### ¿Es /recap un comando real de Claude Code?\nSí. /recap se lanzó en Claude Code en abril de 2026 e imprime un resumen de una línea de las acciones de tu sesión actual. Es configurable a través de /config, y puedes forzar el comportamiento de activación automática con la variable de entorno CLAUDE_CODE_ENABLE_AWAY_SUMMARY. Consulta el desglose completo de niveles de esfuerzo y sesiones más arriba.\n\n### ¿Cuál es la diferencia entre los niveles de esfuerzo "high" y "max" de Claude Code?\nEl esfuerzo high limita la profundidad de pensamiento y las llamadas de herramientas a un techo razonable; max elimina el límite completamente y se aplica solo a la sesión actual (a menos que lo fijes con CLAUDE_CODE_EFFORT_LEVEL). Usa max para builds frontloaded de complejidad arquitectónica. Usa high para trabajo estándar de características. El framework de decisión completo está en el Consejo 5.\n\n### ¿Cómo habilito auto mode en Claude Code?\nEjecuta claude --enable-auto-mode para desbloquearlo en tu cuenta, luego presiona Shift+Tab tres veces para ciclar a través de default → acceptEdits → plan → auto. Auto mode requiere un plan Team, Enterprise o API y usa un clasificador basado en Sonnet 4.6 para bloquear las llamadas de herramientas arriesgadas antes de que se ejecuten.\n\n### ¿Realmente Anthropic eliminó el extended thinking en Opus 4.7?\nSí. Configurar thinking: {\"type\": \"enabled\", \"budget_tokens\": N} en Opus 4.7 devuelve un error 400. El pensamiento adaptativo (thinking: {type: \"adaptive\"}) es ahora el único modo de pensamiento activado, y Claude decide la profundidad de pensamiento dinámicamente. Lo diriges con la redacción del prompt, como "think carefully step by step" o "prioritize responding quickly". Detalles en el Consejo 7.\n\n### ¿Debería usar Claude Code u OpenCode?\nAmbos. Usa Claude Code para builds profundos y de calidad de producción donde la arquitectura y la calidad del código importan. Usa OpenCode para prototipos rápidos, herramientas desechables o cuando necesitas enrutar a modelos que no son de Anthropic. El planteamiento de Boris en el Consejo 3 coincide con mi propia experiencia en ambas herramientas.\n\n## Una última cosa\n\nLa razón por la que los siete consejos de Boris funcionan no es que sean ingeniosos. La mayoría de ellos, individualmente, son pequeños. /recap es un slash command. Un Stop hook son diez líneas de JSON. Auto mode es un flag.\n\nLa razón por la que funcionan es que juntos te mueven de ser la persona que escribe en Claude Code a ser la persona que lo dirige, y que dirige dos o tres instancias de él a la vez, mientras piensas en el siguiente problema por adelantado. Cada consejo de la lista elimina una tarea de vigilancia, eleva la calidad del output o te ayuda a especificar lo correcto antes de presionar enter.\n\nHe pasado cuatro días reconstruyendo el mismo clon de Linear de tres maneras, y el consejo al que sigo volviendo no es ninguno de los siete. Es el meta-consejo debajo de todos ellos: los desarrolladores que están ganando con Claude Code ahora no son los que aprendieron más prompts. Son los que dejaron de actuar como si estuvieran en una conversación con una AI y empezaron a actuar como si estuvieran dirigiendo un pequeño equipo de ingeniería de uno.\n\nShift+Tab tres veces. Frontloada la especificación. Déjalo correr. Ve a redactar el próximo prompt en la app de escritorio mientras las notificaciones manejan las actualizaciones.\n\nEse es todo el juego.\n\n## Let's Work Together\n\n¿Buscas construir sistemas de AI, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.\n\n* Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD\n* Portfolio: mejba.me\n* Ramlit Limited (enterprise solutions): ramlit.com\n* ColorPark (design & branding): colorpark.io\n* xCyberSecurity (security services): xcybersecurity.io"