Deep Modules: el Claude Code Skill que salva mi codebase

Deep Modules: el Claude Code Skill que salva mi codebase

Ejecuté la skill improve-codebase-architecture en un proyecto al que he estado enviando desde noviembre. Sonnet 4.6 pasó once minutos leyendo mi código, abrió un informe de rebajas en mi editor y enumeró seis cosas que pensaba que se estaban pudriendo silenciosamente debajo de mí.

El primero lo descarté. Con el segundo discutí. El tercero me hizo hacer una mueca de dolor, caminar hasta la cocina, servirme el café que no quería y volver a leerlo.

Había encontrado dos implementaciones paralelas del mismo concepto, una en mi interfaz y otra en mi backend, ubicadas en carpetas completamente diferentes, propiedad de modelos mentales completamente diferentes, sin una unión unificada entre ellas. Estaban a la deriva. Había enviado un error tres semanas antes cuya causa principal era exactamente esa desviación. No había conectado los dos eventos. La skill los conectó en un párrafo.

Ese es el momento en que dejé de tratar esta skill como otro repositorio GitHub y comencé a tratarla como lo único que se interpone entre yo y el código base hacia el que me dirijo si sigo enviando a la velocidad AI sin presión arquitectónica.

Si ha estado codificando en Claude Code hasta el primer trimestre de 2026 y su código base comienza a sentirse más pesado de lo que debería (lento para navegar, aterrador para refactorizar, lleno de pequeños módulos que parecen depender unos de otros de maneras que no se pueden dibujar en una pizarra), esta publicación es para usted. Las siguientes 4000 palabras tratan sobre por qué está sucediendo esto, lo que John Ousterhout descubrió hace veinte años que lo hace reparable y cómo la skill improve-codebase-architecture de Matt Pocock pone en práctica la solución dentro de Claude Code.

El coste real de shippear rápido con AI

Esto es lo que nadie pone en las páginas de marketing de codificación AI.

La razón por la que Claude Code se siente mágico en la segunda semana y pesado en el cuarto mes no es que el modelo empeore. Es que tu código base empeora, más rápido de lo que tu cerebro puede modelarlo. El software siempre ha tenido esta propiedad: Ousterhout escribió un libro completo sobre ello, A Philosophy of Software Design, al que volveré en un segundo. Pero el ritmo ha cambiado. AI no escribe código mejor ni peor en promedio que yo. Escribe código a un ritmo de cinco a diez veces mayor que yo. Tomo cada atajo arquitectónico en quince minutos en lugar de dos días, lo que significa que la entropía se compone en un calendario en el que nunca entrené mi juicio.

El nombre técnico de lo que está sucediendo es entropía de software. El nombre en forma de código es "bola de barro". La sensación, si lo ha vivido, es el momento en que abre un archivo y se da cuenta de que ya no sabe quién llama a esta función, qué devuelve cuando la entrada tiene un formato incorrecto o si cambiarlo interrumpirá el conjunto de pruebas, la producción o ambos.

Tuve ese sentimiento en el proyecto que mencioné anteriormente. No porque el código fuera malo: la mayor parte había sido revisada, la mayor parte tenía pruebas, la mayor parte se ejecutó en producción para usuarios pagos. El problema era más detallado que el "código incorrecto". El problema era que tenía treinta módulos cuando necesitaba doce. Los conceptos que pertenecían juntos se habían dividido en archivos porque en el momento en que escribí cada pieza, la división se sentía más limpia. El costo cognitivo total de esas divisiones era ahora mayor que el costo cognitivo de la duplicación que estaban evitando.

Eso es lo que acelera AI. La decisión de dividir, extraer y abstraer es barata cuando un agente puede hacerlo en veinte segundos. La decisión es tan barata que la tomo sin pensar. El resultado es un código base con forma de fractal de módulos pequeños, educados, individualmente correctos y sin centro.

