Vamos a organizar la historia del nacimiento de Claude Code, que proviene principalmente de un artículo del blogger tecnológico Gergely Orosz, quien entrevistó a miembros clave de Claude Code. Claude Code es realmente impresionante, con ingresos anuales de 500 millones de dólares, y en tres meses la cantidad de usuarios ha aumentado 10 veces; ahora es la herramienta de Coding Agent preferida por muchos programadores. Esta herramienta era inicialmente solo un pequeño juguete de línea de comandos que podía decirte "qué canción estás escuchando ahora". 🧵

Gergely Orosz entrevistó a tres miembros clave de Claude Code: • El ingeniero fundador Boris Cherny (17 años de experiencia, ex ingeniero principal de Meta) • El ingeniero número dos Sid Bidasaria (autor de la función Subagents) • Y la gerente de producto Cat Wu. Hablaron sobre cómo Claude Code pasó de ser un prototipo a un producto, qué decisiones técnicas tomaron y cómo este pequeño equipo de unas pocas personas logra publicar 5 PR al día por persona. Este podría ser el ejemplo más cercano a un "equipo de ingeniería priorizando la IA" en la actualidad. Usan IA para escribir código, escribir pruebas, hacer revisiones de código, depurar errores, e incluso utilizan Claude Code para desarrollar Claude Code en sí. El 90% del código lo escribe él mismo. Lo que quiero hacer es recopilar las partes más interesantes de esta entrevista, hablar sobre cómo trabaja este equipo, qué se puede aprender de ellos y qué aspectos son condiciones especiales que no se pueden replicar. A continuación, se divide en 7 pequeñas historias, cada una de las cuales se puede ver de forma independiente, pero juntas forman un panorama completo.

【1】Una pequeña herramienta para escuchar música, ¿cómo se convirtió en un producto que genera 500 millones de dólares al año? En septiembre de 2024, Boris Cherny acaba de unirse a Anthropic y, sin nada que hacer, escribió un pequeño juguete de línea de comandos. ¿Y qué puede hacer esto? Puede decirte qué canción estás escuchando ahora usando AppleScript, y también puede cambiar de canción según tus instrucciones. Así de simple. La propia evaluación de Boris es: “Es un demo bastante genial, pero no tiene mucho sentido.”

El verdadero giro ocurrió después de que él hablara con su colega Cat Wu. Cat estaba investigando la capacidad de uso de computadoras de los Agentes de IA, y mientras conversaban, Boris tuvo una idea: ¿qué pasaría si le diera más permisos a esta herramienta de línea de comandos? Por ejemplo, permitirle leer y escribir archivos, y ejecutar comandos?

Él lo intentó. Luego, llegó el momento de presenciar el milagro. Boris lanzó esta herramienta mejorada en el repositorio de código de Anthropic y preguntó algunas cosas al azar. Claude comenzó a explorar el sistema de archivos por sí mismo: leyó un archivo, vio las declaraciones de importación dentro y siguió leyendo los archivos referenciados, excavando capa por capa hasta encontrar la respuesta. "Esto me dejó atónito," recordó Boris, "nunca había usado una herramienta así."

En el campo de la IA hay un concepto llamado "product overhang", que se traduce como "exceso de producto". Significa que el modelo ya tiene cierta capacidad, pero la forma actual del producto no ha liberado esa capacidad. Lo que Boris descubrió es un enorme "exceso de producto"; Claude ya podía hacer estas cosas, solo que nadie le había construido un contenedor.

Boris comenzó a trabajar todos los días con esta herramienta y luego la compartió con algunos colegas. Dos meses después, en noviembre, lanzaron una versión interna. Los datos son impresionantes: el primer día, el 20% de los ingenieros la estaban usando; el quinto día, el 50%.

En este momento surgió un debate interesante: ¿deberíamos publicar esto al público? Las razones en contra son muy reales: si esto realmente es tan poderoso como pensamos, ¿no sería mejor guardarlo como un "arma secreta"? ¿Por qué deberíamos entregar nuestra ventaja competitiva? Al final, Anthropic decidió publicar. La lógica es la siguiente: la misión central de Anthropic es investigar la seguridad de los modelos, y la mejor manera de investigar la seguridad es permitir que las personas usen realmente estas herramientas. Dado que ya se ha verificado internamente que Claude Code será ampliamente utilizado, publicarlo puede proporcionar más información sobre las capacidades y la seguridad del modelo.

