The Product Engineer: How AI Is Rewriting the Rules of Software Teams

For years, software development was a rigid assembly line: PMs wrote the Jira tickets, engineers translated them into code, and QA and DevOps pushed it across the finish line at the end of a sprint.

AI coding agents changed that. Translating a spec into working code is no longer the hard part. Knowing what to build and why is. That shift has put a new role at the center of modern software teams: the Product Engineer.

The Product Engineer

Picture one person who talks to a customer at 9 a.m., writes a spec at 10, has a working prototype by noon, and pushes a new release by 2 p.m. They didn’t write most of the code. Their AI agents did. They decided what to build, why it mattered, and how it should work. Then they pointed a fleet of agents at the problem and steered the output into production. All before end of day.

That person is a Product Engineer (PE). They operate like a product owner who can build, or a technical founder of every feature they touch. They don’t wait for a PM to hand them requirements. They go find the problem, define the solution, and ship it.

While a full-stack developer spans the frontend and backend, a PE spans the entire product lifecycle. They set the direction, while supporting engineers act as the interface between spec and agent: reviewing AI output, catching errors, and keeping the machinery running.

Because AI hallucinates and writes messy code, a PE’s real job is building guardrails. They don’t just prompt an agent; they write strict tests, double-check logic, and make sure the AI solved the user’s problem instead of spitting out code that compiles but doesn’t work. Daniel Bentes wrote about this shift on Medium, calling it “product engineering discipline applied to probabilistic systems.”

Companies Are Already Hiring for This Role

Job boards are already full of PE listings that read nothing like traditional software engineering roles. The expectations: own the product, use AI agents, ship without a PM telling you what to do.

Vellum, an enterprise AI platform, posted an AI Product Engineer role that says it plainly: “In 2025, tools like Cursor, Devin, and Claude gave engineers superpowers.” They want someone with a “product-minded, high ownership” mentality who ships features autonomously.

Lago, a YC-backed billing platform, hired a PE to take internal AI prototypes running on Claude Code and turn them into a production-grade multi-agent platform. The success metric: “At 3 months, the first monolithic skill is decomposed into independent agents.”

Trellis AI, a YC W24 healthcare startup, asks their PEs to “design and develop AI agents, including computer-use agents, to interact with other systems.” Their listing spells out the PE ethos: “Trellis engineers have the agency and autonomy to architect, build, and ship features end-to-end.”

Abnormal Security hired an AI Product Engineer to build infrastructure powering “a growing fleet of AI agents operating across Sales, Customer Success, and Marketing.” The listing captures the PE duality: “Some weeks you’re extending agent infrastructure. Other weeks you’re shipping GTM tooling, moving fast because the shortest path to impact is writing the code yourself.”

Decagon, backed by a16z, hires full-stack PEs to translate complex engineering into self-serve AI products. Crux Climate hired their first AI Product Engineer to work “from 0 to 1,” combining customer interaction, full-stack architecture, and LLM evaluations in a single role. Hex.tech hires PEs to build features across the stack while refining agentic AI capabilities.

The role looks different at each company, but the job description reads the same: own the product, use AI agents as your team, ship.

Who Becomes the Product Engineer: PMs or Engineers?

If the PE role combines product thinking with engineering skill, who’s better positioned to fill it? Both sides of the aisle are converging, but the path from engineer to PE is shorter than the path from PM.

An engineer who learns how to interview a frustrated user, tell a sales team “no,” and define a feature’s business goal has a smooth learning curve. They already understand system architecture, debugging, and production constraints. Picking up product skills means putting down the IDE and looking at user behavior: watching session replays to see where a customer gets confused, querying the database to see if anyone clicked the button you built, and learning to say “no” to feature requests that don’t serve the core product. The Pragmatic Engineer notes that a PE can recognize when tweaking a feature slightly achieves the same user outcome at 10% of the engineering effort. That trade-off instinct comes from a technical foundation.

PMs face a steeper climb. AI tools like Cursor let PMs spin up prototypes in hours, open pull requests, and validate ideas with working software instead of slide decks. PMs at companies like BlueConic are generating code snippets, automating tests, and shipping features. That helps with validation. Prototyping and production are different games, though. A Business Insider report from early 2026 found that the engineering bottleneck has shifted from writing code to system architecture, AI-generated technical debt, and security. A PM who can generate an app with AI still struggles to deploy it at enterprise scale, debug hallucinations in agent output, or untangle deeply nested logic errors. AI amplifies both good and bad technical decisions, and you need engineering depth to tell the difference.

AI now automates the PRDs and discovery summaries that used to fill a PM’s calendar. PMs who operated as “high-end administrative workers” are seeing their roles shrink. Engineers armed with Cursor and Claude Code are filling the vacuum: talking to users, defining the architecture, and writing the specs themselves. Companies like Linear scaled to a $1.25 billion valuation with about 40 engineers and only 2 PMs. CEO Karri Saarinen’s philosophy: “No product managers, just a head of product. PM duties are distributed across engineering and design.”

