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

I'm doing a reasonable size project with Claude Code doing almost all of the programming, and it's quite challenging.

Vibe coding is easy and fast, but you end up not being an expert in the code base or really having any idea about it. And once it reaches a certain size, the LLM isn't an expert on it either. It is only an expert on cleanly isolated sections of it, which, by the way, it's really bad at producing without lots of good guidance.

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

What I've found is once the system is beyond the size that an LLM can reasonably handle, it's faster to be an expert than to try to get the LLM to do things; in some cases infinitely faster (the LLM can't do it.)

Maybe you get a system of that size done in a week instead of 3 months with vibe coding, and this applies to subsystems as well if they're isolated. But for now you really still want someone to end up an expert in all the code that was produced.

So for now I think there's a big skill point that is still only achieved by humans -- guiding the LLM to produce systems that both the human and the LLM will be good at long term. That is, NOT vibe coding from the beginning, but doing something a bit slower than vibe coding and much faster than bespoke coding, with an eye toward clean, testable, isolated systems - something the LLM is not naturally any good at making but can be done with good guidance.

    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)

    This is off the top of my head so it's pretty broad/messy but I can expand on my points.

    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.

It’s only a feeling, but I’d swear I’ve seen variations on this post across a half a dozen software-adjacent subreddits every day for the last month. The common denominator has always been “Paying $200 for Claude Max is a steal” with absolutely no evidence of what the author did with it.

I honestly think we’re being played.

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

> Last week, I did something I’ve put off for 10 years. Built a full production-grade desktop app in 1 week. Fully reviewed. Clean code. Launched builds on Launchpad. UI/UX and performance? Better than most market leaders. ONE. WEEK.

I really wonder why people who write these things never actually show these apps they vibe coded in a week that are “better than most market leaders”.

> We’ve hit the point where asking “Which programming language should I learn?” is almost irrelevant. The real skill now is system design, architecture, DevOps, cloud — the stuff that separated juniors from seniors. That’s what’ll matter.

My UML professor said very similar things 25 years ago. You’d just draw a UML diagram, and boom! All the code would be generated. The only thing I remember from this class is how terrible she was at coding.

While everyeone is just unilaterally asserting things, I'll jump in: no they won't. Practically every output of LLMs I've seen (even the "cutting edge" agentic ones that everyone says you have to evaluate or else your opinion don't count) has been poor quality with baffling bugs. These things do actually matter. Especially for anything that can be remotely described as "niche" or "research" they are astonishingly bad - maybe they're great for Go microservices or webdev, but there's a huge gap from there to "the entire software developer industry is doomed". Just calm down, man. You don't have to either breathlessly praise AI or start doomsaying, or say they're flat worthless, but a bit of humility over how uncertain the future may turn out is a noble trait to have.

The first comment to the post referenced Kent Beck's:

> "The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate" [0]

At the time that felt like an exaggeration, but from my own use of Claude Code over the last month, I now entirely agree. My take on this is that we need to educate future devs from the very start as engineering managers - to be concerned a lot more with the "what", the "why" and the "is it good for our expected needs" rather than the low-level "how".

[0] https://tidyfirst.substack.com/p/90-of-my-skills-are-now-wor...

> We’ve hit the point where asking “Which programming language should I learn?” is almost irrelevant. The real skill now is system design, architecture, DevOps, cloud — the stuff that separated juniors from seniors. That’s what’ll matter.

I’ve never worked in a shop where knowing how to write code is enough. While I’m sure these places exist, from my first software engineering job ~13 years ago to today, distributed systems design and architecture has always been a table stakes skill and specialization in a particular language has been secondary.

I feel like I’m living in a parallel universe. Where all the code only jobs anyway?

> We’ve hit the point where asking “Which programming language should I learn?” is almost irrelevant. The real skill now is system design, architecture, DevOps, cloud — the stuff that separated juniors from seniors. That’s what’ll matter.

