Let's Address the Elephant in the Room Again
Vibe coding has always been a weird topic to talk about. Lately it's gotten even weirder.
Say "vibe coding is a creative process, but it's not engineering" and people get defensive immediately, calling you a gatekeeper and all those interesting terms.
So I decided to write this brief article to answer those opinions in a short and precise manner, without too much sugarcoating or dancing around.
Engineering is Part of Creation
There's a real difference between the two. Creation is much broader term. engineering is part of the creation process. It's also part of maintenance, debugging, refactoring, and most of what engineers actually spend their days doing.
So the question worth asking is: during the creation process, who does the engineering? You? Your coding agent? Both of you?
Definitions Matter Here, Critically
Vibe Coding
You write a prompt and hand it to the AI. You don't edit the code and you don't review it. You might not know the first thing about programming and still ship something.
AI-Assisting
AI-generated, human-reviewed. The AI writes all of it, you read all of it. THIS IS NOT VIBE CODING, it takes enough skill to tell good code from bad.
AI-assisted
You and the AI write the code together, and you're the one driving. AI gives you speed, a second opinion, and the edge cases you'd have missed. ALSO NOT VIBE CODING.
Where This is Going
The trend is toward more semantics and more abstraction. It's been that way since assembly. Vibe coding is the next step on that line, and it will keep taking over more of the work. Maybe one day the job is 95% writing prompts, and to be honest, I'll welcome it, that makes my life easier too.
But the question right now is whether we're ready to build financial systems, health apps, and anything else touching sensitive data without analyzing the code.
We're not. Doing it anyway to prove your point will cause absolute chaos.
The line I'd draw:
Building something for yourself, for fun? Vibe code all of it. It's genuinely a good time.
Building something real, something that processes people's personal data, handles money, and turns a profit and vibe coding it from start to finish? That tells me one of three things:
You're not willing to spend two to four weeks learning the absolute basics of coding, security, and best practices.
You don't care about the quality of your own product, and ultimately other people's personal data and security.
You're not curious about how any of it works under the hood. And if you're calling yourself an engineer, you should be eager to understand the mechanics of software engineering and coding.
All three happen constantly now, and that's the sad part.
What I Actually Do?
I've been a software engineer for ten years. Even so, when I need to build something in a language I'm not fluent in, I still spend a day or two on the language reference, the docs, the basic mechanics, enough that I can understand what the AI produces.
Then I review everything it generates and ask so many follow-up questions that I probably spend more tokens interrogating the code than creating the project.
Every strong engineer I know works this way. We use AI extensively, every single day. We also take everything it gives us with a grain of salt.
So what's stopping you from doing the same?
We'll get to the point where you can let go of the steering wheel. We're not there yet. Keep holding the wheel to make sure you don't go off the road.
Enjoyed this write-up? Let's stay connected!
I share more software engineering insights, projects, and experiments across these platforms:
Top comments (173)
We’re getting nitpicky with the namings 😄 I’d argue that even before AI, the code wasn’t necessarily great.
So my unpopular opinion is that this doesn't matter. Most of us got some kind of computer science degree, some of us continued to a Master degree in computer engineering, and we still don't know what this engineering is. In today's market the "Software engineering" term is kinda skewed, because we don't understand and we don't build computing systems from the hardware to software but operating in way higher levels.
I think what really matters here are two things: how much you care about the outcome, and how curious you are about what you’re doing.
In my experience so far, vibe coders either lie on the "care but not curious" or "not care and not curious". They either are very excited to bring their idea in life and at the end if prompting doesn't work they will try to find someone to help them. OR they vibed code an app that they think they will make them millionaires in a day.
So I don't think AI fundamentally changed the behaviour by "enabling" vibe coders. I have seen in my jobs over the year countless people that they simple didn't care. They don't want to learn and they don't care about producing good results, they are fine with the "okay". I guess more and more people go to the "don't care category" due to burnout, or this insane pace, or their responsibilities become x10 or the lack of trust in companies or the impeding layoffs everywhere or...
Gosh, that was a long answer with many thoughts, so sorry 😅
Wow, that's such insightful and detailed feedback. Love to see it.
You're spot on about the different combinations of curiosity and care. I'd just add that without care, curiosity doesn't go very far. You might poke at something once, but the kind of curiosity that makes you dig deeper and actually learn comes from caring about the outcome.
As for the engineering part, I'd disagree that the term "engineer" is skewed.
The title isn't reserved for people who build everything from bare metal. A transmission engineer at Ford doesn't design the whole car, yet nobody questions the title. (Fun fact: in North America, even train drivers are officially called locomotive engineers.)
What makes something engineering is the nature of the work: knowing which components go into the build, understanding how they fit together, and balancing countless variables and trade-offs along the way. Performance, cost, reliability, maintainability, all while the system keeps changing under your feet.
Software creation demands exactly that. If this isn't engineering, I don't know what is.
Thanks for the amazing comment!⭐️
I agree, curiosity is induced with care, but sometimes a person might not have time or the possibility to learn everything. I think if you care enough you probably at some point will try to understand though!
Fun fact, in my language engineering means: the one who builds machinery. Very few universities have the word engineer in their title of their programs, Its either computer science or Informatics. But this is beside the point. I get your point, but I still find things like 'AI engineers' silly. I think all those thing you mentioned comes (or came) with time and effort.
I guess we are going to very philosophical territories when we are wondering if we are engineers, or scientists. To be honest, I don't feel I am either of these, I just like to make useful things, so I guess am a maker!
Unpopular opinion. Software has never been engineering, frankly it never met the standards, and to call it that is an insult to actual engineers "move fast and break things" would land you in prison, in engineering you get very litte room for error and are accountable for the outcome. While some individuals certainly meet the bar it would be a stretch extend that to the indistry at large.
I wouldn't agree on that one. By nature software programming is engineering. You take separate components and make them work together efficiently to get some result. That's pretty much what engineers do.
That definition is much too broad. A child combining LEGO pieces also takes separate components and makes them work together toward a result; that alone does not make the activity engineering.
Engineering is not merely assembly. It means working against explicit constraints: efficiency, safety margins, resource consumption, failure modes, verification, maintainability, environmental cost, and ultimately accountability for the consequences of the design.
And on efficiency, modern software is difficult to defend. A single CPU core can execute operations on nanosecond timescales, yet enormous parts of the industry have responded to inefficiency by adding abstraction layers and throwing more compute at the problem. We now operate hyperscale data centres consuming extraordinary quantities of electricity and water partly because computational resources became cheaper than disciplined optimisation.
Software can be engineered. My objection is to assuming that software development is engineering merely because components have been connected and the resulting system happens to work.
That definition wasn't complete, sure.
But your definition of engineering is exactly what software engineers do pretty much every single day.
The distinction is whether the system has an explicit operating envelope, quantified resource and performance bounds, defined interface and failure contracts, documented assumptions, system-level failure analysis, verification traceability, recovery behaviour, configuration control, provenance, and residual-risk documentation.
If that is normal practice in the software you work on, then I would absolutely call that software engineering.
My point is only that this level of assurance is not typical across the software industry. APIs, unit tests, CI and production monitoring are valuable, but they are not the same thing as a defined operating envelope and an evidence-backed assurance case.
Most of the big enterprises use the same approach that you mentioned, otherwise their code and product will just become unsafe, unmanageable, and messy.
You can write code without any of that, of course. You can also build a car from scrapyard parts instead of engineering one. Both will move. Only one is something you'd want to drive.
Wrong. Programming is an act of implementation. Engineers dont implement, we are too expensive for that, we plan and let contractors build it... yes, including programmers. The term developer is only used in web tech, to develop products under agile, no one develops safety interlock software for nuclear reactors, we engineer and implement or program it
Why are computer science and IT guys trying to define engineering? Why dont you just ask people with actual ABET accredited software engineering degrees... you guys sound like Dr. Phil trying to explain open heart surgery.
I think what you're describing is an architect, not an engineer. Architects plan most of the system, and engineers then write software that fits that architecture efficiently. Software also needs engineering, and you can't diagram every project, file, function structure, call sequence, and so on. At some point you have to write it. Whether you write it by hand or with AI is a different conversation.
Love your differentiation between AI Assisting and AI Assisted! 🥰
AI Assisting needs better naming though.
"Assisting" and "Assisted" are too closely resembling words to be recognized at first sight, and one can easily be confused by the other if the naming gets popular.
I'd rather name it like:
Having said that, none of it is Software Engineering unless proper software engineering practices are actually followed, whether by a human or by AI.
Yeah, I'm actually looking for better naming, these two are pretty easy to mix up, especially when they're so close in meaning.
"AI generated (reviewed)" is a longer name but more descriptive. Thanks for the suggestion.
We can also just call it: vibe engineering 😊
So, we’ll have:
😁
I think that could work, but there's still "vibe" in there, yikes. 😆
LOL, I guess devs deserve it if they generate everything from the beginning and they try to review it later as an after thought.
Most of the times, even with frontier models, it's very difficult to produce well engineered software that way.
Haha, good point!
Please, stop. If you want to learn engineering, read about it, dont try to reinvent it and claim credit for a twisted mutated monster. Please, go ask chatGPT what is engineering.
If you truly want to learn engineering, reading about it won't help you. You need to practice it. A lot.
I think there’s another layer beyond reviewing whether the generated code is good: verifying whether the system actually behaves correctly under real conditions. At IT Path Solutions, we’ve seen that understanding AI-generated code is only one part of the engineering responsibility. A developer can follow every line and still miss a race condition, incorrect permission boundary, poor failure recovery, or an assumption that breaks with real data. As AI takes over more implementation work, engineering may increasingly shift from inspecting how something was built to proving that the resulting system behaves as intended. That makes verification and observability just as important as reviewing the generated code itself.
The limitation of software engineering was never code, it was and has always been comprehension.
Thats for you the planner or AI the implementer, both are true.
For real Software Engineers, AI hasn't changed so much in the end, I hand my instructions to AI instead of programmers and electricians now. Checking and drafting hasnt changed, plus another ai review loop or 2 as added benefit, but thats it... before it was a human.
If my name is on code, I can be legally held accountable for it... thats what it means to be a doctor, lawyer or engineer under the United States law... so vibe away, agile all you want, but don't pretend your engineers any longer.
Agreed!
Absolutely, there so many other things that go into creating a product and a system behind all that. It's tricky even if you have 10+ years of experience, let alone when you don't know the first thing about programming.
Really liked this distinction, Giorgi. I think the important boundary is not actually “how much code did the AI write?”, but who still owns the engineering reasoning behind the result. 🔍
An AI could generate 95% of a system and I would still call the process engineering if someone can explain the architecture, identify the assumptions, reason about the failure modes, review the security boundaries, and produce evidence that the important properties actually hold.
The opposite is also true. A human can manually type every line and still produce something without much engineering behind it.
So for me the useful question becomes:
Who wrote the code? matters less than
Who can explain why this design is correct, how it can fail, and how we verified it?
That is also why I like your distinction between AI-generated and human-reviewed work versus pure vibe coding. Review should not just mean “I looked at the diff”. It should mean retaining enough understanding to challenge what the model produced.
I use AI heavily myself, but I have recently started separating building mode from learning mode for exactly this reason. In building mode I want the acceleration. In learning mode I deliberately bring some friction back so I can still reconstruct the reasoning without the model doing it for me.
I think abstraction will keep increasing, just as you said. The dangerous part is not abstraction itself. It is losing understanding while still assuming we own the result. 🔐🧠
What a great, insightful comment! You're absolutely right about the "how much code did the AI write?" question. The better question is "who's doing the engineering?" Even if you don't write a single line yourself, you're still engineering, because typing code is only a small part of the process. In fact, if you can engineer a system without writing any a single line by hand, that arguably makes you an even better engineer, because you're more efficient that way.
I also love the two modes you mentioned: building and learning. I've never made that distinction when working with AI. I just talk to it however the moment calls for. I think I'll borrow your idea and try it out myself!
Hi @georgekobaidze great breakdown here. The nexus between creating, debugging, refactoring and maintaining is an important distinction to parse out = engineering. I see it from the creation side as a vibecoder. My builds aren't meant to last or to become hardened SaaS but if they ever do evolve I'll be thinking about these other areas and considering them.
To be fair, I also vibe coded a few times, but that was only for outlining the concept. Once I found the right concept, I started building from scratch.
Vibe coding is brilliant for demos and early concepts.
I think this reframe we're talking about is important, the distinction between demos, MVPS and early concepts as opposed to hardened production software. The fast sprint builds that I enjoy so much only touch a very small part of the engineering portion of it. PRD, Architecture, agents.md. Not really anything about maintaining, refactoring or debugging...yet! :-)
Totally true! A few months ago, I wrote about this topic, discussing if people like project managers can use vibe coding to communicate with developers more clearly. The more I think of it, the more I like that idea.
The useful boundary for me is not who typed the code, but who owns the acceptance evidence. For an agent-assisted change, I want a short contract before implementation: invariants, permitted side effects, failure behavior, and the checks that can falsify the result. Then I review the diff and run tests that exercise the tool boundary, not only the happy path. That keeps the speed benefit of delegation without treating a plausible demo as proof that the system is engineered.
Completely agree. Typing can be done on either side, it's just technical part.
Software engineering is a whole lot broader topic than just writing code.
This is so true. While I appreciate everyone using AI tools to build and really support the movement from being a "Technical" and "Non-Technical" audience to a mass of "Software Creators", people need to realise that knowing what is going on under the hood of your app is an art and a skill.
I see the vibe coding culture ruining hackathons and competitions where people build stuff in 5 hours and call it a day, and they do not seem to know/care what is going on under the hood of their application. If you do not exit an engineering project knowing more than when you started it, you did it wrong.
As far as I know there are hackathons that evaluate not only the “what” part, but also the “how” part. But they are pretty rare.
Yes, I believe that to tackle this, a lot has to get changes with Hackathons. While we want to encourage hackers to use AI and give more exposure to its capabilities, we also need to make sure that Judges and the organisers are judging the hackers in a way that helps them understand better, and not just compare who has more Claude credits.
Yeah, there should be some sort of a compromise between the two. But the tricky part is, how you evaluate all this. It’s going to make the evaluation process even more complex.
The distinction is important because a code review is only one layer of engineering. A generated implementation can look clean and still be wrong at the system level if the deployment, data handling, permissions, backups, or operating assumptions were never verified.
Absolutely. Thanks for pointing that out. I wanted to make the post as brief as possible, so I skipped that part not drift away from the main point but I'm glad you mentioned it here.
Totally fair. Keeping the main point tight was probably the right call. I liked the post, and the comments are a good place to add the extra pieces anyway.
That’s pretty much the point!💡💯
The three tiers are right and the word is still wrong. At ML Systems we do not say vibe coding for what I do. The role is Language Modeler. I am modeling the system in language: what it is, who may write to it, what counts as true. The AI is a moderator between the English language and the coding language. It carries the model across; it does not own either side.
That reframing settles the accountability thread above. A moderator between two languages is never the author of record. If the English was wrong, the Language Modeler owns it. If the translation was wrong, review catches it, or the Modeler owns that too. Nobody gets to say the AI did it.
It also answers what the person has to know. Not every line of the target language, but enough to read the translation and enough to write the source precisely: the constraints, the invariants, who is allowed to say what. That is most of engineering anyway. In our case the model is a house record that seven AI agents write to: every value enters as a claim with an evidence grade, and only a person stamps. I spent two years as an estimator and years as a carpenter before this. The vocabulary I model in is the building's, not the language's. The AI moderates the rest.
Vibe describes a mood. Modeling describes work.
That’s really interesting.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.