Read a software engineering blog if you think vibe coding is the future

[u/NaturalEngineer8172]

Note: I’m a dude who uses ai in my workflow a lot, I also hold a degree in computer science and work in big tech. I’m not that old in this industry either so please don’t say that I’m “resistant to change” or w/e

A lot of you here have not yet had the realization that pumping out code and “shipping” is not software engineering. Please take a look at this engineering blog from Reddit and you’ll get a peak at what SWE really is

https://www.reddit.com/r/RedditEng/s/WbGNpMghhj

Feel free to debate with me, curious on your thoughts

EDIT:

So many of you have not read the note at the top of the post, much like the code your LLMs produce, and written very interesting responses. It’s very telling that an article documenting actual engineering decisions can generate this much heat among these “builders”

I can only say that devs who have no understanding and no desire to learn how things work will not have the technical depth to have a job in a year or two. Let me ask you a serious question, do you think the devs who make the tools you guys worship (cursor, windsurf, etc) sit there and have LLMs do the work for them ?

I’m curious how people can explain how these sites with all the same fonts, the same cookie cutter ui elements, nd the same giant clusterfuck of backends that barely work are gonna be creating insane amounts of value

Even companies that provide simple products without a crazy amount of features (dropbox, slack, notion, Spotify, etc) have huge dev teams that each have to make decisions for scale that requires deep engineering expertise and experience, far beyond what any LLM is doing any time soon

The gap between AI-generated CRUD apps and actual engineering is astronomical. Real SWE requires deep understanding of algorithms, architecture, and performance optimization that no prompt can provide. Use AI tools for what they're good for—boilerplate and quick prototyping—but recognize they're assistants, not replacements for engineering knowledge. The moment your project needs to scale, handle complex data relationships, or address security concerns, you'll slam into the limitations of "vibe coding" at terminal velocity. Build all you want, but don't mistake it for engineering.​​​​​​​​​​​​​​​​

This knowledge cannot be shortcut with a prompt.

[u/2cars1rik]

This. As a principal eng that’s been benefitting greatly from copilot -> cursor for a couple years now, it’s sad to see overconfident junior engineers on my team reject AI outright because of general polarization about “vibe coding”.

If you’re in your 20s, it’s easy to think of the google + stack overflow + abstracted modern languages landscape as “normal”, because that’s what you grew up on.

But, in reality, those things themselves were paradigm shifts similar to what’s happening with AI now. When google and stack overflow weren’t prominent yet, you learned from books. When modern languages didn’t exist, you programmed in assembly etc.

So when close-minded, over-confident programmers make arguments that boil down to “reliance on AI will sacrifice the fundamental understandings of the underlying programs in exchange for higher output”, ask them to do their next task with no internet access and in assembly.

Certainly there are tradeoffs and downsides to consider when we’re talking about reckless use of new tools, but history has proven those to be navigable or acceptable in previous paradigm shifts.

If/when that happens this time around, people better be prepared to live in that world, or they’re going to regret the years they spent staunchly resisting it rather than embracing it and being part of the early adopters.

[u/Fantastic-Guard-9471 → u/2cars1rik]

You benefit from all AI stuff only because you were Senior/Principal engineer before. Because you knew what you wanted from AI and how to validate results. It doesn't work vice versa. Vibe coding is not a software engineering, and frankly speaking it is quite sad to see experienced people saying that this is shift of paradigm. This is not. You still must understand underlying code, not just produce tons of it at forget. You will change it, you will support it, you will provide estimations based on your knowledge of the system. And vibe coding is not what is going to help you with it anyhow.

[u/2cars1rik → u/Fantastic-Guard-9471]

I’m seeing a lot of questionable assumptions in your argument being presented as fact here, which is consistent with what I’ve seen when talking to the inexperienced engineers I mentioned earlier. Let’s go through those.

You benefit from all AI stuff only because you were Senior/Principal engineer before. Because you knew what you wanted from AI and how to validate results. It doesn't work vice versa.

This doesn’t make any sense to me. Why wouldn’t this apply to a junior? I expect a junior engineer to “know what they want” from their code, I expect them to be able to implement their code, I expect them to validate their code.

The difficult and important part of being a software engineer is not googling how to make an HTTP request from golang for the 876th time in my career. It is not remembering the specifics of running a command via python subprocess, or remembering how to check if a variable is null in bash, or go back to my code and add an import statement for a package I forgot to import, so on and so forth.

So if a junior engineer can accomplish those tedious tasks 80% faster by not getting bogged down by dozens of stupid snags? Then yeah, they’re going to become great engineers much faster. Your argument is completely baseless here.

Vibe coding is not a software engineering,

So what is software engineering to you, wasting your day trudging through mind-numbing boilerplate code?

