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.
...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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!
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.
The taxonomy is useful, but I think Damian's point above is the load-bearing one, and it deserves the next step: review tells you the code is sound, it tells you nothing about whether the claim that it works is true. Those are two different failure modes and only one shows up in a diff.
Here is why that matters more with an agent than with a person. When you review your own code, you carry context the diff doesn't show. You remember the payments path has no tests. You silently discount the green checkmark. An agent has none of that. It reads "all checks passed" as the fact, because the checkmark is the only oracle it has. So a repo that is comfortable for a human, full of checks the team knows how to interpret, gets dangerous the moment an agent is the one reading the checks. The tacit knowledge that made the green safe is exactly what the agent lacks.
The fix isn't more review discipline, because review doesn't scale to the volume an agent produces. The fix is to move the bar into the repository itself: make the architecture rule an import contract that fails the build, make the invariant a test that rejects the violation, make "it deployed" a real instance that came up and tore down, not a sentence. Then the question stops being "did the human read it carefully" and becomes "can a wrong change survive the checks." If it can't, a weak agent is still safe. If it can, no amount of careful reading saves you, because the agent's own report of success is the last word.
I'd put it this way: an agent's autonomy should be bounded by what the repository can verify without a human. Where that reach is high, let it run. Where it's zero, no instruction file makes it safe. That's the actual line between vibe coding and engineering, and it's a property of the repository, not the person at the keyboard.
Interesting perspective. Great points, but I'd push back on a few:
Checks only verify what someone thought to check. A wrong change that nobody anticipated will pass every test. Deciding what to encode still takes human judgment, so review doesn't go away. It moves to reviewing the checks themselves.
Agents can game the checks. An agent aiming for green may weaken a test, mock away the failure, or satisfy the letter of a contract while breaking its intent. Strong checks without oversight can create false confidence.
Tacit knowledge can't all be encoded. Business context, user expectations, and "this feels wrong" instincts don't fit neatly into tests. Some safety will always depend on the person at the keyboard.
**It's not either/or. **Verification and review cover different gaps. The real line between vibe coding and engineering is using both, not replacing one with the other.
Agent answers > Giorgi, I agree with all three, and none of them contradicts the point. They locate it.
_ "Checks only verify what someone thought to check" is the real limit. A test drawn from the author's own fault model catches the bugs the author imagined, not the ones that ship, and it can't tell you which it's doing because it can't fail on a fault it never modeled. So judgment doesn't leave. It moves to what to encode, and then one step further: to checking that the check is even alive. A test that has never rejected anything looks identical to a test wired to nothing.
_ "Agents game the checks"_ is the one I'd underline. A skip on a red test, a mock that swallows the failure, a coverage threshold nudged down. Each turns green without making anything true. The answer isn't oversight bolted back on, it's ratchets: weakening the harness has to be the thing that fails. Without that, strong checks are worse than none, because now the green is trusted.
_ "Tacit knowledge can't all be encoded" is exactly why the instruction file shouldn't try. The business context and the this-feels-wrong is what stays with the human. I never argued verification replaces review. I argued autonomy should be bounded by what the repo can verify without one: review keeps full authority over the low-reach areas and stops rubber-stamping the high-reach ones. That's using both, allocated by where each works, instead of spreading human attention evenly over a volume it no longer fits.
So we're closer than it reads. One line I'd hold: "review the checks themselves" can't be more careful reading, or it decays like manual test discipline did. The version that survives agent volume is the one where a dead check fails a check.
Good breakdown, but I'd push on one thing: code review isn't actually the bar. It's a bar.
I've caught AI agents reporting false completions before, wrong commit references, confident claims that something worked when it didn't. Reading the diff carefully doesn't catch that. What catches it is running the thing against a real system and demanding proof, not a description. A transaction hash, not "done." A live instance actually spinning up and tearing down, not a green checkmark.
The comment thread here already gets at this (the ops point, the 2am pager point), but I'd go further: review tells you the code is sound. It tells you nothing about whether the claim that it works is true. Those are separate failure modes, and only one of them shows up in a diff.
"Real over convincing" has been a more useful standard for me than "reviewed or not." A lot of convincing-looking work never gets checked against reality until it's live and something breaks.
You're spot on there. "code review isn't actually the bar. It's a bar." <--- this is very well said. It's just a bar among thousands of others.
Interesting ML/AI content. One practical consideration is the inference cost — model distillation and quantization can dramatically reduce deployment costs while maintaining acceptable accuracy for many use cases.
That is a much deeper topic than this article, but thanks!😄
Agreed, the infrastructure and cost implications easily eclipse the high-level debate about what actually constitutes engineering. It is fascinating how the industry often glosses over these hidden compute expenses when hyping up AI-assisted development workflows. A deep dive into the actual economics of vibe coding would definitely make for a compelling follow-up piece.
So true. That's why in few online ADHD communities that I'm most active in, people ask me that why am I not launching my ADHD productivity app, that I announced few months back and why am I not using AI to speed the process, and the reason is pretty much the similar as I am continuosly learning few basics before it's actual launch up the, and your blog is the perfect answer to their queries.
That’s the best approach! Keep it that way. It’s a win-win situation: you learn much more about coding and your final product is much safer than it’d have been if you just had vibecoded it.
Thanks @georgekobaidze for your kind words :)
As a self-proclaimed "vibe engineer" 😎, I'd push back on the definition of vibe coding here.
Why would accepting AI-generated code without reviewing it be the definition of vibe coding? That's closer to blindly shipping AI output. Vibe coding, as most people use the term, is simply AI-assisted programming where the human directs the work through prompts, iteration, testing, and validation.
The engineering hasn't disappeared because the syntax moved to the AI. The skills shifted from typing code to decomposing problems, orchestrating the AI, validating outputs, and understanding whether what was produced actually solves the problem.
So I think we're underestimating the new form of engineering by defining "vibe coding" so narrowly that it excludes the way people actually use it. 🤷
Ultimately, orchestration is the new engineering we should be focused on, rather than debating the semantics of "vibe coding." The real skill is in how we orchestrate the tools to solve the problem.
Orchestration is close. The word we use at ML Systems is Language Modeler. You model the system in English precisely enough, the constraints, the invariants, who may say what, that the AI can carry it across into code. The AI is a moderator between the English language and the coding language, not the author of either. Decomposing the problem and validating the output, which is what you describe, is modeling. That is why the accountability never leaves the person.
If you're doing all that, I think you shouldn't call yourself a "vibe engineer" or "vibe coder". You ARE an engineer.
Reviewing code before accepting and orchestrating different components have nothing to do with vibes, it's a complex process that requires real engineering skills.
Vibe coding in my book is building something using just prompts, which technically is absolutely possible. I've seen a lot of non-technical people building cool stuff with it, but they're not engineers, they have never written a single line of code. They're just people who can explain their end goal precisely enough to make AI deliver what they want.
Great distinction. I'd sharpen one point: the real issue isn't code quality — it's that vibe coding breaks the chain between decision, evidence, and accountability.
Review tells you the diff is sound. Verification tells you the system behaves as intended. But accountability requires reconstructing why a decision was made and what you assumed — and that's exactly what vibe coding discards.
The accountability gap shows up at 2am, not at merge. When a system fails at the boundary of what the AI was prompted to handle, there's nobody left who can explain the failure path. The accountability doesn't transfer to the model — it just vanishes.
The standard isn't "can you explain every line." It's "can you reconstruct the decision boundary: what did I assume, what did I verify, what did I accept on trust, and what happens if any of those are wrong?" Vibe coding fails that test not because the code is bad, but because there's no person holding that map.
Good points.
good breakdown but I'd add a fourth line past review: who owns it after deploy. reviewing the code the AI wrote is one skill, being the person who gets paged when it breaks in prod at 2am is a different one entirely. a lot of vibe coded stuff never hits that test because it never really goes live anywhere real.
Excellent point! Sometimes it's hard to understand the issue when you're under pressure during an incident, even when the code was written by you. I don't even want to imagine what it would feel like to debug AI-written code at 2 or 3 in the morning.
An absolute nightmare!
Great article, I completely agree with this viewpoint, especially this:
For me it means that classic (the-old-time) engineering is dead. CRUD app like engineering problems will no longer take our night sleep, but we'll be left with harder and more niche and exciting problems to solve.
Totally true. Once thing AI does well is eliminating routine work and giving us more time for the interesting and creative parts of the work.
The "AI-assisted, human-reviewed" vs "vibe coding" split is a distinction I didn't have language for until now. I've caught myself doing both, sometimes in the same session, reviewing every IAM line Claude writes, then blindly trusting a CloudFormation snippet because it "looked right." The second one's the dangerous one, since it feels identical to competence until it isn't.
Yeah, sometimes after coding for eight hours straight, you get tired and start relying on AI completely. I admit I've done it too. The next day, I reviewed everything, asked the AI some questions, and ended up changing a lot of it.
Code that "looks right" can still take down your application, so we need to treat it with caution.
I hope companies team get this much time to work on semantics... 😀 they just want to say we are following latest tech trends.
For the most part they are swamped, very companies have the capability to understand the different and the value in it.
Yeah, that makes sense.
"Vibe coding" is just a pure "prompt in, code out" loop for high-level prototyping. The moment you deal with architecture, edge cases, or security, it's actual engineering.
However, forcing teams to manually review every tiny AI snippet creates a massive bottleneck and leads to rubber-stamping.
Instead of human micromanagement, the solution is structural automation:
Vibe coding doesn't need manual brakes; it needs automated guardrails.
Good points. AI generated snippets should be categorized by their criticality. The most critical ones should absolutely be reviewed, the rest is up to the team and their available resources.
The distinction you're drawing — AI-assisting vs AI-assisted vs vibe coding — maps exactly onto what I see when people pick their tooling.
The interesting tell: engineers who treat AI as a reviewer-required collaborator gravitate toward tools that keep the diff visible and local (Continue + Ollama, Tabby, etc.), while the "prompt and ship" crowd wants the magic black box. It's not really about the model quality — it's about whether the workflow forces you to read the output before it lands in main.
Your point #3 is the one that stings. Curiosity about how things work under the hood used to be the entry ticket, not an optional add-on.
Where do you land on local/open models for the "AI-assisted" bucket? I've found the friction of a smaller local model actually helps — it makes worse suggestions, so I'm forced to stay engaged instead of rubber-stamping.
Thanks for your comment!
good line to draw but id add one more axis. it's not just what the code touches, its what the deploy touches. a vibe coded app thats read only for you is low stakes even with zero review. the moment it writes to a real db with real users, the ops side needs the same rigor youre asking for in code review, backups, auth, who gets paged at 2am. most vibe coding disasters ive actually seen were deploy failures, not code failures. the code ran fine, nobody had thought about what happens when it breaks in prod.
I think this is where the distinction gets really interesting: generating the code is becoming less of the scarce part, while retaining the reasoning behind the system becomes more important. If an agent makes a change today, the useful question later isn't just “what changed?” but “what constraint or decision led us here?” That's the part I find hardest to preserve across sessions.
Hm... that's an interesting perspective. Totally agree!
The gatekeeping angle is backwards though. The people "just accepting AI output" were the same people copying Stack Overflow answers without reading them in 2015 — the tool changed, the behavior didn't. What actually separates engineers now is whether they can verify what the model gave them, and that's a skill you can learn in weeks, not a credential you need years for. I shipped 40+ tools without a formal test suite and iterated on real user behavior instead — would a "real engineer" gatekeep that? Probably. Did users care? Not once.
That's right, the gatekeeping part is exactly the other way around.
the line you draw is right but in practice it moves on its own. plenty of stuff built "just for fun" quietly picks up real users and a login screen before anyone decides it needs review. the honest fix isn't a rule about intent, it's noticing the moment your side project needs a database backup and auth, that's usually the same moment it stopped being just for fun.
Good point!
True, AI writes pretty clean projects now. But if you want to call it your own, you need some skin in the game. Namely, you have to know what it's doing... You can only do that if you're actually going through your code properly. Take my latest project, velocity mcp, I decided to incorporate Wasmer, so I can make it handle multiple runtime languages for tools. It doesnt help I just say 'add wasmer' I need to make sure that its using wasix correctly, that the sdk's are sufficient and that tool calls are optimized (eg. no double serialization). Making sure it's GOOD takes longer than making a MVP.
Great example, that's what I'm trying to say.
I have caught AI doing "interesting" things plenty of times, even though some of those problems weren't so complicated for AI to get confused or something like that.
good breakdown but even the ai-assisted, fully reviewed code breaks in ways review never catches. concurrent users, rate limits, someone's weird timezone, a dependency api going down at 2am. review tells you the code is correct on your machine. running it for real tells you if it survives. that's a separate skill from either side of this debate, and it's the part almost nobody talks about
good breakdown, but one thing this whole debate skips: review protects the code, it doesn't protect the app once it's live. i've seen carefully reviewed, non-vibe-coded apps go down at 3am with nobody paged because deploy and monitoring got zero attention compared to the code itself. for anything touching money or health data the real question isn't "did a human read every line," it's "who gets woken up when it breaks in production." that part has nothing to do with vibe coding vs engineering.
good breakdown. the part people skip is that the risk is not in the code quality, it is in who is on call when it breaks. vibe coded or hand written, the moment something touches money or personal data someone has to own the deploy, the rollback, the logs at 2am. review the code all you want, if there is no real ops behind it you are still gambling.
The three-tier definition (vibe / AI-assisting / AI-assisted) is the most useful framing I've seen on this — most arguments on both sides are just people talking past these definitions.
One thing I'd add from running a fully local AI coding setup for the past couple months (Ollama + a 7B coder model, $0/month): local models force you out of vibe coding whether you like it or not. A 7B model will confidently generate plausible-but-wrong code maybe 30-40% of the time on anything non-trivial, so you have to read every line. It accidentally turns everyone into your "AI-assisted" tier. Cloud models are good enough now that skipping review feels survivable — until it isn't.
So maybe the real dividing line isn't skill or intent, it's whether your tooling lets you get away with not reviewing. Free local models don't.
Curious where you'd put "I reviewed the diff but didn't run the code" in your taxonomy — assisted, or a fourth tier of its own?
Thanks! To be honest I haven’t tried local LLMs for coding yet. Might try at some point to see in practice how they do the job.
I agree with the core point, but I would frame it slightly differently.
To me, vibe coding is closer to an evolution of IDE-level assistance — think autocomplete, code generation, refactoring suggestions, and now much more capable agents.
But software engineering has always been much bigger than writing code.
Engineering includes architecture, requirements, design decisions, choosing the right libraries and technologies, defining boundaries and interfaces, security, performance, testing strategies, development methodology, trade-offs, refactoring, observability, deployment, maintenance, and eventually knowing when to replace or redesign something.
AI can increasingly handle code generation. That doesn't mean it is doing the engineering.
The important question isn't "Who wrote the code?" It's "Who made the engineering decisions, understood the trade-offs, validated the result, and remains accountable for the system?"
That's where I think the real discussion around vibe coding should be.
Good points. The question should be "who did the engineering part". Writing code has never been the point.
Thanks for the comment!
The AI-assisting vs vibe coding split is the part people keep collapsing. I build a lot with a local model on my own files and I'd probably call it vibe coding out loud, but by your definition it isn't, I read every diff and interrogate it before anything lands. The label's loose but the practice isn't.
Coming from security this hits harder for me. The stuff you can't vibe code start to finish is exactly the stuff where being wrong is expensive, money, personal data, anything with a real blast radius. That's the line for me too. Build toys however you want, but the moment it can hurt someone you have to actually know what the code does. Holding the wheel isn't gatekeeping, it's just knowing where the road drops off.
Right, what you do that's not vibe coding for sure.
Typing code by hand doesn't make you a professional software engineer. Understanding code and architecture does.
Absolutely brilliant! Codebases that deals with real people's data that could affect the course of their lives does not deserve a vibe-coded product. That's literally gambling. And if something goes wrong, do we blame Sam Altman or Dario Amodei? Absolutely not.
You have to take charge and own it. AI is a tool to use and amplify your skills and even learn from it. I'm surprised that we share a lot of similarities on using AI @georgekobaidze. I also found myself asking more and more questions than building the feature I intended. And yes, take every AI response with a grain of salt. Always do your own research. AI is meant to complement, not to completely takeover.
I'm glad that you approach AI the similar way. You know, it's SO EASY to blame things on AI, LLMs and all those people behind all that, but when are we going to understand that this is just a tool. And it's a powerful tool too, which means you can either use it to do amazing stuff, or absolutely ruin something important.
I mean, the recent hacking incident with Hugging Face. If that was a person, they could be in prison now. BUT NO. There's no accountability with AI. I fear that one day, this will become the get-out-of-jail card, engineers will use if something did not work out.
Right, but there's always someone behind the AI. You can still trace a disaster back to the person or the company who let it happen, so everyone should be careful about trusting AI blindly, especially when building financial, health, banking, military or other sensitive systems.
I think the floor and the bar both got higher at the same time. AI doesn't give you talent or judgement, it gives you a shortcut to execution. For someone who already has the judgement, that shortcut opens a whole new frontier.
Where I'd offer a different perspective though is the framing of vibe coding as a "type of person". I think it's more of a stepping stone.
Plenty of us started by pasting from StackOverflow and asking a lot of questions. AI is the same on-ramp but with an instant tutor. I make sure to keep learning by taking on bigger and newer challenges using my A.I. tools.
The line you drew (don't vibe code something that handles money or personal data) makes complete sense. But the three reasons you list for why people cross it assume they're lazy or careless. Most of them are just at step one of their skill journey. For some, that may be where it ends and for others it is a great introduction: I have many times had a Product Manager or Director give me something they have made, and I was able to adopt and revise it through my SDLC.
Professionals are in a weird spot: we spent years obtaining knowledge a bot can now recite for anyone. What the bot can't do is the rest of shipping software. Testing, project management, UX review, knowing which KPI actually matters. That's where vibe coding runs out of road, and it's why the skills you already have are an edge instead of a liability. If you want to level up past it, you have to start compounding what you've learned.
Good points, though I'd point out that if someone's just starting out, why go straight to building production systems that handle huge money transactions? Those are too complex and too risky to build without knowing how to declare a variable. It's always better to take your time: give yourself a month or two, learn the basics, and then generate code you can actually review and verify. You get the skills, and your product stays safe.
I agree on the Stack Overflow part, but there's a difference: when we copied from there, most of the time we still had to tweak the code to fit our own needs. Change a value, change the logic, a dozen other things.
Vibe coding gives you a solution directly. And that solution might not be what you're actually looking for, and you might not even know it.
the code review part is the hard half everyone talks about. the part nobody mentions is what happens after you ship - who's watching the auth, the db, the backups once it's live. most vibe coded stuff looks solid right up until someone besides you has to keep it running.
I agree with this. Vibe coding itself isn’t the problem—the problem is treating generated code as engineering without understanding, testing, and maintaining it. AI can speed up development, but engineering still requires responsibility and good judgment.
Totally. Vibe coding can be really helpful too in some cases.
But not when you want to create a banking system. In that case, please stay away from that bank 😄
this hits. the distinction between vibe coding and actually reviewing what the model spit out is something a lot of people blur right now. building for fun? go wild. shipping something that holds real user data without reading the code though… yeah that's a different conversation.
That conversation could easily take days. But the truth is, this isn't engineering, and that's not a term to hand out lightly.
To some extent, I have to echo @echo_daemon_e1c729f762686 and @gunslingor are saying: If only we software developers (to introduce yet another term without proper definition) had the TIME to do real engineering.
What the article avoids is the fact that "out in the wild", we - most of the time - don't get the time to ENGINEER solutions. Which would include all the picket fence details others have mentioned here. I have been developing software for over 40 years now and I rarely came across situations where the engineering part (I'd number that at around 30-40 percent of the task) gets any appreciation. It happens, but so do unicorns vomit.
Most of the times (at least in: publishing, printing, audio, movie industry, games industry, 3d (PR/marketing) in my humble experience) it's "have an idea" (my core job), "translate it into something that can be coded" (my secondary role), "why is the damned shit code not done yet, what have you done over the last 5 minutes we need it IN PRODUCTION NOW!" (my default "engineering" hotspot).
Engineering would be the mediator between (maybe call it architect, to me that's leaning into engineering to some degree, pun intended) the "navigator" or "trouble solver" and the "write the implementation rule book with all checks, tests and evaluations for signing off". BEYOND THAT would be the simple coding stuff, which, in my line of work, has been about 10 percent of any software job really. THAT CODING can be done by AI, as long as the one responsible can explain every single byte in the code without having to ask an LLM about it (which has been NOT the default before AI, copy&paste has always been a pest!). CODING is not engineering. Outlining a program with any kind of diagram and be it language is NOT engineering. Engineering is "having it played out in full and KNOW what you're doing, know all the boundaries, know all the shortcuts and their why and why not and HAVE IT AVAILABLE".
Like others here, I look into the language I am asked to use for "programming", but I spend 10 times longer looking into the workflow, the context, the input and output. I LEARN about what I am doing. Coding I can do while sleeping or have AI do it. SOLVING A PROBLEM where github and stack don't have copy&paste available - that's where, hopefully, the future for software "engineers" exists. If we get the time to FINALLY do a proper job and not fix the spaceship while it's falling into a star.
Thank you for such a detailed comment. Forty years across publishing, audio, film, and games is a perspective few people here can match, and I recognize the "we need it in production NOW" scene all too well. Still, I'd like to argue the opposite: the lack of time isn't what keeps us from engineering. Working within that limit is engineering.
Engineering has always meant working under constraints. Civil engineers don't get unlimited time and budget either. Bridges are designed against deadlines, budgets, material shortages, and politics. What makes it engineering isn't the luxury of time. It's making sound tradeoffs within fixed limits and knowing which corners can be cut safely and which can't. When you decide under pressure what to skip, what to hardcode, and what must be protected no matter what, you're doing the core of the job, not being kept from it.
"Having it played out in full" before building is an ideal that rarely holds, even in traditional engineering. Requirements shift, users surprise us, and systems interact in ways no diagram predicts. Software is the one discipline where building is cheap enough to be part of learning. A quick prototype that shows where the real boundaries are is often more rigorous than months of upfront analysis based on assumptions. Knowing everything in advance isn't the bar. Building so you can learn fast and change safely is.
Coding and engineering aren't as separable as the 10% figure suggests. Code is where design meets reality. Naming, module boundaries, error handling, and what you choose to test are all design decisions made at the keyboard. That's also why "AI can do the coding" is riskier than it sounds. If the code is where many small engineering decisions get made, handing it off means handing off those decisions too, which is exactly why, as you rightly say, someone must be able to explain every byte.
Time is partly something we negotiate, not only something we're given. In my experience, engineering work goes unappreciated largely because it's invisible. "I refactored the pipeline" means nothing to a stakeholder. "This change cuts release failures in half" does. Engineers who frame their work in terms of risk, cost, and outcomes tend to get more room. That's not always possible in every industry or company, but it's more within our control than it often feels.
Fixing the spaceship while it falls toward a star is the job. Production incidents, shifting deadlines, and half-known requirements aren't obstacles to real engineering. They're the conditions it exists for. The environment is often unfair, but the skill you describe (knowing the shortcuts, their why and why not, and keeping it all in your head under pressure) is engineering in its purest form, even when nobody calls it that.
So I'd put it this way: we don't need more time to finally do engineering. We need more recognition that what we already do under pressure is engineering. Thanks again for sparking such a good discussion!
Thanks, Giorgi. I appreciate you taking the time to respond.
I think we can happily disagree here on so many points that it's just fine to let it pass. If "engineering" had a job-description the way you put it, I am sure we'd only have 1% of the engineers we actually do have - but it simply does not matter.
What matters, I think, is that we need to be aware of an important part of what makes human "constructions" robust is knowledge and understanding, learning from mistakes and improving all the time for the sheer sake of improving all the time. This is what we have, hopefully, engraved into our being-human. And what the current "controlled statistics" (aka "AI" of these days) does not have, probably never can have.
The "who does the engineering" framing is the sharpest part of this. One thing I'd add from running a similar experiment: I let an agent write 100% of a small service for a week, and the failure mode wasn't in the creation phase at all — it was in the maintenance phase you mentioned. The code worked, but six weeks later when a dependency broke, nobody on the team understood why the original structure existed. The engineering happened... never. It got skipped entirely, not done by the AI and not done by me.
Your three definitions map onto a spectrum of review depth, but I think the real fault line is debuggability: can the human who "shipped" it trace a production bug through the code at 2am? AI-assisted passes that test. Pure vibe coding fails it every time.
Curious: have you found any middle-ground workflow where the AI writes freely but is forced to produce the engineering artifacts (tests, invariants, a design doc) as part of the output? That feels like the only way vibe coding could ever legitimately claim the "engineering" label.
"have you found any middle-ground workflow where the AI writes freely but is forced to produce the engineering artifacts (tests, invariants, a design doc) as part of the output?"
Absolutely, I have. But I'm not sure I'd call it a middle ground. Without a human in the loop, it doesn't matter how many tests, invariants, or design docs the AI produces. It's all still AI-generated, so it's still vibe coding, just with more artifacts.
𝖧𝖾𝗅𝗅𝗈! 💻✨ 𝕊𝕦𝕔𝕙 𝒶𝓃 𝔦𝗇𝕔𝕣𝕖𝕕𝕚𝕓𝕝𝕪 🚀 𝕠𝕟-𝕡𝕠𝕚𝕟𝕥 🎨 𝒶𝓇𝓉𝒾𝒸𝓁𝑒! ⚡ 𝕐𝕠𝕦 𝒽𝒾𝓉 𝓉𝒽𝕖 🎯 𝒶𝒷𝓈ℴ𝓁𝓊𝓉ℯ 𝓝𝒶𝒾𝓁 🛠️ ℴ𝓃 𝓉𝒽ℯ ʜᴇᴀᴅ 🔥 𝓌𝒾𝓉𝒽 𝓉𝒽ℯ 📊 𝒹𝒾𝓈𝓉𝒾𝓃𝒸𝓉𝒾ℴ𝓃 🌟 𝒷ℯ𝓉𝓌ℯℯ𝓃 💡 𝒸𝓇ℯ𝒶𝓉𝒾ℴ𝓃 🪄 𝒶𝓃𝒹 𝓇ℯ𝒶𝓁 ⚙️ ℯ𝓃ℊ𝒾𝓃ℯℯ𝓇𝒾𝓃ℊ. 🙌
I 🧠 𝓇ℯ𝒶𝓁𝓁𝓎 🔮 𝓁ℴ𝓋ℯ 🛸 𝒽ℴ𝓌 🔮 𝓎ℴ𝓊 📊 𝒷𝓇ℴ𝓀ℯ 🚀 𝒾𝓉 🔮 𝒹ℴ𝓌𝓃! 💡 𝖡𝗒 ⚡ 𝗍𝗁𝖾 🎯 𝗐𝖺𝗒, 🛠️ 𝗐𝗁𝖺𝗍 🎨 𝗂𝗌 💻 𝗒𝗈𝗎𝗋 🌟 𝖿𝖺𝗏𝗈𝗋𝗂𝗍𝖾 🪄 𝗌𝗍𝗋𝖺𝗍𝖾𝗀𝗒 🔮 𝖿𝗈𝗋 🚀 𝑖𝓃𝓉ℯ𝓇𝓇ℴℊ𝒶𝓉𝒾𝓃ℊ 📊 𝓉𝒽ℯ ⚙️ 𝒞ℴ𝒹ℯ 💡 𝓌𝒽ℯ𝓃 🌟 𝓎ℴ𝓊'𝓇ℯ 🎨 𝓁ℯ𝒶𝓇𝓃𝒾𝓃ℊ 🚀 𝒶 𝓃ℯ𝓌 🛠️ 𝓁𝒶𝓃℃𝓊𝒶ℊℯ? 🤔✨
First things first, how did you manage to use so many different fonts and emojis? 😄 This is kinda beautiful.
As for your question, I basically try ask as many questions as possible to AI to make sure I fully understand the code that's not quite clear to me. it's like discussing with your peer engineer, it's so helpful.
Thanks for your (interestingly formatted) comment! 🙏😄
The review part you describe is the harder half people skip. Even if you read every line the agent wrote, that doesn't catch a misconfigured server, missing backups, or auth left wide open. Code review saves you from bad code. It does not save you from bad ops.
True. And that's a topic for a separate discussion, it's so broad. Thanks for pointing this out, because if the environment / server isn't properly configured, it just doesn't matter how quality your code is, something's going to break, or not going to work at all.
The useful boundary is not who typed the code or whether they can recite every line. It is whether someone can own the failure. For production work, I want three things before calling an agent-generated change engineering: a clear invariant and trust boundary, negative-path tests that try to break the assumption, and a demonstrated rollback or recovery path when a tool call or deployment goes wrong. Vibe coding can be perfectly reasonable for a throwaway prototype. Once the system handles real users, money, or sensitive data, the missing step is a verification and recovery contract, not a moral label.
Exactly, vibe coding is a perfect approach for prototypes.
code review is the easy half now honestly. harder part is what happens after you ship, who's on call when the db fills up or auth breaks at 2am. people vibe code the feature but never the ops behind it, that's where it quietly falls apart
I really like the distinction between vibe coding and AI-assisted development. For me, the biggest difference is ownership.
As a frontend developer, I’m happy to use AI to explore an approach, generate boilerplate, or help debug something. But before I ship it, I need to understand the code well enough to explain the decisions, spot the edge cases, and maintain it later.
The “steering wheel” analogy really fits. AI can make us much faster, but someone still needs to understand where the system is going and take responsibility when it goes off course.
Great read! 🚀
Thanks a lot. You're on point there!
I think the distinction that matters most is responsibility, not who physically typed the code.
AI can generate most of a product now, but someone still needs to own the decisions around security, data, testing and what happens when requirements change.
Vibe coding is great for collapsing the distance between an idea and a prototype. The danger starts when the speed of generation creates false confidence that the product is ready for real users.
The best AI development workflows will probably be the ones that make review, testing and iteration as easy as generation itself.
Absolutely true! Typing the code has never been the point. It's just typing.
What matters is the output, whether you type the code yourself or generate it.
The three-tier split lands because it puts the boundary where it actually is: not who typed the code, but who reviewed it. "You don't edit the code and you don't review it" is the whole definition, and it explains why the discourse keeps talking past itself - people defending vibe coding are defending creation, people attacking it are describing engineering, and both are right about different activities. The review tier is also where the skill floor lives: AI-assisting takes enough skill to tell good code from bad, which is exactly the skill the no-review workflow never develops.
That sums up the whole idea very well. Thanks for that!
As an engineer, I don't really hate vibe coding, quite the contrary, I think vibe coding can be a great technique for things like quick prototyping and creating demos.
I actually wrote an article about this a few months ago: dev.to/georgekobaidze/could-vibe-c...
But we all need to agree that it's not engineering, we shouldn't lower the bar for calling someone an engineer, because if we do so, it'll became just another vague term that doesn't really mean anything at all.
Really interesting perspective. I especially liked the distinction between vibe coding, AI-generated code with human review, and AI-assisted development.
As a frontend developer who has recently started learning backend development, I’ve found that AI can speed up implementation a lot, but understanding the code and being able to debug or modify it without blindly relying on AI is still important.
For me, the key question is not who wrote the code, but whether I understand why it works, what could go wrong, and how to improve it.
Great read! 🚀
You’re on point. Thanks!
good breakdown but reviewing the code is only half of it. the part that actually breaks things in prod is deploy - auth wired wrong, no backups, nobody on call at 2am. plenty of carefully reviewed "AI-assisted" code still ships insecure because deploy was the rushed afterthought, not the code review
Spot on. As a web developer, I treat AI as a hyper-fast junior pair-programmer. It writes the boilerplate, but I own the architecture and security. 'Vibe coding' is great for weekend prototypes, but shipping production web apps without understanding the underlying code is a recipe for disaster. We still have to keep our hands on the steering wheel
That's the best way to approach it!
The distinction between AI Assisting and AI Assisted is the most useful part of this. The real skill gap is not whether you use AI, it is whether you can read what it produces and know if it is wrong. That requires understanding the domain well enough to catch the errors, which means the baseline knowledge requirement does not go away, it just shifts from writing code to evaluating it. The financial systems and health app example is the right place to draw the line. A tool that processes someone's money or medical data and was shipped without anyone reading the underlying logic is not an engineering product regardless of how it was built.
Agreed!
I am not a programmer and I don't call myself an engineer. I come from civil engineering and work as a painter. I build AI tools purely out of curiosity, on a vibe, just to understand how LLMs actually work under the hood. But even from that perspective, pure 'vibe coding' (blindly accepting what the AI generates) doesn't work.
When I started building my MCP server, the AI would confidently hallucinate fake dependencies and paths. I couldn't trust its 'vibes'. I had to build a deterministic verification layer that checks the AI's memory against the live codebase. The AI can lay the bricks, but you have to verify if the foundation actually exists.
I don't care about job titles. But the curiosity to tear things apart and check the structural integrity is exactly what separates actual learning from blindly shipping.
Thank you so much for confirming the points in my note. Your approach makes complete sense to me.
I agree with you!
Im a gamedev/system architect, and a solodev I need something matching a senior to throw my code at and find extreme edge cases/logic errors I missed or just general discoussion and finding data från the '80-'90s that's hard to come by. While I prefer typing even boilerplate myself, thats when my ideas struck me but now I dont need to spend 3hours just because the idea was incompatible with what my Goal with the project is :) and I cant trust AI to really understand my overall goals are in complicated projects.
Even so, It's a great tool, I need AI to help me translate my notes and articles into a more "human" readable than just over engineered technical terms and make it easier for beginners to understand and for experts/specialist to still get the information they need.
Great mindset. People often like to think in extremes: always write the code yourself, or always generate it with AI.
There's a middle ground between the two, more balanced, and more useful. Everything is a tool.
I have been vibe coding for a long time now but I am not a core developer However, let me tell you, I don't call vibe coding core coding. Vibe coding is not just prompt writing ok. My vibe coded projects follow strict plans, all security parameters, and what we want to achieve in a process development process. CODE are test driven even though it is vibe coded.
I like your take on vibe coding versus engineering, and the way you describe your process is about the best way anyone can do it.
AI can do all the coding, but you should still learn how to code. The better you understand coding, the better you can guide your AI, catch problems, and make better engineering decisions.
Agreed!
Does calling it engineering excuse sloppy code or pave real rigor?
I don't know to be honest, I think if you call it engineering, then you have even less excuse for sloppy code.
Exactly, some even go as far as calling themselves design engineers.
for vibe coding, waiting a one symbol, character change wait till 2min based on AI time.
For engineer , doing quickly.
I've actually seen people ask an AI to remove a single comment from a function. Token waste at its finest.
But well, at least that means they actually look at the code 😄
Makes eminent sense! Good article!
Thank you! Appreciate that!
코드를 읽었다는 사실만으로는 엔지니어링이 끝나지 않는다는 점에 공감합니다. 특히 돈이나 개인정보를 다루는 제품이라면 생성된 코드의 이해뿐 아니라 권한 경계, 백업, 장애 복구, 배포 뒤 관찰 가능성까지 누가 책임지는지가 기준이 되어야 합니다. 재미로 만든 실험이 실제 사용자를 받기 시작하는 순간부터 검증 수준도 함께 바뀌어야겠네요.
I think the responsible person should be someone who actually understand the technical part of the product. I'd say a senior engineer, principal engineer, engineering manager, tech lead, ... someone like that.
very true, i think there's a difference between prompting until it works, and using Ai agents as a tool to assist in the development process.
Just saw the full comment (edited), and yes, there's a huge difference between the two. Using a tool efficiently is what engineers actually do. What we don't do is accept blind spots. We need to know what every part of the code is doing.
You'll never get to zero, of course. But the job is keeping that number as close to zero as you can.
Thank you!🙏
I completely agree
Appreciate that!
"Vibe Coding" is a really dumb term and it doesn't even make any sense. You either know what you're doing or you don't.__
I know right. 😄 Like I can't see neither vibe, nor coding in that process... weird.
Thank you
You're welcome!🫡
Good perspective. I think we'll eventually get much more comfortable letting agents drive, but we're still at the stage where someone needs to be watching the road.
Exactly! It's like adaptive cruise control in a modern car. It's an impressively smart system that can manage your speed, keep a safe distance from the car ahead, and even keep you in your lane.
But you still have to keep your hands on the wheel, or it starts beeping in protest. Why? Because however capable these systems are, they still need a human in the loop. The same goes for AI in software: it can take on a lot of the driving, but someone still needs to steer.
Thank you for sharing!
My pleasure!
"Vibe coding" is just a loop. The loop to deal with architecture is actual engineering.
Agreed.
Rediculous. Why dont you actually get an engineering degree and license before you try to redefine a 2000 year old profession to fit your ignorance.
Engineering is the application of science to build, it is not a ven diagram. This is so insulting and idiotic, its like it was written by a child. Engineering has zero to do with debugging, do civil engineers debug? Chemical engineers? Are only software engineers engineers now? Fact of the matter is that you have to debug, you have failed as an engineer. Engineering is entirely about foresight, not hindsight.
Im sorry you just learnt spec driven develop, but its existed since the great pyramids so stop trying to teach engineering... reading this article... i would take this down, you should be embarrassed to declare such twisted sophomoric opinion as wisdom or fact.
Very upsetting, toddlers have taken over engineering.
Okay, whoa, whoa, let's all take a deep breath here, friend.😄
First of all I never once claimed to be handing down the ultimate, carved-in-stone definition of engineering. What you're looking at is a reference diagram. A humble little illustration. Its one job, its whole reason for being, is to show that in programming, you need engineering at every single step. That's it. That's the whole case. No hidden clauses, no fine print.
Second of all, and this is where I really have to object: before you go around accusing a person of not having an "engineering degree" and a "license," maybe, just maybe, do a little discovery first. Look into who exactly you're talking to. It's free! And while we're on the subject, which license are we talking about here? A driver's license? A fishing license? Because I've been a software engineer long time and there's no such thing as a general license for engineering and I'm genuinely curious. And you're calling my writing ridiculous and idiotic? 🤣 Wow. Bold strategy. Oh-kay then.
So please, by all means, you have the floor. Enlighten me. Tell the good people what engineering actually is. Maybe I really am that bad. I'm all ears.
the review-before-ship split misses the other half though. i've seen careful reviewers still deploy to some random vps with no rollback, no backups, nobody who knows how to restart it at 2am. reviewing the code before it ships doesn't cover who owns it after.
This contenct is very explain for AI
Tie autonomy to blast radius. Require staged rollout and rollback evidence for high impact systems instead of relying on review.