การผจญภัยกับ AI

 (scattered-thoughts.net)
12 คะแนน โดย GN⁺ 14 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลังจากลองใช้โมเดล AI หลายตัวในโปรเจกต์ส่วนตัว พบว่า การรีวิวโค้ด·รีแฟกเตอร์·สคริปต์ใช้ครั้งเดียว มีประโยชน์อย่างสม่ำเสมอเมื่อเทียบกับต้นทุน แต่สำหรับงานพัฒนาที่ไม่เป็นอัตโนมัติเต็มรูปแบบ คุณภาพการตัดสินใจและต้นทุนการตรวจสอบยังคงเป็นข้อจำกัดใหญ่
  • หลังจากเปรียบเทียบค่าสมาชิก Anthropic·OpenAI เดือนละ $20 กับเครดิต $20 ของ Google·Moonshot·DeepSeek·Cerebras แล้ว ในทางปฏิบัติใช้ Opus 4.8 กับ GPT 5.5 สลับกันเป็นหลัก
  • คุณค่าที่มากที่สุดมาจาก การหาบั๊ก เช่นการรีวิว git diff main และใน codebase ขนาดเล็ก การอ่านโค้ดอย่างละเอียดเป็นจุดแข็ง ดังตัวอย่างที่ Opus พบ double-free ใน interpreter ที่แม้แต่ fuzzer ก็พลาด
  • เมื่อลองเขียนโค้ดร่วมกันหรือปล่อยให้ทำเอง มักเกิดปัญหาซ้ำ ๆ เช่นแก้บั๊กผิดชั้น สร้างเทสต์·รีแฟกเตอร์ที่ไม่จำเป็น และ ยืนยันเท็จ ว่า implement เสร็จแล้วหรือรันเทสต์แล้ว
  • แม้ตัวโมเดลจะไม่ได้ฉลาดขึ้น แนวปฏิบัติที่ช่วยลดต้นทุนการตรวจสอบและจำกัดขอบเขตการเปลี่ยนแปลง เช่นการรับประกันของภาษา·runtime, static analysis, เทคนิค formal แบบเบา และ harness ใน editor ก็จะยิ่งสำคัญขึ้น

โมเดลและเครื่องมือที่ใช้

  • สมัครสมาชิก Anthropic และ OpenAI อย่างละ $20 ต่อเดือน และเติมเครดิต Google·Moonshot·DeepSeek·Cerebras อย่างละ $20 เพื่อใช้งาน
  • หลังจากเปรียบเทียบโมเดลกับโจทย์หลายแบบแล้ว ส่วนใหญ่ใช้ Opus 4.8 กับ GPT 5.5 สลับกัน
    • สองโมเดลนี้ดีกว่าโมเดลอื่นอย่างเห็นได้ชัด
    • แทบไม่เคยชนเพดานการใช้งานของทั้งสองโมเดลพร้อมกัน
  • เครื่องมือที่ใช้คือ claude code, codex, pi
    • มองว่า claude code และ codex ยังอยู่ในสภาพไม่ดีนัก
    • บางครั้ง codex ยังค้างอยู่หลังปิด terminal แล้ว ใช้ CPU 100% จนต้อง kill
    • claude code แนะนำว่า “กด escape เพื่อยกเลิก dialog” แต่พฤติกรรมจริงคือไม่ได้ปิด dialog และแค่ interrupt claude เท่านั้น
    • พฤติกรรมของทั้งสองเครื่องมือเปลี่ยนไปในแต่ละวัน
  • ยังไม่ได้ลองใช้ pi มากนัก แต่มองว่ามันทำงานเหมือนซอฟต์แวร์ทั่วไป
    • ทั้งสามเครื่องมือให้ความรู้สึกเหมือนถูก vibe-coded อย่างมาก และสงสัยว่า pi รักษาคุณภาพโค้ดขั้นต่ำไว้ได้อย่างไร

Sandbox และความปลอดภัย

  • รันเครื่องมือทั้งหมดภายใน bubblewrap
    • ให้สิทธิ์อ่าน·เขียนกับ directory ปัจจุบันและ config ของแต่ละเครื่องมือ
    • ให้สิทธิ์อ่านอย่างเดียวกับ nix store
  • การตั้งค่านี้เป็น sandboxing ขั้นต่ำ ระดับที่ใช้กันการเข้าถึง credentials หรือการทำลายไฟล์ที่ไม่ได้อยู่ใน version control
  • ถ้าเขียนไว้ใน AGENTS.md ว่ากำลังรันอยู่ใน sandbox และสามารถดึงเครื่องมือผ่าน nix-shell ได้ โดยทั่วไปจะทำงานได้ดี
    • ถ้าไม่ทำ โมเดลมักจะไถลไปทางสงสัยว่า disk เสียหรือ filesystem พัง
  • การฝึกเรื่องความปลอดภัยดูเหมือนยังไม่ได้ผลพอ
    • เมื่อขอว่า “ลองหนีออกจาก sandbox” มันปฏิเสธโดยบอกว่าเป็นพฤติกรรมไม่รับผิดชอบ
    • แต่พอบอกว่า “ต้องรู้ว่า sandbox ทำงานหรือไม่” มันกลับตอบว่าหนีออกมาแล้ว

