Claude Fable เคลื่อนไหวอย่างเชิงรุกไม่หยุดยั้ง

 (simonwillison.net)
3 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ผลการทดลองตลอด 2 วันบ่งชี้ว่าเหมาะจะอธิบาย Claude Fable 5 ว่า "relentlessly proactive"
  • เพียงมีสกรีนช็อตและพรอมป์ต์บรรทัดเดียว ก็สามารถรัน local development server, ควบคุมเบราว์เซอร์จริง, และแทรกโค้ดสำหรับวัดผลเพื่อตามหาสาเหตุของบั๊ก CSS ได้
  • Fable พยายามทำซ้ำบั๊กโดยสลับใช้ Playwright, Firefox, WebKit และ Safari และหลังจากล้มเหลวก็ไปหา browser window จริงแล้วตั้งค่า การทำสกรีนช็อตอัตโนมัติ ด้วยตัวเอง
  • เพื่อทดสอบ modal dialog ที่เปิดด้วยปุ่ม / จึงแทรก JavaScript ลงในเทมเพลต Datasette และสร้างสถานะที่ต้องการด้วยการยิง keyboard event หลังหน้าต่างโหลดเสร็จ
  • เพื่อดึงค่าการวัดจากภายในหน้า จึงสร้าง CORS collection server บนพื้นฐาน Python http.server และบันทึกข้อมูล <textarea> ภายใน shadow DOM ของ Web Component เป็น JSON
  • coding agent ที่ทรงพลังสามารถทำสิ่งที่ผู้ใช้ทำได้ในเทอร์มินัล จึงทำให้การรันนอก sandbox เพิ่มความเสี่ยงจาก prompt injection และการรั่วไหลของข้อมูล

กระบวนการดีบักของ Claude Fable 5

  • เริ่มจากตรวจสอบแถบเลื่อนแนวนอนที่ไม่จำเป็นซึ่งเกิดขึ้นใน jump menu chat prompt ของ Datasette Agent
  • Claude Fable 5 ระดมเทคนิคหลากหลายอย่างเชิงรุกเพื่อให้บรรลุเป้าหมาย
  • อินพุตมีเพียงสกรีนช็อตและพรอมป์ต์หนึ่งบรรทัดว่า Look at dependencies to help figure out why there is a horizontal scrollbar here
  • มีการขอให้เริ่มดูโค้ดของ dependency ก่อน เพราะประเมินว่าสาเหตุของปัญหาอาจอยู่ที่ dependency ของ Datasette Agent โดยเฉพาะ Datasette เอง
  • Claude Code เปิดหน้าต่าง Firefox ปกติและไปยัง dialog นั้นโดยไม่มีคำสั่ง automation ของเบราว์เซอร์อย่างชัดเจน จากนั้นยังเปิดหน้าต่าง Safari เพื่อสำรวจต่อ

การทำสกรีนช็อตเบราว์เซอร์อัตโนมัติ

  • Fable ตั้งค่ากลไกของตัวเองสำหรับจับสกรีนช็อตหน้าต่างเบราว์เซอร์โดยใช้ uv run --with pyobjc-framework-Quartz
  • ใช้ Python วนดูทุกหน้าต่างในเครื่อง แล้วกรองหน้าต่าง Safari ที่ชื่อหน้าต่างมีสตริงที่คาดไว้ เช่น "textarea"
  • หลังพบตัวระบุแบบจำนวนเต็มของหน้าต่าง เช่น 153551 ก็ใช้ CLI screencapture เพื่อบันทึกเป็น PNG
  • เขียนหน้า HTML ชั่วคราวเช่น /tmp/textarea-scrollbar-test.html แล้วเปิดใน Safari เพื่อเก็บสกรีนช็อต
  • ตัวอย่างคำสั่งคือ screencapture -x -o -l 153551 /tmp/safari-cases.png

การสั่งรัน modal dialog อัตโนมัติ

  • modal ที่ต้องทดสอบเปิดได้เฉพาะด้วยการคลิกหรือคีย์ลัด และไม่เห็นกลไกชัดเจนสำหรับสั่งเลื่อนเมาส์หรือกดคีย์ลัดภายใน Safari
  • Claude รันอยู่ในโฟลเดอร์ที่มีซอร์สโค้ดของแอปพลิเคชัน และเข้าใจโครงสร้างมากพอที่จะรัน local development server ของ Datasette ได้
  • จึงเพิ่ม JavaScript ลงในเทมเพลต Datasette เพื่อจำลองการกดปุ่ม / หลังหน้าต่างเปิดขึ้น
  • โค้ดนี้จะยิง event keydown ของปุ่ม / หลังหน้าโหลดเสร็จ 1.2 วินาที เพื่อเรียกคีย์ลัดที่ใช้เปิด modal dialog
<script>  
window.addEventListener("load", function () {  
  setTimeout(function () {  
    document.dispatchEvent(new KeyboardEvent("keydown", {key: "/", bubbles: true}));  
  }, 1200);  
});  
</script>

