# lassiege-usine-logicielle-heure-ia-2026-07-28

## Veille

Página de referencia publicada en **eventuallycoding.com** el **28 de julio de 2026** por **Hugo Lassiège** (Lyon, desarrollador convertido en emprendedor, autor de Bloggrify, Hakanai y Writizzy). El autor la presenta así: *«Esto será más una página de referencia que un artículo»*, pensada para su propia página de recursos. **Tema**: una descripción exhaustiva y detallada de una **fábrica de software en solitario** donde *«el código producido es ahora casi 100% generado»*, en varios monorepos políglotas (Nuxt, Kotlin, JS — Hakanai, Writizzy, Bloggrify) en **despliegue continuo a producción**. **Distinción planteada de entrada**: esto no es **vibe coding** en el sentido de Karpathy (experimentación, dejarse llevar) sino context engineering — *«dar todo el contexto necesario, en el momento adecuado, para que el software se ajuste a una intención y esté sistemáticamente controlado»*, con la frase que fundamenta la responsabilidad: *«Aunque no escriba el código, soy responsable de él y debo mantener el control sobre él»*. **Todo el conjunto de herramientas responde a tres preguntas**, y esta es la grilla de lectura más reutilizable del texto: *«¿Qué sabe el agente?»* (contexto, memoria, grafo de código) — *«¿Qué sabe hacer de forma determinista, sin improvisar?»* (skills, procedimientos) — *«¿Qué lo detiene cuando se equivoca?»* (hooks, tests de arquitectura, quality gates). **Seis capas detalladas**: (1) **contexto** — `CLAUDE.md` raíz + `.claude/rules/*.md` temáticos cargados condicionalmente vía `paths:` + `.agents/*.md` para asuntos no técnicos (personas, posicionamiento, tono); (2) **skills** — una treintena, criterio de existencia *«si explico lo mismo una tercera vez»*; (3) **herramientas** — MCP del IDE de JetBrains, **GitNexus** (grafo de código: `impact(symbol)`, `detect_changes()`), Claude-mem, wrapper de filtrado RTK, Sentry, base de datos de solo lectura; (4) **guardrails ejecutables** — hooks del harness, **tests de arquitectura**, linting de patrones (**ast-grep** para decisiones de arquitectura, no solo ESLint); (5) **fábrica** — quality gate bloqueante con `needs:` sobre el job de calidad, cinco etapas de pruebas; (6) **proceso de producto** — specs numeradas con una skill de redacción **y una skill de cierre**, diseño en Claude Design, entrega escalonada tras feature flags, distinción entre **feature flipping** (Unleash) y **gating** (contrato con el cliente). **La regla que lo resume todo**: *«Lo que importa debe ser ejecutable. Una instrucción se sigue 'la mayoría de las veces'… Un hook o un test se sigue siempre»*. **Una rareza para el género**: una sección «Por mejorar» que expone cuatro limitaciones vividas — la **imposibilidad de medir la obsolescencia de una regla** (*«no tengo forma de saber si una regla antigua se ha vuelto obsoleta»*), el **rabbit hole** creado por una regla boyscout, la **falta de empaquetado** de las skills entre proyectos, y sobre todo la admisión de tensión: *«cada vez soy menos útil durante las fases de implementación»*, *«dividido entre la satisfacción de tener una fábrica cada vez más eficiente y el riesgo de perder conocimiento»*.

## Titre Article

Mon usine logicielle à l'heure de l'IA

## Date

2026-07-28

## URL

https://eventuallycoding.com/p/mon-usine-logicielle-a-l-heure-de-l-ia

## Keywords

fábrica de software, context engineering, vibe coding, Karpathy, código 100% generado, desarrollador en solitario, monorepo, políglota, Nuxt, Kotlin, despliegue continuo, CLAUDE.md, rules, carga condicional, paths, agents.md, personas, contexto permanente, presupuesto de contexto, economía de tokens, skills, procedimiento repetible, sub-agentes, delegación, MCP, JetBrains, GitNexus, grafo de código, impact, radio de impacto, detect_changes, flujo de ejecución, Claude-mem, memoria persistente, RTK, filtrado de salida, Sentry, base de datos de solo lectura, guardrails ejecutables, hooks, harness, tests de arquitectura, frontera open source, linting de patrones, ast-grep, ESLint, typecheck, quality gate bloqueante, GitHub Actions, needs, etapas de pruebas, contenedores desechables, testcontainers, end-to-end, proceso de producto, spec numerada, cierre de spec, Claude Design, mockup, feature flag, Unleash, feature flipping, gating, trunk based, Marty Cagan, cuatro riesgos, obsolescencia de las reglas, rabbit hole, boyscout, empaquetado de skills, pérdida de conocimiento, Hugo Lassiège

## Authors

**Hugo Lassiège** — développeur devenu entrepreneur, basé à **Lyon**, écrit du code depuis 2001 et tient **eventuallycoding.com** (le blog a porté le nom `hakanai.free.fr` avant de devenir *Eventuallycoding* en 2013). *Eventuallycoding* est le nom-parapluie qui regroupe ses projets, sa chaîne YouTube et ses blogs.

