Las 4 líneas que todo CLAUDE.md necesita.

En una sola semana de abril de 2026, Anthropic lanzó Claude Opus 4.7, presentó un nuevo producto llamado Claude Design y añadió Routines, una función capaz de ejecutar tareas incluso cuando tu computadora portátil está cerrada.

Ese mismo día, OpenAI llevó Codex un paso más allá con agentes paralelos capaces de hacer clic y escribir directamente en tu Mac.

Esto ya es normal. Abril de 2026 ha sido calificado como uno de los meses con mayor cantidad de lanzamientos de modelos de lenguaje de la historia. Aproximadamente entre el 65 % y el 70 % del código empresarial está siendo escrito por IA. Más del 50 % de las empresas describe su proceso de adopción de inteligencia artificial como un «caos sin ningún tipo de control».

Y, aun así, el recurso para desarrolladores con más estrellas de todo este sector no es un framework, un plugin ni un modelo.

Son cuatro frases dentro de un archivo Markdown.

Un repositorio de GitHub. 60 000 estrellas.

Sin dependencias, sin API y sin proceso de compilación.

Solo un archivo CLAUDE.md con cuatro directrices de comportamiento derivadas de algo que Andrej Karpathy publicó en enero. Lo que 60 000 desarrolladores decidieron guardar como favorito revela mucho más sobre el verdadero cuello de botella de la programación asistida por IA que cualquier anuncio de producto realizado esta semana.

El fin de semana pasado dediqué tiempo a migrar mi propio archivo CLAUDE.md para que funcionara mejor con la actualización más reciente de Claude Code. Tenía cuarenta y siete reglas, cuidadosamente acumuladas durante meses. El agente ignoró la mitad de ellas e inventó convenciones que yo nunca había escrito. Fue entonces cuando encontré este repositorio. Y también cuando comprendí que el problema no eran mis reglas, sino la cantidad de reglas que había creado.

Lo que Karpathy realmente diagnosticó

En enero de 2026, Andrej Karpathy publicó un hilo que tuvo un impacto diferente al de la mayoría de los comentarios sobre inteligencia artificial. No estaba anunciando nada. Estaba describiendo qué se había roto.

En aproximadamente seis semanas, entre noviembre y diciembre de 2025, había pasado de programar manualmente el 80 % del tiempo, con un 20 % de asistencia de agentes, a hacer exactamente lo contrario: 80 % mediante agentes y 20 % mediante correcciones manuales. Lo calificó como «fácilmente el cambio más grande en aproximadamente dos décadas de programación». Pero el hilo no tenía un tono de celebración. Era un diagnóstico.

Los modelos no estaban fallando al escribir código. Estaban fallando al aplicar criterio.

«Los modelos hacen suposiciones incorrectas en tu nombre y simplemente continúan trabajando basándose en ellas, sin comprobar nada».

Karpathy identificó el problema más profundo:

«No gestionan su confusión, no buscan aclaraciones, no exponen inconsistencias, no presentan ventajas y desventajas y no cuestionan las decisiones cuando deberían hacerlo».

Les pides «exportar los datos de los usuarios» y el agente supone que deben exportarse en JSON, los guarda en el disco, incluye todos los campos y omite la paginación. Nunca se detiene para decir: «No estoy seguro de qué formato deseas». Simplemente elige una opción y continúa.

De ahí surge la Línea 1.

«Les encanta complicar demasiado el código y las API, y llenar todo de abstracciones innecesarias».

En palabras de Karpathy, los modelos:

«Implementan una construcción inflada de más de 1 000 líneas cuando 100 serían suficientes».

Pides una calculadora de descuentos y recibes un patrón Strategy con clases base abstractas, un enum, una configuración mediante dataclass y 40 líneas de preparación. El agente construye pensando en los requisitos del futuro, en lugar de resolver el problema actual.

Esto se corresponde directamente con la Línea 2.

«Todavía modifican o eliminan comentarios y código que no comprenden suficientemente como efectos secundarios, aunque no tengan ninguna relación con la tarea».

Le pides al agente que corrija un error y el pull request también cambia todas las comillas simples por comillas dobles, añade anotaciones de tipos que no solicitaste y reescribe código cercano. La solución necesitaba tres líneas. El cambio contiene cuarenta.

La Línea 3 existe precisamente por esto.