PMs can use AI to generate boilerplate, but they hit a wall when the AI breaks a database migration or creates a subtle memory leak. Engineers have a head start because they already know how to debug and fix the messes AI leaves behind. That’s why engineers are absorbing the PM role faster than PMs are absorbing the engineering one.

Spec-Driven Development Replaces Sprint Planning

Traditional Agile rituals like story point poker, two-week sprints, and backlog grooming make no sense when a feature goes from spec to production in an afternoon.

The spec is the artifact that matters. A good one defines the problem, the user, the expected behavior, the edge cases, and the acceptance criteria. Both humans and AI agents can work from it. The Product Engineer writes it, gets it reviewed, and feeds it to their agents.

Tools like Shotgun are built for this workflow. Shotgun is an open-source CLI that indexes your codebase, researches internal and external patterns, and generates a structured, codebase-aware technical spec. It then breaks that spec into staged tasks that AI agents can follow file-by-file, producing clean PRs instead of chaotic 10,000-line diffs. A case study by Bartek Pucek found that a team burned 16 hours building a complex feature through direct prompting. When they used Shotgun to write the spec first, it took 1 hour to spec and 90 minutes for the agent to implement it. As the author put it: reviewing spec-less AI code felt “less like code review and more like an autopsy.”

Grounding Agents in Reality

A spec tells agents what to build. Grounding tells them how your codebase works so they don’t hallucinate. Without grounding, ~20% of AI package recommendations point to libraries that don’t exist, and 29-45% of generated code uses deprecated APIs or contains security flaws.

The fix is Model Context Protocol (MCP) servers that give agents live access to your codebase and documentation. Tools like Context7 let agents query version-specific docs for thousands of libraries before writing a single line. Your agent asks about Next.js routing, and Context7 fetches the exact docs for your version. No hallucinated methods. No deprecated syntax.

The PE’s job is to wire up this grounding infrastructure: connect agents to your GitHub repo via MCP, set up documentation servers, and make sure the agent reads your code before it writes new code. The “Three Amigos” meeting where PMs, designers, and engineers sat together to write Jira tickets is becoming one Product Engineer with Shotgun, Claude Code, and a stack of MCP servers open in a terminal.

Smaller Teams, Bigger Output

The median private SaaS company generates about $130,000 in revenue per employee, according to Stripe’s benchmarking data. AI-native companies hit $2.2 million to $5 million. Jeremiah Owyang’s Lean AI Native Leaderboard found the top 10 most efficient AI startups averaged $3.48 million per employee. Cursor hit roughly $5 million. A 17x to 38x gap over traditional SaaS.

Inference costs dropped 99.7% from GPT-4’s launch ($37.50 per million tokens) to $0.14 today, per J.P. Morgan’s cost-efficiency benchmarks. Products that cost $500,000 to build can be prototyped for $500.

A viral Dev.to analysis citing McKinsey data coined the “Commando Unit”: 1-3 senior generalists with minimal communication overhead who achieve 5-7x efficiency over traditional teams. The classic “Two-Pizza Team” of 8-10 is too big. McKinsey’s own research found that bolting AI onto traditional Agile teams yields only a 10-15% productivity gain because communication overhead eats the rest.

One senior architect using an agentic IDE produces what five junior developers used to. Put two or three of those people together and they build what used to take 20.

The tooling makes this possible. A senior architect using Cursor or Claude Code can do multi-file edits from natural language. Autonomous agents like Devin can analyze requirements, run tests, and open pull requests without a human touching the keyboard. GitHub Copilot hit 4.7 million paid subscribers by January 2026.

Because AI makes it so cheap to generate code, the danger is no longer shipping too slowly. The danger is shipping a bloated, confusing mess. The scarce resource is curation, what some call “taste”: knowing which 90% of user requests to ignore and how to fit a new feature into the interface without ruining the experience.

The Death of Jira

Jira was built for a different era, one where humans created tickets, updated statuses, and groomed backlogs by hand. For a team of 2-5 Product Engineers running AI agents, that overhead slows you down.

A Dev.to post titled “Why Developers Hate Jira” put it bluntly: “the tool that should serve development has become the master we all serve.” Its “flexibility” produces workflow sprawl: a maze of tickets, sub-tasks, and statuses that serve the dashboard, not the person building.

Teams are switching to Linear: opinionated, keyboard-first, fast. Linear enforces strict statuses (Backlog, Todo, In Progress, Done, Canceled) and limits customization on purpose. Small teams stop hesitating to log bugs because the tool stays out of the way.

A new class of AI-native workflow tools is replacing the old guard:

• Motion is an AI project manager that auto-schedules tasks, reprioritizes work as deadlines shift, and builds your team’s plan without anyone dragging cards across a board. It watches your calendar, your task list, and your priorities, then tells you what to work on next.
• Taskade turns unstructured input into structured work. Paste a Slack thread or meeting transcript and Taskade generates tasks, assigns owners, and tracks progress. It runs AI agents that can research, draft, and automate workflows inside the same workspace.
• Forecast answers the question Jira never could: “will we ship on time?” It tracks delivery risk, resource allocation, and budget burn so you get real numbers instead of gut-feel estimates.

