The system on which a company's operations depend—the one that manages orders, policies, files, or shipments—isn't built by piling up fragments generated on the fly. It needs a defined data model, contracts between modules, a permissions and traceability model, and those four things are decisions someone makes, not results that are obtained.
The confusion arises because assisted generation works very well in the periphery, and that creates the expectation that it will work the same in the core.
Criterion | Core system | Peripheral system |
|---|---|---|
If it stops working | The company for | Someone is upset |
Expected useful life | 5-15 years | Months or a few years |
Number of integrations | Many and critical | Few or none |
Cost of a mistake | Money, customer, or fulfillment | Wasted time |
Who should be able to support it? | Any competent team | Who did it? |
The first row is sufficient to classify the 90% cases. If the answer to "what happens if this stops working for a day?" is that billing, production, or customer service stops, then it's core, and it deserves to be treated as core regardless of its size.
A common mistake is assuming that the core system is the big thing. There are small systems on which the entire operation depends, and enormous systems that nobody would miss for a week.
The data model. How business entities are represented: what is a customer, a file, a shipment; what relationships they have; what states they go through. This is the most costly decision to reverse, because everything else is built on top of it.
Property boundaries. Which module takes precedence over which information and which query? Without this decision, three systems appear writing the same data, and there's no way to know which one is correct.
The permissions model. Who sees what and who can do what, resolved as a system layer and not as conditions repeated throughout the application. This is what determines whether a wizard, a customer portal, or an API can be added tomorrow without creating a vulnerability.
Traceability. What is recorded for each change and for how long. It is irreversible: what wasn't saved doesn't exist.
None of the four can be delegated to a generation tool, because they all depend on knowing the business and anticipating how it will change.
It would be absurd to forgo the available speed. Within a well-structured core, assisted generation performs well in:
The rule is simple: The construction is delegated, not the structure.. And the review remains mandatory, for the reason we explained in The code that nobody understands is debt.
There is an operational criterion for determining if a core system is well-built, and it does not require auditing: Could another team take over this system in a month, without talking to the person who built it?
For the answer to be yes, four things are needed: architecture documentation, versioned integration contracts, tests that express what the business expects, and decisions explained in writing.
A system that fails this test poses a real operational risk, regardless of its technical quality: the company's continuity depends on the availability of specific personnel. And it also has a financial impact, because that's precisely what is penalized in a technology due diligence process.
Because the barrier to entry for producing something that works has dropped significantly, and with it the barrier to producing something that works but cannot be sustained.
GitClear data on 211 million lines of code reveals the pattern: refactoring work fell from around 25% of total change in 2021 to less than 10% in 2024, while replication increased eightfold. More is being built and less is being structured, and in a peripheral system that's manageable; in a core system, it's a burden.
When it comes to deciding how to build a critical system, the useful conversation isn't about methodology or tools. It's about three commitments:
With those three compromises, speed of generation is an advantage. Without them, it's the fastest known way to build something that no one can change.
It's the system on which the operation depends: if it stops working for even a day, billing, production, or customer service ceases. It's not defined by its size—there are small core systems and large systems that aren't—but by the consequences of its unavailability.
Four: the data model that represents the business entities, the ownership boundaries that determine which module has control over which information, the permissions model resolved as a system layer, and the traceability of changes. None of these can be delegated to a generation tool.
Yes, within a pre-defined structure: implementation of pre-specified rules, a presentation layer, transformations with explicit acceptance criteria, and documentation of previously described cases. The rule is to delegate the construction, not the structure.
The handover test involves assessing whether another team can take over within a month without consulting the original team. This requires architectural documentation, versioned integration agreements, tests that demonstrate business expectations, and clearly explained decisions.
An operational risk —continuity depends on specific people— and a financial risk, because that is precisely what is penalized in a technological due diligence when valuing the company or seeking investment.
Because the barrier to producing working code has dropped significantly. GitClear documented that refactoring fell from approximately 25% of total change in 2021 to less than 10% in 2024, and that duplication increased eightfold: more is being built and less is being structured, which in a critical system becomes a burden.
Are you going to build a system that your operation will depend on? We define architecture, data model, and contracts before writing code, and we transfer the code and documentation to you by contract. Let's talk → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
