AI agents in engineering processes: what it really looks like

AI tools for developers are no longer an experiment. Copilot, Cursor, agent pipelines are all part of everyday work in many teams. But there is a big difference between «we connected AI» and «we changed processes for it».

WhiteBIT, a Ukrainian crypto exchange with an audience of over 8 million users, went through this process and shared the results. Spoiler: throughput tripled. But what’s more interesting is how exactly they did it and where they initially went wrong.

The problem they were solving

Fintech development is not a startup where you can «swish and see.» Every change goes through several layers of verification, and rightly so: the price of a mistake is high.

But there is a nuance: a significant part of engineering time is spent not on complex solutions, but on mechanical work. Creating a branch, configuring an endpoint, adhering to conventions, adding logging, writing basic tests — all this is necessary, but does not require deep expertise. This is the «first draft», which eats up hours before the real work begins.

It was this «tax» that the team wanted to remove — so that engineers would spend their time on things that really require their judgment.

The principle that has not changed

Before talking about tools, let’s talk about the approach. WhiteBIT immediately formulated a rule that they never deviated from: the agent speeds up execution, the person makes the decision.

This means that the AI ​​did not get access to the «hard» parts of the work — architectural decisions, threat analysis, edge case assessment. Instead, the agent took on the first draft of clearly defined tasks: PR with UI changes, API, feature flag, and basic tests.

All existing gates remained in place: individual review, team review, CI/CD, production approval for risky changes.

What has changed in six months?

The team measured the result through DORA metrics — not «how much code was written,» but how much value was delivered and how consistently.

Throughput has tripled. Reliability has not dropped. Change failure rate has remained virtually unchanged, which in the context of ×3 performance is a separate achievement.

Why the first month was difficult

32% of PRs needed rework — that’s a lot. The team analyzed the reasons and found out: most of the problems were not in the model, but in the system around it.

The main ones are: the agent invented APIs and methods that did not exist; unclear specifications led to incorrect UX; the task swelled beyond the scope. Fixing these problems — through stricter requirements for the task description, scope restrictions, and a forced «plan first» step — reduced the rework rate from 32% to 9% in five months.

That is, the main tool for improvement is not a model upgrade, but a better engineering discipline around it.

Conclusion

Clear delegation standards, clear lines of responsibility, traceability, observability, and auditability have turned AI agents into a reliable engineering tool.

This change also shapes the profile of the kind of people the team wants to see in them: developers who combine technical depth, responsibility, decision-making maturity, and a hands-on approach to using AI. If you’re interested in working on products where quality, security, and modern engineering approaches are important, check out Career opportunities at WhiteBIT .

The real value isn’t just speed. It’s the ability to automate mechanical work, reduce cognitive load, and allow developers to focus on solutions that really matter—while maintaining the same level of security for products that create real value.