Transcript: ‘The AI Sandwich: Where Humans Excel in an AI World’

The transcript of AI & I with Every’s Kieran Klaassen is below. Watch on X or YouTube, or listen on Spotify or Apple Podcasts.

Timestamps

1. Introduction and the AI sandwich metaphor: 00:00:52
2. What compound engineering is and how it’s evolved: 00:02:33
3. The “work” phase of agentic coding is essentially solved: 00:04:27
4. Why humans belong at the beginning and the end of an AI workflow: 00:06:27
5. Dan’s argument for why agents can’t change frames—and how this will keep us employed: 00:11:06
6. Full automation remains a moving target: 00:16:51
7. Musical composition as a model for human-AI collaboration: 00:23:21
8. Find your place in an AI-accelerated world by leaning into what brings you joy: 00:26:39

Transcript

Dan Shipper

Humans are the bread in the sandwich, and the AI is in the middle.

Kieran

The AI is whatever you put on your sandwich. If you ship something or do something—if you want it to be your own—you cannot fully automate everything. It’s like art. If you want it to be yours, it needs to come from you or somehow be connected.

I believe it’s so important to do things you enjoy and love. It’s very important to make it feel great because the bar is high. The bar will always get higher. The beginning and the end—the middle can be automated pretty well. And Dan at some point said, “Oh, it’s kind of like a sandwich,” which was very funny.

Dan Shipper

Ki, welcome to the show.

Kieran

Hello, Dan. Happy to be here.

Dan Shipper

For people who don’t know, you are the GM of Quora, and you are also the creator of compound engineering—the engineering framework and plugin that everyone inside of Every uses, and that everyone who’s really coding with agents is at least aware of, if not using.

A pleasure to have you on the show.

Kieran

Thank you. It’s always great.

Dan Shipper

I love getting to chat with you and getting to work with you, because every once in a while you figure something out and I’m like, “Holy shit, that’s definitely the future.” And you just figured something out—along with Trevin Chow, who also helps out on compound engineering—that I think has massive implications for how programming works. And I think we can also translate that to the rest of AI and its impact on work.

One of the things you’ve been doing with this compound engineering plugin is you’ve rebuilt the engineering workflow for how you should work with agents. And in thinking about that—thinking about where a human is needed and where a human should not be present inside that process—I think you’ve found something really interesting and deep about how humans and AI are going to interact with work. Do you want to explain a little bit about compound engineering and the process you’ve created, and then also explain this insight about where humans fit?

Kieran

Yeah, absolutely. Compound engineering is a philosophy of doing engineering work. We’ve realized it applies to more than just engineering—it’s product work, design work, knowledge work, and other things. But how I built it was while building Quora. I had AI and was thinking: how can I use AI to do better work more quickly?

The initial version of compound engineering really evolved around four steps. The first is planning—you make a great plan so it’s very clear what you need to build and do. Then the work phase, where the agent does the work, implements it, and actually writes the code, does the design work, or whatever work needs to be done.

The third is review. Some slop comes out—or something beautiful comes out, one of the two—but how do you know it’s good? Traditionally there’s a code review, a PR queue, where someone says, “Hey, this can be improved,” and there’s some iteration going on there.

And then the most important step is the compound step. If anything comes up during the review or during the planning that feels like a good learning—something you’ll probably run into again—you can compound that knowledge back into the system. We store that as knowledge inside the repository, and agents can reference it the next time they go into planning, work, or review. They can see the mistakes they made before so they won’t make them again. That’s the most powerful thing in this plugin.

But we started to realize more things. First of all, the work phase is kind of dumb—not in a bad way. If you have a good plan, it does the work and it’s pretty good. And then the review makes it a little bit better.

Dan Shipper

And by that you mean: having an entire phase dedicated to work in this whole system doesn’t necessarily make that much sense, when all it really means is “run the model, let the model do the thing.”

Kieran

