I’m Changing The Way I Code Because Of AI

A few days ago, I was chatting with Borden here, and I was wondering how did AI actually change the way he codes, the way I code, the way we all code. And by digging deep into it, we realized the answer is quite opposite to what most people think. If you look around here on YouTube, you'll see people talking about MCP and throwing buzzwords around. And actually for us, AI fundamentally changed software engineering, and it did so in five main ways.

And the first way AI is changing the way we code, it's that now we think in first principles and mental models a lot more. That is mainly because text, it's not the most efficient data representation. Symbols are. Like that's why people say an image, it's worth 1,000 words. And mental abstractions are way faster than an LLM. A good example of that, it's sequence diagrams versus raw API code. Exactly, the fact that an LLM tool can churn out a lot of code, it's actually more of a drawback because now for you to understand and expand that code base, you need to read a lot more code, you need to evaluate more code yourself than you used to have to.

So it's more important than ever to be able to boil these things down to fundamentals. And one of them is using UML diagrams, in the back end you can use sequence diagrams, in the front end you can use state diagrams. Because at the very end, it was those ideas that really scaled software development. It was those ideas where we say things like, oh, the UI will be a function of state. So that's a way for us to represent something very complex that has a lot of different details into something that has basically very small details, right?

State, it's basically boiling down so many state changes into simple variables. And so we need that ability more than ever, because you have to work on code bases where code changes happen much faster. There's a lot of rework that usually needs to be done on code generated by AI. And the only way to do that is if you represent your source of truth into something symbolic. And the best examples from traditional software engineering are UML diagrams and state diagrams.

we have symbols. Yes, mathematics actually started as a form of philosophy in Greece and it didn't took off until they agreed on a common shared language in terms of symbols where things went from being abstract words or syntax into being symbols. It's very deterministic operation. You'll always get the same result. And that's when you can actually scale and build a knowledge on top of that. The second way AI changed the way we code is it made us use clean architecture a lot more with land with discipline. First, because stable abstractions mitigate unstable AI output. Second, because my job and your job as a software engineer went from writing code to actually modeling the space where AI it's working. People also call it, you know, building contracts between interfaces or modules. All of a sudden, we have this tool that can churn out a lot of code, and so it's not difficult anymore to write code. The problem is, most of the times those agentic tools, they create very different outputs. And so the only way for us to have cohesion and predictability in a code base is by paying special attention to, as you mentioned, contracts, interfaces. And once you start talking about contracts and interfaces, you go into the realm of abstractions and what clean architecture calls stable abstractions, where you basically pay a lot more attention to the logical entities in your code base, let's say, you have any commerce stored that would be the user, products, and you model those, and then everything else it's a projection that kind of can change, but it will not affect considerably your code base. And you need to do this in order to protect the value in the code. Because if you just leave those agentic tools, I already call it those language models to their own devices, they are by nature divergent. So they will come up with very different solutions to the same problem, and you'll end up having sort of a very much of a spaghetti code base. The third point, it's AI made us think a lot more on paper. Because once AI gets in, it will kind of pollute your thinking and my thinking process.

So you realize it's almost impossible to think deeply when you can generate things so fast. But what happens later on is that if AI builds it and you you kind of delegate your thinking process to the AI, then you have to think about it later twice when it breaks, right? So you have to think about it when you start building it and then later again, you need to actually read whatever the AI has been doing and understand what's breaking.

And the way to cure that is to before you're talking to the AI, before getting any kind of LLM involved, think a lot more on paper and be a lot more intentional about what you're going to build. When I used to lead engineering teams, we had a saying between engineering managers which was that you want to make delivering features somehow expensive on purpose. So product has to think very hard about what is the next value add to the product.

And so sometimes, when you add new code or new features, you're actually making the software worse. That's what we call the cost of regression when we add new bugs, but it's also the cost of regression when you add a useless feature. And there's this natural tendency now with this vibe coding tool to just add things, to just copycat, you know, uh the next tailwind feature into our code. And everybody's building clones and copies of a copy of a copy.

But in reality, a lot of those problems that they are solving are not the real problems, but it's so cheap to generate code that people just bypass the thinking. Because thinking is hard. You need to sit down, think, okay, what's the actual problem? Let's let's model this. What's the data structure we need? Do we really need this feature? Can we reuse something we already have? And you cannot answer those questions if you don't know the code base, if you don't feel at home in the code base because most of it was generated with AI.

