Devin เปิด Code Scans: สั่งด้วยเป้าหมายกว้าง ๆ แล้วให้ agent กระจายอ่านทั้ง repo — ลดเวลาคอมไพล์ Dioxus ลง 64%

งานวิศวกรรมจำนวนมากค้างอยู่ใน backlog ไม่ใช่เพราะยาก แต่เพราะ ขั้นแรกมันใหญ่เกินจะเริ่ม — “ทำให้แอปคอมไพล์เร็วขึ้น” หรือ “ลดหนี้ทางเทคนิค” ไม่มีไฟล์ให้เปิดเป็นไฟล์แรก ต้องไล่อ่านทั้ง repo ก่อนถึงจะรู้ว่าควรเริ่มตรงไหน

เมื่อ 16 กันยายน 2026 Cognition ปล่อย Code Scans ซึ่งจับโจทย์นี้ตรง ๆ: พิมพ์ /scan ในเว็บแอป Devin บอกเป้าหมายเป็นภาษาคน แล้วมันจะช่วยแปลงเป็นขอบเขตการสืบสวนที่เป็นรูปธรรม ไล่อ่านทั้งโค้ดเบส คืนรายการปัญหาที่จัดลำดับความสำคัญแล้ว และเปิด PR ให้ตัวที่คุณเลือก

Agentic MapReduce: สี่เฟสที่ยืมมาจาก Security Swarm

สถาปัตยกรรมเบื้องหลังชื่อ Agentic MapReduce ซึ่ง Cognition สร้างไว้ก่อนสำหรับ Devin Security Swarm แล้วเอามาใช้ต่อ ทำงานสี่เฟส:

1. Plan — Devin อ่าน repo แล้วนิยาม กฎ ว่าโค้ดแบบไหนเกี่ยวกับเป้าหมาย (เช่นงานหา dead code: export ที่ไม่มีใคร import, โมดูลที่ไม่ถูกอ้างถึง, dependency ที่ไม่ได้ใช้, feature flag ที่ตกค้าง)
2. Shard — เอากฎไปรันทั่วโค้ดเบส แล้วแบ่งโค้ดที่เข้าเกณฑ์เป็นก้อนย่อย
3. Map — agent หลายตัวรันขนานกัน แต่ละตัวสืบก้อนของตัวเอง อ่านโค้ดรอบข้างเพิ่มตามต้องการ แล้วรายงานสิ่งที่พบ
4. Reduce — agent ตัวสุดท้ายรวมผล ตัดรายการซ้ำ จัดลำดับความสำคัญเป็นรายงานเดียว

เหตุผลเชิงวิศวกรรมที่ Cognition ให้ไว้น่าสนใจกว่าตัวสถาปัตยกรรมเอง: การ shard ทำให้ context ของแต่ละ agent แคบและตรงเป้า งบการคิดจึงถูกใช้ไปกับการอ่านโค้ดที่เกี่ยวข้อง แทนที่จะถูกเผาไปกับการ search ซ้ำ ๆ และการบังคับว่าทุกก้อนที่ถูกเลือกต้องถูกประมวลผลคือสิ่งที่ให้ ความครบถ้วน — ซึ่งเป็นจุดอ่อนคลาสสิกของการปล่อย agent ตัวเดียวเดินสำรวจ repo เอง แล้วมันหยุดตรงไหนก็ไม่มีใครรู้

เดโมที่วัดผลได้จริง

Cognition ยกตัวอย่างสองงานพร้อมตัวเลขก่อน-หลัง:

ลดเวลาคอมไพล์ Rust — สั่งสแกน repo Dioxus เพื่อหาทางเร่งการคอมไพล์ Devin เจอโอกาสหลายจุด เช่น feature mounted ที่เปิดเป็นค่าเริ่มต้นแล้วลาก web-sys / js-sys / wasm-bindgen เข้ามาให้ renderer ที่ไม่ใช่เว็บทุกตัว, cargo-generate ที่ถูกคอมไพล์ทุกครั้งทั้งที่ใช้แค่ตอน dx create (และมันลาก git2/libgit2-sys ซึ่งต้องบิลด์ไลบรารี C มาด้วย), และ dioxus-ssr ที่ประกาศ tokio แบบ features = ["full"] ทั้งที่ใช้จริงแค่ tokio::fs กับ tokio::io-util ผลหลังแก้: เวลาบิลด์ debug แบบ clean ลดจาก 58.6 เหลือ 21.0 วินาที (−64%) จาก 22 crate ที่ทดสอบ

