For most of my career, the best engineer in the room was the one who could implement anything. Hand them a hard problem and they came back with working code. That was the job, and it was a good one.
Coding agents take a large part of that and make it cheap. The implementation still matters, but it is no longer where a person adds the most value. So the word “engineer” has to carry something else, and on the teams I work with it carries product engineer.
The line between code and judgment
A product engineer owns the decision, not the keystrokes. They decide what to build and why. They shape how it feels to use. They hold the standard for whether the thing is actually finished, which is a judgment no model will make for you.
The agent is very good at the middle of all that. Give it a clear intent and a codebase with strong conventions, and it will produce the change. What it cannot do is care about the outcome. Caring is the part you keep.
The work that survives automation is the work that decides what “good” means.
What this asks of a Rails team
This is why I spend my time on workflows, the harness, and agentic-coding patterns rather than on the model itself. A team becomes product engineers when the tooling lets them work at the level of intent and review, and when the agent is wrapped tightly enough that its output is trustworthy by default.
Rails helps here more than people expect. Its conventions are shared context, and shared context is exactly what an agent needs to stay inside the lines. A team that already agrees on how things are done has most of a harness already built.
None of this removes the engineer. It moves them up. The teams that see that early are the ones that will own their product while everyone else is still reviewing autocomplete.