Louis Knight-Webb from Bloop.ai - the YC startup turning COBOL into Java

Know what a mainframe is? Or have you ever written COBOL? Maybe not.

Everything that exists around software development has a clone in the mainframe space. It's like Mario and Wario, you know. Okay. It's a parallel universe.

We're all really excited about new technology like Bun and Svelte, but a lot of the software that dictates our lives like airline bookings and bank transactions actually runs on mainframes using COBOL. And my friend, Louis, is the founder of Bloop, which is a startup that is completely dedicated to modernizing all this legacy software that no one understands how to build anymore. I feel like the best one's often, like, where they're like, should I say this? Yeah. Alright.

I should pull this idea up.

But Yeah. Yeah. They do it anyway. Yeah. Yeah. You know, something's good. Something good's gonna come from that.

Yeah. What

what was the best talk ever, like, in terms of the ratings? Do you have do you know?

Oh, I love them all. Okay.

No. Not your favorite.

Yeah. Fine.

Statistically because you you just said you have a quantitative method.

I mean, firstly, I don't actually know because I haven't I haven't really been looking out for that. I'd say, you know, things like, you know, former founders, so Guy, Pujani, who, you know, and, Jonas Templestein, we've had previously as well. So, you know, Jonas previously cofounded Monzo, and Guy obviously previously cofounded Snyk. So those kinds of talks, I think, where they span not just the tech, but also entrepreneurialism, Being in London is a is a common theme as well, you know, that gets people excited. And I think just generally, you know, it's like a huge vote of confidence when you're you know, most of the people probably graduated in the last 5 years that attend these events, and they turn up and they see somebody who has built a company worth 1,000,000,000 of dollars basically doing a similar thing to them and is huge validation.

Yeah. Yeah. Because and I guess it's just the the least BS, I guess, as well. It's just like the if you're a founder, you can say whatever you want. Yeah.

So They're rich. Yeah. Like, they can do what they want. Yeah. They can say what they want, and, they don't have to worry too much in that environment either because nothing's recorded. Everybody's an engineer. Like, nobody's trying to do a gotcha or anything like that. It's, yeah, good discussion.

Yeah. And maybe that's a good segue to talk about that you are the founder of Blue. And to illustrate that you can do what you want, you have brought me a bottle of Yeah. Dorset knob, which is displayed for people that, are on the video.

Well, we're meant to do this in Dorset. So in the absence of doing this in Dorset, we've got a slice of Dorset in South London today with us.

Well, what is Dorset? Where is Dorset for for our American and and UK business?

Dorset Dorset is is is is, what is it, a county? It's county, isn't

it? County.

County in the south of England, basically stretches along a piece of, coastline called the Jurassic Coast, which is very famous for fossils. And, they found lots of interesting sea monsters there recently. They, you know, won recently in a in this really cool BBC documentary that they called the Sea Rex, which I highly recommend going and seeing Oh, I see. Down in Cambridge in the museum there. And then it goes up a bit, but I love Dorset because, I quite like sailing, which is a kind of odd pastime and, the waters of of of Dorset have lots of nice little natural harbors, which are not too deep and you can, you know, go sailing on a small boat and capsize and stand up and you don't drown, which is nice.

Yeah. As Paul Harbor is like the second is it like the second biggest?

It's not the biggest or the 2nd biggest natural harbor in the world. So there's a lot of dinghy sailing, a lot of like kite boarding, things like that there. Yeah. We were supposed

to be wearing sailor hats today, but Next time. Yeah. Same times. And Bloop is, doing something very different now to what it was when you started out.

Yeah. Well, we started in a very different world in 2021. You know, there was no GitHub Copilot. I think, you know, the biggest open source model at the time was GPT 2. And, you know, our you know, I initially meeting my cofounder, Gabriel, who's a machine learning researcher by background.

