Cómo funciona Claude Code en bases de código grandes: buenas prácticas y por dónde empezar

• Claude Code lee directamente la base de código viva desde la máquina del desarrollador mediante exploración del sistema de archivos y usando grep y seguimiento de referencias, sin subir índices
• El rendimiento depende en gran medida no solo del modelo, sino también del harness compuesto por CLAUDE.md, hooks, skills, plugins y servidores MCP, además del orden en que se construye
• En repositorios grandes, un CLAUDE.md liviano y jerárquico, empezar desde subdirectorios, pruebas y lint con alcance acotado, y reglas de exclusión mejoran la eficiencia de exploración
• La integración con LSP ofrece seguimiento de definiciones y referencias basado en símbolos en lugar de búsqueda por cadenas, reduciendo exploraciones erróneas en bases de código multilenguaje y de gran tamaño
• Para una adopción exitosa, se necesita revisar la configuración cada 3 a 6 meses y contar con un DRI o agent manager que administre plugins, permisos y reglas

---

Cómo navega Claude Code en bases de código grandes

• Claude Code recorre el sistema de archivos como lo haría un ingeniero de software: lee archivos, busca lo necesario con grep y sigue referencias a lo largo de toda la base de código
• Funciona localmente en la máquina del desarrollador, sin necesidad de construir, mantener ni subir a un servidor un índice de la base de código
• Las herramientas de programación con IA basadas en RAG incrustan toda la base de código y recuperan fragmentos relevantes al momento de la consulta, pero en entornos grandes el pipeline de embeddings puede no seguir el ritmo de un desarrollo muy activo
• Si el índice refleja el estado de hace semanas, días o incluso horas, puede devolver funciones ya renombradas o módulos eliminados en el sprint pasado, sin siquiera indicar que esa información está desactualizada
• La búsqueda agentic de Claude Code permite que cada instancia del desarrollador trabaje sobre la base de código viva sin depender de un pipeline de embeddings ni de un índice centralizado
• También tiene una desventaja: funciona mejor cuando hay suficiente contexto inicial para que Claude sepa dónde mirar
• Si se le pide encontrar todas las instancias de un patrón ambiguo dentro de una base de código de mil millones de líneas, puede chocar con el límite de la ventana de contexto antes incluso de empezar el trabajo
• Los equipos que configuran bien su base de código y estratifican el contexto con archivos CLAUDE.md y skills obtienen mejores resultados

Un harness tan importante como el modelo

• El rendimiento de Claude Code depende en gran medida, más que del modelo en sí, del harness construido a su alrededor
• El harness se compone de cinco puntos de extensión: CLAUDE.md, hooks, skills, plugins y servidores MCP
• Como cada capa se construye sobre la anterior, también importa el orden en que el equipo la implementa
• La integración con LSP y los subagents funcionan como capacidades adicionales que complementan esta configuración

• Archivo CLAUDE.md

  • CLAUDE.md es un archivo de contexto que Claude lee automáticamente al inicio de cada sesión
  • El archivo raíz contiene la visión general, y los archivos en subdirectorios contienen reglas locales
  • Como se carga en todas las sesiones, debe centrarse en lo que aplica de forma amplia para evitar degradación de rendimiento

• Hooks

  • Los Hooks no solo sirven como scripts para impedir comportamientos incorrectos de Claude; su mayor valor está en mejorar la configuración de forma continua
  • Un stop hook puede revisar lo ocurrido en la sesión y sugerir actualizaciones a CLAUDE.md mientras el contexto aún está fresco
  • Un start hook puede cargar dinámicamente contexto específico del equipo para que cada desarrollador reciba la configuración adecuada para su módulo sin tener que configurarla manualmente
  • Las verificaciones automáticas, como linting y formatting, dan resultados más consistentes cuando la regla se hace cumplir de forma determinista con un hook que cuando se intenta que Claude simplemente recuerde la instrucción

• Skills

  • Las Skills permiten mantener experiencia especializada on-demand sin inflar todas las sesiones
  • Una base de código grande puede tener decenas de tipos de tareas, pero no hace falta incluir toda esa especialización en cada sesión
  • A través de la divulgación progresiva (progressive disclosure), las Skills mantienen workflows especializados y conocimiento de dominio fuera del espacio de contexto y los cargan solo cuando hacen falta
  • Por ejemplo, una skill de revisión de seguridad se carga cuando Claude evalúa vulnerabilidades, mientras que una skill de documentación se carga cuando hay que actualizar docs después de cambiar código
  • Las Skills pueden delimitar su alcance a rutas específicas, de modo que una skill de despliegue del equipo de servicios de pago quede vinculada solo a ese directorio y no se cargue automáticamente al trabajar en otras áreas del monorepo

