The real competitive advantage isn't adopting AI coding tools — it's building the architecture, feedback loops, and organisational adaptability to move with the curve.
Almost no matter which direction you look, the numbers show that new companies and products are growing exponentially as AI helps us with coding and automation. Ideas become reality, and limitations caused by missing skills disappear.
For existing companies to take advantage of AI’s potential and avoid being overtaken by the exponentially growing competition enabled by AI coding capabilities, we need to start at the individual level by becoming more adaptable as humans, so the foundation of our companies can become more adaptable as well. Architecture built on a modular and scalable foundation requires that we ourselves think in those terms, rather than trying to protect a “sunk cost” legacy that will only slow down the momentum needed as the wave of competition grows.
The gold of the future is adaptability, its readiness for change in scale.
These days, there is a strong focus on where AI-assisted programming / vibecoding has its limitations across countless forums for developers and educators alike.
The statement often sounds like: “We must maintain ownership over code line by line. (because reasons)” And I’m happy to challenge that directly in order to open a dialogue that I believe is important for everyone running a business, which future is somehow dependent on software/code. The core point of this post is that, as a designer, I can say that before long, line-by-line code will become as much of a black box to us as the diagram on a motherboard/PCB. Yes, specialists can repair it, but most often we simply replace the unit with one that works and has been tested.
When it comes to what AI can code, there are three very different categories of problems that I repeatedly see being misunderstood:
Problems so unique that NO ONE in the world has encountered them before, you cannot Google anything remotely similar. (Perhaps so unique because standardized architecture and principles were never prioritized.)
Problems we experience in our code that seem subjectively extremely unique due to the specific combination of legacy code and integrations we work with. But these are problems that exist elsewhere too, and perhaps 20,000+ other companies have encountered them as well.
Problems that are widely discussed and that most AI agents are already good at coding around.
I believe we need to distinguish more clearly between what feels unique from the inside and what is actually unique from the outside.
Our codebase, legacy systems, integrations, and historical decisions can feel extremely specific. But many of those problems are often variations of issues others have also faced: legacy systems, frameworks, integrations, security, data flows, performance, and architecture.
As humans, we evaluate based on the 50, 100, or 200 projects we ourselves have seen. AI and the open-source community will increasingly reflect patterns across hundreds of thousands of projects, issues, pull requests, repositories, bugs, and solutions.
That’s why we should be careful about calling something unique simply because it is unique within our own professional memory.
But this is not really about AI-generated code as it exists today.
It’s about the trajectory.
Two or three years ago, AI-generated code was far more limited. It could help with small snippets, boilerplate, and simple explanations, but it quickly fell apart when context became large, architecture became complex, or work had to span a larger codebase.
Today, we see models, agents, and tooling capable of writing larger amounts of code, refactoring, understanding multiple files, working with tests, reading documentation, and navigating repositories in entirely different ways.
So the question is not only where AI-generated code is today.
The question is:
where will it be in 2–3 years?
Where will it be in 5 years?
Where will it be in 10 years?
If you look at the curve over the past few years, it seems highly unlikely that it will simply flatline from where it is today.
The models are improving. Context windows are getting larger. Memory frameworks are improving. Repositories are becoming easier to index. Decision histories can be stored. Harness engineering is becoming more mature. Feedback loops are becoming more standardized.
So when we talk about “the model,” we are not only talking about the model itself. We are talking about the model plus the entire way it is packaged, managed, tested, remembered, observed, and validated.
If AI generates code and we are worried about backdoors, security vulnerabilities, or unpredictable behavior, then the answer is not necessarily manual line-by-line control.
The answer is stronger feedback loops, where experienced humans ensure that the right tests and controls are defined.
What today may feel like unique harness engineering with browser checks, device checks, security checks, and other backdoor safeguards are actually fairly generic principles that will naturally become integrated into future AI tooling and vibecoding frameworks.
Tests, security scans, threat models, observability, runtime checks, integration tests, evaluations, rollback mechanisms, and clear acceptance criteria.
Those are the loops that must catch what we can no longer, or should no longer, manually control at the line level.
Many people vibecoding today are used to “one-pass” coding, but we are already far beyond that in larger professional setups where numerous feedback loops and reviews happen automatically without humans involved.
So if there is any code left that, hypothetically in 2–3 years, AI still struggles to handle, then it is likely code that has become so specialized and unnecessarily complex that neither humans nor AI can effectively work with it. And if AI still cannot take over or significantly assist with your code in 2–3 years, then perhaps that is a sign that the architecture was not designed with enough scalability and standardization from the beginning.
Personally, I still believe AI will be able to traverse and understand even the most complex legacy systems within 2–3 years.
So my recommendation is to organize around that reality already now.
And when we talk about very heavy legacy environments, mainframes, COBOL, SAP Hybris, and old monoliths, then perhaps the question is not:
can AI perfectly understand all of that old technology?
The question is rather:
how quickly can we use AI to begin modernizing those layers so they become more standardized, scalable, modular, and maintainable?
The future may not be about getting AI to repair old legacy systems forever. Perhaps it is more about using AI to rewrite, separate, containerize, split into microservices, integrate headlessly, and modernize components that previously would have taken 5–10 years to break free from.
This is where the role of architects becomes crucial.
Humans still need to define what creates stability, scalability, security, and business value. But machines can increasingly help produce, rewrite, test, and validate code within those frameworks.
Where our human value becomes hardest to replace is not necessarily in the code itself.
It is in the context surrounding the code:
the company, the customers, stakeholders, history, product strategy, political considerations, and the unspoken business rules.
This is where context engineering truly becomes human-driven.
I therefore believe we will see a split.
Some companies will use AI to patch the old.
Others will use AI to build their way out of the old.
And that could become a major competitive factor, not just technically, but economically. Because if some companies can modernize in one year what previously took five, then that changes momentum, cost structures, and the ability to execute.
So for me, the question is not about blindly vibecoding business-critical systems tomorrow.
It is about understanding the trajectory and beginning to build architecture, testing environments, feedback loops, and organizations that fit the reality we are moving into.
We should not shape our business around a single point on the curve.
We should shape it around the direction the curve is moving in.
.