AI in our development lifecycle

If this is your first time reading about Adyen, here are some facts about us:

• We power all aspects of global money flow: digital payments, in-person-payments, local payment methods, multi-currency money movement, payouts, issuing, embedded finance, and more.

• We processed 1.5+ trillion euros of payments last year. Hundreds of billions of payments worth trillions of euros are stored across our data infrastructure.

• Our identity service holds information on 4+ billion unique shoppers, and sees 200M shoppers daily. Odds are good that we have processed a lot of your payments.

• We own and operate our global footprint of Financial Infrastructure (licenses) and System Infrastructure (regions, availability zones, servers; down to the metal).

This is built by a relatively small team and an incredible amount of thoughtful engineering. It powers the world’s most innovative businesses like Uber, Spotify, Meta, and more.

Most of the code sits in a few large monorepos for backend (Java), frontend (Javascript/Typescript), Data/AI/ML (Python), and infrastructure. We also develop in-person payment devices using C++, Swift, and Kotlin. We have ~57 million lines of code across these repos in total.

Monorepos solve human problems: they break down context silos, expose work early, and force collaboration when multiple people touch the same system. We’ve used monorepos since day 1, and this approach has forced us to solve a lot of scalability and reproducibility problems along the way. To give context on scale, in the last 90 days, our CI infra ran 13 million jobs across 1+ million pipelines, equivalent to 126 years of CI time.

Our setups are generally containers-first for local development, CI, and production. Every monorepo has its own CLI to abstract and simplify that development workflow. And as with anything in engineering, each monorepo has some skeletons that we need to fix modernization opportunities.

The rapid improvement and adoption of AI turned our 20-year bet on monorepos into a strategic win:

• Frameworks that power our systems live in the same repos as the services they’re used in. Documentation lives besides code. This translates into an immediate win for AI context gathering, and helps humans and agents keep code and docs consistent.

• Local CLIs used by humans are used by AI too, and helped with reproducibility.

• Agents can reason across large surfaces of business logic and services. Truth lives in the code, and agents consume this truth. This breaks when you need to cross monorepos (e.g. from backend to data to infra). We haven’t fully solved for that yet.

Embedding AI

We started experimenting with LLMs for code and test generation in 2023, just after Copilot got released. We built Codyen, an IDE extension that assisted with explaining code, writing tests, code reviews, and doc writing, powered by our internal GenAI inference infrastructure. This work was pre-agents, when prompt engineering was popular, and GenAI models were new and nascent.

Briefly after, two major shifts happened: proprietary models started getting much better at code generation, and many AI development tools were released and quickly evolved. Since then, we have switched to using a combination of buy, build, and open-source tooling. We choose and build tools that utilize multiple model providers. This allows our developers to sample the latest and greatest models, as well as catering for personal model preferences.

Today, AI is deeply embedded across the entire engineering lifecycle:

• In the past 90 days alone, AI has edited ~1 million files, and co-authored 20 thousand git commits.

• 50% of AI code review comments are accepted by developers.

• Our ~1,400 developers currently consume ~1 trillion tokens a year. Token usage has quadrupled over the past 3 months. Half of those are spent on top models (e.g. Opus, GPT-5.6), and the other half on cheaper workhorses (e.g. Sonnet, Kimi, GLM).

We have stabilized our token costs by implementing semantic routing, and connected the tooling to our in-house GenAI infrastructure using Bring Your Own Model (BYOM). We’re preparing for a future where we consume 10+ trillion tokens per-year, and performance improvements of open-source models will play a big part in enabling this. Open-source models are getting better and more efficient, and are a common daily driver for our developers. Owning this infrastructure allows us to balance cost and performance to suit our needs. 

Initially, having monorepos made discovering and sharing resources (like skills, subagents, hooks, commands, etc) easy. This helped kickstart and adopt these patterns. Later on, this turned into a pollution problem of too many resources being shared with little governance. This slowed down workflows and wasted tokens. To address this we built an Agent Marketplace, as a single source for all these resources. Anyone can specify these resources in git, and the marketplace materializes them in harness-specific ways for e.g. Factory Droid, Devin, Gemini CLI, etc. The marketplace is aware of the user and their team and role, and can auto-select the resources and defaults of that team. This simplifies team collaboration, and switching between different harnesses.

Wins and impact

AI adoption is effectively 100% across engineering. Merge requests per developer are up 48%. Self-reported time savings, measured via DX surveys, are 15%. Even if we extrapolate from that 15% alone and ignore larger step-change gains, the resulting productivity improvement represents roughly a 2x return on what we spend on tokens. There are also many 10x wins, where work that used to take months or years gets delivered in weeks. 

Stories around code automation (migrations, modularizations, new features, etc) are obvious, so we wanted to share an uncommon example: refactoring critical legacy systems. In one part of our payments backend, we have ~2,000 production jobs for 40+ card schemes, covering the asynchronous parts of the payment flow (captures, reconciliations, scheme-specific reporting, etc). These relied on a single monolithic deployment image that had been a catch-all for too long. The goal was to refactor this massive dependency graph into 40+ scheme-specific deployment images. This would typically require involvement from multiple teams, and represents an expensive investment of 6-12 months with a substantial risk of omission. With AI, a couple of engineers did it in 2 months with no incidents.

Whilst we’ve had a number of  AI wins, customers don’t care if a product was shipped with AI or not. They care about sustainable value delivery, and so do we. The right approach must maximize speed, quality, and security all at once. Today, most industry discussions focus on adoption rate and delivery speed. Specialized security models and AI code reviews offer nice incremental gains, but a critical piece of the puzzle is still missing: the difference between writing code and evolving systems.

Coding != Engineering

