วิธีเขียนโค้ดด้วย AI แบบ “สายจูงสั้น” ที่เอาชนะ Fable

 (blog.okturtles.org)
1 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หากต้องการใช้เอเจนต์เขียนโค้ด AI ในซอฟต์แวร์ที่ความปลอดภัยสำคัญ จำเป็นต้องใช้แนวทาง Short Leash ที่นักพัฒนายังคงควบคุมการเปลี่ยนแปลงอย่างต่อเนื่อง แทนที่จะปล่อยให้ทำงานเองโดยอัตโนมัติ
  • แนวทางแบบ “vibe” ที่ให้เอเจนต์หลายตัวสร้างและรีวิวโค้ดแบบขนาน อาจทำให้ความเข้าใจใน codebase อ่อนลง และทำให้พบปัญหาก็ต่อเมื่อ AI อยู่ในสถานะ off the rails ไปแล้ว
  • ขั้นตอนหลักประกอบด้วยการวางแผน การแตกงานเป็นขั้นย่อย การ รีวิว diff ในพรอมป์ต์ขอสิทธิ์ การปฏิเสธและแทรกแซงบ่อย ๆ การคอมมิตตามงานย่อย และการรีวิวขั้นสุดท้าย
  • ในการรีวิว PR ควรใช้ทั้ง AI และมนุษย์ร่วมกันจึงจะลดข้อผิดพลาดได้ โดย AI จับข้อผิดพลาดทั่วไปได้รวดเร็ว ส่วนมนุษย์ตัดสินปัญหาและทิศทางในระดับที่สูงกว่า
  • PR ที่ AI มีส่วนร่วมในการเขียน ผู้ส่งต้องตรวจทานทีละบรรทัดด้วยตนเอง และระบุโมเดลที่ใช้ไว้ในคำอธิบาย PR เป็น AI Disclosure เพื่อสร้างความเชื่อถือ

ข้อกำหนดเบื้องต้นสำหรับการใช้เอเจนต์เขียนโค้ด AI

  • วิธีนี้อิงจากประสบการณ์การใช้เอเจนต์ AI เพื่อสร้างซอฟต์แวร์คุณภาพสูงใน ระบบที่ความปลอดภัยสำคัญ
  • กลุ่มเป้าหมายไม่ใช่นักพัฒนามือใหม่ที่ควรมอง AI ว่าเป็นศัตรูของการเรียนรู้ แต่เป็น นักพัฒนามืออาชีพ ที่เก่งกว่า “frontier AI models” ในสาขาความเชี่ยวชาญของตนเอง
  • เป้าหมายคือใช้ AI เป็นเครื่องมือเพิ่มประสิทธิภาพ โดย ไม่แลกกับคุณภาพ ของซอฟต์แวร์
  • ขอบเขตของประสบการณ์รวมถึงการสำรวจข้อจำกัดของเอเจนต์ AI การสร้างเครื่องมือรีวิว AI ของตนเอง และการดูแล คัสตอมฟอร์ก ของ Crush ซึ่งเป็นเอเจนต์เขียนโค้ด AI

จุดที่แนวทางแบบ “vibe” เริ่มสั่นคลอน

  • ในเซสชันที่ใช้เอเจนต์ AI มักเกิดปัญหาสองอย่างได้บ่อย
    • ไอเดียตั้งต้นไม่ดี และเพิ่งพบภายหลังว่ามีแนวทางที่ดีกว่า
    • เอเจนต์เข้าสู่สถานะ off the rails ไปในทิศทางที่ไม่ต้องการ
  • หากมีเอเจนต์ขนานหลายตัวและออร์เคสเตรเตอร์ทำงานพร้อมกัน ขณะที่นักพัฒนาถอยออกจากกระบวนการเขียนโค้ด ก็ยากที่จะสร้างความเข้าใจใน codebase ด้วยตนเอง
  • ในสถานการณ์ที่ไม่ใส่ใจคุณภาพ วิธีนี้อาจใช้ได้ แต่เมื่อ คุณภาพเป็นเรื่องสำคัญ จำเป็นต้องใช้แนวทางอื่น
  • โค้ดที่ Fable 5 เขียนหรือรีวิว แม้จะทำงานได้ ก็อาจไม่มีประสิทธิภาพและดูไม่น่าอ่าน
  • ปัญหาแบบนี้อาจเกิดบ่อยขึ้นใน สาขาเฉพาะทาง ที่มีข้อมูลฝึกให้โมเดลพึ่งพาได้น้อย
  • ตรงข้ามกับการตลาดของ CEO บางราย ในมุมมองนี้ โมเดลไม่สามารถคิดเกินกว่าข้อมูลฝึกของมันได้

