Como el creador de Claude Code realmente usa Claude Code

Boris Cherny, el creador de Claude Code, compartio publicamente su flujo de trabajo de desarrollo, y en solo dos horas supero los 5.000 likes. Cuando la persona que ha construido la herramienta revela como la usa de verdad, la gente presta atencion.

Lo que mas me sorprendio fue la sencillez. Sin personalizaciones complicadas, sin configuraciones secretas. El nucleo de su enfoque consiste en combinar las funcionalidades integradas de Claude Code de forma disciplinada y deliberada.

Si habeis leido el reciente analisis de Andrej Karpathy sobre las capas de abstraccion que los desarrolladores deben entender en los agentes de codigo con IA, la guia de Boris es el complemento practico perfecto.

Procesamiento en paralelo: 15 sesiones de Claude a la vez

Boris ejecuta cinco instancias de Claude simultaneamente en el terminal, mas otras cinco o diez en claude.ai/code a traves del navegador. Incluso inicia sesiones desde el movil por la manana y las revisa mas tarde.

Su configuracion:

• Numera las pestanas del terminal del 1 al 5 y utiliza notificaciones del sistema para saber cuando se necesita su intervencion.
• Alterna entre sesiones locales y web con el comando &.
• Usa --teleport para saltar entre sesiones.
• Cada pestana del terminal tiene su propio checkout de git, de modo que cada sesion ejecuta un plan independiente en una rama independiente.

Esto no es multitarea por el mero hecho de hacerla. Cada sesion se ocupa de una tarea discreta y bien delimitada. El paralelismo surge de tener planes claros, no de cambiar de contexto constantemente.

Un detalle interesante de los comentarios: Boris usa checkouts de git separados por pestana en lugar de git worktrees. Le resulta un modelo mas sencillo de manejar mentalmente cuando hace malabarismos con muchas sesiones.

Opus 4.5 con pensamiento: lo mas grande es realmente mas rapido

Boris utiliza el modelo mas grande disponible para cada tarea. Esto es contraintuitivo: Opus es mas lento por token y mas caro. Pero su razonamiento es practico: el modelo grande requiere menos correcciones, usa las herramientas con mas precision y produce mejores resultados en el primer intento.

El efecto neto es que el tiempo total de finalizacion de una tarea es menor con Opus que con modelos mas pequenos, porque se dedica menos tiempo a corregir errores y a reformular prompts.

• Mejor rendimiento en programacion de todos los modelos que ha probado.
• Menos intervenciones necesarias durante la ejecucion.
• El tiempo real total disminuye a pesar de la mayor latencia por token.

CLAUDE.md: ingenieria de contexto en equipo

Todo el equipo hace commit de un unico fichero CLAUDE.md en Git. Cada vez que Claude comete un error, alguien anade una nota a este fichero para que el mismo fallo no vuelva a ocurrir.

Esto es ingenieria acumulativa en la practica:

• Varios miembros del equipo aportan actualizaciones cada semana.
• Durante las revisiones de codigo, el equipo utiliza etiquetas @.claude para solicitar adiciones al CLAUDE.md.
• Cada equipo mantiene su propio CLAUDE.md.
• El fichero se convierte en un cuerpo creciente de conocimiento institucional que cada sesion de Claude hereda.

El concepto es sencillo, pero la disciplina de mantenerlo de forma consistente es lo que lo hace poderoso.

Modo Plan: una buena planificacion es el 90 % del exito

Boris inicia la mayoria de las sesiones en Modo Plan (shift+tab dos veces). Si el objetivo es un pull request, discute el plan con Claude hasta que le satisface, luego activa el modo de aceptacion automatica y deja que Claude ejecute el plan completo sin interrupciones.

El flujo de trabajo:

1. Invertir tiempo al principio en la fase de planificacion.
2. Iterar sobre el plan hasta que cubra casos limite y problemas potenciales.
3. Una vez cerrado el plan, cambiar a ejecucion automatizada.
4. Minimizar las correcciones de ida y vuelta durante la implementacion.

Este patron elimina el modo de fallo mas habitual: empezar a programar antes de tener claro el enfoque. Planificar es barato. Rehacer es caro.

Slash Commands y subagentes: automatizar el trabajo repetitivo

Cualquier flujo de trabajo que Boris usa mas de unas pocas veces al dia se convierte en un slash command, guardado en .claude/commands/. Comandos como /commit-push-pr quedan disponibles para el propio Claude, no solo para el desarrollador.

• Eliminar por completo los prompts repetitivos.
• Usar bash inline para precomputar contexto, haciendo que los comandos sean mas rapidos.
• Subagentes como code-simplifier y verify-app se encargan de los flujos de validacion habituales.
• Los hooks PostToolUse formatean el codigo automaticamente tras cada edicion.

Boris tambien entiende los Skills como una forma de slash commands: definiciones de flujos de trabajo reutilizables y compartibles que estandarizan como Claude aborda tareas especificas.

Gestion de permisos e integracion de herramientas

En lugar de usar --dangerously-skip-permissions, Boris utiliza /permissions para preaprobar los comandos seguros. El equipo comparte las configuraciones del servidor MCP para que Claude pueda acceder directamente a Slack, BigQuery, Sentry y otras herramientas.

• Compartir la configuracion de permisos a traves de .claude/settings.json.
• Compartir las integraciones de herramientas a traves de .mcp.json.
• Minimizar las solicitudes de permisos innecesarias sin sacrificar la seguridad.

Este es el punto medio pragmatico entre el bloqueo total y el acceso sin restricciones. El equipo acuerda lo que es seguro, lo codifica y sigue adelante.

Bucles de verificacion: el multiplicador de calidad de 2-3x

La practica mas importante del flujo de trabajo de Boris: darle a Claude una forma de verificar su propio trabajo.

En claude.ai/code, hace que Claude pruebe cada cambio a traves de una extension de Chrome que interactua con la aplicacion real. El bucle de verificacion incluye:

• Agentes en segundo plano que revisan el trabajo tras completarlo.
• Hooks Agent Stop que ejecutan validaciones deterministas.
• El plugin ralph-wiggum para verificacion adicional.
• Entornos sandbox con modos de permisos ajustados para evitar bloqueos.
• Pruebas reales de UX en navegadores y simuladores.

Esto no es un pulido opcional. Boris considera que los bucles de verificacion son la diferencia entre una calidad de salida de 1x y de 2-3x.

El patron detras de las practicas

Si eliminamos las herramientas y configuraciones concretas, emergen cuatro principios:

• Paralelizad de forma agresiva. Ejecutad muchas sesiones, cada una con un alcance claro y su propia rama.
• Planificad antes de construir. El Modo Plan es la funcionalidad de mayor apalancamiento en Claude Code.
• Compartid contexto como equipo. CLAUDE.md convierte las lecciones individuales en conocimiento colectivo.
• Cerrad el bucle de verificacion. Dejad que Claude revise su propio trabajo antes de que vosotros lo reviseis.

Lo mas llamativo de la configuracion de Boris no es ninguna tecnica individual, sino lo pocos elementos moviles que tiene. El creador de la herramienta no depende de configuraciones exoticas. Depende de los fundamentos, aplicados de forma consistente.