AI Coding Gone Wrong: A No-Code Writing Assistant and the Pitfalls to Avoid

Introduction: The Real Face of AI Programming

With social media flooded by videos claiming "just one prompt and AI builds your entire project," what does AI-assisted development actually look like in practice? A Chinese content creator answered this question with a full night of uncut, screen-recorded development — AI coding can indeed deliver working products, but things going sideways is the norm. What matters is whether you know how to get back on track.

The creator wrote zero lines of code, relying entirely on conversations with Claude to build an AI writing assistant in a single evening. Yet the process derailed three times: AI nearly deleted the project documentation, debugging a core feature ate up 20 minutes, and front-end/back-end communication completely broke down. Every crash and recovery was kept in the final cut, showing the unvarnished reality of Vibe Coding.

Vibe Coding is a concept coined by Andrej Karpathy in early 2025. It describes a paradigm where developers no longer write code line by line but instead describe requirements in natural language, letting AI generate the code while humans focus on review and adjustment. Karpathy — co-founder of OpenAI and former head of AI at Tesla — offered what many see as an honest boundary-setting for AI programming capabilities. It captures a development paradigm that is actively taking shape, one where the programmer's core skill shifts from "writing code" to "describing requirements" and "diagnosing problems."

Four Steps: From Idea to Working Product

Step 1: Document the Requirements

Turn the vague idea in your head into a structured requirement that AI can understand. The creator's original brief was extremely simple: "Build an AI writing assistant — paste an article on the left, pick a style, hit polish, and get the result on the right." From that single sentence, AI automatically generated a formal requirements document covering feature modules, interaction logic, and expected outcomes.

The key value here is that you don't need to know how to write a PRD (Product Requirements Document) — but you do need to be able to explain what you want in plain language. AI handles the translation from natural language to technical specification.

In the traditional software industry, a PRD is the product manager's core deliverable, typically containing feature descriptions, user stories, interaction flows, and acceptance criteria. Writing a thorough PRD can take days or even weeks. AI coding tools are reshaping this workflow, automating the high-barrier "requirements translation" work that used to fall on product managers. That said, humans can't fully step away — AI-generated requirements documents still need human review to ensure no critical edge cases or error-handling logic has been missed.

Step 2: Technical Architecture Design

Have AI produce a technology stack and architecture plan based on the requirements document: which frameworks to use, how modules interact, and how data flows. This step is essentially asking AI to play the role of a technical architect.

Step 3: Task Breakdown

Split the overall plan into specific, small tasks, each with a clear scope and definition of done. This level of granularity is the key to keeping AI on track — the smaller and more specific the task, the less room AI has to go off the rails.

Step 4: Code and Debug Task by Task

Have AI write code for each task in sequence, then run and debug everything together. This is exactly where things tend to go wrong.

Three Crashes and On-the-Spot Rescues

Crash #1: AI Wipes the Project Directory

AI has what the creator calls "an especially annoying habit" — the moment it starts working, it wants a clean slate and will casually delete existing files to get one. In this session, AI straight-up deleted an existing document. Luckily, the creator had a backup habit and was able to recover the file.

Lesson: AI has no respect for existing assets. It won't proactively determine which files are precious to you. Before starting any conversation, you must explicitly tell it which folders are absolutely off-limits.

Crash #2: A Top-Tier Model Spends 20 Minutes on a Basic Feature

The page finally loaded, but clicking the button did nothing. The front end and back end couldn't talk to each other — the browser was blocking requests outright. Even with the most powerful model available, debugging a basic cross-origin communication issue took a full 20 minutes.

The underlying issue here is CORS (Cross-Origin Resource Sharing), a fundamental browser security policy. When the front-end page and back-end API run on different domains or ports, the browser blocks front-end requests to the back end by default. This is extremely common in local development — the front end typically runs on localhost:3000, the back end on localhost:8000, and just the difference in port numbers constitutes a "cross-origin" request. The fix is to configure the back end to allow requests from specific origins, but AI-generated code frequently omits this configuration or produces a format that doesn't match the actual runtime environment. The difficulty isn't the code complexity — it's how hidden environment configurations can be.

Lesson: AI-generated code may run perfectly in isolation, but the moment cross-module communication is involved — CORS configuration, API routing, environment variables — it's extremely error-prone. This is one of the most common crash scenarios in AI-assisted development.

Crash #3: The Polish Feature Connects to the Wrong Service

The core article-polishing feature was wired to the wrong back-end service, causing it to fail completely. This type of error tends to be subtle — there are no visible code errors on the surface, but the actual logic is completely off.

Modern web applications typically use a decoupled front-end/back-end architecture, and the back end may be further split into multiple microservices, each with its own API address and port. Large language models work by predicting the next token based on probability — they don't truly "understand" the topological relationships between services. When a project contains multiple similar services, AI can easily mix up endpoint addresses. These errors don't trigger code-level exceptions and can only be caught by actually running the application and inspecting the returned results, making them among the hardest hidden bugs to track down.

Lesson: In multi-service architectures, AI easily confuses endpoint addresses and service names. Critical connection points must be manually verified.

Core Methodology: Setting Rules for AI

The most important takeaway the creator shared is this: Having AI write code isn't enough — you need to draw clear boundaries before it starts. This breaks down into three dimensions:

1. File protection rules — Specify which directories and files AI must never touch
2. Runtime mode constraints — Define which mode to use when launching during development
3. Dependency handling protocol — When something is missing, AI can't just forge ahead; it must "ask first" for confirmation

These rules matter more than how fast or how elegantly AI writes code. In the creator's words: "These rules are what give you the confidence to close your laptop and let AI keep running on its own."

At its core, this methodology echoes the concept of "defensive programming" in software engineering. In traditional development, senior engineers establish coding standards, set up protected branches, and configure CI/CD pipelines to prevent human error. In the AI coding context, the same defensive mindset is front-loaded into the prompt layer — you're not guarding against a teammate's mistakes, you're guarding against AI's mistakes, and the tool shifts from code conventions to natural language constraints.

How to Tell If an AI Project Video Is Real

This session also offers a highly practical framework: when you see someone post a video about "AI building an entire project automatically," how do you tell if it actually works or if it's just a demo with a few pretty screenshots?

Key criteria:

• Does it show the full debugging process?
• Does it involve real communication between multiple modules?
• Does it address environment configuration and dependency issues?
• Can the features be reproduced with real data?

If a video only shows "enter prompt → get finished product" with zero debugging in between, it has most likely been heavily edited or only shows the ideal path.

Conclusion: Setting the Right Expectations for AI Coding

This hands-on session delivers a pragmatic message: AI coding isn't a magic trick where one sentence produces a finished product. It's a collaborative model that requires humans to steer direction, set boundaries, and diagnose problems. Its value lies in dramatically lowering the coding barrier so that people who can't write code can still deliver working tools — but only if you know where AI is likely to drop the ball and how to prevent it in advance.

For readers looking to try Vibe Coding, start with small projects, build your own "AI rules template," and develop a habit of frequent backups. Crashing isn't scary — what's scary is crashing and not knowing how to pull the project back on track.