Those skills require knowing how code works. You can't leapfrog into a senior dev., at least not in most cases. Languages have drastically different features plus the AI agents will not be perfect and you'll need to review code and probably modify some of it. The more you know how to code the easier this will be.

Why is a post by some rando on Reddit considered quality news, worthy of reaching the front page of HN? This is just comment bait. The discussion is fine, but all I see is anecdotal conjecturing.

>It’s already doing 100% of the coding.

Way to go killing credibility straight out the gate. I could buy a high percentage for certain types of apps, but not 100%

Probably the biggest sign of the times right now is a massive unfusion of capital into data centers and hardware and less so into programmers. It's hard to land a job right now if you're looking.

I like LLMs. I really do. But my experience with them is very different from the Chicken Little folks.

Let's park coding to the side for a bit.

Case 1:

I am collaborating with a friend to build a graded Sanskrit reader for beginners using the Aesop's fables.

As a precursor, I asked Gemini 2.5 Pro if it had access to all the stories. Yes, it said. The three popular PD ones? Yes.

I asked it to print all three versions of a particular one, and it did. One of them was not the version it confidently claimed it was. We argued about it for a while. It shut up when I provided actual evidence.

I then decided to upload the three Gutenberg text files and asked it to use them as the source of truth to give me a list of unique stories putting variant plots, variant titles etc under the main heading. I gave it certain formatting requirements so that I could later verify if all 600-odd tales across the three books were properly accounted for.

Gemini tied itself into knots trying to do this. It could not guarantee that all the tales were present in the list it generated. It didn't know how to accomplish the task. Finally, I gave it a series of steps, an algorithm based on an n-branched tree. Only then did it manage to generate the list for me.

This took me four hours of wrangling across three different sessions.

Case 2:

I have been buying TASCHEN editions of impressionists and other classical artists. I wanted Gemini to compare various editions, give me the pros and cons so that I could pick a good edition to buy. By the time we came to Michelangelo it went nuts, hallucinating editions, ISBN numbers, page counts, authoritative urls, worldcat searches ...

This took about two hours.

There are more such amusing anecdotes. Some from DeepSeek as well.

I have tried LLMs with python, and typst and a few other things. Sometimes they work, sometimes they don't. They definitely do not write code the way I want them to. They will use OOP even if I specifically warn them not to.

LLMs are VERY good at translation and languages. I will give them that. But reasoning? I am not convinced. I will believe that LLMs are good enough to replace programmers when the Amodei siblings can operate their company only using LLM developers.

> FUTURE GENERATION WILL HAVE HIGHER PRODUCTIVITY INGRAINED AS A EVOLUTIONARY TRAIT IN THEM

If we're lucky, future generations will not have to think about productivity at all. For so long we've been in this mode where more is better: Make the economy go brrr and good things happen by proxy.

If AI can handle the brrr, then maybe we can start being a bit more thoughtful about which direction our efforts are steering it in, about whose dreams we're making come true and whether they're any good.

If so, then the valuable skill is going to be the ability to chart a course to where people want to be, and to be believed when you say you can get us there from here. Letting AI handle most of the middle steps does not strike me as the path to that credibility--that's not a leader, that's just the hype guy.

I see it from many sides.

1. A non-web dev creating a personal website for spouse because well, I am the IT/tech guy. 2. At work with side/ productivity projects where manager asked something to be done but not how it is to be done. 3. At work with enterprise project as main role.

So on 1) AI/LLM are amazing. As easy Hugo maybe I can't create a small website on weekend without even using readymade themes. For 2) again it is great I was able to lot of interesting code/scripts for personal automation with Go, Java, duckdb etc. For 3) they are okay mainly because those large IT applications have far too many hard dependencies on legacy backends and services. Generating some fancy wrapper in Node, React or whatever is not going to do much (for me). They do help with bits on API discoveries and usage examples.

Maybe it is my experience bias but all the Java code it throws at me uses old Java 8 APIs even though my projects are setup to use at least Java 21. So I have to constantly nudge it towards using better APIs, whereas for 1) and 2) I'll take what I get.