El hilo tuvo una gran repercusión porque no era prescriptivo. Karpathy no ofreció soluciones. Describió los modos de fallo con tanta claridad que, pocos días después, alguien los tradujo en un archivo CLAUDE.md de cuatro líneas y lo publicó en GitHub.

Pero existe una cuarta línea que va más allá de la disciplina y se relaciona con algo que el propio Karpathy ya había insinuado:

«Los modelos de lenguaje son excepcionalmente buenos repitiendo ciclos hasta alcanzar objetivos específicos. No les digas qué deben hacer. Dales criterios de éxito y observa cómo trabajan».

Esa es la Línea 4. Y es lo que convierte todo esto en algo más que una simple guía de estilo.

Las nueve secciones que todo DESIGN.md necesita

Lo que 70 000 desarrolladores guardaron como favorito, lo que Google publicó como código abierto y por qué un simple archivo Markdown supera a toda tu cadena de herramientas de diseño.

levelup.gitconnected.com

Las cuatro líneas

Aquí están. Esta es la sección completa de comportamiento de un archivo CLAUDE.md que 55 000 desarrolladores consideraron suficientemente valiosa como para darle una estrella:

1. No hagas suposiciones. No ocultes la confusión. Expón las ventajas y desventajas.
2. Escribe la cantidad mínima de código necesaria para resolver el problema. Nada especulativo.
3. Modifica únicamente lo imprescindible. Limpia solamente el desorden que tú mismo hayas creado.
4. Define criterios de éxito. Repite el proceso hasta verificar el resultado.

Eso es todo. Cada línea se corresponde directamente con uno de los modos de fallo descritos por Karpathy.

Presiona Enter o haz clic para ver la imagen en tamaño completo

Las cuatro líneas: la base completa de comportamiento para tu archivo CLAUDE.md

Analicemos por qué funciona cada una. Los ejemplos de antes y después que aparecen a continuación están adaptados del archivo EXAMPLES.md del repositorio, que incluye explicaciones completas de cada principio.

Piensa antes de programar: no hagas suposiciones, no ocultes la confusión y expón las ventajas y desventajas

Este principio corrige una de las frustraciones más comunes relacionadas con los agentes de programación: hacen suposiciones cuando deberían hacer preguntas.

Sin esta línea, esto es lo que sucede cuando le dices a un agente: «Añade una función para exportar los datos de los usuarios».

def export_users(format='json'):    users = User.query.all()    if format == 'json':        with open('users.json', 'w') as f:            json.dump([u.to_dict() for u in users], f)    return f"Exported {len(users)} users"

El agente supuso que el formato sería JSON. Supuso que debía exportar a todos los usuarios. Supuso que debía generar un archivo en el disco. Supuso qué campos debía incluir. Nunca mencionó ninguna de estas decisiones. Simplemente eligió y continuó trabajando.

Con este principio, la primera respuesta del agente sería algo parecido a esto:

Antes de implementarlo, necesito aclarar algunos puntos:

1. Alcance: ¿debo exportar a todos los usuarios o solo a un subconjunto filtrado?
2. Formato: ¿una descarga en JSON, un archivo CSV o un endpoint de API?
3. Campos: ¿qué campos del usuario deben incluirse? Algunos podrían contener información sensible.
4. Volumen: ¿cuántos usuarios existen? Esto podría afectar al enfoque que se utilice.

Cuatro preguntas en lugar de cuatro suposiciones. El código se escribe después de obtener las respuestas, no antes.

La razón por la que esto es más importante de lo que parece es que los modelos de lenguaje no exteriorizan su incertidumbre de manera natural. Han sido entrenados para completar contenido, no para detenerse. Cada token de sus datos de entrenamiento impulsa la respuesta hacia delante. Detenerse y decir «No estoy seguro» va en contra de la forma en que estos modelos aprendieron a generar texto.

Esta línea obliga al modelo a adoptar un comportamiento para el que tiene capacidad, pero que no utiliza de manera predeterminada. No añade una función nueva. Modifica un comportamiento predeterminado.

La simplicidad primero: escribe la cantidad mínima de código necesaria para resolver el problema, sin nada especulativo

Este principio elimina las abstracciones prematuras. Sin él, pides «una función para calcular un descuento» y obtienes algo como esto:

