Guessing you’re not at FAANG or similar company. For the last 6 months at least there’s been tremendous pressure from leadership (including highly experienced IC engineers) to let AI take the reigns, assumption being that future AI assistants will be able to deal with any level of complexity and tech debt created today.
Given that everyone agrees that reviewing all AI-generated code is impractical (if you let the agents rip at maximum available bandwidth), and that “harness engineering” is at best immature and at worst complete snake oil when it comes to ensuring system stability, maintainability, and quality, I do believe that it’s fair to claim that most engineers are, in fact, supportive of low quality code generated by LLMs.
Fwiw I do see pushback here and there, but only from the lowest rungs on the career ladder - ICs with enough experience to see where this train is headed, but no ability to save it. Management needs to see the results of their policies first, and that will take months or even years to fully play out.
Hence "seem". Of course people are not in the habit of describing their process output as "low quality", let alone supposing that that's the point. But when people clearly prioritize speed, and when the result is low quality, it's easy to get the impression of intent.
Kind of a shocking thing to see argued on HN. Maybe it's just the vibe coders.
There will be a large majority of people who hold these opinions, because they weren’t capable of or didn’t care enough to write good code in the before times
To a lot of engineers code quality means upper-case C Clean Code. Other engineers are in the Grug brain camp where they think that premature abstraction is the worst kind of code.
But to your point I think the majority of engineers think they high quality code is anything that compiles or passes their (almost definitely insufficient) test suite.
You're conflating two different things. I'm one of the people arguing for the latter, but not because I don't think code quality matters but as a counter to to sudden idealization of handcrafted code.
This is the entire premise of the concept of "vibe coding", and the concept of non-programmers using coding agents. The idea that there aren't large amounts of people and companies doing these things and/or who consider it "the future" is hard to argue.
If I know what addition is, I can look at at a line that does addition and reason about it. If I just check "if it works", for all I know, the actual code is something like
if (thing == 17)
{
shit_the_bed();
}
else
{
thing += other_thing;
}
It's kinda like cheap/fake concrete: If you know something about concrete and what concrete is being used, you can roughly tell if it will last, what it will withstand. If you just go by "seems to work", "looks good", you get collapsing bridges and buildings after a few years, during heavy rainfall etc.
No not really. These are separate questions from what the article posits. The argument is about how do we use these tools, our approach as developers, and if the results are going to be as rosy as advertised.