# 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**: la descripción exhaustiva e instrumentada de una **fábrica de software en solitario** donde *"el código producido es ahora casi 100% generado,"* a través de varios monorepos políglotas (Nuxt, Kotlin, JS — Hakanai, Writizzy, Bloggrify) en **despliegue continuo a producción**. **Distinción planteada desde el inicio**: esto no es **vibe coding** en el sentido de Karpathy (experimentación, soltar el control) sino context engineering — *"dar todo el contexto necesario, en el momento adecuado, para que el software se corresponda con 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."* **Toda la instrumentación responde a tres preguntas**, y esta es la rejilla de lectura más reutilizable del texto: *"¿Qué sabe el agente?"* (contexto, memoria, grafo de código) — *"¿Qué puede 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 contenido no técnico (personas, posicionamiento, tono); (2) **skills** — una treintena, criterio de existencia *"si explico lo mismo por tercera vez"*; (3) **herramientas** — MCP del IDE JetBrains, **GitNexus** (grafo de código: `impact(symbol)`, `detect_changes()`), Claude-mem, wrapper RTK de filtrado de salida, Sentry, base de datos de solo lectura; (4) **barreras 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:` en 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 un feature flag, distinción entre **feature flipping** (Unleash) y **gating** (contrato de cliente). **La regla que lo resume todo**: *"Lo que importa debe ser ejecutable. Una instrucción se sigue 'la mayor parte del tiempo'… Un hook o un test se sigue siempre."* ⚠️ **Poco frecuente en 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 **ausencia de empaquetado** de las skills entre proyectos, y sobre todo la admisión de tensión: *"cada vez soy menos útil en 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 el 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 reproducible, sub-agentes, delegación, MCP, JetBrains, GitNexus, grafo de código, impacto, radio de impacto, detect_changes, flujo de ejecución, Claude-mem, memoria persistente, RTK, filtrado de salida, Sentry, base de datos de solo lectura, barreras ejecutables, hooks, harness, tests de arquitectura, frontera del open source, pattern linting, 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**, presentada como tal — *"esto será más una página de referencia que un artículo, y la enlazaré desde la página de recursos del sitio."* 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 propia.

**Estilo**: **arquitectura en capas numeradas** (de la 1 a la 6), cada una abierta por su función, densamente **tabulada** — la página contiene alrededor de 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 y 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 del entorno**:

1. **Modestia sobre el alcance de las rules.** *"Una restricción es específica de un proyecto y 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 se vuelve 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."* **El lector se entera de lo que no funciona, o ya no funciona.**
3. **La admisión final, sin resolver.** *"cada vez soy menos útil en 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 el conocimiento."* El texto termina en un problema abierto, no en una conclusión.

**Frases distintivas**: *"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 introducidos,"* *"La documentación de la spec muere si su cierre no forma parte del proceso,"* *"si explico lo mismo por tercera vez, se convierte en una skill,"* *"no se puede eludir, a diferencia de una regla."*

## Pense-betes

