Cada seis meses, borra tu Claude.md, borra tus skills, borra tus hooks.
Este es el consejo de Boris Cherny, el padre de Claude Code, a los usuarios del producto.
En la nueva entrevista publicada por YC el 28 de julio, "Boris Cherny: We Cut 80% of Claude Code's Prompt", Boris hace un apasionado llamamiento a todas las personas que desarrollan productos de IA para que sean valientes y pulsen la tecla de eliminar en sus nuevos productos, eliminando drásticamente los prompts del sistema, las herramientas y el código de arnés.
△
"Deberías borrar todo el prompt del sistema y luego ir añadiéndolo línea por línea, para ver qué impacto tiene realmente cada línea."
Detrás de esta idea está el concepto de estudio de ablación (ablation study), que recorre la última entrevista de Boris Cherny, con el objetivo de, manteniendo constantes las demás condiciones, eliminar, reemplazar o desactivar un módulo para comparar los cambios en rendimiento, estabilidad, eficiencia o coste.
En la entrevista, Boris afirma con orgullo: "En realidad, para Opus 5, sinceramente recomendamos probar a borrar todas esas cosas, porque el modelo ya no las necesita."
A pesar de los recientes acontecimientos... un usuario también podría afirmar: "En realidad, para Claude, sinceramente recomendamos borrarlo, porque ya no lo necesitamos." (x)
Además de "eliminar con valentía", Boris revela en la entrevista más reflexiones valiosas sobre el diseño de productos, el uso de modelos y el aprendizaje de la programación:
Las opiniones de este artículo provienen del vídeo de la entrevista. Los puntos clave de lectura son: 1. La estrategia de iteración de producto de Boris: Menos predicciones, más pruebas. 2. "Excedente del producto": En un mismo periodo, la capacidad del modelo siempre supera los límites del producto. 3. "Desatar": Hacer que el modelo realice tareas más difíciles y trabaje de forma independiente durante más tiempo. 4. ¿Cómo utilizan la IA los usuarios más avanzados de Claude? 5. Tres consejos para quienes aprenden programación.
"El modelo es un organismo vivo, tiene su propia personalidad"
"Hoy, el código en el arnés de Claude Code casi solo incluye partes de seguridad, permisos y análisis estático."
El 24 de julio, Anthropic publicó las últimas reglas de ingeniería de contexto para Claude 5. Para los nuevos modelos como Opus 5 y Fable 5, el system prompt de Claude Code se simplificó significativamente, eliminando más del 80% de las instrucciones originales.
Para más detalles, consulta el artículo de QbitAI "Claude Code borra frenéticamente el 80% de los prompts, Opus 5 los vuelve a añadir".
Sobre este cambio, Boris comparte en la entrevista su estrategia de iteración de producto: No intentes adivinar qué instrucciones necesita el modelo, porque simplemente no aciertas. Lo que puedes hacer es eliminar línea por línea, probar, y encontrar dónde se atasca repetidamente el modelo.
"Debes pensar en el modelo como un ser vivo, algo más orgánico. Cada generación de modelos se comporta de manera diferente, su personalidad varía ligeramente. Tienes que tomarte el tiempo para entenderlo y ajustar el arnés en consecuencia."
△
Por lo tanto, para Boris esto es más "empírico", y debe tratarse de forma científica: probar sin prejuicios, observar resultados, iterar, repetir.
Y en un mundo de constante reinvención, Eval tampoco es necesariamente estable. Aunque ciertamente es más duradero que el arnés y los prompts, actualmente los modelos evolucionan tan rápido que a menudo un conjunto de evaluaciones alcanza rápidamente la puntuación máxima. Por lo tanto, es necesario observar dónde lucha constantemente el modelo y luego diseñar nuevos Eval.
Una forma de pensar: Excedente, desatar
En la entrevista, Boris comparte un concepto llamado "Product Overhang" (Excedente del Producto), que considera una forma de pensar muy útil para su trabajo en productos.
Overhang, ¿qué significa? Excedente, algo que sobresale o queda pendiente.
Los grandes modelos evolucionan a saltos discontinuos, mientras que la integración en productos avanza de forma incremental y continua. Esto hace que las capacidades del modelo siempre superen los límites que el producto actual puede liberar.
Boris pone un ejemplo: A finales de 2024, cuando se lanzó Sonnet 3.5, este modelo ya podía escribir código de archivos completos de una vez. Pero en ese momento, los productos de programación como Copilot o las primeras versiones de Cursor aún se dedicaban a pequeñas tareas como completar código.
Claude Code, con permisos completos de terminal, compensaba en cierta medida esta brecha. Este es el segundo concepto que propone Boris: "Unhobbling", desatar, quitar las restricciones.
△
Comparte un caso interno de Anthropic: Alguien intentó dar a Opus 5 acceso a OpenCV (la mayor biblioteca de visión por computadora de código abierto del mundo) y descubrió que el modelo podía dibujar retratos de personas, animales y paisajes por sí mismo, algo para lo que nunca antes habían entrenado al modelo.
Esto es la "elicitación del modelo" (model elicitation): Sin cambiar los pesos del modelo, a través del diseño de prompts, contexto, herramientas o la forma del producto, hacer que el modelo muestre capacidades que ya poseía pero que antes no se invocaban.
Aunque aquí quizás aún existan dudas: ¿Cómo atribuirlo? ¿Realmente se despertó una capacidad latente del modelo, o el modelo aprendió una nueva habilidad debido al diseño del "andamiaje"?
Pero quizás esto no sea importante. En cualquier caso, Boris no duda en absoluto de que existe una enorme oportunidad comercial aquí:
No digo que todas las startups puedan aprovecharlo. Pero sé que hay gente pensando en estos problemas, aquí realmente hay una oportunidad enorme para despertar comportamientos del modelo que sean asombrosos, interesantes y con valor comercial.
Para ello, Boris propone tres métodos personales para "desatar" el modelo.
Primero, darle al modelo tareas más difíciles de lo que imaginas. Describe claramente el objetivo, los límites y las condiciones de salida, y luego déjalo actuar.
Segundo, experimentar más. Permitir que el modelo haga intentos divertidos sin un propósito comercial claro, "darse la libertad de jugar con el modelo, de hacer cosas creativas".
Tercero, dejar que el modelo valide sus propios resultados. El foco hoy ya no está en la "ingeniería de prompts". El problema ahora es: "Cuando le asignas a Claude una tarea extremadamente difícil, ¿cómo haces que valide su propio trabajo durante el proceso?"
Boris cree que este tercer punto es probablemente en lo que la gente se desempeña de manera menos satisfactoria hoy. Porque si el modelo no puede autoverificarse, no puede funcionar de forma independiente durante largos periodos.
△
Su propio ejemplo quizás pueda inspirar a todos:
Boris: "Vale, lo que quiero que hagas es: Reescribe la aplicación Electron en Swift. Quiero que ejecutes la aplicación Electron en una máquina virtual Mac, captures la pantalla y luego compares píxel a píxel con la versión Swift. No pares hasta que no esté terminado." Entrevistador: ¿Ese es tu prompt? Boris: Ese es mi prompt. Entrevistador: ¿Cuánto tiempo ha estado funcionando? Boris: Todavía está funcionando. Entrevistador: ¿Cuándo empezó? Boris: Lleva más de dos semanas, unos 14, 15 días... Claude incluso decidió hacer un "streaming en directo". Lo que hace es crear un canal de Slack interno y enviar una captura de pantalla del progreso cada pocos minutos.
Consejos prácticos de Boris para usuarios de IA y emprendedores
Al final de la entrevista, el entrevistador plantea la pregunta:
Entonces, Boris, ¿cómo podemos usar Claude tan bien como tú?
Boris indica que lo más importante es no escuchar a los influencers de LinkedIn, no desplazarse por Twitter.
Sobre el uso de la IA, "todo el mundo busca ese 'truco mágico'. Pero simplemente no existe esa cosa. No existe."
Recomienda tratar el modelo de forma empírica, olvidar la experiencia con modelos antiguos y la teoría de la informática aprendida en clase, observar directamente dónde se atasca el modelo y ajustar en consecuencia.
Así que ya no es una ciencia teórica, se ha convertido en una ciencia empírica. Creo que aquellos que son especialmente buenos soltando sus preconcepciones, dejando atrás esas ideas de 'antes no funcionaba', dispuestos a intentarlo de nuevo, tendrán mucho, mucho éxito.
Lo más importante es mantener una mentalidad de soltar el "deseo de control" sobre el modelo, tratar al modelo como a un compañero de trabajo, sin sobreespecificar, sin hacer demandas demasiado concretas, sin intentar que el modelo haga la tarea exactamente de la forma en que tú lo harías. Porque "el modelo no funciona así".
Para aquellos que aún están aprendiendo programación, Boris hace un llamamiento a no aprender solo teoría pura de informática, sino a aprender a aplicarla. Por ejemplo, su propia motivación inicial para aprender programación fue hacer trampa en un examen de matemáticas.
Normalmente se trata de emprender, de hacer productos, de desarrollar tu propio sentido del diseño, del negocio, aprender a hacer ciencia de datos, aprender a hablar con los usuarios... Cuando combinas eso con la informática y la ingeniería, es cuando se vuelve realmente valioso.
En resumen, "primero haz lo que tú quieres, luego mejora para hacer lo que otros quieren".
Este artículo proviene del WeChat Official Account "量子位" (ID: QbitAI), autor: 关注前沿科技
