Mon usine logicielle à l'heure de l'IA

Puntos clave

1. Fecha / fuente. 28 de julio de 2026, eventuallycoding.com, Hugo Lassiège. Una página de referencia reconocida como tal, que describe el dispositivo con el que el autor ejecuta en producción sus propios productos, en solitario.
2. Planteamiento clave. esto no es vibe coding — «El vibe coding tal como lo definió Karpathy era experimentación y dejarse llevar. Aquí voy a hablar de context engineering». Con la cláusula de responsabilidad: «Aunque no escriba el código, soy responsable de él y debo mantener el control sobre él». ### La grilla de las tres preguntas Todo el conjunto de herramientas responde a tres preguntas, y esta es la contribución más reutilizable del texto: | Pregunta | Qué la responde | |---|---| | ¿Qué sabe el agente? | contexto, memoria, grafo de código | | ¿Qué sabe hacer de forma determinista? | skills, procedimientos | | ¿Qué lo detiene cuando se equivoca? | hooks, tests de arquitectura, quality gates | Planteada ante un dispositivo agéntico, revela cuál de las tres está vacía. Principio rector asociado: «Lo que importa debe ser ejecutable. Una instrucción se sigue 'la mayoría de las veces', pero puede olvidarse. Un hook o un test se sigue siempre». Y sobre los tests de arquitectura: «no se puede eludir, a diferencia de una regla». ### Las seis capas | # | Capa | Contenido | |---|--------|---------| | 1 | Contexto | CLAUDE.md raíz breve y permanente (arquitectura, convenciones, índice de specs); .claude/rules/.md condicionales activados vía frontmatter paths:; .agents/.md para asuntos no técnicos (posicionamiento, personas, tono) | | 2 | Skills | una treintena, seis familias; criterio de existencia: la tercera repetición | | 3 | Herramientas | MCP del IDE de JetBrains, GitNexus (grafo de código), Claude-mem, Sentry, base de datos de solo lectura | | 4 | Guardrails | hooks del harness, tests de arquitectura, linting de patrones (ast-grep) | | 5 | Fábrica | quality gate bloqueante, cinco etapas de pruebas | | 6 | Proceso de producto | specs numeradas, skill de redacción y skill de cierre, feature flags | Capa 1 — el contexto permanente lleva el índice, no el contenido: la regla, vista en su totalidad, es una tabla de enrutamiento que enumera nueve skills junto con la tarea que las activa. «Si la IA no está haciendo un cambio de esquema, no tiene sentido abrir la skill db-migration». Capa 2 — las skills de «procedimiento multiarchivo» son las más rentables: «añadir un bloque al editor de contenido toca tres superficies de renderizado; sin una skill, el agente olvida sistemáticamente una». Matiz: «Esta carga automática a veces puede fallar. En ese caso, hay que pedirle explícitamente que use la skill». Los sub-agentes están en declive, reservados a tareas «que generan mucha lectura sin mucha toma de decisiones» — «los uso cada vez menos; los agentes recientes delegan bastante bien por sí solos». Capa 3 — GitNexus indexa el repositorio como un grafo y ofrece impact(symbol) antes de modificar, detect_changes() antes de hacer commit, búsqueda por flujo de ejecución en lugar de grep, y renombrado vía el grafo de llamadas. La justificación del autor: «lo importante no es la velocidad, es detectar todos los efectos colaterales de un cambio». El MCP se trata como un gasto de contexto que hay que justificar: «intento evitar los MCP que consumen más contexto». Capa 4 — los hooks son «scripts activados por el harness del agente, no por el propio agente»: rechazar el build nativo y redirigir al build del IDE, ejecutar el formateador después de una escritura. Distinción de linting: ESLint para la sintaxis, ast-grep para las decisiones de arquitectura (prohibir cualquier llamada fetch que evite el cliente OpenAPI), typecheck para el tipado. Capa 5 — push a main → quality gate (lint → pattern lint → typecheck → tests) → build de la imagen → registry → webhook de despliegue, con el job de despliegue portando un needs: sobre el job de calidad. Cinco etapas: unitarias, integración con contenedores desechables («base de datos y broker reales, sin mocks»), arquitectura, componentes de front-end, end-to-end solo en las rutas críticas. Capa 6 — specs enmarcadas por dos skills, una de ellas de cierre, que actualiza la spec con lo que realmente se construyó: «la documentación de las specs muere si su cierre no forma parte del proceso». Regla anti-alucinación: «si una spec es vaga o inconsistente con lo que existe, el agente debe preguntar, no adivinar». Entrega escalonada tras feature flags, motivada por la degradación en contextos largos — «me permite hacer varias sesiones de implementación pequeñas en lugar de una gran sesión, que tiende a degradarse en calidad». Distinción entre feature flipping (Unleash: despliegue gradual, kill switch) y gating (contrato con el cliente, plan). ### El movimiento más instructivo: una restricción futura ya garantizada El autor planea liberar parte del código como open source. La regla «el código destinado a open source nunca debe depender de código propietario» está escrita en las rules y verificada por un test de arquitectura. «Escribir una restricción futura en el contexto evita pagar más tarde el precio de una reescritura». ### Por dónde empezar, en el orden dado 1. El quality gate primero, si aún no existe. 2. Un CLAUDE.md ligero que describa lo esencial y el porqué. 3. Rules añadidas de forma incremental para los patrones de arquitectura importantes. 4. Skills en cuanto un procedimiento se repite. 5. CLI y MCP para las herramientas principales. Advertencia: «toda skill, MCP o código traído del exterior debe examinarse con lupa. Son dependencias que pueden convertirse en vectores de ataque». ### Las cuatro limitaciones vividas 1. La obsolescencia de una regla no se puede medir. «A mediados de 2025, 'escribe un test para cada nuevo servicio' tenía sentido. Hoy es ruido y Claude lo hace de forma natural… no tengo forma de medir ni de saber si una regla antigua se ha vuelto obsoleta». 2. El rabbit hole. Una regla boyscout.md produce «sesiones interminables» y sobrecarga cognitiva; una corrección en estudio es enrutar estos hallazgos hacia una lista TODO y trasladar el mantenimiento a un workflow separado. 3. Sin empaquetado. Las skills y las rules se copian y pegan de un proyecto a otro, a veces dependientes de la máquina. 4. Dependencia de Claude, calificada de «riesgo moderado», y un IDE que ha dejado de ser adecuado: «sigo usando IntelliJ, pero ya no lo encuentro adaptado a nuestra época». ### La admisión de fondo «Las últimas versiones de Opus son cada vez más autónomas… Seamos honestos, cada vez soy menos útil durante las fases de implementación, pero no quiero perder el control del código producido. Estoy dividido entre la satisfacción de tener una fábrica de software cada vez más eficiente y el riesgo de perder conocimiento». El dispositivo garantiza que el código sea correcto; no garantiza que el humano siga entendiéndolo. Pregunta que queda abierta: «necesito encontrar una forma de revisar los diseños a posteriori, para hacer mío el resultado». Mismo problema que el planteado por [[osmani-cognitive-surrender-comprehension-debt-2026-05-05]]. ### Alcance Un dispositivo en solitario, sobre productos personales, con un único responsable de decisión: sin coordinación entre varios desarrolladores, sin revisión por pares, sin restricciones de cumplimiento normativo. Lo que se traspone a un entorno empresarial: la grilla de las tres preguntas, el principio de ejecutabilidad, el cierre de specs y el linting de patrones; lo que no se traspone: la ausencia de cualquier control humano que no sea uno mismo. Misma tesis, planteada como doctrina dos días después, en [[sfeir-code-review-anneau-contraintes-2026-07-30]].