Understanding the Limits of Vibe Coding: A Practical Guide to AI Engineering-Grade Programming

From Vibe Coding to AI Engineering-Grade Programming

A teaching course on Bilibili focused on hands-on AI programming has recently sparked widespread discussion. The course dives deep into several of the most mainstream AI programming tools available today—Codex, Claude Code, and Cursor—along with the overarching concept of "AI engineering-grade programming." Unlike the flood of self-media content hyping the idea that "tech novices can build amazing projects with AI," this course offers a more sober perspective grounded in engineering reality.

The instructor opened with a question that cuts right to the heart of the matter: how many developers today actually use AI programming at their companies? Survey results showed that the vast majority already rely on AI tools to write code, and the "traditionalists" who type out every line by hand have become the minority. This shows that AI programming is now an industry standard—but the real point of contention is: where exactly are the limits of AI programming's capabilities?

The Real Limits of Vibe Coding

"Vibe Coding" refers to a programming approach where developers describe their requirements in natural language and have AI directly generate the code, without writing it line by line. The term was coined by OpenAI co-founder Andrej Karpathy on social media in early 2025 and quickly became a buzzword in the AI programming space. Karpathy's own description of this programming paradigm was rather emotive—"fully giving in to the vibes, accepting AI's suggestions, not even entirely sure whether the code actually runs"—which both captures the intuitive appeal of Vibe Coding and hints at its potential risks. Its technical foundation stems from the breakthrough progress of large language models (LLMs) on code generation tasks—models represented by GPT-4, the Claude 3 series, and DeepSeek Coder have already been able to solve a considerable proportion of real-world software engineering problems on programming benchmarks like HumanEval and SWE-bench.

Among these, HumanEval is a code generation evaluation set released by OpenAI, containing 164 function-level programming problems that test a model's ability to generate correct implementations from documentation comments. SWE-bench, on the other hand, is closer to real engineering scenarios, requiring models to fix issues in actual open-source projects on GitHub, and is currently recognized as one of the most difficult software engineering benchmarks. Top models' solution rate on SWE-bench jumped from less than 5% in 2023 to over 30% in 2025—a figure that intuitively demonstrates how LLMs' coding capabilities are undergoing a qualitative shift, from "code completion" to "code generation and reasoning." It's worth mentioning that the emergence of the SWE-bench Verified subset (a high-quality task set jointly curated by OpenAI and the SWE-bench team) has further improved the benchmark's credibility, making it one of the most convincing references for measuring AI engineering capabilities. The rise of Vibe Coding is essentially a product of this qualitative shift—it dramatically lowered the barrier to programming, allowing even non-professionals to quickly produce runnable programs.

However, the instructor was clearly skeptical of the claim that "novices can wipe out programmers with Vibe Coding." He suggested taking a close look at the projects these bloggers actually deliver: most are nothing more than simple small websites, cross-border e-commerce sites, wrapper/proxy relay sites, mini-programs, or lightweight small games—simple business logic and low technical barriers, for which Vibe Coding is indeed capable.

But once you benchmark against truly enterprise-grade projects—highly complex business logic, high-concurrency processing, microservices and distributed architectures, massive data throughput—the situation is entirely different. High-concurrency systems need to handle tens of thousands or even millions of requests per second, involving multi-layered design decisions such as load balancing, caching strategies (like Redis), database connection pool management, and asynchronous message queues (like Kafka and RabbitMQ). Microservice architecture means breaking down a monolithic application into dozens or even hundreds of independent services, each with its own deployment lifecycle, circuit-breaking and rate-limiting mechanisms, and monitoring system. One root cause of this complexity lies in the fundamental difference between "distributed systems" and "single-machine systems": the network is unreliable, nodes can go down at any moment, and clocks cannot be precisely synchronized—problems that don't exist in single-machine programs become engineering challenges that must be systematically addressed in distributed scenarios. These inherent complexities of distributed systems were summarized by computer scientist Peter Deutsch as early as 1994 in the "Fallacies of Distributed Computing," which point out that intuitive assumptions like a reliable network, zero latency, and infinite bandwidth all fail to hold in real-world engineering—and how to address these fallacies remains a core topic that tests the depth of an engineer's experience to this day.

