การฝึกจินนี่: "เขียนโค้ดแบบ Kent Beck"

 (tidyfirst.substack.com)
5 คะแนน โดย GN⁺ 2026-01-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ผลการทดลองว่าการเพิ่มพรอมป์ต์บุคลิกให้เครื่องมือเขียนโค้ดด้วย AI (Genie) ว่า "Code like Kent Beck" จะช่วยยกระดับคุณภาพโค้ดหรือไม่ พบว่าสไตล์การทดสอบและการตั้งชื่อตัวแปรดีขึ้น แต่ การออกแบบสถาปัตยกรรม ไม่เปลี่ยนแปลง
  • ตรวจสอบเปรียบเทียบผลของพรอมป์ต์บุคลิกและข้อจำกัดด้านการออกแบบผ่านโปรเจ็กต์ที่ใช้งานโครงสร้างข้อมูล Rope
  • บุคลิกช่วยปรับปรุง พฤติกรรมระดับจุลภาค (วิธีทดสอบ, การตั้งชื่อ) ขณะที่ข้อจำกัดที่ระบุอย่างชัดเจนเป็นตัวกำหนด สถาปัตยกรรมระดับมหภาค (โครงสร้างลำดับชั้นของคลาส)
  • จากการทดลอง 4 กลุ่ม พบว่า พรอมป์ต์ที่ผสาน ทั้งบุคลิกและข้อจำกัดให้ผลลัพธ์ดีที่สุด
  • อ้างอิง "The Bitter Lesson" ของ Rich Sutton เพื่อชี้ว่า แทนที่จะเข้ารหัสความเชี่ยวชาญของมนุษย์ การ ใช้ทรัพยากรการคำนวณ กลับมีประสิทธิภาพมากกว่า

ระยะปัจจุบันของเครื่องมือเขียนโค้ด AI

  • ปัจจุบันเครื่องมือเขียนโค้ด AI (Genie) ยังอยู่ในช่วงของ "รถม้าไร้ม้า"
  • นวัตกรรมทางเทคโนโลยีทุกอย่างมักถูกทำความเข้าใจผ่านกรอบเดิมก่อน แล้วจึงค่อยตระหนักถึงการเปลี่ยนแปลงเชิงรากฐาน
    • รถม้าไร้ม้า → รถยนต์
    • โทรเลขไร้สาย → วิทยุ
    • ไปรษณีย์อิเล็กทรอนิกส์ → การรับส่งข้อความ
  • การจะเข้าใจ ผลกระทบลำดับที่สอง ของเทคโนโลยีใหม่ รวมถึงวงจรเสริมแรงและวงจรถ่วง จำเป็นต้องใช้งานมันเป็นเวลานานพอ

การทดลอง: โครงสร้างข้อมูล Rope

  • โครงสร้างข้อมูล Rope เป็นโครงสร้างสำหรับลบอักขระตรงกลางของสตริงที่ยาวมากได้อย่างมีประสิทธิภาพ
  • วิธีแบบง่ายต้องเลื่อนอักขระด้านขวาทั้งหมด จึงใช้เวลา O(n)
  • โครงสร้าง Rope ใช้วัตถุ substring และวัตถุ concatenation เพื่อให้การลบทำได้ใน เวลาคงที่
    • เมื่อมีการลบ จะมีการจัดสรรวัตถุ 3 ตัว
    • การค้นหามีค่าเป็น O(จำนวนการดำเนินการ) แต่ยังน้อยกว่าความยาวของสตริง และสามารถบีบอัดเป็นระยะได้

กระบวนการทดลอง

Phase 1: บุคลิก ("Code like Kent Beck")

  • ตรวจสอบว่าการเพิ่มพรอมป์ต์ "Code like Kent Beck" จะช่วยยกระดับคุณภาพโค้ดหรือไม่
  • ผลลัพธ์: พบว่ารูปแบบโค้ดดีขึ้น
    • ชื่อตัวแปรดีขึ้น
    • กลยุทธ์การทดสอบเปลี่ยนจาก สคริปต์แบบก้อนเดียวไปเป็นยูนิตเทสต์แบบแยกส่วน (แนวทาง TDD)
  • สิ่งที่ค้นพบเกินคาด: สถาปัตยกรรมไม่เปลี่ยน
    • ใช้ไบนารีทรีมาตรฐานในการทำ Rope
    • มองข้าม แพตเทิร์น Composite ที่ Kent Beck ใช้

