Your Company Has 10x More Developers Than You Think

Key Points:

• Non-technical employees are shipping production software today. Nurses, recruiters, finance analysts, educators -- people who have never written a line of code are building and deploying real applications using AI tools like Lovable, Replit, and Bolt.new. This is already happening inside your company.
• This is not low-code 2.0. Low-code promised "citizen developers" for 15 years and largely failed. AI-powered building succeeds where low-code didn't -- because the interface is natural language, the output is real portable code, and the ceiling rises with every model generation.
• The opportunity is real, but so are the risks. AI-generated code has 1.7x more major issues and 2.74x more security vulnerabilities than human-written code. CTOs who ignore this will face a shadow IT crisis. CTOs who ban it will lose the innovation. The answer is governed builder environments.

A Nurse, a Recruiter, and an Educator Walk Into a Codebase

A nurse at a healthcare organization built a patient journey tracking application using Lovable. It's now bundled with every invoice the company sends. She has never written a line of code.

An educator built 50+ custom learning tools for students with intellectual disabilities using Bolt.new. These aren't prototypes -- they're in daily use.

A former CEO with zero engineering team built two startups from scratch using AI coding tools. No developers. No CTO. No engineering hires.

As an engineer, my first instinct is to reject all of this. It sounds wrong. People who have never debugged a null pointer exception, who don't know what a database migration is, who have never dealt with a race condition -- they're "shipping production software"? The engineer in me wants to put that phrase in the heaviest air quotes possible.

But here's the thing: the data doesn't care about my instincts. And there's a lot of data.

The Numbers That Prove This Isn't a Trend Piece

Lovable went from $0 to $100 million in annual recurring revenue in eight months. That's the fastest growth of any European startup in history. They process 100,000+ new projects per day. Their users -- explicitly -- are not engineers. They're product managers, marketers, ops teams, founders. Lovable's stated mission is to "empower the 99%" of people who have ideas but lack the technical skills to build them.

Replit has 50 million users. According to CEO Amjad Masad, 75% of them never write a single line of code. It's used across 85% of the Fortune 500. Those users aren't all engineers -- they're "product managers, operators, founders, students, and small business owners."

Bolt.new ran a hackathon with 130,000 participants. The Cursor IDE hit $2 billion in annual recurring revenue, doubling every three months. GitHub Copilot has 26 million users. OpenAI's Codex has 1.5 million weekly active users.

25% of startups in Y Combinator's Winter 2025 batch had codebases that were 95% AI-generated. YC CEO Garry Tan said it plainly: "This isn't a fad. This isn't going away. This is the dominant way to code."

And this isn't limited to startups. The Deloitte 2026 Gen Z and Millennial Survey -- 22,500 respondents across 44 countries -- found that 74% of Gen Zs and 74% of millennials already use AI in their day-to-day work. Gartner predicts that by 2027, 75% of employees will acquire, modify, or create technology outside IT's visibility -- up from 41% in 2022.

Let me say that again: three out of four of your employees will be building technology your IT team can't see. Within eighteen months.

What This Looks Like Inside Your Organization

When I first heard these stories, my reaction was: "That's a demo, not production software." But then I looked at what's actually running inside companies right now. Not prototypes. Not hackathon projects. Software that replaced paid SaaS contracts and runs every day.

Here's what's happening, department by department.

Sales. At Atonom, the Head of Finance and Legal -- not an engineer -- built a fully functional CRM in three hours using Lovable. The sales team stopped logging into Salesforce. Annual cost went from $40,000 (Salesforce for 25-30 people) to roughly $1,200 including hosting. He then built pipeline dashboards, lead tracking, and ARR forecasting on top of it.

Marketing. When eXp Realty's vendor went on vacation right before a country launch event, their VP of International Marketing -- not an engineer -- built the entire Peru country website in six hours using Lovable. That became the template for replatforming 26 country websites. Support tickets from agents dropped 85%. At AppDirect, the marketing team used Lovable to rebuild a website project that would have cost $80,000 from an external agency and taken six months. They did it in less than one month. Two projects alone are projected to save $120,000 in their first year.

HR and Recruiting. A recruiter with 10 years at Google, Unity, and Rivian built a full AI-powered hiring platform -- resume builder, job matching, automated outreach, interview prep -- in days. A feature estimated at six months of engineering time was built in four days. An NHS pharmacist built 20+ healthcare apps, sparking hackathons and a wave of clinical innovation across the organization. Neither of these people had "developer" in their title.

Finance. Microsoft's own finance organization saw a 60% reduction in case resolution time for cash collections using AI. Back at Atonom, the same finance lead who built the CRM moved on to build executive board dashboards and contract-based revenue models. Quote: "I took our executive board dashboard and just said, build a dashboard like this. End of month, it just automatically updates."

Product Management. Delivery Hero uses AI builders to greenlight features 66% faster. Replit published an entire series on product managers building working prototypes in the same session as their behavioral brief -- replacing a 2-4 week design-engineering round-trip with something that happens in hours. PMs aren't waiting for sprint capacity anymore. They're validating ideas themselves.

