# 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 frames it as such: *"This will be more of a reference page than an article,"* intended for his own resources page. **Subject**: the 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 drawn from the outset**: this is not **vibe coding** in Karpathy's sense (experimentation, letting go) 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 responsibility: *"Even if I don't write the code, I'm responsible for it and must keep control over it."* **The entire tooling answers three questions**, and this is the text's most reusable reading grid: *"What does the agent know?"* (context, memory, code graph) — *"What can it 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` + thematic `.claude/rules/*.md` conditionally loaded via `paths:` + `.agents/*.md` for non-technical content (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 output-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 closing skill**, design in Claude Design, staged delivery behind a feature flag, 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."* ⚠️ **Rare for the genre**: a "To improve" section exposing 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 **absence of packaging** for skills across projects, and above all the admission of tension: *"I'm becoming less and less useful in the implementation phases,"* *"torn between the satisfaction of having an increasingly efficient factory and the risk of losing the 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 closing, 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**, presented as such — *"This will be more of a reference page than an article, and I'll link it from the site's resources page."* 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 setup to compare against their own.

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

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

1. **Modesty about the rules' scope.** *"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 turns prescriptive.
2. **Honest self-assessment of the tools.** On Claude-mem: *"I honestly 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."* **The reader learns what doesn't work, or no longer does.**
3. **The final, unresolved admission.** *"I'm becoming less and less useful in the 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 the knowledge."* The text ends on an open problem, not a conclusion.

**Signature phrases**: *"Even if I don't write the code, I'm responsible for it,"* *"There's no point telling an AI to write quality code, it's meaningless. You have to make your own constraints explicit,"* *"What matters must be executable,"* *"Context is a budget,"* *"1 bug fixed, 10 introduced,"* *"Spec documentation dies if its closing 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

