The Tide of AI Programming and the Engineer's Discipline

The strong pass is a wall of iron, / Yet today we stride across it, from the start. — Mao Zedong, “Loushan Pass” (to the tune of Yi Qin E)

Author’s note: This is the transcript of a livestream I gave last week to open the second cohort of my AI bootcamp on Geek Time. If you’re interested in the bootcamp, scan the QR code at the end of this post.

Over the past two years, I’ve gone from a paying Cursor user to a heavy user of Claude Code, and I’ve pushed AI coding tools hard inside my company, turning them from a “novelty toy” into a primary production tool. Along the way, I watched AI programming evolve from a concept everyone scoffed at into a historical tide that every engineer and every company must now take seriously.

This essay is a systematic summing-up of that journey. No fluff — just substance.

1. Reading the Situation: The Spark Has Become a Prairie Fire

In early 2025, when Karpathy coined “Vibe Coding,” it was still a rudimentary concept — people used it to spin up a few flashy web pages, found it amusing, and stopped there. The vast majority of practitioners dismissed it: how could a serious system be written by AI?

Less than a year later, everything has been turned upside down.

Today we can already use AI to generate the infrastructure code for an entire software system, driving the full development pipeline from backend to frontend, from serverless architectures to traditional service architectures. We have a complete set of infrastructure code generated entirely by Claude Code, deploying heavily to production every day — all of it AI-driven.

This is no longer cocktail-party chatter. It is reality, happening now.

In my view, within the next 6 to 18 months, AI programming will become the mainstay of programming. Human engineers will concentrate on defining problems, choosing among options, and final acceptance, while the actual coding will increasingly be handed to AI. The mainstream workflow will become: human defines the problem → AI proposes several options → human picks a direction → AI executes the coding → human reviews and accepts.

This shift isn’t somewhere over the horizon; it’s already underfoot.

2. The Revolution in Trial-and-Error Cost: From General-Purpose to Disposable

Why is vibe coding bound to become the trend? It comes down to a fundamental economic question — the cost of trial and error.

In the past, building a new product or validating a new idea was extremely expensive. You needed a team of five to ten people — ops, backend, frontend, maybe even a machine learning engineer — spending three to six months to get the idea to a verifiable stage. If the product failed, the entire investment went down the drain. That made trial and error in software engineering extraordinarily costly, and many good ideas died in the cradle as a result.

With vibe coding, everything is different.

I have an idea, or I spot an interesting product on the market; I can tell Claude Code directly and have it generate a complete product for me, backend to frontend. I don’t even have to care about its code quality — this is throwaway software, and all I want is to validate my idea. Ship it, let a small group of people try it and give feedback; if the direction holds up, build version two properly; if not, drop it decisively — the loss is negligible.

Fail fast, build fast — that is vibe coding’s greatest contribution to innovation.

Of course, we must look at things dialectically. For user-facing core products, you need rigor; for infrastructure changes, you need sufficient review. But internal systems — especially tooling built for developers or small groups — can absolutely be given free rein to experiment. From what I’ve observed, vibe coding is already being used heavily in many companies’ internal systems, alongside localized experiments in user-facing systems. Internal first, then gradually outward — that’s the prudent path.

3. AI Is the New Compiler

January of this year was a fascinating month. Torvalds, the father of Linux, and Antirez, the father of Redis — the most senior engineers in the industry — both began embracing vibe coding and spoke positively about it. Torvalds even said: AI is the new compiler.

That analogy is remarkably apt.

Early in my career, I wrote a great deal of assembly. Engineers in the ’60s and ’70s had only one programming language: assembly. When compilers arrived, they could write in higher-level languages and no longer had to hand-craft assembly. Many programmers at the time were bewildered: if I write code in a high-level language, am I still a serious developer?

History repeats itself with striking fidelity. AI now occupies the compiler’s ecological niche — it “compiles” our natural language into the corresponding programming language. English and Chinese will both become new ways of coding.

In terms of efficiency, this is a massive leap. A human engineer, no matter how clear the architectural vision or how well they know every next step down to the last detail, still finds writing thousands or tens of thousands of lines of high-quality code in a day extremely taxing. Vibe coding, by contrast, can produce thousands of lines for you within an hour.

4. A Dialectical View of AI’s Capabilities

This raises a core question: how do we guarantee code quality?

AI is a fascinating existence. It possesses the knowledge of the entire world, and its brain capacity exceeds that of any senior engineer on earth. Yet when it performs a concrete task — because only a subset of its parameters are activated to complete the current task (this is how today’s mainstream mixture-of-experts architectures work), and because it is hyper-focused on that task — it falls into a kind of tunnel vision. Like a person inside a tunnel, seeing only the patch of light ahead.

