Asgaut Mjølne Söderbom and Ola Hast discuss the evolution of their software engineering practices past continuous deployment and pair engineering. The conversation continues where it left off in the previous episode and focuses on the experiments in adopting Claude Code and the reasons why they consider it good for everything else, but not coding.
Key Takeaways
- Extending mob and pair programming to all team tasks, even documentation and analysis, serves as the foundation for high-quality, high-velocity delivery by spreading domain knowledge and eliminating knowledge silos.
- LLMs excel at analysis, telemetry visualisation, and task kickstarting. However, in complex ‘brownfield’ environments, they often lack the necessary tacit context, requiring humans to remain the owners of domain logic to avoid "subpar" code.
- Constant mob programming creates psychological safety that allows new team members to be productive and contribute to production on their first day through shadowing and constant shared ownership.
- A strict ‘no outside pull requests’ policy forces genuine collaboration. Rather than asynchronous, lower-quality integration, external changes require active pair programming, reinforcing team ownership and system coherence.
- Rather than debating 'good vs. bad code', focus on 'code that is easy to change'. This goal naturally leads teams to adopt design principles like high cohesion, low coupling, and TDD as essential consequences of the workflow.
Subscribe on:
Transcript #
Olimpiu Pop: Hello everybody. I'm Olimpiu Pop, an InfoQ editor. And today we have in front of us two people that we spoke to almost one year ago. And even though they tried at that point vibe coding or whatever, AI-generated code, they said that AI is not that fast for them. In the meantime, they experimented and we wanted to see where they are. But without further ado, I'll invite Asgaut and Ola to introduce themselves and to just remind us what they are doing for a living and for what company.
Asgaut Mjølne Söderbom: Yes, my name is Asgaut Mjølne Söderbom. I'm a senior developer in SpareBank 1 Utvikling. And SpareBank 1 Utvikling is a software company and 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 are five million inhabitants in total. And Ola, 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 are newspaper headlines pretty fast. So we're doing mob and pair programming on 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 earlier on QCon. You can watch this on QCon, and we also talked about it last year in an episode.
Ola Hast: Hi, my name is Ola. I'm also a senior developer in SpareBank 1 Utvikling. I guess Asgaut said most of what we do.
Olimpiu Pop: Okay. Last time when we spoke, you did mention that you're working with a bunch of researchers that are looking into how the company's working and how you're interacting, basically focusing on pair programming. At that point, I think they were writing a paper. What happened in the meantime? Did that paper get completed? Were there any recommendations, any findings that would be nice to circle back and have them for our listeners?
From Pair Programming to Pair Working: Cross-Functional Collaboration [[03:06](javascript:void(0);)] #
Ola Hast: 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 pair 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 retrospects every week and then everyone talks about how it's worked for them. And then we can navigate and change course a bit underway.
Asgaut Mjølne Söderbom: 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. They've seen a really good impact on introducing a new, 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 this 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 and a cheap experiment.
Olimpiu Pop: 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?
Ola Hast: 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 call them pair working because we want all disciplines in the team. If it's graphical designers, front-end developers, backend developers, people work with UX to actually work together. Also testers if they have them. That's why we switched to focusing more on pair 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.
Asgaut Mjølne Söderbom: Yes, in any given period of three weeks. But that only was the last experiment 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 pair 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.
Olimpiu Pop: So what you're saying is that you made the difference between pair programming, that will be actually just something that to 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?
Asgaut Mjølne Söderbom: Yes, 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 or not. Because we've seen that in all experiments, if you're doing pair programming and one in the pair 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 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. That works for everything.
Ola Hast: 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.
Olimpiu Pop: 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?
Team Level Experiments and Crosspolination [[08:36](javascript:void(0);)] #
Asgaut Mjølne Söderbom: It's not very structured, but 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. Let'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 place to test it out.
Olimpiu Pop: 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.
Asgaut Mjølne Söderbom: So it's one of the biggest in Norway.
Olimpiu Pop: Okay. Just to create the context. And given that you're talking about context, last year you said that you managed the way 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 AI engineering. So let's dive into that.
Asgaut Mjølne Söderbom: Yes, 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 during 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.
Ola Hast: 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.
Asgaut Mjølne Söderbom: Yes, but they're still in an experiment phase.
Olimpiu Pop: You're trying to extend the TDD that you already do to incorporate an agent as well.
Ola Hast: 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 control 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 tests 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...
Asgaut Mjølne Söderbom: Yes, we tried 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.
Olimpiu Pop: So during these four months of using Claude for every, what are your takeaways? What would you use it again? What were the failures and the general feeling about it?
The Brownfield Challenge: Why AI Struggles with Context [[14:15](javascript:void(0);)] #
Asgaut Mjølne Söderbom: 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 times 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 10 to 15 minutes on Claude 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 fallible. So very weird. That was the first thing.
Ola Hast: I think we should say that we still use 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 for 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 and it made us feel a bit complacent, I guess. We just got a bunch of code and it's like, yes, I think it looks good. I don't quite understand it. Let's just put it in production and then sometimes it wasn't correct.
Asgaut Mjølne Söderbom: Yes. What we see, it really depends on the context you're in. So when we are working with our solution, 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 times it's 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 actual implementation. And then Claude is not that useful. We call it more like a brownfield project or working with legacy code.
Ola Hast: 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.
Asgaut Mjølne Söderbom: And you can compare that to 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 vibe coding and 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 Claude a lot for different tasks like analyzing and talking to code and looking at metrics. And we have a lot of use of it. It's just not the code generating part that is seen useful to us.
Olimpiu Pop: 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. I don't know, you have metrics and you have logs and you have telemetry and you have also the code that maybe you're not that good, it can provide you the insights in one go and then it'll be easy. I don't know. Let's say make a graph that incorporates the percentiles and stuff like that. That's useful, but still as a helper for a human coder.
Asgaut Mjølne Söderbom: Yes, I think the help from you 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 made 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 ourself, we would do a lot of small things in production while we're going. But here we created everything at once that is 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?
Ola Hast: No, actually it didn't work because again, it didn't have the context. We would probably make 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 worked with when 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 there that they have available is ask Claude or your coding agent to talk to your application. Ask it how it's performing and 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.
Asgaut Mjølne Söderbom: 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. Claude is amazing. Because we see that the thing that slows us down the most is when we are dependent on other people or other teams. And Claude has made us be a little bit more autonomous there on some parts. At the same time, if it require 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?
Olimpiu Pop: Yes. Well, that's a debate for everybody. And listening to you, I had the previous conversation today and I was talking to somebody that was very ecstatic about agentic 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 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've 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 par with prototyping.
Because now we moved, we have a lot of client-facing customer 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 did, 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.
Asgaut Mjølne Söderbom: I think one part was in it like Ola was talking a little bit on was talking to the code, we call it. For example, we have one complex big API, but 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. So this is a place where I think that Claude is really shining. We can ask Claude to just 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 than 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'll kickstart us. And this kickstart is an amazing thing that we feel it 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.
AI as a Bicycle: Kickstarting Implementation vs. Generating Code [[24:50](javascript:void(0);)] #
Olimpiu Pop: 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 it gives you the extra energy and it transforms energy that you're putting into more productivity. It kick-starts you, but you still respect the proper rules of how to run a bike. You're just going and respecting 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.
Ola Hast: Yes. 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 yes, 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 where you put some tokens into the slot machine and then you see what comes out and sometimes you get what you want and then you're like, "Yes". But the genie thing 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. So even 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.
Asgaut Mjølne Söderbom: Yes. 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 ourself to have full control over the domain, and the integrations to other system and stuff could be easily generated by Claude. But then after a while we saw that this integration with the other systems with Claude, it's part of the domain as well because if you don't have to control of that into the domain, you get into the same 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 Farley explains in his Modern Software Engineering book. I think it's as important today as it was before, just that we have an accelerator on some areas with AI.
Ola Hast: Yes. 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 code base than on a bad code base 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.
Asgaut Mjølne Söderbom: Yes. 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 him job shadowing a test earlier. And he was really impressed how we worked and he wanted to work with TDD and pair programming. And then he came in January at the same times we started with Claude and then he said it was really difficult to learn the domain because we are 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 are 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 missed when we're just sitting waiting. So that part is super important, I think. And it also helps us create better teams, create better psychological safety and so forth.
Ola Hast: 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.
Olimpiu Pop: So to just summarize, the last point that we had is that LLMs 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'll just rub it in your face and say, "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.
Asgaut Mjølne Söderbom: We're discussing that so much that we are bored of it in a way, but it's still important. But it's very important to say again here that we're not negative to Claude. We use it all the time. We think it's amazing, but the way that we've come to today with writing codes 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 Farley 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.
Building Stronger Teams: Onboarding and Psychological Safety [[32:31](javascript:void(0);)] #
He has analogy with a factory making cars where the robots just, they can play around themself 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.
Ola Hast: 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 FOMO 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 a AI bubble so that 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.
Opus is really expensive, and Fable, which was available for 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.
Olimpiu Pop: Thank you. Is there anything else that you would like to add, guys?
Asgaut Mjølne Söderbom: Yes, there are two things I like to add. First, it's just the journal where the SINTEF published their 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. 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 and visiting us for a week. On the first day on a 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 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 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 a junior or from another team or who you are. We get to onboard you very quickly either way.
And this will not change even though we use Claude or agentic coding. We will still use the same approach by sitting in the same task that we are doing, doing some normal coding, some Claude 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 tasks. What we see in many other teams is that when someone is starting in the team, they get a task from the board where it's supposed to fit this new developer in the best way. And this developer has to sit down and show that he's capable of doing this task. Instead, 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 offboard new team members, which would be a huge benefit for the company.
Ola Hast: I know Europe is really warm, but don't just spend the entire summer vibe coding. Do fun stuff, see the sun.
Asgaut Mjølne Söderbom: Yes, take a chill pill. I think is that something that exists?
Olimpiu Pop: Yes, that sounds like a good advice.
Asgaut Mjølne Söderbom: Yes, but we just play around with it, have work as usual, and use Claude to experiment and don't stress it too much. I think that's great that Ola said there.
Olimpiu Pop: Great. Thank you very much for your time.
Ola Hast: Thank you for having us.
Asgaut Mjølne Söderbom: Thank you.
Mentioned:
More about our podcasts
You can keep up-to-date with the podcasts via our [RSS Feed], and they are available via
[SoundCloud](https://soundcloud.com/infoq-channel),
[Apple Podcasts](https://itunes.apple.com/gb/podcast/the-infoq-podcast/id1106971805?mt=2),
[Spotify](https://open.spotify.com/show/4NhWaYYpPWgWRDAOqeRQbj),
[Overcast](https://overcast.fm/itunes1106971805/the-infoq-podcast)and
YouTube. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.