6 Trucos de Boris para Opus 4.7

Boris Cherny es el creador de Claude Code — la herramienta con la que millones de personas usan Claude desde la terminal. No es un usuario cualquiera contando su experiencia: es el ingeniero que diseñó la forma en que Claude entra a tu computadora.

Desde el lanzamiento de Opus 4.7 (16 de abril de 2026), Boris lo estuvo usando todos los días en proyectos reales — lo que en Anthropic llaman “dogfooding” (cuando los mismos que hacen el producto lo usan como usuarios). En sus propias palabras, se siente “increíblemente productivo”. Y soltó seis trucos concretos para que tú llegues a la misma sensación.

Los 6 trucos son, en orden:

1. Auto mode — Claude decide solo qué es seguro ejecutar.
2. /fewer-permission-prompts — una skill que te arma el allowlist de permisos.
3. Recaps — resumen automático de qué hizo y qué falta.
4. Focus mode — esconde los pasos intermedios, solo te enseña el resultado.
5. Effort level — le subes o bajas el nivel de esfuerzo a Claude.
6. Dale cómo probar su trabajo — Chrome extension, Computer Use, bash. El más importante.

Tweet original: Boris arrancó el hilo diciendo que después de dogfoodear Opus 4.7 unas semanas se siente increíblemente productivo — y estos seis trucos son la razón.

Imagínatelo así: es como el piloto automático de un coche. Maneja solo por la carretera, pero si ve algo raro (animal en el camino, una curva rara) te despierta para que tomes el volante. No te pregunta cada vez que quiere cambiar de carril.

Antes, cuando Claude iba a ejecutar un comando, te preguntaba por cada cosa: ¿puedo correr npm install? ¿puedo leer este archivo? ¿puedo editar? Era cansadísimo. La alternativa era usar --dangerously-skip-permissions — o sea, “hazle como quieras” — y rezar.

Con auto mode, Anthropic metió un clasificador: un modelo chiquito que revisa cada comando que Claude quiere correr y decide:

• Si es seguro (leer, correr tests, instalar paquetes comunes) → lo aprueba solito.
• Si huele raro (borrar archivos, tocar el .env, subir a producción) → te pausa y te pregunta.

Cómo activarlo

1. Abre Claude Code en la terminal (o el Desktop / VS Code).
2. Presiona Shift + Tab — verás cómo el modo cicla entre Ask permissions → Plan mode → Auto mode. Déjalo en Auto.
3. En Desktop o VS Code, también puedes elegirlo desde el dropdown de modos.

Cómo usarlo según tu nivel

Captura del tweet: Boris explica el flujo — auto-aprueba lo seguro, pausa si huele raro.

Imagínatelo así: es como cuando Netflix te aprende el patrón. La primera vez te pide PIN para ver algo, pero después ya sabe que tú eres tú y deja de molestarte.

Esta skill oficial de Anthropic hace una sola cosa, pero la hace bien: revisa el historial de tu sesión, encuentra los comandos bash y MCP que corres seguido (y que son seguros), y te los muestra en una lista para que los apruebes todos de una sentada. Cada aprobación se guarda en tu permissions allowlist, que es donde Claude lee qué puede hacer sin preguntarte.

Cómo activarla

1. Claude revisa las últimas interacciones de tu sesión.
2. Detecta los comandos que más se repiten y que son seguros (por ejemplo npm test, git status, ls).
3. Te enseña una lista curada. Tú marcas los que sí quieres aprobar.
4. Los agrega a tu permissions allowlist y listo — no te los vuelve a preguntar.

Cómo usarla según tu nivel

Captura del tweet: así se ve la skill sugiriendo una lista de comandos seguros para añadir al allowlist.

Imagínatelo así: es el “previously on…” de tus series, pero de tu propia sesión con Claude. Te recuerda qué hiciste y en qué te quedaste — para que cuando regreses horas después no andes perdido.

Los recaps son resúmenes cortos que Claude suelta al final de una tarea larga. Te dice:

• Qué hizo — qué archivos tocó, qué PRs abrió, qué pruebas corrió.
• Qué falta — el siguiente paso pendiente.

