# Where the Automation Has to Stop > Source: > Published: 2026-07-12 19:20:10+00:00 I keep seeing people running multiple agents, perfect setups with multiple skills, operating a fleet of assignments. First of all, this looks like science fiction. Besides that, I can hardly get my head around it. I use all the tools, Gemini, Claude, and Codex, and I simply don’t see how I can use several of these at once. My problem is my own cognitive limitation. I can only do so much. I wonder how these people are able to run so many tasks. Is this real? Am I simply older? I asked around. Looks like I’m not the only one. So I’m not an outlier. I wanted to dig deeper into this whole productivity trap, because we feel like we are behind and maybe we are not. Cognitive debt is what people have started calling it, and it makes sense. You can only produce so much before you stop remembering what you did. There was already a question around [where to draw the line with AI at work](https://yusufaytas.com/ai-balance-in-work), but this feels slightly different. The tool is no longer only helping with the work. It can create more work than [one person](https://yusufaytas.com/when-too-many-maps-overlap-on-one-person) can hold in their head. If you did things the old way, there was a limiting factor. [Coding](https://yusufaytas.com/coding-in-leadership), designing, whatever, you had to type, think, type again. I’m writing this and thinking at the same time. It doesn’t all come together at once. The slow part was also where you understood what you were doing. You wrote something, saw it fail, changed it, and kept the whole thing somewhere in your head. AI removes some of that process, but not the need to understand the result. It just leaves that part until later. AI makes us feel like we should go fast, but we can only do so much. That brings me to a few problems. Several Unfinished Things Coming back to where I started, multiple agents, organizations with agents and humans. Who understands this, though? Which companies can realistically do this? I can do it for my toy projects where I don’t have a fucking clue what’s going on, even though I actually read the [code](https://yusufaytas.com/code-author). How can someone run many agents and deploy all of this into [production](https://yusufaytas.com/buggy-code-on-production-survived)? Running multiple agents does not really mean you are doing multiple things at once. It means you have several unfinished things waiting for you. You go from one to another, try to remember what it was doing, review something, answer a question, then go back to the first one and try to remember that again. Maybe some people are very good at this. I am not sure humans can scale it indefinitely. The cognitive load used to come from noise around the [work](https://yusufaytas.com/how-work-software-engineer): notifications, meetings, messy [systems](https://yusufaytas.com/legacy-software-a-goldmine), and hundreds of small decisions. [Now the work itself becomes the interruption](https://yusufaytas.com/stop-wasting-brainpower). Every agent returns with another decision that needs attention. That is where the documentation argument starts to fall apart. Yes, we were bad at documenting before, and things went stale. But there was usually still someone who had followed the change closely enough to explain it. If the code is generated, reviewed, and accepted before anyone builds that understanding, a document written afterwards will not magically create it. You keep accepting, accepting, accepting, and eventually nobody has a clue what is happening. You may finish more work and understand less at the end of the day. That feels fine while everything works. It becomes a different problem six months later when something breaks and someone has to reconstruct the whole thing. The person whose name is on the PR will still be responsible. Nobody will accept “Claude did it” in a postmortem. But that person may have only prompted it, skimmed the change, asked another model to review it, and approved it. Responsibility stays exactly where it was while the actual involvement gets [smaller](https://yusufaytas.com/smaller-is-faster). Code became cheaper, but [ownership did not](https://yusufaytas.com/does-code-quality-still-matter). The newer problem is what ownership means when one person is nominally responsible for several streams of work they did not really follow. The code has an owner in Git, but the decision behind it may not really have one. The Team Did Not Get Bigger I like The Matrix. In fact, that is probably one of the reasons I ended up in this [business](https://yusufaytas.com/representing-the-business), funny enough. Agents are coming, and it feels real now. However, Neo never collaborated with Agent Smith. Somehow, we are expected to. I run my agent and you run yours. How do we share them? Even if we do, how do we make sure we understand the same thing? The work was never only about tools, at least for me. When [people work together](https://yusufaytas.com/the-real-work-is-social), someone pushes back, someone remembers an old incident, someone explains why a bizarre part exists. Slowly, the team builds a shared picture. Agents move a lot of that into private sessions. I ask mine twenty questions, reject a few ideas, change direction, and eventually send you a PR. You see the output, maybe a summary, but not the path that got there. Sharing the transcript does not really solve it either. You can read the same conversation and still come away with a different understanding. Shared context is not just a document. It is built through questions, disagreement, and correcting each other. So now I have my agent, you have yours, and both of us arrive with different histories, assumptions, and summaries. We may have more output, but we also have more [invisible](https://yusufaytas.com/the-invisible-difference) state between us. When another human joins the team, they bring memory, judgment, responsibility, and a relationship with everyone else. An agent does not bring any of that by default. Hence, the team did not get bigger. We just created more work for the humans to merge. The Same Mistake Everywhere Years ago, I remember watching a documentary about Iceland’s reforestation. They were using different types of trees so that if a disease came around, it would not affect everything. I had never thought of that until that moment. When humans write code, we inadvertently write different programs. We have some sort of style. We make different mistakes too. But when AI writes all of it, what happens? Everything may start looking similar in the end. I do not know if this is a problem, but it might be. Humans also copy things and use the same popular libraries, so this is not entirely new. But now the same few models may keep recommending the same structures, [dependencies](https://yusufaytas.com/working-with-dependencies), and ways of solving a problem to everyone at a much larger scale. Say it writes a vulnerability for me. It may write a similar vulnerability for everyone else because these models are trained on similar [data](https://yusufaytas.com/data-as-a-product-a-new-frontier) and the same open-source repositories. The code does not even need to look identical. Different companies can still end up making the same assumptions and missing the same edge cases because the [advice](https://yusufaytas.com/why-we-ignore-advice) came from roughly the same place. One mistake in one company is normal. The same mistake everywhere is a different kind of problem. What Counts as Safe? People are also talking about auto-review and auto-merge. One AI writes the code, another [reviews](https://yusufaytas.com/take-self-reviews-seriously) it, the tests pass, and the thing merges itself. I get that part. Maybe review is not the limit either. Then the work moves somewhere else. Someone has to decide what the agents are allowed to touch, what counts as a safe change, which tests actually prove something, and which changes should never merge on their own. You are not necessarily reviewing every line anymore. You are trying to build enough boundaries around the agents that you don’t have to. Managers already work like this to some degree. They observe behaviour, reproduce failures, compare outcomes, and push on the [system](https://yusufaytas.com/system-design-interviewing-tips) without writing every line themselves. [That only works when the signals are good](https://yusufaytas.com/managers-have-been-vibe-coding-all-along). Without reliable signals and boundaries, supervision is just guessing with more confidence. That sounds quite reasonable for small and repetitive changes. If something is low [risk](https://yusufaytas.com/risk-comes-first), the tests pass, and the blast radius is limited, let it merge. But then the hard problem becomes deciding what low risk means. I’m not sure most companies understand their systems well enough to encode that cleanly. We already struggle to keep documentation current. We have old decisions nobody remembers, strange workarounds from [incidents](https://yusufaytas.com/promoting-learnings-in-incidents) years ago, business rules living in someone’s head, and services nobody wants to touch. Now we want to turn all of that into context files, permissions, tests, and rules an agent can reliably follow. The difference is not who typed the code. It is whether somebody is thinking about [the entire lifecycle around it](https://yusufaytas.com/vibe-coder-vs-software-engineer). Auto-review and auto-merge do not remove that lifecycle. They turn more of it into policy. Maybe this is the answer. The code gets written and reviewed automatically, while engineers spend more of their time defining the constraints around it. But that also means a weak test suite, a missing rule, or a badly drawn permission boundary can now produce bad changes at a much larger scale. People are painting a dystopian future. Maybe we’ll get there. I used to think these tools were only as useful as humans could comprehend. I’m not sure that is true anymore. They may be able to keep producing without us understanding everything they do. Maybe I’m old-fashioned. But these problems won’t arrive one by one. They will accumulate quietly. The code may become automatic. The difficult part will be deciding where the automation has to stop.