วิธีเขียนโปรแกรมร่วมกับเอเจนต์

 (crawshaw.io)
22 คะแนน โดย GN⁺ 2025-06-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บทความนี้เป็นตอนที่สองว่าด้วยการปรับประสบการณ์การเขียนโปรแกรมแบบเดิมให้เข้ากับโลกของ คอมพิวเตอร์เชิงสนทนา (LLM, เอเจนต์)
  • ในตอนแรก "วิธีเขียนโปรแกรมร่วมกับ LLM" ได้อธิบายวิธีนำ LLM ไปผนวกรวมกับเครื่องมือเดิมเพื่อใช้เป็นตัวช่วยเติมโค้ดอัตโนมัติหรือใช้แทนการค้นหา
  • ครั้งนี้จะมาแบ่งปันประสบการณ์จริงและข้อสังเกตของ การเขียนโปรแกรมแบบใช้เอเจนต์เป็นฐาน ซึ่งยากขึ้นแต่ก็คุ้มค่ามากกว่า

ความหมายของเอเจนต์และภาพความเป็นจริง

  • ในบริบทของ LLM (โมเดลภาษาขนาดใหญ่) การนิยามคำว่า "เอเจนต์" ให้ชัดเจนมีความหมาย
  • แม้คำนี้จะถูกใช้มานานราวกับเป็นคำฮิตในวงการ AI แต่เพิ่งไม่นานนี้เองที่มันเริ่มมีรูปแบบที่ใช้งานได้จริง
  • ระหว่างทาง คำนี้ถูกห่อหุ้มด้วยถ้อยคำเชิงการตลาดและความลึกลับอยู่มาก
  • หากมองจากมุมของวิศวกร ตอนนี้สามารถนิยามได้อย่างชัดเจนและเรียบง่ายว่า: เอเจนต์คือโค้ด 9 บรรทัด หรือก็คือ for loop ที่มีการเรียก LLM อยู่ภายใน
  • ภายในลูปนี้ LLM สามารถรันคำสั่งและตรวจสอบผลลัพธ์ได้ด้วยตัวเอง พร้อมทำซ้ำไปเรื่อย ๆ โดยไม่ต้องมีมนุษย์แทรกแซง
  • อาจฟังดูเรียบง่าย แต่เมื่อจัดแบบนี้แล้ว ความสามารถด้านการเขียนโปรแกรมจะพุ่งสูงกว่าการใช้ LLM แบบล้วน ๆ อย่างมาก

ความต่างระหว่างการเขียนโปรแกรมบนไวต์บอร์ดกับเอเจนต์

  • ลองสมมติว่ายืนอยู่หน้าไวต์บอร์ดและต้องเขียนฟังก์ชันภาษา C สำหรับตรวจสอบความถูกต้องของสตริง UTF-8 ด้วยปากกาเมจิก
    • (นี่เป็นสถานการณ์สัมภาษณ์ที่ผู้เขียนเคยเจอจริง และเป็นโจทย์สัมภาษณ์ที่พบได้บ่อย)
    • ความสำเร็จหรือล้มเหลวของงานนี้ขึ้นอยู่กับประสบการณ์ของคุณในฐานะโปรแกรมเมอร์ และความสามารถในการกลบข้อจำกัดที่ไม่สามารถอ้างอิงข้อมูลภายนอกได้
    • คุณต้องจำกฎการเข้ารหัส UTF-8 ให้ได้ และต้องระวังไม่ให้ไวยากรณ์ของ C ไปปะปนกับภาษาในตระกูล C อื่น ๆ (เช่น ลำดับชื่อ-ชนิด หรือชนิด-ชื่อ)
    • แต่ในชีวิตการทำงานจริง คุณสามารถใช้ feedback จากคอมไพเลอร์ การค้นเอกสาร printfs และวิธีอื่น ๆ เพื่อตรวจสอบโค้ดและหาข้อผิดพลาดได้
  • การให้ LLM เขียนโค้ดโดยไม่มีเอเจนต์ คล้ายกับการเขียนโค้ดบนไวต์บอร์ดโดยไม่มีความช่วยเหลือจากภายนอก
    • เป็นงานที่ต้องเค้นความจำลาง ๆ ออกมา พยายามให้ไวยากรณ์ถูกต้องด้วยวิธีที่ไม่มีประสิทธิภาพ และต้องหลีกเลี่ยงการจินตนาการอินเทอร์เฟซผิด ๆ
    • แม้ความสามารถที่ LLM สร้างโปรแกรมใหม่ขึ้นมาได้จะน่าทึ่งในเชิงเทคนิค แต่ไวต์บอร์ดเสมือนที่ต่อกับ GPU เพียงอย่างเดียวก็ยังไม่ช่วยเพิ่มผลิตภาพการเขียนโปรแกรมอย่างมีนัยสำคัญ
  • แต่ถ้าให้ LLM มากกว่าไวต์บอร์ดเสมือน ล่ะ?
    • เช่น ให้มันเรียกคอมไพเลอร์ ตรวจดูข้อผิดพลาดจากการคอมไพล์ แล้วแก้เองได้?
    • หรือให้มันอ่านไฟล์เดิมด้วย grep, cat แพตช์หลายไฟล์รวมถึงยูนิตเทสต์ และรันทดสอบซ้ำไปเรื่อย ๆ ได้?
  • เอเจนต์ก็คือ LLM แบบมี feedback บนฐานนี้นั่นเอง

เอเจนต์ = LLM ที่ทำงานในสภาพแวดล้อมที่มี feedback

  • LLM ที่ทำงานได้ดีใน สภาพแวดล้อมที่มี feedback แบบเดียวกับมนุษย์ สามารถแสดงความสามารถด้านการเขียนโปรแกรมได้จริงด้วยเครื่องมือคุ้นเคยเพียงไม่กี่อย่าง
    • bash(cmd): รันคำสั่งเทอร์มินัล (find, cat, grep ฯลฯ)
    • patch(hunks): แพตช์ไฟล์และนำการแก้โค้ดไปใช้
    • todo(tasks): จัดการรายการงาน
    • web_nav(url), web_eval(script), web_logs(), web_screenshot() ฯลฯ: ท่องเว็บ ประเมินผล ดูล็อก และจับภาพหน้าจอ
    • keyword_search(keywords): ค้นหาด้วยคีย์เวิร์ด
    • codereview(): รีวิวโค้ด
  • มันใช้เครื่องมือ bash เพื่อ สำรวจโค้ดเบสได้อย่างมีประสิทธิภาพ และยังทำเวอร์ชันคอนโทรลอย่าง git add/commit ให้เป็นอัตโนมัติได้ด้วย
  • ต่างจาก LLM ที่ทำแค่สร้างโค้ดโดยไม่มีเครื่องมือเหล่านี้ เอเจนต์มีข้อได้เปรียบสำคัญดังนี้
    • ความแม่นยำในการใช้ API สูงขึ้นมาก (ค้นเอกสารและนำมาใส่ใน context ได้โดยตรง)
    • feedback จากคอมไพเลอร์ ช่วยลดข้อผิดพลาดด้านไวยากรณ์และความเข้าใจผิดเรื่องอินเทอร์เฟซ
    • ความสามารถด้าน dependency/การจัดการเวอร์ชัน ดีขึ้น (เข้าใจคุณลักษณะของเวอร์ชันเฉพาะได้)
    • การตรวจจับข้อผิดพลาดผ่านการทดสอบที่ล้มเหลว และนิสัยการเขียนเทสต์ ดีขึ้น
    • จัดการโค้ดเบสที่เกินข้อจำกัดของ context window ได้ (เลือกอ่านเฉพาะส่วนที่จำเป็น)
    • ทดลองผลลัพธ์การรันได้โดยตรง: รันโค้ด รับ feedback จากสกรีนช็อตของหน้าเบราว์เซอร์ ปรับ CSS อัตโนมัติ ติดตามข้อผิดพลาดจาก server log และเพิ่มเทสต์
  • แน่นอนว่าก็มีข้อเสีย
    • คำขอเพียงประโยคเดียวอาจทำให้เกิดโทเคนระหว่างทางนับหมื่นรายการ (การเรียกเครื่องมือ การค้นเว็บ การทดสอบซ้ำ ฯลฯ) และ ใช้เวลาทำงานตั้งแต่หลายนาทีขึ้นไป
    • มีต้นทุนจากการเรียก API ด้วย แต่คาดว่าปัญหานี้จะค่อย ๆ ลดลงตามพัฒนาการของฮาร์ดแวร์
  • สุดท้ายแล้ว แรงงานตรงกลางถูกให้ CPU/GPU รับไปแทน ช่วยประหยัดเวลาของนักพัฒนาและทำให้สร้างโปรแกรมที่อยากเขียนได้มากขึ้น
  • ในทางปฏิบัติ การนำเอเจนต์มาใช้กับโปรเจกต์แล้ว ลองมอบงานเล็ก ๆ ให้ทำและตรวจผลลัพธ์ นั้นทำได้ง่ายมาก

