Why AI Is Making Quality Assurance More Urgent, Not Less

The quality problem that AI is quietly making worse

There is a version of the AI productivity story that sounds straightforwardly positive: smaller teams can now ship more software, faster, with less capital. And that is true. What gets left out of the story is what happens to quality when the pace of development outstrips the pace of testing.

This is not a theoretical risk. It is already happening. And the people who see it most clearly are the ones who have spent years in industries where the cost of a software failure is immediate, measurable, and sometimes irreversible.

Uldis Tēraudkalns, who we sat down with on a recent episode of the TechEffect podcast, is one of those people. He spent more than a decade building and managing regulated payment infrastructure at NexPay, a fintech company serving the crypto industry, and navigating a sector where a missing payment, a compromised key, or a social engineering attack can translate directly into permanent financial loss. He is now co-founder of OkoRide, a tech-driven ride-hailing fleet operating in Riga, where a three-person founding team is using AI tools to manage operations at a scale that would previously have required a significantly larger headcount.

His experience across both environments—one heavily regulated and high-stakes, one lean and AI-augmented—gives him an unusually clear view of where software quality failures happen and why they keep being deprioritized until they cannot be ignored.

Why QA keeps getting deferred

Most founders understand that quality assurance matters. The problem is not awareness, it is timing.

At NexPay, Tēraudkalns watched the QA investment conversation repeat itself on a reliable cycle: the budget proposal would emerge, get reviewed, and then get pushed to the following year because nothing catastrophic had happened yet.

"In the 2023 budget we're going to be investing into QA and it was like... and then there's like it never comes. And as long as everything is fine, nothing bad happens, then you're like, okay, we're able to handle it on our own."

This pattern is not unique to NexPay. It is structurally predictable in any company where QA costs are visible and immediate while the costs of inadequate QA are invisible until they materialize. The calculation feels rational in the short term and only reveals itself as irrational after something breaks.

What changes that calculation—and what Tēraudkalns now sees clearly—is AI. When developers can ship significantly more code with the same headcount, the volume of untested surface area grows proportionally. More code, more edge cases, more integration points, more opportunities for something to break in a way that nobody checked.

"If we can have a smaller amount of developers pushing out a higher amount of software, then that finally will lead to a place where there's not going to be only room for more professional quality assurance but also bigger need—because a lot more stuff is going to be developed using AI. So there's an additional layer of mistakes that can come out of there."

The implication is direct: AI does not reduce the need for QA. It makes it more urgent. The companies that treat this as still-deferrable are building exposure that will eventually become expensive.

The money interface problem

There is a specific category of software failure that is uniquely damaging in financial products, and it has nothing to do with system architecture or code quality in the abstract. It is the moment a customer cannot account for their money.

Tēraudkalns describes it precisely:

"There is nothing more terrible as somebody making a payment and then the payment is gone. It's not on the recipient's account. It's not on your account. It's not in some kind of transit mode. It's just gone. And then there's somebody getting cold sweats. And it's just a minor glitch on the interface. But for the customers: where's my money? What happened? What did I do wrong?"

This is not a hypothetical. It is one of the most common failure modes in financial software, and its impact is disproportionate to its technical cause. A brief reconciliation error or display bug becomes, from the customer's perspective, a potential loss of their funds. The trust damage that follows is rarely recovered.

The practical standard Tēraudkalns sets is unambiguous: every balance must match, every transaction must be traceable, and every customer-facing interface that involves money must be tested to a higher standard than the rest of the product. Not because regulation requires it—though it often does—but because the cost of getting it wrong is the customer's trust, which is the only asset a financial product is ultimately built on.

This is why his advice to founders building fintech products is consistent: overinvest in the interfaces and user experiences that touch money. The ROI on that investment is not measured in features shipped, it is measured in customers who do not leave.

Social engineering: The attack vector that keeps winning

Ask Tēraudkalns about the most expensive quality failures in the crypto industry and he does not point to architectural vulnerabilities or protocol weaknesses. He points to people.