Behind these design decisions lies a core tradeoff in distributed systems theory—the CAP theorem (Consistency, Availability, Partition Tolerance). This theorem was proposed by computer scientist Eric Brewer in 2000 and formally proven in 2002 by Seth Gilbert and Nancy Lynch: when a network partition occurs, a distributed system can only choose between consistency and availability. Choosing strong consistency (such as in financial transaction systems or inventory deduction scenarios) means sacrificing availability during network jitter; choosing high availability (such as in social feeds or product display scenarios) means accepting temporary data inconsistency. Beyond CAP, the industry has also developed the more fine-grained PACELC model, which further weighs the tradeoff between latency and consistency when there is no network partition, providing a more practical analytical framework for choosing databases and middleware. There is no standard answer to such tradeoffs—they depend entirely on an engineer's deep understanding of the business scenario and system design experience. AI tools can generate the code framework for a single microservice, but the coordination logic between services, fault-tolerance design, and performance tuning based on CAP tradeoffs still heavily depend on human engineers' architectural judgment. The instructor's verdict on whether someone with no technical background could achieve all this purely through Vibe Coding is "absolutely impossible," and there is currently no successful precedent.

This judgment deserves serious consideration from every practitioner. AI programming tools are "amplifiers," not "replacements"—what they amplify is the user's own engineering judgment. Someone lacking architectural ability will only produce simple results even when commanding AI.

The Real Pain Points of AI Programming

During the course, students shared a series of real-world frustrations they encountered when using AI for programming—pain points that are the undercurrents lurking beneath Vibe Coding's glossy exterior.

Security and Accountability

"Feeling uncertain about security" was the most concentrated feedback. AI generates code extremely fast, and developers often have no time to review it line by line before facing go-live decisions. Once a serious bug appears in production, who bears the responsibility? The answer is stark: the large model won't take the fall for you—the responsibility ultimately falls on the person using the AI.

From a security engineering perspective, the risks of AI-generated code are not limited to logic errors but also include potential security vulnerabilities—SQL injection, cross-site scripting (XSS), insecure deserialization, hardcoded credentials, and more. Research shows that current mainstream AI programming tools vary widely in their ability to avoid the OWASP Top 10 security vulnerabilities when generating code. OWASP (Open Web Application Security Project) is a nonprofit international security organization whose published Top 10 vulnerability list is widely adopted as an industry security benchmark. The 2021 version added a new category, "Insecure Design," precisely in response to a new type of risk in AI-assisted development where "the functionality works but the architecture has systemic security flaws." This means that when relying on AI to generate security-critical code (such as authentication and authorization, data encryption, or payment logic), a professional Security Code Review process must be introduced—you cannot go live simply because functional tests pass.

Code Standards and Maintainability

Another prominent issue is the lack of standardization in AI-generated code. When everyone on a team uses a different AI tool without a unified standard, the project cannot achieve true engineering-grade collaboration. The instructor used a vivid metaphor: as more and more code piles up, the project becomes increasingly "spaghetti code" in its later stages, ultimately heading toward an unmaintainable predicament.

This issue has a professional term in software engineering—"technical debt," coined by Ward Cunningham in 1992. The technical debt metaphor comes from financial lending: non-standard implementations adopted for the sake of fast delivery are like "taking on debt," and in the future you'll have to pay a higher price (refactoring, fixing, debugging) to "repay the debt." Technical debt is not inherently harmful—during the early stages of a product when rapidly validating market viability, proactively taking on a certain amount of technical debt is a reasonable business decision. What's truly dangerous is "unconscious technical debt," where the team is completely unaware of the debt's existence until the system collapses and they realize the cost. While AI programming boosts short-term delivery speed, it can also accelerate the accumulation of technical debt if it lacks engineering-grade constraints—AI can generate hundreds of lines of code in a few minutes, but whether that code conforms to the project's existing naming conventions, module division principles, and test coverage requirements depends entirely on whether the user has established corresponding constraint mechanisms.

Token Consumption and Production Failures

A token is the basic unit by which a large language model processes text, roughly understood as a word or a fragment of a word (in English, about 4 characters equal 1 token; in Chinese, about 1-2 characters equal 1 token). Every inference the model performs is subject to a "context window" limit—the maximum number of tokens it can "see" and process at once—which includes both the input prompt and the model's generated output. Even Claude 3.5 Sonnet with its 200K token support or GPT-4 Turbo with 100K tokens, when converted into lines of code, amounts to only tens of thousands of lines—far from enough to cover the complete codebase of a mid-sized engineering project.