ตัวอย่าง: พัฒนาการยืนยันตัวตนของ Github App

  • นี่คือตัวอย่างจริงของการใช้เอเจนต์เพื่อสร้าง flow การยืนยันตัวตนของ Github App สำหรับ sketch.dev
    • ใช้ feedback เพียง 3~4 รอบก็ทำ flow การยืนยันตัวตนทั้งชุดเสร็จอย่างรวดเร็ว
    • เมื่อพบข้อผิดพลาดหรือเงื่อนไขเพิ่มเติม แค่บรรยายด้วยประโยคสั้น ๆ มันก็ปรับทั้งโค้ดและพฤติกรรมให้ทันที
    • มันช่วยลด "งานจิปาถะ" ในงานจริงอย่างการเชื่อม API ซ้ำ ๆ ระบบบิลด์ การจัดการแพ็กเกจ และการตั้งค่าไลบรารี ทำให้ รักษาโมเมนตัมของผลิตภาพ ได้ดีมาก
  • ข้อกำหนดตั้งต้นมีว่า "ใช้เฉพาะข้อมูลยืนยันตัวตนแบบ global ของแอป โดยไม่เก็บโทเคนแยกตามผู้ใช้" และเอเจนต์ก็ทำตามนั้น
    • แต่ผลก็คือเกิด ช่องโหว่ด้านความปลอดภัยร้ายแรง (ใครก็สามารถดูทุก repo ได้)
    • เมื่ออธิบายปัญหาด้วย feedback เพียงประโยคเดียว มันก็เพิ่มการตรวจสิทธิ์แยกตามผู้ใช้และสร้าง commit ที่แก้ไขแล้วทันที
  • จากนั้นก็พบ ปัญหาด้านประสิทธิภาพ
    • โครงสร้างด้านล่างทำให้ต้องมีการเรียก API กับทุกคู่ผสมระหว่างผู้ใช้กับ repo จึงมีปัญหาเรื่องการขยายระบบ 
      for install := range allAppInstallations {  
	for r := range install.Repositories() {  
		if r.IsCollaborator(user) {  
			// add to available repositories  
		}  
	}  
}
    • จึงตระหนักว่าต้นตอของปัญหานี้จริง ๆ มาจากข้อกำหนดของตัวเองที่ว่า "จะไม่เก็บโทเคนแยกตามผู้ใช้"
    • เมื่อเปลี่ยนข้อกำหนด (ยอมให้เก็บโทเคนแยกตามผู้ใช้) เอเจนต์ก็ออกแบบใหม่ด้วยวิธีเรียก API ที่มีประสิทธิภาพกว่า
  • อันที่จริง จำนวนคำที่ใช้เขียนอธิบายกระบวนการนี้ในบทความ ยังมากกว่าจำนวนคำทั้งหมดที่ป้อนเข้า Sketch เพื่อให้ได้โค้ดยืนยันตัวตนเสียอีก
  • สรุปสั้น ๆ คือ เอเจนต์ยังไม่ถึงขั้นแทนนักพัฒนาได้ในวันนี้ แต่ ช่วยให้งานซ้ำ ๆ ที่แต่เดิมต้องใช้เวลาหลายวัน เสร็จได้ภายในวันเดียว
  • ระบบอัตโนมัติไปได้ไกลถึงขั้นที่นักพัฒนายังสามารถให้มันทำงานต่อไปได้แม้ระหว่าง "กำลังทำความสะอาดห้องลูก"

ตัวอย่าง: การใช้กฎ SQL แบบอิง JSON

  • หนึ่งในงานที่เอเจนต์ทำบ่อยคือ ต้องใช้ สไตล์ SQL แปลก ๆ ที่เรียนมาจาก Tailscale
    • ทุกตารางจะมีคอลัมน์จริงเพียงหนึ่งเดียว (ข้อมูล JSON) ส่วนคอลัมน์ที่เหลือเป็น generated column ที่ได้มาจาก JSON
    • ตัวอย่างโครงสร้างตาราง: 
      CREATE TABLE IF NOT EXISTS Cookie (  
  Cookie   TEXT    NOT NULL AS (Data->>'cookie')  STORED UNIQUE, -- PK  
  UserID   INTEGER NOT NULL AS (Data->>'user_id') STORED REFERENCES User (UserID),  
  Created  INTEGER NOT NULL AS (unixepoch(Data->>'created')) STORED,  
  LastUsed INTEGER AS (unixepoch(Data->>'last_used')) CHECK (LastUsed>0),  
  Data     JSONB   NOT NULL  
);
    • วิธีนี้ทำหน้าที่คล้าย poor man’s ORM ช่วยให้ขยายสคีมาได้ง่ายขึ้น และ constraint ของ SQL ก็ช่วยตรวจคุณภาพของข้อมูล JSON ได้
    • ข้อเสียคือข้อมูลที่เก็บต่อแถวจะมากขึ้น และทุก INSERT/UPDATE ต้องทำในหน่วยของ JSON
  • แต่เอเจนต์ ไม่ได้ทำตามสไตล์นี้อย่างสม่ำเสมอเสมอไป
    • ตอนสร้างตารางใหม่มักทำได้ค่อนข้างดี แต่ถ้ามีข้อยกเว้นก็อาจสับสนหรือเปลี่ยนสไตล์เองตามใจ
  • วิธีแก้ง่าย ๆ คือเพิ่ม คำอธิบาย 3 ประโยค ไว้ด้านบนไฟล์สคีมา SQL
    • เพิ่มประโยคคีย์เวิร์ดว่า "แต่ละตารางมีเพียงคอลัมน์ Data JSON จริงหนึ่งคอลัมน์ และคอลัมน์อื่นทั้งหมดถูกอนุมานมาจากมัน"
    • ตารางที่ไม่ทำตามกฎนี้ให้ใส่คอมเมนต์แยกไว้ว่านี่เป็นข้อยกเว้น
    • หลังจากนั้นพฤติกรรมของเอเจนต์ ดีขึ้นอย่างเห็นได้ชัด
  • จุดที่น่าสนใจคือ แม้คำอธิบายและคอมเมนต์แบบนี้มนุษย์วิศวกรมักมองข้ามหรือให้ค่าต่ำ
    • แต่เอเจนต์ที่อิง LLM กลับนำคอมเมนต์และคำอธิบายมาใช้ในการเขียนโค้ดอย่างจริงจัง
    • เพียงเขียนคำอธิบายให้ดี คุณภาพของโค้ดที่สร้างก็จะดีขึ้นอย่างชัดเจน

