▶️YouTube

Beginner’s Guide to Building Software With AI & CLIs

Greg Isenberg·youtube.com·24 min read·Mar 28

Select text to create a clip

Transcript — click timestamp to jump, select text to highlight

303 segments

Can you code with AI agents without being technical at all? Today we're going to go through

if you actually could do that. This is an episode based on an article I read by Ben Tossel.

He is just a master of communicating how non-technical people can use AI and he wrote

this incredible guide. It got 3.8 million views on X and we're going to go through it together

to basically take all those insights. He talks about what he's actually shipped

as a non-technical person, how he actually works, what his setup is, how he codes on the go

and more. All the insights that he has. We're going to go through it together. I started reading this

frankly and I was like this is so so much sauce that I need to go through it with everyone here

together because I think that the people that stayed to the end of this episode are going to

have an unfair advantage because he just he explains it so simply. So let's let's get right into it.

He starts by saying I've spent three billion tokens in four months. Every single one of them

through a terminal watching an agent write code I couldn't write myself. You may class me as a vibe

coder but I think the term overlooks any kind of skill involved in the work itself much like

no code did in circa 2019. He actually started a no code company that was started that was acquired

by Zapier. I don't read the code but I read the agent output religiously and in doing so I picked

up a ton of knowledge around how code works, how projects works, where things fail and where they

succeed. So this is his guide to learning how to program. So he shipped a bunch of things. He shipped a

personal site. He says I revamped my personal site and made it look like a terminal CLI tool. He built a

feed so he built a social so simple social tracker for mentions of factory. That's the company he

works at. Factory on Twitter, GitHub issues, posts from the subreddit. It's open source. He built

factory wrap which was a first version of his wrapped product showed it to the team and they loved it

and they wanted to bake into the actual product themselves. So even if you don't want to actually

build a startup and you want to just get promoted at your job, learning how to actually use AI

agents is helpful. Custom CLIs. I've created a few CLIs like Python CLI which then has been picked up by

the team with customer support queries. He created a crypto tracker that predicts positive, negative,

or neutral signals and dynamic data. He created Droidmas, 12 days, 12 experiments or games that

touch the different themes people are talking about on Twitter, memory, context management,

vibe coding and things of that nature. He created an AI directed video demo system. He gives it a

prompt to create a video. It opens up ghosty, runs the command and can open up other windows like a

browser, recording the screen, basically acts as its own director, producer and editor. He even created a

telegram bot powered by Droid exec so he can have local repos synced on a VPS and about 50 other

things I'm not mentioning here are left to die. So if you're interested in building things like this,

this episode is for you. So let's see how he actually works. So he says he uses CLI exclusively,

terminal over web interfaces always. It's just more capable as a general agent and I get to see it work.

So a lot of people listening to this are non-technical and they're probably using web

web versions of clode. They're using web versions of lovable and products like that. This is your

you know, reminder, kick, you know, pat to actually go and you CLI because if he can do it, you can do

it too. This is what he does. He says, if I have an idea for something or there's an issue with something

that I feel like could be solved with code basically everything these days, I'll spin up a new project

in Droid, which is factory CLI. So I have no affiliation with factory at all. But I, I'm just,

and I've actually never used the product. Um, but he's talking about, he's talking about this.

Um, so, you know, turn scripts into agent armies, dev x, but budget multiplier fails have permission.

Um, so probably worth playing with. Um, I definitely like when I was reading this, I was like, okay,

I need to make a note to actually play with this. Um, so, so you might want to do that too.

I generally just talk to the model a couple of times to start feeding in context about what I'm

trying to do. And then I'll switch into spec mode and start getting a plan on what I want to build

in spec mode. I'll basically question a bunch of things. Like I don't understand what this is

or why would we need that over this? Can't we do it this way? I thought this was like an interesting

insight, which is, uh, approaching it as, you know, almost like a philosopher asking questions.