So you often find: to fix one defect, AI fixates on the immediate problem and introduces new ones; the code it writes is not high quality, the architecture unreasonable. It commands all the world’s knowledge, yet when handling a concrete problem it behaves like a junior engineer — writing unreliable code.

But this isn’t AI’s problem; it’s our failure to activate its capabilities properly.

When you, as a senior engineer, give it good enough context — tell it what you want to build, tell it not to rush into coding, ask it to discuss the design with you first and offer several options for you to choose from — in many cases you don’t need to teach it hand-in-hand the way you’d mentor a newcomer. For instance, if AI proposes a plan and you don’t think it’s good enough, simply saying “a Bloom filter would be better” is enough. You don’t need to explain what a Bloom filter is, or list the good libraries in your language of choice — AI already knows and will go find them. Tell it to design the system with SOLID principles, tell it to use the observer pattern for inter-module relationships, and it grasps it instantly, delivering a design that is completely different and far more beautiful.

So we must see both sides: on one hand, AI’s brain capacity exceeds any senior engineer’s; on the other, without the right guidance it flails about like a novice. At this moment, the engineer’s own taste, cultivation, architectural ability, and design ability become more important than ever before.

In my two years of continuous experimentation, one discovery stands out: the stronger an engineer’s ability, the greater the productivity boost AI gives them. Because when the architecture is right, however badly the code is written, it lands roughly in the right ballpark; when the architecture is wrong, with race conditions introduced everywhere, no matter how elegantly each line is written, you can’t escape the trap of patching patches over patches.

5. Spec-Driven Development (SDD): Giving AI a Map

If AI is the executor, who makes sure it doesn’t go off course? The answer is the spec document.

When you ask AI to build a subsystem, if you just tell it to start writing, it may produce something chaotic with no clear goal. But if you have it first write a product requirements document for the subsystem, and then you review every item — which to keep, which to drop — discussing back and forth until it’s finalized; then have it write a technical design document based on the requirements, specifying your technical preferences (which network framework, which database access layer, how to handle concurrency), and then you carefully review whether its data structures, public interfaces, and architecture are sound.

This entire process is like a conversation with a colleague. You don’t directly rewrite their proposal; you raise comments on it, let them revise, review again, and finally sign off. After sign-off, the rest is mechanical and tedious — have it implement the design stage by stage, and after each stage run the build, formatting, static checks, and tests, proceeding to the next stage only when everything passes.

Once all stages are complete, use another AI (say, Codex) to do code review — note that it’s best to develop with vendor A’s model and review with vendor B’s model, because reviewing your own work, just like with human engineers, tends to miss deep problems. Then work through the issues found in review one by one, and finally submit the pull request.

Isn’t this exactly the process a human team uses for projects? Requirements doc → design review → staged implementation → code review → testing and acceptance. We’ve merely transplanted the entire logic of human collaboration onto the logic of human-AI interaction.

Whether an AI tool succeeds comes down to one core factor: can you get the AI tool to run the same processes that people used to run inside your company?

6. Verification: The Last Mile

A good spec document is the “entrance”; good verification is the “exit.” These two steps, I believe, are the most critical links in the entire process.

The verification I’m talking about isn’t just unit tests and integration tests — it’s putting the product into real scenarios and letting AI drive it to verify.

If it’s a command-line tool, have AI execute every subcommand with every parameter; if it’s an API service, have AI run through the complete workflow; if it’s a product with a frontend, have AI drive Playwright to open the browser, navigate to the relevant page, perform the new feature’s operations, take before-and-after screenshots, and analyze whether the design has been reproduced pixel-perfectly. Mobile is the same — both iOS and Android have simulators, and AI should drive them to do similar verification.

Only in this way can AI control the entire development process end to end, and the mental burden on the humans reviewing code be reduced to a minimum. When submitting the pull request, attach key screenshots and recordings of the whole verification process, and the reviewer’s confidence will be far higher.

This area will become an important research direction this year. How do you provide AI with an environment it can freely operate in, so it can complete all the work within that environment? How do you do complete end-to-end verification across a chain of microservices? How do you isolate AI’s staging environments to avoid interfering with one another? These questions all deserve deep thought.

7. The Agent Era: Everyone Is a Manager

We are currently in the era of agent orchestration. Various agents handle execution-level work for us, while we mostly convey intent to the agents, letting them use skills, tool protocols, command-line tools, and the like to keep closing in on the goals we’ve set, ultimately producing a complete pull request for a human to accept.

