AI Tires Me Out Differently: Developer Life With an Agent Team

I haven’t written a line of code in months, and I’m still a software developer every day. A report from a wall of pebbled concrete on developer life with AI agents: fatigue, depth, and the question of what’s left of me.

Pebbled concrete, and at some point somebody spray-painted the wall. The graffiti has faded so much that you can only guess what it once said. I’m sitting on top, feet up, jeans, hiking shoes with orange laces. In front of me a tablet in a stand, next to it a small Bluetooth keyboard. If you look closely at the photo above, you can make out a chat interface on the dark screen: that’s where my team sits.

Behind the tablet there’s grass first, then a few bushes, and then the view runs far out over fields and woods to the horizon. The sun is low, it’s slightly hazy. You could take it for a vacation photo. Somebody sitting there like that isn’t working, right?

He is. The photo shows pretty exactly what has changed. My developer life with AI has little left in common with what I called work for almost 20 years. Sounds like a brochure, I know. So I’ll try to take it in order, though I already suspect the order won’t hold.

Ten hours of typing: those days are gone

I’ll just write the sentence down, because it still feels strange: I haven’t written a line of code in months. I no longer sit at the computer for ten hours writing out code, function by function, open bracket, close bracket. Not ten hours of programming anymore but orchestrating: I describe what should be built, and AI agents build it.

It feels strange because to me “developer” always meant: the one who types. Whoever writes the code has understood it, and whoever has understood it is the developer; that’s roughly how the equation went. My day as a software developer now consists of talking, reading, deciding and signing off, and somehow the equation still works out. First, the colleagues.

My team is made of AI agents, and I recast it every day

I’ve gathered a whole team around me: developers, designers, project managers, code reviewers, testers, QA people and a few more roles. All of them AI agents, each with its own brief and its own view of things. How I orchestrate the agents technically is in a separate article; that’s also where the term vibe coding gets to show up. Here I’m interested in what all of this does to the working day.

Depending on the task, I put together a custom team from that pool. A small bug in a form doesn’t need a designer; a new application for a client does, plus someone who does the research beforehand and several who check afterwards. I have information researched, I analyze client problems and processes, and I have software built from that. The closest comparison is probably the site foreman: I don’t lay bricks myself anymore, but I know what a straight wall looks like, and I notice when somebody forgot the foundation.

This post came about the same way, incidentally. I threw my thoughts down, a lead agent brought in a copywriter and an SEO specialist, they built a text out of it, and I read it and approved it. How much I knocked over in between, I’m keeping to myself ;) I’ve built my own AI assistant once before; this is the sequel with more staff.

Does AI make you tired? It tires you out differently

There were days when I was done after four hours. Four hours of high concentration, holding one problem with all its branches in my head, and after that, nothing but mush up there. Today I’m still fit after an eight-hour day. I didn’t imagine those four hours, by the way: in 1993, Anders Ericsson and colleagues observed in their paper on deliberate practice that top musicians gain nothing more beyond roughly four hours of concentrated practice a day. Fits my four hours, even if practicing the violin isn’t programming.

Others report the exact opposite, though. The developer Simon Willison says he fires up four agents in parallel and that “by like 11 AM, I am wiped out for the day”. In March 2026 the Harvard Business Review even put a word for it into circulation: “brain fry”, mental exhaustion from excessive use or oversight of AI, based on a survey of 1,488 US workers. And Addy Osmani writes in “Your parallel Agent limit” about “comprehension debt”, and about a background restlessness called “ambient anxiety” when several agents run at once.

Ok, so which is it? Over there it’s AI brain fry by eleven, and I’m still fit after eight hours. I don’t know why it’s different for me, and I don’t trust anyone who claims to know exactly. I have guesses. Maybe this is still the honeymoon for me. Maybe, after years of deep concentration, anything that isn’t deep concentration simply feels lighter. Maybe I just don’t notice it yet; burnout isn’t a new topic on this blog, I’ve written about burnout first aid here before.

Yes: AI tires you out differently. Because I don’t get to the evening untouched either. My AI fatigue just comes from a different corner: from the many decisions, from switching between topics, from keeping a constant overview of things running in parallel. The battery used to be empty after deep concentration the way it is after a long run. Today it feels more like after a big family gathering: did nothing physical, but talked to everyone and listened to everyone.

Several problems a day instead of one per week

I used to concentrate on one specific problem for a week. Today I skim several problems a day, and my agent team goes deep. I drop by, ask questions, read results, decide, and I’m already on the next topic while the digging goes on behind me.

What does that do to you? First of all it’s fun, I’ll admit that. As a generalist you suddenly get your money’s worth: research, process analysis, design, architecture, copy, all in one day and always with someone at your side who knows the details. The work feels less like a mine and more like an editorial meeting.

