- ผู้เขียนไม่ใช้ เครื่องมือ AI สำหรับเขียนโค้ด โดยให้เหตุผลหลักว่า มันไม่ได้ทำให้ตัวเองทำงานได้เร็วขึ้น
- ผู้เขียนมองว่าเวลาในการ ตรวจทานและทำความเข้าใจโค้ด ที่ AI สร้างขึ้น อาจนานกว่าการเขียนเองเสียอีก
- เพราะ คุณภาพของโค้ดและความรับผิดชอบ ยังเป็นของนักพัฒนาเอง การใช้โค้ดจาก AI โดยไม่ตรวจสอบจึงมีความเสี่ยง
- ต่อข้ออ้างที่ว่าให้มอง AI เหมือนเด็กฝึกงาน ผู้เขียนวิจารณ์ว่า AI เหมือน เด็กฝึกงานที่ความจำเสื่อม เพราะมันเรียนรู้ต่อไม่ได้
- ผู้เขียนอธิบายความต่างระหว่างการมีส่วนร่วมในโอเพนซอร์สกับโค้ดจาก AI พร้อมชี้ว่า ปฏิสัมพันธ์กับมนุษย์ให้ไอเดียใหม่ ซึ่งมีคุณค่า
บทนำ
- หลายคนมักถามผู้เขียนว่าใช้ เครื่องมือเขียนโค้ดแบบ Generative AI หรือไม่ และมีความเห็นอย่างไรกับมัน
- บทความนี้จะไม่ถกในเชิงสนับสนุนหรือคัดค้าน แต่จะสรุปเพียง ประสบการณ์ทางเทคนิคส่วนตัว เท่านั้น
- ผู้เขียนอธิบาย เหตุผลในมุมมองทางเทคนิค ว่าทำไม AI จึงไม่ช่วยงานเขียนโค้ดของตน
AI ไม่ได้เร็วกว่า
- ต่อให้ใช้ เครื่องมือเขียนโค้ดแบบ Generative AI ความเร็วในการทำงานของผู้เขียนก็ ไม่ได้เพิ่มขึ้น
- แม้ AI จะช่วยเขียนโค้ดให้ แต่ ความรับผิดชอบต่อโค้ดยังเป็นของผู้เขียน จึงต้องรีวิวอย่างละเอียดและเข้าใจทั้งหมดก่อนนำเข้ามาใช้ในโปรเจ็กต์
- การรีวิวโค้ด ใช้เวลาและสมาธิพอ ๆ กับการเขียนโค้ดเอง และยังมีคำพูดในวงการว่า "การอ่านโค้ดยากกว่าการเขียน"
- การเชื่อโค้ดที่ AI เขียนเหมือนเป็น "กล่องดำ" ถือเป็นทางเลือกที่ ไร้ความรับผิดชอบอย่างมาก หากเกิดบั๊กขึ้นมา ภาระทางกฎหมายและทางการเงินก็ยังตกอยู่กับโปรแกรมเมอร์
- การจะเพิ่มผลิตภาพหรือรายได้ด้วย AI โดยไม่ให้ คุณภาพลดลง และ ความเสี่ยงเพิ่มขึ้น นั้นเป็นไปไม่ได้
AI ไม่ใช่เครื่องมือทวีคูณประสิทธิภาพ
- บางคนอ้างว่า เครื่องมือเขียนโค้ด AI ช่วยทวีคูณประสิทธิภาพ แต่ผู้เขียนมองว่านี่เป็นเพียงความรู้สึกส่วนตัว
- ผู้ใช้บางรายประหยัดเวลาได้ด้วยการ นำโค้ดจาก AI ไปใช้โดยไม่ตรวจสอบ หรือรีวิวเพียงบางส่วน แต่ผู้เขียนข้ามขั้นตอนนี้ไม่ได้ จึงไม่เห็นว่ามันช่วยอะไร
- ผู้เขียนยังไม่เห็นด้วยกับข้ออ้างว่า AI มีประสิทธิภาพสำหรับ การเรียนรู้ภาษาใหม่หรือเทคโนโลยีใหม่ เพราะกระบวนการเรียนรู้สิ่งใหม่เองคือความสนุกของการเขียนโปรแกรม
- ผู้เขียนเรียนรู้ภาษาอย่าง Rust, Go, TypeScript และภาษาอื่น ๆ ด้วยตัวเองจริง ๆ และ ไม่มอบประสบการณ์แบบนี้ให้ AI แทน
- เพราะท้ายที่สุดแล้ว ความรับผิดชอบต่อโค้ดทั้งหมด ก็ยังอยู่ที่ตัวผู้เขียนเอง
โค้ดจาก AI ต่างจากโค้ดของมนุษย์
- ผู้เขียนมักเจอคำถามว่า "โค้ดจากโอเพนซอร์สก็ไม่ใช่โค้ดที่คุณเขียนเองเหมือนกัน แล้วทำไมถึงปฏิบัติต่อมันต่างจากโค้ดของ AI?"
- จริง ๆ แล้วแม้แต่ โอเพนซอร์ส PR ผู้เขียนก็ยังลงทุนเวลารีวิวอย่างละเอียด แต่ การทำงานร่วมกับผู้คน นำไปสู่ไอเดียใหม่และแรงจูงใจ
- แม้จะมีคนบอกว่าการรัน AI agent หลายตัวเพื่อรับ PR สำหรับแก้ bug issue เป็นตัวเปลี่ยนเกม แต่คอขวดของการรีวิวโค้ดก็ยังเป็นคนอยู่ดี จึงยิ่งทำให้ช้าลง
- เมื่อเครื่องมือ AI แพร่หลายขึ้น ก็มี PR คุณภาพต่ำ ถูกสร้างขึ้นบ่อยครั้ง โค้ดจาก AI มักมีความแปลกแยกแบบละเอียดอ่อน และเมื่อถามผู้ส่ง PR ก็มักไม่ได้คำตอบ
- การมีส่วนร่วมต่อโค้ดอย่างมีความรับผิดชอบ และการสื่อสารในชุมชนโอเพนซอร์ส คือจุดต่างสำคัญของโค้ดจากมนุษย์
ความต่างระหว่าง AI กับเด็กฝึกงาน
- แม้จะมีคนเปรียบ AI กับเด็กฝึกงาน แต่ผู้เขียนมองว่า มันต่างกันโดยพื้นฐาน
- โค้ดช่วงแรกของเด็กฝึกงานอาจต้องใช้เวลาและการรีวิวมาก แต่พวกเขา เติบโตได้อย่างรวดเร็วผ่านฟีดแบ็ก
- การลงทุนเพื่อให้เด็กฝึกงานเติบโต จะทำให้สุดท้ายเขากลายเป็นเพื่อนร่วมงานสำคัญที่ทำงานได้อย่างอิสระ
- แต่ เครื่องมือ AI จะลืมความรู้และเริ่มใหม่ทุกครั้งที่เจองานใหม่ ไม่สามารถเติบโตหรือสะสมประสบการณ์ได้
- มันจึงเหมือนเด็กฝึกงานที่ไม่เคยพัฒนาเลย และไม่อาจช่วยเพิ่มผลิตภาพได้
สรุป
- ผู้เขียนต้องการสื่อให้ชัดถึง ปัญหาเชิงเทคนิคของการนำเครื่องมือเขียนโค้ดแบบ Generative AI มาใช้
- ในการเขียนโค้ดด้วย AI ไม่มีคำว่า 'ของฟรีไม่มีในโลก'
- ข้ออ้างว่า AI ทำให้เร็วขึ้นหรือเพิ่มผลิตภาพนั้น มาจากการ ลดมาตรฐานด้านคุณภาพและยอมรับความเสี่ยงเพิ่ม หรือไม่ก็เป็นผลประโยชน์ของ ผู้ขาย AI
- โปรแกรมเมอร์ควรตระหนักไว้เสมอว่า ตนเองคือผู้รับผิดชอบขั้นสุดท้าย
5 ความคิดเห็น
ผมปักหลักใช้โหมด agent ของ copilot (claud) + codex (รัน 3 โมเดลพร้อมกัน: o3/4o/codex-mini ผ่าน mcp) แบบเต็มตัวแล้ว แต่คิดว่าประสิทธิผลของมันต่างกันมาก ขึ้นอยู่กับลักษณะของคนที่ใช้และโปรเจกต์นั้น ๆ
สำหรับผม จะโยนงานไว้พร้อมกันใน 5-6 workspace แล้วค่อยตรวจตามลำดับที่เสร็จ ตัวโมเดลสามารถเข้าไปดูและตรวจสอบได้แม้กระทั่งภายในโค้ดโอเพนซอร์สทั้งหมด เลยรู้สึกว่าค่อนข้างดี พอช่วงพักเที่ยงสั่งงานทิ้งไว้ สักหนึ่งหรือสองงานก็มักจะเสร็จแล้ว บางครั้งก็ปล่อยให้รันข้ามคืน แต่เรื่อง copilot rate limit มันเป็นกล่องดำ...
แม้แต่งานอย่างเคอร์เนลประสิทธิภาพสูง, การทำให้ call stack ทั้งก้อนเรียบง่ายขึ้น, หรือการทำให้โค้ดอ่านง่ายขึ้น ซึ่งสำหรับมนุษย์เป็นงานที่ต้องสลับบริบทเยอะจนใช้เวลา หากให้พรอมป์ต์และเป้าหมายชัดเจน มันก็ทำได้ (เพราะมันสามารถบรรจุโค้ดไว้ในเมมโมรีได้มากกว่ามนุษย์) ดังนั้นการรีวิวแพตช์ในโค้ดแบบนี้จึงค่อนข้างง่าย... และสำหรับคนที่เคยเจอปัญหาล่มจากการใช้ API ผิดพลาดหรือจากบั๊กของโปรเจกต์โอเพนซอร์สเอง การให้ Agent ช่วยตรวจสอบแบบจริงจังก็ส่งผลดีต่อสุขภาพจิตเหมือนกัน...
อย่างไรก็ดี สุดท้ายแล้วนักพัฒนาที่ใช้ก็ต้องเข้าใจแพตช์นั้นได้ และต้องรู้วิธีโยนพรอมป์ต์ด้วย ต้องอาศัยประสบการณ์ในการมองปัญหาให้ออกและนิยามมันอย่างรวดเร็วเพื่อส่งต่อให้มันเริ่มทำงานได้ คล้ายกับที่การพัฒนาเคอร์เนลประสิทธิภาพสูงทำไม่ได้หากไม่มีสมการนั่นแหละ การจับทางให้ได้ว่าปัญหาอยู่ในระดับ chip/os, ระดับแอปพลิเคชัน หรือเป็นปัญหาจาก remote resource ดูเหมือนว่ายังเป็นบทบาทของซีเนียร์อยู่ครับ
จากมุมมองของคนที่ได้ลองใช้ Copilot, ChatGPT ตระกูลต่าง ๆ และ Cursor มาพอสมควร มันเหมาะกับบทบาทระดับเทมเพลตหรือสไนเป็ตของเครื่องมือพัฒนาได้ดี แต่ยังไม่ถึงขั้นเป็นเอเจนต์หรือเพื่อนร่วมงาน
ผมกำลังใช้ cursor อยู่
สำหรับโหมด chat ผมชอบ ask มากกว่า agent เพราะสุดท้ายก็อยากให้เอาไปปรับใช้กับโค้ดของผมหลังจากตรวจสอบแล้ว และโดยรวมก็เห็นด้วยกับข้อเสียแบบเดียวกับที่กล่าวไว้ในบทความ
ถึงอย่างนั้นก็ยังตั้งใจจะใช้ generative AI ต่อไป เพราะมันมักจะสร้างไอเดียหรือโค้ดที่ผมนึกไม่ถึงขึ้นมาได้ จึงมองว่ามีคุณค่ามากพอในฐานะเครื่องมือใช้อ้างอิง
จากประสบการณ์ส่วนตัว ก็รู้สึกคล้ายกันเกี่ยวกับการใช้เครื่องมือเขียนโค้ดแบบ Generative ว่า
ความคิดเห็นจาก Hacker News
บางคนมักมีคำถามทุกครั้งที่เรียนภาษาใหม่หรือเทคโนโลยีใหม่ เมื่อก่อนก็จะค้นหาใน Google หรือโพสต์ถามใน Stack Overflow แล้วรอคำตอบ แต่ตอนนี้ถาม ChatGPT หรือ Gemini ได้ทันที และได้คำตอบเร็วขึ้นมากจนผลิตภาพดีขึ้นอย่างชัดเจน อยากเน้นว่าแค่การได้คำตอบต่อคำถามอย่างรวดเร็วก็ช่วยเร่งกระบวนการเรียนรู้ได้แล้ว
เหตุผลที่ ChatGPT และ Gemini ให้คำตอบที่ถูกต้องได้ ก็เพราะพวกมันเรียนรู้จากความรู้ที่มีอยู่แล้วบนเว็บ รวมถึง Stack Overflow หากทุกคนใช้แต่ AI ในการตั้งคำถาม ในที่สุดแหล่งความรู้สาธารณะที่เชื่อถือได้ก็อาจร่อยหรอไปได้ นี่คล้ายกับการหวนกลับไปสู่ยุคสารานุกรม ซึ่งเป็นยุคที่รวบรวมและขายข้อมูลด้วยต้นทุนสูง อีกทั้งสิ่งที่ผู้เขียนวิจารณ์คือเครื่องมือ AI สำหรับเขียนโค้ดโดยตรง ไม่ใช่เครื่องมือที่ไว้ตอบคำถาม จึงควรแยกอธิบายกัน
ก่อนหน้านี้เคยใช้ API ที่ไม่คุ้นเคยแล้วโปรแกรมแครช พอลองเอา stack trace ใส่ Gemini ก็ได้เบาะแสสาเหตุทันที แก้แค่สองบรรทัดก็จบ ปัญหาแบบนี้ทำให้สัมผัสได้ถึงคุณค่าของ AI อย่างชัดเจน ข้อดีใหญ่คือไม่ต้องเสียเวลางมอยู่นานเพราะความผิดพลาดงี่เง่าในเรื่องที่ไม่คุ้นเคย
การค้นหาทุกวันนี้ยิ่งให้ความสำคัญกับบล็อกสแปมมากขึ้น ดังนั้นการเรียนจากเอกสารทางการหรือคู่มือผู้ใช้ที่เขียนดีจึงให้ความรู้รากฐานมากกว่า เวลาอ่านเอกสาร API ดี ๆ เรามักได้เรียนรู้ทั้งภาพรวมของการออกแบบและฟีเจอร์เพิ่มเติมไปด้วย ตัวอย่างจากบล็อกหรือบทสอนช่วยแก้ปัญหาเฉพาะหน้าได้ก็จริง แต่ไม่ช่วยให้ฝีมือดีขึ้นจริง ๆ เท่าไร เหมือนแค่มีคนช่วยทำการบ้านให้ ดังนั้นจึงคิดว่า ChatGPT ไม่ได้ส่งเสริมการเรียนรู้ด้วยตนเองอย่างแท้จริง
สำหรับปัญหาที่ยาก ต้องมีขั้นตอนตรวจสอบผลลัพธ์จาก AI เสมอ เหตุผลที่ปิดฟีเจอร์เติมโค้ดอัตโนมัติของ AI ก็เพราะในทางปฏิบัติไม่ได้ช่วยประสิทธิภาพมากนัก แถมยังต้องคอยแก้สิ่งไม่จำเป็นเพิ่มอีกเยอะ น่าแปลกที่แม้ใช้แค่โมเดลโลคัลแบบออฟไลน์ล้วน ๆ ก็ยังได้ข้อมูลอ้างอิงที่ใช้ได้พอสมควร ส่วน Gemini ที่ฝังใน Google ก็คุณภาพไม่ค่อยดี สิ่งที่กังวลหลักคือถ้าผู้คนพึ่ง AI อย่างเดียวเพื่อหาข้อมูล คลังความรู้จริงอย่าง Stack Overflow อาจหายไป
AI เหมาะมากกับงานเครื่องมือเล็ก ๆ ที่เป็น boilerplate ของง่ายอย่าง browser extension หรือสคริปต์ Tampermonkey แทบเริ่มทำงานได้ทันทีโดยไม่ต้องอ่านเอกสารมากนัก AI มีประโยชน์พอสมควรกับการเติมโค้ดที่ไม่ซับซ้อนหรือการแก้เล็กน้อย ทำให้โปรเจ็กต์เล็ก ๆ ที่ปกติอาจไม่ได้เริ่มเลย ถูกจัดการได้อย่างรวดเร็ว
ข้อดีที่อาจได้จากการเขียนโค้ดด้วยตัวเองคือมันช่วยสร้าง mental model ที่แข็งแรงเกี่ยวกับปัญหาไว้ในหัว ภายหลังเวลาแก้ปัญหาหรือรวมฟีเจอร์ใหม่ ผลของการเรียนรู้แบบ "ไม่รู้ตัว" นี้จะส่งผลอย่างมาก ต้องสะสมความทรงจำจากการลงมือทำเองจริง ๆ จึงจะพัฒนาฝีมือได้อย่างแท้จริง ในองค์กรที่เคยเห็นมา แม้จะนำ LLM เข้ามาแล้วก็ยังไม่พบการเพิ่มผลิตภาพแบบทวีคูณอย่างมีนัยสำคัญ บางทีเราอาจกำลังเข้าใจผิดว่าการใช้สมองน้อยลงและเลือกทางง่ายคือผลิตภาพก็ได้
คิดว่านี่สรุปปรากฏการณ์ที่คนเคยชินกับการแก้ปัญหาโดยใช้พลังสมองน้อยลง และเข้าใจผิดว่านั่นคือผลิตภาพ ได้ดีมาก ผลการทดลองของ Google Research ในปี 2024 เกี่ยวกับผลด้านผลิตภาพของ LLM พบว่ากลุ่มที่ใช้ LLM ใช้เวลานานกว่ากลุ่มที่เรียนจากหนังสือเสียอีก และมีเพียงผู้เริ่มต้นที่คะแนนดีขึ้นเล็กน้อย ไม่ใช่ผู้ที่เชี่ยวชาญเนื้อหา แต่ผู้เข้าร่วมจำนวนมากกลับเข้าใจเองว่าตนทำงานได้เร็วและแม่นยำขึ้น โดยทีมวิจัยตีความว่าสาเหตุคือ "ภาระทางการรับรู้ที่ลดลง" ลิงก์งานวิจัยที่เกี่ยวข้อง https://storage.googleapis.com/gweb-research2023-media/pubtools/7713.pdf
ถ้าใช้พลังสมองน้อยลงแล้วทำงานได้นานขึ้น แบบนั้นก็อาจรับงานได้มากขึ้นจริงหรือเปล่า? ตอนนี้งานยากมาก ๆ ก็ทำได้แค่ 3~4 ชั่วโมงเท่านั้น มองได้เหมือนถ้าวิ่งมาราธอนได้ด้วยความเร็วระดับเดิน ผลรวมของผลผลิตสุดท้ายก็อาจเพิ่มขึ้น
เห็นด้วยว่าการเขียนโค้ดแบบดั้งเดิมกับ AI coding เป็นคนละทักษะกัน ผมเองก็สงสัยมากกับคำกล่าวที่ว่า AI จะมาแทนการเขียนโค้ด แต่ก็มองว่าตัว "AI coding" เองก็มีเส้นโค้งการเรียนรู้พอสมควร เช่น การจัดการพรอมป์ต์หรือการรักษาบริบท และคิดว่าหลายคนประเมินคุณค่าส่วนนี้ต่ำเกินไป มันคล้ายกับภาพวาดมือกับการถ่ายภาพ ที่เป้าหมายของทั้งสองอย่างอาจต่างกันตั้งแต่ต้น วิธีที่ผมชอบคือ "ให้ AI จัดการงานหนัก ส่วนผมดูภาพรวมการออกแบบและคอยประสานงาน"
การเขียนโค้ดด้วย LLM คล้ายกับการจ้างงานภายนอกที่มากกว่าการเติมคำอัตโนมัติธรรมดา คือเป็นการนิยามงาน-ให้ฟีดแบ็ก-วนซ้ำไปเรื่อย ๆ ความต่างคือความเร็วในการทำงาน (LLM เหนือกว่า) และความน่าเชื่อถือ (มนุษย์เหนือกว่า) แต่ในระยะยาวเส้นแบ่งนี้ก็คงเลือนลงเรื่อย ๆ สิ่งสำคัญคือโดยพื้นฐานแล้วผมเป็นคนที่อยากลงมือกับรายละเอียดของงานเอง ผมเริ่มอาชีพนี้เพราะชอบเรียนรู้และขุดลึกเรื่อง infra กับ programming ดังนั้นจึงหลีกเลี่ยงบทบาทผู้จัดการ และยอมรายได้น้อยกว่าก็ยังอยากทำของเอง ถ้าวันไหน AGI พัฒนาถึงขั้นเป็นเพื่อนร่วมงานได้จริง ค่อยกลับมาสนใจอีกที แม้แต่คำว่า AI เอง ในอนาคตก็อาจไม่ถูกมองว่าเป็นอะไรพิเศษนัก
ต่อให้บอกว่าเส้นโค้งการเรียนรู้ของ AI coding ใหญ่กว่าที่คิด มันก็ยังต่างจากเปียโนที่ต้องทุ่มเวลาหลายปี คนที่เชี่ยวชาญ AI coding ที่สุดในตอนนี้ก็ยังมีประสบการณ์แค่ราว 3 ปีเท่านั้น และโมเดลก็เปลี่ยนตลอด ทำให้ประสบการณ์เก่าใช้กับโมเดลรุ่นปัจจุบันไม่ได้หลายส่วน การที่ไม่มีโครงสร้างแบบได้เรียนจาก master โดยตรงก็เป็นข้อจำกัดอีกอย่าง
ทักษะ AI coding จะมีคุณค่าระยะยาวจริงหรือ? ผมสงสัยว่าชุดทักษะของเครื่องมือ AI ปัจจุบันจะถ่ายทอดไปยังรุ่นถัดไปได้มากแค่ไหน ต่อให้ตอนนี้ช่วยเพิ่มประสิทธิภาพ ก็ต้องเผื่อใจว่าเมื่อโมเดลหรือเครื่องมือเปลี่ยน ทักษะนั้นอาจใช้ไม่ได้อีก
คิดว่าการชำนาญ AI coding ใช้เวลาไม่กี่นาทีหรือไม่ก็หนึ่งชั่วโมงก็พอ เปรียบเทียบแล้วมันไม่ใช่พื้นที่แบบ GDB หรือ UNIX ที่ต้องขุดทีละเล่ม ภาพวาดกับภาพถ่ายเองก็มีหลักการพื้นฐานและเป้าหมายต่างกันโดยสิ้นเชิงจนไม่ควรสับสน เช่นเดียวกัน AI coding ก็เป็นกิจกรรมที่ต่างจากการเขียนโค้ดแบบเดิมโดยสิ้นเชิง
ไม่เห็นด้วยกับความมั่นใจที่มองว่าการชอบเขียนโค้ดเอง เป็นเพียงเพราะยังไม่เก่ง AI coding แค่ ROI จากการลองใช้แบบเสียเงินเล็กน้อยและ free trial ที่ผ่านมา ก็เพียงพอให้ตัดสินใจได้แล้ว
ในความเป็นจริงกลับเกิดวัฒนธรรมที่แทนที่จะใช้ AI ตรวจโค้ดหรือช่วยตรวจผลลัพธ์ กลับเอาโค้ดที่ AI สร้างไปเปิด PR ตรง ๆ แล้วโยนภาระรีวิวให้คนอื่น ในสถานการณ์แบบนี้ GenAI ไม่ได้มีประโยชน์จริงเท่าไร แต่กลับมีผลข้างเคียงคือถูกใช้เป็นเครื่องมือผัดงาน
ผมก็เคยเจอแบบนี้ ถ้าผู้จัดการขาดความสามารถ ก็แยกไม่ออกว่าใครสร้างคุณค่าจริง ผมเองได้ประโยชน์จาก coding agent มากพอตัว แต่คิดว่าปัญหาใหญ่คือองค์กรที่ขาดศักยภาพกลับมีโครงสร้างให้รางวัลกับผลงานที่ลวก ๆ
ถ้า PR ของผู้ส่งยังคงเป็นผลลัพธ์จาก AI แบบเดิมซ้ำ ๆ ก็ควรสะสมฟีดแบ็กไว้ แล้วหัวหน้าทีมต้องยกประเด็นนี้ขึ้นมาพูดอย่างจริงจัง
ในฐานะคนที่ใช้ Claude Code บ่อย ผมเห็นด้วย 100% กับคำกล่าวที่ว่าเวลาตรวจโค้ดที่คนอื่นเขียน แทบไม่ต่างจากเขียนเองเลย LLM ก็พอใช้ได้อยู่หรอก แต่ยิ่งปล่อยการควบคุมมากเท่าไร กว่าจะออกรีลีสจริงกลับยิ่งใช้เวลานานขึ้น มันช่วยบรรเทาอาการ RSI ได้ แต่ผลเรื่องประหยัดเวลาในหลายกรณีก็ถูกพูดเกินจริง
เคยมีคนถามว่าจำเป็นต้องรีวิวโค้ดทั้งหมดไหม ปกติผมมักทำแค่ spot review กับผลลัพธ์จาก AI ให้ AI เขียนเอกสารสเปก แล้วผมค่อยตรวจขั้นสุดท้ายและทดสอบอย่างละเอียด ความจริงแล้วโค้ดจากไลบรารีโอเพนซอร์สส่วนใหญ่ เราก็ไม่ได้รีวิวทุกบรรทัดตั้งแต่แรกอยู่แล้ว
ตรงนี้มีสมมติฐานซ่อนอยู่คือ "โค้ดที่ฉันเขียนเอง ไม่จำเป็นต้องตรวจจากอีกมุมหนึ่ง" แต่จริง ๆ แล้วตัวฉันในอนาคตก็เป็นผู้อ่านโค้ดคนหนึ่งเหมือนกัน AI coding บังคับให้ต้องมี mindset แบบนี้ คือกำหนดเกณฑ์การยอมรับที่ชัดเจน และตรวจสอบด้วยการทดสอบกับกฎที่สม่ำเสมอ สุดท้ายจึงผลักดันวัฒนธรรมการพัฒนาที่แข็งแรงและมีบันทึกมากขึ้น
การดีบักบั๊กด้วย Claude Code ถ้าเริ่มจากการเขียนเทสต์ก่อน AI มักแก้ได้ภายในไม่กี่นาทีเป็นเรื่องปกติ หลังเพิ่มฟีเจอร์ค้นหาใหม่ งานที่ซับซ้อนก็จัดการได้ใน 5 นาที การประหยัดเวลาในจุดนี้สัมผัสได้ชัดมาก
ขอแนะนำวิธีบรรเทาอาการ RSI อีกอย่างคือทำให้แขนอุ่นอยู่เสมอ
มีคำถามว่า "ฉันไม่อยากจัดการทุกอย่างผ่านอินเทอร์เฟซแบบสนทนา มีตัวอย่างการใช้ UI แบบไฮบริดไหม"
เครื่องมือเขียนโค้ดแบบ Generative AI เร่งได้เฉพาะส่วนง่ายของงาน แต่กลับทำให้ส่วนยากยิ่งยากขึ้น ความจริงแล้วเวลาที่ใช้กับการเขียนโค้ดล้วน ๆ ไม่ได้มากขนาดนั้น ต่อให้ส่วนนั้นเร็วขึ้น 100 เท่า ผลิตภาพรวมก็ไม่ได้เปลี่ยนมากนัก เลยไม่อยากเสียเวลาไปกับมัน
ถ้าเป็นวิศวกรที่ทะลุปรุโปร่งทั้งสแตกและโดเมนปัญหาเฉพาะอยู่แล้ว ก็ไม่จำเป็นต้องใช้เครื่องมืออะไรเลย และไม่ต้องเรียนรู้อะไรเพิ่มด้วย แต่ตรรกะแบบนี้ในโลกจริงไม่ได้มีความหมายมากนัก สุดท้ายการเลือกเครื่องมือก็คือการปรับให้เหมาะกับแต่ละคน
ผมให้ AI เขียนอัลกอริทึม อธิบายสาเหตุของโค้ด เรียก API หรือทำฟังก์ชันบางอย่าง แม้จะไม่ถึงขั้นให้เขียนทั้งระบบ แต่ก็ใช้ร่วมกับ debugger มากขึ้นเรื่อย ๆ
มีคำถามแซวปนตลกว่า หรือคุณเป็นช่างประปาหรือเปล่า?
ประโยคที่ผู้เขียนบอกว่า "การรีวิวโค้ดที่คนอื่นเขียน อาจใช้เวลาเท่ากับหรือมากกว่าการเขียนโค้ดเอง" นั้น ผมซึ่งมีประสบการณ์ด้าน code review แบบละเอียดระดับ security audit ก็รู้สึกเห็นด้วย แต่ถ้า AI ถนัดงานรูทีนง่าย ๆ มากจริง บางทีอาจไม่จำเป็นต้องไล่ดูโค้ดอย่างละเอียด แค่ตรวจครอบคลุมแบบ eBPF verifier ก็พอ ถ้ามีประเด็นซับซ้อนเกินไปก็ปฏิเสธ PR ไปเลย สำหรับโค้ดที่เรียบง่ายและซ้ำ ๆ มนุษย์ก็อาจไม่จำเป็นต้องตรวจอย่างพิถีพิถันนัก
แต่ก็ยังสงสัยว่านี่เป็นวิธีที่มีประสิทธิภาพจริงหรือ ถ้าต้องเปิด PR หลายสิบอันแล้วผ่านได้แค่อันเดียว สู้ใช้โค้ดจากเพื่อนร่วมงานคงน่าเชื่อถือกว่า โครงสร้างที่สิ้นเปลืองเวลา เงิน และทรัพยากรด้านสิ่งแวดล้อมแบบนี้ไม่น่าพึงปรารถนา
ถ้าเป็นแค่ "ฟังก์ชัน Go แบบทำซ้ำ" จริง ก็อดสงสัยไม่ได้ว่ามีคุณค่าพอให้เขียนหรือไม่ โค้ดที่ไม่มีประสิทธิภาพ ใช้ซ้ำได้น้อย และเป็นเรื่องที่จบได้ด้วยไลบรารีทั่วไปแค่หนึ่งสองบรรทัด ผมไม่เห็นเหตุผลว่าทำไมต้องใช้ AI สร้างมันขึ้นมา
GenAI มีประโยชน์กับคนที่อ่านโค้ดได้เร็วกว่าที่เขียน ส่วนคนที่เขียนได้เร็วกว่าก็แทบไม่จำเป็นต้องใช้มัน
มีการตั้งคำถามว่าทำไมโค้ดที่ AI เขียนจึงต้องถูกตรวจต่างจากโค้ดที่มนุษย์เขียน
สำหรับงานซ้ำ ๆ และง่าย ฟีเจอร์ IDE template binding กับการเติมชื่อตัวแปรอัตโนมัติก็ครอบคลุมได้เพียงพออยู่แล้ว และวิธีนี้ยังฟรีด้วย
ในการเปรียบเทียบระหว่างเด็กฝึกงานกับเครื่องมือช่วยเขียนโค้ด AI มีการชี้ว่าอินเทิร์นได้เรียนรู้ทั้งโค้ด ธุรกิจ และประวัติของระบบจริง ขณะที่ AI ยังต้องให้คนอธิบายบริบทซ้ำ ๆ ข้อจำกัดนี้ยังคงมีอยู่
มีมุมมองว่าถ้าเก็บบริบทสำคัญไว้ในไฟล์ mdc คนที่มารับงานต่อก็จะอ้างอิงข้อมูลนี้ได้เช่นกัน ทำให้การจัดทำเอกสารและความต่อเนื่องของความรู้ดีขึ้นด้วยซ้ำ
LLM บางตัวมี system prompt ยาวถึง 14k ก็เพราะสาเหตุลักษณะนี้
อินเทิร์นหลายคนใส่ใจจริง ๆ
อีกวิธีคือใส่บริบทธุรกิจที่สำคัญลงไปใน system prompt ตรง ๆ เลย
โมเดล AI ปัจจุบันโดยเนื้อแท้เรียนรู้แค่แพตเทิร์นของข้อมูลเดิม คือเอาเทมเพลตของกรณีสำเร็จมาผสมกัน ไม่ได้มีโครงสร้างที่ชี้นำไปสู่คำตอบใหม่อย่างถึงรากถึงโคน เวลาเจอปัญหามันจะพยายามหาคำตอบจากประสบการณ์ที่คล้ายที่สุด ไม่ได้เข้าหาอย่างมีหลักการตั้งแต่ต้น ผู้เชี่ยวชาญมนุษย์เก่งเรื่อง First-principles ซึ่งเป็นการเข้าถึงจากหลักพื้นฐานที่ AI ทำได้ยาก AI ให้ความสำคัญกับความคล้ายคลึงก่อน จึงมักออกคำตอบแบบสำเร็จรูป และจะยิ่งเห็นข้อจำกัดชัดในงานที่ต้องการนวัตกรรมหรือปัญหาที่ธรรมเนียมเดิมใช้ไม่ได้ แม้แต่ context poisoning มนุษย์ก็รับมือได้มีประสิทธิภาพกว่ามาก
โดยส่วนตัวผมไม่ได้คาดหวังกับงานโค้ดที่ AI สร้างมากนัก แต่สำหรับงาน boilerplate ซ้ำ ๆ น่าเบื่อ AI เร็วกว่าแบบ N เท่าอย่างชัดเจนจากความรู้สึกส่วนตัว ยกตัวอย่างจากประสบการณ์จริง ผมโยนโจทย์ให้ ChatGPT ทำตัวอย่าง modal ที่อิง React Context มันก็สร้างทั้ง hooks, provider และโครงสร้างที่เกี่ยวข้องมาให้ทันที ประหยัดเวลาไปได้ราว 30 นาที แค่นี้ค่าสมาชิก 20 ดอลลาร์ต่อเดือนก็ถือว่าคุ้มแล้วสำหรับงานลักษณะนี้
ในกรณีแบบนี้ บางครั้งก็ดึงตัวอย่างจากเอกสารไลบรารีมาใช้ได้เหมือนกัน และถ้าจะทำเองก็ใช้แค่ 5 นาทีก็เสร็จ implementation พื้นฐานที่จำเป็นที่สุดแล้ว แต่โค้ดที่สร้างขึ้นมามักให้คำตอบทั้งชุดที่เหมาะกับสถานการณ์ปัจจุบัน ทำให้ภายหลังเวลาจะค่อย ๆ ปรับโครงสร้างหรือรีแฟกเตอร์กลับไม่ค่อยสะดวก
ผมเองก็ใช้ AI กับงาน boilerplate หรือสคริปต์ ad-hoc เป็นหลัก ปัญหาจริงที่ซับซ้อนยังมองว่ายากจะฝาก AI ทั้งหมด โดยเฉพาะปัญหาที่ต้องเจาะลึกเข้าไปในระบบ คนยังต้องทำเอง และ insight ที่ได้ระหว่างทางสำคัญมาก ยิ่งโปรเจ็กต์ใหญ่ องค์ประกอบที่ผสมกันมากขึ้น ก็ยิ่งรู้สึกว่า AI มีข้อจำกัดชัดขึ้น