"Most of these hacks are social engineering hacks. It's not like systems fail. Well, they fail in conjunction with a person being duped or a person being a bad actor. So there's always—mostly always—this human element."

The evidence bears this out. The ByBit hack in 2025, which resulted in more than a billion dollars in stolen crypto, is one of the most visible recent examples. But the pattern repeats across the industry: technically sophisticated organizations, with well-designed systems, compromised through manipulation of the humans who operate those systems.

Tēraudkalns speaks from personal experience. Early at NexPay, his team was defrauded through an impersonation scam—a fake persona constructed to extract value. As a company operating in the crypto space, he spent years under sustained attack across multiple channels. That exposure built a practical understanding of how social engineering works that most founders never develop until it is too late.

His conclusion about what organizations actually need to do is more demanding than most are prepared to accept:

"You need to have inside, like basically fake attacks by your own tech team or something like that—to have people really on alert. And second, you have to also think from the system perspective. You have to find ways how to have these trip wires internally, also for people—if somebody from inside is doing something stupid or doing something bad, you need to be able to detect that."

Passive awareness training is not sufficient. One-time e-learning modules are not sufficient. The social engineering threat requires active, ongoing, adversarial testing of the humans in the organization—the same way penetration testing applies adversarial pressure to the systems.

The AI agent problem

There is a new dimension to this threat that has not yet received the attention it deserves.

As organizations deploy AI agents to handle internal tasks—data processing, scheduling, communication, financial operations—those agents become a new attack surface. And AI systems can be manipulated in ways that human employees, trained to be skeptical, might not be.

"You need to also start thinking about social engineering hacks on AI. Like for example, if you have AI agents in your company doing some kind of tasks—and you know how gullible sometimes AI can be—so it's like you then also need to make sure that somebody is not tricking your AI, some human actually exceeding their intelligence with good old scammer intelligence."

This is not a distant concern. Any organization that has deployed AI agents with access to internal systems, financial data, or customer information needs to be testing those agents against manipulation attempts—the same way it tests human employees. The attack surface has expanded, the testing strategy needs to expand with it.

How AI actually performs under real operating conditions

Tēraudkalns is one of the clearest-eyed practitioners of AI-augmented operations currently building in the Baltic tech scene. OkoRide runs a Tesla fleet with a three-person founding team, no administrative hires, and AI embedded throughout its operations—finance, legal, scheduling, technology, and logistics.

His assessment of what AI can and cannot do is grounded in direct experience rather than marketing copy.

On the productivity side, the results have been genuine:

"We have been able to achieve a shocking amount of things in all areas of the business—be it administrative, finance, legal, technology, operational excellence—and a lot of that has been due to AI in all kinds of forms."

But the limits are equally real. Asked to generate driver schedules from availability data, ChatGPT produced unusable output. Grok performed better but still required manual correction. The task—a constrained optimization problem with clear inputs—was precisely the kind of thing that sounds trivially solvable by AI and turns out not to be.

The broader lesson: AI tools are not uniform in capability, they are not reliable across all task types, and the person operating them needs enough domain knowledge to evaluate the output. Someone who cannot tell whether the schedule AI generated makes operational sense has no way to catch the errors before they cause problems.

"The person who is conscious of AI shortcomings is the one who gets value from it. You need to be able to use a lot more than just a chat-based AI to really extract the value."

This applies directly to software development. Vibe coding—using AI to generate working code quickly—lowers the barrier to building a product. It does not lower the standard for testing it. Code generated with absolute confidence can be absolutely wrong, and the developer who cannot evaluate what the AI produced is shipping unknowns into production.

What the Baltic tech scene gets right

Tēraudkalns has been a close observer of the Baltic startup ecosystem for more than a decade, including through four and a half years hosting the Pursuit of Scrappiness podcast. His view of what makes Baltic founders distinctive is consistent with what he practices himself.

