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

## Veille

Reference page published on **eventuallycoding.com** on **July 28, 2026** by **Hugo Lassiège** (Lyon, developer turned entrepreneur, author of Bloggrify, Hakanai, and Writizzy). The author announces it as such: *"This will be more of a reference page than an article,"* intended for his own resources page. **Subject**: an exhaustive, tooled description of a **solo software factory** where *"the code produced is now nearly 100% generated,"* across several polyglot monorepos (Nuxt, Kotlin, JS — Hakanai, Writizzy, Bloggrify) in **continuous deployment to production**. **Distinction stated upfront**: this is not **vibe coding** in Karpathy's sense (experimentation, letting oneself be carried along) but **context engineering** — *"giving all the necessary context, at the right time, so that the software matches an intention and is systematically controlled,"* with the sentence that grounds the responsibility: *"Even if I don't write the code, I am responsible for it and must keep control over it."* **The entire toolset answers three questions**, and this is the text's most reusable reading grid: *"What does the agent know?"* (context, memory, code graph) — *"What does it know how to do deterministically, without improvising?"* (skills, procedures) — *"What stops it when it gets it wrong?"* (hooks, architecture tests, quality gates). **Six layers detailed**: (1) **context** — root `CLAUDE.md` + topical `.claude/rules/*.md` conditionally loaded via `paths:` + `.agents/*.md` for non-technical matters (personas, positioning, tone); (2) **skills** — about thirty, existence criterion *"if I explain the same thing a third time"*; (3) **tools** — JetBrains IDE MCP, **GitNexus** (code graph: `impact(symbol)`, `detect_changes()`), Claude-mem, RTK filtering wrapper, Sentry, read-only database; (4) **executable guardrails** — harness hooks, **architecture tests**, pattern linting (**ast-grep** for architecture decisions, not just ESLint); (5) **factory** — blocking quality gate with `needs:` on the quality job, five test stages; (6) **product process** — numbered specs with a drafting skill **and a closure skill**, design in Claude Design, staged delivery behind feature flags, distinction between **feature flipping** (Unleash) and **gating** (customer contract). **The rule that sums it all up**: *"What matters must be executable. An instruction is followed 'most of the time'… A hook or a test is followed all the time."* **A rarity for the genre**: a "To improve" section that exposes four lived limitations — the **impossibility of measuring a rule's obsolescence** (*"I have no way of knowing whether an old rule has become obsolete"*), the **rabbit hole** created by a boyscout rule, the **lack of packaging** for skills across projects, and above all the admission of tension: *"I am becoming less and less useful during implementation phases,"* *"torn between the satisfaction of having an increasingly efficient factory and the risk of losing knowledge."*

## 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

software factory, context engineering, vibe coding, Karpathy, 100% generated code, solo dev, monorepo, polyglot, Nuxt, Kotlin, continuous deployment, CLAUDE.md, rules, conditional loading, paths, agents.md, personas, permanent context, context budget, token economy, skills, replayable procedure, sub-agents, delegation, MCP, JetBrains, GitNexus, code graph, impact, blast radius, detect_changes, execution flow, Claude-mem, persistent memory, RTK, output filtering, Sentry, read-only database, executable guardrails, hooks, harness, architecture tests, open source boundary, pattern linting, ast-grep, ESLint, typecheck, blocking quality gate, GitHub Actions, needs, test stages, disposable containers, testcontainers, end-to-end, product process, numbered spec, spec closure, Claude Design, mockup, feature flag, Unleash, feature flipping, gating, trunk based, Marty Cagan, four risks, rule obsolescence, rabbit hole, boyscout, skill packaging, loss of knowledge, 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

**Profile**: a **technical reference page**, acknowledged as such — *"This will be more of a reference page than an article, and I'll reference it on the site's resources page."* The register of a **solo practitioner** documenting his own workstation: neither thought leadership, nor a corporate case study, nor a tutorial. Audience: developers who already tool agents and are looking for a reference configuration to compare against their own.

**Style**: an **architecture in numbered layers** (1 to 6), each opened by its function, densely **tabulated** — the page contains around ten two-column tables (file/content, family/what they encode, trigger/effect, stage/coverage, need/mechanism). It is a **technical spec sheet**, not a demonstration: the tables carry the information, the prose carries the reasoning. Real, unvarnished configuration excerpts (a complete `rule` with its `paths:` frontmatter and its routing table to nine skills, the ASCII diagram of the CI pipeline, the content of `boyscout.md`).

**Three traits that set the text apart from the surrounding literature**:

