{"id":64,"date":"2026-10-17T15:00:00","date_gmt":"2026-10-17T15:00:00","guid":{"rendered":"https:\/\/myport.ddev.site\/blog\/letting-an-ai-agent-upgrade-my-typo3-site-with-tests-in-charge\/"},"modified":"2026-10-16T12:00:12","modified_gmt":"2026-10-16T12:00:12","slug":"letting-an-ai-agent-upgrade-my-typo3-site-with-tests-in-charge","status":"publish","type":"post","link":"https:\/\/hoja.in\/blog\/letting-an-ai-agent-upgrade-my-typo3-site-with-tests-in-charge\/","title":{"rendered":"Letting an AI agent upgrade my TYPO3 site, with tests in charge"},"content":{"rendered":"

When I moved my own site hoja.in from TYPO3 7.6 to 14.3 this year, I did not type most of the commands myself. Claude Code did, with a project-migration plugin that I use for TYPO3 upgrades. It made the inventory, restructured the repository into a Composer project, wrote the content import script and the new site package, and upgraded the WordPress blog next to it.<\/p>\n

That sounds like a marketing sentence, so let me say the important part first: the agent did not decide when something was done. A smoke baseline, a verification gate and my own review decided. This post is about that arrangement, and about the places where the agent was wrong.<\/p>\n

Why I did not just say “upgrade my site”<\/h2>\n

AI output looks plausible. That is the problem. An agent can write a perfect-looking summary (“all pages render correctly”) after checking two URLs, or after checking none. I have seen the same pattern in human pull requests too, to be fair. So before any code changed, I wanted three things that do not depend on anybody’s confidence:<\/p>\n

    \n
  1. A baseline<\/strong>: what the old site really delivered, measured.<\/li>\n
  2. A gate<\/strong>: a fixed list of checks that must pass, with real output.<\/li>\n
  3. A ledger<\/strong>: one line per finding, with a status, which the agent must keep up to date and which I can read in two minutes.<\/li>\n<\/ol>\n

    Step 1: The baseline<\/h2>\n

    The agent booted the old 7.6 site in a separate DDEV project with PHP 7.0 and the live database dump, then captured seven URLs: status, final URL, bytes, page title and an error marker flag. This is the real file, shortened:<\/p>\n

    url                                            status  bytes  title                                    error\nhttps:\/\/myport-legacy.ddev.site\/               200     55793  hoja.in | TYPO3 Certified Web Developer  no\nhttps:\/\/myport-legacy.ddev.site\/index.php?id=7 200     60887  About                                    no\nhttps:\/\/myport-legacy.ddev.site\/index.php?id=13 200    62851  Contact                                  no<\/code><\/pre>\n
    Even this step had a surprise. The committed 7.6 core had an empty index.php<\/code>. The agent found it, took the file from the original typo3_src-7.6.10.zip<\/code>, and wrote it into the ledger instead of quietly “fixing” the repository. That is the behaviour I want.<\/p>\n
    Step 2: The gate<\/h2>\n
    The plugin has a verify step that runs the project gate. In plain commands, the gate for this project looks like this:<\/p>\n
    ddev composer show typo3\/cms-core | grep versions   # really 14.3.x?\nddev composer validate\nddev composer check-platform-reqs\nddev exec vendor\/bin\/typo3 cache:flush\nddev exec vendor\/bin\/typo3 upgrade:list              # expect: no wizards left\n# then: the same URLs as the baseline, plus the new ones, compared\n# against the baseline, and new lines in the error log<\/code><\/pre>\n
    The rule was simple: the agent may say “done” only with the gate output in front of it. The final run showed the seven baseline URLs with status 200 and no error markers, plus the new speaking URLs (\/about<\/code>, \/contact<\/code>), \/blog\/<\/code>, one blog post and sitemap.xml<\/code>, all 200. On top of that, a real contact form submission had to arrive in Mailpit, with the visitor as reply-to. It did.<\/p>\n
    Step 3: The ledger<\/h2>\n
    The ledger is a Markdown file with lines like id \u00b7 area \u00b7 status \u00b7 note<\/code>. Status is one of fixed, decision, deferred or open. A few real lines:<\/p>\n
    L04 \u00b7 own-ext \u00b7 decision \u00b7 smslogin dropped (user): no plugin on any page of the live DB\nL11 \u00b7 database \u00b7 fixed \u00b7 Breaking-17406: pages.url removed, blog link page uses pages.link = \/blog\/\nL20 \u00b7 blog \u00b7 deferred \u00b7 no pre-upgrade visual baseline of the blog; check layout by eye\nL23 \u00b7 deploy \u00b7 open \u00b7 production PHP version of the hosting must be >= 8.2<\/code><\/pre>\n
    Two details made it work. First, the ledger separates my<\/em> decisions from decisions the agent took on its own, which are marked “open for veto”. Dropping a cookie bar extension without a v14 release was one of those. Second, “deferred” and “open” are allowed. An honest open item is much better than a fake “fixed”.<\/p>\n
    A guard against the worst mistake<\/h2>\n
    The one thing I could not accept was a lost database. The setup has a hook that blocks database writes when there is no fresh dump. So before the import, before the WordPress database upgrade and before every bigger content change, a dump was written first. The backups folder now has a row of files like pre-v14-import.sql.gz<\/code> and pre-wp-upgrade-blog.sql.gz<\/code>. Each one is a point I can go back to, and that lets me sleep better.<\/p>\n
    Where it went wrong<\/h2>\n
    This is the part most AI success stories skip. The review, done partly by a separate reviewer agent and partly by me, found real problems:<\/p>\n