Should we fire our engineers and have everyone vibe-code products? Probably not.
The bottleneck has moved from the hands to the head
The "barrier to build" has collapsed. With the rise of agentic software development and "vibe coding," leaders are facing a critical human capital question: If AI can write code, why shouldn't everyone in the company—from Sales to Marketing—build our products? And beyond that, why do I need engineers?
Today, we're going to explore this choice by talking through two tricky questions.
- Today (early 2026), do we need software expertise to make software?
- And even if we don't, is the right idea for everyone to develop software?
Today (early 2026), do we need software expertise to make software?
There is a growing narrative that software expertise is becoming a "legacy skill." Some developers at AI-native companies claim to work purely through LLMs.
On the flip side, many developers share the opposite: real difficulty in fully automating software development. I spoke to a developer just last night who was expressing extreme frustration with their organization's mandate that they achieve 100% code written by AI. So how should we square this circle?
Vibe coding provides significant productivity gains
Data from a year-long study of 300 engineers using the DeputyDev platform shows that AI is a massive "force multiplier," but it benefits different levels of expertise in non-linear ways1:
Moreover, code volume increased by 61% for top adopters, and productivity gains were clear as PR review cycle times dropped by 31.8%.
This is consistent with our own findings on how working through AI for ALL knowledge work deliverables (not just coding) can create significant productivity gains.
Code expertise is still needed
Today, when AI successfully generates code, it often introduces code smells—structural defects that compromise long-term maintainability.
An empirical study of 387 agentic Pull Requests (PRs) found that AI agents introduced 364 distinct maintainability and security smells2.
For example, AI agents were found to hardcode credentials and insecure URLs in build scripts, relying on outdated dependency patterns that humans often overlooked in the rush to ship.
Another study analyzed 211 million lines of code authored between 2020 and 2024. The central finding is that while AI assistants (like GitHub Copilot) have significantly increased the volume of code being written, they are simultaneously causing a measurable erosion in code quality and maintainability3:
We are building faster, but we are also generating "system rot". Without software expertise at the Reviewer level (using the FORCE role framework), you aren't building a product; you're building a liability.
AI needs humans in the middle
Recent research into real-world, economically valuable work reveals a massive gap between "coding a snippet" and "delivering a product." In the Remote Labor Index (RLI) study, which tested frontier agents (including GPT-5 and Manus) against 240 professional freelance projects, the results were interesting, to say the least.
The highest-performing agent achieved an automation rate of only 2.5%4.
So we still need humans in the middle. We suggest you don't fire all your software engineers just yet.
What is the human in the middle doing? Engineers as architects, strategists, and leaders.
First, it is important to acknowledge that the core technologies and techniques are getting better every day. Engineers at OpenAI and Anthropic are already saying 100% of their code is AI written despite the challenges listed above. So how are they achieving this?
Reportedly, these organizations are tooling their entire workflows to allow them to trust LLM output. These engineers are designing strict architectural patterns, constraints, and rules. These rules are then reinforced with custom linters and tests (themselves built by their LLMs).
In other words, rather than focusing their time on execution, these engineers moved upstream to architectural work to achieve these high levels of performance. So it isn't that the engineer isn't needed. It's more that they are needed for higher-end work.
But what if...
But let's say you really want to lean forward and still open up product engineering to all your colleagues. Is this still a good idea?
Even if we assume AI will eventually reach the ability to code production products without any engineering skill needed at all (even the architectural skills described above) , the Theory of Constraints suggests that turning your Sales team into a "mini-engineering org" is a strategic error.
The Theory of Constraints says that in any system, there is a bottleneck. If you improve a non-bottleneck, you gain nothing.
For many organizations, it felt that software engineering was the bottleneck. But was it? And even if it was, won't the engineers alone open up that bottleneck? Before you make these fundamental choices about headcount and roles, you should seek to understand where your bottleneck is:
Bottleneck risk 1: Good ideas
When it is easy to build software (and even hardware) products using AI, you have to ask yourself are you building good ideas - meaning ones that can create significant impact in their respective markets.
If you're reading this article, you're probably NOT a tech company with a massive locked-in audience like Google, Apple, and Microsoft, where piling on features can be useful in and of itself.
Your company is out in the fields. You fight for your meals and put your back into your living.
In these companies, you need to spend to enter markets and get attention, so you need good ideas.
Good ideas are hard. A really good idea is aiming for:
- A large total addressable market (TAM)
- Potential for tight product market fit (PMF)
- Structural moats
- Non-linear growth characteristics
- Product-led growth characteristics
Developing these ideas, especially in incumbent, large companies, is hard.
More software won't alleviate this bottleneck.
Bottleneck risk 2: Distribution
It is often said that first-time founders obsess about product while second-time founders obsess about distribution.
The reason why is that even with great products, you're not necessarily going to get traction.
I'm seeing this right now in many companies that we're working with on performance transformations. They have built a lot of products and features with low levels of adoption. Being faster at creating products isn't going to help, because the bottleneck has moved downstream.
When software construction becomes a commodity, the new scarcity becomes Market Attention.
If your Sales and Marketing teams spend their day "vibe coding" internal micro-apps, they are ignoring the only thing AI cannot do for you: owning the customer relationship.
More software won't alleviate this bottleneck.
Bottleneck risk 3: Change management
Even if you manage to get product in the hands of your consumers, there's considerable change management risk that limits renewals and retention.
That change management risk manifests as low levels of actual usage. For example, in reality the average person barely uses the features their computers and phones already offer. In your company, I suspect many people have access to Excel or Google Sheets - extremely powerful and versatile applications. Yet what proportion of these applications' features do you think your people are even aware of?
More software won't alleviate this bottleneck.
Conclusion: Avoid the complexity trap
I have personally experienced for myself the power of AI-native work. We've also learned how to create slop-free AI work product faster than ever before. My own personal productivity has at least tripled because of AI. And our own ask of engineers is to evolve to full agentic software development. So by no means are we bearish on AI's potential impact on human performance.
But does that mean that suddenly everyone is a software engineer, building production-ready products? Probably not.
Before you make drastic changes to your human capital makeup and start declaring that everyone should code, I suggest you first look closely at your strategy-to-execution flow and determine where the bottlenecks are.
Maybe you need more people understanding market gaps and customer needs. Maybe you need more people focusing on adoption. Maybe you need more people building customer relationships. Maybe you need more ideas. Or maybe you actually need more software development.
In our years of conversation with VCs and founders, the empirical evidence suggests that startups die because:
- ~40% → IDEAS: PMF never truly happened
- ~30% → DISTRIBUTION: Couldn't find a way to get to market
- ~20% → CHANGE MANAGEMENT: retention/monetization too weak
- ~10% → DEVELOPMENT SPEED OR DYSFUNCTION: product/velocity/team couldn’t execute
Having everyone vibe-code is the simple thing to do. But it may not be the right thing to do. In the agentic era, the winner isn't the company that builds the most code; it's the company that has the best ideas and the shortest path to the customer.
Further reading
- The problem with performance management - and how to fix it: Learn why endless meetings and split attention stifle high performance and how to fix feedback loops.
- Why Agile goes awry - and how to fix it: Discover why many Agile implementations hurt engineering motivation and how to focus on minimally viable experiments.
- Building high-performing teams with Health Checks: Empower teams to build high-performing cultures by measuring motivation and improving performance habits.
- Org structure might be causing your company's dysfunction: Understand the first principles for building a motivating, adaptive, and high-performing org structure.
- How company culture shapes employee motivation: A study of how culture determines performance by maximizing positive motives and minimizing negative ones.
About the authors
Lindsay McGregor
Meet Lindsay McGregor, the best-selling co-author of Primed to Perform, and co-founder of Factor.ai and Vega Factor. She's on a mission to build organizations that are AI Native & People First, because, let's be honest, who wouldn't want a world where every company thrives and everyone genuinely loves their career?
Lindsay is a hard-working nerd at heart. She holds an MBA from Harvard Business School and an undergraduate degree from Princeton University. A former McKinsey & Company consultant, she's also a New York City Library cardholder and a science fiction enthusiast.
Today, Lindsay isn't just talking about change; she's making the tools and doing the science needed to ensure everybody has great professional lives. It's safe to say, she's making work work better for everyone.
Neel Doshi
Meet Neel Doshi, the best-selling co-author of Primed to Perform, and co-founder of Factor.ai and Vega Factor. He's dedicated his career to a pretty ambitious goal: creating a future where all companies are high-performing because they're AI Native & People First. Think of it as making work so good, people actually look forward to Mondays.
Neel looks at this challenge through the eyes of an engineer. He earned his engineering degree from MIT and his MBA from the Wharton School. A former Partner at McKinsey & Company, he's also a Kentucky Colonel and a graduate of the Bronx High School of Science. Neel takes science-nerd to all new heights.
Currently, Neel is focused on showing the world that through science and AI, every team and company can be extremely motivating and high-performing. No one need be left behind in the march of progress.
Sources
1. ^Kumar et al. (2025). Intuition to Evidence: Measuring AI's True Impact on Developer Productivity. Longitudinal study of 300 engineers.
2. ^Ghammam & Almukhtar (2026). AI builds, We Analyze: An Empirical Study of AI-Generated Build Code Quality. University of Michigan.
3. ^Harding, William. AI Copilot Code Quality: Evaluating 2024's Increased Defect Rate via Code Quality Metrics. Alloy.dev Research, Feb. 2025.
4. ^Mazeika et al. (2025). Remote Labor Index: Measuring AI Automation of Remote Work. Center for AI Safety & Scale AI.
