FNG Exclusive Interview… As fintech firms race to adopt AI, most are still bolting it onto existing engineering workflows. Deriv is taking a different approach, rebuilding its software development pipeline from the ground up with AI at the centre. FNG spoke with Raunak Kathuria, VP of Engineering at Deriv, about what that looks like in practice and where Deriv’s engineering team is heading.

FNG: Hi Raunak, and thanks for joining us today. Deriv talks a lot about being an AI-first organisation. On the engineering side, what does that actually mean day to day?

Raunak: For our engineering team in an AI-first organisation, it means fundamentally changing the relationship between engineers and the work itself. In a traditional development cycle, engineers are the primary executors of every step. That creates bottlenecks at every handoff, code reviews, testing, documentation, and deployment. The speed of the whole system becomes limited by human bandwidth.

What we have done is shift engineers into a directing role. They define the intent, set the standards, and evaluate the output. The pipeline handles the execution. That is a meaningful change in how an engineering organisation operates, and it requires getting the foundations right before it works reliably at scale.

FNG: Standardising AI output across a large engineering organisation is easier said than done. How does Deriv approach that in practice?

Raunak: The key is separating what needs to be consistent from what can be flexible. We built a framework that provides every team with the same steering documents, best practices, and quality gates, all baked into the repository from the start. AI reads those documents and codes against them, so the standards travel with the work rather than depending on individual engineers to remember them.

The other piece is understanding that AI is non-deterministic by nature. This is actually useful for discovery and surfacing problems, but your pipeline still needs to be deterministic. Tests, deployment gates, and CI/CD have to produce the same output every time, or you cannot trust them. Getting those two things working together is where most of the engineering effort went.

FNG: Can you point to a specific instance where this has worked as intended?

Raunak: One example that stands out is a service error our QA agent detected in Sri Lanka during off-hours. The agent identified the issue, logged a ticket with full context and screenshots, and generated the tests needed to catch that class of problem permanently in the pipeline. No one was paged. No one had to pick it up the next morning and work backwards to understand what happened.

For a platform operating continuously across multiple regions and time zones, the ability to detect, document, and resolve issues without human intervention at every step is operationally significant.

FNG: Where does human judgment remain essential in this model?

Raunak: Architecture and strategic trade-offs. Deciding between competing technical approaches, determining what not to build, and understanding whether a solution that works in isolation will hold up at scale. Those decisions still require experienced engineering leadership, and they probably always will.

The other area is output quality. Engineers need a strong enough grasp of fundamentals to evaluate what the AI produces, not just accept it. We are quite deliberate about this internally. You know what separates engineers who use AI well from those who simply generate more output? Understanding why a decision was made.

FNG: What difference has this made to delivery?

Raunak: Teams can move from intent to production without the traditional dependencies on separate QA or infrastructure functions. That removes a significant amount of coordination overhead that used to slow everything down.

The less visible impact is on consistency. Standardising how code is written and tested across a large engineering organisation reduces the variation that accumulates into technical debt over time. That is harder to quantify in the short term, but the compounding effect is substantial.

FNG: What are the next priorities on Deriv’s engineering roadmap?

Raunak: The next step is closing the final gap in the lifecycle: deployment. Today, a developer can go from feature idea to tested, reviewed code with AI handling most of the heavy lifting. The roadmap makes the last mile, shipping that code to production, just as automatic. The goal is a world where a developer describes what they want to build, and the system handles everything from writing the code to deploying it live, without anyone touching infrastructure manually.

On the testing side, the ambition is for QAClaw to trigger automatically on every new release, not just nightly, but the moment anything ships. Combined with real-time crash detection feeding back into the testing loop, the system would catch and flag issues before most users ever encounter them.

The goal is a development lifecycle where intent becomes production without ceremony. Skill is the new programming language, and the engineer’s job is to direct, not execute.

FNG: What is the key takeaway for engineering teams looking at what Deriv has built here?

Raunak: Skill is the new programming language. The quality of what you get out of AI depends entirely on the quality of what you put in. The engineering principles, the guardrails, and the standards you define are what determine whether the output is consistent and trustworthy or not. Teams that get these foundations right will pull ahead. Teams that skip that work will just produce inconsistent output at a greater speed.