Lo que finalmente queremos enseñar al modelo es lo mismo que le enseñamos a los niños.

Autor del artículo, fuente: Machine Learning China

Muchas personas dicen que, en la era de la IA, el gusto es el último foso defensivo de la humanidad. Pero Boris Cherny no piensa así.

Es miembro técnico de Anthropic y uno de los constructores principales de Claude Code. Usa modelos todos los días para escribir código y también para investigar modelos. La tendencia que ha observado es que lo que se denomina "gusto" también se está aprendiendo rápidamente por los modelos.

Si incluso "qué hacer" puede ser dominado por un modelo, ¿qué les queda a los humanos?

En una entrevista reciente, Boris habló sobre este tema.

Cómo Claude Code cambia fundamentalmente los sistemas de las empresas;

Cuando los modelos pueden escribir la mayoría del código, ¿aún vale la pena contratar ingenieros? Si es así, ¿qué se debe considerar?

¿Por qué muchas personas dentro de Anthropic son Member of Technical Staff, sin niveles ni divisiones de responsabilidades claros?

Un consejo contraintuitivo para todos los emprendedores: ¿por qué «contrata menos personas y da más tokens»?

……

Estas preguntas parecen tratar sobre el nacimiento y la iteración de un producto, pero cada respuesta apunta hacia el mismo cambio más fundamental: la forma en que opera la organización está siendo redefinida por el modelo mismo.

La respuesta de Boris merece una reflexión serena.

¿Cómo nació Claude Code?

Cuando el presentador preguntó sobre el origen de Boris Claude Code, su respuesta fue algo inesperada.

En su relato, Claude Code no era un producto principal planeado desde el inicio por Anthropic, sino que, en cierto sentido, puede considerarse un producto inesperado.

A finales de 2024, Boris se unió al equipo de Labs de Anthropic. La responsabilidad de este equipo no es mantener productos existentes, sino explorar formas futuras de productos. Por un lado, deben seguir empujando los límites de las capacidades del modelo; por otro, también buscan nuevos productos que puedan liberar verdaderamente estas capacidades.

En ese momento, el equipo tenía una sensación muy fuerte: el modelo ya poseía capacidades mucho más allá de los productos existentes, pero aún no había en el mercado ningún producto que pudiera aprovechar plenamente estas capacidades. Esto era especialmente cierto en el ámbito de la programación.

En ese momento, las herramientas de programación con IA en el mercado aún se limitaban a dos direcciones. Una era la completación automática, que ayudaba a los desarrolladores a completar la siguiente línea de código; la otra era la asistencia de preguntas y respuestas, donde los desarrolladores podían consultar el significado de un fragmento de código o la solución a un error. Pero Boris consideraba que aún no existía un Coding Agent verdadero.

Entonces, el equipo decidió hacer un intento más audaz: ya no tratar el modelo como una herramienta de apoyo, sino convertirlo directamente en el núcleo del desarrollo. Querían ver qué sucedería si construían desde cero un producto de programación completamente centrado en Agent.

Sin embargo, Boris también admitió francamente que Claude Code inicialmente no era fácil de usar.

Durante mucho tiempo, solo podía completar alrededor del 10% al 20% de su trabajo. La mayor parte del código aún necesitaba ser escrita manualmente por él. El Claude Code que las personas ven hoy en día ya no es ni remotamente el mismo producto que en ese período.

¿Por qué Anthropic le da tanta importancia a la codificación?

Mucha gente cree que la razón por la que Anthropic valora la programación es sencilla: el mercado de la programación es lo suficientemente grande y tiene un valor comercial suficientemente alto. Pero la explicación de Boris es completamente diferente.

Él dijo que si detienes al azar a un empleado en las oficinas de Anthropic y le preguntas por qué vino aquí, la respuesta más probable será la misma: AI Safety.

Para Boris, la misión más fundamental de Anthropic desde su creación ha sido siempre la seguridad de la IA. Ya sea investigación en interpretabilidad, investigación en alineamiento u otras diversas direcciones de seguridad, en esencia todas intentan comprender el comportamiento de los modelos. Pero todas estas investigaciones terminan enfrentando el mismo problema: observar los modelos solo en el laboratorio no es suficiente; los investigadores también deben observar qué sucede cuando los modelos entran en el mundo real.

Y Coding es precisamente un campo de experimentación casi ideal.

A diferencia de la escritura, la pintura u otras tareas abiertas, la programación tiene un mecanismo de retroalimentación extremadamente claro: el código puede ejecutarse o no, el programa puede aprobar o no las pruebas, la compilación puede tener éxito o fallar, y las respuestas suelen ser muy claras. Al mismo tiempo, internet ofrece una cantidad masiva de código como datos de entrenamiento. En comparación con tareas como la creación de poesía, que pueden tener innumerables respuestas excelentes, el espacio de soluciones correctas para problemas de programación es mucho más convergente, lo que facilita la verificación de la capacidad del modelo.

Por esta razón, Anthropic ha prestado una gran atención desde muy temprano a la codificación, el uso de herramientas y el uso de computadoras. Estas áreas no solo tienen valor comercial, sino que, lo más importante, proporcionan un entorno experimental natural para estudiar cómo los modelos interactúan con el mundo real.

Desde este punto de vista, Claude Code nunca ha sido solo una herramienta de productividad dirigida a programadores. En la narrativa de Boris, también es una plataforma experimental clave de Anthropic para comprender los futuros sistemas de IA.

¿Por qué Claude Code se volvió repentinamente más fuerte?

Después de presentar el origen de Claude Code, el presentador planteó una pregunta que mucha gente se pregunta: dado que Claude Code, al principio, solo podía completar entre el 10% y el 20% del trabajo de Boris, ¿qué sucedió después? Después de todo, hoy Boris ha declarado públicamente que no ha escrito código manualmente en seis meses. De completar solo una pequeña parte de las tareas a asumir casi por completo el desarrollo, claramente ocurrieron cambios enormes.

Para esta pregunta, la respuesta de Boris fue sorprendentemente simple. Dijo que el exterior tiende a centrar la atención en las funciones del producto, pero si reflexiona sobre los momentos que realmente generaron saltos de capacidad, la razón más importante es simplemente una: el modelo se volvió más fuerte.

Durante el último año, el equipo de Anthropic ha seguido mejorando constantemente Claude Code. Han realizado una gran cantidad de trabajo de ingeniería para añadir diversas nuevas formas de interacción y formatos de producto. Inicialmente, Claude Code era solo una herramienta de línea de comandos, pero luego se expandió gradualmente a entornos como escritorio, móvil, Slack y GitHub. El equipo también ha probado continuamente nuevas funciones, como el modo planificación (Plan Mode) y otros mecanismos que ayudan a los desarrolladores a colaborar con Agentes. Pero, según Boris, todos estos son mejoras incrementales.

Lo que realmente determina el límite de Claude Code es el modelo subyacente en sí.

Mencionó varios puntos clave. Desde Sonnet 4 y Opus 4 hasta posteriormente Opus 4.5, cada mejora en la capacidad del modelo se refleja directamente en el rendimiento de Claude Code.

Luego, el presentador preguntó si la experiencia con Claude Code influiría a su vez en el desarrollo del modelo. La respuesta de Boris fue que casi todos en Anthropic usan Claude Code todos los días, incluyendo a quienes desarrollan modelos, a quienes crean productos... toda la empresa lo utiliza.

Por lo tanto, no existe un canal de retroalimentación dedicado. La retroalimentación forma parte integral del trabajo diario de la empresa.

Cuando los investigadores encuentran problemas durante el uso, el equipo de modelos los ve inmediatamente; después de mejorar las capacidades del modelo, todos perciben los cambios en su trabajo práctico. El producto y el modelo no son dos líneas paralelas, sino que evolucionan juntos dentro del mismo ciclo.

¿Cuánto aumento de productividad ha traído Claude Code a Anthropic?

Boris dice que, después de trabajar mucho tiempo en laboratorios de IA, la gente se acostumbra a pensar en términos de crecimiento exponencial. Muchas métricas internas —ya sea ingresos, uso o capacidad del modelo— parecen más bien curvas exponenciales, por lo que incluso se acostumbran a usar escalas logarítmicas para observar los cambios.

Y la producción de código también ha mostrado una tendencia similar.

Según los datos divulgados públicamente por Anthropic, desde que Claude Code se implementó ampliamente dentro de la empresa, la cantidad de código producida por cada ingeniero aumentó aproximadamente tres veces. Pero Boris enfatizó especialmente que estos datos ya están desactualizados. El aumento real es mucho mayor que esta cifra.

Lo más interesante es que este crecimiento ocurrió durante un proceso de expansión rápida de la empresa.

Según la experiencia tradicional, cuanto más numerosos sean los ingenieros de una empresa, menor suele ser la productividad promedio. Los nuevos empleados necesitan aprender el sistema, y los empleados experimentados deben responder preguntas, lo que hace que los costos de comunicación organizacional sigan aumentando.

Pero lo que Boris observó fue exactamente lo contrario. Anteriormente, un nuevo ingeniero podía tardar semanas en familiarizarse realmente con los sistemas internos. Ahora, este proceso generalmente solo toma dos días.

La razón no es que el sistema de capacitación haya experimentado un cambio revolucionario, sino que todos ya están acostumbrados a preguntar directamente a Claude. Los nuevos empleados no necesitan saber cómo consultar la base de datos. Incluso no necesitan saber a quién consultar. Dentro de Anthropic, cuando alguien pregunta «¿cómo se consulta la base de datos?», la respuesta frecuente es: «Abre Claude y haz que Claude consulte la base de datos». Muchos conocimientos tácitos que antes requerían que los ingenieros experimentados los dominaran comenzaron a transferirse a los Agentes. Para Boris, este podría ser el cambio más importante.

Claude Code no solo mejora la velocidad de generación de código, sino que también reduce progresivamente el costo de transmisión del conocimiento dentro de las organizaciones. Anteriormente, las empresas dependían de una cadena de transmisión de conocimiento para lograr el flujo de conocimiento. Ahora, cada vez más conocimiento se está encapsulando directamente en los modelos.

Desde las cintas de papel perforado hasta el Vibe Coding, la humanidad simplemente ha elevado nuevamente el nivel de abstracción de la programación.

Dado que Claude Code es tan poderoso, ¿aún escriben código los ingenieros que contrató Anthropic? Cuando el presentador planteó esta pregunta, el foco de la discusión se desplazó inmediatamente a: ¿cómo defines «escribir código»?

Para Boris, la historia del desarrollo de la ingeniería de software es esencialmente una historia de constante elevación de los niveles de abstracción.

Su abuelo programaba con tarjetas perforadas en la era soviética. En aquel entonces, los programadores tenían que perforar agujeros en tarjetas de papel y luego introducirlas en la computadora para esperar los resultados. Luego surgieron los lenguajes ensambladores. Después aparecieron Fortran y COBOL. Luego vinieron Java, Python y JavaScript. Cada aumento en el nivel de abstracción fue acompañado por quienes decían: "Esto ya no es programación real". Los que escribían ensamblador despreciaban a los que usaban lenguajes de alto nivel, y los que programaban en C consideraban que Python era demasiado simple. Pero Boris cree que lo que está sucediendo hoy no es esencialmente diferente. La humanidad simplemente ha elevado nuevamente el nivel de abstracción de la programación.

Él describió el proceso de cambio en su trabajo durante el último año. Al principio, él, como la mayoría de los desarrolladores: abría el IDE, escribía código y ocasionalmente usaba la autocompletación, que es el enfoque tradicional de desarrollo de software.

Después de la aparición de Claude Code, su forma de trabajar se volvió: describir las necesidades a Claude, dejar que Claude escriba el código y asumir él mismo la responsabilidad de revisar y corregir. En esta etapa, la persona aún dirige directamente al modelo; solo el código es generado por el modelo. Pero Boris considera que esto es solo una etapa de transición.

Los cambios verdaderamente interesantes han ocurrido recientemente. Él dice: "Ahora ni siquiera hago prompts directos a Claude". Su trabajo se ha transformado en otra forma. Él escribe diversos procesos y ciclos que se ejecutan automáticamente. Estos ciclos se encargan de hacer preguntas a Claude, descomponer tareas, gestionar el contexto y coordinar el trabajo entre múltiples instancias de Claude.

En otras palabras: antes, las personas le daban instrucciones a Claude. Ahora, son los programas los que le dan instrucciones a Claude. Su trabajo se ha convertido en diseñar estos sistemas automatizados. Lo resume con una frase muy concisa: mi trabajo se ha convertido en escribir Loops.

Parece que Boris no solo está externalizando el código a Claude, sino que también está automatizando el propio proceso de comunicación con Claude. Ya no se trata del modelo de Copilot que todos conocemos, sino más bien de un sistema compuesto por múltiples agentes que funcionan de forma continua.

Boris mencionó que en noviembre del año pasado incluso desinstaló su IDE. La razón no fue una declaración simbólica, sino porque se dio cuenta de que llevaba un mes sin abrir el IDE. Como no lo usaba en absoluto, naturalmente lo desinstaló. Durante ese período, generalmente ejecutaba simultáneamente cinco a diez instancias de Claude, con diferentes instancias de Claude encargadas de distintas tareas, mientras que él se dedicaba principalmente a supervisar todo el proceso.

¿Qué buscan los ingenieros que ya no escriben código?

En este momento, el presentador hizo una pregunta muy interesante: si hoy un ingeniero quisiera unirse a Anthropic, ¿cómo lo evaluaría Anthropic? O dicho de otro modo: en un mundo donde cada vez menos personas escriben código manualmente, ¿qué tipo de personas busca realmente la empresa?

La respuesta de Boris casi llevó directamente a la discusión posterior sobre la forma organizacional. Dijo que el tipo de persona que al equipo de Claude Code le gusta más es: Generalist.

La razón es sencilla: las organizaciones de software anteriores tenían una división muy clara de funciones: los investigadores de usuarios se encargaban de comprender a los usuarios, los diseñadores de diseñar productos, los gerentes de producto de planificar los requisitos y los ingenieros de implementar funciones; cada uno trabajaba en su propio eslabón, como en una línea de producción.

Pero el equipo de Claude Code ha descubierto en los últimos seis meses que esta división de tareas se está desmoronando rápidamente. Cada ingeniero en el equipo casi todos los días realiza todo tipo de tareas que originalmente no correspondían al rol de «ingeniero». Algunos se comunican directamente con los usuarios, otros diseñan interacciones, algunos recopilan datos, realizan análisis de datos y crean dashboards. Nadie se limita solo a una etapa estrecha.

Boris incluso mencionó un ejemplo más extremo: los diseñadores de Anthropic también escriben código, y los colegas de finanzas también escriben código. Satya Nadella llama a este rol «Builder». Este término puede ser más preciso que «ingeniero», porque la verdadera frontera ya no es «¿sabes escribir código?», sino «¿puedes convertir una idea en realidad?».

Desde la perspectiva de Boris, la IA no sustituye simplemente a los programadores; lo que realmente cambia es la relación entre el conocimiento y la ejecución. Anteriormente, una persona no podía desempeñar múltiples roles al mismo tiempo en gran medida debido al alto costo de aprendizaje. Ahora, los modelos están reduciendo constantemente el costo de transferencia entre estas habilidades. Por lo tanto, las personas con mayor ventaja en el futuro no serán necesariamente los expertos más profundos en un solo campo, sino aquellos capaces de cruzar rápidamente diferentes dominios y integrar constantemente recursos.

Por eso Boris cree que estamos entrando en una edad dorada para los generalistas. Para quienes están dispuestos a hacer muchas cosas, este podría ser el mejor momento de la historia.

Member of Technical Staff no es un reclamo, es una preparación para el futuro

El presentador cambió el tema del producto al diseño cultural y organizacional. Observó que el título de Boris no es «Director de Producto» ni «Director de Ingeniería», sino Member of Technical Staff, y que muchas personas en Anthropic tienen este mismo título. Se preguntó: ¿cuáles son las ventajas? ¿Hay desventajas?

Boris es muy sincero. Dice que lo peor es que le envías un mensaje a alguien en Slack cuyo título es MTS, y no tienes ni idea de si esa persona es diseñador, ingeniero o gerente, ni qué proyecto está haciendo. Pero le encanta ese título.

Él recuerda su experiencia en Meta. Todos los ingenieros de software en Meta tenían un solo título: Software Engineer, sin jerarquías como senior o principal. Al principio no lo entendía, pero luego descubrió que en realidad era un diseño cultural. Si le das a alguien un título de "senior", los demás se sentirán reacios a cuestionar sus malas ideas por deferencia. Pero al colocar a todos en un campo aparentemente igualitario, se obliga a que las ideas compitan entre sí, no los currículos.

Claro, él reconoce que los niveles no desaparecen realmente porque los títulos se eliminen. Sabes que alguien es L7, solo que no se indica el título. Pero lo interesante es que, en muchas ocasiones, realmente no lo sabes.

Él contó una historia sobre cuando era ingeniero L4 en Facebook. Tuvo una idea, fue directamente a buscar al VP responsable de conectividad y le dijo: “Esta es mi idea, hagámosla juntos”. Ese VP no sabía en absoluto qué nivel tenía él. Luego fue a otro VP y volvió a fracasar. En el tercer intento, lo logró. Formaron un equipo y comenzaron a desarrollar el producto.

Boris dice que ahora, en el equipo de Claude Code, ve lo mismo todos los días: ingenieros experimentados con 20 o 30 años de experiencia necesitan varios meses para "unlearn", es decir, dejar atrás hábitos antiguos que ya no son aplicables. En cambio, un recién graduado universitario que se une al equipo puede enseñarle cómo usar mejor Claude Code, porque los jóvenes piensan naturalmente con una mentalidad basada en modelos.