En mayo de 2025, Claude Code se hizo público oficialmente. Tres meses después, el uso aumentó 10 veces, con ingresos anuales que superaron los 500 millones de dólares. Lo curioso es que Boris inicialmente solo pensaba en que lo usaran los programadores, por eso se llama "Claude Code". Pero un día, al pasar por el escritorio de un científico de datos, vio que en la pantalla también estaba corriendo Claude Code. "¿Para qué lo usas?" "Me ayuda a escribir consultas y a hacer visualizaciones." Ahora, los científicos de datos de Anthropic tienen uno cada uno, y algunos tienen varios abiertos al mismo tiempo. Una pequeña herramienta para escuchar música, que al darle algunos permisos adicionales, se convirtió en un producto valorado en cientos de millones de dólares. Esto es probablemente la mejor prueba del "product overhang"; la capacidad del modelo siempre ha estado ahí, solo estaba esperando a que alguien la liberara.

【2】El 90% del código está escrito por sí mismo: la filosofía de selección tecnológica de Claude Code Claude Code tiene el 90% de su código escrito por él mismo. Suena a una exageración, pero esto se debe a su lógica de toma de decisiones tecnológicas. Primero, veamos la pila tecnológica: TypeScript para el núcleo, React junto con el marco Ink para la interfaz de usuario en terminal, Yoga de Meta como sistema de diseño, y Bun para la construcción y empaquetado. ¿Por qué elegir estas tecnologías? Porque están "dentro de la distribución". "Dentro de la distribución" (on distribution) es un término del campo de la IA. Significa que el modelo ya ha visto una gran cantidad de este tipo de código y es bueno manejándolo. TypeScript y React son precisamente las fortalezas de Claude. Si se elige un marco poco común, el modelo tendría que "aprender", lo que reduciría la efectividad. Esta elección genera un ciclo maravilloso: escribir Claude Code con la pila tecnológica en la que Claude es experto, y luego usar Claude Code para escribir más Claude Code. El 90% de lo que se escribe es así. Sus elecciones a nivel de arquitectura también son igualmente simples. Claude Code se ejecuta localmente. No hay contenedores Docker, no hay sandbox en la nube, simplemente lee y escribe archivos y ejecuta comandos directamente en tu computadora.

¿Por qué se diseñó así? La respuesta de Boris es: "Cada vez que tomamos decisiones de diseño, casi siempre elegimos la opción más simple. Ejecutar localmente es la respuesta más sencilla." Esta simplicidad se extiende a toda la filosofía del producto: escribir la menor cantidad posible de lógica de negocio y dejar que el modelo sea el protagonista. "Esto puede sonar un poco extraño," dice Boris, "pero queremos que los usuarios puedan experimentar el modelo de la manera más "auténtica" posible. Muchos productos de IA añaden un montón de andamiaje: elementos de UI adicionales, varias funciones auxiliares, y el resultado limita la capacidad del modelo. Lo que queremos hacer es que la UI sea lo más minimalista posible." Para mantener la simplicidad, cada vez que Claude lanza un nuevo modelo, simplifican enormemente el código. Por ejemplo, cuando se lanzó Claude 4.0, eliminaron aproximadamente la mitad de las palabras clave del sistema, ya que el nuevo modelo ya no necesitaba esos "bastones". La cantidad de herramientas también se está simplificando constantemente: lo que se puede eliminar, se elimina; lo que se puede combinar, se combina. Toda la arquitectura de Claude Code se puede resumir en tres cosas: definir la UI y exponer la interfaz para que el modelo la modifique, exponer herramientas para que el modelo las llame, y luego apartarse. Por supuesto, la simplicidad no significa que no haya partes complejas. El sistema de permisos es la excepción. Después de todo, permitir que la IA ejecute comandos en tu computadora conlleva riesgos. La solución de Claude Code es preguntar antes de ejecutar: ¿quieres aprobar esta acción? Puedes aprobar solo esta vez, o aprobar en el futuro, o rechazar. El sistema de permisos admite configuraciones de múltiples niveles: por proyecto, por usuario, por empresa. Los equipos pueden compartir archivos de configuración y agregar comandos de seguridad comunes a la lista blanca. El principio detrás de este diseño de permisos es el siguiente: si inicias Claude Code, no debería cambiar nada sin tu consentimiento. Pero al mismo tiempo, también debe dar a los usuarios la opción de "delegar": en situaciones de confianza, puedes omitir la etapa de confirmación. Sencillo, pero no rudimentario. Moderado, pero no carente de funciones.