So I made a mental note to do that. I'll link docs and get hub repos for the agent to explore.

Then I let Opus 4.5 with autonomy high important here, just rip. I'll watch the stream, see what's

happening. And when there are any errors, I may jump into the question or guide it down a different

path. I start the server, I test it, I give feedback and I iterate. So let's sort of TLDR it.

So I kind of build ahead of myself first. I try and just build the thing. And then

all the gaps and all the issues that I run into are the opportunities for me to learn.

Is that a thing that is part of the system that I've seen across other repos that I should build

up a sort of templated system handle? Should this go into an agents.md that actually follows me around

and does the same thing on all other repos I'm going to be working on? So agent.md, agents.md

is a simple open format for guiding coding agents. So it's used by over 60,000 open source

projects. You can think of agents.md as a read me for agents, a dedicated predictable place to

provide the context and instructions to help AI coding agents work on your projects.

So you can see there's a little why, like why it should exist. But basically it's giving it a clear,

predictable place for instruction. It keeps a concise focus on human contributors. And

there's some examples on the website here. So something that you might want to look into.

So he talks about his agents.md setup. I've been spending more time trying to figure out the best

agents.md setup for myself because this is effectively like an instruction manual. I've

got repos, folders locally. That's where all my coded projects go. In that repos folder is an agents.md

that says to explicitly set up new repo with what to do and not to do. How to do things with GitHub,

how to commit, all that kind of stuff. And whether it should use my work GitHub account or my personal

running tests. End-to-end tests is one of those things I never really paid attention to

previously. But now I'm really keen to have end-to-end tests on everything. Given my current

knowledge and capability, when I'm building things and testing them, there often might be silly things

that I should have just caught or tested that had been tested in the first place. So as you're gaining

confidence, running tests and end-to-end tests is something that you're going to want to do. And I often

look at others' agents.md files to see what I can borrow for my own. I'm constantly

trying to improve my doc to make sure every session goes smoother. Coding on the go section.

So he says, I always make sure that I install the Droid GitHub app on every repo that I create.

So when I'm deploying to GitHub, I make sure I'm submitting pull requests so I can have Droid review

it and I can tag Droid to make fixes itself with a custom prompt. Just insane that you can do this,

by the way. It's literally like having a programmer. I can trigger it like a human programmer. I can

trigger it from issues or from pull requests. It lets me code. This is mind boggling. It lets me code

from my phone and add new things when I'm out and about. That in combination with my Telegram bot makes

it really easy for me to do things when I'm at my desk. I just like picture him, you know, at a

restaurant. He has twins, you know, and he's just, he's waiting for his meal to come or something like

that. And he's just literally coding there. I also use Slack with my agent. I create a new channel for

each repo and just fire off things as, and when I often spin up new channels for new ideas and Slack's a

great one person product with agent. This is a reminder that Slack is a great one person product

with agents and could be super helpful for you. So what has he been learning? Bash commands. So I

hadn't heard about bash commands in a very long time. I actually learned, I dropped out of computer

science school, but I, you know, one of the first classes I took was bash. So it was a throwback. It

really clicked for me when I'd been running the changelog process for a while. It's the same process over and

over. I finally understood the workflow. So I got Droid to create the slash command flow and it's

the first slash command that I actually have used properly, which runs a number of bash commands

and also prompts the model to do certain things like reading through GitHub diffs, checking what

is behind a feature flag and what's not, and putting things into the right section of new features, bug

fixes and that kind of thing. So, you know, what are bash commands by the way? Bash commands are basically

a way for you to interact with the operating system. So there are things like CD, which means

change directory. There's a bunch of commands that it's good to know a few of them because it's going

to make your life a lot easier. From there, he says, I start getting more into bash and CLIs.

I've stopped using MC, I've stopped using MCPs. I use the CLI version of most things over MCPs.

Yes, because MCPs take up context, but mostly I feel like it's simpler. I usually only need a few