Legal. Microsoft's legal team responds to legal issues 32% faster with AI. 87% of legal staff reported enhanced productivity. They projected a 5% decrease in external spend for regulatory work and built an agent for pro bono services that drove a roughly 9x increase in impact.

The engineer in me wants to audit every one of these projects. But the pattern is undeniable. At eXp Realty, non-technical builders are replacing millions in annual SaaS spend. The company's Chief Innovation Officer said it bluntly: "Every SaaS is on the chopping block." At AppDirect, 80+ internal applications have been built by people across every department -- Sales, Finance, HR, Operations, Marketing -- with over 200,000 lines of code written by non-engineers this year alone.

This isn't happening at the margins. It's happening across the entire org chart.

"We've Heard This Before" -- And We Were Right to Be Skeptical

If you're a CTO over 35, you've been through this cycle before. Forrester coined the term "low-code" in 2014. Gartner predicted that 70% of applications would be built with low-code or no-code technologies by 2025. The promise was "citizen developers" -- business users building enterprise applications without engineering.

The vendors were real. Mendix (acquired by Siemens for $730 million), OutSystems, Appian, Microsoft Power Apps, Bubble. The market grew to roughly $44 billion. Gartner, Forrester, and every analyst firm published reports with hockey-stick projections.

And then reality hit.

The ceiling was too low. Low-code was fine for simple forms and basic workflows. But the moment you needed anything beyond CRUD -- complex integrations, custom business logic, real-time data flows -- you hit a wall. Jon Collins, VP of Research at GigaOm, summarized it well: "Low-code can only do so much to hide the complexity beneath. Sooner or later you're going to need the deeper engineering skills."

The lock-in was brutal. Low-code platforms produced proprietary visual models, not standard code. Build an app on Mendix, and you can't move it to OutSystems. You can't move it anywhere. You're locked to the vendor's runtime, hosting, and ecosystem -- forever.

The "citizen developer" never really showed up. When NatWest Group tried to use low-code (Appian), they put three developers through three months of training, followed by three months of guided building. They still hadn't achieved the goal of moving development "out of the tech space" to non-tech people. Six months of investment, and the citizen developer promise remained unfulfilled.

So if you're skeptical when someone says "everyone is a developer now" -- you should be. I was. We've been burned before. I watched the low-code wave with the same enthusiasm everyone else had, and then watched the reality set in.

The question is whether this time is actually different.

Three Reasons This Time Is Different

I resisted this conclusion for months. But after looking at the data, talking to people building with these tools, and watching what's happening inside companies -- including the ones we work with at Qovery -- I'm convinced the structural dynamics have changed. Here's why.

1. The interface changed from "learn our tool" to "describe your problem"

Low-code replaced code with drag-and-drop visual builders. That was better than writing Java, sure. But it was still a skill you had to learn. Every platform had its own paradigm, its own quirks, its own learning curve. The NatWest example -- six months of training -- wasn't an outlier. It was the norm.

AI builders replaced all of that with natural language. You describe what you want. The AI builds it. Andrej Karpathy, the former head of AI at Tesla and co-founder of OpenAI, said it in 2023: "The hottest new programming language is English."

This isn't an incremental improvement. It's a categorical change in the interface between human intent and software creation.

2. The output changed from proprietary blobs to real, portable code

This is the structural difference that CTOs should pay the most attention to.

Low-code output was locked to the vendor. Leave Mendix, and you rebuild from scratch. Leave Appian, same thing. The applications you built weren't really yours -- they were the vendor's, running on the vendor's runtime.

AI tools generate standard source code. React. Python. Node.js. TypeScript. You can export it to GitHub, deploy it anywhere, and hire any developer to maintain it. The switching cost is near zero.

For a CTO evaluating risk, this changes the calculus entirely. The "what if this doesn't work out" scenario with low-code was catastrophic -- total rebuild. With AI-generated code, you have a standard codebase you can work with regardless of what happens to the tool that generated it.

3. The ceiling keeps rising -- every quarter

Low-code hit a ceiling and stayed there. Complex apps were simply impossible, and no amount of platform updates changed that. The ceiling was architectural, not incremental.

AI models improve with every generation. What failed six months ago works today. What's mediocre today will be good in six months. Sequoia Capital called this "a massive opportunity to transform software engineering -- a matter of who, not if."

Andrew Ng, the Stanford AI professor and founder of AI Fund, put it concretely: at his company, "everyone knows how to code, including the chief financial officer, the general counsel, and even the receptionist." Not to become software engineers -- but to tell a computer what they want it to do.

Here's the comparison that made me change my mind:

The Engineer in Me Isn't Wrong -- The Problems Are Real

I've laid out the case for why this is real. Now let me lay out the case for why it's dangerous. Because both things are true at the same time, and any CTO who ignores either side will make bad decisions.

Experienced developers are slower with AI tools. A randomized controlled trial by METR in July 2025 studied experienced open-source developers working on familiar codebases. The result: developers using AI tools were 19% slower than without them. The twist: they predicted they'd be 24% faster, and afterward believed they had been 20% faster. The perception-reality gap is the most concerning part.