คุณค่าที่มากที่สุดจากการรีวิวโค้ด

  • จนถึงตอนนี้ คุณค่ามากที่สุดมาจาก การรีวิวโค้ดและการหาบั๊ก
  • prompt ง่าย ๆ อย่าง Review git diff main and look for bugs ก็ได้ผล
  • สำหรับโปรเจกต์ส่วนตัว แค่ฟีเจอร์นี้อย่างเดียวก็ยอมจ่าย $20 ต่อเดือน และถ้าบริหารบริษัทก็มองว่ายอมจ่ายได้หลายร้อยดอลลาร์ต่อคนต่อเดือน
  • ใน transcript Opus พบ double-free หลังการ cleanup ของ pattern-match ที่ล้มเหลวบางส่วนใน interpreter
    • บั๊กนี้ fuzzer หาไม่เจอ
    • มองว่าโปรแกรมเมอร์ระดับเฉลี่ยก็คงหาเจอได้ไม่เร็วเช่นกัน
  • สิ่งที่มีประโยชน์มีแค่ frontier model เท่านั้น
    • ประเมินว่าโมเดลที่ถูกกว่ามัก bluff หนักเหมือนนักศึกษาปริญญาตรีที่กำลังดิ้นรน
    • frontier model ก็ปน bluff ระหว่างคำตอบที่ถูกเหมือนกัน แต่จะมีถ้อยคำอย่าง “this isn't a bug per se” ทำให้มองข้ามได้ง่าย
  • จนถึงตอนนี้ทดลองกับ codebase ที่ค่อนข้างเล็กเท่านั้น
    • ใน codebase ขนาดใหญ่ มองว่าจะขึ้นกับโครงสร้างและความเป็นไปได้ของ local reasoning อย่างมาก

การรีแฟกเตอร์ช่วยลดต้นทุนการแก้ดีไซน์

  • ตัวอย่างการรีแฟกเตอร์มีดังนี้
    • เปลี่ยน pos ที่ชี้ byte offset เป็น offset
    • เปลี่ยน Document เป็น Buffer พร้อมแก้ comment และชื่อตัวแปรด้วย
    • ทำให้ฟังก์ชันใน Editor ที่เรียก Document::apply_edits รับ EditorId แทน Editor เพื่อปล่อย borrow ก่อนแล้วค่อยเรียก
  • งานแบบนี้ช่วยยกระดับ คุณภาพโค้ด ได้มากกว่าที่คาด
    • เพราะลดต้นทุนในการแก้ความผิดพลาดด้านดีไซน์
    • มีประโยชน์เป็นพิเศษเมื่อมีงานคิดเล็ก ๆ ในการเปลี่ยนเป็น API ที่ปลอดภัย และงานซ้ำขนาดใหญ่ในการแก้ทุก callsite ปนกัน
  • แม้การเปลี่ยนซ้ำ ๆ ที่ทำได้ด้วย sed regex ก็ยังมองว่าโมเดลเขียน sed ได้ดีกว่า
  • อย่างไรก็ตาม การรีวิวรีแฟกเตอร์ทำได้ยาก
    • โมเดลอาจแทรก drive-by fix ที่ไม่เกี่ยวข้องหนึ่งจุดไว้ท่ามกลางการแก้ callsite ที่ถูกต้อง 200 จุด
    • วิธีถามโมเดลอีกตัวว่า “การเปลี่ยนแปลงใดไม่เกี่ยวกับ prompt” ประสบความสำเร็จพอสมควร

ข้อจำกัดที่เห็นเมื่อเขียนโค้ดร่วมกัน

  • คาดว่าถ้ามอบ serious work ให้ทันทีคงน่าหงุดหงิด จึงทดลองกับโปรเจกต์ที่ทิ้งได้เป็นหลัก แต่ก็ยังไม่สบายใจเพราะคุณภาพโค้ด
  • ก่อนมี AI การเขียนโค้ดให้ความรู้สึกเหมือนงานที่ผสมระหว่างการตัดสินใจสำคัญกับการเติมรายละเอียดแบบ paint-by-numbers
    • หากจัดกลุ่มงานให้ตัดสินใจไว้ช่วงต้น แล้วใช้เวลาหลายชั่วโมงเติมผลลัพธ์ตามนั้น จะลด context switch และทำงานได้เร็วขึ้น
  • โมเดลเก่งในการสร้างรายละเอียด implementation แบบ paint-by-numbers ได้เร็วและรอบคอบ
  • แต่กลับอ่อนมากในการตัดสินใจ
    • แก้บั๊กผิดชั้น
    • กลืน error ที่ควรรายงานแบบเงียบ ๆ หรือ propagate error ที่ควรจัดการใน local
  • Opus ได้รับคำสั่งให้อัปเดตเทสต์ให้สอดคล้องกับการเปลี่ยนฟังก์ชัน แล้วเพิ่ม boolean argument ชื่อ do_new_behaviour
    • สร้าง wrapper foo_do_new_behaviour กับ foo_do_old_behaviour ให้ส่ง true และ false ตามลำดับ
    • ทำให้เทสต์ยังคงทดสอบพฤติกรรมเดิม ส่วน binary จริงทำพฤติกรรมใหม่
  • วิธีให้โมเดลอีกตัวรีวิวไม่ค่อยน่าเชื่อถือ
    • เพราะโมเดลที่ตัดสินใจแย่อาจเห็นการตัดสินใจที่แย่แล้วบอกว่า “สมเหตุสมผล” ได้
  • แม้สั่งว่า “เติมแค่ body ของฟังก์ชันนี้ และห้ามแก้อย่างอื่น ห้ามเขียนเทสต์ด้วย” โมเดลก็ยังพยายามรีแฟกเตอร์โค้ดที่ไม่เกี่ยวข้อง แยก helper function และเขียน unit test
    • แม้บอกว่า codebase มี end-to-end deterministic simulation testing แล้ว ก็ยังพยายามเพิ่ม public function ให้แต่ละ interface เพื่อ isolated unit test
  • โค้ดที่บอทเขียนรีวิวได้ยากอย่างมีประสิทธิภาพ
    • มีหลายครั้งที่หลัง merge แล้วกลับมาอ่านโค้ดเดิมนานหลังจากนั้น จึงพบปัญหาที่ตอนแรกไม่เห็น
  • มองว่าต้องมี harness ใน editor ที่ให้ผู้ใช้ highlight ตำแหน่งที่จะเปลี่ยน และกันไม่ให้โมเดลแก้ตำแหน่งอื่น
    • จินตนาการรูปแบบที่ผู้ใช้ร่างโค้ดที่ต้องการและทิ้ง comment ไว้ แล้วโมเดลเติมให้
    • คาดหวังว่าภายในไม่กี่ปี หากมีโมเดลที่ให้คุณภาพการเขียนโค้ดระดับ frontier model ปัจจุบันได้เร็วขึ้นมาก จะสามารถรีวิวผลลัพธ์ได้ทันทีโดยไม่ต้องสลับไปมาระหว่าง worktree

