<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>AI-Assisted Development on Chuanxilu for Skilled Homo sapiens</title><link>https://blog.chuanxilu.net/en/tags/ai-assisted-development/</link><description>Recent content in AI-Assisted Development on Chuanxilu for Skilled Homo sapiens</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Fri, 01 May 2026 10:00:00 +0800</lastBuildDate><atom:link href="https://blog.chuanxilu.net/en/tags/ai-assisted-development/index.xml" rel="self" type="application/rss+xml"/><item><title>The Bug Loop You Can't Escape: Root Cause Diagnosis with AI</title><link>https://blog.chuanxilu.net/en/posts/2026/05/ai-bug-root-cause-diagnosis/</link><pubDate>Fri, 01 May 2026 10:00:00 +0800</pubDate><guid>https://blog.chuanxilu.net/en/posts/2026/05/ai-bug-root-cause-diagnosis/</guid><description>Fix #13, and old bugs come back. This isn&amp;#39;t a &amp;#34;how I fixed a bug with AI&amp;#34; anecdote. It&amp;#39;s a full post-mortem of a 15+ bug battle — four rounds of attribution, regression traps, and how TDD was forced out by pain.</description></item><item><title>The Full Pipeline: Five Stages from Requirements to Code</title><link>https://blog.chuanxilu.net/en/posts/2026/04/ai-tdd-full-pipeline-from-requirements-to-code/</link><pubDate>Thu, 30 Apr 2026 14:00:00 +0800</pubDate><guid>https://blog.chuanxilu.net/en/posts/2026/04/ai-tdd-full-pipeline-from-requirements-to-code/</guid><description>Article 6 in the series. The previous five articles each covered one layer — requirements, design, testing, review, procedural justice. This one connects them into a working pipeline. Checklists for every stage, a real-project retrospective, and a blunt assessment of when this process is worth the overhead.</description></item><item><title>Procedural Justice Encoded: Making Every Step of AI Review Verifiable</title><link>https://blog.chuanxilu.net/en/posts/2026/04/adversarial-review-critical-thinking-ai-quality/</link><pubDate>Thu, 30 Apr 2026 10:00:00 +0800</pubDate><guid>https://blog.chuanxilu.net/en/posts/2026/04/adversarial-review-critical-thinking-ai-quality/</guid><description>Ralph Loop v0.3 encodes procedural justice into the review protocol — structured review output, critical scrutiny, contested issue protocol — so every review decision has evidence, records, and rule-based constraints. Inspired by Robert&amp;#39;s Rules of Order, born 150 years ago.</description></item><item><title>AI Errors Converge, They Don't Randomize: The Review Loop That Catches What You Miss</title><link>https://blog.chuanxilu.net/en/posts/2026/04/ralph-loop-ai-errors-converge/</link><pubDate>Wed, 29 Apr 2026 14:00:00 +0800</pubDate><guid>https://blog.chuanxilu.net/en/posts/2026/04/ralph-loop-ai-errors-converge/</guid><description>The tech spec from the previous article shrank the space where AI can improvise. But the spec itself contains assumptions — and some of them are wrong. Ralph Loop is a multi-round review protocol where an independent AI subagent audits every deliverable. Its exit condition borrows from mathematical convergence: one clean round proves nothing. Two consecutive clean rounds prove convergence.</description></item><item><title>Why PRD Alone Is Not Enough: What the Tech Spec Must Cover in AI-Assisted Development</title><link>https://blog.chuanxilu.net/en/posts/2026/04/prd-to-tech-spec-ai-design-guardrails/</link><pubDate>Wed, 29 Apr 2026 10:00:00 +0800</pubDate><guid>https://blog.chuanxilu.net/en/posts/2026/04/prd-to-tech-spec-ai-design-guardrails/</guid><description>The second Aristotle refactor had clear requirements, clean code structure, passing tests. But the async background mechanism still did not work. The problem was not in the PRD—it was in the tech spec. This article covers what a PRD should contain, what a tech spec should add, and why both are non-negotiable when AI writes your code.</description></item><item><title>Why AI-Assisted Development Needs Structured Requirements First: Lessons from the GEAR Protocol</title><link>https://blog.chuanxilu.net/en/posts/2026/04/why-aristotle-vibe-development-needs-gear-protocol/</link><pubDate>Sat, 25 Apr 2026 00:00:00 +0800</pubDate><guid>https://blog.chuanxilu.net/en/posts/2026/04/why-aristotle-vibe-development-needs-gear-protocol/</guid><description>Aristotle v1 had a one-line requirement. The reflection task ran inside the main session, polluting 371 lines of context. This article starts from that failure and walks through why requirement gaps get amplified into systematic bias in AI-assisted development, and how structured methods close those gaps.</description></item><item><title>Write Test Plans Before Test Code: Requirement Anchoring in AI Development</title><link>https://blog.chuanxilu.net/en/posts/2026/04/test-doc-before-test-code-reverse-anchoring/</link><pubDate>Thu, 23 Apr 2026 10:00:00 +0800</pubDate><guid>https://blog.chuanxilu.net/en/posts/2026/04/test-doc-before-test-code-reverse-anchoring/</guid><description>In AI-assisted development, tests are not just verification. They are the most precise requirement language you can give an AI. Drawing from my own failures, this article walks through the full chain from test scenario identification to test development documents, and explains why this method matters far more when the coder is an AI.</description></item></channel></rss>