If your ecosystem has project management software with a command-line interface and a code repository with a command-line interface, that means agents can automatically pull the latest unprocessed tickets from the project management software, analyze which user story they can handle, generate a design document for engineers to review, start executing after approval, and submit a pull request via the command line when done. All of these interactions can be automated.

The entire work paradigm is changing: everyone used to be an individual contributor; now everyone is becoming a manager — except the people you manage are agents. Whether you can orchestrate them well is your core competitiveness.

And as a manager, you have to take ultimate responsibility. Don’t understand infrastructure? Learn it fast. Were a frontend engineer, now you need to do backend? Catch up quickly. Tomorrow’s engineers are end-to-end; there will be no more fine-grained division into ops, frontend, backend — there’s only one question: here is an unsolved problem, can you organize your army of AI agents to get it done?

8. Tool Protocols and Skills: Quality Over Quantity

On tool selection, let me address a problem that is widely misunderstood today: not everything should be turned into a Model Context Protocol (MCP) server.

MCP carries a significant cost — when you install too many MCPs into Claude Code or other agents, they devour a large amount of the precious context window, leaving very little context actually available for coding. That is deeply detrimental to coding agents.

My criterion is simple: if a tool is only used locally alongside the agent, doesn’t depend on a centralized database, and doesn’t need remote support, then make it a command-line tool wrapped as a skill rather than an MCP. Tools like Playwright and simulators that are only used in the terminal should absolutely be done as CLI plus skill.

MCP is appropriate when: you’re providing capabilities to another company, or when there are many internal users and you need centralized database support.

A skill has both a tool aspect and a knowledge aspect. The tool aspect wraps command-line invocation capability; the knowledge aspect provides methods and workflows for handling specific matters. These things will not die out as models improve — on the contrary, the richer the tools and the better the environment you give the model, the stronger the whole system becomes. Models and tools are complementary, not substitutive.

9. The Engineer’s Path of Cultivation

For senior developers, you need sharper judgment at the architectural level and in choosing direction, using your taste to govern the quality of AI output, and relying on accumulated knowledge and experience to spot problems.

For developers just starting out, you need to rapidly level up your software cultivation — underlying principles, technical terminology, architectural patterns, all must be grasped quickly. At the same time, don’t rely entirely on AI; keep a certain amount of handwritten practice on core data structures and algorithms. This process helps you develop taste and feel for code — let AI do 80% of the work via vibe coding, and reserve 20% of your time for manual practice. That ratio is healthy.

Whether you’re senior or a beginner, a few things are universal:

First, stay curious. When you encounter something interesting, dig to the bottom of it — how is it actually implemented underneath? In the past, sustaining this curiosity was expensive: you had to read docs line by line, read code, and try again and again. Now you can hand it entirely to an agent — have it read the code for you, map out the architecture, peel back layer after layer to understand the details. The threshold for curiosity has never been lower; there’s no excuse not to keep it.

Second, learn how to learn. Software development will only iterate faster; agents may at any moment throw at you a concept, framework, or dependency you don’t understand. Can you quickly use deep research tools to figure out what it is and why you’d use it? That learning ability will be a core competitiveness in the future.

Third, don’t chase surfaces — grasp the essence. Take SDD alone: there are no fewer than ten highly ranked frameworks on GitHub, and more keep coming. Rather than exhausting yourself chasing them, whenever something new appears, pull it down and have an agent analyze it for you — what technology it uses underneath, what capabilities it offers, what its essence is — then absorb the parts that benefit you into your own workflow.

Every person, every team, every company has its own “national conditions.” A big, all-encompassing framework on the market may not fit your immediate needs. What you need to build is your own workflow for using agents.

10. Conclusion: From Craft to Industrial Production

Programming used to be a craft; henceforth it will become more like industrial production — vast numbers of agents producing vast amounts of code every day, with the quality of that code governed by us.

In this transformation, two things must not be lost:

First, reverence for quality. We cannot discard our grasp of underlying logic. A good engineer, encountering a new system, always asks: how is it implemented underneath? This curiosity that digs to the root, this relentless pursuit of fundamental principles, is the most precious quality for engineers in the AI era. Only thus can you hold the bottom line of code quality.

Second, human reason and aesthetics. Don’t get lost in the thrill of automation. We need to inject our taste and aesthetics into the software we build. AI gives us tenfold or a hundredfold efficiency, but efficiency is a means, not an end. The sole purpose of the software industry is to build genuinely good software products, solve real problems, and serve real users.

The enduring path of software development lies in understanding essence rather than chasing trends. Figure out the underlying principles of every new thing, and turn the beneficial parts into your own nourishment — that is the path that goes far.

Paths are made by walking. In the flood of AI, walking your own path is the only true way.