The bottleneck has moved from coding to what you call managers. The aspects of managers you list make sense to me. It changes how you work. Paul Graham describes this in Maker's Schedule, Manager's Schedule. The interleaving is tighter though. Managers are used to work in one-hour blocks. That's not how you work with coding agents.
But I think one element is overlooked. The bottleneck is not really these kinds of management. In fact, some of those can and will be pushed to the agents too. The real bottleneck is specification. In smaller orgs that is happing in grooming sessions often between stakeholders and the dev team where the developers ask question about special cases the stakeholder didn't even thought possible. In larger orgs that is the more specialized role of business analysts. But it amounts to the same thing: You need to understand the domain of the business well enough. A domain no LLM will know much about. Not even if you feed it all the available documentation, because much of that often procedural knowledge is in people's heads.
For a long time we’ve thought of software engineers as split into two tracks: Individual Contributors (ICs) and managers. This divide made a lot of sense when we needed an army of engineers to write code.
Now we have Claude and Codex and Grok and Kimi. They write the code for us, and the job of an IC is to manage their agents.
Functionally, this means that every IC is a manager now. True, ICs don’t manage people, but they manage a team of bots, and that means they face many of the same challenges that managers do.
Like multitasking. Sure, everyone had to multitask some, but for years we’ve encouraged ICs to focus, avoid distractions, and just do one thing at a time. We told them to do that because it was the only way for them to produce high-quality code. But now that agents take care of the code, ICs find themselves needing to manage many threads of concurrent work, nudging their agents along to the right outcomes, and deep focus is becoming less important than the ability to track parallel tasks.
Or giving feedback. Managers have to give feedback all the time so that the people working for them know what they want and do the right things. ICs have to do that now, too, only with bots instead of people. Thankfully, giving Claude feedback is much lower stakes—it doesn’t get upset if you tell it the code it wrote is bad or if you ask it to change the same UI element again for the Nth time—but giving an AI effective feedback is surprisingly similar to giving feedback to a person. In both cases you have to be able to explain yourself well enough to get what you want, and so communication skills have become far more important for ICs than they were in the past.
And then there’s ownership and accountability. Now that ICs don’t need to spend all day writing code, we’re asking them to move up the business stack. It’s no longer enough to merely build what you were asked; we want engineers to think about customer needs, collaborate across functions, and be active partners in figuring out the right things to build. This is pulling them into the realm of leadership, and thus we are asking them not merely to own the quality of their outputs, but to drive the quality of measurable outcomes for the business.
To my mind, we probably shouldn’t even use the term “Individual Contributor” anymore, since there’s no longer anything truly “individual” about the role. And I expect this trend to continue in the coming months, with the job becoming more about effective coordination of technical resources, like agents, and less about directly producing code. In this sense, traditional IC roles seem likely to go away, replaced by new ones that manage and coordinate agents, still requiring strong technical judgement, but no longer rooted in personal labor.
Share