{"slug": "vibe-coding-will-never-be-engineering", "title": "Vibe Coding Will Never Be Engineering", "summary": "Software engineering requires resolving ambiguity, defining system boundaries, and modeling behavior before writing code, but AI-generated \"vibe coding\" skips these steps by producing code without addressing critical design decisions. A demo of user login functionality generated by an LLM failed to ask whether emails must be unique, accounts verified, or roles exist—questions any engineer would raise—leading to fragile systems where features break each other, state becomes unpredictable, and progress stalls. Without upfront engineering decisions, developers end up cleaning up fragility under pressure, making the difference between a working demo and a stable, evolvable product.", "body_md": "Engineering is a discipline. Vibe coding is the input.\n\nIf you want your AI-generated code to become a long-term product, there are software engineering topics that you will have to address. If you do not address them you will find that your progress stalls because features start to break each other, system state becomes unpredictable, managing your code becomes impossible, deployment becomes a barrier, error messages stop making sense, and simple features become hard to add. This leads to a collapse in confidence.\n\nWhen engineers write code, they are not just typing. They are resolving ambiguity, defining boundaries, modelling behaviour, and deciding how the system should work under stress.\n\nMost of this happens before a single line of code exists, and it is the reason human-authored software remains stable as it grows.\n\nVibe coding skips these steps because the AI will happily generate code without them. The system, however, still depends on those decisions having been made. If you do not resolve them upfront, you end up resolving them later under pressure, while cleaning up fragility you never planned for.\n\nA system is more than the text that implements it. A system relies on invariants that must always be true, constraints, contracts, failure modes, and coupling and sequencing that do not appear in the prompt and do not exist in the LLM's internal world.\n\nThe topics below are not \"enterprise ceremony\". They are the questions and decisions every experienced engineer makes before they start typing, and they are the difference between a demo and a product.\n\nIf this resonates, the newsletter continues the work. [Subscribe](/pages/newsletter.html)\n\n### Pre‑coding software engineering topics\n\n| Topic | Description |\n|---|---|\n| Problem framing | Define the problem, the user, the constraints, and the intended outcome. |\n| Requirements engineering | Elicit behaviours, invariants, edge cases, and acceptance criteria. |\n| System modelling | State models, data flows, sequence diagrams, causal reasoning. |\n| Architectural design | Boundaries, responsibilities, interfaces, failure modes, trade‑offs. |\n| Non‑functional requirement definition | Performance, reliability, security, compliance, operability, cost. |\n| Risk identification | Unknowns, dependencies, failure points, mitigations. |\n| Feasibility analysis | Technical, organisational, and economic viability. |\n| Interface and contract design | Define APIs, schemas, and behavioural guarantees. |\n| Planning and sequencing | Break work into coherent, deliverable units. |\n| Definition of done | Evidence required for completion: tests, documentation, review, performance, security. |\n\n## A demo is easy; a product is not\n\nA simple prompt was issued:\n\nwrite python to \"Add user accounts to a website so people can log in.\"\n\nThe model generated a small, working Flask and SQLite example. That is acceptable for a demo. It is not enough for a product. The engineering decisions that make software safe, stable, and evolvable must still be made, and an LLM cannot make or request them.\n\nThe AI did not ask about these five requirements:\n\n- Should emails be unique\n- Should accounts be verified\n- Should users reset passwords\n- Should roles exist\n- What is the security model?\n\nAny engineer would ask these questions about logging in users to a website. The AI did not ask because the prompt was to write code, so code was written.\n\nWhether emails must be unique, accounts must be verified and whether roles\nshould exist are *business rules*. Different companies will make different\nchoices. And these choices are design inputs into code generation.\n\n### The consequences of unasked questions\n\nIf emails are not unique, two people can sign up with the same email address. If this can happen, user login identity is ambiguous.\n\nWhen a user logs in with a repeated email address, the check of that user’s registration from the database will contain multiple values. Any code built to check for a registered user will now have to take into account the possibility of multiple results.\n\nA vibe coded implementation will not handle this case as the person requesting the code did not know to add this possibility to their prompt.\n\nSuch code will work initially when all of your users happen to use unique emails. However, as soon as a user signs up with a repeat, user login identity becomes ambiguous, your code starts to become less reliable, and your job becomes inexplicably more difficult.\n\nThe lack of unique‑email consideration means that if a user with a repeated\nemail resets their password, the vibe‑coded implementation will reset the\npassword for *all* users who share the same email. Chaos reigns. And if one\nuser deletes their account, multiple accounts will be deleted.\n\nAnd no business can tolerate this.\n\nSoftware engineers understand user identity requirements. LLMs do not.\n\n## Why did the LLM not ask about the requirements\n\nIt cannot ask.\n\nLLMs cannot detect missing requirements. They cannot detect ambiguity. LLMs cannot identify risks.\n\nLLMs generate code that looks plausible without understanding:\n\n- your domain\n- its constraints\n- the invariants (what must always be true, like email uniqueness)\n- the failure modes\n- the consequences\n\nIt is not that these points are not important so the LLM did not ask; LLMs cannot see the category of things that must be asked.\n\nThis is because LLMs do not build or maintain a model of your system, the domain, or the consequences of actions. They only predict the next plausible token.\n\nYour code is a stream of tokens that happens to be computer code. But the LLM has no understanding of what that code means in the way an engineer understands meaning.\n\nThe LLM has generated code that breaks when email addresses are no longer unique. The LLM does not understand why unique emails are important for user identity and system safety.\n\nVibe coding produces code. The LLM does not do the understanding about that code for you.\n\n## The misconception behind vibe coding\n\nVibe coding rests on an assumption: that the AI is \"intelligent\" in the way an engineer is intelligent. If that were true, then missing requirements, ambiguous rules, and hidden constraints would be caught automatically.\n\nThe LLM would ask questions. It would notice contradictions. It would flag risks. It would protect invariants.\n\nAn LLM does none of this. It does not reason about the system or build a model of your domain. It does not track consequences or understand the invariants that keep the system stable. It does not recognise what it has missed or what it cannot see. It produces text that looks like an answer without doing any of the thinking an engineer would do before writing any code.\n\nThe danger is not that the LLM is weak. The danger is that the output looks strong enough that people assume the thinking has been done.\n\nThey assume the requirements have been addressed because the code \"works.\" They assume the system is coherent because the file runs.\n\nThey assume intelligence where there is only pattern continuation.\n\nVibe coding fails in production because the missing decisions reappear later as failures, inconsistencies, and fragility.\n\nThe model cannot see the category of things that needed to be asked. The human assumed the model had seen them.\n\nAnd that gap is the entire problem.\n\nRead next:\n\n[The Big AI Gains Come From Teams, Not Individuals]\n\nAI makes individuals faster, but the real gains are between groups of people.\n\n## Related Articles\n\n[Agents Cannot Maintain Systems](agents-cannot-maintain-systems.html)[What Software Engineers Need to Know About LLMs](software-engineers-need-to-know.html)[Latency Is Architectural](latecy-is-architectural.html)\n\n**If this was useful**, you can get more pieces like it in the Phroneses newsletter.\n\nI work with leaders and teams on clarity, capability, and momentum.\n[Work with me →](/pages/services.html)", "url": "https://wpnews.pro/news/vibe-coding-will-never-be-engineering", "canonical_source": "https://phroneses.com/articles/build/notes/vibe-coding-is-not-engineering.html", "published_at": "2026-05-29 00:00:00+00:00", "updated_at": "2026-05-29 15:30:06.414542+00:00", "lang": "en", "topics": ["large-language-models", "generative-ai", "ai-tools", "ai-products"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/vibe-coding-will-never-be-engineering", "markdown": "https://wpnews.pro/news/vibe-coding-will-never-be-engineering.md", "text": "https://wpnews.pro/news/vibe-coding-will-never-be-engineering.txt", "jsonld": "https://wpnews.pro/news/vibe-coding-will-never-be-engineering.jsonld"}}