There is too much – Vardan Torosyan

There is too much

I keep hearing from engineers lately: there is too much going on. Too many parallel threads. Too much code being generated to actually read. Big features merged that nobody could honestly claim to fully understand. On-call for code you didn’t write and don’t fully trust. And underneath all of it, a quieter admission: the work isn’t teaching me much anymore, and it’s stopped being fun.

I know that feeling well. Not from the AI era - from the day my peers became my reports.

When I transitioned to management at SoundCloud, the people I’d been coding alongside were suddenly on my team. The cognitive load was immediate and brutal. I was stretched in every direction and convinced I had to be on top of all of it: every PR, every decision, every conversation. I spent the first few months in a kind of frantic vigilance, trying to hold everything at once. I was doing everything poorly, and eventually I had to admit that to myself, which is a specific kind of awful.

What actually helped wasn’t a mindset shift. It was aggressive prioritization - Shreyas Doshi’s LNO framework in particular - and the uncomfortable acceptance that I had to let some things go badly in order to do the important things well. That took years, not weeks. Five-ish, if I’m honest.

This is just the job description of an engineering manager

Take the word “AI” out and read that list again:

Accountable for output you didn’t personally produce.

Reviewing and steering all day instead of making.

More threads in flight than you can hold in your head.

Signing off on things you don’t fully control or understand.

Grieving the loss of the craft that made you good in the first place.

That’s not a description of agentic coding. That’s a description of becoming a manager. What AI did was give every engineer a small team of tireless, fast, occasionally-wrong direct reports. And with the team came the manager’s problem. The discomfort engineers are feeling right now isn’t an AI problem. It’s a delegation problem, and delegation is the oldest unsolved problem in our discipline.

The good news: it’s not unsolved because nobody tried. Managers have been failing at it and slowly adapting for decades. There’s actually a playbook.

The timeline nobody talks about

Here is the part that bothers me most. It took me roughly five years to get comfortable with the cognitive load of management. Five years of doing it poorly, admitting it, and slowly building the instincts to triage, delegate, and let go without losing the thread. Nobody demanded I be good at it in month two.

Engineers don’t get that grace period. The token-maxxing era is over, ROI conversations are everywhere, and the pressure to show results from AI-augmented work is immediate. Companies bought into the narrative that AI solves the productivity problem - and that narrative doesn’t leave much room for “we need time to figure out how to work with this well.”

What I rarely see discussed is what this costs. Not in tokens, but in engineers who are quietly overwhelmed, building habits under pressure that don’t actually scale, and losing trust in their own judgment because the tools move faster than they can make sense of. The delegation problem is hard. It took managers decades of collective failure to develop even a rough playbook. Expecting engineers to solve it in a quarter, while also shipping, is not a plan. It’s just pressure with a narrative on top.

Start with what’s actually in your control

Before the tactics, there’s an older idea underneath all of them. The Stoics split the world in two: the things that are up to you, and the things that aren’t. Epictetus opens with it because everything else depends on getting it right.

“There is too much” is a true statement about the second pile. The volume of code your agents can generate is not in your control. The number of features other teams need is not in your control. You have limited time and limited power, and no amount of anxiety expands either.

What is in your control is small and it is everything: where you point your attention, what standard you hold, what you decide not to do, and whether you’re honest about which is which. The whole reason “there is too much” feels like drowning is that we keep trying to exert control over the size of the ocean. You can’t. You can only decide where to swim.

What actually helps

None of this makes the load disappear. It makes it carriable.

Separate ownership from authorship. You own the outcome, not the lines. Ownership is having a model of where this thing breaks and what you’d do when it does - not having typed it. You can own code you didn’t write. You cannot own code you refuse to understand. Those are different statements, and the gap between them is the whole job.

Decide what you must understand deeply - then triage the rest without guilt. You cannot review thousands of lines of generated code at equal depth, and pretending you can is...