As part of a software team in a fintech company, we were given a task that sounded simple on paper and heavy in reality: modernize a set of software components, fix a backlog of known bugs, and bring the whole thing to a state where it could be placed into maintenance mode.
This wasn’t a greenfield refactor. It was the kind of code that still ran real transactions and had to keep doing so with predictable behavior. The team was small, and “add a few people for a quarter” was not on the table.
The problems weren’t mysterious. They were the classic ones that accumulate in long-lived fintech systems:
Traditionally, we would have expected this to be staffed like a small development program: multiple developers, an architect, a tester who drives coverage and quality, and a product owner to manage scope and priorities. Instead, it was a small team problem that still needed “team-sized” output.
We started using AI early. First in the obvious way: Copilot and Claude as helpers—answering questions, drafting small snippets, accelerating routine tasks.
But as the tooling matured, we moved from “asking” to orchestrating.
We defined a set of AI agents with agent-specific instructions and a workflow, so each developer could operate with a practical “virtual team.” The goal wasn't a novelty. The goal was to reduce the amount of time spent on low-leverage typing, while increasing consistency and quality.
If you give an agent generic instructions, you get generic output—wrong abstractions, wrong conventions, and “almost right” fixes that cost more to review than they saved.
We solved that by investing early in project-specific instructions:
This gave agents the equivalent of “team context” from day one.
The second risk is speed without coherence: changes that compile but don’t fit the system’s intent.
We tackled that by separating design thinking from implementation throughput:
In practice, the Architect agent acted like the “steady hand” that prevents a modernization project from turning into a pile of clever patches.
A big part of “maintenance readiness” is not modern syntax. It’s confidence. We treated testing as behavior documentation and safety rails, using BDD/TDD thinking:
AI agents are genuinely strong at unit tests when you give them the right inputs: the use cases, the constraints, and the requirement that they must think through edge cases instead of only happy paths. With a dedicated test agent, “tests included” stopped being a best intention and became a default output.
We also addressed a quieter problem: AI sessions don’t naturally build long-lived continuity.
So agents were instructed to:
That way, when a new session started—or when a new agent continued earlier work—it could read the documentation and diaries and quickly understand:
This reduced repetition and kept the modernization coherent across time.
The net effect was that a small team could deliver like a larger one:
One practical takeaway: writing code by hand is expensive—especially in consulting. It consumes the same mental energy you need for correct behavior, edge cases, error handling, and observability. Under time pressure, those are exactly the things humans tend to under-deliver.
With a well-instructed agent workflow, the developer’s role becomes higher leverage:
If two developers start with similar skill, the one who can operate a reliable “virtual agent team” will almost always look more effective to a customer: faster solutions, more consistent quality, fewer missing edge cases, and better overall predictability.