class DiscountStrategy(ABC):    @abstractmethod    def calculate(self, amount: float) -> float:        passclass PercentageDiscount(DiscountStrategy):    def __init__(self, percentage: float):        self.percentage = percentage    def calculate(self, amount: float) -> float:        return amount * (self.percentage / 100)class FixedDiscount(DiscountStrategy):    # ... 20 líneas adicionalesclass DiscountCalculator:    def __init__(self, config: DiscountConfig):        # ... 15 líneas adicionales de configuración

Una clase base abstracta. El patrón Strategy. Una configuración mediante dataclass. Más de cuarenta líneas para realizar una operación aritmética.

Con este principio:

def calculate_discount(amount: float, percent: float) -> float:    return amount * (percent / 100)

Una función. Una línea de lógica. Si más adelante necesitas el patrón Strategy, podrás refactorizar el código en ese momento. No ahora. No de manera especulativa.

Esta es la idea que la mayoría de los artículos no menciona: la versión excesivamente complicada no es necesariamente incorrecta. Sigue patrones de diseño reales. Un ingeniero sénior podría utilizar el patrón Strategy dentro de un gran sistema de facturación.

El problema es el momento en que se utiliza.

Las abstracciones prematuras tienen un coste acumulativo: más código significa una mayor superficie para que aparezcan errores, más carga cognitiva para los revisores y más resistencia cuando sea necesario cambiar de dirección. El agente construye pensando en requisitos que todavía no existen y que quizá nunca lleguen a existir.

El buen código resuelve con sencillez el problema de hoy. No intenta resolver prematuramente el problema de mañana.

La prueba del ingeniero sénior incluida en el archivo original lo resume perfectamente:

«¿Un ingeniero sénior diría que esto está demasiado complicado?».

En caso afirmativo, simplifícalo.

Presiona Enter o haz clic para ver la imagen en tamaño completo

Diagrama del autor: Antes y después de aplicar las cuatro líneas a la corrección de un error real

Cambios quirúrgicos: modifica únicamente lo imprescindible y limpia solamente tu propio desorden

Este principio protege tus diferencias de código. Le pides al agente que corrija un error por el que un correo electrónico vacío provoca un fallo en el validador. Sin este principio, el cambio se vería así:

- if not user_data.get('email'):+ email = user_data.get('email', '').strip()+ if not email:      raise ValueError("Email required")- if '@' not in user_data['email']:+ if '@' not in email or '.' not in email.split('@')[1]:      raise ValueError("Invalid email")- if not user_data.get('username'):+ username = user_data.get('username', '').strip()+ if not username:      raise ValueError("Username required")+ if len(username) < 3:+     raise ValueError("Username too short")+ if not username.isalnum():+     raise ValueError("Username must be alphanumeric")

La corrección del error consistía en gestionar correctamente un correo electrónico vacío. Sin embargo, el agente también «mejoró» la validación del correo, añadió comprobaciones sobre la longitud del nombre de usuario, incorporó una restricción para permitir únicamente caracteres alfanuméricos y cambió los nombres de las variables.

Nada de eso había sido solicitado.

Con este principio, el cambio es quirúrgico:

- if not user_data.get('email'):+ email = user_data.get('email', '')+ if not email or not email.strip():      raise ValueError("Email required")- if '@' not in user_data['email']:+ if '@' not in email:      raise ValueError("Invalid email")

Cada línea modificada se relaciona directamente con el error reportado. Nada más.

La verdadera ventaja no es únicamente la limpieza, sino la posibilidad de auditar el resultado.

Cuando el cambio realizado por un agente contiene cuarenta líneas y solamente tres están relacionadas con la solicitud original, no puedes confiar en las otras treinta y siete sin revisarlas una por una. No se trata de una molestia menor. Es un impuesto de revisión aplicado a cada fragmento de código generado por inteligencia artificial.

Los cambios quirúrgicos hacen que el resultado de la IA pueda revisarse a la velocidad que realmente necesitas. Cuanto menor sea el cambio, más rápido podrás confiar en él, fusionarlo y continuar con el trabajo.

El archivo original añade un matiz sutil, pero importante: cuando TUS cambios crean elementos huérfanos, como importaciones no utilizadas o variables muertas, debes eliminarlos. Sin embargo, no debes modificar código muerto que ya existía anteriormente, salvo que te lo pidan.

Tu desorden, tu limpieza. El desorden de los demás, su decisión.

Ejecución orientada a objetivos: define criterios de éxito y repite el proceso hasta verificar el resultado

