Echemos un vistazo a la historia del nacimiento de Claude Code, basada principalmente en una entrevista con la bloguera tecnológica Gergely Orosz sobre un miembro clave de Claude Code. Claude Code es realmente notable, con unos ingresos anualizados de 500 millones de dólares y un aumento de diez veces en el volumen de usuarios en tres meses, y ahora es la herramienta preferida de Coding Agent por muchos programadores. Esta herramienta empezó como un pequeño juguete de línea de comandos que te decía "qué canción estás escuchando ahora mismo." 🧵

Gergely Orosz entrevistó a tres miembros clave de Claude Code: • Boris Cherny, Ingeniero Fundador (17 años de experiencia, ex Ingeniero Jefe de Meta) • Ingeniero 2 Sid Bidasaria (autor de la sección Subagentes) • y Cat Wu, directora de producto. Hablaron de cómo Claude Code pasó de prototipo a producto, qué decisiones técnicas tomaron y cómo el pequeño equipo de una docena de personas pudo publicar 5 PRs al día. Probablemente esta sea la muestra más parecida a un "equipo de ingeniería con IA primero" en este momento. Utilizan IA para escribir código, hacer pruebas, hacer revisiones de código, solucionar problemas e incluso usar Claude Code para desarrollar Claude Code en sí. El 90% del código está escrito por sí mismo. Lo que quiero hacer es analizar las partes más interesantes de esta entrevista, hablar sobre cómo funciona este equipo, qué se puede aprender y qué está determinado por sus condiciones especiales y no puede copiarse. El siguiente se divide en 7 relatos cortos, cada uno de los cuales puede leerse de forma independiente, y se encadena para formar una imagen completa.

[1] Cómo un dispositivo de escucha puede convertirse en un producto con unos ingresos anuales de 500 millones de dólares En septiembre de 2024, Boris Cherny acaba de unirse a Anthropic y escribió un juguete de línea de comandos cuando no tenía nada que hacer. ¿Qué puede hacer esta cosa? Utiliza AppleScript para decirte qué canción estás escuchando y cambia la canción según tus órdenes. Así de sencillo. El propio Boris comentó: "Demo bastante chulo, pero no interesante. ”

El verdadero giro llegó después de que terminó de charlar con su compañera Cat Wu. Cat estaba estudiando las capacidades informáticas del Agente de IA, y mientras charlaban, Boris tuvo una idea: ¿y si le damos más permisos a esta herramienta de línea de comandos? Por ejemplo, ¿que pueda leer y escribir archivos y ejecutar comandos?

Lo intentó. Entonces, llega el momento de presenciar el milagro. Boris metió la herramienta mejorada en la base de código de Anthropic y le hizo algunas preguntas. Claude empezó a explorar el sistema de archivos por su cuenta—leyendo un archivo, viendo la declaración de importación en su interior y luego leyendo el archivo referenciado, profundizando capa a capa hasta encontrar la respuesta. "Me sacudió", recuerda Boris, "y nunca había usado una herramienta así. ”

En el campo de la IA, existe un concepto llamado "sobrecarga de producto", que se traduce como "sobrecarga de producto". Esto significa que el modelo tiene una cierta capacidad, pero la forma de producto existente no libera esta capacidad. Lo que Boris descubrió fue un enorme "voladizo de producto" que Claude podría haber hecho hace tiempo, pero nadie había construido una carcasa para ello.

Boris empezó a trabajar con la herramienta todos los días y luego la compartió con varios colegas. Dos meses después, en noviembre, lanzaron una versión. Los datos están exagerados: el primer día, el 20% de los ingenieros están en servicio; Día 5, 50%.

En este momento, surge un debate interesante: ¿debería lanzarse al exterior? La razón de la oposición es muy real: si esto es realmente tan fuerte como pensamos, ¿no sería bueno mantenerlo como un "arma secreta"? ¿Por qué renunciar a la ventaja competitiva? Al final, Anthropic decidió publicar. La lógica es la siguiente: la misión principal de Anthropic es estudiar la seguridad de los modelos, y la mejor manera de estudiar la seguridad es utilizar realmente estas herramientas. Ahora que Claude Code ha sido validado internamente para su uso intensivo, su publicación proporcionará más información sobre las capacidades y la seguridad del modelo.

