“Should we build this?" — Thredd's CTO shapes an AI-native culture without losing control

Marilyn McDonald, Thredd’s CTO, has reframed the central engineering question from "how do we build this?" to "should we build this at all?"

Her practices keep humans accountable for final decisions, replace compliance bottlenecks with pre-approved AI workflows, and make legal and compliance teams an active part of product design from day one.

How Thredd governs AI without losing engineering speed

If you're building an AI-native engineering culture in a regulated environment, you're solving problems most engineering playbooks don't cover.

Marilyn McDonald has worked through accountability structures, pre-approved AI workflows, compliance governance, and regulatory readiness at Thredd, a payments infrastructure company empowering 100+ fintechs worldwide.

Read on and you'll have a clear picture of where humans must stay in charge, and what to get right from day one.

What you'll learn

About Marilyn & Thredd

The culture shift at Thredd

Michał Szehidewicz: You've led engineering teams through a lot of change in payments infrastructure, and now you're doing it again with AI.

What about reshaping Thredd’s IT around AI are you most proud of?

The people.

People come together to use tools to create software to solve problems. That is still true.

They're opinionated, willing to debate, and willing to expand their current norms when the evidence calls for it.

Some things are certainties for them, but rigidity isn't one of them.

They're ruthlessly focused on the things that really matter, which is serving our customers.

Customers and the problems customers actually have are what this team stays focused on.

In an environment where the tools are changing fast, that focus is what keeps the work grounded.

You said that design reviews now matter more than code reviews, and that judgment matters more than producing lines of code.

What else changes when your engineering culture shifts from measuring output to measuring judgment?

The fundamental conversation shifts.

Engineering teams used to spend most of their time asking "how do we build this and how long does it take?"

Those questions become less important.

Judgment matters to me more than volume of output.

So, we spend more time evaluating whether we should do something than building it.

If judgment matters more than framework mastery, what does a strong engineer actually look like now compared to 3 years ago?

A strong engineer from a few years ago is still a strong engineer.

Engineers are problem solvers by nature, and that doesn't change.

If you were writing code to solve a human's problem 3 years ago, you're still a good hire.

What shifted is which skills matter most.

System design instincts, comfort with ambiguity, and speed of learning are the most important right now.

The reason those matter is that AI can be convincingly wrong.

If you review something at the highest level, it looks credible.

What matters now is whether you can apply critical judgment to the parts of your job that AI is replacing and catch when the output is wrong.

We dial up on critical thinking and the ability to detect things that look plausible but are wrong, and dial down on framework mastery and memorized algorithms.

ㅤ

Hiring and governance for an AI-native team

So, senior engineers can catch AI errors because they've built systems from scratch and they know what right looks like.

Are you worried the next generation will review AI output before they've ever had to build anything from scratch?

Senior engineers can catch AI errors because they've mastered the fundamentals. 

They know what right looks like before the machine tells them.ams

Eventually all the senior engineers are going to retire or step out of the field.

Building that pipeline means finding ways to put junior engineers in situations where they exercise judgment and learn through doing and not just by reviewing output.

I don't think the engineering industry has worked out what that looks like yet.

Let's discuss how you lead AI adoption at Thredd.

Thredd is processing payments across more than a hundred fintechs and digital banks, with real money and real regulatory scrutiny.

What are the non-negotiables your engineering team follows when AI touches any of those flows?

We focus on provenance: where did this information come from, and what did the model use to generate its output.

The accountability for any change has to sit with a person rather than a machine.

Alongside the accountability, there has to be an audit trail.

If a regulator asks us to show evidence for a decision, we need to trace back through the system and show how we got there.

Beyond the audit trail, data boundaries are defined upfront, meaning no cardholder data in dev/test environments, or no cardholder data in our AI tooling.

Everything must have deterministic verification through tests, controls, and analysis.

Compliance verification runs through the code rather than through a manual process.

Those governance rules sound thorough. But I want to challenge their efficiency.

AI tooling moves fast, and compliance teams are not known for moving fast. 

How do you avoid getting a tool stuck in a months-long review?

Thredd uses pre-approved workflows called paved paths.

A paved path is a pre-approved flow within established boundaries.

Compliance moves slowly by nature.

A governing body issues something vaguely worded, your legal team reviews it, determines how the company implements that guidance, you build the controls, and then you show compliance against the policy.

Pre-approving standard flows lets your compliance and regulatory people focus on novel use cases, which do take time and should take time.

Standardize what can be standardized.

Get those flows pre-approved and show how you're maintaining compliance through deterministic verification.

Compliance as a foundation for product design

Most engineering leaders I talk to treat compliance as a bottleneck they work around.

You're describing the opposite. What are they doing wrong?

The compliance team is an enabler when you bring them into the design process from the beginning.

If they help set guardrails upfront, understand the digital exhaust that your systems produce, and understand what verification looks like before anything ships, they're far more likely to move with you than against you.

At that point, they have to go through everything because they've had no visibility into how you got there.

Bring the compliance team in early and let them design the guardrails with you.

You said that a human has to own accountability regardless of who drafted the code.

When does that actually become a hard line for you?

A human has to be accountable for any change in production for a regulated flow.

Machines can generate most of the output and give the human all the information they need, but at the end of the day a human pushes the button.

During a live incident command, when real customers have real money moving and something is wrong, you need a human making judgment calls under pressure with incomplete information.

