TL;DR Muse แทนที่คอนโซลจัดการ agent แบบสั่งทำเฉพาะกิจ ด้วยเครื่องมือสี่อย่างที่ทีมซอฟต์แวร์ทุกทีมเปิดใช้งานอยู่แล้ว ได้แก่ Slack, Linear, GitHub และ Claude Code ไม่มีแดชบอร์ด ไม่มี SPA ไม่มีโค้ดที่มนุษย์เขียนเอง ทุก PR ต้องผ่านด่าน CI เจ็ดขั้นตอนและคณะกรรมการรีวิว AI สามบุคลิก ภายใต้นโยบายที่ต้องไม่มีข้อค้นพบใด ๆ ก่อนจึงจะ merge ได้ เก็บโหวตได้กว่า 40,000 ครั้ง การประเมินโมเดลพื้นฐานเร็วขึ้น 80%
Muse ย่อมาจาก Meshy Universal System for Evaluation เป็นแพลตฟอร์มประเมินโมเดลภายในของเรา ทีมงานที่ Meshy ใช้มันทุกวันเพื่อดูว่าโมเดล checkpoint ใหม่ทำงานได้ดีกว่าของเก่าหรือไม่
วันหนึ่ง โมเดล checkpoint ใหม่เอี่ยมเพิ่งปั้นเสร็จ ต้องมีการแข่งขันแบบ arena เพื่อกำหนดกลยุทธ์การเทรนขั้นต่อไป ทีมงานพบว่าต้องมีฟีเจอร์ใหม่ใน Muse มารองรับเรื่องนี้
"@Linear สร้าง issue เกี่ยวกับ Muse เรื่องนี้หน่อย"
Product Manager พูดแบบนี้ใน Slack
หนึ่งนาทีต่อมา Linear issue MES-12345 ก็ถูกสร้างขึ้น
เจ้าของแพลตฟอร์ม Muse — ก็คือผม — เห็น issue นี้ มันต้องรีบส่งให้เร็วที่สุดเพื่อปลดล็อกงานประเมิน จากนั้นข้อความก็ถูกส่งไปหา Claude ว่า
"ไปตรวจสอบและแก้ไข MES-12345 ให้หน่อย"
Claude ดู issue นั้น แล้วเสนอประเด็นการออกแบบขึ้นมาสองข้อให้ตัดสินใจ พอตัดสินใจเสร็จ ผมก็ออกจากเทอร์มินัลไปทำงานอย่างอื่นต่อ
ชั่วโมงครึ่งต่อมา Muse เวอร์ชันใหม่ก็ถูก deploy เรียบร้อยแล้ว จบ
วิศวกรรมซอฟต์แวร์แบบอัตโนมัติไม่จำเป็นต้องมาในรูปแบบคอนโซลจัดการ agent หรือแดชบอร์ดหรูหรา และในบทความนี้ผมจะอธิบายว่าเราทำให้มันเกิดขึ้นจริงได้อย่างไร
แกลเลอรี วิวเวอร์ และปุ่มโหวต
คำถามที่ Muse ต้องตอบนั้นยากกว่าที่คิด นั่นคือ checkpoint โมเดลใหม่ดีกว่าจริงหรือไม่? แน่นอนว่ามีตัวชี้วัดเชิงปริมาณให้ติดตามในแต่ละรอบการเทรน แต่ตัวเลขเหล่านั้นยังห่างไกลจากการสะท้อนความหมายของคำว่า "ดี" ในงานสร้างโมเดล 3D ได้อย่างแม่นยำ Muse จึงเลือกทำสิ่งที่เรียบง่ายแต่ได้ผล นั่นคือการทดสอบแบบ double-blind โดยนำผลลัพธ์ของสองโมเดลมาวางเทียบกัน ใช้ภาพอินพุตเดียวกัน สลับตำแหน่งซ้ายขวาแบบสุ่ม แล้วให้เพื่อนร่วมทีมโหวตแบบไม่รู้ว่าอันไหนเป็นของโมเดลไหน
การประเมินหนึ่งครั้งคือชุดของคู่เปรียบเทียบแบบนี้จำนวนหนึ่ง มีคนชี้ให้ Muse ไปดูชุด mesh ที่สร้างขึ้นสองชุดและโฟลเดอร์ภาพอ้างอิง ที่เหลือแอปจะจัดการเอง ทั้งการจับคู่โมเดล การสุ่มปิดบังว่าอันไหนเป็นของใคร และการเสิร์ฟการเปรียบเทียบทีละคู่ ยอดโหวตจะค่อย ๆ สะสมทุกครั้งที่ใครสักคนมีเวลาว่างนิดหน่อย อินเทอร์เฟซทั้งหมดถูกออกแบบให้ใช้งานได้แบบเร็ว ๆ สั้น ๆ และแทบจะควบคุมได้ทั้งหมดด้วยคีย์ลัด เพราะผู้โหวตที่ต้องเอื้อมมือไปจับเมาส์จะโหวตน้อยลง
อินเทอร์เฟซการโหวตของ Muse: mesh ที่สร้างขึ้นสองชิ้น ใช้ภาพอินพุตเดียวกัน สลับตำแหน่งซ้ายขวาแบบสุ่ม
นั่นคือตัวผลิตภัณฑ์ทั้งหมด แกลเลอรี วิวเวอร์ และปุ่มโหวต ไม่มีอะไรใน การทำงาน ของ Muse ที่ซับซ้อนเลย ซึ่งนั่นแหละคือเหตุผลที่มันเป็นกรณีศึกษาที่ชัดเจน สิ่งที่ไม่ธรรมดามีเพียงวิธีที่มันถูกสร้างขึ้นมาเท่านั้น
สถาปัตยกรรมที่ agent เดินเรื่องได้เอง
โปรเจกต์ Muse เริ่มต้นขึ้นในช่วงปลายปี 2025 ตอนที่คำว่า "vibe coding" เพิ่งกลายเป็นคำฮิตใหม่ นอกจากจะรองรับความต้องการประเมินผลที่เพิ่มขึ้นเรื่อย ๆ ของ Meshy ในรอบการเทรนและการปล่อยเวอร์ชันแล้ว Muse ยังมีเป้าหมายที่ทะเยอทะยานอีกด้วย นั่นคือ สร้างซอฟต์แวร์ให้กับทั้งบริษัท โดยไม่มีโค้ดแม้แต่บรรทัดเดียวที่มนุษย์เขียนเอง
วันนี้ ผลลัพธ์ที่ได้นั้นยอดเยี่ยมมาก
- เก็บโหวตได้กว่า 40,000 ครั้ง นับตั้งแต่ Muse เปิดใช้งานครั้งแรก โดยมีโปรเจกต์ประเมินผลมากกว่า 30 โปรเจกต์ต่อเดือน
- มากกว่า 4 ทีม ใช้งาน Muse อย่างต่อเนื่องในงานประจำวัน
- โค้ดเบสภายในชุดแรก ที่มีสมาชิกทีมที่ไม่ใช่สายเทคนิคอย่างน้อย 1 คนร่วมคอนทริบิวต์อย่างจริงจัง
- โค้ดเบสภายในชุดแรก ที่พัฒนาได้แบบอัตโนมัติเต็มรูปแบบ
โดยรวมแล้ว เราประเมินว่า Muse ช่วยให้การประเมินโมเดลพื้นฐานของเราเร็วขึ้นอย่างน้อย 80% และลดเวลาทำงานได้อย่างน้อย 10 คน-วันในทุกครั้งที่ปล่อยโมเดลใหม่ หากไม่มี Muse การรักษาความเร็วในการพัฒนาและปล่อยเวอร์ชันของชุดโมเดล generative ของ Meshy ไม่ว่าจะเป็น geometry, texture หรือ smart topology ในระดับปัจจุบันคงแทบเป็นไปไม่ได้เลย
ตั้งแต่วันแรก Muse ถูกออกแบบมาให้ agent อ่านและเข้าใจได้ง่ายที่สุดเท่าที่จะทำได้ ในปี 2025 เราพบแล้วว่าในการทำ use case แบบเดียวกัน agent จะติดขัดในบางกรณี แต่กลับทำสำเร็จในครั้งเดียวในอีกหลายกรณี การทำซ้ำหลายรอบเหล่านี้ในที่สุดก็นำไปสู่เทคสแต็กที่ธรรมดาอย่างจงใจในทุกวันนี้ ฝั่งแบ็กเอนด์เป็น Python ได้แก่ FastAPI, Postgres สำหรับเก็บข้อมูล และ S3 สำหรับเก็บ mesh และรูปภาพ ฝั่งฟรอนต์เอนด์เรนเดอร์ที่ฝั่งเซิร์ฟเวอร์ ใช้เทมเพลต Jinja2, HTMX สำหรับอัปเดตบางส่วนของหน้า, Tailwind สำหรับสไตล์ และมีคอมโพเนนต์ฝั่งไคลเอนต์จริงเพียงชิ้นเดียวคือ WebGL 3D viewer ที่ใช้เรนเดอร์ mesh ไม่มี SPA และไม่มีโมดูลฟรอนต์เอนด์แยกต่างหาก การเชื่อมโยงระหว่างสองสแต็กนี้เป็นรูปแบบที่เก่าแก่ที่สุดบนเว็บ นั่นคือแบ็กเอนด์เรนเดอร์ HTML แล้วเบราว์เซอร์ก็แสดงผล เมื่อหน้าใดต้องเปลี่ยนแปลง HTMX จะขอ fragment มา แล้วเซิร์ฟเวอร์ก็เรนเดอร์ส่วนนั้นให้เช่นกัน
นี่คือสถาปัตยกรรมของแอปประเมินผลหลักใน Muse
สถาปัตยกรรมแบบเลเยอร์ของแอปประเมินผลหลักของ Muse การพึ่งพา (dependency) ชี้ลงด้านล่างเท่านั้น
รูปแบบนี้มีคุณสมบัติสองอย่างที่สำคัญสำหรับ agent อย่างแรกคือ state ของฟรอนต์เอนด์อยู่ที่ฝั่งเซิร์ฟเวอร์ HTML ที่ผู้ใช้เห็นคือ HTML ที่แบ็กเอนด์สร้างขึ้น ดังนั้นการทดสอบ (หรือ agent) จึงตรวจสอบมันได้โดยตรง โดยไม่ต้องขับเคลื่อนเฟรมเวิร์กฝั่งไคลเอนต์เพื่อประกอบสิ่งที่ผู้ใช้เห็นขึ้นมาใหม่ อย่างที่สองคือทุก dependency ถูกบังคับใช้โดยเครื่องและชี้ลงด้านล่างเท่านั้น โฟลเดอร์ฟีเจอร์หนึ่งจะ import โฟลเดอร์พี่น้องของมันไม่ได้ ถ้าสองฟีเจอร์ต้องพึ่งพากัน composition root จะฉีดความสามารถหนึ่งเข้าไปในอีกฟีเจอร์หนึ่ง ทำให้ dependency นั้นมองเห็นได้ในไฟล์เดียวเท่านั้น แต่ละเลเยอร์มีหน้าที่เดียว และหน้าที่เหล่านั้นถูกเขียนบันทึกไว้ในจุดที่ agent จะต้องเจอแน่ ๆ
| Layer | หน้าที่ | ทำไม agent จึงทำงานตรงนี้ได้อย่างปลอดภัย |
|---|---|---|
main/ | เชื่อมต่อ (wiring) เท่านั้น ลงทะเบียนเส้นทาง URL ของแต่ละโมดูลฟีเจอร์ | ฟีเจอร์ใหม่คือหนึ่งโฟลเดอร์บวกหนึ่งบรรทัด include มีอะไรให้ hallucinate น้อยมาก |
apps/<feature>/ | หนึ่งโฟลเดอร์ต่อหนึ่งฟีเจอร์ ได้แก่ routes, pages, service, store, tests | รัศมีความเสียหายของการแก้ไขจำกัดอยู่แค่ในโฟลเดอร์นั้น การ import ข้ามโฟลเดอร์พี่น้องคือ build ล้มเหลว ไม่ใช่แค่คอมเมนต์ในรีวิว |
adapters/ | โลกภายนอก ได้แก่ การเรนเดอร์เว็บ ฐานข้อมูล และ object storage | I/O ทั้งหมดผ่าน seam เดียวต่อระบบหนึ่ง มี fake ให้ทุก seam |
libs/ | ไลบรารีที่ติดตั้งใช้ร่วมกัน | ถูกกำหนดเวอร์ชันเหมือนโค้ดของบุคคลที่สาม การเปลี่ยนแปลงหนึ่งครั้งต้องเห็นชัดโดยเจตนา |
Dependency จะชี้ลงตามลำดับรายการนี้เท่านั้น และทิศทางนี้ถูกบังคับใช้ด้วยการตรวจสอบตอน build ไม่ใช่แค่ข้อตกลงร่วมกัน
มีคุณสมบัติเพิ่มเติมอีกสามอย่างที่ทำให้โค้ดเบสนี้ agent อ่านเข้าใจได้ง่ายโดยตั้งใจ
- ทุกไดเรกทอรีมีเอกสารประกอบของตัวเอง (บริการนี้ทำอะไร กฎการจัดเลเยอร์เป็นอย่างไร คำสั่งที่ใช้ตรวจก่อน merge คืออะไร) เพื่อให้ agent ที่เพิ่งเข้ามาแบบไม่มีบริบทสามารถหาทิศทางได้เอง โดยไม่ต้องถามหรือเดาเอาเอง
- โมดูลที่ไม่ธรรมดาจะมี docstring พร้อมลิงก์ย้อนกลับไปยังเอกสารการออกแบบ เพื่อให้ เหตุผล อยู่คู่กับ สิ่งที่ทำ เสมอ
- ไม่มีไฟล์ใดเกิน 500 บรรทัด โดยมีข้อยกเว้นอยู่บ้างเล็กน้อยที่ถูกบังคับให้ไล่ลดลงเรื่อย ๆ (ratchet) สำหรับข้อยกเว้นเหล่านั้น ไฟล์จะเล็กลงได้เท่านั้น ห้ามใหญ่ขึ้นอีก เพราะ context window มีจำกัด สถาปัตยกรรมจึงเคารพข้อจำกัดนี้
ความคืบหน้าไม่ควรถูกขังไว้ในห้องเล็ก ๆ
ทุกวันนี้ เมื่อ LLM agent ทรงพลังกว่าในปี 2025 มาก เราต้องการให้การพัฒนา Muse เป็นแบบอัตโนมัติเต็มรูปแบบ นั่นคือมนุษย์เพียงแค่ชี้ให้ agent ไปทำงานที่ต้องการ agent จะหาทิศทางของตัวเองจากโค้ดเบสและบริบทของงาน ลงมือทำตั้งแต่การ implement ไปจนถึง CI และการรีวิวโค้ด แล้วสุดท้ายก็ขับเคลื่อน pull request ของตัวเองจนถึงขั้น merge มนุษย์มีหน้าที่เพียงกำหนดลำดับความสำคัญของ issue และตัดสินใจในประเด็นการออกแบบสำคัญ ๆ เท่านั้น
ความคิดแรกเกี่ยวกับการพัฒนาแบบอัตโนมัติเต็มรูปแบบมักจะเป็นแพลตฟอร์มที่สร้างขึ้นมาเฉพาะทาง ไม่ว่าจะเป็นคอนโซลจัดการ agent, workspace ที่ออกแบบมาสำหรับ agent โดยเฉพาะ หรือแอปแล้วแอปเล่าที่สัญญาว่าจะช่วยจัดการกองทัพ agent ของคุณ เราลองมองดูแล้ว และปฏิเสธ ไม่ใช่เพราะมันไม่ใช่ผลิตภัณฑ์ที่ดี แต่เพราะเรื่องความอ่านง่ายเข้าใจง่ายอีกเช่นเคย
เราต้องการให้งานของ agent เป็นสิ่งที่มนุษย์อ่านและเข้าใจได้ เช่นเดียวกับที่โค้ดเบสควรเป็นสิ่งที่ agent อ่านและเข้าใจได้ เราเป็นบริษัทที่มีขนาดไม่เล็ก หากใส่การพัฒนาแบบอัตโนมัติไว้ในคอนโซลที่สร้างขึ้นเอง ความคืบหน้าของมันจะมองเห็นได้แค่คนกลุ่มเล็ก ๆ ที่ใช้ชีวิตอยู่ในคอนโซลนั้นเท่านั้น
เพราะฉะนั้น สแต็กเครื่องมือสำหรับการทำงานร่วมกันและการพัฒนาก็ธรรมดาอย่างจงใจอีกเช่นกัน ทุกอย่างในเรื่องราวของเราทำงานบนเครื่องมือสี่อย่างที่ทุกบริษัทซอฟต์แวร์เปิดใช้อยู่แล้ว ได้แก่ Slack, Linear, GitHub และ Claude Code สิ่งนี้ทำให้ความคืบหน้าที่ agent สร้างขึ้นสังเกตเห็นและค้นหาได้เหมือนกับของสมาชิกทีมคนอื่น ๆ ทุกประการ Product Manager เปิด Linear issue และเช็กสถานะฟีเจอร์แบบเดียวกับที่เคยทำมาตลอด บอทตรวจบั๊กของ GitHub หรือการรีวิวความปลอดภัยอ่านเธรด PR แบบเดิมที่เคยทำ ใครก็ตามที่รายงานบั๊กก็แปะสกรีนช็อตลงในช่อง Slack เดิมเหมือนเดิม แล้วการแก้ไขก็ปรากฏออกมาเป็น pull request ธรรมดา ๆ ไม่มีใครต้องเรียนรู้อะไรเพิ่มเพื่อคอยดูแล "เครื่องจักร" นี้เลย
นี่คือรูปร่างของ issue อัตโนมัติหนึ่งชิ้น ตั้งแต่ต้นจนจบ
issue อัตโนมัติหนึ่งชิ้น ตั้งแต่ต้นจนจบ มนุษย์แตะต้อง loop นี้เพียงสองจุดเท่านั้น
มนุษย์แตะต้อง loop นี้เพียงสองจุดเท่านั้น คือการชี้ให้ agent ไปดู Linear issue และการตัดสินใจไม่กี่ครั้งที่ agent เสนอขึ้นมาก่อนจะเริ่มเขียนโค้ด ทุกอย่างที่อยู่ระหว่างนั้น ไม่ว่าจะเป็นการ implement การตรวจสอบ บทสนทนาในการรีวิว การ merge และการ deploy ล้วนทำงานโดยไม่มีใครนั่งเฝ้าเลย เมื่อการตรวจสอบล้มเหลวหรือผู้รีวิวคัดค้าน agent จะอ่านความล้มเหลวนั้น แก้ไข แล้ว push ใหม่อีกครั้ง และ loop ก็จะวนอีกรอบเท่านั้นเอง มันจะจบก็ต่อเมื่อ branch เขียวผ่านหมด ข้อค้นพบทุกข้อถูกแก้ไขแล้ว และคิว merge ได้ merge มันเรียบร้อย
สิ่งที่ทำให้เรื่องนี้เป็นไปได้ไม่ใช่การเชื่อมต่อแบบสั่งทำเฉพาะกิจ แต่เป็นเพราะเครื่องมือทั้งสามตัวนี้เปิดพื้นผิวคำสั่งที่ agent ขับเคลื่อนได้โดยตรงอยู่แล้ว เป็นพื้นผิวเดียวกับที่คนใช้งาน
- GitHub ผ่านทาง CLI ของมัน agent เปิด pull request อ่านสถานะและ log ของแต่ละ CI job ตอบกลับในเธรดรีวิวแล้วมาร์กว่าแก้ไขแล้ว และเข้าคิว branch เพื่อ merge ทั้งหมดนี้ผ่านคำสั่ง
ghธรรมดา - Linear ผ่านทาง MCP server ของมัน agent อ่าน issue ที่ถูกชี้ให้ไปดู ตามลิงก์ไปยัง issue ที่เกี่ยวข้องเพื่อดูบริบท เปลี่ยนสถานะ และสร้าง issue ติดตามผลสำหรับงานที่ค้นพบระหว่างทาง ทั้งหมดนี้ในรูปแบบการเรียกใช้ tool ชั้นหนึ่ง
- Monitor loop ของ Claude Code เอง CI ใช้เวลาหลายนาทีและคิว merge ใช้เวลานานกว่านั้น โดยไม่มีมนุษย์คอยเฝ้าดู agent จึงเฝ้าดูแทน และวิธีที่มันเฝ้าดูนี่แหละที่ทำให้การรันแบบไม่มีคนดูแลกลายเป็นสิ่งที่ใช้งานได้จริง แทนที่จะเป็นแค่การเผา token ทิ้งเปล่า ๆ
เมื่อ agent เปิด pull request มันไม่ได้นั่งกดรีเฟรชหน้าจอ แต่มันจะลงทะเบียนสิ่งที่กำลังรอ ไม่ว่าจะเป็นการรัน CI เธรดรีวิว หรือรายการในคิว merge แล้วก็จบเทิร์นของตัวเองไป ฟีเจอร์ Monitor ของ Claude Code จะเรียกมันกลับมาทำงานอีกครั้งก็ต่อเมื่อ state ที่เฝ้าดูอยู่เปลี่ยนแปลงเท่านั้น เช่น job กลายเป็นสีแดง คณะกรรมการรีวิวโพสต์ข้อค้นพบ หรือคิว merge branch นั้นสำเร็จแล้ว เพราะ agent ถูกปลุกด้วยข้อความจาก Monitor เกี่ยวกับการอัปเดตสถานะแต่ละครั้ง มันจึงลงมือทำขั้นตอนถัดไปตามนั้น เช่น ดึง log ของ job ที่ล้มเหลวมาแล้ว push การแก้ไข ตอบกลับเธรดรีวิวแล้วมาร์กว่าแก้ไขแล้ว หรือเข้าคิว branch เมื่อทุกด่านเขียวหมดแล้ว
ไม่มีสิ่งใดในนี้ที่จำเพาะกับ Muse เท่านั้น รีพอสิทอรีใด ๆ ที่เข้าถึงได้ด้วยเครื่องมือทั้งสามนี้ก็ขับเคลื่อนได้แบบเดียวกัน ซึ่งนั่นคือเหตุผลที่แท้จริงที่เราเลือกใช้มัน
ความน่าเชื่อถือคือผลผลิตของ build
เราไม่ได้เชื่อใจตัว LLM เอง แต่เราเชื่อใจ LLM agent ที่อยู่ภายใน harness และ harness นี้ก็ออกแบบให้เป็นผู้พิทักษ์ความน่าเชื่อถือได้ พูดให้เป็นรูปธรรม harness ของเราคือ CI/CD pipeline บวกกับชั้นรีวิวที่อยู่ด้านบนมัน นี่คือสิ่งที่ pull request ทุกอันต้องผ่าน ไม่มีข้อยกเว้น
pull request ทุกอันผ่าน harness เดียวกัน คือการตรวจสอบอัตโนมัติก่อน แล้วตามด้วยคณะกรรมการรีวิว AI
งานแต่ละอย่าง พร้อมเวลาโดยทั่วไปที่วัดจาก PR จริงล่าสุด มีดังนี้
| Job | สิ่งที่บังคับใช้ | เวลาโดยทั่วไป |
|---|---|---|
| Guardrails | การจัดเลเยอร์ (ห้าม import ข้ามโฟลเดอร์พี่น้อง) รูปแบบโฟลเดอร์ เพดานขนาดไฟล์ การตั้งชื่อ | ~60 s |
| Lint | รูปแบบและกฎ lint ของ ruff | ~30 s |
| Type check | pyrefly ตรวจทั้งโปรเจกต์ | ~20 s |
| Unit + integration tests | pytest กับ Postgres จริงที่สร้างจาก schema | ~90 s |
| Visual tests | เทียบ screenshot ของ Playwright กับ golden ที่ commit ไว้ ในตัวเรนเดอร์ของ CI เอง | ~140 s |
| Security | การวิเคราะห์แบบ static ด้วย semgrep บวกกับการสแกนหา secret | ~40 s |
| Container boot test | แอปต้องบูตขึ้นมาได้ ซึ่งมันจะปฏิเสธไม่บูตถ้าทุก route ยังไม่ระบุว่าใครมีสิทธิ์เรียกใช้ | ~215 s |
Guardrail คือสถาปัตยกรรมที่เราอธิบายไปข้างต้น แปลงให้กลายเป็นเครื่องจักรที่ตรวจสอบเอง การ import ข้ามโฟลเดอร์พี่น้องที่นี่ไม่ใช่แค่คอมเมนต์ในรีวิว แต่คือ build ที่ขึ้นสีแดง golden ของภาพถูกจับไว้ในสภาพแวดล้อมเรนเดอร์ของ CI เอง ดังนั้นคำว่า "มันทำงานได้บนเครื่องผม" จึงไม่มีวันใช้เป็นข้ออ้างเพื่อ merge บั๊กเข้า main ได้
ชั้นรีวิวโดย AI นี่แหละที่น่าสนใจ ทุก PR จะถูกอ่านโดยคณะกรรมการรีวิว coding agent ของเราเองสามตัว ซึ่งอ่าน diff เดียวกันเทียบกับหลักการออกแบบที่เขียนไว้ในรีพอ โดยแต่ละตัวได้รับมอบหมายบุคลิกที่แตกต่างกัน ต่อไปนี้คือโครงร่างของ prompt ที่มอบให้ผู้รีวิวแต่ละคน
Principal Engineer:
บุคลิก: Principal Engineer รีวิวการออกแบบ ขอบเขตกว้าง
คุณรีวิวใน ขอบเขตของทั้งระบบ ว่าการเปลี่ยนแปลงนี้อยู่ถูกที่ไหม เข้ากับสถาปัตยกรรมหรือเปล่า ใช้ซ้ำสิ่งที่มีอยู่แล้วหรือไม่ และเป็นการเพิ่มเติมมากกว่าการซ้ำซ้อนหรือเปล่า ไม่ใช่ว่าบรรทัดนั้นเรียบร้อยหรือไม่
คุณเห็นแค่ diff กับ Guides ไม่ใช่ทั้งรีพอ ตัดสินเรื่องการใช้ซ้ำและความสอดคล้องของแพตเทิร์น ...; อย่าอ้างว่าค้นหาทั่วทั้งรีพอที่คุณทำไม่ได้
มุมมองของคุณ: ตัดสิน diff เทียบกับส่วนเหล่านี้ของ Guides ที่ให้มา ...
บททดสอบ: "ถ้าฉันเป็น principal eng ของโค้ดเบสนี้ ฉันจะตีกลับการเปลี่ยนแปลงนี้เพราะมันอยู่ผิดที่ ซ้ำซ้อนกับความสามารถที่มีอยู่แล้ว หรือเพิ่มอีกวิธีหนึ่งให้กับสิ่งที่แก้ไปแล้วหรือไม่?" ถ้าไม่ใช่ ให้ตอบกลับ
[]
Senior Engineer:
บุคลิก: Senior Engineer รีวิวตรรกะ/การ implement/คุณภาพ
คุณรีวิว ภายในขอบเขตของการเปลี่ยนแปลงนี้ ว่าตรรกะถูกต้อง สะอาด ทดสอบได้ และปลอดภัยหรือไม่ นี่คือการรีวิวที่ต้องคิดอย่างละเอียดที่สุด ต้องไล่ตาม code path อย่าอ่านผ่าน ๆ โฟกัสที่ diff และไฟล์ที่มันแตะต้อง (อ่านให้ครบทุกไฟล์)
มุมมองของคุณ: ตัดสิน diff เทียบกับส่วนเหล่านี้ของ Guides ที่ให้มา ...
บททดสอบ: "ฉันจะอนุมัติตรรกะนี้ไหม หรือจะเจอบั๊ก จุดที่ทดสอบไม่ได้ หรือข้อผิดพลาดด้านความปลอดภัยเมื่ออ่านอย่างละเอียด?" ระบุให้ชัดเจนว่าอินพุตหรือ code path ไหนที่ล้มเหลว ถ้าตรรกะถูกต้องดี ให้ตอบกลับ
[]
QA Engineer:
บุคลิก: QA Engineer ตรวจว่ามันทำงานได้จริงไหม ถูกทดสอบหรือยัง จะพังหรือเปล่า
คุณรีวิว พฤติกรรมและความเสี่ยง ว่าการเปลี่ยนแปลงนี้ทำในสิ่งที่มันอ้างไว้จริงหรือไม่ มีการทดสอบครอบคลุมหรือเปล่า และมันอาจทำให้อะไรพังในระบบที่ใช้งานจริงหรือ production หรือไม่ อ่านชื่อและคำอธิบายของ PR ก่อน แล้วตรวจว่า diff ทำตามนั้นจริงไหม
มุมมองของคุณ: ตรงตามเจตนา ...; ความครอบคลุมของการทดสอบ ...; ความเสี่ยงในการเกิด regression ...; กับดักที่อาจเกิดใน production ...
บททดสอบ: "ถ้าฉันเป็น QA ที่ต้องเซ็นอนุมัติ ฉันจะบล็อกสิ่งนี้เพราะมันไม่ทำตามที่อ้าง เพราะปล่อยพฤติกรรมที่ไม่ได้ทดสอบ หรือเพราะการเปลี่ยนแปลงนี้ทำให้ prod พังหรือไม่?" ถ้ามันปลอดภัยและครอบคลุมดีแล้ว ให้ตอบกลับ
[]
นอกจากจะดู diff โค้ดเดียวกันจากมุมมองที่ต่างกันแล้ว ผู้รีวิวทั้ง 3 ตัวยังใช้ชุดกฎร่วมกันที่ควบคุมการพัฒนาของทั้งโค้ดเบส นั่นก็คือ Guides
- สิ่งที่เปลี่ยนแปลงพร้อมกันควรอยู่ด้วยกัน สิ่งที่ไม่เกี่ยวข้องกันควรแยกออกจากกันได้ การเปลี่ยนหรือลบเรื่องใดเรื่องหนึ่งควรแตะแค่จุดเดียว
- ตรรกะทางธุรกิจไม่ควรขึ้นกับรายละเอียดของโลกภายนอก ฟังก์ชันตรรกะทางธุรกิจต้องรันในการทดสอบด้วย fake ที่ส่งเข้าไปได้ โดยไม่มี I/O จริง การสลับแบ็กเอนด์ไม่ควรแตะตรรกะทางธุรกิจเลย และแอปไม่ควรเรียก HTTP endpoint ของตัวเอง
- ใช้ซ้ำ อย่าคิดใหม่ทำใหม่ แต่ละความสามารถควรมี implementation เดียว ผู้ใช้งานรายใหม่ควรเรียกใช้ interface ที่มีอยู่แล้ว แทนที่จะคัดลอกมันไป
- เพิ่มฟีเจอร์ด้วยการเพิ่ม ไม่ใช่การแก้ไข การเพิ่มฟีเจอร์คือ "ไฟล์ใหม่ + บรรทัดลงทะเบียนหนึ่งบรรทัด" และการลบมันก็ไม่ควรแตะฟีเจอร์อื่นเลย
- มีวิธีเดียวที่เป็นมาตรฐานสำหรับแต่ละเรื่อง คนที่เพิ่งเข้ามาใหม่ควรคัดลอกแพตเทิร์นที่มีอยู่แล้ว แทนที่จะต้องเลือกเอง และการทดสอบไม่ควรต้องพึ่งเซิร์ฟเวอร์หรือฐานข้อมูล
- ลบโค้ดทันทีที่มันเลิกถูกใช้งาน ไม่ควรมีอะไรถูกปล่อยออกไปทั้งที่ไม่มีใครเรียกใช้ "เก็บไว้เผื่อได้ใช้" ไม่ใช่เหตุผลที่ดีพอ เพราะ git จำได้อยู่แล้ว
- เลือกวิธีที่ง่ายที่สุดที่ใช้ได้ผล เพิ่มความซับซ้อนก็ต่อเมื่อจำเป็นจริง ๆ ทุก abstraction ต้องคุ้มค่ากับความจำเป็นที่มีอยู่จริงในปัจจุบัน การเปลี่ยนแปลงควรเล็กที่สุดเท่าที่จะแก้ปัญหาได้
คณะกรรมการโพสต์ข้อค้นพบที่บล็อกการ merge แต่ละข้อเป็นคอมเมนต์แบบ inline ที่ปักไว้ตรงบรรทัดที่แน่นอน และคอมเมนต์เหล่านั้นจะกัน merge ไว้จนกว่าจะถูกแก้ไข
การรีวิวจาก PR ฟีเจอร์ล่าสุดอันหนึ่งมีลักษณะแบบนี้
[medium] ความเสี่ยงต่อการเกิด regression ฟังก์ชันนี้เป็นจุดคอขวดร่วมสำหรับการสร้างและซิงค์ ตอนนี้มันยุบไฟล์ที่มีคำต่อท้าย view ให้กลายเป็นแถวที่จัดกลุ่มเดียว dataset เก่าใด ๆ ที่ถูกนำเข้าด้วยรูปแบบเก่า เมื่อซิงค์ครั้งถัดไปจะถูกจัดกลุ่มใหม่แบบเงียบ ๆ ลบ identity ของตัวอย่างเก่าที่การประเมินที่ยังใช้งานอยู่ยังคงอ้างอิงถึง ไม่มีการทดสอบใดครอบคลุมการซิงค์ dataset ที่มีอยู่แล้วซ้ำผ่านการจัดกลุ่มแบบใหม่นี้เลย
ข้อค้นพบนั้นถูกต้อง โค้ดผ่าน test suite ทั้งชุดและ CI รอบแรกที่เขียวหมดแล้ว การทดสอบนั้นถูกต้องสำหรับโค้ดตามที่เขียนไว้ แต่ผู้รีวิวเห็นว่าโค้ดตามที่เขียนไว้นั้นผิดสำหรับข้อมูลที่เรามีอยู่จริง Claude แก้ไขมัน เพิ่ม regression test ที่ขาดหายไป ตอบกลับในเธรด และแก้ไขข้อค้นพบนั้นจนเรียบร้อย การสนทนาทั้งหมดเปิดเผยต่อสาธารณะใน PR เหมือนกับการที่คุณจะสอนวิศวกรจูเนียร์ผ่านการรีวิวโค้ดทุกประการ
นั่นคือ PR หนึ่งอัน เมื่อเรารัน agent ไปเรื่อย ๆ ตามเวลา เราก็ค้นพบแพตเทิร์นทั่วไปอื่น ๆ เพิ่มเติมอีก
- การแก้ไขที่ก่อปัญหาใหม่ เครื่องมือวินิจฉัยตัวหนึ่งที่เราปล่อยออกไปวัดความเร็วในการดาวน์โหลด การรีวิวจับได้ว่าการคำนวณใช้หน่วย MB (1,000,000 ไบต์) แต่เซิร์ฟเวอร์ส่งเป็น MiB (1,048,576 ไบต์) ทำให้ความเร็วทุกค่าอ่านต่ำกว่าจริง 5% หลังจาก push ไปอีกไม่กี่ครั้ง การรีวิวก็ตั้งข้อสังเกตว่าการแก้ไขนั้นทิ้งค่าคงที่สองตัวไว้ให้ต้องคอยซิงค์กันด้วยมือ จึงขอให้คำนวณความเร็วจากจำนวนไบต์ที่รับมาจริงแทน ผู้รีวิวจับบั๊กที่เกิดจากการแก้ตามคำขอครั้งก่อนของตัวเองได้
- Use case ที่จบแบบทางตัน หน้าเดียวกันถูกปล่อยออกไปพร้อมลิงก์ที่มองเห็นได้สำหรับผู้ใช้ที่ล็อกอินทุกคน ทั้งที่ตัวหน้านั้นต้องการสิทธิ์เฉพาะ ใครก็ตามที่ไม่มีสิทธิ์นั้นจะคลิกแล้วเจอ error 403 ไม่มีการทดสอบใดล้มเหลวเลย เพราะลิงก์แสดงผลได้และ permission gate ก็ทำงานถูกต้อง ผู้รีวิว QA เปรียบเทียบทั้งสองอย่างแล้วบล็อกการ merge ไว้จนกว่าลิงก์จะแสดงให้เห็นเฉพาะคนที่เปิดหน้านั้นได้จริง ๆ เท่านั้น
- การแฮ็กเพื่อให้ผ่านการทดสอบ การทดสอบของการแก้ไขอันหนึ่งสร้าง exception ตัวเดียวกับที่มันควรจะดักจับขึ้นมาเอง ทำให้มันผ่านแม้ว่าการจัดการ error จริงจะพังก็ตาม เพราะการทดสอบได้รับข้อความ exception ที่ "ถูกต้อง" คณะกรรมการตั้งข้อสังเกต และการทดสอบที่เขียนใหม่ก็รัน error จริงผ่านโค้ดจริง PR เดียวกันนี้ยังมีการทดสอบที่ผ่านบนเครื่องของนักพัฒนาแต่ล้มเหลวใน CI เพราะมันแอบพึ่งพาไฟล์ credential ที่มีอยู่แค่บนเครื่อง dev ของเราเท่านั้น ทั้งสองกรณีเป็นบั๊กในตัวการทดสอบเอง ที่ถูกจับได้โดยชั้นที่อยู่เหนือมันขึ้นไป
นโยบายการ merge ของเราคือต้องมีข้อค้นพบจากการรีวิว AI เป็น 0 ข้อค้นพบทุกข้อต้องถูกแก้ไข หรือหักล้างด้วยหลักฐาน ก่อนที่คิวจะรับ PR นั้นไป เราทำให้การหักล้างเป็นทางเลือกที่ใช้ได้จริง เพราะคณะกรรมการรีวิวตั้งข้อสังเกตเกินจริงในอัตราที่พอรับได้ การเขียนอธิบายว่า ทำไม ข้อค้นพบหนึ่งจึงผิด บางครั้งก็ช่วยจับข้อผิดพลาดในเหตุผลของคณะกรรมการรีวิวเองได้เช่นกัน
หลังจากผ่านการตรวจสอบทั้งหมดแล้ว คิว merge จะตรวจสอบทุก branch อีกครั้งเทียบกับปลายสุดของ main ที่เคลื่อนที่อยู่ตลอดเวลา แล้วเมื่อ merge สำเร็จก็จะ deploy ขึ้น production โดยอัตโนมัติโดยไม่มีมนุษย์อยู่ใน loop เลย
หลังผ่านทุกด่านแล้ว คิว merge จะตรวจสอบ branch อีกครั้ง และเมื่อ merge สำเร็จก็จะ deploy ขึ้น production
จำนวนบรรทัดโค้ดเป็นแค่ส่วนเล็ก ๆ ของเรื่องราว
ตลอดการทำงานของ PR แบบขับเคลื่อนตัวเองจำนวนมาก เราพบแพตเทิร์นที่น่าประหลาดใจแต่ก็สมเหตุสมผล นั่นคือ เวลาที่ใช้ในการวนซ้ำแก้ไขตามการตรวจสอบและการรีวิวนั้นนานกว่าเวลาที่ใช้เขียน implementation แรกมาก และ อัตราส่วนนี้ก็แตกต่างกันมากตามประเภทของงานด้วย ต่อไปนี้เราจะเปรียบเทียบงานพัฒนาสองประเภทในสัปดาห์เดียวกัน
กรณี A: ปลดระวางฟีเจอร์ที่ตายแล้ว ฟีเจอร์เก่าเล็ก ๆ ตัวหนึ่งถูกปิดใช้งาน ลิงก์ กล่องยืนยัน คำแปล การทดสอบ และ screenshot baseline ของมันต้องถูกลบทิ้งทั้งหมด จากตอนที่ยื่น Linear issue จนถึง PR ถูก merge เข้า main ใช้เวลาแค่ 16 นาที โดย 2 นาทีแรกใช้เขียนโค้ด การรีวิวเป็นแค่คำแนะนำเท่านั้น
กรณี B: การปรับปรุงครั้งใหญ่กับฟีเจอร์วินิจฉัยเครือข่าย เป็นการเปลี่ยนแปลงที่มีขนาดใกล้เคียงกันเมื่อนับตามจำนวนบรรทัด โดยเวอร์ชันแรกเสร็จภายใน 5 นาที แต่เวลารวมจนถึง merge อยู่ที่ราว 3 ชั่วโมง ตลอดกระบวนการนี้ agent แก้ไขการรีวิวไป 5 รอบ และข้อค้นพบที่บล็อกการ merge อีก 7 ข้อ
ไทม์ไลน์ของทั้งสองก็แตกต่างกันมากเช่นกัน
| กรณี A: ปลดระวางฟีเจอร์ที่ตายแล้ว | กรณี B: ปรับปรุงเครื่องมือวินิจฉัย | |
|---|---|---|
| ขนาดการเปลี่ยนแปลง | +10 / -125, 8 ไฟล์ | +439 / -19, 9 ไฟล์ |
| เวอร์ชันแรกที่ใช้งานได้ | 2 นาที | 5 นาที |
| จากยื่น issue ถึง merge | 16 นาที | 3 ชั่วโมง |
| นานกว่าเวอร์ชันแรกกี่เท่าจึงจะ merge ได้ | 8 เท่า | 36 เท่า |
| ข้อค้นพบจากรีวิวที่บล็อก merge | ไม่มี (เป็นแค่คำแนะนำ) | 7 ข้อ ใน 5 รอบ |
| กรณีเลวร้ายที่สุดหากโค้ดผิดพลาด | ลิงก์ที่ไม่ควรมีใครคลิกอยู่แล้ว | ผู้ใช้ทุกคนเชื่อตัวเลขที่ผิด |
งานสองอย่างที่มีจำนวนบรรทัดใกล้เคียงกัน ได้รับความพยายามในการตรวจสอบตามสัดส่วนความเสี่ยง
งานที่สองใช้เวลานานกว่าถึงสิบเอ็ดเท่า ไม่ใช่เพราะโค้ดเขียนยากกว่า แต่เพราะความเสี่ยงต่างกัน และความพยายามในการตรวจสอบก็ถูกใช้ไปตามสัดส่วนนั้น กรณี A คือการลบทิ้ง ผลลัพธ์เลวร้ายที่สุดคือลิงก์เสียที่ไม่ควรมีใครเข้าไปอยู่แล้ว กรณี B คือเครื่องมือวัดค่า ผลลัพธ์เลวร้ายที่สุดคือผู้ใช้ทุกคนเชื่อตัวเลขที่ผิด คณะกรรมการรีวิวพบข้อผิดพลาดเหล่านั้น แล้วใช้เวลาอีกสามรอบปฏิเสธการแก้ไขแบบครึ่ง ๆ กลาง ๆ จนกว่าการจัดการ error จะมีการระบุ type ครบถ้วน และผ่านการทดสอบอย่างละเอียด แต่ละรอบทำให้ implementation รัดกุมขึ้นอย่างเคร่งครัด ไม่มีข้อบกพร่องใดในนี้ที่ทำให้การทดสอบล้มเหลว และทุกข้อก็คงจะถูกปล่อยออกไปแล้วถ้าไม่มีการตรวจสอบนี้
นี่คือจุดที่การสร้างโค้ดแบบ one-shot ทำผิดโดยธรรมชาติของมันเอง การสร้างโค้ดแบบ one-shot จะปรับให้เหมาะกับตัวชี้วัดที่มองเห็นได้ง่ายที่สุด นั่นคือเวลาตั้งแต่ prompt จนถึงโค้ดที่ compile และรันได้ ทั้งสองกรณีของเราทำตัวชี้วัดนั้นได้ภายในไม่กี่นาที และถ้าเราหยุดอยู่แค่นั้น กรณี B ก็คงเสร็จภายในไม่กี่นาทีหลังเริ่มต้น แล้วก็จะผิดพลาดต่อไปอีกหลายเดือน
pipeline เดียวกันที่ปล่อยให้การลบทิ้งผ่านไปได้ภายใน 16 นาที กลับกักเครื่องมือวัดค่าไว้นานถึง 3 ชั่วโมง โดยไม่มีมนุษย์คนไหนตัดสินใจว่าแต่ละกรณีควรได้รับการปฏิบัติแบบไหน เมื่อคนถามว่าโค้ดที่เขียนโดย AI เชื่อถือได้ใน production หรือไม่ นี่คือคำตอบ โค้ดน่าเชื่อถือได้พอ ๆ กับการตรวจสอบที่ห่อหุ้มมันอยู่เท่านั้น และความลึกของการตรวจสอบตอนนี้ก็เป็นสิ่งที่คุณซื้อได้ด้วยชั่วโมงของ agent แทนที่จะเป็นวัน-คนของวิศวกร รายงานความเร็วที่ผิดพลาดมีต้นทุนสูงกว่าสามชั่วโมง ตั้งแต่ครั้งแรกที่ใครสักคนใช้มันในการจัดการข้อร้องเรียนเรื่องเครือข่าย
สิ่งที่เราเรียนรู้และก้าวต่อไป
ทุกวันนี้ ความเป็นอิสระเป็นคุณสมบัติของ harness มากกว่าคุณสมบัติของโมเดล ทุกครั้งที่โมเดลอัปเกรด agent ของเราก็ดีขึ้น แต่ความสามารถของโมเดลเองไม่ได้มาพร้อมการรับประกันว่าคุณจะไว้ใจให้ agent merge pull request ของมันเองได้อย่างอิสระ แทนที่จะทุ่มความสนใจของมนุษย์เพิ่มขึ้น หรือใช้โมเดล frontier ที่แพงที่สุดแบบไม่คิดหน้าคิดหลัง เราเลือกที่จะสร้าง "มือ" และ "ตา" เพื่อให้ agent มีทุกอย่างที่จำเป็นสำหรับการผลิตโค้ด production ที่ถูกต้อง และเมื่อความสามารถของโมเดลพัฒนาขึ้นเรื่อย ๆ สิ่งนี้ก็ทำให้เราโต้คลื่นไปกับมันได้ แทนที่จะต้องสร้าง scaffold ใหม่เพื่อชดเชยข้อจำกัดของโมเดล
บทบาทของมนุษย์เข้มข้นขึ้น ไม่ได้หายไป สิ่งที่เหลืออยู่คือแก่นที่ลดทอนไม่ได้อีกแล้ว นั่นคือการตัดสินใจว่าอะไรคุ้มค่าที่จะสร้าง เขียนมันลงไปให้ชัดเจนพอ และใช้วิจารณญาณในช่วงเวลาที่เครื่องจักรแจ้งว่ายังกำกวมอยู่ รสนิยมในการออกแบบและคุณภาพของสเปกตอนนี้กลายเป็นทักษะทางวิศวกรรมที่ทรงพลังที่สุดในทีมนี้
และข้อสรุปที่น่าสนใจที่สุดเกี่ยวกับทีม agent ก็คือ คุณค่าของทีมมาจากความขัดแย้ง ไม่ใช่จากความร่วมมือ การแบ่งงาน full-stack ออกเป็น agent ฝั่งฟรอนต์เอนด์กับแบ็กเอนด์อาจสมเหตุสมผล แต่การให้ agent ฝั่งฟรอนต์เอนด์กับแบ็กเอนด์คุยกันเองเพียงเพื่อทำงานให้เสร็จนั้นสมเหตุสมผลน้อยกว่า ประโยชน์ของทีมจะเกิดขึ้นเมื่อสมาชิกมีเป้าหมายที่ขัดแย้งกัน agent พัฒนา Muse ของเราต้องการส่งโค้ดออกไป ในขณะที่ agent รีวิว AI ของเราต้องการหาจุดที่โค้ดผิดพลาดหรือออกแบบมาไม่ดี ความตึงเครียดระหว่างพวกมันนี่แหละที่ทำให้ผลลัพธ์น่าเชื่อถือ และเผยให้เห็นปริมาณงานที่แท้จริงของงานพัฒนาแต่ละชิ้นอย่างซื่อตรง
สิ่งที่สำคัญกว่านั้นคือ เราพบว่าการสำรวจของเรานำเราไปสู่วิธีการพัฒนาซอฟต์แวร์แบบใหม่ที่กำลังเกิดขึ้น นั่นคือ องค์กรวิศวกรรมแบบอัตโนมัติ แม้ว่าเราจะแสดงให้เห็นแล้วว่า agent สามารถทำงานแต่ละชิ้นได้อย่างอัตโนมัติด้วยเครื่องมือที่มีอยู่ แต่ก็ยังมีชิ้นส่วนที่ขาดหายไปและคำถามที่ยังเปิดอยู่ไม่กี่ข้อที่รอความพยายามในอนาคต
- เราจะขยายระบบแบบนี้ให้ใหญ่ขึ้นได้มากแค่ไหน เมื่อองค์กรอัตโนมัติทำงานกับงานและโปรเจกต์ที่ใหญ่ขึ้นเรื่อย ๆ ด้วย agent ที่ทำงานคู่ขนานมากขึ้น จะมีปัญหาใหม่อะไรเกิดขึ้นบ้าง?
- ผลลัพธ์ของ harness เอง เช่นอัตราการผ่าน CI ในครั้งแรกและข้อค้นพบจากการรีวิว AI จะกลายเป็นสัญญาณสำหรับการประเมินได้อย่างไร เราจะวัดประสิทธิภาพของ agent ในองค์กรได้อย่างไร และเราจะทำให้มันพัฒนาตัวเองได้อย่างไร?
- รสนิยมด้านการออกแบบและผลิตภัณฑ์ของมนุษย์จะถูกฝังลงในระบบแบบนี้ได้อย่างไร ถ้าวิศวกรรมสามารถทำให้เป็นอัตโนมัติได้ด้วยวิจารณญาณของมนุษย์เพียงเล็กน้อย เราจะไปได้ไกลแค่ไหนในการแก้ปัญหาว่าเราควรสร้างซอฟต์แวร์ให้ใครและมันควรมีหน้าตาเป็นอย่างไร?
สุดท้ายนี้ ขอบคุณที่อ่านมาจนถึงตอนจบ รายการสิ่งที่ต้องทำเพื่อหาคำตอบของคำถามเหล่านี้อยู่ใน Linear อย่างเหมาะสม ซึ่ง agent ตัวต่อไปของเรา หรือแม้แต่คุณเอง อาจจะหยิบมันขึ้นมาทำต่อก็ได้
