Five ways to use AI agents to strengthen software architecture, according to InfoQ

An article published on InfoQ on September 28, 2026, written by architects Pierre Pureur, Kurt Bittner, and Todd Miller and reviewed by Daniel Bryant, summarizes five concrete ways to use AI coding agents to improve (not degrade) a system's architecture. The authors' starting point is a warning that applies to any team that has already put a Claude Code, Cursor, or Copilot to work in production: agents generate code far faster than any previous code-generation tool, but that speed guarantees nothing about the architectural quality of the result. If you feed the agent only functional requirements, it won't magically ensure the architecture is sound. It needs to be fed measurable architectural goals, the so-called QARs (Quality Attribute Requirements), and the trade-offs the team is willing to accept.

1. Document a legacy service nobody understands anymore

The first suggested use is the most direct: point the agent at a legacy service with no reliable documentation. The example given in the article is a rarely used service that reads data from an IMS database from decades ago, built for a context that no longer exists, and that can return incorrect information when used in a scenario its original authors never anticipated. These problems tend to surface late, during acceptance testing or already in production. An agent can map the service's design, document data flows, scan the code for logic or security flaws, and suggest fixes. If the service is bad enough, the agent can even refactor it to be more understandable and maintainable, eliminating a risk before it materializes in the new system.

For Brazilian teams still maintaining integrations with bank, insurer, and payroll mainframes running COBOL or other legacy languages, this is probably the article's most immediate use case. But it comes with a caveat the authors don't develop in detail and that's worth highlighting here: exposing legacy system data to an AI agent requires extra care with sensitive information, especially personal data under the LGPD, Brazil's data protection law. Masking secrets and restricting the agent's access to approved files, as the article itself recommends in the context of security audits, applies equally to this first front.

2. Hunt for architectural flaws before they become technical debt

The second suggestion is to use the agent to find problems that go beyond security: ignored architectural patterns, poor coding practices, boundary violations in Domain-Driven Design, and APIs that are hard to use, insecure, or inefficient. The article gives a specific example: asking the agent to evaluate the service layer and identify whether any component directly accesses another domain's internal state or improperly reuses its code.

The authors make an important caveat: there's a point of diminishing returns in this evaluation, because AI will almost always find some possible improvement. It's up to the team to decide which findings matter and which don't, and that only works if someone experienced in architecture is guiding the prompt and interpreting the result. An agent that receives only functional requirements, without articulated trade-offs, tends to produce a system that fails to meet the expected QARs. An interesting side effect noted in the text: the very exercise of writing that prompt forces the team to become more explicit about trade-offs that previously existed only in the head of the most experienced architect.

3. Security audits, dependencies included

The third front is security auditing, with a four-step playbook described in the article: mapping the system's design by tracing data flows and limiting the agent's access to only approved files; scanning the code for complex cross-file logic flaws, while masking passwords and secrets in the prompts; testing vulnerabilities by generating attack-style scripts to stress the system's defenses, keeping the agent on an isolated network so it doesn't accidentally attack production servers; and finally generating fix patches, with mandatory human review before any merge.

The authors cite a concrete case from their own practice: a client reported that several npm packages in use had been flagged as security risks. Using a coding agent, the team assessed the risks, produced a detailed report of the implications, and, as a result, updated two packages, replaced a third, and kept the fourth because the alert was a false positive. All of this work was done with the agent's support. It's a direct example of the kind of supply-chain triage any JavaScript team in Brazil has already faced after an alarming npm audit, only here automated and documented.

4. Give developers an architectural foundation for prototyping

The fourth suggestion tackles a common problem: agents free the team to experiment and show a user an almost instant prototype, but without architectural direction, that prototype tends to be disposable because it doesn't meet the system's QARs. The proposed solution is to turn architectural goals, code styles, database design, APIs, and preferred platforms and frameworks into Markdown documents that feed the agent, which then generates ready-made skeleton applications as a base for prototypes.

The article gives a practical example: in a small React application, asking the agent to evaluate the folder structure against modern community practices and, if it's out of alignment, apply adjustments, always with the caveat of checking whether the recommendation makes sense for the problem at hand. Another suggestion is to use GitHub's template feature to lock in the team's common application structure, with coding standards already built in, allowing teams to start projects on architecturally solid ground from the first commit.

The authors' central argument here is the most provocative in the article: describing what you want to achieve produces better results than describing the solution the agent should generate. This inverts the skill hierarchy developers have cultivated for years. Writing code, which has always been the core craft, becomes less critical. Understanding and articulating requirements and constraints, a task many developers have historically avoided, becomes the most important skill for the developer working with AI.

5. Generate testable MVAs instead of loose code

The final front is using the agent to generate a Minimum Viable Architecture (MVA), the minimum set of code that proves a system meets both its functional requirements and its QARs. The article is clear about the limits of this approach: part of what the agent generates will be wrong, so inspecting the code isn't enough, it needs to be evaluated through measurable tests. If the team has already provided QARs and trade-offs in earlier prompts, the agent has the information needed to also generate the tests: harnesses, test data, and environment configuration, including containers.

The authors point to a risk the team needs to monitor: the agent may fail to generate an MVA that fully satisfies the QARs, requiring manual extension. To avoid discovering this too late, the team can include architectural-change scenarios in the assessment of how adequate the generated MVA is, before assuming it's ready to become the base of the real system.

What remains open

The authors themselves classify the use of agents for resilient, scalable, and secure architecture as an early-stage practice: there's no established process, only suggestions they tested themselves through trial and error. The article isn't a cookbook, it's a starting point. For those leading architecture in Brazil, the practical takeaway running through all five fronts is always the same: human review before any merge is not optional, and the time the team thought it was saving by not writing detailed requirements now needs to be invested exactly there, because that's what separates an agent that strengthens architecture from an agent that just produces fast, fragile code.