of the tools an MCP would include. So with Supabase, Vercel and GitHub, I'm always using the CLIs over

the MCPs. This was actually news for me. I never thought about it like that. So I'm happy he talked

about it. I often build my own CLI for things. For example, I built my own linear CLI so I can query my

own issues and run everything from the terminal instead of going to the desktop or web interface.

This is like a mindset shift. You're going, you know, doing everything from the terminal

in this new world, this app agent native world is super, it's more powerful right now.

Okay, what else did he learn? He learned VPS. I abstractly knew what VPS was. It's like another

computer that is on all time, that is on all the time somewhere else. But until I truly needed one,

I didn't really know what I needed to do there. And there's still a lot to learn. But effectively,

now when I'm running the crypto tracker, I have a ton of data that's being pulled in every single

minute and need that to stay always on. I can also use the VPS when using my Droid telegram bot and use

something called sync thing to sync my local repos to my VPS so that my repos are always up to date

and they're in the same state as I left it. So it can just pick up on the go. So that's like the big

unlock I think with, you know, a VPS. I think it stands for virtual, let's see, VPS,

virtual private server. So that's the big unlock there. You know, the repos are always up to date

and they're in the same state that I left. And lastly, skills. I've tried to use them a bit more.

I've been using them not only just as knowledge, but also with bash commands and CLIs. I've got a

Gmail CLI that I can pull into any projects. It's portable. It lives at my root directory. So anytime I

need Gmail in my system, I've got Gmail triage system that I use. It just uses CLI.

He then talks about the new programmable layer of abstraction. So not to be like everyone else

on Twitter when they see Carpathie tweeting something, but this really rang true to me.

He says there's a new programmable layer of abstraction to master. When it was in the no-code days,

this is like five, six years ago, the abstraction layer that I was mastering, that he was mastering,

was drag and drop tools like Webflow, Zapier, Airtable. Stitching them together and making it

feel like real software. Until you hit a limit, of course. But now, instead of me thinking I've got

to learn to write code from scratch, in order for me to be able to do all this, what I need to learn is

actually how to work with an AI agent. How can I prompt it well? How can I make sure it has the

right context? And how can it help me understand what we're doing? How do the pieces work together?

And how can I improve my own system over time? Including all of the things like agents, sub-agents,

prompts, context, memories, and skills, and hooks. So then he talks about learning from other people.

So he says, I read people like Peter Steinberger, who's an actual programmer, and he's shipping a lot.

And seeing in his post, almost the simplicity of his system, where he just talks to the model,

lets it do its thing, and doesn't really worry about extra slash commands, sub-agents, hooks, skills.

Although he is coming around to skills. This just gives Ben permission and confidence that he

doesn't need ultra-complex system. So for people who are like, I need to set up all these things,

and I need to make it complex, and I need to do sub-agents, I need to do hooks, I need to do skills,

just get started. Looking at Twitter, you see a lot of people optimizing or potentially over-optimizing

their own system. That can feel daunting for folks. But also, that's what I think some of the beauty

of this is. It's a completely customizable system. So you can make it work for you however you'd like.

You can have a plan mode that you create with a custom slash command that runs for 20 minutes,

like Kieran does, or you can just talk to the model like Peter does. Another thing while following

other engineers is seeing their open source software, cloning it, using it, and trying to

improve it. I think this is such an important part of this whole process. Like Peter's recent

Summarize YouTube, for example, Ben just took it, he removed the Chrome extension part, kept it as the

CLI, and he can talk to that anywhere he wants. And like Mario, reading things like his MCP posts,

where he talks about CLIs over MCPs, just gave Ben the nudge to dive in more to bash in CLIs.

So, this is, you know, Ben is obviously doing this to learn. He's on his holiday break,

and he says, I'm not building things for tens of thousands of people to use in production,

so there's going to be bugs. It's probably like you too, the person listening to this. There's going