En mayo de 2025, Claude Code se hizo públicamente oficialmente. Tres meses después, el consumo se ha multiplicado por diez y los ingresos anualizados superan los 500 millones de dólares. Curiosamente, Boris estaba originalmente pensado para programadores, de ahí el nombre "Claude Code". Pero un día pasó junto a la estación de trabajo del científico de datos y encontró a Claude Code ejecutándose en la otra pantalla. "¿Por qué usas esto?" "Le pedí que me ayudara a escribir consultas y visualizar." Ahora, los científicos de datos de Anthropic tienen uno a mano, y algunos conducen varios a la vez. Un dispositivo de escucha, porque se le dieron algunos permisos más, se convirtió en un producto valorado en cientos de millones de dólares. Probablemente esta sea la mejor prueba de "sobresaliente del producto", la capacidad del modelo siempre está ahí, esperando a que alguien la libere.

[2] El 90% del código está escrito por uno mismo - filosofía de selección técnica de Claude Code Claude Code tiene el 90% de su propio código. Parece un truco, pero en realidad es gracias a su lógica técnica de toma de decisiones. Veamos primero la pila tecnológica: TypeScript escribe el cuerpo principal, React usa el framework Ink como interfaz de terminal, Yoga de código abierto de Meta se encarga del sistema de maquetación, y Bun es responsable de construir y empaquetar. ¿Por qué elegir estas pilas tecnológicas? Porque están "dentro de la distribución". "Sobre distribución" es un término en el campo de la IA. Esto significa que el modelo ha visto mucho de este tipo de código y es bueno manejándolo. TypeScript y React son precisamente donde Claude es fuerte. Si eliges un framework impopular, el modelo tendrá que "aprender" y el efecto se verá comprometido. Esta elección da lugar a un ciclo maravilloso: escribir código Claude con la pila tecnológica en la que Claude es bueno, y luego escribir más código Claude con código Claude. 90% escribe sobre ti mismo, así fue como surgió. Sus elecciones a nivel arquitectónico son igualmente concisas. Claude Code se ejecuta localmente. No hay contenedores Docker, ni sandbox en la nube, solo leer y escribir archivos y ejecutar comandos directamente en tu ordenador.

¿Y por qué está diseñado así? Boris responde: "Cada vez que tomamos una decisión de diseño, casi siempre elegimos la solución más sencilla. Ejecutar localmente es la respuesta más sencilla. ” Esta simplicidad se extiende a toda la filosofía del producto: escribir la menor lógica de negocio posible y dejar que el modelo sea el protagonista. "Puede sonar un poco extraño", dijo Boris, "pero queremos que los usuarios sientan el modelo de la forma más 'auténtica' posible. Muchos productos de IA añaden un montón de andamiajes—elementos adicionales de interfaz, funciones de accesibilidad—y el resultado es que el modelo está limitado. Lo que queremos es que la interfaz sea lo más ágil posible. ” Para simplificar, cada vez que Claude lanza un nuevo modelo, simplifican mucho el código. Por ejemplo, cuando se lanzó Claude 4.0, eliminaron aproximadamente la mitad de las indicaciones del sistema porque el nuevo modelo ya no necesitaba esas "muletas". El número de herramientas también se está simplificando: borra si puedes, fusiona si puedes. Toda la arquitectura de Claude Code se puede resumir en tres cosas: definir la interfaz y exponer la interfaz a la modificación del modelo, exponer las herramientas para que el modelo las llame y luego dejar de lado el flash. Por supuesto, la simplicidad no significa que no haya partes complicadas. El sistema de permisos es la excepción. Al fin y al cabo, hacer que la IA ejecute comandos en tu ordenador es arriesgado. La solución de Claude Code es preguntarte antes de ejecutarlo: ¿Quieres aprobar esta operación? Solo puedes aprobarlo esta vez, aprobarlo más tarde o rechazarlo. El sistema de permisos soporta configuraciones multicapa: por proyecto, por usuario, por empresa. Teams puede compartir perfiles para poner en la lista blanca comandos de seguridad más usados. Los principios detrás de este diseño de permisos son los siguientes: Si inicias Claude Code, no debería cambiar nada sin tu consentimiento. Pero al mismo tiempo, también es necesario dar a los usuarios la opción de "delegar"; en el caso de tu fideicomiso, puedes saltarte el enlace de confirmación. Sencillo, pero no rudimentario. Contención, pero no falta de función.

