I talked to 50 people building with AI. It’s a mess. transcript

Over the last several months, I have spoken to probably 50 people one-on-one, and they show me what they've been working on, how they're using AI to build their project. Usually, most of them are entrepreneurs or solo builders trying to build a side project. And I have seen some things, man. I have seen that you would not believe. Um, but honestly, it's not that egregious because it's the kind of things that I would have been doing last year or maybe even early this year.

And if you're still a engineering the way you were back in March or April of this year, you are doing things woefully wrong and you're going to get left behind, man. It's it's serious. In this video, I want to show you how to use the current generation of AI tools. We're talking Astra, Fable, Opus 5.5. the way you're supposed to be doing egentic development as a solo builder as an entrepreneur, if you're building a startup, if you are employed by Google or Microsoft, do not watch this video.

You will pick up bad habits. It's different. It's different if you are doing a coding for a company that is building medical software versus if you're trying to launch a side project or a company or a business off the ground. These are two totally different workflows. By far the most common thing I see is that people are still treating their AIs like their 2025 generation models. Back then, AI sucked. Okay, these AI agents kind of just sucked.

They would trick you into believing they were amenable to instruction because they would understand your intent. They would say, "Yeah, I understand." And then they would just go and slop around. they wouldn't really finish your task. They would do other things that you didn't want them to do. And so you'd have to go into your claw.md file, your agents.mmd file, and add a bunch of instructions like do not, absolutely do not do this under any circumstances.

You'd litter your file with all these instructions. Delete that. Delete all of that. That is no longer necessary for today's AI models. What I recommend doing is deleting your agents.md file and your cloudmd file. Start from scratch. use the latest generation models and only start appending to that file once you see these models misbehave in a way you don't like and I guarantee you that that frequency will be pretty low.

I have not personally had to add anything in the negative to my agents.mmd file. So I have things like commit your changes after every request but I don't I don't think I have anything like do not under any circumstances do this or this or that. You needed to do that in early 2026. You don't need to do that anymore. The second most common thing that I see, we're going to go through everything that I've seen. It's it's really entertaining stuff, is people will devise like some kind of factory system.

So, I'll speak to people who have like a codeex agent here and then they'll have like 10 more tabs and then they'll have their codeex agent here talking to their or it's an orchestrator that's talking to all these sub little tabs. They've got a little scripting system. Back in 2025, because the AI sucked so bad, smart people wanted to figure out how to make them work better. So, they started devising systems and factories and metaphors like skuorphic metaphors for orchestrator and then children and then message bus for them to talk and stop that.

Stop all of that. Okay? Delete your little factory system. delete your little instruction file that tells agents your novel, genius way for agents to interact with each other. Stop that. That's inhibiting your productivity. You don't need all these clever little hacks anymore. Just stop using like Gemini or something. You'll be like, use Opus 5.5, use Astra, delete your old stop with this funky stuff, and it'll get the job done.

Okay, number three, and this is by far the most common one, is that people treat context as way too sacred. They have agents like take notes after every change and commit the notes as like a markdown file in their repository so that f future agents can pick up and understand what previous agents did. Stop that. Okay? Stop having your agents take notes on things. Your code is the note. Your code is the spec. There's no need to create something separate.

It's all Chinese to the agents. Okay? They do not distinguish between English or code or pixels. It's all tokens. You creating two separate sources of truth is hindering your productivity and your agents productivity. Stop having your agent create documents. For the love of God, just let them write the code and let them commit it. If they want to comment it, let them comment it. Most likely, they will add some comments.

But then there's context from the other direction. I see people who have their agents draft specs for each little feature they want to build. So, they'll give their agent like a couple sentences in human readable format and they'll be like, "Okay, make a spec out of this and add it to my to-dos. Save it as a document so I can hand it over to my next agent or something." Stop that. Please stop that. There's no difference.

The agent that can turn one or two sentences into a full document is the same agent that would have just turned that one or two sentences into code. It's the same thing. You could have just skipped that SC step and have it turn have the future agent just turn one or two sentences into code rather than specs. Stop this whole spec driven development thing. Yes, in 2025 you needed really long detailed specs or the agents would just improvise foolishly at a cost too high, but now that is just no longer the case.

They do tend to make sane defaults. So the again these are all things old bad habits that you have from 2025 era agents um that you have not rechecked. Number five, was it number four or number five? Number four, I see people treat their conversations with agents as sacred. Okay, this is a huge mistake. What I mean by that is that, you know, I'm trying to look for an example here of my conversations. This is the app that I use.

