The first version is only the beginning
The first version of an application looks promising. Sign-in works, customer details can be saved and a quotation takes only a few clicks. A coding assistant has supplied much of the code.
Then the next requirement arrives: several businesses must use the same application while their data remains strictly separate. An employee may edit quotations but must not manage users. A new interface also needs connecting.
At this point, I am less interested in how quickly the first interface appeared. What matters is whether the application was designed to accommodate these changes in a controlled way.
Working code is a beginning. A maintainable application also needs an understandable structure.
Time savings do not end with writing code
On 10 March 2026, DORA published an analysis of 1,110 open-ended responses from Google software engineers, collected in the third quarter of 2025. They described benefits in code creation alongside extra work for checking, correction and integration. These qualitative responses are not a general measurement of productivity gains across all development teams. [1]
For me, this is an important reminder: measuring only the time to the first draft captures just part of the work.
A completed change also includes verification, documentation, release and observation in operation. If a quickly generated feature leaves several confusing dependencies behind, the calculation is not finished.
I would therefore neither hold AI back indiscriminately nor judge it by the amount of code it produces. The useful question is whether the whole task can be completed more reliably.
Architecture starts with clear responsibilities
Software architecture includes how an application is divided into parts, what each part does and how they work together. Microsoft’s architectural principles explain separation of concerns: presentation, business rules and technical data access should not become arbitrarily entangled. [2]
For a small customer management application, I would consider this division:
Sign-in and permissions: verify identities and enforce authorised access.
Customer management: maintain customer details and contacts.
Order processing: represent services, progress and responsibilities.
Document generation: produce the intended documents from approved information.
This is a planning example, not a prescribed architecture.
I would want a document layout change not to affect sign-in at the same time. Equally, a new import feature should not introduce its own inconsistent rules for access to customer data.
AI may propose options. The development team must consciously decide which boundaries apply.
A smaller system does not automatically need microservices
Having several modules does not mean each must run as a separate service on another server.
A modular monolith is delivered as one application but is internally divided into understandable areas. Microservices distribute functions across independently operated services. Microsoft highlights the additional challenges of distributed systems, including inter-service communication, data consistency and more complex testing. [2] [3]
For our small customer management example, I would initially favour a manageable, well-structured application. I would separate services only when a specific need arises.
Such a need might be a computationally intensive process that must operate independently of the rest of the system. “AI suggested it” would not be sufficient justification for me.
A good architecture must suit the task and the team operating it. It does not need to look as complicated as possible.
Define the task before AI implements it
“Build a customer management system” leaves a great deal open. An assistant may then make decisions nobody explicitly requested.
I would define the assignment more narrowly. Which feature is being added? Which existing modules must be used? Which files may be changed? What conditions must the result satisfy?
A suitable assignment might begin like this:
Example assignment: Add search to the existing order module. Use the current permission checks and data access layer. Search must return only orders belonging to the signed-in business. Do not add a new library. Add tests for permitted and denied access.
This still does not guarantee a correct implementation. It does give the subsequent review a standard to work against.
I would also record important architectural decisions briefly: what was chosen, which alternative was rejected and why? A few understandable paragraphs in the project may be enough.
This documentation should not wait until nobody remembers why an unusual solution was introduced.
Tests must check requirements, not merely generated code
A coding assistant can suggest tests. I would not accept them solely because they were generated alongside the implementation.
If both rest on the same incorrect assumption, a green result can be misleading.
For our example, I would first define the required behaviour. Users must not see another company’s customer data. Missing permission must cause rejection. Invalid input must not leave an incomplete order behind.
Only then would I check whether the tests cover those requirements.
OWASP’s Application Security Verification Standard (ASVS) provides guidance for technical security checks. The project page checked on 9 October 2026 supplies version 5.0.0 as a basis for verifiable application security requirements. It does not replace an individual risk assessment but helps make checks more specific. [4]
Hiding a button in the interface would not provide sufficient access protection in our example. Permission must also be checked where data is actually requested or changed.
I would not assess these relationships solely through a superficial demonstration.
Automated code review also needs oversight
Having a second AI examine the first draft may produce further observations. For me, it cannot replace understanding the important changes ourselves.
GitHub recommends using AI-assisted code review to supplement human review. Its feedback should be checked, not assumed correct. [5]
I would therefore prefer manageable changes. A clearly bounded search feature is easier to assess than a package that simultaneously rewrites authentication, database structure and the user interface.
Before approval, I want to see which requirement has been met, which risks have been checked and which changes were deliberately outside the assignment.
The coding assistant’s access rights belong in that decision too. For ordinary development tasks, I would not provide production customer data or extensive administrative access. A separate working environment with suitable test data is my preferred starting point.
Architecture includes operation after release
An application must do more than start. It must also be updateable, observable and recoverable when something goes wrong.
NIST published the Secure Software Development Framework, version 1.1, in February 2022. It integrates secure development into the wider process, aiming to reduce vulnerabilities, limit their impact and address recurring causes. [6]
Before release, I would test a version change in our example. What happens when the database structure changes? Can existing data be migrated correctly? How will we identify unexpected errors in a new version?
A recovery route must also be prepared. Reinstalling the old program may not be enough if the new version has already changed data. I would therefore plan recovery and migration together.
I also want to trace errors without unnecessarily placing confidential information in logs. A useful error message does not need the full contents of a customer document.
How I would recognise useful AI assistance
I would not assess a coding assistant by counting changed files or accepted suggestions.
I care about the consequences: are changes understandable? Are mistakes found before release? Can another person take over? Can features be added without repeatedly rebuilding large parts of the application?
A useful comparison must therefore include verification effort, rework and problems after release.
If AI reliably prepares a recurring task and gives the team more time for professional decisions, that is a tangible benefit. If it mainly creates more unchecked changes, work has initially just been shifted elsewhere.
My conclusion: Responsibility cannot be generated away
I consider AI a useful tool in software development. It can assist with design, explanation, testing and implementation.
Responsibility for the application remains with the people who develop and release it. They must decide which data needs protection, which failures are acceptable and how the system will be supported over time.
This does not require a particularly elaborate architecture diagram. It requires clear decisions and an implementation that can be checked against them.
Good software does not emerge from producing as much code as possible as quickly as possible. It emerges when understandable solutions work reliably together.
Scope and research
Research date: 9 October 2026. Examples provide general guidance, not an individual architecture or security assessment. DORA responses are qualitative observations, not a general productivity measurement.
Sources and further reading
Sources checked on 9 October 2026. Access dates are not publication dates. Manufacturer, research and authority sources were checked directly.
[1] DORA: Balancing AI tensions (10 March 2026)
Read source ↗
[2] Microsoft Learn: Architectural principles and common web architectures
Read source ↗
[2] Microsoft Learn: Architectural principles and common web architectures
Read source ↗
[3] Microsoft Learn: Microservices architecture style
Read source ↗
[4] OWASP: Application Security Verification Standard, version 5.0.0
Read source ↗
[5] GitHub: Application card: GitHub Copilot Agents
Read source ↗
[6] NIST: Secure Software Development Framework version 1.1 (February 2022)
Read source ↗