Dev jobs are about to get a hard reset and nobody's ready
old.reddit.com
old.reddit.com
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.
Switching libraries/frameworks or switching piecemeal to a new language for a codebase that's already well structured seems like it would be noticeably less costly though.
Replacing something with something else isn't a refactor to me, a refactor implies a structural change not a wide surface level change.
IME so far that's what it's best at. As long as there exists tests in the codebase that provide enough of the basic skeleton (i.e. if they already test part of a controller or code that interacts with a DB) to guess what's needed then it can do a decent job. It's still not perfect though and when it comes to inventing bespoke tests that are uniquely different from other tests it needs much more of a helping hand.
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)
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.
And you have to be vigilant, too. You can spend a day or two in full vibe code mode if you really want to ship a bunch of features fast, and they'll all work and it will feel amazing, all while it's secretly shitting all over your codebase, and you won't know it until it's too late. And not in a "oh now you just have to fix it up" way - if you go too long it may be just about as difficult to fix as it would have been to write.
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.That doesn’t mean you can’t churn out all the surface accoutrements of an app (and some of the dull back-end stuff like user databases, etc.) faster—-but it is very far from replacing someone with system design skills in the long run.
I honestly think we’re being played.
(Or at the extreme end, this is what something like C++ templates were for).
This is not the first time the industry has been down this road. They're not in themselves bad tools but their hype engenders a lot of overconfidence in non-technical users.
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.
Fwiw, I use Claude Pro in my own side project. When it’s great, I think it’s a miracle. But when it hits a problem it’s a moron.
Recently I was fascinated to see it (a) integrate swagger into a golang project in two minutes with full docs added for my api endpoints, and then (b) spend 90 minutes unable to figure out that it couldn’t align a circle to the edge of a canvas because it was moving the circle in increments of 20px and the canvas was 150px wide.
Where it’s good it’s a very good tool, where it’s bad it’s very bad indeed.
Supposing this is true, who is playing us and why?
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.
I've got colleagues desperate to be seen as on board with all the AI experiments and they just write things like "tool X is MILES better than tool Y". Leadership laps it up
They never provide any evidence.
> 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.
Reviewed by a bot (that wrote it no less) is not reviewed. This person is not a software engineer.
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.
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.
These tools love to just write new code, they hate refactoring or maintaining code which is what this job actually is.
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.
> "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...
More recently, as I've gained trust in the process, I've also started more and more asking it to manage "subagents" to do some of the lower-level work, and it's been a very valuable power multiplier too, allowing for additional parallelism, without growing the main agent's context.
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?
Way to go killing credibility straight out the gate. I could buy a high percentage for certain types of apps, but not 100%
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.
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.
> 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 hope AI will force this shift to occur. Once the juniors stop thinking that they know everything, stop seeing themselves as coders and start seeing themselves as 'vibe coders'; they may be more inclined to rely on senior devs to evaluate 'their' code and to fill in the gaps.
Part of the issue before was that juniors who could churn out code at a rapid rate, didn't want to take advice from dinosaurs. I understand this very well because I was on the other side of the fence as a highly sought-after junior dev back in the day. I myself didn't see the value of senior devs back then.
Part of the issue is that it takes a long time/effort even to be a junior dev and so by the time junior devs can write any apps at all and they've read a couple of 'Software design patterns' books (sigh...), they think they're geniuses and don't need to take advice from anyone.
I see the same. My conclusion is a lot of people who'd be doing these marketing, analysts and many other low paying jobs where one needs to appear slick have now joined computer/IT due to hig pay in considerable numbers and to the point they hold positions of technical director etc.
At least in my experience I find this push for micro services, async, reactive, cloud, kubernetes, kafka which are part of "we are going state of the art" narrative is just to appear slick.
I can second this. If your stuff runs fine on a VM and provides more in value than it costs to support, then there’s no reason to move unless those technologies provide demonstrable/tangible value above and beyond their costs.
As for both of your comments, I’m also admittedly taking a swing for the fences here based on my read of the environment. A lot of metaphorical checks were written with the intent AI will pay them in full (or whatever the next fad is), but at some point the proverbial bill always comes due.
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.
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.
Oh ya and you're betting your job on that it didnt write activate_skynet()? You still need to fully understand what it wrote.
>The idea of a “Python dev” or “React dev” is outdated. Going forward, I won’t be hiring for languages, I’ll hire devs who can solve problems, no matter the stack. The language barrier is completely gone.
"hiring" people havent gone on language in decades. Implying some bad things about OP.
>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.
Python > *
>Design as a job? Hanging by a thread. Figma Make (still in beta!) is already doing brand identity, UI, and beautiful production-ready site, powered by Claude Sonnet/Opus. Honestly, I’m questioning why I’d need a designer in a year.
Yes, you should get rid of your designers. Other places will gladly hire them.
>A few months ago, $40/month for Cursor felt expensive. Now I’m paying $200/month for Claude Max and it feels dirt cheap. I’d happily pay $500 at its current capabilities. Opus 5 might just break the damn ceiling.
Pycharm pro for the win as well. Choice of tool is dynamic.
>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.
fully reviewed by who? As in Ubuntu's launchpad? that has essentially no reviewing? A huge code dump or big bang pr? Isnt that what nobody wants?
You touch on the real boon, the gap between closed source for $ and open source free work just greatly decreased.
>Productivity has sky rocketed. People are doing things which before took months to do within a week. FUTURE GENERATION WILL HAVE HIGHER PRODUCTIVITY INGRAINED AS A EVOLUTIONARY TRAIT IN THEM.
Scotty: Let's prompt GPT-69 to fix this problem we have.
Where's the code?
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".
That just doesn’t add up for me, if he’s serious about the last two parts.
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.
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).
What I do find helpful is use it to ask for suggestions for how to achieve some result, then learn from the code it gives me.
But even then, going back to this code later is difficult because I didn't go through that period of the failure research success learning loop.
But regardless, on a large project, you're always going to have some version of this problem. At least when you yourself are getting in there and writing and understand the code, you have a half-decent shot at debugging in a reasonable period of time. When even you are vibe coding your additions to the pile, you're all the way back at square one when shit hits the fan, trying to learn it all from scratch.