- **⭐ La rejilla de tres preguntas — la enseñanza más reutilizable**: toda la instrumentación responde a *"¿Qué **sabe** el agente?"* (contexto, memoria, grafo de código), *"¿Qué puede hacer **de forma determinista**, sin improvisar?"* (skills, procedimientos), *"¿Qué lo **detiene** cuando se equivoca?"* (hooks, tests de arquitectura, quality gates). **Rejilla de auditoría instantánea**: aplicada a cualquier configuración agéntica, revela en tres minutos cuál de las tres está vacía. Casi siempre es la tercera.
- **⭐⭐ El principio rector, que merece memorizarse textualmente**: *"Lo que importa debe ser ejecutable. Una instrucción se sigue 'la mayor parte del tiempo', pero puede olvidarse. Un hook o un test se sigue siempre."* Formulado de forma aún más tajante en otro pasaje sobre los tests de arquitectura: *"no se puede eludir, **a diferencia de una regla**."* → **Una regla es una intención, un test es una garantía.** Es la misma tesis que el anillo de restricciones en [[sfeir-code-review-anneau-contraintes-2026-07-30]] (publicado dos días después) y el harness en [[osmani-agent-harness-engineering-2026-04-19]], pero **demostrada en una configuración real, en solitario**, no enunciada como doctrina.
- **Explícitamente en contra del vibe coding**: *"El vibe coding tal como lo define Karpathy era experimentación y soltar el control. Aquí voy a hablar de context engineering."* Y la cláusula de responsabilidad resultante: *"Aunque no escriba el código, soy responsable de él y debo mantener el control sobre él."* Cf. [[karpathy-vibe-coding-agentic-engineering-software-3-0-2026-04-29]].
- **La calidad del software no es la calidad del código**: incluye la **intención** (por qué, para quién) y **los cuatro riesgos de Marty Cagan** — *Value, Usability, Feasibility, Viability*— además del rendimiento y la fiabilidad. Esto es lo que justifica la capa 6 (proceso de producto) y explica por qué una fábrica de software puramente técnica pierde el sentido.
- **Capa 1 — contexto, y el movimiento que vale la pena copiar**: tres niveles separados por su **momento de carga**. `CLAUDE.md` raíz (arquitectura, convenciones transversales, índice de specs) → permanente y **corto**; `.claude/rules/*.md` → **condicional**, activado por un frontmatter `paths:` (la regla de Kotlin se carga solo al tocar `api/**/*`); `.agents/*.md` → contexto **no técnico** (posicionamiento de producto, personas, tono). ⭐ **La regla, vista en su totalidad, es una tabla de enrutamiento**: no contiene los procedimientos, enumera nueve skills con la tarea que dispara cada una, para abrirse solo cuando se necesita. *"Si la IA no está haciendo un cambio de esquema, no tiene sentido abrir la skill db-migration."* → **El contexto permanente lleva el índice, no el contenido.**
- **⭐ Una restricción a largo plazo codificada como contexto *y* como test** — el mejor ejemplo del texto: el autor planea liberar parte del código como open source. La regla *"el código destinado a ser open source nunca debe depender de código propietario"* está **escrita en las rules** *y* **verificada por un test de arquitectura** (ningún archivo del lado "abierto" hace referencia al lado "propietario"; cada archivo de producción pertenece a uno u otro lado). *"Escribir una restricción futura en el contexto evita pagar una reescritura más adelante."* → **Una decisión que aún no existe ya puede garantizarse mecánicamente.**
- **La frase que mata el prompt mágico**: *"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."* Acompañada de una honestidad poco frecuente: *"Una restricción es específica de un proyecto y una persona… Usar feature flags no es mejor ni peor, es solo mi preferencia."*
- **Capa 2 — skills**: *"un procedimiento escrito una vez, reproducido de forma idéntica."* **Criterio de existencia: la tercera repetición.** Una treintena, repartidas en seis familias (backend, frontend, datos, ciclo de producto, operaciones/runbooks, redacción). Dos lecciones: 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"*), y las skills de **"documentación al día"** son críticas en código que evoluciona rápido. ⚠️ Matiz operativo: *"Esta carga automática a veces puede fallar. En ese caso, hay que pedir explícitamente usar la skill."* Cf. [[shihipar-claude-code-lessons-building-skills-2026-06-03]], [[agent-skills-anthropic-2025-10-16]], [[vincent-superpowers-agentic-skills-framework-github-2026-04-02]].
- **Los sub-agentes, en declive**: reservados para tareas *"que generan mucha lectura sin mucha toma de decisiones"* (auditorías, exploración amplia, redacción de documentación) — *"consumen su propio contexto y devuelven una conclusión, no un volcado de archivos."* Pero: *"los uso cada vez menos, los agentes recientes hacen ellos mismos una delegación bastante focalizada."* **Señal de evolución**: una práctica de instrumentación parcialmente vuelta obsoleta por el modelo.
- **⭐ Capa 3 — GitNexus, la herramienta más interesante del dispositivo**: el repositorio se indexa como un **grafo** (símbolos, relaciones, flujos de ejecución), lo que permite `impact(symbol)` **antes** de modificar (radio de impacto, llamadores, nivel de riesgo), `detect_changes()` **antes** de hacer commit (*"¿toqué solo lo que quería tocar?"*), buscar un **flujo de ejecución** en lugar de hacer grep de un nombre de función, y renombrar **vía el grafo de llamadas** en lugar de buscar y reemplazar. Y la justificación, que importa más que la herramienta en sí: *"El verdadero problema no es la velocidad, es **detectar todos los efectos secundarios** de un cambio."* → trasladado a la regla n.º 4: *"Medir los impactos antes y después de la edición. Queremos evitar el efecto '1 bug corregido, 10 introducidos'."* **Vale la pena comparar el contexto estructurado en grafo de código frente al RAG vectorial** — la misma familia de argumento que el resultado de Compare the Market citado en [[sfeir-code-review-anneau-contraintes-2026-07-30]].
- **MCP, con una advertencia de coste**: *"intento evitar los MCP que consumen más contexto, pero aun así tengo algunos"* — IDE JetBrains (build, inspecciones, refactorizaciones, búsqueda indexada), GitNexus, servicios de negocio (pago, monitorización), base de datos, navegador. **El MCP se trata como un gasto de contexto que hay que justificar**, no como algo dado por sentado.
- **Capa 4 — hooks: la definición que importa**: *"scripts disparados por el **harness** del agente, no por el agente mismo."* Dos usos en producción: antes de una llamada de shell, **rechazar el build nativo** y redirigir al build del IDE (más rápido, errores estructurados) explicando el fallback; después de escribir un archivo, **ejecutar el formatter/linter**. Otros usos citados: bloquear ediciones a archivos generados, exigir un test junto a cualquier módulo nuevo, prohibir un patrón peligroso.
- **⭐ Pattern linting — la distinción que vale la pena retener**: **ESLint** para la sintaxis, **`ast-grep` para *decisiones de arquitectura*** (ejemplo: *prohibir cualquier llamada `fetch` que evite el cliente OpenAPI*), **typecheck** para el tipado. → **Una decisión de arquitectura puede convertirse en una regla de lint.** Es el eslabón que falta entre "lo decidimos" y "se aplica", y cuesta unas pocas líneas.
- **Capa 5 — el gate**: `push to main → quality gate (lint → pattern lint → typecheck → tests) → build docker image → push to registry → deployment webhook`. **El punto estructural**: el job de despliegue tiene un **`needs:` sobre el job de calidad**. *"Nada llega a producción sin pasar el gate. Eso es esencial como regla general, más aún para código producido automáticamente."* Cinco etapas de pruebas: unitarias (intensivamente), de integración **con contenedores desechables** (*"base de datos y broker reales, sin mocks"*), de arquitectura, de componentes front-end, **end-to-end solo en los caminos críticos**. Cf. [[williams-adlc-3-tests-are-the-spec-2026-06-12]] y [[williams-adlc-2-two-human-gates-2026-06-12]].
- **Capa 6 — el proceso de producto, y el paso que todo el mundo olvida**: specs numeradas (una por dominio funcional, indexadas en el contexto permanente) enmarcadas por **dos** skills — una para **redactar** la spec y su plan, **otra para cerrarla** actualizándola con lo que realmente se construyó. *"Sin ella, las specs quedan obsoletas en seis meses,"* y como regla final: *"La documentación de la spec muere si su cierre no forma parte del proceso."* ⭐ **El cierre es la parte del ciclo de documentación que casi nunca existe en otros lugares.**
- **Regla anti-alucinación para las specs**: *"Si una spec no es clara o es incoherente con el sistema existente, el agente debe preguntar, no adivinar."* Una sola línea de contexto que aborda el modo de fallo más costoso del desarrollo agéntico.
- **Entrega escalonada, y su razón de ser**: la spec está diseñada para entregarse en etapas protegidas por un feature flag, *"me permite hacer varias sesiones de implementación pequeñas en lugar de una sesión grande, que tiende a degradarse en calidad cuando se llena demasiado."* → **Aquí, la descomposición del producto está dictada por la degradación del contexto largo**, no por la gestión de proyecto. Distinción útil: **feature flipping** (Unleash — activar/desactivar sin redesplegar: rollout, kill switch, mantenimiento) frente a **gating** (tabla de configuración + servicio — restringir según el contrato o plan del cliente). Dos mecanismos, dos necesidades, y una skill para que los agentes no los confundan.
- **Por dónde empezar (orden dado, y es bueno)**: (1) **primero el quality gate**, 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 de seguridad**: *"cualquier skill, MCP o código importado del exterior debe examinarse con lupa. Son dependencias que pueden ser vectores de ataque."* Vale la pena compararlo con la superficie de ataque agéntica descrita en [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]].
- **⚠️ Limitaciones vividas — la sección que da credibilidad a la página**: 1. **La obsolescencia de una regla no es medible.** *"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 o saber si una regla antigua se ha vuelto obsoleta."* → **El contexto acumulado se degrada al ritmo de los modelos, y nada rastrea esa degradación.** Es la verdadera brecha metodológica del campo, y aquí se nombra sin solución. 2. **El rabbit hole.** Una regla `boyscout.md` (*"deja siempre el código un poco mejor… márcame las mejoras"*) produce *"sesiones interminables"* y sobrecarga cognitiva. Solución prevista: encauzar estos hallazgos hacia una **lista de TODO** y trasladar el mantenimiento a un flujo de trabajo separado, parcialmente automatizado. → **Una buena instrucción de mejora continua se convierte en un generador de deriva cuando el agente no se detiene por sí solo.** 3. **Sin empaquetado.** Las skills y las rules se **copian y pegan de proyecto en proyecto**, a veces dependientes de la máquina. Falta: una forma de empaquetar para el despliegue y **centralizar el mantenimiento**. 4. **Dependencia de Claude**, calificada de *"riesgo moderado"* (*"todo el ecosistema está subiendo de nivel"*), con interés en probar modelos de pesos abiertos — bloqueado por el hardware. Y **el IDE ha dejado de encajar bien**: *"sigo usando IntelliJ pero ya no lo encuentro adecuado para nuestra época. Aún no he visto una alternativa interesante."*
- **⭐⭐ La admisión de fondo, que merece citarse textualmente**: *"Las últimas versiones de Opus son cada vez más autónomas… Es rozando lo inquietante, y más riguroso que el 99% de los humanos. Seamos honestos, cada vez soy menos útil en 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 el conocimiento**."* → Es exactamente la **deuda de comprensión** de [[osmani-cognitive-surrender-comprehension-debt-2026-05-05]], expresada desde dentro por alguien que construyó el harness más completo posible **y constata que el harness no resuelve ese problema en particular**. El dispositivo garantiza que el código es correcto; no garantiza que el humano todavía lo entienda. **La pregunta abierta del texto**: *"necesito encontrar una forma de revisar los diseños a posteriori, para hacer mío el resultado."*
- **⚠️ Alcance que no hay que sobrestimar**: un dispositivo **en solitario**, sobre **productos personales**, con un único responsable de decisión. Sin coordinación multideveloper, sin peer review, sin restricciones de cumplimiento o auditoría — la capa de "quién valida" la ocupa una sola persona, que además es la autora de las rules. Lo que se traslada a un entorno empresarial: **la rejilla de tres preguntas, el principio de lo ejecutable, el cierre de specs, el pattern linting**. Lo que no se traslada tal cual: la ausencia total de cualquier gate humano que no sea uno mismo.
- **Meta / relacionados**: una demostración práctica de [[osmani-agent-harness-engineering-2026-04-19]] y un primo directo de [[sfeir-code-review-anneau-contraintes-2026-07-30]] (publicado 2 días después, misma tesis: la calidad reside en el anillo de restricciones, no en el código); el mismo vocabulario de "fábrica de software" que [[wescale-usine-logicielle-augmentee-juge-strategique-2026-05-03]], pero a la escala de un solo individuo; se opone al vibe coding de [[karpathy-vibe-coding-agentic-engineering-software-3-0-2026-04-29]]; converge con [[klaassen-teach-ai-think-senior-engineer-every-2025-11-07]] en hacer explícitas las restricciones; para leer junto con [[shihipar-claude-code-lessons-building-skills-2026-06-03]] sobre skills y [[williams-adlc-3-tests-are-the-spec-2026-06-12]] sobre tests.

