A few years ago, having AI autocomplete a function felt like magic. Today, tools like GitHub Copilot, Cursor, and Claude are writing entire modules, test suites, and deployment configs — and some engineering teams report that AI now originates close to a third of their committed code. We have gone from “AI helps you write faster” to “AI writes whole features while you review.”
But here is the question nobody is asking out loud: what happens when that number is not 30% — but 100%? Not hypothetically. Not philosophically. Practically. What changes about your company, your team, your product, and your competitive moat when software essentially writes itself?
The answer is more complicated — and more exciting — than either the optimists or the alarmists want to admit.
I. Where We Actually Are: The 30% Reality
Before we speculate about 100%, we need to be precise about 30%. When people say AI writes 30% of code, they rarely define what that means — and the definition matters enormously.
GitHub’s internal data on Copilot suggests that a significant portion of accepted suggestions make it into production. But “accepted suggestions” range from a single variable name to a complete function. Measuring by lines of code is different from measuring by meaningful logic. A developer might write 10 lines of complex business logic and accept 100 lines of boilerplate from AI. Which authored more of the product?
What AI handles best today is consistent and telling:
- Boilerplate and scaffolding — CRUD operations, API wrappers, config files
- Unit tests — given a function signature, AI writes comprehensive tests reliably
- Documentation and comments — turning code into prose
- Refactoring — translating one pattern to another with known rules
Where AI still stumbles is equally revealing: multi-system architecture decisions, nuanced business logic with edge cases, security-critical code paths, and anything requiring deep contextual knowledge of a specific codebase built over years.
The 30% number is real, but it is the easy 30%. The remaining 70% — the part that actually differentiates one software product from another — is still deeply human.
2. The Path to 100%: What Would It Actually Require?
Getting from 30% to 100% is not a linear scaling problem. It requires solving a fundamentally different class of challenges.
The first is context. Today’s AI coding tools understand a file, maybe a folder. Production codebases span thousands of files with decades of accumulated decisions, workarounds, technical debt, and implicit knowledge. An AI that writes 100% of code needs to understand not just what the code does, but why it exists in its current form — the product decisions, the compliance requirements, the performance tradeoffs made three engineers ago.
The second is agentic capability. The most exciting development in AI coding is not better autocomplete — it is AI that can plan, write, run, observe failures, and iterate in a closed loop. Tools like Devin, SWE-agent, and Claude Code are early demonstrations of this. They are not reliable enough to ship production code unsupervised today. But the architecture is there.
“Getting from 30% to 100% is not a linear scaling problem. It requires solving a fundamentally different class of challenges.”
The third — and most underappreciated — is the specification problem. AI can only build what it is told to build. If you ask it to “build a user authentication system,” you will get something that works. But it will not know that your compliance team requires MFA, that your largest customer hates email-based login, or that your infrastructure cannot support the OAuth provider it chose. The quality of AI-generated software is bounded by the quality of human requirements. And humans are notoriously bad at writing complete, unambiguous specifications.
This is not a reason to dismiss the 100% scenario — it is a reason to understand what the bottleneck actually is. The constraint shifts from “can AI write code” to “can humans articulate what they want precisely enough.”
3. What Changes for Software Companies First
Before the societal disruption comes the business model disruption — and it is already happening.
Time-to-market compression is the most immediate effect. When a feature that took three weeks now takes three days, competitive dynamics shift dramatically. Companies that once competed on execution speed now have to compete on direction. It is not enough to ship fast; you have to ship the right things fast.
This creates a paradox for software development companies. The MVP — minimum viable product — has been the foundational strategy for a decade. Build the smallest thing that proves value, then iterate. But when anyone can build an MVP over a weekend using AI, the MVP is no longer a differentiator. Every competitor can match your starting point in days. What matters is what you build after that — the depth of domain knowledge, the quality of the user relationships, the institutional knowledge you have accumulated about the problem.
Pricing models are also under pressure. Agencies and dev shops that bill by the hour face an uncomfortable reality: if AI cuts development time by 60%, do clients pay 60% less? Some will demand it. The smart response is not to fight this but to restructure pricing around outcomes, not time. Fixed-price projects, value-based billing, and equity-style arrangements all become more viable when the cost of delivery drops.
The distinction between custom dev shops and product companies will sharpen. Product companies — those building software they own and sell — benefit asymmetrically from AI because it lowers the cost of building without lowering the price they can charge. Dev shops face margin compression. The obvious strategic move for any dev shop is to build products alongside client work. AI makes that economically viable for the first time at small scale.
4. What Happens to Developers?
This is the section everyone wants to read and nobody wants to write honestly. So let us try.
The historical parallels are instructive but imperfect. Desktop publishing eliminated many typesetting jobs but created graphic designers. CAD eliminated drafting boards but created new engineering roles. Database administrators became data engineers and then data scientists. In each case, the tool did not eliminate the human — it changed what kind of human was needed.
The same pattern will hold in software, but with important caveats. The abstraction ladder will move up. Developers who thrive will be those who operate at the level of systems, products, and outcomes — not individual lines of code. The most valuable engineering skill of the next decade will not be writing code fluently; it will be knowing what code to write and why.
New roles are already emerging. AI output reviewers — engineers whose primary job is evaluating and validating AI-generated code for security, performance, and correctness. System architects who design the high-level structure that AI then fills in. What might be called AI wranglers — specialists in crafting the prompts, context, and workflows that get production-quality output from AI systems.
The more difficult problem is the junior developer pipeline. For decades, entry-level engineering roles have been training grounds. Junior developers write the boilerplate, fix the small bugs, and learn by doing. If AI does that work instead, who learns? This is not a hypothetical concern — it is already showing up in hiring patterns. Companies that are cutting junior headcount because AI handles routine tasks are effectively defunding their own talent pipeline. The senior developers of 2035 need somewhere to start.
The honest answer is that some developer jobs will disappear, many will transform, and some new ones will appear that do not exist today. The developers most at risk are those in the middle — experienced enough to be expensive, but focused on execution tasks that AI increasingly handles well. The developers least at risk are those with deep domain expertise, strong product intuition, or the ability to think clearly at a systems level.
5. The Risks Nobody Is Engineering For
The productivity story around AI coding is compelling. The risk story is not getting nearly enough attention.
The first risk is AI-generated vulnerabilities at scale. Security vulnerabilities in software are typically introduced one at a time, by individual developers making individual mistakes. AI introduces a new failure mode: the same vulnerability introduced everywhere at once, because the same model suggested the same insecure pattern across thousands of codebases. A single flaw in a widely-used AI coding suggestion could propagate to millions of lines of production code before anyone notices.
The second risk is the hallucination problem in production systems. AI models confidently generate code that looks correct but contains subtle logical errors. In a development environment, this is caught in testing. But as AI takes on more of the testing process too, the safety net starts to have gaps. Who is responsible when AI-generated code causes a production incident? The legal and liability frameworks do not yet exist.
The third risk is monoculture. When every engineering team uses the same AI models, their codebases start to converge on the same patterns, the same libraries, the same architectural choices. Software diversity — the fact that different systems solve problems differently — is actually a form of resilience. Monoculture in software, like monoculture in agriculture, creates catastrophic single points of failure.
Finally, there is the institutional knowledge problem. Code written by AI and approved by engineers who did not fully understand it accumulates fast. Within a few years, organisations could find themselves running systems that nobody truly understands — not because the code is bad, but because no human ever built a deep mental model of it. Legacy code is already a problem. AI-generated legacy code, where the original intent is buried even deeper, could be far worse.
6. The Opportunity Hiding Inside the Disruption
Here is the counterintuitive truth: the companies that benefit most from AI writing code will not be the ones who use it to write more code faster. They will be the ones who use it to compete on something AI cannot commoditise.
When code becomes cheap to produce, value migrates to the things that remain scarce. Deep domain expertise — the kind you only get from years working inside a specific industry — becomes more valuable, not less. Distribution — having relationships with customers, a trusted brand, a sales motion — becomes more valuable. Product intuition — knowing which problems are worth solving and which solutions users will actually adopt — becomes more valuable.
The strategic distinction between AI-native and AI-augmented development companies will matter enormously. AI-augmented companies use AI to do what they already did, faster. AI-native companies redesign their entire workflow around AI capabilities and build things that were previously impossible. The second group will outcompete the first within five years.
Vertical software — products built for a specific industry with deep domain specificity — is the most defensible category in an AI-commoditised world. A generic project management tool can be replicated by AI in a weekend. A compliance workflow tool built specifically for pharmaceutical clinical trials, with the institutional knowledge to handle FDA audit requirements, cannot. The specificity is the moat.
The new product categories enabled by cheap code are also worth attention. Software products that were previously uneconomical to build — too niche, too complex for the potential market size — become viable when development cost drops by an order of magnitude. The long tail of software, where genuine problems go unsolved because they affect too few people to justify the development investment, is about to get built.
7. The Question Was Never “If” — It Is “When, and Are You Ready?”
AI writing 100% of code is not a thought experiment. It is a trajectory. The questions worth asking now are not about whether it will happen, but about what your company looks like when it does.
The companies that will thrive are not the ones who use AI to do the same things cheaper. They are the ones who ask: if code is free to produce, what becomes the new competitive advantage? Then they build for that instead.
The developers who will thrive are not the ones who resist AI or pretend it is a passing trend. They are the ones who climb the abstraction ladder — who become the people who can tell AI what to build, evaluate whether it built the right thing, and make the product and architectural decisions that determine whether the software is worth building at all.
“If code is free to produce, what becomes the new competitive advantage? That is the only question that matters right now.”
Every development company should be asking itself one question this quarter: what do we know, and who do we serve, that cannot be replicated by a model trained on the public internet?
The answer to that question is your actual business. Everything else is execution — and execution is becoming a commodity.
What do you think?
It is nice to know your opinion. Leave a comment.