เราใช้ Codex สร้าง Sora สำหรับ Android ใน 28 วันได้อย่างไร

ตั้งแต่วันที่ 26 เมษายน 2569 เป็นต้นไป Sora ได้ยุติการให้บริการแล้ว

ในเดือนพฤศจิกายน เราได้เปิดตัวแอป Sora บน Android สู่ทั่วโลก ให้ทุกคนที่มีอุปกรณ์ Android สามารถเปลี่ยนคำสั่งสั้นๆ ให้กลายเป็นวิดีโอที่มีชีวิตชีวาได้ ในวันเปิดตัว แอปขึ้นสู่อันดับหนึ่งใน Play Store ผู้ใช้ Android สร้างวิดีโอมากกว่าหนึ่งล้านรายการใน 24 ชั่วโมงแรก

เบื้องหลังการเปิดตัวนี้มีเรื่องราว: แอป Android เวอร์ชันแรกของ Sora ถูกสร้างขึ้นใน 28 วัน ด้วยความช่วยเหลือจากเอเจนต์เดียวกันที่มีให้กับทีมหรือนักพัฒนาทุกคน: Codex

ตั้งแต่วันที่ 8 ตุลาคม ถึง 5 พฤศจิกายน 2568 ทีมวิศวกรขนาดเล็กที่ทำงานร่วมกับ Codex และใช้ token ประมาณ 5,000 ล้าน token ได้เปิดตัว Sora สำหรับ Android จากต้นแบบสู่การเปิดตัวทั่วโลก แม้จะมีขนาดใหญ่ แต่แอปนี้มีอัตราการไม่เกิดข้อผิดพลาดถึง 99.9% และมีสถาปัตยกรรมที่เราภูมิใจ หากคุณสงสัยว่าเราใช้โมเดลลับหรือไม่ เราใช้เวอร์ชันแรกของ GPT‑5.1‑Codex โมเดล – เวอร์ชันเดียวกับที่นักพัฒนาหรือ Business สามารถใช้งานได้ในวันนี้ผ่าน CLI ส่วนขยาย IDE หรือแอปเว็บ

เมื่อ Sora เปิดตัวบน iOS การใช้งานก็พุ่งสูงขึ้นอย่างรวดเร็ว ผู้คนเริ่มสร้างวิดีโอจำนวนมากทันที ในทางตรงกันข้าม บน Android เรามีเพียงต้นแบบภายในขนาดเล็กและจำนวนผู้ใช้ที่ลงทะเบียนล่วงหน้าบน Google Play ที่เพิ่มขึ้นเรื่อยๆ

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

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

ด้วยการทำงานในลักษณะนี้ เราได้จัดส่งเวอร์ชันภายในของ Sora สำหรับ Android ให้กับพนักงานภายใน 18 วัน และเปิดตัวสู่สาธารณะในอีก 10 วันต่อมา เรารักษามาตรฐานสูงในด้านการปฏิบัติทางวิศวกรรมของ Android ลงทุนในความสามารถในการบำรุงรักษา และถือว่าแอปมีมาตรฐานความน่าเชื่อถือเช่นเดียวกับที่เราคาดหวังจากโครงการที่เป็นทางการ (เราต่อไปใช้ Codex อย่างกว้างขวางในปัจจุบันเพื่อพัฒนาและนำคุณสมบัติใหม่ๆ มาสู่แอป)

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

จุดที่ Codex ต้องการคำแนะนำ

