If our experience is anything to go by, product managers will be adding depth to the direction setting probably. They can dive deeper on research of all types: pricing, user interviews, growth, etc.
Cheap code generation just accelerates the accumulation of unowned runtime surface. The primary constraint has always been verification and operational triage: tracing silent exceptions, schema drift, and resource leaks that never trigger an alert.
the part nobody talks about is that reviewing an agent's PR is harder than just writing the code yourself — the agent is confident and wrong in ways that take real digging to catch. I've started writing the 'why' and the acceptance criteria up front and treating the code like someone else's job. the monitoring framing rings true but it doesn't feel like shipping, and I think that's what engineers will miss the most.
I don't necessarily think reviewing an agent's PR is harder than writing code yourself. If that was the case, then we wouldn't see more PRs ship when we use AI to write them. I do agree with the spirit though, that this is a critical bit.
Also agree on the basically agent-first version of test driven development, writing the why and acceptance criteria up front. If you were to fit this into this framework, it would happen at the direction and decision phase, rather than the observing one.
> Engineers aren’t going away. They'll be piloting the product loop.
In that case, what's the plan for Product Managers?
If our experience is anything to go by, product managers will be adding depth to the direction setting probably. They can dive deeper on research of all types: pricing, user interviews, growth, etc.
Product managers still have a big role to play!
Cheap code generation just accelerates the accumulation of unowned runtime surface. The primary constraint has always been verification and operational triage: tracing silent exceptions, schema drift, and resource leaks that never trigger an alert.
the part nobody talks about is that reviewing an agent's PR is harder than just writing the code yourself — the agent is confident and wrong in ways that take real digging to catch. I've started writing the 'why' and the acceptance criteria up front and treating the code like someone else's job. the monitoring framing rings true but it doesn't feel like shipping, and I think that's what engineers will miss the most.
I don't necessarily think reviewing an agent's PR is harder than writing code yourself. If that was the case, then we wouldn't see more PRs ship when we use AI to write them. I do agree with the spirit though, that this is a critical bit.
Also agree on the basically agent-first version of test driven development, writing the why and acceptance criteria up front. If you were to fit this into this framework, it would happen at the direction and decision phase, rather than the observing one.