Osloq คือ AI ที่รับงานน่าเบื่อที่สุดของการตามแก้บั๊กไปทำแทนทีมพัฒนาซอฟต์แวร์ บั๊กคืออาการที่โปรแกรมทำงานผิดไปจากที่ควรจะเป็น เวลาผู้ใช้เจอบั๊ก ก็มักไปเปิดรายงานปัญหาที่เรียกกันว่า issue ค้างไว้บน GitHub เว็บที่ทีมพัฒนาใช้เก็บโค้ดและรับเรื่องบั๊กจากผู้ใช้ หน้าที่ของ Osloq คือรับ issue นั้นมา แล้วลงมือทำให้บั๊กตัวนั้นเกิดซ้ำให้เห็นกับตาจริง ๆ

ฟังดูเป็นขั้นเล็ก ๆ แต่จริง ๆ แล้วนี่คือส่วนที่กินเวลาที่สุดของการแก้บั๊ก เพราะในการทำงานจริง มีสองคำที่นักพัฒนาเกลียดที่สุดคือ "cannot reproduce" หรือทำให้บั๊กเกิดซ้ำไม่ได้ และพอทำให้เกิดซ้ำไม่ได้ ก็แก้ไม่ได้ ปิดเรื่องนั้นก็ไม่ลง ได้แต่ดองค้างไว้อย่างนั้น

ไม่ใช่ตัวแก้บั๊ก แต่เป็นตัวยืนยันบั๊ก

เครื่องมือ AI สายไล่บั๊กส่วนใหญ่ชอบกระโดดข้ามไปเสนอ "ทางแก้" ให้เลย เห็นข้อความ error ปุ๊บก็เดาว่าควรแก้บรรทัดไหน แต่ Osloq เลือกหยุดอยู่ที่ขั้นก่อนหน้านั้น มันไม่เสนอทางแก้ ไม่เขียนโค้ดให้ และไม่ส่งโค้ดกลับเข้าไปแก้ในโปรเจกต์เลย หน้าที่เดียวของมันคือยืนยันว่าบั๊กในรายงานนั้นเกิดขึ้นจริงหรือไม่ และเกิดตรงไหน

วิธีใช้ก็ตรงไปตรงมา เริ่มจากเชื่อม repo หรือที่เก็บโค้ดของโปรเจกต์บน GitHub เข้ากับ Osloq เลือก issue ที่อยากรู้ความจริง แล้วปล่อยให้มันไปตรวจสอบ สิ่งที่ได้กลับมาไม่ใช่ความเห็น แต่เป็นผลสรุปที่ชี้ชัดว่าเกิดอะไรขึ้นพร้อมหลักฐานแนบ ทั้ง log หรือบันทึกการทำงานที่รันออกมาจริง สกรีนช็อตตอนบั๊กโผล่ และลำดับการทำงานของโค้ดที่ชี้ว่าพังตรงจุดไหน

สี่ขั้น จาก issue ถึงผลสรุปที่มีหลักฐาน

เบื้องหลังผลสรุปหนึ่งชุด Osloq ทำงานสี่ขั้น:

1. อ่าน issue ให้เข้าใจก่อน · มันอ่านรายละเอียดในรายงาน แล้วไล่หาโค้ดกับ commit หรือการแก้ไขที่เกี่ยวข้องกับอาการนั้น
2. ตั้งพื้นที่ทดลองที่แยกออกมา · ดึงโค้ดของโปรเจกต์ไปรันในพื้นที่ทดลองใหม่ที่แยกจากระบบจริง (เรียกว่าแซนด์บ็อกซ์) เพื่อไม่ให้ไปกระทบอะไรของเรา
3. ลองทำให้บั๊กเกิดซ้ำ · รันขั้นตอนที่เกี่ยวข้องจริง ๆ พร้อมเก็บ log สกรีนช็อต และข้อความ error ที่โผล่ระหว่างทางไว้เป็นหลักฐาน
4. สรุปผลพร้อมหลักฐาน · บอกว่าทำให้เกิดซ้ำได้หรือไม่ ผูกหลักฐานกลับเข้ากับ issue นั้น ชี้ลำดับการทำงานของโค้ดที่พัง และบอกขั้นต่อไปให้นักพัฒนาทำต่อได้ทันที โดยไม่ต้องไปไล่เก็บรายละเอียดเองใหม่

จุดที่ทำให้มันต่างจากการเดาคือขั้นที่สาม เพราะมันไม่ได้อ่านโค้ดแล้วสรุปเอา แต่ลงมือรันจริงจนบั๊กโผล่ออกมาให้เห็นกับตา

ทำไมต้องทำให้เกิดซ้ำก่อน ถึงจะแก้ได้

ลองคิดตามง่าย ๆ ถ้าบั๊กหนึ่งตัวยังทำให้เกิดซ้ำไม่ได้ เราจะเชื่อ "ทางแก้" ของมันได้ยังไง ทางแก้ที่เดาจากอาการโดยไม่เคยเห็นบั๊กเกิดจริง จะแก้ถูกก็ได้ แก้ผิดจุดก็ได้ และกว่าจะรู้ว่าผิดก็เสียเวลาไปอีกรอบ

นี่คือเหตุผลที่การทำให้เกิดซ้ำต้องมาก่อน เพราะมันเปลี่ยนรายงานบั๊กที่คลุมเครืออย่าง "กดแล้วมันพัง" ให้กลายเป็นสิ่งที่ลงมือแก้ได้ทันที ในเมื่อมีหลักฐานบอกชัดว่าพังยังไงและพังตรงไหน Osloq จึงรับส่วนที่น่าเบื่อและกินเวลานี้ไปทำแทน นักพัฒนาจะได้เอาเวลาไปโฟกัสกับสิ่งที่ AI ยังทำแทนได้ไม่ดีนัก นั่นคือการตัดสินใจว่าจะแก้มันยังไง