The defining characteristic is operational efficiency under constraint. Baltic founders have historically had access to less capital, smaller local markets, and fewer infrastructure advantages than their counterparts in London or Berlin. The response has been a discipline around doing more with less that functions as a genuine competitive advantage when applied to technology businesses.

"This mindset of doing more with less, I think, has helped a lot. And every second conversation we had with founders, we were actually talking about all kinds of scrappy tactics that actually helped them build their business."

The ecosystem has also matured rapidly. The regulatory and institutional infrastructure that would have been absent ten years ago now exists—crypto licensing frameworks, digital government services, access to EU capital markets—and the quality of life that makes Riga, Tallinn, and Vilnius attractive means that global ambitions no longer require physical relocation.

Tēraudkalns also notes the speed at which Latvia's digital infrastructure has developed. Registering a fleet company, onboarding drivers, managing licensing: processes that would have required days of in-person visits now complete almost entirely online. That infrastructure advantage compounds. Businesses that operate in well-digitized environments spend less time on administration and more time on the work that creates value.

What founders building fintech products should do differently

The advice Tēraudkalns gives to technical founders building in financial services is specific and experience-backed.

First, do not enter the industry without domain experience. Fintech is slow, expensive, and regulation-heavy in ways that catch founders unprepared. Either bring that experience yourself or partner with someone who has it. The mistakes you make without it are not just expensive, they are avoidable.

Second, buy what others have already built better. Fintech companies are, at their core, integration stacks. A payment rails provider, a KYC partner, a banking-as-a-service platform—these are products that specialist companies have spent years building and refining. Trying to replicate them in-house is a distraction from what actually differentiates the business.

"Don't try to build everything yourself. If you have a product feature that needs to be done and for somebody else it's their complete product, chances are they know it better than you do and they're going to do it better than you do."

Third, build for interchangeability. Some of those partners will perform well. Others will become sources of operational pain. If the product is architected around any single integration in a way that makes replacement costly, that dependency becomes a structural risk.

Fourth, treat QA on money interfaces as non-negotiable. Not as a line item to be optimized—as a baseline. The customer experience of a payment disappearing, even temporarily, inflicts reputational damage that cannot be undone by a subsequent fix.

Essentially, AI is increasing the volume of software being shipped and decreasing the scrutiny applied to it—which makes professional quality assurance more valuable than it has ever been, not less. The founders who understand this early will build products that survive contact with real users. The ones who defer it will eventually learn why it should not have been deferred.

→ Listen to the full conversation with Uldis Tēraudkalns on the Tech Effect podcast

Key takeaways

AI raises the floor for getting started and raises the stakes for shipping badly. When a three-person team can produce the output of a much larger one, the volume of untested code grows in proportion. Quality assurance does not become less necessary—it becomes more urgent.

QA investment keeps getting deferred because the cost of inadequate QA is invisible until it materializes. The pattern repeats in company after company: the budget is proposed, nothing bad has happened yet, so it gets pushed. AI accelerates the moment when that calculation becomes wrong.

Social engineering is the dominant attack vector in financial software. Systems do not usually fail in isolation—they fail when a person inside them is manipulated or makes a mistake. One-time training is not sufficient. Organizations need ongoing adversarial testing of both their people and, increasingly, their AI agents.

AI agents are a new social engineering surface that most organizations are not yet testing. If an AI agent has access to internal systems or financial data, it can be manipulated. That manipulation needs to be tested for, just as human vulnerability to phishing is tested for.

Every customer-facing interface that touches money is a trust surface, not just a technical component. A payment that disappears briefly—even due to a minor display error—destroys customer confidence in ways that a subsequent fix cannot fully repair. Overinvest in testing these interfaces.

Buy what others have built better, and own only what differentiates you. Fintech companies that try to build every component in-house build slower and build worse. Treat the stack as integrations, architect for interchangeability, and allocate engineering effort to what actually creates competitive advantage.