**Les trois produits cités sont les siens**, et c'est ce qui donne son poids au texte : **Bloggrify** (générateur de blog statique, open source), **Hakanai** (application de newsletter pour blogs statiques) et **Writizzy** (plateforme de blogging — qui propulse la page elle-même, *« Propulsé par Writizzy »* en pied de page). Il ne décrit donc pas une méthode conseillée à des clients mais **le dispositif avec lequel il fait tourner ses propres produits en production**, seul.

## Ton

**Perfil**: una **página de referencia técnica**, reconocida como tal — *«esto será más una página de referencia que un artículo, y la referenciaré en la página de recursos del sitio»*. El registro de un **practicante en solitario** que documenta su propio puesto de trabajo: ni thought leadership, ni caso de estudio corporativo, ni tutorial. Público: desarrolladores que ya instrumentan agentes y buscan una configuración de referencia con la que comparar la suya.

**Estilo**: una **arquitectura en capas numeradas** (de 1 a 6), cada una abierta por su función, densamente **tabulada** — la página contiene una decena de tablas de dos columnas (archivo/contenido, familia/qué codifican, disparador/efecto, etapa/cobertura, necesidad/mecanismo). Es una **ficha técnica**, no una demostración: las tablas llevan la información, la prosa lleva el razonamiento. Extractos de configuración reales, sin pulir (una `rule` completa con su frontmatter `paths:` y su tabla de enrutamiento hacia nueve skills, el diagrama ASCII del pipeline de CI, el contenido de `boyscout.md`).

**Tres rasgos que distinguen el texto de la literatura circundante**:

1. **Modestia sobre el alcance de las rules.** *«Una restricción es específica de un proyecto y de una persona. No es una cuestión de calidad del software en sentido estricto»*. El autor se niega explícitamente a presentar sus convenciones como buenas prácticas universales — algo poco frecuente en un género que rápidamente cae en lo prescriptivo.
2. **Autoevaluación honesta de las herramientas.** Sobre Claude-mem: *«honestamente, me cuesta medir el impacto negativo o positivo. Todavía no tengo suficiente perspectiva»*. Sobre el wrapper RTK: *«la ganancia a veces se anula porque Claude ejecuta el comando dos veces»*. Sobre los sub-agentes: *«los uso cada vez menos»*. **Lo que se lee es lo que no funciona, o ya no funciona.**
3. **La admisión final, sin resolver.** *«Cada vez soy menos útil durante las fases de implementación»*, *«roza lo inquietante y es más riguroso que el 99% de los humanos»*, *«dividido entre la satisfacción de tener una fábrica de software cada vez más eficiente y el riesgo de perder conocimiento»*. El texto termina en un problema abierto, no en una conclusión.

**Frases características**: *«Aunque no escriba el código, soy responsable de él»*, *«no sirve de nada decirle a una IA que escriba código de calidad — no significa nada. Hay que hacer explícitas las propias restricciones»*, *«lo que importa debe ser ejecutable»*, *«el contexto es un presupuesto»*, *«1 bug corregido, 10 producidos»*, *«la documentación de las specs muere si su cierre no forma parte del proceso»*, *«si explico lo mismo una tercera vez, se convierte en una skill»*, *«no se puede eludir, a diferencia de una regla»*.

## Pense-betes

- **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.
- **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]].

## RésuméDe400mots

Página de referencia publicada el **28 de julio de 2026** por **Hugo Lassiège** en eventuallycoding.com, que documenta su **fábrica de software en solitario** para productos en producción (Hakanai, Writizzy, Bloggrify) cuyo *«código producido es ahora casi 100% generado»*.

**El planteamiento.** Esto no es **vibe coding** —que, para Karpathy, significaba experimentación— sino context engineering: *«dar todo el contexto necesario, en el momento adecuado, para que el software se ajuste a una intención y esté sistemáticamente controlado»*. La responsabilidad no se puede delegar: *«Aunque no escriba el código, soy responsable de él»*. Y la calidad del software va más allá del código: incluye la intención y **los cuatro riesgos de Marty Cagan**.

**La grilla.** Todo el conjunto de herramientas responde a tres preguntas: qué **sabe** el agente (contexto, memoria, grafo de código), qué sabe hacer de forma **determinista** (skills), y **qué lo detiene** cuando se equivoca (hooks, tests, gates).

