Developer Experience AI: Designing DX for Agents and Humans
Developer experience AI agents demand new tooling, testing, and feedback loops. Learn how product engineers design DX when agents are part of the team.
Aug 22 · 18 min readEngineering leadership AI requires new skills. How EMs and directors should adapt to manage agent-augmented product engineering teams effectively.
Felipe BarreirosSr. Product Engineer @ AWS
Leading a tech product at AWS with 35 engineers impacting 6.1M customers across 16 languages. 2x founder with exits (acquired by NASDAQ:XP). Coached 12,000 tech graduates. TEDx Speaker. Global Shaper by World Economic Forum. Building product.engineer because 2026 is the year engineers own the full product cycle.
Developer experience AI agents demand new tooling, testing, and feedback loops. Learn how product engineers design DX when agents are part of the team.
Aug 22 · 18 min readAI agent maturity spans four levels from copy-paste to autonomous. Learn how product engineers maintain quality at each stage.
Aug 21 · 19 min readWhat an AI-native company actually looks like in 2026. 5-person teams doing what 50 did, built from day one with agents as first-class teammates.
Aug 20 · 18 min readYour best engineer just shipped three features in a week. Two of them were wrong.
That sentence captures the central tension of engineering leadership AI in 2026. Your teams are faster than ever. Agent-assisted workflows compress cycle times from weeks to days. But speed without direction is just chaos with better tooling. The role of the engineering manager has not disappeared. It has fundamentally shifted.
product.engineer defines engineering leadership AI as the discipline of managing teams where human engineers collaborate with AI agents to discover, build, and ship product in what many now call agentic engineering. It requires a new set of skills: curating agent output instead of reviewing all code manually, measuring throughput differently, restructuring team topologies around human-AI pairs, and rethinking what "done" means when an agent can produce a working prototype in two hours. This is not about replacing managers. It is about replacing old management patterns that assume humans are the only ones producing code.
If you have followed the broader movement toward product engineering, you already understand that engineers who own outcomes (not just outputs) deliver better results. Now layer AI agents on top. The product engineer who understands user problems, wields AI tools effectively, and ships measured experiments becomes exponentially more productive. The question for leaders is: how do you build, support, and scale teams of these people?
The playbook that worked from 2015 to 2023 assumed a few things. Engineers write all the code. Code review catches bugs. Sprint velocity measures productivity. One-on-ones focus on blockers and career growth. Stand-ups surface dependencies. These are all reasonable assumptions when humans are the sole producers of software.
They are falling apart now.
Join 2,000+ engineers who define, build, and ship.
One email per week. Practical frameworks for product engineers. No spam.
Engineering leaders at companies that adopted AI coding agents early report a consistent pattern: teams see large increases in lines of code committed per sprint, but only modest increases in features shipped to production that actually move target metrics. The gap between output and outcome widened, not narrowed. More code did not mean more value.
This mirrors what DX (formerly known as DevEx) reported in their 2025 Developer Productivity study across 450 engineering organizations. Teams that adopted AI coding assistants without changing their management practices saw a temporary productivity spike followed by a regression. Within six months, those teams reported higher defect rates, more time spent on code review, and lower developer satisfaction. The tool was not the problem. The operating model was.
Engineering managers consistently report feeling less confident about their teams' code quality after adopting AI pair programming tools. Not because the tools are bad, but because the volume of output exceeds their capacity to evaluate it. Traditional code review processes become bottlenecks. Managers who previously reviewed 15 to 20 PRs per week are now facing 50 or more.
The old model of engineering management assumed scarcity. Scarce engineering time. Scarce code output. Scarce shipping capacity. AI agents eliminated the scarcity of production but created a new scarcity: judgment about what to produce and whether it is any good.
The traditional EM acts as a quality gate. They review designs, approve architectures, sign off on code reviews. They are the checkpoint between development and production.
In agent-augmented teams, this breaks. The volume of output makes gatekeeping impossible. An engineering manager who insists on reviewing every AI-assisted PR will become the bottleneck that negates the speed gains.
The new role is curator. You establish quality frameworks, not quality checks. You define what "good" looks like through automated tests, product metrics thresholds, and design principles, then let the human-AI pair execute against those standards. Your job shifts from approving individual outputs to tuning the system that produces them.
Linear does this well. Their engineering team operates with high autonomy per individual, but strong shared standards encoded in tooling. Linting, type checking, automated visual regression tests, and performance budgets act as the quality layer. The humans (and their AI assistants) move fast because the guardrails are structural, not managerial.
Story points, tickets closed, PRs merged, lines written. These metrics already had problems. With AI agents in the loop, they become actively misleading.
A product engineer using Cursor or Claude Code can produce a working feature branch in two hours. Does that mean they did two hours of work? Or did they do eight hours of thinking, problem framing, user research, and experiment design, then use the AI to compress the implementation phase? The latter is dramatically more valuable, but looks the same (or worse) on a velocity dashboard.
The leadership shift: stop measuring production metrics. Start measuring outcome metrics exclusively.
| Old Metric | New Metric |
|---|---|
| Story points per sprint | User outcomes delivered per sprint |
| PRs merged per engineer | Experiments run and concluded per engineer |
| Tickets closed | Problems solved (validated with data) |
| Lines of code | Reduction in customer-reported issues |
| Sprint velocity | Time from problem identification to validated solution |
This is not a theoretical nicety. At Vercel, engineering teams measure themselves on deployment success rates, time-to-first-byte improvements, and developer satisfaction scores for their platform, not on how many commits they push. The product engineer who ships one carefully measured experiment that moves a core metric by 3% is more valuable than the one who ships fifteen features nobody evaluates.
The standard model: you need X engineers for Y work. More work means more engineers. Headcount is the lever.
AI agents change the math. One product engineer with strong AI fluency can produce output that previously required two to three engineers. But they still need the same amount of user research, product thinking, and strategic direction. The constraint shifts from coding capacity to judgment capacity.
This means team composition matters more than team size. The product engineering manager of 2026 should optimize for:
Shopify restructured their engineering organization in early 2026 around what they call "pods of one." A single senior product engineer owns an entire problem space, uses AI agents for implementation, and partners directly with a designer and a data analyst. No PM layer in between. No sprint planning for a team of six. Just one person with tools, judgment, and direct access to users.
Junior engineers used to need mentorship on writing clean code, understanding design patterns, navigating complex architectures. AI agents now handle much of that. A junior engineer using Claude Code gets real-time guidance on implementation that is often better than what a busy senior would provide in code review.
The mentorship gap is no longer technical. It is judgment.
How do you decide what to build? How do you know when to stop iterating? How do you interpret ambiguous user feedback? How do you distinguish a problem worth solving from a problem that is merely interesting? How do you kill a project that is technically beautiful but commercially irrelevant?
These questions require experience, taste, and pattern recognition that AI agents cannot provide. Engineering leaders in 2026 must refocus mentorship programs on:
This is the core of what makes a product engineer effective. The technical skills are table stakes. The judgment skills are the multiplier.
Stand-ups, sprint planning, retros, grooming sessions. The ceremony of agile was designed for a world where coordination costs were high and information asymmetry was the enemy.
AI-augmented teams coordinate differently. Many of the information-sharing functions of meetings can be handled asynchronously through AI-generated summaries, automated status updates, and intelligent notification routing. The coordination overhead drops.
According to product.engineer's framework for leadership, what leaders need to design instead is the environment for high-quality decision making. That means:
Notion's engineering leadership talks about "decision velocity" rather than "development velocity." Their goal is not faster code. It is faster, better decisions about what code to write. Their EMs spend more time in customer conversations and data reviews than in code reviews.
Based on conversations with engineering leaders at Figma, Stripe, OpenAI, and a dozen other companies shipping AI-native products, here is the competency model emerging for the AI-era engineering leader:
Strategic judgment (40% of time)
System design for humans plus AI (25% of time)
People development (25% of time)
Technical oversight (10% of time)
Notice the inversion. Traditional EMs spent 40% or more of their time on technical oversight (code reviews, architecture discussions, technical mentorship). In the AI-augmented model, that drops to 10%. The freed-up time goes into strategic judgment and system design, the two areas where AI agents cannot replace human leadership.
I have seen this play out firsthand. As someone who has hired over 600 engineers and coached more than 12,000 across various roles, the pattern is unmistakable. Teams that adopt AI tools without adapting their leadership model hit predictable failure modes.
The review bottleneck. Managers insist on reviewing all AI-assisted output at the same granularity they reviewed human-only output. PRs pile up. Engineers get frustrated. The speed gains from AI tools get eaten by process overhead.
The metrics mirage. Leaders see velocity numbers spike and report success to their executives. But user outcomes have not changed. Three months later, stakeholders ask why customers are not happier despite all the "productivity gains."
The mentorship vacuum. Junior engineers become very productive at generating code but never develop product judgment. They ship fast but ship the wrong things. Nobody catches this because the output volume is impressive.
The trust collapse. Engineers lose confidence in their own code because they do not fully understand the AI-generated portions. Quality suffers. Incident rates climb. The team starts adding more process, which slows everything down, which defeats the purpose of AI assistance.
In my experience as a Senior Product Engineer at AWS, the teams that thrive with AI tools are the ones where leadership actively redesigns the operating model. They do not just hand out Copilot licenses and declare victory. They rethink what the team is optimizing for, how quality is maintained, and what role the manager plays in a world of abundant output.
Here is a framework I use when advising engineering leaders making this transition:
C - Curate, do not gate. Replace approval checkpoints with quality frameworks. Define standards in code (tests, linting, performance budgets) rather than in review comments.
L - Lead with outcomes. Every project starts with a measurable user outcome. Not a feature spec. Not a ticket. A hypothesis about what will change for users and how you will measure it.
E - Enable fast feedback. Shorten the loop between shipping and learning. If it takes two weeks to know whether a feature worked, your AI-accelerated development speed is wasted on building the wrong things faster.
A - Allocate for discovery. Since implementation is faster, reallocate saved time to problem discovery. The ratio of research-to-build should shift significantly toward research.
R - Redefine growth. Career progression for product engineers in AI-augmented teams should reward judgment, user empathy, and outcome delivery, not code volume or architectural complexity for its own sake.
Days 1 to 30: Observe and measure
Days 31 to 60: Redesign
Days 61 to 90: Scale
Everything in this article points toward one conclusion: the product engineer is becoming the atomic unit of software delivery in AI-augmented organizations.
Not the team. Not the squad. Not the pod. The individual product engineer who combines user empathy, technical skill, AI fluency, and product judgment into a single high-impact role.
This does not mean teams disappear. It means the team's function changes. Instead of pooling coding capacity to produce more output, teams pool judgment capacity to make better decisions. The leader's job is building an environment where individual product engineers can exercise excellent judgment, rapidly validate ideas, and learn from outcomes.
The organizations getting this right, PostHog with their small autonomous teams, Vercel with their focus on developer experience metrics, Stripe with their outcome-driven engineering culture, are building what I call the post-engineer engineering org. They share a common thread. Their leaders understood that AI tools changed the bottleneck. The constraint is no longer "can we build this?" It is "should we build this, and how will we know if it worked?"
That question has always been the domain of great engineering leadership. AI did not make the question obsolete. It made the question louder.
Here is what nobody wants to say publicly. If one product engineer with AI tools can do the implementation work of three engineers, then teams will get smaller. This is already happening. Klarna reported in early 2026 that they reduced their engineering workforce by 25% while increasing product output. Shopify's CEO stated that teams should demonstrate why work cannot be done by AI before requesting additional headcount.
For engineering leaders, this creates a tension. Your influence traditionally correlates with team size. Fewer direct reports means less organizational power in most corporate structures.
The leaders who will thrive are the ones who redefine their value proposition. Your value is not "I manage X people." It is "my team delivers Y outcomes for the business." If you can deliver more outcomes with a smaller, more senior, AI-augmented team, that is the correct structure. Fighting it to preserve headcount serves nobody.
This also means the bar for who you hire goes up. The product engineer you hire in 2026 needs stronger product sense, better judgment, higher AI fluency, and more autonomy than the generalist software engineer you hired in 2022. The job description changes. The interview process changes. The onboarding changes. Everything changes.
Based on what is working at companies actively navigating this transition, three leadership archetypes are emerging:
The Coach. Spends 60% or more of time in one-on-ones and problem-framing sessions. Rarely reviews code directly. Instead, reviews outcomes weekly and coaches engineers on improving their judgment. Common at PostHog and Linear-style small teams.
The Architect. Focuses on designing the system, not the software system, but the human system. Defines team structure, workflow design, tool selection, and quality frameworks. Then steps back and lets the team operate. Common at infrastructure-heavy companies like Vercel and Cloudflare.
The Explorer. Acts as the team's chief scout. Spends significant time in customer conversations, competitive analysis, and opportunity identification, then brings synthesized problems back to the team. The product engineer benefits from having a leader who surfaces the highest-value problems. Common at product-led growth companies like Figma and Notion.
All three work. None of them look like the traditional EM who splits time between code reviews, sprint ceremonies, and stakeholder updates.
Traditional engineering management focuses on coordinating human effort, tracking velocity, reviewing code, and removing blockers. Engineering leadership AI shifts the emphasis to curating AI-augmented output, measuring user outcomes instead of production metrics, mentoring judgment rather than technical skills, and designing quality frameworks that scale with increased output volume. The leader moves from gatekeeper to environment designer.
No. AI agents replace production capacity, not decision-making capacity. The need for human judgment about what to build, whether it worked, and what to do next has actually increased. What changes is the percentage of time leaders spend on different activities. Less time on technical oversight and process enforcement, more time on strategic judgment and people development.
Evaluate on outcomes, not output. A product engineer who ships one feature that moves a core metric by 5% is more valuable than one who ships ten features with no measurable impact. Track experiments run, hypotheses validated, user problems solved, and metric movements. Ignore lines of code, PRs merged, and story points as primary indicators.
There is no universal answer, but the trend is toward smaller, more senior teams. Many high-performing companies are moving toward three to five senior product engineers per problem area, down from eight to twelve generalist engineers. The key is matching team size to judgment capacity needed, not coding capacity needed.
Build quality into the system rather than into the review process. Invest in comprehensive automated testing, type safety, performance monitoring, and feature flags for gradual rollouts. Establish clear "definition of done" criteria that include passing automated checks, not just human approval. Reserve human review for architectural decisions and product direction, not line-by-line code inspection.