This episode is brought to you by WorkOS. If you're building a dev tool, at some point, your customers are gonna start asking you for enterprise features. WorkOS offers you single sign on, skin provisioning, and audit logs out the box. WorkOS is trusted by Perplexity and Vercel as well as Workbrew, a home brew management startup that I recently interviewed. I just told Mike that WorkOS is the sponsor and this is what Mike said.

Yeah. So WorkOS isn't paying me any money for this. I I pay WorkOS money for this, but WorkOS is like one of the best developer tools I've, like, ever used. It's it's the documentation and the experience with building with them is so so good. Like, I initially was almost like, okay.

Go to workos.com to learn more. That I think, like, that Microsoft, it seems like they have really tried to create the, you know, the Office Suite for developers and and you're competing against that. And if they have it I mean, even we saw with, like, Office, it's like the Slack challenges that they've had even after all of that adoption that, like, Teams is really taking a lot of their, I think, a lot of their their share.

Yeah. 100%. And, you know, distribution is really key. You know, they're coming out of the gate. It doesn't matter if they they ship a feature a year later because they've already got the list of customers and the renegotiation, you know, they can throw that extra feature into the bundle.

Yeah. And what was like the 1st week of, you know, jumping to that as you put up?

The fur well, it was it was kind of a few conversations and then a reflection on those. So I think the very first thing we learned about was, spending some time in in San Francisco and going to some dev events and just bumping into, some really, you know, high up kind of tech leadership people in in very big branding companies and listening to them just talk about the challenge of of legacy code. And the first couple of conversations were legacy in the context of JavaScript. Like, they were considering JavaScript and I think Flow.

Oh, the Yeah. TypeScript.

Exactly. It's not enough. To be their legacy and what they wanted to move to was TypeScript in their case. Yeah. And they were forecasting it was gonna take, you know, a decade of developer time to port from flow to TypeScript because the type system cannot be mapped 1 to 1 between all of the different flow types.

When you say, sorry, a decade, do you mean like

One developer for 1 developer. Working solidly for 10 years.

For 10 developers for 1 year sort of thing.

The same thing. Yeah.

Yeah. Okay. But they they were actually thinking time wise. It's literally not gonna be done until, like No.

I think they would have got a squad on it. But in terms of cost, it would have been about 10 years of a developer's time to solve that problem because a human needed to, you know, manually reason about, well, what do we do about this flow type? What's the correct translation into TypeScript? So we thought about modern language translation for a little bit, and we started talking about this in the context of some of the customer calls we're still having about code search. We're dropping in well, you know, what about, like, legacy code modernization?

they build and they build and they build and, you

know, you wake up one day and you've got a 1,000,000,000 lines of cobalt in production. And it's so hard for those companies to move away from that because they've just accumulated it. And, there aren't really, you know, a lot of good options. I mean, using humans take a very long time to convert. Right?

Which will just create absolute carnage.

Well, yes. I mean, I don't know if there's any examples of, like, machine generated code that people like, but I assure you people do not like machine generated Java. It reads like, you know, and and there's huge differences between these languages. And so, you know, you're not taking full advantage of what the Java language can do, can, you know, represent things properly as, you know, all your entities as nice objects. You're not necessarily representing COBOL objects in clean Java objects because the, the the types are different in both of those languages.

Yeah.

And just copy and paste the the output back. Right? Now the problem with this and the problem with any task in involving COBOL is that there's basically no COBOL in open source. And if you think about how the very biggest models have been trained, they've been trained on GitHub and open source. And that's why they're really good at modern programming languages because there's so much Java and JavaScript and whatever in open source.

To make it.

And refactor

it Readable.

The readable, modern, performant, all the rest of it. So, you know, there's 2 halves to our system. We've got transpiler, and we've got, agentic refactoring.

And does it go like in is it like in waves where you run like, okay. Let's use the let's do the date for like, you were mentioning about, like, using the standard libraries and stuff. Okay. I'm guessing you're just doing it, like, let's do that, and then let's do this other thing, and then let's do this other thing.

