An ISO/IEC27001:2013 and ISO 27018:2019 certified cloud solution
80 Key Customer Loyalty Stats & Trends to Watch in 2026 | Perx
Blogs
We Don't Trust AI to Write Our Code Alone. That's Why It's Working.
IN BRIEF
- Our time-to-QA is down 7.26x, and time-to-market is down 5.95x. That matters more than the raw numbers suggest: a 2026 benchmark across 60+ enterprises found AI-assisted pull requests sitting in review 4.6x longer than human-written ones, not shorter. We’re moving in the opposite direction from most of the industry.
- Every AI-written change is checked twice before a human ever sees it. Once by a second, independent AI system, and again by a panel of five different models on anything high-risk.
- We built our own internal AI development platform instead of just subscribing to someone else’s.
- Our cloud infrastructure bill fell 60% year over year, and none of our clients felt a thing while we modernised underneath them.
- 200+ product features have shipped through this pipeline since December 2025.
I lead the Performance & Scale Team at Perx Technologies, and one question comes up in almost every technical due-diligence call we sit through: how much do you actually trust the AI writing your code?
A year and a half ago, if you’d asked how much we trusted AI to write our code, I’d have said: not much. Ask me today, and I’ll give you the same answer. What changed isn’t how much we trust the AI. It’s that we stopped needing to. We built a system that checks its work for us, every time, before it ever reaches production.
That’s the part most companies leave out of their AI story. Everyone wants to tell you how much faster they are now. Almost nobody wants to tell you what they had to build first to make that speed safe.
Is AI-generated code actually safe for something this sensitive?
Not automatically, and the industry’s own numbers say so.
McKinsey’s original research on AI coding tools found real gains: documentation time cut nearly in half, and new code written in close to the same margin, though the gains shrank to single digits on the hardest, most complex tasks. A follow-up study of more than 600 organisations found most teams landing around a 25 percent productivity improvement, and only the teams at near-full adoption clearing 100 percent. Useful, but a long way from the ten-times figures that show up in vendor decks.
A 2026 benchmark spanning more than 250,000 developers across over 60 enterprises found something sharper: pull requests built with AI assistance were sitting in review queues 4.6 times longer than ones written by hand, and shipping with 15 to 18 percent more security vulnerabilities. Teams were producing more code and trusting it less.
That’s the gap we didn’t want to fall into. We weren’t interested in being another company that talks about the upside and hopes nobody asks about the downside. So before we let AI touch anything that mattered, we built the downside protection first.
What we built before we let AI near anything that matters
Here’s the rule everything else follows from: no AI system grades its own work. Every layer below exists to enforce that one rule.
- Separated roles. 27 specialised AI processes, each restricted to a single job such as writing code, reviewing it, or testing it, so the system that writes a fix is never the one that approves it.
- A shared playbook. 42 pre-built command sequences cover the full development lifecycle, from planning a feature through to shipping it, so the process doesn’t live in any one engineer’s head.
- Adversarial review. Every AI-written change is checked by a second, independent AI system before a human reviewer sees it. Anything high-risk goes through an additional panel of five different AI models.
- Guardrail checks. 20 automatic checks block a change outright if it matches a known failure pattern, such as a hard-coded password or a database query missing a required security filter, before it can be merged.
- A shared memory of mistakes. Every error the system makes gets fed back in, so the same mistake doesn’t recur somewhere else in the codebase.
- A dedicated QA layer. 15 testing routines, backed by 15 reusable descriptions of how each part of our product behaves, and a 27-file internal knowledge base of testing conventions.
None of this exists for our comfort. It exists so that when a client’s technical due-diligence team asks how we build software, the honest answer is a system built the way a regulated institution would build it themselves.
What it's actually delivered
We measure two specific stages of our delivery pipeline. Time-to-QA is the average time between a feature being marked ready and entering formal testing. Time-to-market is the average time between QA sign-off and release. Comparing our current pipeline to our own pre-AI baseline:
- Time-to-QA: down 7.26x.
- Time-to-market: down 5.95x.
- 200+ features shipped through the pipeline since it went live in December 2025.
- Average response time across the platform improved by roughly 10 percent.
The clearest proof of what this system actually does showed up almost by accident. One of our engineers took on a project in Go, a language they had never written a single line of before. Normally that’s a multi-month ramp-up before someone touches production. Instead, the same review layers that catch a senior engineer’s mistakes caught a first-timer’s too, and caught them fast enough that the work shipped anyway: a production-grade service now handling 4,000 requests per second on a single server instance. The point was never that Go got easier. It’s that the guardrails don’t care how many years of experience wrote the code. They check the work, not the resume.
Built by us, for us: what is Copperfield?
A lot of companies are currently buying an AI coding assistant and calling it their AI strategy. We took a different route. We built our own internal AI development platform, nicknamed Copperfield, shaped around how our team actually works, not around a generic workflow someone else designed.
Copperfield connects into the systems we already rely on, rather than sitting apart from them:
- Ticketing integration. It connects to our project-tracking system to auto-create support tickets and answer flagged questions.
- Governed execution. Agent work runs in an isolated, temporary cloud workspace, separate from our live product, with automatic cost tracking and a fixed expiry time, rather than anywhere near production by default.
- Feature-request drafting. It takes a product manager’s rough brief, flags gaps, asks clarifying questions, and drafts a properly scoped request before a single line of code gets written.
- Support and root-cause investigation. A dedicated agent, connected to production data on a read-only basis, can investigate a live incident, trace it back to what actually caused it, and propose a fix for a human to review. It never applies anything directly.
That’s the difference between using AI and building with it. Buying a coding assistant is a subscription decision. Building your own platform, integrated into your own systems and shaped around your own team, is an investment that keeps paying out.
What our infrastructure work actually means for you
We didn’t bolt AI onto an ageing stack and call it a transformation. Underneath the pipeline, we spent the same period bringing our core infrastructure fully current, and we did it without a single client noticing. That silence is the whole point.
- No surprise downtime. We retired every system running on software past its support window before it became a liability, not after.
- Security patches on our schedule, not scrambled in after an incident. Staying current means we’re rarely reacting to a vulnerability everyone already knows about.
- Fixes reach you the same day, not weeks later. Our deployment process now runs in a fraction of the time it used to, so a fix we make this morning can be live in your environment by the afternoon.
- Lower costs, not passed on to you. Our infrastructure bill fell 60% year over year. That’s headroom we reinvest in the platform, not a line item we bill you for later.
What this means if you're evaluating us as a vendor
None of this shows up in a product demo. But it’s exactly what a technical due-diligence team is trained to look for before recommending a multi-year infrastructure decision: current, supported software, fixes that ship fast, and AI-assisted development treated as something to be governed, not just adopted.
When we tell a client that a feature will ship within a sprint, this is the machinery that makes that a promise we can actually keep, not a hope.
FAQs:
What does "AI-assisted engineering" mean at Perx?
It means AI systems draft, review, and test code under a governed process, with defined checkpoints and guardrails, and a human always signs off before anything reaches production. It does not mean AI operates unsupervised.
Do you let AI deploy code without a human reviewing it?
No. Every AI-written change passes through independent AI review first, and high-risk changes go through a five-model panel, but a human engineer is always the final approval before release.
How much faster are you shipping features since introducing this pipeline?
Average time-to-QA is down 7.26x and average time-to-market is down 5.95x, both measured against our own pre-AI engineering baseline.
What is Copperfield?
Copperfield is the AI development-lifecycle platform we built in-house, covering ticketing integration, governed sandboxed execution, feature-request drafting, and production support and root-cause investigation.
Is this relevant if I'm evaluating you as a vendor?
Yes. It reflects the engineering governance and infrastructure currency that a technical due-diligence review typically checks for before an enterprise commits to a platform.
Recommended for you
An ISO/IEC27001:2013 and ISO 27018:2019 certified cloud solution
SAY HELLO
Perx Technologies Pte Ltd
20A Tanjong Pagar Road
Singapore 088443
An ISO/IEC27001:2013 and ISO 27018:2019 compliant cloud solution
An ISO/IEC27001:2013 and ISO 27018:2019 certified cloud solution