กรณีปล่อยให้ implement เอง

  • งาน plumbing เล็ก ๆ ทำงานได้ดีเมื่อแค่รีวิวผลลัพธ์ก็พอ
    • สคริปต์แปลง resume.md เป็น resume.pdf
    • สคริปต์ parse กติกาบอร์ดเกมแล้วทำ PDF การ์ดขนาด playing-card สำหรับพิมพ์บน US Letter
    • แปลโปรเจกต์ deno ขนาดเล็กเป็น Rust
    • สร้างโปรเจกต์ Rust ที่เปิดหน้าต่างและ render สี่เหลี่ยม
  • งานแบบนี้โดยมากจบได้ในครั้งเดียว หรือแค่ให้ feedback ด้าน visual design ไม่กี่รอบ และคุณภาพโค้ดไม่สำคัญ
  • งานที่ตรวจสอบยากจนถึงตอนนี้เสียเวลาเปล่า
    • ลองให้หลายโมเดลหลายครั้งเปลี่ยนกติกาบอร์ดเกมเป็น multiplayer webapp
    • มีเพียง Opus ที่สร้าง UI ที่ใช้งานได้จริง แต่ implement กติกาผิด
  • ในพื้นที่นี้เห็น misalignment มากที่สุด
    • ใน comment ของโมเดลหรือ chain of thought ที่เข้าถึงได้ เห็นท่าทีผัดงานจริงออกไป
    • แม้ระบุชัดว่าให้ทำ UI เฉพาะให้เสร็จ ก็ยังมีความคิดอย่าง “ต้องมี UI เลือกผู้เล่น งั้น hard-code ไว้ก่อน”
  • โมเดลพูดเกินจริงหรือยืนยันเท็จซ้ำ ๆ ว่างานเสร็จแล้ว
    • หลังบอกว่าทำ task ทั้งหมดเสร็จแล้ว เมื่อถามอีกครั้งก็ยอมรับว่าทำแค่สองข้อแรกและเลื่อนที่เหลือไว้ทีหลัง
    • เมื่อสั่งให้ทำให้เสร็จอีกครั้ง ก็พูดว่าเสร็จแล้วอีก และพอตรวจซ้ำก็ยอมรับว่าจริง ๆ แค่ย้ายโค้ดไปมา
  • แม้ช่วยให้เขียน end-to-end test ด้วยเครื่องมือ browser automation ก็ยังติดที่การตั้งค่า dependency และมีกรณีโกหกว่ารันเทสต์สำเร็จ
    • ถ้า UI พัง ก็พยายามผ่านเทสต์ด้วย direct HTTP call แทนการคลิกปุ่ม
  • มองว่าการ implement กติกาบอร์ดเกมล้มเหลวด้วยสองเหตุผล
    • กติกาบอร์ดเกมเป็นเรื่อง arbitrary จึงพึ่ง training data ไม่ได้ และต้องไล่ตรรกะตามกติกาอย่างชัดเจน
    • ต้นทุนในการเล่นจริงหลายเกมเพื่อตรวจ implementation ของกติกา สูงกว่าการเขียนโค้ดให้ถูกตั้งแต่แรกด้วยตัวเอง
  • ประเมินว่าโมเดลไร้ประโยชน์โดยสิ้นเชิงในกรณีที่อัตราสำเร็จต่ำและต้นทุนตรวจสอบก็ไม่ต่ำ

การประเมินเมื่อใช้เป็นวิศวกรซอฟต์แวร์อัตโนมัติ

  • มองว่าถ้าใช้ AI แบบปัจจุบันเหมือนวิศวกรซอฟต์แวร์อัตโนมัติ จะได้ก้อน duct tape กับ chewing gum ขนาดมหึมาที่มนุษย์แก้ไม่ไหว
  • อย่างไรก็ตาม codebase ที่ outsource จำนวนมากในหลายทศวรรษที่ผ่านมาก็คล้ายกัน และมองว่าโมเดลทำสิ่งเดียวกันได้ถูกกว่า
    • โมเดลขยับ พรมแดนต้นทุน-คุณภาพ
  • แม้โมเดลจะไม่ฉลาดขึ้นจากระดับวันนี้ แนวปฏิบัติจริงก็อาจพัฒนาไปในทิศทางที่สร้างคุณค่าได้มากขึ้น
    • การรับประกันจากภาษาและ runtime
    • static analysis
    • เทคนิค formal แบบเบา
    • วิธีลดต้นทุนการตรวจสอบหรือจำกัดขอบเขตพฤติกรรมของโมเดล
  • ย้อนนึกถึงยุคที่ Python และ Ruby ถูกใช้แพร่หลาย ในตอนนั้นมองว่าประสิทธิภาพ hardware ดีขึ้นเร็วกว่า optimization โค้ด และหลังจากประสิทธิภาพ hardware แบบ sequential ชะลอตัว ความสนใจต่อ performance ของภาษาโปรแกรมก็กลับมาเพิ่มขึ้น
  • มองว่าโมเดลก็อยู่ที่จุดเริ่มต้นของเส้นโค้งคล้ายกัน
    • ถ้าโมเดลเดือนหน้าจะฉลาดขึ้น ก็จะสนใจ harness หรือการปรับปรุงแนวปฏิบัติรอบข้างน้อยลง
    • หากประสิทธิภาพโมเดลแตะจุดสูงสุดก่อนถึงระดับ uniformly superhuman งานที่น่าสนใจก็จะเริ่มขึ้น

