You have to decide

Today’s AI coding tools aren’t built for engineers.

It’s amazing how easy it is for absolutely anybody to build a new app with Bolt and Lovable and v0. Github’s marketing points towards “the next billion developers.” We’re heading towards a future where product managers and designers can fire up one of 50 AI IDEs and have meaningful tools to prototype and experiment in codebases, large and small.

But these tools aren’t built to do engineering. They steer you away from the act of designing systems and the craft of building software. They undercut your ability to build products that endure.

Engineering is so much more than creating lines of code. It’s the exploration, the planning, and the million little choices that happen continuously throughout every ambitious migration or major feature.

AI isn’t helping with that. Yet.

It matters how it’s built

There’s a paradox here I can’t square. Ask how the most cracked coder today works, and you’ll hear breathless stories of half a dozen agents and manic multi-tasking, opening dozens of PRs in random order.

That doesn’t make sense to me. The best engineers I’ve met demand focus and flow. They think deeply about a single problem, poring over details before they solve it. They obsess over design.

They do this because bad software design is cartoonishly expensive. There’s no shortage of numbers that quantify “tech debt,” as fuzzy as the term is. Stripe found devs spend 17 hours per week dealing with “bad code”. That’s an average across all companies; what must it feel like to work somewhere that’s worse than average?

More commonly, though, it simply kills our ability to innovate. Every successful startup spends meaningful time undoing bad early design decisions. Not everybody is so lucky: most new products don’t make it, and sometimes it is an engineering problem. It hurts to try to succeed despite an ill-considered database schema or a too-clever tech stack, but it’s worse to be forced to pause for a rewrite 4 months before the cash runs out. Getting the bones wrong leaves deep scars.

Which makes the simplest explanation much more confusing: it sure seems like a lot of people have stopped doing engineering. AI has gotten strong enough that people are fully delegating the engineering to the tool. We’re in a renaissance of tinkering and prototyping, but it’s easier than ever to skip the part where you plan for success.

Describing the user experience and running acceptance tests misses the part where you care about how the thing is built. That feels wrong.

The decisions are the craft

I’ve been a part of a lot of gnarly, ambitious projects, and the hard part is always making the decisions. My team of 20 engineers stalled for a year before deciding what order to stand up services in AWS GovCloud. Tern’s podcast guests are engineers who spent real cycles deciding which product should migrate to the new datastore at Datadog or how functional a Python 3 branch needed to be before merging at Lyft.

It’s scary to make these decisions, because the problem is always under-specified. There are real constraints from the business, the code, production, and more, but there’s almost always more than one viable solution.

The decisions are fractal and continuous, too. Sometimes you just have to decide to not fix anything while you’re in there. Sometimes the hardest things to learn are about the running system: what DB tables, logic bugs, or race conditions are actually load-bearing. There’s always something to learn, until the last feature flag is flipped.

Most AI output looks viable because you skipped the part where you learned about the problem. Today’s tools dive in immediately. They know how to change code, so they change code, even if they wrote a little todo list first. There is no space for you (or the AI) to make thoughtful decisions.

Learning and leverage

The best developers I know use AI weirdly. They build mini-products, wrapped around how their brains work, to wrangle the complexity of their systems. To learn and share.

Some of the most interesting ones:

An infra engineer who writes AI-readable runbooks for her team to query the state of kube clusters while updating services
A tooling engineer who runs a bot to research and document surprising features of each of dozens of repos
A security engineer that wires together 5+ MCPs to identify which auth system callsites are safe to refactor, and how
A product engineer that sets up EM, PM, exec, and engineer agents identify weaknesses in RFCs

The common thread is that they’re using AI to learn more. They’re finding ways to see more data, as quickly as possible, and they’re making higher quality decisions faster. This has always been the bottleneck, as the software ecosystem becomes more complex every year. There’s a step-change happening right now though, as every developer can suddenly churn out 2x-5x the number of lines of working code. The only way to see through that higher noise floor is to look at that same toolkit with a different lens. We have robots that can read novels in seconds. It’s on us to use them.

But even beyond interrogating and synthesizing the data, they’re using AI to influence. It’s not just decisions in a vacuum; they’re setting up structures that allow everybody around them to ultimately succeed. They’re setting the direction for what to build and how to build it, leading by example from the front.

They’re building amazing things, before they even write a line of code.

Multiplayer AI

The software of the next decade will need to be fundamentally more ambitious. Users will demand it. What seemed like magic a year ago already feels inconsistent and sloppy (though Apple’s notification summaries were never good). As a developer, I’m excited to find the best way to use these new tools, but as a user, I’m eternally discontent. I expect more polish, more depth, and more thought, simply because I know it’s possible now.

Meeting that bar will require a different approach than even today’s most AI-forward developers have found. We need to create a space for the important work of making great decisions, putting AI to work during the most critical part of building. If we don’t, we’ll lose the ability to create truly ambitious software.

This space exists at the beginning of the creative process, with deep ties into the systems and people that build products.

It starts with Exploration. Tools to synthesize what’s going on, from the code on your machine to the running state of production to any piece of information available on the internet.
It creates Plans, which organize the atomic units of work. Tiny, self-executing programs with rich context, tied natively to the code it needs to change.
It understands Priority. Not every plan is shovel-ready, so it understands sequencing, team structure, and how to play nicely with the chaos of a fast-moving codebase.

It’ll need to feel a little like project management, tied to your source control, that can get at your observability data. It’s not any of those, though; it’s a place for doing engineering with AI as a powerful tool.

That’s the space we’re creating at Tern.

Building Tern, starting with migrations

Migrations are the perfect problem to start with, so that’s what Tern does today. You need to upgrade Python, React, or Django? Migrate to a new design system or the next generation auth microservice? Let our agent do that. It’ll deeply read your code, pore over the docs, figure out all the dependencies and pull out the breaking changes.

This ultimately results in a self-implementing plan:

It executes itself. Each task runs a mix of codemods, tuned LLM prompts, and migration-specific scripts with no further user input.
It’s uniquely grounded in your code. It only lists the changes that matter to your code, without trying to modernize everything at once.
It’s durable and shareable. Progress and sequencing is visible to everybody.

As this becomes the primary way to develop, we’ll not just steer the AI into crafting good code, but we’ll create wildly better software. Every engineer will get to stand on the shoulders of giants, creating products on timelines that seemed unachievable even just 2 years ago.

You can decide to build great software. If that’s something you want to do, let us show you, starting with that migration you’ve been putting off. Get in touch.