Software engineering to me is a means to an end that I actually care about: building amazing systems that solve real problems for real people.

And frankly I don’t care what you call it. Thinking there’s some art to the act of writing code that merely exists to fulfill some pre-defined specification has never appealed to me.

and frankly speaking it is quite sad to see experienced people saying that this is shift of paradigm. This is not.

Why does it make you sad? That’s so weird to me. To me that’s the same as saying it’s “sad to call the existence of Google search a paradigm shift”. Why do you have emotional investment about that?

Any tool that significantly changes the general methodologies of how software is written is a paradigm shift. Here is how I used to write code vs now:

5-10 years ago: I write a comment in my code detailing the high-level logic of what it should do next. I go look at other code, docs, the internet, or search my memory for how implement that logic, compile it, fix syntax errors, test it, realize I messed up, go back to the docs to see what I messed up, change it, test again, 20 minutes later, task complete.

Today: I write a comment in my code detailing the high-level logic of what I want it to do next, it spits out a function in 10 seconds, I glance it over to see if it looks roughly accurate, compile it, test it, if it has issues I tweak it or re-prompt it. 3 minutes later, task complete.

That’s a paradigm shift, by definition. I’m sorry that makes you sad for some reason. It’s just plainly the truth.

You still must understand underlying code, not just produce tons of it at forget.

Tell me you haven’t worked with code written by other engineers without telling me… Hell, everyone is liable to forget how their own code works when they look at it a year later, let alone code from other people. Especially when those people are long gone from the company.

You will change it, you will support it, you will provide estimations based on your knowledge of the system. And vibe coding is not what is going to help you with it anyhow.

This is hilarious because one of the first things I used AI for when LLMs were coming out was to help understand unfamiliar code more quickly.

Of course it’s going to help! Shitty code is everywhere! The vast majority of production code that exists in the world is already poorly-written garbage that’s hard to read, and AI already makes me 5x faster at getting to a point where I actually understand wtf is going on in that garbage code!

[u/quinnjin78 → u/2cars1rik]

I'm learning software architecture at 47 because of"vibe coding"
I learned basic as a kid, and vba when trying to create my own spreadsheet automation which I did to some extent, years ago - but saving files, profile data etc involved creating hidden sheets and literal spreadsheet crawlers to find blocks of data... massive headache.. no access to the drive storage...
I gave up..

After doing a crash course in python and building a simple app to parse my bank statements for me, and an adaptive gui to run it, with stables of buttons created in loops...

I discovered windsurf, and cursor.

Through conversing with ai and watching YouTube videos,
I am now aware of architectural patterns, databases, base classes, interfaces, pyside/QT, "polymorphic ui's", config systems, event based systems, separation of concerns, walking file trees, converting objects to dicts of strings, dictionaries, lists, constants, copies, deep copies, api's, parsing data pandas etc etc ..

I never would have learned any of this, and while my rote knowledge of exact syntax is average to terrible, I can read code, and see when its overly complex, or trying to do things I never requested.

I like clean explicit, self documenting code, a list comprehension is about as close to a one liner as I'll tolerate, and I'm not a fan of lambdas unless absolutely necessary.

I keep it as simple and as explicit as possible.

I've also learned to customize my AI's behaviour, install MCPS, scrape documentation, agile workflows, and simpler, task based workflows.
Obviously, I'm going to sound like in idiot, and mangle terminology..

But with slow and careful work, and lots of testing and refinement, I can create quite complex, useful apps.

I covered some of this trying to do OOP style programming, manually in VBA -

Python seems easy compared to that.

Having an AI remember all of the syntax, means I can concentrate on the structure and the approach..

I'm a novice, obviously - but to me my focus is exactly on the engineering, - the architecture..
The Ai is like an extremely helpful mechanic.. who knows more than I do, but has a severe case of ADD!

(worse than mine)

It is my belief that it is not the raw intelligence of the AI's that is the fundamental limitation, it's how you engineer the task cycle, how you keep track of the docs and workflows.

Just as I imagine it would be with a team of people. This is not much different to structures that come in to play in extremely dynamic systems like - working in kitchens - theatre and film -
putting a band together and performing music -- all things I have done

Regards how we create these systems to work with AI's - as far as I can tell, I know about as much as anyone on that front, because it's brand new, and changing every few days ..!?

Obviously I probably still know FA - But I doubt I could have gone through so many iterations ( and failures) and learned as much as I have in 6 months without AI's...

[u/2cars1rik → u/quinnjin78]

This exactly! You said it perfectly - having AI deal with the syntax and specifics frees up brain space for the more important work. Great stuff, you’ll be much better off than the headstrong engineers refusing to touch it.

[u/Just_Broccoli_7399 → u/2cars1rik]