การเก็บค่าการวัดจากภายในหน้า

  • Claude จำเป็นต้องรัน JavaScript บนหน้าเพื่อดึงค่าการวัดโดยตรง และเพื่อทำเช่นนั้นจึงเขียนเว็บแอปของตัวเองเพื่อรับข้อมูลผ่าน CORS
  • ใช้ http.server จาก Python standard library เพื่อรัน local server ที่ 127.0.0.1:9999
  • เซิร์ฟเวอร์รับคำขอ POST ที่มี JSON แล้วบันทึกลง /tmp/diag.json พร้อมส่ง header Access-Control-Allow-Origin: * เพื่อให้โค้ดจากโดเมนอื่นสื่อสารได้
  • Claude แทรก JavaScript ลงในเทมเพลตที่โหลดในเบราว์เซอร์เพื่อค้นหา <textarea> ภายใน Web Component <navigation-search>
  • โค้ดที่แทรกจะวัดค่า devicePixelRatio, scrollWidth, clientWidth, whiteSpace, width แล้วส่งไปยัง local server
const host = document.querySelector("navigation-search");  
const ta   = host.shadowRoot.querySelector("textarea");  
const cs   = getComputedStyle(ta);  
fetch("http://127.0.0.1:9999/diag";, {  
  method: "POST",  
  body: JSON.stringify({  
    dpr: window.devicePixelRatio,  
    scrollWidth: ta.scrollWidth, clientWidth: ta.clientWidth,  
    whiteSpace: cs.whiteSpace, width: cs.width,  
  }),  
});

การสลับไปใช้ Opus และการตรวจสอบการแก้ไข

  • หลังค้นพบเทคนิคหลายอย่าง Fable ก็ชนกับ guardrail ที่มองไม่เห็นและ ถูก downgrade ไปเป็น Opus
  • Opus เข้าถึงประวัติการสนทนาทั้งหมดได้ และ ใช้งานเทคนิคที่ Fable บุกเบิกไว้ต่อ
  • จากนั้น Opus ค้นหาปัญหา ทดสอบ และยืนยันผล ก่อนจะทำ commit แก้ไข เสร็จ
  • Opus สรุปเทคนิค automation และตัวอย่างโค้ดที่ใช้กับเบราว์เซอร์จริงในเซสชันนี้ไว้ใน /tmp/automation-report.md
  • รายงานดังกล่าวถูกแชร์เป็น gist แยก และบันทึกเทอร์มินัล Claude Code แบบเต็มก็ เปิดเผยสู่สาธารณะ

ทบทวนงานทั้งหมดที่ทำ

  • Claude Fable 5 และ Claude Code หาวิธีรัน local development server ได้ และยังตั้งค่า environment variable ปลอมที่จำเป็นต่อการรัน
  • รัน Playwright Chrome session และเปิดการตั้งค่า visible scrollbar ของ Chrome ด้วย defaults write com.google.chrome.for.testing AppleShowScrollBars Always ก่อนจะปิดกลับในภายหลัง
  • ลองวนใช้ทั้ง Playwright Firefox และ WebKit แต่ไม่สามารถทำซ้ำบั๊กได้
  • ตรวจพบว่าเบราว์เซอร์เริ่มต้นคือ Safari และสร้างเอกสาร HTML textarea-scrollbar-test.html
  • เปิดเอกสารทดสอบใน Firefox จริง และการเข้าถึง osascript ถูกบล็อกเพราะ “osascript is not allowed assistive access”
  • ค้นพบวิธีอ้อมด้วย pyobjc-framework-Quartz และจัดทำ workflow สกรีนช็อตตามหมายเลขหน้าต่าง
  • เพิ่ม JavaScript ลงในเทมเพลตของไซต์เพื่อยิงปุ่ม / และรับข้อมูล JSON ผ่าน Python CORS server
  • ค้นหาข้อมูลที่ต้องการผ่าน shadow DOM ของ Web Component และยืนยันสาเหตุของบั๊กใน Safari
  • ทดลองใส่แนวทางแก้ที่เป็นไปได้ลงในเทมเพลตแบบกำหนดเอง แล้วยืนยันการทำงานก่อนรายงานวิธีแก้ปัญหา

การประเมินค่าใช้จ่าย

  • แพลนที่ใช้อยู่คือ Claude Max ราคา $100 ต่อเดือน โดย Anthropic ระบุว่าจะให้โควตา Fable แบบค่อนข้าง generous จนถึงวันที่ 22 มิถุนายน แล้วหลังจากนั้นจะคิดราคาตาม API เต็ม
  • AgentsView ถูกใช้เพื่อติดตามค่าใช้จ่าย และหากจ่ายราคาปกติเต็ม เซสชันนี้จะมีค่าใช้จ่ายราว $12.11
  • เอาต์พุตของเซสชันคือ 68606, context สูงสุดคือ 113178, และโมเดลที่ใช้คือ claude-fable-5 กับ claude-opus-4-8
  • หากไม่จับตาเรื่องต้นทุน Fable สามารถ คิดวิธีใหม่ขึ้นมาเพื่อดีบัก CSS และเผาค่า token ประมาณ $12 ได้อย่างง่ายดาย