Yeah. There needs to be a step, but what I mean by “dumb” is I don’t need to care about it—I don’t need to think about it. I trust it. And this isn’t “trust me, bro, it just works.” This is: I’ve seen that if you put in a good plan, it executes on the plan. LLMs are very good at following steps, doing deep work, working for hours or even days now.

That thing is kind of solved. The review is starting to get there too. The planning is starting to get there too. And then you hit this next question: if all these things work, where do I actually have to do anything?

Dan Shipper

Yeah.

Kieran

Did I automate myself out of a job? If everything works, where do I work? What is still the bottleneck?

There are two things we started to identify—and Trevin was a big contributor here. He’s a product person, and he said, “I need more on the product side, which is before the planning phase.” So he added a brainstorm step and an ideate step. The ideate step is really going wide—coming up with ideas in a room full of interesting people with different angles. Brainstorm is more like: I have a problem but I don’t really understand exactly what or how. So it’s very much brainstorming around the problem.

The first thing we noticed there is that at the top, it’s very important to stay in the loop with a human and really ask a lot of questions—the human should think hard, and the LLM should support the human. But then after that, if you have a good brainstorm and a clear idea of what problem you’re solving, it can create a very good plan and the human doesn’t need to be in the loop.

So that’s the first realization: here’s where it’s good to be in the loop versus not. You can see other approaches—spec-driven development, for example—that assume it’s always good to have people in the loop, and I disagree. It’s very important to know when to be in the loop versus when to hand it off, because that means we can think harder at the moments where we actually need to think harder.

The other moment comes at the end. Something comes out. How do you validate it? Well, it’s already tested—browser automated testing has clicked through everything, all the requirements are clearly specified, and it says everything works. But the beauty comes in when a human looks at it, clicks around, and has a feel for it: “Oh, this doesn’t feel right. We can polish it. We can make it better. There’s something still missing. We can make the design better.”

I learned this from doing Pomodoros. Ideally, if you finish a task after 15 minutes, you still have 10 more minutes to work on the same task—you can’t switch. And sometimes in that space, something beautiful happens because you go deeper, further than you would have otherwise.

I think that’s the other critical moment: all the way at the end, when everything is done, you can elevate everything and make it even better. And I think we need to do that, because if we don’t, it will all be slop—all the same. It’s very important to make it feel great because the bar is high, and the bar will always get higher.

So this is what we realized: the beginning and the end. The middle can be automated pretty well. And Dan at some point said, “Oh, it’s kind of like a sandwich,” which was very funny. And Dan is now referring to the AI sandwich, which I think is very cool. The sandwich is really: when do you need to think about what you’re doing and really use your brain, versus when do you offload it?

(00:10:00)

Dan Shipper

Humans are the bread in the sandwich, and the AI is in the middle.

Kieran

Yeah. The AI is whatever you put on your sandwich.

Dan Shipper

Exactly. And I think that’s really interesting and really cool because it gives me a good mental model for how I should be working with coding agents—but I think it also applies to the rest of knowledge work.

This is such an important question now, because we have all these questions about what agents are going to do, whether everyone’s going to lose their job, all that kind of stuff. I think software engineers are a little bit the canary in the coal mine. And so far, what we’ve found internally at Every is: absolutely not. We still hire software engineers. We need software engineers. But the way you’re working—what you’re doing—looks a lot more like managing. If you’re doing it well, you’re still involved, but you’re involved at the beginning and the end as this kind of sandwich. And I think the same is going to be true of every other kind of work, whether that’s copywriting, strategy, or design.

And there are deep reasons why that is the case. I want to start with an objection people will have, which is: okay, for now agents can’t do the ideate and brainstorm phases, but pretty soon they will. So then what?

