When AI coding tools started working well for us, we had a choice. We could keep the same team structure and just move faster. Or we could rethink what engineers do.
We chose the second option. The result is a model we call Product Engineers: engineers who own end-to-end delivery, from understanding the problem to shipping the solution. Not because it sounds good on a career page, but because AI made the old division of labor obsolete.
What Changed
In a traditional setup, work flows through stages. Product defines the feature. Design mocks it up. Engineering builds it. QA tests it. Each handoff introduces latency, context loss, and misalignment.
When AI handles the mechanical coding, the bottleneck shifts. The hard part is no longer "can someone write this code fast enough?" The hard part is "does someone understand the problem well enough to direct the AI correctly?"
That understanding requires product context, not just technical skill. An engineer who knows why a feature matters to users will write a better spec than one who only knows the data model. And with spec-driven development, the spec is everything.
How We Restructured
Our current model works on three tiers:
Simple features and quick wins are co-created directly by the Product team or Customer Success. They write the spec, the AI generates the implementation using our documentation layer (AGENTS.md, agent_docs), and a Product Engineer reviews the PR. These are things like UI tweaks, copy changes, simple CRUD additions, or dashboard adjustments.
We use Devin and Claude in Slack for these. A CS team member can describe a bug, tag the AI agent, and get a fix proposed within minutes. This isn't a toy demo. This is how actual bugs get resolved in our workflow.
Complex features are where Product Engineers spend most of their time. But they don't start by coding. They start by understanding the problem deeply, then design the solution at an architecture level. The spec-driven workflow (Spec, Research, Plan, Implement) handles the rest.
The engineer's job is to think well at the spec and plan stages. The AI does the research and implementation. The engineer reviews at the gates.
Architecture-level work is fully human. System design, data model decisions, cross-app integrations, performance architecture. These require the kind of reasoning and trade-off analysis that models can assist with but not own.
The Documentation Feedback Loop
One of the most important changes in our workflow is how we handle documentation. We don't treat it as a separate activity. It's embedded in the development cycle.
The flow: document using AI, review and correct, build feature plans, review plans, generate the feature.
Every time we ship a feature, the documentation for that area gets updated. AGENTS.md files evolve. New agent_docs get added. Rules get refined based on what worked and what didn't.
We improve our rules and documentation constantly so that reasoning models can direct their own decision-making. This is a compounding advantage. Every feature we ship makes the next feature faster and more reliable, because the documentation layer is richer.
What Product Engineers Actually Do Day-to-Day
A typical day for a Product Engineer at Horizon looks different from a traditional engineering role.
Morning might start with reviewing a PR that Claude in Slack generated overnight from a bug report. The code follows the patterns defined in AGENTS.md. The review is quick because the architecture is already correct. The engineer focuses on logic and edge cases.
Then they pick up a complex feature. They've already written the spec based on customer conversations and product requirements. They kick off the Research phase, review the output, approve or correct it, then trigger the Plan phase. They review the plan carefully because this is where their expertise matters most. Once approved, implementation runs.
In the afternoon, they might update the agent_docs for an area where they noticed the AI struggling. Or they work on an architecture proposal for a new system that needs human design.
The pattern: high-leverage thinking, delegated execution, continuous improvement of the system that enables delegation.
What This Requires From Your Team
This model doesn't work with every engineer. It requires people who are comfortable with product context, not just technical depth. Engineers who want to understand why something is being built, not just how.
It also requires trust in the AI tooling, which comes from the documentation layer. If engineers don't trust that the AI will follow patterns correctly, they won't delegate. Building that trust through AGENTS.md and rigorous documentation is a prerequisite.
Finally, it requires measuring the right things. We don't measure lines of code or PRs merged. We measure features shipped, bugs resolved with one prompt, and customer impact. These metrics align with the Product Engineer model.
The Bottom Line
AI didn't eliminate engineers. It eliminated the parts of engineering that were mechanical and repetitive. What's left is the hard, valuable work: understanding problems, designing solutions, making architectural decisions, and continuously improving the systems that let AI do the rest.
The Product Engineer model is how we organize around this reality. Engineers who own the full stack of value creation, from customer problem to shipped solution, with AI handling everything in between that can be specified clearly enough.