AI Coding for Professional Software Engineers (Best Practices)

So you've probably already seen all those videos where they promise you you'll be 100 times faster if you code with AI. And so when I started coding with AI, my expectations were something like this. In reality, the more you go down the rabbit hole, it feels something more like this, where it resembles the alchemy in the medieval times, where they say, "Oh, no, do context engineering and then add this and then stick it to this way and then you can transform lead into gold."

And they throw all the terms around like MCP, deterministic, chain of thought to make it look very scientific, but in reality, there's a lot of pseudo science attached to it. And so in this video I'll go over the five best practices that I found coding with AI. Those are for you if you are an experienced developer. So if you just vibe coding or you just code, probably this is not the best video because the stuff will go over, it's more advanced and it's there to use on real code bases at work or if you are coding for interviews as a software developer.

And the number one rule is to keep your context very small. And I know this is exactly the opposite from what people are saying. But the reality is that the more context you add, the less accuracy you'll get from the model, the more prompts you give, the more you ask, the worse the output will be. And by the way, in this video, I will use a lot of examples from Claude Code, but you could apply the same in Quin and open code, and basically both Windsurf and cursor will work the same way.

So pretty much everything I'll show here, it's valid for any AI coding tool. Now, the number one way you can keep context small, it's really by running in it in your code base and have it summarize your repository. And so in that run, basically Claude will write a read me for you. I found this feature very cool because you'll see that Claude actually keeps this up to date. And one of the hardest thing in development teams was always to keep the read me up to date.

Usually nobody updates it and then when you onboard someone new, they they're trying to find their way around it and it's just impossible. So I really love that they do this on autopilot. I think Claude MD is very useful for us humans. not so much for the LLM because the LLM can actually take in the whole project, but for us, it's super easy to see exactly more or less like a high-level map. the actual repository. This is how it looks like and it's one of the first files I would generate or look at if I would be onboarding myself on a large code base. So if you just started a new position or you join a new company, I would really try to get a hands on exactly this file because it will basically tell me 95% of everything I need to know about the code base. The second thing is you want to really clear your context window between sessions. So I know people feel like, oh, the more context I add, the better will be the response because the model will just know everything, but in reality, the model is programmed to pay attention to very specific things. So the more things we add, the more biased it ends up being. So I do founded that I get a lot better results and more deterministic results. When I clear the context window, or at least use compact. It will also save up tokens, you'll get faster responses. But in general, keep your context window small. Now, a few more things you can do to keep your context window small, it's basically to use continuous integration. So do make sure you follow GitHub or feature flow where you have feature branches to make sure you use Git rebase. Don't use Git merge. It will be very chaotic if you're coding with AI in a team and everybody's just pushing changes to the main branch, the history will look like hell. And make sure you use Git squash to combine all those commits into a single one. It's just a lot better to keep things simple and deterministic and be able to roll back changes very fast. Also, make sure you folks implement continuous deployment. Release things as soon as they are ready. Now, of course, if you want to keep quality high and do that, you will need to add a lot of tests. Auditing for a test coverage over 65%. We've seen a second how you get there. And optionally, do push your product team for analytics. If you're building software, you really want to know if people use a feature, how much they use it, because you're just making hypothesis. We live in a world where it's easier and easier to create a compelling case for a feature.

might feel pressured by product to build this, build that, and you really want to bring this empirical mindset to it. So, be sure that you put product analytics on any feature you build. So then you as a team can make better choices and you can actually push back on certain things that you feel like shouldn't be implemented. Because everybody's doing an AI and there's all this fomo around, we need to do it.

And also keep minimal documentation. And I know this sounds counterintuitive. But code should be self-documented and self-explanatory. If we're adding all this AI generated comments in every function, it just makes it very hard and very tedious to go through the code. And again, more context means actually worse results. So you want to keep things small, functions should have names that really tell you what they do, and if you use TypeScript, most of things should be self-explanatory.

The other reality is that a lot of people that are giving you AI coding advice, they haven't coded too much before AI. So, they're not so proficient in traditional software building and that's why they're basically telling you to do everything with AI. Let's just throw it to the model, generate some text. That's basically the solution. To every problem. And there's also a lot of bad advice that's very popular that they're giving you.

And the number one bad advice is that you should create a plan or tasks or PIPs. I mean, if you want some clarity on how to go through the feature and you want to brainstorm that with a model, that's great. But when it comes to the code, really keep the repo just about the code. You have J, you have linear, they have MCPs. You can connect them directly to your models so it can communicate with the tickets you're working on.

And you don't really need to repeat all that product work or product specs in the code repo. The code is about the code. Most of those chain of talks thing are generated by the model to give us an insight on how it's supposedly thinking, but it doesn't really reflect what the model did. Sometimes the internals of the neurons are totally different to the plan that it's presenting to us. The next bad advice is that you should write documentation.

