We have all heard the scientific thought experiment of Schrodinger’s cat, where a notional cat is put into a box with a vial of poison. It either may or may not break open. Without looking into the box, the cat is either alive or dead, and you don’t know which way it is until you actually open the box.
This analogy, I think, works fairly well when we talk about AI and coding. We talk about AI replacing engineering, we talk about AI not replacing engineering, and really I think the only way we’re going to know for sure is by opening the box, by looking inside, looking at specific use cases and deciding which one is true.
I see in the media two very different opinions on AI and code writing. You have one camp which says that there’s no more need for software engineers because AI can already or will soon be able to do everything, and we just don’t need those people anymore. On the other extreme, you see the opinion that AI is no good, it doesn’t work, it’s just a toy. But I think the way to look at it is that it really depends on what you’re trying to do, and I think the intent is really the key here. So when we look at using AI for coding, I break it down into a couple of different ways :
- Vibe coding, where you just create a prompt (either with a lot of detail or a little detail) and say “go build me this piece of software”, and the AI goes off and does it. It comes back with something, you may need to tweak it with additional vibe coding, but you get something that works.
- Using AI as an assistant to a skilled engineer. The engineer is responsible for knowing what they want the code to say at a high, medium, and somewhat low level, and they use AI to help accelerate some of that work. Writing function calls or writing small pieces of functionality that they can then look at and either tweak or accept on their own.
These approaches lend themselves into two different use cases. Let’s look at vibe coding. It’s great for building prototypes, I’ve done this myself. You just want to build something to see what it looks like, try it out, make sure the basics of it work, and then maybe iterate from there. This is great for people like product managers or even non-engineers who want to build something to show other people what they’re looking to do or what they want. It is drastically better than a mockup in figma or powerpoint because it actually works.
The code that gets created (and a lot of studies have confirmed this) is what some people call spaghetti code. It has:
- Variable quality
- Increased instances of security vulnerabilities
- Underlying logic can be rewritten without warning
Because of these issues, in my opinion, it’s not something you would ever really want to put into a production system that people would rely on.
Now when we look at the other side of it, where you’re an engineer using AI to assist your coding, this is where AI is interesting because in some studies they’ve shown that engineers think they’re about 20% faster using AI, but the studies and the part of these studies have shown that in reality, they’re actually a little bit slower, but it does help to automate the actual typing of code and the simpler parts of coding.
When you have an engineer setting the architecture, setting the high-level plan (what talks to what, what functions are needed, etc.), then you get a much more explainable, stable codebase. Some of the lower-level pieces may have been written by AI (AI may have been also been used to debug, write tests etc.) but the structure and architecture has been designed by a human.
Another key issue when dealing with AI-generated code is maintainability. Writing the first version is fine, but when you have to change things, that’s where things can get more complicated. In the instance of Vibe coding, each time you prompt to change the code, the code that gets generated may be in a very different style from the previous version. The code could be inconsistent, and the architecture may not scale or be maintainable over the longer term. If someone has to go in and manually look at that code and fix it, then it becomes much more difficult because it looks like a whole bunch of junior engineers all writing code with their own styles.
Another aspect is scalability and performance. If this is an app for large numbers of people or with a high load, performance and scalability will be key. This is not something that AI generated code generally does well.
At the end of the day, when you look at the two different approaches, there really hasn’t been any large-scale, peer-reviewed studies that compare the two for the same project over a period of years.
When we ask: “Will AI kill coding?”, I think the answer to that is no. Will it change it? Yes. But the key thing to keep in mind when writing code is intent. What is your intent for that app? Are you looking at something quick and dirty as a prototype, or are you looking at a mission critical application that provides high scalability and throughput for thousands, if not millions of users?
At the end of the day, Vibe coding is great for quick prototypes and planning. But if you want something that’s going to scale, something that’s going to be maintainable, something that’s going to last, then a human engineer guided and assisted by AI is going to be your better choice.