เมื่อมีคนบอกคุณว่าเขาปล่อยหน้าเว็บจริง (live pages) ไปถึง 335 หน้า จาก 26 repositories ภายในเวลาเพียง 29 วัน โดยทำงานเพียงลำพัง สัญชาตญาณแรกคือการถามว่าเขาทำเร็วขนาดนั้นได้อย่างไร แต่คำถามที่ดีกว่าคือ มีอะไรพังบ้างในระหว่างที่ทำแบบนั้น

ตัวเลขเหล่านี้คือเรื่องจริง: 1,549 commits, 26 repos, 29 วัน โดยนักพัฒนาเพียงคนเดียวที่ใช้ Claude Code แต่ความเร็ว (velocity) เพียงอย่างเดียวไม่ได้สอนอะไรคุณมากนัก สิ่งที่สำคัญคือลักษณะของความล้มเหลว เพราะมันไม่ใช่ความผิดพลาดประเภทที่คุณจะตรวจเจอใน stack trace แต่มันคือรอยร้าวทางโครงสร้าง คุณจะเห็นมันก็ต่อเมื่อคุณถอยออกมาจาก editor แล้วมองดูระบบทั้งหมดที่กำลังทำงานอยู่ใน production

สิ่งที่ได้ผล

ความเร็วนั้นไม่ใช่ภาพลวงตา งานบางอย่างใช้เวลาลดลงอย่างมหาศาลเมื่อคุณส่งต่อให้ AI ที่ไม่มีวันหลับใหล

อัลกอริทึมตามตำรากลายเป็นฟีเจอร์ที่ใช้งานได้จริงภายในไม่กี่วัน ไม่ใช่เป็นสัปดาห์ ตัวแก้เกม 2048 และเกมที่ใช้พื้นฐาน minimax ถูกสร้างขึ้นอย่างรวดเร็วเพราะรูปแบบการเขียนโค้ด (implementation patterns) มีการบันทึกไว้อย่างดี โมเดลไม่ได้หลงทางอยู่ในงานวิจัยทางวิชาการ แต่มันเขียน search tree, การประเมินแบบ heuristic, การให้คะแนนการเดินหมาก และไปต่อได้ทันที สิ่งเหล่านี้คือปัญหาที่ได้รับการแก้ไขมาแล้ว และ AI pair programmer ก็จัดการกับปัญหาที่แก้ได้แล้วเหล่านี้ด้วยประสิทธิภาพที่สูงมาก

การตรวจสอบ (audit) ที่น่าเบื่อหน่ายกลายเป็นเรื่องที่พอรับได้ การไล่ตรวจสอบ link graphs, การยืนยัน redirect chains, การเช็ค canonical tags ในหน้าเว็บหลายร้อยหน้า — งานเหล่านี้ทำลายสมาธิของมนุษย์ แต่โมเดลภาษาจะทำงานซ้ำๆ ได้โดยไม่บ่น มันตรวจสอบรูปแบบเดิมซ้ำๆ ถึงสามร้อยครั้งแล้วรายงานผลกลับมา

สิ่งที่น่าประหลาดใจจริงๆ คือความสม่ำเสมอ เมื่อคุณสั่งให้ AI สร้าง landing page จำนวนมาก ความคลาดเคลื่อน (drift) ย่อมเกิดขึ้นอย่างหลีกเลี่ยงไม่ได้ เว้นแต่คุณจะกำหนดจุดยึดให้มัน ผมใช้ไฟล์หน่วยความจำ (memory files) ขนาดเล็กเพื่อล็อกระบบแบรนด์เพียงหนึ่งเดียว: กฎการใช้ภาษา (voice rules), ชื่อ color token, ข้อจำกัดของ component และรูปแบบหน้าเว็บ (page archetypes) โมเดลจะอ่านข้อจำกัดเหล่านั้นเมื่อเริ่มงานที่เกี่ยวข้อง และสร้างผลงานที่ให้ความรู้สึกเหมือนมาจากมือคนเพียงคนเดียว แทนที่จะมาจากอารมณ์ที่แตกต่างกันถึง 29 แบบ

สิ่งที่พังจริงๆ

ความล้มเหลวเหล่านั้นเป็นเรื่องทางสถาปัตยกรรม ไม่มี build ไหนพังเพราะลืมใส่ semicolon แต่ระบบกลับค่อยๆ หลอกให้ผมคิดว่าทุกอย่างยังปกติดี

SEO cannibalization เกิดขึ้นเป็นอย่างแรก AI สร้าง tool hub ใหม่ภายใต้ URL ใหม่ ในขณะที่ tool hub อันเก่าก็ยังอยู่ที่ path เดิม แต่ละหน้าถูกปรับแต่งมาอย่างดี (optimized) ทั้ง Title ที่กระชับ, Meta description ที่ไม่ซ้ำกัน และเนื้อหาที่มีประโยชน์ แต่ทุกหน้ากลับมุ่งเป้าไปที่ search intent เดียวกัน ผลคือ Search engine เห็นว่ามีแหล่งข้อมูลที่น่าเชื่อถือสองแห่งในหัวข้อเดียวกัน จึงไม่จัดอันดับให้ทั้งคู่ หน้าเว็บที่สมบูรณ์แบบกลับหักล้างกันเอง เพราะไม่มีใครมองเว็บไซต์ในฐานะพอร์ตโฟลิโอ แต่มองเป็นเพียงแค่การสะสมไฟล์ต่างๆ เท่านั้น