[3] 20 prototipos en dos días - cómo es la iteración de productos en la era de la IA Antes, cuando hacía prototipos de producto, podía hacer dos en dos días, lo cual se consideraba eficiente. Boris hizo 20 en dos días. Esto no es una exageración, sino un verdadero registro de su desarrollo de la función de lista de tareas de Claude Code. Incluso compartió indicaciones y capturas de pantalla de cada paso. Veamos cómo iteran estos 20 arquetipos. En la primera versión, quería que la lista de tareas apareciera debajo de la llamada de herramientas más reciente. El prompt es breve: "En lugar de que aparezca hacer con la entrada, muestra una lista de tareas fija encima del cuadro de entrada, con el título '/todo (1 de 3)' en gris". Después de ver el efecto, no quedé muy satisfecho. En la segunda versión, se muestra en línea en cada actualización de ToDo. Prompt: "En lugar de mostrar una lista de tareas, renderiza el nombre de la herramienta en negrita cuando el modelo empiece a procesar una tarea." Mantén la pantalla de progreso como 'paso 2 de 4'. ” Sigue sin ser correcto. En la tercera y cuarta edición, intentó crear una "pastilla interactiva": un pequeño cuadrado en la parte inferior de la pantalla en el que puedes hacer clic para ver el progreso. "Añade una pastilla de tareas debajo del cuadro de texto de entrada, similar a una tarea en segundo plano, mostrando 'pendientes: 1 de 3'." Luego: "Haz que esta pastilla sea interactiva, como una pastilla de misión de fondo." ” Es un poco interesante, pero no lo suficientemente bueno. En la quinta y sexta edición, cambió de opinión: hacer un "cajón" que se deslice desde la derecha. "Deshaz las pastillas y títulos anteriores, y en su lugar muestra la lista de tareas en el lado derecho del cuadro de entrada, centrada verticalmente, separada por un divisor gris." "Está un poco nervioso, ¿puedes convertirlo en una animación de cajón?" Tiene buena pinta, pero su practicidad es cuestionable. En las séptima y novena ediciones, movió la lista de tareas por encima del cuadro de entrada y experimentó con diferentes estilos de truncamiento y cabecera. "Si hay más de 5, demuestra '... y 4 más'", "Añadir un título gris de 'Todo:'". La respuesta se está acercando cada vez más. En las ediciones décima y vigésima empezó a averiguar cómo combinar listas de tareas con animaciones de carga. La solución final es colocar la información de progreso junto al spinner (indicador de carga) para maximizar la visibilidad. Tras el lanzamiento, los usuarios informaron querer ver la lista completa de tareas. Así que se añade otra iteración: pulsa Ctrl+T para expandir todos los pasos. Esta es la versión que ahora está disponible.