What the Leaders Are Saying

Patrick Collison (CEO, Stripe): “If you’re just substitution-oriented, i.e., not improving the product, I think you will suffer at the hands of somebody who is using it to improve the product.” Collison says the future of programming moves away from syntax toward APIs, data models, and system design. In a Retool Summit 2025 fireside chat, Collison revealed that Stripe’s internal agent builder originated from their finance ops team, not an AI lab. During a recent fix-it week, AI “minions” autonomously resolved 30% of bugs. Five percent of all Stripe pull requests are now generated by AI agents.

Guillermo Rauch (CEO, Vercel): Rauch predicts AI and SaaS will enable one-person billion-dollar companies within five years. His guiding principle: “Software ages like milk, not wine,” meaning you ship fast and iterate, because code left sitting goes stale. Vercel drove 10% of new signups from ChatGPT citations in 2025, a 10x increase in six months. Tools like 21st.dev, a YC-backed platform for agent infrastructure and UI building blocks, are pushing this further by giving PEs pre-built components for the agentic internet: SDKs, agent templates, and pre-built UI components that work with Claude and OpenAI out of the box.

The a16z ecosystem is funding this transition, backing platforms like Decagon and HUD (which evaluates frontier AI agents). The consensus across Heavybit and a16z: as LLMs generate code, the skill that matters is “Context Engineering”: giving AI agents the right codebase context, the right docs, and the right constraints so they build what you mean, not what they guess.

How to Spot a Product Engineer

If you’re hiring for PEs, stop running algorithmic whiteboard interviews. The traits that matter show up in behavior, not in LeetCode scores.

Ask about outcomes, not tech stacks. When a candidate describes past work, listen for the frame. A traditional engineer talks about the architecture and the frameworks. A PE talks about the user problem, the business context, and what happened after launch. A former Meta engineer noted on ProductEng.dev that shipping ten flawless features in six months earned a poor performance review because none of them moved business metrics.

Give them an ambiguous prompt. Present a vague request from a non-technical stakeholder: “We need to add a chatbot to the pricing page.” A traditional engineer asks about API integrations. A PE asks: “What problem are we solving for the customer? What data do we have? What’s the cheapest way to validate this?”

Check for analytics literacy. Ask how they measured success on their last shipped feature. A PE cites specific product metrics: “We tracked cohort retention in Amplitude and saw a 15% lift.” A traditional engineer cites uptime or latency.

Look for customer obsession. PEs rotate through support queues, read raw feedback, and join user interviews. Sonya Park, a PE at Mixpanel, reviews customer feedback and product data every morning before touching code.

How to Become a Product Engineer

The path depends on where you’re starting.

If You’re an Engineer

You already have the technical foundation. The gap is product sense and customer context.

• Stop measuring success by tickets closed. Track the business metrics your features affect. Get access to Mixpanel, Amplitude, or PostHog and build a dashboard for your shipped features.
• Get in front of users. Ask to join user interviews as a silent listener. Spend one hour a week reading raw support tickets. AI can summarize them, but it can’t feel a user’s frustration. That friction changes the engineering decisions you make.
• Learn the Double Diamond. Engineers skip straight to building. The Double Diamond makes you research the problem first, narrow it down, then prototype and test. It keeps you from building the wrong thing fast.
• Negotiate scope. When you get a complex spec, find the 20% of engineering effort that delivers 80% of user value. Propose a simplified version that ships in days, not weeks.
• Split your time. Divide your calendar into “Coding Time” and “Product Time.” Start each day with analytics or feedback before entering deep-focus coding.

If You’re a PM

The gap is hands-on building. PMs who can prototype with AI tools have an advantage, but production-grade engineering requires depth.

• Build something real. As Aakash Gupta noted, companies hiring AI PMs say: “We don’t hire people who talk about AI. We hire people who build with AI.” Use Cursor or Lovable to ship an MVP.
• Learn how AI breaks. You don’t need to write production algorithms. But you do need to know what a context window is, why your agent hallucinates when the prompt gets too long, and what happens when latency spikes under load. When your AI feature gives a wrong answer, you need to know where to look.
• Design for AI failure. AI will be wrong. Add an undo button. Show a “the AI did this, here’s what it changed” summary so users can verify. When the AI can’t handle something, your app should still work without it.
• Stop treating deployment as a handoff. If you build a feature, you are responsible for its survival in the wild. If user engagement drops or the feature breaks at 2 a.m., you don’t wait for someone to write a bug ticket. You investigate the analytics, find the flaw, and deploy the fix yourself. If that sounds uncomfortable, you’re still operating as a PM who hands work to someone else.

---

Sources: The Pragmatic Engineer, Lenny’s Newsletter on Linear, Web Strategist, Stripe Benchmarking, Retool Summit / Collison Interview, Microsoft Q2 FY2026 Earnings, McKinsey/Commando Units on Dev.to, Shotgun Case Study, and ProductEng.dev. Full research report with 41 citations available in the repository.