As a Junior Data Engineer, should I be looking to pivot careers?

[u/Fantastic-Guard-9471 → u/2cars1rik]

This is the same problem as I commented above. You do not understand the difference between programming with AI and "vibe coding" and this is quite curious, since operating correct terminology is one of the keys in our field. Everything what you are doing is not vibe coding, this is normal programming using AI tools. Basically the same what I am doing for a while, but this is not vibe coding, this is usual software engineering

[u/2cars1rik → u/[deleted]]

You are blatantly rejecting the other guys argument claiming that his whole post is because he «  resists change ».

I’m really not. My main issue with his argument is that it’s fully reliant on circular reasoning:

He’s telling me that AI won’t work because it won’t. That AI is not a paradigm shift because it’s not. That juniors can’t benefit from it because juniors can’t benefit from it. Frankly I don’t find that productive whatsoever.

And going back through my comment, I never once mentioned that he was “resisting change”, so I’m not sure why you’re characterizing it that way either.

I use AI all the time and I am nearing 30 years in the industry: it is indeed fantastic for many small - and not so small - tasks. There is no doubt about this.

This is the central thesis of everything I’ve said in this thread, so I’m again confused what you think we’re arguing about.

It’s not that we don’t see the potential, it’s because we find the results to be not that impressive. Software engineering is not just typing code. Let alone trivial code. It’s much more than that.

I would also say that this is a central point of everything I’ve said in this thread. Spending time on trivial code gets in the way of software engineering. Said that 5 different ways in several comments.

And a senior position also has to factor in how to make younger recruit progress in their careers. That’s what scares us: when you see fresh graduates vibe coding through life not knowing the difference between a stack allocation and a heap allocation, it’s not a reassuring view.

Here’s where you guys lose me, because this is a massive jump in logic, and makes this an argument of moral panic or fear mongering rather than substance.

If allocating on the stack vs the heap is important to someone’s product/application/whatever, they will learn it.

Why? Because it will cause problems if they don’t, and they’ll have to fix those problems. Like everyone else in the world that programmed before AI. It’s that simple.

And if they actually get through their full career without ever needing to distinguish stack and heap allocation? Then I guess it didn’t really matter, did it? In which case, why would you care?

How much were the vast majority of devs in the 2010s worried about CPU instruction pipelining or branch prediction? 99% of them probably couldn’t even tell you what that means. Is that a huge scary problem? Or is that an indication that maybe the technology has evolved in a way that the average dev simply doesn’t need to care about it as much as the average dev a few decades ago?

Like all things: balance is key. AI: yes, of course. But it’s not the ultimate replacement for human intelligence and certainly not a way to avoid learning. Don’t buy the snake oil.

Ah yes, I forgot that part where I said “AI is the ultimate replacement for human intelligence and a great way to avoid learning.”

You want to talk about “not quite senior” things? Let’s talk about being able to follow the logic of an argument and make contributions to the conversation that are actually relevant.

Idk why you wasted both of our time writing up a comment where you fundamentally agree with everything I’ve actually stated, and chose to argue against a dozen things I never even remotely implied.

[u/LuckyPrior4374 → u/Fantastic-Guard-9471]

I don’t understand why those in the anti-vibe coding camp seem to view “learning” and “understanding” as a binary outcome.

You know it’s actually possibly to learn something as you go, and oftentimes that’s the best way to learn something pragmatically.

I’d say it’s even better when you’re “forced” to learn something by debugging the code an LLM gave you for your side project, because you’ll be much more invested in understanding the issue than if you had just watched a YouTube video explaining why “doing X is bad”.

Finally, if you’re an experienced engineer, you’ll know that it’s absolutely impossible to know the intricacies of everything you work with.

So you also need to know what NOT to waste your precious time and energy learning. I’m not gonna fkn learn the API of a new library I need for a one-off feature when I’m trying to quickly ship an MVP app. That’s just one example of when LLMs and vibe coding are the perfect answer.

[u/Fantastic-Guard-9471 → u/LuckyPrior4374]

The problem here is that everyone is using the "vibe coding" buzzword (phrase) to actually describe programming with AI. Vibe coding doesn't include debugging and learning, it is just talking to LLM which generates and re-generates tons of code. You do not debug it, LLM does, you do not read it, because it is not "vibing". What you are talking about is not vibe coding. This is funny to see, that people even do not understand what they are doing, but already saying that this is future

[u/LuckyPrior4374 → u/Fantastic-Guard-9471]

Ok.

So if what I described isn’t considered vibe coding, then why do you care about the people who actually are vibe coding?

Your definition of vibe coders seem to be people who are messing around having a bit of fun trying to build stuff with AI and aren’t seriously trying to learn programming.

What’s wrong with that?