【3】Veinte prototipos en dos días: ¿cómo es la iteración de productos en la era de la IA? Antes, hacer prototipos de productos en dos días y conseguir dos era considerado un gran logro. Boris hizo 20 en dos días. No es una exageración, es un registro real de cuando desarrolló la función de lista de tareas de Claude Code. Incluso compartió las indicaciones y capturas de pantalla de cada paso. Veamos cómo se iteraron estos 20 prototipos. En la primera versión, quería que la lista de tareas se mostrara debajo de la última llamada a la herramienta. La indicación era muy corta: “Haz que la lista de tareas no aparezca con la entrada, sino que muestre una lista de tareas fija sobre el cuadro de entrada, con el título en gris '/todo (1 de 3)'”. Al ver el resultado, no estaba muy satisfecho. En la segunda versión, cambió a mostrar en línea cada vez que se actualizaba una tarea. La indicación: “En realidad, no muestres la lista de tareas, cambia a renderizar el nombre de la herramienta en negrita como título cuando el modelo comience a procesar una tarea. Mantén la visualización del progreso como 'paso 2 de 4'.” Todavía no era correcto. En la tercera y cuarta versión, intentó hacer una “píldora interactiva”: un pequeño cuadrado en la parte inferior de la pantalla que al hacer clic muestra el progreso. “Agrega una píldora de tareas debajo del cuadro de entrada, similar al estilo de tareas en segundo plano, mostrando 'todos: 1 de 3'.” Luego: “Haz que esta píldora sea interactiva, como la píldora de tareas en segundo plano.” Ya era un poco interesante, pero aún no era lo suficientemente bueno. En la quinta y sexta versión, cambió de enfoque: hizo un “cajón” que se desliza desde la derecha. “Retira la píldora anterior y el título, y muestra la lista de tareas a la derecha del cuadro de entrada, centrada verticalmente, separada por una línea gris.” “Es un poco abrupto, ¿puedes hacerlo con una animación de cajón?” Se veía genial, pero su utilidad era dudosa. De la séptima a la novena versión, volvió a mover la lista de tareas sobre el cuadro de entrada, probando diferentes formas de truncar y estilos de título. “Si hay más de 5, muestra '... y 4 más'”, “Agrega un título gris 'Todo:'”. Se estaba acercando cada vez más a la respuesta. De la décima a la vigésima versión, comenzó a pensar en cómo combinar la lista de tareas con la animación de carga. La solución final fue colocar la información de progreso al lado del spinner (indicador de carga), maximizando la visibilidad. Después del lanzamiento, los usuarios comentaron que querían ver la lista completa de tareas. Así que se agregó otra iteración: al presionar Ctrl+T se pueden expandir todos los pasos. Esta es la versión que está en línea ahora.

