สรุปสั้น: AI คือ Rockstar Developer ตัวใหม่
เคยเจอ dev เก่งๆ ลาออกแล้วทิ้งโค้ดที่ไม่มีใครอ่านออกไว้ให้ทีมงมเดือนกว่าจะเข้าใจ? ปัญหาเดียวกันกำลังเกิดขึ้นอีกครั้ง — แต่คราวนี้ตัวการคือ AI
Jesse Skinner เขียนไว้ในบทความ “Cleaning up after AI rockstar developers” ว่า AI agents เขียนโค้ดเร็วมาก แต่ไม่มี context ของระบบเดิม ไม่เข้าใจ architecture ภาพรวม และสร้างโค้ดปริมาณมหาศาลที่ทีมตามไม่ทัน
ผลลัพธ์คือ codebase ที่ซับซ้อนขึ้นเรื่อยๆ เหมือนมี rockstar developer หลายร้อยคนเข้ามาเขียนโค้ดพร้อมกัน แต่ไม่มีใครคุยกัน
เมื่อ Rockstar Developer คนเดิมหายไป

เคยมั้ยที่ senior dev คนสำคัญลาออกแล้วทิ้งโค้ดไว้ให้ทีมงง? เจอมาแล้ว — ระบบ payment ที่ใช้งานได้ดี แต่พอต้องแก้บัคหรือเพิ่ม feature ใหม่ กลับกลายเป็นฝันร้าย
โค้ดไม่มี comment สักบรรทัด function ยาวกว่า 200 บรรทัด variable ชื่อ a, b, c ไปหมด ไม่มี documentation ไม่มี test ที่อธิบายว่าระบบทำงานยังไง
ปัญหานี้ไม่ใช่เรื่องใหม่ ทุกทีมเคยเจอ — dev ที่เก่งจนเขียนโค้ดที่ตัวเองคนเดียวอ่านออก พอเขาหายไป ทีมต้องนั่งงมโค้ดกันเป็นเดือน
AI คือ Rockstar Developer ยุคใหม่

Skinner ชี้ว่า AI กำลังสร้างปัญหาเดียวกัน — แต่แย่กว่า เพราะ AI ไม่ใช่ rockstar developer คนเดียว แต่เหมือนมี rockstar หลายร้อยคนเข้ามาเขียนโค้ดพร้อมกัน
ปัญหาหลักของโค้ดที่ AI สร้าง:
- ขาด context ของระบบเดิม — AI ไม่รู้ว่า codebase มี convention อะไร ใช้ pattern ไหน มี dependency chain ยังไง
- ปริมาณโค้ดมหาศาล — AI สร้างโค้ดเร็วจนทีมตรวจสอบไม่ทัน code review กลายเป็นแค่ rubber stamp
- สถาปัตยกรรมกระจัดกระจาย — แต่ละ AI conversation สร้าง solution แยกกัน ไม่มี coherent architecture
- ทีมเสพติดความเร็ว — พอเคยชินกับการให้ AI เขียนโค้ด ทีมเริ่มลืมว่าต้องเข้าใจโค้ดก่อนที่จะ ship
มองว่าตรงนี้คือจุดที่น่ากลัวที่สุด — เมื่อก่อน rockstar developer อย่างน้อยยังเป็นคนเดียวที่รู้ทุกอย่าง แต่ AI ไม่มี “ความจำ” ข้าม session ด้วยซ้ำ
เปรียบเทียบ Rockstar Developer กับ AI Developer
| Factor | Human Rockstar Dev | AI Developer |
|---|---|---|
| ความเร็วเขียนโค้ด | เร็ว แต่ยังมีขีดจำกัด | เร็วมาก ไม่มีขีดจำกัดเวลา |
| ความเข้าใจ context | เข้าใจระบบทั้งหมด แต่อาจไม่อธิบาย | ไม่มี context ข้ามระบบ |
| Documentation | มักไม่เขียน แต่ถามได้ | ไม่เขียน และถามไม่ได้เมื่อ session จบ |
| ความสม่ำเสมอ | style เดียวทั้ง codebase | style เปลี่ยนทุก conversation |
ความต่างที่ชัดที่สุดคือ human rockstar อย่างน้อยยังเข้าใจระบบเป็นภาพรวม แม้จะเขียนโค้ดยากๆ แต่ถ้ายังอยู่ในทีมก็ถามได้ AI ไม่มีข้อนี้ — พอ session จบ context หายหมด session ใหม่เริ่มต้นจากศูนย์
จุดที่หลายคนมองข้ามคือ AI แต่ละ conversation อาจเลือก pattern หรือ library ที่ต่างกัน ทำให้ codebase กลายเป็น Frankenstein ของ coding style ที่ไม่มีใครตั้งใจ
ทางออกที่ Skinner แนะนำ

