Dev jobs are about to get a hard reset and nobody's ready

I spent the last two months "vibe coding". I really think VC as it is defined (keep smashing the accept button and let the LLM eventually "get there") is terrible. My flow has been to use Claude code for an incredibly amazing code gen where:

1. I know exactly what I want architecturally

2. I know how I want it

In this mode the flow is then about validating the code to make sure it is my "image" frequently rather than me dreading not know what rube Goldberg machine it generated after 10s or Ks of lines.

Sometimes I even let it get "close" (ie it took care of all the nitty gritty) and I take over and finish the interesting bits then tell CC what I did and why to update the project memory. Frequent checkpointing and sprinkling .md files with latest understanding is very important (it also has the advantage of making your code llm-portable).

I think the biggest irony is PMs, VPs, CEO had traditional been pretty derisive of "clean code" and yet clean code is absolutely essential to make vibe coding work. Feels like a huge vindication.

I wrote a comment in a similar thread a few weeks ago describing my LLM-coding experience - here's a copy+paste (so any quote replies will be out of context / not actually replying to your comment):

`I'll preface this comment with: I am a recent startup owner (so only dev, which is important) and my entire codebase has been generated via Sonnet (mostly 3.7, now using 4.0). If you actually looked at the work I'm (personally) producing, I guess I'm more of a product-owner/project-manager as I'm really just overseeing the development.

> I have yet to see an LLM-generated app not collapse under it’s own weight after enough iterations/prompts.

There's a few crucial steps to make an LLM-generated app maintainable (by the LLM):

- _have a very, very strong SWE background_; ideally as a "strong" Lead Dev, _this is critical_

- your entire workflow NEEDS to be centered around LLM-development (or even model-specific):

  - use MCPs wherever possible and make sure they're specifically configured for your project

  - don't write "human" documentation; use rule + reusable prompt files

  - you MUST do this in a *very* granular but specialized way; keep rules/prompts very small (like you would when creating tickets)

  - make sure rules are conditionally applied (using globs); do not auto include anything except your "system rules"

  - use the LLM to generate said prompts and rules; this forces consistency across prompts, very important

  - follow a typical agile workflow (creating epics, tickets, backlogs etc)

  - TESTS TESTS AND MORE TESTS; add automated tools (like linters) EVERYWHERE you can

  - keep your code VERY modular so the LLM can keep a focused context, rules should provide all key context (like the broader architecture); the goal is for your LLM to only need to read or interact with files related to the strict 'current task' scope

  - iterating on code is almost always more difficult than writing it from scratch: provided your code is well architected, no single rewrite should be larger than a regular ticket (if the ticket is too large then it needs to be split up)

LLM-coding requires a complete overhaul of your workflow so it is tailored specifically to an LLM, not a human, but this is also a massive learning curve (that take's a lot of time to figure out and optimize). Would I bother doing this if I were still working on a team? Probably not, I don't think it would've saved me much time in a "regular" codebase. As a single developer at a startup? This is the only way I've been able to get "other startup-y" work done while also progressing the codebase - the value of being able to do multiple things at a time, let the LLM and intermittently review the output while you get to work on other things.

The biggest tip I can give: LLMs struggle at "coding like a human" and are much better at "bad-practice" workflows (e.g. throwing away large parts of code in favour of a total rewrite) - let the LLM lead the development process, with the rules/prompts as guardrails, and try stay out of it's way while it works (instead of saying "hey X thing didn't work, go fix that now") - hold its hand but let it experiment before jumping in. `

> Bespoke coding is easy and slow, and you end up an expert in the systems you make.

What good is that when the code gets written by a fresher from Accenture, or someone who ends up leaving the company (average job length for a software dev is just over two years)

I've seen a different kind of usage pattern recently, which is to find a problem that the LLM is good at, something which is very local in reasoning, and do it at big scale across the whole codebase.

I have had a lot of success building small isolated features / projects, but have found Claude to be frustratingly inadequate for any non-trivial work. Ran it on an old and complex C++ codebase, and spent an hour unsuccessfully trying to coax it into fixing a bug. I even helped it by writing a failing test for it by hand. The tools need to improve a ton before software developers can forget how to code.

Yeah, I was about to say, it sounds a lot like this guy is just riding an intense high from getting Claude to build some side-project he's been putting off, which I feel is like 90% of all cases where someone writes a post like this.

But then I never really hear any update on whether the high is still there or if it's tapered off and now they're hitting reality.

I don't think you're getting played.

I think it's legitimately possible to get something done in a week that used to take 3 months, without realizing that you haven't actually done that.

You might have all the features that would have taken 3 months, but you personally have zero understanding of the code produced. And that code is horrible. The LLM won't be able to take it further, and you won't either.

I think we're seeing people on a high before they've come to understand what they have.

Watch: it's just Dario Amodei's marketing reddit account.

Agreed. Where's the code?

> I honestly think we’re being played.

Supposing this is true, who is playing us and why?

> My UML professor said very similar things 25 years ago.

Yeah, it feels like a lot of these stories are the new version of the methodology / database / framework hype we've seen for so many years... with our new tool, you can write Reddit / Yelp / Wikipedia / S3 / etc. in a week. Sure, you can write a prototype that kind of replicates the surface level functionality. How about the actual hard part? Things like scaling, optimization of computing resources across large fleets, evolution of the system to attract more customers, fighting spam, increasingly complicated integrations with 3rd parties, maintenance, etc.

So much of this will turn out like all those things we've seen before. It will take skilled engineers doing a lot of thinking to figure out the right way to leverage the tools to make better systems for less.

> Fully reviewed

Reviewed by a bot (that wrote it no less) is not reviewed. This person is not a software engineer.

I’m always a little surprised when LinkedIn-style posts like this make it on Reddit.

> Yeah maybe. Talk is cheap, show me the code.

Or even just link the app (which the poster is presumably eager to market, right?) as a bare minimum.

If LLMs for coding were half as productive at cranking out production quality software unassisted as the astroturfed hype around them suggests we should have seen a large unmistakable wave of better, faster-released software by now just in the output of software companies, startups, etc, but beyond the hype blogs (or reddit posts) I'm not seeing anything other than the status quo.

I'm not saying LLMs are worthless, they are pretty useful as advanced autocomplete and documentation that you can also happen to ask things in natural languages and get reasonable results (so long as you already have a solid enough base of knowledge to recognize when they are going off the rails). They can be very useful productivity speed-up tools, especially when you start working in a new realm.

But there's a long way from that to the "replaces 90% of all developers in writing 100% of their code" that is being sold in the hype.

I started trying to vibecode over the last couple weeks, and it sucks at 90% of the stuff I have to do at work. That last 10% is nice, but not worth the cost IMO.

However, because I does show promise on a small segment of my work I could see there being an effect on industry where a certain type of dev work gets wiped out. To the extent that there are companies paying people to “be a webmaster” or maintain a basic crud-app, those teams could drastically downsize. Even if that’s just 5% of the total dev population, that’s still a lot of jobs and an entire type of work that just gets wiped out.

AI is like an intern with a LOC quota to hit.

These tools love to just write new code, they hate refactoring or maintaining code which is what this job actually is.

What have you accomplished with Claude Code? Anything you can share?

You and I clicked on it, and the algorithm did the rest.

Cant even tell you how many times vibe code leaves obvious security bugs. Atleast it makes me feel like my job isn't going away anytime soon.