中文 English

In May, I ran a small experiment. In my spare time, I mainly pair programmed with DeepSeek V4 Pro and built a 3D geometry processing application. During the last few days, Codex helped me with cleanup, refactoring, and final organization. Throughout the whole process, I basically only wrote requirements, made design decisions, reviewed results, and accepted or rejected behavior. I did not directly hand-write the business logic.

The project is called 3D Claw, and the code is open source:

https://github.com/tangtangtang1995/3D-Claw

This article is not meant to prove that AI can already replace programmers, nor is it trying to package some magical one-click development workflow. What I want to record is something more specific: when a person with some engineering experience really treats AI as a pair programming partner, what becomes fast, what still cannot be skipped, and what actually tests the human side of the process.

My Programming Background

If I count the patch-style development I did in the robotics team during my first two years of college, where I worked on electronic speed control and badminton trajectory detection, I have roughly more than ten years of C/C++ programming experience. During graduate school, I moved more toward algorithms, so my main languages became Python and MATLAB. After starting work, practical project requirements pushed me back toward lower-level knowledge, engineering details, and mixed-language programming.

I have always felt that programming languages are connected. Once you are familiar with C++, this “high-level assembly language,” it is usually not too hard to pick up interpreted languages. Of course, being able to write code and being able to write good code are two different things. With AI programming, that gap becomes even more obvious: you can quickly make AI write a piece of code that runs, but making it continuously produce code that can be integrated into a system, maintained, and evolved is not something a vague “help me implement this” can solve.

AI Pair Programming Is Not Wishing

In this project, I tried to follow a normal software development process, only in a lighter and more compressed form. The rough process included:

  • Product design description
  • Technical investigation
  • System design
  • Module-level design
  • Coding implementation
  • Single-point testing
  • Integration acceptance
  • System testing

Most of the documents and code were generated by AI, but AI did not decide the direction by itself. I would first state the goal, ask it to propose a plan, then review, question, reject, split, merge, and finally let it execute. I treated AI as a group of very capable engineers who still needed explicit management. You have to tell it where the boundaries are, which files can be touched, which interfaces must stay stable, which behaviors must be accepted, when to commit, and when to stop and review.

Architecture First

The early preparation was definitely architecture first. At the beginning, I directly asked AI to imitate the kind of hand-crafted architecture we used in the old days. Then I found that as the codebase became deeper, AI would start to lose control and damage the architecture. More precisely: as the codebase grew, AI gradually started solving problems by proximity. Wherever it was convenient, it added logic. Wherever it could grab data, it made a detour. In the end, system boundaries were slowly worn away.

There were also coding conventions, version control rules, and decisions about when to commit. I will not expand the detailed programming process here; that belongs to the earlier article. The key point is simple: as long as the architecture is still there, AI will not cause a major disaster. So later I made the rules much harder:

  • UI code must not directly touch heavy algorithm libraries
  • Algorithm capabilities must enter through the service layer
  • Configuration, execution, results, and status must be passed separately
  • Complex tasks must be split into small modules
  • A single function should usually stay under 200 lines
  • A single code file should usually stay under 2000 lines
  • Before every major change, AI must restate the current architecture
  • After every major change, AI must check whether it broke any boundary

The Core Knowledge for Working with AI

After this experiment, I found that the most useful knowledge in AI programming is not necessarily the kind of knowledge that appears most often in interviews.

Books like CSAPP, C++ Primer, data structures, algorithm design, and operating systems are of course important. They form the basic foundation of a programmer. But when pair programming with AI, AI often remembers more local knowledge than you do. Syntax, APIs, common algorithms, and library calls are usually things it can provide a decent starting point for.

What really creates distance is another kind of knowledge:

  • Large-scale C++ software development
  • The Mythical Man-Month
  • The Psychology of Computer Programming
  • Layering, boundaries, and evolution in software engineering
  • Requirement decomposition, acceptance criteria, and risk control

As for design patterns, I now feel they are not as magical as people sometimes imagine. The names of patterns are not the important part. What matters is whether you can identify where change may happen, control dependency direction, and make a module replaceable in the future instead of letting it drag down the entire project.

