📱

Get Our Mobile App

Take your business learning on the go!

Download on the App StoreGet it on Google Play

The Real Reason AI Is Going Back to the Terminal

Matt Maher17:37

Transcription

Have you noticed that suddenly everyone seems to have a CLI? I mean, like all of the major model manufacturers. We have Anthropic, OpenAI, Google. All of these have CLI applications suddenly. And in fact, things like GitHub and, uh, even Warp, a terminal application, have CLIs. And Cursor, which by definition was not a CLI. What on earth is going on? Why are we taking so many steps backward and moving into the terminal again? Isn't everybody scared of the terminal?

Okay. Okay. In this video, I'm going to show you what the dream is actually all about. A perfect union between you, your code, and your model. That's the whole idea. Now, it's not really the reason they're all rushing to a CLI, but the major model manufacturers, I think it's a really core point. But let's take a look at the journey. Why on earth are we taking steps backward and putting people into a black and white world of terminal? We can't really be getting everyone stuck in terminal again, right? I mean, everybody's scared of terminal.

Okay, so we all know the terminal application, right? Lots of people are scared of it. Devs have used it for a long time, but even a lot of devs kind of avoid it because there's a lot of trickiness to it. And in fact, you can kind of make mistakes as well. So a lot of us have a little bit of fear about opening it up and just diving in and doing something in it. So why on earth have we moved to a place that everything runs inside of the terminal? So this really feels like a weird place to really try to collect everybody and write all the brand new applications that are doing the absolute most cutting-edge stuff. So what the hell?

Okay, so what you're seeing here is really one of the most popular CLIs these days, which is Claude Code. This is Anthropic Claude's version of how to use their models to code. It really is as simple as having an area where you type your question, hit enter, just like you would on ChatGPT. It goes off, does some work, calls some tools, and comes back and gives you an answer. Look, it feels very much like any other chatbot that you might have a conversation with, only in a more difficult, harder to read, and more risky feeling environment. So again, why the heck are we here?

Okay, so let's take a little bit of a discovery journey into exactly why all of these big, huge, billion-dollar companies, hundred-billion-dollar, trillion-dollar companies are now actually investing so much in building applications for something as incredible as a terminal agent. It's not about nostalgia. It's actually a strategy.

So step one, what we're looking at is the surface area. The friction here is very low. It's super easy to update. They are not making huge bets, huge investments on a bunch of buttons and a bunch of UI designers and UI developers and all of the stuff that goes along with it. Those systems, having spent a large portion of my career in that space, get tremendously complicated. You'd be surprised at how hard to keep the wheels on those things it actually can be. And so putting a bunch of time into something like that doesn't really feel forward-thinking when you realize the world is changing every six to eight weeks. You have no idea if you spend a whole bunch of time trying to build a feature if it's even going to be useful a month from now.

But that's actually not the reason. It feels like maybe that's a good reason for them to be here and a good reason for a lot of them to write these applications. But they really didn't have a reason to put applications out if it was just to repeat what Cursor was already doing. So this really can't be the entire story. The trick is there's something even tighter happening here. It's not just that you can create a very simple UI and it do very, very incredibly powerful things. It's actually the incredibly powerful things that they were actually doing.

And so let me describe what's going on inside of these applications. So something like Claude Code that we were just looking at, or Codec CLI, or even Gemini CLI. These are major, major agentic loops. And what I mean by agentic loop is just a set of agents that are tacked together with an objective. You put a question in, it kind of uses its tools and its techniques and its models to solve that question, to do whatever it needs to do to kind of resolve the objective against that, that request that you put in, and then return a result to you.

Anthropic runs the Claude Code set of models. Those models are incredibly performant. Back in the 3.5 era, they realized they really had a hit on their hands. This is maybe the beginning of 2025 or in that neighborhood. Uh, developers really started flocking toward their 3.5 version of Sonnet. It was a great coding model, had a lot of performance problems, but we could control them and we could work through them. And that was one of the things that engineers started learning how to do is how to kind of control the wild outputs that these models had from time to time. The people that work on these models also use these models. And they were doing the exact same things and realized if we just put agent systems around this and kind of control what's going on a little bit better, give it a better understanding of the world around it, let it kind of keep lists and track of the work that it's doing so that it's working progressively through a problem and we're not just hoping that the model remembers to do everything. But they've built this nice tight agentic system around it, or kind of workflow around how to talk to this model.

