A working screen is a beginning. Someone still has to decide whether it solves the right problem, what happens when the connection drops, and how a person recovers when something goes wrong. Those decisions connect the interface to the system behind it. They are the work I mean when I talk about product engineering.
Coding agents make it easier to get a first version running. That gives us more room to explore, but it also makes judgment more visible: which version is worth pursuing, what needs to change, and when the product is ready for someone to depend on it.
I wrote about the product engineer's skillset in 2025. This is how I think about that work as agents take on more of the implementation.
Start with the experience
Lee Robinson's Product Engineers describes an approach that resonates with me: start with the experience you want to create, then work back to the technology that makes it possible. That requires a broad understanding of the stack and enough depth to apply it well.
Consider a document upload. The component is only one part of the feature. People need to know which files are accepted, whether an upload is progressing, and what to do if it fails. The backend needs to validate the file, enforce access rules, and make retries safe. If processing takes time, the product needs a way to tell someone when the result is ready.
A product engineer follows those connections. The responsibility extends from the first interaction to the behavior of the running system.
Frontend, backend, and infrastructure expertise all contribute to that work. Product managers and designers contribute research, priorities, and experience design. The value of product engineering is being able to work across those concerns and carry a decision through implementation without losing its purpose.
A forward deployed engineer often does similar work in a particular customer's environment. The emphasis shifts toward making the product useful within that customer's systems and processes. The roles overlap; their scope depends on what the team needs someone to own.
Judgment takes practice
An agent can help identify failure cases, generate alternatives, and test behavior. It still needs a clear objective and someone who can assess whether the result fits the product.
For the upload flow, a passing test might prove that a file reaches storage. It won't necessarily tell you whether the progress indicator makes sense to a person on a slow connection, or whether an error message gives them enough information to continue. Those questions need explicit attention.
This is why I associate product engineering with substantial ownership. It takes experience to recognize tradeoffs across design, data, reliability, and delivery, and to know when a specialist needs to be involved. Engineers can develop that judgment throughout their careers. A title alone doesn't establish it.
Contact with users is part of developing it. Watching someone struggle with a flow can reveal a problem the team never thought to put in the specification. Technical skill becomes more useful when it is informed by that understanding.
Where agents fit in my work
I use agents to shorten the distance between an idea and something I can evaluate. The most useful workflow keeps the intended experience visible throughout the work.
Describe the behavior. Before implementation, I want to know what the person is trying to accomplish, what constraints apply, and which failures matter. For an upload, that could include file limits, mobile behavior, cancellation, retries, and access permissions. The specification can be short, as long as it answers the questions that would otherwise become guesses.
Make the interaction tangible. A prototype lets me try alternatives and notice awkward transitions. Being able to click through a flow changes the conversation: an abstract concern becomes something the team can see and adjust.
Review the whole path. I look at copy, loading states, errors, and permissions alongside the implementation. Automated checks provide evidence about correctness. Using the product provides another kind of evidence. Both belong in the definition of done.
Use the saved time to explore. Faster implementation makes it practical to compare approaches before committing to one. Sometimes the best result is a smaller feature or a simpler interaction than the first proposal.
Those decisions also shape the work handed to an AI coding factory. Automating delivery is useful when the system has a clear target and meaningful checks for reaching it.
What I would look for when hiring
I would ask a product engineer to walk me through something they shipped. What did users need? Which alternatives did they consider? What changed after feedback? Where did a technical constraint reshape the experience?
Those answers reveal how someone connects decisions across the product. A polished demo is useful evidence, but so is an explanation of a difficult compromise or a failure that led to a better design.
The opportunity with agents is to spend more time on that work. We can test ideas sooner and carry more of them into a running product. The responsibility remains to understand what people need, make thoughtful choices, and stay with the result long enough to learn whether it helped.