Why "English is the New Coding Language" is Only Half the Story

The future of building with AI is less about chat conversations and more about visual, layered creation.

One week ago today, we launched Opal, the culmination of many different beginnings across various teams, each passionately working on related efforts for months, sometimes years. It’s undergone many evolutions, and if you were part of the process, thank you for building through it all (what an adventure!).

If you’re familiar with the popular product lifecycle drawing, this launch was very much in that first, messy section. While incredibly exciting, the most important part to me is that this is still just the beginning.

Shipping this first version has given me a chance to reflect on why this space excites me so much. I keep coming back to one of the biggest hypotheses driving AI, a phrase famously articulated by Andrej Karpathy: “The hottest new programming language is English.”

On one hand, I deeply believe in this statement. When I first joined Google Labs, I worked on the PaLM API (now Gemini API) and MakerSuite (now AI Studio). We called it MakerSuite because we believed generative AI would unleash a wave of “Makers” by enabling anyone to build things using plain English. What tool would the rural farmer in Northern Ontario make for herself? Or the teacher in Kansas? That question continues to give me immense excitement.

It turned out we were a little premature. We eventually shifted focus from Makers to Developers, but that mission—to democratize building for anyone—never left my mind.

Fast forward to today, and we're living in a world of vibe coding and instant apps, with new products emerging constantly. But one thing most have in common is that they are seen as places to "vibe code" because they still support exporting to code.

While powerful, this isn't what all users want. During a recent trip to visit family in Canada, I caught up with folks who aren't in the tech bubble. They are consultants, real estate agents, and small business owners. They all had incredible ideas for apps to help their businesses, but they didn’t want to code—not even "vibe coding."

This brings me back to the mantra that "English is the new coding language." It’s powerful, but it doesn’t sit quite right. Because there’s another saying that is just as important: “a picture is worth a thousand words.”

The Limit of Conversation as a Blueprint

There’s a lot of excitement around vibe coding tools that lean into conversation as the primary way to build. While this is one approach, it feels like something is missing. A chat transcript is rarely the most effective final blueprint.

Let's start with a real-world example. Imagine two PMs brainstorming a better bill-splitting app. Their chat transcript would be a meandering path of ideas, constraints, and changes of mind.

"Okay, new app idea: a 'smart' bill splitter. Before the bill comes, you take a photo of the table. The app uses visual recognition to match the food in the photo to the items on the bill and automatically assigns them!"

"That sounds cool, but what about edge cases? Two people order the same wine? Drinks that were cleared away? It feels more like a gimmick than a core feature."

"You're right. Let's scrap the photo idea. What's the actual worst part of splitting a bill? The slow, one-person-at-a-time input process."

"Exactly! But you know... even after we split the bill, I still have to Venmo request Sarah for the concert tickets from last week, and you owe me for coffee yesterday. The real problem isn't just this one dinner, it's the constant, messy ledger of who owes what in a friend group."

"100%. The bill-splitting is just a small feature. The real product is a shared running tab for a group. A way to track all the little social debts without the awkwardness."

"Whoa, let's forget the bill-splitting app entirely. Let's build a 'Group Tab' app. Anyone in a friend group can add an expense—dinner, tickets, groceries, a weekend trip—and the app just keeps a running balance. You can settle up once a month. No more twenty tiny Venmo requests."

"YES! That's a way bigger, much more valuable idea. Solved."

The transcript is the messy process of creation. The initial, "magical" idea is now completely irrelevant. The valuable output we actually want is a spec for the collaborative, link-based splitting feature. A long conversation history, full of dead ends and invalidated ideas, isn't the most effective final blueprint.

But this reveals a more critical point: the end output also isn’t enough. You can't look at a final UI or the code behind it and fully understand the why—all the trade-offs, discarded ideas, and strategic reasoning that led to its creation.

This means both the initial chat history and the final product are incomplete records of intent.

This is where the idea of an evolved, modern "spec" becomes so crucial. It’s the durable, lossless artifact that truly aligns everyone around the product that should be built. It serves as the source of truth that captures not just what to build, but why - it’s the document that product, engineering, legal, and policy can all read, debate, and sync on. It’s also immensely helpful when it comes time to update and iterate.

Finding a way to bridge the gap between the fluid, creative process of ideation and the need for a clear, well-reasoned, and lasting blueprint is one of the most exciting challenges for product builders today. This is clearly an evolving space, and I don’t think any product has truly nailed this “vibe making” experience yet - which makes this product space so appealing to play in.

Beyond Chat: A New Class of "Prompt Apps"

Here’s the other challenge: many ideas I have these days are for a new class of "prompt apps," where the magic isn't in a clean UI, but in a sophisticated workflow of prompts behind the scenes that enable new types of user experiences and product capabilities.

Here’s a simple app I made in Opal to help with my salad recipe book: Not So Simple Salad Pix. The concept is simple: upload a salad recipe, and it generates a realistic, overhead shot of the assembled salad.

Previously, I had been manually copying and pasting prompts between Gemini and Imagen. With Opal, I was able to string together a simple visual workflow:

This visual view works so well because the app itself is simple; the complexity lives in the prompt inside the "Create Image Prompt" node. Being able to edit that prompt directly in a visual editor unlocked a new way for me to iterate on exactly how I wanted my app to work.

This is a new class of "thing" that's hard to describe. Is it an AI mini-app? An "appified workflow"? The line is blurry, and that's exciting.

Finding Your Abstraction Layer

This brings me to the core of how I see things evolving. People think and create at different levels of detail, complexity, and abstraction—text, prompts, flowcharts, and yes, code. The tools we build should meet them where they are.

This philosophy is what we're exploring with Opal, which allows for building at two distinct layers:

• The Vibe Maker: You can start with simple natural language to generate a working app in a single shot. This is for making something fun, interesting, and ephemeral, lowering the bar for anyone with an idea.

• The Prompt Chainer: For those who want more control—the builders who think in systems—there’s the visual editor. You can dive deeper, refine the prompts, customize the logic, and truly own the creation. This raises the ceiling for what’s possible.

As we continue to build in public and learn from our users, I'm excited to see the use cases emerge. By expanding the number and type of people who can build, the hope is that we're going to see an explosion of interesting, useful, and wonderfully weird products that we couldn't have imagined before. The future is bright, and it's definitely more than just a chat box.