1. Codex ยังไม่เก่งในการคาดเดาสิ่งที่ไม่ได้บอกไว้ (เช่น รูปแบบสถาปัตยกรรมที่คุณชื่นชอบ กลยุทธ์ผลิตภัณฑ์ พฤติกรรมของผู้ใช้จริง และมาตรฐานหรือคีย์ลัดภายใน)
2. ในทำนองเดียวกัน Codex ไม่สามารถเห็นแอปทำงานจริงได้: ไม่สามารถเปิด Sora บนอุปกรณ์ สังเกตว่าการเลื่อนดูรู้สึกไม่ถูกต้อง หรือรับรู้ว่าการไหลของการทำงานนั้นสับสน มีเพียงทีมของเราเท่านั้นที่สามารถครอบคลุมงานที่เกี่ยวข้องกับประสบการณ์เหล่านี้ได้
3. แต่ละกรณีต้องการการเริ่มต้นใช้งาน การแบ่งปันบริบทที่มีเป้าหมายชัดเจน ข้อจำกัด และคำแนะนำเกี่ยวกับ "วิธีการที่เราทำสิ่งต่างๆ" เป็นสิ่งสำคัญในการทำให้ Codex ทำงานได้อย่างมีประสิทธิภาพ
4. ในทำนองเดียวกัน Codex ประสบปัญหาในการตัดสินใจเชิงสถาปัตยกรรมอย่างลึกซึ้ง: หากปล่อยให้ทำงานเอง อาจเพิ่มโมเดลมุมมองใหม่ในที่ที่เราต้องการขยายโมเดลที่มีอยู่ หรือผลักดันตรรกะเข้าสู่ชั้น UI ที่ควรอยู่ใน repository อย่างชัดเจน สัญชาตญาณของมันคือการทำให้บางสิ่งทำงานได้ โดยไม่ให้ความสำคัญกับความสะอาดในระยะยาว

เราได้พบว่ามีประโยชน์ในการให้ Codex สร้างและดูแลไฟล์ AGENT.md จำนวนมากในโค้ดเบส สิ่งนี้ทำให้ง่ายต่อการนำคำแนะนำและแนวทางปฏิบัติที่ดีที่สุดเดียวกันไปใช้ในทุกเซสชัน ตัวอย่างเช่น เพื่อให้มั่นใจว่า Codex เขียนโค้ดตามแนวทางการเขียนของเรา เราได้เพิ่มสิ่งต่อไปนี้ใน AGENTS.md ระดับบนสุด:

จุดที่ Codex มีความโดดเด่น

1. การอ่านและทำความเข้าใจฐานโค้ดขนาดใหญ่ได้อย่างรวดเร็ว: Codex รู้จักภาษาการเขียนโปรแกรมหลักเกือบทั้งหมด ซึ่งทำให้ง่ายต่อการใช้แนวคิดเดียวกันในหลายแพลตฟอร์มโดยไม่ต้องมีการนามธรรมที่ซับซ้อน
2. การทดสอบความครอบคลุม: Codex มีความกระตือรือร้นอย่างเป็นพิเศษในการเขียนการทดสอบหน่วยเพื่อครอบคลุมกรณีที่หลากหลาย ไม่ใช่ทุกการทดสอบจะลึกซึ้ง แต่การมีความครอบคลุมที่กว้างขวางช่วยป้องกันการถดถอยได้ 
3. การนำข้อเสนอแนะไปใช้: ในทำนองเดียวกัน Codex สามารถตอบสนองต่อข้อเสนอแนะได้ดี เมื่อ CI ล้มเหลว เราสามารถวางเอาต์พุตของบันทึกลงในคำสั่งและขอให้ Codex เสนอการแก้ไข
4. การประมวลผลแบบขนานขนาดใหญ่ที่สามารถทิ้งได้: ส่วนใหญ่จะไม่ถึงขีดจำกัดของจำนวนเซสชันที่สามารถรันได้พร้อมกัน มีความเป็นไปได้สูงที่จะทดสอบแนวคิดหลายอย่างพร้อมกันและมองว่าโค้ดเป็นสิ่งที่ทิ้งได้
5. การนำเสนอแนวคิดใหม่: ในการอภิปรายเกี่ยวกับการออกแบบ เราใช้ Codex เป็นเครื่องมือในการสร้างสรรค์เพื่อสำรวจจุดที่อาจเกิดความล้มเหลวและค้นพบวิธีใหม่ในการแก้ปัญหา ตัวอย่างเช่น ในขณะที่เรากำลังออกแบบการเพิ่มประสิทธิภาพหน่วยความจำของเครื่องเล่นวิดีโอ Codex ได้คัดกรอง SDK หลายตัวเพื่อเสนอแนวทางที่เราไม่มีเวลาวิเคราะห์ ข้อมูลเชิงลึกจากการวิจัยของ Codex มีคุณค่าอย่างยิ่งในการลดการใช้หน่วยความจำในแอปขั้นสุดท้าย
6. การทำงานที่มีผลกระทบสูงขึ้น: ในทางปฏิบัติ เราใช้เวลามากขึ้นในการตรวจสอบและกำกับดูแลโค้ดมากกว่าการเขียนด้วยตัวเอง อย่างไรก็ตาม Codex มีความสามารถในการตรวจสอบโค้ดที่ยอดเยี่ยม มักจะจับข้อบกพร่องได้ก่อนที่จะผสาน ซึ่งช่วยเพิ่มความน่าเชื่อถือ

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

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