Durante todo el proceso, los prompts de Boris eran sorprendentemente cortos—en su mayoría una o dos frases. Pero cada versión es un prototipo que realmente se puede ejecutar, no un dibujo estático, ni un PPT. Puede probar y verificar esta función para ver si funciona bien. El proceso tradicional de desarrollo de producto es: idea→ discusión → dibujar wireframes → hacer diseño → desarrollo → pruebas de alta fidelidad → puesta en marcha. Cada paso lleva tiempo, y cada paso puede quedarse atascado. Ahora el flujo es: Idea → prompt de una frase → prototipo ejecutable → Si algo no te parece bien, hazlo de nuevo. Esto requiere que los desarrolladores cambien su mentalidad para adaptarse a este proceso de desarrollo. En el pasado, el papel de los prototipos era "verificar ideas", porque el coste de prototipar era alto y había que pensarlo bien antes de hacerlo. Ahora, los prototipos se han convertido en "explorar posibilidades"; como el coste de fabricar prototipos es bajo, puedes hacerlos primero y luego desecharlos. Boris dijo que al usar Claude Code, a menudo se salta la fase de dibujar el plano y simplemente crea una versión en ejecución, que es más intuitiva que cualquier otra cosa. La cadencia diaria del equipo de Claude Code es la siguiente: cada ingeniero realiza unas 5 PRs al día, 60-100 lanzamientos internos al día y 1 lanzamiento externo al día. 5 marcas personales al día, lo cual es inimaginable en la mayoría de las empresas. Uber está en el periodo de reestructuración más intenso, y no está mal poder lograr una marca media media al día. Cuando cambian las herramientas, cambia el ritmo y la forma de pensar tiene que cambiar.

[4] Rediseñado el terminal de línea de comandos con IA integrada Los terminales de línea de comandos existen desde hace décadas, ¿por qué necesitan ser rediseñados ahora? Porque antes de los LLM, los terminales no se centraban demasiado en experiencias interactivas. La línea de comandos tradicional es una pregunta y respuesta: introduces un comando, te devuelve un resultado y listo. Sin diálogo, sin contexto, sin retroalimentación mientras esperaba. Te quedas mirando el cursor parpadeando y no sabes qué está pasando en segundo plano. Claude Code fue el primer producto que realmente necesitaba pensar en la "experiencia de usuario terminal". Añadieron algunos pequeños detalles que parecían discretos, pero que se sentían completamente diferentes al usarlos. Primero: Prompts contextuales de carga. Cuando el modelo está pensando, la pantalla puede generar indicaciones relevantes basadas en la tarea actual que se ve: por ejemplo, "leer la estructura de tu código" o "pensar en una solución". Es un detalle pequeño, pero le da a la herramienta una "personalidad". Sentirás que está trabajando duro y no atascado. Boris dice que la última vez que vio este tipo de interacción tan agradable fue cuando Slack era un proceso de incorporación para principiantes. Segundo: Consejos para enseñar mientras esperas. Cuando Claude ejecuta una tarea larga, la parte inferior de la pantalla mostrará una rotación de consejos, como "Puedes pulsar Esc para interrumpir la tarea actual" o "Probar /help para ver todos los comandos". La línea de comandos se utiliza para enseñar la línea de comandos, que es sencilla e inteligente. La tercera historia es aún más emocionante: el renderizador Markdown. El día antes del lanzamiento, algunos ingenieros se quejaron de que las listas anidadas eran feas y que el espaciado de los párrafos no era correcto. El problema está con el renderizador Markdown. Boris probó todos los renderizadores del mercado, y ninguno se veía bien en el terminal. Así que pasó un día usando Claude Code para escribir un analizador y renderizador Markdown desde cero. Sí, el día antes del lanzamiento. Sí, escribe desde cero. Sí, usando el propio Claude Code. Como resultado, este renderizador "apresurado" se ve mejor que todas las soluciones ya hechas. Lo publicaron directamente. Boris cree que ningún otro terminal tiene ahora la misma calidad de renderizado Markdown. Esta historia ilustra una cosa: cuando tienes una herramienta de programación de IA lo suficientemente buena, el coste de "construir tus propias ruedas" baja significativamente. El compromiso de "simplemente úsalo" puede convertirse ahora en "entonces haz uno mejor". La antigua forma de interfaz del terminal de línea de comandos está renaciéndose con la incorporación de los LLM. El terminal sigue siendo el mismo, pero debido a la incorporación de la IA, necesitamos pensar seriamente en cómo hacer que la gente tenga una mejor conversación con la IA del terminal.

