70% of our new code is now AI-generated. Here's what that actually means.

More than 70% of the new code we ship is generated by AI under human oversight. Here's the honest story of what that number means, and the governance we built before we let it grow.

Written byRaquel HernándezVP of Engineering, Clara

Raquel is an engineering executive with nearly two decades of experience building and scaling technology teams, with a focus on AI transformation initiatives and developing high-performance organizations. She believes in building teams that combine technical excellence with strong product thinking.

LinkedIn ↗
Concentric indigo rings over a light gradient background

Engineering @ Clara · Series #1

A year ago we made a bet: AI wasn’t a productivity feature to bolt onto the engineering org. It was a fundamental rethink of how software gets built. This is what we’ve learned so far.

More than 70% of the new code we ship is generated by AI under human oversight.

That number reflects our full codebase, including legacy systems where AI plays a supporting role. For greenfield features and new products, the figure runs closer to 90%. Clara Global is the clearest example: a three-person team built a full expense reimbursement platform covering 210+ countries and 180+ currencies in weeks, not years, with AI generating the overwhelming majority of the code. We announced it at Web Summit Rio.

I want to be honest about what that number means and what it doesn’t. It’s not a headline we’re chasing. It’s a byproduct of engineers genuinely changing how they work. The real signal is that nobody on our team asks “should I use AI for this?” anymore. They ask “what’s the right way to use AI for this?”

That shift, from opt-in experiment to default workflow, is the one worth talking about.

Building financial infrastructure changes how you adopt AI

Clara builds financial infrastructure. That changes everything about how you approach AI.

We run corporate cards, bill payments, and expense management across Mexico, Brazil, and Colombia. Our engineers build systems that sit inside treasury workflows, touch payment rails, and handle sensitive financial data across multiple regulatory environments, including PCI DSS, ISO 27001, and country-specific compliance frameworks in each market.

Speed in our context isn’t just about shipping features. It’s about shipping features that are secure, auditable, and compliant. We can’t trade one for the other.

That’s why we built the governance infrastructure first. Tools first, guardrails later is a pattern we’ve seen go wrong at companies at our stage, and we weren’t willing to clean that up.

What we actually built

Phase 1: Access for everyone, no exceptions

The first thing we did was make sure every engineer had access to serious AI tooling. Not a pilot group, not senior engineers only. Everyone. We went from GitHub Copilot, to Cursor, to where we are today: Claude Code and Codex as our primary coding environments. We have 100% adoption across the engineering organization.

Phase 2: The platform layer, not just the tools

Giving engineers AI tools is table stakes. The harder problem is making AI understand Clara: our systems, our codebases, our context. We’ve been building the internal infrastructure that lets AI access organizational knowledge securely, including knowledge bases, internal developer tooling, workflow automation, and an internal platform that lets anyone at Clara, technical or not, build and ship working apps and prototypes without touching servers, pipelines, or security configuration.

We also built Clara Watchtower, an internal visibility platform that brings adoption, cost, and usage patterns into one place. Mostly it answers a question we couldn’t answer cleanly before: how much of what we ship is actually AI-generated, and where. Before Watchtower, we were mostly guessing at the workflow level.

It’s also what gives us confidence in the 70% figure.

Watchtower pulls from several independent sources across our internal tooling and cross-checks them against each other, so every number on the dashboard maps to real teams and real work instead of a raw usage count. We keep the underlying source data intact, which means any figure can be traced back and audited instead of taken on faith.

That’s why the number is specific: it’s AI-generated code an engineer accepted and that was then committed and shipped. If it didn’t ship, it doesn’t count.

Phase 3: Governance that doesn’t kill velocity

This is the part that rarely gets written about, because access controls are less exciting to talk about than AI agents. But for a company operating in regulated markets at our scale, it’s arguably the most important work.

We run continuous model evaluation, data handling reviews, and cost governance. We treat AI the way we’d treat any other critical vendor in our stack: with real due diligence, not just enthusiasm.

How we think about AI risk

Getting to 70% wasn’t the hard part. Keeping it responsible is the ongoing one. A few risks stay on our radar, and the two that shape our decisions most are the ones tied to where and how Clara operates.

The first is cost. There’s a myth that AI spend is inherently unpredictable, but in our experience it’s more manageable than people assume, once you stop treating every task as if it needs the most powerful model. We route work to the right model for the job, cache repetitive workloads, and track cost at the workflow level rather than in aggregate. That last part matters more for us than for most, because we operate across three markets with different cost structures, and an aggregate number hides that.

The second is concentration. A lot of engineering orgs have AI tooling that looks diverse but quietly depends on a single model provider or cloud layer underneath. We’re deliberate about what our options are if a provider changes terms, pricing, or availability, and about how portable our workflows actually are. Operating across Mexico, Brazil, and Colombia adds a layer most companies don’t have to think about: data residency, local availability, and regulatory expectations aren’t identical in each market, so “just switch providers” is never as simple as it sounds.

Underneath both is a principle we keep coming back to. Access to foundation models is becoming a commodity, so the real advantage isn’t the model. It’s what we do with our own transaction data and workflow context, and whether we govern the privacy, security, and lineage questions well enough to keep that advantage. That’s the work we’re most focused on now.

Where we are, honestly

More than 70% is a number we’re proud of, and one we intend to keep pushing. Not because there’s a magic number we’re chasing, but because every percentage point represents engineers spending less time on work that doesn’t require human judgment, and more time on the problems that actually do. The higher that number goes, the more we compress cycle times, reduce toil, and let our teams focus on what matters: building better financial products for our customers across Latin America.

We don’t have all the answers yet. But we have enough hard-won experience that it’s worth sharing, which is why we’re starting this series.

If this is the kind of environment where you want to do your best engineering work, we’re hiring. See open roles →