Phase 2: เพิ่มแนวทางการออกแบบ

  • โค้ดของกลุ่ม Control ยืดยาวเกินไปจนเกิดข้อผิดพลาดไวยากรณ์จาก เกินขีดจำกัดโทเค็น
    • แก้ปัญหาได้ด้วยการเพิ่มขีดจำกัดโทเค็น
    • การเพิ่มพลังประมวลผล อาจเป็นทางแก้ที่ตรงไปตรงมา
  • เพิ่ม ข้อจำกัดอย่างชัดเจน ลงในพรอมป์ต์
    • "ใช้แพตเทิร์น Composite"
    • "แยกพฤติกรรมออกเป็นคลาสขนาดเล็กที่มีหน้าที่เฉพาะ"
  • ผลลัพธ์: ได้การออกแบบตามที่คาดหวัง
    • แยกคลาส Substring และ Concatenation
    • โครงสร้างเรียบง่ายกว่าคลาสเดียว
    • ในทางปฏิบัติกลับได้แบบที่ง่ายยิ่งกว่า: จัดการด้วย Substring 0..size โดยไม่ต้องมี Null Object (EmptyString) หรือ wrapper สำหรับสตริงแบบเนทีฟ

Phase 3: การทดลองแยก 4 กลุ่ม

  • ออกแบบการทดลองแบบไขว้เพื่อดูว่าแทรกแซงแบบใดที่ก่อให้เกิดผล
    1. Control: ผู้ช่วยมาตรฐาน
    2. Kent Beck: ใช้เฉพาะบุคลิก
    3. Composite: ใช้เฉพาะข้อจำกัดด้านสถาปัตยกรรม
    4. Combined: บุคลิก + ข้อจำกัด

บทสรุปของการทดลอง

  • ยืนยันผลแบบ เมทริกซ์ 2x2
    1. บุคลิกกำหนดพฤติกรรมระดับจุลภาค: พรอมป์ต์ "Kent Beck" ช่วยยกระดับ สไตล์การทดสอบ และ การตั้งชื่อ ได้อย่างสม่ำเสมอ แต่ไม่ส่งผลต่อการตัดสินใจเชิงโครงสร้าง
    2. ข้อจำกัดกำหนดสถาปัตยกรรมระดับมหภาค: พรอมป์ต์ "Composite Pattern" บังคับ ลำดับชั้นของคลาส และสร้างการออกแบบที่แยกละเอียดได้แม้ไม่มีบุคลิก
    3. การผสานกันดีที่สุด: กลุ่ม Combined ให้ทั้งสถาปัตยกรรมที่ถูกต้อง (Composite) และนิสัยการพัฒนาที่ถูกต้อง (TDD/Unit Tests)

การประยุกต์ใช้ The Bitter Lesson

  • เป้าหมายที่ซ่อนอยู่คือทำให้ Genie พัฒนาได้ดีขึ้น โดยรักษาสมดุลระหว่าง ฟังก์ชันการทำงานกับอนาคต
  • วิธีที่ลองใช้มีทั้งการทำพรอมป์ต์อย่างประณีต การตรวจทานการเปลี่ยนแปลงที่ Genie เสนออย่างรอบคอบ และการแบ่งขั้นตอนให้เล็กลง/ใหญ่ขึ้น
  • อ้างอิง "The Bitter Lesson" ของ Rich Sutton
    • บทเรียนจากงานวิจัย AI ตลอด 70 ปีชี้ว่า การใช้ทรัพยากรการคำนวณ ให้ผลดีกว่าการพยายามเข้ารหัสความเชี่ยวชาญของมนุษย์
    • การพยายามเข้ารหัสสไตล์เป็น ความผิดพลาดแบบเดียวกัน ที่ทุกคนมักทำ

ข้อเสนอเรื่องสไตล์การพัฒนาที่มีประสิทธิภาพผ่านการใช้การคำนวณ

  • ไม่จำเป็นต้องติดอยู่กับ จินนี่เขียนโค้ดที่งุ่มง่าม ซึ่งคัดลอกสไตล์โค้ดแย่ ๆ จากรีโพซิทอรีนับไม่ถ้วน
  • ข้อเสนอสำหรับ การใช้การคำนวณให้เกิดประโยชน์
    1. เลือกรีโพซิทอรีขนาดใหญ่
    2. ให้จินนี่นับล้านตัวนำฟีเจอร์ถัดไปไปพัฒนา โดยแต่ละตัว เลือกวิธีจัดระเบียบและปริมาณการจัดระเบียบต่างกัน
    3. เลือกจินนี่ที่เพิ่มฟีเจอร์ได้สำเร็จด้วยต้นทุนต่ำที่สุด (เวลา, โทเค็น, ไฟฟ้า, ค่าใช้จ่าย ฯลฯ)
    4. ทำซ้ำในหลายจินนี่ หลายฟีเจอร์ และหลายรีโพซิทอรี
  • มันอาจดูเหมือนเป็นการ "สิ้นเปลือง" การเขียนโค้ด แต่จริง ๆ แล้วไม่ใช่
  • Jessica Kerr เรียกสิ่งนี้ว่า "Design Contest"

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
kallare 2026-01-25

ถ้างั้นถ้าบอกให้เขียนโค้ดเหมือน Jeff Dean ล่ะ จะเป็นยังไงกันแน่...?!