your system language is:English

Boris Cherny: Claude Code e ingeniería de software con IA

Cover

📺 Vídeo de estudio recomendado hoy: https://www.youtube.com/watch?v=AmdLVWMdjOk


De Meta a Anthropic: Boris Cherny y la reinvención del ingeniero en la era de la IA

Boris Cherny, el creador de Claude Code, revela cómo pasó de hackear grupos de Facebook en la cafetería a liderar la revolución de la programación con agentes de IA. Descubre por qué el “sentido común” y las “side quests” son las herramientas más poderosas para escalar una carrera técnica hasta el nivel de Principal Engineer.

Pregunta central: ¿Cómo cambia el rol del ingeniero cuando la IA puede escribir el 90% del código y qué principios de producto permanecen inmutables?

Puntos clave

  • El concepto de “Demanda Latente” como el motor principal para el éxito de productos como Facebook Marketplace.
  • La importancia de las side quests (proyectos paralelos) para ganar influencia y acelerar la carrera técnica.
  • Por qué el futuro de la ingeniería no es escribir código manualmente, sino orquestar enjambres de agentes.
  • Cómo Claude Code ha disparado la productividad en Anthropic un 70% a pesar de triplicar el tamaño del equipo.

⏱️ Tiempo de lectura: aprox. 10 minutos · Te ahorra unos 75 minutos frente a ver el vídeo.

¿Quieres tomar notas mientras ves el vídeo? Haz clic en la imagen de abajo y deja que AI Notebook extraiga los puntos clave por ti 👇

AI Notebook


El poder de la Demanda Latente y la cultura de Meta

Hackeando la cafetería para entender al usuario

Boris comenzó su ascenso en Meta uniendo Messenger y Facebook Groups, un proyecto que requería entender comportamientos humanos antes que algoritmos complejos.

En los inicios de “Chats en Grupos”, el equipo carecía de investigadores de usuario formales, por lo que Boris implementó una técnica de guerrilla: llevaba a los ingenieros a la cafetería durante el almuerzo para observar cómo los trabajadores usaban las funciones sin instrucciones. Esta investigación observacional pura permitía ver dónde tropezaba la gente realmente, eliminando el sesgo de las preguntas guiadas y forzando a los ingenieros a desarrollar un “sentido de producto” agudo.

El concepto fundamental que Boris defiende es la “demanda latente”.

Según su experiencia, es casi imposible obligar a los usuarios a hacer algo que aún no quieren hacer; el éxito reside en observar cómo la gente ya está “abusando” de tus herramientas para satisfacer una necesidad y luego construir un producto oficial que facilite ese comportamiento. Facebook Marketplace nació precisamente así, tras notar que el 40% de los posts en grupos eran personas intentando comprar y vender objetos en una interfaz que no estaba diseñada para ello.

Functional diagram showing the 'Latent Demand' cycle: 1. Observe user behavior hacks (unintended use) -> 2. Analyze data of 'abuse' -> 3. Build a dedicated product around that intent -> 4. Achieve product-market fit (e.g., Facebook Marketplace).

💡 Profundizando

Q: ¿Qué es exactamente la demanda latente? A: Es identificar una intención que el usuario ya tiene pero que satisface de forma ineficiente, para luego darle una vía directa.
Q: ¿Por qué Boris prefiere contratar ingenieros generalistas? A: Porque un ingeniero que entiende de diseño, producto y datos tiene un impacto exponencial comparado con uno que solo se limita a escribir código.
Q: ¿Cuál fue el mayor reto al colaborar entre Facebook y Messenger? A: El choque cultural; un equipo priorizaba la velocidad extrema y el otro la confiabilidad absoluta de los sistemas.


Side Quests: La vía rápida hacia la influencia técnica

De una moto rota a un libro de TypeScript

Las side quests o proyectos paralelos no son simples distracciones; son, según Boris, la forma más efectiva de construir una red de contactos y ganar autoridad técnica real en una organización grande.

Boris creó Unidux simplemente porque Redux le parecía demasiado complejo para su cerebro de “ingeniero promedio”. Al notar que otros ingenieros en Meta compartían su frustración en foros internos, decidió no esperar permiso: mapeó qué equipos tenían más problemas, programó charlas técnicas con ellos y, en poco tiempo, su herramienta personal se convirtió en el estándar de gestión de estado de la compañía, superando a las soluciones oficiales del momento.

Incluso los desastres personales pueden convertirse en catalizadores de carrera.

Tras un accidente de motocicleta que le dejó ambos brazos fracturados, Boris se vio obligado a buscar lenguajes de programación que requirieran menos pulsaciones de teclas para evitar el dolor. Este obstáculo físico lo llevó a profundizar en Haskell, Scala y, finalmente, a escribir un libro fundamental sobre TypeScript que le dio visibilidad mundial, demostrando que profundizar en la teoría por necesidad práctica es un diferencial competitivo enorme.

Concept map: Side Quests (Tooling, Books, Open Source) -> Shared Pain Discovery (Identifying common problems) -> Internal Adoption (Tech Talks, Scraping Issue Groups) -> Career Leverage (Influence, Promotion, Credibility).

💡 Profundizando