It's called Enjoy. Go to enjoy.dev to download this. So, we'll go over why I think you should use Enjoy later in the video, but what people have is like huge conversations with agents and they'll just keep a mega thread going with like hundreds of replies back and forth because they feel that there's so much context in this thread that they don't want to start over. So, what they do is they have like 10 overall conversations that they keep going back to rather than creating a new conversation for every feature, which is the way you should be doing it.

Stop treating your English conversations as sacred context. It is not. What is sacred is the codebase. That's the context. The way you should be doing it is when you have a feature, you create, you start a new conversation, whether it's with enjoy, whether it's with a terminal client, whether it's with claw desktop, hit the plus button, type a few sentences, and hit send. When it's done, X out of that conversation and enjoy.

You mark it as complete and it hides it so that you focus on exactly what needs to be working right now in the terminal. Just close the conversation. Act like it never existed. Okay? Do not have the agent write that conversation history into a little context file. Stop it. You don't need to do that. Okay? Every little thought you have, hit the plus button. describe it to your agent, hit send. When it's done, close out of that conversation, and never think about it again.

Okay? The context is in the code. This brings me to the number six thing that I see very commonly, which is that people have, and and again, this is for like solo projects. They're starting a business, they're starting a side project, they haven't validated their idea yet. They have conbon boards filled with to-dos planned out for the next month. And each of these is like they they've had their agents like create markdown file like a huge markdown blob of context for what that task is.

Other people will have like huge to-do lists planned out for the next like month. And I'm like what are you doing? Why do you have a to-do list? Why do you have a conbon board as a single dude making a side project? Now, if you're savvy enough, if you've taken the Ship Academy course, you know that the number one thing you need to do very quickly is, of course, validate your idea. Get it in front of some alpha users so you can get actual feedback.

A lot of these people are just going into some kind of dark dungeon and just building for like 30, 60 days or something. They're just getting lost in productivity porn. They're getting addicted to the coding process and they just they go in and they make these factories. They make these conbon boards, this little productivity system. Dude, stop with your to-do list. Okay, stop with your conbon board. A to-do list is an anti-attern today.

Okay, here's the way you do it. When you have a thought, when you think to yourself, "Oh, I should add this to my to-do list." Stop. Go to your agent, hit the plus button, and type the to-do here and hit send and let the agent just do it. Okay? It's quicker to do this than to put it in a to-do list and come back to it and try to prioritize it. And if it's not worth doing now, it's not worth doing later. Okay? Do not add it to a to-do list because that just creates clutter.

And if you're worried that if you don't write it down, you'll forget. Good. Forget, man. Forget about it. Stop. Stop inundating your app with feature after feature. If it's important enough, it will come to the surface. It will rise to the surface. Now, the seventh thing that I see is people using funky tools to do aentic coding. Now, most of the people that I speak to are nontechnical. They're technically savvy, but they're not engineers.

And I see all sorts of things, man. Um, I've been trying to get people to use the terminal because I think that's the most that was before I built Enjoy. That was the most productive way, but because the terminal is hard to use for normies, it's why I built Enjoy. People are using really weird things like one guy was using anti-gravity, but he not to use Gemini. who's using clawed in anti-gravity. Other people are using claude desktop and then when they run out of quota they'll have their agent write a handoff document.

Then they'll open up codeex desktop. It's a mess man. And then codeex is like littering. You got to understand about chat GPT desktop and claude desktop. These are designed these products are designed to work for like billions of people. And the most vocal of those people will be the engineers who want like really verbose output. They want to see what the agents are editing and touching and thinking about and all these this technical lingo that these tools inundate you with that you don't need to know or bother with if you're just building an MVP or or or trying to validate your idea.

You just want to focus on the work. And so the these people are getting lost in these conversations in in chat GPT desktop and claw desktop. It's a total mess. And then they just they've lost idea of what they're working on, what they did, what they didn't do. So they start devising these productivity systems, these conbon boards. They don't know what the state of their project is. They have to ask in in many of these calls that I've had, I've asked someone like, "Oh, tell me about this or that." And it's a non-technical question, but they're like, "Hold on one second, please." And they asked their agent, "Mo is asking." And they're not hiding it.

They're just like, "Well, let me ask my agent. Mo is asking about our productivity system." And I I got to sit there and wait until the agent tells me that their productivity system. It's Dude, it's a total mess. Okay, here's what I want you to do. Okay, now I'm going to tell you to use Enjoy. Honestly, not because I want you to use my product. If my product wasn't good, I wouldn't be here trying to get you to use it.

