- ในสภาพแวดล้อมการพัฒนาที่ ทำงานร่วมกับ AI มนุษย์ต้องกำหนดทิศทางและการตัดสินใจของโปรเจกต์ให้ชัดเจนจึงจะรักษาคุณภาพได้
- ต้องมี เอกสารที่แม่นยำ เพื่อให้ทั้ง AI และนักพัฒนาคนอื่นเข้าใจความต้องการและข้อจำกัดได้อย่างชัดเจน
- สร้าง ระบบดีบักและกระบวนการรีวิวโค้ด เพื่อเสริมความน่าเชื่อถือและการตรวจสอบโค้ดที่ AI สร้างขึ้น
- ใช้แนวทางอย่าง การระบุฟังก์ชันที่มีความเสี่ยงด้านความปลอดภัย การแยกชุดทดสอบ และกฎ lint ที่เข้มงวด เพื่อรับประกันเสถียรภาพและความสม่ำเสมอของโค้ด
- รักษาการควบคุมการสร้างโค้ดด้วย AI และเพิ่มประสิทธิภาพสูงสุดผ่าน การแบ่งงานเป็นหน่วยย่อยและลดความซับซ้อนให้ต่ำที่สุด
1. กำหนดวิสัยทัศน์ให้ชัดเจน
- มนุษย์เข้าใจโลก ทีม และพฤติกรรมผู้ใช้ แต่ AI ไม่มีประสบการณ์ จึงต้องมีคำสั่งที่ชัดเจนอย่างเป็นรูปธรรม
- การตัดสินใจใด ๆ ในโปรเจกต์ที่ไม่ได้ถูกบันทึกไว้เป็นเอกสาร AI จะเป็นฝ่ายตัดสินใจแทน
- ควรหารือเรื่อง สถาปัตยกรรม อินเทอร์เฟซ โครงสร้างข้อมูล และอัลกอริทึม ล่วงหน้า พร้อมกำหนดวิธีทดสอบให้ชัดเจน
- การตัดสินใจระยะยาวที่เปลี่ยนแปลงได้ยาก มนุษย์ต้องเป็นผู้ดูแลโดยตรงเท่านั้น
2. ดูแลเอกสารให้ถูกต้องแม่นยำ
- หากต้องการให้ AI สร้างโค้ดได้ตรงตามเป้าหมาย การ ถ่ายทอดข้อกำหนดอย่างละเอียด เป็นสิ่งจำเป็น
- เนื่องจากนักพัฒนาคนอื่นก็ต้องให้ข้อมูลเดียวกันกับ AI จึงควรรวม เอกสารในรูปแบบมาตรฐาน ไว้ใน code repository
- บันทึกข้อกำหนด ข้อจำกัด สถาปัตยกรรม มาตรฐานการเขียนโค้ด และ design pattern อย่างละเอียด
- ใช้ UML diagram, flowchart, pseudocode ฯลฯ เพื่อแสดงโครงสร้างที่ซับซ้อนในรูปแบบภาพ
3. สร้างระบบดีบักที่สนับสนุน AI
- ควรจัดเตรียม ระบบดีบักที่มีประสิทธิภาพ เพื่อให้ AI ตรวจสอบการทำงานของโค้ดได้อย่างรวดเร็ว
- ตัวอย่าง: รวบรวม log จากทุกโหนดใน distributed system แล้วสรุปข้อมูล เช่น “ข้อมูลถูกส่งไปยังทุกโหนดแล้ว”
- วิธีนี้ช่วย ลดต้นทุนในการรันคำสั่ง และเพิ่มความเร็วในการระบุปัญหาได้
4. ระบุระดับการรีวิวโค้ด
- ควร แยกระดับความเข้มงวดของการรีวิว ตามความสำคัญของโค้ด
- ตัวอย่าง: เพิ่มคอมเมนต์
//A หลังฟังก์ชันที่ AI เขียน เพื่อระบุว่ามนุษย์ได้ตรวจทานแล้วหรือไม่
- ระบบนี้ช่วยให้ ระบุและจัดการโค้ดที่ยังไม่ได้รับการตรวจทาน ได้ง่ายขึ้น
5. เขียนสเปกระดับสูงและทดสอบด้วยตนเอง
- AI อาจ ใช้ mock object หรือค่าที่ hardcode เพื่อหลอกให้ผ่านการทดสอบ ได้
- เพื่อป้องกันปัญหานี้ ควรเขียน property-based testing ด้วยตนเอง
- ตัวอย่าง: รีสตาร์ตเซิร์ฟเวอร์และตรวจสอบความสอดคล้องของค่าในฐานข้อมูล
- ควรแยกโค้ดทดสอบไว้ใน พื้นที่แยกต่างหาก เพื่อไม่ให้ AI แก้ไขได้
6. แยกการทดสอบอินเทอร์เฟซออกจากกัน
- ควรให้ AI เขียนการทดสอบอินเทอร์เฟซโดยไม่รู้บริบทของโค้ดส่วนอื่น
- เพื่อไม่ให้ได้รับอิทธิพลจาก AI ที่เขียน implementation และคงความเป็นกลางของการทดสอบไว้
- การทดสอบนี้ก็ควรได้รับการปกป้องไม่ให้ AI แก้ไขเองได้ตามอำเภอใจเช่นกัน
7. กฎ linting และ formatting ที่เข้มงวด
- รูปแบบโค้ดที่สม่ำเสมอและกฎ linting ที่ชัดเจน เป็นสิ่งจำเป็นต่อการรักษาคุณภาพและการค้นหาข้อผิดพลาดตั้งแต่เนิ่น ๆ
- ทั้ง AI และมนุษย์สามารถตรวจสอบคุณภาพโค้ดได้ง่ายขึ้น
8. ใช้พรอมป์ต์สำหรับ code agent ตามบริบท
- ใช้ ไฟล์พรอมป์ต์สำหรับแต่ละโปรเจกต์ เช่น CLAUDE.md เพื่อลดต้นทุนในการทำความเข้าใจตั้งต้นของ AI
- โดยใส่มาตรฐานการเขียนโค้ด design pattern และข้อกำหนดต่าง ๆ เพื่อเพิ่ม คุณภาพและประสิทธิภาพในการสร้างโค้ดของ AI
9. ระบุและทำเครื่องหมายฟังก์ชันที่มีความเสี่ยงด้านความปลอดภัย
- ต้องระบุอย่างชัดเจนว่า ฟังก์ชันใดมีความอ่อนไหวด้านความปลอดภัย เช่น การยืนยันตัวตน สิทธิ์การเข้าถึง หรือการจัดการข้อมูล
- ตัวอย่าง: ใช้คอมเมนต์
//HIGH-RISK-UNREVIEWED, //HIGH-RISK-REVIEWED
- ควรตั้งค่าให้เมื่อ AI แก้ไขฟังก์ชันดังกล่าว ระบบจะ เปลี่ยนสถานะการรีวิวโดยอัตโนมัติ
- นักพัฒนาต้องตรวจสอบอยู่เสมอว่าสถานะนี้ถูกต้องจริง
10. ลดความซับซ้อนของโค้ดให้ต่ำที่สุด
- แม้จะเป็น โค้ดที่ไม่จำเป็นเพียงบรรทัดเดียว ก็ยังกินพื้นที่ใน context window ของ AI และเพิ่มต้นทุน
- ควรรักษาโครงสร้างให้เรียบง่ายที่สุดเท่าที่เป็นไปได้เพื่อเพิ่ม ความเข้าใจของทั้ง AI และมนุษย์
11. สำรวจปัญหาด้วยการทดลองและต้นแบบ
- สามารถใช้ประโยชน์จาก ต้นทุนต่ำของการสร้างโค้ดด้วย AI เพื่อทดลองแนวทางแก้ปัญหาได้หลากหลาย
- สร้าง prototype หลายแบบจากสเปกขั้นต่ำเพื่อ ค้นหาแนวทางที่เหมาะสมที่สุด
12. หลีกเลี่ยงการสร้างโค้ดขนาดใหญ่แบบไร้การควบคุม
- งานที่ซับซ้อนควร แบ่งเป็นหน่วยเล็ก ๆ เพื่อให้ AI จัดการทีละขั้นตอน
- ตัวอย่าง: สร้างเป็นรายฟังก์ชันหรือรายคลาส แทนการสร้างทั้งโปรเจกต์ในครั้งเดียว
- ต้องตรวจสอบว่าแต่ละองค์ประกอบสอดคล้องกับสเปกหรือไม่ และ
หากไม่สามารถควบคุมความซับซ้อนของโค้ดได้ ก็ต้องย้อนโปรเจกต์กลับไปยังสถานะเริ่มต้น
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ฉันยังคงรู้สึกว่า กระบวนการเขียนโค้ดด้วยตัวเองและจัดระเบียบความคิด นั้นสำคัญ
สำหรับฉัน โค้ดเหมือนเป็นกลไกบังคับให้ต้องขัดเกลารายละเอียด
แค่เขียนสเปกอย่างเดียวให้ความลึกแบบนั้นไม่ได้
ถ้าโยนกระบวนการนี้ให้ LLM ทำ ก็เหมือนเครื่องบินเข้าสู่ภาวะ stall แล้วสมองหยุดนิ่ง
ความเครียดจากการแก้ปัญหาลดลงก็จริง แต่แรงจูงใจในการคิดและสร้างสรรค์ก็หายไปด้วย
คนรอบตัวชอบให้ AI เขียนโค้ดแทน แต่ฉันไม่ใช่คนกลุ่มนั้น
มันยากที่จะเชื่อคนที่บอกว่าจิบกาแฟไปพร้อมกับรันเอเจนต์ 5 ตัวแล้วสร้าง SaaS ได้
ถ้าต้องการโค้ดคุณภาพดี ฉันคิดว่าจำเป็นต้อง ลงลึกกับโค้ดด้วยตัวเอง
ถึงอย่างนั้น AI ก็มีประโยชน์มากกับ งานซ้ำๆ ง่ายๆ อย่างการเขียนเทสต์หรือแก้ปัญหาการตั้งค่า
ตัวอย่างเช่น ฉันเอาโปรเจ็กต์ที่เลิกทำไปเมื่อ 5 ปีก่อนกลับมาปัดฝุ่นด้วย Claude แล้วในไม่กี่ชั่วโมงก็รู้สึกว่าเดินหน้าไปได้ครึ่งทาง
แต่ช่วงนี้ก็รู้สึกเหมือนกลับไปใช้ แนวทางที่ยึดสเปกเป็นศูนย์กลาง
ด้วยเอเจนต์ ทำให้ลองแล้วทิ้งได้เร็ว จึงยังรักษา กระบวนการพัฒนาแบบวนซ้ำ เอาไว้ได้
ฉันมองว่าสเปกกับเทสต์คือผลงานหลักจริงๆ และค่อยๆ แก้ไขไปพร้อมจัดระเบียบความคิด
แค่สเปกอย่างเดียวไม่สามารถครอบคลุมความซับซ้อนของโลกจริงได้ทั้งหมด
โค้ดที่ LLM เขียนมักจะ เยิ่นเย้อและไหลไปในทิศทางแปลกๆ จึงต้องคอยกำกับด้วยตัวเอง
แต่ในฐานะ พาร์ตเนอร์สำหรับถกและขัดเกลาไอเดีย นั้น LLM ก็ใช้ได้ดีทีเดียว
ตอนนี้เมื่อการเขียนโค้ดถูกลงและเร็วขึ้น บางทีเราอาจต้องเสริม ขั้นตอนการออกแบบอย่างเป็นทางการ ให้แข็งแรงขึ้นแทน
ฉันคิดว่าสิ่งที่ส่งผลต่อคุณภาพโค้ดมากที่สุดคือการตั้งค่า เครื่องมือวิเคราะห์สถิต อย่างเป็นระบบ
ในฝั่ง TypeScript ฉันรวม
tsc,eslint,sonarjs,knip,jscpd,dependency-cruiser,semgrepเข้าด้วยกันผ่านคำสั่งpnpm checkและให้รันอัตโนมัติด้วย pre-commit hook เพื่อกันปัญหาที่ LLM พลาดไป
ด้วยแบบนี้ ต่อให้ LLM ไปต่อไม่ได้ ก็ยังแก้ด้วยมือได้ง่าย
ถ้าสไตล์โค้ดสม่ำเสมอ การรีวิวก็ง่ายขึ้นมาก และถึงจะมีทั้งโค้ดจาก AI กับจากคนปนกันก็สับสนน้อยลง
แต่ถึงจะผ่านทั้ง lint และเทสต์ ก็ยังมี โค้ดที่ทำงานไม่ตรงกับเจตนา ได้อยู่ดี
ตัวอย่างเช่น API ที่คืนค่าเป็นอาร์เรย์ว่างแทน 404 แบบนี้ไวยากรณ์ถูกแต่ความหมายผิด
การประเมิน ความถูกต้องเชิงพฤติกรรม แบบนี้ยังคงเป็นส่วนที่ยากที่สุดในตอนนี้
บางครั้งฉันคิดว่าควรให้ความสำคัญกับการบำรุงรักษามากกว่ากฎ lint
ทุกครั้งที่เพิ่มฟีเจอร์ ฉันจะทำ refactoring เป็นประจำ
ทุกๆ ไม่กี่ฟีเจอร์ก็จะตรวจและจัดระเบียบโค้ดเบสทั้งก้อน
ฉันเขียนโค้ดมา 40 ปีแล้ว แต่โค้ดตอนนี้คือช่วงที่พอใจที่สุด
แต่ด้วย LLM ทำให้ ต้นทุนของการ refactor แทบจะใกล้ศูนย์
ตอนนี้จึงไม่มีเหตุผลจะปล่อยให้โค้ดแย่ค้างอยู่
ฉันคิดว่าคุณค่าที่แท้จริงคือเอาเครื่องมือที่ช่วยเพิ่มประสิทธิภาพมาใช้เพื่อยกระดับคุณภาพ
ฉันสร้างเครื่องมือภายในที่ทำเครื่องหมายบรรทัดโค้ดในแต่ละ commit เป็น ดี (เขียว) / ต้อง refactor (เหลือง) / ต้องเขียนใหม่ (แดง)
มันสะอาดและเป็นระบบกว่าคอมเมนต์ “TODO refactor” มาก และกำลังจะปล่อยเป็นโอเพนซอร์สเร็วๆ นี้
ตอนนี้ฉันคิดว่า การพัฒนาแบบอิงสเปก คือแนวทางที่เสถียรที่สุดหากต้องทำงานร่วมกับ AI
ฉันใช้เวลามากขึ้นกับการขัดเกลาสเปกให้ละเอียดและแลกเปลี่ยนไอเดียกับทีมและ AI
ถ้าสเปกไม่สมบูรณ์ AI ก็จะสร้างโค้ดหลงทิศหลงทาง
พอเข้าใจโดเมนลึกขึ้นแล้ว ก็มักรู้สึกว่าการให้มันเริ่ม implement ใหม่ตั้งแต่ต้นจะดีกว่า
ตอนนั้นมีวิสัยทัศน์ว่า “แค่กำหนด requirement แล้วระบบจะสร้างทุกอย่างให้เอง”
สุดท้ายมันล้มเหลวและ agile กลายเป็นกระแสหลัก แต่ตอนนี้เทคโนโลยีดูเหมือนจะทำให้ความฝันนั้นเป็นไปได้อีกครั้ง
คุณค่าที่แท้จริงของ AI อยู่ที่ ความเร็วและความสามารถในการจัดการความกำกวม
แต่ถ้าต้องผ่านทุกขั้นตอนครบหมด สุดท้ายมันก็ช้าจนเหมือน waterfall
ฉันคิดว่าสู้เขียนโค้ดเองแล้วใช้ AI เป็น ผู้รีวิวรอบแรก จะดีกว่า
การเดินหน้าแบบตรวจสอบเร็วเป็นหน่วยเล็กๆ ยังเป็น แนวทางแบบ agile อยู่ดี
โดยเฉพาะข้อเสนอเรื่อง การทำเครื่องหมายฟังก์ชันที่เกี่ยวกับความปลอดภัย ซึ่งดีมาก เพราะช่วยรักษาบริบทไว้เมื่อโค้ดถูกเปลี่ยนภายหลัง
คำว่า “แบ่งให้เล็ก” เป็นพื้นฐานก็จริง แต่เป็นจุดที่มือใหม่มักพลาดบ่อย
ตลกดีที่ทุกวันนี้ผู้คนกลับมาค้นพบ best practices พื้นฐาน อีกครั้งเพราะ AI
ทั้งที่จริงๆ แล้วมันคือสิ่งที่ควรทำกันมาตั้งนานแล้ว
ตอนนี้เมื่อเวลาเขียนโค้ดลดลง ก็มีช่องว่างให้ทำงานพวกนี้มากขึ้น
แถม AI ยัง นำเอกสารไปใช้จริง ด้วย ดังนั้นการเขียนเอกสารให้ดีจึงมีคุณค่าโดยตรง
ในอดีตเขียนเอกสารไปก็มักถูกเมิน แต่ LLM อ่านหมด
เมื่อก่อนฉันเคย เขียนสเปกละเอียดก่อนลงมือเขียนโค้ด แต่ภายหลังก็พบว่าการกระโดดเข้าไปที่โค้ดเลยเร็วกว่า
แต่ตอนนี้เรากำลังย้อนกลับไปสู่แนวทางที่สเปกเป็นศูนย์กลางอีกครั้งหรือเปล่า?
ถ้ายังไม่เข้าใจปัญหาอย่างถ่องแท้แล้วไปเขียนสเปก สุดท้ายก็ต้องมาเรียนรู้ตอนลงมือเขียนโค้ดอยู่ดี
ตอนนี้ดูเหมือนว่าเราอยู่ตรงกลางระหว่างสองทางนั้น
แต่ตอนนี้ด้วย AI ต้นทุนของโค้ดที่ผิดแทบเป็นศูนย์ จึงรู้สึกว่าคุณค่าของสเปกลดลง
มันคล้ายกับแนวคิดการเขียนโปรแกรมที่ Joe Armstrong เคยพูดไว้
ตอนนี้มันกลายเป็นสิ่งที่ทำได้จริงแล้ว
ตอนที่รับตำแหน่ง lead ฉันจะ เขียน ticket อย่างละเอียดมาก
ก็เพื่อช่วย junior ด้วย แต่ก็เพื่อกันไม่ให้ตัวเองลืมรายละเอียดด้วยเช่นกัน
แต่ฝ่ายบริหารมองว่าเป็น “การเสียเวลา” และคัดค้าน จนสุดท้ายฉันก็เลิกนิสัยนั้นไป
ตอนนี้กลับถูกคาดหวังให้เขียนสเปกที่ละเอียดกว่านั้นอีก ได้เร็วกว่าเดิม
เวลาใช้ AI agent ฉันสงสัยเรื่อง สัดส่วนระหว่าง Markdown กับโค้ด รวมถึง ความอ่านง่าย ของผลลัพธ์
และก็ยังสงสัยด้วยว่า เวลาที่ใช้รีวิวจะไม่มากกว่าการเขียนโค้ดเองจริงหรือ
มันช่างประชดดีที่ทุกวันนี้นักพัฒนาจำนวนมาก ออกตัวสนับสนุน AI อย่างกระตือรือร้น ทั้งที่มันอาจมาแทนที่ตัวเอง
ลิงก์ทวีตที่เกี่ยวข้อง ล้อเลียนปรากฏการณ์นี้ไว้
ข้อความแนว “ถ้าไม่ใช้ Claude คุณจะตามไม่ทัน” อาจเป็นเหตุผลนั้นก็ได้
มันมีโอกาสสูงที่จะนำไปสู่ ความต้องการนักพัฒนาที่ลดลงและค่าตอบแทนที่ลดลง
โดยเฉพาะนักพัฒนาที่ทำได้แค่ประกอบแพ็กเกจ NPM เข้าด้วยกัน ยิ่งเสี่ยงมาก