1. **Modesty about the scope of the rules.** *"A constraint is specific to a project and a person. It's not a matter of software quality in the strict sense."* The author explicitly refuses to present his conventions as universal best practices — rare in a genre that quickly tips into the prescriptive.
2. **Honest self-assessment of the tools.** On Claude-mem: *"honestly, I have some trouble measuring the negative or positive impact. I don't have enough hindsight yet."* On the RTK wrapper: *"the gain is sometimes canceled out because Claude runs the command twice."* On sub-agents: *"I use them less and less."* **What one reads is what doesn't work, or no longer does.**
3. **The final, unresolved admission.** *"I am becoming less and less useful during implementation phases,"* *"it's borderline unsettling and more rigorous than 99% of humans,"* *"torn between the satisfaction of having an increasingly efficient software factory and the risk of losing knowledge."* The text ends on an open problem, not a conclusion.

**Signature phrases**: *"Even if I don't write the code, I am responsible for it"*, *"There's no point telling an AI to write quality code — it means nothing. You have to make your own constraints explicit"*, *"What matters must be executable"*, *"Context is a budget"*, *"1 bug fixed, 10 produced"*, *"Spec documentation dies if its closure isn't part of the process"*, *"if I explain the same thing a third time, it becomes a skill"*, *"it can't be bypassed, unlike a rule"*.

## Pense-betes

- **Date / source**: **July 28, 2026**, eventuallycoding.com, **Hugo Lassiège**. A reference page acknowledged as such, describing the setup with which the author runs his own products in production, alone.
- **Key framing**: this is not vibe coding — *"Vibe coding as defined by Karpathy was experimentation and letting oneself be carried along. Here, I'm going to talk about context engineering."* With the responsibility clause: *"Even if I don't write the code, I am responsible for it and must keep control over it."* ### The three-question grid The entire toolset answers three questions, and this is the text's most reusable contribution: | Question | What answers it | |---|---| | What does the agent **know**? | context, memory, code graph | | What does it know how to do **deterministically**? | skills, procedures | | What **stops it** when it gets it wrong? | hooks, architecture tests, quality gates | Asked in front of an agentic setup, it reveals which of the three is empty. Associated guiding principle: *"What matters must be executable. An instruction is followed 'most of the time,' but it can be forgotten. A hook or a test is followed all the time."* And on architecture tests: *"it can't be bypassed, unlike a rule."* ### The six layers | # | Layer | Content | |---|--------|---------| | 1 | **Context** | short, permanent root `CLAUDE.md` (architecture, conventions, spec index); conditional `.claude/rules/*.md` activated via `paths:` frontmatter; `.agents/*.md` for non-technical matters (positioning, personas, tone) | | 2 | **Skills** | about thirty, six families; existence criterion: the third repetition | | 3 | **Tools** | JetBrains IDE MCP, **GitNexus** (code graph), Claude-mem, Sentry, read-only database | | 4 | **Guardrails** | harness hooks, architecture tests, pattern linting (`ast-grep`) | | 5 | **Factory** | blocking quality gate, five test stages | | 6 | **Product process** | numbered specs, drafting skill **and** closure skill, feature flags | **Layer 1** — permanent context carries the index, not the content: the rule, seen in full, is a routing table listing nine skills alongside the task that triggers them. *"If the AI isn't making a schema change, there's no point opening the db-migration skill."* **Layer 2** — "multi-file procedure" skills are the most cost-effective: *"adding a block to the content editor touches three rendering surfaces; without a skill, the agent systematically forgets one."* Nuance: *"This automatic loading can sometimes fail. In that case, you have to explicitly ask it to use the skill."* Sub-agents are on the decline, reserved for tasks *"that generate a lot of reading without much decision-making"* — *"I use them less and less; recent agents delegate quite precisely on their own."* **Layer 3** — GitNexus indexes the repository as a graph and provides `impact(symbol)` before modifying, `detect_changes()` before committing, execution-flow search rather than grep, and renaming via the call graph. The author's justification: *"The real point isn't speed, it's detecting all the side effects of a change."* MCP is treated as a context expense to be justified: *"I try to avoid MCPs that consume more context."* **Layer 4** — hooks are *"scripts triggered by the agent's harness, not by the agent itself"*: refusing the native build and redirecting to the IDE build, running the formatter after a write. Linting distinction: ESLint for syntax, **`ast-grep` for architecture decisions** (forbidding any `fetch` call that bypasses the OpenAPI client), typecheck for typing. **Layer 5** — `push to main → quality gate (lint → pattern lint → typecheck → tests) → build image → registry → deployment webhook`, with the deployment job carrying a **`needs:` on the quality job**. Five stages: unit, integration with disposable containers (*"real database and broker, no mocks"*), architecture, front-end components, end-to-end on critical paths only. **Layer 6** — specs framed by two skills, one of them **for closure**, updating the spec with what was actually built: *"Spec documentation dies if its closure isn't part of the process."* Anti-hallucination rule: *"If a spec is vague or inconsistent with what exists, the agent must ask, not guess."* Staged delivery behind feature flags, motivated by long-context degradation — *"it lets me do several small implementation sessions rather than one big session, which tends to degrade in quality."* Distinction between **feature flipping** (Unleash: rollout, kill switch) and **gating** (customer contract, plan). ### The most instructive move: a future constraint already guaranteed The author plans to open-source part of the code. The rule *"code intended for open source must never depend on proprietary code"* is **written into the rules** and **verified by an architecture test**. *"Writing a future constraint into the context avoids paying for a rewrite later."* ### Where to start, in the order given 1. The **quality gate** first, if it doesn't exist yet. 2. A lightweight `CLAUDE.md` describing the essentials **and the why**. 3. Rules added incrementally for important architecture patterns. 4. Skills as soon as a procedure recurs. 5. CLI and MCP for the main tools. Warning: *"any skill, MCP, or code brought in from outside must be scrutinized. These are dependencies that can be attack vectors."* ### The four lived limitations 1. **Rule obsolescence cannot be measured.** *"In mid-2025, 'write a test for every new service' made sense. Today it's noise and Claude does it naturally… I have no way to measure or know whether an old rule has become obsolete."* 2. **The rabbit hole.** A `boyscout.md` rule produces *"endless sessions"* and cognitive overload; a fix under consideration is routing these findings to a TODO list and moving maintenance into a separate workflow. 3. **No packaging.** Skills and rules are copy-pasted from one project to another, sometimes machine-dependent. 4. **Dependence on Claude**, judged *"moderate risk,"* and an IDE that has become ill-suited: *"I still use IntelliJ, but I no longer find it suited to our era."* ### The underlying admission *"The latest versions of Opus are increasingly autonomous… Let's be honest, I'm becoming less and less useful during implementation phases, but I don't want to lose control of the code produced. I'm torn between the satisfaction of having an increasingly efficient software factory and the risk of losing knowledge."* The setup guarantees that the code is correct; it does not guarantee that the human still understands it. Question left open: *"I need to find a way to review designs after the fact, to make the result my own."* Same problem as the one raised by [[osmani-cognitive-surrender-comprehension-debt-2026-05-05]]. ### Scope A **solo** setup, on personal products, with a single decision-maker: no multi-developer coordination, no peer review, no compliance constraints. What transposes to a company setting: the three-question grid, the executable principle, spec closure, and pattern linting; what does not transpose: the absence of any human gate other than oneself. Same thesis, stated as doctrine two days later, in [[sfeir-code-review-anneau-contraintes-2026-07-30]].