• Plugins

  • Los Plugins son el medio para distribuir una configuración que funciona bien y evitar que quede como conocimiento tácito
  • Un plugin agrupa skills, hooks y configuración MCP en un solo paquete instalable
  • Si un nuevo ingeniero instala el plugin en su primer día, obtiene de inmediato el mismo contexto y las mismas capacidades que quienes ya usaban Claude
  • Las actualizaciones de plugins pueden desplegarse a toda la organización mediante managed marketplaces
  • Una gran organización minorista creó una skill que conectaba Claude con su plataforma interna de análisis para que los analistas de negocio pudieran consultar datos de rendimiento sin salir de su workflow, y luego la distribuyó como plugin antes de un despliegue más amplio en toda la empresa

• Integración con Language Server Protocol

  • La integración con Language Server Protocol (LSP) permite que Claude tenga la misma capacidad de navegación de código que el IDE del desarrollador
  • La mayoría de los IDE para bases de código grandes ya ejecutan LSP para habilitar “go to definition” y “find all references”
  • Al exponer eso a Claude, se obtiene precisión a nivel de símbolo para seguir llamadas de función hasta su definición, rastrear referencias entre archivos y distinguir funciones con el mismo nombre en lenguajes distintos
  • Sin LSP, Claude depende de coincidencias de patrones de texto y puede terminar en el símbolo equivocado
  • Una empresa de software empresarial desplegó la integración con LSP en toda la organización antes de adoptar Claude Code, con el fin de estabilizar la navegación en C y C++ a gran escala
  • Es una de las inversiones de mayor valor en bases de código multilenguaje

• Servidores MCP

  • Los servidores MCP son la forma en que Claude se conecta con herramientas internas, fuentes de datos y APIs a las que no puede acceder directamente
  • Los equipos más maduros construyen servidores MCP que exponen búsquedas estructuradas como herramientas que Claude puede invocar directamente
  • Otros equipos conectan Claude con documentación interna, sistemas de tickets y plataformas de analítica

• Subagents

  • Los Subagents separan la exploración de la edición
  • Un subagent es una instancia aislada de Claude con su propia ventana de contexto, que recibe una tarea, la ejecuta y devuelve solo el resultado final al agente padre
  • Después de tener listo el harness, algunos equipos lanzan subagents de solo lectura para mapear subsistemas y escribir los resultados en archivos, dejando que el agente principal edite con base en la visión completa

• Rol de cada componente y confusiones comunes

  • CLAUDE.md: archivo de contexto que Claude lee automáticamente y que se carga en todas las sesiones. Es adecuado para reglas por proyecto y conocimiento de la base de código, pero es fácil meter aquí experiencia reutilizable que debería ir en una skill
  • Hooks: scripts que se ejecutan en momentos clave y se activan por eventos. Son adecuados para automatizar comportamientos consistentes y capturar aprendizajes de las sesiones, pero es fácil intentar resolver con prompts cosas que deberían ejecutarse automáticamente
  • Skills: instrucciones empaquetadas para tipos de tareas específicos y que se cargan on-demand cuando son relevantes. Son adecuadas para experiencia reutilizable entre sesiones y proyectos, pero es fácil meter todo en CLAUDE.md
  • Plugins: paquetes de skills, hooks y configuración MCP, disponibles siempre después de configurarse. Son adecuados para distribuir configuraciones que funcionan a toda la organización, pero es fácil dejar una buena configuración como conocimiento tácito
  • LSP: inteligencia de código en tiempo real a través de servidores por lenguaje, siempre disponible una vez configurado. Es adecuado para navegación a nivel de símbolo en lenguajes tipados y detección automática de errores, pero es fácil asumir que vendrá funcionando por defecto
  • Servidores MCP: conexiones con herramientas y datos externos, siempre disponibles una vez configurados. Son adecuados para acceso a herramientas internas a las que Claude no puede acceder directamente, pero es fácil empezar construyendo la conexión MCP antes de que lo básico funcione
  • Subagents: instancias separadas de Claude para tareas específicas, que se ejecutan al invocarse. Son adecuados para separar exploración y edición, y para trabajo en paralelo, pero es fácil intentar hacer ambas cosas en la misma sesión
  • Se accede a LSP a través de la capa de plugins, mientras que los subagents no son un punto de extensión configurado, sino una capacidad de delegación