งาน SEO — สแกน repo ของ devin.ai และ cognition.com เจอ 44 จุด เทียบ crawl ของ Ahrefs ก่อน-หลังแล้ว health score ขึ้นจาก 87 เป็น 92, หน้าช้าลดลง 73% และ alt text ที่หายไปถูกเก็บครบ ตัวอย่างสิ่งที่มันเจอค่อนข้างละเอียด เช่น og:image ที่เป็น path สัมพัทธ์ไม่มีโดเมน (ผิดสเปก Open Graph), redirect chain สองทอดบน URL ที่มี backlink จริง 157 เส้น และหน้า event ที่จบไปแล้วแต่ยังไม่ได้ตั้ง robots: {index:false} ทำให้ snippet ในผลค้นหายังโฆษณาว่างานยังเปิดลงทะเบียน

ลูกค้าที่ทดสอบก่อนเปิดตัว — ทีม Digital Computational Pathology ของ Philips — ให้ตัวเลขว่า PR merge rate ราว 96% และประเมินว่าประหยัดเวลาวิศวกรไปกว่า 700 ชั่วโมง ในช่วงทดสอบสั้น ๆ (เป็นตัวเลขที่ลูกค้าประเมินเอง ไม่ใช่การวัดอิสระ)

ประเภทของสแกนที่ Cognition แนะนำไว้ครอบคลุม performance, N+1 query, test coverage, dead code, code quality, telemetry, accessibility ตาม WCAG, compliance, การวางแผน migration และ SEO — หรือจะนิยามเกณฑ์เองก็ได้ เช่น coding standard ของทีม หรือเช็กลิสต์สำหรับ migration ที่กำลังจะมาถึง

มุมมอง AI Curator

ข้อกล่าวหาที่ดังขึ้นเรื่อย ๆ ตลอดปีนี้คือ agent swarm เผาโทเคนทิ้งโดยไม่ได้คุณภาพเพิ่ม และ Code Scans คือตัวอย่างที่ตอบข้อกล่าวหานั้นได้ตรงที่สุดเท่าที่เห็นมา — ความต่างไม่ได้อยู่ที่ “ใช้ agent หลายตัว” แต่อยู่ที่ ใครเป็นคนแบ่งงาน ใน swarm ทั่วไป agent แต่ละตัวต้องหาเองว่าจะอ่านอะไร ซึ่งแปลว่าทุกตัวจ่ายค่าสำรวจ repo ซ้ำกันหมด ส่วน MapReduce แบ่งก่อนแล้วค่อยแจก ต้นทุนการสำรวจจึงจ่ายครั้งเดียวในเฟส Plan ตรงนี้คือความแตกต่างที่จับต้องได้ระหว่าง “ขนานกัน” กับ “ขนานกันอย่างมีแผน”

แต่เฟสที่ผมสนใจที่สุดคือ Reduce เพราะมันคือจุดที่งานประเภทนี้มักพัง ทีมไหนเคยรัน static analysis ทั้ง repo จะรู้ดีว่าปัญหาไม่ใช่ “หาไม่เจอ” แต่คือ เจอ 3,000 รายการแล้วไม่มีใครอ่าน การมี agent มาตัดซ้ำและจัดลำดับก่อนส่งถึงมนุษย์ คือส่วนที่ทำให้มันเป็นเครื่องมือแทนที่จะเป็นเครื่องผลิต noise — และตัวเลข 44 finding จากสองเว็บไซต์ (ไม่ใช่ 440) ก็ชี้ไปทางนั้น

สำหรับทีมไทย มีโจทย์หนึ่งที่เหมาะกับเครื่องมือแบบนี้ผิดปกติ: หนี้ทางเทคนิคของระบบที่คนเขียนลาออกไปแล้ว ซึ่งเป็นสภาพที่บริษัทซอฟต์แวร์ไทยเจอกันแทบทุกที่ เพราะสิ่งที่ Code Scans ให้จริง ๆ ไม่ใช่การแก้โค้ด แต่คือ แผนที่ ว่าปัญหาอยู่ตรงไหนบ้าง ซึ่งเป็นสิ่งที่เดิมต้องใช้ senior คนหนึ่งนั่งอ่านสองสัปดาห์

ข้อควรระวังคือ Code Scans เป็นฟีเจอร์ปิดบนแพลตฟอร์ม Devin ไม่ใช่ของที่ self-host ได้ — แปลว่าโค้ดเบสทั้งก้อนต้องขึ้นไปอยู่บนคลาวด์ของ Cognition ซึ่งสำหรับงานที่มีข้อผูกพัน NDA หรือระบบภาครัฐไทยนั้นจบตั้งแต่ข้อนี้ และตัวเลข merge rate 96% ก็ควรอ่านว่า “PR ที่ทีมเลือกให้เปิดแล้ว merge ผ่าน” ไม่ใช่ “AI แก้ถูก 96% ของปัญหาทั้งหมด” — มนุษย์ยังคัดอยู่หน้างานทุกขั้น และนั่นคือส่วนที่ทำให้มันใช้ได้

แหล่งข่าว

• Introducing Code Scans — Devin Blog, Cognition (16 ก.ย. 2026)
• Code Scans — เอกสาร Devin
• Dioxus — repo ที่ใช้ในเดโมลดเวลาคอมไพล์