## 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, era experimentación— sino context engineering: *"dar todo el contexto necesario, en el momento adecuado, para que el software se corresponda con una intención y esté sistemáticamente controlado."* La responsabilidad no se delega: *"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 rejilla.** Toda la instrumentación responde a tres preguntas: qué **sabe** el agente (contexto, memoria, grafo de código), qué puede hacer **de forma determinista** (skills), y **qué lo detiene** cuando se equivoca (hooks, tests, gates).

**Seis capas.** El **contexto** se organiza en capas según el momento de carga: un `CLAUDE.md` raíz corto y permanente, `rules` condicionales activadas por ruta, `.agents/*.md` para personas y posicionamiento —una regla que actúa como **tabla de enrutamiento** hacia skills que solo se abren cuando se necesitan. 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 — *"el verdadero problema no es la velocidad, es detectar todos los efectos secundarios."* Las **barreras** son ejecutables: hooks disparados 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 quedan obsoletas en seis meses"*— entregada de forma escalonada tras un feature flag.

**El principio.** *"Lo que importa debe ser ejecutable. Una instrucción se sigue 'la mayor parte del tiempo'… Un hook o un test se sigue siempre."*

**Las limitaciones, expuestas.** La obsolescencia de una regla no es medible; una regla boyscout genera sesiones interminables; las skills se copian y pegan a falta de empaquetado. Y la admisión final: *"cada vez soy menos útil en las fases de implementación,"* dividido entre la eficiencia de la fábrica y *"el riesgo de perder el 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/