I will explain that one. It makes the repo to verbose. Code should be self-explanatory, and you can use your tests as documentation. So, when you write your unit tests, and I read that file, I should already know what the function it's supposed to. You don't need to repeat that and have all this redundant text that just makes it harder to read code. And the next best advice is just to write unit test because that's how people think that they maintain quality of other code base.

In reality, AI is very good at generating unit test for everything. Like, you can write the dumbest function ever, AI will give you like a great looking test on it. And so what you want to do is to actually combine writing unit test with a lot of enter and tests where you look at the specs, you write some behavioral tests or enter and tests, and then finally you write some unit tests. And so these three things I've seen referenced a lot in many vibe coding or AI coding videos, and I think they will actually create very bloated code bases. So make sure you stay away from those. Because again, you put garbage in, you get garbage out.

And by the way, if you don't know me, I'm Bogdan. I started a senior dev 5 years ago with my brother Darosh and together we help JavaScript developers, so software engineers, but particularly JavaScript engineers, go to the senior level and beyond. Check out the links in the description for our free training, technical assessment, and all the free resources we also offer. The number two rule is to keep your context fresh. You can do this by leveraging what they call rag. This is a very popular term you'll see thrown around a lot. Basically, this is a way to compensate for the fact that sometimes we train a model and then maybe the documentation of whatever we're using change in the meantime. And so, we don't want to really retrain a whole model to include that. So what we do is to extract the relevant parts from the documentation and inject them in our prompt.

So basically, if I'm using an LLM that was trained with, let's say, React 16, and nowadays we're using React 19. chunks, and then we finally send that to the LLM. So this is how you basically augment your generation process by doing semantic retrieval from a context store. Now, you don't need to set this all those things manually or go learn Python and do it in Jupiter notebook. There's many tools that can do this for you, and my favorite one is context 7. You can add this as an MCP to cloud code, and then you just select what documentation you're actually using. And then whenever you are making a prompt, it'll take the latest documentation into account. So, you really get like the latest latest version of React or Nextjs or ChatCN or whatever in your queries. It's quite amazing, it's very easy to set up together a website, and it's one of the best tools that I've been using so far. Moving on to number three, what I call the full responsible the principle. Everyone has full responsibility over the code they commit or they write. It doesn't matter you generated with AI, if you commit that to the code base, it's on you. If you wrote it, you run it, you are responsible. It's end-to-end. We cannot just generate some code, throw it out there and have our colleagues taking the heavy load of doing the pull requests review and going to all that generated cabbage with AI. A lot of people here on YouTube talk about generating solo projects and they talk about, oh, how I started my project, but a lot of developer work is very collaborative. And we need new standards now that we have these tools that can generate code very fast. AI doesn't write code, humans write code. So, you want to review your code down to the character, down to every line. Everything you commit, you are responsible, you are liable for. And I really have to stress this because we're working with people and sometimes they had situations where they would use a vibe coding tool, they would submit the code in a take home task and then the developers will tell them, okay, let's give you the code. They would go line by line and they will stumble because they really haven't reviewed the code before sending it. You want to make a habit of reading everything before you commit.

move on. It's a very bad habit. You want to run the test suite manually and check all the coverage reports, and you also want to read the test. Actually, tests are becoming now super important because if you have great tests and you are really good at testing and debugging, you can more or less have the model inferring the rest of the code, kind of writing the rest of the code. And I do suggest using Git blame to incentivize responsibility at the individual level.

I know it might feel a bit uncomfortable in the very beginning, but we need to bring back responsibility now that AI can code so fast, we want to make sure that that doesn't disincentivize people to just turn out code and decrease the quality of the code base. Number four, and you probably heard this one before, program to interfaces. This is more important than ever. Remember that structure scales, inference does not.

Software scales because it's very structural. That's why, for example, TypeScript code bases, they scale a lot better than JavaScript code bases because they have more structure, they have less possibilities. Now, LLMs are the exact opposite, where you get a lot of possibilities. That's why the use cases for LLMs in real consumer applications haven't went beyond the typical child applications so far, because it's extremely hard to get predictable outputs from them.

Deterministic systems will always be written in a programming language because programming languages, they are basically English without ambiguity. So when we program, we say if else. That's it. It cannot have a thousand possibilities. It's either an if or an else. And that's the valuable thing, is that contract where we set in stone, we say these are the only two things that we want, you will happen.

That's what creates predictability. You got to think of those static interfaces as the molds where the LLM will actually write the code. And as developers, we will do a lot of kind of building those molds, because once you have the mold set up, then you're just kind of pouring the concrete and then you'll get the shape you want. As an example, you know, you want to use relational databases or at least have a schema whenever you use a data store.

