Context Engineering for a 100%-Generated Software Factory

Key takeaways

1. 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.
2. 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]].