The Intent Is the Attribution

Benni Mack
Benni Mack more

This year I was on the road a lot: conferences, meetups, customer workshops, and in between at our headquarters at b13. One sentence came up again and again, from people working on very different projects: “I haven’t written a line of code myself in weeks.” Some said months. And recently, nobody said it as a confession anymore.

In the same year, the TYPO3 community and many others discussed how to mark AI-generated code. Written by AI, reviewed by AI, assisted by AI. Should every commit carry an Assisted-by line, and where exactly does assistance start?

I tried to believe others such a line was helpful. I don’t anymore. What I want to know about a change is why it was made, whether it solves the right problem, and who is responsible for it. None of this depends on who or what typed the code.

The Background

The numbers back up what I heard. In the Stack Overflow Developer Survey 2026, only 17% of developers say they don’t use AI tools at all, and two thirds use coding assistants or agents. aifoc.us counted Claude Code going from 0.7% to 4.5% of all public commits on GitHub within six months, and that only covers commits which say so.

The harder question is what counts as “assisted”. Autocomplete finishing a line. A chat explaining an old piece of code. Claude Code looking into a failing test. A generated migration, a docs page, a commit message. An agent writing most of a feature while a developer reviews it. We’ve had IDEs, code generators, PHP-CS-Fixer and Rector for years, and nobody ever listed them in a commit. AI is a much bigger step, but the line between help and generation gets blurrier every month.

Ask ten developers when they would add Assisted-By, and you get ten answers. Some add it for autocomplete, some only when an agent wrote the whole feature, some never. For a reviewer, that line carries almost no information. Once AI is part of nearly every commit, it carries none.

How Other Projects Handle It

Open source projects came to different conclusions. The Linux kernel, Fedora and the Apache Software Foundation allow AI-assisted contributions and ask for disclosure. Ghostty is built with plenty of AI itself, but is strict with outside contributions. QEMU, Gentoo and NetBSD went the restrictive way, mostly because of copyright.

I understand all of them. Maintainers review contributions in their free time, and nobody wants to spend an evening on generated patches the submitter never looked at.

Still, Linus Torvalds made a point in the kernel discussion about guidelines for AI tools that stuck with me: “The documentation is for good actors.” Somebody sending a bad patch won’t label it. Somebody using AI responsibly ends up discussing the label instead of the change. Daniel Stenberg said something similar when curl ended its bug bounty in January. The problem was low-effort reports, “AI generated or not.”

So we should judge a contribution by its quality and by the person responsible for it, not by the tools used. Where licensing or legal questions require disclosure, it still makes sense. A generic trailer on every commit doesn’t solve these questions.

Commit and Issue

Every TYPO3 Core commit links to a Forge (our ticketing system) issue with a Resolves: line. I always liked this, because it keeps the context. Somebody described a problem, people discussed it on Forge, in Slack or on Gerrit, and eventually someone pushed a patch. The commit tells you what changed. The issue tells you why.

This becomes more important now. Agents already investigate bugs, change code, write tests and prepare patches, and soon they will do a good part of the routine work around issues too. I’m fine with that. But I still want to know who needed the change, which problem it solves, what alternatives were considered, and who decided this is the right way. An agent can help find the answers. A person has to own the decision.

That person doesn’t need twenty years of Core experience. Sometimes a newcomer has the better idea, and that’s one of the best things about open source. What counts is a reason behind the change and somebody who stands behind it.

Sign-Off

The other half is responsibility. The Linux kernel has used Signed-off-by and the Developer Certificate of Origin for over twenty years: by signing off, you certify that you may submit the change under the project’s license. The kernel’s guidelines for coding assistants say it plainly: “Only humans can legally certify the Developer Certificate of Origin.”

TYPO3 has its own workflow on Gerrit. Several people review and test a patch, and a member of the Core team merges it. The rule behind that is “you break it, you fix it”: whoever merges a change is responsible for it.

I prefer this to any Assisted-by line. Whether I wrote the code myself, worked with an agent, or picked up somebody else’s patch: if I merge it, it’s on me. AI doesn’t make that responsibility smaller. If anything it grows, because generating code got cheap, and reviewing and understanding it is now the expensive part.

And responsibility doesn’t end with the merge. Every line we add has to be maintained, patched and understood for years. In TYPO3 we know this from our LTS releases: shipping a feature is the easy part, supporting it for three years is the actual work. With the EU Cyber Resilience Act, “who maintains this?” is no longer only a community question but a legal one.

My short version: a person defines the intent, AI may help with the work, a person takes responsibility for the result.

Not a Free-for-All

Dropping the label doesn’t mean dropping the rules. A few things apply no matter how much AI you use:

And then there’s learning. If juniors never have to understand code because an agent always fixes it, who will review our patches in ten years? I don’t have the answer yet. But it’s the discussion I’d rather have than one about another trailer.

The People

My first change to TYPO3 Core went into version 4.1. I was new, I had an idea, and the Core team at the time let me have a go. Nobody asked which editor I used. They reviewed my patch, explained things, and sometimes told me that my solution wasn’t a good one. Twenty years later I’m still here, and that’s because of these people, not because of the code.

TYPO3’s claim is “Inspiring people to share”, and something is changing here, too. Back then I asked my questions on the mailing list, later in Slack, at sprints and at conferences. Often a short question turned into a long discussion, and sometimes into a friendship. Today many of these questions go to an AI assistant and come back in seconds. I do that myself all the time, and it’s useful. But each of these questions is one conversation less with another developer.

At b13 we use AI in almost everything, from upgrades and debugging to Core contributions, and we won’t go back. What I want is to put some of the time we save into the things that made open source work in the first place: good issues, careful reviews, helping newcomers, sharing what we learned, and meeting in person at Code Sprints, Developer Days and conferences. The tools will change again next year. The community is the reason TYPO3 is still here after more than 25 years.

For me, the Assisted-by question is closed. I care about why we change something, whether it’s good, and who stands behind it, and that we still have people who want to do this together. If you see it differently, let me know, ideally in person at the next event, or get in touch.

References

More Articles by Benni Mack