Tres patrones de configuración que se repiten en despliegues exitosos

• Hacer que la base de código sea navegable incluso a gran escala

  • El alcance en el que Claude puede ayudar en una base de código grande está limitado por su capacidad de encontrar el contexto correcto
  • Cargar demasiado contexto en todas las sesiones degrada el rendimiento; cargar muy poco hace que Claude navegue a ciegas
  • Los despliegues efectivos invierten al principio en hacer que la base de código sea fácil de leer para Claude

  • Mantener los archivos CLAUDE.md livianos y jerárquicos

    • Claude carga de forma acumulativa los archivos CLAUDE.md mientras se desplaza por la base de código
    • El archivo raíz se encarga de la visión general, y los archivos en subdirectorios de las reglas locales
    • El archivo raíz debería contener solo punteros y advertencias críticas; cualquier otra cosa tiende a convertirse en ruido

  • Empezar desde subdirectorios, no desde la raíz del repositorio

    • Claude funciona mejor cuando su alcance se limita a la parte de la base de código realmente relacionada con la tarea
    • En monorepos, esto puede parecer contraintuitivo, ya que muchas herramientas asumen acceso desde la raíz
    • Claude sube automáticamente por el árbol de directorios y carga todos los archivos CLAUDE.md que encuentra, por lo que el contexto a nivel raíz no se pierde

  • Acotar por subdirectorio los comandos de prueba y lint

    • Si Claude cambia solo un servicio pero ejecuta toda la suite de pruebas, puede terminar en timeout y desperdiciar contexto en salida irrelevante
    • Los archivos CLAUDE.md en subdirectorios deben especificar los comandos que aplican a esa parte de la base de código
    • Esto funciona bien en bases de código orientadas a servicios donde cada directorio tiene sus propios comandos de pruebas y build
    • En monorepos de lenguajes compilados con dependencias profundas entre directorios, acotar por subdirectorio es más difícil y puede requerir configuración de build por proyecto

  • Excluir archivos generados, artefactos de build y código de terceros con archivos .ignore

    • Si se versionan reglas permissions.deny en .claude/settings.json, las reglas de exclusión quedan bajo control de versiones
    • Todos los desarrolladores del equipo obtienen la misma reducción de ruido sin configuración adicional
    • En algunas bases de código, los propios archivos generados pueden ser parte del trabajo de desarrollo
    • Quienes trabajan con generadores de código pueden sobrescribir localmente las reglas de exclusión a nivel proyecto sin afectar al resto del equipo

  • Construir un mapa de la base de código si la estructura de directorios no basta

    • En organizaciones donde el código no está integrado en una estructura de directorios convencional, puede ayudar un archivo Markdown liviano en la raíz
    • Una línea de descripción para cada carpeta de nivel superior y lo que contiene sirve como tabla de contenido que Claude puede revisar antes de abrir archivos
    • Si hay cientos de carpetas de nivel superior, funciona mejor un enfoque jerárquico: el archivo raíz describe solo la estructura de más alto nivel y los CLAUDE.md de subdirectorios aportan el siguiente nivel de detalle on-demand
    • En casos más simples, se puede lograr el mismo efecto mencionando con @ archivos o directorios específicos que Claude deba consultar

  • Buscar por símbolos con servidores LSP, no por cadenas

    • Si se hace grep de un nombre de función común en una base de código grande, pueden aparecer miles de coincidencias y Claude consumirá contexto abriendo archivos para decidir qué importa
    • LSP devuelve solo referencias que apuntan al mismo símbolo, así que el filtrado ocurre antes de que Claude tenga que leer nada
    • Para configurarlo, hay que instalar el code intelligence plugin del lenguaje correspondiente y el binario del language server
    • La documentación de Claude Code incluye los plugins disponibles y cómo resolver problemas

  • Excepciones

    • Incluso el enfoque jerárquico con CLAUDE.md tiene casos límite donde puede fallar
    • Eso incluye bases de código con cientos de miles de carpetas y millones de archivos, o sistemas legacy bajo control de versiones distinto de Git