Así se ve uno real

* Cogitated for 6m 27s

* recap: Fixing the post-submit transcript shift bug. The styling-flash
  part is shipped as PR #29869 (auto-merge on, posted to stamps). Next:
  I need a screen recording of the remaining horizontal rewrap on `cc -c`
  to target that separate cause. (disable recaps in /config)

Ejemplo oficial del propio markdown de Boris. Fíjate en "Next:" — es el renglón que te dice dónde retomar.

Cómo apagarlos (si te estorban)

Los recaps vienen prendidos por defecto. Si te saturan en sesiones cortas, los apagas en la configuración:

En el menú de configuración encuentras la opción para desactivar los recaps. Pero el consejo de Boris (y el nuestro) es dejarlos prendidos.

Cómo usarlos según tu nivel

Captura del tweet: Boris enseña un recap real de su propia sesión — PR enviado, siguiente paso identificado.

Imagínatelo así: es como un restaurante fancy donde te traen el plato ya listo y emplatado — no te enseñan la cocina, los pasos, ni cuántas veces probaron la salsa. Lo que te importa es el platillo final.

Focus mode hace exactamente eso: esconde todos los pasos intermedios que Claude toma — las lecturas de archivos, los greps, los edits individuales, los comandos que corre — y solo te enseña el resultado final. Menos texto en pantalla, más foco en la salida.

Cómo activarlo

El comando funciona como un interruptor: /focus una vez lo prende, otra vez lo apaga.

Cómo usarlo según tu nivel

Captura del tweet: Boris explica que ya confía en Claude lo suficiente como para ver solo el output final.

Imagínatelo así: es el slider de dificultad de un videojuego. En fácil juegas rapidito, los enemigos son tontos, ganas sin pensar. En modo nightmare, cada enemigo es un desafío y tardas más — pero el juego se pone bueno.

Opus 4.7 cambió la forma de controlar el “pensamiento” de Claude. Antes había thinking budgets (le asignabas X tokens para pensar). Ahora hay adaptive thinking — Claude decide cuánto pensar, pero tú le dices qué tan duro le meta con un slider de 5 niveles.

Los 5 niveles

Al lado izquierdo del slider = Velocidad. Al lado derecho = Inteligencia.

Qué nivel usar por tarea

Cómo usarlo según tu nivel

Captura del tweet: el slider con los 5 niveles. Velocidad a la izquierda, inteligencia a la derecha.

Imagínatelo así: un mecánico que arregla tu moto pero también la maneja una vuelta a la manzana antes de dártela. Si algo no jala, lo nota él — no tú al subirte. Esa es la diferencia entre un mecánico malo y uno bueno.

Claude puede construir cosas impresionantes, pero si no tiene cómo verificar que lo que construyó funciona, tú te conviertes en su tester. Y eso te consume el día. La solución: dale tú mismo las herramientas para que pruebe.

Tres caminos para verificar

El workflow /go que usa Boris

Boris cuenta que sus prompts se ven así: Claude haz blah blah /go. El /go es una skill personal que Boris armó y que hace estas tres cosas en cadena:

1. Se prueba solo de principio a fin — con bash, el navegador o Computer Use (lo que aplique al proyecto).
2. Corre /simplify para limpiar el código.
3. Abre un Pull Request con todo listo para revisar.

Claude, construye [lo que quieras].
Cuando termines, ejecuta /go — que haga:

1. Prueba end-to-end con bash, browser o computer use (según aplique).
2. Corre /simplify para limpiar el código.
3. Abre un Pull Request con el resumen.

Si algo falla en la prueba, arréglalo y vuelve a probar antes de abrir el PR.

Captura del tweet: Boris insiste en que darle forma de verificar es lo más importante — y comparte su skill /go como patrón.

Los seis trucos no viven solos — se potencian. Auto mode sin verificación es peligroso. Focus mode sin recaps te deja ciego. Effort level sin saber qué tarea haces te quema el plan. Por eso Boris los presenta juntos.

Te recomendamos activarlos en este orden — del más universal al más opcional: