Andrey Kuznetsov is a founder and CTO focused on agentic systems in finance, blockchain infrastructure and regulated financial technology.
For years, engineering organizations were built around scarcity. Headcount was the ceiling. Merge conflicts were manageable. System analysts translated business intent into something engineering could build. The main question was simple: How do we allocate limited human capacity?
AI agents change that assumption. They don’t fix bad architecture or remove the need for judgment. What they do is increase output. A lot of output.
Putting agents into an engineering team can feel like upgrading every car in a city to a Ferrari overnight. It’s the same roads, drivers and traffic lights, but everything suddenly moves faster, and the old rules aren’t enough.
When output becomes cheap, coherence becomes expensive.
The Bottleneck Moves
The number of engineers used to limit how much code an organization could produce. That acted as a natural brake. AI removes part of that friction. First drafts, tests, documentation and refactoring are all faster. However, more pull requests don’t automatically mean more product value.
Once agents increase output per developer, the pressure moves to coordination. Review queues get longer. Similar logic appears in three places. Two agents solve the same problem in incompatible ways. A quick fix breaks an invariant nobody wrote down. Interfaces drift. Ownership gets blurry.
A problem that used to grow over six months can now grow over six weeks. The job is to make sure the system can absorb more speed without collapsing.
Architecture Is City Planning Now
A city doesn’t work because every car is fast. It works because roads, zoning, traffic rules and utilities keep movement from turning into chaos.
Module boundaries are zoning laws. Every domain needs an owner, a boundary and a rule for what can cross it. In a fintech product, that might mean billing, risk, ledger, identity and compliance are treated as separate zones.
A developer, or an agent working with that developer, shouldn’t touch billing logic and risk logic in the same pull request just because both files were easy to edit. That’s how cities get factories inside residential blocks. If a change crosses a domain boundary, it needs a higher level of review because boundaries are where hidden risk lives.
A billing workflow shouldn’t read directly from the internal tables of a risk engine. It should use a public API or a contract owned by the risk team. AI agents will find those hidden dependencies and multiply them.
Interfaces are permits. Who owns this contract? What data can pass? What happens when the other service is down? Who gets paged if it breaks? With AI-assisted work, the bar often needs to be higher because the code may look clean while missing the system context entirely.
Shared infrastructure is the road network. The platform team defines the paved paths: CI checks, deployment templates, observability, feature flags, secrets management and rollback patterns. A team shouldn’t have to invent its own rollback process. The rule should already exist.
Some changes can move fast (UI copy, documentation, test scaffolding and low-risk refactoring inside one module). Some need a stop sign (permissions, payments, ledger logic, customer data access, cross-domain dependencies and production infrastructure). If agents are allowed to touch all of these with the same workflow, the organization is driving without lanes.
A Checklist Before You Give Agents More Room
• Do we know our zones? List core domains: payments, risk, identity, billing, compliance, infrastructure. Each needs an owner. If nobody owns a domain, AI will make the ambiguity faster.
• Do we know which boundaries can’t be crossed casually? A change inside one front-end component isn’t the same as one that touches authentication and billing.
• Do our interfaces have written contracts? Schema, owner, compatibility rules, failure behavior, rollback path. If the contract only exists in someone’s head, an agent will eventually break it.
• Do we have paved roads? Standard ways to create services, deploy changes, add observability and roll back. The more output you generate, the more you need standard roads.
• Do we know which changes require a human? This should be written down. Changes involving money, permissions or customer data shouldn’t move through the same lane as a documentation update.
The Rise Of Architecture Stewards
AI makes one type of engineer more important: the person who reduces complexity.
Feature work gets prestige. Cleanup work gets postponed. That model breaks when agents flood the system with output. These engineers are part of the real work.
They watch for duplicated business logic and collapse it into one source of truth. They protect invariants: a ledger stays append-only, a payment stays idempotent, a risk decision stays traceable. When code is cheap to generate, saying “we don’t need this” becomes a senior skill. When reviewers keep catching the same AI-generated problem, they add a check or a boundary that prevents it from repeating.
Every AI-heavy engineering organization needs them. Not as a committee but as a small group of high-context engineers who keep the shape of the system intact while everyone else moves faster.
The CTO’s Job Changes
AI agents don’t understand the whole city. They don’t know which road was built badly five years ago, which bridge can’t handle more load or which shortcut will become tomorrow’s outage.
The highest leverage now is designing the environment where code can be produced safely. Stricter boundaries. Clearer ownership. Better interfaces. Stronger review standards. Faster rollback.
AI will make the city grow faster than ever. The question is whether you’re managing that growth like a city planner or waiting for the first major accident.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
