Agentic Coding คือกับดัก
(larsfaye.com)- Agentic coding คือแนวทางที่มนุษย์กำหนดความต้องการและแผนงาน แล้วให้เอเจนต์เขียนโค้ดหลายตัวลงมือทำ แต่โครงสร้างแบบนี้ทำให้ระยะห่างระหว่างมนุษย์กับโค้ดที่ถูกสร้างและคอมมิตเพิ่มมากขึ้นเรื่อย ๆ
- แนวทางนี้จะสำเร็จได้ก็ต่อเมื่อนักพัฒนาที่มีทักษะสูงสามารถตรวจทานเชิงวิพากษ์ในระดับสถาปัตยกรรมได้ แต่การใช้ AI มากเกินไปอาจก่อให้เกิด หนี้ทางปัญญา (cognitive debt) ที่บั่นทอนทักษะซึ่งจำเป็นต่อสิ่งนั้น
- เช่นเดียวกับ paradox of oversight ที่งานวิจัยของ Anthropic พูดถึง การใช้ Claude ให้มีประสิทธิภาพต้องอาศัยทักษะการเขียนโค้ดเพื่อกำกับดูแล แต่การใช้เอเจนต์เขียนโค้ดกลับอาจทำให้ทักษะนั้นอ่อนแอลง
- LLM มักถูกใช้ไปในทิศทางที่เพิ่มปริมาณโค้ดที่สร้างได้ภายในเวลาที่กำหนด มากกว่าจะเน้นความเข้าใจเชิงลึกและความกระชับ และยังอาจเติมเต็มความต้องการที่คลุมเครือด้วยการคาดเดาหรือการหลอน ทำให้เกิดการรีวิว การแก้ไข และการใช้โทเคนมากขึ้น
- เหตุขัดข้องของ Claude และความผันผวนของต้นทุนโทเคนเผยให้เห็น vendor lock-in และความไม่แน่นอนด้านต้นทุน โดย AI อาจเหมาะกว่าหากใช้เป็นเครื่องมือช่วยวางแผน เอกสาร รีเสิร์ช และการมอบหมายงานแบบจำกัด แทนที่จะเป็นผู้ควบคุมหลักที่มาแทนการลงมือทำจริง เพราะช่วยลดหนี้ด้านความเข้าใจได้
trade-off เชิงโครงสร้าง
- เอเจนต์เขียนโค้ดมีประโยชน์และทรงพลัง แต่ก็มี trade-off ที่ต้องพิจารณาแล้วทั้งในเชิงปริมาณและเชิงปฏิบัติ
- เพื่อลดความกำกวมที่มาจากความไม่แน่นอนของ AI ความซับซ้อนของระบบรอบข้างจะเพิ่มขึ้น
- ทักษะของนักพัฒนาจำนวนมากอาจถดถอย
- ความขัดข้องของผู้ให้บริการรายใดรายหนึ่ง เช่น กรณี Claude Code ล่ม อาจทำให้ทั้งทีมหยุดชะงัก
- ต้นทุนพนักงานค่อนข้างคงที่ แต่ต้นทุนโทเคนอาจผันผวนและเพิ่มขึ้นได้ตลอด
- แนวทางนี้จะสำเร็จได้ก็ต่อเมื่อมีนักพัฒนาที่ชำนาญซึ่งคิดเชิงวิพากษ์ในระดับสถาปัตยกรรม และสามารถพบปัญหาได้ตั้งแต่ก่อนที่มันจะขยายใหญ่ในโค้ดที่สร้างขึ้นมาหลายพันบรรทัด
- แต่เครื่องมือ AI อาจส่งผลลบต่อการคิดเชิงวิพากษ์และความชัดเจนทางความคิดที่จำเป็นต่อสิ่งนั้น และอาจทำให้ หนี้ทางปัญญา (cognitive debt) สะสมมากขึ้น
ไม่ใช่แค่นามธรรมชั้นใหม่
- การตีความว่า “โปรแกรมเมอร์แค่ย้ายขึ้นไปทำงานในชั้นนามธรรมที่สูงขึ้น” เพียงอย่างเดียวไม่เพียงพอ
- ความกำกวมที่เพิ่มขึ้นไม่ได้แปลว่าเป็นการยกระดับนามธรรมเสมอไป
- ตอนที่ FORTRAN, คอมไพเลอร์ และภาษาระดับสูงถือกำเนิดขึ้น ก็เคยมีเสียงกังวลเรื่องบั๊ก ความไม่เสถียร ประสิทธิภาพที่ลดลง และความเป็น “เวทมนตร์” ที่มากขึ้นเช่นกัน
- ความกังวลในอดีตส่วนใหญ่เป็นข้อกังวลเชิงบรรทัดฐานและเชิงทฤษฎีเกี่ยวกับสิ่งที่จะสูญเสียไปหากรับเทคโนโลยีใหม่ แต่เครื่องมือ AI แสดงผลกระทบที่จับต้องได้แล้วภายในเวลาเพียงไม่กี่ปีหลัง появление
- ผลกระทบไม่ได้จำกัดอยู่แค่นักพัฒนารุ่นจูเนียร์ แต่เกิดกับนักพัฒนาที่มีประสบการณ์มากกว่า 10 ปีด้วย
- นักพัฒนาจูเนียร์เผชิญเส้นโค้งการเรียนรู้ที่ชันกว่าเดิม เพราะเวลาในการลงมือแตะโค้ดจริงลดลง และถูกผลักไปสู่บทบาทการรีวิวโค้ดที่สร้างขึ้น
- การรีวิวโค้ดเป็นเรื่องสำคัญ แต่เป็นเพียงครึ่งหนึ่งของกระบวนการเรียนรู้ และเมื่อแรงเสียดทานจากการเขียนและดีบักโค้ดด้วยตนเองหายไป ความสามารถในการเรียนรู้ก็อ่อนแอลงอย่างมาก
- ปรากฏการณ์นี้ต้องใช้เวลากว่าจะมีงานวิจัยรองรับ จึงทำให้หลักฐานเชิงประสบการณ์ยังสำคัญต่อการมองเห็นสิ่งที่เกิดขึ้นแบบเรียลไทม์ แต่ก็มีข้อมูลสนับสนุนจาก รายงานของ MIT Media Lab และ รายงานข่าวเกี่ยวกับ Microsoft
ทำไมการเปลี่ยนครั้งนี้ถึงต่างออกไป
- นักพัฒนา C++ ที่ย้ายไป Java หรือ Python ไม่ได้บ่นว่าตัวเองมี “brain fog” และผู้ดูแลระบบที่ย้ายไปใช้ AWS ก็ไม่ได้รู้สึกว่าสูญเสียความเข้าใจด้านเครือข่าย
- ปรากฏการณ์ที่วิศวกรอาวุโสย้ายไปสู่งานบริหาร ทำโค้ดน้อยลง และเมื่อเวลาผ่านไปก็ “มือขึ้นสนิม” ไม่ใช่เรื่องใหม่
- ในเส้นทางเดิม วิศวกรจะสะสมการเขียนโค้ด แรงเสียดทาน และการแก้ปัญหามาหลายสิบปี ก่อนจะย้ายไปสู่บทบาทที่จัดการการตัดสินใจเชิงสถาปัตยกรรมมากกว่าไวยากรณ์
- แต่ตอนนี้ นักพัฒนากำลังย้ายไปสู่งานในเวิร์กโฟลว์ระดับสูงที่ต้องคอยกำกับเอเจนต์ AI โดยยังไม่มีประสบการณ์ระยะยาวแบบนั้น
- ปัญหาคือเวิร์กโฟลว์ลักษณะนี้กลับต้องการทักษะชุดเดียวกับที่ปกติได้มาจากประสบการณ์หลายสิบปี
- แม้แต่วิศวกรอาวุโสก็ไม่ใช่ข้อยกเว้น
- Simon Willison ซึ่งเป็นนักพัฒนาที่มีประสบการณ์เกือบ 30 ปี กล่าวว่า หากไม่มี “mental model ที่มั่นคง” ว่าแอปพลิเคชันทำอะไรได้บ้างและทำงานอย่างไร การให้เหตุผลก็จะยากขึ้นเรื่อย ๆ เมื่อมีฟีเจอร์เพิ่มเข้ามา
paradox ของผู้ควบคุมที่มีทักษะ
- งานวิจัย ล่าสุดของ Anthropic กล่าวถึง “paradox of oversight” ว่าเป็นความเสี่ยงของการใช้เอเจนต์เขียนโค้ดบ่อยครั้ง
- แก่นสำคัญคือ การใช้ Claude ให้มีประสิทธิภาพต้องมีการกำกับดูแล และการกำกับดูแล Claude ก็ต้องอาศัยทักษะการเขียนโค้ดแบบเดียวกันซึ่งอาจอ่อนแอลงจากการใช้ AI มากเกินไป
- Sandor Nyako ผู้ดูแลวิศวกร 50 คนใน LinkedIn เห็นการถดถอยของทักษะแพร่กระจายในองค์กร จึงขอให้ทีม “อย่าใช้ AI กับงานที่ต้องใช้การคิดเชิงวิพากษ์หรือการแก้ปัญหา”
- เขามองว่าการพัฒนาทักษะต้องอาศัยการผ่านความยากลำบากและการฝึกกล้ามเนื้อแห่งการคิดปัญหาอย่างลึกซึ้ง และหากไม่มีการคิดเชิงวิพากษ์ ก็ยากที่จะตั้งคำถามว่า AI ถูกต้องหรือไม่
- แม้เกณฑ์ของคำว่า “ใช้มากเกินไป” จะยังไม่ชัดเจน แต่ทั้งงานวิจัยเชิงข้อมูล และหลักฐานเชิงประสบการณ์ชี้ว่าทักษะอาจอ่อนแอลงอย่างรวดเร็วได้ภายในไม่กี่เดือน
- การใช้เอเจนต์เขียนโค้ดจึงสร้างความย้อนแย้งที่มันบั่นทอนทักษะซึ่งจำเป็นต่อการกำกับเอเจนต์ให้ดีเสียเอง
LLM เร่งส่วนที่ผิดให้เร็วขึ้น
- สิ่งที่จำเป็นไม่ใช่การเขียนโค้ดให้เร็วขึ้นเสมอไป
- โดยเฉพาะอย่างยิ่ง ไม่ได้จำเป็นต้องทำให้การสร้างโค้ดที่ยังไม่เข้าใจอย่างถ่องแท้ หรือโค้ดจำนวนมหาศาลที่รีวิวไม่ไหวภายในเวลาสมเหตุสมผล เร็วขึ้นกว่าเดิม
- ก่อนยุค AI ลำดับความสำคัญของนักพัฒนาที่ดีมักเป็นดังนี้
- เข้าใจความสัมพันธ์ระหว่างโค้ดกับโค้ดเบส
- ตรวจสอบว่าเป็นไปตามมาตรฐานที่มีการบันทึกไว้และมีประสิทธิภาพ
- ลดจำนวนบรรทัดโค้ดให้เหลือน้อยที่สุดเท่าที่จำเป็นต่อการบรรลุเป้าหมาย โดยยังคงความอ่านง่าย
- คำนึงถึงเวลาในการประมวลผล
- Agentic coding และ LLM กลับแทบจะสลับลำดับความสำคัญเหล่านี้
- ความสามารถและรูปแบบการใช้งานในปัจจุบันมีแนวโน้มเน้นเพิ่มปริมาณโค้ดที่สร้างได้ภายในเวลาที่กำหนดเพื่อเร่งความเร็ว
- ความเร็วเป็นผลลัพธ์ตามธรรมชาติของความชำนาญสูง แต่เมื่อฝืนเร่งก็จะนำไปสู่ความแม่นยำที่ลดลง
- แม้ LLM จะสามารถใช้ในแบบที่เพิ่มความเข้าใจเชิงลึกและความกระชับได้ แต่การบังคับใช้ในองค์กรและความคลั่งไคล้ การวัดผลจากปริมาณการใช้โทเคน แสดงให้เห็นว่าการใช้งานจริงมักไม่ได้เป็นเช่นนั้น
การเขียนโค้ดก็คือการวางแผนด้วย
- นักพัฒนาบางคนวางแผนและคิดได้ดีกว่าเมื่อใช้โค้ด
- การคิดและทำงานผ่านโค้ดไม่ใช่งานซ้ำซากไร้ความหมาย แต่เป็นกระบวนการที่บังคับให้คิดในระดับเทคนิค ทั้งเรื่องความปลอดภัย ประสิทธิภาพ ประสบการณ์ผู้ใช้ และความสามารถในการบำรุงรักษา
- Dax ผู้สร้าง OpenCode กล่าวในบทสัมภาษณ์เกี่ยวกับ Spec Driven Development ว่า เมื่อทำงานใหม่หรือยาก เขาจะค้นหาว่าต้องทำอะไรด้วยการพิมพ์โค้ดเอง
- เขาชอบจับต้อง type, ปฏิสัมพันธ์ระหว่างฟังก์ชัน และโครงสร้างโฟลเดอร์ด้วยตัวเองเพื่อสร้างภาพของแนวคิด แทนที่จะเขียนสเปกก้อนใหญ่ก่อน
- สิ่งที่มนุษย์พูดออกมาไม่ได้ตรงกับเจตนาที่แท้จริงเสมอไป และ LLM จะเติมความคลุมเครือด้วยการคาดเดาหรือการหลอน
- ผลลัพธ์คือมีการรีวิวมากขึ้น การแก้โดยเอเจนต์มากขึ้น การใช้โทเคนมากขึ้น และความแยกขาดจากสิ่งที่ถูกสร้างมากขึ้น
- ในทางกลับกัน แม้จะเขียนพรอมป์ต์ที่ชัดเจนและมีโครงสร้างมาก LLM ก็ยังอาจสร้างเมธอดที่หลอนขึ้นมาได้
- LLM ไม่ใช่คอมไพเลอร์ แต่เป็นเครื่องทำนายโทเคนถัดไป จึงไม่สามารถแทนที่ระบบเชิงกำหนดด้วยระบบเชิงความน่าจะเป็น แล้วคาดหวังให้ความกำกวมกลายเป็นศูนย์ได้
- แม้แต่นักพัฒนาอาวุโสที่ สนับสนุน AI อย่างจริงจัง ก็เริ่มมองว่าความแยกขาดนี้เป็นปัญหาที่ใหญ่ขึ้นเรื่อย ๆ
vendor lock-in และความไม่แน่นอนด้านต้นทุน
- ระหว่างที่ Claude ล่ม มีโพสต์ออกมาว่านักพัฒนาและทีมวิศวกรรมบางส่วนหยุดทำงานไปเลย
- เวิร์กโฟลว์และความสามารถในการเขียนโค้ดบางส่วนได้พึ่งพาผู้ให้บริการ AI รายใดรายหนึ่งอย่างหนักแล้ว
- ทักษะที่ครั้งหนึ่งเคยทำได้ด้วยแค่คีย์บอร์ดกับโปรแกรมแก้ไขข้อความ ตอนนี้กลับต้องพึ่งการสมัครใช้งานจากผู้ให้บริการโมเดล AI
-
ต้นทุนโทเคนคาดเดาได้ยาก
- ผู้ให้บริการโมเดลได้รับการอุดหนุนอย่างมหาศาล และตัวโมเดลเองก็อยู่บนฐานที่เปลี่ยนตลอดเวลา
- การเปิดตัวโมเดลใหม่มักวนซ้ำเป็นแพตเทิร์นเดิม คือคะแนน benchmark สูง กระแส hype แล้วตามด้วยคำบ่นว่า “โดน nerf” หลังใช้งานจริง
- และมักมีคำบ่นตามมาว่าการทำงานแบบเดิมกลับเผาโทเคนมากขึ้น 2-3 เท่า
- ต้นทุนพนักงานยังพอประเมินได้ แต่ต้นทุนโทเคนคาดการณ์ได้ยากทั้งรายวัน รายเดือน และรายปี
- หากทั้งทีมใช้ agentic coding เป็นค่าเริ่มต้น บัญชีค่าใช้จ่ายต้องยืดหยุ่นมากเป็นพิเศษ
- Primeagen บอกว่าหากใช้เวิร์กโฟลว์แบบ agentic เต็มรูปแบบ “ผู้ให้บริการโมเดลก็แทบจะเป็นเจ้าของคุณ”
- อาจเกิดโครงสร้างอุตสาหกรรมที่ต้องจ่ายต้นทุนการบริโภคโทเคนเพื่อทำสิ่งที่ครั้งหนึ่งเคยอาศัยการคิดเชิงวิพากษ์และทักษะการแก้ปัญหา
- นี่ไม่ใช่แค่ vendor lock-in ระดับผลิตภัณฑ์ แต่ใกล้เคียงกับการผูกติดผู้ให้บริการในระดับศักยภาพทางเทคนิคของทั้งอุตสาหกรรม
- ฐานรากทั้งทางการเงินและทางปัญญาอาจสั่นคลอนได้ทุกเมื่อ และ local LLM ก็ยังไม่พร้อมจะรองรับปริมาณการใช้งานระดับนั้น
- นี่ไม่ใช่ปัญหาในทางทฤษฎี แต่มีการรายงานแล้ว และผู้ให้บริการโมเดลเองก็พูดถึงโดยตรง
- งานวิจัยอีกชิ้นของ Anthropic ระบุว่าทักษะการดีบักลดลงอย่างมากถึง 47%
- หากนำ AI เข้าไปใช้ในที่ทำงานอย่างดุดัน โดยเฉพาะในวิศวกรรมซอฟต์แวร์ คนอาจหันไปพึ่ง AI เพื่อผลลัพธ์ที่เร็วขึ้น แทนที่จะสร้างทักษะหลักในการดีบักเมื่อเกิดปัญหา
แนวทางที่ลดบทบาทของ AI ลง
- LLM สามารถเป็นเครื่องมือทรงพลังสำหรับการเรียนรู้และการพัฒนาความสามารถ
- มันช่วยให้สำรวจแนวคิดและเทคนิคได้ลึกและกว้างขึ้น และทดลองไอเดียใหม่ ๆ ได้ด้วยแรงน้อยกว่าเดิม
- ตัวเครื่องมือสร้างโค้ดเองก็ไม่ใช่เรื่องใหม่
- Emmet, การเติมข้อความอัตโนมัติ และ snippet ล้วนเป็นเครื่องมือที่ช่วยให้เขียนโค้ดตรง ๆ น้อยลงแล้วสร้างได้มากขึ้น
- COBOL เองก็พยายามใช้คำสไตล์อังกฤษอย่าง
MOVE,WRITEเพื่อใส่คำสั่งให้มากขึ้นด้วยการพิมพ์น้อยลง - motto ของ jQuery ก็เคยเป็น “write less, do more”
- LLM จึงอาจมองได้ว่าเป็นอีกหนึ่งส่วนเสริมของเครื่องมือสร้างโค้ดเหล่านี้
- ความแตกต่างสำคัญอยู่ที่การใช้ LLM และเอเจนต์เขียนโค้ดเป็นกระบวนการเสริม
- เป็นไปได้ที่จะใช้ AI ช่วย brainstorm ในขั้นวางแผน แต่ยังคงมีส่วนร่วมอย่างจริงจังในขั้นลงมือทำ โดยไม่ต้องเอาทักษะส่วนบุคคลไปแลกกับผลิตภาพ
- หากมอบหมายงานเฉพาะเมื่อจำเป็น ก็จะได้ประโยชน์ด้านผลิตภาพพร้อมลดหนี้ด้านความเข้าใจไปด้วย
รูปแบบการใช้งานในชีวิตประจำวัน
- ใช้ LLM เพื่อสร้างสเปกและแผน แต่ให้มนุษย์เป็นผู้นำการลงมือทำ
- นี่เป็นการกลับด้านเวิร์กโฟลว์แบบ “orchestration” และขึ้นอยู่กับงานว่าอาจเขียนโค้ดเองตั้งแต่ 20% ถึง 100%
- แม้ตอนใช้โมเดลก็มักเขียน pseudocode บ่อย ๆ เพื่อลดระยะห่างระหว่างคำขอกับโค้ดที่สร้าง
- ใช้โมเดลเป็นเครื่องมือสร้างโค้ดชั่วคราว เอกสารแบบโต้ตอบได้ และเครื่องมือรีเสิร์ช
- ใช้มันเหมือนเครื่องมือมอบหมายงานอย่างมีความรับผิดชอบ เพื่อถามคำถาม ทำซ้ำ รีแฟกเตอร์ และทำให้แนวทางชัดเจนขึ้น
- ไม่สร้างโค้ดมากเกินกว่าปริมาณที่รีวิวได้ในคราวเดียว
- ถ้าโค้ดมากเกินกว่าจะรีวิวไหว ก็ชะลอความเร็ว แยกงานให้ย่อยลง และหากจำเป็นก็รีแฟกเตอร์ด้วยตัวเองเพื่อให้เข้าใจผลลัพธ์สุดท้ายอย่างครอบคลุม
- จะไม่มอบหมายงานให้ LLM หรือเอเจนต์ หากเป็นการลงมือทำที่ตัวเองไม่เคยทำมาก่อน หรือทำเองคนเดียวไม่ได้
- ข้อยกเว้นคือกรณีเพื่อการศึกษา أو tutorial และผลลัพธ์ที่ได้ก็มักถูกทิ้งในภายหลัง
- สรุปคือ ควรใช้ AI ให้เหมือน Ship’s Computer มากกว่า Data จาก Star Trek
ทำงานให้ดีกว่า ไม่ใช่แค่เร็วกว่า
- การเพิ่มผลิตภาพจากโมเดลนั้นมีอยู่จริง
- ในขณะเดียวกัน แรงเสียดทานและความเข้าใจที่เกิดจากการลงมือทำงานโดยตรงและบ่อยครั้งก็สำคัญจริงเช่นกัน
- ความพยายามที่จะทำให้การเขียนโค้ดเป็นประชาธิปไตยโดยไม่ต้องเข้าใจโค้ดนั้นล้มเหลวมาซ้ำแล้วซ้ำเล่า
- การจะเข้าใจโค้ดได้ ต้องเข้าไปปะทะและทำงานกับโค้ดโดยตรง
- หากไม่เกี่ยวข้องกับโค้ดและไม่เขียนโค้ดอย่างต่อเนื่อง ก็อาจสูญเสียทั้งความเข้าใจและความเชื่อมโยงนั้นไป
- เมื่อสูญเสียความเข้าใจ ความสามารถในการกำกับเอเจนต์ให้ดีขึ้นก็จะอ่อนลง และช่วงเปลี่ยนผ่านสู่การเขียนโค้ดด้วย AI ก็จะกลายเป็นช่วงที่แปลกและเครียดเกินจำเป็น
มันอาจเป็นการทดลองที่ใหญ่กว่าเดิม
- กระแสปัจจุบันดูเหมือนเป็นการทดลองขนาดใหญ่อีกครั้งที่เราทำกับตัวเองโดยยังไม่เข้าใจผลกระทบระยะยาวดีพอ
- ตอนรับโซเชียลมีเดียเข้ามา เราก็ยังไม่เข้าใจผลระยะยาว และต่อมาก็เกิดปัญหาต่าง ๆ เช่น ภาวะขาดสมาธิในวงกว้าง
- ครั้งนี้สิ่งที่เอามาเสี่ยงมีความสำคัญยิ่งกว่า
- Jeremy Howard ผู้ก่อตั้ง fast.ai กล่าวว่าคนที่ฝากทุกอย่างไว้กับ AI agent กำลังรับประกันการหมดความสำคัญของตัวเอง
- หากเอาการคิดทั้งหมดไปเอาต์ซอร์สให้คอมพิวเตอร์ ก็จะหยุดกระบวนการพัฒนาความสามารถ การเรียนรู้ และการเก่งขึ้น
1 ความคิดเห็น
ความเห็นจาก Hacker News
ตลอดหลายปีที่ทำงานกับ agentic coding ผมได้เรียนรู้เกี่ยวกับภาษา ระบบ และเครื่องมือที่ใช้ มากกว่าตอนเขียนโปรแกรมด้วยมือตลอด 35 ปีที่ผ่านมาเสียอีก
ความสามารถในการตัดสินใจเลือกระบบ เทคนิค และแนวทาง ยังไงผมก็ยังเหนือกว่าเครื่องมือเหล่านี้มาก แต่เครื่องมือพวกนี้ก็เหมือนเด็กฝึกงานที่รอบรู้มาก รู้รายละเอียดจุกจิกเยอะ ประสบการณ์น้อยและพลาดแบบกระตือรือร้น แต่ช่วงแรกอย่างน้อยก็รับฟีดแบ็กและลงมือปรับตามได้ เพียงแต่ไม่ได้เข้าใจและซึมซับอย่างแท้จริง เลยมักจะลืมบ่อย
การอ้างว่าคุณต้องรู้ทุกอย่างที่ตัวเองกำลังทำอยู่นั้นไร้เดียงสามาก ถ้าคุณทำงานมากกว่าหนึ่งหรือสองทีม ก็จะมีหลายส่วนที่คุณไม่เข้าใจทั้งหมด และถ้าเป็นโค้ดเบสเก่า แทบทุกส่วนอาจดูแปลกหน้าไปหมด ใน monorepo ขนาดมหึมาที่สะสมมาหลายสิบปี แค่เข้าใจแม้แต่ส่วนที่ทุกคนมองว่าคุณเป็นผู้เชี่ยวชาญจริง ๆ ก็ถือว่าโชคดีแล้ว
คนที่พูดแบบนี้ส่วนใหญ่มักจะยังจูเนียร์มาก ทำงานคนเดียวแทบทั้งหมด หรือไม่ก็เหมือนจับโปรเจ็กต์เดียวมานาน 20 ปี คนที่ทำงานในทีมหรือองค์กรใหญ่ไม่มีใครบอกได้ว่ารู้ทั้ง codebase และคนที่ทำ agentic programming ก็ไม่ต่างกัน อย่างน้อยคุณยังถาม agent ได้ และในฐานะคนที่อ่านโค้ดคนอื่นมาทั้งชีวิต ผมก็อ่านโค้ดที่ LLM เขียนได้เหมือนกัน โค้ดแย่จะมาจากเครื่องหรือคนก็ไม่ได้ต่างอะไรสำหรับผม และอย่างน้อยเครื่องก็รับฟีดแบ็กของผมแล้วเอาไปทำต่อ
ผมเห็นทีมซอฟต์แวร์จำนวนมากหยุดนิ่งเพราะแม้แต่ปัญหาเล็กน้อย พอถึงจุดที่ต้องใช้ทักษะเพิ่มอย่างภาษา low-level, assembly, อัลกอริทึมหายาก, หรือ network protocol ก็แก้ต่อไม่ได้
ในทางกลับกัน บางครั้งก็ติดเพราะไม่ใช่ว่าขาดความสามารถในการตีความสิ่งที่เห็น แต่เพราะใช้สิ่งที่เป็น black box อย่างไลบรารีหรือระบบปฏิบัติการแบบ proprietary เลยขุดดูข้างในไม่ได้และไม่มีทางตรวจสอบการทำงานจริง
เพราะงั้นต่อให้จำเป็นน้อยมาก ผมก็คิดว่าสภาพแวดล้อมที่ทำให้เราสืบรู้ทุกอย่างเกี่ยวกับสิ่งที่เรากำลังทำงานอยู่ได้ทั้งหมด ควรต้องเป็นไปได้เสมอ
สิ่งสำคัญคืออย่ากลัวที่จะเรียนรู้ส่วนที่เหลือของระบบ และต้องรักษา ดัชนี เอาไว้
เหนือสิ่งอื่นใดคือคุณต้องทำความเข้าใจอะไรก็ตามได้อย่างรวดเร็ว แบบนั้นถึงจะทำงานได้กว้าง รู้ว่าเมื่อไรควรขุดลึก และเมื่อไรควรสแกนในระดับสูง เพื่อเลือกระดับที่เหมาะกับปัญหา
นานมาแล้วตอนเรียนมหาวิทยาลัย เขาสอนวิศวกรรมโดยรวมให้กับนักศึกษาวิทยาการคอมพิวเตอร์ ผมเคยถามว่า “แล้วเมื่อไรผมจะต้องรู้ chemical engineering หรือ analog control systems?” คำตอบคือ “คงไม่ได้ใช้หรอก แต่คุณควรทำความเข้าใจมันให้เร็วพอที่จะเอาไปเขียนโค้ดได้ แล้วค่อยลืมทีหลัง เรากำลังให้พื้นฐานที่แข็งแรงกับคุณ”
เรื่องนี้ใช้ได้ตรงตัวแม้ภายใน codebase ขนาดใหญ่
เครื่องมืออย่าง git-ai [0] จะจับ session ของ LLM ไว้ และเชื่อมการแก้ไขแต่ละไฟล์กับการกระทำของ agent แบบเฉพาะเจาะจง ทำให้ agent สามารถเรียกดูบทสนทนารอบ ๆ code fragment นั้นได้ เช่น ผู้ใช้ prompt อะไรไว้ หรือเหตุผลของ LLM ที่สร้างโค้ดส่วนนั้นคืออะไร มันอาจเปลี่ยนสมดุลได้ แต่ก็ยังไม่แพร่หลาย
[0] https://usegitai.com/
ในฐานะนักพัฒนาอาวุโสที่ทำงานมาเกิน 25 ปี ไม่นานมานี้ผมโดนโยนเข้าประชุมแบบ “เข้ามาแค่ 5 นาทีได้ไหม” ซึ่งเป็นการประชุมที่ถูกลากเข้าไปกลางคันโดยไม่มีบริบทอะไรเลย และผมเกลียดมาก
คำถามถูกยิงใส่อย่างรวดเร็วโดยไม่มีบทนำ และเป็นเรื่องของ integration ภายนอกตัวหนึ่งจากหลายสิบตัว ยิ่งแย่กว่านั้นคือฝั่งนั้นใช้ศัพท์เฉพาะของตัวเองที่ไม่เหมือนเรา
เพราะตอนสร้าง integration พวกนี้ผมพึ่งโมเดลหนักมาก ผมเลย ลำบากมาก ในการเข้าใจคำถาม มันเป็นงานที่น่าเบื่อสุด ๆ และมีสเปกภายนอกหนา ๆ ให้มาอยู่แล้ว
ผมยังมองในแง่ดีว่า ถ้าไม่ได้ใช้โมเดล ต่อให้ใช้เวลามากกว่าเดิม 10 เท่า integration พวกนี้ก็คงไม่เสร็จอยู่ดี แต่ตอนนี้ผมกำลังคิดอย่างจริงจังว่าจะกลับไปเขียนเอกสาร “จุดอ๋อ” ต่าง ๆ ใหม่ เพื่อไม่ให้มีช่วงน่าอึดอัดแบบนี้อีก
ผมไม่เคยรู้สึกทั้งไม่รู้เรื่องและน่าอายขนาดนี้ในห้องประชุมมาก่อน และทั้งหมดที่พูดได้คือ “เดี๋ยวผมไปเช็กแล้วจะตอบ”, “อันนี้ด้วย”, “อันนั้นด้วย”
หนี้ทางการรับรู้ มีอยู่จริง และสำหรับผมมันเจ็บกว่าหนี้ทางเทคนิคอีก หนี้ทางเทคนิคเป็นสิ่งที่ทั้งทีมแบกร่วมกัน แต่หนี้ทางการรับรู้เป็นเรื่องส่วนบุคคล และถ้าคนที่สร้างมันคือผมเอง ผมก็ควรรู้มันให้ดีกว่านี้
ต่อไปนี้ถ้ายังไม่ได้ทำรายการศัพท์แบบ Markdown สไตล์แฟลชการ์ด 5 นาทีประเภท “นี่คืออะไร”, “นั่นคืออะไร” ผมจะถือว่างานยังไม่เสร็จ
ถ้าคุณเป็น senior developer คุณก็คือคนที่ต้อง เหยียบเบรก กับพฤติกรรมที่ไม่น่าพอใจ คุณมีอำนาจที่จะพูดว่า “คำถามน่าสนใจนะครับ แต่ถ้าจะให้มุมมองของผม ผมต้องมีบริบทมากกว่านี้ ช่วยอธิบาย architecture ของระบบคร่าว ๆ หรืออธิบายว่าพวกคุณกำลังพยายามแก้ปัญหาอะไรด้วยแนวทางนี้ได้ไหม?”
เวลาถูกปฏิบัติแบบนั้น การตอบว่า “ถ้าจะตอบคำถามนี้ให้ถูกต้อง ผมต้องไปดูเอกสารกับโค้ดก่อน” ถือว่าโอเคมาก และค่อนข้างเป็นคำตอบเชิงการทูตด้วย
การประชุมที่มองความเชี่ยวชาญไม่ใช่เป็นสิ่งที่ต้องค่อย ๆ สั่งสม แต่เป็นแค่เครื่องมือเอาไว้ยืนยัน confirmation bias แบบสร้างสรรค์นั้นไม่สนุกเลย
ถ้าจะหาปัญหาในโค้ดที่ถูก generate ขึ้นมา นักพัฒนาต้องใส่ใจ หลายนักพัฒนา โดยเฉพาะในบริษัทใหญ่ ๆ หลุดออกจากงานไปมากแล้ว และแค่มองหาวิธีปิด ticket ด้วยแรงให้น้อยที่สุดแล้วโยนความรับผิดชอบต่อไป
คนแบบนั้นถึงจะมีความสามารถ ก็จะไม่พยายามทำความเข้าใจโค้ดที่ generate มาให้ดีพอจะหาปัญหาที่ agent พลาดไป โดยเฉพาะในกระแส ความคลั่งความเร็วที่ขับเคลื่อนด้วย AI แบบตอนนี้
โค้ดที่ generate มาดูเหมือนถูกต้องในเชิงภาษา แต่บ่อยครั้งจะเลียนแบบ idiom ทั่วไปแบบไม่รู้ตัวอย่าง incoherent ทำให้บั๊กจริง ๆ อาจซ่อนอยู่แบบบังเอิญในลักษณะที่มนุษย์ปกติ หรือแม้แต่นักเขียนโปรแกรมแย่ ๆ ก็ยังนึกไม่ถึง
LLM ไม่มีการประเมินภายในของตัวเอง ดังนั้น reviewer ต้องประเมินทีละบรรทัด พร้อมกับสร้างเหตุผลแฝงและความรู้โดยนัยที่ LLM ไม่เคยมีขึ้นมาใหม่ตั้งแต่ต้น บางทีก็ถูกดึงไปเสียเวลาแพง ๆ กับเรื่องที่ไม่ใช่ปัญหา
ถึงจุดนี้หลายครั้งมันกลายเป็นการลงทุนมากกว่าการเขียนเองตั้งแต่แรก
บางทีตอนนี้บริษัทต่าง ๆ กำลังซื้อ junk AI และในขั้นถัดไปก็กำลังถูกสัญญาว่าจะได้ “ทางแก้” นั้น ทุนนิยมกำลังทำงานตรงตามที่คาดไว้เป๊ะ
ผมว่าบทความนี้หลุดประเด็นหลักไปนิดหน่อย
การใช้ AI มาก ๆ ทำให้เกิด การเสื่อมทักษะ จริง
แต่ผมอยากยอมรับช้างตัวใหญ่ที่อึดอัดอยู่กลางห้อง AI กำลังทำให้คนเร็วขึ้นมาก ไม่ได้แปลว่าผลผลิตที่เร็วขึ้นนั้นแย่ในตัวเอง แต่หมายถึง output กับโค้ดกำลังวิ่งนำหน้าความเข้าใจและประสบการณ์โดยรวมที่สร้างมันขึ้นมา เรากำลังให้รางวัลกับคนที่พูดเรื่องคุณค่าทางธุรกิจได้ มากกว่าคนที่สร้างของด้วยความรู้ลึกและตัดสินใจอย่างปลอดภัย
AI อาจดีและอาจสร้างทางออกที่ดีได้ แต่ท้ายที่สุดมันไม่รู้จริง ๆ ว่าตัวเองกำลังทำอะไร และต่อให้ดีที่สุดก็ยังต้องการคนกำกับที่แข็งแรง
ตอนนี้เราอยู่ในบ่อโคลนของ business-driven development และชื่อเสียงที่ควรลงโทษการตัดสินใจแย่ ๆ ก็ยังไม่รุนแรงพอ
พูดอีกแบบคือผมไม่แน่ใจว่าการเสื่อมทักษะเป็นปัญหาใหญ่ขนาดนั้นหรือเปล่า มันอาจเป็นแค่สัญญาณว่าลักษณะงานของเรากำลังเปลี่ยนไปก็ได้ เราอาจเข้าสู่ยุคที่ความสามารถในการรู้ architecture ที่ดี มีค่ามากกว่าการท่องมาตรฐาน C++ หรือใช้ฟีเจอร์นับร้อยอย่างถูกต้อง
ในการพัฒนาปกติ เรามักจะวนกลับไปถามกันมากกว่าว่า “เราต้องการสร้างสิ่งนี้จริงหรือ”, “ถ้าทำแบบนี้อะไรอาจพังได้บ้าง” และในอุดมคติก็ควรทำก่อน approve PR หรือก่อน merge/deploy ตอนนี้บางส่วนกำลังถูกย้ายไปเป็น “เดี๋ยวดูทีหลังว่ามีใครบ่นไหม” อย่างที่เขาว่า ป้องกันไว้หนึ่งออนซ์ ดีกว่ารักษาทีหลังหนึ่งปอนด์
แถมโค้ดนั้นก็ไม่ใช่ C++ แบบ idiomatic ของโปรเจ็กต์นั้นเลย และ LLM ยังเมิน API ที่มีอยู่แล้วไปหมด แก้ได้ก็จริง และ maintainer ก็ควรจับได้ แต่เพราะปริมาณโค้ดที่ถูก generate ออกมา ทุกคนเลยต้องใช้พลังงานมากเกินไป
บล็อกโพสต์แบบนี้คงเขียนด้วยความช่วยเหลือของ AI อย่างไม่ต้องสงสัย และก็เป็นหัวข้อคอมเมนต์ทั้งที่นี่และทั่วอินเทอร์เน็ตมาหลายปีแล้ว การฝ่อของทักษะ เป็นความกังวลใหญ่ และทุกคนที่สงสัย AI มาตั้งแต่ปี 2022 ก็พูดซ้ำเรื่องนี้มาตลอด แต่ดูเหมือนบางคนกับบางที่ก็ไม่สนใจอยู่ดี
ถ้าวันหนึ่งคุณแค่คอยดึงคันโยกของ เครื่องผลิตขยะ โดยไม่มี insight ต่อโค้ดเลย มันก็สมเหตุสมผลที่หัวหน้าจะถามว่าทำไมคุณควรได้เงินเดือนเกิน 50,000 ดอลลาร์
การใช้ AI เพื่อให้ไปเร็วขึ้นคือการ optimize สิ่งที่ผิด ทุกที่ที่ผมเคยทำงานมา เวลาที่ใช้ไปกับ “การเขียนโค้ด” เองมีน้อยที่สุดเมื่อเทียบกับงานอื่นทั้งหมดที่ต้องทำเพื่อส่งมอบฟีเจอร์
ลองดูฟีเจอร์หนึ่งที่จริง ๆ แล้วเขียนโค้ดเสร็จได้ในวันเดียว ก่อนอื่นคุณต้องวางแผนทุกอย่างผ่านพิธีกรรมแบบ Agile หรือ Waterfall ที่บริษัทใช้ แยกงาน ทำ JIRA ticket และตัดสินใจว่าใครจะทำ แค่นี้ก็อาจกินเวลาหลายวันหรือหลายสัปดาห์แล้ว จากนั้นต้องเขียน design doc สำหรับแนวทางที่เสนอและให้เพื่อนร่วมงานกับทีมรีวิว ถ้าเป็นฟีเจอร์จริงจังก็เพิ่มอีกหนึ่งสัปดาห์ ถ้ามีหลายทีมเกี่ยวข้อง ก็ต้องเอาฉันทามติและข้อตกลงด้าน design จากทีมเหล่านั้น เพิ่มอีกสัปดาห์ ในบางที่ยังต้องขออนุมัติเริ่มงาน ซึ่งก็อาจเพิ่มอีกหลายวันตามตารางและความพร้อมของผู้อนุมัติ
จากนั้นคุณก็ใช้เวลาหนึ่งวันเขียนโค้ดและทำให้ test ผ่าน
ต่อไปคือ code review มีการโต้กลับไปมาหลายรอบกับทีม อาจต้องรีวิวซ้ำและขอรีวิวเพิ่ม อีกหลายวันหรือหลายสัปดาห์ก็ผ่านไป ถ้าเป็นบริษัทใหญ่กว่านั้น คุณยังต้องผ่านรีวิวจากฝ่ายอื่นอีกสารพัด เช่น legal, privacy, performance, accessibility, QA แม้จะทำคู่ขนานกันก็เผื่อไว้อย่างน้อยอีก 2 สัปดาห์ สุดท้ายต้องขึ้น staging แล้วปล่อยให้ internal dogfooder ใช้งานสักพักจนมั่นใจว่ามันทำงาน เพิ่มอีก 1 สัปดาห์ ตอนนี้พร้อมจะขึ้น production แล้ว แต่ถ้าเป็นบริษัทที่จริงจัง ก็ไม่มีใครปล่อยอะไรขึ้น production 100% ทันที ต้องค่อย ๆ เพิ่มสัดส่วน พร้อมดู feedback และ metrics เผื่อต้อง rollback กว่าจะ rollout ครบก็อาจกินอีก 2 สัปดาห์
สรุปคือจากดีไซน์จนถึงปล่อยจริง ฟีเจอร์หนึ่งกินเวลาราวสองเดือน แต่เรากลับกำลังวุ่นวายกันเพื่อย่อส่วนที่ใช้เวลา 1 วัน ให้เหลือ 5 นาที
เวลาคุณสร้างซอฟต์แวร์ ต้องจำไว้ว่ามันคือ ภาพสแนปช็อตของความเข้าใจ ต่อปัญหา มันสื่อให้ทุกคนรวมถึงตัวคุณในอนาคตรู้ถึงแนวทาง ความชัดเจน และความเหมาะสมของวิธีแก้สำหรับปัญหาตรงหน้า เพราะฉะนั้นจงเลือกอย่างฉลาดว่าคุณต้องการจะพูดอะไร
ประโยคที่ว่าฟีเจอร์หนึ่งกินสองเดือนตั้งแต่ดีไซน์ถึงปล่อย แต่เรากลับพยายามย่อส่วนหนึ่งวันให้เหลือห้านาทีนั้น ชี้ประเด็นได้ดีมาก
ในบริษัทที่มั่นคง งานประเภทนี้กินเวลาชีวิตประจำวันของวิศวกรทุกคนอยู่ไม่น้อย ไม่ว่าจะเรียกมันว่า “platform engineering” หรืออะไรก็ตาม พื้นที่นี้ตายแล้ว
และยังมีไอเดียที่เสี่ยงในเชิงเทคนิคซึ่งเมื่อก่อนเราไม่ลอง เพราะผลตอบแทนไม่คุ้มกับความเสี่ยงและแรง ตอนนี้กลับอยู่แค่เอื้อม มันไม่ใช่แค่ “ไปเร็วขึ้น” แต่ความเร็วที่คุณทดลองอะไรบางอย่างได้ กำลังเปลี่ยนธรรมชาติของกระบวนการวิศวกรรมเอง
ถ้าวิศวกรซอฟต์แวร์ถูกพอ ความจำเป็นของหลายกระบวนการก็จะหายไป บริษัทที่มีกระบวนการพวกนี้อยู่แล้วคงลำบาก เพราะการทำลายระบบราชการแบบนั้นยากมาก แต่บริษัทที่เดิมไม่มีกระบวนการแบบนี้ หรือสามารถเอาออกได้ จะได้เปรียบในการแข่งขันอย่างมาก
มันไม่ใช่เรื่องใหม่ สตาร์ตอัปแข่งขันกับบริษัทเดิมด้วยความเร็วในการลงมือทำมาโดยตลอด สิ่งใหม่คือความสามารถในการรักษาความเร็วนั้นไว้ได้นานขึ้น
แม้แต่รีวิวด้าน legal, privacy, performance, accessibility, QA ก็อยู่ในขอบเขตที่จะถูกกระทบทั้งหมด ถ้าบริษัทสามารถโยนความรับผิดทางกฎหมายจากรีวิวเหล่านี้ไปให้ผู้ให้บริการภายนอกได้ พวกเขาก็จะทำ
[0] ขอข้ามความประชดที่ว่ากระบวนการส่วนใหญ่เหล่านี้สุดท้ายก็ตกกลับมาอยู่บนบ่าพนักงานคนเดิมที่ตั้งใจจะช่วยประหยัดเวลาให้ไปก่อน
Big Tech มีขั้นตอนโอ้อวดแบบนี้เยอะ แต่บริษัทเล็ก ๆ ยังเคลื่อนที่เร็วและลุยแบบหยาบ ๆ ได้
คุณภาพโค้ดสุดท้ายแล้วขึ้นอยู่กับคุณเอง
ไม่มีอะไรขวางคุณจากการทำงานวนซ้ำกับ agent ไปเรื่อย ๆ จนได้โค้ดคุณภาพ เท่ากับที่คุณเขียนเอง
บทความพวกนี้น่าหงุดหงิดพอสมควร แต่เรื่อง ต้นทุน token ที่ผู้เขียนพูดถึงนั้นเป็นเรื่องจริงและอันตราย
ผมใช้เครื่องมือ AI เพื่อ brainstorm แนวทาง และบางทีก็ให้ generate โค้ด แต่การพิมพ์จริงผมพิมพ์เอง แบบนั้นเมื่อเวลาผ่านไปก็มีโอกาสน้อยลงที่จะลืม กลไกและภาษาการเขียนโปรแกรม
พูดตามตรง ถ้าทั้งหมดกลายเป็นแค่การ prompt ให้ LLM เขียนโค้ดแล้วมานั่งรีวิว ผมก็คงไม่อยากเป็น maintainer โอเพนซอร์ส มันไม่รู้สึกเติมเต็มเลย
ถ้าเป็นงานประจำที่ได้เงินจริง ผมก็สงสัยว่ารูปแบบการใช้ LLM ของผมจะเปลี่ยนไปยังไง เหตุผลที่ผมเป็นนักพัฒนาซอฟต์แวร์ก็เพราะรักเทคโนโลยีนี้เอง ผมชอบการสร้าง ชอบการใช้สมองเปลี่ยนไอเดียให้เป็นโค้ด ถ้างานกลายเป็นแค่การ prompt LLM ผมก็ไม่แน่ใจว่าจะอยากทำอาชีพนี้ต่อไหม อย่างน้อยก็คงเริ่มมองหาการเปลี่ยนอาชีพ
ผมใช้วิธีนี้กับโค้ดที่ต้องดูแลต่อ ถึงอย่างนั้นโมเดลก็ยังสอดข้อมูลผิดเข้ามาเยอะอยู่ดี บางครั้งก็พลาดง่าย ๆ ส่วนมากเป็นข้อมูลที่เมื่อก่อนเคยถูกแต่ตอนนี้ผิดแล้ว
ถ้าเป็นสคริปต์ที่ทิ้งได้หรือสคริปต์ที่ตรวจสอบง่าย ผมก็ปล่อยให้ generate แต่จะขอให้หลีกเลี่ยงการ over-engineer หรือพยายามครอบคลุมทุก edge case เพราะสำหรับสคริปต์ การปล่อยให้มัน error แล้วเห็นขั้นที่พังชัด ๆ มักทำให้เข้าใจง่ายกว่า
ผมหลีกเลี่ยงภาษาอย่าง PowerShell ที่รู้สึกว่าอ่านยาก และชอบให้มัน generate ของที่สั้นพอจะอยู่ในหน้าจอเดียวเพื่อให้ผมอ่านและเข้าใจได้ทั้งหมด Python, Bash, Batch คือภาษาสคริปต์หลักที่ผมใช้
ทุกวันนี้ผมยังปฏิเสธข้อเสนอจาก AI มากกว่า 50% อยู่ดี เพราะมันธรรมดาเกินไป ย้ายโค้ดไปมาดื้อ ๆ โดยไม่มีเหตุผล หรือบางทีก็แค่ผิดเลย
เรื่องตลกคือเทคโนโลยีนี้ดูจะเป็นได้แค่สองแบบ
มันอาจเป็น เทคโนโลยีสำหรับผู้จัดการ ที่มอบหมายงานได้โดยไม่มีความเชี่ยวชาญ แต่ก็ดูไม่ออกว่ามันผิดหรือเป็นไปไม่ได้ หรือเป็น เทคโนโลยีสำหรับคนเขียนโค้ด ที่มีความเชี่ยวชาญอยู่แล้ว แต่จะค่อย ๆ สูญเสียความเชี่ยวชาญนั้นไป
เพราะงั้นผมเลยไม่ค่อยแน่ใจว่ามันมีไว้เพื่อใคร นอกจาก VC และผู้ถือหุ้นของไตรมาสหน้า
อาจนอกเรื่องนิดหน่อย แต่ผมขำที่บทความบอกว่า Spec Driven Development คืออนาคต
ในเชิงเทคนิค เราเคยทำแบบนั้นกันอยู่แล้วตอนยุค Waterfall สมัยที่ยังมีเอกสารดี ๆ อยู่ ผมแอบคิดถึงมันนิดหน่อยด้วยซ้ำ ตลอด 10 ปีที่ผ่านมา หรืออาจนานกว่านั้น ผมมักได้รับ JIRA ticket แค่บรรทัดเดียว ซึ่งแทบไม่ได้ระบุอะไรเลย จนต้องโทรหาคนอื่นบ่อย ๆ
ตอนนี้ผมยังเลี่ยงการทำงานด้วย AI อยู่ กำลังคิดว่าจะลองโมเดล local สักสองสามตัวไว้ใช้ทดลอง แต่ผมไม่ยอมจ่ายเงินให้ของที่สร้างจากการแกะของคนอื่นมา และจนถึงตอนนี้ local model ก็ยังน่าผิดหวัง