So what has really happened is they have created the best delivery system for coding with their own model. So it's a one-to-one. It's you, it's your context, basically your files, your problem, your question, the model, and an agentic loop coordinating all of those together to solve it. There is nothing else to move. So nobody owns anything else. Nothing else can disrupt the problem. It's a one-to-one kind of relationship. And I think that's really a very interesting aspect of what they were doing is they were saying, if you want to use our model and you want to use it to the fullest potential, we don't actually control the people that do the Cursor thing or the Wind Surf thing or any of the others. How about if we write it ourselves and say this is literally the best way to work with our model. We'll build you the best pattern.

And so that's the next kind of link in this chain. They built great agentic loops for their own models. And of course, OpenAI, Google, they noticed this as well. They had already been out there for a little bit. Everybody had dabbled in this space, but they really realized, wait, the actual secret here is to build the best interaction with our own model and build a very tight relationship between the request and the response using our systems. So, that's really the next actual kind of clue that we have here of what's going on.

Okay, here's a little one that I don't think anybody really pays attention to, but actually from a business world, I have a feeling this is a pretty important aspect. If you build one of these and you have a subscription already, let's say you're Anthropic Claude Code, once again, you build this and you tie it into your subscription. If you have that relationship with your customer, it's a one-to-one relationship. There's nobody in the middle. If you're trying to have that relationship with a customer like people were using the Sonnet 4.5 or 3.5, 3.7, 4.5 models through Cursor, well, C, Anthropic didn't have any relationship with those customers. They couldn't message them. They couldn't upsell them. They couldn't keep a relationship with them, ask them what was going on. They didn't really know those customers. That's a real problem for a business. You want to own your own customers.

Suddenly we can build a very simple application. Simple in the sense that you don't have all the buttons. You don't have to get a whole team together. And that gives us a one-to-one relationship. Not only the customer with the model. Now us as the model manufacturers have a relationship with individual customers themselves. No other middlemen. We can communicate to them. We can understand their problems and we can build them directly for their usage. So I think that there's another thing that they got directly into our pockets. That might not be the best perspective here, but I think that relationship is something that these companies saw as a real value add. So that's link number two.

I think the low traction or friction to change these things was kind of an artifact of everything as much as anything. It was probably the first thing they built because they needed it themselves and then they realized, wow, this is pretty easy to keep changing. Let's not build a full UI out of it. That was probably the actual rationale. And then they said, "Boy, we can build the best possible pipe to our model." And then, hey, we can gain relationships directly with our customers. This is getting fantastic. However, with all of this, even though these steps were important along the way, I still don't think any of these are the reason.

Let's talk about the real reason I think everyone is building a CLI these days.

Okay, so the final unlock here and really what I think is the cornerstone of why everyone is moving this way and actually why it's really worth paying attention to it, even though I understand it's terminal and we'll talk about whether or not we all need to rush to the terminal at the end. Give me a second. But first, let's talk a little bit about really what I think the major point here is.

Number one, as you remember, we had these things in something like Cursor. They were models that could be called from some kind of coding environment. That coding environment could just send the context to the model and say, "What do you think?" and then attempt to update the files. Then they realized a better way to do that was, let's build our own agentic loop that could do those updates and make those calls and the tools and use that stuff ourselves because we better understand how our model works. Okay, that's really smart. But what comes out of that is what actually that artifact is the most important part. You're building an engine.

So all of the sudden you're building this little tight piece of code that knows how to take in a problem, work with tools and context, make changes as needed, and then give back the result. And that in and of itself, just as a standalone little engine, forget what it can do. Just understand that it's a little program that can do it. That in and of itself is the super secret sauce. And so let's go through a little journey of calling these things.

Okay, here we are in, of course, terminal, as you probably are not surprised at this point. And we're in Claude Code, as we saw before. Let me just say, "Tell me about this application." Now, we've seen this, right? So Claude can read through the files and give us kind of a definition of the application on the other side of asking this question. This seems obvious. This seems like exactly what this system was built to do. But it actually offers some interesting new tricks. So here we are. We have this big long list of what the application is about. Excellent.

Let's drop down into terminal itself. And then we can say, "Claude, tell me about this application." So in this case, I'm not even going to launch Claude. I'm using Claude as a tool. So it's kind of what we might call headless. You don't see any of the UI, but it will give us the result from this tool call. It's doing exactly the same thing as if I had opened the application and posted this kind of prompt to it. So that -p just means take the next thing as the prompt. Okay.

So what's fascinating about this is then you can write tools that use the Claude environment, or any one of these CLIs, as an actual tool call in the middle of your own tool. So if you have a script or you have an application that needs to use a little bit of agentic information, give it some context, give it a prompt, you get back what you want. Super easy to use. Great agentic loop. Can definitely use these tools directly. Kind of brilliant, right? And that's an example of it being an engine. But that's not enough.

