My AI Coding Experience: Three Principles
Table of Contents
AI Coding doesn't fundamentally make you a better programmer. It's an amplifier—amplifying your strengths and your weaknesses. Friends keep asking me about my Vibe Coding experience. My last small project got comments like “Not Even A Thing”—fair enough, it was small. I was mainly trying to share my thoughts on AI application architecture evolution. Different opinions are welcome; keeping an open mind is always good. But today I’m not really talking about Vibe Coding. I want to share my AI Coding practice. They’re different. In February this year, Andrej Karpathy coined “Vibe Coding” on Twitter, which later became Collins Dictionary’s Word of the Year 2025. His original words: “fully give in to the vibes, embrace exponentials, and forget that the code even exists.” Django co-creator Simon Willison offered a sharp distinction: “If an LLM wrote every line of your code, but you’ve reviewed, tested, and understood it all, that’s not vibe coding in my book—that’s using an LLM as a typing assistant.” I don’t fully agree with this distinction, but it’s still important. What I’m sharing here leans more toward the latter. The week ChatGPT launched three years ago, I had it write code and shared it on Twitter. I was stunned. But back then, there was no “Agent” concept—no CLI-based AI Coding Agents like Claude Code or Codex. All I could do was feed code snippets to ChatGPT, see its suggestions, and handle the integration myself. Then Cursor came along, embedding AI Coding into the IDE. Our team gradually adopted it, but the work remained local and well-defined: writing algorithms, unit tests, refactoring modules. For example, we migrated a large portion of GreptimeDB’s SQL test cases from DuckDB this way. Claude Code completely changed my perspective. Fuzzy idea? No problem—it helps you refine and plan in detail. It can implement entire projects: research, debugging, refactoring, documentation, testing, CI/CD—leveraging various tools to show what Agents can really do. When MCP came out, it got even better with richer data and more powerful tools. But honestly, before Opus 4.5, I completed many small projects with Claude Code and still hit frequent “context drift”—long conversation contexts triggered memory compression, and the model’s understanding, planning, and execution dropped significantly. A common pattern: I’d assign a difficult task, it would spend hours exploring code, researching, and writing detailed plans, then deliver something completely off track, often “pretending” to complete the task. My definition of this state: confident-sounding but unreliable under long context. Here’s a ridiculous example. I wanted Claude Code to integrate GreptimeDB into an open-source monitoring product—a complex task spanning two large codebases. It started confidently, spent hours exploring both codebases, and wrote a detailed integration plan. What did it deliver? A toy with mock data—all the critical integration logic was faked with hardcoded data. Anyone who’s practiced AI Coding has probably had similar experiences. Opus 4.5, Codex (GPT 5.1), and Gemini 3 changed everything. I fully embraced AI Coding and all AI applications—what I call the AI Native way of working. Using Claude Code + Codex, I’ve completed: GreptimeDB features: Vector index prototype, MySQL/PG protocol compatibility improvements (series of PRs like #7315), multi-language protocol and SDK tests—ranging from several thousand to over ten thousand lines of code. This is within a 500K-line Rust codebase. Now for any task, even if AI Agents don’t complete it entirely, I have them help with research, planning, test documentation, and final review. Side Projects (tens of thousands of lines): I’m also planning to update some open-source projects I maintain: JRaft, AviatorScript—ideas I never had time for can now be quickly implemented and validated. Through these projects, I’ve reached a fundamental conclusion: AI Coding doesn’t fundamentally make you a better programmer. It’s an amplifier—amplifying your strengths and your weaknesses. If you can’t do architecture well, can’t write good code and tests, you probably can’t judge whether its output is good or bad. Simon Greenman (MapQuest co-founder) made a similar observation: “AI may write the code, but experience still writes the system.” I don’t fully agree—to some extent, AI Coding Agents can help you even when you have no experience in a domain. Human and machine learn from each other. Based on this finding, I’ve summarized three principles: Before starting a task or project, define goals and scope as clearly as possible (unless it’s exploratory): Simon Willison recommends this approach: “For longer changes, it is useful to tell the LLM to write a plan. I iterate over it until it is reasonable and save it as a kind of meta program. Then I instruct it to implement it step by step.” A typical prompt example: Early strict requirements keep AI Coding within bounds, avoiding unnecessary exploration, token waste, and context pollution. Use design documents to judge and validate feasibility. Plan review is critical, especially for overall architecture and key data structures/algorithms. If something feels off, iterate through dialogue. This is why I keep saying: you need the ability to judge quality. Coding should follow your practices and preferences. I recommend Xuanwo’s AGENTS.md. Your project should bear your mark. But later in the project, once the framework works and tests are in place, loosen the reins and let the Agent explore: This often brings surprises—Agents can spot blind spots in your thinking. Which leads to the second principle— This is a highly effective method I discovered in practice. I haven’t seen this discussed much. The core idea: bring in third-party perspectives to review the project early (after high-level design) and late. Key points: Perspectives I commonly use: After several rounds of dialogue and iteration, you typically gain valuable insights and implementations. My understanding: third-party perspectives essentially compensate for single-conversation AI context limitations. It’s similar to traditional software development—we used to achieve this through specialized roles (PM, architect, test engineer, security expert each doing their part), now you can achieve it through LLM role-playing and conversation isolation. I expect this multi-perspective approach will eventually be automated at the Agent level (Multi-Agent playing different roles)—Agent evolution is fast. The industry already has multi-Agent review tools (like Endor Labs using Developer/Architect/Security Agents working together), but for individual developers today, manually starting new conversations and reviewing from different perspectives is more flexible and effective. Vibe Coding means complete trust—it’s “vibe programming” after all. But for serious projects, my principle is trust, never blindly follow. Andrew Ng (Google Brain co-founder) put it well: “In reality, coding with AI is a deeply intellectual exercise. When I’m coding for a day with AI coding assistance, I’m frankly exhausted by the end of the day.” AI Coding is exciting and exhausting—exciting because you can’t stop, exhausting because of the intense human-machine cognitive interaction. Practical approaches in three areas: Early project phase: Strict requirements and plan review are essential Implementation: Constantly require review. Humans review critical code; for overall review, let models cross-validate. I often have Claude Code write code and Codex do periodic reviews Codex excels at project design and code review—more thorough in depth and breadth, like a senior software engineer. Claude Code feels like an agile development believer—once there’s a rough plan, it starts building. Its Agent capabilities are strong, enabling fast iteration and delivery. They complement each other well. Test, test, test: Always require unit test coverage during implementation. Have the Agent set up automated CI/CD early and frequently verify CI passes. After core features work, add integration (black-box) tests covering main cases end-to-end TDD and Spec-First development are even more valuable in the AI Coding era: have the Agent write tests first, then implement. It’s fundamentally about applying constraints Record dev logs and update documentation: After the Agent completes a milestone, beyond passing CI and review, have it record dev logs and update documentation. This helps you track progress and, more importantly, provides context for future iterations Proactively refresh Agent memory: LLM memory state and context management still aren’t good enough. My experience: after complex task iterations, explicitly prompt the Agent to re-read AGENTS.md principles and historical dev logs. Don’t assume it remembers previous agreements—explicit reminders beat implicit expectations These are my personal experiences—not necessarily correct, and I’d love to discuss. Talking with colleagues about what AI Coding has brought us: Because of AI, I’ve also picked up writing again after a long break. Think about it—ChatGPT launched just three years ago. What’s happened in these three years is incredible. The 2020s will be a decade for the history books. Not embracing the AI Native way of working means falling behind. Let’s all become 100x engineers together.Vibe Coding vs. AI Coding
My AI Coding Journey
Projects I’ve Completed with AI Coding
My Core Finding
Principle 1: Tight First, Loose Later
I want to add pipeline management to GreptimeDB MCP Server:
- List all pipelines
- Create/delete pipeline
- Test pipeline (dry run)
First, research GreptimeDB's pipeline HTTP API (docs in /docs, source in /path/to/greptimedb),
then output a design proposal covering:
1. What new MCP tools to add
2. Parameter design
3. Error handling strategy
Also research similar intelligent logging features in the industry for reference.
Flag anything uncertain—we'll discuss.
Principle 2: Third-Party Perspectives
Principle 3: Trust, But Don’t Follow Blindly
Development Process
Quality Assurance
Context Management
Conclusion