There is a growing assumption in software development that AI can increasingly replace traditional engineering effort. Give a coding agent a business requirement. Let it generate the application. Review the output. Repeat.
For simple applications, that approach can work surprisingly well. For complex operational systems, it can also fail spectacularly.
The problem is not that AI cannot write code. It can. The problem is that writing code is only one small part of building a high-quality system. The harder questions are:
- What should the system actually do? How modular should it be? What is the build strategy we should use to create and assemble the right modules in the right order?
- Which parts should be deterministic?
- Which parts genuinely require an LLM?
- What information does the model need to make a reliable decision?
- What happens when the source data is incomplete, contradictory, or of poor quality?
- How should confidence be measured?
- When should the system retry?
- When should it escalate?
- Which business rules must never be left to probabilistic interpretation?
- And how should the entire architecture balance quality, speed, cost, maintainability, and operational risk?
These are architecture questions.... and AI is creating the need for a new breed of architect.
From Software Architect to AI-Native Business Architect
Traditional organizations often separate responsibilities.
- Business leaders define requirements.
- Business analysts document workflows.
- Solution architects design systems.
- Software engineers write code.
- Data scientists build models.
- Operations teams explain exceptions.
AI is beginning to blur or eliminate many of these boundaries. The most effective architect in an AI-driven development environment may need to understand all of them. This person needs enough domain expertise to deeply understand the business problem, enough systems thinking to translate that problem into a robust architecture, and enough technical depth to work directly alongside AI coding tools at the level of APIs, data structures, database schemas, orchestration logic, model selection, validation rules, and even individual functions.
That is a very different role from the traditional architect who produces a high-level diagram and hands it to a development team.
The new AI-native architect must be able to move continuously between three levels:
- Business reality.
- System architecture.
- Detailed implementation.
That combination is becoming extremely powerful.
A Logistics Document Parser Is a Good Example
Consider something that sounds relatively straightforward: build a system that extracts structured information from logistics documents. The obvious AI-first approach is simple.
- Send every document to a powerful frontier model.
- Ask the model to extract the required fields.
- Return structured JSON.
- At first glance, this looks elegant.
- It may even produce an impressive demo.
But real operations quickly expose the weaknesses. Some documents are clean digital PDFs. Others are scans. Some contain tables. Some are poorly aligned. Some have handwriting. Some use known templates. Others are completely unfamiliar. Some fields can be extracted deterministically. Others require contextual interpretation. Some missing values can be inferred safely. Others must never be guessed.
A blind AI engineering approach treats all of these situations as essentially the same problem. Send the document to the biggest model and hope it figures it out. That approach can become expensive, inconsistent, difficult to debug, and hard to scale.
A strong architect looks at the same problem differently.
The question is not: **Which AI model should parse the document?
The question is: **What is the most efficient and reliable processing architecture for each type of document and each type of information within that document?
That leads to a completely different system.
The Best AI Architecture Often Uses Less AI
A well-designed document processing pipeline might begin by analyzing the input.
- What kind of document is this?
- Is it a digital PDF or an image?
- Does it contain an accessible text layer?
- How clean is the layout?
- Is the document based on a known format?
- How much ambiguity exists?
The system can then choose an appropriate processing path. High-quality documents may be handled largely through deterministic parsing libraries. Known structures may be processed using rules, coordinates, regular expressions, table extraction, or document-specific parsers. Moderately difficult documents may be sent to a fast, inexpensive model. Only the genuinely difficult cases may require a more powerful reasoning model.
The system can then perform validation.
- Are required fields present?
- Do the extracted values follow expected formats?
- Do totals reconcile?
- Do dates make sense?
- Are pickup and delivery locations logically consistent?
- Does the extracted equipment type belong to the allowed set?
- Does one field contradict another?
Low-confidence fields can be selectively reprocessed rather than sending the entire document through another expensive model call. This is no longer a single AI prompt. It is an engineered decision system. And in one implementation of this approach, the result was approximately 100 times lower processing cost for good-quality documents and 10 times lower cost for poor-quality PDFs, while also improving overall output quality.
The improvement did not come from finding a more powerful AI model.
It came from better architecture (and a little bit by moving to GLM 4.7 flash and GLM 5.2)
Domain Expertise Is What Makes the Architecture Intelligent
This is where deep business knowledge becomes critical. An engineer who does not understand logistics may be able to extract text from a rate confirmation. But will that engineer understand the operational significance of the difference between a pickup appointment and a delivery appointment? Will the system understand that a reference number appearing near a shipper may mean something different from the same label near a consignee? Will it understand accessorial charges? etc.
The business workflow defines what the software must consider important. Without domain expertise, the AI may produce operationally wrong and technically valid output.
That is one of the most dangerous failure modes in AI development. A system can appear sophisticated, produce polished output, and still misunderstand the business. The architect, therefore, has to do more than translate a requirement document into a system design. The architect needs to understand how the work is actually performed, including the exceptions, the workarounds, the edge cases, and the undocumented rules.
The situations where an experienced operator would immediately say, “That cannot be right.” Those details become business logic. And business logic must ultimately become system behavior.
But Business Expertise Alone Is No Longer Enough
The opposite problem also exists. A domain expert may understand the business perfectly but lack the technical depth required to shape the architecture. That can lead to another form of blind AI adoption.
The business expert explains the process to an AI coding agent and accepts whatever technical architecture the agent produces. But AI coding systems optimize within the context they are given. They do not automatically understand the economics of the complete system. They may use an LLM where a database query would be better. They may repeatedly send large context windows where a small structured payload would work. They may duplicate logic. They may create unnecessary model calls. They may put critical business rules inside prompts rather than deterministic code. They may build a technically functioning system whose cost structure becomes impossible at production scale.... or should I say "they will" often enough that it matters.
Someone needs to recognize these decisions. That person needs enough technical depth to ask questions such as:
- Why are we calling the model here?
- Could this be deterministic?
- Why are we sending the entire document again?
- Can we isolate only the low-confidence fields?
- Should this logic be implemented in SQL, application code, a rules engine, or an LLM?
- What happens when the model returns invalid JSON?
- How are retries controlled?
- How is confidence measured?
- What is the fallback path?
- How do we trace why the system made a particular decision?
- How much will this architecture cost at one thousand transactions per day? What about one million?
The new architect does not necessarily need to personally write every line of production code. But the architect must understand the code deeply enough to shape it.
Working Alongside AI, Not Merely Delegating to It
This may be one of the biggest changes in software development. Historically, senior architects often moved away from detailed implementation. AI may reverse that trend.
Because AI can generate code so quickly, the bottleneck increasingly moves from typing code to making good decisions. A technically capable architect can now work directly with AI to move from business concept to architecture to implementation at extraordinary speed. The architect can define the workflow, ask AI to generate the first implementation, inspect the data model, challenge the API design, restructure the orchestration, move logic from prompts into deterministic functions, simplify model calls, add validation, simulate edge cases, review SQL, refactor individual functions, test alternative architectures.
The architect is not competing with AI as a programmer; he or she is directing it. AI becomes an extremely capable engineering partner. But a partner still needs direction.
The Future May Belong to People Who Can Cross the Boundaries
The traditional separation between “business person” and “technical person” is becoming less useful. The most valuable people in complex AI development may increasingly be those who can operate across both worlds. They can sit with executives and understand the business objective, and with operators to understand the real workflow. They can identify where rules, judgment, and exceptions actually exist. They can translate that understanding into system architecture, and then go deep enough into the implementation to ensure the architecture survives contact with the code. They understand that not every problem requires AI and that probabilistic systems and deterministic software add value in very different ways.
They understand model economics, context limitations, validation, and orchestration. Most importantly, they understand the business well enough to know when the system is technically correct but operationally wrong.
AI Does Not Eliminate the Need for Architecture
It makes architecture more important. When code becomes cheaper to generate, bad architecture can be produced faster than ever. A team can build an enormous amount of software before realizing that the underlying design is wrong. The winners in AI development will not necessarily be the organizations with access to the most powerful models. Everyone will increasingly have access to powerful models. The advantage will come from how those models are used. Knowing when to use them and when not to use them. How to combine them with deterministic systems, capture business logic correctly, design workflows around uncertainty, and create systems that are not merely impressive in a demonstration, but reliable, economical, and operationally valuable in the real world.
That requires more than an AI engineer. It requires a new kind of architect.
One who understands the business deeply enough to define what should be built. And understands the technology deeply enough to make sure it is built the right way.