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.
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.
Where my time goes now
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.
What I do instead falls into three buckets.
1. Scoping
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 it, because it does not carry the consequences when the contact form silently stops sending mail.
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.
2. Review
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.
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 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.
3. Saying no
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.
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 on a commit is blocked. I do not want to rely on politeness for the things that cannot be undone.
Why tests and review matter more than before
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.
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.
What juniors should still learn by hand
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 the agent’s work, you must have done yourself at least a few times.
- Debugging without help. Reading a stack trace, adding a breakpoint, finding out why a TypoScript condition does not match. If you cannot do this, you cannot tell a real fix from a lucky one.
- Reading the core. When the documentation and the agent disagree, the source code of TYPO3 decides. Open the class, read it. It is less scary than it sounds.
- Writing a migration by hand once. Take one extension from one version to the next without Rector and without an agent. It is slow and annoying. Afterwards you understand what the tools do, and you see when they guess.
- SQL and the database. Agents are confident with queries. Know enough to see when a query will be slow or will touch more rows than intended.
- Writing a clear task. This sounds soft, but it is a technical skill. If you cannot describe the job and the definition of done in a few sentences, neither you nor the agent will know when you are finished.
Then use the agent for everything else, and use it a lot. I am not romantic about typing. I just want people to know what good looks like before they approve it.
What has not changed
The customer still wants a website that works on Monday morning. Editors still need a backend they understand. Public institutions and associations, the sites I work on at jweiland.net, still need accessible pages and careful upgrades more than they need novelty. The responsibility for that stays with a person. The agent made the typing cheaper, but it did not make the decisions cheaper. If anything, every decision now has more code behind it.
Feedbacks are the champion’s breakfast, so if your day changed in a different way, tell me in the comments. I am curious.