If you want to learn more about Opus 4.5, Kieran Klaassen and I are hosting a Claude Code Camp on Opus 4.5 exclusively for paid subscribers on Friday (that’s tomorrow) at 12 p.m. ET. Sign up and reserve your spot.—Dan Shipper

Was this newsletter forwarded to you? Sign up to get it in your inbox.

---

Humans have always had two main intuitions about what we’ll find when we travel to the end of the earth:

1. An edge where the known world falls off into nothingness, chaos, or monsters
2. A new vista where unexplored, lush, and perhaps perilous territory extends toward a new horizon

The first is terrifying, a place to be avoided. The second represents possibility and an entirely new world.

These days most new AI model releases are incremental. Sometimes, though, a new model brings us right up to the edge of the known and allows us to take a peek at what lies beyond. Is it nothingness, dragons, or a new horizon?

Anthropic’s Opus 4.5 is one of those models, and I’ve been peering over the edge for about a week now. Here’s what’s over the horizon:

1. We are in a new era of autonomous coding. You can build astonishingly complex apps without looking at a single line of code.
2. **Prompt-native apps are now possible. **You can use Opus 4.5 as a general-purpose agent to power your app’s features. This turns new features into an exercise in prompt-writing, rather than coding.

The infinite vibe coding machine

The first step change with Opus 4.5 is the amount of autonomous coding that is now possible.

Over the last week, I built an iOS reading companion app with a comprehensive suite of features. It’s the kind of thing that previous models could one-shot as a demo, but would start to trip over themselves after a while if I didn’t sit down and look at the code myself. I started writing the app with Anthropic’s Sonnet 4.5 and OpenAI’s Codex, but gave up pretty quickly because they were getting lost in loops of errors that I didn’t have time to debug.

Opus 4.5 is different. I didn’t write a single line of code. I didn’t even look at the code. I just talked into my computer with Monologue. And out came a complete reading companion.

I can photograph any book page, and it identifies the work, analyzes the passage, and connects it to larger themes—with zero clicks. I can tap a character name for a spoiler-free summary of everything the character has done so far in the book. It even automatically researches and downloads the original text (if the book is in the public domain) plus academic secondary sources to help with its analysis, and writes a custom introduction for each book to tell me why I might be interested in it.

This reading companion app would have taken three to six months of developer work pre-AI. (GIF courtesy of Dan Shipper.)

It does more than this but phew. That is a lot. And let me remind you: I have no idea how the underlying code works, I did not get stuck in an infinite loop of errors, and generally the app is pretty much ready for people inside of Every to start testing.

My estimate is that, pre-AI, this would be three to six months of developer work. Pre-Opus 4.5, a full-time developer would have to focus on it for a month or so to get right, based on my experience. Today, it’s something I can do in my spare time between meetings.

But speedier, less error-prone, more autonomous coding is only half the story. What surprised me wasn’t just that I could build a beta-quality app in a week with Opus 4.5. It’s also how the app works under the hood. Because I didn’t just write the code with Claude—instead, Claude *is *also the code.

Pitch like the pros, without the production time

Need a great presentation but don’t have the time or resources? Try Pitch, which helps you generate a deck in a fraction of the time. You’ll have access to everything you might need: designer-quality templates and brand libraries, cloud-based editing and comments, and high-quality video embeds. With their latest AI features, you’re now able to instantly adapt messaging, maintain brand tone, and upgrade visuals, all while keeping creative control. Win work with half the time spent.

Prompt-native apps

Opus 4.5 now lets us build features from prompts, not code. This is the second biggest breakthrough—a shift that will unlock a new category of what I call “prompt-native apps.”

Writing a traditional application is like writing a recipe. For every feature, you spell out each step in excruciating detail: First do this, then check for that, handle this edge case, then return your result. The computer follows your instructions exactly—so you have to think of everything.

