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.