It's worth noting that the size of the context window does not equal the model's effective "attention" range. A 2023 research paper published by Stanford University, Lost in the Middle, found that when input content approaches the window limit, the model often exhibits "attention decay" for information in the middle of the window—if key information is placed in the middle of a long document, the model's accuracy in extracting and utilizing that information drops significantly, whereas information at the beginning and end of the document is better retained. This finding has direct practical implications for AI programming: when constructing prompts, the most critical constraints, interface definitions, and business rules should be placed at the beginning or end of the input, rather than buried in lengthy middle passages. Additionally, token consumption directly determines API call costs—in enterprise-grade AI programming projects, budget management for token consumption is itself an engineering decision that cannot be ignored.

The token consumption problem is especially pronounced in AI programming scenarios: a mid-sized project's codebase may contain hundreds of thousands of lines of code, far exceeding the context window capacity of existing models. This causes AI to often fall into an "information silo" dilemma when fixing complex bugs: it cannot see the full picture of the problem and can only make modifications based on local context that may trigger cascading errors. When AI persistently fails to fix a production failure, the entire project may stall as a result. This is one of the systemic shortcomings that Vibe Coding exposes in enterprise scenarios, and it's also why AI engineering-grade programming emphasizes modular design—breaking code down into small units that AI can fully understand is a key engineering strategy for circumventing token limits and improving the reliability of AI programming.

AI Engineering-Grade Programming: From Casual to Standardized

In response to the pain points above, the course's core proposition is: to shift from casual Vibe Coding to standardized AI engineering-grade programming. This is also the development approach that more and more enterprises are adopting, and the instructor believes it can solve the vast majority of practical problems in AI programming.

AI engineering-grade programming is not a concept that emerged out of thin air—it is a further evolution built on modern software engineering methodologies like DevOps and GitOps. DevOps emerged around 2009 (marked by the first DevOpsDays conference organized by Patrick Debois in Belgium), with the core philosophy of breaking down the organizational barriers between Development (Dev) and Operations (Ops), and achieving fast, reliable software delivery through continuous integration (CI), continuous delivery (CD), and infrastructure as code (IaC). Continuous integration requires developers to frequently merge code into the main branch and quickly detect integration issues through automated testing; continuous delivery further automatically pushes deployable software packages to production-like environments, making "always ready to ship" an engineering norm. GitOps is the extension of DevOps into the cloud-native era, using the Git repository as the single source of truth for system state, where all changes are triggered by Git commits into automated pipelines—Argo CD and Flux being typical implementations.

AI engineering-grade programming introduces a new layer of standards on top of this mature methodology: a human review process for AI-generated code (Code Review Gate), Prompt version management (bringing the prompts that drive AI code generation under version control to ensure the reproducibility and auditability of AI behavior), test coverage requirements for AI-generated code, and the unification of AI tool configurations in team collaboration (such as shared .cursorrules or CLAUDE.md configuration files to ensure all team members use the same AI behavior constraints). The concept of Prompt version management deserves special attention: in traditional software engineering, code is deterministic—the same input produces the same output—whereas the quality of AI-generated code depends heavily on the wording, structure, and constraints of the prompt, meaning that "Prompt Engineering" itself needs to be treated as a reproducible, auditable engineering artifact rather than an arbitrary exercise of personal experience. The essence of these standards is to treat AI as a team member that needs to be managed rather than a magic black box, requiring its output to meet the team's existing engineering quality standards, thereby truly incorporating AI capabilities into a manageable, auditable, and sustainably iterable engineering system.

The course uses a hands-on comparative design, clearly demonstrating the differences through two projects:

• E-commerce project: completed using the Vibe Coding approach, showcasing its applicable scenarios and boundaries;
• OpenRouter AI model aggregation platform: completed using the AI engineering-grade programming approach, simulating a real enterprise-grade development workflow.

OpenRouter is a representative choice as a hands-on course project—it is itself a routing platform that aggregates the APIs of multiple AI models, allowing developers to call mainstream models like GPT, Claude, and Gemini through a unified interface. Using it as the target, the course is effectively demonstrating how to build an AI infrastructure project with a certain degree of complexity using AI engineering-grade programming, rather than a toy-level demo.

This comparison is not a simple rejection of Vibe Coding, but rather a clear delineation of each approach's applicable scope: use Vibe Coding to boost efficiency on simple projects, while complex projects must return to engineering-grade standards, collaboration, and maintainability.

Recommendations for Tool and Model Selection

At the tool level, the instructor offered pragmatic selection guidance.

Choosing a Programming Tool

