Brilliant. You put into words something that I've thought every time I've seen people flinging around slop, or ideating about ways to fling around slop to "accelerate productivity"...
On the plus side, vibe coding disaster remediation looks to be a promising revenue stream in the near future, and I am rubbing my hands together eagerly as I ponder the filthy lucre.
> On the plus side, vibe coding disaster remediation looks to be a promising revenue stream in the near future, and I am rubbing my hands together eagerly as I ponder the filthy lucre.
I don't think it will be; a vibe coder using Gas Town will easily spit out 300k LoC for a MVP TODO application. Can you imagine what it will spit out for anything non-trivial?
How do you even begin to approach remedying that? The only recourse for humans is to offer to rebuild it all using the existing features as a functional spec.
There's a middle ground here that you're not considering (at least in the small amount of text). Vibe coders will spit out a lot of nonsense because they don't have the skills (or choose not) to tweak the output of their agents. A well seasoned developer using tools like Claude Code on such a codebase can remediate a lot more quickly at this point than someone not using any AI. The current best practices are akin to thinking like a mathematician with regards to calculator use, rather than like a student trying to just pass a class. Working in small chunks and understanding the output at every step is the best approach in some situations.
That's very true. The LLM can be an accelerator for the remediator, too, with the value-add coming from "actually knowing what they're doing", much as before.
> How do you even begin to approach remedying that? The only recourse for humans is to offer to rebuild it all using the existing features as a functional spec.
There are cases where that will be the appropriate decision. That may not be every case, but it'll be enough cases that there's money to be made.
There will be other cases where just untangling the clusterfuck and coming up with any sense of direction at all, to be implemented however, will be the key deliverable.
I have had several projects that look like this already in the VoIP world, and it's been very gainful. However, my industry probably does not compare fairly to the common denominator of CRUD apps in common tech stacks; some of it is specialised enough that the LLMs drop to GPT-2 type levels of utility (and hallucination! -- that's been particularly lucrative).
Anyway, the problem to be solved in vibe coding remediation often has little to do with the code itself, which we can all agree can be generated in essentially infinite amounts at a pace that is, for all intents and purposes, almost instantaneous. If you are in need vibe coding disaster remediation consulting, it's not because you need to refactor 300,000 lines of slop real quick. That's not going to happen.
The general business problem to be solved is how to make this consumable to the business as a whole, which still moves at the speed of human. I am fond of a metaphor I heard somewhere: you can't just plug a firehose into your house's plumbing and expect a fire hydrant's worth of water pressure out of your kitchen faucet.
In the same way, removing the barriers to writing 300,000 lines isn't the same as removing the barriers to operationalising, adopting and owning 300,000 lines in a way that can be a realistic input into a real-world product or service. I'm not talking about the really airy-fairy appeals to maintainability or reliability one sometimes hears (although, those are very real concerns), but rather, how to get one's arms around the 300,000 lines from a product direction perspective, except by prompting one's way into even more slop.
I think that's where the challenges will be, and if you understand that challenge, especially in industry- and domain-specific ways (always critical for moats), I think there's a brisk livelihood to be made here in the foreseeable future. I make a living from adding deep specialist knowledge to projects executed by people who have no idea what they're doing, and LLMs haven't materially altered that reality in any way. Giving people who have no idea what they're doing a way to express that cluelessness in tremendous amounts of code, quickly, doesn't really solve the problem, although it certainly alters the texture of the problem.
Lastly, it's probably not a great time to be a very middling pure CRUD web app developer. However, has it ever been, outside of SV and certain very select, fortunate corners of the economy? The lack of moat around it was a problem long before LLMs. I, for example, can't imagine making a comfortable living in it outside of SV engineer inflation; it just doesn't pay remotely enough in most other places. Like everything else worth doing, deep specialisation is valuable and, to some extent, insulating. Underappreciated specialist personalities will certainly see a return in a flight-to-quality environment.
>it's probably not a great time to be a very middling pure CRUD web app developer
Businesses don't pay for CRUD apps, businesses pay for apps that solve problems which often involves CRUD to persist their valuable data. This is often within the sometimes very strange and difficult to understand business logic which varies greatly from one business to another. That is what "CRUD app developers" actually do, so dismissing them as though there is zero business logic and only CRUD is doing them, us, a disservice.
I really wasn't referring to domain-specific CRUD development of that sort, and tried to draw attention to the distinction with the word "middling", but perhaps it was a bit too subtle.
> it's probably not a great time to be a very middling pure CRUD web app developer. However, has it ever been, outside of SV and certain very select, fortunate corners of the economy?
Like 80% of jobs outside the USA are either local or outsourced CRUD web applications. Many people live quite well thanks to exchange rates. I wonder what's gonna happen if/when those jobs disappear.
I've read your whole reply and agree with most of it; what I don't agree with (or don't understand) is below:
> If you are in need vibe coding disaster remediation consulting, it's not because you need to refactor 300,000 lines of slop real quick. That's not going to happen.
My experience as a consultant to business is that they only ever bring in consultants when they need a fix and are in a hurry. No client of mine ever phoned me up to say "Hey, there, have you any timeslots next week to advise on the best way to do $FOO?", it's always "Hey there, we need to get out an urgent fix to this crashing/broken system/process - can we chat during your next free slot?".
> Like everything else worth doing, deep specialisation is valuable and, to some extent, insulating.
I dunno about this - depends on the specialisation.
They want a deep specialist in K8? Sure, they'll hire a consultant. Someone very specialist in React? They'll hire a consultant. C++ experts? Consultants again.
Someone with deep knowledge of the insurance industry? Nope - they'll look for a f/timer. Someone with deep knowledge of payment processing? No consultant, they'll get a f/timer.
> My experience as a consultant to business is that they only ever bring in consultants when they need a fix and are in a hurry.
No, that's fair, and I think you're right about that. But refactoring 300,000 lines 'real quick' isn't going to happen, regardless of that. :)
> They want a deep specialist in K8? Sure, they'll hire a consultant. Someone very specialist in React? They'll hire a consultant. C++ experts? Consultants again.
I implicitly had narrow technical specialisations in mind, albeit including ones that intersect with things like "insurance industry workflows".
For what I am vibing my normal work process is: build a feature until it works, have decent test coverage, then ask Claude to offer a code critique and propose refactoring ideas. I'd review them and decide which to implement. It is token-heavy but produces good, elegant codebases at scales I am working on for my side projects. I do this for every feature that is completed, and have it maintain design docs that document the software architecture choices made so far. It largely ignores them when vibing very interactively on a new feature, but it does help with the regular refactoring.
In my experience, it doubles the token costs per feature but otherwise it works fine.
I have been programming since I was 7 - 40 years ago. Across all tech stacks, from barebones assembly through enterprise architecture for a large enterprise. I thought I was a decent good coder, programmer and architect. Now, I find the code Claude/Opus 4.5 generates for me to be in general of higher quality then anything I ever made myself.
Mainly because it does things I'd be too tired to do, or never bother because why expand energy on refactoring for something that is perfectly working and not to be further developed.
Btw, its a good teaching tool. Load a codebase or build one, and then have it describe the current software architecture, propose changes and explain their impact and so on.
> I thought I was a decent good coder, programmer and architect. Now, I find the code Claude/Opus 4.5 generates for me to be in general of higher quality then anything I ever made myself.
I have about the same experience as you do and experience using Opus 4.5.
If this is true, you weren’t a very good programmer. There’s much more to code quality than refactoring working code.
> If this is true, you weren’t a very good programmer. There’s much more to code quality than refactoring working code.
Yup, my conclusion exactly.
With that said, most code I have seen in private sector is almost objectively horrible (and certainly subjectively). Code manufactured with the current best tools such as Claude compares favourably. Companies rarely have the patience to pay for well manicured, elegant code. If it sort of works it ships.
The thing is good code doesn’t cost more than bad code in the long run.
In many cases it doesn’t even cost more in the short run. And it usually has nothing to do with being manicured or elegant.
A good engineer will tell you how to spend 25% of effort to get to 90% of the result you want. With maintainable code, and importantly with less code that touches fewer systems.
A bad engineer will deliver exactly what product asked for without asking questions, generate 4x the code, and touch every piece of the system.
Companies are just setup in a way that incentivizes building organizations that create bad code. Most places would rather hire 100 bad engineers who can be easily replaced than 5 good engineers.
Despite having worked with or managed hundreds of developers over the years, I don't think there were more than, maybe, 5 that I would not gladly swap for a claude-equivalent. Diligent, able to produce good code when adequately supervised, and devoid of a desire for work life balance :-)
Most software devs are just mediocre, they learn to code late in life, they work 9-5, and often stop learning as quickly as they can.
> Companies are just setup in a way that incentivizes building organizations that create bad code. Most places would rather hire 100 bad engineers who can be easily replaced than 5 good engineers.
This is quite true, and it is this -- really, a special case of "the market can remain irrational longer than you can stay solvent" -- that has me worried about the implications for the labour economy more than anything else.
The amount of software needed and the amount being written are off many orders of magnitude. It has been that way since software's inception and I don't see it changing anytime soon. AI tools are like having a jr dev to do your grunt work. Soon it will be like a senior dev. Then like a dev team. I would love to have an entire dev team to do my work. It doesn't change the fact that I still have plenty of work for them to do. I'm not worried AI will take my job I will just be doing bigger jobs.
> Do you not fear that future/advanced AI will be able to look at a vibe-coded codebase and make sensible refactors itself?
This is a possibility in very well-trodden areas of tech, where the stack and the application are both banal to the point of being infinitely well-represented in the training.
As far as anything with any kind of moat whatsoever? Here, I'm not too concerned.
I am no longer sure thats the case. I had it chew through a gnarly problem with my own custom webrtc implementation on a esp32 SOC. It did not rely on any existing documentation as this stuff is quite obscure - it relied on me pointing to specs for webrtc, specs for esp32 SDK, and quite some prompting. But it solved the problems I was dreading to solve manually in a matter of a 2hr session. Thats for a hobby project, we are now starting to experiment using this in the enterprise, on obscure and horrible to work with platforms (such as some industry specific salesforce packages). I think claude can work effectively with existing code, specs on things that would never made it to stackoverflow before.
> Do you truly believe it won't get better, maybe even better at whole system design and implementation than people?
What are you calling "growth"? Adoption, or LLM progress? LLM progress has objectively slowed down, and for rather obvious reasons. The leaps from GPT-2 to GPT-4 can't be reprised forever.
Came here to say this. I've been programming since I was 9, and it always had a strong aesthetic, artistic and creative dimension. That dimension has always been in tension with the economic demands of adult life, but I was good at finding the quiet corners in which to resolve it.
A lot of work was tedious, painstaking grind, but the reward at the end was considerable.
AI has completely annihilated all of the joy I got out of the process, and everything that attracted me to it with such abandon as an adolescent and a teenager. If someone had told me it was mostly slop curation, I would have stayed in school, stuck to my philosophy major, and who knows -- anything but this. I'm sure I'd have got reasonably far in law, too, despite the unpropitious time to be a JD.
I'm very much in a similar boat to you - I'm also considering a pivot away from SWE if this is what it's going to become. Luckily I'm still young and don't have anyone depending on me (other than myself).
I'm still working on my own small closed source projects, building them the way I want to, like a gameboy emulator - and I've gotten a lot of joy from those.
I think deskilling is an underrated concern. Programming among the competent is a mind-body experience and a matter of motor memory and habits of mind, and LLMs make you extraordinarily lazy.
No matter how 'senior' you are, when you lose touch with the code, you will, slowly, lose the ability to audit what LLMs spit out, while the world moves on. You got the ability to do that by banging your head against code the hard, "pre-AI" way, perhaps for decades, and if you don't do the reps, the muscle will atrophy. People who think this doesn't matter anymore, and you can just forget the code and "embrace exponentials" or whatever, are smoking the good crack; it _is_ about the code, which is exactly why LLMs' ability to write it is the object of such close examination and contestation.
Folks who realise this will show to advantage in the longer run. I don't mean that one shouldn't use LLMs as an accelerant -- that ship has sailed, I think. However, there is a really good case to be made for writing a lot by hand.
I understand the overwhelming opposition to this, and I wouldn't do it myself. However, I lead a life of very few meetings (I'd actually appreciate more--this stance puts me in a very small company, to be sure), so it's easy for me to say that one should be more judicious with one's timing.
I can emphathise with someone stuck in meetings all day in a predominantly listening role, that they consider perfunctory or mostly pointless, or maybe in a very active role that has them stressfully bouncing from meeting to meeting.
I can easily envision how this would lead to a kind of nihilistic resignation and a determination to just do normal life stuff with a headset on one's head.
And if you're going to be playing audio in the bathroom, any audio, wear some god damn headphones. I don't want to listen to your standup or your tiktok.
An old business partner had meetings which felt like 24/7. He had zero issue taking a phone call in the bathroom. I doubt anyone on the other end ever knew.
As a matter of fact, I do NOT understand the overwhelming opposition to this. What's your deal if a guy is good at multitasking and people on the other end of the wire don't mind it? It isn't like he is desecrating a temple, or intruding into your home and using your toilet, or jerking off in the public... Wait, actually I'd say even the latter shouldn't be your business, unless he stains something. Why cannot people mind their own business?
> It isn't like he is desecrating a temple, or intruding into your home and using your toilet, or jerking off in the public...
Just like jerking off, defecation should be done in private. Meetings are not private.
Very few people want to see/hear/smell you do that and that includes over zoom or phone conference. Most people really do want to mind their own business, and that means having no part in you doing those very private things.
If someone is in a meeting on their phone while in a bathroom stall it's also very rude to everyone else in the bathroom trying to do their own business as privately as they possibly can under the circumstances.
Even that I'd call somewhat petty, but it is more defensible if it's insulting to you when you hear toilet noises from your phone, and you are totally in your right to tell it straight to the person who is calling you, that it's hard to hear him behind all farts and flushes. That's ok. People here seem to be complaining that somebody else is talking to somebody else on a phone while being in the public (office) toilet. I mean, I kinda understand if it distracts them from their business due to some psychological difficulties they may have, but that's the public toilet design fault when you cannot feel isolated enough, not the guy's talking.
Me either, which is why I find it so satisfying to shake the stall with explosive bowel movements when necessary. I’m very private by nature so it makes me giddy to cut loose. Only when necessary of course.
What a weird take. If I'm also in the bathroom, I can tune out all the other noises around me because everyone's in there to do the same thing. If I were on the phone with someone, paying close attention to what they're saying, and then I'm treated to a thunderstorm of bowl challenges, I'm going to be annoyed.
Humans pee, fart, and burp. That's perfectly normal. And yet, it's considered basic politeness not to do those things in a freaking business meeting if you can help it.
At the end of the day it's very easy and free to not shit while on a conference call. I think 99% of people would prefer a shit-free conference call, so, maybe we're all spoiled.
Asking because I was pretty much on-board with the comment and took it as being fully serious, up until the point of “jerking off in public shouldn’t be anybody else’s business, unless they stain something” being mentioned.
Now, I am not so sure. Either the entire comment was sarcastic or I am missing something major. But putting jerking off in public and talking on the phone in a public bathroom into the same bucket of activities (in terms of appropriateness) feels crazy to me.
They are not in the same bucket, and I'm being intentionally provocative, if this confession makes things easier for you, but I really don't think you should mind that much if somebody is jerking off in public unless it harms you in some way (in broad sense, e.g. being intentionally annoying, loud and doing it right into your face). The point is that you should do whatever you want unless it harms others, and shouldn't mind other people doing whatever they want unless it actually harms you. I would say a guy watching tiktok without a headset right next to you in the airport harms you waaay more than a guy jerking off in the same airport standing 10 m away from you or anyone else. I mean, it's disconcerning, because you'd rightfully assume he must be crazy, but the activity itself really shouldn't bother you.
And surely anyone mentioned is a hundred times less harmful than a guy smoking on the street. That should be illegal. Yet people for some reason act as if it's ok, and it is broadly legal in most places (unlike jerking off in public).
If that's the case, then sure, that perspective is way more understandable.
I didn't take it that way, because "in public", to me, implies that other people are fully exposed to it. I don't consider "in a private stall" as public, just like I don't consider "taking your underwear off in a bathroom stall" (very normal) as "taking your underwear off in public".
I have no wish to listen to other people's bodily functions when I'm working, or conversely to listen to them working while I'm answering a call of nature. The correct response to these behavior is to either hang up on them or tell them to shut the fuck up, respectively. It's not OK to impose yourself on others like this.
Thank you for helping me clarify something. Your last example, jerking off in public, is not only a crime (as it should be) but is clearly antisocial behavior. That helped me realize that's what all the other shit is too, no pun intended. Using the restroom while you're talking to other people on the phone, or generally just doing anything that forces other people to listen to you use the restroom, is antisocial behavior and shouldn't be tolerated by anyone civilized.
"Minding your own business" when it comes to antisocial behavior is enabling when the correct response in shaming and ostracizing. It's not going to work with LBJ but it will probably work with Kevin from accounting.
I can relate to this. I was always moderately extroverted and sociable, but the irony has never ceased to flabbergast me that the very behaviours and interests for which nerds like me would have been stuffed into lockers and garbage cans (if I had dared to tell anyone in school that I was into computers) became, only a decade later, de rigueur for every young person.
I remember sitting in a coffee shop in 2003 (senior year of HS) trying to get kernel drivers for a PCMCIA 802.11b card to work on an ancient Compaq laptop, and being pointed, laughed at, and called -- by modern standards -- unconscienable names by a table of high schoolers nearby. It must have seemed so strange to them to see someone's head so deeply in a laptop.
And my goodness, I wouldn't have dared to confess that I talk to strangers in faraway places _online_. To be known to have substantive computer-based interactions would have branded one so profoundly socially unsuccessful, that one's very family name would be cursed with this prejudice for two generations. AIMing one's classmates on the family PC was one thing, but chatting online to likeminded peers in other countries? Why, that was radiantly gay!
But literally a few years later, I can't get anyone to make eye contact and they frequently plough into me because their heads are buried in their phones, texting people they never see.
Trust me I am in 2025 and I am in senior high school and whenever I try to talk about open source or linux or anything others. Friends have point blank said that they aren't interested in it. (only one friend showed interest/shows interests at times)
the most ironical part is that they want to become software engineers for just the money aspect but fundamentally they really don't know anything about the field or are even interested to talk about.
So in a sense this still happens :) This happened so much that I had to cut off my friends because the only thing that they were interested in talking about were woman or insta shorts and very few intellectual discussion could happen (atleast with that friend group and I would consider that friend group to be more intellectual among other peers but for some reason they just never wanted to discuss intellectual topics other than some very few occasions, mostly just shitposting being honest and I didn't enjoy the shit posting aspect that much if I am being honest as well)
For what its worth, the field does have something of an immune response to those sorts of people (software engineers only in it for the money). You often hear a lot of nonsense online about leetcode interviews or whatever, but most of my jobs have asked questions like "do you have a computer at home? what kind?" and "have you ever used linux?" or "tell me about some hobby projects you have done, its okay if it was a long time ago" and used the responses to try and figure out if you were interested in computers. Ive often had bosses talk about how its been much more successful for them to train someone interested or give them space to learn themselves rather than hire someone checked out who has only credentials. If anything, thats the entire risk that hiring is trying to avoid.
I get it a little less now, but perhaps thats because i'm starting to have a good amount of experience to talk about - and getting questions more like "talk about a project that you thought was going to fail. What happened? did you do anything? why?" to try the same thing but with management concepts. They want to see that you're interested.
Hah! I had a very similar thought enter mind recently. I used to get shamed for being on screens too much, now the situation seems to have flipped. Who's the nerd now??
> Americans get an idea of how bad we have it when we go on vacation, but we don't see it as something that can be built at home.
It's so strange how this works. They go, sometimes repeatedly, to enjoy these rather basic things, but behave as though they're visiting a quaint Disneyland of sorts and as though there could be no lessons they could take away and apply toward a vision of their own community...
What if we hosted the cloud... on our own computers?
I see we have entered that phase in the ebb and flow of cloud vs. self-hosting. I'm seeing lots of echoes of this everywhere, epitomised by talks like this:
> What if we hosted the cloud... on our own computers?
The value proposition of function-as-a-service offerings is not "cloud" buzzwords, but providing an event-handling framework where developers can focus on implementing event handlers that are triggered by specific events.
FaaS frameworks are the high-level counterpart of the low-pevel message brokers+web services/background tasks.
Once you include queues in the list of primitives, durable executions are another step in that direction.
If you have any experience developing and maintaining web services, you'll understand that API work is largely comprised of writing boilerplate code, controller actions, and background tasks. FaaS frameworks abstract away the boilerplate work.
To me, the principal differentiator is the elasticity. I start and retire instances according to my needs, and only pay for the resources I've actually consumed. This is only possible on a very large shared pool of resources, where spikes of use even out somehow.
If I host everything myself, the cloud-like deployment tools simplify my life, but I still pay the full price for my rented / colocated server. This makes sense when my load is reasonably even and predictable. This also makes sense when it's my home NAS or media server anyway.
