[lelanthran]

> 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.

[mathgeek]

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.

[abalashov]

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.

[baxuz]

The f is gas town?

[hkrgl]

https://github.com/steveyegge/gastown

[abalashov]

> 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.

[newsoftheday]

>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.

[abalashov]

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.

Why, I do plenty of what you describe myself...

[dysoco]

> 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.

[abalashov]

That is concerning, as a matter of social problems.

[lelanthran]

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.

[abalashov]

> 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".