Here's 10 skills to become god-tier in AI agentic coding

AI has gotten really good at writing code, but still not very good at building good software. And that's the major reason why you see most of the good and half-decent AI apps out there are built by people who already have some previous experience building software. Maybe they're software engineers, they're web developers, whatever they are, right? But they have some previous experience building software. And that's because there's a lot of different skill sets within software development besides just writing more and more code that are crucial when you're trying to build a good app. And in this video, I'm going to go through all of them for you. So if you're some vibe coder, or you're a junior developer at some company, or heck, you just want to level up your software development skills in the age of AI coding, this video is going to be extremely helpful for you because I'm going to tell you exactly what skills are valuable now that AI has basically started writing all the code for you. So, with all that being said, let's head over to my screen where I can teach you exactly what you need to know. So here's what we're gonna do. I'm going to explain the following 10 topics to you, right? We're gonna go discuss, we're gonna go through databases, data structures, algorithms, system design, and everything else you see on this list, right? I'm not gonna teach you everything there is to know about this topic because that will take like 500 more videos of this kind. What I am going to do is give you an overview of this topic, what it is, how we use it, and what kind of problems it solves and why it's still important today. And I'll give you some sort of a roadmap or some learning resources so that you can go out there and learn these things for yourself. Right now, as you can see, I built this entire little whiteboard presentation for you. So let's start with databases. So databases, one of the most important topics you as a developer today, despite AI writing all of your code for you, right? You need to know how databases work. You need to specifically know about relational versus non-relational databases and when you should be using which one, right? In most cases, you would be using a relational database like Postgres or MySQL or something like that, but there are many cases where something like a document database like MongoDB or something else works really well, and you need to know when to use which. You also need to know about vector databases. Now, vector databases are really different from traditional databases in that they don't necessarily store data the way you think about it. They store vectors, as in really large numbers, basically. And without going into too much detail about them over here, they're basically used a lot in AI, in LLMs, in RAG, in all sorts of different AI workflows and models, right? So this is extremely important for you to learn. Some examples of vector databases are ChromaDB, Pinecone. There's also a Postgres extension called pgvector, I believe, and you can use that as well. But yeah, learn vector databases. Along with that, learn about query optimization because AI can write a bunch of SQL queries for you, but you have no way to tell whether they're good queries or not. You also don't have any way to optimize them if you need to, right? One query could take 10 whole seconds to finish executing, while another, more efficient query could take something like, I don't know, 50 milliseconds, right? That's a huge difference, and so learn about query optimization. I'm not telling you to learn SQL syntax or whatever. I'm saying learn how to optimize queries and write better queries. Learn about things like indexing, about joins, left outer joins, right outer joins, and how they work and what they do to the database columns and everything. Learn how to analyze the performance of every single SQL query you run. I know that Postgres has its own internal tools that can help you to analyze the performance of any SQL query. I'm pretty sure other database systems have their own equivalent of that as well. So go learn how to use them and how to, and how to write good queries with them. Now, lastly, learn about scaling because you can build toy projects all you want, but at some point you need to get them out to real users, right? And when I say real users, I don't mean your family or friends. I mean hundreds or thousands or tens of thousands of real users, right? And when you get to a scale like that, you need to know how things like read replicas work, how things like sharding works, right? Different optimization strategies like these that help you to scale your app to hundreds of thousands or even millions of users, right? So when you're building real apps that ship to thousands of users out there in production, you need to know about these things as well. Now, with databases covered, let's talk about data structures and algorithms. So the reason you need to know all these different data structures and algorithms is mainly so you can write more efficient and better code, right? Like an algorithm is basically just a series of steps, right? It's not something complicated, but the main value there is that you need to learn to write better algorithms. You need to learn to use better data structures so that you can increase the performance of your application. For example, if you've got some API, you've got a really horribly optimized endpoint over here that takes 10 whole seconds to finish executing, no human being is going to sit through that, right? You're going to lose users, obviously. Whereas if you had a really highly optimized endpoint with good queries, with fast performance, that finishes running in literally just 200 milliseconds, which is like 0 seconds if my math is correct, you're going to retain a lot more users. Not only that, but your cloud infrastructure costs are going to be lower because you're not using as much compute. You're going to finish your requests faster, all sorts of good things, right? And the difference between a really poorly written endpoint and a very fast-performing endpoint can really just be the data structures and the algorithms you use to do all the operations in that endpoint. And as a very simple but really practical example, if you've done map lookups in programming, right, like hash maps, dictionaries, basically a dictionary in Python, right, that's called a map. If you've done those before, you'll know they're extremely fast, even if you have thousands or tens of thousands of items inside your dictionary or hash map, right? Why are they so fast? Because they have an O(1) lookup time, as in no matter how large that map gets, the time to find an item inside it is still constant. Whereas if you try to look up some items in an array, that has a time complexity of O(n), which basically means the larger that array gets, the more time it's going to take to find items in the array. So, super simple example of using good data structures. If you've got a really large, you know, list or whatever, and you need to look up something in it, that's going to take a really long time. If you instead had a map, like a hash map of that entire list, looking up something in that map would take like a millisecond, probably. Now, where do you go to learn these things? Well, there's a roadmap to learn data structures and algorithms over this link, which you can open up, and it'll just give you a big bunch of topics to learn, and you can just get started there. Now, let's talk about systems design. System design is basically how you design and architect your entire application, right? It's not necessarily the code you write. It's more how you structure everything, how you design everything to be, to satisfy these four main criteria, right? So, scalability. What do I mean by scalability? Are you designing an application that can easily be scaled to thousands or tens of thousands of users? Because if you're not, you need to fix that. Maintainability. Is your application going to be easy to update and refactor later on? Or is it some giant AI-generated mess of code that nobody is ever going to be able to touch, right? Because these things matter. Availability. Is your system designed to be available, or is it just going to crash 20 times a day like GitHub does nowadays? Like when you see things like 99.9% uptime on websites, this is what they're talking about. They're talking about availability. And availability isn't strictly limited to your web servers being online. It can also mean different individual features inside your application. Do you, let's say, a certain feature in your app stops functioning properly, right? Is that going to affect the rest of your application? Is that going to take down the rest of your application? Or can it gracefully handle its failures, go down individually if it has to, but let the rest of your application keep running, right? Because those things matter as well. And lastly, let's talk about reliability. Is your system reliable? Can users make changes to it and expect them to stay there, right? If you look at GitHub, for example, nowadays, it's malfunctioning really horribly to the point where you can't even trust a PR that is merged to actually retain those changes. Like, you could merge a PR on GitHub nowadays, and you wouldn't even be sure if it actually merged those changes or not. Like, that's the kind of bugs that GitHub is now going through. So obviously, you don't want that. So can your system or your app be completely reliable for users? Can I make some changes in it and expect to see those changes live permanently without some sort of malfunction? Because, like, look, a lot of people go really deep into UI and UX, right? Designing the right user experience for users. Let me tell you something that's going to save you a heck of a lot of trouble. The best user experience is when your app does what it's fucking supposed to do. All right? So have some reliability. Make sure that your app does what it says it can do. Now, let's talk about API design and API security. I'm not going to go too deep into these. Basically, when it comes to API design, it really just means how you're designing your endpoints, how you're structuring your URLs and different URL formats and everything, right? And API security is kind of related to that. You need to make sure your API is completely secure. Users can't, you know, hack it in some way. Like, super simple example, you need to have rate limits so users can't, for example, try out like 10,000 different email and password combinations on your login endpoints, right? Like some brute force hacking program. You need to have all sorts of different security practices over here, right? I'm not going to go too deep into these things right now, but I am going to link you to two amazing resources from roadmap.sh to learn about API design and API security. And as long as you're doing the things that they mentioned over here, you're gonna be ahead of 99.9% of developers when it comes to API design and API security. So now, let's talk about CI and CD, all right? CI/CD basically stands for continuous integration and continuous deployment, and over here, I'm basically talking about stuff like GitHub Actions or some other CI/CD pipeline that you're using, right? The reason you need to use these things is so you can automatically run linters and checks and different, you know, verification tools for your code base, and also so you can run your tests, your entire test suite, and make sure that your app actually works and you didn't break anything by making some changes, right? That's the continuous integration part. And once you're done with that, you can deploy to whatever environment you want, whether that's a beta environment, that's a staging environment, or it's a production environment, right? You can automatically deploy to all these different environments. And if you have any other tasks that you need to do before deployment or after deployment, right? You can configure some pre-deployment and post-deployment tasks to run automatically, and that works really well as well. And again, the reason you need these things is because, like, you can do all these things manually, right? But you would have to do them again and again manually every single time you make a change to your code base and deploy that, right? So instead of that, why not just have a simple pipeline that does it for you, right? So that's why you need to know these things. Go ahead and learn them as well. Now, let's talk about caching. Now, when it comes to caching, just go ahead and learn Redis, right? Like, Redis is basically the industry standard when it comes to caching, so just go ahead and learn that, and you'll be pretty much golden. Now, the reason why you need caching is because there's going to be some expensive endpoints in your API where you're running some really computationally expensive SQL query or something, or you're doing some other expensive operation that's going to take a lot of time, a lot of computational energy, and you don't want to run that every single time a user requests it because the result may not have changed, right? Let's say I'm running some search function on some government website documents where those documents rarely ever change, right? Let's say they take months to update, right? And let's say, for the purposes of this example, that it just takes a really long time to run that operation, right? That search operation. It takes five seconds, let's just say. If I run this operation every single time I have to search something there, that's going to take forever, right? Five seconds is a lot of time, especially when you add that up to thousands or hundreds of thousands of users, right? That may be viewing that website at the same time as me, right? So that's a lot of unnecessary load on your servers, especially because these results are not really changing anytime soon, right? So in these cases, what you do is you cache the result of the DB query inside of Redis, inside of a cache. And then, for all subsequent requests after that, the server will just open up the memory cache, and it's going to fetch the result from over there, right? And this is extremely fast because it doesn't need to go and run some computations or queries anymore. It literally just fetches the result from the system's RAM and just sends it over to the user as a response, extremely fast. So learn Redis, learn how it works, learn the problems it solves, and anytime you're designing an API with a bunch of expensive endpoints that don't really change often, make sure you use Redis or some other caching solution over there, and you'll be very amazed with the results. Now, let's talk about messaging. So the reason I'm talking about messaging is because you will often, especially if you're building a really complicated, really large app, you're going to have multiple different services that need to communicate with each other, right? And this is going to be more apparent if you're using a microservices architecture. But even without that, you're usually going to have multiple different services that need to communicate with each other, right? And there's basically two ways to make them communicate with each other. One of them is a horrible way, and the other is a really good way. So let's talk about both. If you're a junior developer, if you don't know what message brokers are, you would probably do something like this, right? You would have a bunch of services, like a backend API or a frontend application or something else, or you have multiple different backend servers that handle different parts of the API or whatever, right? You have a bunch of services, and you need to make them communicate with each other and keep each other in sync, right? What you might try is some sort of a direct communication kind of a method, right? Where each server basically sends a request to the other one, and they communicate whatever they want to say, right? You send requests to server two, server two sends a response back. You send a request to server one, server one sends a response back. This is a horrible way for communicating between different services, and it's horrible because it's bottlenecked. Because here's what's actually happening: when server one needs to communicate with server three, it needs to send a request to server three, wait for server three to respond, and then server three needs to send a response back to server one, wait for server one to acknowledge it, and then the request ends. That's just unnecessary work that these two services are doing, right? And the same thing would happen if I tried communicating between server 1 and server 2, right? They need to wait for each other to respond and acknowledge the messages and stuff, and this is a horrible way to communicate between different services. Now, the better approach to make your services communicate with each other is to use a message broker. Now, a message broker is basically a program or some server that is going to listen to events from your various services, and it's going to store them in a queue, like over here, right? You can see we have a bunch of messages over here in this queue. The message broker is going to store them in here, and anytime a service wants to send a message, like let's say service one wants to communicate with service two, right? What it's going to do is it's going to send a message over to the message broker, which is then going to be stored inside the message broker queue, and then it can just go back to work. Like service one doesn't need to do anything else after this. It sends a message to the message broker. It doesn't need to do anything else. It can go right back to work. It doesn't need to wait for some sort of a response from the other server. Then service 2 is going to receive that message from the message broker, and then it can process it and do whatever it needs to do based on that, right? Whereas server 1 can just go back to work without needing to wait for some sort of acknowledgement or whatever, right? So that's a way better way of communicating between different services, right? Now, there's a couple cool message brokers out there. Some really popular ones are RabbitMQ. Redis can also be used as a message queue. I know I said that it's used as a cache, but it's also used as a message queue, and there's a bunch of other ones as well. Basically, go learn about these things, and you're going to figure it out. And just don't try to make your services communicate directly with each other. I know a lot of you junior developers do this. Stop doing that. It's really inefficient. You might not notice the horrible side effects in your toy apps because you don't have any users, but in a real production application, you're going to need a message broker that can handle these things for you. So start learning those things now. Now, finally, let's talk about Docker and Kubernetes. So here's what Docker does. Docker is an application that's going to take your entire app and everything it needs, right? Like the entire application source code and everything, the dependencies, like the node modules and the Python packages that you need to run this application, the OS packages, like some system-level libraries or packages you need to run this application, right? Like, I don't know, FFmpeg or something, or some other utility or some library, like curl or wget. The database that you need, the web server, like Nginx or Apache or Caddy or whatever you're using. It's going to take basically everything that your application needs to run properly, and it's going to package it all up inside of one big container, right? Now, this container is completely isolated from the rest of the system environment, and it's extremely easy to reproduce, as in you can create like hundreds of instances of this Docker container very easily, and you can run this anywhere on any machine that has Docker because you've literally packaged your entire application in a Docker container, right? All the things your application needs to run are in this container. So as long as you can just send this container over to someone, they can run your application very easily. Now, Docker is extremely useful on its own already, but it really shines when you combine it with something like Kubernetes, which is basically a cluster management slash container management tool that helps you manage multiple different Docker containers more efficiently. And this is going to become really important for you to learn as you build larger and larger applications for many different, you know, like thousands and thousands of users, right? So over here, I have an example Kubernetes cluster, right? Which has 12 Docker containers inside it. How does Kubernetes help us over here? Well, it's going to manage the containers for us. If some container goes down or has some trouble or it's malfunctioning, Kubernetes is going to fix it for us, or it's going to restart it for us. It's going to do health checks on every single container and make sure everything is running properly, right? If a container stops running or if a container has some sort of issue, it's going to replace that container, restart it, something, right? It's going to fix it for us. It also helps with progressive deployment. So basically, if you want to deploy a new feature, Kubernetes is going to help you deploy it without any downtime. You don't need to take your entire application down in order to deploy that update because you can literally let some of these containers keep running while you deploy it. So let's say you've got a new update. You can let these three containers deploy the new update while the other nine are still running the current application, right? And then once the new update is live over here, you can put these containers back online, and you can then update the other nine containers over here. So basically, your users will experience zero downtime. Like the site will never go down whilst you're updating everything and deploying your new features. So that's Docker and Kubernetes, and with that, we've covered the 10 topics that I need you to learn if you want to be a good developer, especially in today's day and age. The only thing AI has really automated is syntax. You don't need to write code yourself anymore, but you do need to understand the fundamentals, and that's what this video is going to help you do. All right, go ahead and learn all 10 of these topics, and you're going to be a much better developer than you are right now. And most importantly, do all of this