Early in the work on yesid.dev, I chose a clear CMS boundary: repeated shared interface content was supposed to come from the CMS instead of staying in frontend files. Claude produced the implementation, and I checked the files against that boundary. I found shared copy still hardcoded in the frontend. Hardcoded text and CMS-backed text can produce the same pixels. A browser check proves that the page renders, not which system owns the content. The file check showed that the implementation did not yet match the content model I had chosen.
Claude was my primary implementation tool for yesid.dev and transit.yesid.dev. Codex mostly reviewed the work and sometimes stepped in as a backup implementer. I oversaw both projects from A to Z and made the architecture decisions. I kept the project context, decided how the parts should fit, gave direction, inspected results, found problems, and moved the work forward.
The work became more managerial. Instead of typing each implementation, I was directing the projects, keeping the architecture in view, and checking what came back.
The yesid.dev repository also has mechanical checks today for generated content and Svelte warnings. The pre-commit hook and PR CI compare CMS-generated modules with their recorded manifest. PR CI runs this check for pull requests targeting main or develop. The comparison catches ordinary drift between the modules and manifest, but it checks consistency, not whether the CMS produced the files. The local hook can be skipped, and a coordinated module-plus-manifest edit can still agree.
The web check uses a configurable warning lock specifically for Svelte. It fails when reported warnings exceed that lock. These checks cover repeatable repository conditions. They do not decide whether the CMS architecture is right or whether a piece of content belongs in the frontend. That remains a project and architecture decision.
My process starts with a conversation and my rambling. AI organizes the material into a skeleton and supplies wording in blocks. An article carries my name only after I check and correct the structure, claims, and wording, use those corrections in another AI draft, read every block from A to Z, and decide what stays.
If a client wants to know whether I understand what I publish, quiz me about anything on this site.
AI is one tool among many. It is not the end result. The results are yesid.dev, transit.yesid.dev, and the systems that make their content and services work.
After I deployed Transit, I also had to keep it running and pay the monthly infrastructure bill.
This is chapter 4 of a six-chapter epic. Chapters 1–3: who I am. Chapters 4–6: what I build. Previous: Thinking in matrices · Next: $50 to $0: an Oracle Always Free VM.
Need a system that stays editable?