Advancements in AI-assisted coding are disrupting the traditional separation of roles and responsibilities in software teams. Agents are already replacing the people who take business requirements and turn them into technical implementation: junior developers and offshore or contract shops. Some senior engineers will get hit too, especially the ones whose value is almost entirely in the mechanics of writing software.

I don't think the answer is "everyone gets replaced." I think two roles are collapsing into one. I've started calling it Product Engineer, and it's the job I find myself doing.

The Traditional Work Pipeline

Product -> Senior Engineer(s) -> Junior Engineers (or contract/offshore)

Business leaders decide on a strategic direction for the company or application and hand it down to the Product Team. The Product Team breaks the work into stories or tickets on a backlog. Then come the grooming meetings, where engineers ask clarifying questions, debate a few implementation decisions, and estimate the work. Eventually someone implements the story.

Look at that last segment. Their job is turning business requirements into code, and that is precisely what AI is now good at. Most organizations are starting to realize this. The trouble is how they plan to respond, because many of the adjustments they'll make are bound to fail. Let's look at two ways this goes wrong.

Failure Mode #1: Vibe Coding (we don't need no stinkin' Engineers!)

Wikipedia defines "vibe coding" as:

...the software development practice assisted by artificial intelligence (AI) where the software developer describes a project or task in natural languages to a large language model (LLM), which generates source code automatically. Vibe coding may involve accepting AI-generated code without thorough review of the output, instead relying on results and follow-up prompts to guide changes.

Product Managers are feeling emboldened, and many organizations will try to replace engineers outright, since engineers are more expensive on average. But the last sentence of that definition is the important one: without thorough review of the output.

AI can do impressive things with very hard problems and then get something trivial wrong. I was recently planning the implementation of a scheduling feature and asked the agent for sample data. It gave me "Friday, November 6" as the next scheduled date. I asked it to move the schedule to Wednesday, and it cheerfully returned "Wednesday, November 6." Wednesday was actually the 4th. The hard part of the implementation, by the way, was spot on.

Someone with an engineering instinct catches that immediately. Someone who has never had to debug a date defect at 2 a.m. ships it.

The deeper problem is that most Product Managers haven't built software systems, so they don't know what they don't know. Non-functional requirements like performance, security, and scalability are invisible until they fail. A vibe-coded application is no good if it falls over under production load or gets hacked on day one. There are horror stories out there of vibe coding gone wrong - an AI coding agent from Replit went rogue during a code freeze and deleted a production database.

Failure Mode #2: The Engineer Who Just Wants the Ticket

The opposite problem lives on the engineering side. Most engineers are deeply technical. They don't much care why the business is asking for feature X; they want to be told what to do, because the part they enjoy is making it work.

I feel for these engineers, because they're the ones who will be left in the dust. The survivors will be those who embrace the business problem and can put themselves in the user's shoes.

This isn't a new lesson. In 2005, my manager and mentor Chad Fowler wrote My Job Went to India: And All I Got Was This Lousy Book, about how outsourcing was reshaping tech jobs in the US. His argument was that engineers need more than technical prowess; they need a value-add proposition, and domain mastery was a big part of it. That is true now more than ever, but for a different reason.

Even during the big outsourcing wave of the early 2000s, most projects kept a few senior engineers and augmented them with offshore or junior developers. The logic was simple: you still needed deep technical expertise, but your expensive seniors were more valuable on the bigger-picture problems, delegating the mundane, time-intensive work of turning detailed requirements into code. AI is now taking over that delegated work. The difference is that the delegate is no longer a person, and that changes what the senior engineer's remaining value is. It's the judgment about what to build, whether the result is right, or maybe even if it's worth building at all.

The Telephone Game

Remember the Telephone Game? Someone whispers a message to the next person, who relays it to the next, and so on down the line. The point of the game is that meaning gets lost in translation. The more hops, the further the final message drifts from the original.

Software teams have always played this game. The business has an idea. A product manager translates it into a story. An engineer interprets the story. A junior developer or contractor interprets the engineer's interpretation. Every handoff is a chance to lose nuance, and every one of them is also a meeting, a ticket, or a clarifying Slack thread.

