AI coding agents can help software teams address architectural problems that go beyond simply writing code, but their usefulness depends on the clarity of the goals and constraints defined by the team. The article published in InfoQ, written by Pierre Pureur, Kurt Bittner, and Todd Miller and reviewed by Daniel Bryant, warns that providing an agent with only functional requirements does not guarantee an architecture that is scalable, secure, or easy to maintain.
The proposed approach is based on Quality Attribute Requirements (QARs), such as performance, security, and scalability, as well as clarifying the trade-offs that the agent should consider. The article also stresses the need to test what the agent produces using clear measurements, rather than merely inspecting the code or trusting its recommendations.
1. Document Legacy Services Before Relying on Them
A modern architecture may depend on a legacy service that performs a specific function, such as retrieving insurance-policy data from a legacy system built on an IMS database. The problem is that these services may lack accurate documentation, making it difficult to understand data flows or identify logical and security flaws that may emerge late in development or after migration to production.
The agent can map the service design and document data flows, then inspect the code and suggest fixes or refactoring if the service is difficult to understand and maintain. However, this use does not eliminate the need for a human engineering decision about whether the service can be retained or whether its risks require replacement.
2. Look for Architectural Flaws
The agent can be directed to find violations of architectural standards, degraded software practices, or areas that require refactoring. Examples of areas to inspect include API design, complex, insecure, or inefficient interfaces, and violations of Domain-Driven Design (DDD) boundaries.
The article notes that the agent will often find many possible improvements, so the team must distinguish important problems from low-value suggestions. Results improve when engineers define measurable goals, known alternatives, and clear trade-offs instead of merely describing the required functions.
3. Conduct Security Audits with Agent Isolation
The agent can be used to map data flows, identify high-risk files, inspect complex logical flaws, create tests or scripts that simulate exploitation attempts, and then suggest patches for discovered issues. The article presents an experiment involving npm packages classified as posing security risks; two packages were updated, one package was replaced, and another was retained after the alert was considered a false positive.
However, this use requires explicit operational constraints: limiting the agent’s access to approved files, concealing database passwords and secrets, running tests on an isolated network, and requiring human review before merging any change.
4. Create an Architectural Foundation for Prototypes
Agents’ speed makes it possible to build a prototype quickly, but the resulting prototype may be temporary and unsuitable if architectural goals are not defined for it. The article suggests preparing starter applications that include coding style, database design, interfaces, preferred platforms and frameworks, along with QARs written in Markdown.
GitHub templates can also be used to standardize the initial structure of applications and incorporate team standards from the outset. It is better to describe the goal, the constraints, and how their achievement will be verified than to impose a detailed solution on the agent in advance.
5. Generate Testable Initial Architectures
The article proposes using the agent to create Minimum Viable Architectures, or MVAs, which include not only code that proves functionality but also the tests, test data, and runtime environment needed to verify QARs. The agent can generate testing tools and container configurations, but the team must ensure that the tests actually measure the required attributes.
The MVA’s ability to accommodate architectural change scenarios should also be assessed, because expanding an automatically generated architecture may become costly if it was not designed to evolve.
What Changes in Practice?
The article’s central message is that coding agents make code production faster, but they increase the importance of formulating requirements, constraints, and tests. Skills related to writing code do not disappear, but determining what should be built, what constitutes acceptable quality, and how it will be measured becomes more critical. Therefore, the agent should be treated as a tool under architectural supervision, not as a substitute for engineering judgment.