Why a manifesto, not a portfolio
A classic portfolio answers an implicit request: show me what you can do, then I will decide whether you are interesting. This site starts somewhere else. It tries to make a posture legible: how I think about design leadership, how I formalize methods, how I learn by working with AI agents.
That difference changes how the site is made. A portfolio can live on a few polished cases. A manifesto has to hold a voice, an architecture, evidence and the ability to evolve. Good-looking pages are not enough. The system has to make it possible to keep thinking in public without rebuilding everything each time.
Claude Code came in through that door. Not as a magic tool to generate a site, but as an execution partner able to move fast when the direction was clear. Codex took over later, with a different environment and different constraints. The real subject appeared quickly: when the agent can produce a lot, the quality of what we give it becomes the main work.
Code-first as public learning
The first shock was not technical. Astro, Tailwind, MDX, GitHub, Vercel: each piece can be learned. The shock was elsewhere, in building in public, on a real repo, with visible commits, blocking hooks, and mistakes that remain in the history.
For someone who does not come from development, the first Git push is not a detail. It makes a posture visible: learning by doing, accepting that learning leaves traces, not waiting to be an expert before testing. The sentence that stayed from that moment is simple: I was scared, it was magnificent.
That vulnerability was not decorative. It gave the site its coherence. You cannot defend curiosity as a doctrine and hide the places where you are still learning. The site therefore had to show a capability, but also a way of becoming more capable.
Guardrails before volume
The first weeks were mostly about installing limits. Not because the project was technically complex, but because an agent that moves fast also amplifies blurry instructions. Without guardrails, every session redefines the conventions, the voice, the structure, the way to publish.
The system took shape in layers: a documented voice, writing rules, a scanner that flags forbidden paragraph openings and overly automatic markers, Git hooks, commitlint, Prettier, ESLint, Astro check, parity checks across languages, then a CI that replays the same barriers.
These tools do not replace judgment. They free attention. When the linter watches syntax, when the voice scanner catches drift, when the build rejects a broken page, energy can return to where it matters: the angle, the proof, the decision, the sentence that actually carries something.
A craft pass, then a removal
The visual craft phase produced several adjustments that stayed: typography, rhythm, dark mode, transitions, an internal playground. It also produced an experiment that did not stay. The idea was to support active reading: when someone selected a sentence, the site kept a local trace and brought it back on the next visit.
The intention was right. It matched the site’s contract: read, come back, find again what caught your attention. But the implementation touched the rendered text too deeply. Highlighting a selection meant slicing the DOM, injecting tags, handling spaces, headings and navigation between pages. Two correction cycles were enough to show the risk: visual residue, weakened layout, loss of stability on long pages.
The component was removed. Not because the idea was bad, but because its maintenance cost exceeded its value. That decision matters as much as the components that stayed. Craft is not the accumulation of visible gestures. It is also knowing how to remove an effect when it threatens the first quality of an editorial site: remaining readable.
Translating, going live, checking reality
In early August, the project changed nature. As long as the site lived locally, it remained a workshop. Once the content was translated into Spanish and English, the domain connected to Vercel and V1 went live, it became a public surface. That shift forces a different way of looking at details.
Production taught a simple lesson: the production build is the source of truth. In development, drafts stay visible for review. In production, only published content is emitted. The playground exists locally, but it is removed from the public build. What we see in the browser while working is therefore not automatically what others will see online.
The SEO layer arrived in that logic: canonical, hreflang, Open Graph, sitemap, robots.txt, llms.txt, structured data. Not as a marketing layer added at the end, but as a way to tell engines correctly what the site is, which languages the pages exist in, and which versions should not be invented.
The bug the green checks did not see
One incident made the system stronger. The Spanish and English versions of some templates had stayed poorer than the French version after a redesign. The translations were in parity, the build passed, the checks were green. Yet the pages did not tell the same thing visually.
The problem was not the absence of control. It was the wrong control for that specific risk. i18n parity checked translation keys, not page shape. The fix therefore added two guardrails: one check that compares [slug].astro templates across languages, and one check that compares the structure of the generated pages in dist/.
This part sums up much of the learning. A guardrail only proves what it has been asked to measure. If direction has to survive several weeks of work, several languages, several agents and several sessions, it has to become verifiable.
What this site proves now
A few weeks after launch, the site is no longer only a learning story. It has become proof of its own method. The content lives in MDX collections. Public pages are built from a clear source. Translations can arrive without breaking slugs. Production is verified through a documented procedure. Discovered mistakes become tests.
Claude Code accelerated the first weeks. Codex now carries the continuation. That switch is not a tooling detail, it says something about the system: if the method only holds with one specific agent, it is not yet a method. The subject remains direction: knowing what to ask, what to refuse, what to document, what to test, what to remove. An agent can produce code. Alone, it does not know what must still be true in six months.
This is where the project becomes interesting for design leadership. Design-to-code is not only a new production speed. It is a new framing responsibility. The faster the tool executes, the more visible the quality of the system around it becomes.