You will be surprised by how many professional software engineers don't read their code or care these days.
I have seen a bubble sort function in a PR from an engineer with 10 years of experience. Meanwhile sort from standard library is easily available with one single line.
The bar has become as low as "it works" without considering what's in the code or whether the entire feature should even exist at all.
P.S. that same engineer sent out a PR of 200-file feature. The PR is so large that it freezes the latest MacBook Pro if you try to read it. Nobody reviewed it and he merged it himself. Nobody uses that feature, and nobody in the teams wants to maintain it. Now we are considering scrapping it.
The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
So it's already an improvement. Should it be manually read, comprehended, reviewed? Probably. But they can get to an improvement over what they did 2 years ago, with basically no effort. And then they can get a little bit further, with massive effort?
The "LLM-yolo" is a big knee in the cost/benefit curve. It's an improvement over their "old code". The only drawback is: it's still containing bugs, and now no one understands them. But that's not hitting them until that code has aged somewhat, so a year or two down the line.
> The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
If mediocre code is better quality than what you wrote by hand, you've quickly discovered that you're incompetent.
> If mediocre code is better quality than what you wrote by hand
Most code I have seen and reviewed over my 25+ year programmer life has been no worse than mediocre LLM code.
It's not a massive sample, but to me it suggests, most code programmers write, is somewhere between bad and mediocre.
And here's the appeal of the models: if what you used to produced was bad-to-mediocre, and you can now do slightly better for much cheaper, that's a huge win.
> And here's the appeal of the models: if what you used to produced was bad-to-mediocre, and you can now do slightly better for much cheaper, that's a huge win.
And the guy you were responding to is seeing people produce worse code with LLMs (e.g. senior engineers pushing non-library bubble sort implementations, like they're in a high school programming class).
And if you're somehow right, it's not a "huge win" for you. It's a sign you're personally providing little value to the business, and sooner or later you'll need to find a new career.
What I'm saying is the quiet part out loud: A majority of coders and a majority of really IS bad. And now a lot of that code is actually better (big win).
Basically: the code was so bad before, that un-reviewed LLM-code is now better than the average contribution. That means, that at least short term, the vibe coding can increase quality.
The problem is that it also increases code volume (bad) and rapidly decreases understanding (even worse).
Yeah I've been experimenting with a bunch of different domains: 2D CAD, PCB design, coding obviously and recently I had Claude finish a project on all three fronts: finish the firmware(in rust because why not), change up a few components and finalise the pcb design, source all the non pcb components and do all the documentation for the installer. To be fair, it had a solid base to build from, but still, almost everything was "good enough", now I'm at work looking at PCB design that take the electrical engineers 8 weeks when I know I could have had two prototypes shipped and tested already. The fact is 90% of people are not doing the really hard stuff and Claude can just brute force pretty much any low to mid tier white collar task given enough information.
Code volume and understanding can be tackled with a proper system prompt. Even afterwards, apart from costing resources, a cross-model optimization can increase quality of the output.
Unix philosophy in the system prompt could be useful if the code wants to be worked on later again.
> Unix philosophy in the system prompt could be useful if the code wants to be worked on later again
There is no system prompt that can prevent this. If all you needed was some kind of rather short instruction we'd already have that baked into harnesses a long time ago. The problem is not that agents do not have the right instructions, they theoretically have everything there is to know about software architecture already in their training data.
They do have "everything" but that's too much, I think. They need to have direct instruction that is in the context, that is appropriate for the project and codebase at hand. In the whole universe of training data, there's every approach imaginable. What's needed is enough guidance to identify the right approach consistently.
I recognize that crafting a 'perfect' prompt is impossible, but neither is writing the perfect code, or even the 'perfect' code style guide. But it is 100% the kind of problem that can be iteratively improved to a point where it's much better than what you get by one-shotting everything without much consideration of these details.
I myself am maybe 5% sophisticated if 0 is I just discovered LLMs today, and 100 is the most skilled at using AI the world has seen. What I've learned so far is that I have a lot of room to improve.
Which is why I am actually not completely worried about the careers of current software engineers: If you brought in a bunch of non-engineers to prompt Claude to build and maintain an ERP system, or a social networking site, or an ad exchange, or even Shopify clone, I don't see those products being competitive with ones where engineers armed with the same LLMs are building them.
> They need to have direct instruction that is in the context, that is appropriate for the project and codebase at hand
> I recognize that crafting a 'perfect' prompt is impossible, but neither is writing the perfect code, or even the 'perfect' code style guide
This is not about "perfect code" or style guides. For code styles we have linters, that does not require any instructions. I'm talking about software architecture for large complex web applications that dozens of people (that also change frequently) contribute to and that is spread across many different repos/services and an environment with constantly changing business requirements.
The terms that are relevant here are: coupling, cohesion, vertical slices, module boundaries and so on. This is software architecture and coding agents are terrible at this and there is no prompt and no instruction fixes this that could reasonably fit into a context window. I don't even think that coding agents fail because the lack the instructions and therefore adding instructions won't fix these failure modes.
> What I'm saying is the quiet part out loud: A majority of coders and a majority of really IS bad....
How would you know "the majority" from your anecdotes? Maybe you just spent your career working with incompetent people who didn't care.
And actually there's a point I forgot to address earlier, in my first comment:
>>>>> The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
People whose hand-written code is worse than "mediocre LLM-code with a mediocre LLM-review" are not going to discover the LLM-code is better, because they typically don't care. That's usually the whole problem with that kind of person.
> ...And now a lot of that code is actually better (big win).
> Basically: the code was so bad before, that un-reviewed LLM-code is now better than the average contribution. That means, that at least short term, the vibe coding can increase quality.
> The problem is that it also increases code volume (bad) and rapidly decreases understanding (even worse).
You're contradicting yourself here. Even accepting your statements uncritically, it doesn't sound like a "big win." It sounds like a marginal improvement that's ultimately self-defeating.
The problem with hand review I always had was trying to teach the other person. You don't want to present them with an avalanche of problems. So you pick the most important 5. Over time this iterates and you build someone good at what they do.
The good part of LLMs is you don't have to worry about overloading them: you can just outline every problem with the code they produce.
The bad part of LLMs is they don't really "get better" at this stuff. I'm not training a human, and there's a limited amount LLMs can learn. So the training phase never really ends - it's Eternal September.
There's also the problem of this ultimately being my code. It isn't Claude's - Claude isn't a person.
I still read the code. I use LLMs to review it. But I also review it myself. Ultimately its faster than before, and probably better quality (because I can just give all the problems to the LLM), but slower than people doing zero review.
> The bad part of LLMs is they don't really "get better" at this stuff. I'm not training a human, and there's a limited amount LLMs can learn. So the training phase never really ends - it's Eternal September.
After I give feedback to the AI I then ask it if we learned something and then I ask it to store that guidance in a relevant skill file.
I have skill files for everything and anything in my project. Three just for testing - one for frontend, backend, and e2e. I have one just for frontend forms. I have one for project terms, which I ask it to read before doing anything, so it keeps the terms in the project right. I have one for doing db migrations and one for doing backend routes. I have many tens of skills that have been slowly built up like this.
> The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
Not my experience at all. Mediocre LLM-code, mediocrely reviewed is a loaded footgun aimed at both your feet.
> The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
Emphasis mine.
I can't phantom some that bad at coding. Using such exaggeration void your comment.
> The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
No, I find that most teams I've been on have 5% to 20% of their most artisan engineers actually giving a shit about the code, and gently coaching the other 95% to 80% of the engineers who are usually much more junior during code review to not push unmaintainable slop. If you're on a team that doesn't still have someone giving a shit, it's not a sign that there are no teams that don't give a shit, it's that you're on a shit team.
There are also teams where the incentive is to get to pull request (or merge request) as soon as possible, so that you can move the ticket across the board and relieve downward pressure. That usually means pushing subpar code to PR that you know you'll spend another few hours fixing. EDIT: I bring this up because this can bias one's belief that humans produce poor quality code, when you're usually looking at the first draft that was incentivized to be pushed out "too early".
Anyway, if you're on a shit team, but you're still satisfying product and nothing is blowing up yet, there's a pretty good sign that your software has no moat and will be the first to be replaced by LLM-generated software on-demand. This is probably where most niche B2B back-office, front-office software sits. Stuff that sits somewhere in the realm of "We could probably do this in Excel if we wanted to."
It’s so easy to generate a pile of crap now that it “just works” as you say.
Quality, maintainability, simplicity, understandability, flexibility etc all still matter at $DAY_JOB, where you’ve got paying customers. We’ve got a responsibility to write good software that adds to people’s lives.
I’d recommend to try to raise the bar. Commit messages written by humans, no PRs above a certain size, any PR needs an introduction / explanation by author first for the reviewers.
This is not overly surprising to me, the last decade or so has seen the industry become a "good job that pays well" and many people got into not for the love and craft, but for the money
I dont think it has as much to do with that as it does rising expectations from leadership to just ship MORE.
MORE MORE MORE like AI has given executives an excuse to ratchet up performance expectations by at least 3x (as in my company) up to 10x for certain start ups I've heard.
There's literally not enough time for a human to do all the activities around quality they were doing even a year ago.
This kind of thing is awful if this is how engineering is going for user-facing apps, but disastrous if this is how it's going for infrastructure and libraries.
It's interesting your complaints are similar to mine about TDD. I've dealt with so many engineers that assume that coverage and passing tests is the bar.
When you get paid to care, you will care. Unfortunately, no one cares, they just want results, any result. Bubble sort will do, especially for low volume tasks.
Use the time you save by not caring, to do other fun stuff.
> Use the time you save by not caring, to do other fun stuff
What kind of time do you save, especially at work? At any normal software shop you have an endless list of things to do. And most often you don't get to choose the "fun" part.
Had AI do some work parsing markdown with the leading library for it.
Follow up work to generate markdown? It wrote a mess of manual string building instead of using said library lol. Even with strong AGENTS.md guidance around using existing and leading community libraries they will often take a hard left and write stdlib straight into your repo.
Y'all should scrap that feature and maybe the engineer. I believe the Shopify CEO recently referred to those types of PR as "slop grenades" that cause headaches for everyone else..
I have seen a bubble sort function in a PR from an engineer with 10 years of experience. Meanwhile sort from standard library is easily available with one single line.
The bar has become as low as "it works" without considering what's in the code or whether the entire feature should even exist at all.
P.S. that same engineer sent out a PR of 200-file feature. The PR is so large that it freezes the latest MacBook Pro if you try to read it. Nobody reviewed it and he merged it himself. Nobody uses that feature, and nobody in the teams wants to maintain it. Now we are considering scrapping it.