**Seis capas.** El **contexto** está estratificado por momento de carga: un `CLAUDE.md` breve y permanente, `rules` condicionales activadas por ruta, `.agents/*.md` para personas y posicionamiento —una regla que funciona como **tabla de enrutamiento** hacia skills que solo se abren en caso de necesidad. Las **skills** (una treintena) nacen en la tercera repetición; las más rentables son las que cubren un **procedimiento multiarchivo**. Las **herramientas** delegan lo determinista: MCP del IDE, **GitNexus**, que indexa el repositorio como un grafo para medir el radio de impacto de un cambio —*«lo importante no es la velocidad, es detectar todos los efectos colaterales»*. Los **guardrails** son ejecutables: hooks activados por el harness, **tests de arquitectura** que rompen la CI, y **`ast-grep`** para convertir una decisión de arquitectura en una regla de lint. La **fábrica** impone un quality gate del que depende el job de despliegue (`needs:`), con cinco etapas de pruebas. El **proceso de producto** parte de una spec numerada, enmarcada por una skill de redacción **y una skill de cierre** —*«sin ella, las specs se vuelven obsoletas en seis meses»*— entregada de forma escalonada tras feature flags.

**El principio.** *«Lo que importa debe ser ejecutable. Una instrucción se sigue 'la mayoría de las veces'… Un hook o un test se sigue siempre»*.

**Las limitaciones, expuestas.** La obsolescencia de una regla no se puede medir; una regla boyscout produce sesiones interminables; las skills se copian y pegan a falta de empaquetado. Y la admisión final: *«cada vez soy menos útil durante las fases de implementación»*, dividido entre la eficiencia de la fábrica y *«el riesgo de perder conocimiento»*.

## GrapheDeConnaissance

- Hugo Lassiège —publie→ Mon usine logicielle à l'heure de l'IA (DOCUMENT, 0.98)
- Hugo Lassiège —a_créé→ Bloggrify (TECHNOLOGIE, 0.93)
- Hugo Lassiège —a_créé→ Writizzy (TECHNOLOGIE, 0.93)
- Hugo Lassiège —affirme_que→ ce qui compte doit être exécutable : une consigne est suivie la plupart du temps, un hook ou un test est suivi tout le temps (CITATION, 0.97)
- test d'architecture —surpasse→ une rule de contexte, parce qu'il ne peut pas être contourné (AFFIRMATION, 0.95)
- context engineering —s_oppose_à→ vibe coding (METHODOLOGIE, 0.95)
- Hugo Lassiège —affirme_que→ même sans écrire le code, l'humain en reste responsable et doit en garder le contrôle (CITATION, 0.95)
- Hugo Lassiège —recommande→ expliciter ses propres contraintes plutôt que demander à une IA d'écrire du code de qualité (AFFIRMATION, 0.95)
- usine logicielle —est_basé_sur→ trois questions : ce que l'agent sait, ce qu'il fait de façon déterministe, ce qui l'arrête quand il se trompe (AFFIRMATION, 0.94)
- contexte permanent —permet→ d'indexer les skills sans les charger, le contenu n'étant ouvert qu'au besoin (AFFIRMATION, 0.92)
- skill —est_instance_de→ procédure écrite une fois et rejouée à l'identique, créée dès la troisième répétition (AFFIRMATION, 0.94)
- GitNexus —permet→ de mesurer le rayon d'explosion d'une modification et d'en détecter tous les effets de bord (AFFIRMATION, 0.94)
- graphe de code —surpasse→ le grep de nom de fonction pour retrouver un flux d'exécution (AFFIRMATION, 0.9)
- hooks —fait_partie_de→ harness de l'agent (CONCEPT, 0.94)
- ast-grep —permet→ de transformer une décision d'architecture en règle de lint (AFFIRMATION, 0.93)
- quality gate —permet→ d'empêcher tout déploiement non validé, via une dépendance du job de déploiement au job de qualité (AFFIRMATION, 0.95)
- clôture de spec —résout→ l'obsolescence des specs, qui deviennent périmées en six mois sans elle (AFFIRMATION, 0.93)
- feature flag —permet→ de livrer une spec par étapes et d'éviter les longues sessions dont la qualité se dégrade (AFFIRMATION, 0.9)
- Unleash —s_applique_à→ l'activation et la désactivation de fonctionnalités sans redéploiement (AFFIRMATION, 0.9)
- Hugo Lassiège —affirme_que→ rien ne permet de mesurer si une ancienne rule est devenue obsolète (AFFIRMATION, 0.93)
- règle d'amélioration continue —s_oppose_à→ la terminaison d'une session, en produisant des sessions sans fin (AFFIRMATION, 0.88)
- Hugo Lassiège —affirme_que→ l'efficacité croissante de l'usine logicielle s'accompagne d'un risque de perdre la connaissance du code (CITATION, 0.94)
- skills et MCP repris de l'extérieur —s_oppose_à→ la sécurité de la chaîne, en constituant des dépendances vectrices d'attaques (AFFIRMATION, 0.9)
- qualité logicielle —est_basé_sur→ les quatre risques de Marty Cagan — valeur, utilisabilité, faisabilité, viabilité — au-delà de la production de code (AFFIRMATION, 0.92)
- sous-agents —s_applique_à→ les tâches à forte lecture et faible décision, rendant une conclusion plutôt qu'un dump de fichiers (AFFIRMATION, 0.9)

---
Canonical: https://www.thekb.eu/es/fiches/lassiege-usine-logicielle-heure-ia-2026-07-28/