นี่คือสิ่งที่เราได้เรียนรู้จากการสร้างความสามารถในการทดสอบแบบ end-to-end ภายในเครื่องเสมือนของ Devin
เมื่อ 3 เดือนที่แล้ว ผมเข้าร่วม Cognition เพื่อช่วยสร้างอนาคตของวิศวกรรมซอฟต์แวร์ Devin มาไกลมากนับตั้งแต่เปิดตัวในฐานะวิศวกรซอฟต์แวร์ AI คนแรก และผมก็ทึ่งมากที่ได้เห็นทีมที่อยู่เบื้องหลังใช้ Devin จริงๆ ทุกวัน
สิ่งหนึ่งที่โดดเด่นคือวิธีที่ Devin ใช้คอมพิวเตอร์ของมันเพื่อตรวจสอบงานอย่างอิสระบนคลาวด์ ตั้งแต่ การตรวจสอบการผสานรวม Slack ของเรา ไปจนถึงการทดสอบฟีเจอร์ Windsurf ที่ซับซ้อน ทีมงานมักจะมีกองทัพ Devin ในโหมดทดสอบอยู่เสมอ ในโพสต์นี้ ผมจะแบ่งปันว่าทำไมเราถึงให้ความสำคัญกับการตรวจสอบเอเจนต์บนคลาวด์แบบ end-to-end และวิธีที่เรากำลังดำเนินการสร้างมันขึ้นมา
การเปลี่ยนผ่านสู่วิศวกรรมซอฟต์แวร์แบบอะซิงโครนัส
ที่ Cognition เราเพิ่งบรรลุเหตุการณ์สำคัญใหม่ เป็นครั้งแรกที่มี Devin จำนวนมากถูกเรียกใช้แบบอะซิงโครนัส ผ่านอีเวนต์ ระบบอัตโนมัติ ตารางเวลา และ Devin อื่นๆ เราคาดว่าสิ่งนี้จะยังคงเร่งตัวขึ้นต่อไปเมื่อเรามีการเปิดตัว Auto-Triage ล่าสุด
ในขณะที่เรากำลังเปลี่ยนผ่านสู่โลกแบบอะซิงโครนัสนี้ เป็นสิ่งสำคัญอย่างยิ่งที่นักพัฒนาจะสามารถกลับมาที่ผลลัพธ์ที่ได้รับการตรวจสอบแล้วซึ่งพร้อมที่จะถูกผสานได้ เมื่อต้นปีที่ผ่านมา เราเปิดตัว Devin Review ซึ่งเป็นเครื่องมือตรวจสอบโค้ดที่ขยายความเข้าใจของมนุษย์เกี่ยวกับความแตกต่างของโค้ดที่ซับซ้อน มันไม่เพียงแค่แจ้งข้อบกพร่อง - Devin ปิดวงจร ด้วยการแก้ไขแต่ละสิ่งที่พบจนกว่าความแตกต่างจะกลับมาสะอาด แต่การตรวจสอบที่สะอาดเพียงอย่างเดียวมักจะไม่เพียงพอ - วิศวกรต้องการเห็นการเปลี่ยนแปลงที่ทดสอบแบบ end-to-end เช่นเดียวกับวิธีที่พวกเขาจะทดสอบด้วยตนเอง
เป็นความรู้สึกที่ยอดเยี่ยมเมื่อ Devin สร้าง PR แก้ไขข้อร้องเรียนของผู้ใช้ ก่อนที่คุณจะมีโอกาสเห็นข้อความในช่องบั๊กเสียอีก สิ่งที่ทำให้มันมหัศจรรย์คือเมื่อ PR นั้นมาพร้อมกับหลักฐานว่าการแก้ไขใช้งานได้จริง และความมหัศจรรย์นี้อาจกลายเป็นสิ่งจำเป็นในไม่ช้า - เมื่อ PR มากขึ้นมาจากการเพิ่มขึ้นของเอเจนต์เชิงรุก การเปลี่ยนแปลงที่ไม่ได้รับการตรวจสอบก็จะจัดการได้ยากขึ้นอย่างรวดเร็ว
จากจุดเริ่มต้น
ตั้งแต่ Devin เปิดตัว มันก็สามารถสาธิตการทำงานบนเครื่องเสมือนคลาวด์ได้เสมอ เมื่อประมาณ 6 เดือนที่แล้ว เราขยายความสามารถในการใช้งานคอมพิวเตอร์ของ Devin ซึ่งในทางปฏิบัติหมายความว่าเราได้เพิ่มเครื่องมือให้กับชุดควบคุมของ Devin เพื่อจับภาพหน้าจอ เลื่อนเมาส์ คลิก ลาก พิมพ์ กดปุ่ม เลื่อน รอ ซูม และเริ่ม/หยุดการบันทึก การใช้งานคอมพิวเตอร์มีมาระยะหนึ่งแล้ว แต่เรารู้สึกว่ารุ่นล่าสุดของโมเดลจากห้องปฏิบัติการชั้นแนวหน้าเริ่มเก่งในการใช้เครื่องมือเหล่านี้จริงๆ
การใช้งานคอมพิวเตอร์ปลดล็อกความสามารถใหม่ที่สนุกสนานสำหรับ Devin เช่น การสร้างและเล่นเกมบนเดสก์ท็อป หรือการใช้เบราว์เซอร์เพื่อสั่งซื้อสินค้าบน Amazon แต่สิ่งที่เราสังเกตเห็นว่าปลดล็อกได้อย่างแท้จริงคือความสามารถของ Devin ในการทดสอบงานของตัวเอง Devin จะเปิดแอปขึ้นมา คลิกผ่านมัน และยืนยันว่าการเปลี่ยนแปลงของมันใช้งานได้จริง เช่นเดียวกับที่วิศวกรทำ ทุกอย่างทำงานบนคลาวด์และสามารถปรับขนาดแบบขนานได้ สิ่งนี้ทำให้ผมประทับใจจริงๆ เมื่อเห็นวิศวกรรัน Devin 10 ถึง 20 ตัวพร้อมกัน แต่ละตัวมีเซิร์ฟเวอร์ dev ของตัวเอง ทำงานผ่านการเปลี่ยนแปลง – นี่คือสิ่งที่คุณไม่สามารถทำได้บนแล็ปท็อปเครื่องเดียว การทดสอบคลาวด์อัตโนมัติเริ่มช่วยเราประหยัดเวลาได้มหาศาล เนื่องจากเราไม่ต้องรันและตรวจสอบโค้ดในเครื่องอีกต่อไป
บอกตามตรง การมาถึงจุดนี้ไม่ใช่เรื่องราบรื่น เราพบโหมดความล้มเหลวมากมายตลอดทาง ซึ่งแต่ละอย่างสอนเราเกี่ยวกับสิ่งที่ต้องทำเพื่อทำให้ระบบนี้เชื่อถือได้มากขึ้น
การเพิ่มความน่าเชื่อถือ
ในเวอร์ชันแรกๆ เป็นเรื่องธรรมดามากที่ Devin จะหลุดออกนอกเส้นทางระหว่างการทดสอบ มันเกิดขึ้นได้หลายวิธี: การทดสอบส่วนอื่นๆ ของผลิตภัณฑ์ที่ไม่เกี่ยวข้องมากเกินไป การหลงทางในการตั้งค่าก่อนที่จะถึงฟีเจอร์ หรือเพียงแค่พลาดพฤติกรรมหลักที่ PR ตั้งใจจะเปลี่ยนแปลงจริงๆ
เพื่อแก้ไขปัญหานี้ เมื่อ Devin เข้าสู่โหมดทดสอบ เราจะให้มันเขียนแผนการทดสอบก่อน โดยระบุเป้าหมายที่ชัดเจนเกี่ยวกับสิ่งที่ต้องทดสอบ แผนนี้ต้องมีพื้นฐานมาจากซอร์สโค้ด ไม่ใช่สมมติฐาน หากไม่มีพื้นฐานในโค้ด เราพบว่าโมเดลมักจะคิดว่าพวกเขาสามารถดำเนินไปตามเส้นทางในแอปที่ไม่มีอยู่จริง นอกจากนี้ แผนการทดสอบยังเพิ่มความซับซ้อนของการเปลี่ยนแปลงที่ Devin สามารถทดสอบได้สำเร็จอย่างมาก คำขอที่ทะเยอทะยานที่สุดของเราบางส่วนรวมถึงฟีเจอร์ที่ต้องใช้บริการหลายตัวทำงาน ต้องกำหนดค่าการตั้งค่าผู้ดูแลระบบเฉพาะ และเปิดใช้งานแฟล็กที่ถูกต้องก่อนที่จะสามารถเข้าถึงพฤติกรรมนั้นได้ เมื่ออ่านโค้ดล่วงหน้า Devin มีแนวโน้มที่จะตั้งค่าสภาพแวดล้อมได้อย่างถูกต้อง แทนที่จะค้นพบสิ่งที่ขาดหายไปครึ่งทางของการทดสอบ แผนการทดสอบทำหน้าที่เป็นรูปแบบหนึ่งของการจัดแนวล่วงหน้า และทำให้ Devin มีแนวโน้มที่จะหลงทางน้อยลงเมื่อทำการทดสอบจริง
ในขณะที่ Devin ดำเนินการตามแผน มันจะเพิ่มคำอธิบายของตัวเองลงในไทม์ไลน์ สิ่งเหล่านี้รวมถึงบันทึกการตั้งค่า จุดเริ่มต้นของการทดสอบแต่ละรายการที่มีชื่อ และการยืนยันที่ทำเครื่องหมายว่าผ่าน ไม่ผ่าน หรือไม่ได้ทดสอบ เราพบว่า Devin จะโกหกเกี่ยวกับสิ่งที่ค้นพบน้อยลง ถ้ามันใส่คำอธิบายเกี่ยวกับพฤติกรรมที่คาดหวังไว้ก่อนที่จะดำเนินการ - คล้ายกับการพัฒนาที่ขับเคลื่อนด้วยการทดสอบ ถ้าคุณยอมรับความคาดหวังล่วงหน้า มันจะทำให้การหาเหตุผลเข้าข้างตนเองสำหรับผลลัพธ์ที่ไม่คาดคิดว่าเป็นการผ่านได้ยากขึ้นมาก
บางส่วนของขั้นตอนการทดสอบจะเกิดขึ้นซ้ำในเกือบทุกการรัน การเข้าสู่ระบบเป็นตัวอย่างคลาสสิก: การขับฟอร์มเข้าสู่ระบบผ่านการใช้งานคอมพิวเตอร์มักหมายถึงการพิมพ์อีเมล ทำ SSO ให้เสร็จ คลิกผ่านการเปลี่ยนเส้นทาง และรอทุกการโหลดหน้า ภาพทีละภาพ สิ่งนี้อาจมีต้นทุนสูงทั้งในด้านเวลาและโทเคน เพื่อปรับปรุงความน่าเชื่อถือและต้นทุนสำหรับการดำเนินการเหล่านี้ Devin ได้แยกงานออกเป็นสคริปต์ที่กำหนดได้ซึ่งอยู่ในทักษะการทดสอบในที่เก็บของเรา ด้วยวิธีนี้ Devin สามารถรันสคริปต์และรับเซสชันเบราว์เซอร์ที่ผ่านการรับรองความถูกต้องได้ภายในไม่กี่วินาที และกระโดดเข้าสู่ส่วนหลักของการทดสอบ ลักษณะที่กำหนดได้ของสคริปต์เหล่านี้ช่วยลดความไม่แน่นอนลงได้อย่างมาก เราอัปเดต Devin ให้ปิดวงจรนี้ด้วยตัวเองเช่นกัน เมื่อมันเข้าใจขั้นตอนการตั้งค่าด้วยวิธีที่ยากแล้ว Devin สามารถแนะนำให้บันทึกความรู้นั้นเป็นทักษะการทดสอบในที่เก็บ และเสนอการแก้ไขกลับไปยังผู้ใช้เป็น PR แบบคลิกเดียว
เรายังกำลังทดลองการกำหนดเส้นทางของเฟสการทดสอบไปยังโมเดลต่างๆ เนื่องจากการทดสอบอาศัยจุดแข็งที่แตกต่างจากการเขียนโค้ด เช่น การอ่านภาพหน้าจอ การติดตามสถานะ UI และการตัดสินใจเกี่ยวกับการกระทำในเบราว์เซอร์ครั้งต่อไป โมเดลบางตัวก็ดีกว่าโมเดลทั่วไปที่คุณจะเลือกสำหรับการแก้ไขโค้ด
การใช้การทดสอบอัตโนมัติใน Devin ปัจจุบัน
ปัจจุบัน Devin เข้าสู่โหมดทดสอบด้วยสองวิธี: การขอให้ทดสอบการเปลี่ยนแปลงอย่างชัดเจน หรือหลังจากที่ Devin สร้าง PR มันจะเสนอให้ทดสอบการเปลี่ยนแปลงถ้าเกี่ยวข้อง จากนั้น มันจะสร้างแผนการทดสอบและเริ่มทำงาน
บ่อยครั้งเมื่อคุณเริ่มใช้ความสามารถในการทดสอบของ Devin ครั้งแรก มันจะต้องการความช่วยเหลือจากคุณ ตัวอย่างที่ดีคือถ้ามันต้องการความลับเมื่อรันแอปของคุณในเครื่อง เพื่อให้กระบวนการนี้ราบรื่นขึ้น Devin สามารถ ขอข้อมูลประจำตัวจากคุณในเซสชัน หรือข้อมูลอื่น ๆ ที่อาจขาดหายไป สำหรับกรณีที่ยากขึ้น คุณสามารถควบคุมคอมพิวเตอร์ของ Devin และป้อนสิ่งต่าง ๆ เช่น รหัส OTP ได้ ข่าวดีคือเมื่อ Devin ตั้งค่าที่เก็บของคุณเสร็จแล้ว มันสามารถบันทึก การกำหนดค่าแบบประกาศ ในรูปแบบของพิมพ์เขียว YAML ที่สร้างสแนปชอตสำหรับทุกเซสชันในอนาคตเพื่อบูตจาก
สิ่งที่คุณจะได้รับกลับมา
เมื่อ Devin ทดสอบเสร็จ มันไม่ได้บอกคุณเพียงว่าแอปทำงานหรือไม่ การบันทึกหน้าจอแบบดิบมีประโยชน์ แต่เรารู้สึกว่ามันไม่เพียงพอในตัวมันเอง - คุณต้องเข้าใจว่าคุณกำลังดูอะไร เหตุใด Devin จึงดำเนินการแต่ละอย่าง และส่วนใดของการทดสอบผ่านหรือไม่ผ่าน
สำหรับการตรวจสอบอย่างรวดเร็ว Devin จะส่งคืนรายงานการทดสอบพร้อมคำอธิบายภาพหน้าจอจากช่วงเวลาสำคัญในการรัน เพื่อให้คุณเห็นได้อย่างรวดเร็วว่า Devin ทดสอบอะไรและแอปมีลักษณะอย่างไรตลอดทาง
หากคุณต้องการตรวจสอบที่ลึกซึ้งยิ่งขึ้น Devin ยังสร้างวิดีโอทดสอบพร้อม UI ผู้เล่นที่หลากหลายซึ่งมีบทเพื่อให้คุณสามารถกระโดดระหว่างส่วนการทดสอบ กรอไปมาระหว่างการรันทั้งหมด และตรวจสอบการยืนยันที่ผ่านหรือไม่ผ่านในมุมมองรายการตามลำดับเวลา ในการประมวลผลภายหลัง เวลาที่ตายระหว่างการดำเนินการจะถูกบีบอัด ในขณะที่ช่วงเวลารอบ ๆ การดำเนินการจะเล่นด้วยความเร็วปกติ สิ่งนี้ทำให้การรันที่ยาวนานถูกย่อให้เป็นบันทึกที่คุณสามารถดูได้จริง สิ่งประดิษฐ์เหล่านี้มีอยู่ในอินเทอร์เฟซเว็บของเราและยังถูกแจกจ่ายไปยัง Slack ถ้า Devin เริ่มจากที่นั่น
จุดที่ยังเป็นปัญหา
การใช้งานคอมพิวเตอร์ยังคงมีจุดที่เป็นปัญหา ตัวอย่างหนึ่งคือเวลา - ถ้า Devin กำลังทดสอบการแจ้งเตือนแบบ toast ภาพหน้าจอที่ถ่ายเร็วเกินไปหรือช้าเกินไปอาจพลาด toast ทั้งหมด และโมเดลอาจสับสนว่าพฤติกรรมที่คาดหวังเกิดขึ้นจริงหรือไม่
โหมดความล้มเหลวอีกอย่างคือการโกง เมื่อปล่อยให้อยู่กับอุปกรณ์ของตัวเอง โมเดลบางครั้งอาจพึ่งพาการรัน JavaScript ในเบราว์เซอร์เพื่อกระตุ้นสถานะโดยทางโปรแกรมมากเกินไป แทนที่จะคลิกผ่าน UI สิ่งนี้มีประโยชน์ในการทดสอบฟังก์ชันการทำงาน แต่ผู้ใช้มักจะต้องการเห็น Devin ใช้งานแอปในแบบที่ผู้ใช้จริงจะทำ
เรากำลังดำเนินการอย่างแข็งขันในปัญหาเหล่านี้ผ่านการประเมินผลที่ดีขึ้น การ์ดเรลที่แน่นหนาในชุดควบคุม และโมเดลรุ่นใหม่แต่ละรุ่นที่เก่งขึ้นในการใช้งานคอมพิวเตอร์
อนาคตของการพัฒนาแบบอะซิงโครนัสคือการตรวจสอบ
ในสองสามเดือนที่ผ่านมา จำนวนการทดสอบที่ได้รับการอนุมัติต่อวันบน Devin เพิ่มขึ้นมากกว่าสองเท่า การเติบโตนั้นสะท้อนถึงบางสิ่งที่เรียบง่าย: เอเจนต์แบบอะซิงโครนัสจะมีประโยชน์ก็ต่อเมื่อนักพัฒนาสามารถไว้วางใจสิ่งที่พวกเขากลับมาพร้อมกับ บ่อยครั้งที่ความไว้วางใจนั้นไม่สามารถมาจากโค้ดเพียงอย่างเดียว: สำหรับการเปลี่ยนแปลงหลายอย่าง คุณต้องการรู้ว่าแอปถูกเรียกใช้จริง ๆ โฟลว์ที่สำคัญถูกใช้งาน และผลลัพธ์ถูกบันทึกในแบบที่คุณสามารถตรวจสอบได้ง่าย
นั่นคือสิ่งที่การทดสอบอัตโนมัติใน Devin ถูกออกแบบมาเพื่อให้ Devin วางแผนการทดสอบ ดำเนินการแอป บันทึกและอธิบายสิ่งที่เกิดขึ้น และสุดท้ายส่งคืนสิ่งประดิษฐ์ที่ทำให้ผลลัพธ์สามารถตรวจสอบได้ ยังมีอีกมากที่ต้องปรับปรุง แต่เราคิดว่านี่คือรูปร่างที่ถูกต้องของอนาคต: เอเจนต์ที่ไม่เพียงแค่ทำงานให้เสร็จแบบอะซิงโครนัส แต่กลับมาพร้อมกับหลักฐาน
เราประหลาดใจอยู่เสมอว่า Devin ช่วยเราประหยัดเวลาได้มากเพียงใดโดยการทดสอบงานของตัวเอง และรู้สึกว่าลูกค้าจำนวนมากยังคงใช้ฟีเจอร์การทดสอบอัตโนมัติของ Devin น้อยเกินไป เพื่อสนับสนุนการทดลอง เรากำลังคิดค่าใช้จ่ายในอัตรา 1/5 ของต้นทุนการใช้งานปกติในขณะที่อยู่ในโหมดทดสอบ
ลองทำงานของเราที่ devin.ai หรือ windsurf.com และถ้าการทำงานเกี่ยวกับปัญหาแบบนี้ฟังดูสนุก ติดต่อมาได้ที่ ido [at] cognition.ai