- **⭐ The three-question grid — the most reusable takeaway**: all the tooling answers *"What does the agent **know**?"* (context, memory, code graph), *"What can it do **deterministically**, without improvising?"* (skills, procedures), *"What **stops it** when it gets it wrong?"* (hooks, architecture tests, quality gates). **Instant audit grid**: held up against any agentic setup, it reveals within three minutes which of the three is empty. The third one almost always is.
- **⭐⭐ The guiding principle, worth memorizing verbatim**: *"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."* Stated even more sharply elsewhere regarding architecture tests: *"it can't be bypassed, **unlike a rule**."* → **A rule is an intention, a test is a guarantee.** This is the same thesis as the constraint ring in [[sfeir-code-review-anneau-contraintes-2026-07-30]] (published two days later) and the harness in [[osmani-agent-harness-engineering-2026-04-19]], but **demonstrated on a real, solo setup**, not stated as doctrine.
- **Explicitly against vibe coding**: *"Vibe coding as defined by Karpathy was experimentation and letting go. Here, I'm going to talk about context engineering."* And the resulting responsibility clause: *"Even if I don't write the code, I'm responsible for it and must keep control over it."* Cf. [[karpathy-vibe-coding-agentic-engineering-software-3-0-2026-04-29]].
- **Software quality is not code quality**: it includes **intention** (why, for whom) and **Marty Cagan's four risks** — *Value, Usability, Feasibility, Viability* — plus performance and reliability. This is what justifies layer 6 (product process) and explains why a purely technical software factory misses the point.
- **Layer 1 — context, and the move worth copying**: three levels separated by their **loading moment**. Root `CLAUDE.md` (architecture, cross-cutting conventions, spec index) → permanent and **short**; `.claude/rules/*.md` → **conditional**, activated by a `paths:` frontmatter (the Kotlin rule loads only when touching `api/**/*`); `.agents/*.md` → **non-technical** context (product positioning, personas, tone). ⭐ **The rule, seen in full, is a routing table**: it doesn't contain the procedures, it lists nine skills with the task that triggers each, to be opened only when needed. *"If the AI isn't making a schema change, there's no point opening the db-migration skill."* → **Permanent context carries the index, not the content.**
- **⭐ A long-term constraint encoded as context *and* as a test** — the text's best example: 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** (no file on the "open" side references the "proprietary" side; every production file belongs to one side or the other). *"Writing a future constraint into the context avoids paying for a rewrite later."* → **A decision that doesn't exist yet can already be mechanically guaranteed.**
- **The line that kills the magic prompt**: *"There's no point telling an AI to 'write quality code,' it's meaningless. You have to make your own constraints explicit."* Paired with rare honesty: *"A constraint is specific to a project and a person… Using feature flags isn't better or worse, it's just my preference."*
- **Layer 2 — skills**: *"a procedure written once, replayed identically."* **Existence criterion: the third repetition.** About thirty, across six families (backend, frontend, data, product cycle, operations/runbooks, writing). Two lessons: **"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"*), and **"docs up to date"** skills are critical on fast-moving code. ⚠️ Operational nuance: *"This automatic loading can sometimes fail. In that case, you have to explicitly ask to use the 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]].
- **Sub-agents, in decline**: reserved for tasks *"that generate a lot of reading without much decision-making"* (audits, broad exploration, doc drafting) — they *"consume their own context and return a conclusion, not a file dump."* But: *"I use them less and less, recent agents do fairly targeted delegation themselves."* **Signal of evolution**: a tooling practice partly made obsolete by the model.
- **⭐ Layer 3 — GitNexus, the setup's most interesting tool**: the repository is indexed as a **graph** (symbols, relations, execution flows), which yields `impact(symbol)` **before** modifying (blast radius, callers, risk level), `detect_changes()` **before** committing (*"did I only touch what I meant to?"*), searching for an **execution flow** rather than grepping a function name, and renaming **via the call graph** rather than find-and-replace. And the justification, which matters more than the tool itself: *"The real issue isn't speed, it's **detecting all the side effects** of a change."* → carried over into rule #4: *"Measure impacts before and after the edit. We want to avoid the '1 bug fixed, 10 introduced' effect."* **Worth comparing to structured code-graph context versus vector RAG** — the same family of argument as the Compare the Market result cited in [[sfeir-code-review-anneau-contraintes-2026-07-30]].
- **MCP, with a cost caveat**: *"I try to avoid MCPs that consume more context, but I still have a few"* — JetBrains IDE (build, inspections, refactorings, indexed search), GitNexus, business services (payment, monitoring), database, browser. **MCP is treated as a context expense to justify**, not a given.
- **Layer 4 — hooks: the definition that matters**: *"scripts triggered by the agent's **harness**, not by the agent itself."* Two production uses: before a shell call, **reject the native build** and redirect to the IDE build (faster, structured errors) while explaining the fallback; after a file write, **run the formatter/linter**. Other cited uses: blocking edits to generated files, requiring a test alongside any new module, forbidding a dangerous pattern.
- **⭐ Pattern linting — the distinction worth keeping**: **ESLint** for syntax, **`ast-grep` for *architecture decisions*** (example: *forbidding any `fetch` call that bypasses the OpenAPI client*), **typecheck** for typing. → **An architecture decision can become a lint rule.** This is the missing link between "we decided" and "it's enforced," and it costs a few lines.
- **Layer 5 — the gate**: `push to main → quality gate (lint → pattern lint → typecheck → tests) → build docker image → push to registry → deployment webhook`. **The structural point**: the deployment job has a **`needs:` on the quality job**. *"Nothing ships to production without passing the gate. That's essential as a general rule, even more so for automatically produced code."* Five test stages: unit (heavily), integration **with disposable containers** (*"real database and broker, no mocks"*), architecture, front-end components, **end-to-end on critical paths only**. Cf. [[williams-adlc-3-tests-are-the-spec-2026-06-12]] and [[williams-adlc-2-two-human-gates-2026-06-12]].
- **Layer 6 — the product process, and the step everyone forgets**: numbered specs (one per functional domain, indexed in the permanent context) framed by **two** skills — one for **drafting** the spec and its plan, **one for closing it out** by updating it with what was actually built. *"Without it, specs become obsolete within six months,"* and as a final rule: *"Spec documentation dies if its closing isn't part of the process."* ⭐ **Closing-out is the part of the documentation cycle that almost never exists elsewhere.**
- **Anti-hallucination rule for specs**: *"If a spec is unclear or inconsistent with the existing system, the agent must ask, not guess."* A single line of context addressing agentic development's costliest failure mode.
- **Staged delivery, and its rationale**: the spec is designed to be delivered in stages protected by a feature flag, *"it lets me do several small implementation sessions rather than one big session, which tends to degrade in quality once it fills up too much."* → **Here, product decomposition is dictated by long-context degradation**, not project management. Useful distinction: **feature flipping** (Unleash — turning things on/off without redeploying: rollout, kill switch, maintenance) vs **gating** (configuration table + service — restricting by customer contract or plan). Two mechanisms, two needs, and a skill so agents don't conflate them.
- **Where to start (order given, and it's a good one)**: (1) **the quality gate first**, if it doesn't already exist; (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. ⚠️ **Security warning**: *"any skill, MCP, or code pulled in from outside must be scrutinized. These are dependencies that can be attack vectors."* Worth comparing to the agentic attack surface described in [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]].
- **⚠️ Lived limitations — the section that makes the page credible**: 1. **Rule obsolescence isn't measurable.** *"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."* → **Accumulated context decays at the pace of the models, and nothing tracks that decay.** This is the field's real methodological gap, and it's named here without a solution. 2. **The rabbit hole.** A `boyscout.md` rule (*"always leave the code a bit better… flag improvements for me"*) produces *"endless sessions"* and cognitive overload. Envisioned fix: route these findings into a **TODO list** and move maintenance into a separate, partially automated workflow. → **A good continuous-improvement instruction turns into a drift generator when the agent doesn't stop on its own.** 3. **No packaging.** Skills and rules are **copy-pasted from project to project**, sometimes machine-dependent. Missing: a way to package for deployment and **centralize maintenance**. 4. **Dependence on Claude**, judged a *"moderate risk"* (*"the whole ecosystem is moving upward"*), with an interest in testing open-weight models — blocked by hardware. And **the IDE has become a poor fit**: *"I still use IntelliJ but I no longer find it suited to our era. I haven't yet seen an interesting alternative."*
- **⭐⭐ The underlying admission, worth quoting verbatim**: *"The latest versions of Opus are increasingly autonomous… It's borderline unsettling, and more rigorous than 99% of humans. Let's be honest, I'm becoming less and less useful in the 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 the knowledge**."* → This is exactly the **comprehension debt** from [[osmani-cognitive-surrender-comprehension-debt-2026-05-05]], voiced from the inside by someone who built the most complete harness possible **and observes that the harness doesn't solve that particular problem**. The setup guarantees the code is correct; it doesn't guarantee the human still understands it. **The text's open question**: *"I need to find a way to check the designs after the fact, to make the result my own."*
- **⚠️ Scope not to overstate**: a **solo** setup, on **personal products**, with a single decision-maker. No multi-developer coordination, no peer review, no compliance or audit constraints — the "who validates" layer is occupied by a single person who is also the author of the rules. What carries over to a company setting: **the three-question grid, the executable principle, spec closing, pattern linting**. What doesn't carry over as-is: the total absence of any human gate other than oneself.
- **Meta / related**: a practitioner's demonstration of [[osmani-agent-harness-engineering-2026-04-19]] and a direct cousin of [[sfeir-code-review-anneau-contraintes-2026-07-30]] (published 2 days later, same thesis: quality lives in the ring of constraints, not in the code); the same "software factory" vocabulary as [[wescale-usine-logicielle-augmentee-juge-strategique-2026-05-03]], but at the scale of one individual; stands in opposition to the vibe coding of [[karpathy-vibe-coding-agentic-engineering-software-3-0-2026-04-29]]; converges with [[klaassen-teach-ai-think-senior-engineer-every-2025-11-07]] on making constraints explicit; to be read alongside [[shihipar-claude-code-lessons-building-skills-2026-06-03]] on skills and [[williams-adlc-3-tests-are-the-spec-2026-06-12]] on tests.

## 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, was 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 isn't delegated: *"Even if I don't write the code, I'm responsible for it."* And software quality goes beyond code — it includes intention and **Marty Cagan's four risks**.

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

**Six layers.** **Context** is layered by loading moment: a short, permanent root `CLAUDE.md`, conditional `rules` activated by path, `.agents/*.md` for personas and positioning — a rule acting as a **routing table** toward skills to be opened only when 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 a change's blast radius — *"the real issue 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 closing skill** — *"without it, specs become obsolete within six months"* — delivered in stages behind a feature flag.

**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 isn't measurable; a boyscout rule produces endless sessions; skills get copy-pasted for lack of packaging. And the final admission: *"I'm becoming less and less useful in the implementation phases,"* torn between the factory's efficiency and *"the risk of losing the 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/