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 supero los 5,000 likes en apenas dos horas. Cuando la persona que construyo la herramienta revela como la usa en la practica, la gente presta atencion.

Lo que mas me sorprendio fue la simplicidad. Nada de personalizaciones elaboradas ni configuraciones secretas. La base de su enfoque es combinar las funciones integradas de Claude Code de manera disciplinada y deliberada.

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

Procesamiento paralelo: ejecutar 15 sesiones de Claude al mismo tiempo

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

Su configuracion:

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

Esto no es multitarea por el simple hecho de hacerlo. Cada sesion maneja una tarea concreta y bien delimitada. El paralelismo surge de tener planes claros, no de cambiar de contexto constantemente.

Un dato interesante de los comentarios: Boris usa checkouts de git separados por pestana en lugar de git worktrees. Considera que el modelo mas simple es mas facil de razonar cuando manejas muchas sesiones al mismo tiempo.

Opus 4.5 con Thinking: lo mas grande es en realidad lo mas rapido

Boris usa 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 mas grande requiere menos correcciones, usa las herramientas con mayor precision y produce mejores resultados en el primer intento.

El efecto neto es que el tiempo total para completar una tarea es menor con Opus que con modelos mas pequenos, porque se gasta menos tiempo corrigiendo errores y reformulando prompts.

• Mejor rendimiento en programacion de cualquier modelo 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 mantiene un unico archivo CLAUDE.md registrado en Git. Cada vez que Claude comete un error, alguien agrega una nota a este archivo para que el mismo error no se repita.

Esto es ingenieria acumulativa en la practica:

• Varios miembros del equipo contribuyen actualizaciones semanalmente.
• Durante la revision de codigo, el equipo usa etiquetas @.claude para solicitar adiciones al CLAUDE.md.
• Cada equipo mantiene su propio CLAUDE.md.
• El archivo 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.

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

Boris inicia la mayoria de sus sesiones en Plan Mode (shift+tab dos veces). Si el objetivo es un pull request, discute el plan con Claude hasta quedar satisfecho, luego cambia al modo de auto-aceptacion y deja que Claude ejecute el plan completo sin interrupciones.

El flujo de trabajo:

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

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

Slash Commands y subagentes: automatizar el trabajo repetitivo

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

• Eliminan la necesidad de escribir prompts repetitivos.
• Usan bash en linea para pre-calcular contexto, haciendo los comandos mas rapidos.
• Subagentes como code-simplifier y verify-app manejan flujos de validacion comunes.
• Los hooks PostToolUse dan formato al codigo automaticamente despues de cada edicion.

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

Gestion de permisos e integracion de herramientas

En lugar de usar --dangerously-skip-permissions, Boris usa /permissions para pre-aprobar comandos seguros. El equipo comparte las configuraciones de servidores 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 un bloqueo total y un acceso sin restricciones. El equipo acuerda que es seguro, lo codifica y sigue adelante.

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

La practica mas importante en el 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 ciclo de verificacion incluye:

• Agentes en segundo plano que revisan el trabajo despues de completarse.
• Hooks de Agent Stop que ejecutan validaciones deterministicas.
• 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 ciclos de verificacion son la diferencia entre una calidad de 1x y una de 2-3x.

El patron detras de las practicas

Si dejamos de lado las herramientas y configuraciones especificas, emergen cuatro principios:

• Paralelizar agresivamente. Ejecutar muchas sesiones, cada una con un alcance claro y su propia rama.
• Planificar antes de construir. Plan Mode es la funcion de mayor apalancamiento en Claude Code.
• Compartir contexto como equipo. CLAUDE.md convierte lecciones individuales en conocimiento colectivo.
• Cerrar el ciclo de verificacion. Dejar que Claude revise su propio trabajo antes de que lo revises tu.

Lo mas llamativo de la configuracion de Boris no es ninguna tecnica individual, sino lo pocas piezas moviles que tiene. El creador de la herramienta no depende de configuraciones exoticas. Depende de los fundamentos, aplicados con consistencia.