ตามมาด้วยความไม่สอดคล้องของ URL แต่ละ repository ใช้โครงสร้างโฟลเดอร์ที่ต่างกันเล็กน้อยสำหรับเนื้อหาประเภทเดียวกัน Repo หนึ่งเก็บเครื่องมือไว้ภายใต้ /tools/utility-name แต่อีก repo หนึ่งกลับวางไว้ที่ /utility-name โดยตรง เมื่อ CDN เห็นทั้งสองแบบ จึงสร้าง redirect chains เพื่อจัดการกับมัน และเริ่มเกิดข้อผิดพลาดที่ edge แม้ในที่สุดหน้าเว็บจะโหลดขึ้นมาได้ แต่ทุกการ redirect ก็เป็นการสิ้นเปลือง crawl budget และความอดทนของผู้ใช้ โค้ดนั้นถูกต้อง แต่โครงสร้าง (topology) นั้นเละเทะ

จากนั้นก็เจอกับดักการ sync ผมอัปเดต mirror site ซึ่งเป็น staging หรือ instance สำรอง แต่ลืมส่งการเปลี่ยนแปลงเหล่านั้นกลับไปยัง source repository เมื่อผมสั่งให้ AI ทำการ sync สภาพแวดล้อม (environments) ในภายหลัง มันกลับมองว่า mirror site คือข้อมูลที่ถูกต้องที่สุด (ground truth) คำสั่ง sync ง่ายๆ เพียงคำสั่งเดียวอาจเขียนทับฐานข้อมูลหรือชุดไฟล์ใน production ด้วยข้อมูลเก่าจาก mirror AI ทำตามสิ่งที่ผมอธิบาย ไม่ใช่สิ่งที่ผมตั้งใจ ความตั้งใจไม่มีการ diff แต่ไฟล์มี

แม้แต่เครื่องมือ audit เองก็ยังโกหก เพราะผมทำให้การตรวจสอบเป็นแบบอัตโนมัติ ผมจึงทึกทักเอาเองว่าผลลัพธ์ที่ได้นั้นสะอาดสะอ้าน แต่มันไม่ใช่ สคริปต์ audit ที่เขียนโดย AI มีบั๊กที่ตรวจจับได้ยาก เช่น การเช็คแบบ off-by-one, การสันนิษฐานรหัสสถานะ redirect (status codes) ที่ผิดพลาด หรือข้อผิดพลาดหลอนๆ (phantom errors) ที่เกิดจากเรื่องของเวลาหรือ header มากกว่าการตั้งค่าที่ผิดพลาดจริงๆ มันรายงานปัญหาที่ไม่มีอยู่จริง ทำให้ผมต้องวิ่งไล่ตามผี ผมเรียนรู้ที่จะเลิกเชื่อถือ static analysis จนกว่าจะได้ตรวจสอบหน้าเว็บจริงด้วยตัวเอง และยืนยันอาการผ่านเบราว์เซอร์หรือการใช้ curl โดยตรง

ต้นทุนที่ซ่อนอยู่

นี่คือตัวเลขที่ไม่มีใครพูดถึง: 93 เปอร์เซ็นต์ของค่าใช้จ่าย token ของผม หมดไปกับการอ่าน cached context ซ้ำไปซ้ำมา

In a long Claude Code session, every new request forces the model to revisit the previous conversation history, file buffers, and working memory. The first task in a session might be cheap. By the tenth task, the model is digesting everything that came before just to understand the next sentence. The cost curve bends upward fast. Long sessions turn into expensive rereading exercises, and the context window fills with debris from earlier jobs that have nothing to do with the current one.

This is not a quirk. It is a direct tax on poor session hygiene.

How to Fix It

The fixes were simple once I named the problems.

Treat one session as one task. When the job changes, start fresh. The temptation to keep the context warm is strong — you feel like you are saving setup time — but you are actually renting memory at compounding interest.

Keep knowledge in small, dedicated memory files. Do not let the model carry brand guidelines, component libraries, or SEO rules inside conversational context. Write them to disk in concise files and reference them explicitly. This moves information from expensive volatile context to cheap persistent storage.

Between different jobs, clear the decks. Close the session. Open a new one. The thirty seconds of setup saves dollars and hallucinations later.

Lessons for Scaling

If you are going to work at this volume, you need guardrails that treat the system, not the file, as the unit of review.

Benchmark before you publish. Do not assume a page works because it renders. Check load time, mobile layout, and core metrics on the deployed URL. A beautiful component in local dev can collapse under real network conditions.

Diff before you copy. Never run a bulk sync or copy operation blindly. Look at the delta. Understand which direction the data is flowing. The AI will not warn you that you are about to overwrite live customer data.

Probe live sites before trusting audits. Static analysis is a hypothesis. A live request is evidence. When an audit tool reports a broken link or a redirect loop, verify it with a direct request. Tools have bugs too, especially tools written by an AI operating on inferred patterns.

Write conventions down before you scale. URL structure, folder hierarchy, canonical patterns, and content taxonomy need to be documented in a place the AI can read before it generates a single new page. Memory files are not optional at