Are product and engineering teams debating the wrong thing?

Over the past few weeks, I have had many conversations with product and engineering leaders about what machine intelligence is doing to the way teams build software.

The questions are real: who owns prompting internally, whether traditional product design still has a place, whether product management is becoming a bottleneck, whether engineers should get closer to users, whether product people should become more technical, and what it actually means for a team to become machine-intelligence-native instead of simply adding machine intelligence on top of the same old process.

These debates matter. They matter because thousands of people are already seeing their work, status, responsibilities, and sense of usefulness shift under their feet. They matter because organizations still need accountability. Someone still needs to decide what good looks like, what should be built, what should not be built, and who is responsible when things break.

But I also think these debates are one layer too high.

They are mostly debates about the workshop: the roles, boundaries, rituals, ownership lines, handoffs, and power structures of software production as we know it.

The deeper shift may be happening underneath that.

Why product and engineering were separated

For a long time, the separation between product and engineering made sense. It was not just corporate theatre. It came from a real constraint: execution was hard.

The distance between deciding what to build and actually building it was wide enough to require different kinds of expertise. Product learned to hold the user, the market, the messy human context, and the contradiction between what people say they want and what they actually need. Engineering learned to turn intention into running systems, under real constraints: infrastructure, security, latency, cost, maintainability, accumulated debt, and previous decisions that could no longer be wished away.

Both disciplines developed their own tools, rituals, instincts, and status.

The model was not perfect, but it was coherent. Someone understood the problem. Someone specified the thing. Someone built it. Someone shipped it. Someone maintained it. Someone supported it. Not always in that order, not always that cleanly, but close enough.

Software was organized with an industrial logic: thinking, specifying, building, distributing, maintaining, supporting.

That structure made sense when execution was scarce, specialized, and slow.

Machine intelligence is compressing the handoff

That condition is changing.

Not everywhere. Not at the same speed. Not in the same way for a ten-person startup, a public institution, a broadcaster, a national bank, or a highly regulated infrastructure company. Pretending the timeline is uniform would be lazy.

But the direction is clear enough to name: machine intelligence is compressing the distance between thinking and building.

Engineers can prototype in minutes what used to take days or weeks. Product people can generate working interfaces from descriptions.

This does not mean execution disappears. It means execution stops being the only place where scarcity lives.

And when that happens, the old handoff model starts to lose the justification that produced it.

The last two stations in that chain are worth pausing on. In the current rush to build and ship faster, maintenance and support are the functions most likely to be treated as someone else's problem, or deferred until later. But the work does not disappear. It accumulates. There is a striking data point from one organization I have been chatting with: roughly 80% of their code is now written by AI, but overall productivity has only improved by about 20%. The bottlenecks did not disappear. They moved. My guess is that a significant part of where they moved is exactly here: into the unglamorous, invisible work of keeping things running, understanding what was shipped, distributing it, and absorbing the consequences of decisions made at speed.

This is why the prompting debate feels both important and too small at the same time. When an engineer prompts a model to build a feature, they bring something real: a feel for system constraints, tradeoffs, failure modes, what the infrastructure can bear, and what will become painful later. When a product person prompts the same model, they also bring something real: a model of the user, the use case, the confusion points, the success criteria, and the reasons a technically impressive thing may still be useless.

Neither lens is optional; they shouldn't be.

But the interesting part is not deciding which role gets to touch the prompt. The interesting part is that the prompt exposes the judgment underneath each role.

The role debate is real, but transitional

Product judgment and engineering judgment were never as separate as the org chart suggested. They were made to look more separate because execution required a long chain of specialized work.

As that chain compresses, the overlap becomes harder to ignore.

This is uncomfortable because execution gave both disciplines a place to stand. Engineers who thought their value was writing code may find that their deeper value was understanding systems: what should exist, what can safely exist, what will break, what should not be automated, and what should remain boring, visible, and controlled.

Product people who thought their value was coordination may find that their deeper value was judgment: who this is for, why it matters, what evidence counts, what tradeoffs are acceptable, and what should not be built just because it can now be built cheaply.

That is clarifying, but it is also threatening. If execution becomes cheaper, faster, and more widely available, then status can no longer hide behind throughput. A team cannot simply say "we shipped." A product person cannot simply say "I aligned stakeholders." An engineer cannot simply say "I implemented the spec."

The harder questions move up a level.

Was this the right thing to build? Can we maintain it? Who is accountable when the demo becomes infrastructure?

But we may still be in a transitional moment.

Most of these debates assume that the software production model remains basically intact. Product defines. Design explores. Engineering builds. QA tests. Operations deploys. Support absorbs the consequences. Machine intelligence is then added into each step to make the process faster.