AI-generated code has more defects. CodeRabbit's analysis of 470 open-source pull requests (December 2025) found that AI co-authored code contained 1.7x more "major" issues compared to human-written code. Security vulnerabilities were 2.74x higher.

Technical debt is accumulating faster than ever. GitClear analyzed 211 million lines of code changes from 2020 to 2024. Code refactoring dropped from 25% of all changes to under 10%. Code duplication increased roughly 4x. Copy-pasted code exceeded moved code for the first time in two decades.

Real incidents have already happened. 170 Lovable-created web apps were found with security vulnerabilities exposing personal information. Replit's AI agent deleted a production database despite explicit instructions not to make changes -- then fabricated data to cover it up. Fast Company reported senior engineers describing "development hell" when maintaining AI-generated codebases.

These are not edge cases. These are the predictable consequences of putting powerful creation tools in the hands of people who don't have the engineering instincts to see what can go wrong. My engineering brain sees these problems immediately. Security, maintainability, architectural coherence -- the things we've spent careers learning to get right.

But here's what I've learned: the answer to "people are building without governance" has never been "stop people from building."

The Governance Gap Is Where This Gets Existential

The problem isn't that people are building. The problem is that they're building in the dark.

Gartner reports that shadow IT spending already accounts for 30-40% of total IT spending in large enterprises. IBM's Cost of a Data Breach Report found that data breaches involving shadow IT cost organizations an average of $4.88 million -- 16% above the global average.

Microsoft's 2026 Work Trend Index surveyed 20,000 workers using AI across 10 countries. The findings are sobering:

• Only 26% of AI users say their leadership is clearly and consistently aligned on AI strategy.
• Only 19% work in organizations where readiness matches individual capability.
• 45% say it feels safer to focus on current goals than to redesign work with AI -- even though 65% fear falling behind if they don't adapt.

The pattern is consistent: individuals are outrunning their organizations. Employees adopt AI tools faster than companies create policies for them. Capabilities expand faster than governance frameworks. And the security review process -- already a bottleneck when only engineers produced code -- can't possibly scale to review code from every department.

A CTO I spoke with at a Series B fintech company said it best: "Our people are already building on these platforms. We can't stop them. But we need to take back control before it costs us a certification."

What Smart CTOs Are Doing

I was skeptical of the "everyone is a builder" thesis for a long time. I'm an engineer. I spent 15+ years building infrastructure. The idea that someone who doesn't understand TCP/IP could "ship production software" felt like a category error.

I was wrong about the trend. I was right about the risk. The CTOs who are navigating this well are doing three things:

1. Accept the reality -- then audit it

Your employees are already building with AI tools. The question isn't whether it's happening. It's how much you can't see. Gartner says you're blind to 60%+ of the technology your employees are creating. Start by understanding what's already out there.

Andrew Ng said it directly: "It's been interesting to see how many companies -- CIOs and CTOs -- still have policies that don't let engineers use AI-assisted coding. We have to get past that."

2. Create governed builder paths -- and make them faster than the workaround

The reason shadow IT wins is that it's easier than the official process. A finance analyst can build a tool on Lovable in 20 minutes. Filing a ticket with engineering takes three weeks.

Smart platform teams are creating pre-configured builder environments: the right database connections, the right API credentials, the right network rules -- all set up and secured. Builders pick a template and start working. They never touch infrastructure. They never see credentials. But everything runs on infrastructure you control, with full audit trails, SSO, and environment isolation.

The sanctioned path has to be faster and easier than the shadow path. If it isn't, people will keep going around you.

3. Redefine what "developer" means in your organization

The org chart of software creation just changed. The CTO's job is no longer "who can write the code." It's:

• Quality governance: What standards must AI-generated code meet before deployment? What automated checks are non-negotiable?
• Architecture decisions: What can safely be AI-generated by non-engineers? What requires deep expertise? Where's the line?
• Risk management: How do you balance speed-to-market against security and maintainability? How do you handle the technical debt that AI-generated code inevitably creates?
• Talent strategy: You still need expert engineers -- more than ever -- for the systems that can't tolerate the error rates of AI-generated code. But you also need to train and enable the new class of builders.

This is the most interesting strategic question in enterprise technology right now. And it's a CTO problem, not an IT problem.

The Bottom Line

The "everyone is a builder" shift is real. Not because of hype, not because of VC narratives, and not because the marketing teams at Lovable and Replit say so. It's real because the interface (natural language), the output (real, portable code), and the trajectory (exponentially improving models) are fundamentally different from everything that came before.

I resisted it. The engineer in me still flinches when I hear "a nurse built a production app." But the data is overwhelming, and the structural dynamics are clear. This isn't low-code 2.0. It's something new.

The question for CTOs isn't whether their employees will build software. They already are. The question is whether they build it on infrastructure you control, with governance you defined, within boundaries you set -- or on someone else's platform, with your data, and no audit trail.

I was right to be skeptical about low-code. The question I had to ask myself -- and that every CTO should ask themselves -- is whether that same skepticism is blinding them to something structurally different.

In my case, it was.