Boris Cherny, who created Claude Code, has given one of the clearer descriptions I have seen of how Ai is reshaping work, and it is being passed around for good reason. His observation is that the old job functions, engineer, product manager, designer, data scientist, are melting into something more fluid, and that work is starting to organise around the stages of building a product rather than around fixed job titles. Linas Beliūnas took that a step further with a sharp piece of advice, which is to stop relying on a title you do not really own and to productise yourself instead, building the taste, judgement, audience and systems that compound while the title underneath you keeps changing. Both are right, and both, I think, stop at the most comfortable place to stop, which is the individual. The harder and more interesting implication sits one level downstream, in the system that surrounds the role.
The archetypes describe people, not organisations
Cherny's five archetypes are worth holding onto because they ring true. There is the prototyper who turns messy ideas into fast experiments, the builder who turns the promising ones into real systems, the sweeper who deletes and simplifies and unships, the grower who talks to users and pushes towards product-market fit, and the maintainer who keeps the mature thing reliable at scale. The genuinely useful insight is that these are not job titles, because the same person might prototype on Monday, build on Tuesday, sweep on Wednesday, talk to users on Thursday and maintain the thing on Friday, and the most valuable person on a team is increasingly the one who can move between those modes quickly. If that is true of individuals, then productising yourself is sensible advice, because the thing that lasts is the range and the judgement rather than the label. The trouble is that an organisation is not simply a pile of adaptable individuals, it is a system of how you hire, how you manage, how you measure and how you reward, and almost all of those systems were built on the assumption that work happens in fixed lanes.
What actually breaks is everything downstream of hiring
Most teams still hire as if work happens in clear lanes, with clear roles, clear boundaries and clear ownership, and that is the part everyone notices first. What gets missed is that hiring is only the start of the problem, because once value is created across stages rather than within them, everything that follows the hire begins to strain. Management becomes harder, because you are no longer overseeing a set of discrete functions, you are managing flow, handoffs and context as work moves from one mode to the next. Measurement becomes harder, because impact is now shared across stages rather than owned cleanly in one place, and the honest answer to who delivered a given result is usually several people, at different moments. Reward becomes distorted, because the systems most companies run quietly favour the visible output that sits in a single lane, and they are close to blind to the quieter work of connecting, translating and carrying momentum across the whole thing. None of that is solved by writing a more modern job description.
The gap that punishes your most valuable people
Put those together and a specific, awkward gap appears. We have started hiring for adaptability, because we can all see that the world now rewards it, but we are still managing and rewarding for specialisation, because that is what our systems were built to do. The people who create the most value in a fluid setup are exactly the ones who live in the gaps, the ones who take a prototype and make it real, who notice the thing that should be unshipped, who carry the context from a user conversation into the build. In a lane-shaped system that connective work is almost invisible, because it does not arrive as a finished artefact with one name on it, and so the people doing it are often the least recognised, the least rewarded and, in the end, the most likely to leave. That is not a people problem, it is a design problem, and it is one most organisations have not yet noticed they have.
This is a systems problem, which is the part I find interesting
This is the kind of problem I spend most of my time on, because underneath the Ai story it is really a question of systems and change, and both of those are older and far better understood than the technology sitting on top. You cannot bolt adaptable people onto a specialised system and expect the mismatch to resolve itself, you have to redesign the system around the way the work now actually flows. In practice that begins where it always begins, with mapping the real work by stage rather than by lane, because you cannot manage or improve a flow you have never actually drawn. It runs straight into measurement, because what you measure is what you get, and a business that only measures single-lane outputs will keep starving the connective work no matter how warmly it praises adaptability in the all-hands. And it depends, more than anything, on change management, because none of this lands by relabelling the org chart, it lands by bringing people through the shift in a way that makes sense to them, and nobody has ever been argued into a new way of working by a new diagram. The thread that holds a more fluid system together is the same management-system discipline that holds anything together, clear ownership of outcomes rather than tasks, a way of seeing who carried what across the stages, and enough traceability that the quiet contributions stop being invisible. That last point is where the governance side of Ai and the people side of the business meet, because the same instinct that makes a system legible to an auditor is what lets you reward the right things in a team.
What it comes down to
The future probably does belong to people who can change modes faster than an org chart can rename them, which is the line from Linas's post I keep coming back to. What I would add is that it only belongs to them if the organisations around them change too, because adaptability that is never seen, measured or rewarded is not an advantage, it is a slow source of resentment. The next shift is not really in how we define roles, it is in how we design the system around them, and that is a systems and change problem long before it is a technology one. Get that right and the blurring of roles becomes the opportunity everyone says it is. Get it wrong and you will keep hiring for the future while managing for the past, and quietly losing the very people who were ready for it.
Sources
- Boris Cherny's archetypes (prototyper, builder, sweeper, grower, maintainer): his post on X.
- Linas Beliūnas on productising yourself: Productize Yourself.