Let's look at others. Okay, here we are in Cursor, a standard IDE that developers will use. And I can from here click a button to open the Claude Code extension, which is just a panel. So I've added this extension, by the way, to, um, Cursor itself. You can do this for Visual Studio Code or Cursor, something like that. And when you click this button on an open file, it will open the panel. Now, what's going on in this panel, which is very, very cool, is that it is behind the scenes. It looks like a native panel. And of course, the panel itself is native, but what it's doing is it's actually running a version of Claude Code behind it that we've been using this whole time, that terminal version, that engine of Claude Code and asking it, submitting this question in the same way we just did with the -p sort of, and it's getting that information back and presenting it to us here. And so, it's doing the exact same thing that we've been doing. Now, this is the third way that we've done it. It's all using the same code line. I think now you're starting to get the message, but really, we're not done.

All right, here we are at Claude AI, which is basically ChatGPT for Claude. If they click the code button on the side, you'll see it drops us into the list of repos that we can execute with. I can send the same question in here that we've been sending everywhere else. And by this time, we can all say it together. What's going on? Well, they have a virtual machine in which what are they running? Claude Code. Exactly the same engine running the same way, giving us the same kind of output. They've just wrapped a UI around it in the web so that we can see its output here. And so you might imagine we're really starting to be able to use this engine literally anywhere that they can run this kind of code. And that is really the major unlock.

Okay, sorry about this dead horse. We're going one more. All right. I've dropped over into the same exact repo on a PR that I've put together that has some problems. And what am I going to do? We're going to scroll down. We're going to take a look that Claude has already made a review of this PR automatically. Fantastic. And if you scroll down into the review of what it's describing, what it does or doesn't like about the PR, you'll see that it has some test cases that are failing, saying, in fact, these tests are even missing. So, what are we going to do? Well, why don't we drop to the bottom and say, "Hey, Claude, please go fix this for me." We submit that. And what does Claude do? He comes back and says, "Yep, I'm on it." How's he doing that? Okay, now we all know this and it's getting boring. It's running Claude Code inside of the GitHub infra. That's how it's solving this problem. Brilliant.

Okay, so with all of this change, I'm sorry to beat you up with that, but at least that's all the different moving parts on how we're seeing these systems kind of expose themselves at the moment. I'm sure it's broader and broader. In fact, you can do the exact same thing that they're showing here with any of your own agentic loops or even using Claude Code or Codec CLI or Gemini CLI and use those in the same kind of way. Put it on a lot of different surface areas and be able to get that same value out of many different kind of interfaces.

So, there's really a value here that is way beyond we're bringing things to the terminal. Terminal just happens to be that almost friction-free change environment that they can exercise changes very, very quickly in and engineers and people that are using these tools can get the value out of very, very fast. So that's really at least my belief why we're seeing all of this movement to what looks like the CLI or kind of down into terminal.

But let me answer the question that we posed earlier, which is, does this mean that you need to use the terminal? Well, as you just saw, you don't really need to use the terminal. Listen, if you've been using Cursor with one of these models, let's say the Sonnet 4.5 model, which is the model that we've been using all along in all of these experiences, if you've been using that in something like Cursor and getting great results out of it, moving over to Claude Code only probably has a chance of giving you worse results. So, I'm not advocating that this is the only way to do it. I do believe in my experience is that it is the most tuned way to do it. So if you want the best work out of these models and you are willing to figure out how to work with these models, this is really the best way to go about doing that and you'll get the most value for your input. At least that's been my experience.

And I won't necessarily in this video at least draw comparisons between Claude Code and Codex and Gemini. They all have their own values, their own strengths and weaknesses, but they all exhibit the same behavior that something like the Gemini 2.5 Pro model that's being used in Gemini CLI, I get more performance out of it when I use the Gemini CLI than I do out of it when using Cursor or something like that. So, it's the same behavior that their agentic loop really tightens down everything so that you get the most value out of it. That's been my experience. I don't mind using the terminal, but in fact, what I just showed you was using the web client. I kick off jobs in the web client all the time.

Now, hey, I'll show, I'll point you at my last video which really talked a little bit about that and kind of the future of the way engineering is about to start happening. I really think this kind of cloud engineering thing is about to take off. And why is it going to take off? Well, because all of these teams saw, wait, if we write an engine, we can do this same work anywhere and where people need or want to do that work is no longer a barrier. So, I think this is kind of a real interesting unlock for the industry. We will see much more of this coming forward.

But if you're not in the CLI today and you're curious, I would definitely, definitely advise drop in. It'll be a little bit different than what you've been doing. Allow it to be a little bit different and just keep asking the model how to solve problems if you're confused. They're actually pretty good once you just touch them a little bit. So, I appreciate you coming along for the ride on this one, and I'll see you in the next.