It is, but software engineers have a much broader understanding of the problem, they also ask questions, and if they are good, they ask the right questions, something LLMs still have a problem with.
Personal example of what LLMs can't do, but I could: I made a script to update some version numbers in some files, based on some other files. Simple stuff, and one of my colleagues told me "ask the AI, it will take 5 minutes". Well, no, because the files sit on different machines, and extracting the files from one machine and putting the result on the other machine requires knowledge of the infrastructure. Again, simple stuff, but the AI doesn't know, and we certainly are not going to let it run wild in our network. I know all this because I talked to the team, attended meetings, and did a bit of careful exploration. I am trusted with resources to do my work in a way the AI doesn't, I am sure it is mostly because I can take the blame me if I misuse them.
I recently vibe coded an application fully and tested it with users. So all the functional requirements were there.
Guess what wasn’t?
The nonfunctional requirements.
Also: my app needs to do LLM classification. But instead sometimes the coding assistant wrote not an LLM api call but it wrote a regex to classify instead. This was despite the fact that I mentioned to not use regexes to classify things with.
Non-technical people don’t know what a regex is. Usually they also aren’t knowledgeable enough about nonfunctional requirements.
All of this may improve over time of course. But right now, I am not impressed (in terms of replacing SWEs).
>Guess what wasn’t? The nonfunctional requirements.
OK, so you test it, see which nonfunctional requirements it doesn't meet, and ask the AI to change the code to include them - repeat until you're happy.
Yep and then you'll have some war stories how things break in production because they weren't initially included in the nonfunctional requirements. Have enough of these war stories and you'll basically be a software engineer. Albeit, a software engineer that has never coded before, but definitely someone who understands production issues.
It is, but software engineers have a much broader understanding of the problem, they also ask questions, and if they are good, they ask the right questions, something LLMs still have a problem with.
Personal example of what LLMs can't do, but I could: I made a script to update some version numbers in some files, based on some other files. Simple stuff, and one of my colleagues told me "ask the AI, it will take 5 minutes". Well, no, because the files sit on different machines, and extracting the files from one machine and putting the result on the other machine requires knowledge of the infrastructure. Again, simple stuff, but the AI doesn't know, and we certainly are not going to let it run wild in our network. I know all this because I talked to the team, attended meetings, and did a bit of careful exploration. I am trusted with resources to do my work in a way the AI doesn't, I am sure it is mostly because I can take the blame me if I misuse them.
I recently vibe coded an application fully and tested it with users. So all the functional requirements were there.
Guess what wasn’t?
The nonfunctional requirements.
Also: my app needs to do LLM classification. But instead sometimes the coding assistant wrote not an LLM api call but it wrote a regex to classify instead. This was despite the fact that I mentioned to not use regexes to classify things with.
Non-technical people don’t know what a regex is. Usually they also aren’t knowledgeable enough about nonfunctional requirements.
All of this may improve over time of course. But right now, I am not impressed (in terms of replacing SWEs).
Why didnt you vibecode the The nonfunctional requirements?
Not needed yet, we needed to capture the UX first to see if we could create what we'd want to create.
>Guess what wasn’t? The nonfunctional requirements.
OK, so you test it, see which nonfunctional requirements it doesn't meet, and ask the AI to change the code to include them - repeat until you're happy.
Yep and then you'll have some war stories how things break in production because they weren't initially included in the nonfunctional requirements. Have enough of these war stories and you'll basically be a software engineer. Albeit, a software engineer that has never coded before, but definitely someone who understands production issues.