การเขียนโค้ดโดยใช้ LLM (ฤดูร้อน 2025)
(antirez.com)- อัปเดตประสบการณ์การใช้ LLM ของ antirez นักพัฒนา Redis
- LLM ระดับแนวหน้าอย่าง Gemini 2.5 PRO และ Claude Opus 4 ช่วย เสริมศักยภาพ ของนักพัฒนา
- การใช้ LLM สามารถช่วยเพิ่มประสิทธิภาพการทำงานได้หลายด้าน เช่น กำจัดบั๊ก, ทดสอบไอเดีย, ขยายองค์ความรู้
- ทำให้สามารถ รับมือกับงานนอกความเชี่ยวชาญหรือเทคโนโลยีใหม่ได้ง่ายขึ้นด้วยความช่วยเหลือจาก LLM
- แต่เพื่อ คุณภาพโดยรวมของโค้ดและการดูแลรักษา การทำงานร่วมกันแบบ 'มนุษย์ + LLM' ยังคงเป็นหัวใจสำคัญ
- หากต้องการใช้ LLM ให้เกิดประสิทธิภาพสูงสุด ต้องมี การให้บริบทอย่างเพียงพอและความสามารถในการสื่อสารที่ชัดเจน
การเปลี่ยนแปลงของการพัฒนาด้วย LLM และประเด็นสำคัญ
LLM ระดับแนวหน้า (เช่น Gemini 2.5 PRO, Claude Opus 4) มีบทบาทในการ ขยายขีดความสามารถ ของโปรแกรมเมอร์ โดยอาศัย ความสามารถในการทำความเข้าใจ ที่กว้างขวางและการจัดการโค้ดปริมาณมาก
- หากอธิบายปัญหาได้อย่างชัดเจนและคุ้นเคยกับการสื่อสารแบบวนซ้ำ
- ก็สามารถกำจัดบั๊กได้ตั้งแต่ก่อนปล่อยใช้งาน (เช่น ในกรณีการพัฒนา Vector Sets ของ Redis ที่ Gemini/Claude ช่วยรีวิวโค้ดและกำจัดบั๊กได้ทันที)
- สามารถทดสอบได้อย่างรวดเร็วว่าไอเดียใช้งานได้จริงหรือไม่ พร้อมทั้งเขียนโค้ดเชิงทดลองและประเมินประสิทธิภาพ
- สามารถทำ pair-design โดยอาศัยประสบการณ์และสัญชาตญาณ ผสานองค์ความรู้เฉพาะทางอันหลากหลายของ LLM เข้ากับสัญชาตญาณของมนุษย์
- หากให้คำสั่งที่ชัดเจนกับ LLM ก็สามารถเร่งการเขียนโค้ดบางส่วนให้เสร็จได้อย่างรวดเร็ว
- สามารถปรับตัวทางเทคนิคได้รวดเร็วแม้ในสายงานที่ไม่คุ้นเคย (เช่น โค้ดแอสเซมบลี 68000 สำหรับ Amiga)
ในบทความก่อนหน้า 'LLMs และการเขียนโปรแกรมต้นปี 2024' ได้กล่าวถึงประโยชน์ของ LLM ไว้แล้ว แต่ในช่วง 1.5 ปีที่ผ่านมา LLM พัฒนาแบบก้าวกระโดด
เพื่อใช้ LLM ให้ได้ผลดีที่สุด ทั้งมนุษย์และ LLM ต่างก็ต้องมีทักษะและนิสัยบางอย่างร่วมกัน และหลักการเหล่านี้มีความสำคัญมาก
การยับยั้ง Vibe Coding และหลักการทำงานร่วมกันระหว่างมนุษย์กับ LLM
ปัจจุบัน LLM นั้นยอดเยี่ยมในฐานะ ตัวขยายความสามารถของนักพัฒนา แต่ก็ยังไม่ถึงระดับที่จะทำงานทุกอย่างได้เองอย่างอัตโนมัติ
- สำหรับงานเดี่ยวขนาดเล็ก เช่น การทดสอบหรือยูทิลิตีเล็ก ๆ LLM อาจออกแบบเองได้
- แต่ถ้าใช้ LLM เพียงลำพังกับโปรเจ็กต์ขนาดใหญ่และไม่ธรรมดา ก็มีโอกาสสูงที่จะเกิดปัญหาอย่าง ความซับซ้อน, โค้ดที่ไม่จำเป็น, ความเปราะบางเชิงโครงสร้าง
- การทำงานร่วมกันระหว่าง LLM กับมนุษย์ให้ผลด้านผลิตภาพดีที่สุด แต่มีเงื่อนไขว่าต้องมี ประสบการณ์ในการสื่อสารอย่างมีประสิทธิภาพและการกำกับดูแล LLM
- ไม่ควรโยนงานซับซ้อนให้ LLM เพียงฝ่ายเดียว แต่ต้องใช้ กลยุทธ์ที่มนุษย์เข้าไปมีส่วนร่วมในกระบวนการอย่างสม่ำเสมอ
ความสำคัญของการให้บริบทอย่างเพียงพอกับ LLM
หากต้องการให้ LLM เข้าใจทิศทางของการพัฒนาหรือการแก้ปัญหาได้อย่างถูกต้อง การให้ ข้อมูลบริบทอย่างกว้างขวาง เป็นสิ่งจำเป็น
- ควรให้ทั้งงานวิจัย, codebase เป้าหมาย (ให้ครบที่สุดเท่าที่ทำได้), และเจตนาของงาน
- ควรรวมข้อมูลสำคัญ เช่น วัตถุประสงค์ของการพัฒนา, แนวทางที่ไม่ต้องการหรืออ่อนแอ, ไอเดียหลักที่ทำได้จริง, เป้าหมาย, เงื่อนไขคงที่, และสไตล์โค้ด
- ตัวอย่างเช่น เมื่อต้องรับมือกับเทคโนโลยีใหม่ที่ LLM ยังไม่รู้จัก (เช่น Redis vector sets) หากใส่เอกสาร README ไว้ในบริบท ก็สามารถได้คำตอบระดับผู้เชี่ยวชาญทันที
การเลือก LLM และวิธีใช้งาน
LLM ที่เป็นที่รู้จักมากที่สุด ไม่ได้แปลว่าจะให้ผลลัพธ์ดีที่สุดเสมอไป
- สำหรับการเขียนโค้ด Gemini 2.5 PRO และ Claude Opus 4 มีประสิทธิภาพโดดเด่นเป็นพิเศษ
- Gemini 2.5 PRO โดดเด่นด้าน การตรวจจับบั๊กซับซ้อนและการแก้ปัญหา
- Claude Opus 4 เก่งด้าน การเขียนโค้ดใหม่ และยังมีประสบการณ์ใช้งานที่ยอดเยี่ยม
- การสลับใช้สองโมเดลนี้ไปมาช่วยเพิ่มความเข้าใจในการออกแบบที่ซับซ้อน
- หากต้องเลือกเพียงตัวเดียว แนะนำ Gemini 2.5 PRO
- เงื่อนไขที่ควรปฏิบัติเมื่อใช้ LLM
- หลีกเลี่ยงการใช้ code agent หรือ agent ที่ผสานอยู่ใน IDE
- ควรทำให้ LLM มองเห็นบริบททั้งหมดได้โดยตรง (เช่น โค้ดและเอกสาร) เพื่อดึงคำตอบที่ดีที่สุด
- หากใช้ฟีเจอร์ที่แสดงเพียงบางส่วนของบริบท เช่น RAG(การดึงความรู้มาใช้) ประสิทธิภาพจะลดลง
- ในแต่ละขั้นตอน มนุษย์ควรคัดลอก/วางโค้ดด้วยตนเองและติดตามลำดับการทำงานโดยตรง
บทสรุป – การคงการควบคุมไว้คือหัวใจสำคัญ
การมาถึงของ agent ที่เขียนโค้ดได้เองล้วน ๆ คงอยู่อีกไม่ไกล แต่ ณ ตอนนี้ วิธีที่ให้โค้ดคมที่สุดยังคงเป็นการที่มนุษย์เป็นผู้นำและทำงานร่วมกับ LLM
- มนุษย์ยังคงมีบทบาทสำคัญในการตัดสินใจว่า ‘จะทำอะไร และทำอย่างไร’
- การใช้ LLM ช่วยให้เติบโตได้ด้วยการเรียนรู้เทคโนโลยีหรือแนวคิดใหม่ ๆ ที่ก้าวข้ามขอบเขตความรู้เดิม
- หากควบคุมโค้ดด้วยตนเอง ก็จะรักษาความสอดคล้องของการออกแบบและการพัฒนาได้ พร้อมทั้งลด ความไม่แน่นอนจากข้อผิดพลาดของ LLM ให้น้อยที่สุด
- การติดตามพัฒนาการด้านประสิทธิภาพของ agent เป็นระยะ ๆ ก็เป็นกลยุทธ์ที่ชาญฉลาด
- หากหลีกเลี่ยงการใช้ LLM ในช่วงนี้ อาจตามการเปลี่ยนแปลงไม่ทัน ดังนั้นนี่คือช่วงเวลาที่ การใช้งานอย่างสมดุล มีความสำคัญ
1 ความคิดเห็น
ความเห็นจาก Hacker News
รู้สึกเสียดายที่ตอนนี้โมเดล LLM แบบปิดอย่าง Gemini 2.5 PRO หรือ Claude Opus 4 กำลังกลายเป็นมาตรฐาน แม้มองว่าความก้าวหน้าของ LLM และพลังในฐานะเครื่องมือเป็นเรื่องบวกมาก แต่ก็ยังเข้าใจยากว่าทำไมนักพัฒนาไม่ว่าจะดังหรือไม่ดังถึงยังมองว่าเป็นเรื่องโอเคที่จะต้องพึ่งพาบริการเสียเงินของบุคคลที่สามเพื่อเขียนโปรแกรม แต่ก่อนเราก็เขียนโค้ดได้ด้วยโอเพนซอร์สและเครื่องมือฟรีล้วน ๆ เลยกังวลว่าอีกไม่กี่ปีข้างหน้า การต้องพึ่ง LLM แบบเสียเงินอาจจะกลายเป็นความไม่สะดวกพอ ๆ กับการเขียนโค้ดโดยไม่มี IDE หรือ vim ในตอนนี้ การพูดทำนองว่าเดือนละ $200 ไม่ใช่เรื่องใหญ่อะไรไม่ได้แก้ปัญหารากฐาน
ตอนนี้โมเดลเปิดที่รันในเครื่องได้ยังด้อยกว่าในด้านคุณภาพ และเหนือสิ่งอื่นใดคือต้นทุนการรันสูงกว่ามาก ถ้าวันหนึ่งโมเดลระดับ Claude 4 สามารถรันบนคอมส่วนตัวได้อย่างคุ้มค่า คนจำนวนมากก็คงลองทำกัน ตอนนี้โมเดลอย่าง Kimi K2 รันได้บน Mac Studio 512GB สองเครื่อง แต่ค่าเครื่องอย่างเดียวก็ราว $20,000 แล้ว
โมเดลแบบสมัครสมาชิกทำให้ในช่วงแรกมันดูเหมือนคุ้มค่ามากเมื่อเทียบกับราคา แต่พอเวลาผ่านไป ราคาก็สูงขึ้น คุณภาพกลับลดลง สุดท้ายก็กลายเป็นว่าถูกมัดติดกับบริการ เหมือนตอนในตอน "Common People" ของ Black Mirror
ส่วนตัวคิดว่าอนาคตที่นักพัฒนาทุกคนจะต้องขึ้นกับ LLM แบบเสียเงินอย่างสมบูรณ์นั้นเกิดขึ้นได้ยาก ในระยะยาวคนจะตระหนักเองว่าการผลิตโค้ดออกมาจำนวนมากไม่ใช่เรื่องดี โค้ดคือหนี้ และถ้าเป็นโค้ดที่ไม่เสถียรหรือช้าก็ยิ่งเพิ่มหนี้นั้น AI คงไม่หายไปไหน แต่พอกระแสเริ่มซาลง ความเข้าใจว่าจะใช้มันที่ไหนและอย่างไรคงมากขึ้น อีกเรื่องที่น่าสงสัยคือถ้าเงินลงทุนแห้งไปจะเกิดอะไรขึ้น OpenAI กับ Anthropic ยังไม่ทำกำไรและต้องอาศัยเงินทุนไหลเข้าต่อเนื่องเพื่อคงสภาพปัจจุบันไว้ ถ้าวิวัฒนาการของ LLM มาถึงแค่นี้และนี่คือขีดจำกัด เงินลงทุนก็น่าจะถอนออก แล้วต้นทุนการใช้งานก็อาจสูงขึ้น หรือบริการอาจหายไปเลยก็ได้
มองตามความเป็นจริงแล้วคิดว่าไม่ใช่ปัญหาใหญ่ ถ้าไม่มีเหตุผลเชิงประสิทธิภาพที่ชัดเจน ก็ไม่มีเหตุผลต้องผูกตัวเองกับบริการที่แพงและใช้งานไม่เป็นมิตร โมเดลเปิดก็กำลังพัฒนาอย่างต่อเนื่อง ถ้าช่องว่างกับโมเดลเปิดไม่มากก็ไม่จำเป็นต้องใช้ต่อ แต่ถ้าการพัฒนา LLM ไม่หยุดและยังพุ่งแรงต่อไป เราเองก็จะสู้ด้วยวิธีเดิมไม่ได้และคงต้องย้ายไปทำอย่างอื่น สรุปคือไม่คิดว่าต้องกังวลมากนัก และยังรู้สึกด้วยว่ามูลค่าของบริษัทโมเดลขนาดใหญ่ถูกประเมินสูงเกินจริงมาก
ขอเสริมจากที่บอกว่าเราสามารถเขียนโค้ดด้วยโอเพนซอร์สและเครื่องมือฟรีได้ JetBrains เป็นบริษัทที่เก่าแก่กว่าหลายบริษัทในยุคนี้ และ MS Visual Basic/C++/Studio ก็ทำให้การพัฒนา Windows ง่ายขึ้น แต่ทั้งหมดนั้นก็เป็นของเสียเงิน
ไม่เห็นด้วยกับคำว่า "PhD-level knowledge" หลักสูตร PhD ไม่ได้มีเป้าหมายเพื่อรับเอาความรู้เดิมเป็นหลัก แต่แก่นสำคัญคือการเรียนรู้วิธีทำวิจัย นี่เป็นจุดที่มักถูกเข้าใจผิดในการถกเรื่อง AI ทำให้คำว่าความรู้ระดับปริญญาเอกกลายเป็นคำที่ความหมายไม่ชัด
นอกจากประเด็นที่ว่า PhD คือกระบวนการเรียนรู้การวิจัยแล้ว สิ่งสำคัญคือความสามารถในการตั้งคำถาม LLM ใกล้เคียงกับ "แรงงานขี้เกียจที่มีความรู้มาก" มากกว่า มันไม่ได้ตั้งคำถามกับตัวเองแล้วสำรวจสมมติฐาน จากประสบการณ์จริง ผมให้ Claude Code(Max Pro) ไปคอมเมนต์จำนวน test assertion แล้วมันสร้างบั๊กจากสมมติฐานที่ผิดในแผนเดิม ผมต้องสั่งให้มันเขียนแผนใหม่เองถึงจะหาสาเหตุและแก้ได้ ตัวอย่างเช่น สาเหตุที่ ORM object มีค่า null เป็นเพราะไม่มีการ refresh หลัง commit และยังเกิดจากการที่ข้อมูลที่โหลดมาจาก DB session อื่นค้างอยู่เหมือนเดิมแม้ session จะปิดไปแล้ว
เห็นด้วย มันมีความรู้ระดับผู้เชี่ยวชาญ แต่ LLM ยังทำสิ่งที่มนุษย์ถนัดได้ไม่เท่า ตัวอย่างเช่น LLM อาจเขียนโปรแกรมที่น่าทึ่งได้ตั้งแต่ต้นจนจบในครั้งเดียว แต่การปรับปรุงซ้ำไปเรื่อย ๆ กลับทำได้ยาก
ถึงจะเข้าใจว่า PhD มีความหมายมากกว่าแค่ความรู้ แต่การเข้าถึงความรู้นั้นได้ง่ายก็มีคุณค่ามหาศาล ที่บริษัทเก่าของผม LLM เคยตอบคำถามยาก ๆ ที่ปกติมีแต่ PhD เท่านั้นจะตอบได้ค่อนข้างใช้ได้ เช่นคำถามประมาณว่า "ถ้าใช้แรงดันไฟฟ้าในทิศทางหนึ่งกับรอยต่อระหว่างวัสดุสองชนิด จะเกิดปรากฏการณ์อะไรขึ้น?"
ต่อให้จบ PhD มา ก็ไม่ได้แปลว่าจะสนใจตัววิชาเองมากขึ้น สุดท้ายสิ่งสำคัญคือได้เรียนรู้วิธีทำวิจัย
คิดว่าการถกเรื่องการเขียนโค้ดด้วย LLM จำเป็นต้องพูดถึงโดเมนที่ทำงานและภาษาโปรแกรมที่ใช้ เพราะสองตัวแปรนี้มีอิทธิพลมากกว่าวิธีใช้ LLM เสียอีก ถ้าใครชอบหรือไม่ชอบการเขียนโค้ดด้วย LLM สิ่งแรกที่ควรถามคือเขาแก้ปัญหาในด้านไหน และควรลองใช้ AI แก้ปัญหาแบบนั้นด้วยตัวเองก่อน ถึงจะเข้าใจจุดยืนของแต่ละฝ่ายได้ดี ไม่อย่างนั้นก็จะวนอยู่กับการพูดแบบ "ก็เพราะคุณใช้มันผิด" หรือ "ฉันลองแล้วแต่ไม่เวิร์ก" ที่ไม่ก่อประโยชน์
จากประสบการณ์ทำงานที่โฟกัสกับ agentic coding มาหลายเดือน ผมเห็นด้วยกับทุกอย่างในโพสต์นี้ LLM ระดับล้ำหน้าที่สุดยังคงใช้งานง่ายที่สุด แต่ก็คาดว่าโมเดลเปิดจะตามมาทันในไม่ช้า เราสามารถให้ LLM แนะนำแนวทางใหม่หรือเสนอวิธีที่เรารู้อยู่แล้วก็ได้ บางครั้ง LLM มีแนวโน้มจะทำเรื่องให้ซับซ้อนขึ้น ถ้าจับสัญญาณได้เร็วหรือขอให้รีแฟกเตอร์ก็ช่วยได้ และสถานการณ์ก็จะเปลี่ยนไปอีกทุกครั้งที่มีโมเดลใหม่ออกมา ไม่ใช่ว่าทุกงานต้องใช้โมเดลล้ำหน้าที่สุดเสมอไป งานฟีเจอร์หรือแก้บั๊กง่าย ๆ Copilot ก็เป็นจุดเริ่มต้นที่ดีพอสมควร อยากให้ทุกคนสนุกกับการลองหลาย ๆ แบบและเรียนรู้ไปกับความเปลี่ยนแปลงใหม่นี้
ผมลองใช้ GitHub action ของ Claude กับงานทำ issue ราว 10~20 งานและรีวิว PR แล้ว ผลมันเข้าข่าย hit and miss อย่างแท้จริง เลยเห็นด้วยว่ามันเหมาะเป็นเครื่องมือเสริมมากกว่าระบบอัตโนมัติแบบไม่ยั้ง งานเปลี่ยนแปลงเล็ก ๆ และฟีเจอร์/รีแฟกเตอร์ขนาดย่อมที่มีเทสต์ครบ มักสำเร็จแทบจะอัตโนมัติ การปล่อยให้ action ทำงานก็มีข้อดีตรงที่ผมไปทำอย่างอื่นได้ (ถ้าให้ Claude เขียน issue ให้ด้วยก็ยิ่งสบาย) แต่พอเป็นงานขนาดกลางขึ้นไป มักได้ผลลัพธ์ที่ดูเหมือนใช้งานได้แต่จริง ๆ แล้วไม่ทำงาน อาจเป็นความผิดผมเองที่ coverage ของเทสต์ไม่พอ แต่ก็เกิดบ่อยชัดเจน ต่อให้เขียน issue ละเอียดขึ้นหรือเปลี่ยน
promtหลายแบบ ผลก็ยังน่าผิดหวัง งานใหญ่ยิ่งไม่ต้องพูดถึง ฟีเจอร์รีวิว PR ใช้ได้ในงานเล็กถึงกลาง แต่ก็มีการทักอะไรที่ไร้ประโยชน์เยอะ สรุปแล้วคิดว่า LLM ยังอีกไกลกว่าจะเขียนโค้ดได้ด้วยตัวเอง วิธีที่คุ้มที่สุดคือให้มันช่วยเขียน issue งานเล็ก ๆ แล้วรอให้ PR มา สำหรับงานส่วนใหญ่ของผมที่เป็นงานขนาดกลาง ปกติผมแค่คอยบอกทิศทางให้ Claude แล้วแทบไม่ต้องเขียนโค้ดเองเลย ทำให้ประสิทธิภาพเพิ่มขึ้นชัดเจน ผมก็ลอง Gemini เหมือนกัน แต่ถ้าปล่อยไว้เฉย ๆ โค้ดมันจะแกว่งแบบคาดเดาไม่ได้ ภายในบริษัทเราก็ใช้ Copilot รีวิว PR ด้วย แต่แทบไม่เห็นผลอะไร ถ้าเป็น codebase ขนาดใหญ่มาก Gemini อาจมีประโยชน์มากกว่านี้ก็ได้ต่างจาก OP ผมเจาะด้านนี้อย่างจริงจังอยู่เดือนหนึ่ง และพบว่า Gemini 2.5 PRO กับ Opus 4 ให้ผลดีกว่าเวลาใช้คุยเรื่องนามธรรมอย่างสถาปัตยกรรม จากนั้นค่อยโยนงาน implement โค้ดรายจุดให้ Sonnet จะมีประสิทธิภาพกว่า 2.5 PRO กับ Opus มักมีรูปแบบคือวนเวียนอยู่รอบคำตอบแล้วแก้ตัวเองซ้ำ ๆ ส่วน Sonnet จะพุ่งตรงไปหาคำตอบมากกว่า แต่ก็ต้องการคำสั่งที่ละเอียดพอ
เป็นไปได้มากทีเดียว จริง ๆ แล้ว Sonnet/Opus 4 อาจทรงพลังกว่าเมื่อดูจากผลลัพธ์ที่ดีที่สุด แต่บางส่วนกลับมีความสม่ำเสมอหรือ alignment ด้อยกว่า Sonnet 3.5v2 (บางคนเรียก 3.6) หรือแม้แต่ 3.7 ด้วย นอกจากนี้ตัวโมเดลเองก็เป็นวัตถุที่ซับซ้อน จึงมีกรณีที่โมเดลที่ "ดูอ่อนกว่า" ทำงานได้ดีกว่าในบางโดเมน และสภาพแวดล้อมแบบ interactive กับแบบเน้น agent ก็ใช้เทคนิค reinforcement learning คนละแบบ ทำให้ประสิทธิภาพของโมเดลเปลี่ยนไปตามวิธีใช้งาน
แม้แต่ในข้อมูลสถิติภายในจริงก็ยืนยันว่า Opus และ Gemini 2.5 pro มีผลงานด้อยกว่า Sonnet 4 ในสภาพแวดล้อมจริง ลิงก์สถิติที่เกี่ยวข้อง
ผมเองก็มีประสบการณ์คล้ายกัน ผมใช้ Gemini 2.5 Pro ใน AI Studio เพื่อตรวจสอบและขัดเกลาแนวคิดด้านดีไซน์ภาพใหญ่ แล้วค่อยเอาความต้องการไปให้ Claude Code ซึ่งส่วนใหญ่จะเขียนออกมาได้เรียบร้อยดี ช่วงหลังผมลอง Gemini CLI ด้วย แต่ความสามารถด้านการเขียนโค้ดยังตาม Claude Code อยู่มาก มี syntax error เยอะ หลุดจากลูปไม่ค่อยได้ แล้วผลลัพธ์ก็ยืดยาวและเร็วเกินกว่าจะตามทัน ตรงกันข้าม Claude Code เก่งเรื่องดีบักมาก ส่วนงานแก้ปัญหาระดับ "ภาพใหญ่" ก็ใช้ DeepSeek R1 ได้เหมือนกัน แม้จะช้ามากแต่ความแม่นยำสูง
นี่คือตัวอย่างจริงที่สะท้อนว่า AI/LLM บางครั้งเขียนโค้ดที่ไม่มีประสิทธิภาพอย่างมาก ลิงก์บล็อกที่เกี่ยวข้อง
ผมเคยมีประสบการณ์ว่าถ้าขอให้ LLM อธิบายงานที่ต้องการก่อน โดยยังไม่ต้องเขียนโค้ด แล้วผมคอยให้ฟีดแบ็กระหว่างทางและวนทำแบบนี้สักสองสามรอบ คุณภาพของโค้ดที่ออกมาหลังจากนั้นจะดีขึ้นมาก การให้มันยืนยันแผนละเอียดก่อนเริ่มทำได้ผลดี
จากประสบการณ์ของผม งานซ้ำ ๆ เรียบง่าย และตรวจสอบได้ง่ายในฝั่งฟรอนต์เอนด์จะโยนให้ vibe coding ทำก็ได้ แต่โดยปกติผมใช้ LLM เป็น sparring partner สำหรับรีวิวโค้ดของตัวเองและประเมินทางเลือกต่าง ๆ แม้บางคำแนะนำจะเพี้ยนหรือมีช่องโหว่ทางตรรกะ แต่มันช่วยให้ผมไม่พลาดสิ่งที่ควรเห็นอย่างชัดเจน เลยค่อนข้างพอใจ และยังช่วยแก้นิสัยผมที่ชอบพยายามเกินเหตุเวลาต้องเจอปัญหาซับซ้อนยุ่งเหยิงด้วย
ผมไม่ค่อยเข้าใจว่าที่ OP พูดหมายถึงวิธีไหนกันแน่ หมายถึงให้เอาไฟล์ C ของ redis ไปแปะทีละไฟล์ในเว็บแชต Gemini Pro ด้วยมืออย่างนั้นหรือ?