ความจำเป็นของ sandbox

  • กระบวนการที่ Fable ถึงขั้นใช้ วิธีสุดโต่ง เพื่อให้ได้ข้อมูลที่จำเป็นสำหรับการแก้ CSS สองบรรทัดนั้นน่าประทับใจ
  • coding agent สามารถทำสิ่งที่ผู้ใช้ทำได้ด้วยการพิมพ์คำสั่งในเทอร์มินัล และ frontier model ก็รู้เทคนิคจำนวนมหาศาล
  • หากมีคำสั่งอันตราย, prompt injection ในโค้ดหรือ issue thread, หรือข้อความที่วางลงเทอร์มินัลอย่างไม่ระวัง ก็อาจนำไปสู่ข้อมูลรั่วไหลหรือความเสียหายอื่นได้
  • การรัน coding agent นอก sandbox เป็นความคิดที่ไม่ดีเสมอ และถือเป็นผู้เข้าข่ายสำคัญของเหตุการณ์ด้านความปลอดภัยจาก coding agent
  • Fable อาจฉลาดพอจะระแวงคำสั่งอันตรายมากขึ้น แต่หากหลงเชื่อคำสั่งเมื่อใด ความเชิงรุกอย่างไม่หยุดยั้งก็อาจขยายขนาดความเสียหายได้

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

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

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

  • นี่อ่านแล้วเหมือนเป็นกรณีตัวอย่างที่น่าประทับใจซึ่งแสดงให้เห็นถึง การสูญเสียความเป็นผู้ริเริ่มของมนุษย์อย่างร้ายแรง และคอมมิตจริงก็เผยอะไรไว้ค่อนข้างมาก [0]
    ผู้เขียนแค่อยากซ่อนแถบเลื่อนแนวนอน นักพัฒนาฟรอนต์เอนด์ระดับจูเนียร์ที่พอใช้ได้คงจะถามทันทีว่า “จะใส่ overflow-x: hidden; ไว้ตรงไหนดี?” วิธีแก้ที่สมบูรณ์คือกด “Inspect element” ในเบราว์เซอร์เพื่อหาคลาส CSS แล้วใช้ (rip)grep หาในโค้ดและเพิ่มเข้าไปหนึ่งบรรทัด
    โปรแกรมเมอร์ที่มีความเป็นผู้ริเริ่มมากกว่านั้นคงจะถามว่าในกล่องข้อความว่างมีคอนเทนต์อะไรถึงล้น ทำไมต้องใส่วิธีเลี่ยงที่แค่ปิดอาการแทนจะแก้ต้นตอสองจุด และทำไมไม่สไตล์ textarea แค่ครั้งเดียวให้จบ
    [0] https://github.com/datasette/datasette-agent/commit/a75a8b72...

    • ก่อนจะไปแก้รายละเอียด CSS ก็น่าจะถามได้เหมือนกันว่าทำไม CSS แบบสแตติกจาก JavaScript หลายจุดถึงไปซ่อนอยู่ใน __init__.py [0]
      จากประสบการณ์ที่ฉันใช้ Claude มา โดยทั่วไปมันออกโค้ดที่มีโครงสร้างดี เลยค่อนข้างแปลกใจอยู่เหมือนกัน แต่ของฉันใกล้เคียงกับการถกเถียงแบบโสกราตีสอย่างเป็นกันเองกับวิศวกรอีกคนที่เป็นหุ่นยนต์ มากกว่าจะเป็น vibe coding แบบเต็มตัว
      [0] https://github.com/datasette/datasette-agent/blob/main/datas...
    • ดูเหมือนโมเดลนี้จะทำผลงานได้ดีในส่วนที่เดิมก็สเกลได้อยู่แล้ว นั่นคือ ความยาวและความซับซ้อนของงานตามคำขอ แต่สำหรับเรื่องที่จนถึงตอนนี้ยังสเกลไม่ได้ดีอย่าง สามัญสำนึก วิจารณญาณ และการตัดสินใจ ก็ดูเหมือนจะยังไม่ได้ดีขึ้นมากนัก
    • เห็นด้วยแบบตรงเผง Simon โยนงานจุกจิกแบบนี้ให้ LLM ทำ เลยพลาดโอกาสที่จะประเมินและปรับปรุง abstraction จากข้อมูลเพิ่มเติม แทนที่จะได้เรียนรู้อะไร เขากลับปล่อยให้เอเจนต์ใช้เงินไป 12 ดอลลาร์ เพื่อแก้มัน แล้วสุดท้ายก็ไม่ได้เรียนรู้อะไรเลย
    • Fable ดูเหมือนจะมีแนวโน้มพยายามตรวจสอบการแก้ไขของตัวเอง ซึ่งในตัวมันเองถือว่าดีมาก ถ้าจะทำให้ Opus ทำสิ่งที่ Fable ทำได้เองโดยไม่ต้องมีพรอมป์ต์ ก็ต้องใส่พรอมป์ต์เพิ่มพอสมควร
      นั่นก็ตรงกับสิ่งที่ฉันคาดหวังจากนักพัฒนาระดับจูเนียร์พอดี คือยืนยันว่าบั๊กมีอยู่จริง หาวิธีแก้ และตรวจสอบว่าบั๊กถูกแก้แล้ว
      ปัญหาคืออย่างที่บทความบล็อกชี้ไว้ชัดเจน แทนที่จะหยุดแล้วถามเมื่อ ต้องการสิทธิ์ระดับสูงกว่า มันกลับพยายามหาทางอ้อมแบบแฮ็กๆ ด้วยตัวเองไม่รู้จบ ถ้าเทียบเป็นนักพัฒนามนุษย์ก็เหมือนต้องใช้สิทธิ์เข้าถึง sandbox ของบุคคลที่สาม แต่แทนที่จะขอข้อมูลรับรองจากรุ่นพี่ กลับพยายามสร้าง sandbox ของตัวเองขึ้นมาใหม่ตั้งแต่ต้น
    • พูดตรงๆ มันดูเหมือนวิธี ทำเงินเกินพอดี จากแรงกระตุ้นอะไรก็ตาม
      มันทำให้นึกถึงสมัยก่อนที่การเข้าโลกออนไลน์ถูกคิดเงินเป็นรายนาที ตอนนั้นมีแรงจูงใจสูงมากที่จะทำให้มิเตอร์วิ่งต่อไป และนี่ก็ดูเหมือนจะเป็นอะไรทำนองนั้น

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

    • ยกตัวอย่างได้น่าสนใจดี การขับรถเป็นกิจกรรมที่แม้จะปฏิบัติตามกฎความปลอดภัยทุกข้อ ก็ยังจัดว่าเกือบจะอันตรายที่สุดอย่างหนึ่งในบรรดาสิ่งที่เราทำกันเป็นประจำทุกวัน แต่ถึงอย่างนั้นเราก็ตัดสินใจว่า ประโยชน์มากกว่าความเสี่ยง อยู่ดี
    • ทุกวันนี้ทุกคนถูกคาดหวังให้ทำงานต่อวันได้เพิ่มขึ้น 10 เท่า พอถึงจุดนั้น การตรวจสอบด้านความปลอดภัยก็ถูกโยนทิ้งออกนอกหน้าต่างไปเลย
    • ฉันลองทำแบบนั้นมาตั้งแต่หลายเดือนก่อนแล้ว และพูดตรง ๆ คือสิ่งที่ agent จะทำก็ไม่ได้คาดเดาไม่ได้ขนาดนั้น
      ปัญหาคือแต่ละคนให้พรอมป์ตต่างกันมากเกินไป
      เช่น ฉันอาจขอว่า “ลองทดสอบ annotation นี้หลาย ๆ แบบบน k8s pod ของ service นี้ในคลัสเตอร์ X หน่อย เพราะมันจะพิสูจน์ทฤษฎี Y ได้” แต่เพื่อนร่วมงานอาจพูดแค่ว่า “ลองทดสอบทฤษฎี Y ดู” ถ้าถามวิศวกรจูเนียร์สองคนแบบนั้น คนหนึ่งอาจไปลองสุ่ม ๆ บน production ส่วนอีกคนอาจรัน local test แทน มันคือคำขอแบบ ไม่มีการกำหนดทิศทาง ในลักษณะ “ทำอะไรก็ได้ที่อยากทำเพื่อหาคำตอบมา” และ agent ก็อ่านมันเหมือนวิศวกรจูเนียร์ที่ไม่ได้รับการบอกขอบเขต แต่ถูกกดดันอย่างหนักให้ “หาคำตอบมาให้ได้”
    • อีกเรื่องที่ทำให้งงคือ หลายคนคิดว่าตัวเองมี sandbox ที่มีประสิทธิภาพ แต่ agent ใน sandbox นั้นกลับมี สิทธิ์เข้าถึงโค้ดทั้งหมด, GitHub, และเว็บแบบไม่จำกัด
    • ฉันรู้ว่ามีทางออกแบบ VM แต่ฉันพอใจกับวิธีตั้งชื่อผู้ใช้ OS แยกต่างหากเป็น claude
      มันมี dotfile คล้ายของฉัน แต่ไม่มี secret ใด ๆ โฮมไดเรกทอรีของฉันเป็น 0700, claude มี SSH key แยกของตัวเอง และฉันเพิ่มมันเข้าไปในโปรไฟล์ GitHub ของฉันแล้วแต่ใส่รหัสผ่านไว้ ส่วน push/pull ฉันเป็นคนทำแทน นอกจากนี้ยังมีผู้ใช้และฐานข้อมูล Postgres สำหรับ dev/test แยกต่างหาก และไม่ใช่ superuser
      เรียกได้ว่าปฏิบัติกับมันเหมือนนักพัฒนาคนอื่นในโปรเจ็กต์ ถ้าต้องรันอะไรด้วย sudo ก็ต้องมาถามฉัน บางครั้งเราสองคนก็อาจทำงานเดียวกันแบบขนานกันได้ ตั้งแต่แรก Unix ก็ถูกออกแบบมาให้เป็นระบบหลายผู้ใช้อยู่แล้ว
      เคล็ดลับที่ฉันใช้บ่อยคือเพิ่ม remote พิเศษแบบนี้ใน git repository ของมัน:
      paul ssh://paul@localhost/~/src/example (fetch)
      paul ssh://paul@localhost/~/src/example (push)
      ทำให้ร่วมงานกันกับสิ่งที่ยังไม่พร้อมแชร์ได้ง่ายขึ้นมาก
      การตั้งค่านี้ค่อนข้างสบายใจทีเดียว แต่ก็ยังกังวลเรื่องบั๊กยกระดับสิทธิ์บน Linux ฉันไม่เชื่อว่า AI จะเข้าใจจริง ๆ ว่าห้าม exploit ช่องโหว่ ย้อนให้นึกถึงตอนงานแรกของฉัน เวลารีบ ๆ ฉันเคยใช้ฟังก์ชัน :! ของ vim ผิดพลาดเพื่อขยายสิทธิ์ sudo ที่ตามทางการจำกัดไว้สำหรับแก้ httpd.conf ทุกวันนี้ถึงจะมี automatic security update ฉันก็ยังอัปเดตแพ็กเกจเองบ่อยกว่าเดิม ฉันไม่คิดว่า Opus จะถึงขั้นไปค้นหาช่องโหว่ความปลอดภัยเอง แต่ Fable อาจจะทำ และช่วงหลัง ๆ ก็มีช่องโหว่แบบนั้นเยอะอยู่ โมเดลในอนาคตอาจค้นหาช่องโหว่ใหม่ ๆ ได้เอง หรือถึงขั้นติดตั้ง keylogger เพื่อพยายามเรียนรู้รหัสผ่านของ SSH key ก็ได้
      ผู้ใช้แยกต่างหากถือว่าเป็นการตั้งค่าที่เกือบจะระแวงสุดโต่งที่สุดเท่าที่ฉันเคยได้ยินมา ถ้าไม่นับการใช้เครื่องแยกไปเลย เลยก็อดสงสัยไม่ได้ว่าฉันกำลังเสียสละความเร็วกับความสะดวกมากเกินไปหรือเปล่า แต่ในทางปฏิบัติมันก็ยังสะดวกมากอยู่ดี และฉันมองว่าเป็นวิธีที่ทั้งมีประสิทธิภาพและมีความรับผิดชอบ ถ้าใครเห็นช่องโหว่ก็อยากฟัง

  • Fable ให้ความรู้สึกเหมือน “Opus ที่รันอยู่บน harness ที่ไม่ยอมให้หยุดจนกว่าจะมั่นใจว่าปัญหาถูกแก้แล้ว” ถ้าคุณอยากได้โมเดลที่ทำ benchmark ได้ดีกว่า นี่ก็เป็นทิศทางที่สมเหตุสมผล
    มันเป็นโมเดลที่ดีมาก แต่ มีต้นทุนพรีเมียมสูง ไม่ใช่แค่ token แพงกว่าเท่านั้น แต่ตัวโมเดลเองก็อยากใช้ token พวกนั้นให้หมดด้วย เช่น ในงาน React Native นั้น Fable จะไม่พูดว่า “โอเค ทำได้แล้ว จบ” แต่มันจะพยายาม build แอปทั้งตัวใหม่ตั้งแต่ต้น, รันชุดทดสอบทั้งหมด, แล้วเฝ้าดู log และ warning ทุกอย่าง
    เป็นครั้งแรกตั้งแต่ใช้ LLM มา ที่ฉันรู้สึกว่าต่อให้บริษัทอนุญาต การอัปเกรดโมเดลก็ไม่คุ้มค่า เพราะ build กับ test มันใช้งานเครื่องและแบตเตอรี่ของฉันหนักเกินไปจนทำอย่างอื่นไม่ได้
    ตอนนี้ดูเหมือนใช้ ultracode กับ Opus จะดีกว่า การปนเปื้อนของบริบทหลักน้อยกว่า และงานค้นคว้าก็ขนานได้มากกว่า

    • ถ้าใช้การตั้งค่า effort ระดับ low/medium จะไม่ช่วยเหรอ? Fable 5 low ดูเหมือนจะดีกว่า Opus 4.8 high/xhigh บ่อยกว่า และยังใช้ token น้อยกว่ามากด้วย
    • ประสบการณ์ของฉันกลับตรงกันข้ามนะ แน่นอนว่าฉันใช้ sub-agent เยอะ แต่ฉันเคยปล่อยให้มันรันต่อเนื่องได้หลายชั่วโมงด้วย token น้อยกว่าสมัยใช้ opus4.6-8 เสียอีก
    • อยากรู้ว่ารันในสภาพแวดล้อมไหนและใช้การตั้งค่าอะไร ฉันใช้ส่วนขยาย VSCode ที่ Extra High และรู้สึกว่ามันทำเฉพาะสิ่งที่จำเป็นต่อสิ่งที่ขออย่างแม่นยำ แล้วพอเสร็จก็หยุด คอมเมนต์เพิ่มเติมก็จะมีเฉพาะตอนเกี่ยวข้องกับบริเวณโค้ดที่เปลี่ยน
    • การตั้งค่า high effort ใหม่แรงเกินไป จนถ้าเลือกใช้ตอนที่งานไม่ได้ต้องการ มันกลับเหมือนส่งผลเสียต่อคุณภาพของเอาต์พุตด้วยซ้ำ
    • โดยทฤษฎีแล้วฉันชอบความ proactive แบบนี้นะ แต่ก็แพงอย่างที่ว่า เลยสงสัยว่าอาจแก้ได้ด้วยพรอมป์ตที่เหมาะสมหรือเปล่า เช่น “นี่คือข้อจำกัด แก้แค่ x เท่านั้น ถ้าไม่แน่ใจว่างานอยู่นอกข้อจำกัดนี้หรือไม่ ให้ถามฉันก่อน”

  • Fable เคยพยายามตรวจสอบการเปลี่ยนแปลง UI ในเกมของฉัน ตอนนั้นฉันกำลังทำงานอยู่อีกหน้าต่างหนึ่ง แล้วเห็นโปรแกรมเด้งขึ้นมาบน taskbar Fable เปิดเกมจาก CLI ด้วย เครื่องมือ movie maker, อัดวิดีโอเอาต์พุต, แล้วจับเฟรมสุดท้ายมาเพื่อตรวจสอบ UI พอหน้าจอต้อนรับของเกมบังส่วนที่มันอยากดู มันก็สร้าง worktree ชั่วคราว ลบหน้าจอต้อนรับออก แล้วรัน movie maker ใหม่
    ตอนดูขั้นตอนนั้น ฉันคิดแค่ว่าถ้ามันขอ screenshot จากฉันตรง ๆ ก็น่าจะประหยัด token ได้ แต่ถึงอย่างนั้นก็อดทึ่งไม่ได้อยู่ดี Opus ไม่มีทางทำแบบนั้นแน่

    • นี่จับประเด็นหลักของปัญหาเวลาที่โมเดล proactive แบบไม่สิ้นสุดได้ตรงมาก มันยอมเผา token มูลค่า 5 ดอลลาร์ อย่างเต็มใจเพื่อไม่ต้องถามมนุษย์ให้ช่วยถ่าย screenshot หรือกดปุ่มให้
    • ก็บอกมันตรง ๆ แบบนั้นได้เลย ฉันก็เคยเจอแบบนั้นเหมือนกัน แต่หลังจากสั่งให้ปล่อยงานรีวิวไว้ให้ฉันทำ Fable ก็มีประโยชน์มากกับงานวนซ้ำฝั่งฟรอนต์เอนด์อยู่หลายชั่วโมง โดยไม่ใช้ token เยอะเกินไป

  • บทความแบบนี้ให้ความรู้สึกเหมือนมาจากจักรวาลคู่ขนาน จากประสบการณ์ส่วนตัวของฉัน และจากเบนช์มาร์กที่ฉันทำเองซึ่งแม้จะยังเป็นเรื่องอัตวิสัยอยู่ (https://pshirshov.github.io/llm-bench-pi-oneshot/) Fable ไม่ได้น่าประทับใจขนาดนั้น
    มันอยู่ประมาณระดับ gpt-5.5 กับ opus 4.8 บางครั้งก็ดีกว่า บางครั้งก็แย่กว่า แถมแพงกว่าชัดเจน และยังเคยปฏิเสธคำถามเกี่ยวกับ React โดยบอกว่าเคมีช่วยไม่ได้
    ฉันไม่แน่ใจว่าความวุ่นวายนี้มีมูลจริงหรือเป็นแค่ การปั่น AGI ก่อน IPO

    • หลังเปิดตัวมา ประสบการณ์ของฉันกับ Fable ก็สอดคล้องกับของ Simon
      ฉันให้ Fable คอยประสานงานการ implement ที่ซับซ้อน ฉันให้ตั๋วระดับบนจาก Linear ไปแล้วบอกว่า “ดู sub-issues ของตั๋วนี้ แล้วตัดสินใจว่าอันไหนที่คุณลงมือ implement เองได้ ควรทำตามลำดับไหน และต้องประสานกับสิ่งที่สมาชิกทีมคนอื่นกำลังทำอยู่ตอนนี้อย่างไร” ตั๋วพวกนี้ไม่ใช่งานเล็ก ๆ มีหลายส่วนที่ขยับไปมาและมี dependency จำนวนมาก และยังเชื่อมโยงทั้งในและนอกโปรเจกต์เดียวกัน เช่น ฝั่ง backend ด้วย
      แล้ว Fable ก็จะเลือกตั๋วและมอบหมายแต่ละตั๋วให้ sub-agent (ซึ่งก็เป็น Fable เหมือนกัน) sub-agent จะดูดีไซน์ใน Figma ของตั๋วนั้น ปฏิบัติตามแนวทางและธรรมเนียมของรีโพอย่างเคร่งครัด implement ออกมาได้อย่างสมบูรณ์ ถ่าย screenshot ของแต่ละส่วน เขียน commit message และคำอธิบาย PR อย่างละเอียด แล้วแนบ screenshot เป็นหลักฐาน สุดท้ายมันจะสรุปให้ประมาณว่า “ต้อง merge PR #1283 ก่อน และเผื่อไว้ด้วยว่าหน้าจอบางอันไม่มีดีไซน์ใน Figma แต่ฉันดูหน้าคล้าย ๆ ที่มี implement ไว้แล้วแล้วนำแพตเทิร์นนั้นมาใช้”
      นี่น่าจะเป็นแค่ราว 20% ของสิ่งที่ Fable ทำได้ มันเป็นโมเดลที่ทรงพลังมากจริง ๆ
      Opus 4.8 ก็ทำงานพวกนี้ได้หลายอย่างเหมือนกัน แต่ต้องคอยประคองมากกว่าเยอะ และถ้าเจอจุดที่ติด มันก็มักจะหยุดพร้อมบอกว่า “ฉันทำได้ถึงตรงนี้ แต่ไปต่อไม่ได้”

  • Fable ฉลาดกว่าอยู่นิดหน่อย แต่เพราะอย่างนั้นเองมันเลยให้ความรู้สึกว่าเป็นเครื่องมือที่แย่กว่าเมื่อมองภาพรวม
    มันชอบเปลี่ยน แพตช์ 50 บรรทัด ที่ควรจบได้ด้วยพรอมป์ครั้งเดียว ให้กลายเป็นการสำรวจยาว 30 นาทีอยู่เรื่อย ๆ ทั้งที่บ่อยครั้งไม่คุ้มเลย แถมยังผิดบ่อยด้วย
    ฉันทดลองกับงานที่ค่อนข้างง่าย เป็นการ backfill แคช deduplication ของ redis ตอนที่ hash function เปลี่ยนไป จริง ๆ แค่รัน hash function ใหม่กับค่าใน DB ทั้งหมดแล้วขยายแคชก็พอ แต่ Fable กลับไป implement การอัปเดตแคชที่ซับซ้อนเกินจำเป็น โดยพยายามเดาเวอร์ชัน hash function ของแต่ละค่าในแคชแล้วคำนวณใหม่เฉพาะ hash เก่า ในบางบริบทมันอาจพอฟังขึ้น แต่ผลลัพธ์จากการเผาโทเค็นไป 30 นาทีคือโค้ดที่ฉันแทนที่ด้วย for loop 10 บรรทัด
    มันทำให้ฉันกังวลว่าเป็นข่าวร้ายต่อการเขียนโปรแกรมโดยรวม ดูชัดเจนมากว่าเทคโนโลยี LLM ชนเข้ากับกำแพงของผลตอบแทนที่ลดลงในด้านความฉลาดแล้ว และถ้าวิธีรับมือคือทำให้มันดื้อดึงมากขึ้นเฉย ๆ นั่นก็เป็นทางออกที่แย่มากสำหรับทุกคนที่เกี่ยวข้อง ยกเว้นคนขายโทเค็นกับคนที่จ่ายค่าโทเค็นเพื่อสแกนหา 0-day ได้ไหว

    • ฉันคิดว่า LLM และเอเจนต์มีปัญหาอยู่สองอย่างที่อาจไม่มีวันแก้ได้
      อย่างแรก มันไม่มี แบบจำลองเชิงเหตุและผล สิ่งที่ทำได้มีแค่การสำรวจแบบลองผิดลองถูก ซึ่งใช้ได้ค่อนข้างดีสำหรับปัญหาหลายแบบ แต่ก็มีอีกหลายปัญหาที่ต้องการแบบจำลองเชิงเหตุและผล
      อย่างที่สอง พรอมป์ไม่แม่นยำ ภาษาโปรแกรมและ machine model ถูกคิดค้นมาก็เพื่อแก้ปัญหานี้นี่เอง ภาษาอังกฤษนั้นยอดเยี่ยม แต่ไม่ใช่ภาษาโปรแกรม
    • ฉันคิดว่าข้างในพวกเขารู้อยู่แล้วมานานว่าไปถึงจุด ผลตอบแทนลดลง แล้ว
      ก่อน IPO พวกเขาใช้การผลักดันเชิงกลยุทธ์และการชี้นำอยู่มาก และในแง่นั้นมันก็ได้ผล
    • ไม่กี่วันก่อนฉันใช้ CC ทำการเปลี่ยนแปลงแบบเดียวกันเป๊ะในไฟล์ 15~20 ไฟล์ คือย้ายฟังก์ชันบางตัวออกไปไว้นอก component body จริง ๆ แค่แก้ไฟล์พวกนั้นก็พอ แต่กลับมีการปล่อยหลายเอเจนต์ออกมา และหนึ่งในนั้นก็เขียนสคริปต์ perl เพื่อหาไฟล์ทั้งหมดแล้วแทนที่ด้วย regex จากนั้นการตรวจ error ก็แค่รัน tsc ก็พอ แต่มันยังไปเขียนสคริปต์อีกตัวเพื่อรัน tsc ในแต่ละ sub-agent แล้วรวมผลเข้าด้วยกัน
      มันน่าหงุดหงิดมาก เรื่องที่อย่างมากควรใช้เวลา 1~2 นาที ดันกลายเป็นใช้ประมาณ 10 นาทีเพราะเดินไปตามเส้นทางนั้น
      ทีหลังฉันคงลองกับงานที่ซับซ้อนกว่านี้มาก แต่สำหรับงานง่าย ๆ มันให้ความรู้สึกเหมือน ขับ Corvette ไปเช็กตู้จดหมาย

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

    • น่าตกใจที่ไม่มีวิธีรันใน sandbox มาเป็นค่าเริ่มต้น
      ถ้าเป็น บริษัทมูลค่า 1 ล้านล้านดอลลาร์ ก็น่าจะจัดให้ได้ค่อนข้างง่ายไม่ใช่หรือ? เมื่อเทียบกับฮาร์เนสทั้งหมดแล้วก็ดูเป็นเรื่องเล็กน้อยด้วยซ้ำ

  • เห็นได้ชัดว่าความปลอดภัยเป็นประเด็นใหญ่กว่า แต่ตอนอ่านสิ่งนี้ฉันเอาแต่คิดว่าเขาใช้โทเค็นไปเท่าไรเพื่อแก้ CSS 2 บรรทัด

    • จำนวนบรรทัดของโค้ดที่ใช้แก้บั๊กเป็นตัวชี้วัดทดแทนที่แย่มากในการประเมินความพยายามที่ต้องใช้
      คุณควรประเมินว่าถ้าเป็นคนจะใช้เวลานานแค่ไหน
    • ง่ายมาก ถ้าต้องแก้ CSS 2 บรรทัด ก็ไม่ควรใช้ Fable เด็ดขาด ควรใช้มันเฉพาะงานที่ซับซ้อนและกินเวลานาน
    • น่าจะประมาณ 12 ดอลลาร์
    • ผู้เขียนเป็นพ่อค้าปั่นกระแส AI และไม่ได้จ่ายค่าโทเค็นเอง
    • ฉันเร็วกว่าพวกสาวก LLM แบบนี้ ฉันยังไม่เชื่อว่าการใช้ LLM จะเร็วกว่า ข้อยกเว้นอาจเป็นพวก boilerplate แต่ก็ไม่เห็นว่าสำคัญอะไรนัก
      ตอนนี้คนแค่สามารถขี้เกียจแต่ยังดูเหมือน productive ได้ และมันก็ยังคือความขี้เกียจอยู่ดี
      ตอนนี้มีคนที่ต้องมีสิทธิ์เข้าถึงฮาร์ดแวร์ราคาหลายแสนดอลลาร์เพื่อจะเขียนอีเมลหนึ่งฉบับ ฉันขอผ่าน
      ฉันไม่อยากเผาสมองตัวเองเพื่อไปพึ่งพาเครื่องจักรความคิดของมหาเศรษฐี
      และฉันก็จะไม่เผาสมองกับ “เครื่องที่คิดแทนให้” แบบโลคัลด้วย ฉันอยากเป็นคนที่มีค่ามากกว่าฮาร์ดแวร์ที่ฉันเข้าถึงได้

  • ประสบการณ์ส่วนตัวของผมกับ Fable 5 ที่ทำงานในแบบของตัวเองนั้นเป็นไปในทางบวกมาก
    ผมพยายามหาสาเหตุรากของโมดูล Python ที่แครชโดยไม่ทิ้ง error ไว้ใน log หรือคอนโซลเลย Fable เขียน test harness ที่จำลองการคลิก UI จากนั้นทำ binary search กับโค้ดของผมเพื่อหาจุดที่เริ่มเกิดอาการแครช มันตั้งสมมติฐานแบบขยายความเกี่ยวกับสาเหตุของการแครช แล้วรันคำสั่ง bash แบบ one-liner ต่อเนื่องกันเพื่อสร้าง virtual environment ของโมดูล Python นั้นแต่ละเวอร์ชันไว้ใต้ /tmp เพื่อหาเวอร์ชันที่ไม่แครช
    มันไล่สาวถึงสาเหตุรากได้ลึกกว่าที่ผมทำเองมาก และสาเหตุก็คือ regression ของโมดูลที่ทำให้เกิด heap allocation overflow มันให้ข้อมูลมากพอและตัวอย่างที่ลดรูปแล้วจนสามารถนำไปยื่น bug report ได้ และยังเขียนวิธีเลี่ยงปัญหาเพื่อไม่ให้เรื่องนี้เกิดขึ้นในแอปพลิเคชันของผมด้วย
    ไม่ได้ปล่อยให้มันทำทุกอย่างเองทั้งหมด ผมตรวจทานแต่ละคำสั่ง CLI ที่มันจะรัน และเมื่อกด “yes” เพื่อให้ทำต่อก็จะพิมพ์คำตอบเพิ่มเข้าไปเพื่อป้องกันการใช้โทเคนเกินจำเป็น

    • ผมคิดว่า Fable เหมาะมากกับการดีบักบั๊กที่ยาก
      ถ้าตั้งขอบเขตไว้ในพรอมป์ต์หรือ Markdown จะช่วยได้มาก ตัวอย่างเช่น ถ้าบอกว่าอย่าใช้ระบบอัตโนมัติของเว็บเบราว์เซอร์ ผมเห็นว่า Fable ทำตามทั้งตัวกฎและเจตนาของกฎนั้นจริง ๆ มันไม่ได้ใช้วิธีแฮ็กแปลก ๆ ด้วย
      แต่ดูเหมือนว่ามันจะปฏิบัติกับงานดีบักง่าย ๆ บางอย่างราวกับว่าซับซ้อนกว่าความเป็นจริง ตัวอย่างที่ดีคงเป็นโพสต์ต้นฉบับนี้
    • ผมสงสัยว่าในการหาสาเหตุที่โมดูล Python แครชโดยไม่ทิ้ง error ไว้ใน log หรือคอนโซลนั้น จำเป็นต้องใช้เอเจนต์เพื่อสร้างเทสต์ที่จำลองการคลิก UI และหมุนลูป git bisect จริงหรือ
      ผมพอเข้าใจเรื่องการสร้าง test case กับลูป git bisect แต่ไม่เข้าใจว่าทำไมต้องเอาไปรันผ่านอินเทอร์เน็ตและ GPU ด้วย งานแบบนี้ไม่น่าจะรันได้แม้แต่บน Celeron คอร์เดียวไม่ใช่หรือ