I want you to use Enjoy because it is the best way to code with AI. And I have been using it extensively. And I don't use bad tools. I've made products before, man. God knows I have made products before that I've thrown them away. Hundreds of them. This one survives because it's useful. Now, here's how I have been doing agentic development. The sane way to do it so you don't get lost and confused. Now, when it comes to how to do it, honestly, look, the vision for AI, right, is that it's like an autonomous worker.

And with workers, you know, if if you're having to design like productivity systems for your highle engineers, presumably they're not good engineers, right? you want if if you want a 10x engineer, they sort of just get it done and that's how you should treat these these current frontier models. Let me show you how I would do something today. So, we have enjoy.dev's website. Let's say I want to make a change here, something drastic.

Let's just say I want to change the hero here to be something else. Now, the best way to go about this is to ask your agent to workshop something. Workshop means create a few different variations. and let me pick the one that I like and then it will just go out and build it. So I have a skill where I tell my agent workshop a new hero for our website and it knows what I'm talking about. So I will use codeex low here just to get moving and what that's going to do is it's going to put together a separate index.html file which are really high fidelity and it'll give me like three or four choices and it'll ask me which one do you like and I'll say one two three or four.

I'll say one build it and it goes and builds it and it does it well. The seventh thing, the seventh and final thing that I see people stressing over that they should not be stressing over with current level frontier models is code quality. I've had non-technical people pause their project because they're concerned about code quality. And I'm like, what are you talking about? Why why do you care about code quality, man?

Like again, if you're working for Google, you're making medical software. Yes, take code quality extremely seriously. If however you have not even validated your idea whether there's any market demand for your idea, code quality is the last thing you need to be worrying about. And the way we did this before AI in 2016 or so was that if you had a idea you wanted to validate, you couldn't hire a cracked engineer just yet.

You you had some 20-year-old build a proof of concept overnight, man. It was a mess. It was an absolute mess. The code quality was Most pre MVP software had horrific code quality. Okay, that was just the nature of building fast and breaking things. Where do you think that whole motto came from? I would wager that honestly that Astra code quality is probably better than a pre MVP startup code quality in 2016. Now, I stand by the fact that humans can write beautiful code in a way that I don't think agents can right now or or maybe even ever because it's such a soft thing.

But humans at their best, yes, can write beautiful code, but humans on average, if you're a developer, you know what it feels like when it's 11 p.m. and you're trying to get a feature to work and you just want to close your laptop and go to sleep more than anything in the world. In that moment, you will write truly horrific things. Okay, we've all been there. You need to go and validate your idea because your code base is going to change in a thousand ways by the time you actually get your first 100 customers.

And if you invest too much early on, it's it's kind of a waste. So, I'm not saying code quality isn't important, but when you're trying to launch a business and validate your idea in a market, it's not the most important thing. Okay, so here's the workshop that it created. It created four directions here. This one's pretty. This is actually really nice. This one's really nice, too. I mean, I'm telling you, Astra, by the way, is really good at design.

So, when you tell Astra to workshop something, man, I have been blown away by some of the the UX solutions that it comes with are really good. It's going to ask you which one do you like? And I'll say, you know, build O2 and it does it. And this way there's no surprises. This way, you're not fighting back and forth saying, okay, build it, make it pop, and then it builds something. You're like, I don't like this. I don't like this.

I don't like this. do that in the workshop because it's very easy for an agent to change workshop files because it's it knows it's disposable. Take all your feedback out in the workshop and then when it when you tell it a direction, that's it. It'll do it at close to 100% fidelity towards what you saw in the workshop. And so you will not be spending this time going back and forth bickering with an agent. If you are bickering with your agent, you're doing something wrong.

Yes. in in late 2025, early 2026, I spent most of my time bickering with agents and it was very frustrating. And so we we would design these systems to try to avoid it. That's not the should not be the case anymore. If you are finding yourself having these 100 message threads with an agent on a single thing, something's wrong. And my bet would be that you are giving your agent too much instruction and too much too much guard rails, too much system.

You're telling them to stay in one lane rather than just telling them the task and the acceptance criteria and letting them find the solution. So it might be that your agents MD file is too restrictive. It might be that you're telling your agents to read all documentation before starting a feature. Delete all that man. I mean I trust me I've been there. When I was doing this when I was building a product called Shape back in March and April of this year I tried just prompting, right?

I tried just launching one-off prompts and I just suffered and I was like, "All right, let me do this. Let me create what I called a bible of everything about shape, everything, the the aesthetic, the design, the principles, the backend, the front end." This way, whenever I ask an agent for a small sentence or two, I tell it, "Read the Bible first, then make your change." It didn't work either, man. It was it was a nightmare.

