Vibe Coding Is Not Engineering(phroneses.com) |
Vibe Coding Is Not Engineering(phroneses.com) |
By this definition, anyone hired to be a code contributor, and not operating at the architecture level, isn't an engineer.
On the other side of that definition, engineering doesn't even require code, but would be architecture with deep technical understanding that allows you to create the tasks that you hand off to individual coders.
- A person writing code vs a bot writing code
- A person designing systems vs a bot designing systems
You say that as if it’s not true, but it is. And even then, still not always.
Engineer is a regulated term in Canada. If you’re not licensed, you’re not an engineer. If you say you are and acting as one in a professional capacity you are comitting fraud.
The amount of delulu Americans larping as engineers is always good for a laugh.
You do ask hard questions up front, define boundaries, give lots of high level architectural guidance, declare interfaces, and bounds of abstraction... And then you ask the LLM to make it so, and it does. You give it the structure, and it fills in the implementation.
This is engineering, more or less.
I would love to see how perfect their “organic” code looks because I wont be surprised if its full of all sorts of issues, all in prod, for years, never known or spotted, just to be found and fixed by Claude in 15 minutes, with unit testing to test and ensure no regression is introduced.
There is no "correct" way to toss a coin. Some day people who are depending on LLMs blindly will understand that. All their notions of "correct use" is based on folk lore and...vibes, that is just maximizing token use under some misguided notion of "correctness"..
The more context an LLM gets, the more likely it will start to ignore instructions.
If the LLM runs a context compression, all bets are off. There's a reason Anthropic upped the context to 1M tokens to reduce the chance of this from happening.
The human. But only if you care about verification.
I mean, it's the same with building a bridge in the real world, right?
Someone has to check the work.
I use Cursor and Codex but the agents keep making regressions and breaking rules. They'll even take shortcuts sometimes, by doing things to make tests pass but with code that would be dangerous in prod.
Now, I use them file by file but it feels more like a typing assistant than something much more.
We have as much test code as deployable code because the AI keeps finding ways to do what we told it to, but not what we meant.
People who build bridges for a living shake their heads in dismay.
Software on the other hand...
You see, the difference is that with building bridges, there is no value in building a "Toy" bridge that does not require any real knowledge. But even toy software can bring huge value. But that does not mean it does not require engineering discipline to build non-toy software.
Software engineering is not about learning libraries or tools. It is the art and science of managing complexity under constant change.
myFramework new myCoolStartup
myFramework generate dataModel
myFramework generate controllerForModel
myPackageManager install coolViewWidgets
# insert glue code I learned on Youtube here
git push coolPaaS myBranchwrite python to "Add user accounts to a website so people can log in."
The model generated a small, working Flask and SQLite example. That is acceptable for a demo but it did not ask about these five requirements:
Should emails be unique Should accounts be verified Should users reset passwords Should roles exist What is the security model? ”
Write a better prompt? I don’t think any software engineer would ever send that?
The days of Devs gatekeeping and shitting on good ideas because the syntax of a PR was not perfect are over.
"vibe coding" by definition means you are not looking or understanding the generated code and you are accepting all changes and "fixes" by the AI.
In software engineering, you must understand what the code is doing and you will struggle to resolve sudden issues if you do not understand these systems which risk outages, loss of money, and data.
You do not want to be "vibe coding" software that is to be operating on planes. That would be disastrous.
> The days of Devs gatekeeping and shitting on good ideas because the syntax of a PR was not perfect are over.
Developers who do that without using a formatter are the bad ones anyway and are there to argue and waste your time.
Most software engineers are hilariously inept at systems engineering,
I agree with this. Sadly, we're good at pushing working demos as the final product in corporate.
Who even puts forward such claims?
who cares?
That's why they have to make what we produce with the LLM something lesser than what they can do by themselves.
> A model can generate a login system in seconds. It will not ask if emails must be unique. That single missing requirement can collapse the system. LLMs cannot see the category of questions that keep software safe.
really? I am assuming here that the author means that the emails used when registering across users need to be unique. even mediocre models will do that for you.
even more to the point though, if you tell an LLM, hey I want to build this system, let's talk about the architecture, it will ask you all the relevant questions. this can really help with the engineering. sure, there's a rubber ducking aspect to it, but even so. telling an LLM to immediately implement an idea does not lead to great engineering. starting to code yourself has the same problem. doing some brainstorming with an LLM (like in the olden days with humans) is where they help with the engineering part.
Software development is more like being a construction worker that uses engineered materials. The engineers, on the other hand, develop the structural components (steel beams, the actual dry wall), an architect designs the whole system, and a contractor manages it.
With vibe coding, you make yourself the contractor and turn agent into the other roles. You can choose to build a building without an architect (you or the agent) and without using engineered components (a proper database for example), which will likely lead to leaks or a full on collapse.
Frankly, this is no different to the franksystems build in midieval times.
Ive used it to write that terrible one-off powershell or bash script. You know the types: grunt work, boring, and you just need it done.
I can ask my local LLM to make it. Its done as fast as it takes to load up a console and vim. I spend a minute or 2 reviewing, and run in stage.
The tough stuff or API specific proprietary stuff; i still write and maintain. But the drudge work is getting automated.
It uses like 45GB system ram and 11GB g-ram.
You can't call it "engineering" if you don't care about verification.
They're the ones checking that work matches the plan.
https://www.buildordie.com/ (Build or Die is the web site for a mid-sized architecture firm.)
You seem to be implying that since the current wave of AI started that things have gotten better. That is demonstrably, repeatedly, and completely false. Just cruise the HN front page and watch the AI fails scroll by.
That you point to Windows getting bad over the years, and the fact that it continues to get worse with the full AI buy-in of Microsoft, shows that AI is not some magical software savior.
Unfortunately, many "computer science" curricula weren't much better, and so now we have hordes of unemployed people with a skillset about as relevant as being able to hand-assemble ZRA1 code.
(I'm a very biased self-taught developer from the late 1990s who just happened to hit the industry at the perfect time)
The whole reason we have engineers is because we used to let anyone call themselves that and lo and behold a bunch of bridges collapsed under load and killed people. Who could’ve thought?!
Almost 2/3rds of the professionals in my family are licensed engineers and we take it extremely seriously.
Canada has only been actually licensing software engineers for a short time compared to other disciplines - but the industry as a whole is due for a reckoning.