Durante todo el proceso, las indicaciones de Boris son sorprendentemente breves: la mayoría son solo una o dos frases. Pero cada versión es un prototipo funcional, no una imagen estática, no un PPT. Él puede probar realmente esta función y sentir si es fluida o no. El proceso tradicional de desarrollo de productos es: idea → discusión → diseño de wireframes → diseño de alta fidelidad → desarrollo → pruebas → lanzamiento. Cada paso lleva tiempo y cada paso puede atascarse. Ahora el proceso se ha convertido en: idea → indicación de una frase → prototipo funcional → si no se siente bien, se hace otra versión. Esto realmente requiere que los desarrolladores cambien su forma de pensar para adaptarse a este proceso de desarrollo. Antes, el propósito del prototipo era "validar la idea" — porque hacer un prototipo es costoso, debes pensar bien antes de empezar. Ahora, el prototipo se ha convertido en "explorar posibilidades" — porque hacer un prototipo es barato, puedes hacerlo primero y luego decidir, si no funciona, lo descartas. Boris dice que, al usar Claude Code, a menudo salta directamente la fase de diseño y hace una versión que funcione, es más intuitivo que cualquier otra cosa. El ritmo diario del equipo de Claude Code es: cada ingeniero empuja alrededor de 5 PR al día, publican internamente de 60 a 100 versiones al día y externamente publican 1 versión al día. Cinco PR al día es algo inimaginable en la mayoría de las empresas. Uber, en su período de reestructuración más intenso, consideraba que empujar un PR de tamaño mediano al día era un buen resultado. Las herramientas han cambiado, el ritmo ha cambiado, y la forma de pensar también debe cambiar.

【4】Rediseño de la terminal de línea de comandos integrada con AI La terminal de línea de comandos ha existido durante décadas, ¿por qué es necesario rediseñarla ahora? Porque antes de la llegada de los LLM, la terminal no prestaba mucha atención a la experiencia de interacción. La línea de comandos tradicional es un intercambio de preguntas y respuestas: tú ingresas un comando, y devuelve un resultado, y eso es todo. No hay diálogo, no hay contexto, no hay retroalimentación mientras esperas. Miras el cursor parpadeando, sin saber qué está haciendo el sistema en segundo plano. Claude Code es uno de los primeros productos que realmente necesita pensar en la "UX de la terminal". Han añadido algunos pequeños detalles que parecen insignificantes, pero la experiencia de uso es completamente diferente. Primero: indicaciones de carga de contexto. Cuando el modelo está pensando, la pantalla puede mostrar indicaciones relacionadas con la tarea actual: por ejemplo, "leyendo tu estructura de código" o "pensando en una solución". Es un pequeño toque, pero le da "personalidad" a la herramienta. Sientes que está trabajando seriamente, en lugar de estar atascada. Boris dijo que la última vez que vio una interacción tan agradable fue en el proceso de guía para principiantes de Slack. Segundo: indicaciones educativas mientras esperas. Cuando Claude está ejecutando una tarea larga, la parte inferior de la pantalla muestra de forma alterna consejos de uso, como "puedes presionar Esc para interrumpir la tarea actual" o "prueba /help para ver todos los comandos". La línea de comandos se utiliza para enseñar la línea de comandos, simple y inteligente. La tercera historia es aún más interesante: el renderizador de Markdown. Un día antes del lanzamiento, un ingeniero se quejó de que las listas anidadas se veían muy mal y el espaciado entre párrafos también era incorrecto. El problema estaba en el renderizador de Markdown. Boris probó todos los renderizadores disponibles en el mercado, y ninguno se veía bien en la terminal. Así que pasó un día usando Claude Code para escribir desde cero un analizador y renderizador de Markdown. Sí, un día antes del lanzamiento. Sí, lo escribió desde cero. Sí, usó Claude Code. El resultado es que este renderizador "de última hora" se ve mejor que todas las soluciones disponibles. Lo lanzaron directamente. Boris cree que actualmente no hay ninguna otra terminal que tenga un renderizado de Markdown de la misma calidad. Esta historia demuestra una cosa: cuando tienes una herramienta de programación AI lo suficientemente buena, el costo de "hacer tu propia rueda" disminuye drásticamente. La antigua concesión de "mientras funcione está bien" ahora puede convertirse en "entonces hagamos algo mejor". La antigua interfaz de la terminal de línea de comandos está renaciendo gracias a la incorporación de los LLM. La terminal sigue siendo la misma terminal, solo que ahora, con la llegada de la AI, necesitamos pensar seriamente: ¿cómo podemos hacer que las personas dialoguen mejor con la AI en la terminal?