บั๊กที่ทำให้เกิดซ้ำไม่ได้ ก็คือบั๊กที่ยังแก้ไม่ได้ การทำให้มันเกิดซ้ำพร้อมหลักฐานต่างหากที่เป็นจุดเริ่มต้นจริงของการแก้

ปล่อย AI เข้าถึงโค้ดแล้วปลอดภัยแค่ไหน

การให้ AI เข้าถึงที่เก็บโค้ดเป็นเรื่องที่ทีมไหนก็กังวล Osloq เลยวางกติกาไว้ค่อนข้างชัด

การเชื่อมต่อทำผ่าน GitHub App แบบ least-privilege หรือให้สิทธิ์ต่ำสุดเท่าที่จำเป็น และเป็นแบบอ่านอย่างเดียว (read-only) เฉพาะที่เก็บโค้ดที่เราอนุญาตเท่านั้น เราคุมขอบเขตได้เองตั้งแต่โปรเจกต์เดียวไปจนถึงทั้งองค์กร และถอนสิทธิ์เมื่อไหร่ก็ได้ ที่สำคัญคือมันไม่ส่งการแก้ไขกลับเข้าไป และไม่แตะโค้ดของเราแม้แต่บรรทัดเดียว

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

เรื่องข้อมูลลับอย่างรหัสหรือคีย์ต่าง ๆ (secret) ก็คิดเผื่อไว้แล้ว เราจะให้ข้อมูลลับของโปรเจกต์กับมันหรือไม่ก็ได้ ถ้าให้ มันจะทำให้เกิดซ้ำในสภาพแวดล้อมที่ใกล้เคียงระบบจริงมากขึ้น ถ้าไม่ให้ มันจะข้ามส่วนที่ต้องพึ่งข้อมูลนั้น แล้วทำให้เกิดซ้ำต่อได้อยู่ดี ไม่ว่าจะเลือกแบบไหน ตัวโมเดลเห็นแค่ "ชื่อ" ของข้อมูลลับ ไม่เคยเห็น "ค่า" ของมันเลย

รองรับภาษาอะไร ราคาเท่าไร เริ่มตรงไหน

วันนี้ Osloq รองรับโปรเจกต์ที่เขียนด้วยสี่ภาษาคือ JavaScript, TypeScript, Python และ Go หน้าเว็บบอกว่าออกแบบให้เข้าใจโค้ดได้หลายภาษาและกำลังขยายต่อ แต่ที่รองรับจริงตอนนี้คือสี่ภาษานี้ ถ้าโปรเจกต์เราใช้ภาษาอื่นก็ต้องรอไปก่อน

ราคาแบ่งเป็นสามแผน คิดเงินรายเดือนเป็นสกุลดอลลาร์:

เลือกแผนไหนก็ดูตามการใช้จริง เริ่มที่ Free ไปก่อนเพื่อดูว่ามันเข้ากับวิธีทำงานของเราไหม ขยับขึ้น Pro เมื่อ 5 ครั้งต่อเดือนเริ่มไม่พอ ส่วน Team เหมาะเมื่อต้องแชร์สิทธิ์และประวัติการตรวจสอบกันทั้งทีม เพราะมีระบบคุมสิทธิ์รายคน (role-based access control) ให้กำหนดว่าใครทำอะไรได้บ้าง

ทั้งสามแผนเริ่มใช้ฟรีได้โดยไม่ต้องใส่บัตรเครดิต และยกเลิกได้ทุกเมื่อ อยากเริ่มวันนี้ก็ทำเพียงสามขั้นตอน คือเชื่อมที่เก็บโค้ดบน GitHub เข้ากับ Osloq แล้วเลือก issue สักอันที่ค้างคาใจ จากนั้นปล่อยให้มันไปยืนยันว่าเกิดอะไรขึ้นจริง

สิ่งที่ Osloq ไม่ได้ทำแทน

ก่อนจะลอง มีขอบเขตที่ต้องเข้าใจให้ตรงกันก่อน นั่นคือ Osloq ทำหน้าที่ทำให้บั๊กเกิดซ้ำและให้หลักฐานเท่านั้น มันไม่ใช่ตัวแก้บั๊กและไม่ส่งโค้ดที่แก้แล้วกลับเข้าไปให้ ข้อนี้ไม่ใช่เพราะมันทำไม่ได้ แต่เป็นสิ่งที่ตั้งใจออกแบบมาให้ทำงานแบบอ่านอย่างเดียวตั้งแต่ต้น เพราะการยืนยันความจริงกับการลงมือแก้เป็นงานคนละแบบกัน

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

ที่ผ่านมาเรามักมองว่างานไล่บั๊กคือ "การหาทางแก้" แต่จริง ๆ แล้วครึ่งหนึ่งของงานคือการพิสูจน์ให้ได้ก่อนว่าบั๊กมีอยู่จริงและอยู่ตรงไหน พอมีเครื่องมือมารับขั้นพิสูจน์นี้ไป คำว่า cannot reproduce ก็ค่อย ๆ กลายเป็นเรื่องที่เจอน้อยลง เหลือไว้แค่บั๊กที่รอการตัดสินใจว่าจะแก้มันยังไง

---

ที่มา: เว็บไซต์ทางการ Osloq