โมเดลโค้ดแบบ “สินทรัพย์” และ “หนี้สิน”

  • หนึ่งในคำวิจารณ์ที่พบบ่อยต่อเครื่องมือสร้างโค้ดด้วย LLM คือ การสร้างโค้ดเองเป็นเพียงส่วนน้อยมากของต้นทุนซอฟต์แวร์ทั้งหมด
    • ในความเป็นจริง เวลาส่วนใหญ่หมดไปกับการจัดการ dependency ความพัวพัน และอินเทอร์เฟซที่ซับซ้อนของโค้ดเดิม
    • ผลิตภัณฑ์ขนาดใหญ่ เก่า และมีผู้ใช้จำนวนมาก มักมีต้นทุนการบำรุงรักษาสูงล้น
    • ในสภาพแวดล้อมแบบนี้ การไปขอให้ LLM "เขียน bubble sort เป็น Fortran ให้หน่อย" อาจดูเหมือนของเล่นหรือสิ่งรบกวนที่น่ารำคาญ
    • มีการเปรียบเทียบกับแนวคิด "สินทรัพย์/หนี้สิน" ทางการเงินเช่นกัน แต่ก็ไม่ได้ตรงเป๊ะนัก
  • อย่างไรก็ตาม ไม่ใช่ว่างานวิศวกรรมซอฟต์แวร์ทั้งหมดจะเป็นโปรเจกต์ขนาดใหญ่ระยะยาวแบบนี้เสมอไป
    • โปรแกรมส่วนใหญ่มีผู้ใช้น้อย หรือเป็นโปรเจกต์อายุสั้น
    • ไม่ควรขยายประสบการณ์การบำรุงรักษาระบบใหญ่ไปตีความว่าเป็นธรรมชาติของทั้งอุตสาหกรรม
  • คุณค่าของเอเจนต์ไม่ได้จำกัดอยู่แค่การสร้างโค้ด
    • เอเจนต์ผสานหลายเครื่องมือเข้ากับ LLM เพื่อ ทำให้การอ่านโค้ด แก้ไฟล์ ลบ/ปรับแก้โค้ด หรือการเปลี่ยนแปลงโดยรวมเป็นอัตโนมัติ
    • มันไม่ได้เก่งแค่เพิ่มโค้ด แต่ยัง ลบโค้ด/รีแฟกเตอร์ ได้อย่างเป็นธรรมชาติด้วย
  • สุดท้ายแล้ว เป้าหมายของวิศวกรคือการเปลี่ยนแปลง (change)
    • ระหว่างกระบวนการเปลี่ยนแปลง แน่นอนว่าคนขับเคลื่อนต้องมีงานเพิ่มเพื่อทำความเข้าใจสิ่งที่ถูกแก้ แต่เอเจนต์กำลังแสดงให้เห็นแล้วว่าสามารถสร้างการเปลี่ยนแปลงแบบค่อยเป็นค่อยไปได้ แม้ในโปรเจกต์ระดับกลาง
    • แม้วันนี้ยังไม่สมบูรณ์พอ แต่มันกำลังพัฒนาอย่างรวดเร็วไปในทิศทางที่ถูกต้อง
  • อีกมุมหนึ่ง ยังมีความเห็นว่า ภาษาและระบบบิลด์ที่ซับซ้อนทำหน้าที่เป็นกำแพงกั้นการเข้ามาของโปรเจกต์
    • บางคนกังวลว่าเมื่อมีเครื่องมือที่ทำให้เขียนโค้ดได้ง่ายขึ้น (LLM, type safety, garbage collection, package management, เอเจนต์ ฯลฯ) กำแพงนี้จะต่ำลงและคุณภาพจะตก
    • หากเป้าหมายของคุณคือการชะลอการเปลี่ยนแปลงหรือควบคุมมัน เครื่องมืออัตโนมัติอย่างเอเจนต์ก็คงไม่เหมาะ

ทำไมต้องเป็นเอเจนต์ในตอนนี้?

  • ต่างจากหลักการ AI ที่ซับซ้อนอย่างทรานส์ฟอร์เมอร์ การ ใส่ feedback loop ให้ LLM เป็นแนวทางที่เข้าใจได้ตรงไปตรงมา
    • หากมองจากฝั่งที่สร้างเครื่องมือสำหรับนักพัฒนา นี่เป็นทิศทางวิวัฒนาการที่ดูเป็นธรรมชาติ
    • อันที่จริง sketch.dev เวอร์ชันแรกเมื่อหนึ่งปีก่อนก็เป็นเพียง LLM ที่ต่อเข้ากับเครื่องมือ Go เท่านั้น แต่เมื่อเทียบกับเอเจนต์ที่ใช้อยู่ตอนนี้แล้ว ต่างกันมากในแง่การใช้งานจริง
    • ในแวดวง ML เอง reinforcement learning (การเรียนรู้แบบอิง feedback) ก็เป็นหลักการพื้นฐานมานานกว่า 50 ปีแล้ว
  • การเกิดขึ้นอย่างแท้จริงของเอเจนต์ผูกอยู่กับวิวัฒนาการของ LLM โดยตรง
    • LLM ในปี 2023 ยังมีความสามารถด้านการเรียกเครื่องมือไม่พอ ทำให้บทบาทเอเจนต์ถูกจำกัด
    • LLM ในปี 2025 ถูกปรับให้เหมาะกับการเรียกเครื่องมือและงานวนซ้ำ จึงทำให้การใช้เอเจนต์ในทางปฏิบัติเป็นไปได้จริง
    • โมเดล Frontier (เชิงพาณิชย์รุ่นล้ำหน้า) ยังเหนือกว่าโอเพนโมเดลอย่างมากในเรื่องการใช้เครื่องมือ
    • คาดว่าโอเพนโมเดลจะไล่ทันได้ภายใน 6 เดือนข้างหน้า
    • ความสามารถในการ เรียกใช้เครื่องมือซ้ำ ๆ อย่างมีประโยชน์ คือการเปลี่ยนแปลงที่ใหญ่ที่สุดของ LLM รุ่นล่าสุด