I once worked on a set of features for an internal "trust and verify" system. Partner operations wanted to cut their workload by auditing only a subset of the deals that came through each month, rather than reviewing every one. A sensible goal, and one the business cared about.

The requirements reached us in bits and pieces, relayed through the product manager. We built what the stories described, and we built it well. But when the engineers finally got to talk directly with the stakeholders, it became clear that what we'd delivered, while faithful to every user story, wasn't what partner ops actually needed. We came close to scrapping the whole thing and starting over.

Nobody in that chain was incompetent. The product manager relayed what they heard. The engineers implemented what they were given. The meaning simply got lost somewhere along the way. What finally surfaced the gap was engineers talking directly to the people who would use the system, a habit I'll come back to at the end.

Here's what I think gets overlooked: AI doesn't remove the Telephone Game, but it dramatically shortens it. If the translation from requirement to code is now nearly free, then every human hop that remains is pure cost. The pipeline wants to get shorter.

The AI Is the Compiler

What about programming languages? Don't we still need developers who can read and understand what the AI produces? For now, yes. But that need will become less as time passes and the models improve. It will fade slowest in security-critical systems and highly regulated industries, where the cost of a subtle mistake is highest.

Think about the Java compiler. Does a Java developer review the bytecode it generates? I've inspected bytecode once in my career, out of morbid curiosity rather than necessity. We trust the compiler because it's deterministic, well tested, and has a long track record. AI isn't there yet; it's non-deterministic and, as my date example shows, occasionally wrong in embarrassing ways. But the trajectory is clear. The AI is becoming the compiler, and the thing we write is moving up a level of abstraction.

Specifications Will Be the New Source Code

If the AI is the compiler, the natural question is: what's the source?

Chad discusses this in his Phoenix Architecture. When an AI can generate the code and verify it against a full suite of tests, the program code becomes disposable. Maybe we still keep versions of it for backup and restore, but it's no longer the source of truth. The spec is. If there's a bug in the code, you don't patch the code; you fix the spec and regenerate.

Writing good specs, then, becomes the skill of the future, at least until AI can do that too. And a good spec requires exactly the two things that used to live in separate people: a deep understanding of the problem (what does the user need, and why?) and enough technical judgment to state constraints precisely (what are the performance targets, the security boundaries, the failure modes?). A spec written by someone with only one of those is either vague or wrong.

The Product Engineer

This is the role I've been circling. A Product Engineer:

• Owns the problem, not just the solution. They talk to users and stakeholders, understand the business motivation, and decide what's worth building.
• Writes the spec. They turn intent into precise, testable requirements, including the non-functional ones a pure product person would miss.
• Directs and verifies the AI. They know enough about systems to review what comes back, catch the "Wednesday, November 6" mistakes, and push back on architecture that won't survive production.
• Closes the loop. They watch how the result behaves in the real world and feed that back into the spec.

It's not a product manager who learned to prompt, and it's not an engineer who sits in more meetings. It's one person holding both halves of the context, which is the whole point.

What Should You Do About It?

If you're on either side of the pipeline, the path to Product Engineer runs through the half you're missing.

Product Managers: Don't just learn to code. The AI will handle much of that for you. Instead, learn what it won't think to ask about: architecture, security, scalability, and the other non-functional concerns. Work to understand how your system actually runs, and how to spot where it will bottleneck before your users do.

Engineers: Start caring about the business domain now. Talk directly to stakeholders and users as often as you can, and do it in partnership with your product manager rather than around them. Write down the business rules you hear and practice turning them into functional specifications. You already know how to explain the technical side. The skill to build is capturing the why just as precisely.

Final Thoughts

The next step for most dev teams will be this pipeline:

Product Manager -> Senior Engineer -> AI code generation

This is already happening where I work. I don't think it will be long before the first two merge, and the only thing left to get lost in translation will be the hop between the Product Engineer and the AI:

Product Engineer -> AI code generation

One hop, and the quality of that hop depends entirely on how well the human can say what they mean.