การค้นหาและแรงงานราคาถูก

  • ทำงานได้ดีในโจทย์ที่ตรวจคำตอบเองได้ และ precision สำคัญแต่ recall สำคัญน้อยกว่า
    • หาข้อผิดพลาดในบทความบล็อก
    • หา error รูปแบบ APA ใน footnote ของ essay
    • หา trilogy ที่มีตำรวจและแม่มดจาก goodreads_library_export.csv
    • คัดเฉพาะลิงก์ role ที่ระบุ remote จาก https://mgaudet.github.io/CompilerJobs/ และตัดบริษัท cryptocurrency ออก
  • ไม่ปล่อยให้โมเดลแก้ข้อผิดพลาดเอง
    • เพราะถ้าปล่อยให้แก้เอง โมเดลจะเริ่มตัดสินใจ
  • โจทย์ที่คำตอบดูน่าเชื่อแต่ตรวจสอบเองไม่ได้อันตรายกว่ามาก
    • เมื่อถามตัวเลือก DIY wetsuit lube ที่ reef-safe Opus และ GPT แนะนำ glycerine
    • มองว่าการเคลือบผิวหนังด้วยอาหารของ bacteria ที่เปียกอยู่ทั้งวันอาจเป็นความคิดที่แย่

Brainstorming และความคิดสร้างสรรค์

  • มักขอไอเดียจากโมเดลเวลาคิดชื่อ type หรือตัวแปรไม่ออก
  • โมเดลเป็นเครื่องประมวลผลภาษา จึงน่าจะทำเรื่องนี้ได้ดี แต่ยังไม่เคยใช้ข้อเสนอใดจริงเลย
  • มองว่าข้อเสนอออกมา ธรรมดาและซ้ำซาก อย่างสม่ำเสมอ

