I have two books that shaped how I think about product: Marty Cagan’s Inspired and Joca Torres’s Gestão de Produtos. I was even lucky enough to be mentored by Joca himself. For years those two were my map: what a PM is, what a product designer is, what an engineer is, who does what. Each role with a clear outline.
Over the last year, watching my team work with AI at Prolog, I started to feel those outlines slip. Not that the books became wrong. The layer where each role happens moved up.
In the first post in this series I told the story of the discomfort that pushed me to start rebuilding tech at Prolog. In the second, what a harness is, the infrastructure that makes AI actually deliver. At the end of the first one I promised to open up a specific part: how each job changes when AI becomes the one who builds. That’s the subject here.
The work doesn’t disappear, it moves up a layer
AI isn’t erasing the role of each profession. It’s changing the layer where the role happens.
The easy read, the one that sells fear, is “AI will replace job X”. That’s not what I saw happen. What I saw was the content of the work move: what used to be doing became directing and critiquing whoever does it.
The engineer, who used to write the code, now reviews what the agent wrote. The PM, who used to write the spec, now judges the prototype that came out of it in hours. The person is the same, and the instrument in their hand is what changed.
When I went back to Cagan and Joca with that in mind, the penny dropped differently. Both describe, carefully, the floor of each role: the concrete task, the deliverable, what leaves your hands at the end of the day. And that floor is exactly what AI is taking over. What’s left for the human is what used to sit on top: deciding what’s worth building, finding the hole in what got built, having the taste to know what’s good. The ceiling, not the floor.
So I’ll do what I did for myself: take each role’s definition from the books, and ask what AI eats from it and what survives (and gets more expensive).
The team of three, according to the books
Before splitting it role by role, it’s worth recalling how the books assemble the team. Joca is direct: a successful product has to be desirable, viable and feasible, and that defines what he calls the three essential functions to build a successful product: a UX designer, product management and a developer. That trio is the core team (ch. 2). Cagan, in Inspired, describes the same roles in his opening chapter, “Key Roles and Responsibilities”.
Both insist on a point I’ll come back to at the end: it’s not a boss-and-subordinate relationship. In Joca’s words, product engineering, product management and UX are a team, with no subordination between any of these groups (ch. 31), and in Cagan the same idea shows up as PM and engineering being peers, neither position subordinate to the other (ch. 5). When AI steps into the middle of the trio, it’s that partnership that changes shape most.
Engineer: from code producer to agent critic
For engineering, what counts stopped being how much code you produce: it became how well you critique what the agent produced.
Joca’s definition almost hurts to revisit now: product engineering is responsible for developing the product and keeping it running, and, a little further on, engineering builds the product (ch. 31). Build was the verb. Cagan completes it from the other side, on the relationship with product: the product manager defines the solution, but the engineering team knows best what’s possible, and they’re the ones who ultimately deliver it (ch. 5). Define on one side, deliver on the other.
Now the delivery of the first version belongs to the agent. What didn’t change, and got more expensive, is everything Cagan pinned on the engineer as a source of innovation: engineers know better than anyone what’s possible (ch. 5). Knowing what’s possible, finding the hole in the plan the agent proposed, seeing the performance or security trade-off it can’t see, deciding when to step in and when to let it run. That weighs more every month. Syntax from memory, boilerplate by hand, combing Stack Overflow, lines of code as a personal trophy: that weighs less.
At Prolog I said it to the team in plain words: no one will be evaluated by lines of code. Whoever was always good at “finding the hole” gets more valuable, and whoever identified with “producing a lot of code fast” will have to recalibrate where they invest. And this doesn’t make engineering worth less. Its value was always more about knowing what holds up than about producing fast, and now that just becomes explicit.
PM: from spec-writer to iteration architect
The PM feels it when the prototype gets cheap: the work stops being writing the document and becomes choosing which idea is worth the team’s time.
Cagan is categorical about the heart of the job: someone has to discover what the solution, the product, actually is, including the features, the user experience and the release criteria. That someone is the product manager, and that task is the heart of the job (ch. 1). Joca gives the wide outline: product management is the function responsible for every aspect of a software product, across its whole life cycle, from conception to end of life (ch. 2).
Notice that in both the key word is discover, not specify. Cagan has an entire chapter defending that the job is discovery, not “requirements”: software has two stages, figuring out what to build (the right product) and building it (the product right). The first is discovery, the second is execution (ch. 12). That was always his message. AI just made it literal.
Because when the build collapses from weeks to hours, the bottleneck stops being building and becomes deciding what’s worth building. The long spec reviewed by committee, the closed quarterly planning, the status report as a deliverable, the traffic control between engineering and design: all of it weighs less. What weighs more is fast discovery (prototype to understand, not spec to build), curating hypotheses (which idea deserves the team’s time) and deciding what not to do, more often. Some companies are already calling this PM an “Editor” or an “Architect”. It’s not less PM: it’s a different PM, the one who curates, who decides with taste, who gives direction. What was central in the old version, writing the spec, is what got light.
Product designer: from screen producer to experiment conductor
In design, the unit of work leaves the screen and moves to the system that produces screens, and the product designer starts choosing which variation survives.
In Joca, the definition of UX is to understand in order to design: UX is responsible for deeply understanding the user and the problem you want to solve for them (ch. 32). And the flow he describes is the ritual everyone knows: paper prototype, then wireframe, then the visual designer adds color and form to the screens. Cagan cuts the role in two with the same logic: the interaction designer develops a deep understanding of the users and creates the tasks, navigation and flow, maps that to wireframes, and passes them to the visual designer, who puts flesh on the wireframe (ch. 4).
That sequence, understand, sketch, refine screen by screen, is exactly what AI shortens. The unit of work stops being “the screen” and becomes “the system that generates screens”. Redoing the same variation five times in Figma, specifying component by component, the pixel-perfect handoff as a rite: weighs less. Prototyping at iteration speed (several options in parallel, throw away the bad ones), defining the visual system instead of each isolated screen, and fast visual critique (seeing AI propose something and catching that it’s wrong before the user does): weighs more.
And here Cagan says, back in 2008, something that protects the product designer from thinking they became a button-pusher: the job was never just to draw something pretty. A good product requires a good user experience, and a good user experience requires the close collaboration of product management and design (ch. 4). AI generates the variation. Whoever decides which one deserves to reach the user is still a person with taste.
QA: from tester to validation builder
QA is the most interesting case, because it’s the role the books barely isolated, and the one AI moves the most.
Look: in Joca’s trio (designer, PM, developer) and in Cagan’s roles, quality shows up diluted, as a responsibility of the team, not as its own seat with its own method. For a long time that made sense. It doesn’t anymore, and the reason is simple: if the agent builds fast and validation stays manual, all you produced is technical debt at high speed.
So QA stops being whoever runs the test case by hand and becomes whoever designs the testing harness, the system that tests the system: configuring AI to write tests for code another AI wrote, catching regressions before the user does, thinking about where a defect tends to appear. In practice it became an operational question we adopted: every bug that slips through turns into “how do we detect this automatically next time?”. Exhaustive manual testing of a known flow, regression run by hand every release, QA as the single gate before shipping: weighs less. Validation as a system, not as a handoff at the end of the line.
It’s the role that rises the most precisely because it was the least defined. Where the books didn’t carve an outline, AI is drawing a new one.
The constant: what the books already said mattered most
There’s one thing that doesn’t change, and it was hiding in plain sight in both books: what they name as the most important thing is exactly what AI doesn’t do.
Joca opens his chapter on the traits of a good PM with no hedging: the most important of all, without a doubt, is empathy (ch. 4). Not a function chart or a deliverable: it’s the ability to put yourself in the place of whoever uses the thing. Cagan, for his part, spends the whole book defending discovery, taste and judgment over process, and both, each in their own way, were saying the same thing: what separates the good from the average was never the mechanical part of the work.
And the mechanical part is exactly what went to the agent. Writing the spec, drawing the screen, writing the code, running the test. What stayed, and got more expensive, is critical thinking, taste (knowing what’s good), judgment under ambiguity, curiosity, care for whoever uses what you make. To put it in the line I used with the team: the content of the work changes, the person doing it doesn’t.
What it will cost (no clichés)
I don’t want to wrap this up too neatly, because it isn’t. This shift costs concrete things, and none of them are comfortable.
The first is leaving a decade of habits behind. Whoever’s been five or ten years in the old way carries patterns that helped them get here. Those same patterns are the ones that weigh against changing. There’s no shortcut, and the discomfort is expected.
Then, critiquing AI as much as creating with it: accepting the suggestion that showed up isn’t work; finding the hole in the plan it proposed is. What was always expensive (critical thinking, taste, judgment) gets more expensive.
There’s also failing as a team, not as a person. We don’t fire an engineer over a bug in production, we improve the review, and when AI gets it wrong it’s the harness we strengthen. An agent’s bug is process, not person: a commitment, not a slogan.
And the most uncomfortable one: accepting that some functions change more than others. That creates discomfort for whoever changed little so far, and you can’t pretend everything’s the same. What you can do is bring it into an open conversation.
And so I don’t sound like someone who arrived: Prolog is still early in this. We’re still AI-assisted, with a 10 to 20% gain, not AI-first at 5x or 10x. I’m describing a direction we’re building, with hits and misses, not a victory.
What I take from this
The books didn’t become wrong. They described the floor of each role with a precision I only really understood now (write the spec, draw the screen, build the product, run the test), and that floor now belongs to the agent. And what’s left for the human is the ceiling, judging, critiquing, having taste, caring for whoever uses it, which, going back to Cagan and Joca, is what they said mattered most from the first page.
Maybe that’s the good part: the work AI took out of our hands is the most repetitive part, and what it left is what was always the hardest, and the most interesting. I’ll keep telling how it goes.
Sources
- Marty Cagan, Inspired: How to Create Products Customers Love (1st edition, 2008). The role definitions come from chapters 1 (Key Roles and Responsibilities), 4 (Product Management vs. Design), 5 (Product Management vs. Engineering) and 12 (Product Discovery).
- Joca Torres, Gestão de produtos: Como aumentar as chances de sucesso do seu software (Casa do Código). The definitions come from chapters 2 (What is software product management?), 4 (Key traits of a product manager), 31 (Product engineering and product management) and 32 (UX and product management).
- The reading on the role moving up a layer backs the series: OpenAI, Harness Engineering, and Peter Pang, CTO of CREAO.