- มีการทำการทดลองสร้างแอปโดยใช้เพียง เวิร์กโฟลว์การพัฒนาแบบมี AI ช่วย เป็นเวลา 2 สัปดาห์ แต่ผลลัพธ์ออกมาไม่น่าพอใจเท่าที่คาดหวัง
- ใช้สแตกที่อิง Claude Code และ Remix โดยวนกระบวนการ นิยามอีชู → ให้ AI ลงมือทำ → รีวิวโค้ด → ดีพลอย ซ้ำไปมา
- แต่กลับยิ่งรู้สึกหงุดหงิดมากขึ้นจาก บริบทไม่เพียงพอ, โค้ดซ้ำที่นำกลับมาใช้ไม่ได้, การไหลของงานสะดุด, อาการหลอน (hallucination) และ ปัญหาตามกฎ Pareto
- สุดท้ายหลังผ่านไป 2 สัปดาห์ จึงเลิกแนวทางพัฒนาแบบยึด AI เป็นศูนย์กลางและกลับไปใช้วิธีเดิม พร้อมรู้สึกพอใจกับการจัดระเบียบโค้ดและปรับปรุงคุณภาพ
- ปัจจุบันใช้ AI เฉพาะในงานที่จำกัด เช่น การค้นหา, rubber ducking, โค้ดสไนเป็ต, การทดสอบ, การเกลาภาษา และยังไม่มีแผนจะขยายการใช้งานมากกว่านี้จนกว่าจะมีการเปลี่ยนแปลงทางเทคโนโลยีอย่างมีนัยสำคัญ
ภาพรวมของการทดลอง
- ได้ทำการทดลองพัฒนาแอปเป็นเวลา 2 สัปดาห์ โดยนำเวิร์กโฟลว์การพัฒนาด้วย LLM (โมเดลภาษาขนาดใหญ่) ที่กำลังได้รับความสนใจมาใช้จริงด้วยตนเอง
- จากประสบการณ์ใช้งาน UI ที่ซับซ้อนของบัญชี Facebook Ads จึงเริ่มพัฒนาโปรโตไทป์ adbrew ซึ่งเป็นเครื่องมือจัดการโฆษณาแบบเรียบง่ายที่ใช้เฉพาะ Facebook Ads API
- การทดลองนี้ดำเนินไปทั้งด้วยเป้าหมายในการตรวจสอบศักยภาพของ AI และความคาดหวังว่าจะช่วยแก้ปัญหาได้จริง
แนวทางที่ใช้
- ติดตามบัญชีที่เกี่ยวข้องกับ AI หลายแหล่ง ศึกษาเวิร์กโฟลว์ต่าง ๆ และเลือกเทคโนโลยีสแตกเป็น Remix/React Router v7
- หลังสมัครใช้งาน Claude Code ก็ทุ่มเวลาให้กับการตั้งค่าสภาพแวดล้อมช่วงแรก เช่น พรอมป์ต์, การตั้งค่าเครื่องมือ DX, การนิยามอีชู
- รูทีนรายวัน
- นิยามอีชู
- ขอให้ AI ลงมือพัฒนา
- ปรับความต้องการร่วมกับ AI
- ตรวจทานโค้ดที่สร้างขึ้นอย่างละเอียด
- คอมมิต/ดีพลอยโค้ด
- ทำกระบวนการซ้ำ
- ปรับปรุงไฟล์แนวทางและไฟล์ตรวจสอบอัตโนมัติเป็นระยะ
- มีความพยายามอย่างต่อเนื่องในการปรับให้การไหลของงานพัฒนาสอดคล้องกับ AI
ปัญหาที่เกิดขึ้นบ่อย
- บริบทไม่เคยเพียงพอ
- ต่อให้ให้บริบทไปมาก AI ก็ไม่ร้องขอฟีดแบ็กหรือข้อมูลที่จำเป็น
- AI ตั้งสมมติฐานเองระหว่างทำงาน ส่งผลให้เกิดการพัฒนาที่ผิดพลาดอยู่บ่อยครั้ง
- โค้ดนำกลับมาใช้ซ้ำและบำรุงรักษาไม่ได้
- ยังทำได้ไม่ดีทั้งด้าน abstraction และการสร้างโค้ดที่นำกลับมาใช้ซ้ำได้
- สร้างคอมโพเนนต์เดิมซ้ำ ๆ ทำให้ความเหนื่อยล้าจากการรีวิวเพิ่มขึ้น
- ผลของการเพิ่มแนวทางกำกับมีน้อยมาก
- การไหลของงานขาดตอน
- เมื่อต้องทำงานร่วมกับ AI จำเป็นต้องคอยเฝ้าดูอย่างต่อเนื่อง
- ยากที่จะจัดสรรช่วงเวลาที่มีสมาธิอย่างมีประสิทธิภาพในแต่ละอีชู ทำให้ ประสิทธิภาพการทำงานลดลง
- อาการหลอน (Hallucination)
- เมื่อรวมความซับซ้อนของ Facebook API เข้ากับเอกสารที่ไม่เพียงพอและ SDK ที่พิมพ์ผิดพลาด ความมั่นใจผิด ๆ ของ AI ก็ยิ่งเพิ่มความสับสน
- มีการสร้างข้อมูลที่ผิดซ้ำ ๆ เกี่ยวกับเฟรมเวิร์กและไลบรารีหลายตัว
- ปรากฏการณ์ Pareto รุนแรงขึ้น
- งาน 80% แรก AI ทำได้รวดเร็ว แต่ 20% สุดท้ายในการเก็บงานและแก้ไขกลับต้องใช้แรงถึง 80%
- เกิดข้อบกพร่องและบั๊กสำคัญจำนวนมากในส่วนของการจัดการกรณียกเว้นและปฏิสัมพันธ์ระหว่างฟีเจอร์
ผลลัพธ์และสิ่งที่ได้ทบทวน
- หลังผ่านไป 2 สัปดาห์ โค้ดเริ่มเละเทะและควบคุมไม่ได้มากขึ้นเรื่อย ๆ
- ระหว่างพัฒนาได้ สูญเสียความสนุก และพบปัญหาด้านคุณภาพ จึงกลับไปใช้เวิร์กโฟลว์เดิม
- เมื่อกลับมาจัดระเบียบโค้ดด้วยมืออีกครั้ง ก็พบจุดที่ AI รีวิวพลาดไป และสุดท้ายได้ฐานโค้ดที่ดีกว่าเดิม
วิธีใช้ AI ในปัจจุบัน
- เสิร์ชเอนจินที่ทรงพลัง: มีประสิทธิภาพในการค้นหาข้อมูลซับซ้อนและให้คำตอบที่เข้ากับบริบท และหากล้มเหลวก็สามารถกลับไปใช้วิธีเดิมได้อย่างรวดเร็ว
- rubber duck (ระดมไอเดีย) : มีประโยชน์มากในการเสนอทางเลือก ขยายขอบเขตการสำรวจ และช่วยค้นหาคีย์เวิร์ดที่เกี่ยวข้อง
- ผู้ช่วยโค้ดสไนเป็ต: ช่วยทำให้การสร้าง utility function ที่ทำซ้ำเป็นอัตโนมัติ เพื่อลดความเหนื่อยล้าในการพัฒนา
- ผู้ช่วยโค้ดทดสอบ: ใช้ AI เพื่อค้นหาซีนาริโอใหม่ ๆ ที่เกี่ยวข้องกับการทดสอบ
- งานด้านภาษา: มีประโยชน์ในบทบาทการแก้ไขข้อความ เช่น commit message, issue, PR
- ช่วงหลังเกิดการกลับด้าน คือแทนที่ AI จะเป็นคนเขียน นักพัฒนาเขียนเองแล้วให้ AI รีวิว
บทสรุปและมุมมองต่อไป
- จะยังใช้ AI ต่อไปในฐานะ ผู้ช่วยงานประจำวัน แต่ยังมีมุมมองเชิงลบต่อการขยายไปสู่ การมอบหมายกระบวนการพัฒนาทั้งหมดให้ AI ในตอนนี้
- กำลังพยายามให้ความสำคัญกับ การใช้ local LLM เป็นหลัก และรักษาการควบคุมข้อมูลไว้
- จะติดตามความเปลี่ยนแปลงของเทคโนโลยีในอนาคตอย่างต่อเนื่อง แต่ ณ ตอนนี้ตั้งใจจะจำกัดขอบเขตการใช้ AI ไว้เท่าที่จำเป็น
2 ความคิดเห็น
นี่เป็นข้อเสียที่รู้สึกได้บ่อยมากเวลาทำงานที่ซับซ้อน
ความสนุกหายไป + โค้ดยุ่งเหยิง..
หลายครั้งรู้สึกว่าเหมาะจะใช้แค่งานรีแฟกเตอร์โค้ด + ใช้เป็นไอเดีย มากกว่าจะเอาไปใช้ด้านอื่นจริง ๆ
ความคิดเห็นจาก Hacker News
ช่วงนี้ผมลองถาม ChatGPT เรื่องคำสั่ง rsync ง่ายๆ อยู่เกินชั่วโมง แต่มันก็ยังให้พารามิเตอร์ของคำสั่งที่ใช้ไม่ได้กับ rsync เวอร์ชันบน Mac ของผมอยู่เรื่อยๆ ครึ่งหนึ่งของความล้มเหลวคือมันพาหลงไปกับการแก้ปัญหาที่ไม่เข้าท่า อีกครึ่งหนึ่งคือมันบอกว่ามัน “เพิ่งรู้ตัว” ว่าตัวเองผิด แล้วก็ตอบผิดอีกในเวอร์ชันใหม่ ผมสั่งให้มันตรวจสอบพารามิเตอร์ให้ตรงกับเวอร์ชันที่ผมมี แต่มันก็ทำแบบนั้นไม่ได้ชัดเจน จริงๆ ถ้าทำเองก็คงเสร็จใน 5 นาที แต่ผมกลับหยุดดูเทคโนโลยีแปลกใหม่นี้เสียเวลาของผมไม่ได้ ผมไม่ใช่นักพัฒนามืออาชีพ แต่ก็สงสัยว่าประสบการณ์แบบนี้เป็นเรื่องปกติในหมู่นักพัฒนาด้วยไหม ถ้าเขียนโค้ดกับซอฟต์แวร์เวอร์ชันที่ตรงกับชุดข้อมูลฝึกหลักของ LLM อาจจะไม่เจอปัญหานี้ก็ได้ และผมก็สงสัยว่ามีวิธีหลบปัญหานี้ด้วยพรอมป์ต์ไหม ตอนนี้ผมยังมองไม่ค่อยออกว่า LLM ช่วยประหยัดเวลาในงานเขียนโค้ดได้จริง ตรงกันข้าม ผมคิดว่าบุคลิกแปลกๆ ของมันทำให้เสียเวลามากกว่าเดิม
ต่อให้ผมขอให้ LLM ตรวจสอบพารามิเตอร์ให้ตรงกับเวอร์ชันของผม มันก็ยังทำไม่ได้ดี ผมเลยอยากรู้ความเห็นจากคนที่เชี่ยวชาญด้าน AI เรื่องนี้ ผมเองก็เจอแบบนี้บ่อยมาก สุดท้ายแล้ว LLM ไม่ได้ “เข้าใจ” สิ่งที่ผมพูดจริงๆ ซึ่งถ้ามองทางคณิตศาสตร์ก็พออธิบายได้ แต่ขณะเดียวกันก็ดูเหมือนว่าจะมีเทคนิคอย่าง transformer หรือกลเม็ดเสริมอื่นๆ ถูกใส่มาเพื่อให้งานที่ไม่น่าอายแบบการนับตัวอักษรทำได้ดีขึ้น ผมเลยสงสัยว่ามีอะไรที่ผมกำลังมองข้ามอยู่หรือเปล่า
เรื่องแบบนี้พบได้บ่อยมากแม้แต่ในหมู่นักพัฒนา ใครบางคนอาจบอกว่า “ฉันไม่เคยเจอ” แต่ก็เป็นข้อยกเว้นส่วนน้อยมาก คนส่วนใหญ่บ่นคล้ายๆ กัน คุณยังถามด้วยว่าจะหลบปัญหานี้ด้วยพรอมป์ต์ได้ไหม คำตอบคือถ้าเป็นเรื่องที่ไม่มีในข้อมูลฝึกก็แทบไม่มีประโยชน์อะไรเลย LLM ห่วยมากกับหลายภาษา ส่วนเครื่องมือ CLI นั้น ต่อให้บอก LLM ไปแล้วว่าเป็น macOS หรือเวอร์ชัน BSD มันก็มักจะยังให้ GNU flags มาอยู่ดี โดยเฉพาะบน macOS ที่ช่วงหลัง rsync เพิ่งมีการเปลี่ยนแปลง ทำให้ข้อมูลออนไลน์ก็ยังมีไม่มาก ดูลิงก์นี้ บทความเรื่องการเปลี่ยน rsync และความคิดที่ว่า LLM จะช่วยประหยัดเวลาในการเขียนโค้ดได้นั้นก็เป็นกรณีดีที่สุดเท่านั้น ตรงกันข้าม หลายครั้งคนกลับเชื่อโค้ดจาก LLM มากเกินไปแล้วคอมมิตเข้าไป จนเกิดบั๊กหรือช่องโหว่ด้านความปลอดภัยได้ด้วย อ้างอิง บล็อก ai-coding-slowdown และ บทความ arxiv
เรื่องการหลบปัญหานี้ด้วยพรอมป์ต์ ผมก็ไม่แน่ใจนัก แต่ใน Claude Code มันสามารถรันคำสั่งได้โดยตรง กล่าวคืออย่าปล่อยให้ LLM จินตนาการเองล้วนๆ ให้เอาผลลัพธ์จริงของคำสั่งอย่าง
! man rsyncหรือ! rsync --helpมาใส่เพิ่มในบริบทแทนถ้าจะเปิดคู่มือของเครื่องมือเฉพาะตัวอยู่แล้ว ก็สงสัยว่าทำไมต้องใช้ LLM ด้วย
เรื่องที่พยายามเกินชั่วโมงเพื่อเอาคำสั่ง rsync ง่ายๆ จาก ChatGPT นั้น ผมจะลองหลายรอบโดยเพิ่มข้อมูลสภาพแวดล้อมและข้อความ error ให้มากพอ แล้วถ้ายังไม่ได้ก็ลองโมเดลอื่นอย่าง Claude, Gemini ถ้าลองครบตามจำนวนที่ตั้งไว้แล้วยังไม่สำเร็จ ก็แปลว่าคงยากที่จะได้ความช่วยเหลือจาก LLM แล้ว ควรหยุดและกลับไปใช้วิธีเดิมอย่างอ่านคู่มือหรือค้นตามฟอรัมจะเร็วกว่าเยอะ โดยทั่วไปลองสัก 10-20 นาทีแล้วไปต่อถือเป็นเกณฑ์ที่สมจริง มีปัญหาบางอย่างที่ต่อให้ LLM พยายามนานแค่ไหนก็แก้ไม่ได้ และจะวนไปวนมาอยู่อย่างนั้น
ผมเองก็มีประสบการณ์แบบนี้เยอะเหมือนกัน AI จะมีประโยชน์จริงเมื่อผมให้มันทำงานที่ผมทำเองเป็นอยู่แล้ว ถ้าผมอธิบายปัญหาได้แม่นพอให้ LLM เข้าใจ มันก็ให้ผลลัพธ์ที่โอเค และผมก็ตรวจโค้ดที่มันให้มาได้ทันทีว่าตรงตามที่ต้องการไหม แต่ถ้าโยนเรื่องที่ไม่รู้เลยให้มันทำ กลับยิ่งซับซ้อนกว่าเดิม
ผมคิดว่าบทความนี้ (ไม่นับชื่อเรื่อง) มองได้ค่อนข้างสมดุล “โยนทุกอย่างให้ LLM ไปเลย!” นั้นมีปัญหาเต็มไปหมด ส่วน “ให้มันช่วยเฉพาะโค้ดซ้ำๆ ที่ประหยัดเวลา หรือโค้ดทดสอบบางส่วน” นั้นค่อนข้างโอเค เพียงแต่ถ้าใช้ชื่อธรรมดาว่า “AI บางครั้งก็เวิร์ก บางครั้งก็ไม่เวิร์ก” ก็คงไม่มีทางได้ยอดเข้าชม
AI ให้ความรู้สึกเหมือนเด็กฝึกงานมากกว่าผู้รับจ้างภายนอก
ผมอินมากกับคำว่า “ข้อมูลบริบทมันไม่เคยพอ” ไม่ว่าเราจะป้อนบริบทไปมากแค่ไหน AI ส่วนใหญ่ก็มักจะเดาเองไปเรื่อยๆ จนพัง แทนที่จะถามกลับเพื่อรับฟีดแบ็ก ผมนึกถึงฉากในรายการทีวีเรื่องหนึ่งที่มีคนขอพรกับยักษ์จีนี่ แล้วต้องคุยแบบทนาย คอยย้ำเงื่อนไขให้ครบทุกข้อ การคุยกับ LLM ก็ให้ความรู้สึกคล้ายๆ กัน
AI เหมือนเพื่อนร่วมงานที่ฉลาดมากแต่ไม่เคยพูดสิ่งที่คิดออกมาตรงๆ ดูเหมือนจะทำได้ทุกอย่าง แต่ทำงานร่วมกันไม่ค่อยได้ และบทสนทนาแบบ “ฉันไม่เข้าใจว่าคุณต้องการอะไรตรงนี้ ช่วยอธิบายเพิ่มหน่อย” ก็แทบไม่เคยออกมาจาก AI เลย
(ผมว่าเดาออกว่าฉากทีวีที่ว่าคืออะไร) ในฉากนั้นสุดท้ายมันจบได้ดี แต่ผมคิดว่า LLM ไม่ได้รู้สึกว่าตัวเองจำเป็นต้องรักษา “คำสัญญา” อะไรเลย ตรงกันข้าม จีนี่กลับใกล้เคียง AI แบบไซไฟคลาสสิกที่ติดอยู่กับกฎและข้อบังคับมากกว่า ส่วน LLM เป็นคนละแบบโดยสิ้นเชิง
ผมไม่ค่อยชอบ vibe coding ที่เน้นสื่อสารกับ AI มากกว่าการลงมือเขียนโค้ดจริง สิ่งที่ผมเปลี่ยนมากกว่าคือผมเริ่มจัดโครงสร้างกระบวนการพัฒนาให้เร็วขึ้นกว่าเดิม ผมจะเขียนไฟล์สเปกก่อน แล้วให้ LLM ช่วยแยกว่าตรงไหนใน requirement ควรอธิบายให้ชัด โดยอิงจาก codebase และข้อมูลออนไลน์ พร้อมแตกขั้นตอนการทำงานออกเป็นเช็กลิสต์ทีละข้อ จากนั้นค่อยไปเซสชันถัดไปเมื่อจบแต่ละขั้นเพื่อเกลางานให้สมบูรณ์ขึ้น ถ้าคุยกับ AI จนล้า ผมหรือคนในทีมก็กลับมาลงมือทำตามสเปกเองได้อยู่แล้ว เลยใช้ได้อย่างยืดหยุ่น
โปรเจ็กต์ล่าสุดผมเริ่มเอา AI coding มาใช้ ผมไม่แน่ใจว่า vibe coding จริงๆ หมายถึงอะไร แต่แนวทางที่ผมเลือกคือการโต้ตอบแบบค่อยเป็นค่อยไปอย่างสบายๆ ผมใช้ Gemini AI studio และพอใจกับผลลัพธ์มาก จนบันทึกกระบวนการทั้งหมดแล้วปล่อยเป็นโอเพนซอร์ส มันช่วยเพิ่มผลิตภาพของผมได้อย่างเห็นได้ชัด ข้อเสียอย่างเดียวคือ AI พูดสุภาพเกินไป ในความเห็นผม AI ให้ ROI สูงสุดเมื่อเรารู้ชัดว่าต้องการผลลัพธ์อะไร และต้องใช้มันเพื่อเปรียบเทียบตัวเลือกต่างๆ ระหว่างทาง ผมใช้มันกับทุกผลลัพธ์ของโปรเจ็กต์ ทั้งโค้ดหลัก test case สคริปต์ build เอกสาร แอปตัวอย่าง และยูทิลิตี ดูบันทึกบทสนทนาการพัฒนาทั้งหมดได้ที่นี่ และดูซอร์สของโปรเจ็กต์ได้ที่นี่
ผมใช้ AI คล้ายๆ แบบที่คุณใช้นั่นแหละ การคาดหวังให้มันสร้าง abstraction แบบปฏิวัติวงการนั้นมากเกินไป มันทำงานได้ดีบนเส้นทางธรรมดามากๆ ที่นักพัฒนาหลายพันคนเคยเดินมาแล้ว ในแง่นั้นมันก็คล้าย search engine ที่ทรงพลังมาก
วิธีที่ผมชอบคือให้ LLM ช่วยออก solution แรกหรือยกตัวอย่างโค้ดสั้นๆ ให้ก่อน จากนั้นผมก็ทำต่อเองเลยโดยไม่เสียเวลาไล่ปรับพรอมป์ต์ไปเรื่อยๆ แล้วค่อยให้ LLM ช่วย review โค้ดของผมตอนท้ายถ้าจำเป็น ข้อดีใหญ่สุดคือข้ามลูปการขัดเกลาพรอมป์ต์ไปได้ ซึ่งลูปนี้น่าเบื่อมาก กินเวลาเยอะมาก และในระยะยาวอาจทำให้ประสิทธิภาพการทำงานแย่ลงด้วยซ้ำ
เรื่องที่ AI เดินหน้าทำต่อไปเองโดยไม่มีฟีดแบ็กหรือคำถามเพื่อขอความชัดเจนนี่น่าหงุดหงิดจริงๆ
ผมเล่าความเห็นของทีมว่า “ตอนนี้เราจะใช้ AI แค่นี้ก่อน และถ้าในอนาคตเทคโนโลยีเปลี่ยนไปในระดับพื้นฐาน ค่อยกลับมาประเมินใหม่” ผมสงสัยว่า LLM จะทำได้มากกว่านี้ไหม แต่ตอนนี้ก็คิดว่าถ้าใช้ให้เป็น มันมีประโยชน์มาก
การใช้ AI เพื่อปรับปรุง facebook ads ก็เหมือนกับพวก breakers ในซีรีส์ Dark Tower