Yeah. So well, so, you know, these code bases are enormous, like millions of lines. And, you know, the context of, the best models will be, you know, a 100 k tokens. We've done quite a lot of work to understand how much of that context is actually usable. And so the the reality is, like, you know, at 30 k tokens in the prompt, you start to see a lot of performance degradation.

Yeah.

And just replace that with Yeah. You know, the the standard date full matter. But, you know, there's so many permutations. Right? Because every implementation of formatted date in COBOL has been done by hand by a COBOL engineer. Yeah. So every code base has got a different version of formatting a date. Yeah. So this is something That's what. That the LLMs are really good at.

And how does it work if there's kind of like sort of like Jank in the code where it's like they're using a different date format there. They're using a different date format there, and maybe they shouldn't be. It's like, do you sort of correct it or or is it like you kind of, it's the same. It's gonna have the same problems. But

Yeah. So duplication is a huge one, and we do a lot of deduplication on the code basis. You you can literally reduce these code bases, you know, like, at least by, you know, 50%, in terms of the the size of what you started with. A lot of the type so, you know, literally these code bases have been started in the seventies

a lot of the time Yeah.

And developers developing them today are not the same that originally started off. And actually, they're often in maintenance mode. So often there's nobody on the team who knows the code base in a lot of detail. Mhmm. So if they're implementing any changes, there is a bias to write something new as opposed to reusing an existing program or module. So we do this is something that is really common as we see, lots of duplication of of functionality across the code base.

Mhmm. That makes sense. And I think you told me that the the people that do understand it are, like, quite expensive.

So yeah. So well, okay. So we could talk about drivers a bit. So the talent is the the reason that everything, you know, everything kinda stems from. So, most of your listeners probably will not be seriously considering COBOL as a career path.

Yeah.

And that's, you know, that's true of of most graduates joining the industry today. And so what that means is many more people retire every year with COBOL skills than join the market. And that means if you're, operating COBOL application and you need to make changes because a lot of these businesses are regulated and regulation forces changes. Or if you're in a traditional industry that is facing competition from I know you're a bank and then there's neobanks popping up, you are stuffed because you can't get enough engineering resource to make those changes. All you've got is enough engineering resource to keep the lights on.

Yeah. And do they so I I I wanna ask, like, more about the actual, like, getting going to market, but one last question on the like, do they run the Java on the mainframe once they've changed it, or are they also, like, moving?

Yeah. So this is kind of a hot topic at the moment, which is like running Java on the mainframe. And for many years, you know, you could run Java on the mainframe, but it was like super old versions of Java. And and quite recently, they brought, you know, the newer versions of of Java onto the mainframe, to encourage more people to run Java on the mainframe.

Yeah.

But I have really yet to find a single customer to reach out to us that is interested in running Java on a mainframe. I mean, the way the way I think about this, you take the the circle of people who understand mainframe, you take the circle of people who understand Java, and, like, you know, the intersection of those two things is even smaller than either.

Okay.

So, you know, if you're trying to solve a talent problem, ultimately, you're not solving a talent problem by running JavaScript. Also real

new question. I actually don't think I really understand what a mainframe is. Yeah. What what is actually what is a mainframe?

Well, it's a it's it's a it's an architecture. It's a it's a computing platform that is, you know, distinct from, you know, what we know, in terms of, like, x 86 ox architecture or anything like that. So it's got its own, chips. You know, it's got its own operating systems. It's got its own languages, IDEs, protocols for connecting to screens.

know? Okay. It's a parallel Yeah. Sort of universe.

Exactly. A parallel universe.

Okay. That makes more sense. Okay. And so what what is it looking like when you go and talk to companies? Like, what does it look like to start working with them?

So typically, people come to us today when they know they are moving their code from Cobalt to Java. Yeah. So we don't spend too much time persuading them to do that because there's enough people for us to kinda work with at the moment who are already somewhere in that process.

Yeah.

