Owning the output when you use AI agents
I've noticed a habit in conversations about AI that I'm trying to catch in myself: "Look what my agent is doing."
I get the excitement. It's interesting watching a tool take on work that you previously had to do yourself. But the constant mention of the agent is getting a bit boring, and I think the way we talk about it makes it easier to distance ourselves from the output. If I'm putting a change forward under my name, I own that change.
We used to get excited about our IDEs too. We'd share a useful extension or show someone a refactoring shortcut. I don't remember us crediting the IDE in everyday updates nearly as often as we now credit agents. Usually, we'd just say we'd made the change.
There's still a useful conversation to have about how we work. If we're comparing approaches or explaining how we automated something, the agent belongs in that discussion. But when someone asks what's changed, "I've updated the validation" tells them what they need to know. "My agent has updated the validation" leaves me wondering whether you've checked it yet.
That distinction becomes more uncomfortable when something goes wrong.
I've seen "my agent did it" turn into "I didn't do that, my clanker did." Sometimes it's a joke. Even then, it gives us a convenient way to talk as though the mistake belongs to someone else. We were happy to show off the output a moment ago; now there's a bit of distance between us and the thing we submitted.
An agent can absolutely produce a bad change. Describing what it did may be necessary to understand the failure. We still need to explain our part in allowing that change through.
For example, "The agent removed that check, and I missed it during review" gives us something to work with. We can investigate why it removed the check and why the review didn't catch it. "The agent did it" on its own leaves the accountability unresolved.
The comparison I keep coming back to is leadership.
If a team delivered a change that caused a problem, I'd have very little confidence in a lead whose response was, "I didn't do it. Someone on my team did." I'd expect them to help understand what happened and take responsibility for their part in the outcome. That includes the direction they gave and how the work was checked before it reached other people.
The person who made the mistake still has responsibility too. A lead owning the outcome doesn't erase everyone else's contribution or mean pretending they personally wrote every line. It means they can't use delegation as a reason to stop caring about the result.
I think that expectation applies when we delegate work to agents. If I decide an agent can make changes and submit them through my account, the amount of freedom I've given it is part of my decision. "It did that without asking me" should prompt me to look at the permissions and review process I've set up.
This makes me wonder whether some of what we're seeing is people encountering delegation for the first time.
You can be an experienced developer without having led a team. Then you start using agents, and suddenly you're deciding what work to hand over, giving enough context for someone else to carry it out, and judging whether the result is ready. Those responsibilities overlap with parts of leadership, even though working with software is very different from working with people.
I don't know whether a lack of leadership experience explains the habit. Experienced leaders can shift blame too, and some of it may just be excitement about the tools. I'd be interested in talking about that over an in-person social: what experience helps someone delegate well to an agent, and what do we need to learn when we haven't done that before?
For now, I'm trying to change how I give updates. I'll say what I've changed and what I've checked, and mention the agent when its involvement helps explain the work. If something slips through, I want to be able to explain what I missed and what I'm doing to fix it.