Q: ¿Cómo se gestiona un desacuerdo con un ingeniero mucho más senior? A: Ganando su confianza primero, demostrando que puedes ejecutar su visión incluso si no estás de acuerdo, antes de proponer cambios drásticos.
Q: ¿Qué libro técnico recomienda por encima de todos? A: “Functional Programming in Scala”, no por el lenguaje, sino por cómo redefine tu manera de estructurar soluciones lógicas.
Q: ¿Es beneficioso entrar a una empresa en un nivel “bajo”? A: Sí, porque reduce la presión inicial y te permite “sorprender” positivamente, construyendo un impulso de reputación difícil de frenar.


La revolución de Claude Code en Anthropic

El fin de la era de la escritura manual

En Anthropic, Boris aprendió una lección vital de su mánager: no debes construir herramientas para el modelo de lenguaje de hoy, sino para el que existirá dentro de seis meses.

Esta mentalidad permitió que Claude Code pasara de ser un asistente de autocompletado mediocre a una herramienta capaz de escribir el 90% del código en algunos equipos. El impacto es tangible: a pesar de que la empresa ha triplicado su tamaño, la productividad por ingeniero ha crecido un 70%, un fenómeno inaudito en el desarrollo de software tradicional donde el crecimiento del equipo suele ralentizar la entrega debido a la burocracia.

Hoy, la ingeniería se parece más a la gestión de personal que a la artesanía manual.

Boris describe un flujo de trabajo donde el ingeniero actúa como un orquestador que “alinea” un plan con el modelo de IA antes de dejar que este ejecute la tarea. Existe incluso el “vibe coding” para prototipos rápidos, pero para el código de producción mantienen un estándar de hierro: no se acepta código de la IA que no pase la misma revisión rigurosa que el de un humano, fomentando una relación de “pareja de programación” donde el humano aporta la visión y la IA la fuerza bruta de ejecución.

Architecture diagram of Claude Code workflow: User/Engineer Input -> Agentic Planning Phase -> Iterative Code Generation -> Terminal/Environment Feedback Loop -> Human Review/Final Commit.

💡 Profundizando

Q: ¿Cómo ha cambiado la forma de programar de Boris? A: Ahora inicia varios agentes por la mañana desde su móvil para que preparen el trabajo y, al llegar al ordenador, solo revisa y fusiona los cambios.
Q: ¿Qué opina del ‘vibe coding’? A: Es excelente para prototipos y código desechable, pero peligroso si no se tiene una barra de calidad estricta para el código mantenible.
Q: ¿Es la IA solo para ingenieros? A: No, en Anthropic, equipos de ventas y datos usan Claude Code para conectar bases de datos y automatizar flujos complejos sin ser programadores expertos.


Conclusiones clave

Boris Cherny nos recuerda que, a pesar del avance vertiginoso de la inteligencia artificial, el éxito en la ingeniería sigue anclado en principios humanos: el sentido común y la capacidad de observar las necesidades reales del usuario. Su trayectoria demuestra que los ingenieros más valiosos no son aquellos que dominan una única tecnología, sino los generalistas curiosos que se atreven a salir de su carril para resolver problemas de infraestructura o producto que otros ignoran.

La verdadera palanca de crecimiento para un profesional técnico hoy no está en trabajar más horas, sino en buscar problemas compartidos y automatizarlos agresivamente. Ya sea mediante reglas de lint personalizadas o enjambres de agentes de IA, el objetivo final es el mismo: liberar tiempo de las tareas tediosas para enfocarse en la estrategia y la creatividad, manteniendo siempre una conexión emocional con el código que se construye.


Preguntas y Respuestas

Q1: ¿Por qué Boris prefiere que no haya títulos jerárquicos en las empresas?
A1: Porque cree que la falta de títulos obliga a las personas a ganarse el respeto y la autoridad día a día a través de su competencia técnica y su capacidad de colaboración, en lugar de apoyarse en un cargo estático.

Q2: ¿Cuál es su consejo principal para realizar estimaciones técnicas rápidas?
A2: No perderse en los detalles infinitos. Recomienda dedicar máximo 30 minutos a un bosquejo inicial y usar herramientas como Claude Code para mapear rápidamente los sistemas involucrados.

Q3: ¿Cómo manejó el síndrome del impostor al liderar a ingenieros de su mismo nivel en Meta?
A3: Entendiendo que nadie, en ningún nivel, sabe realmente lo que está haciendo al 100%. Sentir ese miedo es simplemente una señal de que estás empujando tus propios límites.

Q4: ¿Qué es el “unshipping” y por qué es importante en Instagram?
A4: Es la práctica de eliminar funciones que no tienen suficiente uso. Aunque moleste a una minoría, mantiene la aplicación limpia, rápida y enfocada para la gran mayoría de los usuarios.

Q5: ¿Cómo afectó el cambio de zona horaria al mudarse a Japón su productividad?
A5: Fue un beneficio inesperado; al no poder asistir a reuniones en horario estadounidense, recuperó bloques gigantescos de tiempo para programar, lo que le permitió reconectar con su pasión y evitar el agotamiento.

Q6: ¿Qué recomienda a quienes no tienen un título formal en Ciencias de la Computación?
A6: Aprender de forma práctica y aplicada. Boris, que estudió Economía, sostiene que la programación es una habilidad práctica que se domina construyendo productos reales, y la teoría se puede absorber después con mayor contexto.

Q7: ¿Cómo visualiza Boris el futuro de la ingeniería de software?
A7: Como una transición de “escribir código” a “orquestar agentes”. El ingeniero del futuro será un gestor de contexto y un revisor de calidad más que un ejecutor de líneas de código.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts