El fundador de Claude Code, Boris Cherny, comparte 7 juicios clave sobre IA en la conferencia de Sequoia

Organizado por A Ying

Boris Cherny, fundador de Claude Code, compartió en la conferencia de Sequoia, y la información fue muy abundante; muchas de sus ideas las escuché por primera vez de forma completa. Este tipo realmente entiende bien la IA.

Comparto mi resumen.

Para una gran cantidad de escenarios de desarrollo principales, escribir código a mano ya se está volviendo algo ineficiente.

Antes, para entregar una función, los ingenieros se sentaban, pensaban cuidadosamente cómo implementarla y luego escribían el código línea por línea. En este proceso, el mayor valor del ingeniero era: saber escribir o no, escribir bien o mal, escribir rápido o lento.

The way things work now is different.

Para la misma función, lo que hace el ingeniero es más como: primero aclarar los requisitos, dividir la tarea en varias partes y asignarlas al agente, establecer un criterio de aceptación, y luego verificar si el resultado generado por el agente es correcto; si no lo es, ajustar la indicación y hacer que lo ejecute nuevamente.

La IA ya puede manejar la mayoría de las tareas de codificación. Por supuesto, no es del 100%, aún existen grandes y complejos repositorios de código, lenguajes poco comunes o entornos especiales en los que los modelos actuales aún no se desempeñan lo suficientemente bien.

En general, el valor del ingeniero ha pasado de saber o no escribir código a saber o no descomponer tareas, explicar claramente los objetivos, validar los resultados y gestionar Agentes.

Este cambio es en realidad muy parecido a la Revolución Industrial.

Antes de la Revolución Industrial, un herrero realizaba por sí solo todo el proceso: forjar, moldear, pulir y ensamblar. Los herreros con buena habilidad eran naturalmente valiosos.

Luego apareció la línea de producción. Cada trabajador se encargaba solo de una etapa, y la producción total era decenas o cientos de veces mayor que en la era artesanal.

En este momento, el papel más valioso en la fábrica ya no es el artesano que realiza mejor una sola operación, sino quien puede diseñar, gestionar y hacer que la línea de producción funcione sin problemas.

Los trabajadores no han desaparecido, pero su rol ha cambiado.

La ingeniería de software está experimentando ahora un giro similar. El código en sí ya no es escaso. Saber escribir código está convirtiéndose en una habilidad básica, como saber usar PowerPoint.

Lo verdaderamente escaso es la capacidad de descomponer necesidades ambiguas en tareas claras, de elegir la mejor opción entre varias propuestas del agente y de hacer que un grupo de IA colabore para lograr un objetivo.

De hecho, muchos ingenieros experimentados al principio no pudieron aceptar esto. Hacer el código uno mismo ha sido, durante las últimas décadas, la razón por la que mucha gente amaba esta profesión.

Entregar esto a una máquina, para muchas personas, no solo cambia la forma de trabajar, sino que implica una redefinición de la identidad.

Pero la tendencia es la tendencia.

La programación está pasando de ser una habilidad profesional a convertirse en una competencia básica. Esto puede compararse con la imprenta en Europa del siglo XV.

Antes de la invención de la imprenta, solo alrededor del 10% de la población europea sabía leer y escribir. Estas personas solían estar empleadas por nobles analfabetos, dedicándose exclusivamente a leer y escribir por ellos.

Luego llegó la imprenta. En 50 años, el número de libros publicados en Europa superó la suma de los mil años anteriores, y los precios de los libros bajaron aproximadamente 100 veces. Pasaron cientos de años más hasta que los sistemas complementarios (educación, estructura económica) se adaptaron, y la tasa global de alfabetización alcanzó el 70% actual.

Boris cree que la influencia de la IA en el software es una revolución de la imprenta acelerada. El software se democratizará por completo en décadas, convirtiéndose en algo que cualquiera puede manejar.

Al final, hacer software será tan natural como enviar un mensaje de texto.

Cuando la barrera para escribir código se reduce a un nivel extremadamente bajo gracias a la IA, lo que realmente distingue la capacidad de una persona es su sentido del producto y su comprensión genuina de un campo específico.

Por ejemplo. Dos personas quieren desarrollar un producto dirigido a médicos. Una es un ingeniero que codifica rápidamente, y la otra ha trabajado varios años en el departamento de información hospitalaria.

Antes, el ingeniero tenía más probabilidades de hacer realidad algo, porque podía implementar la idea.

Ahora es al revés. Cualquiera puede implementar una idea. En este momento, la persona que realmente entiende los flujos de trabajo diarios del hospital es más valiosa, porque sabe qué funciones realmente usarán los médicos y cuáles solo suenan lógicas.

Es decir, después de que la IA nivelara el umbral de ejecución, la brecha en el juicio se amplió.

This event directly rewrote the meaning of the word generalist.

Anteriormente, cuando decíamos generalista, normalmente nos referíamos a un ingeniero que podía desarrollar tanto para iOS como para Web y para el backend. Este tipo de generalista, en esencia, sigue siendo un full-stack dentro de la ingeniería.

El generalista del futuro es un full-stack interdisciplinario.

Alguien entiende simultáneamente producto, diseño e ingeniería. Alguien entiende simultáneamente producto, ciencia de datos e ingeniería. Esta combinación era casi imposible en el pasado, ya que cada una requería un entrenamiento especializado prolongado.

Pero ahora la IA ha reducido el umbral de entrada para cada tarea, permitiendo que una persona abarque varios campos y aún así mantenga la profundidad profesional.

El equipo de Claude Code es así. El gerente de ingeniería, el PM, el diseñador, el científico de datos, finanzas, investigación de usuarios, todos escriben código.

Los diseñadores pueden ejecutar directamente los prototipos interactivos para mostrarlos al equipo, en lugar de solo entregar imágenes y esperar a que los ingenieros las implementen.

El equipo de finanzas puede construir su propia herramienta de análisis para ejecutar modelos financieros complejos de la empresa, sin tener que esperar su turno en el equipo de BI. Los colegas de investigación de usuarios también comenzaron a ejecutar sus propios datos, asumiendo las tareas que antes dependían del equipo de datos.

La profundidad profesional de cada uno aún existe. Pero con la ayuda de la IA, escribir código se ha convertido en un lenguaje compartido por todos.

Durante los últimos diez años, la industria SaaS ha tenido varias ideas consideradas casi como axiomas.

El primer costo es el de cambio. Una vez que una empresa utiliza tu sistema, acumula gradualmente datos, configuraciones, campos y relaciones de permisos de varios años, incluso décadas.

Mudarse a otro sistema, simplemente trasladar estas cosas tal cual y volverlas a importar, es suficiente para hacer que uno se sienta agotado y no quiera moverse.

La segunda es el bloqueo del flujo de trabajo. Las operaciones diarias de los empleados, la colaboración interdepartamental y los puntos de aprobación surgen todos alrededor de este SaaS.

Cambiar un sistema no es solo transferir datos, es derribar y volver a construir los hábitos que la empresa ha desarrollado durante los últimos años.

Sumadas, estas dos constituyeron la fortaleza más profunda de la industria SaaS en el pasado. Pero con modelos lo suficientemente potentes, la lógica de las cosas comienza a cambiar.

Primero, veamos el costo de cambio. Anteriormente, pasar de un SaaS a otro requería que el equipo de ingeniería trabajara horas extras durante meses solo para alinear los campos y replicar la estructura de datos.

Ahora simplemente se proporcionan las interfaces y estructuras de datos de ambos lados al modelo, permitiéndole descifrar por sí mismo las relaciones de mapeo y avanzar paso a paso hacia la solución óptima. Lo que antes tomaba meses puede producir una versión funcional en pocos días.

Ahora veamos el otro lado del bloqueo del flujo de trabajo, que es más interesante. En el pasado, los flujos de trabajo podían retener a los clientes porque estos procesos eran complejos, implícitos y dependían de personas.

La comprensión implícita entre los empleados sobre quién debe aprobar a quién y en qué paso se atasca no se puede trasladar directamente.

Pero modelos como Opus 4.7 son precisamente los mejores para comprender, desglosar y volver a armar un proceso complejo en un nuevo entorno. Incluso, la versión reconstruida podría funcionar mejor que la original.

Así que el foso de protección construido con base en la acumulación de datos y procesos está desmoronándose.

Para quienes desarrollan SaaS, esto podría ser una mala noticia. Pero para todos los clientes que utilizan SaaS y los equipos que preparan la próxima generación de SaaS, esta es una verdadera ventana de oportunidad.

Las empresas emergentes que realmente revolucionarán la industria en los próximos 10 años podrían ser 10 veces más que las de los últimos 10 años.

La razón en realidad no es complicada.

Los pequeños equipos pueden usar la IA para crear productos del mismo nivel o incluso superiores a los de las grandes empresas. Por el contrario, para las grandes empresas, intentar usar realmente la IA se convierte en un activo negativo.

How to say it?

Una empresa con más de una década de historia ha desarrollado un conjunto completo de procesos operativos, asignación de roles, hábitos de colaboración, sistema de capacitación y métricas de desempeño (KPI). Estos elementos fueron, en el pasado, activos y barreras de entrada.

Pero integrar verdaderamente la IA significa revisar todo esto: reestructurar los procesos de negocio, capacitar nuevamente a todos los empleados, y enfrentar una gran resistencia interna en cada paso adelante, coordinando N departamentos y N niveles de aprobación.

Un equipo inicial de tres personas ha tratado la IA como la base predeterminada desde el primer día. No tienen cargas históricas que eliminar, hábitos que cambiar ni a nadie que convencer. Hoy discuten con claridad, mañana generan un demo y al día siguiente ya pueden lanzarlo para que los usuarios lo utilicen.

Esta diferencia de velocidad ya existía antes con la IA. Las startups siempre han tenido una ventaja de velocidad sobre las grandes empresas. Pero la IA ha multiplicado esta brecha por muchas veces.

¿Por qué?

Cuanto más potente sea la IA, mayor será la palanca que una persona puede mover en un período de tiempo determinado. Un pequeño equipo que utilice la IA de manera efectiva hoy puede producir lo que antes lograban diez personas, y mañana podría equivaler a treinta personas del pasado.

Pero el peso organizativo de las grandes empresas no se ha aligerado; por el contrario, se ha vuelto más pesado debido a la necesidad de integrar la IA. Cuanto más poderosa sea la IA, mayor será la brecha entre la aceleración de los pequeños equipos y la resistencia de las grandes empresas.

Esto es lo que Boris llama activos negativos. No es que las grandes empresas no tengan dinero, personas o voluntad; es que esos músculos que antes les generaban ganancias ahora se atascan en el camino hacia el verdadero valor del AI.

MCP no morirá.

Después de que Skill se volvió popular, mucha gente creyó que MCP ya no era necesario. El fundador de OpenClaw también tiene una opinión similar.

Pero Boris no lo ve así. Él cree que MCP se convertirá en la capa de conexión de software de la era de la IA.

Anteriormente, la forma de conectar software en Internet era mediante API.

Pero el problema fundamental de la API es que está diseñada para ingenieros. Para usar una API, primero debes revisar la documentación, solicitar un Token, escribir código, alinear campos y manejar excepciones. En resumen, la API está hecha para desarrolladores humanos.

MCP es diferente. Permite que los modelos se conecten directamente; el modelo puede leerlo y llamarlo por sí mismo, sin necesidad de que un programador lo traduzca por el medio.

Entonces Boris llama a la API Human Developer Interface y al MCP Model Interface Protocol. Uno es para humanos y el otro es para modelos.

Esto es realmente muy similar a lo de entonces. En la era de Internet móvil, se daba por sentado que todos los servicios debían estar estandarizados en API. En la era de la IA, se da por sentado que todos los servicios deben estar estandarizados en MCP.

Mucha gente ahora habla de Computer Use y piensa que esta dirección podría no funcionar.

La razón también es lógica: consume demasiados Token, es lento y no es estable. Parece más bien una demostración de habilidad técnica, aún le falta mucho para ser realmente utilizable.

Pero Boris ve un nivel completamente diferente.

Lo que realmente valora es que Computer Use resuelve uno de los mayores dolores de cabeza para la implementación de IA: en el mundo real, existen muchos sistemas que no tienen API ni MCP.

Especialmente en el mundo empresarial.

Solo quien haya trabajado en la empresa sabe que muchos de sus sistemas centrales son muy antiguos: ERP, OA, sistemas financieros, aprobaciones internas, backends de cadena de suministro, diversos sistemas personalizados. Muchos no tienen interfaces abiertas, ni documentación, ni capacidad de automatización. Simplemente están allí, operados manualmente por innumerables empleados cada día.

¿Por qué no les hacemos directamente una API?

Porque es inviable. Los proveedores que desarrollaron estos sistemas probablemente ya no existen. El departamento de TI no tiene motivación ni presupuesto para reestructurarlos.

El departamento de operaciones no puede detenerse a esperar seis meses o un año. Estos sistemas nunca esperarán a que una API perfecta los salve.

En el corto plazo, los principales modelos aún deberían seguir mejorando su capacidad de uso de computadoras.