Transcription
Learning AI in today's age is one of the hardest things you can do. There are literally distractions everywhere. And every single time you think you've mastered something, something new comes out, making it seemingly obsolete. And the issue is you keep bouncing around building half-built bridges or half-built skill sets in every part of AI. Or even worse, you work with a series of people that live in the stone age that still hate the word AI and think it's useless even though it's doing more and more of our work every single day.
Having worked and studied in the AI space for now more than 10 years, I can tell you very confidently that despite all of these paralyzing factors, upskilling an AI is one of the most valuable things you can do for yourself, your career, and your business. So, in this video, my goal is not to give you a list of shoulds because I don't think the word should should apply in this space for tools, models, or frameworks. Depending on when you watch this video, the name of the most popular tools trending on Google search results will have changed or might have changed order or might have changed priority. So, it's a lot more important for me to convey to you what you could do to avoid this video becoming yet another YAP session on the internet. I'm going to make it a lot more tangible. I'm going to walk through the four biggest mistakes that you could make learning AI, whether you are at zero from scratch or you're immediate to intermediate. And to make it even more tangible, I'll walk through the top 10 questions that I've received from thousands of hours of consulting as well as with mentoring in my community. And these questions will be evergreen. Meaning, if you watch this 3 months from now, a year from now, hopefully my answer will give you what you need to take the path forward. And the last thing I'll leave you with is a very simple road map that you can tether to whether you're starting or you're already on your journey learning AI. So you can have tangible steps to go from someone who kind of wants to learn this stuff to being an actual practitioner, whatever being a practitioner means to you. Let's dive in.
All right, so starting off, these are the four biggest mistakes that I see happening every single day and it hasn't changed since Chad GBT first came out. The first mistake is the perpetual beginner syndrome. And this is what happens if you're either starting out or you just keep restarting every single time you see a brand new tool, framework, or thing come out, very shiny thing that might not even apply to what you're trying to do from a use case perspective, but you keep relearning every single month. And when you do that, you're really depriving of yourself. Even if you watch YouTube videos, including mine or whoever's, and you feel like you're learning passively, you're actually learning nothing because you're either barely applying it or you're applying it for a weekend to build a small project and then you either let it go and move on to the next thing or you become paralyzed in fear as to whether or not you should stay and double down or move on to this brand new shiny tool that says it's better or kills the rest of them.
And the next one is tool addiction. And I literally made a video on this in the past 30 days where you just keep stacking not just tools but also courses and even school communities. I meet some people every day that are in five, 10, 20 paid school communities. Impossible to keep up with with YouTube videos, feeds, X, Twitter, LinkedIn, every single school community. It becomes overwhelming. So again, you fall into the same trap where you think you're ahead of 90% of people and you might be exposed to more than 90% of people, but you don't actually know much. You don't know anything really deeply. You're at a shadow level where you know a little bit about everything.
The next one is learning theory over practice. So you learn everything you know about prompt engineering, but you don't actually tangibly try prompts and see the results and iterate and see what happens when you try this model versus the other model to better understand the entire landscape and ecosystem of when you should ask for request A for chatt versus request B from Claude or request C from Gemini. And the issue here is you accumulate knowledge and you having that knowledge and accumulating it gives you the perception that you are a great AI consultant or you are a great AI practitioner. But if you try to provide advice to someone else or another business or another person on how to use AI, your opinion doesn't actually carry that much weight because you have a lot of things in theory. But generative AI in practice, not even normal AI like machine learning and stats, which is more deterministic. But generative AI is unpredictable in the real world. So for you to say that you've accumulated all this knowledge, that you know exactly what model to use when, but you haven't actually used them to see and have that been there done that logic is what will hold you back.
And that segues to this last point, which is learning instead of building. So, you take a 6-hour end course, but you have built half a workflow or you just did the normal one where you put a chat trigger and an agent and you say, "Look, I just built my first automation." And then you stop there and as soon as you see something scary like, "What's an HTTP request?" You stop, you pause, and maybe you go back to, "Oh, look at this new thing from Chat GBT. Look, Sora 2 just came out. Let me just drop everything and learn that."
Now, these are the mistakes. So, I'm going to walk you through now the 10 questions I told you about to walk through the question, how I would think about answering it. And again, the answers to these questions are not shoulds. They are my opinion based on seeing tons of applied knowledge in the space, having personal tons of failures with client projects and tons of successes.
Now, question one is, should you focus on learning to code or learning to recognize and work with code patterns? Very common question I get. If you're trying to be a core engineer and you want to build things that are brand new that haven't been done before, or you want to do things reliably and scalably and robustly, then learning to code in my opinion is not just a good thing to do, but you still should have to learn all the patterns and the fundamentals because language models, even though they'll get even much smarter. You'll be able to oneshot all kinds of brand new things. At the end of the day, I do think that at least understanding the principles of how these things work is helpful. One thing you have to understand is language models can only build what they've seen before. So if you're trying to build something cutting edge that hasn't existed and you want a vibe coding tool or any form of AI editor to take you from zero to 100% on its own, maybe with enough iteration, it could take you there with enough push. But if you understand what's happening and you can read the screen and recognize and basically intervene, then you can actually build something where AI takes 80% and then you come in for the last 20%.
Now, if you don't fall into that bucket and you just want to build automations, then you don't need to learn how to code. But it's helpful to recognize code. So, doing a four, five hour free course on YouTube, learning things like JavaScript and Python, just understanding that there's something called a function, there's a way to call a variable. When you go and open up something like a cloud code or you go behind the curtains of something like a bolt or a lovable, you can literally see and start to spot patterns of where the AI might have hallucinated. Because where people run into issues with Vive coding and anything like Vive coding is they have no clue what's happening on the screen and then they build something and they get confused why it gets hacked, why it gets compromised, why they can't push it to where they want it to go and it's stuck in one specific area and they can't open an editor and recognize the code to see ah there's duplicates of the same function or there's duplicates of this functionality stopping this app from moving forward. So learning to recognize code to me is a cheat code for anyone trying to work with AI especially if you want to go the full nine yards and use something like a cloud code cursor winds surf etc.
Now the next question that primarily comes from business owners is what essential automations should every business implement first regardless of industry and this is tricky because every industry has its nuances and pros and cons. But if you're starting from zero, then you want to remove as many admin tasks that don't need genuine creativity and you want to start down this ladder or this hierarchy where ideally you want to take the most deterministic which in plain English means predictable workflows where you don't need AI at all where you just have workflows or just Python or JavaScript functions. So a tangible example is if you do onboarding for clients and when someone pays for your thing, they get an email that automatically gives them the link that's the same link every single time. They get invited to this Slack or this Discord and then you ingest them into that portal and then they go through the same kind of repertoire of start to finish. Then it makes a lot of sense to be deterministic and build a normal automation. People get really hyped about adding AI agents or generative AI to everything where generative AI is something in my case you treat like a dog on a leash where you have the leash really close to you and you release it as you need more creativity and you have an error tolerance in your system. So doing everything also revenue adjacent will get you some more ROI versus just stacking automations for the sake of stacking automations. And other things you could think of could be like email management, CRM, note-taking and then not just doing the note-taking but taking the assets from the note takingaking outputs and storing them in systems where you or someone else on the team would have otherwise had to do.
The next one is what future skill sets will be the most valuable for automation professionals. Now automation in general I think a lot of technical skills the core moat of that of understanding when to use a web hook when to use a HTTP request when to use both a lot of that will become more and more commoditized every single major provider of automation now is moving towards text to workflow now none of them are perfect and I don't think perfect is really something you can strive for it's really in the eye of the beholder of the automation but it will continue to get better and better so that core skill of putting nodes on a canvas will not go away but it'll be less valuable. What will be infinitely more valuable is the strategic thinking because when we can do quote unquote anything then now you have a new set of paralysis for everyone trying to implement AI. So if you've been there done that and you understand the fundamentals and you've built automations then you can answer the questions like what is the most valuable thing for me to do right now? What is worth doing? What's probably going to be a tricky automation? and what should I put on the back burner for later? So, strategic thinking in the future, yes, you're going to say AI can also do strategic thinking. Sure, but for now, if you are a master of this craft, a master of the craft of automation in a certain industry, it's not the nodes or knowing how to put together nodes, that is the skill set. It's understanding the design thinking of what should fire first, how should it progress, should you have agents, if so, where? If not now, will you add agents in the future? What's the criteria for adding those agents? You can go down a rabbit hole of logic on whether or not an automation is built well, robust, scalable, and most importantly, tailored for someone's processes, which the same business in the same industry, two different owners will have two different processes. So, thinking through how to make those processes something that's eligible to use AI is going to be also another barrier to entry.
Now the next one is when should you use no code low code tools versus something like a Python, like a JavaScript, like custom development. And the real question people are usually asking is again, can I avoid learning or recognizing code or seeing code on my screen and just deal with nice pretty bubbles? And the answer is always it depends on a couple things. The time horizon, what you're trying to implement, whether or not you have native tools you're trying to integrate with that would be a bit of a pain otherwise. So if you use something like a make, zap year, any insert name of tool here that makes it easier to authenticate into really annoying to work with systems, it might make sense. And if you have linear workflows, it also makes sense. If you're trying to deploy something from an idea to something tangible within days or weeks, not months, then it definitely makes sense because custom development takes more time because it's custom. When it comes to security and a lot of concerns about legacy systems marrying with new systems, custom development now really shines because you need that flexibility. You need to be able to be malleable and nimble with the way you build the solution. And the one twist here is we're moving from a world where you have to do linear workflows that don't have a lot of authentication or special services just using something like a cloud code or a cursor. You're going to have things like cursor or cloud code where you're going to be able to send over a prompt of what you're trying to automate and assuming that it's not very authenticationheavy or serviceheavy. It'll be able to do it in one shot in the same amount of time without 15 different nodes in a workflow. Because at the end of the day, no code tools are what are called layers of abstraction. And what that means in plain English is it's trying to make using Python and JavaScript less painful by reducing the chance that you see them in practice. But if we go into a world where cloud code becomes a pseudo chat GBT where anyone can theoretically technical or non-technical hop into a terminal use English or whatever native language it is to ask for something to be automated and now you have a full workflow running just using Python without the middle software then you don't necessarily need the middle software. So again, it really depends on what you're trying to build and how you're trying to build it.
The next one, very common one. What's the difference between fine-tuning and rag and when should you use each approach? The first thing I'll say is again, we're moving to a world where depending on when you watch this, we could have context windows of 5 million, 10 million, 50 million, could be 100 million eventually. So when it comes to something like rag, I still think there will be pockets in the future where it will still make sense to do this for some form of retrieval. But if we live in a world where you can dump a 100,000 documents into a language model and you don't have what's called context rot where essentially it has a hallucination or has amnesia of the data that you've put into the prompt because it's so long, then you have a case where you need things like rag and fine-tuning less and less. And if you don't know what RAG is, it stands for retrieval augmented generation, which just means you take text, you make text into number, you store number into database that stores a lot of those different numbers, and then you can do a lookup based on how similar a question is to what's in the database. Fine-tuning is one of the rarest things you'd ever want to do, which is you want to give a PhD to a model that has a masters in everything. And this one really makes sense if you're trying to emulate a tone or a brand voice or something that is so specific that even with the best of prompting and chain prompting. This is the course of last resort. And the reason why I say last resort is it's annoying to update fine-tuning because you have to retrain the model, have brand new examples, and do tons of quality testing to make sure it works. Rag makes a lot of sense if you're dealing with a database with hundreds of millions of rows where it doesn't make sense to take a whole database nor is it secure and copy paste that into a prompt just to ask a singular question that is completely computationally inefficient not a very straightforward way of doing things and it makes more sense to do it in a more procedural way. Now I also think that rag and what we call rag today will also evolve over time.
The next one is what are the practical use cases for voice agents in different industries? And this one is an interesting one because to me in some industries if a voice agent isn't 100% indistinguishable from a human, it's either zero or 100%. But in other industries, it's very flexible. If it works, amazing. If it doesn't work, then maybe you have a human in the loop. This will continue to get better and it'll become even more indistinguishable where someone's voice will be so close to a human that you literally can't tell. But in most cases, we're still not nimble, enough to make it worth it. So if you proverbally replace someone's receptionist, and that receptionist is responsible for bringing in business, but that receptionist actually closes the four or five that come in through the month. Whereas this voice agent could be amazing at 99% of cases, but maybe those five calls that really matter, it completely blunders. So the ROI of replacing that human being with this AI thing might seem on the surface like it's really well justified, but in practice, in production with people who have accents, who sneeze, who say, "Sorry honey, I'm on the phone." And it confuses the AI and changes the cadence, it's still not fully there yet. But in industries where someone literally doesn't have time to pick up the phone, like you are a plumber, a roofer, you have a lot of people in the field working that physically can't take a call to book, then I call that a surplus opportunity where things like voice agents are super helpful because you can fill in the gap where a human wasn't going to be there to begin with.
The next one is what emerging AI technologies are worth investing time in learning. And what I'll say here is I'm not going to name drop any tools because depending on when you watch this, it might completely be different. What I will say is the skill sets worth learning are evergreen skill sets. And if you're going to make a bet on which platforms to learn, ideally learn from the platforms that one have a lot of backing behind them because generative AI is very much a loss leader kind of industry for a lot of tools and services and frameworks. So even though there's for example 10,000 vibe coding tools, one coming out every single day, and by the way, you can pretty much build your own version of these vibe coding tools with all the technology we have today. But if you take those as an example, if you say, "Oh, look, ABC.xyz platform now can allow you to build mobile apps and web apps and it looks really shiny and clean and they have this kind of database versus that kind of database. you're also investing your time in something that might not exist next month if they don't have enough money to pay the bills. So, ideally, if you're going to invest your time learning something, you want to look at the long-term horizon of their survivability. So, if you take some of the giants like the Open AIs and the anthropics, what's the likelihood that they're still going to be around in a couple years? Now, outside of regulatory stuff changing that from a money perspective, from a network effect perspective, they'll probably still be around. Now, there could be some new entrance, but as the time progresses and more of these companies become super companies where they have super apps, super models, they're integrated into our emails, they're integrated into our phones, it becomes that much more sticky and more importantly, that much harder for new entrance to come in. Now, why should you care about this from a business perspective? Well, if you can see the road map of where each one of your tools you're investing in are going and you're doubtful whether or not one will survive more than three months, then why are you taking the time to master to begin with? Which is why I typically have a very lean tool set where I don't really move beyond it. And for me personally, as of today, it is all the core models. So, the Gemini, OpenAI, Anthropic, I know when to use each and where to use each. And then I have one editing tool like a cursor cloud code. And then I have one vibe coding tool for something very quick and dirty. Then I have one automation tool that I really focus on. I can use all of them. I've learned how to use all of them and when to use all of them, but I stick to my guns on five or six tools that are my core that allow me to go really deep and each one or I can combine multiple together and I can get new combinations of tools that I can either build or use or deploy.
Now this next one's a tricky one, which is how do you navigate markets with low AI adoption and overcome institutional resistance? Now, there's no silver bullet answer for this, but typically what I've seen is if you focus a lot more on the pain point versus the technology to solve said painoint, you'll move a lot quicker and a lot faster. And people will naturally want to look and see what this AI thing can do. And we have enough infrastructure tools. Do you have enough cloud providers to give you enough ways to build something and deploy something that is technically secure where even the language model is within a contained environment that you can even see exactly what's happening and none of the data ever leaves that container. But if this is not based on regulation specifically, but more so on a culture you're in or a team environment you're in, then typically I like to call it the Trojan horse strategy where you build something to solve a particular painoint. You vibe code something over the course of a night and you don't even tell them that it's vibe coded. You just say that I built the software that does X and then sometimes you'll be able to get that wow effect. This is awesome. I didn't know you're a programmer. And then you can say oh look I'm not I use XYZ tool. This is why this stuff is so helpful. We can go from zero to this in a snap of a finger. So sometimes alleviating these concerns is a lot more powerful by you just showing the solution and that it worked versus saying I want to use this so I can solve XYZ problem. Again, is this foolproof for all scenarios? No. But it should give you some points of entry.
The next one is what industries are underserved by AI or automation beyond the obvious ones. And this one's pretty straightforward for me. You have industries like construction, like agriculture, like logistics. And logistics is very hard to apply a lot of generative AI to because it is unpredictable in a way and there are many moving parts. And it's hard to prompt all those different parts or build a system that is dynamic by nature for a very dynamic environment system. And then you still have things like non-forprofits as well as municipal governments where a lot of things could literally be done by AI, not to replace people, but to give the average citizen a much better experience with their day-to-day things. If you take a big picture and look at the way you pay your bills and the way you submit payment to all kinds of different services, it's still using technology from the early 2000s. So, there's so many industries, whether you're trying to monetize, educate, consult, there's so much opportunity here, which is why I think it's so important for you to upskill yourself and there's so much free content on YouTube that you can go from zero to someone that knows what they're saying in a practically very short amount of time.
And the last question is, how do you balance speed to market with building scalable foundations? And this is a question that comes from all kinds of people. There are some people that are so obsessed with building the perfect workflow that is so robust and has the best quality check and is the most world-class design of that workflow even though one they haven't validated the idea, two they haven't audited their systems or their client systems to see whether or not they're even eligible to be automated. And then three, a lot of times in this world where you can build quote unquote anything, it's much more important that you just validate the idea. So you can vibe code, vibe automate, vibe whatever in a very short amount of time. See if it has legs, test it out, and then build it a little bit better and then build it so it can handle, let's say we're taking a vibe coded app, so it can handle five people and 10 people, 50 people, then 100 people. You can keep revisiting a build and as new technology and models come out, which they literally do. I was in the middle of building something yesterday with the old version of cloud code and now I updated to use the new version and now what I thought was going to be a three-day process was a one-day process. So as you iterate this technology will continue to change underneath you. So if you build in an iterative way as the space continues to iterate and it literally won't stop because if these companies are taking the data that we're basically outputting and going back and forth with claude and chatbt and using it to retrain their models then yes they will get better because they will have even more brand new training data that we're literally giving them. So I'd say planning a specific rigid cemented process of saying we're going to start project from zero and end it at day 45 and that's it is probably not practical for this new world. Once you have something working and it's in production and you can validate that it's actually working the way we expect it and you see all the edge cases then and only then in my opinion should you double down and make it really robust. Assuming again, you're not catering to enterprise clients or you're not catering to the masses, in which case it makes sense to go down the slow and steady route where you build something for as much perfection as possible. But for most of you, that probably doesn't apply.
And last but not least, I promised you a road map. Not the road map, no shoulds, but a road map. So looking at it, we only have really a few different sectors that I think through. Sector number one is tools and taste. So if you're starting from zero, go and test out become a pseudo expert. Work with build, try to break the chatbts, the cloudy eyes of the world. Just those two tools alone. If you go deep and you know something beyond write me an email and you make images and you test out every single model or now we have different tiers of thinking, understanding what thinking is and how much thinking can help or hurt your prompt because sometimes people think that thinking is real. But the thinking that we see in these tools is a bit of an illusion. So if you quote unquote think for eight minutes, you might get a way worse result than if it thought for four minutes. These are the things you can go really deep on that and people bounce around from tool to tool before even mastering the basics. And ideally while you're mastering these tools, you're trying to also identify the problems that you're trying to solve with them.
The next phase would be systematic prompting. And I keep harping on and I will continue to harp on that prompt engineering is the bedrock for every single thing in this space whether it's image, video, new model. Every single time a new model comes out, it has brand new weights. When it has brand new weights, the way you speak to it and the way it speaks back to you will change ever so slightly. So being able to be nimble and look for those nuances and read system cards or have AI read system cards for you and understanding what system prompts are will help you become that much better than the average person. And like I said before, it's more important than to learn the theory is to actually apply it. Test out the prompt, see what changes, see what breaks, and even test out something like apply the same prompt in an automation could be very simple 100 times and see how many times the result drifts. If you don't know what you're doing, it will drift a lot.
And the next thing you can go through are things like architecture and agents. And we live in a world right now where every single thing is called an agent, even if it's not. So a chatbot is being called an agent. A workflow automation with an agent node is called an agent, even though just a workflow automation featuring AI. So in a world where the definition of these words is really all over the place and it's muddied, it's really important to double down eventually once you have your footing and understanding different design patterns, different agent structures, what is an agent, what is not, what is the spectrum of the word agent. And then once you have your core stack of tools that are not necessarily immutable or they don't ever change, but for the most part are pretty predictable which ones you're going to stick to, this is where you can start to specialize. And this is where you can start to say,"I really love making AI images for UGC or AI videos using this kind of model." Then no matter what new model comes out, you're already such a specialist cuz you spent all the time understanding and seeing patterns that you're able to build whatever you want and become a real specialist in that domain. And just to think four, five years out, we're going to have humanoid robots pretty soon. And how do you think those are going to interact with the real world? Will they read your mind? probably not the beginning, but they will need to be prompted just like LLMs need to be prompted. Now, the way you'll prompt a humanoid robot to go and fold your clothes will be different from the way you ask midjourney to make a picture of a goose. But by learning prompt engineering and understanding that rhythm and flow, you will continue to be nimble. So the ground will continue to shake and move beneath you, but you'll be able to jump to the next step because you have the prerequisite skills and the knowhow and the being there done that experience to be able to adapt because we need to be in a world where we're constantly learning forever. And with that, I hope it helps shape the way you think about the AI space in general because it can be daunting and completely overwhelming. But if you break it down into individual parts and you try to look at the big picture as much as possible, you'll be less affiliated with these tools that kind of have cultlike gatherings around them. The goal is you understand the foundations and the goal is you know how to apply them because in the not-so-distant future all kinds of technical and non-technical skills will continue to get automated. But one of the things that will remain from people that win is understanding and having familiarity with the ecosystem of AI. knowing what different sectors there are, what different tool sets there are, which tools are better than others, which tools are you willing to bet on for the next 12 to 18 months. And the goal again is to continue to learn, but learn the things that matter versus learning the noise.
Now, very atypically of me, I have three call to actions. The first call to action for the majority of you is if you check the second link in the description below, we put together a beautiful care package of some beginner automations that you can get started with. And these are not rinky-dink automations. We've actually tested it. You can build it. You can use it. You can take it off the shelf. So if you are actually starting from zero, then you can use that.
Call to action number two is if you're a client watching this and you're looking for help implementing using AI, actually having someone build your automations. I'm not going to market my personal agency to build those automations for you, but a brand new network that I'm bringing to market called the AI Expert Network. And this is a network that I'm building from my community called Early AI Do Adopters where I'm focusing on upskilling as many people as possible to be those strategic thinkers of the future where certifications won't matter, letters after your name won't matter, but actually understanding what you're doing and more importantly why you're doing it will matter. And the cool thing about this community is we're going to make it free for you, the client, and free for the actual freelancers themselves. Because one of my core goals is to try to help as many people not just upskill, but also find meaningful and sustainable ways to monetize having this AI knowledge, but more importantly applying it. If you are a client and you are looking for some talent to help you get started on your AI journey, then check the third link in the description below. It'll be a waiting list for our soft launch of this network coming very soon.
And the last call to action is if you want to learn AI, you can learn everything you want for free on YouTube and everywhere else without adding an info product, a community, or a course to your stack. But if you want to go faster, if you want to be around other people that are also specializing and want to level themselves up, then absolutely check out the first link in the description below for my exclusive community called Early AI Do Adopters. If you watched this far, then you're a legend. I thank you and I'll see you in the next.