We try and get, like, a chunk of their code to production as quickly as possible. Mhmm. So these code base is pretty big, and the key is to answer as many hard questions as you can as as early as possible because there's a risk if you try and take the entire code base from a to b in one step. You'll just die from, you know, overcomplication and then these things, you know, these huge projects can can run out of control. So we we take a small chunk of code and we, isolate it from the rest of the system, and we move it into Java, and then we work with the client to deploy it into, the cloud.

Okay. That that makes sense. And so you're basically just offering them you're gonna be able to convert this. You you're gonna do something. Or or the I guess at the beginning, they're kind of taking a bet that this is probably gonna work, and it's we're only betting this amount. Yeah. Yeah. And if it works, great, because we can actually get this done. Yeah. But worst case is like this amount of money.

Yeah. Exactly. And for an enterprise, you know, it's like it's peanuts for them to run an experiment. You know, we have yet to see somebody not go on from a pilot to do a full project. They tend to be quite successful, and in comparison, it's a much quicker and often cheaper alternative to

what

they would otherwise consider doing with humans Yeah. Or, you know, the, you know, and it's it's kind of not really comparable to automatic translation because, you know, people don't want code that they can't read at the end because they're maintainable.

Yeah. I'm just imagining, like, how do they know if it was, like, successful? Because I I guess you mentioned, like, they don't even necessarily know what this code is doing.

Yeah. So we typically define a kind of evaluation matrix ahead of time. So we say to the client, what is important to you in terms of code quality? And they can tell us, well, it's really important that, you know, the, we're using this particular open source library. Right? Because they will have existing Java developers and Java applications, and, you know, they can personalize the output to their coding style.

Okay. Cool.

And we can say, okay. Well, how important is it that each database table is represented cleanly as a, you know, as an entity and, you know, or they can say, oh, well, it's really important that we end up in Java Spring Boot. Mhmm. Something like that, like a particular framework. And so, you know, the the the the key to, to to having a a happy customer at the end is not to do the project, show them the code, and then be like, are you happy?

And then

at the end, it's it's kind of like, you know, it's like a math question. It's like yes, no, yes, no.

Yeah. Okay. That makes sense. And then but do they have, like, tests and stuff? Do they usually do they typically have tests written in Cobalt?

No. No? Okay. Well, we haven't seen one yet. Okay.

But because I get what you're saying about, like, the evaluation of, like, if the the code quality and that, like, you know, it uses libraries they want to use and stuff. But Yeah. How do they know if it actually, like, does the same thing that the Cobalt does?

Yeah. So that's, a huge topic of interest to us, obviously, is making sure that when we're moving these very critical applications for the biggest companies that we don't break anything along the way. And there's plenty of examples of companies that have actually received pretty substantial fines for getting this wrong Yeah. In the process of migrating their tech.

Because we could be talking about finance, like banks and stuff like that.

Yeah. 100%. Like, you know, the regulator sees that suddenly, you switch over your system and half your customers can't log in to their online banking account the next day, you're gonna get fined 1,000,000 of of dollars. So it it's it's it's really important that we demonstrate, that the code performs the same after conversion as it does before. So, you know, how do we do this if there's no tests to begin with?

Yeah. Yeah.

So what you know, we got a mixture of techniques. I mean, you know, technically, we're we're using a lot of the the classic techniques for, generating tests, but, you know, where the customer can provide us with data, that's very helpful because we can use historic inputs and outputs to create Okay. Cool. For the code when it's a batch system. For online systems, which are kinda more like I mean, when you go to, check-in at the desk Yeah.

That makes sense. This seems very it's like it's very interesting. It's like it seems so much harder in some ways, but then probably you have the benefit is that not many people would be mad enough to try and Yeah. Help solve such a hard problem.

Yes. Yeah. So it is it is a funny one. It's it's kinda mad. It's also slightly detached from, I think, the the crazy hype of, like, coding agent stuff at the moment in a funny way.

Yeah. And what what is the vision as well? Because I I guess you people ask you this. It's like, once you've once you've fixed all the COBOL in the world.

Well, then we convert all their Java to somebody else. Right?

Okay. Yeah. Yeah. Yeah. That that makes sense. There's always gonna be people that are, like, modernizing.