วิธีทำงานของแนวทาง Short Leash

  • แนวทาง Short Leash ไม่ใช่วิธีที่ใครก็ใช้ได้ แต่เหมาะกับ นักพัฒนาซอฟต์แวร์มืออาชีพ
  • ข้อดีคือสามารถสร้างผลลัพธ์ที่เอาชนะ Fable ได้ แม้ไม่ใช้ frontier model
  • ก่อนลงมือทำงาน จะมีขั้นวางแผนเพื่อค้นคว้าโจทย์และจัดทำแผน
    • งานใหญ่จะแบ่งเป็นขั้นตอนและติดตามความคืบหน้าด้วยเครื่องมืออย่าง tasks skill
    • ส่วนนี้มีความคล้ายกับแนวทาง “vibe engineering” หลายแบบ
  • แกนหลักหลังจากนั้นคือการผูก AI ไว้กับ สายจูงสั้น ตลอดเวลา
    • ไม่ใช้โหมด “YOLO” หรือ “dangerously skip permissions”
    • ไม่ปล่อยให้ AI ทำงานคนเดียวขณะที่ผู้ใช้ไปเล่นเกม
    • ใช้เอเจนต์เขียนโค้ดที่แสดง diff ของการเปลี่ยนแปลงที่จะถูกนำไปใช้ในพรอมป์ต์ขอสิทธิ์
    • นักพัฒนาวิเคราะห์การเปลี่ยนแปลงที่ AI เสนออย่างจริงจัง
    • ใช้ diff ในพรอมป์ต์ขอสิทธิ์เพื่อรักษาความเข้าใจใน codebase ให้เป็นปัจจุบันและควบคุม AI
    • หาก AI พยายามทำสิ่งที่ไม่ต้องการ ให้ปฏิเสธสิทธิ์
    • แทรกแซงบ่อยเท่าที่จำเป็นเพื่อไม่ให้ AI หลงทิศ
  • เมื่อจบงานย่อยแต่ละงาน ให้สร้างคอมมิตไว้ เพื่อป้องกันไม่ให้ AI ทำให้งานก่อนหน้าเสียหายหรือลบหาย
    • เรื่องแบบนี้เกิดขึ้นได้จริง และเคยเห็นกรณีใน Opus
  • ขั้นตอนสุดท้ายคือการรีวิว

การรีวิวด้วย AI ไม่ได้แทนที่การรีวิวโดยมนุษย์

  • เมื่อเทียบกับ PR ที่รีวิวโดยมนุษย์เท่านั้นหรือ AI เท่านั้น PR ที่มีทั้งมนุษย์และ AI ร่วมรีวิว สามารถลดข้อผิดพลาดได้มากกว่า
  • AI สามารถ扱ได้เหมือนลินเตอร์
    • จับข้อผิดพลาดทั่วไปได้อย่างรวดเร็ว
    • มนุษย์ตัดสินปัญหาระดับสูงกว่าและความจำเป็นในการเปลี่ยนทิศทาง
  • แนะนำให้ PR ทุกอันผ่านการรีวิวด้วย AI
  • การรีวิวด้วย AI ต้องมี บริบท เพียงพอ
    • issue
    • คำอธิบาย PR
    • codebase
    • รายการเปลี่ยนแปลง
  • แนะนำให้ใช้โมเดลล่าสุดที่ใช้งานได้สำหรับการรีวิว

AI Disclosure และความรับผิดชอบของผู้ส่ง

  • หากมีการใช้ AI ในการเขียน PR ต้องเปิดเผยโมเดลที่ใช้จริงในส่วน AI Disclosure ของคำอธิบาย PR
  • การเปิดเผยนี้มีหลายวัตถุประสงค์
    • แจ้งผู้ดูแลว่ามีการใช้ AI
    • หากใช้โมเดลที่อ่อนกว่า จะได้เสนอโมเดลที่ดีกว่าได้
    • ส่งสัญญาณว่าไม่ได้พยายามแอบนำ AI เข้ามา
  • PR ที่ใช้ AI ต้องให้ “ผู้เขียน” PR รีวิวด้วยตนเองเสมอ
  • PR ที่มี AI ช่วย ในทางปฏิบัติใกล้เคียงกับ PR ของ AI ที่มีมนุษย์ช่วย ดังนั้นผู้ส่งต้องเข้าใจสิ่งที่ตนส่ง
  • ผู้ส่งต้องมอง PR ของตนเหมือน PR ของคนอื่น และรีวิวด้วยตนเองแบบ line-by-line
  • หลังจากรีวิวตัวเองเสร็จแล้ว จึงยืนยันการอนุมัติของตนและขอให้ผู้ดูแลตรวจทานได้
  • กระบวนการนี้ช่วยทำให้เกิดและแสดงให้เห็นว่าผู้ส่งเข้าใจ codebase

