Code is cheap. Context isn't.

Writing code stopped being the hard part

For decades, the scarce resource in software was the ability to write code. Teams, roadmaps, hiring plans and tools were all built around that scarcity. A good idea waited in a queue until an engineer had time to turn it into code.

AI agents changed the economics. A first version of a change now takes minutes, not days. Engineers ship more than they used to. And people who never wrote code before (product managers, designers, founders) are writing it now.

The people who know what to build can now build it

This is the part most teams haven't absorbed. The PM who has talked to forty customers about the billing page knows exactly what should change. The designer who has watched users miss the same button knows exactly how to fix it. Until now, that knowledge had to be translated into a ticket, queued, and interpreted by someone else. Something always got lost on the way.

That translation step is optional now. Plenty of PMs and designers are already shipping changes with AI tools, quietly, whether or not their company has a plan for it. Their company should have one.

The bottleneck moved to context and running

If writing code is cheap, where do the days go? Two places.

Context. An AI agent can read every file in your repository and still not know your product. It doesn't know which of three billing paths customers actually use, that team plans never show the tax ID field, or that the helper it's about to write already exists. So it guesses, and the guess is plausible enough to pass a quick review. Most "the AI wrote bad code" stories are really "the AI didn't know" stories.

Running. A change that only runs on one laptop hasn't been shown to anyone. The PM can't click it. The designer can't check it on real data. The reviewer reads a diff and imagines the rest. Staging is one server, shared by a team that now produces far more branches than it used to.

Fix those two, and the speed AI promised actually shows up.

Engineering becomes stewardship

None of this makes engineers less important. It moves where their judgment matters most.

When more people and more agents write code, someone has to own what the codebase is: its architecture, its conventions, its guardrails, and what gets merged. That's engineering's job now, and it's harder than the old one. Engineers should spend less time turning tickets into code, and more time deciding what good looks like and reviewing what arrives.

Teams that treat non-engineers shipping code as a threat will get shadow code: pasted .env files, shared staging passwords, and changes nobody reviewed. Teams that design for it will get more done, and do it safely.

Demos are not products

A wave of tools can generate a new app from a prompt. They're impressive, and they're great for starting something. But most companies aren't starting something. They have a product, customers, and a codebase that's years old and messy in the specific ways real codebases are.

Tools that only work on fresh, generated code produce apps that can't grow, and those end in a rewrite. The bigger opportunity is changing the software that already exists: safely, and by more of the people who understand it.

Safety is what makes speed possible

Letting more people ship doesn't mean lowering the bar. It means building the bar into the system:

• Every change runs in its own isolated environment, with its own data and its own secrets.
• Unreleased work stays private, and sharing it is a deliberate choice.
• Nothing reaches production without the same review as everything else.

With those in place, saying yes is easy. Without them, saying no is the only responsible answer, and it's the answer most teams are giving today.

What we're building

Ensemble is a cloud workspace for shipping changes to real codebases.

Ensemble Context gives every AI working on your code an understanding of your product: a codebase graph and product knowledge, kept current, that agents ask instead of guessing. Ensemble Previews give every change a running copy of your app, with its own data, at its own URL, private by default. Ensemble Studio puts both in the browser, so a PM, a designer or a founder can describe a change, watch it run, and hand an engineer something real to review.

We believe the best software teams of the next decade will be the ones where everyone who understands the product can change it, and engineers keep it true. We're building the place where that happens.

Scott Kapelewski, founder, Ensemble
September 2026