Now, when you go in, none of that Bible stuff. Do not tell your agent to read a bunch of docs before it starts. Again, your code is the context. So this is what I do. And then I say O2. That's it. And it says I'll build O2. And then it'll go and build it. So with Enjoy, by the way, the browser opens side by side. You're not having a 100 tabs open in your Chrome with those annoying colorful colorful automation badges.

Um the agent here can control this browser. Could take screenshots. And when I'm done, I'll just hit complete. And then it just goes away forever. Man, do not bring it back. You could reopen this I if you want to tweak something very specific that the agent did here. But the next time you want to make a change to your website, hit the plus button, okay? Start a new conversation. Stop treating your context as sacred. It is not.

Do not have separate documentation. Your code is the documentation. Again, it's all Chinese to the agents. So, as a quick tour of what enjoy can do and why I prefer using it here, I was having codeex workshop directions, but let's say you want to you've run out of codeex credits. You just switch to cloud code and you say continue and it'll pick up where Codex left off. There's no handoff document. There's no funky systems you got to devise.

There's no different app you got to track. It's all here. You have Opus 5.5. It just came out yesterday. You have an account switcher. So if you have multiple cloud code accounts or Codex account, you hit change account. You can create docs. And so if you insist on having a to-do, create a new markdown file and you say my to-dos priorities. You create a checklist, do this, do that. You can pin these and so they'll appear here.

So you can easily access your documents from here. You can browse your project files. You could edit JSON files directly here if you need to. You have workflows. So this is something I rely on heavily which is whenever I push up to main on GitHub I have these jobs that run tests publishing they always fail right because we're moving fast we're breaking things a test always ends up failing and so what I do is I have these workflows and I'll say I've just pushed to main monitor the CI job on that and make changes commit and push as needed to fix any test failure.

So I'll just hit run workflow and it'll do it. So Codeex is really good at this. Uh Claude can do it and it'll work for three hours, man. I'll run this. I'll step away and I'll come back and CI is passing on Maine. I mean, if you're a developer, you know how much of a relief that is that you you keep Maine healthy and and all the jobs passing. I have another workflow for desktop expedited. Here I say trigger a desktop deploy on GitHub and make changes as needed to get it to succeed.

Then you could do things like starting your your website server. I mean developers know typically you just open the terminal you hit yarn rundev and then you have a bunch of ter terminal tabs running and you lose track of things here you just hit run this workflow it'll start the process if it's not already running enjoy here will handle all your processes for you so you're not losing things it opened my website it registered the process so next time you want to know where is my godforsaken website you just hit open on this it'll open it you can open it in your browser and if you want to stop it you could Just hit the stop button here.

You can see the the output here. So enjoy. You will have way less browser tabs open, way less terminal tabs. It's all here. And of course, it's very easy to switch between different projects. I have enjoy here. I have ship academy here. I have an automations project where I just experiment with a few things. I have my notes here. Just using it as an obsidian replacement. I don't really like obsidian. I think it's too clunky.

And so I just take all my notes here if I if I need to. Of course, you can control this from your phone. So if you go to app.enjoy.dev dev from your phone or from any browser. You can connect to your desktop and you could send commands, you can start new work, create documents, whatever you could do on desktop, you could do from your phone. It's a blast, man. I have never had more fun working with AI before. If if I if Enjoy didn't exist, I would be recommending you to use the terminal because it's just the fastest, most ergonomic thing.

But this was my fate always. I had all these tabs. I couldn't keep track of what was running, what needed my input, what this tab was working on. It was a mess, man. And if I struggled with that, imagine trying to tell non-technical people to use it. It It was a lost cause. And I think even the cloud desktop app, it's too clunky, man. The Chad GPT desktop app, it's it's inundating you with all this information that's distracting you from what needs to actually be worked on, and it's not helping you push your project forward.

It's just context and context and buttons and and statuses and I've people are just getting lost man. So enjoy was born out of all these conversations that I've had with people and I didn't initially set out to build something. I just wanted to understand what people were doing so I could help them and give them and and give them guidance and advice. And once I've seen all that I was like dude there has to be a better way.

And that's what enjoy is. So that is the current state u from my vantage point of aentic engineering. Stop the things you were doing in 2025 early 2026. Stop using funky models for now. If you are launching a business or a project you hope to make money off if you think you can't afford to use Astra. You can't afford to use Gemini to be honest. So spend the little extra money if if you have a corporation. It's a tax it's a business expense.

So you could write off your AI subscriptions. What I would recommend is going no lower than Opus. Opus is a very good daily driver. So if that's cheaper for you, then Astra, do that. Default to high. I would say default unless you're doing pixel level changes. If you're doing anything like architectural or new feature that requires touching a lot of things. I would default effort level too high on both claw code and codeex.