• Dar mantenimiento a los archivos CLAUDE.md conforme cambia la inteligencia del modelo

  • A medida que los modelos mejoran, instrucciones escritas para el modelo actual pueden volverse un obstáculo para modelos futuros
  • Las reglas de CLAUDE.md que antes guiaban a Claude en patrones difíciles pueden dejar de ser necesarias o incluso volverse una restricción en modelos nuevos
  • Por ejemplo, una regla que obligue a dividir toda refactorización en cambios de un solo archivo pudo haber ayudado a un modelo anterior a no perder el hilo, pero puede impedir ediciones coordinadas de múltiples archivos que un modelo nuevo sí maneja bien
  • Las skills y hooks creados para compensar una limitación específica del razonamiento del modelo o de las herramientas de Claude Code se vuelven sobrecarga una vez que esa limitación desaparece
  • Un hook que interceptaba escrituras de archivos para forzar p4 edit en una base de código con Perforce se vuelve redundante después de que Claude Code añade un modo nativo para Perforce
  • Los equipos deberían prever una revisión importante de la configuración cada 3 a 6 meses
  • También vale la pena revisar la configuración cuando, tras una gran actualización del modelo, el rendimiento parezca haberse estancado

• Asignar ownership de la administración y adopción de Claude Code

  • La adopción no ocurre solo con la configuración técnica
  • Los despliegues que se difundieron más rápido habían hecho inversión en infraestructura antes de dar acceso amplio
  • Un equipo pequeño, a veces una sola persona, conectó las herramientas para que, cuando los desarrolladores probaran Claude por primera vez, ya funcionara de acuerdo con su workflow
  • En una empresa, algunos ingenieros construyeron desde el primer día un paquete de plugins y MCP utilizable
  • En otra, un equipo dedicado a administrar herramientas de programación con IA preparó la infraestructura antes del rollout
  • Este trabajo suele quedar dentro de organizaciones de experiencia del desarrollador o productividad del desarrollador, que también se encargan del onboarding de nuevos ingenieros y de construir herramientas internas
  • En varias organizaciones está apareciendo el rol de agent manager, una función híbrida entre PM e ingeniería para administrar el ecosistema de Claude Code
  • Si no existe un equipo dedicado, la forma mínima viable es contar al menos con un DRI
  • Ese DRI debe tener ownership sobre la configuración de Claude Code, los criterios de configuración, las políticas de permisos, el plugin marketplace y las reglas de CLAUDE.md, además de mantener todo actualizado
  • La adopción bottom-up genera entusiasmo, pero puede fragmentarse si nadie centraliza lo que realmente funciona
  • Se necesita una persona o equipo que recopile y difunda convenciones de Claude Code, como una jerarquía estandarizada de CLAUDE.md o un conjunto curado de skills y plugins
  • Sin ese trabajo, el conocimiento sigue siendo tácito y la adopción se estanca

Gobernanza y rollout

• En organizaciones grandes, especialmente en industrias reguladas, las preguntas de gobernanza aparecen temprano
• Entre los temas clave están quién controla qué skills y plugins pueden usarse, cómo evitar que miles de ingenieros reconstruyan lo mismo por su cuenta y cómo garantizar que el código generado por IA pase por el mismo proceso de revisión que el código escrito por personas
• Al principio, se recomienda un enfoque que empiece con un conjunto definido de skills aprobadas, procesos obligatorios de code review y acceso inicial limitado, para luego ampliar a medida que crece la confianza
• Los despliegues más fluidos se dieron en organizaciones que formaron desde temprano un grupo de trabajo multifuncional con representantes de ingeniería, seguridad de la información y gobernanza, para definir juntos los requisitos y el roadmap del rollout

Supuestos y límites al aplicarlo en la organización

• Claude Code está diseñado principalmente para entornos tradicionales de ingeniería de software donde los ingenieros son los principales contribuidores a la base de código, el repositorio usa Git y el código sigue una estructura de directorios estándar
• La mayoría de las bases de código grandes encajan en este marco, pero motores de juego con grandes activos binarios, entornos de control de versiones no tradicionales y entornos donde personas no técnicas contribuyen a la base de código requieren trabajo adicional de configuración
• Los patrones presentados parten de una configuración tradicional y han funcionado en distintos entornos de clientes
• La complejidad restante debe evaluarse según la base de código, las herramientas y la estructura organizacional de cada empresa
• El equipo de Applied AI de Anthropic colabora directamente con equipos de ingeniería para traducir estos patrones a las necesidades específicas de cada organización

