--- title: "Vibe Coding Is Easy. Production Isn't." slug: vibe-coding-is-easy-production-isnt url: https://listedarticles.com/articles/vibe-coding-is-easy-production-isnt canonical_url: https://antrecu.com/blog/vibe-coding-easy-production-isnt content_type: essay language: en published_at: 2026-09-02T00:00:00.000Z updated_at: 2026-09-24T15:26:01.135Z author: "Andres Torres Russo" author_url: https://antrecu.com authored_by: human publisher: "antrecu" publisher_url: https://antrecu.com topics: ["AI", "Programming", "Engineering", "Startups"] license: all-rights-reserved word_count: 2311 reading_minutes: 10 citation: "Andres Torres Russo, antrecu. \"Vibe Coding Is Easy. Production Isn't..\" 2 Sept 2026. https://antrecu.com/blog/vibe-coding-easy-production-isnt (all-rights-reserved)" # The full text follows. The web page shows an extract and sends readers # to the source above; quote the citation and link the canonical URL. --- # Vibe Coding Is Easy. Production Isn't. > Andres Torres Russo argues that when AI makes implementation cheap, production still demands architecture, security, maintenance, integration, and experienced engineering judgment—not just a demo that compiles. **AI is making software development dramatically more accessible. That's great. But when software generation becomes cheap, engineering judgment becomes even more important.** There it is again! A new AI model drops, **X** goes crazy, and suddenly we're all looking at the next thing that's going to completely change software development. **Fable 5.1** is out. Boom! Within hours, timelines are full of people showing what the new model can build. And somewhere in that noise, a post catches my attention: *“I know literally NOTHING about coding. ZERO. And I just built three fully functioning web applications in 30 minutes.”*   Then come the screenshots. And the links: `localhost:3000`, `localhost:8000`, `localhost:5000`. That's when I started laughing. Not because AI can't build applications. It absolutely can. And not because I'm against vibe coding. I'm not. I use it myself. The problem is something much more fundamental: Getting software to run is not the same thing as engineering software. ### We've already talked about the hype A while ago I wrote about my own relationship with the endless AI race in **What If I Stop Chasing the Best AI?** The idea was simple: if we're constantly waiting for the next model, the next benchmark, the next “best AI,” we can spend all our time chasing the tool instead of actually doing something useful with it. And here we are again. A new model arrives. Everyone gets excited. Next week, another one will arrive and kick its ass at something else. Then another. And another. That's not necessarily a bad thing. Competition is great, and the pace of improvement is genuinely impressive. But there's a point where we need to stop asking *“Which AI is the best?”* and start asking: “What are we actually doing with all this capability?” Because something important is happening underneath the hype. AI is not only making experienced developers faster. It's making software creation accessible to people who previously couldn't write software at all. And that's both **incredible** and **potentially dangerous.** ### I'm not against vibe coding Let's get this out of the way. I vibe code. A lot more than I used to. I use AI coding tools, including Codex, and sometimes Claude Code. I let AI scaffold things, write implementation code, explore approaches, refactor code and take care of enormous amounts of work that would previously have taken me hours. And honestly? **It's fucking useful!** Why would I manually write hundreds of lines of repetitive code when I can describe what I need and have an AI produce a first implementation in minutes? That would be silly. But there's a difference between **using AI to write software** and **outsourcing software engineering to AI**. I still review the code. I still make architectural decisions. I still care about Git history. I still run tests. I still care about CI/CD. I still think about security, scalability, maintainability and failure modes. And when something gets delivered, **I'm responsible for it.** That's the difference! AI can do an enormous amount of the work. It doesn't inherit the responsibility. ### The prototype illusion This is where I think a lot of the current vibe-coding conversation goes wrong. AI has become incredibly good at producing something that **looks like software**. Give it a description. Give it a prompt. Give it a screenshot. Give it a few requirements. And suddenly you have an application. It runs. The UI looks good. You can click around. Maybe you've even got a database and authentication. That's genuinely impressive! But software engineering doesn't end when the demo works. In many cases, **that's when it starts.** What happens when the database gets large? What happens when two users perform the same operation at the same time? What happens when an external API goes down? What happens when an authentication token expires? What happens when the dependency you used gets a breaking change? What happens when the application needs to be upgraded? What happens when the traffic increases by 100x? What happens when the data model changes? What happens when somebody has to debug the thing six months from now? And perhaps the most important question: What happens when you're no longer there to explain what you built? A prototype can answer: “Does this work?” Engineering has to answer: “Will this continue to work?” Those are very different questions. ### Now put this inside an enterprise This is where the conversation gets much more interesting. Because enterprises are going to adopt AI-assisted development. Of course they are. If AI can make developers dramatically more productive, organizations will want that productivity. And they should. But imagine taking the *“I don't know anything about coding, but AI built three apps for me”* mentality and putting it directly into an enterprise development environment. Now the stakes change. The application isn't just a toy. It might be connected to customer data. It might interact with internal systems. It might process payments. It might expose APIs. It might contain business-critical workflows. It might be responsible for data that cannot simply disappear because somebody's prompt generated a questionable migration. And eventually something will break. Someone will need to figure out why. Someone will need to deploy the fix. Someone will need to roll something back. Someone will need to understand the architecture. Someone will need to make the decision about whether the proposed fix is actually safe. **Who is that someone?** The AI? No. The prompt? No. The person who copied the generated code into the repository? Maybe. But if they don't understand the system they're responsible for, we've created a very strange situation. We've made **writing software cheap while potentially making understanding software more expensive.** ### The bill doesn't arrive when you generate the code This is probably the part of vibe coding that worries me the most. AI can move an enormous amount of work forward. But it doesn't necessarily eliminate that work. Sometimes it simply moves the cost somewhere else. You can generate a feature in thirty minutes. Great! But perhaps maintaining it for five years takes hundreds of hours. You can generate an application in an afternoon. Great! But who owns its security updates? Who understands its dependencies? Who knows why the architecture looks the way it does? Who handles the production incident? Who upgrades it? Who documents it? Who takes over when the original developer leaves? The cost of software isn't just the cost of **creating** it. It's the cost of **owning it.** And enterprise software is owned for a very long time. This is also where another question starts to matter: if AI makes software generation dramatically cheaper, does that actually make software cheaper? I explored that question in **Is AI Really Making Software Cheap?** ### Drupal makes this painfully obvious I've spent a large part of my career working with Drupal. And Drupal is a particularly good example of why this distinction matters. A serious Drupal platform isn't something you simply “build.” **You inherit it. You extend it. You upgrade it. You migrate it. You integrate it. You secure it. You monitor it. You scale it.** And eventually, somebody else inherits it from you. That's the lifecycle of enterprise software. You've got Drupal core, contrib modules, custom modules, configuration, content models, permissions, caching, queues, search, APIs, integrations, deployment processes, databases, infrastructure, security updates, performance considerations, editorial workflows and business rules. And often years of history. Some of the most important parts of a Drupal platform aren't even obvious when you first look at the code. Why is this cache configured this way? Why does this permission exist? Why does this migration work like that? Why can't this module be updated independently? Why does this custom module exist? Why does changing this field break something three systems away? These are engineering questions. And AI can absolutely help answer them. It can inspect code, analyze configuration, explain dependencies, propose fixes and even help implement those fixes. But somebody still needs to understand **the system**. Because eventually the AI-generated code meets reality. And reality doesn't care how impressive the demo looked. ### This isn't just about debugging I think there's a temptation to reduce this entire conversation to one question: “Who's going to debug the AI-generated code?” That's important, but it's not enough. The real challenge is much bigger. Who is going to design the system? Who is going to decide what shouldn't be built? Who understands the business rules? Who reviews architectural decisions? Who determines whether a shortcut is acceptable? Who thinks about scalability? Who understands the deployment pipeline? Who defines what needs to be tested? Who understands the consequences of changing a dependency? Who owns the production environment? Who is responsible five years from now? That's why I don't think the future problem is simply **teaching people how to use AI**. The future problem is teaching people **how to think while using AI**. ### So should we keep vibe coders out of enterprise teams? I don't think that's the answer either. In fact, I think that would be missing the point. If anything, organizations should embrace AI-assisted development. But they need to change **how they train and evaluate people who use it.** The goal shouldn't be to turn everyone into better prompt engineers. It should be to turn developers into **better engineers who happen to have extremely powerful AI tools.** That's a different mindset. Instead of: “The AI wrote it, so it must work.” We need: **“The AI wrote it. Now let's prove that it works.”** Instead of: “The AI says this is the best architecture.” We need: **“Why is this architecture appropriate for our system?”** Instead of: “The feature works.” We need: **“How does it behave when something goes wrong?”** That's **engineering**. ### And Drupal is already part of this conversation This isn't theoretical in the Drupal community either. That's an important conversation. But I think we're still asking a question that's one level too low. **Which model should we use?** Is useful. But eventually we need to ask: What kind of engineering discipline do we need around the people using those models? Because the model is going to change. Fable 5.1 today. Something else tomorrow. **The engineering responsibility doesn't.** ### The AI engineering maturity gap I think we're going to see a very interesting separation between different levels of AI-assisted development. At the bottom, you have the **prompt consumer**: “Build me an app.” Then the **vibe coder**: “I can get AI to produce working software.” Then the **AI-assisted developer**: “I understand the software, and AI makes me significantly faster.” And eventually the **AI engineer**: “I use AI throughout the development lifecycle while remaining responsible for the architecture, quality and delivery.” And beyond that, there's the **AI-native engineering organization.** That's where AI isn't just generating code. It's integrated into development, testing, code review, documentation, CI/CD, monitoring, debugging, maintenance and operations. But humans still own the system. That's the direction I think enterprises should be moving toward. Not **AI instead of engineering.** **AI integrated into engineering.** ### The code is becoming cheap And this might be the biggest change of all. For decades, one of the bottlenecks in software development was the cost of producing code. AI is attacking that bottleneck head-on. That's fantastic! But when code becomes cheap, something else becomes comparatively more valuable: **Judgment.** Knowing what should be built. Knowing what shouldn't be built. Understanding trade-offs. Recognizing bad architecture. Knowing when a shortcut is acceptable and when it will become technical debt. Understanding production systems. Knowing how systems fail. Knowing how to evolve them. Knowing when the AI is confidently wrong. That's not disappearing. If anything, **it's becoming more important.** ### AI doesn't get a special exemption from engineering There's another piece enterprises need to get right. AI-generated code cannot be allowed to bypass the normal engineering process simply because it was generated quickly. If anything, the more code an organization can generate, **the more important the process becomes.** Code review. Testing. Security. Dependency management. Documentation. Git. CI/CD. Observability. Deployment. Rollback. Incident response. Technical debt. Architecture. These aren't obstacles to AI-assisted development. **They are what make AI-assisted development safe enough to use at scale.** ### We don't need less engineering I don't think the future of software development is going to be humans sitting around manually typing code while AI watches. That's already changing. And frankly, I'm happy about it. I don't want to spend my career typing boilerplate. I want to solve problems. I want to design systems. I want to make good technical decisions. And if AI can save me ten hours of implementation work, **give me the ten hours back.** I'll use them to think. But there's a fundamental principle I don't think should change: If you deliver software, you are responsible for that software. It doesn't matter whether you wrote every line yourself. It doesn't matter whether an AI wrote 90% of it. It doesn't matter which model generated it. The production environment doesn't care. The customer doesn't care. The incident doesn't care. The business doesn't care. **Someone owns the outcome.** And that's the part of the vibe-coding conversation I think we're still missing. ### The question we should be asking We're entering a world where almost anyone might be able to generate software. That's amazing! But it creates a question that enterprises are going to have to answer sooner rather than later: When everyone can generate software, who is responsible for the software? I don't think the answer is to stop people from using AI. Quite the opposite. I think we need to teach people how to use it **as engineers.** Because vibe coding isn't the enemy. **The idea that vibe coding eliminates the need for software engineering is.** And as AI gets better at writing code, I'm willing to bet that the engineers who understand what happens **after the code is written** are going to become more valuable, not less. Because getting software to run is easy. **Keeping it alive is the job.**