The bottleneck in software development is no longer writing code: it's deciding what to build, how to connect it, and how to maintain it as it changes. For two decades, the shortage was in production capacity; today, code production is abundant and cheap, and the shortage has shifted entirely to design decisions that no code generation tool can make for you.
This has a concrete business consequence for any company purchasing development services in 2026: the hourly rate for writing code is falling, and the cost of a poor architectural decision is rising. Purchasing as if we were still in 2019—comparing providers by price and speed—is optimizing the wrong variable.
Intuition suggests that if producing code is faster, projects should finish sooner. Data tells a different story.
The 2024 DORA report, compiled by Google Cloud from approximately 39,000 industry professionals, found that a 25% increase in AI adoption correlated with a 1.5% decrease in delivery throughput and a 7.2% decrease in stability. This wasn't because the generated code was inherently bad, but because change batch sizes were increasing: more code was being deployed at once, reviews were less thorough, and more code was breaking. In the same study, 39.2% of developers reported little to no confidence in AI-generated code.
GitClear, analyzing 211 million lines of code between 2020 and 2024, documented the other side of the same phenomenon: refactored or "moved" code fell from approximately 25% in 2021 to less than 10% in 2024, while copy-pasting rose from 8.3% to 12.3% and duplicate blocks increased eightfold.
Translated: More is written, less is reorganized. It accumulates.
METR's July 2025 study added a nuance that needs to be addressed honestly. In a controlled trial with 16 experienced open-source developers and 246 real-world tasks, participants took 19% longer using AI, even though they expected to be 24% faster and, after the test, still believed they had been 20% faster. METR itself reviewed that design in February 2026 for potential selection bias, and a larger cohort showed a much smaller difference. The exact result is up for debate. What is not up for debate is the secondary finding: perceived speed and actual speed decouple.
When the perception of speed becomes decoupled from reality, the discipline that corrects the course is not execution. It's design.
Not all technical decisions carry the same weight. The practical distinction is between what can be changed in a week and what will shape the next five years.
Type of decision | Example | Cost of changing it afterwards |
Tool | Frontend framework, graphics library | Low: weeks |
Model provider | Changing from one LLM to another | Under if there is a layer of abstraction |
Data model | How to represent a customer or an order | High: affects everything built above it |
Boundaries between systems | Which module owns which information? | Very high: partial rewrite |
Permit template | Who can see and do what, and with what traceability | Very high: implies security and compliance |
The first two rows are the ones that generate the most noise in technical meetings. The last three are the ones that determine whether, in three years' time, the company can evolve its system or has to rewrite it.
A concrete example that recurs in logistics, insurance, and healthcare is the decision of whether a "patient record" is a standalone entity with its own lifecycle or simply a view built on top of other tables. This decision is made in week two of the project, almost always without discussion, and determines for years whether changes can be audited, whether data retention can be enforced, and whether the record can be exposed to a third party via an API. No code generator is going to make this decision because it's not a coding question: it's a business question.
This is the work we do in Custom software development [internal link] Before writing the first line: define what exists, what owns what, and what contract each module has with the others.
The architecture of an enterprise system is defined by four boundaries. When all four are well-defined, the system evolves. When any one becomes blurred, the system degrades, even if the code is impeccable.
The data frontier. Each piece of data should have a single owner: one system that commands and others that query it. The alternative—three systems writing the same information—produces contradictions that no higher layer can resolve, and is the root cause of most business intelligence projects that end in arguments about which number is correct.
The frontier of contracts. The modules communicate through explicit, versioned, and documented interfaces. A contract is a promise: "this is what I deliver, this is what I guarantee, this is what I change with prior notice." Without contracts, every integration is a new coupling, and every change is a negotiation.
The border of permits. Who can see what and who can do what should be a layer of the system, not a condition repeated in forty places. This boundary has become critical with the arrival of AI agents that execute actions: if the permissions model was fragile with human users, it breaks down with non-human identities.
The boundary of observability. A system where it's impossible to know what happened, when, and why, is neither maintainable nor auditable. And since probabilistic components have been introduced into the chain, traceability has ceased to be a good operational practice and has become a governance requirement.
These four boundaries are what structure a composable architecture, an approach that we develop in detail in our analysis on composable architecture, APIs and artificial intelligence
A formal audit isn't necessary to detect the early symptoms. These are the indicators that appear first:
When three or more of these symptoms appear, adding development capacity doesn't accelerate anything. It only increases the number of people waiting for a design decision to be resolved.
The argument for architecture is often presented in engineering terms, which is why it loses traction in management committees. Translated into business language, good architecture does four measurable things:
Reduce the cost of changing your mind. A company that can modify its offering, its billing process, or its pricing model in weeks competes differently than one that needs six months.
Turn technology into an asset, not a recurring expense. A system with clear code ownership, documentation, and explicit contracts is valuable in due diligence. A system that relies on a single vendor is not.
It allows replacing parts without rebuilding the assembly. This is especially relevant with AI models, whose prices, capabilities, and usage policies change several times a year.
It makes decisions auditable. With the European regulatory framework becoming stricter, it is important to be able to demonstrate what the system did and with what data has gone from being desirable to being required.
At The Cloud Group, this is formalized in TCG-SAF™, our systems architecture framework: five stages—Vision, Domains, Modules, Engineer, Execute—and a single architecture document that governs the entire build. This isn't an aesthetic preference. It's the reason we can provide written deadline guarantees: a date can only be committed to when the scope is structured before starting.
During the peak of the hype, it was assumed that if everyone had access to the same models, capabilities would be equalized. The opposite has occurred. Two companies with identical access to the same tools obtain radically different results, and the difference lies in their proprietary data, their domain knowledge, and the quality of integration between their systems.
Models become commoditized. Code generation tools become commoditized. What doesn't become commoditized is the ability to transform generic capabilities into a specific, reliable, and proprietary system.
That ability has an old and rather unglamorous name: engineering.
Software architecture is the set of decisions about which components exist, what information each one holds, and how they communicate with each other. It matters more than code because code can be rewritten in weeks, while changing the data model or the boundaries between systems may require a partial rewrite of the product.
Typical symptoms include: small changes take as long as large ones, estimates are unreliable, each new integration costs as much as the first, there are areas of the system that the team avoids touching, and knowledge of the information flow depends on a single person.
No: it increases it. When generating code is cheap, scarcity shifts to deciding what to build and how to connect it. The 2024 DORA report found that increased AI adoption correlated with lower delivery stability, precisely because the volume of change grows without a corresponding increase in design discipline.
The three most expensive aspects to revert are the data model (how business entities are represented), the ownership boundaries between systems (which module controls which information), and the permissions and traceability model. Changing frameworks or model providers is comparatively inexpensive.
It depends on the degree of coupling, but the typical pattern is that the cost grows non-linearly over time: each month of building on a poorly defined boundary adds code that will depend on that decision. That's why an early technical audit usually costs a fraction of what the rewrite it prevents would cost.
Yes. The usual approach is to isolate the existing system behind explicit contracts and replace domains one by one, rather than rewriting everything at once. This requires a preliminary assessment that prioritizes which domain to modernize first based on risk and business value.
Do you suspect that your architecture is the obstacle? Our technical software audit delivers a written diagnosis of architecture, code, debt, and security within 10 business days at a fixed price. No commercial proposal included: diagnosis first, then decision. Request the audit → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