Don't just freestyle your way into data storage. Use coding typing. So, TypeScript is not optional, it's a must and you want to be as strict as possible. The the more strict you are, the more controlled the damage would be. The the smaller the blast radius, let's call it that way, of an AI mistake. And so, we want to restrain the AI. And then use Ainter and Prettier with global setups. All those code quality measures that used to be more or less optional sometimes, now they are mandatory and you want to be as strict as possible.

Finally, remember you can plug those things into your cloud code. So, they basically add hooks where you tell cloud code, hey, whenever you start a session, you can do certain commands, when you end the session, you can do certain commands. But also, you can actually tell it to do certain things when a sub agent finish a task or a tool was called. So, you have all this freedom to plug in and say, you know what, when a coding session ends, I want you to re run the Lter, to re run Prettier, and run all the tests.

That can be one of the setups you go for. And that would allow you to have this automatic code quality where we know that whatever the AI will write, still gets all our aesthetic checks. And by the way, if you want to get better at writing quality code, get faster with AI and really figure out where you are, you know, technically, take a free technical assessment, you'll find a link in the comments and it will basically tell you where your skills are compared to the market and what's needed for you to go to the next level.

You'll see a lot of things about continuous integration and testing that I mentioned in this video in the assessment itself too. And finally, the fact that we use AI to write the code will also change the software architecture. And this is a topic I feel people don't talk enough about, but there's two differences when it comes to monoliths and microservices. So, traditionally, we used to have monoliths, which are very big code bases where everything is.

But then we moved towards microservices that are individual and separated. Now, when it comes to using AI for coding, with monoliths, you usually get a more coherent answer because the LLM has all the context. But when it comes to microservices, you'll get better curious See, because again, the context is smaller, so it's just easier for the LLM to really get it right. In general, when you go from monolith to a microservice will also now depend on the quality you want on your coding tools.

So you want to add this to your requirements. Basically, when you have a very big code base, the productivity you get from AI will decrease a lot. And moving towards microservices or at least extracting part of that code will make it easier to extend or go faster with AI. So keep this in mind too. And if you want the best of both worlds, you can actually put your microservices in a mono repo. So you can decide, am I going to extend service A just by itself as a single unit, or am I going to load all this up into a mono repo?

Load it up in my cursor and then make decisions or make AI coding changes based on the overall context of the application where I have all the services. What I found out is that the more services you add, the worst results you get. And even if the AI feels like it's aware of everything, so it will go in and be like, oh, I see you're using JVT based authentication in the front end and let me check the back end.

The final results will be very poor quality. So the story to tell you about the prompt is doing would be amazing. But then I found the result to be disastrous. And so I prefer smaller scoped changes. And as a bonus, finally, test. We talked about unit testing before. Most model companies like open AI andropic are claiming that software will be this projection of the specs where you just write a markdown file with what you want.

The LLM will go and compile that to software. I believe the reality would be a bit different in the sense of we will actually write specifications in our product backlog. Based on that, we will extract tests, usually BDD, behavioral driven test, and then end to end test. And then with the end test written, then we can reliably use the LLM agent. spec driven development, because they fill the need to really push new things out there, but we already had behavior driven tests, which is just an amazing tool to really make sure not only that you write the specifications and you have the LMX executing on that, but you can actually verify it.

And you do all that in a single shot by writing just the tests. And if you're not out, I do recommend the play right MCP, you can connect that to cloud code and you can combine that with your play right BDD framework and you can basically write specifications from your driver tickets, write into your behavior development and then go through the TDD cycle. And so basically you can implement behavior given development and have the model first writing the test.

You can basically set up engine test with play right and then follow the red green refactor cycle. And so basically you would have the model update the test, then again clear and then again go and make the test pass in a first pass. And then I would clear in between and finally go in and have the model maybe refactoring and doing all these non-functional checks, like the linter, maybe accessibility, maybe web performance.

But that's a very good workflow if you can afford it. Again, you need a bit of setup and it's a different change of habit. But I find that with AI, we can finally build even better software or get even better because we don't spend that much time writing that specific function or class. You just have to review it. But then you can spend more time writing the test, committing, fixing the CD pipeline, working on the requirements.

Making sure we're building the right thing. So overall, I'm quite excited about AI. But I do feel like we're still in this hype phase where a lot of people will just throw things at you and tell you you're going to be you're going to be 100 times faster because it generates code. I feel like we need to scratch under the surface and as we go deeper in the best case scenario, AI makes software dev a lot more fun because we can do things that it was very hard to do before.

because there's just not enough time. But I feel like now we might be moving in a direction where we can actually do that. Now if you are a JavaScript developer, check the links in the description will help you becomingble, develop senior level thinking and mental models and type inspired AI on layoffs. As for me, I'll see you in the next one.