A Beginner's Real Experience with AI Programming: Will Programmers Be Replaced?

Introduction: When a Complete Beginner Meets AI Programming

In an era where AI tools are everywhere, can an ordinary person with virtually no programming background use AI to complete a real hardware project? A Bilibili content creator shared a firsthand experience that's both inspiring and sobering.

His goal seemed simple: use an ESP32 microcontroller to build a Nasdaq display that automatically turns on when the U.S. stock market opens and goes to sleep when it closes. The ESP32 is a low-cost, low-power microcontroller chip developed by Espressif Systems, featuring integrated Wi-Fi and Bluetooth. It's extremely popular in maker communities and IoT projects. Priced affordably (usually under 30 RMB), it has a mature development ecosystem supporting Arduino IDE, MicroPython, and other development environments. With its dual-core processor, rich GPIO pins, and multiple communication interfaces, it can drive displays, sensors, and other peripherals while fetching real-time data over the network. For this Nasdaq display project, the ESP32 needed to connect to the internet via Wi-Fi to retrieve stock market data while controlling hardware peripherals like a display and buzzer.

However, this project that seemed like it could be "done with a few lines of text" turned into a prolonged tug-of-war with multiple AI tools.

One Project, Four AI Tools, a Full Day of Struggle

Doubao: Crashed at the Starting Line

The author first chose Doubao as his programming assistant. Doubao could indeed teach him how to wire the ESP32 and generate code, but the problem was code quality — when copied into the IDE and compiled, it threw errors immediately. After asking Doubao to fix it, errors persisted. This exposed a typical weakness of general-purpose AI in embedded development: it might "know" what an ESP32 is, but lacks precise control over specific hardware connections, pin configurations, and other details. Embedded development differs from pure software programming — it requires code to strictly match specific hardware models, firmware versions, and pin definitions. Any detail mismatch leads to compilation failures or runtime anomalies.

Google AI: Runs but Has Bugs

After switching to Google AI, things improved — at least the program could run. But new problems emerged: the buzzer kept buzzing non-stop. The author repeatedly sent error messages to the AI for fixes, going through many iterations, but the problem persisted. This shows that when AI handles hardware-level debugging, it often falls into a "treating symptoms, not causes" loop, unable to fundamentally locate the problem. AI can only see code text — it can't "see" the actual physical wiring. So its fix suggestions are always limited to the software layer, while the real problem might be in the hardware connections.

ChatGPT: Also No Solution

With a "let's try a different tree" mentality, the author tried ChatGPT, with equally unsatisfying results. By this point, from wiring to repeated back-and-forth communication and fixes, an entire day had been consumed. The author lamented: if he knew programming, he probably would have finished long ago.

Cursor: Finally the Right Tool

The turning point came with a professional code editing tool recommended by ChatGPT — Cursor. Cursor is an AI-native code editor built on the VS Code architecture, developed by Anysphere. Unlike general-purpose chat AI, Cursor deeply integrates large language models into the code editing workflow, with awareness of the entire project's file structure, dependencies, and context. Its core advantages include: the ability to read and understand all code files in the current project rather than just processing code snippets pasted by users; presenting modification suggestions in diff (difference comparison) format so users can review AI changes line by line; and supporting multiple AI models with specialized optimization for code generation scenarios.

The author pasted in the buggy code, and the tool immediately pinpointed the root cause — the buzzer was connected to 5V, when the correct approach is to connect it to 3.3V; otherwise, it would buzz continuously as soon as power was on.

This diagnosis involves a key embedded development concept: ESP32's GPIO pins operate at 3.3V, with digital output high level at 3.3V, and input pins can only handle 3.3V signals. When a buzzer is directly connected to a 5V power supply, if it's an active buzzer (with a built-in oscillator circuit), it will sound continuously as long as power is applied, making it uncontrollable via ESP32's GPIO. The correct approach is to connect the buzzer to 3.3V or power it through a GPIO pin, allowing the ESP32 to control the buzzer's on/off state through high/low level switching. This type of voltage matching issue is extremely common in embedded development and is a typical hardware problem that pure software AI struggles to diagnose — because from a code logic perspective everything looks correct, with the problem existing at the physical wiring level.

This diagnosis was eye-opening. A hardware connection problem that three general-purpose AIs failed to identify was spotted immediately by the specialized tool. After rewiring according to its suggestion, the buzzer problem was indeed resolved. Subsequent WiFi code optimization was also completed one by one, with efficiency far exceeding all previously used AI tools.

However, the tool's free quota ran out quickly, and it refreshes weekly rather than daily, forcing the author to return to the less efficient Google AI to continue development.

The Biggest Pitfall of AI Programming: Silently Deleting Your Features