Are there functions at Thredd where AI simply doesn't get to touch the output?

Regulatory attestation is another area where a human must stay in the loop.

Machines can generate the evidence, but someone from inside the firm has to sign off on the regulatory controls.

Where there's accountability, there has to be a person.

Accountability is one thing you cannot hand off to a machine. At least not yet.

AI errors and the build vs buy decision

You said that you'd distrust anyone who claimed AI has never misled them.

Has AI ever produced something at Thredd that looked right but wasn't?

I've only been at Thredd for about 4 months, so I'm speaking more as an industry observation than a Thredd-specific incident log.

And, I'd distrust anyone who said they'd never been in that situation.

AI is still learning and makes bad calls sometimes.

What matters is the guardrails you put in place to catch those moments.

When you need new governance tooling quickly, does your team build it in-house or do you bring in outside help?

I rely on both, and any CTO who says they never use external vendors either works somewhere I've never worked or isn't being straight with you.

The question is what you delegate to them and what stays internal.

Accountability-critical work stays primarily in-house.

A tool or control built for a regulator needs to be owned by someone inside the firm.

What stays internal and what do you bring in from the outside?

You can surround that core with external vendors to accelerate delivery, but the named individual accountable for the output has to sit inside your organization.

My preference for the ratio of employees to contractors is roughly 70% to 30% as a baseline, with room to stretch that ratio in an emergency.

The caveat is that senior external partners who've been with the firm for 15 years aren't external anymore in any meaningful sense.

Skeptics, regulation, and who owns readiness

How do you deal with senior engineers who've seen too many technology waves to trust the AI one?

I stopped thinking of skeptics as people to convert.

Several years ago, I started calling them Guardians of the Past instead.

They're senior people who've seen the company grow, know the systems when they were small, and care deeply about protecting what's been built.

Their skepticism isn't bad faith.

A loyal employee doesn't want to see the company fail. 

They came to work to do a good job without some malicious goal to resist change.

Their deep care is exactly what makes them useful. 

So, I give them a seat at the table.

Most AI-wary seniors that I've worked with become effective in that role.

They help write your guardrails on day one.

The 1 or 2 who don't want to move come around when they realize no one is asking them to abandon the things they care about.

If a new regulation targeting AI in financial infrastructure dropped tomorrow, how confident are you in Thredd's readiness?

My engineering teams adapt well.

The harder question is whether you have visibility into your estate: where AI is being used, what vendor tools are in play, what's in-house, and what data each tool can access.

Most regulation requires evidence, and if a regulator walks in and asks for your AI inventory, that needs to be an easy report to pull.

If it's a nightmare to produce, you're not ready.

Vendor models are the harder part of this equation, and they are harder for everyone. 

Which vendor tools are in play, what data each one can access, and how they are trained and governed.  

It's difficult for a buyer of a third-party model to fully produce the internal evidence of someone else's system.  

So we control for the boundary of what goes in and what we accept coming out.

Should it be engineering's job to stay on top of incoming regulation, or does that sit somewhere else?

Legal, compliance, and the leadership team all own a piece of it.

My role in engineering covers security, so I'm very invested in what regulators are saying, what competitors are doing, and what precedents are being set.

I’d recommend that other IT executives read draft legislation and stay on the radar of what their colleagues are talking about in the markets you operate in.

Industry pace and priorities

Do you feel like the pace of AI adoption in payments is being set by companies like yours, or is it big tech setting the direction and you're reacting to it?

Big tech is setting the pace because they're developing the capabilities and the tech that most consumers use every day.

Nobody expected on-demand cars until Uber put a map on a phone, and now everything has to be that immediate and that visible.

For infrastructure players like Thredd, the job is different.

We have to experiment and be ready to react when the demand comes from our partners.

We're not setting consumer trends.

We're making sure we're ready to enable whatever the trend turns out to be.

That's a harder job.

What would you tell yourself on day one of building AI-native engineering at Thredd?

The most important thing to get right on day one is bringing legal and compliance into the process as part of the solution.

IT teams that struggle with AI adoption are the ones where compliance is the last gate.

When the compliance team hasn't had context for the decisions made before they arrived, they have to review everything from scratch and delivery stalls.

Then, get simple use cases live, understand your data sources, and make compliance part of the design from the start. 

Done right, this speeds up delivery rather than slowing it down.

If you roll out AI one tool at a time without a coherent plan, your compliance team is going to shut you down.

3 moves worth making

At Thredd, the fundamental judgment call changed from implementation speed to evaluation rigor.

Evaluating whether something should be built at all matters more than reviewing the code that builds it, because every decision must be defensible to regulators.

Thredd serves both fast-moving fintechs and cautious banks, which means speed without judgment is dangerous.

Thredd uses pre-approved flows for common AI use cases like code generation in approved environments.

When legal and compliance help design guardrails upfront, new tools move inside known boundaries without delay.

Marilyn frames this as making compliance part of building the solution.

If you bring compliance in at the end, they have to go through everything from scratch and delivery slows down.

Senior engineers who resist AI adoption usually care deeply about protecting what the company has built.

Include them in planning sessions with a defined role in the governance work.

The governance role means building the guardrails, deciding what tests need to be in place, what documentation is required, and what a safe migration looks like.

In Marilyn's experience, most AI-wary engineers come around once they see the direction isn't asking them to abandon what they care about.