There's a lot of COBOL. I mean, that's the first thing. Right? There's, like, billions and billions of lines of COBOL out there. So it'll take us a very long time to convert all of that. And at the same time, there's, you know, successive waves of technology. I mean, flow was new not that long ago.

Yeah. That's true.

Yeah. Now it's something that somebody's trying to buy a solution to convert away from. So Yeah. You know, these things, I I don't think, you know, I don't think I see programming languages, converging on a single one anytime soon. So as long as that remains true, there's always gonna be, you know, work to be done.

Yeah. And then build

on that relationship to see what else, you know, what other problems we can solve.

That makes sense. So it's not actually just like a one like, it's not just like, we're gonna migrate this thing and then that's done. It's like a it the it's a start. It's the beginning of a relationship.

Yeah. Definitely. Even though today, like, our only product is

the code

translation part. Yeah. But it's, you know, it's valuable enough that we can build a business just out of that. Mhmm. And the rest of, you know, the the other products that we can build, you know, this doesn't have to turn into, like, product 1 of 40 products that Bloop offers for this to be a big opportunity.

Yeah.

To not, you know, then help solve other problems

Yeah.

That they also face.

Yeah. That makes sense. Maybe my question is kind of, like, naive in a sense that it's like when you hit just because you aren't faced with like, I am not faced with, like, COBOL every day and, like, mainframes. It's, like, easy to, like, compartmentalize something that, like, you're gonna be able to just, like, fix all of this Cobalt and, like, you know, and then it's it's done. So that that makes a lot of sense.

Need multiple needles in the haystack. Needles in the haystack. Sorry.

Your multiple needles in haystack, benchmark. What dev tools are you excited about at the moment besides bloop? Dev tools am I excited about? Especially, I mean, AI ones. They've gotta be AI. Yeah. Yeah. Yeah. For for you.

I think okay. This is gonna be a really self serving answer. Basically, I think dev tools are best at tasks where there is it is it is possible to deterministically evaluate the result. So what I mean by that is where you could basically run a language model infinitely and test its output deterministically to tell whether it has succeeded or failed. Yeah.

And I guess, like, the final question maybe is like, do you think that what what do you think development is gonna be like in, say, 10 years' time?

10 years' time. You know, it's funny. I think we wrote a our first pitch deck, we had this kind of, you know, like, evolution of mankind type Yeah. Photo with eventually writing code using natural language somewhere up right at the end at 10 years, and it's happened in 2 years. So, I mean, my record for predicting what's gonna happen in 10 years is is very poor and is probably an underestimate is what I've learned.

Yeah. I thought it was coming back to that. It was like it's the analogy of, like, there's all this cloud computing stuff. Yeah. But everyone's still the COBOL is locking people into Exactly. On the mainframes. It's

The world's gonna be crazy in 10 years time. The the the ways in which, you know, software is written, you know, is gonna be so much more efficient. But if you're stuck, COBOL. So this is the good to action.

You're gonna be feeling like a Dorset knob.

You're gonna be feeling like a Dorset knob. So full circle.

Louie, thank you very much. I think that was, that was great fun, and very, very interesting. Where can people learn more about if someone's got a load of cobalt cobalt, how can they reach out to you?

Yeah. I'd be amazed if you're like the the I don't I don't know. Yeah. I don't wanna undersell the podcast. Maybe you've got, like, a huge cobalt fan base. If you have

a friend who's struggling with a cobalt problem.

If you have, like, a great aunt or uncle who he's, like, working with COBOL and really wants to retire, at bloop.ai, please, you know, reach out to us. We're happy to have a chat. And, obviously, you know, we see a lot of people going through these migrations, and we could tell you about what we've seen that works and, what doesn't work. And, you know, often, it's not a case of actually jumping right into a modernization project. It's just building a relationship, understanding, you know, what AI really brings to the modernization space.

yeah. Amazing. Well, thanks, Louie, and thanks, everyone, for listening.

Thanks so much.