Ousterhout tiene una palabra para esa forma. Él lo llama superficial. La solución también tiene un nombre: deep modules. La skill que estoy a punto de explicarles es la primera herramienta que he usado y que pone en práctica la solución sin necesidad de volver a leer trescientas páginas de un libro de diseño de software todos los viernes por la tarde.

Deep Modules frente a módulos poco profundos: en inglés sencillo

Antes de analizar la skill, necesitas el vocabulario. Una vez que lo tengas, el resultado de la skill se leerá como en inglés. Sin él, el informe parece una lista de compras refactorizada.

Un módulo es una unidad de su aplicación con un límite claro. En una aplicación React, un módulo puede ser un componente. En un servicio de Nodo, puede ser una función, una clase o una carpeta. Lo que lo convierte en un módulo no es su tamaño, es que hay un exterior y un interior, y el interior está oculto.

La interfaz es lo que alguien tiene que aprender para usar el módulo desde afuera. Firmas de funciones. Accesorios de componentes. Métodos públicos. Documentación. Definiciones de tipos. Cualquier cosa que la persona que llama tenga que cargar en su cabeza para que el módulo haga su trabajo.

La implementación es todo lo que está dentro del límite y que la persona que llama no necesita saber. Bucles, ayudas, máquinas de estado, consultas de bases de datos, reintentos: el trabajo real.

Ahora la parte que importa.

Un módulo profundo tiene una interfaz pequeña y una implementación compleja. Aprendes diez cosas sobre él y hace mil cosas por ti. El índice de apalancamiento (comportamiento accesible por unidad de interfaz aprendida) es alto. El ejemplo clásico de Ousterhout es la llamada al sistema de archivos Unix read(fd, buf, n). Tres argumentos. Décadas de complejidad del sistema operativo se esconden detrás de esto. No piensa en la geometría del disco, los cachés de páginas o la asignación de bloques. Pides n bytes. Obtienes n bytes.

Un módulo superficial tiene una interfaz que es aproximadamente tan compleja como la implementación que oculta. Aprendes diez cosas al respecto y hace once cosas por ti. O, en el peor de los casos, aprendes diez cosas sobre él y hace ocho cosas por ti, porque la interfaz filtra más de lo que contiene la implementación. El ratio de apalancamiento está cerca de uno. El módulo apenas paga el alquiler.

Aquí hay un par concreto. Quédate conmigo: este es el momento en que llega el vocabulario.

// SHALLOW: this module's interface is bigger than what it hides
export class UserAuthHelper {
  hashPassword(password: string, salt: string): Promise<string>;
  generateSalt(): string;
  verifyPasswordAgainstHash(password: string, hash: string, salt: string): Promise<boolean>;
  isPasswordStrongEnough(password: string): boolean;
  getMinimumPasswordLength(): number;
  getMaximumPasswordLength(): number;
  generateSessionToken(userId: string): string;
  validateSessionToken(token: string): { userId: string } | null;
  revokeSessionToken(token: string): Promise<void>;
}

Lees eso y ya puedes sentirlo. Para usar esto, tengo que saber sobre sales, hashes, tokens de sesión, reglas de contraseña y revocación, todos los cuales son detalles de implementación de ser autenticado. La interfaz está filtrando el interior del módulo al cerebro de cada persona que llama.

Ahora la versión profunda de lo mismo.

// DEEP: small interface, the complexity is locked inside
export class Auth {
  signIn(email: string, password: string): Promise<Session>;
  signOut(session: Session): Promise<void>;
  currentUser(session: Session): Promise<User | null>;
}

Tres métodos. Salts, hashes, generación de sesión, reglas de contraseña, revocación, caducidad, tokens de actualización: todo eso se encuentra dentro de signIn, signOut y currentUser. La persona que llama no necesita saber nada de esto. Si quiero migrar de bcrypt a argon2 el próximo mes, no habrá cambios en la persona que llama. Si quiero agregar autenticación multifactor, la interfaz sigue siendo la misma: signIn simplemente se enriquece detrás de la costura.

Ese es el movimiento que busca la skill. Cada oportunidad de profundización es, en esencia, una oportunidad de adoptar la segunda forma y cubrir la primera.

