The Job Positions of the AI Future

**Nathaniel Whittemore** (0:01)
Today on the AI Daily Brief, the job positions of this new agentic future.
The AI Daily Brief is a daily podcast and video about the most important news and discussions in AI.
All right, friends, quick announcements before we dive in. First of all, thank you to today's sponsors, Robots and Pencils, Retool, Blitzi, and Airtable. To get an ad-free version of the show, go to patreon.com/aidailybrief, or you can subscribe on Apple Podcasts. And if you want to learn more about sponsoring the show, send us a note at sponsors at aidailybrief.ai.
Today we are once again turning to the future of jobs. This episode is not about exploring what industries or types of roles are going to be displaced by AI, nor is it exactly like my episode from a month or two ago about the entirely net new roles that are going to be created by AI. Instead, this one is about new ways of working and some patterns that people are starting to observe about how the roles of jobs are changing as we get deeper into AI. Now obviously a lot of this is predicated on the meta shift from doing a job to managing agents that do that job. That I think is going to be a big part of the common shift for all roles is a process of people exploring how much of what they do on any given day or in any given week can be more effectively outsourced to teams of agents that actually do the execution and then working backwards from that what is the actual substance of the role that remains. Likewise, as with a lot in AI, a big part of what us non-technical users are doing is looking over at the developers and technical users and trying to map their experience back onto the types of roles that we have. Now this particular episode was inspired by a very specific tweet from Cloud Code creator Boris Cherny. At the end of last month, he wrote, As engineering, product, design, DS, etc. melt into a new kind of role, I was reflecting on what roles might look like in the future. For example, when I look at the Cloud Code team, I see what I think is five archetypes. One, the prototyper comes up with brand new ideas, turns out many ideas, most of which don't ship. Two, the builder quickly turns a prototype idea into production-grade product and infrastructure. Three, the sweeper, cleans up the UI, simplifies the code and system, unships, optimizes performance. Four, the grower, takes a product that has been built and iterates on it to improve product market fit. Five, the maintainer, owns a mature system to make it secure, reliable, fast and efficient as it scales. Many people span across two roles and sometimes three roles. I also noticed that these roles are not really tied to job function. E.g. across Anthropic, some designers match category one, some two, some three. Same for engineers, PMDS. A healthy team needs a mix of these depending on the product. A product that is new and pre-PMF needs people that are strong at one, two, and three. Prototyper, builder, and sweeper. A product that is growing and has found product market fit needs two, three, and four. Builder, sweeper, grower, and some five, maintainer. A product that has strong product market fit needs three plus four plus five, sweeper, grower, maintainer, and some two, builder. Maybe product roles of the future will look more like this and less like the domain-specific roles of today. Now, this is one of those great posts that's detailed enough to dig into, but also open enough and exploratory enough to build off from.
So what I wanted to do is go a little bit deeper into each of these five roles, try to apply it to areas outside of engineering and product work, and then look at what I think might be missing. Now, so one common thread in all of the positions outlined by Boris is that they are product-facing. In other words, they more or less face inward, connected to the product that is being built. The order is also a rough life cycle of a product. Boris even articulates how different teams need different combinations of these things based on where in the product's life cycle the product is. So let's talk about each of these five work-facing roles. The Prototyper is a role that many of you inhabit on a fairly regular basis. This is a person who is generating brand new ideas and using things like CodD code and Codex to do the first version of them. Now, historically, the knock on the idea person was that ideas were free and it was all about execution. Now, what execution means, I think, is getting a little bit different as taking the first steps towards bringing that idea to life gets vanishingly simpler in the context of code generating agents. And what's interesting about the archetype of the Prototyper is that while obviously Boris is talking about it in the context of the actual product team, this is not at all constrained to product builders. In fact, increasingly, the capability of using agents to prototype and build things means that product style thinking is infiltrating other parts of the organization. People who have never touched a product before are thinking about how they could build their own products or tools to make whatever it is that they're doing easier. But the Prototyper isn't just valuable because they figure out how to solve problems using code, but also because they're pushing the shape of what their function can actually do. The Prototyper cuts down what used to be an endless discussion phase into much more directed and applied conversations based on looking at something real. In other words, the Prototyper isn't just coming up with new ideas, they're also eliminating an entire step in the conversation which can be extraordinarily time-consuming because that conversation can now be had while looking at something real and tangible.