【5】AI se infiltra en cada etapa: un experimento de "total AI" de un equipo de ingeniería El equipo de ingeniería de Anthropic es posiblemente uno de los equipos que utiliza herramientas de AI de manera más extrema en la actualidad. No solo se refleja en la escritura de código, sino en todas las etapas del proyecto. Revisión de código: la primera revisión de todos los PR la realiza Claude Code, y el ingeniero hace la segunda. Boris dice que Claude Code puede detectar muchos problemas en la primera revisión. Esta función originalmente solo se usaba internamente, pero luego la hicieron pública, y ahora todos pueden usar Claude Code para revisiones de seguridad. Escritura de pruebas: casi todas las pruebas del conjunto de pruebas de Claude Code fueron escritas por Claude Code. Boris dice: "Antes, si alguien presentaba un PR sin escribir pruebas, dudaba en decir algo; sentía que era como ser quisquilloso. Pero ahora, con Claude, escribir pruebas es solo cuestión de una frase de indicación, no hay excusa para no hacerlo." Respuesta a incidentes: el ingeniero de guardia permite que Claude Code ayude a analizar la Causa Raíz (la razón más fundamental del problema). Puede extraer discusiones relevantes de Slack, registros de errores de Sentry y datos de varios sistemas de monitoreo, y luego realizar un análisis integral. Boris dice que Claude Code puede encontrar la Causa Raíz más rápido que las personas en ciertos escenarios. Desvío de problemas de GitHub: cada vez que llega un nuevo problema, Claude Code realiza un análisis primero, y luego el ingeniero le pregunta "¿puedes implementarlo?". Boris dice que en aproximadamente el 20%-40% de los casos, puede resolverlo en el primer intento. Gráficos y consultas: los datos del producto están en BigQuery, y casi todas las consultas y visualizaciones son generadas por Claude Code. Los ingenieros incluso le piden que genere gráficos ASCII directamente.

Lo que más me sorprendió fue el renacimiento de TDD (Desarrollo Guiado por Pruebas). TDD es un concepto antiguo: primero escribes pruebas, luego escribes el código que hace que las pruebas pasen. En teoría es muy bonito: te obliga a pensar primero en lo que quieres. Pero en la práctica, la mayoría de la gente lo encuentra demasiado lento y complicado, por lo que este método se ha ido marginando en los últimos diez años. Pero Boris dice que, después de usar Claude Code, ha hecho una gran cantidad de TDD: "Primero haré que el modelo escriba una prueba, al mismo tiempo que le digo que esta prueba fallará ahora, no intentes hacer que pase. Luego le pido que escriba el código para implementar la funcionalidad y hacer que la prueba pase, pero no puede cambiar la prueba en sí." "Cuando el modelo tiene un objetivo claro para iterar, como una prueba unitaria o un mock, se comporta muy bien." Él menciona especialmente que Claude 4.0 es la primera serie de modelos que puede hacer que el modelo escriba la mayoría de las pruebas. Las versiones anteriores podían escribir una parte, pero requerían mucha intervención manual. Hay un nuevo concepto: multi-clauding. Significa ejecutar múltiples instancias de Claude Code al mismo tiempo, permitiendo que manejen diferentes tareas en paralelo. Sid dice que a menudo hace esto: inicia varios agentes durante las reuniones y luego revisa los resultados después. Anthropic ha descubierto que el 25% de los usuarios suscritos a Max (usuarios premium que pagan entre 100 y 200 dólares al mes) están utilizando multi-clauding todos los días. Este es un cambio muy interesante. La programación siempre ha sido una actividad "de un solo hilo": solo puedes hacer una cosa a la vez, solo cambias de tarea cuando esperas la revisión del código o el despliegue. Pero ahora, la "programación paralela" se ha vuelto posible: puedes avanzar en varias cosas al mismo tiempo. Por supuesto, hay muchas incógnitas: ¿es realmente más eficiente trabajar en paralelo o solo parece más eficiente? ¿Qué tipo de tareas son adecuadas para el trabajo en paralelo? ¿Habrá problemas si cada agente recibe menos atención? Estas preguntas aún no tienen respuesta. Pero ahora tenemos una nueva herramienta para experimentar. Finalmente, un caso. Una empresa necesitaba hacer una migración de marco, originalmente estimaron que necesitarían dos años de ingeniería: un ingeniero durante dos años, o diez ingenieros durante dos meses y medio. Usaron Claude Code y un ingeniero lo resolvió en dos semanas. Boris dice que solía ser escéptico ante este tipo de afirmaciones, pero han escuchado historias similares demasiadas veces.

