It happened faster than anyone expected
Something in your role changed this year. The task that used to take an afternoon now takes an agent ten minutes. The report you wrote every Friday? There’s a pipeline for that. The coordination work, the status updates, the ticket grooming — it didn’t disappear, exactly. It got absorbed.
AI ate part of your role. Maybe a big part. The question in the air is the obvious one: what’s next?
The Anatomy of an AI-Native Org talked about what happens to the shape of organisations. This is the follow-up people actually asked for — the role-by-role walkthrough. Project and Product Managers asked first. Designers asked next. EMs asked, slightly defensively. Junior engineers asked quietly, the way you ask a question you’re afraid of the answer to.
This is the answer.
⸻
The cut that runs through every role
Before I go role by role, one principle does most of the work.
Every role splits along the same line.
The parts of your role that look like translation — converting one well-defined input into a well-defined output, running a process that produces a predictable artifact, coordinating other people’s work — are the parts that collapse. They collapse into the agents layer of the new anatomy. This is true regardless of your job title.
The parts of your role that look like judgement — deciding what correct means in an ambiguous situation, holding context across a problem larger than any single ticket, taking responsibility for an outcome rather than an output — are the parts that grow. Dramatically.
When you read the role sections below, the underlying question is always the same: which parts of what I do today are translation, and which parts are judgement? Your career strategy for the next five years is whatever moves you decisively toward the second column.
Now, role by role.
⸻
At a glance
Two arcs run through what follows. Some roles evolve — the work sharpens, the leverage grows, but you’re still doing a version of what you were doing, with much bigger tools. Other roles transform — the job becomes a different job with the old name still attached. Knowing which arc you’re on changes everything about how you prepare.
Roles that evolve — same job, sharper.
| Role | What gets eaten | What grows | Where to start |
|---|---|---|---|
| Product Manager | PRD drafting, research synthesis, RICE prioritization | Business ownership; vision, intuition, research, customer lanes | Pick your strength lane. Carry the business number, not the roadmap. |
| Senior / Staff / Principal Engineer | Boilerplate, rote refactors, internal scaffolding | Architecture, eval design, agent direction | Stop coding everything yourself. Design the system agents operate inside. |
| Project / Program Manager | Status updates, sprint facilitation, ticket grooming | Outcome ownership, eval design, boundary work | Pick a lane (taste, harness, boundary) and operate visibly from it. |
| Engineering Manager | Standup chairing, status writeups, ticket grooming | Design contribution, harness ownership, hiring | Get hands back on the work. Ship something this quarter. |
Roles that transform — different job, old name.
| Role | What gets eaten | What grows | Where to start |
|---|---|---|---|
| Junior Engineer | The apprenticeship pipeline itself | Reading-and-judging muscle, outcome thinking | Read code like a critic. Find a mentor for judgement, not syntax. |
| Designer | Production work, mockup variants, output volume | Taste, brand judgement, system coherence | Build a portfolio of judgement, not of output. |
| QA | Manual passes, regression suites, downstream validation | Eval design, acceptance criteria, embedded quality | Move into engineering, not alongside it. Build eval suites. |
| Customer Success | Tier-1 support, ticket triage, FAQ responses | Product feedback synthesis, strategic-account ownership | Show up to product with a point of view, not a summary. |
Jump to your role, or read straight through.
⸻
Product Managers
Evolution — but only if you already had a thesis.
This is the role most often confused with Project / Program Manager, and the AI shift is about to make that confusion impossible to ignore. The two roles have shared a title in many companies for a decade. The underlying work was never the same.
A traditional Product Manager spent maybe 70% of the week on translation: PRDs, research synthesis, prioritization frameworks, alignment decks, status updates, roadmap reviews. The other 30% was judgement — deciding what to build, holding a thesis under pressure, knowing which customer signal mattered and which was noise. Honestly told, most of that 70% was project management work, not product thinking. Agents now do the 70% faster and at higher fidelity than any human running on Friday-afternoon coffee. The gap that opens when the 70% vanishes is exactly the gap between project management and product thinking. For some people that gap is a chasm.
Product and project are different skills. They’ve shared a title for a decade. They never shared a capability.
What gets eaten: PRD drafting, research synthesis, competitive analysis aggregation, RICE-style prioritization scoring, the slide-deck-and-summary motion of the role. Status communication and roadmap presentation. Most of the document production that filled a PM’s calendar.
If you’re a Product Manager, four lanes survive and grow. They map to four different muscles — thinking, intuition, research, and user proximity — and most strong PMs lean into one or two.
Vision PM. The thinking lane. You hold the product thesis. Original strategic ideas about where to take the product, why now, why us. You write the document that becomes the company’s direction, and you operate from it under pressure. The agent can summarize the market; only you can decide what to do about it. This is the most senior shape of Product Manager work in the new world — and the rarest.
Intuition PM. The taste lane. Years of pattern recognition across products, markets, customers. You know which features will land before research confirms it. The agent can generate options; only you can tell which one is right. The hardest lane to develop in someone who doesn’t already have it — and the most valuable in the agent era, because intuition is what tells you when the agent’s output is plausibly wrong.
Research PM. The discovery lane. Rigorous, structured customer research. You design experiments, run user interviews that move the conversation forward, build feedback loops the company can act on. The agent can synthesize transcripts at scale; you decide which questions to ask, and what the answers mean. This lane gets bigger, not smaller — because more conversations don’t equal more insight.
Customer PM. The user lane. Embedded in the customer’s world. You ride along with sales calls, sit in support tickets, visit users in their context. You bring specific, dated customer voice into every product decision. Closely related to where the strongest CS leads end up. The agent can read every ticket; only you sit in the room with a frustrated user and feel what’s actually wrong.
The four lanes are about how you contribute. But there’s a bigger shift sitting above all four, and it applies whichever lane you pick. The new Product Manager evolves into something the old role often wasn’t: a business owner. Your real job, always implicit and rarely held accountable, is becoming brutally explicit: make money. Revenue. Margin. Growth. Retention. Whatever the number is for your product, that’s now your number — not the roadmap, not the OKRs, not features shipped. The conversation with leadership stops being did you ship? and becomes did you move the number? Most PM organisations aren’t structured for this yet. Most PMs weren’t trained for it. It’s the shift that runs deeper than any of the four lanes.
Whichever lane you love, the real job is unchanged: own the business outcome. Make money.
What I’d do if I were a Product Manager today: choose your strength, honestly. If the project work was where you actually shone — running the process, holding the alignment, shepherding the launch — you’re a Project / Program Manager, and that section is your roadmap. If product thinking was your real instinct, pick the lane within it that fits you — vision, intuition, research, or customer — and operate from it visibly. Stop being the person who runs the discovery process. Start being the person who has a point of view about what should be built, and the conviction to hold it when leadership pushes back.
And underneath whichever lane is yours, start carrying a business number. Revenue, margin, growth, retention — whatever your product’s actual job is in the company. Own that number, operate as someone accountable to it, not as someone shipping features into it. That’s the real evolution, and the lanes are just different paths to it.
The agent can do the synthesis. Only you can have the conviction. Both lanes are honourable. Pretending you’re in the one you’re not is what gets people stranded.
The era of “let me find out what to build” is closing. The era of “I know what we should build, and here’s why” is opening.
⸻
Senior / Staff / Principal Engineers
Evolution — bigger leverage, fewer trophies.
Less affected than people think. Senior engineering work was always closer to judgement than translation — defining architecture, owning systems, deciding what correct looks like across complex domains.
What gets eaten: writing the boilerplate parts of the design yourself, doing the rote refactors, hand-tooling internal scaffolding. The slice of your day that was conversion is gone.
What survives and grows, dramatically, is leverage.
The 10x engineer trope was always mythical. The 100x engineer pattern — one senior engineer plus the agents they direct — is real, and I’ve watched it work this year.
The 10x engineer trope was always mythical. The 100x engineer pattern — one senior engineer plus the agents they direct, replacing what used to require a team of eight — is real, and I’ve watched it work this year. Architecture decisions. Cross-system reasoning. Eval design. The 5% of the codebase the agent shouldn’t touch unsupervised. Performance work in deeply intricate systems.
What I’d do if I were senior today: stop coding everything yourself. Start designing the system the agents operate inside. Your role moves from writing the hard code to defining what good means in the hard places. That’s a bigger job, not a smaller one. It’s also harder than it sounds, because writing the code was the comfortable part — the part with visible output and immediate dopamine. The new work — specs, evals, architectural reviews of agent-generated code, harness design — produces fewer trophies and more leverage. That trade is worth making.
⸻
Project / Program Managers
Evolution — but the most aggressive one in the post.
This is the role that triggered the post in the first place. Of every job in software, it’s the one facing the sharpest transition — because the work was almost entirely translation.
Status updates synthesized from engineering progress. Sprint facilitation. Roadmap-to-JIRA conversion. Standup chairing. Read that list with the principle above in mind and the answer is uncomfortable but clear — almost all of it is translation. Agents are getting scary good at it. Status updates synthesized from the PR graph and deploy log are more accurate than the ones a PM stitches together by hand on Friday afternoon. Dependency tracking from the code graph is more complete than what any human can hold in their head.
The blunt thing worth saying out loud: the three lanes that survive each ask you to become something adjacent — more product, more quality engineering, more governance. This sits closer to role change with continuity than to same role, sharper. Your PM skills transfer. The day-to-day work won’t look the way it does now.
Your PM skills transfer. The day-to-day work won’t look the way it does now.
If you’re a Project / Program Manager, three lanes survive and grow.
Taste PM. You move up into the what layer — which is essentially crossing over into Product Manager territory. The ones who already pushed back on bad scope, said no, we won’t build that even though we could, and held a product thesis under pressure — that’s you, and there’s more room for that work now than there’s ever been. The good ones always knew this was the real job. The agent era just makes it explicit. Transfer skill: holding context and packaging it for decisions. New skill: a thesis of your own.
Harness PM. This is a new lane and possibly the most valuable. Someone has to define acceptance criteria. Someone has to design the eval suites that determine whether the agent shipped the right thing. Someone has to track outcomes now that outputs are nearly free. Project Managers with a quality-of-outcome instinct slot here naturally. The work looks more like product reliability engineering than project management, but it’s PM-shaped at its core. Transfer skill: process design, definition-of-done discipline. New skill: enough technical depth to design evals that catch real failures.
Boundary PM. The few cross-team threads that genuinely need a human — compliance, legal, regulatory commitments, multi-org customer engagements — survive. Fewer people in this lane, doing more senior work. Transfer skill: stakeholder management, complex coordination. New skill: domain depth (legal, compliance, regulatory) that takes years to build.
What I’d do if I were a Project / Program Manager today: pick a lane and start visibly doing that work this quarter. Don’t wait for the role to find you. If you’ve been the coordinator-PM, write a product thesis for something you care about, get it in front of leadership, and start operating from that thesis instead of from JIRA. If quality-of-outcome is your instinct, propose an eval suite for one of your features and own the definition of done.
And the math nobody wants to say out loud: the total number of seats in this role is going to shrink. The seats that remain will be senior, lane-specialised, and will go to the people who started shifting six months ago. The hardest version of this advice is the simplest — start now, in one specific lane, with one specific artefact.
⸻
Engineering Managers
Evolution — if you keep your hands on the work.
EMs got partial coverage in the macro post — the contribute or disappear line — but the question I keep getting is what contribute actually means in practice.
The EM who hasn’t coded in five years is the most at-risk profile. The EM who still ships something every quarter — a tool, a script, anything — is the most resilient one.
The EM who hasn’t coded in five years is the most at-risk profile. The EM who still ships something every quarter — a tool, a script, anything — is the most resilient one. That’s the whole section, really. Everything else is scaffolding.
The EM work that collapses: standup facilitation, the upward translation of engineering progress, the downward translation of business priorities, ticket grooming, weekly status writeups. Most EMs I’ve talked to know this in their gut already.
What survives and grows: people development; hiring; design contribution — the EM who shows up to the design discussion with a real opinion; harness ownership; incident command and post-mortem leadership.
What I’d do if I were an EM today: get hands back on the work. Not all the work — but enough that you’re in the design conversation, not just facilitating it. Read the codebase. Read the agent’s PRs. Push back on architecture decisions with actual evidence. There’s no rule that says you have to be the loudest contributor. But you do have to be a contributor.
⸻
Junior Engineers
Transformation — and the industry hasn’t built the new path yet.
This is the hardest one and I want to be honest about it.
The traditional path from junior to senior was: write a lot of code, ship a lot of bugs, get a lot of feedback, gradually develop judgement. The translation work — converting tickets to PRs, implementing well-defined features, fixing well-defined bugs — was also the apprenticeship. Senior engineers came out of that pipeline because the conversion work taught them, over five or seven years, what correct looked like in production.
The agent now does most of that conversion work, and it does it faster than any junior can. Which means the apprenticeship pipeline that produced senior engineers is breaking. We haven’t built a new one yet. Anyone who claims they have is selling something.
I don’t want to be dishonest about this. The hardest career conversation in software right now is: how do you become a senior engineer if you’re a junior engineer in 2026? The old path is closing. The new path is being figured out in real time by a small number of teams and a small number of individuals, and most companies haven’t worked out how to develop a junior engineer in an AI-native environment.
What I’d do if I were a junior today, holding nothing back.
Don’t try to compete with the agent on speed of execution. You won’t win.
Don’t try to compete with the agent on speed of execution. You won’t win.
Compete on judgement. The reading-and-judging muscle is the senior-engineer muscle, and the agent has actually made it more accessible. Try this: pick three pull requests this week — yours, your team’s, or open source. For each, ask the same three questions: what was the constraint this was solving for? what did it trade off? would I have made the same trade? Write your answers down. Do this every week. After three months you’ll have a notebook of forty critiques, which is roughly forty more than most juniors will have.
Take ownership of outcomes, not tasks. If the agent shipped a feature, the question stops being did I write the code and becomes did this feature do what it was supposed to do? Live inside that question even when nobody is asking you to. Get the metric. Watch it for a week. Write the post-launch note that no one asked for. That note is what makes you visible to the seniors who matter.
Find a senior who’ll mentor you on judgement, not syntax. The senior who’ll sit with you and explain why a decision was made — not just what the decision was — is more valuable to your career than the senior who shows you a clever piece of code. If you don’t have one inside your company, find one outside it: open-source maintainers, engineers you’ve worked with before, people whose writing you return to. Ask one specific question. Follow up with another. Most seniors will respond if the question is specific and the follow-up is thoughtful.
Look hard at whether your company is actually investing in juniors. Is there a real path? A senior who’s measurably better at developing people than the others? A culture of explaining the why? If yes, stay and absorb everything. If no, leave. The industry is splitting into companies that will produce the next generation of senior engineers and companies that will hire from those companies. Be at the first kind. The pay is the same. The trajectory isn’t.
Worth saying out loud — the industry owes juniors a better answer than “use the AI and figure it out.” We’re going to lose a generation if we don’t think harder about this. I’m working on it.
⸻
Designers
Transformation — from making volume to defining good.
Designers asked about this more nervously than I expected, and I get why. AI is generating images, mockups, design system variants, even working prototypes. It can feel like the heart of the craft is under attack.
I don’t think it is. But the shape of the role is changing.
What gets eaten: production work. Wireframes from a brief. Mockup variants. Design system implementation. The output-volume parts of design — the slides, the asset packs, the dozen-versions-of-the-hero-image work — agents can do faster than any human.
What survives and grows: taste, conceptual design, brand judgement, system-level coherence, the what does this product actually feel like call. The cuts. The no’s. The opinionated calls about what good looks like for this product, this brand, these users. The sensitivity to detail that only comes from caring about craft for a long time.
What I’d do if I were a designer today: lean into the parts of design that require years of caring about craft.
Stop optimising your portfolio for output volume. Start optimising for what you can decide, not what you can make.
Stop optimising your portfolio for output volume. Start optimising for what I’d call judgement artifacts — design rationale documents, critiques of other people’s work, brand voice guides, taste essays. These are the things that prove you can decide what’s good, not just make a lot of things. The market for that has never been bigger.
⸻
QA
Transformation — from downstream service to embedded quality engineering.
I want to be more honest about QA than the easy version of this story allows.
The easy version says QA was undervalued and now finally gets its moment. I don’t think that’s quite right, and I want to say why.
For thirty years, traditional QA created a quiet co-dependency with engineering. Developers learned that they didn’t have to worry about quality at the moment of writing, because QA was the safety net downstream. They churned out features. QA caught the obvious bugs. Both sides made their numbers. But the code wasn’t actually up to standard at the point of commit. The product wasn’t up to standard at the point of merge. Quality became something that happened to the work, not something that lived inside the work.
Quality became something that happened to the work, not something that lived inside the work.
The cost showed up in cycle time. Manual QA passes took days. Regression suites took weeks. Code-to-production stretched from hours to fortnights, and engineering teams quietly became hostages to QA orgs that had to physically run through every release. Trust in delivery eroded — both ways. Engineering didn’t trust its own output. QA didn’t trust engineering’s output. Customers didn’t trust either of them. We called this normal. It was actually a co-dependency dressed up as a process.
The Tests We Skipped is what magnifies the impact here. When automation and specs and eval suites become load-bearing — when the harness is real — the long manual QA cycle stops being viable. You can’t have a three-week QA pass on a feature an agent shipped in three hours. The geometry doesn’t work. The traditional QA role collapses, and it collapses because the engineering practices around it finally have to be real.
What this means for people currently in QA roles: the role you have today is not the role that’s going to exist. Not as an evolution. As a different role.
The new role sits at par with software engineering, not downstream of it. The skills carry over — adversarial thinking, defining what correct means, knowing how systems break — but the work is different. You’re designing evals, not running them. You’re owning acceptance criteria, not validating against them after the fact. You’re embedded in the work the moment it starts, not waiting at the end for it to land in your queue.
The differentiator, for the QA people who move up, is domain knowledge. The QA folks who spent years inside one product, one regulatory environment, one customer base — they know things about how the system actually behaves under stress that engineers often don’t. That domain depth, paired with judgement work on the harness, is the lane that opens.
What I’d do if I were in QA today: stop thinking of this as your moment of arrival, and start thinking of it as a role change. Build eval suites. Design acceptance criteria templates that PMs and engineers can both work from. Make your domain knowledge visible — write internal docs about how this product actually behaves, where it fails, what correct means in your specific context. Move into the engineering organisation, not alongside it.
⸻
Customer Success
Transformation — into product strategist with a customer specialty.
The role most software companies systematically undervalued, and one that quietly becomes one of the most strategically important seats in an AI-native org.
What gets eaten: tier-1 support, ticket triage, FAQ responses, account health reporting, the recurring how do I… emails. Agents handle this faster, more consistently, and at zero marginal cost. Most CS work currently measured in ticket volume is gone.
What survives and grows: customer outcome ownership. Relationship work with strategic accounts. Escalation judgement. Product feedback synthesis — the work of distilling hundreds of customer conversations into what your product should do next. The bridge between why and what, with one foot in the customer’s reality.
CS people who make this transition start to look like product strategists with a customer specialty. The best ones I’ve seen do it by changing what they measure themselves on, before anyone tells them to. They stop counting tickets closed. They start writing product briefs from customer patterns — here’s what I heard fifteen customers say this month, here’s what I think it means, here’s what we should build. They show up to the product meeting with a point of view, not a summary. That’s the new role, and the companies that develop people into it will have a feedback loop that’s nearly impossible to replicate.
They show up to the product meeting with a point of view, not a summary. That’s the new role.
What I’d do if I were in CS today: pick up product-call authority. Earn the right to be in the room when product decisions get made. The CS person who can synthesise a customer trend into a product change is the new version of the role, and most CS leaders haven’t figured out how to develop people into it yet. Be the person who shows them what it looks like.
⸻
The pattern, again
You’ll have noticed every section above ends with some version of the same advice: move toward judgement, away from translation. That isn’t laziness on my part. It’s the pattern.
Translation work is going. It is going faster than any of us expected and it is going across every role, not just engineering. The judgement work — defining correct, holding context, owning outcomes, exercising taste — is what survives.
For some of you this is evolution. The work sharpens, the leverage grows, but the role survives in recognisable form. Product Managers, senior engineers, Project Managers, EMs — your job has a different texture in twelve months, not a different name.
For others this is transformation. QA becoming quality engineering. Customer Success picking up product authority. Designer-as-taste-keeper. The apprenticeship layer for juniors getting rebuilt from scratch. The role doesn’t just grow. It becomes a different role with the old name still attached. The transformation is real, and pretending it’s continuity is part of what stalls people.
The honest acknowledgment, because it bears repeating: this is hard. Some of these transitions are professionally scary, especially for people early in their careers. The junior engineer question is the hardest one and the industry has not solved it. Some roles that exist today, in their current form, will not exist in five years.
The opportunity is real and very large. The work that’s left — judgement, taste, outcomes, ownership, the harness — is the most interesting work software has ever had to offer. The 100x leverage is real. The new senior engineer, the new senior product manager, the new senior CS person — they’ll have a kind of impact the old versions of those roles couldn’t have dreamed of.
The transition belongs to the people who started six months ago, not the people who start six months from now.
⸻
If I got your role wrong
If you read the section that applies to you and thought that’s not quite how my work breaks down, I want to hear about it. The macro framework is the framework. The role-by-role walkthrough is my best read on it based on the conversations I’ve had this year.
The roles you don’t see here yet — data, ML, security, sales engineering, recruiting, legal-in-tech, finance ops — deserve their own walkthrough. If one of those is yours and you’d like me to think it through, send me a note.
Tell me where the map is wrong. That’s how it gets better.
⸻
What’s next
The same answer, in every role. The translation work is gone — or going. The judgement work is yours, and it’s growing.
What’s next isn’t a new job. It’s the harder half of the job you already had. The part where you decide what correct means. Where you own an outcome, not just a task. Where the question stops being did I do the thing and becomes did the thing work.
That part of your role? AI didn’t eat it. It can’t.
The translation work is gone. The judgement work is yours. That part of your role? AI didn’t eat it. It can’t.
Start there. Start now. The people who started six months ago already have a head start — but the work doesn’t close. It keeps getting more important.
That’s what’s next.