Back to one role: who a product engineer is

There was a time when one person built the whole thing. The webmaster made the page, wrote the code behind it, put it on a server and answered for every broken form. The applications were simple, the websites were simple, and nobody needed an org chart to ship a change.

Then the systems got radically more complex, and the work split. Frontend, backend, QA. Business analyst, architect, developer. Each split made sense on the day it happened. Nobody can design a complex system and build it at the same time, not with full focus on both, so the thinking went to some people and the building went to others. Between every pair of them we put a handoff.

That second picture is the one most of us still work in. A feature enters as a request and leaves as a set of tickets, one per stack and one per role. Each ticket is small and each person is busy. The request is retold at every step, and every retelling is one more link where meaning can leak.

Now the spiral has made one more turn. The part that forced the split was implementation: someone had to type all that code, in all those stacks, and one head was not enough. Implementation went to agents. So responsibility can sit in one place again.

We have a name for the person who holds it. Inside the team we call them a product engineer. It is our own term, new enough that this is the first time I write it down for anyone outside.

A product engineer takes a request and owns it end to end. They write the user stories with acceptance criteria, make the architecture, deliver the code through agents and harnesses, and review the result. No handoff to a separate analyst, no handoff to a separate developer. One person, one request, one answer at the end.

It is easy to confuse this role with a product manager. The difference is where the work ends. A product manager researches the market and decides which hypotheses go forward. A product engineer takes the capability that was chosen and makes it real, from the stories to the review of what the agents built.

This looks like the webmaster again. The difference matters.

The webmaster made simple sites. A product engineer owns a capability of a product that is far too complex for one person to type. What changed is the speed, the scale, and the price of an improvement. Every person you remove from the chain removes communication links, and every link you remove makes the next change cheaper.

The unit of work changes with it. Tasks no longer split by stack. The engineer prepares a change to a product capability, and the agents change the code repositories as a whole, in whatever stack each one happens to use.

People usually expect the gain to come from speed of typing. The model must write code faster than a person, so a team gets faster. In my experience it is often the other way around: the model writes code slower than a person, because it tries about five times more variants on the way.

To be fair to the speed argument: alone, on a new project, a plain model can be faster than a person. That part is true. The multiplier comes from elsewhere.

The gain comes from two things that have nothing to do with typing speed.

First, one person can take a task end to end. The value is that the chain of people between the request and the result gets short, sometimes one link long.

Second, the agents work around the clock, and the tasks get bigger. A working day is no longer eight hours, so there is no point in the old habit of cutting work into pieces under eight hours. Code written 24 hours a day instead of 8 gives roughly three times more. That is a calculation, not a measurement, and I would rather say so than dress it up.

One more thing a product engineer is not: the author of the harness. A product engineer uses harnesses, the shared rules, skills and checks of a team, every day. They do not write them, unless they are part of the team that builds the AI infrastructure. Owning the capability is a full-time job. Owning the tooling is another one.

Flagridge itself is the first case. Two people built the Flagridge plugin and platform in two weeks. Two people, two weeks, and both numbers are the real ones. What they built: four role harnesses for the business analyst, the architect, the developer and quality, shared Core contracts, a local Runtime, and work that passes from role to role as artifacts.

The second case is an intermediate step, and I want to describe it as one. We see it at Winery OS, one of our users, where we put the system in place. Their development moved to Flagridge in March 2026. Today a team of 10 carries the volume of work that took 18, and every change traces back to a change request.

At Winery OS the roles are still separate. The analyst, the architect and the developer each work with their own harness. Nobody there is a product engineer yet. What changed is that the handoffs became artifacts, and the chain got lighter.

That case has limits, and they belong in the same paragraph as the numbers. It is not a controlled comparison: “before” and “after” differ in more than the tooling. The figures count people, not work. And it is one team on one product; another team may see a different result.

Somewhere around here an analyst who reads this asks a fair question: what happens to me, if I do not understand code? And a developer asks the mirror one: what happens to me, if I cannot write a user story?

My answer is that AI will not replace all people. It will replace the people who do not adapt. This is the time for engineers to understand the business better, and for analysts to understand the technology better. Both roads end in the same place: one role again, the product engineer, the way it was in the time of webmasters.

Nobody has to make that move with bare hands. A harness carries the best standards and approaches of every role in a unified form, so the analyst and the engineer work to the same rules. It augments the skills of the person who uses it. People adapt, and over time they do this work better, more productively and smarter.

One more job of a harness matters here. The code and the documentation of a real product outgrew any single reader. A harness reads all of it. It finds the links nobody wrote down, between a requirement here and a module three repositories away, and puts them in front of the person before they turn into a bug.

And product engineers rarely come alone. Each one owns a capability, and together they still need shared links, a shared structure and shared approaches. Alone, the rules can live in your head. With several people, only a harness holds the shared requirements, decisions and rules.

Now the honest part about the claim itself. AI cannot solve every task today. Complex tasks still need an experienced engineer, and a product engineer will hand some work to one. I accept that. Models will get smarter, and the move has to start now, not on the day the last hard task gets easy.

The webmaster held a whole website in one head. A product engineer holds a whole capability, and the agents hold the keyboard.