I’m not a developer, just an IT dinosaur, but one comment in the thread stuck with me:

> it has felt like a movement of “code first, think and ask questions later” took over the narrative during the past decade

That, I believe, is the real “hard reset” nobody is really talking about. Because the outcome is the same regardless of how AI goes:

* If AI is real, this progress continues, and magically half of my technical grievances are addressed, then thinking through the actual long-term problems, project planning, and technology architecture skills will explode in value overnight and the next millionaires will be Architects who can orchestrate and integrate complex systems with AI tooling…

OR

* This AI is just a fad, the bubble pops, and suddenly everyone who has “bandwagoned” into tech but not cultivated a growing skill set beyond coding problems will be forced out of a job. Those left behind will be the ones who kept their skills sharp and growing while everyone else drank the Kool-Aid, and no amount of community college programs or ITT Tech schemes will be able to create the amount of talent needed.

Just my two cents, and why I’ve been punching my way into architecture since COVID. I’m no dummy.

I would really like to see the App this person is talking about. I am sure AI coding is very useful, but its so hard for me to judge without seeing the projects people are making with it. I have seen lots of toy examples in my field (not intended to be commercial) but this person claims they are making a commercial thing from scratch with AI. It's so hard to judge without seeing the work product.

I'm curious what software engineering is like inside companies like Anthropic. How much of their work is done using Claude Code and how much more productive are they? I'm not looking for something like an engineering blog that's been crafted for marketing purposes. I would really like an honest appraisal from a developer working there.

post by someone financially self interested in scaring labor into submission

> Going forward, I won’t be hiring for languages, I’ll hire devs who can solve problems, no matter the stack.

Ah, there it is. Every time I see one of these posts, it's by someone who isn't actually a developer. It's always some gleeful executive type salivating over how much money he thinks this will save him.

I suppose we'll have to suffer a wave of these idiots firing their engineering staff and crashing their companies before they learn their lesson.

I've recently been writing some Nix modules for personal use (mostly flake-parts) and using o3 to help, since o3 is the first OpenAI model I've used that seems good enough for many tasks.

It's useful for answering some questions about Nixpkgs conventions, but it's not much faster than just looking in the manuals or reading the source.

But when it comes to looking at my actual code and answering questions about it, it's extremely hit and miss. It's good at constructing simple functions, but the module code it writes sometimes inappropriately imports idioms from other languages. It hallucinates often.

And it's absolutely worse than useless for debugging Nix module system issues. It gives nonsense answers to questions about infinite recursion issues which manage to be plausible enough to make me waste a lot of time thinking about them, before I learned more details of the module system.

After getting burned for following it down its rabbit holes, I unfortunately find myself ignoring most of its output related to this project, even as I continue to reflexively ask it things. I have often noticed in these cases that it turns out to have been right, but am left still with the empty feeling not that I shouldn't have bothered to figure out my own answer, but that I shouldn't have bothered to ask.

All of that is to say: I think working in a language/ecosystem LLMs are "bad at" is a useful sanity check. The ways that LLMs suck at languages they suck with are instructive because they reiterate the nature of the things. The failure modes are still what you'd expect from a stochastic parrot, even as the models get "smarter".

The massive training data pools for more popular programming ecosystems make it too easy to fool yourself into believing that these things can reason. The unevenness of their performance tells you what hasn't actually "generalized".

Often see these glowing reviews.

Where's the code?

Good luck trying to debug the code you've generated without knowing anything about what it does.

They're all pattern recognizers. Do not overhype it, it's all they can do. THey have no brain.

>Honestly, I’m questioning why I’d need a designer in a year.

Idk my guy maybe you should sit down with them and ask them how they're using AI and if they aren't, maybe be cooperative and introduce them to it instead of getting a stiff one fantasizing about firing them.

This whole hype cycle has some serious arrogance and sociopathic undertones about unemploying a lot of technical people suddenly (like they had it coming or something).

Wake me up when Claude Max Ultra Xtreme Millennium Edition can make its own Claude for you, and that Claude is better than the one you are using.