to be issues, and he's going to run, you're going to run into it. It's a reminder that this is a gap

in your knowledge, not in the capability that you have now. Really important point. Then he goes,

my role is identifying the gaps or finding those gaps and thinking, how do I make sure that this

never happens again? Or how do I make sure I understand this part of the system enough

that if it's going to happen again, I will catch it? So, even the simplest things from when he

started using agents to code, like why can't I use GitHub pages when I've got dynamic data

and multiple users to be able to use something, that's like a very, very simple thing that programmers

know. But it was just something that Ben learned because he was building something. He was trying to

build something different than the tools allowed him to do so. So then he's like, so this is his thought

process. He's basically like, well, what do I, what do we, what do we need to do? Like all you need

to do is just ask the model. The model knows everything you don't. Just think about it like

that. You can just keep, keep asking it. It's your ever patient over the shoulder expert programmer.

You can add it to your agents MD. I'm not a, I'm not a programmer. You need to explain things very

simply for me and you can tweak it exactly how you want it. This might be one of the most important

things that he says, uh, using, using the model as your teacher, your professor. This is your computer

science school and you've got the best school on the planet, right? Um, and you can just, if you don't

understand anything, you just ask questions. And I really liked that. He says you're ever patient over

your shoulder expert programmer. So Ben does contribute to real products, uh, in, in, you know,

during this period, he says, I've even contributed improvements to our own products, some simple

things, but improvements on the last, which is really cool because they were like a venture

backed company that's raised millions of dollars. There's a team of engineers at factory that's

extremely experienced and good at what they do. And he's learned a lot by just watching them,

looking at their PRs. So, you know, PRs are a good way to, that's the insight, right? Looking at PRs is

a good way to, to understand more about how this works. We have an internal lunch and learn where

people say, this is how I scope new product features. Here's how I bug fix things like that,

that, that, which has been helpful. Not everyone has that, but, um, you know, there are a lot of

YouTube videos that talk about this sort of thing. So he says, so this whole thing is really just a big

learning experience for me and I'm really enjoying, enjoying learning a code or learning how to work

with code. Uh, why this is different. So Ben has tried to, like maybe many of you have tried to learn

to code many times in his life. And every time it was type in these characters, hint, enter and do you

see hello world? It was, that's what he means by that is hello world is like the, you know, what

prints basically one of the first things that they teach you in computer science school, or if you're

learning a code is, you know, hello world. Um, you know, it's just like you create like your first C

program or your first website that just literally is a website or piece of software that says hello

world. And then he says, it was kind of do this, then that, then this happens. And maybe it would have

been helpful for me to learn all that, but I just think that's so different to what it is today.

He says, for me to be able to build things I've built now, if I'd taken that other path, I would

have had a code for many months, many years to get to a point where I could feel like I can write the

code myself. So instead of coming at it from a point of view of, I understand systems thinking for

projects built with code. I accidentally learned that when I was running my last company with no code,

education, you're still learning that, okay, Webflow is the front end, Zapier is the API roots,

the connective tissue, the data flows, and Airtable is your database. So I learned the systems of that

previously. And I think that's helping me understand some of those pieces. 100%. A lot of people listening

to this don't even know what API roots are, connective tissue data flows is. So I think that I'm happy he put

that in there. It's absolutely true that he had some of the primitives and understood that from that

perspective. He says, there's so much you can learn. And I'll often I'll see something that

someone posts on Twitter. And I'm like, I have no idea what that is, or what I can do with it. But I'll

bet you can play around with it. He says, no piece of software feels unattainable. This is a huge mindset

shift. And so amazing. He goes, I can just get clone it and say, what the hell does this thing do? Okay,

I've been building it. I've been thinking about this. Is this thing going to do anything related

to what I thought? And it's just all exploration, all and just a lot of fun. So if you find something,

just get clone it and play with it. And you're going to learn a lot. Asking the silly questions.