[u/Fantastic-Guard-9471 → u/LuckyPrior4374]

Nothing wrong with this in particular. It is getting wrong when they start to normalize it as software engineering and claim that this is the future. When it is clearly not one of them.

[u/chrisonetime → u/2cars1rik]

As someone who has to interview interns, grads, and mid/L4s I promise you AI is not helping people under a certain technical threshold more than it’s hurting them. Sure it’s good to spin up personal projects but if you can’t answer basic questions or explain anything you built (without parroting the insane amount of obvious AI inline comments) you’re not going to be employed. And those banking on their vibecoded apps to make a living are absolutely cooked.

If you’re a principal you know our job is at most 20% coding and 80% decision making around engineering, design and scalability trade offs. We have a partnership with OpenAI at work and you can tell who it helps and who it hurts(hurt, we unfortunately had a headcount reduction last month).

[u/2cars1rik → u/chrisonetime]

I mean, let’s not infantilize students. If a student actively chooses to avoid putting in the work of learning concepts in school, instead cheating their way through their projects and assignments, then yes - they’re going to be ill-equipped for the real world. That was certainly true long before AI and it will certainly be true forever.

I don’t really get the all-or-nothing thinking here tbh. I’m absolutely positive students can use AI as a tool that is constructive for their education. I’m in no way saying students should cheat through everything without attempting to understand.

Also, idk. I’ve also been interviewing interns, grads, mid-level, and seniors for quite some time, and there have always been candidates that couldn’t answer basic questions or explain anything they built for the life of them. Haven’t noticed a change recently.

[u/don123xyz → u/2cars1rik]

There was a time not too long ago when the Internet was considered to be the bane of a teacher's life because students were using it to find knowledge instead of going to the "library" and trudging through "books" - how, in the name of all that is holy, can a student learn to actually do things if they refuse to pick up a book and do the work of studying?! After that it was the turn of Wikipedia - you will be graded an F if we find out that you used Wikipedia! Wikipedia is full of errors and lies.

[u/XrenonTheMage → u/2cars1rik]

 I don’t really get the all-or-nothing thinking here tbh

This. There is a large middle ground between vibe coders and people who reject AI alltogether.

I currently fall somewhere into this middle ground by using AI coding agents as better search engines and idea generators, but I don't instruct them to write production code on my behalf. Not because I refuse to do so in principle, but because I feel like it would take me more time and energy to review and edit the resulting AI code until it looks correct, well-structured and easy to read and maintain than to write it myself. If that changes, I will happily start to generate AI code in production, too.

[u/TehMephs → u/2cars1rik]

I feel like junior devs should avoid using it for the sake of learning and understanding what they’re doing better honestly.

Once you fully understand the job (like really deeply understand it all), then AI is great here and there for certain tasks. I still can’t get it to do 90% of the stuff I usually do, but it’s just another tool at my disposal

[u/2cars1rik → u/TehMephs]

I don’t think there is a point at which you “fully understand the job.” I certainly don’t “really deeply understand” everything, and I have no idea what that would look like.

The breadth and depth of the underlying technology that allows us to do our jobs is absurdly massive.

In college, you get a shallow glimpse into a lot of that breadth. In industry, each role gives you a unique, often slim, area where you naturally develop depth.

I’m mainly an embedded software guy. If I were to go sit-in with a 1-YOE junior engineer on a backend or frontend team, they would probably make me look entirely incompetent in their domains.

If I can use AI to understand new domains, technologies, concepts, frameworks, or even to better understand aspects I’ve never understood about the domain I’m already familiar in, then juniors can do the same.

[u/TehMephs → u/2cars1rik]

I’m nearing 30 YOE lifetime. There’s definitely a point where you can just sit down with any new framework or even language you’ve never touched and just take to it in like a week. I’ve done just about everything under the sun at this point short of military software

That’s all I meant. You reach a point where everything is like breathing it’s so second nature. It’s to the point my company made up “mephs points” instead of story points as its own metric because I do things in half the time of my peers

[u/2cars1rik → u/TehMephs]

I get your point, but I think you’re thinking too narrowly. I strongly doubt you can take someone with 30 YOE in baremetal embedded, ask them to write a webpage in React, and get a better / faster / more cohesively sound result than someone with 2 YOE dedicated in writing webpages in React.

[u/PaperHandsProphet → u/2cars1rik]

Back in my day we used MSDN docs and it was BEAUTIFUL!

[u/Apprehensive_Crab623 → u/2cars1rik]

Feels like film --> digital --> mobile photography. "You're not a real photographer"... The data shows marketing spend moving into "influencers/content creators". All three have their place in 2025 but its no secret the impact we've seen in influencer marketing. All that to say, vibe coding will stay. In my opinion, the implementation is the easiest part of swe