That is probably where many organizations are today.

But it may not be where the system is going.

The factory is moving into the grid

If products can increasingly generate parts of themselves, observe their own failures, and adapt over time, then the question is not only how product and engineering roles change. It is whether those roles were partly artifacts of a specific production system. One that is now changing underneath us.

The model providers are not just selling access to intelligence. They are building the environment where future workflows, agents, memory, and applications will live. The more products become adaptive and agentic, the more the platform underneath becomes the product's real operating environment. That is where value is accumulating. It is also, strangely, the layer that features least in most product conversations I have been part of.

I do not think that is an accident. The workshop is visible, familiar, and full of people whose interests depend on its continuity. The grid is abstract until it is not.

Dependency is becoming infrastructure

This is where the dependency question gets serious.

We talk a lot about how teams should use machine intelligence. Governance, acceptable use, prompting practices, workflow automation. These things matter. But there is much less attention to what is being built underneath.

Organizations are creating real dependency on a small number of external providers. Usually not carelessly. The tools are good. The pressure to move fast is intense. The short-term logic often makes sense.

A startup may decide, rationally, to trade long-term optionality for speed. That can be a valid choice. But it is still a choice.

Every agentic workflow added to an operation is another connection to infrastructure someone else controls. Models get deprecated. Pricing changes. Behavior shifts between versions, sometimes in ways you only notice when something breaks. A process that looked like an efficiency gain can become a dependency you did not mean to create.

My colleague Raffi Krikorian has been writing about this in Owners Not Renters. One number he cites stayed with me: most executives believed they could switch machine intelligence vendors within four weeks if needed. Among those who had actually tried, a majority said the migration failed or cost far more than expected. The gap between perceived control and actual control is wide. And it does not close by itself.

There is a real difference between using a model as a replaceable component and making it the substrate of how customers are served, employees are evaluated, or institutional knowledge is accessed. The first is usage. The second is infrastructure. And infrastructure needs a different kind of judgment before you build on it, not after.

This is not an argument against using external models. It is an argument for being honest about what you are choosing.

The transition will not be evenly distributed

There is another reason to be careful here: the transition is not happening evenly.

In tech, it is tempting to talk as if machine intelligence is already reorganizing all work at the same speed. It is not. Many people outside software are not yet experiencing this as a direct transformation of their daily work, or they are experiencing it indirectly through platforms, scheduling systems, assessment tools, customer interfaces, management processes, and institutional pressure.

Manual work, care work, teaching, hospitality, logistics, repair, public service, and many forms of human-facing work do not change in the same way or at the same pace as software development. Some of them may be affected later. Some are already being affected quietly. Some will resist automation because the human part is not an inefficiency to remove but the work itself.

The product and engineering debate is not the whole labor debate. It is a debate happening in one part of the economy, among people whose work is unusually exposed to the same systems they are building.

But that is also why it is interesting.

Software teams are not just adopting machine intelligence. They are becoming an early site where machine intelligence changes the production system from inside. The same people building the tools are also being reorganized by them.

That makes the debate about role legitimacy real. It also makes it insufficient.

The question is not whether product or engineering wins

I do not think the future of product and engineering is about one discipline absorbing the other. That is the wrong anxiety.

The real question is what both disciplines become when execution is no longer the hardest part of the work.

My current view is that the most valuable people will not be the ones defending old boundaries most aggressively. They will be the ones able to combine judgment across layers: people who can understand users without being naive about systems, people who can understand systems without being indifferent to users, people who can move fast without pretending speed is the same thing as progress, and people who can use external infrastructure without forgetting that dependence compounds.

The important question is not only "can we build this?"

It is also: what are we binding ourselves to by building it this way?

That is the level where the real work is moving. Not away from product. Not away from engineering. Away from execution as the main source of value.

The debates in the room are worth having. But if the conversation stops at role ownership, we will miss the larger shift.

The organizations that adapt best will not be the ones that simply become faster at shipping machine-generated work. They will be the ones that understand where judgment, risk, control, and value have moved.

And increasingly, they may not have moved to the role that writes the prompt or the team that owns the workflow.

They may have moved into the grid.

This piece continues a thread I have been pulling on in earlier posts, including When Shipping Becomes Too Easy and Build AI Products You Can Still Control. My ex-colleague Alejandro's Owning Code in the Age of AI is where the scarcity shift in code felt clearest to me. Davide Rovati's essay on product management engineering captures the role convergence in concrete terms and is worth reading alongside this one. Raffi Krikorian's Owners Not Renters is the most rigorous place I know to follow the infrastructure dependency question. And Luiza Jarovsky's newsletter keeps me honest about what these conversations look like beyond the tech industry.