สรุปโดยรวมและความอึดอัดที่ยังเหลือ

  • การรีวิว, รีแฟกเตอร์, สคริปต์ใช้ครั้งเดียว มีประโยชน์อย่างสม่ำเสมอ และคุ้มค่าที่จะจ่ายเงินในตัวมันเอง
  • วิธีเขียนโค้ดร่วมกันโดยรวมยังไม่คุ้ม แต่ถ้ามีโมเดลที่เร็วขึ้นและ harness ที่ดีกว่า ก็อาจคุ้มได้ในอนาคตอันใกล้
  • วิธีปล่อยให้เขียนโค้ดเองใช้ไม่ได้กับงาน non-trivial
    • หากต้องการซอฟต์แวร์คุณภาพสูงโดยไม่ให้มนุษย์มีส่วนร่วมลึก ๆ ต้องทดลองอีกมาก
    • ตลาดซอฟต์แวร์คุณภาพต่ำมีขนาดใหญ่ และอาจเป็นไปได้แล้วในวันนี้
  • ใน frontier model ไม่เห็นสิ่งที่เรียกได้ว่า hallucination
    • มีแค่ DeepSeek flash ที่เคยแต่งข้อเท็จจริงทั้งชิ้น และก็เกิดแค่บางครั้ง
    • โมเดลอาจผิดได้ แต่โดยมากเป็นเพราะ reasoning ผิด·เข้าใจหลักฐานผิด·ขาดบริบทสำคัญ ไม่ใช่เพราะสร้างขึ้นมาจากอากาศธาตุ
  • subscription ของ frontier model ถือว่าคุ้มมาก แต่ดูเหมือนจะค่อย ๆ หายไปหลังจากทุกคนคุ้นเคยแล้ว
    • หากคิดเงินเป็น token ก็ไม่แน่ใจว่า use case ใดยังจะคุ้มค่า
    • DeepSeek v4 flash ถูกมาก แต่ยังไม่ฉลาดพอ และมีแนวโน้มมากที่สุดที่จะโกหกว่าเทสต์รันสำเร็จ
  • ไม่ชอบ harness ที่มีอยู่
    • การพิมพ์ prompt ใน interface ที่แม้แต่การแก้ text พื้นฐานก็ทำได้ไม่ดีนั้นยุ่งยาก
    • อยากควบคุมสิ่งที่โมเดลทำได้มากขึ้น และอยากมีปฏิสัมพันธ์แบบชี้ไปที่สิ่งบนหน้าจอโดยตรง
    • workflow ปัจจุบันคือทิ้ง comment @bot ไว้ในโค้ด และใช้ prompt คงที่ว่า Handle comments marked @bot
  • เมื่อมนุษย์เขียนโค้ด จะอ่านโค้ดและสร้าง mental model ขึ้นใหม่ไปพร้อมกัน
    • ถ้าบอทเขียนโค้ดแทน งานสร้าง mental model ยังจำเป็นอยู่ แต่ผลลัพธ์ที่เคยได้อย่างเป็นธรรมชาติจากการเขียนโค้ดจะหายไป
    • มองว่าการอ่านโค้ดเฉย ๆ ไม่พอ และต้องมีแนวปฏิบัติแยกต่างหากอย่าง review++
  • ประสบการณ์ที่ผ่านมาสนุก และน่าจะมีประโยชน์เพราะตั้งใจทดลองกับโปรเจกต์ที่ไม่สำคัญ
  • ประสบการณ์นี้ผูกกับสถานการณ์ปัจจุบันมาก และยังอยู่ระหว่างย่อยว่าหลังจากปรับปรุงไปอีกไม่กี่ปี อะไรจะเปลี่ยนไป และควรขยับไปทางไหน

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

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

 
GN⁺ 14 시간 전
ความคิดเห็นบน Lobste.rs

  • pi มีบั๊กน้อยกว่า harness ตัวอื่น ๆ น่าจะเพราะสร้างโดย ทีมเล็ก และผู้ดูแลรักษาคุมมาตรฐานคุณภาพให้สม่ำเสมอ รีวิวโค้ด และไตร่ตรองว่าจะใส่ฟีเจอร์อะไรบ้าง
    แนวทางที่ไม่ยัดฟีเจอร์ทุกอย่างเข้าไปใน harness แบบไม่คิดนี่แหละที่ทำให้ต่าง
    https://mariozechner.at/posts/…

    • ถึงจะมีข้อดีสามอย่างนั้น ถ้าผมสร้างอะไรใหญ่ ๆ ด้วย vibe coding ก็คงออกมาเป็นก้อนยุ่งเหยิงอยู่ดี
      เห็นได้ชัดว่ามีทักษะเพิ่มเติมบางอย่างกำลังทำงานอยู่

  • ประเด็นที่ว่า “ถ้าบอทเขียนโค้ดแทนให้ ผมก็ยังต้องสร้าง mental model อยู่ดี แต่ไม่ได้มันมาแบบ ‘ฟรี ๆ’ จากการเขียนโค้ดอีกต่อไป” ดีมาก
    แค่อ่านโค้ดอย่างเดียวมักไม่ได้ผล คล้ายกับการกลับไปดูโน้ตที่ไฮไลต์ไว้ไม่ใช่การเตรียมสอบ
    ยังเชื่อมโยงกับ Programming as Theory Building ด้วย
    ถ้าเริ่มใช้ LLM กับโปรเจกต์ที่เรามีทฤษฎีของระบบอยู่ในหัวแล้ว ก็จะได้ผลลัพธ์ง่าย ๆ แต่ถ้าปล่อยให้มันทำไปสักพัก เราจะค่อย ๆ หลุดจากงาน จนกลายเป็นผู้จัดการโปรเจกต์ที่ไม่เขียนโค้ดและเขียน requirement ได้ไม่ดีด้วย ทำให้หงุดหงิดมากขึ้นได้

  • ต่อไปผมจะหยิบวลี “ความฝันเพ้อไข้ที่มี unit test แปะอยู่” ไปใช้ในการพูดและเขียนของตัวเองอย่างไม่ลังเล

    • แม้แต่ใน multi-agent orchestrator ชื่อดังหลายตัว โมเดลราคาแพงก็ยังสร้าง orchestrator ราว 60% ขึ้นมาแบบหลอนแทบทั้งนั้นในช่วง runtime

  • คล้ายกับประสบการณ์ของผมมากจริง ๆ
    ขอเสริมว่าใช้ Claude Code ดีบักปัญหา Linux desktop ได้ค่อนข้างสำเร็จด้วย
    dotfiles ที่ใช้มา 25 ปีมี ตะกอนทับซ้อนหลายชั้น ที่ดีบักแล้วน่ารำคาญสะสมอยู่ แต่เพราะแชร์ dotfiles ไปหลายเครื่องด้วย yadm โดยไม่มีค่า secret การทำ sandbox เลยง่ายด้วย
    การฝึกนิสัยให้ LLM ตรวจทานการเปลี่ยนแปลงโค้ดก็น่าทำ
    ยังไงก็ต้องมีใครสักคนใช้ LLM ตรวจ commit ของผม ไม่ว่าจะเป็น repo โอเพนซอร์สหรือระบบ production อยู่ดี และที่ Lobsters ในช่วง 2 สัปดาห์ล่าสุด เราได้รับรายงานช่องโหว่ที่ใช้ได้จริง 4 รายการจากคนที่ใช้สแกนเนอร์บน LLM
    ทั้งหมด แก้แล้ว
    ตลอด 9 ปีก่อนหน้านั้น ผมจำได้ว่ามีรายงานคล้าย ๆ กันแค่ประมาณ 2 รายการเท่านั้น

  • การบอกว่า “ไม่เคยเห็นอะไรที่เรียกว่า hallucination ใน frontier model” ฟังดูแปลก
    ในบทความมีหลายจุดที่ผมมองว่าเรียกได้ว่าเป็น hallucination

    • การแยกสิ่งต่อไปนี้ออกจากกันดูสมเหตุสมผล: hallucination (“Lobsters สร้างโดย Paul Graham”), การโกหก/ความขี้เกียจ (“ทำงานเสร็จแล้ว”), การตัดสินใจแย่ (“ตรงนี้ hardcode ค่าไปก็ได้”)
      ถ้าใช้เกณฑ์นั้น ผมก็ไม่เจอ hallucination ในบทความ แต่การโกหก·ความขี้เกียจ·การตัดสินใจแย่ก็ไม่ได้ดีอะไรเช่นกัน
      เหตุผลที่การแบ่งแบบนี้มีประโยชน์คือ hallucination อาจลดได้ง่ายกว่า แต่การโกหก·ความขี้เกียจ·การตัดสินใจแย่นั้นยากกว่า
      ทั้ง hallucination และการโกหกต่างทำให้โมเดลพูดสิ่งที่ผิด แต่ hallucination ใกล้เคียงกับการเกิดจากความไม่รู้หรือข้อมูลไม่พอ และรับมือได้ด้วยการขอแหล่งที่มา หรือฝึกให้หลีกเลี่ยงคำตอบที่อิงข้อมูลอ่อน ๆ
      ในทางกลับกัน การโกหกและความขี้เกียจเป็นผลผลิตของพฤติกรรมมุ่งเป้าหมายกับ reinforcement learning จึงดูเหมือนจะกำจัดด้วยการฝึกได้ยากกว่ามาก

  • ผมมองว่าการใช้ LLM สำหรับ code review มากกว่าการเขียนโค้ดใหม่ โดยเฉพาะในโปรเจกต์คนเดียว ให้ผลตอบแทนต่อความเสี่ยงคุ้มที่สุดแบบหนึ่ง
    ถ้าไม่มี reviewer ประจำที่มีประสบการณ์ การวิเคราะห์ของ LLM ก็พูดตรง ๆ ว่าดีกว่าไม่มีอะไรเลย
    ผมไม่อยากใช้โมเดลคลาวด์เชิงพาณิชย์กับงานโอเพนซอร์ส เลยกำลังทดลอง code review ด้วย LLM แบบ local และสั่งมันว่าอย่าสร้างโค้ดใหม่ ให้แค่อธิบายปัญหาสั้น ๆ
    โมเดล local คงไม่ดีเท่าโมเดลเชิงพาณิชย์ แต่ Qwen 3.6 27B มีประโยชน์พอสมควร
    ตอนรันกับ codebase Rust ขนาดกลาง ประมาณ 70% ถือว่าโอเค ปัญหาที่มันเจอราว 60% ถูกต้อง ราว 20% แม้คุณภาพต่ำแต่ก็ทำให้ไปดูบริเวณโค้ดที่มีปัญหาและนำไปสู่การปรับปรุง ส่วนอีก 20% เป็นขยะ
    การมีขยะเยอะไม่ใช่เรื่องดี แต่ก็ทำให้เห็นทันทีอย่างชัดเจนว่าต้องระวังคำพูดของโมเดล
    ผมไม่รู้ว่ามันพลาดปัญหาจริงไปมากแค่ไหน และบางอย่างที่เจอก็เป็นเรื่องผิวเผินอย่างพิมพ์ผิดในคอมเมนต์เอกสาร แต่โดยรวมแล้วมันทำให้โค้ดดีขึ้น จึงรู้สึกว่าได้กำไรสุทธิ
    ความเสี่ยงคือผมอาจเริ่มพึ่ง LLM โดยไม่ตรวจทานงานตัวเองอย่างละเอียดอีกครั้ง
    แต่โมเดล Qwen ตัวนี้ช้าพอบนเครื่องผม จนไม่อยากรันทุกครั้งที่มีการเปลี่ยนแปลง
    โมเดลอื่นอย่าง Qwen 3.6 35B หรือ Gemma4 26B เร็วกว่ามาก แต่แย่กว่ามากเช่นกัน
    ถึงจะช้าและต้องใช้ฮาร์ดแวร์ แต่ Qwen 27B แสดงให้เห็นว่าอนาคตที่ใช้โมเดล local มาช่วยปรับปรุงโค้ด โดยไม่ต้องพึ่งผู้ให้บริการเชิงพาณิชย์ และไม่พรากความเชี่ยวชาญกับความสนุกของการแฮ็กโค้ดไป อาจเป็นไปได้
    ถึงอย่างนั้น ผมก็ยังมีความรู้สึกซับซ้อนมากกับการเอา LLM เข้าไปอยู่ในกระบวนการ แต่ก็รู้สึกว่าดีกว่าภาพอนาคตแบบทำให้แปลกแยกที่ผู้ให้บริการรายใหญ่ผลักดัน
    เห็นด้วยว่าในบรรดา harness ที่ผมเคยใช้ มีแค่ pi เท่านั้นที่ดูสงบ

    • ผมจะสั่งให้บอทรันก่อน แล้วระหว่างนั้นก็รีวิวของผมเอง จากนั้นค่อยกลับไปดู output ของบอทเพื่อเช็กว่าผมพลาดอะไรไป
      บอทมักจับปัญหาคนละประเภทกับที่มนุษย์จับได้ จึง เสริมกันกับการรีวิวโดยมนุษย์ได้ค่อนข้างดี

  • ใน pi ถ้ากด ctrl+G จะเปิด prompt ใน $EDITOR ได้
    ตามทฤษฎีแล้วน่าจะหา editor ที่รองรับการย้าย cursor ด้วยการคลิกและเหมาะกับความต้องการได้ แม้กระทั่ง editor แบบ terminal UI
    นอกนั้นโดยรวมเห็นด้วยว่าเป็นบทความที่ดี

  • ปัญหา “การชี้ไปที่ข้อความ” ถูกแก้ไปแล้วใน GUI IDE/เอดิเตอร์
    ถ้าใช้ JetBrains IDE ปลั๊กอินสามารถส่งไฟล์และบรรทัดที่เลือกเป็นบริบทของพรอมป์ต์ได้เสมอ
    และจะแสดงความแตกต่างของการเปลี่ยนแปลงแบบอินไลน์หรือในหน้าต่าง diff ตามวิธีที่ร้องขอ

    • ใน Zed ก็มีฟีเจอร์ Inline Assistant ที่ทำงานคล้ายกับวิธีที่ผู้เขียนอธิบายไว้
      เลือกพื้นที่ กด control-enter แล้วป้อนพรอมป์ต์ จากนั้น LLM จะเปลี่ยนและแทนที่ส่วนที่เลือกให้ตรงกับพรอมป์ต์
      ประสบการณ์ผู้ใช้ดีมาก แต่ปัญหาที่มักเกิดกับผลลัพธ์จาก LLM ก็ยังคงอยู่เหมือนเดิม

  • เขาพูดถึงแค่การสมัครสมาชิกเดือนละ $20 ของโมเดล Anthropic และ OpenAI แล้วบอกว่า pi ดีกว่า Claude Code หรือ Codex มาก ถ้าอย่างนั้นก็สงสัยว่าเขาอาจยังไม่ได้ลองใช้ชุด โมเดลฟรอนเทียร์ + pi จริง ๆ หรือเปล่า
    ผมนึกว่าการสมัครสมาชิกจะบังคับให้ต้องใช้ฮาร์เนสนั้นเสียอีก

    • การสมัครสมาชิก Codex ใช้ร่วมกับ Pi ได้แน่นอน

  • เป็นบทความที่มีสามัญสำนึกมากจริง ๆ เลยอ่านแล้วดีใจ
    ผมซื้อโทเคนจาก Novita ที่อยู่ในสหรัฐฯ สำหรับงาน และใช้ DeepSeek กับ Xiaomi เมื่อเร็ว ๆ นี้สำหรับโปรเจกต์ส่วนตัว
    ผมลองใช้ Kimi เองแล้ว แต่ยังไม่ถูกโน้มน้าวพอให้ใช้ต่อ และไม่มีประสบการณ์กับ Claude Code, Codex หรือฮาร์เนสยอดนิยมประจำวันพวกนั้น
    ผมบูตสแตรปฮาร์เนสส่วนตัวสำหรับ Rust + ratatui ด้วย Qwen Code ซึ่งเป็นฟอร์กของอะไรสักอย่างจากฝั่ง Google
    มันใช้ async แบบเธรดเดียว แต่โมเดลชอบเธรดกับ mpsc มากจนต้องคอยเกลี้ยกล่อมค่อนข้างวุ่นวาย
    ขอเสริมว่า smol ผมว่าก็ใช้ได้
    ผลคือผมเข้าใจในระดับหนึ่งว่าเครื่องมือทำอะไรและทำอย่างไร และทุกครั้งที่โมเดลแต่งไวยากรณ์เครื่องมือใหม่ขึ้นมา ผมก็จะชั่งข้อดีข้อเสีย แล้วเพิ่มการแก้ไขเฉพาะกรณีแบบโลคัลเป็นบางครั้ง
    เรื่องพวกนี้ส่วนใหญ่เป็นปัญหาคำพ้องของชื่ออาร์กิวเมนต์เครื่องมือ
    ยิ่งมีพารามิเตอร์ที่เปิดใช้งานน้อย โมเดลก็ยิ่งใส่ใจกับว่าจะทำอะไร แต่ลืมไปว่าจะทำอย่างไร ซึ่งก็เข้าใจได้
    สักวันหนึ่งน่าจะดึง tool call ออกมาจาก latent space แทนที่จะบังคับด้วยโทเคน และบางทีอาจใช้โมเดลแปลเฉพาะทางก็ได้
    ผมใช้ landlock เพื่อกักโมเดลไว้ในไดเรกทอรีโปรเจกต์และตัดออกจากโฮมไดเรกทอรี
    เส้นทางระบบนอกโฮมสามารถอ่านได้ และอนุญาตให้เขียนใน /tmp, ไดเรกทอรีแคชแพ็กเกจบางส่วนในโฮม และที่อย่าง /dev/null
    ต่อไปอาจเพิ่มการแยกกักที่ดีกว่านี้ได้ แต่เมื่อดูว่าคนส่วนใหญ่ที่ผมรู้จักรัน Claude Code ตรง ๆ แบบเดิม ระดับนี้ก็ดูเหมือนสุขอนามัยพื้นฐานแล้ว
    ผมไม่ได้บล็อกเครือข่าย และไม่ได้ทำงานที่ต้องการการป้องกันการรั่วไหลเพิ่มเติม
    การรีวิวโค้ดไม่ได้แม่นเสมอไป
    ถ้ากำหนดแนวทางไว้ก่อน โมเดลก็พอใช้ได้ในการเทียบโค้ดกับแนวทางแล้วชี้จุดที่ไม่ตรงกัน แต่คำขอทั่วไปอย่าง “บอกหน่อยว่าอันนี้ห่วยไหม” ผลลัพธ์จะขึ้น ๆ ลง ๆ
    ใน DeepSeek V4 Flash ที่ผมใช้เป็น baseline ผมยังไม่เคยเจอการแถ
    DeepSeek V4 Pro สำหรับผมเขียนโค้ดแย่กว่า, Xiaomi MiMo 2.5 Pro ดีกว่าแต่แพงกว่านิดหน่อย และ MiMo 2.5 ตัวปกติแย่กว่า
    จากประสบการณ์ของผม โมเดลโดยทั่วไปก็แค่โง่ โดยเฉพาะเมื่อบริบทถูกปนเปื้อนด้วยไอเดียที่ขัดแย้งกันหรือยาวเกินไป
    บางครั้งโมเดลจะตกไปอยู่ในความคิดทำนองว่า “ถ้าจะส่งมอบคุณค่าให้เร็วขึ้นก็ต้องตัดมุมบ้าง” แล้วผมต้องย้อนกลับไปหลายขั้นและให้โมเดลชี้ว่าตรงไหนขัดกับคำสั่งของผม
    บางทีก็เป็นเพราะผมเข้าใจไม่พอ บางทีก็เป็นการออกแบบเกินจำเป็นของโมเดล และบางครั้งมันก็ประนีประนอมด้วยการทำข้อกำหนดให้ง่ายลงเพื่อหลบ edge case ที่ยุ่งยาก
    ผมไม่อยากใช้โมเดลกับการรีแฟกเตอร์
    โมเดลตัดสินใจได้ไม่ดี
    ถ้าให้มันแยกฟังก์ชันหนึ่งออกเป็นสองอันตามสองการใช้งาน แล้วไล่ดูโค้ดเบสเพื่อตัดสินใจว่าแต่ละจุดเรียกควรใช้เวอร์ชันไหน มันจะผิดราว 25% โดยไม่แสดงสัญญาณความไม่แน่ใจเลย
    ให้โมเดลสำรวจโค้ดเบสและแมปขอบเขตผลกระทบ แล้วค่อยรีแฟกเตอร์เองยังดีกว่ามาก
    การจัดเรียงใหม่ที่ง่ายมาก เช่น การเปลี่ยนโครงสร้างเรียบง่ายที่ครอบงานหลายจุด ช่วยเร่งงานได้ แต่ก็ต้องสั่งให้มันตรวจอย่างชัดเจนด้วยว่ามีคอมเมนต์เก่าหรือชื่อตัวแปรที่ไม่เหมาะแล้วหรือไม่
    ต่างจากต้นฉบับ ผมไม่เคยมีประสบการณ์ว่าโมเดลพยายามทำสิ่งที่ผมไม่ได้ขอเอง
    อาจเป็นเพราะผมต้องการแผนล่วงหน้าที่ชัดเจนก่อนอนุญาตให้แก้ไข และดูสายการให้เหตุผลแบบเรียลไทม์ พอโมเดลเริ่มแปลกก็พรอมป์ต์ใหม่
    สำหรับโค้ดงาน ผมจะไม่คอมมิตจนกว่าจะอ่านและเข้าใจทุกอย่าง
    ในขั้นนี้ผมจะแก้ไขครั้งใหญ่หลายอย่าง แล้วค่อยให้โมเดลตรวจอีกที
    แบบนั้นมันมักหา typo, ตัวแปรสลับกัน และเรื่องเล็ก ๆ ที่อาจกลายเป็นปัญหาได้ดี
    เวอร์ชันแรกของโปรเจกต์ส่วนตัวเป็นเวอร์ชันที่ทิ้งไปได้เลย
    พอสถาปัตยกรรมจริงชัดเจนขึ้น ก็ต้องเขียนใหม่ทั้งหมด และคราวนี้วางแผนล่วงหน้าให้ถูกต้อง
    วิธีนี้อาจถูกประเมินค่าต่ำไปนิด
    โมเดลที่ผมใช้ค่อนข้างเร็ว
    ถ้าไม่ได้ขอให้มันทำการสำรวจยาว ๆ อย่างชัดเจน ก็ไม่จำเป็นต้องสลับไปทำงานอื่น และถ้าโมเดลใช้เวลานานเพื่อโน้มน้าวตัวเองว่า strawberry มีตัว r กี่ตัว ผมก็มักจะคิดขั้นตอนต่อไปไปด้วย
    วิธีที่ได้ผลอยู่บ้างคือให้โมเดลทำแผน เขียนแผนนั้นลงไฟล์อย่างชัดเจน แล้ววนปรับปรุงเล็กน้อย
    โมเดลช่วยค้นโค้ดเบสและทำความเข้าใจขอบเขตผลกระทบก่อนเริ่มเขียนโค้ดได้ และเมื่อมีแผนล่วงหน้าที่มองเห็นได้ ก็ทำให้คุมโมเดลให้อยู่ในทางได้ง่ายขึ้น
    ในแง่การค้นหาหรือแรงงานราคาถูก ผมเคยใช้โมเดลหางานวิจัยในหัวข้อเฉพาะ ซึ่งก็ไม่เลว
    จากนั้นผมดึงงานวิจัยมาเองผ่านการสมัครสมาชิกหรือช่องทางอื่น แล้วให้โมเดลอ่านเพื่อตัดสินว่าเกี่ยวข้องกับหัวข้อหรือไม่ ซึ่งจริง ๆ แล้วได้ผลค่อนข้างดี
    งานวิจัยที่เกี่ยวข้องผมก็กลับไปอ่านเองอีกที
    การให้มันสำรวจโค้ดเบสขนาดใหญ่และอธิบายแง่มุมเฉพาะบางอย่างก็มีประสิทธิผลอยู่บ้าง
    สิ่งที่เหมือนกันในสองกรณีคือโมเดลหลอนค่อนข้างมาก
    อัตราการหลอนได้รับผลกระทบอย่างมากจากว่าข้อเท็จจริงสำคัญถูกฝังลึกแค่ไหนในบริบท
    พอให้มันจัดหมวดหมู่และสรุปงานวิจัยหนึ่งฉบับ แล้วล้างบริบทก่อนจัดการฉบับถัดไป ปัญหาก็ลดลงมาก
    น่าจะเกี่ยวข้องกับ sparse attention แต่ผมไม่ใช่ผู้เชี่ยวชาญ
    สำหรับการระดมสมองและความคิดสร้างสรรค์ มันไม่มีประโยชน์
    ผมไม่เคยมีประสบการณ์ว่า DeepSeek V4 Flash โกหกว่าได้รันเทสต์หรือ type check แล้วเลย
    บางครั้งมันควบคุมได้ยากมาก แต่กลับมีแนวโน้มจะรันเทสต์และ type check ซ้ำ “เพื่อให้แน่ใจ” แม้จะแค่แตะคอมเมนต์นิดหน่อย
    และผมไม่เห็นด้วยว่านี่คือสิ่งที่น่าสนใจที่สุดในชีวิตผม