How I develop with an AI agent: lessons from this site and Zyvra CMS

I build this site and Zyvra CMS, the CMS it runs on, together with Claude Code, an AI agent. It is not autocomplete in an editor: the agent works in a terminal with my repositories, reads code, runs tests, commits and deploys changes to the server — on my tasks and within my rules.

The first commit of the CMS landed on October 8, and on October 12 this site was already running on it. Since then it has gained forms with files and emails, a blog, services and security headers. The two repositories now have about 470 automated tests. Here is how it works and what I have learned along the way.

Who does what

I set the task and decide what counts as done. I choose the architecture and the stack and make the decisions that carry a cost: what to publish, which data to keep, whom to let in where. I read the diffs and check the result in a browser.

The agent writes code, tests and documentation, runs the checks, reads logs and other people's code. When replies to submissions had to open in the SOGo web mail, it did not guess: it read the JavaScript of SOGo itself and found the address SOGo opens a new message with.

Rules instead of prompts

Good results come from standing rules, not from lucky wording. I keep them in an instructions file the agent reads at the start of every session:

• think first and state the assumptions, and ask when something is unclear;

• the least code that solves the task, nothing "for the future";

• change only what the task needs, and clean up after yourself;

• turn a task into a goal that can be checked: "fix the bug" means "write a test that reproduces it and make it pass".

The same file holds the style: BEM in SCSS, colors only through variables, commits in the Conventional Commits format. Decisions about the project go into the agent's memory: for example, that client cases are published anonymously, with no names in the texts and with logos blurred in the screenshots. A week later the rule applies by itself, with no reminders.

Done means checked

The agent is quick to say "done". So only what passed the checks counts as done: types, the linter, unit, integration and end-to-end tests, and for an interface, screenshots from a real browser. The agent does not see a page until it captures it with Playwright, and this rule catches a lot.

An example: when I added a Content Security Policy to the site, the end-to-end tests failed. The default error page of Nuxt inserted an inline script, and the policy blocked it. Instead of weakening the policy, the site got its own 404 page. Without a test that fails on any error in the console, visitors would have found it.

After a deployment the agent checks the live site: opens the pages, looks at the response headers and the browser console.

What one task looks like

A recent example is the Reply button on a submission in the CMS: it had to open the web mail instead of a desktop mail app.

1. The agent looked at where the settings of a form live and suggested a setting of the form instead of an address hard-coded into the code: the CMS is generic, and different forms may go to different mailboxes.

2. It found the format of a new-message link in the code of SOGo.

3. It added a migration, the schema, a field in the admin and tests at every level, and updated the docs.

4. It checked everything in a browser, committed and deployed to the server, backing up the database before the migration.

My part was setting the task and checking the result.

Where the agent goes wrong

• It guesses instead of reading. A field name in an API response, the version of a record, a file path: the first guess is often wrong. The cure is to require a look at the code or the docs first.

• It draws conclusions from an incomplete search. Once the agent said that a sent form was not counted in analytics. It was: the agent had searched for umami.track, while the code said umami?.track.

• It does not know the environment. Emails from the CMS were not going out, although the tests were green: the mail library looks up the server through DNS and does not read /etc/hosts. We found it in the server logs and fixed it with a TLS server name setting.

• It slips on shell details. A pkill -f once killed the very shell it was started from.

All of these are caught the same way: by checking, not by trust.

What stays with me

• Access and secrets. Passwords go neither into the chat nor into the shell history: the agent passes them through files with 600 permissions or through stdin.

• Production. Writing to the live database, sudo, publishing: only with my explicit permission. When the site went down because of routing on my home server, the agent found the cause, but I ran the sudo command myself.

• Decisions with consequences. Prices, texts about clients, what to publish and what not. The agent offers options and warns about the risks; I choose.

The bottom line

An AI agent does not replace a developer, but it changes the work: less typing, more setting tasks, architecture and review. The speed comes when the agent has rules, tests and a duty to check its result. Without them it does the wrong things just as fast.

How the CMS itself works is in the Zyvra CMS case. And if you want to launch your own site or account just as fast, get in touch.