A system isn’t good or bad because one function is badly written. Quality is an emergent property of code, architecture and runtime behavior; architectural decisions from every engineer, agent, or request continuously feed into one big puzzle that has to click together perfectly. This challenge affects both humans and AI, but AI amplifies the good and the bad. How do you provide every engineer and agent visibility on the entire system and empower them to make the best decisions possible?

To solve this, we built Architect. Architect combines:

• A code graph, generated from compile-time dependency graphs of our backend monorepo, covering more than 215k classes, 5,600 modules, and 138k dependency edges.

• A realtime service graph, generated from millions of spans per second, tracking the relationship between thousands of services and jobs, and hundreds of databases, via hundreds of thousands of dependency edges.

• An infra graph that captures our entire physical infrastructure with full hierarchical mapping: from regions to availability zones, to racks, to bare-metal hosts and virtual machines.

This captures both the static and runtime versions of reality. It is browsable by humans and AI (via MCP), and you can query each graph separately, or in combination. Architect helps with dead dependency detection, build impact analysis, service topology, and blast radius mapping of services and infrastructural analysis. And this is only the start of what it can do. You can read more about the design of Architect in this blog post.

Rigor and safety

Knowing your architecture is only half the battle though; the other half is changing it safely. Production guardrails for software rollouts are another age-old problem that AI amplifies. Our critical flows cover thousands of combinations of payment acceptance and payout methods, not to mention continuous A/B testing and feature flags. Platform health isn’t measured via HTTP status alone, but interconnected business metrics on conversion rates, fraud rates, payout timeliness, balance correctness, and more.

To get ahead of the accelerating pace of software creation, we’re expanding our already-large investments in rollout strategies and rapid regression detection covering services, feature flags, and ML models. We’re also prioritizing deeper alignment between our staging and production environments to increase consistency across the deployment lifecycle.

Beyond production guardrails, we continue to believe in human–in-the-loop, and human focus remains critical for quality control. More code changes will lead to more context switching and less discussions in code reviews. This is a net increase in risk. Even before AI, review efforts are often not proportional to change risk. A small change could be a typo fix, but could have an unobvious security critical or high blast radius impact. To address this, we’re currently piloting a risk tagging system. It uses AI to evaluate change risk behind every merge request. It tags every request with a classification (low, mid, high, unknown) based on explicit criteria around fault likelihood, critical-flow impact, security, behaviour change, reversibility, rollout safety, and other repository-specific criteria. This informs both authors and reviewers, and helps engineers focus their time and effort.

AI progress will likely stabilize at some point, and while the world will look very different, most companies will have access to a similar set of models and tooling. Top talent will always be the difference maker in energy, culture, and technological innovations. We want Adyen to be a great place for developers to re-invent how they work in this new landscape, so we think long and hard about creating the right environment and incentives for our engineers.

Growing and supporting our engineers

As AI takes over code generation, the definition of the job is fundamentally shifting. Developers of all seniority levels can rapidly generate large volumes of seemingly correct code. This makes engineering intuition much more important, but also harder for junior engineers to develop. We will be using this shift to evolve our mentorship models, focusing our junior engineers much earlier on system design, code evaluation, and architectural decision-making to help them develop their intuition faster. At the same time, many engineers experience growing cognitive load and context debt when heavily orchestrating multiple agents. We’re trying to understand and address that by investing more in streamlined, centralized developer tooling and autonomous agents.

Making the most of AI is itself an acquired skill. We observe within our team today that heavy AI users produce 2x more merge requests than other engineers of the same seniority level. This is a noisy and perhaps distracting proxy metric, but it does suggest that using these tools effectively takes practice and training. To scale this expertise, we formed an AI Champions group of 40 expert users across our organization. They translate general AI capabilities into concrete workflows tailored to their product areas, while closing the feedback loop with our AI-focused developer experience team by surfacing friction. This loop supplements our productivity metrics and helps us understand where operational bottlenecks are shifting.

Beyond supporting individuals, we win and deliver in teams. The gap between individual speed and team speed is becoming much more visible. There’s no single fix; closing this gap requires continuous adaptation. Within our teams, the bottleneck has already shifted from code generation to code reviews, as we see an increase in code review turnaround times and pushback per review. We’ll continue to iterate on our approach to code reviews. We’re also seeing roles evolve organically. In many of our teams, frontend and backend engineering roles are converging (again) into full-stack engineering roles.

Tokenmaxxing and limits

Tokenmaxxing is fundamentally the wrong incentive. Whilst in some ways it drives adoption, it’s another gamifiable metric like lines of codes, and reflects usage not outcomes or value generation. Hard token limits also miss the point. We want everyone to have the space to try things, and increase their use when there’s value.

We practice a balanced view. Tokens are just another resource for a team or an engineer, similar to compute capacity, storage capacity, or even travel spending. We practice a “no blush” policy: there are no pre-defined budgets, but we’re all adults and are accountable for our actions. As long as you don’t blush when explaining your actions, you’re fine.

However we still need to incentivize effective token use, so we landed on a system where everyone has a default token limit, but can request top-ups indefinitely. Top-ups are approved by team leads, as they are best positioned to evaluate the need and support when necessary. These incentives have proved effective to date: we see responsible token usage across the board, and recently doubled default token limits for all developers.

In terms of aggregate usage, we’re a public company with financial planning obligations. We size and purchase tokens in pools that are shared by everyone, and as explained above, we’re planning for 10x growth in usage.

This is a snapshot of our experience and thinking. The journey ahead is uncharted, and is incredibly exciting with lots of pain and opportunity to come. If what we shared here resonates with you, consider joining us! We’re always looking for exceptional talent to help us reinvent our work and our products. Explore our open roles here.