Actually I wanted to celebrate breadth in this section. Just noticing, though, that something else is on my mind: I skim. I used that word myself a moment ago, and it isn’t exactly flattering. If you skim, you don’t stay anywhere, and if you don’t stay anywhere, you end up knowing a lot of things by sight. And that brings me to the question I like to dodge.

How much depth of my own do I still need?

The criticism is obvious: you stop going deep yourself. My first reflex is a shrug. But how important is that really? Depth was never an end in itself; the client pays for a solution that works.

Ok, that’s too cheap. I can only judge what my team delivers because I did the digging myself for almost 20 years. I recognize a shaky architecture by its smell, and I picked up that sense of smell in exactly the weeks I no longer need today. What does someone live off who never had those weeks?

There are numbers on this that I don’t like, which is why they belong here. In January 2026 Anthropic published a study with 52 mostly junior developers: in the comprehension test the group with AI help scored 50%, the control group 67%, and the biggest gap was in debugging. So an AI vendor, of all people, measures that you understand less with AI. That’s the strongest objection to everything I’m writing here. I have the depth from before at my back; someone just entering the profession doesn’t.

Maybe it’s enough to have been deep once. But maybe it evaporates when you stop practicing, like a foreign language you never speak again after school. Maybe a different kind of depth emerges too, one in asking questions and in judging. What if depth simply moves to a new address? Don’t know. I’m watching it in myself and I’ll let you know.

“AI code is bad”: that used to be true

And now to you, you guardians of quality in my LinkedIn timeline. “AI-generated code is garbage, no human can maintain that afterwards, and the security, and the technical debt, blah blah blah.” Yeah yeah. Absolutely. You even had numbers on your side: in the summer of 2025 METR had 16 experienced open-source developers complete 246 tasks, and with AI they were 19% slower, even though they themselves believed it had sped them up. In December 2025 CodeRabbit counted, across 470 pull requests, an average of 10.83 issues in the AI contributions and 6.45 in the human ones, so roughly a factor of 1.7. AI produces junk, granted. I produced junk for almost 20 years, by hand, every bug one of a kind, and nobody ever commissioned a study on that.

So in 2025 you could put it that way. Only something has happened since, and you see it best at the same source. METR wanted to repeat the study and, in its update from February 2026, calls its own new data an unreliable signal, among other things because 30% to 50% of developers said they were choosing not to submit some tasks: they did not want to do them without AI. A study goes into a skid because the participants no longer want to work without AI. Wild. After conversations with the participants, METR itself believes it is likely that developers are more sped up from AI tools now, in early 2026, than in its estimates from early 2025. Simon Willison names November 2025 as the turning point; since then, he says, “almost all of the time it does what you told it to do”, and in his words: “Probably 95% of the code that I produce, I didn’t type myself.” In April 2026 Sundar Pichai said that 75% of new code at Google is AI-generated and approved by engineers, up from 50% the fall before.

Sure: adoption is no proof of quality. I don’t know of any independent measurement that shows outstanding AI-generated code quality for 2026. I can only tell you what I see every day, and that’s the opposite of what it says in the timeline: on my projects, quality today, in 2026, is outstanding. Better tested and better documented than a lot of what I used to deliver myself.

It doesn’t come out of the wall socket, though. Quality is made in the process: the developer agent writes, the reviewer reads against it, the tester tries to break it, and QA checks against acceptance criteria that I spelled out clearly beforehand. Review stays mandatory, including mine at the very end.

Nobody has ever had 100,000 lines in their head

Behind the quality criticism there’s often a picture that was never true: the developer who knows his system like the back of his hand. Nobody needs to tell me he had a hundred thousand lines of code in his head back then. That’s simply not true. Developers have always made mistakes, software has always been error-prone, and we spent a large part of our time just trying to understand what’s written there. That has even been measured: a field study with 78 developers (Xia and colleagues, 2017) arrived at around 58% of working time going into understanding code alone.

And how did we find bugs? Often not at all. Often you only reacted when a client got in touch: the client was the monitoring. I’m explicitly not excluding myself here. Today you can let a swarm of agents loose on the code and find bugs before the client does. Today you can take in code within seconds that nobody ever had in their head. How far that carries was shown by DARPA’s AI Cyber Challenge: in the final in August 2025 the systems searched 54 million lines of code, found 54 of 63 deliberately planted vulnerabilities plus 18 real ones nobody had known about. With 54 million lines, I’d have gotten lost in the first directory back in the day.

The bus factor the critics keep quiet about

The bus factor is the number of people who can get run over by a bus before a software project grinds to a halt because the knowledge is gone. In research it’s also called the truck factor, and it’s frighteningly low: in 2016 Avelino and colleagues examined 133 popular GitHub projects, and 65% of them had a truck factor of at most 2.