วิธีที่ okTurtles นำไปใช้

  • okTurtles ใช้ AI ด้วยแนวทางนี้
  • นโยบายอย่างเป็นทางการสรุปไว้ใน AI Usage Policy
  • ตัวบทความเขียนโดยมนุษย์ และมี AI Disclosure ว่าก่อนเผยแพร่ใช้ AI เพียงเพื่อ ตรวจสะกด ตามสไตล์เท่านั้น

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

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

 
GN⁺ 5 시간 전
ความคิดเห็นจาก Hacker News

  • วิธี “สายจูงสั้น” นี้ดูเหมือนไม้ค้ำมากกว่าเครื่องมือช่วย และเหมือนเป็นสัญญาณว่าตั้งแต่แรกไม่ได้อธิบายปัญหาให้ AI เข้าใจเพียงพอ หรือไม่ได้ตรวจทานและทำซ้ำกับผลลัพธ์
    การจูงมือโมเดลเก่ง ๆ อย่าง Fable ไปในขั้นตอน implement เป็นการเสียเวลาและเสียของ Fable ด้วย โมเดลที่เก่งยิ่งทำให้คุยเรื่อง design ที่ละเอียดอ่อนมากขึ้นได้ และเขียนโค้ดได้ดีกว่าเมื่อก่อนมาก กระบวนการคุยกันเรื่อง design กับ implementation, ตั้งคำถามกับส่วนที่ดูแปลก ๆ, และอ่านคำตอบของ AI จริง ๆ นั้นช่วยให้เจอทางแก้ที่ดีกว่า
    ครั้งหนึ่งเคยพยายามทำวิธีแก้แบบ greedy algorithm แต่ระหว่างคุยกับ Opus ได้รับข้อเสนอว่าสามารถใช้ ไลบรารี MILP ที่มีอยู่เพื่อแก้ปัญหาได้อย่างแม่นยำ ทั้งที่ไม่เคยได้ยิน MILP มาก่อน แต่ implementation สุดท้ายกลับดีและเรียบง่ายกว่าตอนทำเอง

    • แม้จะบอกว่าคุยกับโมเดลเก่ง ๆ ได้ละเอียดอ่อนขึ้น แต่พอถาม Claude ว่าทำไมถึงเปลี่ยนแปลงเล็ก ๆ บางอย่างที่ผมไม่เข้าใจ มันตอบว่า “ให้เหตุผลจาก first principles” ตาม code path
      แต่โค้ดกลับไม่ทำงาน และพอให้มันอธิบายขั้นตอนการให้เหตุผลจาก first principles นั้น มันก็ตอบว่าจริง ๆ แล้วแค่แต่งขึ้นมาเอง ดังนั้นผมจึงเชื่อคำว่าการคุยอย่างละเอียดอ่อนกับโมเดลได้ยาก
    • เห็นด้วยโดยรวม
      ถ้าลงทุนกับขั้นตอนวางแผนมากพอ และ architecture กับ convention เดิมของโปรเจกต์แข็งแรงพอ อาจไม่จำเป็นต้องกำกับดูแลในขั้นตอน implement มากเท่าที่บทความนี้พูด
      เรื่องที่ว่า “ไอเดียตั้งต้นโง่ และอาจพบว่ามีวิธีที่ดีกว่า” ปกติจะพบในระดับสูงระหว่าง ขั้นตอนวางแผนและ architecture
      ปัญหาที่ agent “หลุดราง” ไปในทิศทางที่ไม่ต้องการก็ไม่ได้แย่เหมือนเมื่อก่อนแล้ว และการเปลี่ยนแปลงที่มีผลกระทบควรมี test coverage ขั้นต่ำ อย่างน้อยแม้ test นั้นจะแค่ “ตรึง” พฤติกรรมที่ implement ไว้ก็ตาม การคุยรีวิวสุดท้ายเป็นโอกาสที่ดีในการตรวจอะไรที่มากกว่าสิ่งที่รีวิวหรือ agent รีวิวแบบ adversarial หาเจอ
    • ค่อนข้างสับสนว่าคัดค้านตรงไหนกันแน่ การอ่านคำตอบของ AI กับการรีวิวโค้ดก็ดูเป็นวิธีเดียวกันในท้ายที่สุด
      ตัวอย่าง MILP ไม่ใช่สิ่งที่ approach นี้จะขัดขวาง และน่าจะโผล่มาใน ขั้นตอนวางแผน
      สุดท้ายรายละเอียดก็สำคัญ และการเขียน prompt เริ่มงานก็มีผล ถึงอย่างนั้น การตรวจผลลัพธ์ การมีส่วนร่วมกับสิ่งที่โมเดลทำ และการซักไซ้ว่าทำไมจะสร้างแบบนั้น ก็ยังจำเป็นอยู่ดี
    • บทความให้ความรู้สึกเหมือน micromanage AI ถ้าคิดว่ามันเป็นพนักงาน junior การ micromanage ทำให้เขาทำงานที่ต้องการในแบบที่ต้องการได้จริง
      แต่ไอเดียของพนักงานคนนั้นจะไม่ถูกนำขึ้นโต๊ะ และ contribution ที่อาจเป็นประโยชน์ต่อทีมโดยรวมในระยะยาวก็จะหายไปด้วย
    • ผมใช้อยู่แบบนี้
      มันช่วยให้เข้าใจทุกอย่างที่ถูกสร้างขึ้น และรักษา working knowledge ของ codebase ไว้ได้ตลอด ยังสั่งให้เปลี่ยนทิศทางได้ง่ายด้วย

  • ผมทำแบบนี้กับ side project อยู่ 2 สัปดาห์ แต่สุดท้ายกลายเป็นไม่มี mental model ของ codebase
    ยิ่งมั่นใจมากขึ้นว่าไม่มีทางสร้าง model นั้นได้ถ้าไม่ได้ลงมือสร้างเอง

    • น่าเสียดายที่ก่อนยุค AI ก็เจอปัญหาเดียวกัน
      เพราะ forgetting curve ทำให้ mental model ของผมอยู่ได้ไม่นานเท่าช่วงที่สร้างมันขึ้นมาตอนแรก ยังหาวิธีสร้างมันขึ้นมาใหม่ไม่ได้
    • ถ้าเป็นผู้จัดการของโปรเจกต์ใหญ่ ๆ เขาจะสร้าง model อย่างไร? หมายถึงสถานการณ์ที่ตามหน้าที่ต้องเข้าใจโปรเจกต์ทั้งหมด แต่จริง ๆ แล้วไม่จำเป็นต้องเขียนหรือรีวิวโค้ดมากนัก
    • ขอให้โมเดลอธิบายโค้ดให้ก็ได้
    • ไม่แน่ใจนัก ผมคิดว่าทำได้ แต่ต้องตั้งใจขุดลงไปในส่วนที่ไม่เข้าใจ และนั่นคือแนวทาง
      อย่างไรก็ดี ผมเห็นด้วยว่า “ความสามารถที่จะสร้างได้ด้วยตัวเอง” ไม่ได้สะสมขึ้นมาเหมือนตอนเขียนเอง
      เช่น ผมรู้ว่าถ้าต้องการ effect บางอย่าง ต้องเปลี่ยนอะไร และเมื่อเปลี่ยนจริงก็ได้ผลลัพธ์ตามคาด จึงรู้ว่า mental model ของผมทำงานอยู่ แต่ถ้าให้สร้างสิ่งคล้ายกันตั้งแต่ศูนย์เอง คงทำไม่ได้ รู้สึกเหมือน approach นั้นอยู่นอกระยะมือเอื้อม อธิบายยาก
    • การรีวิวโค้ดเหมาะกับผมดี

  • ผมนึกว่าคนที่เขียนโค้ดเป็นจริง ๆ เวลาใช้ AI กับงานสำคัญก็ใช้กันแบบนี้หมด
    ผมเข้าใจผิดเหรอ? เดี๋ยวนี้ทุกคนแค่รันใน โหมด YOLO กันหรือเปล่า?

    • ใช่ ผมเตรียมแล็ปท็อปเครื่องหนึ่งที่ไม่ห่วงอะไรไว้ แล้วปล่อยให้ Claude แตะต้องอะไรก็ได้ใน WSL
      เป็นความสนุกของช่วง funemployment ถ้ากลับไปทำงานอีกครั้งคงเป็นการเปลี่ยนแปลงที่น่าสนใจทีเดียว
      ตอนนี้ก็แค่ปล่อยให้มันรันไว้ ดื่มเบียร์ไปด้วย สักชั่วโมงหนึ่งก็คอย critique ทิศทางใหญ่ ๆ และตั้ง feedback loop แบบ self-check/closed-loop ใหม่ แล้วก็ปล่อยให้มันทำเองต่อ ง่าย ๆ แบบนั้น
    • ที่ว่า “โหมด YOLO” หรือ “ข้าม permission แบบเสี่ยง ๆ” นี่หมายถึงการบอกว่าไม่ควรใช้แบบนี้หรือเปล่า?
      อยากรู้ว่าใช้ Claude แบบอื่นนอกจาก bypass-permissions กันอย่างไร ผมเคยจัดการรายการเครื่องมือที่ Claude ใช้ได้อยู่นาน แต่สุดท้ายพอกลับมาดูทีไร มันมักค้างอยู่เพราะพยายาม pipe output ของเครื่องมือหนึ่งไปอีกเครื่องมือหนึ่ง แล้วบอกว่าไม่ได้รับอนุญาตอย่างชัดเจน ทั้งที่เป็นแค่งานประมาณ grep ก็ยังค้าง น่าหงุดหงิด
      ใน bypass-permissions มัน “แค่ทำงานได้” แน่นอนว่าผมใช้เฉพาะกับการวิเคราะห์โค้ดเดิมและเสนอการเปลี่ยนแปลง และถ้ามีอะไรพัง นั่นก็เป็นเหตุผลที่เรามี version control

  • เห็นด้วยกับผู้เขียนโดยรวม และเหนือสิ่งอื่นใดอยากเสริมว่า อย่าเชื่อสิ่งใดก็ตามที่ LLM ทำหรือพูด
    วันนี้ผมให้ Claude ทำให้พฤติกรรมของ component 3 ตัวสอดคล้องกัน และสั่งไป 5 ครั้ง ทุกครั้งพอถึงท้ายสุดก็ยังมีส่วนที่ไม่ตรงกันอยู่ และ Claude ก็หาวิธี rationalize มันได้
    พอถาม มันตอบว่า “เป็นความรับผิดชอบของผม” หรือ “ผมคิดว่าเป็นการตัดสินใจโดยตั้งใจ” แต่ไม่เคยถามก่อนเลยว่าควรทำอะไร หรือบอกว่ามีปัญหา ดังนั้นต้องจับสายจูงให้สั้น ดูกระบวนการคิด และแก้การทำอะไรมั่ว ๆ ทันที นี่อ้างอิงจาก Sonnet 5 วันนี้ และพรุ่งนี้อาจดีขึ้นหรือแย่ลงก็ได้ วิธีพูดที่ใช้ได้กับ Claude วันนี้ พรุ่งนี้อาจให้ผลลัพธ์อีกแบบ

  • ปัญหาของบทความแนว “วิธีทำ X ด้วย AI” คือแต่ละสถานการณ์แตกต่างกันหมด ตัวอย่างเช่น งานอัปเกรดโปรเจกต์ Symfony จาก 3.1 เป็น 8.1 มีเส้นทางที่ชัดเจน
    แค่ทำตามคู่มือ migration ที่เขียนไว้สำหรับแต่ละเมเจอร์เวอร์ชัน แล้วทดสอบ route ทั้งหมด รวมถึง flow การยืนยันตัวตน เป็นต้น การทดสอบพวกนี้ก็เลือกเองได้ บางอันอาจคืนค่า 200 บางอันอาจคืนค่า 302
    จะเลือกเขียน safety net ไว้ก่อนเพื่อลดการทดสอบด้วยมือ และตั้งอย่างเช่น PHPStan baseline ไว้ก็ได้
    ถ้า route ทำงานแบบ end-to-end ได้ตรงตามที่ตั้งใจ ก็จบแล้ว ในกรณีนี้ใช้ snapshot test ได้ด้วย
    กรณีแบบนี้ไม่จำเป็นต้องคอยเฝ้า AI อาจรีวิวโค้ดตอนท้ายได้ แต่ไม่จำเป็นต้องอนุมัติด้วยมือระหว่างทางเป็นระยะ ๆ เลยปิดฟีเจอร์ความปลอดภัยไว้

    • นี่น่าจะใกล้เคียงกับวิธีรับคอนเทนต์บนอินเทอร์เน็ตมากกว่าจะเป็นปัญหาของ “วิธีทำ X ด้วย AI”
      ส่วนใหญ่คนเขียนจากมุมมองเดียว แต่ในความเป็นจริงมุมมองกว้างกว่านั้น และสิ่งที่ใช้ได้ในสถานการณ์หนึ่งอาจใช้ไม่ได้ในอีกสถานการณ์หนึ่ง สุดท้ายแล้ว software engineering ทั้งหมดก็ใกล้เคียงกับการหาว่าอะไรควรนำไปใช้ที่ไหนและเมื่อไร แล้วไม่สนใจส่วนที่เหลือ
      บทความบล็อกของบริษัทจำนวนมากทำให้เชื่อเหมือนมี กระสุนเงิน ที่ใช้ได้กับทุกกรณี แต่โดยปกติแล้วไม่เป็นความจริง
      สุดท้ายมันก็ใกล้เคียงกับสิ่งที่ software engineering รับมือมาตลอด คือ “บางอย่างใช้ได้ในบางสถานการณ์” และไม่ใช่เรื่องถูกหรือผิดเท่าไร แต่การนำไปใช้จริงต่างกันไปตามบริบท ซึ่งเป็นเรื่องปกติ
    • เคยลองใช้ rector ไหม?

  • AI อยู่ประมาณวิศวกรระดับจูเนียร์ถึงระดับกลาง ถ้าปฏิบัติกับมันแบบนั้น ก็จะได้ข้อดีทั้งของ vibe coding และวิศวกรรมแบบเข้มงวด โดยไม่ต้องระแวงทั้งหมดนี้
    ผมให้ Claude รันใน โหมด YOLO บน VM ที่แยกไว้ตั้งแต่แรก เหมือนให้แล็ปท็อปส่วนตัวกับวิศวกรคนหนึ่ง Claude ทำฟีเจอร์จนถึงจุดที่เปิด PR ได้ แล้วผมก็รีวิว diff เหมือนรีวิวงานวิศวกรคนอื่น จากนั้นปรับแต่งให้เข้ารูปแล้วไปต่อ
    วิศวกรที่ยังไม่ชำนาญก็ทำพลาดแบบเดียวกัน ผมเคยเห็น rm -rf ด้วย แม้จะไม่ได้ทำจาก root ก็ตาม ถ้าผมต้อง micromanage ใครสักคนโดยปฏิเสธสิทธิ์ทุกอย่าง คงประสาทเสียแน่

    • เห็นด้วยกับมุมมองนี้อย่างแรง และเพราะอย่างนั้นยิ่งไม่เข้าใจบทความนี้ PR ก็เป็นด่านตรวจอยู่แล้ว ไม่ใช่เหรอ? ภายใน workspace เอเจนต์จะทำอะไรก็ช่าง ตราบใดที่ contribution ถูก gate ผ่าน git repository และงานพัฒนาไม่ต้องมี production access แปลก ๆ ผมก็ไม่สน
      เห็นด้วยกับการเปรียบเทียบว่าเป็นวิศวกรจูเนียร์/ระดับกลาง แต่มีข้อแม้ใหญ่ AI เหมือนวิศวกรจูเนียร์ที่ไม่รู้วิธีเรียนรู้
      เหมือนทำงานกับตัวเอกจาก Memento ทุกวันพอ LLM มาทำงาน มันไม่ได้เรียนรู้อะไรจากงานที่ทำมาจนถึงตอนนี้เลย และทุกวันคือวันแรก
      แน่นอนว่าเหมือนตัวเอกจาก Memento เราช่วยได้ด้วยการแปะโพสต์อิทและการแจ้งเตือนไว้ทั่ว workspace ถ้าพยายามก็เข้าใกล้สิ่งที่เรียกว่า “การเรียนรู้” ได้ ซึ่งนี่เป็นคุณสมบัติที่สำคัญที่สุดอย่างแท้จริงสำหรับนักพัฒนาซอฟต์แวร์ทุกคนในทีม
      แต่มันไม่ง่าย และเครื่องมือก็ยังไม่พอ สิ่งที่ดีที่สุดที่ผมเคยทำได้คือคล้าย “สมองที่สอง” ที่ใช้ผ่านเครื่องมืออย่าง Obsidian น่าเศร้าที่ผมมองว่าสมองที่สองไม่ใช่สิ่งทดแทนสมองแรก พูดตรง ๆ ถ้าเป็นวิศวกรที่เรียนรู้และเติบโตไม่ได้เหมือน AI agent ก็คงถูกไล่ออกหลังผ่านเดือนแรกในทุกบริษัทที่ผมเคยทำงานมา
      ถึงอย่างนั้นผมก็ค่อนข้างมองโลกในแง่ดีว่าผู้ให้บริการ AI รายใหญ่หรือใครสักคนจะปรับปรุงเรื่องนี้ได้ในอนาคต ถ้ามี memory ที่ดี บวกกับระบบคิดที่ออกแบบมาดีซึ่งฉีดความจำให้เข้ากับบริบทได้ดีกว่าเดิม และสามารถจับการเรียนรู้จริงได้โดยไม่ต้องมีการกำกับ ก็ดูไม่ใช่งานที่เป็นไปไม่ได้
      ผมอ่านบทความพวกนี้โดยหวังว่าจะมีใครแก้ปัญหานี้ไปแล้ว และผมแค่รู้ช้าไปเอง แต่ตอนนี้สิ่งที่เกิดขึ้นคือความสามารถในการออกแบบ agent ของผมดีขึ้นจากตอนแรกนิดหน่อยเท่านั้น
    • ประสบการณ์ของผมก็เหมือนกัน ผมมองว่าใกล้เคียงกับอินเทิร์นที่ฉลาดมากและเร็วมาก เห็นแววว่าจะไปได้ไกล และในหลายด้านก็ดีกว่าผมมากแล้ว แต่ก็ยังต้องให้มือของผู้ชำนาญช่วยกำหนดทิศทาง
      กฎจากประสบการณ์ของผมคือ process พิเศษที่ทำขึ้นเพื่อ AI ควรสมเหตุสมผลกับมนุษย์ด้วย ถ้าไม่ใช่ก็ไม่มีคุณค่า เครื่องมือ command line ที่ดี การสรุป output คำสั่งยาว ๆ อัตโนมัติ เอกสาร Markdown และ workflow ก็มีประโยชน์กับมนุษย์ด้วย
      ถ้าจะป้องกันความผิดพลาดและการใช้งานเกินขอบเขต ควรใช้ sandbox และสิทธิ์แบบจำกัดขอบเขต ไม่ใช่ micromanaging
      สิ่งที่อยากค้นหาคือ workflow การ pair programming ที่ดีกับ AI agent โมเดลประสิทธิภาพสูงสามารถรับงานใหญ่ได้ และมันก็ทำได้ดี จะใช้โมเดลระดับต่ำเป็นผู้ช่วยใน IDE ก็ได้ และนั่นก็ทำได้ดีเช่นกัน แต่สองอย่างนี้เป็น workflow คนละแบบ
      สิ่งที่มีประโยชน์จริง ๆ คือการสร้างร่วมกันกับโมเดลประสิทธิภาพสูง โดยสลับกันจับคีย์บอร์ด เพียงแต่ไม่ควรให้รันแบบ YOLO เต็มรูปแบบบนเครื่องของผมเอง ตรงนี้คือความต่างระหว่างมนุษย์กับ LLM เพราะมันเร็วเกินไป เวลาหลุดทางแล้วจะคว้าคีย์บอร์ดกลับมาได้ยาก
    • ถ้าให้แล็ปท็อปจริงกับ Claude มันอาจแก้ปัญหา Bluetooth audio บน Linux ได้ด้วย ;)
    • ใช้ VM/provisioning แบบไหนอยู่?
    • คำว่า “AI คือวิศวกรระดับจูเนียร์ถึงระดับกลาง” ตอนนี้ไม่จริงแล้ว และการเข้าใจผิดแบบนั้นก็ไม่ได้ช่วยอะไร
      ไม่มีใครรู้แน่ชัดว่า AI คืออะไร แต่ไม่ใช่วิศวกรจูเนียร์หรือระดับกลาง มันใกล้เคียงกับ staff engineer ด้านนิวเคลียร์ที่อาศัยอยู่ในเพิง ไม่มีบริบทของโดเมน และตื่นขึ้นมาทุก 5 ชั่วโมงโดยไม่มีความทรงจำ

  • LLM ยังคงเป็นตัวทำนายโทเค็นถัดไปอยู่ดี การที่มันหาขั้นตอนที่ถูกต้องได้แม้จะให้คำสั่งที่คลุมเครือกว่าเดิม ไม่ได้แปลว่ามันมีสติปัญญา แต่แปลว่าคุณกำลังพูดภาษาเดียวกับ harness ที่ใช้ฝึกโมเดล
    และตรงนั้นก็มีขีดจำกัด หากคุณยังอยู่แค่ระดับ proof of concept หรือแอปง่าย ๆ คุณอาจไม่รู้ว่าโมเดลปัจจุบันยังมีข้อจำกัดมากแค่ไหน ในกรณีแบบนั้นควรแบ่งงานออกเป็นชิ้น ๆ ไม่ใช่เชื่อใจตัวทำนายโทเค็นที่เรียงขั้นตอนให้ดูน่าเชื่อถือ
    ต้องมี human loop อยู่ตรงไหนสักแห่งเสมอ ถ้าเริ่มข้ามการขอสิทธิ์ไปเอง ผลลัพธ์ที่ดีที่สุดอาจแจ็กพอต แต่ที่มีโอกาสมากกว่าคือได้ทางออกที่รองลงมาและเสียโทเค็นเปล่า ๆ สิ่งที่น่ากลัวจริง ๆ คือกรณีที่โมเดลไม่ทำตามคำสั่ง แล้วทำเรื่องโง่ ๆ จนพังไปทั้งวัน
    มันคมเหมือนเครื่อง CNC ไม่ใช่ว่าไม่มีประโยชน์ แต่ก็อันตรายได้ ถ้าคุณจอดรถขนานไม่เป็น ก็คงดีกว่าที่จะไม่พยายามใช้เครื่องจักรสัตว์ประหลาดไปแกะไม้ หรือพยายามจอด Ferrari ในย่านแคบ ๆ

    • การทำนายโทเค็นถัดไป ไม่ใช่อัลกอริทึม แต่เป็นอินเทอร์เฟซ กระบวนการ “ทำนายโทเค็นถัดไป” อาจซับซ้อนหรือเรียบง่ายแค่ไหนก็ได้ และความสามารถในการทำงานที่ได้รับมอบหมายก็อาจสูงหรือต่ำแค่ไหนก็ได้เช่นกัน
      การบอกว่า LLM ทำอะไรได้หรือทำอะไรไม่ได้เพราะมันเป็น “ตัวทำนายโทเค็น” เป็นการจัดหมวดหมู่ผิด อินเทอร์เฟซไม่ใช่ขีดจำกัดที่ตายตัว
    • ไม่รู้ว่าคุณนิยามสติปัญญาอย่างไรในคำว่า “ไม่ใช่สติปัญญา”
      ผมสงสัยว่าจะนิยามอย่างไรให้ตัดโมเดลภาษาออก แต่รวมมนุษย์เข้าไว้ โดยไม่ตั้งสัจพจน์ล่วงหน้าว่า LLM ไม่มีสติปัญญา
    • ถ้าอย่างนั้นคุณเองก็เป็นแค่คนที่พูดคำถัดไปเหมือนกัน
    • การเรียก LLM ว่า “ตัวทำนายโทเค็นถัดไป” เป็นการลดทอนอย่างสิ้นเชิงและไม่จริงใจ ทางเทคนิคก็ถูก แต่คุณเองก็เหมือนกัน
      โดยทั่วไปที่คนหมายถึงด้วยคำนี้คือ “มันแค่ทำนายโทเค็นถัดไปของข้อมูลฝึก หรือก็คืออินเทอร์เน็ต” ซึ่งอาจจริงสำหรับโมเดลดิบ แต่โมเดลผ่านการฝึกหลังจากนั้นด้วย ดังนั้นแม้แต่คำอธิบายนี้ก็ไม่ถูกอีกต่อไป
      คำว่า “ไม่ใช่สติปัญญา” ไม่ได้มีประโยชน์ และในความเห็นผมมันผิดด้วย ใครจะสนว่ามันตรงกับนิยามสติปัญญาของคุณไหม มันยังทำสิ่งที่น่าประทับใจได้ และยังทำสิ่งที่ยิ่งใหญ่กว่าที่คุณบอกเป็นนัยไว้มาก
    • ถ้าเกินเกณฑ์ไหนแล้วคุณถึงจะเรียกว่ามีสติปัญญา?

  • ต้นฉบับให้ความรู้สึกว่ายังติดอยู่ในปี 2025
    เขาบอกว่า “AI จะหลุดรางหลายครั้ง และจะรู้ตัวก็ต่อเมื่อได้ลองใช้ซอฟต์แวร์จริง ๆ” แต่ตอนนี้ AI ตัวนั้นสามารถใช้ซอฟต์แวร์เองเพื่อหาบั๊ก แก้บั๊ก และผลักดันฟีเจอร์ใหม่ได้แล้ว
    กรณีที่เอเจนต์เริ่มทำสิ่งที่เราไม่ต้องการยังมีอยู่ แต่ลดลงมากเมื่อเทียบกับก่อนหน้า และข้อโต้แย้งฝั่ง เอเจนต์อัตโนมัติเต็มรูปแบบ ไม่ได้อ่อนลง แต่แข็งแรงขึ้น
    คำว่า “การที่คนจะเข้าใจ codebase นั้นเป็นไปไม่ได้ในเชิงมนุษย์” ก็ดูล้าสมัยแล้ว ผมมองว่ากำลังไปในทิศทางที่มนุษย์ไม่จำเป็นต้องเข้าใจ codebase อีกต่อไป และ AI เป็นฝ่ายนำ

    • บริษัท AI มีแรงจูงใจที่จะผลักดัน slopmaxxing แบบบ้าบิ่นนี้ ผลลัพธ์สุดท้ายคือธุรกิจของคุณต้องพึ่งพาพวกเขาโดยสมบูรณ์ และมูลค่าของผลิตภัณฑ์ทั้งหมดก็มาจากพวกเขา
      หลายคนกำลังกระโดดขึ้นขบวนนี้ แต่ผมมองว่าเป็นกระแสโง่ ๆ
    • ใช่แล้ว การเข้าใจอะไรสักอย่างนี่มันช่างเป็นแนวคิดแบบปี 2025 มาก ๆ
    • คำพูดนี้อาจใช้ได้กับซอฟต์แวร์ที่ไม่ใช่แกนหลัก เช่น ความบันเทิงหรือสื่อ
      แต่ใช้ไม่ได้เด็ดขาดกับระบบที่มีความเสี่ยงด้านความปลอดภัยสูง ในสาขาอย่างธนาคาร การบิน และกลาโหม AI จะมีส่วนช่วยแน่นอน แต่ไม่สามารถเดินหน้าโดยเป็นอิสระจากความเข้าใจด้านวิศวกรรมของมนุษย์ได้
    • ถ้าเป็นคนที่มีเซนส์ด้านการเขียนโปรแกรมและสถาปัตยกรรมที่มีประสิทธิภาพดีพอ ก็คงไม่เห็นด้วยกับคำว่า AI ใช้ซอฟต์แวร์เองเพื่อหาบั๊กและสร้างฟีเจอร์ได้
      วิธีสายจูงสั้น คือวิธีรับประกันผลลัพธ์ที่ดีเมื่อทำงานนอกข้อมูลฝึก สำหรับผม แม้แต่โปรแกรมเมอร์ที่เก่งกว่าค่าเฉลี่ยเพียงเล็กน้อย วิธีนี้ก็เป็นวิธีเดียวที่จะรับประกันการพัฒนาที่รวดเร็วและมีคุณภาพด้วย LLM ได้
      คำว่ามนุษย์ไม่จำเป็นต้องเข้าใจ codebase อีกต่อไป ดูเหมือนจะมาจากการไม่รู้จักโลกการเขียนโปรแกรมที่ AI ยังทำได้แย่อย่างยับเยิน ผมเห็นมันพังเรื่องการจัดการหน่วยความจำอยู่บ่อย ๆ ในภาษาที่มีการจัดการหน่วยความจำแบบ manual และมันไม่ได้ง่ายถึงขั้นแค่ใส่ไว้ในลูป Valgrind ก็พอ
    • ผมไม่รู้สึกว่าข้อโต้แย้งฝั่งเอเจนต์อัตโนมัติเต็มรูปแบบแข็งแรงขึ้นเลย นี่คือสิ่งที่ผมเจอเมื่อไม่กี่สัปดาห์ก่อนกับ Claude Code + Opus 4.8 งานไม่ได้ซับซ้อนมาก เป็น API endpoint ใหม่ 4 จุด และ event ที่สตรีมไปยังไคลเอนต์ผ่าน WebSocket
      ผมปรับแต่งนิยาม API, โมเดล request/response, schema ฐานข้อมูล และ flow ทั้งหมดซ้ำหลายรอบ และต้องลงมือกำจัดความขัดแย้งกับแก้เอกสารเองไปมาก Opus หลุดรางอยู่เรื่อย ๆ และเอกสารสุดท้ายยาวเกิน 500 บรรทัด
      ต้องวนกลับไปกลับมากับ API integration test ด้วย AI สร้าง test จากเอกสารโดยตรงไม่ได้ เลยต้องให้สร้าง placeholder ที่มีคอมเมนต์ Given-When-Then ก่อน แล้วผมตรวจและแก้ด้วยมือ จากนั้นค่อยให้ implement test ในรอบที่สอง มีข้อผิดพลาดที่ต้องแก้หลังรีวิวจำนวนมาก
      ในขั้น implement ผมให้เอกสาร API, test ที่รันได้, hook สำหรับบล็อกการแก้ไข, skill “แนวปฏิบัติที่ดี” มากกว่า 6 อย่าง, เอเจนต์ “rubber duck” และ “ลดความซับซ้อนโค้ด”, รวมถึงสคริปต์สำหรับตรวจ test, linter และ compile error หลังจากวางแผน ลงมือทำ รีวิว และแก้หลายรอบ ฟีเจอร์ก็ implement เสร็จและ test ทั้งหมดผ่าน
      ใน code review ผมพบปัญหาเฉลี่ยหนึ่งจุดต่อโค้ด 20 บรรทัด แม้ไม่นับ code style ก็ยังมีการใช้ in-memory semaphore ในบริการ Kubernetes, การเรียก DB 8 ครั้งเพื่อพยายามอัปเดตเรคอร์ดเดียวกันภายใน request เดียว, การอัปเดตทีละคอลัมน์, read-modify-save แบบไม่มี transaction, รวมถึงข้อผิดพลาดด้าน business logic, recovery และ authorization
      ผลลัพธ์คือเกือบหนึ่งสัปดาห์ทำงาน, ค่าโทเค็นมากกว่า 100 ดอลลาร์ และเหลือแต่ความคิดว่า “ความพยายามนี้คุ้มค่าหรือเปล่า?” ผมมีทีม developer 2 คนอยู่ และเพิ่งรีวิว PR ของคนหนึ่งไป พบว่า 80% เป็น slop

  • ผมเคยลองแนวทางคล้ายกัน แต่ไม่ค่อยเข้ากับผม แทบไม่ได้เพิ่มความเร็วเลย หรือไม่เพิ่มเลย ผมคิดว่าถ้าจะได้ productivity ต้องมี YOLO mode ใน sandbox ระดับหนึ่ง
    เป้าหมายควรเป็นการ outsource งานให้โมเดลมากที่สุดเท่าที่ทำได้ พร้อมลดความพยายามที่ต้องใช้ในการทำความเข้าใจและรีวิวผลลัพธ์ให้น้อยที่สุด
    เช่น ให้โมเดลหาสาเหตุของบั๊ก, ทำ proof of concept ของ X, ค่อย ๆ optimize บางอย่าง, หรือทำ refactoring ที่กำหนดชัดเจนพร้อม guide
    สิ่งที่คนพูดถึงเวลาเรียกว่าสร้าง loop ก็คล้ายกันมาก คือทำให้สิ่งที่โมเดลทำมีมากที่สุด และลดสิ่งที่ผมต้องทำเพื่อควบคุมมันให้น้อยที่สุด

  • บทความแทบไม่มีสาระอะไร

    • ก็แค่ทำตามวลีที่กำลังฮิตอยู่ตอนนี้เท่านั้น
      ปีที่แล้วคือ “AI ก็เป็นแค่นกแก้วเชิงความน่าจะเป็น”
      ปีนี้คือ “AI เขียนโค้ดได้ก็จริง แต่สุดท้ายมนุษย์ก็ยังต้องรีวิว!” แน่นอนว่าการรีวิวนั้นก็ใช้ AI ด้วย
      อีกสัก 1 ปีข้างหน้า เรื่องเล่าก็คงจะกลายเป็น “การรีวิวโค้ดมีแต่ AI เท่านั้นที่ทำได้ และสิ่งที่รีวิวรีวิวของ AI ได้ก็มีแต่ AI เท่านั้น มนุษย์แค่อ่านความเห็นสุดท้ายของ AI ก็พอ เพื่อคงการกำกับดูแลที่มีความหมายไว้”
      เสาประตูถูกขยับไปเรื่อย ๆ แต่ความมั่นใจไม่เคยขยับเลย