จากพื้นฐานนี้ เราได้พัฒนาฟีเจอร์ตัวแทนบางอย่างแบบครบวงจร เราใช้กฎที่เราต้องการให้โค้ดทั้งหมดปฏิบัติตาม และบันทึกรูปแบบของโครงการในขณะที่เราดำเนินการ เมื่อชี้นำ Codex ไปยังคุณสมบัติที่เป็นตัวแทน Codex สามารถทำงานได้อย่างอิสระมากขึ้นตามมาตรฐานของเรา สำหรับโครงการที่เราประเมินว่า 85% เขียนโดย Codex การวางรากฐานอย่างรอบคอบช่วยหลีกเลี่ยงการย้อนกลับและการปรับโครงสร้างที่มีค่าใช้จ่ายสูง มันเป็นหนึ่งในการตัดสินใจที่สำคัญที่สุดที่เราได้ทำ 

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

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

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

ขั้นตอนต่อไปในการปลดล็อกศักยภาพของ Codex ให้ได้มากที่สุด คือการหาวิธีให้ Codex ทำงานได้นานโดยไม่ต้องมีคนคอยดูแล (ซึ่งล่าสุดทำได้ นานกว่า 24 ชั่วโมง⁠)

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

ดังนั้นเราจึงเปลี่ยนกระบวนการทำงาน สำหรับการเปลี่ยนแปลงที่ไม่ใช่เรื่องเล็กน้อย เราได้ขอให้ Codex ช่วยให้เราเข้าใจวิธีการทำงานของระบบและโค้ดก่อน ตัวอย่างเช่น เราอาจขอให้มันอ่านชุดไฟล์ที่เกี่ยวข้องและสรุปว่าฟีเจอร์นั้นทำงานอย่างไร เช่น วิธีการที่ข้อมูลไหลจาก API ผ่านชั้นที่เก็บข้อมูล โมเดลมุมมอง และเข้าสู่ UI จากนั้นเราจะทำการแก้ไขหรือปรับปรุงความเข้าใจของมัน (ตัวอย่างเช่น เราจะชี้ให้เห็นว่าการนามธรรมบางอย่างควรอยู่ในชั้นที่ต่างออกไป หรือว่าคลาสที่กำหนดมีไว้สำหรับโหมดออฟไลน์เคุณั้นและไม่ควรขยายเพิ่มเติม)

เช่นเดียวกับการที่คุณอาจจะมีปฏิสัมพันธ์กับเพื่อนร่วมทีมใหม่ที่มีความสามารถสูง เราได้ทำงานร่วมกับ Codex เพื่อสร้างบริการที่มั่นคง บริการนั้นมักจะดูเหมือนเอกสารการออกแบบขนาดเล็กที่กำหนดว่าไฟล์ใดควรเปลี่ยนแปลง สถานะใหม่ใดควรถูกนำเสนอ และตรรกะควรดำเนินไปอย่างไร จากนั้นเราจึงขอให้ Codex เริ่มดำเนินการตามบริการทีละขั้นตอน เคล็ดลับที่มีประโยชน์: สำหรับงานที่ยาวมาก ซึ่งเราถึงขีดจำกัดของหน้าต่างบริบท เราจะขอให้ Codex บันทึกบริการของมันลงในไฟล์ เพื่อให้เราสามารถใช้ทิศทางเดียวกันในหลายกรณี

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

บรรยากาศคล้ายกับวิธีที่เอกสารการออกแบบที่ดีสร้างความมั่นใจให้กับหัวหน้าฝ่ายเทคโนโลยีในโครงการ เราไม่ได้เพียงแค่สร้างโค้ด แต่เรากำลังผลิตโค้ดที่สนับสนุนแผนงานร่วมกัน

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

