For a long time the division of labor in software teams made sense. A product manager decided what to build, a designer decided how it should look, and an engineer built it. That split was partly about specialization, and partly about cost: implementation was expensive, so you did not want engineers guessing.
Coding agents are changing the cost side of that equation. This post looks at what that means for engineers, using two recent pieces from Atlassian, and ends with a routine you can start this week.
The definition worth borrowing
In How AI turns software engineers into product engineers (January 2026), Atlassian describes product engineering as three things combined:
Technical excellence + customer context + strategic problem-solving.
The point is not that engineers should become product managers. It is that an engineer with enough context can take part in defining the problem instead of receiving a ticket and implementing it.
Why now: the scarce thing moved
The article's central claim is that the time between "I know what we should build" and "here is a working prototype" has shrunk from weeks to hours, so the scarce resource is no longer engineering capacity but knowing what is actually worth building.
If you accept that, the implications follow naturally:
- A prototype becomes a conversation tool. You can show a customer something real before a spec is finished.
- A PM can prototype, and a designer can change a working product, so the boundaries between the three roles blur.
- The engineer who understands the customer has more leverage than the one who only understands the codebase.
Outcomes instead of output
Atlassian contrasts how success is measured. A traditional engineer is judged by story points and sprint velocity; a product engineer by customer outcomes and feature adoption. The activities that go with it are concrete: joining user interviews, reading support tickets, getting direct customer feedback, validating with a small group of "lighthouse" users, and contributing to prioritization.
The article also reports that teams working this collaboratively see 70% higher feature adoption. Treat that number with caution: it is Atlassian's own claim, and I could not see how it was measured. The direction is plausible, the size is unproven.
The bottleneck keeps shifting
A second Atlassian piece, The bottleneck keeps shifting (May 2026), adds the other half of the story. Its thesis: the constraint is no longer producing enough output, but deciding what to build and having the restraint to build something good. The author calls discernment the new superpower for product managers.
The article uses the AI presentation company Gamma as an example: a PM-to-engineer ratio of 1:4 compared with the historical industry norm of 1:10, and half of the PMs and designers committing code. It claims one PM with four engineers now gets done what eight to ten engineers once did. That is a single company's account, but it shows what a blurred role boundary looks like in practice.
Cheap building has a trap. When anything can be built quickly, it is easy to build too much. Restraint, knowing what not to build, becomes a real skill.
Five questions before you open the editor
An AI-native product engineer asks more upstream questions than "how should I implement this?":
- What problem are we actually solving?
- For whom?
- What behavior would count as success?
- What should explicitly not happen?
- How could we prove the solution worked?
Notice that the last three are specification and evaluation. Problem framing, specification and evaluation start to look like one skill, which the next posts in this series explore: AI doesn't just scale execution. It scales ambiguity and Evals are product analytics for probabilistic software.
A routine you can start this week
None of this requires a new job title. A few small habits get you most of the way:
- Read five support tickets or user comments each week. Pick ones from real users, not summaries.
- Sit in on one customer conversation a month. Even as a listener.
- Write a three-line problem statement before you start a task: the user, the problem, the success signal.
- Define one adoption metric for what you ship, and look at it two weeks later.
- Ship early to a few real users before the full release.
Where this does not apply
Not every engineering job faces a customer directly. Platform, infrastructure and security work has internal users, and the same questions still apply, just with colleagues as the customer. And depth still matters: customer context makes strong engineers more valuable, it does not replace technical skill. Having the context to question a requirement only helps if you can also build the better answer.
The one-line version
AI doesn't eliminate engineering. It removes the excuse for engineers not to understand the customer.