## RésuméDe400mots

Reference page published on **July 28, 2026** by **Hugo Lassiège** on eventuallycoding.com, documenting his **solo software factory** for production products (Hakanai, Writizzy, Bloggrify) whose *"code produced is now nearly 100% generated."*

**The framing.** This is not **vibe coding** — which, for Karpathy, meant experimentation — but **context engineering**: *"giving all the necessary context, at the right time, so that the software matches an intention and is systematically controlled."* Responsibility cannot be delegated: *"Even if I don't write the code, I am responsible for it."* And software quality goes beyond code — it includes intention and **Marty Cagan's four risks**.

**The grid.** The entire toolset answers three questions: what the agent **knows** (context, memory, code graph), what it knows how to do **deterministically** (skills), and **what stops it** when it gets it wrong (hooks, tests, gates).

**Six layers.** **Context** is stratified by loading moment: a short, permanent `CLAUDE.md`, conditional `rules` activated by path, `.agents/*.md` for personas and positioning — a rule serving as a **routing table** to skills to be opened only as needed. **Skills** (about thirty) are born at the third repetition; the most cost-effective are those covering a **multi-file procedure**. **Tools** delegate the deterministic: IDE MCP, **GitNexus**, which indexes the repository as a graph to measure the blast radius of a change — *"the real point isn't speed, it's detecting all the side effects."* **Guardrails** are executable: hooks triggered by the harness, **architecture tests** that break CI, and **`ast-grep`** to turn an architecture decision into a lint rule. The **factory** enforces a quality gate that the deployment job depends on (`needs:`), with five test stages. The **product process** starts from a numbered spec, framed by a drafting skill **and a closure skill** — *"without it, specs go stale within six months"* — delivered in stages behind feature flags.

**The principle.** *"What matters must be executable. An instruction is followed 'most of the time'… A hook or a test is followed all the time."*

**The limitations, exposed.** A rule's obsolescence cannot be measured; a boyscout rule produces endless sessions; skills get copy-pasted for lack of packaging. And the final admission: *"I am becoming less and less useful during implementation phases,"* torn between the factory's efficiency and *"the risk of losing knowledge."*

## 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/en/fiches/lassiege-usine-logicielle-heure-ia-2026-07-28/