Skinner ไม่ได้บอกว่าอย่าใช้ AI แต่บอกว่าให้ใช้อย่างตั้งใจ:
- ให้ AI เขียนโค้ดทีละส่วนเล็กๆ — ไม่ใช่โยน prompt ยาวแล้วรับ output ทั้งหมด ต้องแบ่งงานเป็นชิ้นที่ตรวจสอบได้
- ให้ความสำคัญกับ readability — โค้ดที่ดีคือโค้ดที่ทีมอ่านเข้าใจ ไม่ใช่โค้ดที่ “ทำงานได้”
- เลือก deliberate progress มากกว่า speed — ช้าแต่เข้าใจดีกว่าเร็วแต่งมทีหลัง
- บางทีก็เขียนเอง — Skinner บอกว่า “Craftsmanship will always be in our hands” ไม่ใช่ทุกอย่างต้องให้ AI ทำ
ตรงนี้ต้องบอกว่าเห็นด้วยมาก โดยเฉพาะข้อ 3 — ปัญหาที่เจอในทีมส่วนใหญ่คือ management เห็นว่า AI ช่วยให้ ship เร็ว แล้วก็คาดหวังว่าทุกอย่างจะเร็วตลอด โดยไม่คิดว่า technical debt กำลังสะสม
ข้อดีข้อเสียของการใช้ AI เขียนโค้ด
ข้อดี
- +เร็วมาก boilerplate code ที่เคยเขียน 2 ชั่วโมงเสร็จใน 5 นาที
- +ช่วย explore solution ที่เราอาจไม่เคยคิดถึง
- +ลดงาน repetitive ให้ dev โฟกัสที่ business logic
- +เรียนรู้ pattern ใหม่ๆ จาก AI suggestion
ข้อเสีย
- −โค้ดขาด context ของระบบเดิม อาจซ้ำหรือขัดกับ convention ที่มี
- −ปริมาณโค้ดเยอะจน review ไม่ทัน กลายเป็น rubber stamp
- −ทีมเสพติดความเร็ว ลืม fundamental skills
- −สถาปัตยกรรมกระจัดกระจายจาก AI หลาย session ที่ไม่เชื่อมกัน
พูดตรงๆ — AI ไม่ใช่ปัญหา คนที่ใช้ AI แบบไม่คิดต่างหากที่เป็นปัญหา ถ้าให้ AI เขียนโค้ดแล้วไม่ review ไม่ refactor ไม่ทำ documentation ก็ไม่ต่างจากจ้าง rockstar developer มาแล้วปล่อยให้ทำอะไรก็ได้
สรุป: Craftsmanship ยังอยู่ที่คน
เครื่องมือ AI เขียนโค้ดได้ แต่ “เข้าใจ” ระบบไม่ได้ ความรับผิดชอบในการทำให้ codebase maintain ได้ยังเป็นของทีม — ไม่ว่าจะใช้ AI มากแค่ไหน
สิ่งที่ต้องทำตอนนี้:
- Review ทุก AI-generated code เหมือน review code ของ junior dev — อย่า rubber stamp
- ตั้ง coding standard ที่ชัดเจน แล้วให้ AI ทำตาม ไม่ใช่ปล่อยให้ AI ตัดสินใจเอง
- เขียนเองบ้าง — ไม่ใช่ทุก function ต้องให้ AI สร้าง craftsmanship ยังสำคัญ
Bottom line: AI เป็น rockstar developer ที่ไม่เคยลาออก แต่ก็ไม่เคยเรียนรู้จากความผิดพลาดเหมือนกัน ใช้อย่างตั้งใจ ไม่ใช่พึ่งพา