Los tres primeros principios funcionan como barreras de protección. Limitan el comportamiento. Este principio es diferente. Desbloquea una capacidad.

Es el principio que convierte la observación de Karpathy en una ventaja práctica. Karpathy se dio cuenta de que los modelos de lenguaje son «excepcionalmente buenos repitiendo ciclos hasta alcanzar objetivos específicos».

El problema no es que los agentes no puedan iterar. El problema es que les damos instrucciones imprecisas, en lugar de objetivos verificables.

Sin este principio, dices: «Corrige el sistema de autenticación», y el agente responde:

Corregiré el sistema de autenticación mediante los siguientes pasos:

1. Revisar el código.
2. Identificar los problemas.
3. Realizar mejoras.
4. Probar los cambios.

Un plan impreciso. Sin criterios de éxito. Sin verificación. Cambiará algo y lo considerará terminado.

Con este principio, la misma solicitud se transforma:

1. Escribir una prueba: al cambiar la contraseña, la sesión anterior debe quedar invalidada.
   → Verificación: la prueba falla y reproduce el error.
2. Implementar la invalidación de sesiones cuando se cambie la contraseña.
   → Verificación: la prueba se supera correctamente.
3. Comprobar casos límite: múltiples sesiones y cambios simultáneos.
   → Verificación: las pruebas adicionales se superan.
4. Comprobar regresiones: las pruebas existentes de autenticación deben seguir funcionando.
   → Verificación: toda la suite de pruebas se ejecuta correctamente.

Cada paso contiene una comprobación. El agente puede repetir el proceso de forma independiente porque sabe cómo se ve un resultado terminado. Los criterios de éxito sólidos sustituyen la necesidad de supervisión constante.

Esto es lo que diferencia este principio de los otros tres: pensar antes de programar, priorizar la simplicidad y realizar cambios quirúrgicos son formas de disciplina. Evitan comportamientos negativos.

La ejecución orientada a objetivos es una ventaja. Desbloquea un comportamiento para el que el agente ya es bueno, pero que no se activa sin una estructura adecuada en el prompt.

Los tres primeros principios hacen que el agente resulte menos molesto. El cuarto lo hace más capaz. Y esta diferencia importa. La disciplina ofrece rendimientos decrecientes. La ventaja se acumula.

Una advertencia: estos ejemplos muestran tareas sencillas dentro de un solo archivo. Me gustaría comprobar cómo se comportan las cuatro líneas en un monorepositorio de 100 000 líneas, con varios equipos y dependencias entrelazadas.

Los proyectos de un solo desarrollador son el caso sencillo. La pregunta más difícil es si unas directrices de comportamiento pueden escalar por sí solas hasta la complejidad que tienen la mayoría de las bases de código empresariales.

La paradoja de la configuración

El instinto natural cuando un agente de IA se comporta incorrectamente es añadir más reglas.

No utilices punto y coma. Añade siempre gestión de errores. Sigue la convención de nombres del repositorio. Da prioridad a los patrones funcionales. Utiliza el modo estricto de TypeScript.

Este instinto ha producido un ecosistema de una magnitud impresionante. Un popular conjunto de herramientas de GitHub enumera 135 agentes, 35 habilidades seleccionadas, más de 400 000 habilidades disponibles en un marketplace, 176 plugins y 42 comandos.

Otro ofrece 30 agentes especializados y 136 habilidades.

Actualmente existen al menos cinco formatos de configuración que compiten entre sí:

• CLAUDE.md
• AGENTS.md
• .cursorrules
• copilot-instructions.md
• .windsurfrules

Incluso existe una herramienta para convertir reglas entre diferentes formatos.

El ecosistema cuenta con más opciones de configuración que ingenieros tienen la mayoría de los equipos.

Este es el problema: no escala de la forma que cabría esperar.

Claude Code limita cada archivo de reglas a 6 000 caracteres y el conjunto combinado de reglas a 12 000 caracteres. Esos límites existen por una razón. A partir de cierto punto, añadir reglas no produce agentes más disciplinados, sino agentes confundidos.

La propia documentación de Anthropic lo expresa claramente:

«Para cada línea, pregúntate: “¿Eliminar esta línea provocaría que Claude cometiera errores?”. Si la respuesta es no, elimínala».

Piensa en ello como la incorporación de un nuevo empleado. Puedes entregarle un manual de cincuenta páginas que cubra todos los escenarios posibles. O puedes explicarle cuatro principios que la empresa realmente aplica y confiar en que utilice su criterio.

