Louis Knight-Webb from Bloop.ai - the YC startup turning COBOL into Java
One of Bloop's customers told Louis Knight-Webb they had a billion lines of COBOL in production. He didn't know what COBOL was. His startup pivoted twice — from code search, to enterprise code search, to converting mainframes to Java — before finding a problem nobody else wants to touch.
Louis Knight-Webb is the co-founder of Bloop, which started in 2021 building code search for GitHub Copilot's predecessor era and has since pivoted into converting COBOL mainframe applications into modern Java. Along the way it survived Copilot launching a month into Y Combinator, then GitHub bundling chat-based code search directly into its own product.
We get into why large language models are fundamentally bad at COBOL, how Bloop actually structures a codebase conversion when there's no test suite and nobody left at the company who understands the original code, and why he thinks this is a genuinely durable niche precisely because it's insulated from the current hype around general-purpose coding agents.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
Bloop didn't start out doing COBOL migrations. What was the original idea?
We started in 2021, in a very different world — there was no GitHub Copilot yet, and the biggest open-source model at the time was GPT-2. My co-founder Gabriel is a machine learning researcher; my background was more classic software development. We were trying to solve code understanding: back then you'd 'raw dog' VS Code, typing everything or copying from Stack Overflow. So we downloaded GitHub, chunked it into 256-token pieces, fine-tuned a small embedding model on code, and built a VS Code extension where you could type something like 'how do I make a Stripe payment' and it would find the most relevant code from GitHub. We raised a pre-seed on that, got into Y Combinator — and about a month in, GitHub Copilot launched, and it was just a better product, trained on all the world's open-source code with much better personalization than our search-based approach could offer.
How did you pivot from there?
We moved from open-source code search into enterprise code search — helping engineers at huge companies with massive codebases find and share code with each other, so you could type 'how do we do payments' and it would surface that you use Worldpay, who last implemented it, and their documentation. That made more sense in enterprise, because fine-tuning models on rapidly-changing enterprise code is expensive and needs a real training pipeline, so a search-based approach fit better. But right around the ChatGPT moment, we saw a wave of direct competitors — code search is a natural thing for developers to build the moment a new model API drops. GitHub Copilot also moved into the sidebar with a chat experience similar to ours, and in commercial conversations we kept hearing the same feedback: we didn't have enough differentiation against a 40-product bundle from GitHub. It's also genuinely hard to prove the productivity benefit of a copilot-style tool with hard numbers, and I don't think we did a good enough job of that compared to how much GitHub has invested in white papers and research to communicate that value.
How did you end up in COBOL specifically?
It started with conversations we were still having about code search. Some enterprise contacts were talking about legacy code in the context of JavaScript moving to TypeScript, or Flow to TypeScript — one company forecast it would take a decade of developer time to port Flow to TypeScript, because the type systems don't map one to one. At some point in one of these conversations, someone said, 'oh, we've got a billion lines of COBOL in production, can you do that?' And honestly, we had to ask what COBOL even was. It turned out to be a completely different environment: the mainframe is its own architecture, with its own chips, operating systems, languages, IDEs, and protocols — everything that exists in modern software development has a parallel-universe clone in the mainframe space, like Mario and Wario.
Why can't you just paste COBOL into an LLM and ask for Java?
There's basically no COBOL in open source, and the biggest models are trained on GitHub and open-source code — that's why they're excellent at Java and JavaScript, because there's so much of it to train on. The same task performed on COBOL is much less accurate than the same task on Java. We actually tried generating synthetic COBOL and fine-tuning open-source models on it, but what we could achieve was a drop in the ocean compared to what's needed. Traditional transpilation — mechanical line-by-line conversion — is the other option, but nobody likes machine-generated Java: it doesn't represent things as clean objects, doesn't take advantage of the language's standard library, and reads nothing like code a human would write. If you want to format a date in COBOL, you write a whole program to do it, where Java has a one-line standard function for it.
So what does Bloop actually do instead?
We combined both approaches: we statically transpile COBOL into Java first, but we optimize that transpiler to produce output that's chunked and structured in a way that makes it easy to then run an LLM over it to refactor into something readable, modern, and performant. So there are two halves — the transpiler, and agentic refactoring on top. Because these codebases are millions of lines and even the best models only have around 100k tokens of usable context before performance degrades — really more like 30k before you see real degradation — we have to work incrementally, making many smaller targeted refactors and merging them. LLMs are very good at spotting patterns like 300 lines of machine-generated Java that's really just formatting a date, written slightly differently every time because every COBOL engineer implemented it by hand, and collapsing all those permutations down to one standard library call. We can reduce codebase size by at least 50% just through deduplication, since these systems have been worked on since the seventies by developers who no longer know the codebase and default to writing something new rather than reusing an existing module.
How do you prove the converted code actually behaves the same as the original, especially when there's no test suite?
There usually are no tests, because these programs have been in production so long they're just assumed to work, and people are afraid to touch them. Companies have received real fines for getting migrations wrong — if a bank switches systems and customers can't log into online banking the next day, that's a multi-million dollar problem. We use a mix of techniques: for batch systems, if a customer can give us historic inputs and outputs, we generate tests from those. For online systems — like the green-text screen an agent looks at when you check in for a flight — we record sessions and use some robotic process automation to generate tests from that. We also use language models to generate additional tests on top of the transpiled Java, which matters because the LLM-driven refactoring step will occasionally make mistakes and cause test failures, so we need as much coverage as possible to catch that.
How do you scope a project when the customer might not even fully understand their own system?
Typically people come to us already committed to moving from COBOL to Java, so we don't spend much time persuading them. We take a small, isolated chunk of the codebase, convert it to Java, and deploy it to the cloud, choosing a cluster that's representative of the wider system — where it touches a database, writes a file, makes a network request. That pilot is really about properly scoping the rest of the project, because a customer often has only one engineer left who understands the COBOL and can make occasional small fixes, which makes it hard to have a real conversation about timeline or cost otherwise. We put the pilot into a fixed-price package we effectively insure the customer against — if it takes us longer, we eat the cost. We've yet to see a customer not continue from a pilot into a full project, and it's a much quicker, often cheaper alternative than what they'd otherwise be considering with a human team.
Why does this niche feel insulated from the current hype around general coding agents?
None of our customers are seriously considering the generic coding agents on the market, because the fundamental problem is the same one we started with — there just isn't much COBOL in the training data, so a pure LLM-based approach doesn't work here. If you want to enter this space, you have to be willing to build an actual transpiler, which is a huge undertaking: there are countless edge cases, the documentation is bad, and there are different dialects of COBOL. That's a real moat against the wider excitement around agents, because it's a limitation specific to legacy code that a general-purpose coding agent can't just improve its way past.
Is COBOL-to-Java the whole business, or a way into something bigger?
There's an enormous amount of COBOL out there — billions of lines — so it'll take a long time just to work through that. But I also don't think programming languages are converging on a single one anytime soon, so there will always be a next wave: Flow was new not that long ago, and now people are trying to buy a solution to convert away from it. Even after conversion, applications need ongoing maintenance and updates to newer Java versions, and there's room to build new functionality. I see COBOL-to-Java translation as a killer wedge into the enterprise — proof to very risk-averse, very large companies that we can solve a genuinely hard problem — and a relationship we can build on to solve whatever else they need next, even though our only product today is the translation piece.