Bank moves team to tiny teams: AI writes 90% of the code, agents take on 20% of tasks

Most teams already use AI, but mostly as smart autocomplete: the engineer writes, the model suggests. The Budget Tool team at a bank, which works on expense management, went further. It rebuilt the process itself around small groups in which each engineer owns the entire result and an agent does the routine work. Tech lead Dima Vdovin described on Habr how it went. The account is candid, with failures and unpleasant side effects included.

The first sprint was a failure, and that was useful

The starting point: two cross-functional feature teams totaling 14 people, with Kotlin and Spring on the backend and TypeScript and React on the frontend. For the pilot, the bank set aside two people, a backend engineer and a QA engineer, and two months. The goal was to close a user story end to end, from analysis to production.

The first small task was not finished two weeks before the production deadline. A lot of time went into working through requirements, but most of it went into the frontend. The team tried to feed Figma mockups to the agent, then endlessly corrected the output based on review comments. Only the frontend engineer and the designer had licenses for Figma Dev Mode and the corresponding MCP. So sometimes it was simpler to just show the agent a screenshot of the finished screen.

Things sped up after that: the cycle got shorter with every sprint. But the problems remained, and all of them are about context:

• Knowledge lives in people's heads. Architectural agreements built up over years, and until they are in the agent's context, it makes mistakes.
• Review slows things down. It is hard for a product engineer to judge code in someone else's area, and code gets written faster than it can be checked.
• It is unclear how to show the agent a design. There needs to be a proper channel from mockup to agent, not a pile of workarounds.

The harness as a product

In this story, the harness is a set of rules, skills, MCP servers, and context that help the agent work in your specific project. The team did not reinvent the wheel and reused what already existed in the bank and the domain.

The main idea is a continuous loop: complete a task with AI, review where the agent stumbled, extend the skills and context, and run it again. Expertise hubs are responsible for this: backend, frontend, QA, and systems analysis. They collect feedback from all the tiny teams, find gaps, and share the best solutions with everyone else.

The team was split into four tiny teams and a discovery hub, where the product owner, the designer, and the business analyst sit. There is deliberately no analyst in the tiny teams: that raises the motivation to use AI. Tasks are sorted by color. Green ones, which are small, go to autonomous agents. Yellow ones, which are larger, are done locally inside the team with AI assistance. Red ones, which are expert-level, require deep expertise and are solved only by combined effort.

Server-side agents and the price of the effect

At first everything was done locally, because it is easier to correct the agent with messages and build up experience that way. But a local agent works only while the laptop is open. The team wants the agent to be one more engineer: you assign a task in the tracker and get back a finished MR.

They started with security. When an AppSec scan finds a vulnerable library or image, the agent creates a task itself, makes the fixes, and prepares an MR. By morning, several ready requests are waiting for review. Now small business tasks are handed off the same way, if it is clear what to change, how, and where.

Results after six months: LLMs write 90% of the code, more than 70% of business tasks are done in AI-assisted mode, and more than 20% are handled by server-side agents. But first the number of closed tasks dropped, and then side effects surfaced:

• cognitive load and burnout risk are growing;
• without knowledge of adjacent areas, you can neither set a task nor check the result;
• review has to be restructured: look at architecture, not syntax;
• analysis and planning remain with the human, who has to make more decisions.

What to take away from this

The authors' advice is down to earth. Start with a repeatable task that has clear acceptance criteria. Use off-the-shelf coding agents rather than writing your own. Debug the workflow locally first and only then move it to a server. Hide everything deterministic in scripts that a skill calls. Write documentation so that people and agents understand it the same way.

The point about eval metrics is especially valuable: without them, it is unclear whether the harness has improved or you are just changing settings. That is why it should be run like a product and honestly recorded as tech debt.

The limitations matter too. This is the experience of one bank team with a well-tuned stack. The figures are internal and have not been verified by anyone, and complex analytical tasks where mistakes are costly are not yet handed to agents. But the conclusion applies broadly: speed comes not from a more powerful model but from how well your team can explain to the agent how things are done in your shop.