What I’ve Been Working On

I am currently preparing to open-source a system of experiences on “how to teach AI effectively,” which has led me to restart several projects. So far, the codebase has reached 98,800 lines. This is no longer a “toy project” phase; it has entered a typical medium to large monorepo scale, and it is far from being completed.

This means that the real challenge ahead is not just “Can I write it?” but rather:

• Can I sustain progress?
• Can I iterate stably?
• Can I maintain low-friction collaboration and low-loss decision-making as complexity increases?

The Real Issue: It’s Not About Writing Code

As project complexity increases, documentation management, code management, and project iteration will reach a tipping point.

One real issue I often encounter is that after being interrupted, it becomes difficult to re-enter the project state the next day without friction.

Many might say: “Isn’t AI available now? Why is there still work friction?”

My answer is: because real projects are not linear.

On one hand, I actively break the project into multiple modules for independent maintenance and development. This significantly enhances the system’s scalability but also brings more state-switching costs.

On the other hand, a project from requirement definition → solution selection → development → testing and acceptance is never a one-way process.

Problems discovered at later stages can directly overturn judgments made at earlier stages.

Thus, AI can enhance efficiency, but it cannot eliminate complexity.

What truly determines whether my project can be sustained is whether I have established a management mechanism to combat complexity.

My Solution: Introducing Two Core Methods

During development, I gradually introduced two core methods:

1. Use engineering control principles to establish standards for different stages.
2. Visualize these standards in the testing and acceptance phase using Kanban.

In other words: first, make the project “standardized,” then make the project “observable.”

Method One: Establishing a Closed Loop for AI Projects Using Engineering Control

Many AI projects initially struggle not because the model isn’t strong enough, but because the system hasn’t been designed as a system.

If you only focus on whether “it answers correctly,” you only see the result; but if you view the project from a control theory perspective, you will start to pay attention to inputs, states, feedback, disturbances, and constraints.

I now require myself to do at least the following 10 things:

1. Draw the closed-loop diagram of the AI system.

   Break the system down into: inputs, states, outputs, feedback, disturbances, and constraints. Only by visualizing the closed loop can you identify whether the issue lies in prompts, context, retrieval, memory, or execution links.

2. Define five core metrics.

   I focus on these five: success rate, time cost, stability, user correction frequency.

   For AI systems, “answering correctly” is merely the minimum standard; true product quality comes from overall operational quality.

3. Classify errors for failed cases.

   Don’t just write “answered incorrectly.” Keep asking: Is it a comprehension error, retrieval error, memory pollution, tool invocation error, or context window degradation? Only by classifying errors can optimization be targeted.

4. Add noise filtering layers for context, memory, and retrieval.

   As AI projects progress, the biggest fear is not a lack of information, but an excess of dirty information. Context pollution, outdated memories, and low-quality retrieval results can lead the system off course.

5. Set fixed review cycles.

   Reviews cannot rely on mood. If reviews are done only when thought of, they will likely always be postponed for more urgent tasks. Thus, I treat reviews as a systematic action rather than a personal will.

6. Separate different operating conditions.

   Do not hide all issues under an average score. The same AI system may perform entirely differently in high-frequency short tasks, long-link tasks, and multi-turn interactive tasks. Without separating operating conditions, conclusions will be distorted.

7. Upgrade in small steps.

   Change only 1 to 2 major variables at a time. Otherwise, if results improve or worsen, you won’t know where the influence came from.

8. Allow exploration, but set boundaries.

   AI projects need an exploration mechanism; otherwise, they will never evolve. But exploration must have safety boundaries and rollback mechanisms; otherwise, the system may become uncontrollable due to “over-innovation.”

9. Monitor delay, not just accuracy.

   Many projects only focus on accuracy, ultimately creating a system that is “very accurate but no one wants to use.” User perception often begins with delay.

10. Enable AI to not just answer questions but to correct processes.

A truly mature AI system should not merely be an “answering machine” but should gradually possess the ability to adjust its processes based on feedback.

Method Two: Making the Testing and Acceptance Process Kanban Instead of a Memory Game

What significantly reduced my work friction was not writing more documentation, but transforming the acceptance process into Kanban management.

Once a project becomes complex, the biggest fear is that things are progressing, but the status is invisible; tasks are flowing, but responsibilities are unclear; problems are discovered, but have not entered a stable closed loop.

Thus, I break the testing and acceptance phase into four fixed Kanban sections:

My Four-Stage Acceptance Kanban

Automated Testing Acceptance

This is the first layer of the filter. The goal is not to prove that the system is “very strong,” but to first prove that it is not easily broken. Automated testing addresses underlying stability issues, preventing obvious errors from flowing into subsequent stages.

Internal Demonstration

This is the second layer of validation. The value of internal demonstrations lies not in “showing results,” but in forcing oneself to answer three questions: What problem does this solve? Is this process smooth enough? Can this solution truly be understood and reused by others?

Many designs that seem valid in one’s mind will be exposed during a demonstration.

Small-Scale Testing

This is the third layer of calibration. At this stage, the focus is not on “pursuing perfection,” but on collecting real user feedback. You will find that many designs that seem reasonable during development can be quickly dismantled by real users. This step is essentially injecting real-world disturbances.

Public Production

This is the fourth layer of implementation. Only when it reaches public production does the system truly enter a complete operating condition. You will see performance pressures, abnormal inputs, edge cases, and long-term stability issues arise together.

This is why I increasingly believe that the maturity of an AI project is not about whether it can run, but whether it can be continuously operated.

Why Kanban Management is Particularly Suitable for Vibe Coding

Vibe coding often gives the impression that as long as the rhythm is right, the feeling is good, and the AI cooperates smoothly, the project will naturally grow. However, my experience is quite the opposite:

The more reliant the development method is on creativity and rapid iteration, the more structured project management is needed.

The advantage of Vibe coding lies in high fluidity, and the problem arises precisely from high fluidity. Without a clear Kanban system to accommodate these flowing ideas, tasks, conclusions, and rollback actions, inspiration will ultimately turn into fragments. For me, Kanban is not an “administrative tool” but an external brain that reduces cognitive switching costs. It solves at least three issues: it lets me know the current state of the project; it tells me what the next most important task is; and it helps me quickly restore context after task interruptions.

These three issues are precisely where complex AI projects are most prone to losing control.

My Interim Judgment

When the project scale is small, personal ability can cover everything. But once the project enters the medium to large monorepo range, project management itself has become part of product capability.

At this stage, what truly matters is not “writing a bit more,” but rather:

• How to make complexity visible;
• How to maintain a rhythm in iteration;
• How to ensure feedback can close the loop;
• How to shift the project from “driven by individuals” to “driven by systems.”

This is also why I have become increasingly convinced:

The core competitiveness of AI projects is ultimately not how fast the model can respond, but how stable the system management is.

Conclusion

If you are also working on AI projects and have entered a development state with multiple modules, stages, and feedback loops, please do one thing as soon as possible: upgrade your project from being “driven by feelings” to being “driven by Kanban and closed loops.”

Why?

Because when the system becomes complex enough, intuition will fail; only engineering order can be the truly reliable productivity.

So my advice is simple—establish your order, even if it starts with a Kanban or a review loop.