[GN⁺]

Comentarios de Hacker News

• La frase de que explora la base de código “como un ingeniero de software” y la conclusión parecen no cuadrar
  El autocompletado o el LSP se usan siempre y son útiles; ¿eso no es también una especie de índice? También me pregunto por qué Claude no puede usar algo así
  Los ingenieros de software también recuerdan la base de código, y eso en la práctica se parece mucho a RAG; además, hay mucha memoria muscular para encontrar el archivo necesario con CMD+P y autocompletado
  No hace falta que sea en tiempo real para toda la base de código que miles de ingenieros cambian al mismo tiempo; basta con ver bien la rama en la que estoy trabajando
  Rara vez se explora una base de código recorriendo el sistema de archivos desde el principio; normalmente solo pasa con una base nueva, y ni siquiera en ese caso diría que sea la mejor experiencia

  • Es exactamente igual a cómo trabajo yo
    Aprendí a navegar bases de código grandes desde antes de que existiera el LSP, y durante mucho tiempo usé vim y grep para encontrar archivos relacionados
    Cuando probé Claude Code por primera vez el año pasado, sentí algo como “¿qué es esto?, está haciendo exactamente lo que yo iba a hacer”
  • La respuesta está en la introducción del artículo
    Claude Code parte de la premisa de que se usa en monorepos de millones de líneas, sistemas legacy de décadas y arquitecturas distribuidas repartidas en decenas de repositorios
    Por eso está optimizado para el caso general de usar herramientas robustas que funcionen en cualquier parte, especialmente en bases de código grandes y desordenadas
    Aun así, también es cierto que en repositorios pequeños y bien organizados se pueden y se deben usar herramientas mejores
    Al menos Codex funciona así y, por ejemplo, usa go doc antes de hacer grep
  • En bases de código realmente grandes, grep y find se agotan por timeout
    Si trabajas a esa escala, enseguida notas que Claude no usa las herramientas que construyeron para hacer posible la búsqueda
  • Hay muchas expresiones plausibles en un párrafo corto, pero en realidad parece más una afirmación cargada de esperanza
    Lo de “como un ingeniero de software” solo es cierto en parte
    Las personas también usan búsqueda de símbolos, pero buscan símbolos que ya recuerdan dentro de un contexto de trabajo específico
    La forma en que Claude Code ahora explora símbolos a lo bruto es distinta de cómo trabaja un ingeniero
    Un solo typo puede hacer que el agente decida que tiene que reimplementar algo y, aunque por suerte lea el archivo correcto, puede alucinar con facilidad
    Tampoco es así como se trabaja en bases de código grandes
    La parte de “encontrar exactamente lo que necesitas con grep” me choca especialmente
    Para usar grep tienes que saber qué vas a buscar, y si salen miles de resultados hay que revisarlos todos
    Cuando pasa eso, una persona no se pone a revisar la salida de forma bruta, sino que piensa cómo acotarla
    El enfoque del artículo se siente más como una explicación para justificar la forma actual de hacer las cosas que como una recomendación sólida
    También es cierto eso de que “no hace falta indexar la base de código”, pero solo en el sentido de que tarde o temprano encuentras la respuesta inflando el contexto con grep-read-grep
    Suena parecido a decir “Claude Code no hace falta porque un desarrollador puede implementarlo por sí mismo”
    Creo que ese mensaje de “no hace falta” está mal porque transmite a la comunidad una decisión como si fuera un absoluto
    En general, sí es honesto sobre el costo organizacional
    Dice que en varias organizaciones están apareciendo roles de “agent manager”, una mezcla de PM e ingeniero, para administrar el ecosistema de Claude Code, y que los equipos deberían hacer revisiones de configuración significativas cada 3 a 6 meses
    Eso muestra con bastante precisión la realidad de usar Claude Code a gran escala sin una capa de inteligencia de código preconstruida
    La dirección parece correcta, pero al terminar de leer queda la sensación de “no resolvimos el problema y este es nuestro límite”
  • Incluso si exploras una parte de la base de código desde cero, hay zonas que nunca cambian, y volver a explorarlas cada vez es un desperdicio de tokens enorme
    Uno de los puntos en los que más discuto con Claude es en hacer que explore mucho menos
    Yo conozco mejor y más rápido las cosas que casi no cambian que repasarlas de una forma lenta y cara
    Y aun así siempre se mete en el mismo tipo de madriguera