The course uses both Codex and Claude Code, but with Claude Code as the primary tool. Claude Code is a command-line-native AI programming tool launched by Anthropic, whose underlying models (the Claude 3.5/3.7 Sonnet series) are specifically optimized for code reasoning, long-context understanding, and following complex instructions. Unlike GUI tools, Claude Code can directly read the file system, execute shell commands, manage git operations, and call external APIs, building an "Agent-style" interaction mode that is closer to the real workflow of a senior developer—the developer describes the intent, and Claude Code autonomously plans the execution steps and completes multi-step tasks.

Behind this "Agent-style" interaction mode lies the core design philosophy of AI Agent architecture: transforming the large language model from an "oracle" of single-turn Q&A into an autonomous agent capable of perceiving the environment, planning actions, calling tools, and executing feedback loops. At the technical implementation level, AI Agents typically operate on the ReAct (Reasoning + Acting) framework—at each step, the model first performs reasoning (generating a chain of thought), then selects and executes a tool call based on the reasoning result, using the returned result as new observational input, looping until the task is complete. This paradigm allows AI to break through the limitations of a single inference and handle complex tasks that require multi-step information gathering and iterative decision-making. In software engineering scenarios, this means AI can not only generate code snippets but also proactively read error messages, search relevant documentation, run tests, and iteratively fix issues based on test results—forming a closed-loop autonomous development process. This is also the fundamental difference between Claude Code and traditional IDE plugins.

Codex is the product of OpenAI's earlier exploration of AI programming, initially released in 2021 and entering developers' daily workflows in the form of GitHub Copilot, focusing on real-time code completion and line-level suggestions within the IDE. Later, as foundation models like GPT-4o iterated, Codex's capabilities were significantly enhanced, and stronger autonomous execution capabilities were introduced in products like the OpenAI Codex CLI. GitHub Copilot currently has over 1.8 million paying users, making it the AI programming tool with the widest global user base, and its deep integration with mainstream IDEs like VS Code and JetBrains makes it a representative "zero-configuration, ready-to-use" product. The fundamental difference between the two lies in their target user positioning: Claude Code leans more toward deep integration and autonomous task execution in professional engineering environments, while the Codex ecosystem, thanks to the wide adoption of GitHub Copilot, is more suited to daily code completion and lightweight assistance scenarios, with a more mainstream user base. This also explains the technical logic behind the instructor's preference for Claude Code in enterprise-grade projects.

The instructor's own workflow is: use VS Code as the IDE, integrate the Claude Code plugin, and then use Codex in tandem. He also emphasized that tool selection varies from person to person—Cursor, ByteDance's Trae, and Tencent's related products can all do the job; what matters is personal usage habits and the team environment.

Backend Large Model Pairing

At the model level, the Codex backend prefers native GPT for the best compatibility; Claude Code correspondingly integrates its own models. Notably, in the course interactions, many students indicated they primarily use domestic large models like DeepSeek and GLM—the DeepSeek Coder series has already approached or even surpassed international models of the same tier on multiple code benchmarks, and Zhipu AI's GLM-4 series has also been specifically optimized for Chinese-language code scenarios. DeepSeek's rise is especially worth noting: the MoE (Mixture of Experts) architecture it adopts achieves code capabilities close to top-tier closed-source models while maintaining relatively low inference costs. The core idea of the MoE architecture is to group model parameters into multiple "expert" sub-networks, activating only a small portion of them during each inference (dynamically selected by a lightweight "router" network) rather than activating all parameters as dense models do. This allows the model to keep the actual computation per inference (i.e., the "activated parameter count") at a lower level even while having an enormous total parameter count, thereby striking a better balance between model capability and inference cost. DeepSeek releases its weights in an open-source manner, enabling domestic developers to deploy them in local or private cloud environments, circumventing the data privacy concerns of API calls—which is especially important for enterprise-grade AI programming scenarios. This phenomenon genuinely reflects the increasingly diversified state of model selection among domestic developers, and it also means that the battle over the "foundation model" behind AI programming tools is far from settled.

Viewing AI Programming Rationally: Tools Are Ultimately Just Tools

The greatest value of this course may not lie in the specific operational demonstrations, but in its rational positioning of AI programming. In an era where self-media widely exaggerate AI's capabilities, it reminds practitioners: AI programming is a powerful productivity tool, but it cannot replace engineering ability, architectural thinking, and accountability.

For developers who want to truly implement AI programming in enterprise environments, moving from Vibe Coding toward AI engineering-grade programming—deeply understanding the importance of standardization, team collaboration, and code maintainability—is the key step to letting AI truly drive complex projects.

Key Takeaways