When programming with AI, the test is not “do you know this specific knowledge point?” The test is “can you turn a vague goal into engineering tasks that AI can reliably execute?” You are the system engineer, the project manager, and from time to time the client and the tester.

To put it plainly, you are negotiating with AI.

Is real-world project work not often like this too?

The Boundary of Algorithm Code

In the field of 3D data processing, I am fairly conservative about AI-written algorithm code: it can help a lot, but it should not be mythologized.

If the task is to call mature geometry libraries, such as Easy3D, CGAL, OpenGL, or ImGui, AI performs quite well. It can quickly build interfaces, pipelines, parameter panels, logs, status feedback, and visualization flows. As long as you clearly define the interfaces and acceptance criteria, it moves very fast.

But if the task is to write real geometry algorithms from zero to one, it becomes much more uneven. For example, when I asked it to compute the shortest point-to-point distance between two point clouds, it directly wrote a naive m * n double loop. The project already had a kdtree.h file, but it did not proactively think to reuse it. Only after I explicitly pointed out that this should use a KD-tree did it modify the implementation.

This is a representative example. It is not that AI does not know these things. It just does not always remember them at the right moment. It has knowledge, but not stable engineering instinct. It can generate locally correct code, but it does not always actively choose the best path inside the system.

So I let AI write code, but I must review the critical paths. I let AI propose plans, but I must make the architecture decisions. I let AI implement features, but the acceptance criteria must come from me.

Vague Requirements Create False Consensus

There is another problem with current AI programming: the same requirement may have completely different correct answers for different projects, different stages, and different developers.

When you say “help me add a feature,” AI does not know whether you want a temporary demo, a maintainable module, a production-level implementation, or a disposable script. It also does not know whether you care more about performance, clarity, interaction design, compatibility, or future extensibility.

If the requirement itself is vague, AI can easily produce a seemingly reasonable compromise. It writes smoothly, explains fluently, and may even make you feel that “we have reached an agreement.” But that agreement can be fake, because the constraints were never actually clarified.

Vague requirements produce vague probabilities. Vague probabilities often lead to muddy architecture.

AI is a reckless strongman with almost unlimited energy, if you have enough money. But in engineering projects, unconstrained AI is usually also a breeding ground for bugs.

Can Complete Beginners Use AI to Program?

I think the answer is yes, but expectations should be lowered first.

AI greatly lowers the threshold from zero to one. A person without much programming experience can now build a visible prototype much faster: a web page, a small tool, an automation script, a data analysis workflow, a small game, or even a simple app. This change is real, and it is valuable.

But AI has not removed the importance of engineering ability. It has only moved the bottleneck.

The old bottleneck was “I do not know how to write code.” The new bottleneck becomes:

  • I do not know how to describe the requirement
  • I do not know whether the code AI wrote is correct
  • I do not know where the security risks are
  • I do not know how to test it
  • I do not know how to split the project when it grows
  • I do not know how to roll back when the code breaks

So for complete beginners, I would suggest starting with small projects. Do not begin with a huge system. Start with something that has clear inputs and outputs, results that can be checked visually, and a failure mode that is easy to recover from. During the process, learn Git, learn to ask AI to write tests, learn to ask AI to explain what it changed, and learn to stop it when it starts making the project messier and messier.

AI can help you cross the syntax threshold, but it cannot take responsibility for judgment on your behalf.

Summary

The core of AI coding is not “wishing.” It is “organizing.” The real key is architecture.

You have to organize requirements, architecture, modules, commits, tests, and AI’s attention. It is powerful, but it is not a naturally reliable engineering team. The more clearly you can break the problem down, the more it feels like a superpower. The more you throw a vague cloud of ideas at it, the more likely it is to lead the project into a state that looks prosperous but is actually out of control.

The AI era will indeed bring opportunities to ordinary people, but that opportunity is not simply “people who cannot program can now write code.” More accurately, many people now have their first chance to push their ideas quickly into a runnable form, then learn engineering, product thinking, and systems thinking through real feedback.

That is probably what I like most about AI programming right now: it makes implementation faster, and it makes human judgment more important.