He says, there's been countless times when I think about silly questions to me or silly question that

other programmers would never ask that have the permission to ask because there's no one watching me

and no one shooting me down for being stupid or saying the wrong thing. Like why do all these

frameworks, these different types, why do we use all these frameworks, these different types of

frameworks? Because they are abstractions for human, humans writing code. So why, if an LLM is so super

smart, why couldn't it be just be simpler? Why couldn't it just be simpler code written, less dependencies,

less potential surface areas for bugs? Is that a silly thought or is that a good thought? And then

he says, I can learn that it might not be a silly thought, but okay, yes, there are these many projects

that the model has been trained on, which is why often things will be built in certain frameworks.

So it's just building up this understanding of the code world, the engineering world that I don't,

I didn't deserve to be in, but I'm absolutely part of now.

You should be asking silly questions and being a student of it. And I think it's going to make you

a better programmer. And I'm not saying that everyone should become a programmer, but I do think that the

more you play with these tools, the more of a weapon you're going to become. And, you know,

I actually just sort of tweeted this, uh, right before I came on here, I go 2026 feels like a general

lock in lock in moment, daily exposure to playing. Wow. I literally, I wrote it so quickly that it

doesn't even make sense. Basically what I meant is, can I edit it? Yeah, we're going to edit it live

here. Daily exposure to AI tools. It's probably the single greatest thing you can do now. Launch seven

apps in a year, double down on one, become a weapon at your job, get promoted, find freedom,

life change right now matters so much. My point here is, uh, it's time to lock in, understand how

these, how these things work. Um, and I think that the people that come on the other side of them are,

are going to see a lot of, so there's a lot of benefits right now. Uh, even if you don't become

a full stack engineer beyond vibe coding, uh, by the way, we're, we're, we're almost, we're almost

at the end of it. Thanks for sticking with me. I'm doing this, I'm doing this for us, uh, beyond

vibe coding. Yes, you can call vibe coding, but I think vibe coding misses the point. He's actually

trying to learn the systems. He's trying to understand what is going on, what can you improve,

and how could he be a new age programmer? What is this technical class? That he says, that's what

I think is the most interesting thing here. I can't categorically call myself non-technical,

but I also can call myself a programmer, nor would I want to. I'm part of this new technical class,

and I don't know what it's called, but I think vibe coding gives a negative connotation to it,

much like no code gave a negative connotation to that group. So let us know in the comment section

what you are, vibe coders, if you like that word or not. He says, it feels like a game. Some people

have likened this new way of programming to a game. Factorio is the one that people talk about.

I've never played it. He's not much of a gamer. I've never played it either. I am a gamer.

But this whole paradigm feels like a real game to me, and the output, I'm building stuff that I want

to build. A tons of things that don't end up anywhere on GitHub. They don't end up live. They're

just mere explorations, part of a system or a topic. Others end up published, and other people use it.

I had a CTO fork my personal site and use it for himself. Big boss stuff for me. How cool is that?

If someone posts, oh, I built this React grab tool, for example. Okay, cool. Can I build my own?

Like why? This one looks really cool. This one looks really good. Well, just because I want to,

I can just explore things for the sake of exploring things. Then he says, and this is very smart. He says,

every idea if you've ever had can be exercise, can be explored, and it doesn't need to be good.

And you'll learn along the way. And he gives you permission to throw things away. He says,

previously, if I'd learned to code to build a really crappy version of something I was thinking of,

like a big idea that I had, and then no one wanted it, I'd be too emotionally invested in that idea

to just be able to throw it away. With no code, I can effectively build a version of that idea in

an hour or a couple hours weekend. And if no one liked it, no one wanted to pay for it. It was

rubbish. Then you can just throw it away. It wasn't that much of time or energy into something

that ultimately wasn't going to be something good for someone else. And he says, I feel the same is