Prompt-native development inverts this entirely. Instead of writing the recipe, you hire a chef, Opus 4.5. When a user puts in an order, the chef figures out how to make it.

The core of a prompt-native app is a general-purpose agent powered by Opus 4.5. Each feature of your app (like the passage analysis function from my reading companion) is just a prompt that tells Opus what you want it to accomplish, and gives it a set of tools that it can use to get there, like web search or access to your photo library. For example, you might tell the agent “analyze this book passage without spoilers”—and it figures out how to do that.

To make this more concrete, let’s talk about an example from my reading app. One of my favorite features is the reading profile: It automatically goes to your phone’s camera roll to identify books and articles you’ve been reading over the years from photos and screenshots. Then it uses those to write a guide for itself about what you like to read:

The reading companion app gives a profile of the user’s reading habits based on screenshots. (Screenshot courtesy of Dan.)

Writing this as a traditional program would’ve been daunting. You’d need to write an algorithm to efficiently scan through a gigantic photo library, identify photos that are *likely *to contain text, convert them from images to text, collect them, and summarize them into a coherent, interesting synthesis. Each of these steps is complex, and putting them into sequence is complex. As a result, the code they’re written in is brittle. If the requirements change—say, you also want to scan PDFs or pull in newsletters from my email—you’re looking at a lot of work.

A prompt-native app is different. Because the app is really a general purpose agent, if you want to pull in newsletters from email, you give the agent access to your inbox and update the prompt to say, “Also look for Substacks and newsletters.” The agent will probably do this poorly the first time you test it, but that’s okay because you can improve it just by editing your prompt until it works.

Prompt-native apps are not totally new—I consider Claude Code the paradigmatic example of a prompt-native app. Most of its core functionality, like slash commands and subagents, are really just prompts, cleverly disguised as simple features. This is what makes it so powerful.

Opus is the first model reliable, quick, and powerful enough to make being prompt-native accessible for a broad range of software.

What prompt-native apps tell us about the future of software

Prompt-native apps are inherently flexible and extensible. It’s much easier to rewrite or add prompts than it is to modify or add code. You can move more quickly when you’re in the early stages of application development because it’s easier to code features in the first place *and *change them in response to feedback.

Now, your users can modify and discover new features on their own—after all, if features are just prompts, all your users need to add or change themis the ability to write English. This is going to be a core feature of software in the allocation economy: Instead of sending in bug reports, hardcore users will send in updated prompts (or perhaps even full features) to help improve the software they love.

Of course, this doesn’t mean all code goes away. The tradeoff of a prompt-native architecture is speed, predictability, and cost. Each time someone uses a feature in your app, it’s calling an agent to do work—which costs money and takes time. And everyone who uses AI knows that sometimes the same prompt produces wildly different results.

Over time, these tradeoffs will improve—the costs of using models are dropping rapidly, as speed is increasing dramatically. But rather than either-or, I think prompt-native will be where many features start, and they will be hardened into code over time as they stabilize. Developers can use prompts to explore and iterate; once a feature’s requirements stop changing, it can crystallize them into traditional code for speed and cost savings.

I’ll have more on Opus 4.5 and prompt-native apps over the next few weeks. But for now I’ll leave you with this:

If you haven’t taken time to explore this new world yet, it’s a good time to start walking. There are fewer dragons than you think, and the view is beautiful over the horizon.

---

Dan Shipper* is the cofounder and CEO of Every, where he writes the Chain of Thought column and hosts the podcast* AI & I. You can follow him on X at @danshipper and on LinkedIn, and Every on X at @every and on LinkedIn.

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

We build AI tools for readers like you. Write brilliantly with Spiral. Organize files automatically with Sparkle. Deliver yourself from email with Cora. Dictate effortlessly with Monologue.

We also do AI training, adoption, and innovation for companies. Work with us to bring AI into your organization.

Get paid for sharing Every with your friends. Join our referral program.

For sponsorship opportunities, reach out to [email protected].