• Como anécdota, estaba diseñando un proyecto para onboarding y orquestación con LLM, y Claude eligió leer solo las primeras 40 líneas de cada archivo
  Más tarde, en otra sesión, Claude, buscando la causa de una baja calidad, detectó ese defecto y cambió el código para hacer análisis AST usando como entrada las líneas de documentación y las entradas/salidas de las firmas de funciones
  El enfoque inicial de Claude fue realmente muy malo
  Eso me hace preguntarme cuánto hay que corregir y revisar Claude Code para que llegue a ser bueno, o si siquiera puede producir buen código desde el principio
  Generalizando, Claude sí puede corregir malas decisiones locales e identificables, como “leer solo las primeras 40 líneas”
  Porque el defecto está aislado y se puede rastrear hasta una pieza de código concreta
  Pero los problemas reales de calidad de software muchas veces surgen cuando pequeñas decisiones razonables por separado se combinan para producir un mal resultado
  En esos casos ninguna es un “defecto” obvio por sí sola, así que una herramienta que genera por partes componentes de baja calidad puede no converger en buen código, porque cada pieza por separado parece aceptable

  • Parece que fue entrenado para mirar el código fuente por un agujero estrecho con tal de conservar contexto
    En estos casos podría encajar bien una lógica subordinada o subagentes completos
    Por ejemplo, podrías asignarle a un subagente algo como: “revisa este archivo y resúmelo, marcando las partes relacionadas con X e Y; luego yo lo veo desde el contexto principal”
    También se le podría poner a observar periódicamente el flujo de trabajo principal y hacer una intervención si concluye que algo dentro del archivo en el que está pensando se relaciona con la tarea actual o podría cambiar la dirección

• ¿Cómo funciona Claude Code en bases de código grandes? Fácil
  Incluso en proyectos pequeños, se come hasta 35% del límite de uso de 5 horas en el primer prompt, y si no responde rápido dentro de 5 minutos se pierde la caché, así que en el siguiente prompt vuelve a cobrarte otro 12–15%

  • El artículo enlazado explica cómo evitar eso
    Si lo sueltas de manera ingenua en una base de código grande, sí, va a quemar muchos tokens mientras busca

• ¿No debería Claude Code inspeccionar la base de código y generar automáticamente un arnés efectivo?
  He definido CLAUDE.md, AGENTS.md, skills y plugins, pero no estoy obteniendo el nivel de efectividad que otras personas dicen tener
  Por ejemplo, aunque haya un plugin LSP, Claude Code no usa el renombrado de símbolos del LSP y en cambio edita archivos uno por uno lentamente, o aunque en el prompt diga explícitamente que invoque un skill cuando aparezca cierta pista, no lo invoca
  ¿Lo estaré usando mal? Me pregunto si existe algún ejemplo sólido de arnés que se pueda copiar y usar

  • Este es un punto de dolor de hace años y sigue sin resolverse para nada
    Aunque le digas “si A, haz X. Haz B, C, D. Haz A”, simplemente no usa X
    Es porque “lo olvidó”
    No puedes confiar en que el tiempo invertido en crear reglas vaya a tener recompensa; de hecho, sí puedes confiar en que en algún momento va a fallar
    RAG, los arneses y los skills prometieron arreglar esto, pero en la práctica no lo arreglaron
  • Dejé de usar /init y de tener archivos CLAUDE.md o AGENTS.md que describieran la base de código
    Lo único que dejé fue cómo explorar la base de código y que use git log al investigar, aunque probablemente esto también sea redundante
    Yo tampoco sé la respuesta
    La base de código en la que trabajo tiene alrededor de 100 mil líneas, no sé si eso cuenta como grande, pero personalmente es el repositorio más grande en el que he trabajado
  • En algunos casos, los hooks con scripts parecen funcionar para meter información en la ventana de contexto
    Tuve que eliminar algunos mensajes innecesarios del linter para limitar el contexto
    También ayudan linters o verificadores específicos por lenguaje que se puedan instalar desde el repositorio de paquetes del sistema operativo e invocar desde scripts
    La combinación del modelo con el contexto del skill también puede marcar diferencia
    Un skill que “funcionaba” en 4.6 puede no encajar bien en 4.7; 4.7 necesita instrucciones más explícitas, pero es relativamente más estable que 4.6
    Actualizar el skill también puede ayudar, y conviene comparar pruebas y ejecución antes y después
    Claude Code también mete en el contexto llamadas de herramientas innecesarias, así que, por ejemplo, si le gustan los beads, quizá tengas que restringir la tarea

