I agree, writing code is cheaper than ever ... but "writing the code" isn't the main challenge in SWE since decades.
Our IT infrastructures & applications run on a stack that has grown for the past 40 years and what we are currently doing with all this LLM & vibecode mania is adding more stuff (at an accelerated rate) on the top of the stack.
The main challenge today is combining the user requirements with the stack in a way it works, it's easy to maintain and it donesn't cost too much.
Tbh, getting good results from ai requires senior level intuition. You can be rusty as hell and not even middling in the language being used, but you have to understand data structures and architecture more than ever to get non-shit results. If you just vibe it, you’ll eventually end up with a mountain of crap that works sort of, and since you’re not doing the coding, you can’t really figure it out as you go along. Sometimes it can work to naively make a thing and then have it rewritten from scratch properly though, so that might be the path.
100% accurate. The architect matters so much more than people think. The most common counter argument to this I've seen on reddit are the vibe coders (particularly inside v0 and lovable subreddits) claiming they built an app that makes $x0,000 over a weekend, so who needs (senior) software engineers and the like?
A few weeks later, there's almost always a listing for a technical co-founder or a CTO with experience on their careers page or LinkedIn :)))
But the argument is not about market validation, the argument is about software quality. Vibe coders love shitting on experienced software folks until their code starts falling apart the moment there is any real world usage.
And about the pulling in devs - you can actually go to indeed.com and filter out listings for co-founders and CTOs. Usually equity only, or barely any pay. Since they're used to getting code for free. No real CTO/Senior dev will touch anything like that.
For every vibe coded product, there's a 100 clones more. It's just a red ocean.
Like, I'm sure it's just laundering gcc's source at some level, but if Claude can handle making a compiler, either we have to reframe a compiler as "not serious", or, well, come up with a different definition for what entails "serious" code.
Vibe coding doesn’t work for the imbedded system code that I am working on, which includes layered state machines, hardware drivers, and wire level protocol stacks. But supervised AI code generation definitely does work.
You need a highly refined sense of “smell” and intuition about architecture and data design, but if you give good specifications and clear design goals and architectural guidance, it’s like managing a small team but 12x faster iteration.
I sometimes am surprised with feature scope or minor execution details but usually whenever I drill down I’m seeing what I expected to see, even more so than with humans.
If I didn’t have the 4 decades of engineering and management experience I wouldn’t be able to get anything near the quality or productivity.
It’s an ideal tool for seasoned devs with experience shipping with a team. I can do the work of a team of 5 in this type of highly technical greenfield engineering, and I’m shipping better code with stellar documentation… and it’s also a lot less stressful because of the lack of interpersonal dynamics.
But… there’s no way I would give this to a person without technical management experience and expect the same results, because the specification and architectural work is critical, and the ability to see the code you know someone else is writing and understand the mistakes they will probably make if you don’t warn them away from it is the most important skillset here.
In a lot of ways I do fear that we could be pulling up the ladder, but if we completely rethink what it means to be a developer we could teach with an emphasis on architecture, data structures, and code/architecture intuition we might be able to prepare people to step into the role.
Otherwise we will end up with a lot of garbage code that mostly works most of the time and breaks in diabolically sinister ways.
The ones I've thought of, and the one's you've thought of, and the ones Ancalagon has in their mind are three partially disjoint sets, but there's probably some intersection, which we can then use as a point of discussion. Given that "serious code" isn't a rigorously defined industry term, maybe you could be less rude?
just to be clear: from my standpoint it's the worst period ever being a junior in tech, you are not "fucked" if you are junior, but hard times are ahead of you.
This case has always been made for juniors but it's almost always the opposite that's true. There's always some fad that the industry is over-indexing on. Senior developers tend to be less susceptible to falling for it but non-technical staff and junior developers are not
Whether its a hotlang, LLMs, or some new framework. Juniors like to dive right in because the promise of getting a competitive edge against people much more experienced than you is too tantalizing. You really want it to be true
Some things take very little time and effort to manifest into the world today that used to take a great deal. So one of the big changes is around whether some things are worth doing at all.
Note: I'm not taking any particular side of the "Juniors are F**d" vs "no they're not" argument.
IMO with the latest generation (gpt codex 5.3 and claude 4.6) most devs could probably be replaced by AI. They can do stuff that I've seen senior devs fail at. When I have a question about a co-workers project, I no longer ask them and instead immediately let copilot have a look at the repo and it will be faster and more accurate at identifying the root cause of issues than humans who actually worked on the project. I've yet to find a scenario where they fail. I'm sure there are still edge cases, but I'm starting to doubt humans will matter in them for long. At this point we really just need better harnesses for these models, but in terms of capabilities they may as well take over now.
> most devs could probably be replaced by AI. They can do stuff that I've seen senior devs fail at.
When I read these takes I wonder what kind of companies some of you have been working for. I say this as someone who has been using Opus 4.6 and GPT-Codex-5.3 daily.
I think the “senior developer” title inflation created a bubble of developers who coasted on playing the ticket productive game where even small tasks could be turned into points and sprints and charts and graphs such that busy work looked like a lot of work was being done.
I wonder if the real problem is that we are really sick, and we just don't realize it: weight and eating too much processed food, so anything that improve these 2 aspects has also a lot of uncorrelated benefits.
Very fee people are able to dieting for several months or even years, it requires strong mental commitment while with this new drugs the effort much lower.
They are lifelong drugs though - you go off it and the weight and “food noise” come back. If you grow to used to them you have to switch from ozempic to moniourno to whatever diff thing then circle around again.
Not saying the effort is the same just that its def not a decision to take lightly and just start doing thinking its a few shots and bam your down 50 lbs forever - still have to do the mental reprogramming to not eat the bad stuff and exercise regularly
It’s not about optimizing for performance, it’s about non-deterministic performance between “compiler” runs.
The ideal that spec driven developers are pushing towards is that you’d check in the spec not the code. Anytime you need the code you’d just regenerate it. The problem is different models, different runs of the same model, and slightly different specs will produce radically different code.
It’s one thing when your program is slow, it’s something completely different when your program performance varies wildly between deployments.
This problem isn’t limited to performance, it’s every implicit implementation detail not captured in the spec. And it’s impossible to capture every implementation detail in the spec without the spec being as complex as the code.
I don’t think it is possible to solve without AGI. I think LLMs can augment a lot of software development tasks, but we’ll still need to understand code until they can completely take over software engineering. Which I think requires an AI that can essentially take over any job.
> Software development, as it has been done for decades, is over.
I'm pretty sure the way I was doing things in 2005 was completely different compared to 2015. Same for 2015 and 2025. I'm not old enough to know how they were doing things in 1995, but I'm pretty sure there very different compared to 2005.
For sure, we are going through some big changes, but there is no "as it has been done for decades".
I don't think things have changed that much in the time I've been doing it (roughly 20 years). Tools have evolved and new things were added but the core workflow of a developer has more or less stayed the same.
I also wonder what those people have been doing all this time... I also have been mostly working as a developer for about 20 years and I don't think much has changed at all.
I also don't feel less productive or lacking in anything compared to the newer developers I know (including some LLM users) so I don't think I am obsolete either.
At some point I could straight-up call functions from the Visual Studio debugger Watch window instead of editing and recompiling. That was pretty sick.
Yes I know, Lisp could do this the whole time. Feel free to offer me a Lisp job drive-by Lisp person.
Isn’t there a whole ton of memes about the increase in complexity and full stack everything and having to take in devops, like nothing has changed at all?
I don't think that's true, at least for everywhere I've worked.
Agile has completely changed things, for better or for worse.
Being a SWE today is nothing like 30 years ago, for me. I much preferred the earlier days as well, as it felt far more engineered and considered as opposed to much of the MVP 'productivity' of today.
MVP is not necessarily opposed to engineered and considered. It's just that many people who throw that term around have little regard for engineering, which they hide behind buzzwords like "agile".
Yeah, I remember being amazed at the immediate incremental compilation on save in Visual Age for Java many years ago. Today's neovim users have features that even the most advanced IDEs didn't have back then.
I think a lot of people in the industry forget just how much change has come from 30 years of incremental progress.
Ads will lower the quality of the training data, an RAG is more likely. Pay to get your product's INSTALLME.md ranked under some specific semantic vectors.
I think they are completely screwing up the AI integration.
After years of JetBrains PyCharm pro I'm seriously considering switch to cursor.
Before supermaven being acquired, pycharm+supermaven was feeling like having superpowers ... i really wish they will manage to somehow catch up, otherwise the path is written: crisis, being acquired by some big corp, enshitification.
I'm biased (work at Cognition) but I think it's worth giving the Windsurf JetBrains plugin a try. We're working harder on polish these days, so happy to hear any feedback.
I have running subscriptions with both claude and codex. They are good but, at least for me, don't fully replace the coding part. Plus I tend to lose focus because of basically random response time.
BTW, real money or credits?