El manual termina guardado en un cajón. Los principios se utilizan.

Esa es la paradoja de la configuración: más reglas parecen ofrecer un mayor control, pero, una vez establecida la base de comportamiento, las reglas adicionales añaden ruido que compite con la señal.

Las 55 000 estrellas no son un voto a favor del minimalismo como elección estética. Son un voto a favor de la idea de que las restricciones de comportamiento superan a las listas de funciones.

Las cuatro líneas funcionan porque determinan cómo piensa el agente, no solamente qué hace. Pueden transferirse entre proyectos, lenguajes y tipos de problemas.

Una regla como «utiliza el modo estricto de TypeScript» se aplica a una tecnología concreta. «No hagas suposiciones» se aplica a todo.

Qué debes incluir realmente en tu archivo

El camino más rápido consiste en instalar directamente el archivo desde el repositorio que inició todo esto.

Opción A: plugin de Claude Code — recomendado

Desde Claude Code, añade el marketplace e instala el plugin:

/plugin marketplace add forrestchang/andrej-karpathy-skills/plugin install andrej-karpathy-skills@karpathy-skills

Esto hace que las directrices estén disponibles automáticamente en todos tus proyectos.

Opción B: descargar directamente el archivo

Para un proyecto nuevo:

curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

Para un proyecto existente, añádelo al final de tu archivo actual:

echo "" >> CLAUDE.mdcurl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

El archivo completo amplía cada uno de los cuatro principios mediante subpuntos y ejemplos. Sin embargo, el núcleo sigue siendo esas cuatro frases. Todo lo demás son explicaciones adicionales.

Una vez establecida la base de comportamiento, añade una pequeña capa de contexto específico del proyecto. No reglas sobre cómo programar, sino contexto que el agente no puede deducir leyendo tus archivos.

Comandos de compilación

El agente necesita saber cómo ejecutar tu proyecto:

## Project- Build: `npm run build`- Test: `npm test`- Lint: `npm run lint -- --fix`

Convenciones que el código no muestra

Decisiones que no son visibles dentro del código existente:

## Conventions- API errors return { error: string, code: number }, never throw- All dates stored as UTC, displayed in user's timezone- Feature flags live in config/flags.ts, not inline

Lecciones aprendidas de errores anteriores

Recordatorios de una sola línea sobre cosas que ya provocaron problemas:

## Watch out- The payments service timeout is 30s, not the default 5s- Don't import from /internal -- it breaks the public API build

Presiona Enter o haz clic para ver la imagen en tamaño completo

Diagrama del autor: Anatomía de un archivo CLAUDE.md. Base de comportamiento más una pequeña capa específica del proyecto.

Eso es todo. La base de comportamiento obtenida del repositorio, los comandos de compilación, algunas convenciones y quizá una advertencia.

La prueba que debes aplicar a cada línea adicional que quieras incluir después de las cuatro principales es la siguiente:

«¿Eliminar esta línea provocaría que el agente cometiera un error del que no podría recuperarse?».

Si la respuesta es no, no la incluyas.

Qué NO debes incluir en el archivo

No incluyas descripciones generales de la arquitectura que el agente pueda deducir leyendo el código, guías de estilo que pueda inferir a partir de los patrones existentes, listas de dependencias que pueda encontrar en package.json ni documentación a la que ya pueda acceder desde el repositorio.

El agente lee tu base de código. No dupliques información que ya se encuentra allí.

Cuándo cuatro líneas no son suficientes

Estas directrices gestionan correctamente la capa de comportamiento. Pero el comportamiento no es la única capa.

Refactorizaciones complejas de múltiples archivos

Cuando estás reestructurando un módulo completo, moviendo funciones entre archivos y actualizando cadenas de importación, el agente necesita un contexto arquitectónico que las restricciones de comportamiento no pueden proporcionar.

«No hagas suposiciones» no será suficiente si el agente desconoce qué archivos dependen de otros.

Para las grandes refactorizaciones, debes añadir una breve sección de arquitectura a tu archivo CLAUDE.md o dividir el trabajo en tareas más pequeñas y bien delimitadas que el agente pueda gestionar una por una.

Sectores regulados