ทิศทางต่อจากนี้: คอนเทนเนอร์และการรันแบบขนาน

  • วงการ LLM เอเจนต์ยังอยู่ในช่วง เริ่มต้นและเปลี่ยนแปลงเร็ว ที่วิศวกรส่วนใหญ่ยังไม่ได้เอามาใช้จริง
  • ในตอนนี้ เอเจนต์ส่วนใหญ่มักถูกใช้ให้ทำงานใน IDE หรือรีโพซิทอรีบนเครื่องโลคัล
    • เริ่มต้นได้ง่ายผ่านการติดตั้ง VSCode fork หรือเครื่องมือบรรทัดคำสั่ง
    • แต่มี ข้อจำกัดสำคัญ 2 ประการ
      • อย่างแรกคือ การขาดกลไกป้องกัน: เสี่ยงต่อการเปิดเผยข้อมูลอ่อนไหวอย่างข้อมูลยืนยันตัวตนของระบบจริงที่เก็บไว้ในเครื่อง
        • หากเอเจนต์ไปรันคำสั่งที่ไม่ตั้งใจ เช่น deploy script อาจก่อเหตุด้านความปลอดภัยร้ายแรงได้
        • แม้จะให้ยืนยันด้วยมือทุกครั้งก่อนรันคำสั่ง ความเสี่ยงจากการเผลอเปิดเผยข้อมูลสำคัญก็ยังมีอยู่
      • อย่างที่สองคือ ข้อจำกัดด้านการรันขนานและระบบอัตโนมัติ: เพราะนักพัฒนาแต่ละคนต้องรันเอเจนต์ได้ทีละตัวในสภาพแวดล้อมของตัวเอง
        • การทำงานของเอเจนต์หนึ่งครั้งกินเวลาหลายนาที ทำให้ทำหลายงานพร้อมกันได้ยากและไม่มีประสิทธิภาพ
  • ที่ sketch.dev จึงพยายามแก้ข้อจำกัดเหล่านี้ด้วย สภาพแวดล้อมแบบคอนเทนเนอร์
    • สร้าง development container ที่แยกขาดกันสำหรับแต่ละงาน แล้วคัดลอกซอร์สโค้ดเข้าไป จากนั้นดึงเฉพาะสิ่งที่ต้องออกมาภายนอก เช่น git commit
    • ทำให้สามารถรันเอเจนต์หลายตัวพร้อมกันได้ และเอเจนต์อื่น ๆ ก็เริ่มสำรวจแนวทางนี้เช่นกัน
  • ตัวอย่างจริง: ระหว่างทำงานยืนยันตัวตนของ Github ก็ให้เอเจนต์อีกเซสชันหนึ่งไปปรับปรุง UI ของฟอร์มพร้อมกัน
    • โดยไม่ต้องสร้างรายการใน issue tracker แยกต่างหาก แค่ส่งสกรีนช็อตกับคำขอสั้น ๆ หนึ่งบรรทัดเพื่อให้มันแก้ดีไซน์ฟอร์ม
    • มอบประสบการณ์ที่ใช้เวลาเพียง 30 วินาทีแต่ได้ผลลัพธ์ที่ดีเกินระดับหนึ่งแน่นอน
  • ผลจากการทดลอง UX ตลอด 6 เดือนที่ผ่านมา:
    • ได้ข้อสรุปว่าในงานพัฒนาแบบใช้เอเจนต์ คอนเทนเนอร์ (สภาพแวดล้อมรันแบบแยกขาด) คือวิธีที่ใช้งานได้จริงที่สุด

IDE จะกลายเป็นอะไร?

  • ในสภาพแวดล้อมการพัฒนาแบบใช้เอเจนต์ บทบาทของ IDE (integrated development environment) จะเป็นอย่างไร ยังเป็นคำถามที่เปิดอยู่
    • เวิร์กโฟลว์จริงอาจกลายเป็นการพิมพ์คำสั่งให้เอเจนต์เริ่มงาน ให้มันรันในคอนเทนเนอร์ ตรวจการเปลี่ยนแปลงผ่าน diff แล้ว push ออกไปเป็น branch/PR
  • ในทางปฏิบัติ commit ส่วนใหญ่ที่เอเจนต์สร้างขึ้น ยังต้องการการเก็บงานโดยมนุษย์ในระดับหนึ่ง
    • ช่วงแรกแทบทุก commit ต้องแก้ด้วยมือ แต่เมื่อชำนาญในการเขียนพรอมป์มากขึ้น ปริมาณงานแก้ก็จะค่อย ๆ ลดลง
    • สิ่งที่แก้มีได้ตั้งแต่เรื่องง่าย ๆ อย่างแก้คอมเมนต์หรือเปลี่ยนชื่อตัวแปร ไปจนถึงรีแฟกเตอร์ที่ซับซ้อนกว่า
    • ประเด็นสำคัญคือจะทำการแก้เหล่านี้ให้มีประสิทธิภาพในสภาพแวดล้อมแบบคอนเทนเนอร์ได้อย่างไร
  • เวิร์กโฟลว์ที่กำลังทดลองใน sketch.dev เป็นต้น
    • มี อินเทอร์เฟซ diff view ที่แก้ไขได้โดยตรง
      • หากแก้โค้ดตรงด้านขวาของหน้าจอ diff ใน Sketch การแก้นั้นจะถูกนำไปใส่ใน commit และ push ได้ทันที
      • มีประสิทธิภาพมากกับการแก้เล็ก ๆ แค่บรรทัดเดียว
    • มี การเปิดให้ SSH เข้าไปยังคอนเทนเนอร์
      • เข้าเชลล์โดยตรงหรือใช้เว็บเทอร์มินัลเพื่อจัดการโค้ดได้
      • เปิดผ่าน URL แบบ vscode:// แล้วไปทำงานต่อใน IDE แบบดั้งเดิมได้
    • มี คอมเมนต์สไตล์โค้ดรีวิว ให้เขียนทิ้งไว้บน diff เพื่อส่งกลับเป็น feedback ให้เอเจนต์โดยตรง
      • ใช้ประสบการณ์จากการรีวิวโค้ด เพื่อสื่อสารคำอธิบายหรือข้อกำหนดที่จำเป็นด้วยอินพุตให้น้อยที่สุด
  • สรุปรวม
    • สภาพแวดล้อมแบบคอนเทนเนอร์ทำให้การสร้าง-แก้-ตรวจสอบ-รีวิวโค้ดเกิดขึ้นอย่างบูรณาการ
      จึงทำให้การพัฒนาแบบใช้เอเจนต์ที่แท้จริงเกิดขึ้นได้ ไม่ใช่แค่การเขียนโค้ดอย่างเดียว
    • ในอดีตผู้เขียนไม่อยากพัฒนาในคอนเทนเนอร์ แต่ประสบการณ์การเก็บงาน/แก้ diff ที่เอเจนต์สร้างไว้ในคอนเทนเนอร์นั้นน่าสนใจและเพิ่มผลิตภาพมาก