Cada vez que sale un nuevo modelo, todos deben recalibrar. La experiencia en esta era no se acumula linealmente, a veces incluso es una carga.

Entonces, el título aparentemente vago de Member of Technical Staff, según Boris, es una premonición de una realidad inminente: para fin de año, las fronteras entre ingenieros, PM, diseñadores e investigadores de usuarios desaparecerán básicamente. En lugar de aceptar pasivamente este cambio, es mejor usar el título para impulsar activamente a todos hacia un mismo rol: Builder.

Consejo para todos los fundadores: contrata menos personas y emite más tokens

El moderador pide a Boris que, desde la perspectiva de Anthropic, brinde un consejo más general a los fundadores y empresas presentes: ¿cómo deberían ajustar su mentalidad antes de finales de 2026?

La primera frase de Boris lleva un toque de humor: «Da a todos la mayor cantidad posible de tokens». Al igual que la famosa frase de Jensen Huang: «Cuanto más compres, más ahorrarás».

Esto no es una broma. Está serio. Sus recomendaciones específicas son dos cosas:

En primer lugar, otorga la mayor cantidad posible de tokens para que todos puedan experimentar intensamente.

En segundo lugar, cada proyecto intencionalmente «asigna a menos personas». Si crees que un proyecto necesita cuatro ingenieros, solo asigna dos, y dales una gran cantidad de tokens para que encuentren la manera por sí mismos. Descubrirás que, con gran probabilidad, realmente lo lograrán. Automatizarán todo lo que puedan, y como estará automatizado, la próxima vez será más rápido y más barato. Es un efecto de interés compuesto.

El anfitrión resumió muy concisamente esta sugerencia: con menos personas, transfiera el presupuesto de los salarios a tokens. Esto aumentará su costo inicial, pero reducirá significativamente el costo continuo. Es como pre-compilar: haces el trabajo sucio y pesado una sola vez, y cada ejecución posterior es casi gratuita.

Boris expresó total acuerdo. El moderador hizo luego una pregunta más directa: en el pasado, la gente se enorgullecía mucho de su disciplina. Los PM se enorgullecían de los artículos de producto que escribían, y los diseñadores de sus portafolios impecables. ¿Acaso en 12 meses todos deben renunciar a su identidad de «soy alguien» para convertirse en un «bolsa flexible que consume tokens»?

Boris dice: «Podría usar un lenguaje ligeramente diferente, pero... sí, más o menos es así.»

¿También la sensibilidad será erosionada por los modelos? Al final, solo quedará «el valor».

El anfitrión mencionó un tema que había discutido previamente con otro miembro de Anthropic, Jared, y quería escuchar la opinión de Boris: ¿cómo entienden ustedes el «taste» (gusto)?

La respuesta de Boris fue muy sincera. Dijo que cada vez que creyó tener algún "gusto especial" en programación, al final resultó estar equivocado.

Antes le encantaba la programación funcional, y le gustaban lenguajes como Haskell y Scala. En el código inicial de Claude Code, estableció una regla: no se permitían clases, solo funciones. Los ingenieros enviaban secretamente código con clases los fines de semana, y él lo rechazaba los lunes. Luego, cuando el modelo comenzó a escribir código a gran escala, el modelo escribió directamente clases. Él lo miró durante mucho tiempo y finalmente dijo: "Bueno, tal vez el modelo tenga razón. Tal vez mi obsesión no tuviera ningún sentido; el resultado comercial se logró, y más rápido, y el código no es malo."

Luego hizo una inferencia aún más atrevida. Ahora todos dicen que "el gusto del producto es el último alfa". Pero él cree que este alfa también está desapareciendo rápidamente.

Actualmente tiene cientos de instancias de Claude funcionando simultáneamente. Algunas están monitoreando comentarios en Twitter, otras revisando issues de GitHub, y otras analizando Slack, y luego deciden por sí mismas qué funciones implementar en la próxima fase. Por ahora, la mayoría de las ideas son malas, aproximadamente un 20% son buenas. Pero con el próximo modelo, dentro de 3 a 6 meses, la mayoría de las ideas probablemente serán buenas.

El presentador pregunta nuevamente: ¿Entonces, qué es lo único que aún le queda a la humanidad? ¿Hay algo que el modelo nunca podrá hacer?

Boris pensó un momento y dijo: valores.

Él dijo que, al final, lo que queremos enseñar al modelo es lo mismo que lo que enseñamos a los niños: cómo ser un buen ser. Cómo hacer lo correcto, y no solo hacer las cosas correctamente.