Si trabajas en sanidad, tecnología financiera o cualquier sector con requisitos de cumplimiento normativo, cuatro líneas de comportamiento no cubren reglas como «nunca registrar información personal identificable» o «todos los cambios en la API requieren una revisión de seguridad».

Las barreras de protección específicas de cada sector son una cuestión diferente de las directrices de comportamiento. Añádelas junto con las cuatro líneas, no en sustitución de ellas.

Consistencia a escala de equipo

El archivo CLAUDE.md de un solo desarrollador es relativamente sencillo. Conseguir que veinte ingenieros compartan las mismas normas de comportamiento para sus agentes es un problema de coordinación, no de configuración.

Aquí es donde formatos como AGENTS.md, que pueden incorporarse al repositorio y no dependen de una herramienta específica, empiezan a ser importantes.

Las cuatro líneas son un punto de partida para los equipos, pero estos también deben acordar qué reglas específicas del proyecto se añadirán sobre esa base.

Portabilidad entre herramientas

Estas directrices fueron escritas específicamente para Claude Code. Cursor, Copilot y Codex tienen modos de fallo similares, pero no idénticos.

Los principios pueden transferirse. «No hagas suposiciones» es un buen consejo independientemente del agente que utilices. Sin embargo, la redacción específica y el grado en que cada agente responde a ella variarán según la herramienta.

Si utilizas Cursor, tendrás que adaptar estas reglas al formato .cursorrules y comprobar si el agente las interpreta de la misma forma.

Una observación honesta adicional: las 60 000 estrellas son una señal de que la idea ha tenido repercusión, no una prueba de su eficacia.

No disponemos de estudios rigurosos que comparen el rendimiento antes y después de aplicar estas directrices y que demuestren exactamente cuánto mejoran la calidad de los resultados.

Un sitio afirma haber conseguido un 94 % de precisión con las directrices de Karpathy, pero sería necesario revisar su metodología antes de considerar esa cifra como definitiva.

Lo que sí tenemos es un fuerte consenso anecdótico procedente de una gran población de desarrolladores. Es significativo, pero no equivale a un estudio controlado.

El cuello de botella del comportamiento

Que un archivo de texto tenga 60 000 estrellas revela algo que los anuncios de producto no muestran: el cuello de botella de la programación asistida por IA nunca fue la capacidad, sino el comportamiento.

Los modelos pueden escribir código. Llevan bastante tiempo siendo capaces de hacerlo.

Lo que todavía no pueden hacer de manera fiable es decidir cuándo deben dejar de escribir, qué preguntas deben hacer antes de comenzar, cuánto código deben modificar y cómo comprobar que realmente han terminado.

Esos son problemas de comportamiento, no problemas de inteligencia. Y los problemas de comportamiento no se resuelven únicamente haciendo que el modelo sea más inteligente. Se resuelven explicándole al modelo cómo debe actuar.

Por eso cuatro frases superaron a todo un ecosistema de plugins, agentes y habilidades.

No porque ese ecosistema sea incorrecto. No lo es. Pero está intentando resolver la capa de capacidad mientras la capa de comportamiento continúa siendo la principal restricción.

Cada mejora del modelo ayuda. Sin embargo, mientras los agentes no puedan gestionar de manera fiable su propia incertidumbre, limitar el alcance de sus cambios y verificar su propio trabajo, las cuatro líneas seguirán aportando más valor por carácter que cualquier anuncio de nuevas funciones.

Esto es lo que realmente cambiaría mañana en mi flujo de trabajo: abriría mi archivo CLAUDE.md, eliminaría todas las reglas que el agente pudiera deducir leyendo la base de código, añadiría las cuatro líneas de comportamiento si todavía no estuvieran allí y evaluaría cada regla nueva que quisiera incluir mediante una sola pregunta:

«¿Esta regla determina cómo piensa el agente o solamente qué hace?».

Si solamente determina qué hace, probablemente no debería estar en el archivo.

Para profundizar más, el archivo EXAMPLES.md del repositorio contiene explicaciones completas de código antes y después de aplicar cada principio, incluidos patrones de verificación con múltiples pasos para la Línea 4.

Los modelos seguirán volviéndose más inteligentes. Las herramientas continuarán siendo más potentes. El cuello de botella seguirá siendo el comportamiento hasta que los modelos aprendan a gestionar su propio criterio.

Y, hasta que eso suceda, cuatro frases dentro de un archivo Markdown seguirán superando al ciclo constante de lanzamientos de productos.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.