Those are open-source projects. For small companies I don’t know of any study, but I do know small companies. Many of them had just one or two developers, and when that person was gone, the know-how was gone. What stayed behind was code nobody wanted to touch anymore. In all those quality debates I’ve read surprisingly little about this risk: the handwritten code of a single person counted as solid, even though all the understanding of it hung on a single employment contract.

Today AI takes over. An agent reads its way into a codebase it has never seen, explains it to you, documents it after the fact and keeps building in it. That way the know-how sits less in one head and more in the code, the tests and the documentation. It still doesn’t work without people; somebody still gets to know what the company actually wants. But I have a lot less respect for the bus than I used to.

On my desk right now: Traffalyzer, first as a Drupal module, now as a WordPress plugin

So this doesn’t stay vague: right now I’m working on a Traffalyzer WordPress plugin, after building the Traffalyzer Drupal module a few days ago. Traffalyzer is my own SEO tool: you enter your domain on traffalyzer.com and get a free first scan, no account needed. I’ve written down why I built Traffalyzer elsewhere (in German), and where the module stands among the others is shown in my comparison of Drupal SEO modules.

There’s no link for the WordPress plugin yet; it’s in progress, and I’m not promising anything here. What I find interesting is something else anyway: these are two systems with their own rules and their own pitfalls, and only a few days lie between the two. By the old math, one problem per week, I’d probably still be sitting on the first one. And yes, this is exactly where the question from above pops up again: how deep am I myself in what’s being built there? Deep enough to judge what gets delivered, or at least I think so.

What’s left of me as a developer?

If I no longer type and no longer go deep myself: what do I actually do all day? Written down, my developer life with AI agents is less spectacular than all the agent talk suggests:

• understand the client’s problem before anybody builds anything
• put together the right team for the task
• phrase acceptance criteria so clearly that nobody can talk their way out
• read results, ask follow-up questions, decide
• take the heat for it at the end

No agent takes that last point off my hands. When something goes wrong, the client calls me and no reviewer agent. Responsibility is hard to delegate, so is judgment, and for me both feed on the years in which I did the typing myself (who I am and where I come from is on the about page). My role as a developer has become that of a generalist. I bring in specialist knowledge when I need it; the question of what should be built and why stays with me.

Whether that will still be called software developer in a few years, I don’t know, and honestly I don’t much care. In the photo above the sun is low, the tablet is pretty much the smallest thing in the whole picture, and the feet are up. How much depth of his own the guy on the wall still needs, I’ll ask him again in a year.

Frequently Asked Questions about developer life with AI

How is AI changing the daily life of software developers?

AI shifts the daily work of software developers from programming to orchestrating: the developer describes what should be built, and AI agents build it. My own working day now consists of talking, reading, deciding and signing off. Instead of sitting on one problem for a week, I skim several problems a day, and the agent team goes deep.

Does working with AI agents make you tired?

Yes, working with AI agents makes you tired, but AI fatigue feels different from the tiredness after concentrated programming. Deep concentration gives way to decisions, context switching and keeping a constant overview. I myself am fitter after an eight-hour day with agents than I used to be after four hours of code.

Do developers lose their skills when AI writes the code?

According to an Anthropic study, developers at the start of their careers build less code comprehension with AI help than without it. In the study with 52 mostly junior developers, the AI group reached 50% in the comprehension test, the control group 67%. Whether experienced developers lose their depth once they stop practicing it, the skill atrophy question, remains open.

Is AI-generated code worse than human code?

AI-generated code is as good as the process it comes out of. Analyses from 2025 such as the one by CodeRabbit found about 1.7 times as many issues in AI pull requests as in human ones. My experience in 2026 is different: with reviewer, tester and QA agents and clear acceptance criteria, my code quality is higher than it used to be by hand. So far that hasn’t been measured independently.

What does a developer still do when AI does the programming?

A developer who works with AI agents understands problems, writes briefs and acceptance criteria, checks results and carries the responsibility. What falls away is mainly the typing. That’s also how the Drupal module and the WordPress plugin for Traffalyzer, my SEO tool, are being built right now.

What is the bus factor in software development, and does AI lower the risk?

The bus factor states how many people can drop out before a software project comes to a standstill for lack of knowledge. According to Avelino et al. (2016), it is 2 or lower for 65% of 133 popular GitHub projects studied. AI agents defuse this risk because they can quickly read their way into unfamiliar code, explain it and document it after the fact.

Will software developers be replaced by AI?

In my experience AI replaces the writing of code, while the profession of software developer shifts toward orchestrating, judging and taking responsibility. At Google, according to Sundar Pichai, 75% of new code is AI-generated; it is still approved by engineers.

Generalist or specialist: who is in demand as a developer with AI?

In software development with AI agents, the generalist with experience is more in demand than the specialist for a single framework. Specialist knowledge becomes easier to come by because AI agents bring it along; what gains in value is the ability to judge results. What remains open for me is where that judgment comes from when nobody goes deep themselves anymore.