> Software Engineering is often not truly Engineering.
"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.
There are many who built careers around being essentially software assembly liners. Glue together framework/library bits, following well-trod paths. Get really good at Googling and grabbing code from Stack Overflow when you have to go off the path or solve problems.
You just described essentially what those coding "boot camps" taught people to do. Something you can learn in 12 weeks always seemed to me to be a job at high risk of automation.
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.
Both boot camps and academia do a poor job of preparing developers for a real career, they just started at opposite ends of the problem and never provide enough depth to get to the good part in the middle.
(I'm a very biased self-taught developer from the late 1990s who just happened to hit the industry at the perfect time)
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.
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.
When something is wrong everyone complains, when nothing is wrong you rarely hear a peep. I've either shipped to production or helped others ship "AI Slop" code as would be blindly described by others, despite me reviewing it and testing it. I've first hand seen AI-first greenfield projects go into production and help small businesses achieve more sales and success, heck I reviewed such code for a relative who is now hiring developers and lets them AI code so long as they review, because it gave him something no software company in his market would offer.
Clearly you have never worked in heavy industry, or you would know that the word "build" is used at all levels, all the way up to architect and real estate development level. Example:
At least bridges come in the realm of unchanging physics and unchanging material behavior. There is only so much variety in building bridges.
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.
The rest of us who do similar work with the model to build richly define spec files. Spec driven development is a lost art with non-AI coding anyway. People who complain about these things either do not work with people using AI correctly and dont realize they just need to push for better standards or they are terrible at architecting. I notice everyone who hates AI just finds any excuse to dismiss it instead of actually pushing towards more effective ways of using it.
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"..
- Depending on the nature of your application, it may be very important to be able to audit the business logic and intended behavior. For compliance reasons, for operational reasons, for moral/ethical reasons -- you very well might want to affirm what the code is actually trying to do.
- A coding agent may get very creative in order to write code that passes a tightly-defined unit test. It may come up with approaches that technically pass, but work against the overall intention of the app in the first place. This becomes an arms race rather than a productive collaboration, where the agent's increasing creativity has to be matched by a sprawling test suite.
- Eventually, inevitably, business requirements will change, and the blob will need to evolve. It will be much easier for an agent or a human alike to understand how to safely make the change, if the existing implementation is transparent and understandable.
1. Your unit tests are exacting enough to fully specify the unit. In that case, congratulations, your unit tests are the code. They're also probably much more awkward to write, maintain, etc. Also, the compilation step to go from the unit tests to the actual code is now orders of magnitude more expensive, requires a SaaS to even work, etc.
2. Your unit tests are not that exacting and still leave ambiguity, edge cases, etc. In that case it very much matters what's in the blob of code, because while it could be a correct implementation of what you wanted, it could also be something else entirely that just happens to be correct for the part you did specify.
LLMs are not deterministic. They do typically behave within pretty reasonable boundaries. Humans are not deterministic. They also typically behave within pretty reasonable boundaries. Engineering with LLMs and humans means understanding those boundaries and designing for them. This is a legitimate engineering problem like any other. I think the main misalignment I see is the expected productivity gain. When you are using real engineering discipline it is still very productive to use AI for coding, but not nearly so productive as many people claim when you factor the fragility of their system.
There is no correct use. There is no “correct” way to build systems. There is principled and disciplined use.
There is a pretty big difference. If you ask a human "Is X true", and they says "yes", you can be 100% sure that they will always behave in a way that is logically consistent with X being true (talking about a competent and honest human being here, and when the implication is obvious). But by their very nature, there is no reason to assume the same with the LLMs.
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.
Come on, now. The human writes the plan up front, which includes guidance on testing strategy, classes of tests, particular test cases to cover, etc. And just like normal, of course you don't just ship the code without doing manual verification, code review, auditing the test cases, and all the rest.
How do you do this? I really struggle to get the agents to follow my architectural invariants and coding conventions.
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.
When your AI slides, make a permanent test that catches that particular slide. Then have it run all the tests every time it does something significant.
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.
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.
> By this definition, anyone hired to be a code contributor, and not operating at the architecture level, isn't an engineer.
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.
We recognized socially that people who engineer things need to have professional ethics and carry liability for their projects.
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.
Sure, and that's laudable, both for Canada and for your family. But most other countries don't have such a professional certification program, and since a ton of brilliant creators of software never had one, should we declare them fake engineers? People like John Carmack, Fabrice Bellard, Richard Hipp, Linus Torvalds... I think ultimately results speak for themselves. Surely there are plenty of middling licensed Canadian software engineers as well. Let's not police language like this.
It’s not about skill level it’s about accountability and ethics.
If a bug that Linus introduces into the kernel kills someone, is he held accountable? No, of course not the kernel is provided without warranty or any kind of guarantee of fitness.
He’s not an engineer.
He’s a programmer. A very very good one. But he’s not an engineer.
> 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.
It was already debated whether "software engineering" is engineering, even before LLMs. Even traditional software engineering looks nothing like other fields - in particular lacking a whole lot of discipline. I believe it is, because it's a process of creating complex artefacts to satisfy business requirements, despite the different medium - that definition still remains true when an LLM is used as one of many tools. But "vibe coding" means the LLM is the only tool. Is that still engineering? Well I guess, did you create an artefact that satisfied business requirements? Seems like you did. There's not a good clear line here.
I'm going to take this a step further. Software development is not engineering.
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.
By "franksystems" do you mean those cathedrals which will outlast most buildings we're putting up today? We could go even farther back in history: how about the Pantheon, still the largest unreinforced concrete dome ever made?
hiteshsundraaa | a day ago
dannypdx | a day ago
The days of Devs gatekeeping and shitting on good ideas because the syntax of a PR was not perfect are over.
rvz | a day ago
"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.
bdcravens | a day ago
trollbridge | a day ago
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.
bdcravens | a day ago
(I'm a very biased self-taught developer from the late 1990s who just happened to hit the industry at the perfect time)
dannypdx | a day ago
Most software engineers are hilariously inept at systems engineering,
ejejje1 | a day ago
There’s an easy fix to this - set hard deadlines.
qsera | a day ago
Sure, just also set the requirements "hard" while your are at it..
ravenstine | a day ago
erelong | a day ago
bdcravens | a day ago
reaperducer | a day ago
abc42 | a day ago
montroser | a day ago
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.
reaperducer | a day ago
People who build bridges for a living shake their heads in dismay.
giancarlostoro | a day ago
reaperducer | a day ago
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.
giancarlostoro | a day ago
petcat | a day ago
reaperducer | a day ago
https://www.buildordie.com/ (Build or Die is the web site for a mid-sized architecture firm.)
bdcravens | a day ago
reaperducer | a day ago
qsera | a day ago
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.
giancarlostoro | a day ago
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.
qsera | a day ago
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"..
ofcourseyoudo | a day ago
qsera | a day ago
montroser | a day ago
- Depending on the nature of your application, it may be very important to be able to audit the business logic and intended behavior. For compliance reasons, for operational reasons, for moral/ethical reasons -- you very well might want to affirm what the code is actually trying to do.
- A coding agent may get very creative in order to write code that passes a tightly-defined unit test. It may come up with approaches that technically pass, but work against the overall intention of the app in the first place. This becomes an arms race rather than a productive collaboration, where the agent's increasing creativity has to be matched by a sprawling test suite.
- Eventually, inevitably, business requirements will change, and the blob will need to evolve. It will be much easier for an agent or a human alike to understand how to safely make the change, if the existing implementation is transparent and understandable.
giancarlostoro | a day ago
lunar_mycroft | 23 hours ago
1. Your unit tests are exacting enough to fully specify the unit. In that case, congratulations, your unit tests are the code. They're also probably much more awkward to write, maintain, etc. Also, the compilation step to go from the unit tests to the actual code is now orders of magnitude more expensive, requires a SaaS to even work, etc.
2. Your unit tests are not that exacting and still leave ambiguity, edge cases, etc. In that case it very much matters what's in the blob of code, because while it could be a correct implementation of what you wanted, it could also be something else entirely that just happens to be correct for the part you did specify.
bitexploder | 23 hours ago
There is no correct use. There is no “correct” way to build systems. There is principled and disciplined use.
qsera | 15 hours ago
There is a pretty big difference. If you ask a human "Is X true", and they says "yes", you can be 100% sure that they will always behave in a way that is logically consistent with X being true (talking about a competent and honest human being here, and when the implication is obvious). But by their very nature, there is no reason to assume the same with the LLMs.
giancarlostoro | 39 minutes ago
bhaak | a day ago
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.
ceejayoz | a day ago
I mean, it's the same with building a bridge in the real world, right?
Someone has to check the work.
not_a_bot_4sho | a day ago
The human. But only if you care about verification.
bhaak | a day ago
You can't call it "engineering" if you don't care about verification.
ceejayoz | a day ago
They're the ones checking that work matches the plan.
montroser | a day ago
nilirl | a day ago
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.
zulux | a day ago
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.
bdcravens | a day ago
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.
jnovek | a day ago
throwatdem12311 | a day ago
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.
pegasus | a day ago
throwatdem12311 | a day ago
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.
pegasus | 23 hours ago
throwatdem12311 | 21 hours ago
If a bug that Linus introduces into the kernel kills someone, is he held accountable? No, of course not the kernel is provided without warranty or any kind of guarantee of fitness.
He’s not an engineer.
He’s a programmer. A very very good one. But he’s not an engineer.
whimbyte | a day ago
Majeh905 | a day ago
I agree with this. Sadly, we're good at pushing working demos as the final product in corporate.
guff_se | a day ago
computerphage | a day ago
bhaak | a day ago
Who even puts forward such claims?
classified | 18 hours ago
andrewstuart | a day ago
dosinga | a day ago
> 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.
mystraline | a day ago
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.
throwaway7783 | a day ago
mystraline | a day ago
It uses like 45GB system ram and 11GB g-ram.
pocksuppet | a day ago
m3kw9 | a day ago
empressplay | a day ago
tontonius | a day ago
who cares?
barbazoo | a day ago
That's why they have to make what we produce with the LLM something lesser than what they can do by themselves.
fny | a day ago
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.
pegasus | a day ago
fny | 23 hours ago
vitrealis | a day ago
write 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?
xurenwu | a day ago