Tern's Open Beta

“So what’s the plan?”

That’s the question that inspired us to build Tern. This is what you get when you have a genuinely good idea. You’re being asked this because whoever (your teammate, your boss, your CTO) agrees it’d be great to finally get off Angular, or migrate that home-built auth system, or switch from REST to GraphQL. So they expect you to have a plan.

Migrations are particularly challenging, because you’re not adding, you’re replacing. The bigger your codebase, the more work it is.

Tern figures out that plan for you. It reads through your codebase, with patience and care. You get plans so good, even an AI can execute them.

Today we’re launching our Open Beta. Our goal is to simply help you understand what needs to be done. That’s always been the bottleneck: sitting down and reading the material.

AI that reads code

LLMs in developer tools are mostly about generation: write this function, vibe this app. But when you ask an AI to write code, it doesn’t have to be your code. It can write bash scripts that explore, or python that organizes.

It can write code to read code.

That exploratory code can find what’s actually hard about a migration. Most migrations have one or two things that are way harder than the rest. There’s some weird coupling, an edge case that doesn’t fit the documented pattern, or a shockingly diverse set of usage patterns of a little-known API. The default plan of “just start migrating” works fine until you hit those. Finding them early is what matters, so you can start with them in mind instead of discovering them halfway through.

AI makes that exploration cheap enough to actually do.

The question is: what do you do with all that information?

A plan that runs

Historically, you’d dump all that information into some ad hoc pile. A spreadsheet tracking files to change. Jira tickets for each component. These tools weren’t built for migrations.

This is Tern.

Tern explores your codebase. It reads the changelogs, traces the dependencies, maps every call site, then builds a plan. Not a doc. A structured set of tasks, each one tied to actual code. “Migrate all save() methods” comes with a search that finds all 76 instances. You can see exactly what needs to change before you start.

The plan is shrink-wrapped to exactly what your codebase needs. Libraries with extensive usage at the core of your product get shim libraries and an incremental cutover strategy, but API changes that affect a single admin panel get a single “just do it” task. Tern spends its tokens on what matters to you.

And because the plan is built on searches that run against actual code, it stays true to your codebase. Merge main, re-run the searches, see what’s new. This is what makes planning migrations actually tractable.

Getting started

So: what’s the plan?

You’ve got one. Here are the 200 files that need changes. Here are the 15 that are tricky. Here’s what makes each one hard. Not a Google Doc, but actual work, mapped and ready.

That’s what ships today. But when every task is this specific, when every instruction has this much context, execution becomes the obvious next step. We’re building that now.

What will you migrate?