[5] La IA impregna cada enlace: un experimento de "IA integral" realizado por un equipo de ingeniería El equipo de ingeniería de Anthropic es probablemente uno de los usos más extremos de las herramientas de IA en este momento. No se trata solo de escribir código, se trata de cada aspecto del proyecto. Revisión de código: La primera revisión de todas las PRs la realiza Claude Code, y la segunda la hacen los ingenieros. Boris dice que Claude Code puede encontrar muchos problemas a la primera. Esta función se usaba originalmente solo internamente, pero más tarde la hicieron pública para que todos pudieran usar Claude Code para la revisión de seguridad. Pruebas de escritura: El conjunto de pruebas de Claude Code está escrito casi en su totalidad por Claude Code. "Antes, si alguien mencionaba una imagen personal y no hacía un examen, dudaba en decir algo — parecía un pick and point", dijo Boris. Pero ahora, con Claude, escribir un examen es una palabra de enunciado, y no hay excusa para no escribirlo. ” Respuesta a incidentes: Los ingenieros de Oncall piden a Claude Code que ayude a analizar la causa raíz (la causa raíz del problema). Extrae discusiones relevantes de Slack, registros de errores de Sentry, datos de varios sistemas de monitorización y los analiza sintéticamente. Boris dice que Claude Code encuentra la Causa Raíz más rápido que una persona en algunos escenarios. Triaje de incidencias en GitHub: Cada vez que surge un nuevo problema, Claude Code hace primero un análisis y luego el ingeniero pregunta si se puede implementar. Boris dice que entre un 20% y un 40% de las veces se puede hacer la primera vez. Gráficos y consultas: Los datos de producto residen en BigQuery, y casi todas las consultas y visualizaciones se generan en Claude Code. Los ingenieros incluso permiten que produzca diagramas ASCII directamente.

Lo que más me sorprendió fue el resurgimiento del TDD (desarrollo guiado por pruebas). TDD es un concepto antiguo: primero escribe pruebas y luego el código que pasa las pruebas. En teoría es bueno: te obliga a pensar primero en lo que quieres. Pero en la práctica, la mayoría piensa que es demasiado lento y engorroso, por lo que este método ha ido marginándose poco a poco en los últimos diez años. Pero Boris dijo que después de usar Claude Code, hizo mucho TDD: "Empezaré pidiéndole al modelo que escriba una prueba y le diga que la prueba va a suspender ahora, no intentes que pase. Luego le pedí que escribiera código para implementar la función y que dejara pasar la prueba, pero sin cambiar la prueba en sí. ” "Cuando un modelo tiene un objetivo claro sobre el que iterar —como una prueba unitaria o un simulacrio— funciona muy bien." Mencionó específicamente que Claude 4.0 es la primera serie de modelos que permite a los modelos escribir la mayoría de las pruebas. Las versiones anteriores podían escribir una parte, pero requerían mucha intervención humana. También hay un concepto nuevo: el multi-clauding. Esto significa ejecutar múltiples instancias de Claude Code simultáneamente, permitiéndoles trabajar en diferentes tareas en paralelo. Sid dice que suele hacer esto: poner a algunos agentes en las reuniones y volver más tarde para ver los resultados. Anthropic descubrió que el 25% de los suscriptores de Max (usuarios premium que cuestan entre 100 y 200 dólares al mes) hacen multi-clauding cada día. Este es un cambio interesante. La programación siempre ha sido una actividad "de un solo hilo": solo puedes hacer una cosa a la vez y solo cambiar de tarea cuando el código es revisado o desplegado. Pero ahora, la "programación paralela" es posible: puedes avanzar en varias cosas a la vez. Por supuesto, hay muchas incógnitas aquí: ¿es realmente el trabajo paralelo más eficiente o simplemente se siente más eficiente? ¿Qué tipos de tareas son adecuadas para el paralelismo? ¿Habrá algún problema si cada agente recibe menos atención? Estas preguntas aún no han sido respondidas. Pero tenemos una nueva herramienta con la que experimentar. Por último, hablemos de un caso. Una empresa iba a hacer una migración de framework, y se estimaba que llevaría dos años de ingeniería — dos años para un ingeniero, o dos meses y medio para diez ingenieros. Usaron Claude Code, y un ingeniero lo hizo en dos semanas. Boris dijo que solía ser escéptico con tales afirmaciones, pero que han escuchado historias similares demasiadas veces.

