{"id":94,"date":"2026-10-27T16:00:00","date_gmt":"2026-10-27T15:00:00","guid":{"rendered":"https:\/\/hoja.in\/blog\/senior-engineering-with-ai-agents-what-changed-in-my-day\/"},"modified":"2026-10-16T14:00:12","modified_gmt":"2026-10-16T12:00:12","slug":"senior-engineering-with-ai-agents-what-changed-in-my-day","status":"publish","type":"post","link":"https:\/\/hoja.in\/blog\/senior-engineering-with-ai-agents-what-changed-in-my-day\/","title":{"rendered":"Senior engineering with AI agents: what changed in my day"},"content":{"rendered":"

I started writing PHP for money in 2012, at Vismaya Infotech, and I have been a TYPO3 developer for most of the years since. PIT Solutions in Trivandrum, Bloom in Munich, and since 2023 jweiland.net in Stuttgart. In all those years, my day changed slowly: new versions, new frameworks, Composer, then DDEV, then site sets. The last two years changed it faster than the ten before.<\/p>\n

Today a large part of the typing in my projects is done by an AI agent, mostly Claude Code with plugins, skills and hooks I wrote for TYPO3 work. This is not a post about how amazing that is. It is about where my time goes now, and what I think it means for people who are earlier in their career. Opinion piece, so take it with a cup of tea.<\/p>\n

Where my time goes now<\/h2>\n

I used to spend most of a typical upgrade day on mechanical work. Find all usages of a removed API, fix them one by one, run the tests, repeat. That is exactly the work an agent does well, and it does it while I think about other things.<\/p>\n

What I do instead falls into three buckets.<\/p>\n

1. Scoping<\/h3>\n

Before the agent touches anything, somebody has to decide what the job actually is. For the move of my own site hoja.in from TYPO3 7.6 to 14.3, the most important decision was made before any code: no seven-hop in-place upgrade, but a fresh v14 project with a content import. Which extensions to replace (powermail by EXT:form, realurl by core routing), which to drop, what counts as “done”. The agent can propose all of this. It cannot own<\/em> it, because it does not carry the consequences when the contact form silently stops sending mail.<\/p>\n

A good scope is also what makes the agent useful. “Upgrade the site” is a wish. “Import pages below uid 6 with their original uids, map the powermail element to EXT:form, and prove it with these seven URLs against the old site” is a task.<\/p>\n

2. Review<\/h3>\n

Reviewing is now the biggest part of my day, and it is harder than before. Human code has a kind of fingerprint: you see where the colleague was unsure, where they copied, where they were tired. Agent code is evenly confident everywhere. The wrong line looks exactly as tidy as the right one.<\/p>\n

So I review differently. I read the diff with the changelog open, and I ask the agent for the source of each change, not just the change. I look at what is missing<\/em> as much as at what is there: the field that was not copied, the edge case without a test. And I do not trust a sentence like “all tests pass” in a summary. I run them myself, or I read the output.<\/p>\n

3. Saying no<\/h3>\n

This one surprised me. An agent is very willing. It will happily add a fallback for a case that cannot happen, a compatibility layer nobody asked for, a fourth abstraction. Each one looks reasonable in isolation. Together they make code nobody wants to maintain. A big part of my job is now to say “no, delete that, keep it simple”, many times a day.<\/p>\n

Saying no also means saying no to the agent’s shortcuts. When a check fails, the easiest fix for any eager worker is to weaken the check. That is why some rules in my setup are not prompts but hooks: database writes need a fresh dump, and --no-verify<\/code> on a commit is blocked. I do not want to rely on politeness for the things that cannot be undone.<\/p>\n

Why tests and review matter more than before<\/h2>\n

When I wrote everything by hand, my speed was the limit, and my speed also limited my mistakes. With an agent, the amount of change per day goes up a lot. The amount of attention I have does not.<\/p>\n

So the safety net has to be automatic. For hoja.in, the most valuable artifact was not any clever piece of code. It was a boring smoke test baseline: status code, size and title of the old site’s pages, captured before anything changed, and compared after every step. When a step broke something, the comparison said so, no matter how convincing the summary sounded. In my experience, a team that has good tests can let an agent do a lot. A team without tests should invest in tests first and agents second.<\/p>\n

What juniors should still learn by hand<\/h2>\n

I trained juniors at PIT Solutions, and I think about this question a lot. My honest answer: the things you need in order to judge<\/em> the agent’s work, you must have done yourself at least a few times.<\/p>\n