Опыт + ИИ: как AI-агенты меняют роль архитектора

Writing code since 1989, the author has experienced numerous technological shifts, from Pascal and Clipper to modern ASP.NET Core stacks. They have witnessed paradigm changes, from structured programming to object-oriented, microservices, DevOps, clouds, and now artificial intelligence (AI). AI discussions often focus on AI replacing developers, but the author argues that a more pertinent question is how AI changes the developer's role, particularly the architect's role, when AI agents capable of writing code and making local technical decisions independently appear.

In this article, the author shares observations from personal experience about where AI saves time, common errors it makes, and how to adjust the review and task-setting process to benefit architecture rather than hinder it. The architect's role remains constant despite AI's arrival. While it may seem tempting to think that an AI agent writing code means the architect's role is limited to prompt writing, this is not the case.

The architect's primary responsibilities are: defining bounded contexts and where one service's responsibility ends and another's begins; making decisions under uncertainty when there is no single correct answer and only trade-offs between performance, support cost, and development speed; deeply understanding the business context to foresee the long-term consequences of technical decisions; and maintaining consistency across the entire system's architecture, not just within individual modules.

None of these tasks can be performed by an AI agent, as it requires not just access to code but an understanding of business goals, project history, and prior compromises. The agent sees the code, while the architect sees the system as a whole, including what may be missing in the code. AI truly saves time in specific scenarios, such as generating boilerplate code, implementing repository interfaces, DTO classes, and data mappers between layers, creating rough implementations to test hypotheses quickly, routine refactoring tasks like renaming, extracting common logic into methods, and enforcing consistent coding styles, and generating documentation like XML comments, README drafts, and API descriptions from existing code.

The general principle is that the more mechanical the task, the more confident one can let an agent handle it. The more architectural decisions are involved, the more human input is needed. A key takeaway from the common errors made by AI agents is that their generated code requires at least as thorough a review as junior developer code, if not more.

Common mistakes include API hallucinations (using non-existent methods or properties), incorrect assumptions about project context, violating architectural boundaries by directly accessing domain entities from controllers, ignoring existing project patterns, generating unnecessary code with unnecessary abstractions, and over-engineering.

When reviewing AI-generated code, the author focuses on verifying that layers aren't leaking business logic, adhering to existing architectural patterns, avoiding unnecessary complexity, and identifying hidden assumptions. Essentially, reviewing AI-generated code is similar to reviewing any team code, with added attention to common AI pitfalls.