周末,扯点AI Coding和人

周末,扯点AI Coding和人


On weekends, I force myself to break away from my usual rhythm. Thinking has always been more important than doing, and today, this is even more pronounced. Because of AI, "doing" is becoming less and less of a problem. However, many problems cannot be solved by simply extrapolating linearly along a single path.

Yesterday, I updated the fabric project, https://github.com/dmquant/fabric, mainly expanding the Cloudflare Worker endpoints. Some projects in Gemini Build require persistent storage that is session-independent. Therefore, I added app-level POST and GET requests and corresponding asset management. Meanwhile, I abstracted the app's own data structures—essentially markdown, json, html (js, ts, css), wav (mp3), jpeg (png), mp4, and csv. The worker handles storage and retrieval, while the app handles parsing. There's no need for a bloated software system; a simple, unified backend is enough.

Why is it that after decades of office automation, Microsoft Office remains the most convenient? Because as long as inputs and outputs are standardized, the rest should be left to human subjective initiative.

This is the first essence of AI-Native as I understand it: let the model provide maximum flexibility, and just manage the reading and writing for everything else.

At the same time, I have actually stopped using Claude Code and rarely use Claude models for coding. If needed, I use Codex, but my productivity has increased. A large portion of my work has shifted to Gemini AI Studio's "Build" (the name Build fits my habits well, though its prefix is a bit long to explain to readers). Especially after integrating the Cloudflare backend, it feels nearly omnipotent.

Build has taught me a great lesson: don't aim for all-in-one complexity. Every requirement originating from a real-world scenario can be simplified into a small tool, which can then be combined when the opportunity arises.

This is the second essence of AI-Native: reinventing the wheel for actual scenario needs—simple wheels, whether they are called APPs or Agents.

Yes, based on these two personal understandings (which may not be perfectly correct or comprehensive, but I'll leave "correct and comprehensive" to the teachers in the paid knowledge sector), I have taken a new "detour": I implement every idea into Build.

AI Coding is the ultimate productivity tool; it has almost completely transformed me and is changing more and more people.

But before diving into some new examples, here is a TL;DR:

AI Coding is suitable for everyone; it is an unprecedented "programming language."

However, not every model is suitable for everyone. Why is Claude considered the best programming model? Because it is the most "idiot-proof." You barely need any programming foundation to achieve results that closely match your needs. This isn't just the credit of the model itself; the Agent recipes contribute significantly. Some models, such as domestic ones like Kimi, Minimax, GLM, and QWen, have learned and expanded the "diligent" qualities of Agents, excelling in implementation frameworks and comprehensiveness, though they may lack slightly in specific content quality. Models like Gemini and GPT have huge potential; the more precise the requirements, the more "beautiful" the results—acting more like partners in exploration.

Therefore, if you want quick results, choose Claude. For variety, use domestic Agent-boosted models. For stable and reliable results under fine-tuned guidance, go with GPT or Gemini. For scaling, once a process is finalized using Claude/GPT/Gemini, deploying with domestic models is a more cost-effective approach.

Now, back to the "human" aspect.

Unchanged from traditional software development is the fact that all requirements come from actual scenarios. What has changed is that when we propose requirements, we no longer primarily need a programmer, but AI.

This is the point where I've always felt lucky: I am my own client and my own implementer.

However, I still follow a basic process: 1. Simple validation of ideas; 2. Design; 3. MVP implementation; 4. Design adjustment; 5. Repeated iterations; 6. Adding features; 7. Scaling.

This process isn't much different from basic software engineering, though it involves far less documentation, confirmation, and back-and-forth arguments.

In this process, just like in software engineering, many tools are needed: design tools, flowchart tools, document management tools, testing tools, and so on.

This is also the original intention of writing this article: although all mass-market tools are becoming AI-powered, when an organization shrinks to just one person, no matter how much AI is added to these tools, they fail to meet the needs. They have too many features designed for management and fewer and fewer features designed for actual "usability."

So, when I needed to draw flowcharts, I had Build create the following Canvas tool: hand-draw some sketches (the ones mostly covered up), write a few simple explanations, and let Nano Banana generate it in one go—with the ability to modify.

Yes, it wasn't built in one shot. I modified "counter-intuitive" functions as I discovered them through use.

Since I am the user and the developer, I can make it closer to my ideal tool while continuously optimizing my own workflow and habits.

Then, I export and feed it to Gemini-2.5-Deep-Thinking for design. This model, which won an IMO gold medal, is so far the only one that far surpasses others: it is accurate, restrained, does not overthink, and provides feasible solutions. It might actually possess "intelligence."

It far exceeds GPT-5-Pro.

Next, I need to edit and write documentation. I need AI editing features, multi-modal support, and the ability to embed JS code. Thus, the Editor was born.

2025-11-08-周末扯点ai-coding和人-1r9kqe-1771981322888-4057.png

2025-11-08-周末扯点ai-coding和人-1r9kqe-1771981322885-5706.png

There are a series of other tools related to research, photography, and video.

Whenever I have an idea, I first try to build a tool for it. This is my understanding of being AI-native.

Then, I push the tool forward to see how far it can go and how much capability it can carry. As I push, they inspire new ideas, allowing me to go back and modify old tools that were stuck or even reintegrate them.

I love this era—the era of AI Coding. It has nothing to do with APPs or Agents; it is only about the person, the ideas, and "pleasing oneself."

This is the simplest dream of being a lifelong programmer, planted over thirty years ago when I started learning programming and read Bill Gates' autobiography. Today, everyone can do it.

This is the best of times.

← Back to Blog