They’re already starting to do the beginning of that process. And I think there’s something interesting here. If you look within any given local frame of a problem—to take a non-coding example—the problem might be “my knee hurts” and you want to solve that. But “my knee hurts” is the same kind of problem as “this feature is broken” or “customers are anxious about this part of the product.” Any problem. If you take that frame and say, “The solution is take Advil”—any part of that process, getting to the store or whatever, can be automated. DoorDash can go do it. But there’s always, even once you’ve solved it at that level, a larger frame within which to think about the problem.

If your knee hurts, you might need to stretch your IT band. Or you might need to stop running on hard surfaces every day. And each one of these addresses the same problem at a different level of the stack, from a different frame. Humans are very good at flipping and changing frames like that. Our job is to set the frame—set the bounds within which we solve the problem. And I think it’s going to be very hard for agents to do that well by themselves.

Does that resonate for you?

Kieran

Yeah, for sure. It all comes down to building an environment where the agent will thrive. And you do that by picking the right things. That’s why it’s so important to have humans with experience, humans with taste, humans who want to click around and say, “This is great” or “This is not”—and say why.

I think it’s similar to the Advil example. If you keep taking Advil, eventually a friend will say, “That’s messed up—just go fix the actual problem instead of denying it.” It might work for a while, but you need someone to shake you up. And in that case, that’s the human.

But I do think the ideation step will also become more automated. You can say, “Let’s have a persona of 100 people and run simulations of how they think and behave.” And clearly we’re going there—running simulations of millions of people, seeing how things work, learning something from that. There will be more automation, and maybe even the front step will eventually be fully automated.

But I do think that in the end, if you ship something—if you make a statement in the world—and you want it to be your own, you have to say yes or no at some point. You cannot fully automate everything. It’s a bit like making art. If you want it to be yours, it needs to come from you or somehow be connected.

So I believe having those moments where you decide—where you choose what you enjoy—is so important. That’s why it’s so important to do things you enjoy and love.

Dan Shipper

I agree. And you can imagine it being: “We’re going to simulate a billion people and make decisions based on what we think they would do.” But that would still only cover a small set of the decisions someone might actually make.

Kieran

It will never be fully solved—it’s a moving target. We always create something new, and then there’s a layer above that where we can make even bigger impact.

Dan Shipper

Especially because, for a lot of these decisions, the feedback loops are so long and the data is so rare. You may only get a couple of moments in your career where you gather the data that helps you decide about a particular thing. That’s very hard to get into language models—especially because it’s hard to gather in the first place, and they need a lot of it. That rare expertise, encapsulated in an expert who has a personality and a worldview, is hard to replicate. And you’re right—it’s always moving.

That makes me really excited about this, because I feel like we’ve been wandering in the woods for a long time on the question of what AI progress is going to mean, and how humans are going to be involved. And it just feels very much to me like the simple answer is: ride the bottle. Or to mix the metaphor—be the bread in the sandwich. If you do that, you’re going to be fine. It’s going to be really, really great.

Kieran

I agree. And it will be different for different people, and you will need to change some things. If you only love writing code, you need to find your way of doing that. Yes, you can still write code—but maybe it’s about beautiful code. Maybe you find a lot of value in just recognizing beauty, the way someone looks at a UI and says, “This is beautiful, this works great.” Maybe you want that for code. Some people don’t care about that, but they love that the UI should feel great, and they’ll polish it, go extra—wherever they feel joy.

And it’s also becoming much more product-focused. As an engineer, you’re going to become either more of a manager or more of a product person. Product manager, product engineer—it’s more of those things as well. So there will be some changes, but lean into making beautiful things. Whatever that means to you: beautiful code, beautiful abstractions, beautiful architecture, beautiful design, beautiful copy.

I think it’s very important to lean into what is beautiful to you, because then you’ll find a way to use an LLM to make something that gives you energy instead of draining you.

(00:20:00)

Dan Shipper