[6] Hackathon de tres días - cómo nació la función Subagentes La inspiración para esta función en Subagents viene de una publicación en Reddit. Algunos dicen que abría cinco instancias de Claude Code al mismo tiempo, asignaba roles diferentes para cada instancia y luego usaba el sistema de archivos para comunicarse entre sí. Cuando Sid Bidasaria vio esta publicación, su primera reacción fue: Esta jugabilidad mola, pero los usuarios no deberían tener que lanzar así. Deberíamos hacerlo una función incorporada del producto. Resultó que la empresa organizó un hackathon interno de tres días, y Sid decidió aprovechar esos tres días para hacerlo. El primer día, el equipo dibujó con entusiasmo una variedad de topologías complejas de agentes: comunicación entre agentes en el bus de mensajes, modo asincrónico, interacciones de muchos a muchos...... La imagen está bellamente dibujada y el concepto está avanzado. Al día siguiente, se dieron cuenta de que no parecía factible hacerlo. El problema no es la implementación técnica: se pueden crear patrones complejos. El problema es que los usuarios no pueden entenderlo. La interfaz de Claude Code es un terminal sencillo, ¿cómo haces que los usuarios comprendan esos modos complejos de comunicación de agentes en una interfaz tan sencilla? Decidieron empezar de nuevo y volver a la pregunta fundamental: ¿Cuál es la forma más sencilla que puede usar el desarrollador medio? Se impusieron dos restricciones: Primero, no inventes nada nuevo. Usa solo las capacidades que Claude Code ya tiene: los archivos de comandos "/" y .md. Segundo, no te comuniques entre agentes. Cambiar a un patrón de orquestación simple: hay un agente maestro que puede llamar al agente hijo, y el agente hijo devuelve el resultado tras completar la tarea, y eso es todo. También charlaron con el equipo de investigación de Anthropic. Los investigadores están trabajando en patrones multiagente, pero la conclusión es que aún no es concluyente si las topologías complejas de agentes realmente funcionan. Esto les da más confianza: dado que incluso el equipo de investigación dice que la complejidad no es necesariamente buena, es mejor hacer una versión sencilla. Al final del tercer día, hicieron una versión funcional. Los usuarios pueden definir los roles y capacidades de los subagentes en archivos .md (por ejemplo, "agentes front-end: usando React 19 y Next.js"), Claude Code los llamará cuando sea apropiado, o el usuario puede activarlos manualmente. Después del hackathon, tras un poco de pulido, la sección está en activo. Ahora puedes definir varios subagentes exclusivos: agentes de back-end con experiencia en auditoría de seguridad, agentes de front-end familiarizados con frameworks específicos y agentes de QA especializados en escribir pruebas...... Pueden trabajar en paralelo en segundo plano, cada uno desempeñando su propio papel. Muchos equipos serán reacios a revertir sus complejos planes en el hackathon, después de todo, pasan todo un día dibujando y discutiendo, y tienen sentimientos. Ser capaz de admitir que "este camino no funciona" y derrocarlo y empezar de cero requiere valor y fe en la "simplicidad". La simplicidad no es pereza. Lo sencillo es encontrar el formulario que el usuario realmente pueda usar entre las innumerables opciones.

