At Itaú, a security scanner can trigger an agent to prepare a repair for an engineer to review. That is one of several ways the bank is weaving Devin into ongoing software maintenance. A vendor-hosted account featuring its technology leaders reports adoption by 75% of teams. The interesting story is how agents enter the existing work, not just how many people have access.
Agents enter an existing delivery process
The Itaú customer account describes Devin responding to security-scanner findings inside CI/CD, the automated pipeline that checks proposed software changes. Engineers review repairs. They also review tests generated from their playbooks.
The account reports several different kinds of scale:
| Reported measure | What it counts |
|---|---|
| 75% of teams use Devin | Organizational adoption |
| More than 300,000 repositories documented | Codebase coverage |
| About 70% of named scanners' findings resolved automatically | A reported maintenance outcome, with engineer review |
| 59 .NET services consolidated into nine Java services | One migration's scope |
The page is undated and does not give complete measurement windows. It describes universal first-pass PR review as forthcoming. These details constrain any claim about the bank's current operating system.
A large codebase changes the product question
The managerial question is how to make work repeatable across teams that maintain different services. A migration request needs a destination, a responsible owner, and a way to check behavior. A security finding needs enough context to locate and repair the defect. Both need a result that the receiving engineer can evaluate.
SWFT's interpretation is that a useful factory makes those handoffs explicit. Start with a queue whose items share an acceptance rule. For example, a framework upgrade can require the target version, a passing build, and agreed behavior checks. If the next item needs different permissions or a different reviewer, record that difference before dispatching it.
Company-wide access is a different operating achievement from that repeatable task flow. A team can use an agent frequently while still spending considerable time recovering context, correcting output, or waiting for review. Adoption alone cannot settle whether the workflow improved delivery.
Read each number with its denominator
Ask what entered the measured group and what was left out. For a repair rate, that means the eligible findings, duplicates, failed attempts, manual corrections, and accepted patches. For a migration, ask whether the comparison includes testing, deployment, and cleanup. For a usage percentage, ask what activity makes a team count as a user.
These are requests for a measurement method, not reasons to discard a reported result. They let another organization decide whether its own backlog resembles the reported work closely enough to attempt a pilot.
The missing number for a swarm comparison is concurrency: how many agents were active together on one defined objective. Repository coverage and team adoption cannot be converted into it. A useful run record would include the task, active workers over time, elapsed duration, accepted output, cost, and human review effort.
Itaú is a relevant operating case in SWFT's financial-services coverage. Its public account supports further investigation of repeated agent work inside a bank; it supplies no basis for a numerical ranking of the largest coordinated swarms.