เซสชันแต่ละรอบจะรายงานความคืบหน้าให้เราทราบเป็นระยะๆ บางคนอาจจะพูดว่า “ฉันวางแผนโมดูลนี้เสร็จแล้ว นี่คือสิ่งที่ฉันเสนอ” ในขณะที่อีกคนหนึ่งอาจจะเสนอการเปลี่ยนแปลงครั้งใหญ่สำหรับฟีเจอร์ใหม่ แต่ละรายการต้องการความสนใจ ข้อเสนอแนะ และการตรวจสอบ มันคล้ายกับการเป็นหัวหน้าฝ่ายเทคโนโลยีที่มีวิศวกรใหม่หลายคน ทุกคนกำลังมีความก้าวหน้า และทุกคนต้องการคำแนะนำ

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

ในขณะเดียวกัน ความเร็วที่เพิ่มขึ้นนั้นหมายความว่าเรามีสิ่งที่รออยู่ในคิวการตรวจสอบเสมอ Codex ไม่ได้ถูกขัดขวางจากการสลับบริบท แต่พวกเรากลับถูกขัดขวาง คอขวดในการพัฒนาของเราเปลี่ยนจากการเขียนโค้ดไปเป็นการตัดสินใจ การให้ข้อเสนอแนะ และการผนวกการเปลี่ยนแปลง

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

เราเริ่มต้นโครงการของเราด้วยก้าวสำคัญ: Sora ได้เปิดตัวบน iOS แล้ว เรามักจะชี้ให้ Codex ดูที่ฐานรหัส iOS และแบ็กเอนด์เพื่อช่วยให้เข้าใจข้อกำหนดและข้อจำกัดที่สำคัญ ตลอดโครงการนี้ เราล้อกันว่าเราได้คิดค้นแนวคิดของเฟรมเวิร์กข้ามแพลตฟอร์มขึ้นมาใหม่ ลืม React Native หรือ Flutter ไปได้เลย อนาคตของการพัฒนาข้ามแพลตฟอร์มคือ Codex เคุณั้น

ภายใต้คำพูดล้อเล่นมีหลักการสองข้อ

1. ตรรกะสามารถพกพาได้ ไม่ว่าจะเขียนโค้ดด้วย Swift หรือ Kotlin ตรรกะของแอปพลิเคชันพื้นฐาน – โมเดลข้อมูล การเรียกเครือข่าย กฎการตรวจสอบ ตรรกะ Business – ยังคงเหมือนเดิม Codex มีความสามารถในการอ่านการใช้งาน Swift ได้ดีมาก และสร้างโค้ดที่เทียบเท่าใน Kotlin โดยรักษาความหมายเดิมไว้
2. ตัวอย่างที่เป็นรูปธรรมให้บริบทที่มีพลัง เซสชัน Codex ใหม่ที่สามารถเห็นว่า "นี่คือวิธีการทำงานบน iOS" และ "นี่คือสถาปัตยกรรมของ Android" มีประสิทธิภาพมากกว่าการทำงานจากคำอธิบายภาษาธรรมชาติเคุณั้น

ด้วยการนำหลักการเหล่านี้ไปใช้ เราได้ทำให้ iOS, backend และ Android repos ใช้งานได้ในสภาพแวดล้อมเดียวกัน เราให้คำสั่ง Codex เช่นว่า:

“อ่านโมเดลและปลายทางเหล่านี้ในโค้ด iOS แล้วเสนอบริการเพื่อดำเนินการพฤติกรรมที่เทียบเท่าบน Android โดยใช้ client และคลาสโมเดล API ที่มีอยู่ของเรา”

เคล็ดลับเล็กๆ แต่มีประโยชน์คือการระบุรายละเอียดใน ~/.codex/AGENTS.md ว่า repo ท้องถิ่นอยู่ที่ไหนและมีอะไรบ้าง สิ่งนี้ทำให้ Codex ค้นหาและนำทางโค้ดที่เกี่ยวข้องได้ง่ายขึ้น