[7] ¿Cómo será el equipo de ingeniería en el futuro? Algunas pueden usarse como referencia y otras no pueden copiarse Boris dijo: "Ahora programar es muy divertido. La última vez que me sentí así fue cuando escribí código en una calculadora gráfica por primera vez en el instituto. Esa sensación mágica que no había experimentado en mucho tiempo, pero que ahora ha vuelto. ” Sid siente algo similar: "Hay dos cosas que me emocionan. Una es la velocidad a la que lanzamos – a veces parece demasiado rápida. La segunda es mucho espacio experimental: aunque el trabajo anterior fue rápido, lo que hice fue más rutinario y, sabiendo cuál era la respuesta, simplemente fue ejecución. Ahora es diferente, el modelo cambia cada tres meses y tenemos que replantearnos constantemente cómo hacemos las cosas. ” Estos sentimientos son muy reales y contagiosos. Pero antes de hablar de "cómo será el futuro de los equipos de ingeniería", no olvidemos la especificidad de Anthropic. Primero, Anthropic es un laboratorio de investigación, no una empresa de productos. Su misión principal es investigar la seguridad y las capacidades de la IA, y el producto es el medio, no el fin. Esto significa que tienen una tolerancia mucho mayor a la "experimentación rápida" que la media de las empresas. Segundo, su producto principal es el propio modelo de Claude. Claude Code es solo una "cáscara" del modelo. Así que "eliminar código para que el modelo haga más" es una elección natural para ellos, pero para otras empresas puede significar dar la lógica central de negocio a una caja negra. Tercero, todos los empleados tienen acceso ilimitado a Claude, incluido el modelo Opus más caro. En la mayoría de las empresas, las cuotas de suscripción a la IA son un concepto presupuestario por el que hay que luchar y que no puede ser utilizado por todo el mundo. Cuarto, el equipo solo cuenta con una docena de personas y el proceso es mínimo. Casi no usan feature flags porque son "demasiado lentos". Esto es impensable en un producto con una gran base de usuarios y alto coste de error. Así que, copiar directamente al equipo de Claude Code no es necesariamente realista para la mayoría de los equipos. Pero hay cosas de las que aprender. Mentalidad de prototipado rápido: Aunque no puedas hacer 10 prototipos al día, ¿puedes cambiar de "uno cada dos semanas" a "tres a la semana"? Las herramientas han cambiado y las expectativas sobre "qué velocidad debe tener el prototipo" deberían actualizarse. Revisión de código asistida por IA: Deja que la IA haga la primera revisión y el humano la segunda. Este proceso no depende de acceso ilimitado a la API, que la mayoría de los equipos pueden intentar. La recuperación del TDD: Si escribir exámenes se vuelve lo suficientemente fácil, "no tener tiempo para hacerlo" deja de ser una excusa. Esto puede ser un punto de entrada de bajo coste para mejorar la calidad del código. El valor de los ingenieros orientados al producto se amplifica: el equipo de Claude Code no tiene diseñadores ni PMs, solo unos pocos ingenieros enfocados en el producto. Las herramientas de IA han ampliado enormemente lo que este "talento full-stack" puede hacer.

Por supuesto, hay cosas que no pueden ser reemplazadas por herramientas. Boris pudo elegir el mejor de entre 20 arquetipos porque era crítico—sabía qué "se sentía bien" y qué simplemente "quedaba bien". Este sabor es el resultado de 17 años de experiencia en desarrollo de software, no es algo que la IA pueda ofrecer. El equipo hizo un plan complejo el primer día, y al día siguiente podrían revertir sin piedad y empezar de nuevo, lo cual también es un juicio humano. Saber cuándo eliminar código y cuándo conservarlo es lo mismo para esta intuición arquitectónica. La IA acelera la ejecución, pero no facilita "saber qué hacer". En cambio, debido a que el coste de ejecución ha disminuido, la decisión de "qué hacer" se ha vuelto más importante: puedes hacer 20 versiones rápidamente, pero tienes que saber cuál es la correcta. ¿Cómo será la ingeniería de software dentro de unos años? Nadie puede predecir con precisión. Pero el equipo Claude Code de hoy puede ser una especie de ensayo para mañana para muchos equipos: iteraciones más rápidas, menos "movimiento de ladrillos", más juicio y toma de decisiones. Las herramientas están cambiando. Lo que sigue sin cambios es que siguen siendo las personas quienes toman la decisión final.