Throughout the development process, the author discovered a problem more troublesome than error messages: when AI helps you add new features, it silently deletes or simplifies existing ones.

For example, the WiFi login page was already working, but when asking AI to add other features, it would delete or break previously functioning modules while adding new code. This means every version of code needs complete testing to confirm whether all old features are still working properly.

This problem has deep technical roots. Current large language models have a structural issue when generating code: although their attention windows (Context Windows) keep expanding (from the initial 4K tokens to today's 100K or more), they still tend to produce "coherent" new output when generating long text, rather than making minimally invasive modifications to existing code. This relates to how models are trained — they're trained to generate complete, self-consistent text sequences, not to perform precise text editing operations. In professional development, programmers use version control systems like Git to track the change history of every line of code. Any modification exists as an "incremental patch" that can be precisely traced and reverted. General-purpose AI lacks this incremental thinking, tending to output a "complete version" with each response, easily omitting or simplifying previous functional modules in the process.

The author had to adopt a "crude method": saving every working version of code in a Word document. When AI broke the code beyond repair, he would retrieve code from previously stored old versions and have AI modify based on the old code. While this method seems primitive, it's essentially manual version control — the author achieved with Word documents what professional programmers do with Git.

This problem reflects a core limitation of current AI programming — lack of global code management awareness. AI tends to "rewrite" rather than "incrementally modify" with each change. It won't carefully touch only the parts that need changing while ensuring other modules remain unaffected, as an experienced programmer would. This is also why professional tools like Cursor use diff mode to display changes — through tool-level design, it forces AI to work incrementally, letting users clearly see which lines were added and which were deleted.

Understanding AI Programming's Capability Boundaries from This Experience

What AI Programming Can Do

Lower the programming barrier: People with zero background can indeed complete actual projects with AI assistance
Accelerate simple tasks: Generating basic code frameworks, explaining error messages, optimizing local code
Specialized tools outperform general AI: Tools optimized for programming scenarios (like Cursor) perform far better than general-purpose conversational AI. The root of this gap lies in specialized tools having complete project context awareness, while general AI can only reason based on code snippets pasted in conversation

What AI Programming Still Can't Do Well

Hardware debugging: When physical connections and voltage matching are involved, general AI tends to be "armchair theorizing." AI can't "see" actual circuit connections — all its reasoning is based on text descriptions, while hardware problems often require physical tools like multimeters and oscilloscopes to diagnose
Code integrity maintenance: Breaking old features when adding new ones is currently the most dangerous trap in AI programming. In software engineering, these are called "Regression Bugs," which professional teams prevent through automated test suites. But AI currently won't proactively write and run tests for existing features
Root cause analysis of complex problems: Facing recurring similar errors, AI easily falls into ineffective loops. It lacks the ability to "step back and think," and won't question the premise assumptions of a problem (like "maybe the problem isn't in the code at all, but in the hardware wiring")

Will Programmers Be Replaced by AI?

The author offered an interesting judgment: Programmers will be replaced by AI, but not this year — maybe next year or the year after.

This judgment is both optimistic and pragmatic. From this experience, the evolution speed of AI programming tools is indeed astonishing — from Doubao's "compilation errors everywhere" to Cursor's "instantly identifying hardware problems," the capability gap is already very apparent. But currently, AI still needs humans for "quality control" and "version management," which happens to be one of programmers' most core competencies.

More precisely, AI won't replace programmers but will redefine what programmers do. Future programmers may no longer need to write code line by line, but will need capabilities in architecture design, code review, system integration, and debugging — precisely the areas where current AI is weakest. Historically, every evolution of development tools (from assembly language to high-level languages, from hand-written code to visual development) never eliminated programmers but pushed their work toward higher levels of abstraction. AI programming tools will likely continue this trend.

Practical Tips for Beginners Who Want to Use AI for Programming

Choose the right tool: Professional AI programming tools (like Cursor) perform far better than general-purpose chat AI. Other noteworthy specialized tools include GitHub Copilot, Windsurf, etc., all deeply optimized for code editing scenarios
Practice version management: Save backups of every version of code that runs properly. If you're willing to learn one more step, look into basic Git usage (init, add, commit) — it's more professional and reliable than Word documents
Iterate incrementally: Don't submit too many requirements at once; change only one feature at a time. This way, even if AI introduces a problem, you can quickly identify which change introduced the bug
Learn to verify: Every version of code from AI needs complete testing, with special attention to whether old features have been broken. Create a simple test checklist and check each item after every modification
Understand fundamental principles: Even if you can't write code, understand basic hardware knowledge and programming logic to communicate more effectively with AI. For ESP32 projects, at minimum understand GPIO, voltage levels, serial communication, and other basic concepts — this knowledge helps you describe problems to AI more accurately