เราได้ทำการพัฒนาข้ามแพลตฟอร์มอย่างมีประสิทธิภาพผ่านการแปลแทนที่จะใช้การสรุปร่วมกัน เนื่องจาก Codex จัดการการแปลส่วนใหญ่ เราจึงหลีกเลี่ยงการเพิ่มขึ้นของค่าใช้จ่ายในการดำเนินการ

บทเรียนที่กว้างขึ้นคือสำหรับ Codex บริบทคือทุกสิ่ง Codex ทำงานได้ดีที่สุดเมื่อเข้าใจวิธีการทำงานของฟีเจอร์ใน iOS ควบคู่กับความเข้าใจโครงสร้างของแอป Android ของเรา เมื่อ Codex ขาดบริบทนั้น มันไม่ได้ "ปฏิเสธที่จะร่วมมือ" แต่กำลังคาดเดา ยิ่งเราปฏิบัติต่อมันเหมือนเป็นเพื่อนร่วมทีมใหม่ และลงทุนในการให้อินพุตที่ถูกต้องมากเท่าไหร่ มันก็ยิ่งทำงานได้ดีขึ้นเคุณั้น

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

มันชัดเจนว่าการพัฒนาที่มี AI ช่วยเหลือไม่ได้ลดความจำเป็นในการทำงานอย่างละเอียดรอบคอบ แต่กลับเพิ่มความจำเป็นนั้น แม้ว่า Codex จะมีความสามารถมาก แต่เป้าหมายของมันคือการไปจากจุด A ไปยังจุด B ทันที นี่คือเหตุผลว่าทำไมการเขียนโค้ดที่มี AI ช่วยไม่สามารถทำงานได้หากไม่มีมนุษย์ วิศวกรซอฟต์แวร์สามารถเข้าใจและประยุกต์ใช้ข้อจำกัดในโลกแห่งความเป็นจริงของระบบ วิธีที่ดีที่สุดในการออกแบบซอฟต์แวร์ และวิธีการสร้างโดยคำนึงถึงการพัฒนาในอนาคตและบริการผลิตภัณฑ์ พลังพิเศษของวิศวกรซอฟต์แวร์ในอนาคตจะเป็นความเข้าใจระบบอย่างลึกซึ้งและความสามารถในการทำงานร่วมกับ AI ในระยะยาว 

ส่วนที่น่าสนใจที่สุดของวิศวกรรมซอฟต์แวร์คือการสร้างผลิตภัณฑ์ที่น่าดึงดูด การออกแบบระบบที่ขยายได้ การเขียนอัลกอริทึมที่ซับซ้อน และการทดลองกับข้อมูล รูปแบบ และโค้ด อย่างไรก็ตาม ความเป็นจริงของวิศวกรรมซอฟต์แวร์ในอดีตและปัจจุบันมักจะมีลักษณะที่ธรรมดา: การจัดตำแหน่งปุ่มให้ตรงกลาง การเชื่อมต่อปลายทาง และการเขียนโค้ดที่เป็นแบบแผน ตอนนี้ Codex ทำให้เราสามารถมุ่งเน้นไปที่ส่วนที่มีความหมายที่สุดของวิศวกรรมซอฟต์แวร์และให้เหตุผลที่เรารักในงานฝีมือของเรา

เมื่อ Codex ถูกตั้งค่าในสภาพแวดล้อมที่มีบริบทที่สมบูรณ์ซึ่งเข้าใจเป้าหมายของคุณและวิธีที่คุณชอบสร้างทีมใดๆ ก็สามารถเพิ่มขีดความสามารถได้ การทบทวนการเปิดตัวของเราไม่ใช่สูตรสำเร็จที่ใช้ได้กับทุกสถานการณ์ และเราไม่ได้อ้างว่าได้แก้ปัญหาการพัฒนาที่ใช้ AI ช่วย แต่เราหวังว่าประสบการณ์ของเราจะทำให้การค้นหาวิธีที่ดีที่สุดในการเสริมศักยภาพให้ Codex เพื่อเสริมศักยภาพให้คุณเป็นเรื่องง่ายขึ้น 

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

คุณจะสร้างอะไรกับทีมของคุณเอง