# Strategic AI Integration in High-Stakes Banking

**Podcast:** The InfoQ Podcast
**Published:** 2026-08-24

## Transcript

The decisions you're making right now about AI adoption, architecture trade-offs, and how your team works together will shape your systems for years.
Getting those calls right when the landscape is shifting this fast is hard.
QCon San Francisco has spent 20 years connecting senior engineers with practitioners who are a few steps ahead on the same problems.
This November 16th through the 20th, 60-plus speakers across 12 tracks will share what's actually working in production and what isn't.
No hidden product pitches, just senior practitioners helping senior practitioners.
Learn more at QConSF.com.
But without further ado, I'll invite Asgut and Ola to introduce themselves and to just remind us what they are doing for a living and for what company.
Yeah, my name is Asgut Mjolnir Søderbom.
I'm a senior developer in Sparbank and Utvikling.
Sparbank and Utvikling is a software company.
It's owned by 12 different banks in an alliance.
So 12 different banks own our company.
We are creating the digital.
bank solutions for all these banks, both on private and company sector.
So we have about 1.2 million customers, which is a lot in Norway since we have 5 million inhabitants in total.
And Ola and me, we work in a team that's called the private market account team, where we are four developers and one product leader.
The thing that we are developing is...
the APIs, which are like the heart of the solutions for all the banks for accounts.
And we have around 100 million requests every day on the most central APIs.
So if we do something wrong when we are developing, we're newspaper headlines pretty fast.
So we're doing mob and pair program and absolutely everything.
No tasks is done in isolation.
We use TDD.
We're putting things into production up to several times an hour.
We have talked about this early on QCon.
You can watch this on QCon, and we also talked about it last year in an episode.
Hi, my name is Oraf.
I'm also a senior developer in Spalbank & Utvikling.
I guess Oskar said most of what we do.
Okay.
Last time we spoke.
You did mention that you're working with a bunch of researchers that are looking into how the company is working and how you're interacting, basically focusing on pair programming.
At that point, I think they were computing a paper.
What happened in the meantime?
Did that paper get computed?
Were there any recommendations, any findings that would be nice to circle back and have them for our listeners?
It is published now and it's available.
The paper is about how to introduce a new way of working into a company.
Basically, they looked at how we had organized what we called experiments, where we let a team or several teams try peer programming over a few weeks.
And they've seen, based on the research that they've done, that this is a really good way of introducing a new way of working into a team.
It's letting the team testing by just committing to trying pair programming a few times a week, let's say two sessions a week.
If they do more, good, but that's the minimum commitment that the team has to make.
It's supposed to be very low key, so it shouldn't interrupt any of the tasks that the team are working on during that week.
And then we have the researchers from Sintef.
do a few surveys and observe some of the people in the team and do survey afterwards.
We have retro specs every week and then everyone talks about how it's worked for them.
And then we can navigate and change course a bit underway.
We've done seven different experiments now over the last four years, I think.
And so they have a lot of data now that they can use for analyzing.
And they've seen a really good impact on introducing a new, like this is a very good way to introduce a new way of working.
So they published an article, a scientific article, not just a blog post.
And we continue with these experiments after we spoke last year as well.
And it has a great effect, not just introducing a new way of working, but also effects in culture, getting several people to try pair programming.
And it's something that works very well.
a cheap experiment.
Okay, so to just understand, you mentioned there were seven experiments.
Were all of those focused only on pair programming or there were different methodologies or just different teams tried pair programming?
I guess we tried to be champions of working together.
So in the first experiments, we called them pair programming experiments.
But later on, we called them pair working because we want all disciplines in the team.
If it's graphical designers, front-end developers, back-end developers, people who work with UX to actually work together, also testers if they have them.
That's why we switched to focusing more on peer working.
But the methodology was the same in all of them.
We refined it slightly, but basically it's as simple as committing to working together for maybe a two-hour session, two times a week.
Yeah, in any given period of three weeks.
But the last experience was a little bit different now.
Then we had a goal in the team that was testing that they should also try to come up with a good way of doing peer programming at the same time as they use Claude.
Because the problems with using Claude with all the weighting and how big the task should be and all those stuff.
So they should come up with a good way of doing.
Claude and pair programming.
So what you're saying is that you made the difference between pair programming, that would be actually just something that would be probably focused on output, where you're just generating lines of code or something like that, and pair work, what I suppose is focused on a given goal, and that doesn't focus only on developers, but probably, as you mentioned, different functions in the team that have an end goal of developing.
outcome.
Is that the correct assumption?
Yeah, it doesn't matter what kind of task you are doing.
As in our team, we sit together on absolutely everything.
Everything from creating a PowerPoint to looking at logs to doing analysis to everything.
We are working as a team on everything.
One key part of these experiments now and how we work is to switch navigator and driver often.
The one who's sitting with a keyboard and not.
Because we've seen that in all experiments, if you're doing peer programming and one in the peer is sitting, for example, for one hour and the other one is just watching, then you lose focus.
So it's very, very important to switch at least every 15 minutes as we see it, who is driving and navigating.
And if we're sitting in mobs, for example, on four, as we did earlier today, then we're switching every five minutes to keep up the focus.
And that works for everything.
And it's not the code or work that's produced that's necessarily the best value.
It's also about the learning and, as you say, the outcomes that's important.
And that's why we think that working together is better because software development is so much more than just producing code.
Mob programming and pair programming keeps the understanding of the solution that the team.
owns in the entire team instead of it being in the head of one singular person, which is often a problem.
So this is experimentation at team level.
And when you say that an experiment is successful, will that be cross-pollinated across the organization?
How is that done?
It's not very structured, but we use in our organization, we use Slack for absolutely everything.
Also the management use.
Slack a lot.
So we share everything there.
It's around, I didn't say that in the beginning, but we are around 800 with consultants, I think 500 that are employed and it's 60 to 70 teams.
And all of these are communicating through Slack.
So we are sharing a lot of the information there.
And we've seen after the experiments that they also do surveys a couple of months after the experiments, and they ask if people are keeping up working together, and they've seen a positive trend on all experiments on this.
And it's very easy for other companies to try this as well.
It's just have a certain period on three weeks, and everyone has to book two sessions a week, as Ola said, on pair programming, and it's a nice way to test it out.
So to just put it in a nutshell, your company has a couple of trademarks.
I know some of them are transparency.
As you mentioned, everybody's communicating via Slack and then it's about experimenting and working together for a common goal.
And you are currently serving more or less a quarter of Norway's population in terms of banking.
That's a rough estimate.
Probably it's a bit less.
So it's one of the biggest in Norway.
Okay.
Just to create the context.
And given that you're talking about context, last year you said that you manage the way how you put it with continuous development, with pair programming and everything, the culture got to a point where you don't think you can be more productive.
Even though you're using at some point development used by AI, it's not always the best, especially in some places where you have legacy codes and it's not that easy to do it.
And this time we are circling around and see if you had any experiments with...
non-human colleagues, as we probably have to get used to calling them, because now a lot of companies are mentioning that they have, I don't know, 100 employees, out of which 80 are agents.
You mentioned also earlier that there were a couple of experiments based on also AI engineering.
So let's dive into that.
Yeah, it's just the last experiment that they used, Claude.
Since we started using that in January, that would be the first experiment that tested it.
But this team, they're very modern.
And they have tested different ways of doing test-driven development by using Claude as well.
So the latest thing they showed us in the experiment was that they just write unit tests and then they have a skill.
And the skill is looking at the tests all the time and trying to implement the code for the tests that are written.
That was really impressive to see.
So basically what they do is they tell Claude to monitor the code base.
And every time Claude sees that there is a failing test, Claude writes the minimum amount of code needed to get the test to green.
And then afterwards comes with a suggestion on how to refactor it to improve the code base.
Yeah, but that's still in an experiment phase.
You're trying to extend the TDD that you already do to incorporate an agent as well.
Yes.
And the reason why we do this is because, at least what I think is that if you're going to...
create high quality software, on some level, you need to have an artifact that you know, that you control, and that you can validate.
And before agents and AI tests were always the way that you validated and controlled that the code you have written does what it's supposed to do.
At least that's what I prefer to do.
Some prefer to just write a bunch of code and then...
manually sit and test that it does the same thing.
But now that you have agents that in theory can produce a lot of codes, then test becomes even more important because you have to be able to validate the output and doing manual code review or even worse, doing manual testing of AI-generated code.
Either way, how you do it, you're going to be the bottleneck.
unless you do something radically different.
So you just replace the fun part of the job with a lot of boring work, which is reviewing code you haven't written or testing stuff that you haven't.
Yeah, we try a different type of TDD skills as well to try to use Claude to work in small steps, to use Claude in a smart way of TDD, but we haven't landed anything we like yet, I guess.
So that brings us a little bit back to what we've done.
So in January, we decided to start using Claude together with a big part of our company.
And we decided to do Claude first.
We decided to do Claude first for several months and just use it for absolutely everything, just to get the experience with it.
So we did it from January to May.
And then in May, we made a conclusion that we want to go back to a little bit more of traditional coding with TDD and use Claude more as super consultants to help us with things here and there.
So during these four months of using Claude for everything, what are your takeaways?
What would you use it again?
What were the failures and the general feeling about it?
We got this, what do you call it, fatigue.
We got a little bit bored and we got a little bit depressed at the same time that we saw that it was extremely powerful.
We understood pretty early that we had to change and we have to use this tool in a good way.
But we used a lot of time in these months just waiting and looking.
And we are feedback junkies.
We hate to wait.
And the process that we have already with TDD is that we make unit tests and we make implementations and we put into production several times an hour.
And suddenly we're waiting like 10 to 15 minutes on CROD, planning things and making things.
And we were just reading, reading, reading code.
And that was like moving backwards into the future at the same time that it was powerful.
So it was very weird.
That was the first thing.
AI for a lot of things today.
But when it comes to actually creating, it works some of the time, but it produces, in my opinion, at least it produces code that's, I'm not sure if I should say subpar, but it produces code that doesn't fit exactly.
So we end up having a lot of round trips.
So I think In all, when it comes to producing code that's in our domain, we are also, in addition to TDD, we also enjoy using domain-driven design, where we have tried to keep our domain clean.
And our domain is our understanding of the problem we're trying to solve.
So putting an agent in there, producing a lot of code, it reduced our ownership of the problem.
made us feel a bit complacent, I guess.
We just got a bunch of code and it's like, yeah, I think it looks good.
I don't quite understand it.
Let's just put it in production.
And then sometimes it just, it wasn't correct.
Yeah, what we see, it's really depend on the context you're in.
So when we are working with our solution, it's like, it's very, it's a system.
It's a very critical system.
And it will affect a lot of users, a lot of other teams, a lot of different solutions if we do something wrong.
And then the focus on delivering small things with quality all the time has been a success for us.
And when you're working like that, a lot of time is not used on writing code, producing code fast.
It's used on understanding the system, on the organizations, on the vendors.
on how everything is put together and then small pieces of the time is used for actually implementation.
And then Claude is not that useful.
We call it more like a brownfield project or working with Legacy Code.
It's very much brownfield.
We have maybe, not in our code bases, but the backend systems that we integrate with have maybe 50, 60 years of history.
So you can compare that to like Greenfield projects.
One guy I know that created a startup project before AI, and the code that was written was horrible, but he made a product that a lot of people wanted.
He sold it in the end and got rich on it, but the company who bought it, they didn't care about the quality, but they just wanted the product, and then they rewrite themselves afterwards, of course.
In that case, I guess, wipe coding, writing code fast would fit a lot better than it does.
in our system when it's a complex organization.
So it really depends on the context.
At the same time, we use Cloud a lot to different tasks like analyzing and talking to code and looking at metrics.
We have a lot of use of it.
It's just not the code generating part that is seen useful to us.
So on things that you are very familiar with, it grew through the...
already decades.
So it's something that is very old and grew organically, where you need to have the feeling and the broad context and you have all the stories that an agent doesn't have.
It's not the quality that you expected it to be.
It was good, but not good enough.
And at points, it just failed.
And on the other hand, it's good where actually it should be good on crunching a lot of data.
So if you want to have a broader context, I don't know, I'm just trying to...
paint a picture here, like, I don't know, you have metrics and you have logs and you have telemetry and you have also the code that you're not that good.
It can provide you the insights in one go and then it will be easy.
I don't know, let's say, let's make a graph that incorporates the percentiles and stuff like that.
That's useful, but still as a helper for a human coder.
Yeah, I think the help from a human coder is something...
There are so many people who think that that is a bottleneck.
We had a task this morning that was to write the integration to another system with an adapter and a REST client and so forth, the normal stuff that we do all the time.
And as a little experiment, we just asked Claude to look at another similar integration, which was very similar and make the one that we needed.
And it took around 45 minutes an hour before everything was finished.
And then we looked through everything that it had done.
and then we put it into production.
If we had done that ourselves, we would do a lot of small things in production while we're going.
But here we created everything at once.
It's like moving a little bit backward into the future, I think.
And then we were pretty certain that it was going to work, but it didn't.
Did it, Ola?
No, actually it didn't work because again, it didn't have the context.
We would probably have made the same mistake because the API.
had some quirks that Claude couldn't know about.
And that's the thing.
Context is everything, especially with some of the systems we work with.
It's impossible to write down all of the context.
I guess it's what you can refer to as tacit knowledge.
But one thing that I would encourage everyone to try if they have telemetry that they have available is...
ask Claude or your coding agent to talk to your application.
Ask it how it's performing in production.
If you're using Java, then ask it, how is the JVM configured in production?
What does the latency look like?
Stuff like that, it's brilliant.
You can get a lot of data.
And if you want something more visual, then it's really good at creating stuff like Grafana dashboards.
or just making an ASCII graph of the latency or just a table.
It's really good at that.
I just have to add there, that makes us also a little bit more autonomous because earlier we had to get help for a lot of those dashboards stuff from other expert teams.
And also some of the scripting we do in pipelines and everything, there's a little bit of what we do normally.
Their cloud is amazing.
Because we see that the thing that slows us down the most is when we are dependent on other people, other teams.
And Claude has made us be a little bit more autonomous there on some parts.
At the same time, if it requires quality, I think it's still the same.
We can suddenly do front-end development, for example.
But then we don't know what we're doing.
So is it smart or not?
Yeah, well, that's a debate for everybody.
Listening to you, I had a previous conversation today and I was talking to somebody that was very ecstatic about agenting coding and now it felt a bit, as you mentioned, fatigue.
And for me, it feels like it's like sugar rush.
When you eat sugar, you just eat, eat and eat and eat.
And at some point you get to the point where you just feel tired and then your energy level is dropping.
So that's my feeling that everybody after they use a lot of AI.
They feel that things are not on par with what they would have done.
And after a bunch of compromises, now they start using it in places where it's actually needed.
As you mentioned, it's about also front-end development where we use it with a lot of success, I would say, is on the part with prototyping.
Because now we have a lot of client-facing customers from different perspectives.
And then rather than just talking and doing mock-ups, it's very useful to just give them an app.
You just give them an app in one or two days and you see exactly how they use it rather than just imagining them.
But after that, what we do, we just use it as glue code.
We just generate stuff, but with components that are already in place.
And then that's a lot easier because you can constrain it.
It's not always fabulous, but still okay.
But then on the part where you need, I'm expecting that when you're discussing about transactions and you have to be really on spot, you cannot make mistakes.
And also you have different ways of doing it.
So that place I would be a bit careful in how to do it, especially on old code where it just makes assumptions that are not actually there.
I think one part we've seen, like Ola was talking a little bit on, is talking to the code, we call it.
For example, we have one complex big API with a lot of integration tests that we don't want.
And the whole test coverage is a little bit weird and that is also affecting the design.
This is a place where I think that Claude is really shining.
We can ask Claude to just kind of go into the code and analyze this and give us some overview of all the tests and how this design looks like.
And then in no time, it comes back with an answer much, much faster that we can do.
But instead of going forward and asking to create a plan and implement everything, we will do the implementation ourselves.
But it will kickstart us.
And this kickstart is an amazing thing that we feel it can.
takes a lot of the backlog that we haven't been able to do before and it makes us faster and we can get a bad overview.
So actually what you're saying is that you're using LLMs, well in this case Claude or any of them, like a bicycle that gives you the extra energy and it transforms the energy that you're putting into more productivity.
It kickstarts you, but you still respect the proper rules of how to run a bike.
You're just going and inspecting the traffic signs rather than just going off-road and then falling in a pit because in the end that's it.
It's an accelerator but if you don't respect the rules you'll just get in the wrong place.
Yeah, you need two things to get somewhere.
You need speed and direction and if you only have speed then obviously you're not going the right way.
So yeah, that's basically it.
It can get you somewhere quickly but knowing what you're actually doing.
And I really like what Kent Beck came up with.
He talks about the genie.
He also called it the slot machine, which is a little bit back to the sugar rush.
You put some tokens into the slot machine and you see what comes out and sometimes you get what you want and then you're like, yes.
But the genie thing is, I think is a really good picture of it because often you get exactly what you ask for.
And if it wasn't what you actually wanted, it was because you didn't ask it correctly.
So if you have the proper context, then it can be really helpful.
But that's also part of the issue, especially in the brownfield area where we're in, is that there's so much stuff that's cruft and history that just does not make sense.
If you get code that on the surface makes sense, it's just not fit for purpose because the backend system maybe has some weird rules that just doesn't make sense.
Yeah.
And in the beginning also, after a while, we saw that coding in the domain layer, we always wanted to do the coding in the domain layer ourselves to have full control over the domain.
And the integrations to other systems and stuff could be easily generated by Claude.
integration with the other systems with Claude, it's kind of part of the domain as well.
Because if you don't have to control that into the domain, you get into the same kind of problems.
So we're back to the coding in small parts and putting things into production feels much better.
It's like we talked about earlier, it's like the scientific way of doing software development as Dave Fairley explains in his modern software engineering book.
It's as important today as it was before, just that we have an accelerator on some areas with AI.
Yeah, and as a lot of the research shows, those principles, it's even more important because an LLM works a lot better on a well-factored codebase than on a bad codebase because an LLM is really good at looking at patterns and reproducing them.
For instance, in the thing we made earlier today, We saw something that we thought like, why on earth did you do that?
So that's another thing we often do when we see something that's subpar.
We ask LLM, why did you do that?
And the response was, because you did it in the other integration that I copied.
So having a well-factored code base is essential for getting better results.
And the learning part.
We feel that it's much better when you sit like we've done before with small things and we don't have this interruption and we have to make everything ourselves.
Often we create code and we throw away code just to have a feeling on it and to learn from it.
And what we saw there in January, we took in another developer called Magnus and we had had him on a week job shadowing test earlier and he was really impressed how it worked and he wanted to...
to work with TDD and pair programming.
And then he came in January.
At the same time, we started with Claude.
And then he said it was really difficult to learn the domain because we're just asking Claude and we have to read all this stuff all the time from Claude.
So it's difficult to get into the domain rather than how we did earlier when we were doing TDD and pair programming with much higher flow.
We saw that when we went back to writing more code as well, we noticed how little waiting we actually have.
We have a continuous flow all the time.
We're writing tests.
We're talking to each other all the time.
We're writing on whiteboards.
We're doing discussions.
All of that was kind of missed when we're just sitting waiting.
So that part is super important, I think.
And it's also helps us create better teams, create better psychological safety and so forth.
One other thing that takes a lot of time where Claude...
necessarily isn't a good help is figuring out what parts we don't have to do.
For instance, now we're modernizing a lot of our main applications and a lot of the work is actually figuring out which fields are not in use anymore.
So we can drop them and leave them be without trying to figure out where we can get that data.
because an LLM will just let me just generate everything for you so you don't have to think.
But by actually having a look at what fields are in our APIs and seeing if they're actually still in use, we can save a lot more time than it would save and everything that goes with compared to just letting an LLM generate it.
And this requires talking to other people, asking them, are you actually using this?
So there's a lot of time saved in not implementing things as well.
So to just summarize the last point that we had is that LLens in particular are very smart kids, but kids still at this point.
And if you did a mistake, this kid will just take it and accelerate your mistake and do it all over again.
And if you ask it why...
It will just rub it in your face and okay, because you did it.
That's how you taught me.
Given that we should wrap up our conversation, what predictions do you have moving forward?
You choose the scale in terms of how software engineering will change or how working in a team will change.
We're discussing that so much that we kind of border it in a way, but it's still important.
But it's very important to say again here that we're not negative to close.
We use it all the time.
We think it's amazing.
But the way that we come to today with writing coders by hand again and using Claude is something that works for us in our domain, in our context right now.
When this episode is released someday in fall or something, that may be totally changed.
But that doesn't matter.
It's just we have to do what fits our code base, our customers, our vendors, our system.
But as of the future, I listened to a podcast with the engineering room with Dave Haley and Sam Newman.
And he talks about if you're going to use AI, then AI maybe have to both write the code and review the code and just have full control.
He has an analogy with a factory.
making cars with the robots, just they can play around themselves when they're making the cars and no one can go into the rooms where the robots are.
Maybe we have to move in that direction.
And when they have so much control over the application, then we can maybe verify the solution on another abstraction and then we can take full usage.
But I have no idea and I don't think it's tomorrow.
I don't think it's next year either.
The problem with the car analogy or the robot analogy is that a robot that welds car parts, it's a highly scripted thing.
It's deterministic.
It does the same thing every time, while an LLM by nature does not.
So I think, first of all, I would like to say that everyone should probably take a chill pill.
Just drop the Fovol because...
I don't think that anyone will be out of a job anytime soon as software developers.
I think the term that coding is solved is absolutely wrong.
As I said, it's very dependent on context and what you're working with.
I think we're still very much in an AI bubble.
So I think we need to keep calm and carry on and see.
if the bubble deflates or if the world economy crashes or whatever happens, and then see both what the actual cost of using an LLM will be after.
Because if you're not doing the coding, if you're outsourcing the coding to an LLM, someone wants to be paid for that.
And it still looks like the cost of token is subsidized.
And it seems also that a lot of the progress with the models now is due to reasoning, i.e.
the model prompts itself and then uses more tokens.
And you'd see it very clearly in the pricing of the new models coming out.
Like Opus is really expensive and Fable, which was available for like five minutes, was double as expensive as Opus.
And you're approaching the territory when you can start.
asking yourself as someone who wants work done if it's just cheaper to have a developer do it than a model so if you're going to make progress with ai then something has to change with the way new models are made i think thank you is there anything else that you would like to add guys yes there are two things i like to add first it's just The journal where the Sintet published the article is called Journal of Systems and Software, which is a well-respected journal.
The other thing I would like to add is that I think we have solved this junior problem in our team.
You know, the gap everyone is talking about when you come out of a university and start working and suddenly are using agentic coding like Claude and you don't get to learn.
how to program as we did when we started working.
In our team, we have something called job shadowing.
We have a developer from another team coming, visiting us for a week.
On the first day on the Monday morning, they get some cinnamon buns.
We just sit and talk for an hour or something about normal stuff.
And then after an hour, we're showing them the problem or the task that we have for that week.
And then we just start working.
Since they are developers and since they know how to write ifs and else and spring and all the other stuff that we are using, it's pretty easy to get them productive because we narrow the scope so much.
More importantly, since we are doing mob and poe pair programming and we're rotating every 10 minutes, then they very quickly get into the tasks.
So for the last year, we had several different developers coming visiting us for a week, and all of them had code running in production before lunch the first day.
They also reported back that they learned a lot this week, and when they came back to their team, they started doing the same practices in their teams.
We had organic growth in the way we are working.
This doesn't matter if you're a senior or junior or from another team of who you are.
We get to onboard you very quickly either way.
And this will not change even though we use Claude or Agente Coding.
We will still use the same approach by setting in...
into the same task that we are doing, doing some normal coding, some cloud coding, talking about design, writing on the whiteboards and so forth.
And then they get to know the domain pretty quickly and they get productive very quickly.
I think if all teams worked in this way, it would never be any problems with people coming out of college and working the way that we do.
This approach also leads to two different things.
psychological safety is much, much higher because when you start working in a team, you don't have to show that you can deliver or that you are capable of doing this and this task.
What we see in many other teams is when someone is starting in a team, they get a task from the board which is supposed to fit this new developer in the best way and this developer has to sit down and show that he is like...
capable of doing this task.
Instead, we just the new developers is just set directly into a task with us.
And we are delivering the tasks and producing the tasks together, which is a much better way.
We think the other thing, this shows a very good way of doing team mobility.
If every team in a company works this way, it would be very easy to switch teams.
to onboard new team members and off-board new team members, which would be a huge benefit for the company.
I know Europe is really warm, but don't just spend the entire summer vibe coding, do fun stuff, see the sun.
Yeah, take a chill pill.
I think, is that something that exists?
Yeah, that sounds like a good advice.
Yeah, but we just play around with it, have work as usual.
Use Claude to experiment and don't stress it too much.
I think that's great that Ola said there.
Great.
Thank you very much for your time.
Thank you for having us.
Thank you.