Hay un fragmento más de vocabulario que necesitas antes de continuar.

Localidad es cómo se agrupa la funcionalidad relacionada en el código base. Alta localidad significa que las cosas que cambian juntas viven una al lado de la otra. La localidad baja significa que cambiar una característica requiere editar archivos en tres carpetas que ni siquiera se conocen entre sí. El UserAuthHelper poco profundo de arriba tiene una localidad media, al menos es una clase. El error que encontré en mi proyecto tenía una localidad baja: la lógica con forma de autenticación estaba duplicada en apps/web/src/lib/session.ts y services/api/src/auth/session.go, sin tipos compartidos ni contrato obligatorio entre ellos.

La profundización generalmente mejora la localidad automáticamente. Cuando colapsas tres shallow modules en un módulo profundo, el código relacionado se mueve al mismo archivo, lo que significa que la próxima persona que lo edite (probablemente el futuro yo, a las 11 p. m., dentro de dos meses) podrá verlo todo a la vez.

Qué hace realmente la skill

La skill improve-codebase-architecture, escrita por Matt Pocock y enviada como parte de su [repositorio de skilles] de código abierto (https://github.com/mattpocock/skills), es un pequeño paquete de rebajas que remodela la forma en que Claude Code lee su repositorio. Lo instala como cualquier otra skill: colóquelo en ~/.claude/skills/ o use el comando de instalación desde README, y de ahí en adelante, cuando le pide a Claude Code que busque oportunidades de refactorización, lo hace a través de la lente de Ousterhout en lugar de heurísticas genéricas de "olor a código".

Mecánicamente, la skill hace tres cosas.

Primero, escanea el repositorio con una pregunta específica en mente: ¿dónde están agrupados los shallow modules? No busca archivos malos individuales. Busca grupos de módulos pequeños que estén estrechamente acoplados, donde cada uno tenga una interfaz casi tan compleja como su implementación, y donde puedas sentir la fricción de moverse entre ellos cuando lees el código.

En segundo lugar, produce una lista de oportunidades de profundización (generalmente entre tres y diez, según mi experiencia), cada una escrita como una propuesta breve: qué módulos fusionar, cómo debería verse la nueva interfaz, dónde viviría la costura de prueba y qué riesgos conlleva la refactorización. La propuesta debe ser leída por un ser humano, discutida y aceptada, modificada o rechazada.

En tercer lugar, cuando acepta una propuesta, la skill entra en un pase de diseño interactivo. Claude propone la nueva interfaz, usted rechaza nombres y formas, el modelo se revisa y una vez que se establece la interfaz, propone una estrategia de implementación. La estrategia incluye cómo migrar a las personas que llaman y dónde colocar el límite de prueba. Cuando das luz verde, la skill archiva un problema GitHub (o cualquier rastreador de problemas que hayas conectado) para que se realice un seguimiento del trabajo incluso si no lo haces ese día.

Las dos cosas que quiero subrayar. La skill no refactoriza tu código por sí sola. Muestra oportunidades y te ayuda a pensar. Los humanos hacen cada llamada arquitectónica. Y la skill es obstinada: prefiere específicamente menos módulos y más profundos a más módulos más pequeños. Si tu equipo tiene una fuerte preferencia cultural en la otra dirección, lucharás contra ella.

El día que lo ejecuté en mi propio repositorio

El repositorio que probé fue un panel SaaS al que he estado enviando semanalmente desde noviembre. Alrededor de 1500 confirmaciones, en su mayoría mías, ocasionalmente programadas en pares con Claude Code. TypeScript en toda la stack, React Router en la interfaz, un servicio de Nodo en la parte posterior, una base de datos Postgres debajo. Usuarios reales. Errores reales. Costo cognitivo real cada vez que lo abro.

Limpié un domingo por la mañana, preparé café y ejecuté un mensaje:

Usa la skill improve-codebase-architecture. Escanee este repositorio y produzca una lista de oportunidades de profundización, ordenadas por impacto.

Once minutos. Seis oportunidades.

Voy a repasar tres de ellos, porque los otros tres eran variaciones de los mismos patrones y de estos obtendrás la forma.

Oportunidad 1: El concepto de sesión duplicada. Esta fue la que me hizo dejar el café. La skill marcó que apps/web/src/lib/session.ts y services/api/src/middleware/session.go estaban implementando lo que parecía, semánticamente, el mismo módulo: leer la sesión, validarla, actualizar si expiró, devolver nulo si no es válido. Tenían diferentes tipos. Denominación diferente. Semántica de error diferente. La interfaz trataba silenciosamente las sesiones caducadas como "cerrar la sesión del usuario". El backend devolvió un 401. No había ningún contrato compartido entre ellos, lo que significaba que cualquier desviación entre los dos se manifestaría como un error de UX. La propuesta de la skill: definir un único módulo Session con una interfaz (escrita en un esquema compartido), una máquina de estado canónica (expresada en OpenAPI más un cliente generado) y un adaptador en cada lado que implementa la interfaz en el entorno local.

Dos adaptadores, una interfaz. Una verdadera costura. Tres semanas antes había enviado un error relacionado con la sesión. La skill no lo sabía. La skill vio la arquitectura y predijo la forma del insecto solo a partir de la arquitectura.

Oportunidad 2: El registrador fragmentado. Tenía cuatro utilidades de registro. Un contenedor console.log en la interfaz. Una configuración pino en el backend. Un asistente de "evento estructurado" para análisis. Un asistente de "intervalo de telemetría" para el rastreo. Cada uno de ellos se había añadido, por separado, en respuesta a una necesidad real. Cada uno parecía limpio de forma aislada. Juntos, significaban que cuando quería depurar el flujo de un usuario específico en la stack, tenía que leer cuatro conjuntos de registros en cuatro formatos diferentes. La propuesta de la skill: un único módulo Observability con una interfaz (event(name, payload), error(err, context), span(name, fn)) y cuatro adaptadores que se despliegan hacia los transportes existentes. Mismos sitios de llamadas. Mismas salidas. Una interfaz para aprender, cuatro implementaciones detrás. Esta fue una pura profundización: no se perdió ninguna funcionalidad, la vida de las personas que llaman se simplificó significativamente.

Oportunidad 3: Con la que discutí. La skill marcó a mis ayudantes de validación de formularios como una oportunidad de profundización. Tenía validateEmail, validatePhone, validateRequired y media docena más, cada una de las cuales era una pequeña función pura. La propuesta: colapsarlos en un único módulo Validator con un API fluido. Retrocedí. Las funciones puras suelen ser más profundas de lo que parecen: validateEmail(email) tiene una interfaz pequeña y una implementación no trivial (RFC 5322 no es amigable), y el índice de apalancamiento está bien. El contraargumento de la skill era sobre la localidad: los validadores se usaban juntos, en grupos, en cada formulario, y el código circundante tenía que importar seis funciones diferentes en lugar de una.

Después de diez minutos de ida y vuelta en el chat, admití que el argumento de la localidad era real, pero propuse un compromiso: mantener las funciones puras, agregar un módulo Form con un API fluido que las compone. El experto estuvo de acuerdo, redactó la nueva forma y archivó el asunto. Ese es el momento en que confié en esto.

Las otras tres oportunidades involucraban un módulo de estado de enrutador que había desarrollado una máquina de estado en su interior, una integración de pago que filtraba detalles de webhook en el código de la interfaz de usuario y un sistema de indicadores de funciones que silenciosamente se había convertido en tres sistemas de indicadores de funciones independientes. Los tres recibieron propuestas. Dos acepté; uno lo pospuse para el siguiente trimestre.

Costuras y adaptadores: por qué la profundización hace posibles las pruebas

Aquí está la parte de la skill que se conecta directamente con si su código base es comprobable, y la razón por la que todo esto importa más que simplemente "el código se ve mejor".

Una costura es un límite en su código donde puede sustituir uno falso por uno real sin cambiar el código circundante. Michael Feathers lo llamó así en Trabajar eficazmente con código heredado, hace veinte años, pero nunca ha sido más relevante que en 2026. La interfaz de un módulo es su costura natural. Si el módulo tiene una interfaz pequeña y limpia, puede colocar una copia falsa en el otro lado de esa interfaz para realizar pruebas. Si el módulo tiene una interfaz extensa y con fugas, cada prueba tiene que pretender ser real de doce maneras diferentes, y dejas de escribir pruebas porque duelen.

Un adaptador es la implementación concreta que vive al otro lado de la costura. El real habla con lo real: Postgres, la red, el reloj del sistema. El falso te devuelve lo que quieras para la prueba.

El ejemplo más claro, y el que uso ahora para enseñar esto a mi equipo, es el reloj del sistema.

// The interface — a one-method module
interface Clock {
  now(): Date;
}

// The real adapter
class SystemClock implements Clock {
  now() { return new Date(); }
}

// The fake adapter, for tests
class FakeClock implements Clock {
  constructor(private current: Date) {}
  now() { return this.current; }
  advance(ms: number) {
    this.current = new Date(this.current.getTime() + ms);
  }
}

Ahora cualquier código que dependa del tiempo depende de Clock, no de Date.now(). En producción se obtiene el reloj real. En las pruebas obtiene un reloj falso que puedo adelantar una hora, un día, un año. Cada prueba que escribí que dependía del tiempo solía ser inestable. Cada prueba que he escrito desde que extraje el reloj en un módulo profundo con dos adaptadores es determinista.

A la skill le encanta este tipo de refactorización. Cuando escanea un repositorio, la pregunta que hace en cada módulo es: ¿dónde iría la costura de prueba? Si la respuesta es "en ninguna parte obvia: el módulo habla directamente con la base de datos, la red, el reloj y el sistema de archivos simultáneamente", esa es una oportunidad cada vez más profunda. La solución es extraer las dependencias en módulos con sus propias interfaces y luego colocar adaptadores en cada lado. De repente, cada prueba que fue dolorosa se vuelve fácil.

Esta es la parte que se amortiza más rápido. La primera profundización que hice en el informe de skilles (el módulo de sesión) me ahorró una tarde completa la semana siguiente cuando necesitaba probar un caso límite de vencimiento de sesión. Antes de la refactorización, habría levantado una base de datos de prueba, me habría burlado de una llamada HTTP y habría orado. Después de la refactorización, creé una instancia de un adaptador de sesión falso, establecí su vencimiento hace 30 segundos y ejecuté una afirmación.

La trampa del código base heredado (y cómo evitarla)

Ahora la advertencia, porque casi cometo este error.

Si ejecuta esta skill en una base de código heredada (una con cobertura de prueba irregular, baja localidad y shallow modules en todas partes), el primer instinto es ir de arriba hacia abajo en el informe. Aproveche la mayor oportunidad de profundización, refactorice agresivamente y envíe.

No.

La razón por la que todo ingeniero senior con cicatrices en las manos tiene el mismo consejo (no refactorizar código no probado) es que shallow modules sin pruebas son exactamente los módulos donde la profundización romperá cosas que no sabía que existían. Las personas que llaman dependen del comportamiento de los indocumentados. Las cajas de borde se esconden en las grietas entre los módulos. La forma de los insectos es exactamente lo que hizo que los módulos fueran poco profundos en primer lugar.

El movimiento correcto es el poco glamoroso. Antes de profundizar, escriba pruebas de caracterización alrededor del módulo superficial existente. No pruebas unitarias. Pruebas no perfectas. Solo pruebas que precisan el comportamiento actual, incluido el comportamiento con errores, de modo que cuando profundices, tengas una manera de saber qué cambió. El libro de Feathers es la referencia canónica aquí. La skill en sí, en su README, recomienda aproximadamente el mismo flujo de trabajo para el código heredado: escribir pruebas que documenten el comportamiento actual del clúster que está a punto de profundizar, ejecutar la propuesta de profundización de la skill contra esas pruebas y usar los deltas de prueba como una función forzada para las decisiones de diseño.

Ahora sigo esta regla incluso en códigos totalmente nuevos. Si una propuesta de profundización toca un módulo que no tiene pruebas, la primera confirmación en la refactorización es la confirmación de prueba. El compromiso de profundización ocupa el segundo lugar. Me ralentiza unos veinte minutos por refactorización y me ahorra sesiones de depuración de "espera, ¿por qué el panel está en blanco ahora?" una hora más tarde. Comercio que aceptaré siempre.

¿Con qué frecuencia lo ejecuto ahora (y dónde falla)?

Ejecuto la skill todos los lunes por la mañana en mi proyecto principal y aproximadamente cada cinco días hábiles en proyectos secundarios con alta velocidad de compromiso. Esa cadencia surgió de una simple observación: en un proyecto en el que envío diariamente Claude Code, la entropía se acumula lo suficientemente rápido como para que una revisión arquitectónica semanal la detecte antes de que se congele. En un proyecto que es mayormente estable, mensualmente está bien.

El consejo de cadencia de la documentación de la skill es "cada pocos días en bases de código de rápido movimiento" y eso concuerda con mi experiencia. Si lo dejo pasar durante dos o tres semanas, el informe pasa de seis oportunidades a quince, y a los quince me canso de tomar decisiones y empiezo a ignorar el informe por completo. Seis es el número correcto para actuar.

Ahora la parte honesta: donde la skill tropieza.

Es malo con modismos específicos de un idioma. Cuando lo ejecuté en un servicio de Go, seguía proponiendo diseños en forma de clases que no encajaban con la esencia de Go. El vocabulario de módulos, interfaces y adaptadores se traduce, pero la forma de las propuestas está sesgada hacia TypeScript y Python. Si estás hablando en un idioma con una fuerte opinión propia (Go, Rust, Elixir), pasarás los primeros cinco minutos de cada propuesta traduciendo el idioma.

También es ciego al costo del tiempo de ejecución. Cada propuesta que he recibido ha sido sobre el costo cognitivo (qué tan fácil es entender el código, qué tan comprobable es la costura) y ninguna de ellas ha considerado aspectos como el diseño de la memoria, los patrones de asignación o el rendimiento de la ruta activa. Para la mayoría del código de aplicaciones, está bien. Para cualquier cosa que sea sensible al rendimiento, debes aplicar tu propio criterio.

Y el tercer tropiezo: a veces propone profundizaciones que me obligarían a reescribir el conjunto de pruebas para validarlo. La propuesta parece hermosa por sí sola, pero el costo de la migración (incluidas las pruebas que dependen de la forma actual) es mayor que el valor de la nueva forma. La skill no modela muy bien el costo de la migración. Ahora leo cada propuesta con una pregunta en la parte superior: ¿cómo es la migración? ¿El costo de la migración es menor que el apalancamiento que obtendría? La mitad de las veces, la respuesta es sí. La otra mitad, cierro el tema.

Si ha estado ejecutando skilles más antiguas como instalación de Karpathy CLAUDE.md o cualquiera de los 32 trucos diarios de Claude Code que escribí el mes pasado, esta skill se ubica claramente por encima de ellas. Los trucos hacen que el envío de Claude Code sea más rápido. La skill de arquitectura es la presión arquitectónica que evita que la velocidad pudra su código base.

La pregunta que llevo conmigo ahora

Seis semanas después de que comencé a ejecutar esta skill semanalmente, mi código base es significativamente diferente de donde estaba. No es dramáticamente más pequeño (no he eliminado tanto código), pero es significativamente más navegable. El módulo de sesión es un solo lugar. El módulo de observabilidad es un lugar. La composición del formulario tiene una única puerta de entrada. Cuando abro un archivo a las 11 p.m. para depurar algo, generalmente puedo ver el concepto completo del archivo en el que estoy, en lugar de saltar entre cuatro archivos y reconstruir la arquitectura desde la memoria.

El cambio que más importa es el que se produce antes del código base. Cuando le solicito a Claude Code que incluya una nueva función ahora, primero pienso en los módulos. ¿Dónde estará la costura? ¿Cuál es la interfaz? ¿Cómo es la versión profunda de esto? La skill me entrenó para hacer esas preguntas antes de escribir el mensaje, lo que significa que los mensajes en sí mismos producen un código que ya está más cerca de lo que propondría el siguiente escaneo de la skill.

La entropía del software es una flecha unidireccional sin presión arquitectónica. AI acaba de hacer que la flecha se mueva más rápido. La solución no es más lenta AI. La solución es más presión, aplicada antes, por algo que aumenta con la tarifa de envío. La skill improve-codebase-architecture es lo más parecido que he encontrado a esa presión y es la única herramienta de revisión arquitectónica en mi flujo de trabajo que ha sobrevivido más allá del primer mes.

Si toma algo de esta publicación, tome la pregunta que ahora llevo a cada sesión de Claude Code: ¿es este módulo más profundo o menos profundo que lo que reemplaza? Pregúntelo antes de escribir el mensaje. Pregúntalo de nuevo cuando leas la diferencia. Pregúntelo los lunes por la mañana, con café, mientras un pequeño archivo de rebajas escanea su repositorio y le dice las cosas que ya sabía a medias pero que estaba demasiado cansado para afrontar.

Esa pregunta hace más por mi código que cualquier skill, marco o herramienta de refactorización que haya instalado en los últimos dos años. La base de código a la que enviará en 2027 será la base de código que esa pregunta creó, o la que no construyó.

Abra el informe. Lee las seis cosas. Elige uno.

Preguntas frecuentes

¿Qué es la skill improve-codebase-architecture en Claude Code?

Es una skill de código abierto de Matt Pocock que escanea un repositorio en busca de shallow modules y propone refactorizaciones más profundas. Se ejecuta dentro de Claude Code, produce una lista de oportunidades de arquitectura y le ayuda a diseñar de forma interactiva las nuevas interfaces. Para ver el tutorial completo de lo que encontré en mi repositorio, consulte "El día que lo ejecuté en mi propio repositorio" más arriba.

¿Qué es un módulo profundo en diseño de software?

Un módulo profundo es aquel con una interfaz simple y una implementación compleja, por lo que quien llama aprende muy poco sobre el módulo pero obtiene mucho comportamiento a cambio. El término proviene de A Philosophy of Software Design de John Ousterhout. Los módulos superficiales, por el contrario, tienen interfaces casi tan complejas como sus implementaciones y proporcionan un bajo apalancamiento.

¿Con qué frecuencia debo ejecutar la skill de arquitectura de base de código?

Cada pocos días en bases de código de rápido movimiento con confirmaciones diarias asistidas por AI, y semanal o mensualmente en repositorios más estables. Después de tres semanas de silencio, el informe crece a más de diez oportunidades y comienza la fatiga por tomar decisiones. Seis oportunidades por semana es el punto ideal para actuar de acuerdo con las propuestas.

¿La skill refactoriza el código automáticamente?

No, y eso es deliberado. Muestra oportunidades cada vez más profundas y le ayuda a diseñar la nueva interfaz y la unión, pero los humanos hacen cada llamada arquitectónica y aprueban cada cambio. Una vez que acepte una propuesta, puede presentar un problema GitHub para realizar un seguimiento de la refactorización.

¿Debería profundizar los módulos en un código base heredado sin pruebas?

No directamente. Primero escriba pruebas de caracterización alrededor del grupo poco profundo para determinar el comportamiento existente y luego profundice con las pruebas como su red de seguridad. Profundizar en shallow modules no probado es una de las formas más rápidas de realizar una regresión.

Trabajemos juntos

¿Quiere crear sistemas AI, automatizar flujos de trabajo o ampliar su infraestructura tecnológica? Me encantaría ayudar.

• Fiverr (comstackciones e integraciones personalizadas): fiverr.com/s/EgxYmWD
• Cartera: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y marca): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io