【6】Hackathon de tres días: ¿cómo nació la función Subagents? La inspiración para la función Subagents provino de una publicación en Reddit. Alguien mencionó que había abierto cinco instancias de Claude Code al mismo tiempo, asignando diferentes roles a cada instancia y utilizando un sistema de archivos para que se comunicaran entre sí. Cuando Sid Bidasaria vio esta publicación, su primera reacción fue: este enfoque es genial, pero los usuarios no deberían tener que complicarse tanto. Deberíamos convertirlo en una función integrada en el producto. Justo en ese momento, la empresa tenía un hackathon interno de tres días, y Sid decidió dedicar esos tres días a este proyecto. El primer día, el equipo emocionado dibujó diversas y complejas estructuras topológicas de Agentes: comunicación entre Agentes a través de un bus de mensajes, modos asíncronos, interacciones de muchos a muchos... Los dibujos eran muy bonitos y el concepto muy avanzado. El segundo día, se dieron cuenta de que esto parecía inviable. El problema no era la implementación técnica: esos modos complejos se podían realizar. El problema era que los usuarios no podían entenderlo. La interfaz de usuario de Claude Code es simplemente un terminal, ¿cómo puedes hacer que los usuarios comprendan esos complejos modos de comunicación entre Agentes en una interfaz tan simple? Decidieron empezar de nuevo, volviendo a una pregunta fundamental: ¿cuál es la forma más simple que puede usar un desarrollador común? Se impusieron dos restricciones: Primero, no inventar nada nuevo. Solo usar las capacidades existentes de Claude Code: comandos “/” y archivos .md. Segundo, no hacer comunicación entre Agentes. Cambiar a un modo de orquestación simple: hay un Agente principal que puede invocar Agentes secundarios, y los Agentes secundarios devuelven resultados una vez que completan sus tareas, y eso es todo. También hablaron con el equipo de investigación de Anthropic. Los investigadores estaban estudiando el modo de múltiples Agentes, pero la conclusión era: no hay consenso sobre si las topologías complejas de Agentes son realmente efectivas. Esto les dio más confianza: dado que incluso el equipo de investigación dice que lo complejo no siempre es mejor, entonces deberían hacer una versión simple. Al final del tercer día, habían creado una versión funcional. Los usuarios pueden definir los roles y capacidades de los Agentes secundarios en un archivo .md (por ejemplo, "Agente secundario frontend: usar React 19 y Next.js"), y Claude Code los invocará en el momento adecuado, o los usuarios pueden activarlos manualmente. Después del hackathon, hicieron algunos ajustes y la función se lanzó. Ahora puedes definir varios Agentes secundarios personalizados: un Agente backend especializado en auditoría de seguridad, un Agente frontend familiarizado con marcos específicos, un Agente de QA especializado en escribir pruebas... pueden trabajar en paralelo en segundo plano, cada uno cumpliendo su función. Muchos equipos en el hackathon se resisten a deshacer sus complejos planes, después de todo, pasaron todo un día dibujando y discutiendo, se encariñaron con ellos. Reconocer que "este camino no funciona" y empezar de nuevo requiere valentía, así como una creencia en lo "simple". La simplicidad no es pereza. La simplicidad es encontrar la forma que realmente puede usar el usuario entre innumerables posibilidades.