On codeex go no lower than Astra. I know Soul and Terra six came out yesterday. I played a little bit with those, but still Astra is going to be hard to beat at this point. Astra High is pretty fast to be honest. Now, if you're sitting there working on one thing at a time and you're just waiting for something to finish, you're going to feel like everything's slow. But if you're working on four things at a time and and you're able to productively manage those four conversations, things are going to be moving very fast because there's always something happening.

And actually, one more thing, I forgot to mention this one. This is a very important one. Number eight, branches and work trees. Oh my god, you guys are going to burn me at the stake for this. But stop with the work tree stuff, man. Stop with branches. Okay. Yes, in 2025, early 2026, you needed work trees and branches because agents were slopping on each other's work, deleting other agents changes. It was a mess. I have honestly found at least with Astra High, that's the model I've been using for everything, I could have six things running on the main branch at the same time.

And I have not had any incidents with agents overwriting each other's work. In the lifetime of Ship Academy and Enjoy as projects, I have not used a single work tree or a single feature branch. It's all been on main. Now, I will admit that I do apply a little mental filtering so that if I do have six tasks running, I know that they are somewhat isolated in scope. So, I'll never have three tasks running that I'll say edit the feature, edit the hero on the website.

Okay, that's don't do that. Even if you're using branches, even if you're using work trees, don't do that. But I will very comfortably have six agents running. One of them is doing the website hero. One of them is doing logout cookies. One of them is doing a feedback form. One of them is fixing a bug here there. As long as there's no meaningful overlap. Do not create separate branches. Do not create work trees. Stop over complicating your workflow is all I'm saying.

Okay? Start with the most naive thing you could possibly do, which is one branch and just giving it all you got with as simple as descriptions as you can. And only when you encounter failure with the current level of models should you then adapt your workflow. Because the thing about branches of work trees is they're they're just mental overhead and it it makes things a little messier. What I do honestly I have a little instruction that says after every change commit your changes.

And so you have this little little tiny log that an agent works for 5 minutes it commits its files. And so if six agents work each one just commits their files. If one agent screws up I just have it revert its changes. And by the end of it, when all six agents are done, there's there's not a whole bunch of unstaged files. There's zero unstaged files. And so each agent has taken responsibility for its chunk of work. And if they encounter something like, "Oh, I see these unrelated changes." Firstly, they will say, "Oh, I shouldn't touch this." They know, but also they'll flag it to you.

Like if if their work gets overwritten by another agent, be like, "Oh, my work got overwritten by another agent." Like they're they're pretty good, man. They're pretty good. Start as naively as possible. Imagine that you are getting into this for the first time ever. You have no preconceived notions of how Agentic engineering should go and then make corrections as you need. But throw away your old workflows. Throw away all that stuff.

Start simple. So, two things in closing. If you want to get enjoy.dev, head over to enjoy.dev download. You get a 7-day free trial. You can try everything. If you don't like it, hit the cancel button and you're all set. I promise you that you will like it. There's a lot to love. It's It's called Enjoy for a reason. It's a lot of fun. The second thing is if you're already good at this building stuff, but you kind of suck at marketing, which is where a lot of uh people building are to be honest, cuz the building is easy.

Now, the marketing is harder than ever because there's so much competition. Head over to shipacademy.com. This is where I teach you the importance of positioning and branding and storytelling and how to do that and how to use AI to do that and how to actually ship rather than just build and how to get your first customers and all of that. I put a lot of time and effort into these classes, real testimonials here from from members.

Head over to shipacademy.com. And actually, if you buy the Ship Academy course, you get one year free of Enjoy. That's $180 value. But if if all you want is if you're good at the marketing stuff and all you want is to build stuff, I honestly wholeheartedly like if I was if I was telling a friend how to get started, I would tell them to use this and it's what I use. I will not go back to the terminal, man. I like if I thought it would be more productive for me, I would go back.

I don't want to. Like I've never been more productive. I sincerely mean that. If you have any questions about any of this stuff, if you want to see what other people are doing with their agentic workflows, you want to talk to me, join our Slack on Enjoy.dev, in the footer, there's a join our Slack button. I'm active there. I love helping people. I love giving people feedback, advice, or if you need help getting started with Enjoy, ask away.

There's people there, too. I share a lot of tips and tricks there, too. So, that is all. I hope that is helpful. I've taken everything that I've learned from all these conversations that I've had over since I started my my whole YouTube career and I've condensed it here into one video. I hope that helps and I will see you next time. Thanks for watching.