And I think there’s a deep reason why language models are not going to be as good at that. One reason is it’s just not going to be yours if you didn’t decide it, if you didn’t do it. But another deep reason is that you can think of language models as a super-intelligence that’s been kept in a box for the last year and has no idea what’s going on in the world, except for whatever it picks up when it pops out of the box. Because of that, its outputs end up being a little more generic and less personal to your situation.

You can see this in all the AI writing that reads like “It’s X not Y” and that kind of thing. To truly solve a problem well—or to truly make art, or to truly make a product that resonates with people—it has to be really well tuned to the exact problem you’re trying to solve or the exact form you’re trying to make. Language models need a lot of help to get there. That’s why you have to be on either end of them: to set the frame of the problem, and then to make sure the details are really right at the level of execution. And I think they’ll get better at this, but they’re much further from being able to do it end to end than we think.

My general bar for AGI is: whenever it becomes economically worthwhile to run an agent 24/7—it never turns off. OpenClaw is pushing in this direction, but it runs on a schedule, it has a heartbeat. You can’t just say, “Hey, go do a bunch of stuff and work all the time, spend tokens on everything constantly,” and have it be worthwhile. We’re not even close to that. Yes, we sometimes have well-specified tasks we can send a model off to work on for 24 hours, but it’s not changing frames on its own. It’s not finishing a task and then picking the next one, spending five minutes on this one and four days on that one. We’re not even close to that. I think we’re going to need some fundamental changes to the language model architecture to get there.

If they are running 24/7 like that, they’ll be a lot closer to being context-sensitive enough to do interesting creative things. But we’re not there yet.

Kieran

Yeah, I agree. One other way to look at it: I have a music background. I studied classical composition. And one of the beautiful things about music is—yes, Suno can create songs, but it will never capture a live performance, or the experience of coming up with a melody. There’s something internal in the human. As a composer or musician, if you perform something and deliver it to other people, they feel that. It’s different.

If you’re a DJ, it’s maybe somewhere in the middle—but there is something about performing, about expressing something. And I think there’s some of that element in these steps too. You see something and you feel like, “This is a little bit off here—I don’t know exactly why, but I want to change it.” And suddenly you’re performing, iterating, making something. You’re putting something into the world.

Practicing a piece, playing it 100 times—that’s not very creative, as a musician. That’s kind of the middle part. But the performance, at the end, is where you bring it out into the world to the people. That’s a special moment. And there’s a link for me with doing that polishing step at the end of a project.

And the start—if you’re a composer, coming up with something out of nothing—that’s also a special moment. Everything in the middle is kind of boring. It’s just work. But those end moments are still special, and it kind of works for making software or other things with agents as well.

Dan Shipper

I think that’s totally right. I love this art angle. Another way to say it: all work exists on a spectrum from being totally rote to being art. And art itself has many tasks within it—any kind of creative work has many tasks within it that are more or less rote.

If you’re trying to map work on that spectrum, the stuff that is more rote is just stuff you’re not going to have to do anymore. And that is a big opportunity to move a lot of the work we do to the more creative—and probably more interesting—parts of work. And to recognize that the frame is always changing. As certain things get rote, other things become what humans start to do. Yes, those will get automated too, but we’ll also keep moving along that spectrum.

The final thing that’s not automatable is art made by humans who feel something. And I think that’s beautiful.

Kieran

Yeah, it’s still scary—because what if you’re in the middle and you want to move? What if you’re trying to figure out what that means for you? This might sound very abstract and weird to some people. If you’re not an artist or haven’t really felt this in moments, it might sound like, “Oh, but that’s not me.”

But I do believe everyone has this. What brings you joy? What lights a fire in you? What do you get excited about? Whatever that thing is, you should lean into it. That can be beautiful writing, or very structured lists, or anything that just brings you happiness—you should do more of that, and use LLMs in your work toward that. That’s good.

Dan Shipper

I agree. Kieran, always a pleasure.

Kieran

Thank you. Let’s see where this goes.

Dan Shipper

See you next time.

Kieran

See you. Bye.

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.

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

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