David Heinemeier Hansson (DHH) — one of the most influential voices in software development, a self-described AI holdout until late last year — now takes an agent-first approach to everything at 37signals. He barely writes code by hand. He reviewed 100 pull requests in 90 minutes using Claude. He describes it as stepping into a "super mech suit." Google reports 75% of its new code is AI-generated. Anthropic says 70–90%. OpenAI's president puts the figure at 80%.
Those are the headlines. Here's our honest position: at Cymonz, we're being deliberate. We're a payments platform operating in a regulated environment — we don't move fast and break things. Some of our developers have leaned in and are seeing real results. Others are still evaluating. We're adopting carefully, but we're paying close attention to where this is heading.
There's a version of the AI story that goes like this: AI writes the code, developers become optional, and the speed of software delivery becomes limited only by how fast you can type prompts. I don't believe that story. And I think the evidence from building payments infrastructure — one of the more regulated, consequence-heavy environments in software — supports a different conclusion.
The productivity gains are real
The developers on our team who have adopted AI tooling are noticeably faster at certain categories of work — scaffolding, test coverage, exploring unfamiliar code, drafting documentation. For a lean team building a payments platform that competes with much larger organisations, even modest gains in velocity matter.
GitHub Copilot, Claude and similar tools have become part of how our engineers work. Not because we were told to use them — but because they genuinely accelerate certain categories of work. The productivity argument is real.
But what's more interesting than the speed is what DHH calls the "great bifurcation." His observation — now backed by data from Amazon and others — is that AI tooling disproportionately benefits experienced developers. Seniors who understand the architecture, the domain, the regulatory context can direct AI like a force multiplier. They know what good looks like, so they can evaluate what comes back. Juniors without that foundation can produce more code, faster — but without the judgment to know whether it's actually right. In payments infrastructure, "actually right" is the whole game.
But the judgment hasn't been automated
There are prominent voices in tech predicting that traditional programming will effectively end within the next year or two. That's a bold call, and I think the timeline is aggressive — but the direction isn't wrong. The constraint is shifting. It's less about the ability to produce code and more about knowing what to build and whether what was built is correct.
The developer's role in a regulated payments environment is not just to produce working code. It is to understand the system well enough to know what 'working' actually means in context — across jurisdictions, across regulatory regimes, across the edge cases that only emerge when real money is moving for real people.
In our world — cross-border payments, multi-jurisdictional compliance, settlement logic, AML obligations — the consequences of getting things wrong are severe and often delayed. A compliance gap doesn't announce itself at the moment it's introduced. A settlement logic error can propagate through hundreds of transactions before it surfaces. A security vulnerability in an API integration can sit dormant for months.
AI doesn't know what it doesn't know. It can generate code that passes tests but fails in production. It can suggest patterns that are technically valid but architecturally unsound for a given context. The developer's job — increasingly — is to be the person who knows the difference.
What this means for how we hire and build
At Cymonz, we've thought carefully about what this shift means for our engineering team. We're not looking for developers who resist AI tooling — that's not a useful posture in 2026. But we are looking for developers who understand that their value lies in judgment, not in the ability to produce syntax quickly.
That means deep understanding of the domain — payments, compliance, settlement, regulatory architecture. It means the ability to review AI-generated code with genuine critical evaluation rather than surface-level acceptance. And it means the kind of professional rigour that comes from understanding that the systems you build have consequences.
The honest view from inside a payments platform
We're not going to be late to this. The signal from the industry is too strong and the potential too significant to treat AI tooling as optional. Our plan is to invest deliberately — equipping the team with the right tools, building internal knowledge around what works, and creating space for our engineers to experiment.
But we're also not going to pretend we're further along than we are. The honest truth is that we're a fintech in a regulated environment, building on a codebase with real complexity, and the path to AI-augmented development looks different for us than it does for a greenfield SaaS product.
What I do believe — and what DHH's experience reinforces — is that the developers who will thrive are the ones who combine deep domain knowledge with a willingness to adopt these tools. The "super mech suit" metaphor is apt: the suit amplifies whatever you bring to it. Bring expertise, judgment and an understanding of payments infrastructure, and you get a force multiplier. Bring nothing, and you get fast-moving code that nobody can vouch for.
That's the bet we're making: invest in AI adoption, but anchor it in the domain expertise and professional rigour that payments demands. We're early. We're watching closely. And we're increasingly confident this is the most significant shift in how software gets built that any of us have seen.
AI has made our team faster. It has not made our decisions easier, our architecture simpler, or our regulatory environment more forgiving. The developer who thrives in this environment is the one who uses AI as a force multiplier on their own expertise — not as a substitute for it.
That's the story I think is actually playing out. And it's a more interesting one than 'developers are becoming optional.'