A (0:00)

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 and 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 gonna 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 3 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 ed company 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 post 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 like 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 droidmiss 12 days, 12 experiments or games that touch the different themes people are talking about on Twitter. Many 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. And he even created a Telegram bot powered by Droid Exec so I could. So he can have local repo 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 cloud, 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 use 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've actually never used the product. But he's talking about this. So turn scripts into agent armies devex budget multiplier fails have permission so probably worth playing with. I definitely like when I was reading this, I was like, okay, I need to make a note to actually play with this. So. So you might want to do that. I generally just talk to the model a couple 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'm going to. I thought this was like an interesting insight which is 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 GitHub 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 I 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 TL doctor 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, 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 readme 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 you know, 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 set up for myself because this is effectively, 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 you know, as you're gaining confidence, running tasks and end to end tasks 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 from 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 at a restaurant, he has twins and 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 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 Divs, 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 they're 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 started 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 clique 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 than 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 and use something called syncthing 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 a vps. I think it stands for virtual. 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 Carpathy 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 and 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, hook skills. Although he is coming around to skills, this just gives, this just gives Ben permission and confidence that he doesn't need ultra complex system. So for people who are like, I need, you know, I need to set up all these things and I may make it complex and I need to do sub agents, I need to do hooked, I need to do skills. Just get started. Looking at Twitter, you see a lot of people optimizing or potentially over, 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 creates with that, 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 post where he talks about clis over mcps just Gave Ben the nudge to dive in more to Bash and 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 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 agent's md. 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 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? And you can just, if you don't understand anything, you just ask questions. And I really like that. He says, you're ever patient. Over your shoulder expert programmer. So Ben does contribute to real products during this period. He says I've even contributed improvements to our own products. Some simple things, but improvements nonetheless, which is really cool because they're like a venture backed company that's raised millions of doll. 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 PRs are a good way to. That's the insight, right? Looking at PRs is a good way 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's that which has been helpful. Not everyone has that, but, 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 to code or learning how to work with code. 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. 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 to code is, you know, hello, world. 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 to 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 routes 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 routes 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 is so much you can learn. And 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 git clone it and say, what the hell does this thing do? Okay, I've been building, 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 git, 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 right before it 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 2 AI tools is 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 it's time to lock in, understand how these, how these things work. And I think that the people that come on the other side of them are, are gonna see a lot of. There's a lot of benefits right now even if you don't become a full stack engineer. Beyond Vibe coding. By the way, we're almost at the end of it. Thanks for sticking with me. I'm doing this for us. 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 he improve and how could he be a new age programmer? What is this technical class? 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't 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. In the output, I'm building stuff that I want to build. 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, 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 he 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. Most we're going to see 10,000x, if not more of the amount of software. Most of it will be bad, horrible, horrible, horrible AI slop. But you know, 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 non 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. 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 Anti Gravity, 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 environments. I've tried a bunch. I used one, 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 changelog, 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 a 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, 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, you're going to come out of the other side more powerful. And 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. Subscribe to the Startup Ideas podcast on YouTube, on Spotify, on Apple. 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 spending some time with me and if this was helpful, please share with a friend. I'd love to see more people ship their ideas.