【7】¿Cómo serán los equipos de ingeniería del futuro? Algunas cosas que se pueden tomar como referencia y otras que no se pueden replicar. Boris dice: “Programar ahora es muy interesante. La última vez que sentí esto fue en la escuela secundaria, cuando escribí código por primera vez en una calculadora gráfica. Esa sensación mágica, no la había experimentado en mucho tiempo, pero ahora ha vuelto.” Sid tiene sentimientos similares: “Hay dos cosas que me emocionan. Una es la velocidad a la que publicamos: a veces incluso parece demasiado rápido. La otra es el gran espacio para experimentar: en trabajos anteriores, aunque también era rápido, lo que hacíamos era más rutinario, sabíamos cuál era la respuesta, solo había que ejecutarla. Ahora es diferente, el modelo cambia cada tres meses, tenemos que repensar constantemente cómo hacer las cosas.” Estos sentimientos son muy reales y contagiosos. Pero antes de discutir “cómo serán los equipos de ingeniería del futuro”, no debemos olvidar la singularidad de Anthropic. Primero, Anthropic es un laboratorio de investigación, no una empresa de productos. Su misión central es investigar la seguridad y capacidad de la IA, el producto es un medio, no un fin. Esto significa que su tolerancia a los “experimentos rápidos” es mucho mayor que la de una empresa típica. En segundo lugar, su producto principal es el modelo Claude en sí. Claude Code es solo una “cáscara” del modelo. Por lo tanto, “eliminar código para que el modelo haga más cosas” es una elección natural para ellos, pero para otras empresas podría significar entregar la lógica central del negocio a una caja negra. En tercer lugar, todos los empleados tienen acceso ilimitado a Claude, incluido el modelo Opus, que es el más caro. En la mayoría de las empresas, la tarifa de suscripción a la IA es un proyecto presupuestario que hay que negociar, no es posible que todos tengan acceso sin restricciones. En cuarto lugar, el equipo tiene solo unas pocas personas y el proceso es extremadamente simple. Casi no utilizan feature flags (interruptores de funciones), porque “es demasiado lento”. Esto es inimaginable en productos con una gran base de usuarios y altos costos de error. Por lo tanto, copiar directamente las prácticas del equipo de Claude Code no es necesariamente realista para la mayoría de los equipos. Pero hay algunas cosas que se pueden tomar como referencia. La mentalidad de prototipado rápido: aunque no puedas hacer 10 prototipos al día, ¿puedes pasar de “uno cada dos semanas” a “tres a la semana”? Las herramientas han cambiado, y las expectativas sobre “qué tan rápido deben ser los prototipos” también deberían actualizarse. Revisión de código asistida por IA: deja que la IA haga la primera revisión, y que una persona haga la segunda. Este proceso no depende de un acceso ilimitado a la API, la mayoría de los equipos pueden intentarlo. El renacimiento del TDD: si escribir pruebas se vuelve lo suficientemente fácil, entonces “no hay tiempo para escribir pruebas” ya no será una excusa. Este podría ser un punto de entrada de bajo costo para mejorar la calidad del código. La amplificación del valor de un ingeniero con mentalidad de producto: el equipo de Claude Code no tiene diseñadores ni PM, solo se basa en unos pocos ingenieros con mentalidad de producto. Las herramientas de IA han ampliado enormemente lo que este tipo de “talento de pila completa” puede hacer.

Por supuesto, hay algunas cosas que las herramientas no pueden reemplazar. Boris puede elegir el mejor de los 20 prototipos porque tiene juicio: sabe qué "se siente bien" y qué solo "parece útil". Este gusto es el resultado de 17 años de experiencia en desarrollo de software, no algo que pueda proporcionar la IA. El primer día, el equipo hizo un plan complejo, y al segundo día pudo tomar la dura decisión de empezar de nuevo; esta capacidad de decisión también es un juicio humano. Saber cuándo eliminar código y cuándo mantenerlo, esa intuición arquitectónica es igualmente importante. La IA ha acelerado la ejecución, pero no ha simplificado el "saber qué hacer". Por el contrario, debido a que el costo de ejecución ha disminuido, la decisión de "qué hacer" se ha vuelto más importante: puedes crear rápidamente 20 versiones, pero debes saber cuál es la correcta. ¿Cómo será la ingeniería de software en unos años? Nadie puede predecirlo con precisión. Pero el hoy del equipo de Claude Code podría ser un tipo de preámbulo para muchos equipos mañana: iteraciones más rápidas, menos "mover ladrillos", más juicio y decisiones. Las herramientas están cambiando. Lo que no cambia es que, al final, la decisión la toma la gente.