• No estoy de acuerdo con la afirmación sobre indexar la base de código
  En PHPStorm u otros IDE de JetBrains, el indexado funciona bastante bien

  • El indexado de PHPStorm es increíble
    Muy rara vez se me ha corrupto, pero fue fácil de arreglar, y nunca he recibido resultados desactualizados
    Si has usado las herramientas de búsqueda de Claude, no te sorprenderá que ese equipo no sepa nada de indexado
    No entiendo cómo una empresa cuyo producto principal es un chat basado en texto hace que para el usuario sea difícil buscar texto dentro de ese chat
  • Claude Code puede usar ese índice mediante el MCP de JetBrains
  • Es una afirmación rara
    ¿Es texto basura generado por IA? GitHub Copilot también tiene un índice local bastante bueno
    Meter código en una base de datos vectorial no es un problema tan difícil

• Está clarísimo que este artículo lo escribió Claude
  Tiene mucho relleno y muy poca sustancia real

• Me parece rara la frase de que incluye lenguajes como C, C++, C#, Java y PHP, que los equipos no siempre asocian con herramientas de programación con IA
  ¿Por qué habría que asumir que Claude Code no funcionaría bien con esos lenguajes? ¿Qué lenguajes se supone que uno debería imaginar, Python y JavaScript?

• En una industria donde el panorama cambia no en semanas sino en meses, me parece interesante que haya pasado suficiente tiempo como para que aparezcan patrones claros y que esos patrones hayan sido exitosos en bases de código grandes
  ¿Cuál es el criterio de éxito? ¿No borrar la base de datos de producción? ¿Aumentar la velocidad del equipo? ¿Alargar la vida útil de la base de código? ¿Hacer más feliz al equipo de operaciones?

  • Si una herramienta de IA borró la base de datos de producción, quiero seguir diciendo que eso es un fracaso tuyo y de tu organización por haber dado a los desarrolladores permisos de producción capaces de borrar recursos operativos
    Nunca he trabajado en una empresa donde te dieran un nivel tan descontrolado de acceso

• Últimamente todo mi estrés viene de que Claude Code no sigue instrucciones, y mientras más grande es la base de código, peor se vuelve
  No quiero que se malinterprete: Claude es impresionante y me encanta
  Pero no hay forma de contratar solo a Claude Code para mantener la base de código o añadir funcionalidades
  Sigo agregando entradas de memoria sobre errores pasados, pero el problema de ignorar instrucciones importantes sigue ocurriendo con una probabilidad de alrededor del 90%
  La única forma de evitarlo es vigilar cada tarea de cerca y revisar muchísimo el resultado
  Claude Code es excelente para documentación o para entender bases de código grandes, pero es débil para cambios que requieren comprender el conjunto
  Por ejemplo, en toda la base de código hay como 10 patrones de registro usados para varias entidades; aunque había una regla explícita de “usa este único patrón de registro”, Claude Code implementó por separado 4 registros independientes para cada entidad
  Me pasé medio día casi gritándole a Claude Code para que acertara con esta tarea simple y al final lo corregí yo mismo para ahorrar estrés y tiempo

• Ni siquiera explican en términos concretos qué debe ir exactamente en cada archivo CLAUDE.md, así que no sé qué tan importantes son realmente esos archivos

  • Pescado: se puede leer aquí https://code.claude.com/docs/en/best-practices#write-an-effe...
    Técnica de pesca: 1) instala el skill-creator oficial 2) usa el enlace de arriba para crear claude-md-improver 3) haz que investigue el tema progressive-disclosure en la documentación oficial para mejorar el skill 4) aplica el nuevo skill al archivo CLAUDE.md y acepta los cambios