I was listening to episode 280 of Think Fast Talk Smart recently; an interview between host Matt Abrahams and Aneesh Raman, Chief Economic Opportunity Officer at LinkedIn, former CNN war correspondent, and former speechwriter for Barack Obama. The episode is about career development in an AI world, and somewhere in the first few minutes, Raman introduced a three-bucket model for categorising work. I had to pause and rewind.
What he was describing, from the vantage point of careers research and labour economics, sounded eerily similar to something I had written in a case study a few months earlier, about a journalist who built a production React application in a month without writing a line of code. Raman is not a software engineer. He has never worked in a development team. He was talking about the broader workforce. And that is precisely why his framework is worth examining: the shift I have been watching happen inside software teams is not a niche technical quirk. It is part of a much larger change in how professional work operates.
The Three Buckets
Raman divides work into three categories. The first contains tasks that AI can already do, or will soon: summarising, coding, analytics, research. If your current role consists primarily of Bucket One work, the pressure is real and it is not going away. The third bucket covers work that requires specifically human presence; ethics, interpersonal trust, community, ideation that depends on relationship. That bucket is genuinely hard to automate, but it is also not where most developers currently sit.
The second bucket is where things get interesting. It covers work done in partnership with AI tools: directing, reviewing, refining, and making judgement calls about the output.
Work is changing, not ending.
This is actually the most important bucket. This is where high performers are emerging from new corners in new ways.
That second framing cuts against the most anxious narratives around AI and employment. The question is not whether AI will replace workers; it is whether workers will develop the skills to operate in Bucket Two. For developers, the shape of that skill set is already becoming clear.
Raman also offers a reframe on careers more broadly: they are no longer ladders, he argues, but climbing walls, with multiple routes up, some of which only you can take. For developers who feel that AI has blocked their path, this is a more useful mental model than the ladder suggests.
I Have Already Seen This in Practice
Earlier this year, I worked with Ollie Peart, a journalist and presenter for The Modern Mann podcast. A listener had challenged him to build a working web application using only AI tools, with no prior coding experience and no development background. You can read the full story in the case study, but the short version is this: within approximately one month, working almost entirely through natural language prompts to Google AI Studio, Ollie built and deployed a production-ready React application. The app is live and in use by the podcast’s community.
What matters for this conversation is not what Ollie built; it is what my role looked like throughout. I never wrote a line of code. I helped with tool selection, prompting methodology, and problem decomposition. When Ollie hit obstacles, I taught him meta-prompting techniques: asking the AI what it needed to know in order to produce a better answer. When image paths broke, we diagnosed the underlying issue together. When episode linking required external research into URL structures, I helped him think through how to approach the problem systematically rather than just asking the AI to guess.
That is Bucket Two. I was directing, reviewing, and teaching someone else to direct and review. The “Author” role, sit down, write the code, ship the file, was handled entirely by AI. The work that delivered value was editorial: knowing what to ask for, recognising when the output was wrong, and understanding the system well enough to guide the AI towards a correct solution.
I called this the transition from developer-as-author to developer-as-editor-in-chief in the case study. Raman’s framework gives that transition a name that resonates well outside the software world.
What Bucket Two Actually Requires
Raman describes the capabilities that matter in Bucket Two through five attributes he calls the Five C’s:
Courage, curiosity, creativity, compassion and communication — sitting at the intersection of IQ and EQ, of consciousness and conscience.
None of these are soft skills in the dismissive sense, and they map directly onto what editorial work in software actually requires.
Courage comes first, because AI tools produce output confidently regardless of whether that output is correct. Pushing back on generated code, especially under deadline pressure when the code looks plausible, requires the willingness to question what you are given rather than accept it at face value. A developer who cannot do this is not reviewing AI; they are just shipping it.
Curiosity matters for the same reason. A developer who accepts AI output without understanding why it made the choices it did has outsourced their judgement, not merely their typing. The review process only works if someone is genuinely asking questions of the output.
Creativity, compassion, and communication are perhaps less obvious, but they hold. Effective prompting takes imagination; getting an AI to produce something genuinely useful, rather than something generic, requires the ability to describe a problem from multiple angles and iterate when the first attempt misses. Compassion for the humans who will use and maintain the system is what keeps code quality, documentation, and architecture decisions from being treated as optional. And communication, the ability to translate between what the AI produced and what the business actually needs, is one of the most consistently undervalued skills in any development team.
Humans aren’t meant to be machine-like, and machines will eventually out machine us.
This has been true in manufacturing and logistics for decades. It is now true in code generation. The developers who thrive will not be the ones who type fastest; they will be the ones who think most clearly about what should be built and why.
What This Means for Team Leaders
If you lead a development team, Raman’s Three Buckets model is a useful diagnostic. Look honestly at what your team currently spends its time on. How much of that work falls into Bucket One: repeatable, automatable, or already being done better by AI tools? How much of it requires the judgement, communication, and systemic thinking that Bucket Two demands?
If the answer skews heavily towards Bucket One, that is worth addressing. Not because those developers are at immediate risk, but because the team’s value to the business is eroding in real time. Hiring, onboarding, and performance management built around Bucket One capabilities will produce a team that is progressively less competitive, and progressively less visible to the business stakeholders who fund it.
The practical reframe is simpler than it might sound. Bucket Two skills can be developed deliberately. Code review practices that ask “why did the AI make this choice?” build curiosity. Post-incident retrospectives that examine systemic conditions rather than individual blame build courage and communication. Encouraging developers to document their prompting decisions, not just the resulting code, builds the creative and communicative muscles that Bucket Two work demands.
Raman’s observation for individual careers translates directly to teams: “Chase your talent, not your dreams.” For a development team, that means investing in what humans do well, rather than trying to compete directly with what AI does well.
The Shift Is Already Here
“Work is changing, not ending.” It is a simple line, but it is the right frame. The question for every engineering leader is not whether this transition is coming; it is which bucket their team is currently living in.
When a journalist with no coding background can build and deploy a production application in a month, Bucket One is already here. The genuinely human work is happening in Bucket Two. That is where the Editorial role lives, and that is where development teams need to be building capability now.
If you are thinking about how your team navigates this shift, a consultation might be a useful starting point.