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 (218)
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 😅
200% agree that this behaviour didn’t magically appear with ai, it just made the consequences and the scale way more visible.
and, care about the outcome & stay curious about the process is such a solid combo. Tools will keep changing, but that mindset is gonna keep you growing as a dev !!
Loved this perspective thoughhh, these are exactly the kind of conversations I come to dev communities for🌸
100%
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!
this should have been the post
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.
You need to learn the basics first IMHO, i.e. read the manuals before you try to operate heavy machinery.
Programming has nothing to do with engineering, your mixing a very specialized trade from a web centric perspective with a broad 10k year old evolved profession.
Engineering simply is not defined as the overlap of debugging, creating, refactoring and maintaining by any reasonable measure... every single one of those is an implementation or administration concern, not an engineering concern; there is no engineering principles in that. If a product is well engineered, maintenance is minimal, debugging isn't required, 'creating' is handled by machines now and refactoring is planned/predictable in advance per stage for code evolution. You could at least reduce your redefinition of engineering to just Software Engineering, or even better Software Development.
en.wikipedia.org/wiki/Engineering
en.wikipedia.org/wiki/Software_eng...
If I were to make a Ven diagram after 20 years of engineering:
Engineering = 01 Study, 02 Design, 03 Build, 04 Test
I swear on my life in 20 years of engineering I have never used a debugger, 99% of that happens before I write the first line of code and the 1% remaining is caught while I write code or tests. Why anyone would want to limit an engineers ability to diagnose to Debugging specifically or pay an expensive engineer to do maintenance, I can't understand that. That doesn't take an engineer, any level Programmer can handle maintenance if the architecture is engineered properly.
Well, looks like we're not on the same page when it comes to the definition of engineering. Which is OK, we agree to disagree. That's normal.
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.
Its not. Programming is a subset of general writing or authoring. Writing is not engineering, engineering is independant of language or notation, culture, preference, etc.
Is it possible to approach a work of fiction or logic from an engineering perspective, absolutely, but there is no requirement for it. Programming is writing a set of instructions for a computer. Pretending they are the same thing or drawing a ven diagram to simplify understand... i dont know brother, it ain't that complicated.
Once you right your first line of code, your a programmer, doesnt even have to work. Remember before the world had programmers, engineers had word processors (human machine programmers) and drafters. Architects say what, engineers say how, programmers go build it... software need not be unique in engineering, zero reason given beyond agile, which is largely dead with AI.
There is literally no legal protections for the title Programmer.
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.
Its true, but only in the web world and only due to a historical inaccuracy caused by IT/CS misunderstanding what engineering is.
Architecture is a design consideration, the "what should it look like", while Engineering is more practical, the "how do I build it". Programming is an act without constraint or requirement, like welding. Development is a product consideration, how do we Develop/Evolve the product.
Architects are visionary artists more than practical developers. Most things architected never actually get built. As far as I am concerned, the greatest architect in history was MC Esher but nothing was actually buildable with scientific principles (at least not until we figure out higher order space time from a scientific perspective, then engineers will have their day, lol.
Architects and Engineers are usually at odds with each other. Architects say what every one wants, Engineers say what everyone can have, without exploding budget, maintenance costs or getting 100s of people killed or shutting down half the internet because a PR wasn't review (wink at Cloudstrike, not engineers).
For software, you guys weren't shooting yourselves in the foot to horribly (bad, but you could still limp) with the redefinition all these years because your systems were deterministic... that isn't true any more with AI... only real engineering can handle that, not debugging, not maintenance... we are talking "100 year flood" pre planned considerations or "what if chatGPTs child controls go down for 1 day every 100 years". Its more about controlling the parameters of a system of infinite states than it is about fixing or architecting.
i.e. its only web people that try to combine arch and engineering... everyone else views arch as aspiration and engineering as practical design and implementation planning.... go ahead, have an architecture design a house, train or bridge and build it directly, good luck, lol.
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.
It's happening now, and its hilarious. 20 years sitting in meetings with IT guys pretending to be engineers... I suggest "a minimal spec could really help this project" and get laughed out of the room. Now spec driven development is their new fad like its a brand new concept, and devs/programmers/IT are freaking out because they hate documentation generally and have no idea how to manage non-deterministic systems (something engineers inherently do and have always done).
Wow! @marc_albrecht_8e1e0a8583a 😄 Aren't you a charming little fella, appreciate those kind words!😆
As for the @gunslingor 's quote: "20 years sitting in meetings with IT guys pretending to be engineers..."
I still don't know who you call engineers exactly, but I guarantee you people building car engines in Mercedes sit at meetings with people from multiple departments.
But as I said, we can't all agree on everything. There are different opinions and that's why this world is so amazing. Enjoy your wide view of the world. 🫡
Enjoy your debugging and maintenance in an AI world. When the AI does the implementation, all that remains for humans is what you call architecture and i call engineering.
As long as you dont add the word professional in front of your engineering title, you'll be fine.
I'll enjoy all that and I'll proudly add the word "professional" and "engineer" in front of my name. 🫡
Maybe your not in the US, might be okay in your country but most countries license at the federal level. Be sure to ask AI before adding it to a resume is my advice.
With all due respect, I honestly think you're either trolling me (successfully) or truly have no idea how this industry works. I think it's the former, because even non-developers know that there is no such thing as what you're describing.
Not in Europe, not in the US, nowhere.
If you mean the license that Apple requires for developers, sure. But that's a different kind of a license.
But you can believe what you believe. Who am I to change that?
Hence why its insulting, your not even aware we exist.
A Professional Engineer (PE) license gives you legal authority to sign, seal, and submit public engineering plans.The 4-Step PE PathEducation: Earn a bachelor's degree from an EAC/ABET-accredited engineering program.FE Exam: Pass the computer-based Fundamentals of Engineering exam (best taken in senior year).Experience: Complete 4 years of progressive, verifiable work experience (often under a licensed PE).PE Exam: Pass the discipline-specific Principles and Practice of Engineering exam administered via NCEES and your state board.
My license covers computer, software and electrical engineering.
Well ... I hear you ... and I feel a sense of tongue-in-cheek there as well :-)
I think the problem (aside from the article's author's quite narrow view on the world when it comes to defining "engineering" ;-) ) might touch on "engineers usually know what they are doing, they have leeway/headroom that they 'vibe' within, their precision has a built-in tolerance". For software people that's a way of seeing "specs" that just does not work, full stop. You don't have "headroom" when you say "this value can't pass 1.0". An engineer (I am simplifying here) might say "or so". A software fraggle will start screaming, kicking and throwing pizza on that remark.
But that's not fair, I admit. And I guess I'd better shut up now before I open yet another box of pandorra's "give-or-take".
I think your correct. Software Engineering and software development are much different operations with much different results. One wouldnt want Software Developers or Programmers doing any part of the Engineering associated with nuclear reactor shutdown statemachine or tomahawk missile telemetry system, still software engineering... yet having a licensed PE software engineer at Facebook could provide rare value... they dont even know we exist! 🤣
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!💡💯
Glad it landed.
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 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.
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 :)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.