บทส่งท้าย

  • กระบวนการเรียนรู้และทดลองเทคโนโลยีที่อิง LLM เป็น ช่วงเวลาที่สอนให้ถ่อมตน
    • ในอดีต เวลามีการเปลี่ยนแปลงแก่นของการเขียนโปรแกรม เช่น มัลติคอร์ SSD หรือการขยายเครือข่าย ผู้เขียนมักรู้สึกสนุก แต่ LLM โดยเฉพาะเอเจนต์กำลัง เปลี่ยน "กระบวนการของการเขียนโค้ด" เองอย่างสิ้นเชิง
    • ต่างจากการเปลี่ยนแปลงที่เคยมีผลต่อการเลือกอัลกอริทึม ภาษา หรือไลบรารี เอเจนต์กำลังทำให้เราต้อง ทบทวนสมมติฐานพื้นฐานทั้งหมดของวิธีการทำงานเสียใหม่
    • บางครั้งการเปลี่ยนแปลงนี้มากจนรู้สึกว่า "ถ้าเริ่มเรียนใหม่ตั้งแต่ต้นโดยไม่รู้อะไรเกี่ยวกับการเขียนโปรแกรมเลย อาจจะดีกว่า"
    • และการเปลี่ยนแปลงนี้ก็ ยังดำเนินอยู่ในตอนนี้
  • วิธีการที่เรากำลังสัมผัสในตอนนี้ ต่างจากเมื่อ 6 เดือนก่อนอย่างสิ้นเชิง และก็ยังไม่เสถียรด้วย
    • มาตรฐานของวัฒนธรรมการพัฒนา เช่น การทำงานร่วมกันในทีมและการรีวิว ก็น่าจะเปลี่ยนไปมากในไม่ช้า
    • ตัวอย่างเช่น การรีวิวโค้ดที่ทำกันแบบพิธีการ กำลังไม่สามารถแก้ปัญหาจริงได้อีกต่อไป
      • ถึงเวลาที่ต้องประดิษฐ์กระบวนการรีวิวโค้ดขึ้นมาใหม่ทั้งชุด
    • IDE เองก็เช่นกัน จากเดิมที่เคยยึดกับความเป็นศูนย์รวม ตอนนี้ใกล้ถึงเวลาต้องรื้อใหม่ทั้งหมด
    • ในอุตสาหกรรมเองก็เริ่มตระหนักถึงความเปลี่ยนแปลงนี้ แต่ แนวทางที่เอาเอเจนต์เป็นศูนย์กลาง ยังเพิ่งเริ่มต้นเท่านั้น
    • ยังมีการเปลี่ยนแปลงใหญ่อีกมากรออยู่ข้างหน้า และ
      ความอยากรู้อยากเห็นกับความถ่อมตน เท่านั้นที่จะช่วยให้ผ่านการเปลี่ยนแปลงนี้ไปได้ดี
    • อันที่จริง ตอนนี้อาจเป็นเวลาที่ควรถอยห่างจากฟอรัมอินเทอร์เน็ตสายเทคโนโลยี
      และ ปล่อยให้เอเจนต์จัดการทั้งการถกเถียงและการสรุปแบบนี้แทน

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

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

 
GN⁺ 2025-06-13
ความคิดเห็นใน Hacker News

  • ผมเขียนโค้ดส่วนใหญ่เพื่อใช้กับเครื่องมือของตัวเองเท่านั้น เลยรู้สึกว่าไม่ค่อยเห็นประโยชน์มากนักจากการให้คนอื่นหรืออะไรบางอย่างที่ไม่ใช่ผมเป็นคนเขียนโค้ดแทน แล้วผมค่อยมาอ่าน ทำความเข้าใจ และแก้มันเอง แน่นอนว่าถ้าให้ LLM ไปหาเฉพาะส่วนที่ผมต้องการในเอกสาร API มันมีประโยชน์มากและช่วยประหยัดเวลาได้เยอะ ดังนั้นไม่ว่าอนาคตความสามารถของ LLM จะดีขึ้นหรือไม่ โดยพื้นฐานแล้วผมก็แค่ไม่ค่อยชอบการอ่านโค้ดของคนอื่นอยู่ดี

    • สำหรับผม LLM ก็มีกรณีที่ช่วยได้ เช่น ในโค้ดที่เป็นแบบแผนชัดเจน มันทำให้ไม่ต้องใช้แมโครหรือ code generator ได้ แม้จะช้าและอัปเดตทั้งหมดทีเดียวแบบแมโครไม่ได้ แต่กับโค้ดที่มีโครงสร้างซ้ำ ๆ และต่างกันเล็กน้อย LLM กลับมีประโยชน์กว่าแมโคร อีกทั้งเวลาใช้ API ที่คุ้นเคยแต่ไม่ได้จำรายละเอียดโค้ดได้ ผมก็ทำงานต่อได้ทันทีโดยไม่ต้องไปค้น Google หรือไล่อ่านเอกสาร และเพราะผมใช้ภาษาที่มี type ถ้า LLM พูดมั่ว typechecker หรือการทดสอบก็มักจับได้ เลยไม่ค่อยกังวลมากนัก อีกอย่าง เวลาต้องเปลี่ยนอะไรที่กระทบมากกว่า 10 ไฟล์ การให้มันเขียนแผนการแก้ไขเป็น Markdown ช่วยประหยัดเวลาได้มากจริง ๆ สุดท้าย เวลาล้าผมมักปล่อยผ่านเรื่องสไตล์หรือนโยบายการตั้งชื่อได้ง่าย แต่ LLM รักษาสไตล์เดิมของโปรเจกต์ได้ดี ซึ่งผมชอบมาก
    • ช่วงนี้ผมยิ่งชอบทำงานแบบนี้มากขึ้น คือก่อนอื่นวางแผนดีไซน์การเขียนโค้ดทั้งหมดก่อน จากนั้นอธิบายขั้นตอนที่เป็นรูปธรรมให้ LLM ฟัง แล้วระหว่างที่ผมอ่าน ทำความเข้าใจ แก้โค้ด และวางแผนขั้นถัดไป ผมก็ให้ LLM ไปทำโค้ดของส่วนถัดไปล่วงหน้า พูดอีกแบบคือผมกับ LLM ทำงานกันคนละส่วนแบบขนานกัน มันคล้ายกับเชฟในร้านอาหารที่พอมีออเดอร์เข้าก็คิดลำดับขั้นการทำอาหารทั้งชุดทันที แล้วระหว่างย่างสเต๊กก็ไม่ได้นั่งรอเฉย ๆ แต่เตรียมอย่างอื่นไปพร้อมกัน LLM จึงใกล้เคียงกับเครื่องมือในครัวอย่างเตาอบหรือ food processor มากกว่า เช่น คุณจะขูดชีสด้วยมือก็ได้ แต่ถ้าโยนเข้า food processor ก็ประหยัดเวลาไปได้หลายนาที เชฟมืออาชีพเพิ่มประสิทธิภาพด้วยการใช้เครื่องมือหลายอย่างและทำหลายงานพร้อมกัน ผมคิดว่าต่อไปการเขียนโค้ดก็อาจเปลี่ยนจากการทำทีละบรรทัดตามลำดับขั้น ไปเป็นโครงสร้างแบบ multitasking ได้
    • สำหรับคำถามว่าการผลักภาระการเขียนโค้ดของผมไปให้สิ่งอื่นทำ แล้วสุดท้ายยังต้องกลับมาอ่าน ทำความเข้าใจ และแก้เอง มันมีข้อดีอะไร ผมใช้คำว่า "แรงเสียดทาน" หลายคนเริ่มงานใหม่ได้ยากมาก ๆ (คล้าย writer's block) แต่ถ้าได้รับโซลูชันที่มีคนทำไว้ให้แล้ว การค่อย ๆ ปรับให้เป็นแบบของตัวเองและแยกเป็นโมดูล จะช่วยลดกำแพงในการเริ่มต้นได้มาก ผมและเพื่อนร่วมงานหลายคนรู้สึกว่าการตั้งโปรเจกต์จาก 0 โดยต้องจัด toolchain และ bootstrap เป็นภาระหนัก LLM ถ้ามีบริบทและทรัพยากรเพียงพอ อาจสแกน codebase ทั้งหมดอย่างรวดเร็วแล้วพบเรื่องอย่าง "ในโค้ดนี้มี audit mechanism อยู่สองที่แล้ว เราน่าจะดึงส่วนร่วมออกมา" ได้ มันอาจจับจุดที่ผมมองข้ามไปเองได้ด้วย
    • ใน codebase หนึ่งที่ผมดูแล มีงานจำนวนมากที่ต้องแก้ทีละนิดแบบซ้ำ ๆ ข้ามหลายไฟล์ งานแบบนี้ไม่ได้ต้องใช้ความคิดสร้างสรรค์หรือความท้าทายอะไร แค่เปิดหลายไฟล์แล้วแก้ซ้ำไปซ้ำมา ก่อนหน้านี้ใช้เวลา 3~4 ชั่วโมง แต่ถ้าอธิบายงานให้ AI agent ฟัง มันจัดการให้ได้เอง 99% และใช้เวลาแค่ 3~4 นาทีเท่านั้น
    • บางคนเป็นประเภทที่ทำอะไรแทบไม่ได้เลยถ้าไม่มีเครื่องมือ คนพวกนี้มักเป็น early adopter และ power user ที่ช่วยเผยแพร่สิ่งค้นพบใหม่ ๆ คุณค่าของ GitHub คือการมอบสภาพแวดล้อมที่ทำให้นักพัฒนาทั่วไปดูเหมือนทำงานได้มีประสิทธิผลผ่าน PR, รีวิว, green square, รายการ todo ฯลฯ ส่วน LLM ก็เช่นกัน มันทำให้คนทำงานทั่วไปสามารถดูเหมือนมีประสิทธิผลได้ด้วยการรันเครื่องมือและ agent ที่ไม่ได้สำคัญมากนัก ซึ่งผู้จัดการก็มักชอบ

  • ผมเห็นด้วยเต็มที่กับส่วนที่ผู้เขียนบอกว่า code review มักหละหลวมและแทบไม่ค่อยทำงานจริง ในยุคที่ agent เป็นคนเขียนโค้ด คอขวดที่แท้จริงไม่ใช่การเขียน แต่เป็นการอ่านโค้ด ถ้าคนรีวิวแบบลวก ๆ หรือใช้มันเป็นพื้นที่แสดงรสนิยมส่วนตัว agent ก็สามารถแทรกปัญหาด้านความปลอดภัยหรือประสิทธิภาพที่ร้ายแรงเข้ามาได้ง่าย ๆ พูดตรง ๆ คือปัญหาจริงมักไม่เห็นจากการอ่านโค้ดอย่างเดียว แต่ต้องดีบักเองหรือทำงานแบบ manual เพื่อตรวจสอบสมมติฐาน

    • ผมสงสัยว่าปัญหาเรื่อง "รีวิวหละหลวม" จะถูกแก้ยังไงด้วย agent/AI code เพราะคนไม่ชอบทำ code review อยู่แล้วและมองว่ามันน่าเบื่อ ผมกังวลว่าเราจะยกงานส่วนที่สนุกอย่าง "การเขียนโค้ด" ให้ AI ไป แล้วแทนที่ด้วยการต้องอ่านและตรวจโค้ดอย่างไม่รู้จบ
    • ตอนนี้สิ่งที่ขาดที่สุดในตลาดคือการอ่าน รีวิว และทำความเข้าใจโค้ด, diff และ codebase ทั้งชุดที่ LLM สร้างขึ้นมาอย่างมีประสิทธิภาพและถูกต้อง ถ้าในโปรเจกต์มีคนน้อยมาก ผมก็อดกังวลไม่ได้ว่าคนที่เหลืออยู่ได้อ่านโค้ดจริงไหม หรือแค่ปล่อยผ่านไป
    • หัวใจของ agent คือถ้ามี test coverage เพียงพอ AI ก็เขียนโค้ดและรับ feedback เรื่องความปลอดภัย/ประสิทธิภาพได้ และ AI ตัวนั้นก็ช่วยเขียนเทสต์ได้ด้วย

  • ในที่สุดก็ได้เห็นบทความที่วิเคราะห์ LLM แบบสมจริงเสียที คำว่า "agent" มันชวนหงุดหงิดนิดหน่อยเพราะโดยพื้นฐานแล้วก็เป็นแค่ชื่อที่ตั้งให้กับ for loop ที่เรียก LLM ซ้ำแบบ recursive แต่ก็ยอมรับได้เพราะวงการนี้ก็ไม่ค่อยเก่งเรื่องตั้งชื่ออยู่แล้ว

    • ผมเห็นไม่ตรงกับผู้เขียนในนิยามของคำว่า 'agent' จริง ๆ แล้วมันคือโครงสร้างที่ LLM เรียกใช้เครื่องมือและทรัพยากรแบบวนลูป (ซ้ำ ๆ) ความต่างมันละเอียดก็จริง แต่เกี่ยวกับการกำหนดว่าตัวการหลักคืออะไร
    • ผมชอบคำพูดที่ว่า "agent คือการมีเครื่องมืออยู่ในลูป" จำได้ว่า Simon เคยพูดไว้แบบนี้
    • ผมเห็นต่างจากนิยาม agent ของ OP เล็กน้อย จุดสำคัญจริง ๆ ไม่ใช่แค่ LLM วนลูป แต่คือการที่พฤติกรรมของ LLM ถูกจำกัดหรือชี้นำโดยองค์ประกอบเชิงตรรกะอื่น ๆ ซึ่งบางส่วนเป็น deterministic และบางส่วนอิง ML (รวมถึง LMM) กล่าวคือ เราอาจได้ประโยชน์เพิ่มจากระบบที่ออกแบบมาให้บังคับให้ LLM วางแผนในบางรูปแบบ หรือกระตุ้นการ build และรันเทสต์หลังแก้โค้ดเสร็จ เป็นต้น คำอธิบายว่า "agent เคลื่อนไหวด้วยตัวเองจากอินพุต" ไม่ถึงกับผิด แต่สิ่งที่เป็นแก่นมากกว่าคือความตั้งใจที่จะให้หลายองค์ประกอบคอยกำกับและนำทางพฤติกรรมของ LLM อยู่ตลอด
    • ชื่อ "Agent" ผมว่าโอเคเพราะคนเข้าใจได้ตรงสัญชาตญาณดี แต่ถ้าจะหาชื่อทางเลือก ก็เคยนึกเหมือนกันว่า LoopGPT จะเป็นยังไง

  • ตรงส่วนที่บอกว่า "เราต่างเห็นตรงกันว่าคอนเทนเนอร์มีประโยชน์และจำเป็นต่อการเขียนโปรแกรม" มีคำอธิบายว่าทำไม Solomon Hykes ผู้สร้าง Docker ถึงเพิ่งเปิดซอร์สโปรเจกต์ Container Use นั่นคือเพื่อให้ agent รันแบบขนานกันได้อย่างปลอดภัย บางแพลตฟอร์มอย่าง Sketch มี local development environment แบบแยกส่วนในตัว แต่ agent สำหรับการเขียนโค้ดตัวอื่นยังไม่มี และขอแนะนำ วิดีโอ YouTube เป็นข้อมูลเพิ่มเติมด้วย

  • agentic loop, สมองในเครื่องจักร, โดยพื้นฐานดูเหมือนตัวแทนของ rules engine แม้ยังมีข้อเสียเฉพาะตัวอยู่ แต่ผมคิดว่าหลายคนเก่ง ๆ จับแก่นได้ถูกแล้ว คือ "เอาเครื่องมือของ agent มาเชื่อมกัน พรอมป์ตามคำขอของผู้ใช้ แล้วปล่อยให้รันและวนซ้ำไปเรื่อย ๆ โดยตัวพรอมป์เองก็เปลี่ยนแบบไดนามิกตามสถานการณ์" ต่อให้ไม่พยายามเลียนแบบปฏิสัมพันธ์หรือวิธีแก้ปัญหาแบบมนุษย์ มันก็มีประโยชน์มากพอสำหรับงาน orchestration/multistage และการแทนที่หรือทำให้งานคลุมเครือเป็นอัตโนมัติ แต่ก่อนเราต้องเขียนโค้ดเพื่อจัดการความคลุมเครือเอง ตอนนี้มันอาจหายไปได้ แม้ใน production จะยังน่ากังวลเรื่องการรันโดยไม่มี dry run แต่ผมคิดว่าตัวเครื่องมือและบริการเองก็คงจะพัฒนาไป ถ้ามีบริการคล้าย ๆ กันเกิน 100 ตัวที่เชื่อมกับโลกภายนอกผ่านอินเทอร์เฟซที่สอดคล้องกัน (เช่น SMS, เมล, อากาศ, โซเชียล ฯลฯ) เราน่าจะได้ผู้ช่วยที่ทรงพลังกว่าตอนนี้มาก หรืออาจเกินกว่านั้น

    • มี toy project ที่น่าสนใจซึ่งเชื่อม agent เข้ากับบริการหลายอย่าง เช่น ปฏิทินและสภาพอากาศ แล้วทำเป็นอินเทอร์เฟซแบบเกม ลิงก์
    • ถ้าการ abstraction ของเครื่องมือทั้งหมดที่ใช้ถูกทำให้เป็นแบบเดียวกัน มันอาจเหนือกว่าผู้ช่วยแบบเดิมมาก แต่ในความเป็นจริงเราก็ต้องยอมรับความเป็นไปได้ของความล้มเหลวและความผิดพลาดมหาศาลด้วย ประเด็นอย่าง reliability engineering, quality assurance, การจัดการสิทธิ์, ความปลอดภัย, ความเป็นส่วนตัว จะยิ่งสำคัญขึ้นเรื่อย ๆ ผมเดาว่าเหตุผลที่ Apple ยังไม่ปล่อย voice assistant รุ่นใหม่ที่ก้าวข้ามข้อจำกัดของ Siri ก็อาจเป็นเพราะการจัดการความเสี่ยงพวกนี้นี่เอง

  • การอ่านโค้ดสำคัญพอ ๆ กับการเขียนมาตลอด แต่ตอนนี้มันยิ่งสำคัญขึ้นเรื่อย ๆ นี่คือฝันร้ายของผม การเขียนโค้ดบางครั้งยังสนุกได้ แต่การอ่านโค้ดเป็นงานใช้แรงเสมอ

    • ถึงอย่างนั้น "ความสนุกของการแก้" อาจยังอยู่ต่อ หรืออาจมากขึ้นด้วยซ้ำ

  • ผมสงสัยว่าคนที่ใช้ agent มีสักกี่คนที่ชอบ "การเขียนโปรแกรม" จริง ๆ หมายถึงชอบการคิดวิธีแก้ปัญหาและความสนุกจากการถ่ายทอดมันออกมาเป็นโค้ด เพราะงานแบบ agent หลายอย่างที่เห็นทุกวันนี้เหมือนกระบวนการนั้นหายไป กลายเป็นแค่อธิบายความต้องการด้วยภาษาธรรมชาติแล้วหวังว่า LLM จะไม่สร้างบั๊ก

    • ผมเป็นคนที่ชอบการเขียนโค้ดอยู่แล้ว และตอนที่ LLM สร้าง parser ที่น่าจะเป็นงานสนุกสำหรับผมออกมาทีเดียวเสร็จ ผมก็แอบรู้สึกโล่งโหวงเหมือนกัน ถึงอย่างนั้นมันก็ทำให้ผมไปโฟกัสกับเป้าหมายที่ใหญ่กว่าได้แทนที่จะหมดเวลาไปกับการเขียน parser สิ่งที่น่าประทับใจคือแค่ผมวาง type/function signature ที่ต้องการไว้ แล้วให้ LLM เติมรายละเอียดการใช้งานต่อ ผมก็ไปขั้นถัดไปได้ทันที เมื่อก่อนการแก้ทั้งระบบในระดับ "ถ้าแก้ได้ก็ดี แต่ขี้เกียจเกินไป" เป็นภาระใหญ่มาก แต่ตอนนี้ LLM ช่วยทั้งขัดโค้ด สร้างเทสต์ ซิงก์ README และเสนอไอเดียรีแฟกเตอร์ ทำให้ทั้งความสมบูรณ์และความทะเยอทะยานของโปรเจกต์สูงขึ้น ถ้าปรับวิธีคิดให้ดี สำหรับคนสร้างซอฟต์แวร์ที่สนุกกับการลงมือทำ มันแทบจะเป็นสวรรค์เลย
    • ในทางกลับกัน สำหรับปัญหาที่ถูกทำซ้ำมาแล้วนับพันครั้ง ผมไม่ได้อยากลงมือเขียนเองนัก เวลาแบบนั้นผมใช้ dictionary ได้ก็ใช้ ไม่ได้จะมาสร้าง hash table ใหม่ ถ้าคุณบอกว่า "ช่วยทำคอมไพเลอร์ของภาษานี้" หรือ "ลองแก้ด้วย DFS" แล้วได้คำตอบที่สมบูรณ์กลับมา ผมก็ไม่ได้คิดว่าความสนุกของการเขียนโปรแกรมจะลดลงเสมอไป การอธิบายกระบวนการคำนวณด้วยภาษาธรรมชาติมันก็มีข้อจำกัดอยู่ เพราะพอซับซ้อนขึ้นมันคลาดเคลื่อนหรือก่อความขัดแย้งได้ง่าย แต่ไม่ว่ามองทางไหน ตอนนี้ก็ไม่มีใครแนะนำให้ใช้ LLM แบบไม่คิดอะไรอยู่แล้ว และสุดท้ายผมก็ยังต้องรับผิดชอบผลลัพธ์เอง
    • อ้างถึงเอกสาร EWD667 เป็นเหตุผลว่าทำไมภาษาธรรมชาติจึงไม่เหมาะกับการเขียนโปรแกรม ในทางปฏิบัติ LLM มีประโยชน์กับคำถาม-คำตอบสไตล์ stackoverflow แต่ถ้าในอนาคตข้อมูลของ SO ลดลง แม้แต่เรื่องนั้นก็คงมีข้อจำกัดตามมา
    • สำหรับผมไม่เห็นด้วย สิ่งที่ LLM ทำส่วนใหญ่เป็นงาน implementation ที่ซ้ำซากและน่าเบื่อ ผมยังคงเก็บส่วนที่สนุกไว้ เช่น สถาปัตยกรรมของโปรเจกต์ หรือการออกแบบส่วนที่สร้างสรรค์และยากจนแม้แต่ LLM ก็ยังลำบาก อีก 1 ปีข้างหน้าอาจเป็นอีกเรื่อง แต่ในระยะนี้ผมพอใจที่ได้โฟกัสเฉพาะส่วนที่ต้องใช้ความคิดจริง ๆ
    • ผู้เขียนตัวจริงมาเอง ผมชอบทั้งการเขียนโปรแกรม และชอบทั้ง agent ด้วย

  • มีบางด้านที่ผมชอบใช้ AI เวลาทำโค้ด (นี่คือสิ่งที่ผมเขียนเองจริง ๆ!):

    • CSS: ผมเกลียดงาน CSS ในเว็บทุกประเภท แต่ AI จำลูกเล่น CSS ซับซ้อนได้หมด เลยช่วยย่นเวลาได้มาก เช่น การจัด div ให้อยู่กลางใน WordPress ที่ซับซ้อน ก็ทำได้เร็วหลังลองผิดลองถูกไม่กี่ครั้ง
    • unit test: ถ้าข้อมูลโค้ดที่ AI ฝังมาไม่ได้เก่าเกินไป การสร้างเทสต์ก็เป็นประสบการณ์ที่สนุกดี
    • สรุป commit: อย่างน้อยฉบับร่างแรกก็ใช้ได้ดีพอ
    • งานเล็กมาก ๆ ระดับปี 1 ก็จัดการได้เร็ว
    • น่าสนใจที่ในมุมผม AI ดูเขียน CSS ไม่ค่อยเก่ง เลยเคยรู้สึกว่าไม่ค่อยมีประโยชน์ แต่ผมเห็นด้วยเต็มที่ว่าการให้มันทำงานที่เราไม่ชอบนั้นมีคุณค่า สำหรับผม ตัวอย่างคือการเขียนคำอธิบาย ticket ซึ่ง AI ทำได้ดีกว่าผมมาก
    • ถ้าผมเข้าใจผิดก็ขอโทษด้วย แต่ถ้าคุณยังไม่คุ้นกับเทรนด์ CSS สมัยใหม่ ผมแนะนำให้ลองใช้เวลาสักไม่กี่ชั่วโมงอัปเดตมันดู เพราะ CSS ทุกวันนี้ซับซ้อนน้อยลงและจัดการง่ายขึ้นกว่าสมัยก่อนมาก ถึงอย่างนั้นตัวผมเองก็ยังใช้ AI กับงานสไตลิงเยอะเหมือนกัน

  • ส่วนที่พูดถึง "สินทรัพย์" และ "หนี้" น่าสนใจ แต่ผมไม่เห็นด้วย หลายโปรแกรมเริ่มจากมีผู้ใช้ไม่กี่คนแล้วค่อย ๆ โตเป็นโปรเจกต์ใหญ่ก็มีอยู่บ่อยมาก ในอดีตผมเจอบ่อยเกินไปกับโค้ดวิทยาศาสตร์ที่เขียนแบบหยาบ ๆ ใช้ครั้งเดียว แต่สุดท้ายกลับขยายตัวโดยไม่ตั้งใจอยู่ได้นานและกว้างไกลกว่าที่คิด เพราะงั้นผมเลยเขียนโค้ดโดยคิดเผื่ออายุการใช้งานที่ยาวขึ้นและขอบเขตที่กว้างขึ้นมาก รวมถึงคำนึงถึงตัวเองและคนอื่นด้วย ถ้าคุณเคยมีประสบการณ์ที่ side project ส่วนตัวของเพื่อนร่วมงานถูกผู้จัดการยกระดับให้เป็นโปรเจกต์ของทีม คุณคงเข้าใจปัญหานี้ดี

    • ถึงอย่างนั้นก็ยังมีคำถามว่า "แล้วทางเลือกคืออะไร?" คนเรามักทำนายไม่เก่งว่าอะไรจะถูกใช้อย่างแพร่หลาย จริง ๆ แล้วโปรเจกต์ที่ตั้งใจทำอย่างดีแต่ไม่มีใครใช้เลยมีให้เห็นบ่อยกว่า ส่วนโปรเจกต์ที่หลวม ๆ แต่ทำเร็วแล้วประสบความสำเร็จนั้นเหมือนถูกแรงคัดเลือกผลักดันไว้ ความคิดนี้โยงไปถึงบทความคลาสสิก "worse is better" ได้ (ลิงก์)

  • ผมคิดว่าการใช้ LLM ไม่ใช่เพื่อเขียน/ออกแบบโค้ด แต่เพื่อ code review ต่างหากที่อาจเป็น killer feature ที่แท้จริง ตอนนี้ code review เองก็พังอยู่หลายจุด และต่อไป LLM น่าจะมีบทบาทมากขึ้นในการตรวจเรื่องความปลอดภัย, undefined behavior, การใช้ฟีเจอร์ผิด, หรือการตรวจซ้ำประเด็น compiler warning โดยส่วนตัวผมใช้ LLM เป็นหลักในสไตล์ search engine เพื่อวินิจฉัยข้อผิดพลาดหรือดีบัก ซึ่งอัตราถูกต้องราว 50% และผมก็พอใจกับระดับนี้

    • ถ้าเป็นปัญหาที่ถูกพูดถึงบนเว็บเยอะอยู่แล้ว ChatGPT เก่งเรื่องดีบักมาก เพราะมันสรุปและผสานความรู้จาก stack overflow ทำให้ประหยัดเวลาจากการไปไล่หากรณีทีละอันได้มาก แต่คำตอบของ LLM ยังมีเรื่องแต่งปนอยู่บ้างเลยยังมี noise อยู่ ถ้าให้มันรีวิวทั้งโค้ด มันอาจหา pattern ของข้อผิดพลาดหรือฟังก์ชัน/การเรียกใช้ที่มีปัญหาได้ดี แต่ในทางกลับกันมันก็เลี่ยง false positive ไม่ได้ ผมเลยสงสัยว่ามีใครใช้งาน LLM กับการรีวิวโค้ดอัตโนมัติอย่างเหมาะสมจริง ๆ ไหม
    • ถ้าคุณขอว่า "ช่วยรีวิวโค้ดนี้หน่อย" ซ้ำ ๆ ไปเรื่อย ๆ บางครั้ง chatbot จะบอกให้เปลี่ยน X เป็น Y แล้วอีกสักพักก็บอกให้เปลี่ยน Y กลับเป็น X อีก มันช่วยเรื่อง code review ได้ในระดับหนึ่ง แต่สุดท้ายคุณก็ยังต้องตัดสินใจเองว่าจะรับหรือปฏิเสธข้อเสนอไหน สำหรับคนที่มีวิจารณญาณเพียงพอ มันมีประโยชน์มากในฐานะตัวช่วยเสนอรายการแก้ไขที่เป็นไปได้เพื่อเพิ่มผลิตภาพ
    • ผมสงสัยว่าทำไมเรื่องนี้ถึงไม่ถูกพูดถึงมากกว่านี้ นักพัฒนารอบตัวผมสนใจเทคโนโลยีไม่เท่ากัน โดยมากยิ่งประสบการณ์น้อยยิ่งใช้กันอย่างกระตือรือร้น ส่วน senior มักสนใจน้อยกว่า ผมแทบไม่เคยได้ยินใครพูดถึงการใช้ AI กับ code review/verification เลย อาจเพราะมันควรเป็นฟีเจอร์ที่ทำอัตโนมัติตั้งแต่ตอน commit
    • LLM ที่เน้นเฉพาะ code review โดยเฉพาะนั้นมีให้ใช้ใน GitHub Copilot แล้วในโหมด reviewer แม้ยังไม่ใช่ระดับท็อปสุด แต่คุณภาพก็ดีพอจะเอาเข้าไปอยู่ในลูปการทำงานได้
    • เห็นด้วย เรากำลังทำเรื่องนี้อยู่ที่ sourcery.ai