true today. We're going to see an explosion of software. Many of it won't be good, but lots of

it is already great. Spoiler alert. We're going to see 10,000 X, if not more of the amount of software.

Most of it will be bad, horrible, horrible, horrible AI slot. But some of it will be incredible.

He says, there are expert programmers who are shipping things like crazy that are all good projects.

So we're just going to have this absolute plethora of coded projects out there that you can use,

clone, tweak, and remix. It's going to take a lot less time than if you had to learn to code,

or if you're reading the files, or you're writing the files, or anything like that. It's just a lot

quicker. The feedback loop is quicker. The process is quicker. You can just do anything at any time and

just consistently keep churning out stuff. Fail forward. The way to learn about code is just to build

ahead of your capability and fail forward. He says, I feel like everyone who is not technical

today, who wants to be in this world, who wants to do stuff like this can absolutely do it. They

just need some permission to do it. To play around, you must think of it like play. Well,

I'm giving you permission and Ben is giving you permission to go and do it. He says, sign up to a

CLI agent like Droid. Say you want to build a personal website. Say you want to build a little RSS

feed tracker, a little to-do list, a little workup app. Whatever you do, you just spin it up,

start working on it. Every little hiccup, bug, or issue you run into, question it.

Okay, why did this come up? Why did you hit those errors? You know you don't know how to code,

so you shouldn't get bogged down with bugs. Expert programmers hit bugs all the times,

and you can take it to other places. You can go to ChatGPT or Cloud and give it different models for

different perspectives. You're always going to have all the choice up there and all the different

variations. Last but not least, he ends it by saying, just pick one. There are so many different

tools, so many different options. Ultimately, just pick one and just stick with it. Just learn that

system. They all look fairly similar. Obviously, he uses Droid because he works at the company, but

also, he says, they get the best output of any model. They're model agnostic. But use whatever

you want to use. You can use Google's product, NTGravity. You can use Cursor. You can use

Cloud Code. So use what you want.

He says, ultimately, what I want and what I need from a tool is, is this one going to help me get

the furthest I can in the least amount of time with the least amount of trouble? The more I have

to do with using the tools themselves, the harder it is. Things like IDEs, Integrated Development

Environment, I've tried a bunch. I used to use one in particular for a long time. It just got so much

extra stuff that I just don't need or care about. I just want to talk to a model, have code written.

If I need to inspect some markdown files, I can now use what I've just recently discovered is a file

manager in the terminal. So I can just look through that or I can open up in NZ, which is what he uses,

just to view markdown files, edit them. If it's a change log, for example, if you want to tweak

something briefly, just go back to the CLI and just let it rip from there. And he says,

and any tool or feature I think I'm missing, I'll have to crack at it building myself, of course,

like a terminal file viewer. And he ends it with a quote, or not a quote, he ends it with a very

succinct way that is an important message. He says, this whole thing is just a really big learning

experience for me. And I'm really enjoying it. Build, fail forward and keep shipping. He's

acknowledging the fact that you're going to fail a ton of stuff. It's about learning. It's going to

be frustrating. It's overwhelming. There's a lot of words and vocabulary that you're not going to

understand. But, you know, if you treat it like just a learning experiment, a sandbox for fun,

uh, you're going to come out of the other side, uh, more powerful. And, um, listen, if this was

enjoyable and you want to commit to this, you know, I think that would be cool. I think it would be cool

if you build stuff in 2026, uh, subscribe to the startup ideas podcast on YouTube, on Spotify, on Apple.

Uh, I share ideas. I share tactics for getting your ideas into the real world and I make it practical

and helpful and I give away all the sauce. Thank you for, uh, spending some time with me. And if this

was helpful, please share with a friend. Uh, I'd love to see more people ship their ideas.

Thank you.

Clips

No clips yet

Select text above to create your first clip

Loading connections...

Reflect

What question does this raise that the author didn't answer?

Press Cmd+Enter to submit