By the way, folks, if you don't know us, my name is D and together with my fellow developer and brother Bogdan, we built the senior dev. where in the last five years, we helped over 360 JavaScript engineers level up to senior and beyond. skills, static checking skills, keep in mind, TypeScript for JavaScript developers became a hell a lot more important. Because when you add AI to a code base, suddenly you have a lot more code, but you don't have better code. Which is why refactoring and code management skills are becoming top engineering skills that a software engineer can have. The second point is the deterministic tools scale much faster than AI. Exactly, so with a type checker, you can basically check the type safety of a code base that has millions of lines of code. And a language model would have to ingest that, tokenize it, evaluate it, and then maybe give you the next line, but it wouldn't be able to give you a holistic diagnosis of, hey, you have all these type errors. So what we've seen is a lot of those vibe coding tools are now combining, making on TypeScript, making it run the linter. And so in that way, they kind of mitigate that. What usually happens is that agents uh usually end up just editing whatever codes to make the uh the static checking tools pass. But with all this AI generated code, all of a sudden as a developer, you have more work to do, like you already had a lot to do and now there's all these pull requests that are coming in, that people maybe give you their cells, maybe not, and you need to find a way to really go through all this code in a very efficient manner. And that's why knowing how to use the debugger, which unfortunately a lot of JavaScript developers, especially, tend to work a lot with, knowing how to use profiling tools, and knowing how to use diagnosis tools, and then coupling that with static analysis, TypeScript it's one of them, but there's many static analysis tools out there. The Linter and Prettier another one, that will make sure that you don't literally drown in all this low quality code generated by AI tools. Funny enough, in the talks I have with software engineers worldwide, uh these are the skills many of them lack the most. Maybe because there are not so many resources, maybe because in the past you could just swing it, you could and a lot of them are seeing that hey, you know, when they go and do a technical interview, they are lacking. these exact skills for them to be considered senior. The last point is that AI made us get even deeper into traditional software engineering. That's because

the first context engineering there was, was actually software engineering itself. Design patterns, compilers, interfaces were all boundary conditions added by the developer, or the engineer, in order to limit the context of the problem, to make it more digestible, to be able to model it in the proper way. Which is why, while everybody is looking at MCP, we are getting back to traditional software engineering.

Because these techniques were built in an age where there was no AI. So people were forced to very much think very high about these problems and their solutions. And that's how, you know, software engineering was actually born. It was born out of the need to model information systems without having the easiness of just asking GPT how to do it. Exactly. And this applies also to software design, it applies pretty much to every aspect.

And so what we are seeing even years after the AI revolution, is that the actual features, the actual software, didn't improve that much. And the reason for that is because people are not thinking about how to improve the software anymore. They're just delegating that to the AI. Basically, every single decision would be, oh, let me ask GPT how to do this, or let me just have cloud doing it. And the problem there is that the limitation in a way was the gift when you limit options, you get a lot more creative.

Uh, a very good example is Blackberry versus Apple, where the BlackBerry phones had so many features and an Apple came in and said, well, we will just have one button. So sometimes you add value to a product by subtracting things, and it's the same with code. A lot of those AI vibe coding and AI coding seems a lot like the JavaScript ecosystem in 2020, where it was all about the next framework, you know, view then Svelt, then Solid, and all those frameworks came along and they were totally irrelevant in the long term because React ended up being 80% of the market for the whole year.

So there's a lot of noise, there's a lot of push towards all these fancy terms like MCP, chain of thought, context engineering. But in reality, most of those things are nothing new, like you mentioned, software architecture was context engineering. when when you fade in a microservice, then in a big one. And so great software engineers are even better with AI. The amount of benefits you get from the AI will be proportional to your software engineering skills. And this is number one advice in this video I'll give to people that are a lot of developers come to us and they're like, hey, how can I take advantage of AI?

What should I learn? Is there, you know, uh, is this this MCP thing? you know, do I need to to learn how to use it better? There's this this FOMO feeling that somehow becoming a better engineer these days, it's not about, you know, getting better at at software engineering itself, but actually being better at working with AI. And there's some truth in that, but definitely the advice we give those people is you have to look inside. You have to get back to the basics, back to traditional software engineering itself. This will make you a better AI engineer or a better software engineer working with AI.

And finally, by the way, folks, if you are a JavaScript engineer and you are interviewing or you simply want to get better and you don't know where to start, well, the best way to start is by knowing what you lack. This is why Bogdan and I built this free 10 minutes, 10 skill assessment for JavaScript engineers. You have to answer a bunch of questions and you will get back a full report on your current tinker level, how you compare to other developers. And finally, what's the best way for you to fix those gaps to be competitive in the market.