โรงงานซอฟต์แวร์คือวงจรที่ทำซ้ำได้เกี่ยวกับงานซอฟต์แวร์ หากคุณกำลังสร้างโรงงานซอฟต์แวร์ โค้ดที่ "ดีพอที่จะปล่อย" ก็ยังคงต้องใช้รสนิยมและความเป็นเจ้าของของมนุษย์ เราจะพูดถึงเรื่องนี้ รวมถึงว่าคุณ จำเป็น ต้องมีโรงงานหรือไม่
ถ้าจำเป็น:
- คุณอาจต้องให้มนุษย์อยู่ในวงจรตั้งแต่แรกเพื่อตัดสินใจเกี่ยวกับเจตนาของผลิตภัณฑ์ การออกแบบระบบ (ถ้าคุณใส่ใจ) และเกณฑ์คุณภาพของคุณ
- ควรตรวจสอบโค้ด (โรงงานแบบไฟเขียว) แต่จงตั้งใจในจุดที่จำเป็นที่สุด ผมพบว่าคุณต้องระวังจุดที่แรงดันย้อนกลับอัตโนมัติพัง หรือจุดที่ต้องมีการตัดสินใจแลกเปลี่ยนในเรื่องการบำรุงรักษา
- ตั้งเป้าให้การตรวจสอบคุณภาพเกิดขึ้นโดยเร็วและต่อเนื่องที่สุด ไม่ใช่ทั้งหมดที่ต้องทำ แต่รวมถึงระบบชนิดข้อมูล (type systems), การทดสอบอัตโนมัติ, การทดสอบแบบมิวเทชัน (mutation testing), สแกนเนอร์ความปลอดภัย และการ lint สำหรับกฎสถาปัตยกรรม
- จำนวนการตรวจสอบ != คุณภาพ คุณอาจต้องทดลองว่าการตรวจสอบแบบใดให้อัตราส่วนสัญญาณต่อสัญญาณรบกวนที่ดีที่สุด จงพร้อมที่จะปรับข้อจำกัดให้เข้มงวดขึ้นหรือผ่อนคลายลงอย่างตั้งใจ
คุณต้องการสร้างโรงงานของคุณเพื่อให้แง่มุมของรสนิยมมนุษย์บางส่วนถูกเข้ารหัสไว้ในสภาพแวดล้อม เอเจนต์ให้หลักฐานแก่คุณว่างานของมันถูกต้อง และมนุษย์ยังคง "เป็นเจ้าของ" สิ่งที่ถูกส่งไปยังระบบผลิต
คุณจำเป็นต้องมีโรงงานซอฟต์แวร์จริงหรือ?
จากประสบการณ์ของผม คุณสามารถไปได้ไกลอย่างน่าประหลาดใจด้วยชุดเครื่องมือเขียนโค้ดมาตรฐานของคุณ! เช่น Claude Code หรือ Codex, หลายเซสชัน, สเปกที่ดีพร้อมการตรวจสอบในตัว และข้อจำกัด คุณยังสามารถโยนชุด GitHub Issues ไปให้พวกเขาพร้อมเกณฑ์การนำไปปฏิบัติและการมีส่วนร่วมของมนุษย์ Claude Code routines และ Copilot/Codex cloud agents ก็มีลูปตามกำหนดการหรือตามเหตุการณ์อยู่แล้วโดยไม่ต้องมีโครงสร้างพื้นฐานแบบกำหนดเอง
โรงงานจะมีค่าก็ต่อเมื่อคุณต้องการ การรันที่สม่ำเสมอและทำซ้ำได้, การส่งมอบงานระหว่างเอเจนต์, การหยุดสองเซสชันไม่ให้รับงานเดียวกัน, การเก็บหลักฐาน และการหยุดการผลิตเมื่อการตรวจสอบตามหลัง
ผมเริ่มต้นด้วยการบอกว่า โรงงานซอฟต์แวร์คือวงจรที่ทำซ้ำได้เกี่ยวกับงานซอฟต์แวร์ เราสามารถดูพรอมต์ที่สาธิตวงจรโรงงานขนาดเล็กมากได้ที่นี่:
อ่าน GitHub issue #123 และคำแนะนำของ repository ก่อนที่จะเปลี่ยนแปลงโค้ด
ใช้เฉพาะเกณฑ์การยอมรับที่ระบุไว้เท่านั้น ห้ามแก้ไขการตรวจสอบสิทธิ์ การเรียกเก็บเงิน การย้ายข้อมูล หรือ assertions การทดสอบที่มีอยู่ ทำงานใน branch และทำให้ diff ตรวจสอบได้
รัน npm run lint, npm test, และ npm run build หากการตรวจสอบที่จำเป็นไม่สามารถรันได้ ให้หยุดและอธิบายว่าเพราะเหตุใด เปิด draft pull request พร้อมการตรวจสอบที่คุณรัน ความเสี่ยงที่เหลืออยู่ และการตัดสินใจใดๆ ที่มนุษย์ยังคงต้องทำ ห้าม merge
เป้าหมายสามารถทำให้สิ่งนี้ดำเนินต่อไปได้จนกว่าการตรวจสอบจะผ่าน และเราสามารถ poll GitHub issues สำหรับ label เฉพาะใดๆ หรือตรวจสอบ open pull requests ทุกเช้า Branch protection สามารถบังคับใช้ขอบเขตการ merge และมนุษย์สามารถอยู่ในวงจรได้โดยการเลือกสิ่งที่พร้อม ตรวจสอบ และทำการตัดสินใจ merge ขั้นสุดท้าย เป็นต้น
เพิ่มโรงงานซอฟต์แวร์เมื่อคุณต้องการคิวงานที่ขับเคลื่อนด้วยเหตุการณ์ (เช่น Slack triggers, GitHub issues, Linear, backlog) เพื่อรันในสภาพแวดล้อมคลาวด์ที่แยกออกมา เพื่อจัดการกับการคัดแยก (triage) การนำไปปฏิบัติ และการทดสอบ โดยมีการดูแลของมนุษย์อย่างชัดเจน บางส่วนจบวงจรด้วยเอเจนต์ตรวจสอบที่คอยดูระบบผลิตและสร้าง issues ซึ่งจะถูกคัดแยกอีกครั้ง
จากประสบการณ์ของผม โรงงานจะมีประโยชน์เมื่อส่วนที่ยากคือการทำให้การรันที่แตกต่างกันของคุณทำงานอย่างสม่ำเสมอ การส่งมอบงานระหว่างเอเจนต์ และการหลีกเลี่ยงไม่ให้เซสชันต่างๆ อ้างสิทธิ์ใน issue เดียวกัน การเก็บรักษาหลักฐาน และการหยุดการผลิตเมื่อการตรวจสอบของมนุษย์ตามหลัง
สิ่งที่แก้ปัญหานี้อาจฟังดูน่าเบื่อหน่อย ตัวอย่างเช่น Warp กล่าวถึง การคัดแยก ทุก issue ที่เข้ามาเป็นหนึ่งในสี่สถานะ - พร้อมนำไปปฏิบัติ, พร้อมทำสเปก, ต้องการข้อมูล, รอการนำไปปฏิบัติ - และ label คือสิ่งที่เรียกใช้เอเจนต์ถัดไป
label นี้ทำงานหลายอย่างในครั้งเดียว: มันคือคิว มันคือตัวล็อค และเนื่องจากเซสชันจะหยิบเฉพาะสิ่งที่ทำเครื่องหมายว่าพร้อม มันจึงเป็นจุดที่มนุษย์สามารถจอดสิ่งต่างๆ ไว้ได้โดยไม่ต้องปฏิเสธอย่างถาวร
ในแง่ของเวิร์กโฟลว์ มีความคล้ายคลึงและความแตกต่างบางประการกับการใช้ Claude/Codex:
- การนำทาง (Steering): เอเจนต์ต้องการการแก้ไขเส้นทาง คุณสามารถให้ข้อมูลและเปลี่ยนเส้นทางได้
- การแจ้งเตือน (Notifications): วิธีที่โรงงานบอกว่ามันติดขัด อาจเป็นเพราะข้อกำหนดคลุมเครือ มันเริ่มทำสิ่งที่เสี่ยง หรือต้องการข้อมูลนำเข้าจากมนุษย์ (การนำทาง)
- การส่งมอบ (Handoff): ย้ายงาน สถานะ และบริบทระหว่างโรงงานคลาวด์/เอเจนต์อื่น/ผู้ตรวจสอบที่เป็นมนุษย์ การส่งมอบที่ดีจะติดตามสิ่งที่เกิดขึ้น สิ่งที่เหลือให้ทำ และเหตุผลที่จำเป็นต้องส่งมอบ
ในโรงงานที่ดี มนุษย์ไม่ได้ถูกจำกัดแค่การตรวจสอบและอนุมัติ diff สุดท้ายในตอนท้ายเท่านั้น พวกเขาสามารถกำหนดรูปแบบงานตั้งแต่เนิ่นๆ นำทางมันระหว่างการนำไปปฏิบัติ ส่งผ่านการส่งมอบ หรือหยุดไม่ให้มันถูกส่งไปยังระบบผลิต
การตรวจสอบคือสิ่งที่โรงงานที่มีความรับผิดชอบใช้เวลาส่วนใหญ่ไปกับมัน เราจะพูดถึงเรื่องนี้เพิ่มเติมในภายหลัง
หากคุณตัดสินใจว่าคุณจำเป็นต้องมีโรงงานซอฟต์แวร์ การสร้างมันไม่ใช่ทางเลือกเดียว การตั้งโครงสร้างพื้นฐานเพื่อขยายขนาดโรงงานอาจเป็นงานที่หนัก และคุณอาจต้องการพิจารณาซื้อเทียบกับสร้าง Factory.ai, Devin, Warp และ HumanLayer ต่างก็ขายบางส่วนของวงจรนี้
จุดที่ผมใช้ความสนใจจริงๆ
ประสบการณ์การพัฒนาซอฟต์แวร์ในแต่ละวันของผมเปลี่ยนไปอย่างมากในช่วงปีที่ผ่านมา ผมพูดถึงมากขึ้นเรื่อยๆ เกี่ยวกับการทำงานแบบคู่ขนานกับเอเจนต์ และการเคลื่อนไปสู่การมีโรงงานซอฟต์แวร์แบบไฟเขียว และหลายคนถามผมว่า สิ่งเหล่านี้หมายความว่าอะไรกันแน่? คุณกำลังสร้างอะไร? โปรเจกต์ประเภทไหนที่คุณใช้สิ่งเหล่านี้? ส่วนใหญ่เป็นแบบนี้:
ในวันปกติทั่วไป ผมมีโรงงานซอฟต์แวร์แบบไฟเขียวที่เรียบง่ายกว่า ผมสามารถมีงานที่รันอยู่ในคลาวด์ ครึ่งหนึ่งของงานเหล่านี้อาจทำงานบนแอปพลิเคชันไคลเอนต์ที่ใช้งานจริงกับบริษัทขนาดเล็กที่ผมทำงานด้วย พวกเขาจะมีผู้ใช้จริง พวกเขาจะมีการตรวจสอบสิทธิ์จริง การชำระเงิน การสมัครสมาชิก ความเสี่ยงที่ต้องระวังอย่างแท้จริง คุณไม่สามารถพูดว่า โอ้ เอเจนต์ ไปทำสิ่งนี้เถอะ โดยไม่มีการทดสอบ ข้อจำกัด และการตรวจสอบคุณภาพ
ผมสามารถทำงานในโปรเจกต์โอเพนซอร์สของผม ผมสามารถสร้างเว็บไซต์ประกอบหนังสือของผม ผมสามารถทำงานกับเครื่องมือต่างๆ ผมสามารถสร้างแอปของตัวเอง และสิ่งเหล่านี้ล้วนเป็นแอปพลิเคชันประเภทที่แตกต่างกันมากที่ผมกำลังทำอยู่ และบางครั้งสิ่งเดียวที่เหมือนกันคือเครื่องมือที่ผมใช้ทำงานกับมัน ใช่ไหม? บางทีผมอาจกำลังทำงานกับการย้ายข้อมูล (migration) บางครั้ง ผมอาจกำลังทำงานฟีเจอร์ที่หนักหน่วงจริงๆ และรัศมีการระเบิด (blast radius) ของงานก็อาจแตกต่างกันมากเช่นกัน
ดังนั้น เมื่อคุณเริ่มคิดถึงการไปถึงจุดที่เราทำงานคู่ขนานกันมากขึ้น เราพยายามเพิ่มความเร็ว เราพยายามเพิ่มผลผลิต และเราพยายามเพิ่มความเป็นอิสระ ซึ่งหมายถึงการทำให้ระบบไปถึงจุดที่เราเชื่อถือมันมากขึ้น คุณต้องคิดว่าจุดใดบ้างที่จำเป็นต้องมีการตรวจสอบโค้ดโดยมนุษย์ การป้อนข้อมูลโดยมนุษย์อย่างแท้จริง
และส่วนใหญ่จะต้องทำตั้งแต่แรก ใช่ไหม? เมื่อคุณกำลังกำหนดสเปก ความต้องการของคุณ การออกแบบผลิตภัณฑ์จะมีลักษณะอย่างไร? เจตนาของผลิตภัณฑ์จะเป็นอย่างไร? แล้วคุณจะตรวจสอบได้อย่างไรว่าเอเจนต์ทำงานได้ถูกต้อง? คุณจะตรวจสอบได้อย่างไรว่าพวกมันไม่ได้ทำลายระบบเดิมที่มีอยู่? คุณจะแน่ใจได้อย่างไรว่ามันตรงตามเกณฑ์คุณภาพของคุณ?
ดังนั้น การสร้างโค้ดจึงไม่จำเป็นต้องเป็นส่วนที่คุณต้องกังวลมากที่สุด เมื่อมีบริบทเพียงพอ เอเจนต์สามารถเขียนการนำไปใช้ รันการทดสอบ ตรวจสอบความล้มเหลว และแก้ไขโค้ดให้เราได้ เราต้องไปถึงจุดที่เรารู้สึกว่ามีรสนิยมของมนุษย์ถูกเข้ารหัสไว้ในสภาพแวดล้อมมากพอที่เราจะเชื่อถือสิ่งที่กำลังถูกสร้างขึ้น เพื่อที่ความสนใจของมนุษย์จะได้มุ่งเน้นไปยังจุดที่จำเป็นที่สุด
ตอนนี้ มีเสียงคัดค้านจากบางคนที่บอกว่า เฮ้ ฉันไม่เชื่อว่าคุณจะทำให้สิ่งเหล่านี้เป็นอัตโนมัติได้มากขนาดนั้น มันไม่ได้หมายความว่าเราจะทำให้ทุกอย่างเป็นอัตโนมัติ ใช่ไหม? แต่เมื่อพิจารณาจากปริมาณโค้ดที่ถูกสร้างขึ้น ฉันไม่คิดว่ามันจะเป็นจริงได้ที่มนุษย์จะอ่านมันทั้งหมด โดยเฉพาะอย่างยิ่งเมื่อเราไม่ได้สร้างจรวดบ่อยๆ ใช่ไหม? เรากำลังสร้าง UI เรากำลังสร้างแอปพลิเคชัน full stack
วิจารณญาณ รสนิยมของเราควรมุ่งเน้นไปยังจุดที่จำเป็นที่สุด เช่น อะไรคือส่วนที่เสี่ยงที่สุดของระบบ? เราต้องใช้รสนิยมของมนุษย์ที่ไหน? ซึ่งอาจจะอยู่ที่ฟรอนต์เอนด์ อาจจะอยู่ที่ว่าระบบทำงานอย่างไร มันไม่จำเป็นต้องเป็น 100% ของทั้งหมด
แบนด์วิดท์การรับรู้ของผมไม่ได้ปรับขนาดตามเอเจนต์
ความจริงก็คือ ใช่ ตอนนี้เราสามารถเปิดใช้งานเอเจนต์หลายสิบ หลายร้อย หลายพันตัวแบบคู่ขนานได้ แต่แบนด์วิดท์การรับรู้ของคุณเองไม่ได้ปรับขนาดในลักษณะเดียวกัน สิ่งนี้สามารถนำไปสู่หนี้ด้านการรับรู้หรือความเข้าใจ (cognitive or comprehension debt) ซึ่งผมเคยพูดถึงมาก่อน
ถ้าคุณจำได้เมื่อห้าถึงสิบปีที่แล้ว มีการถกเถียงกันมากมายในชุมชนวิศวกรรมเกี่ยวกับการสลับบริบท (context switching) และต้นทุนของมัน เราจะพูดถึงว่าผู้คนเกลียดเมื่อเพื่อนร่วมงานหรือใครสักคนเดินมาที่โต๊ะของคุณตอนที่คุณกำลังจดจ่อกับงานอยู่ มันจะใช้เวลานานมากกว่าจะกลับเข้าสู่สภาวะ flow ได้ เพราะคุณต้องตามให้ทันว่า ฉันอยู่ตรงไหน? ฉันกำลังทำอะไรอยู่? ถึงแม้จะมีร่องรอยหลงเหลืออยู่บ้าง ก็ยังใช้เวลา
ตอนนี้เราสลับบริบทมากกว่าเดิมเสียอีก ในแต่ละวัน ถ้าผมทำงานนอกโรงงานซอฟต์แวร์ ผมสามารถทำงานในโปรเจกต์ต่างๆ ห้าถึงสิบโปรเจกต์กับเอเจนต์ในเวลาเดียวกัน หรือฟีเจอร์ต่างๆ ห้าถึงสิบฟีเจอร์ในโปรเจกต์เดียวในเวลาเดียวกัน ผมสามารถมีเซสชันต่างๆ ห้าถึงสิบเซสชันได้
นั่นหมายความว่าผมต้องสามารถติดตามอย่างน้อยสองสามอย่างได้ เป็นไปได้ที่ผมจะเพิ่มความเป็นอิสระให้กับงานบางอย่างได้ ถ้าผมเชื่อใจว่าผมได้กำหนดงานไว้ดีพอแล้ว ผมได้กำหนดผลลัพธ์ วิธีการตรวจสอบว่างานเสร็จสมบูรณ์ดีพอแล้ว แต่แล้วก็จะมีงานที่บางทีผมอาจไม่รู้สึกแบบนั้นและมีความเสี่ยงหรือความละเอียดอ่อนมากกว่า ผมจะต้องให้ความสนใจ
ลองพิจารณาปรับแต่งโรงงานซอฟต์แวร์สำหรับผู้ตรวจสอบของคุณ เนื่องจากทุกแนวทางเหล่านั้นยังคงส่งผลลัพธ์ไปยังความสนใจของคนคนเดียว คุณควรถามว่าการตัดสินใจที่คุณยังต้องทำนั้นถูกลงแค่ไหนด้วยโรงงาน
ความผิดพลาดแบบผิดโปรเจกต์
ผมจำได้ว่าตอนที่ผมทำงานหลายโปรเจกต์คู่ขนานกับเอเจนต์ของผม และมีบางครั้งที่ผมทำผิดพลาดโดยไม่ได้ตั้งใจ เช่น บางทีผมกำลังทำงานบนเว็บแอปที่ต้องการเพิ่มโหมดมืด และผมก็คิดในหัวว่า โอเค นี่คือรูปแบบที่มันควรจะเป็น แต่ผมบังเอิญไปที่เซสชันของอีกโปรเจกต์หนึ่ง และเริ่มใส่พรอมต์เดียวกันนั้น
ดังนั้นผมจึงเริ่มใช้โหมดมืดกับบางสิ่งที่ไม่ได้ต้องการมันเลย และผมก็ทำผิดพลาดแบบนั้นได้ ผมไม่ต้องการให้โรงงานซอฟต์แวร์ของผมทำผิดพลาดแบบนั้น
คุณต้องคิดถึงเรื่องนี้ในแง่ของระบบจริงๆ คุณกำลังพยายามเข้ารหัสวัฒนธรรมวิศวกรรมซอฟต์แวร์ วัฒนธรรมทีม ลงในระบบ เพื่อให้มันมีพฤติกรรมแบบเดียวกัน เพื่อให้มีความเป็นเจ้าของที่อยู่ที่ไหนสักแห่ง เพื่อให้ยังมีคนที่รับผิดชอบต่อสิ่งที่เกิดขึ้น และคุณกำลังระบุอย่างชัดเจนว่าคุณคิดเกี่ยวกับสิ่งเหล่านั้นอย่างไร
เมื่อสีเขียวทำให้เข้าใจผิด
แม้แต่ในระบบเหล่านี้ คุณต้องระวังให้มาก ใช่ไหม? พวกเราหลายคนเคยเห็นว่าเมื่อคุณขอให้ AI ช่วยคุณผ่านการทดสอบ เช่น การทดสอบการเขียนโปรแกรม การทดสอบหน่วย (unit test) มันสามารถเปลี่ยนการทดสอบหน่วยเพื่อให้เป็นไปตามเงื่อนไขนั้น หรือมันสามารถเปลี่ยนตรรกะของโค้ดเพื่อให้ผ่านเงื่อนไขนั้น นั่นไม่ได้หมายความว่ามันทำตามเจตนาของคุณจริงๆ เพื่อให้สอดคล้องทั้งพฤติกรรมการทำงานและสิ่งที่การทดสอบควรจะทดสอบ ใช่ไหม?
เพียงเพราะโรงงานซอฟต์แวร์แสดงว่าทุกอย่างเป็นสีเขียว ไม่ได้หมายความว่ามันเป็นสีเขียวจริงๆ โดยเฉพาะอย่างยิ่งในช่วงเริ่มต้นที่คุณกำลังตั้งค่าสิ่งเหล่านี้ คุณต้องใส่ใจอย่างมากเพื่อให้แน่ใจว่าการตรวจสอบ การยืนยันของคุณ ทั้งหมดนั้นถูกกำหนดรูปแบบอย่างถูกต้อง พวกมันกำลังทำสิ่งที่คุณคาดหวังให้มันทำ คุณไม่ต้องการให้มันทำให้เข้าใจผิด
คุณไม่ต้องการสถานการณ์ที่คุณมีการทดสอบที่บอกว่า เฮ้ จริงๆ แล้ว ฉันได้ไปเปลี่ยนว่ามีการรองรับผู้ให้บริการตรวจสอบสิทธิ์ใดบ้าง คุณขอให้ฉันเพิ่ม GitHub เป็นตัวอย่าง ในฐานะผู้ให้บริการตรวจสอบสิทธิ์ แต่เฮ้ UI ของฉันมีที่ว่างแค่สามที่ ดังนั้นฉันก็ไปและลบอันอื่นทิ้ง และเฮ้ ยังไงก็ตาม อันนั้นกลายเป็นอันที่ลูกค้าของคุณต้องการจริงๆ ดังนั้นคุณแค่ต้องระบุอย่างชัดเจนว่าคุณต้องการให้ระบบเหล่านี้ทำงานอย่างไร
อีกอย่าง ความปลอดภัยก็สำคัญมากเช่นกัน และถ้าโรงงานของคุณอ่านข้อมูลนำเข้าที่ไม่น่าเชื่อถือ เช่น GitHub issue/Slack message มันอาจเป็นปฏิปักษ์และรวมถึงปัญหาเช่นการโจมตีห่วงโซ่อุปทาน (supply chain attacks) ผลิตภัณฑ์บางอย่างเกี่ยวกับโรงงานซอฟต์แวร์ เช่น Vercel Sandbox/AI ADK Factory รันเอเจนต์ของพวกเขาใน sandbox ที่แยกออกมาซึ่งเก็บเฉพาะความลับที่งานต้องการ วิธีนี้ทำให้การรันที่ถูกบุกรุกไม่สามารถเข้าถึงสิ่งที่งานไม่ต้องการ การป้องกันของคุณจะเป็นการป้องกันแบบหลายชั้น
โปรเจกต์เก่าๆ โปรเจกต์ไหนสมควรมีชีวิตอีกครั้ง?
ผมยังคิดว่าส่วนสำคัญของวิธีการทำงานของเราในทุกวันนี้คือการตัดสินใจว่าอะไรควรมีอยู่ ถ้าคุณจำได้เมื่อหลายปีก่อนก่อนยุค AI มีโปรเจกต์วิศวกรรมซอฟต์แวร์ที่ถูกทิ้งร้างมากมาย โปรเจกต์วันหยุดสุดสัปดาห์ที่ถูกทิ้ง โปรเจกต์ส่วนตัวที่พวกเขาจะไม่เปิดตัวเพราะเราไม่มีเวลาทำให้เสร็จ เราไม่มีแบนด์วิดท์ที่จะจัดลำดับความสำคัญในการทำให้มันออกมาเพราะมันไม่สำคัญสำหรับเราหรือเราหาเวลาไม่ได้
ตอนนี้มันค่อนข้างง่ายสำหรับเราที่จะทำโปรเจกต์เหล่านั้นให้เสร็จ แต่คำถามเรื่องวิจารณญาณของมนุษย์ก็กลับมา โปรเจกต์เหล่านั้นสมควรมีอยู่หรือไม่? ควรเปิดตัวหรือไม่? เพราะเมื่อคุณปล่อยมันออกสู่โลก และถึงแม้มันจะมีผู้ใช้แค่ห้าคน บางทีคุณอาจต้องดูแลรักษามัน บางทีตอนนี้คุณมีเกณฑ์คุณภาพที่ต้องการรักษาไว้
ผมรู้ว่าผมมีโปรเจกต์ GitHub มากมายตลอดหลายปีที่ผ่านมา ซึ่งตอนนี้ผมมีเอเจนต์ สิ่งแรกที่ผมทำคือทำให้มัน build ได้ เพราะแน่นอน คุณ clone มัน และตอนนี้มัน build ไม่ได้เพราะ dependency ทั้งหมดเปลี่ยนไป ครึ่งหนึ่งล้าสมัยหรือมีช่องโหว่ด้านความปลอดภัยเต็มไปหมด คุณจึงต้องอัปเดตมัน
จากนั้นคุณต้องเพิ่มการทดสอบถ้าคุณไม่มีการทดสอบ เพื่อให้คุณรู้ว่าพฤติกรรมนั้นจะยังคงอยู่ถ้าคุณกำลังอัปเกรดโปรเจกต์ หรือถ้าคุณกำลังย้ายไปยังภาษา เฟรมเวิร์ก หรือสิ่งที่ทันสมัยกว่า
จากนั้นคุณเริ่มถามตัวเองว่า เอาล่ะ ตัวอย่างงี่เง่า แต่บางทีฉันเคยใช้ Twitter Bootstrap สมัยก่อนสำหรับสิ่งนี้ แต่ตอนนี้ทุกคนใช้ Tailwind และ shadcn ดังนั้นฉันต้อง implement UI ใหม่ และสิ่งที่คุณจะสังเกตคือ จู่ๆ สิ่งนี้ก็ใช้เวลาคุณมากขึ้น ใช่ไหม? ใช่ เอเจนต์สามารถทำสิ่งนี้ได้เร็วขึ้นมาก แต่ตอนนี้คุณต้องคำนึงถึงความรู้สึกด้านผลิตภัณฑ์ (product sense) และรสนิยม และสิ่งเหล่านี้ทั้งหมด
คุณยังคงตั้งคำถามว่า เอาล่ะ สิ่งนี้มีไว้เพื่อใคร? มันมีตลาดหรือไม่? มันมีไว้สำหรับฉันเอง? หรือเพื่อคนอื่น? ถ้าฉันปล่อยมันออกสู่โลก มันจะยังน่าสนใจอยู่หรือไม่ เมื่อตอนนี้ใครๆ ก็สามารถสร้างสิ่งเหล่านี้ได้อย่างรวดเร็ว?
ดังนั้นผมคิดว่าคำถามของมนุษย์ที่ว่าสิ่งเหล่านี้สมควรมีอยู่หรือไม่? เราจะรวมรสนิยมและวิจารณญาณของเราเข้าไปได้อย่างไร? ผมรู้สึกว่าสิ่งเหล่านั้นยังคงมีความสำคัญอย่างยิ่ง นั่นคือจุดที่ทรัพยากรอัน scarce อย่างความสนใจของมนุษย์ยังคงเข้ามามีบทบาทจริงๆ สมัยก่อน เรามีเวลาในแต่ละวันจำกัด เรามีการประชุม เราต้องจัดสรรเวลาสำหรับการออกแบบและการเขียนโค้ด และอื่นๆ
ตอนนี้เรามีเอเจนต์ช่วยเรา ผมคิดว่าคุณต้องระบุให้ชัดเจนจริงๆ ว่าคุณใช้เวลาที่ไหนและทำไม
สิ่งที่เกิดขึ้นเมื่อผมสร้างตัวอย่างหนึ่งขึ้นมา
ผมจะพูดถึงการรันโรงงาน 82 นาที ผู้คนถามผมมานานแล้วว่า "ฉันจะสร้างโรงงานซอฟต์แวร์ได้อย่างไร?" หรือ "ฉันคุ้นเคยกับการใช้ Claude Code หรือ Codex ฉันจะพัฒนาการตั้งค่าของฉันให้ใช้โรงงานซอฟต์แวร์ได้อย่างไร?"
สิ่งแรกที่ผมพูดคือ "คุณอาจไม่เป็นไร งานของคุณอาจจะโอเคโดยไม่ต้องมีโรงงาน" แต่ผมอยากให้ผู้คนมีการตั้งค่าอ้างอิงที่พวกเขาสามารถลองดูได้ ดังนั้นสิ่งที่ผมรวบรวมคือ repository ที่ชื่อว่า Factory ที่คุณสามารถไปดูได้ ผมยังรวบรวม แอปพลิเคชันตัวอย่าง และ เวิร์กช็อป ไว้ด้วย
ในช่วงสองสามปีที่ผ่านมา แอปพลิเคชันตัวอย่างหลักของผมสำหรับหลายสิ่งคือแอปภาพยนตร์ ผมเป็นแฟนตัวยงของภาพยนตร์ ผมชอบดูหนัง ผมดูหนังตลอดเวลา ดังนั้นผมจึงมีแอปพลิเคชันตัวอย่าง ซึ่งเริ่มต้นจากแอปภาพยนตร์ที่เรียบง่ายมาก และสิ่งที่ผมต้องการให้โรงงานทำได้คือดำเนินการ implement ฟีเจอร์ต่างๆ มีฟีเจอร์ที่แตกต่างกันสองสามอย่าง ผมต้องการฟีเจอร์รายการโปรด ผมต้องการให้มันสามารถค้นหาได้ และบางทีก็ต้องการธีมมืดด้วย สิ่งเหล่านั้น
ดังนั้นผมจึงให้โรงงานของผมไปและเริ่มทำงานกับสิ่งเหล่านี้ คุณสามารถดูการ implement ได้ ข้อดีอย่างหนึ่งของมันคือการจับปัญหาจริงๆ ปัญหาเหล่านี้อาจไม่ใช่สิ่งที่ผมจะจับได้ถ้าผมแค่ขอให้มัน implement แบบครั้งเดียว
ประมาณนาทีที่ 60 ผมรู้สึกว่า "ว้าว นี่มันช้าผิดปกติ" ผมถาม harness ของผมโดยใช้โรงงานว่า "ทำไมถึงช้า?" มันตอบว่า "นี่เป็นเรื่องปกติจริงๆ ตัวตรวจสอบทั้งหมดยังคงทำงานอยู่"
คุณอาจคาดหวังว่างานแต่ละงานจะใช้เวลา 10 นาที 15 นาที 20 นาที แต่มันอาจใช้เวลานานกว่าสองถึงสี่เท่าเมื่อคุณเริ่มรวมการตรวจสอบ การลองใหม่ การตรวจสอบเบราว์เซอร์ การตรวจสอบโดยมนุษย์ หรือความล่าช้าพิเศษอื่นๆ
ผมคิดว่าสิ่งเหล่านี้สามารถนำไปสู่คุณภาพที่ดีขึ้นและความไว้วางใจในระบบที่ดีขึ้น จากมุมมองของการวัด คุณอาจดูเมตริกเช่นต้นทุนต่อ PR ที่ถูก merge และอายุของโค้ด (code shelf life) เป็นเมตริกหนี้ด้านความเข้าใจ (comprehension debt)
คุณต้องคิดด้วยว่าอะไรคือความล่าช้าที่มีประโยชน์เทียบกับค่าใช้จ่ายของโรงงาน ตัวตรวจสอบ ในกรณีของผม จับปัญหาจริงๆ ได้ เวลาส่วนหนึ่งอาจถูกใช้ไปกับการสร้างหลักฐานที่ผมต้องการ บางส่วนเป็นค่าใช้จ่ายในการรันโรงงาน ผมไม่ได้ใช้เวลาในการปรับแต่งมันเลย แต่โรงงานที่รันการตรวจสอบมากมายที่คุณไม่เห็นว่ามีค่าไม่ได้หมายความว่ามันมีคุณภาพสูง
คุณต้องการศึกษาว่า สำหรับการตรวจสอบซ้ำๆ ใดๆ มันไม่เกี่ยวข้องหรือไม่? มันมีสัญญาณรบกวนหรือไม่? มันทำให้ระบบปลอดภัยขึ้นจริงหรือไม่?
การตรวจสอบต้องมีงบประมาณ
วิธีที่ผมคิดเกี่ยวกับงบประมาณสำหรับการตรวจสอบ โดยพื้นฐานแล้วนี่คือสิ่งที่เรากำลังพูดถึง เรากำลังพูดถึงงบประมาณการตรวจสอบ (verification budget) ผมคิดถึงมันในแบบเดียวกับที่ผมเคยคิดเกี่ยวกับงบประมาณประสิทธิภาพ (performance budgets)
จะมีการตรวจสอบบางประเภทที่คุณสามารถรันได้ตั้งแต่เนิ่นๆ ในวงจรการพัฒนาซอฟต์แวร์ของคุณ และจะมีบางสิ่งที่หนักหน่วงมาก แต่ให้คุณค่ามากมาย ซึ่งคุณจะต้องการรันมันในภายหลัง มีการตรวจสอบที่รวดเร็วบางอย่าง เช่น การ lint, การตรวจสอบชนิดข้อมูล (type checking) สิ่งเหล่านี้เป็นการตรวจสอบที่ค่อนข้างเร็วที่คุณสามารถรันได้ตั้งแต่เนิ่นๆ
ชุดทดสอบเต็มรูปแบบของเราสามารถรันได้ใกล้เคียงกับก่อนที่จะมีการสร้าง draft PR หรือหลังจากนั้น ซึ่งอาจรวมถึงการทดสอบแบบมิวเทชัน การทดสอบเบราว์เซอร์ การตรวจสอบความปลอดภัย หรืออะไรก็ตาม
ผมคิดว่าคุณไม่จำเป็นต้องแทนที่สิ่งเหล่านี้ด้วยบทสรุป คุณต้องการการทดสอบจริง แต่คุณแค่ต้องแน่ใจว่าคุณจัดสรรงบประมาณให้มันในที่ที่ถูกต้อง เพราะคุณไม่ต้องการทำให้วงจรการพัฒนาของคุณช้าลง ผมไม่เคยต้องการทำให้วงจรการพัฒนาของผมช้าลง การมีวงจรการทำซ้ำที่รวดเร็วเป็นสิ่งสำคัญสำหรับผม แต่ผมก็ยังต้องการให้มีการตรวจสอบและถ่วงดุลเหล่านั้น
เมื่อการรันไม่ถูกส่งออก
ส่วนใหญ่ของสิ่งที่ผมเขียนข้างต้นเกี่ยวกับการตรวจสอบ
ในโรงงานซอฟต์แวร์ของพวกเขา Vercel ทำเครื่องหมาย ทุกการรันของเอเจนต์ว่า "สำเร็จ", "มีข้อบกพร่อง", "ถูกบล็อก" หรือ "ด้วยตนเอง" และมีเพียง "สำเร็จ" เท่านั้นที่ถูกส่งไปยังระบบผลิต ส่วนที่เหลือจะกลับเข้าสู่ระบบ ผมคิดเกี่ยวกับการรันในแง่ที่คล้ายกัน
"มีข้อบกพร่อง" ในที่นี้หมายถึงสิ่งที่ผิดถูก implement หรือบางทีมันไม่มีบริบทที่สมบูรณ์ ดังนั้นจึงต้องแก้ไข "ถูกบล็อก" หมายถึงสภาพแวดล้อมอาจขาดข้อมูลรับรอง (credential) ดังนั้นคุณต้องจัดหาให้ "ด้วยตนเอง" คือขอบเขตที่โรงงานอาจยังไม่ได้รับอนุญาตให้ข้ามผ่าน
สองในสามสิ่งนี้อาจมีการแก้ไขเชิงกลไก และสิ่งสุดท้ายเกี่ยวกับความไว้วางใจ
แม้ว่าสิ่งนี้จะดี แต่การจัดหมวดหมู่ไม่ได้แสดงต้นทุนให้คุณเห็น กลับไปที่การ implement โรงงานของผมกับแอป TMDB ตัวค้นหาด่วนที่ไม่มีการปฏิเสธใช้เวลา 7 นาที รายการโปรดที่มีการปฏิเสธสองครั้งและการตัดสินใจของมนุษย์อยู่ตรงกลาง ใช้เวลา 56 นาที โรงงานเดียวกัน ดังนั้นผมจะจับคู่การจัดหมวดหมู่กับระยะเวลาในแต่ละขั้น มิฉะนั้นคุณจะรู้ว่าการรันกลับมามีข้อบกพร่องโดยไม่รู้ว่าการค้นพบนั้นทำให้คุณเสียค่าใช้จ่ายเท่าไร อีกสิ่งที่ผมจะแก้ไขคือการส่งมอบที่ขอบเขต: โรงงานตัวอย่างของมหยุด issue แรกและย้ายไปที่ factory:needs-info ซึ่งถูกต้อง แต่ผมไม่รู้ว่าจะใส่คำตอบของผมไว้ที่ไหน การรันด้วยตนเองยังไม่เสร็จสิ้นเมื่อโรงงานหยุด แต่เมื่อมนุษย์รู้ว่าต้องทำอะไรต่อไป
ความเป็นอิสระไม่ใช่การตั้งค่าเดียว
ผมเขียนบทความเกี่ยวกับ ระดับความเป็นอิสระของเอเจนต์ (agentic autonomy) เมื่อสองสามสัปดาห์ก่อน และวิธีคิดเกี่ยวกับความเป็นอิสระ เพราะความเป็นอิสระจะไม่ใช่การตั้งค่าเดียวสำหรับทุกโปรเจกต์
การตรวจสอบทำให้คุณมีความไว้วางใจ และทำให้คุณสามารถให้ความเป็นอิสระแก่เอเจนต์ของคุณมากขึ้น ตัวอย่างเช่น ถ้าผมกำลังทำงานกับการเปลี่ยนแปลงที่ไม่สำคัญ แต่ผมมีการตรวจสอบหลายอย่าง ทุกอย่างได้รับการตรวจสอบอย่างถูกต้อง และบางทีผมอาจตรวจสอบด้วยตนเองแล้ว ครั้งต่อไปที่ผมจะทำงานแบบนั้นในโปรเจกต์เดียวกัน บางทีผมอาจรู้สึกสบายใจที่จะให้เอเจนต์มีความเป็นอิสระมากขึ้นอีกหน่อย
นั่นคือสิ่งที่คุณคิดถึงเมื่อคุณสร้างโรงงานซอฟต์แวร์เหล่านี้ การตรวจสอบของคุณจะเปลี่ยนไปตามความเสี่ยง เป้าหมายของคุณคืออัตราส่วนสัญญาณต่อสัญญาณรบกวนที่ดีที่สุด คุณไม่ต้องการแค่มีรายการตรวจสอบขนาดใหญ่ที่คุณรัน
ฟีเจอร์ที่ผมต้องเรียนรู้ใหม่
มีฟีเจอร์หนึ่งที่ผมเลื่อนออกไปในวันที่ผมใช้หลายเซสชันกับ Claude และผมกำลังทำงานในโปรเจกต์ต่างๆ สองสามโปรเจกต์ในเวลาเดียวกัน ฟีเจอร์ต่างๆ สองสามฟีเจอร์ต่อโปรเจกต์ ดังนั้น Claude ได้ implement ฟีเจอร์ที่ผมกำลังทำอยู่ ดูเหมือนว่าการทดสอบจะผ่าน ผมไม่ได้คิดมากเกี่ยวกับการตรวจสอบ แต่การทดสอบผ่าน ดังนั้นผมคิดว่ามันใช้ได้ ผม merge มัน
และนี่คือฟีเจอร์การเพิ่มรายการโปรด ผมคิดว่ามันค่อนข้างดี ผมพยายามตรวจสอบในเบราว์เซอร์ มันดูเหมือนว่าโอเค แต่สองสามวันต่อมา ผมกลับมาที่โค้ดเพราะมี tweaks บางอย่างที่ผมคิดว่าอาจจะทำกับมัน
ฉันไม่อยากแค่บอกให้เอเจนต์ของฉันแก้ไข เพราะมันเป็นเพียงวิธีที่ละเอียดอ่อนที่มันทำงาน คุณแตะที่ไอคอน แล้วมันจะไม่แสดงเอฟเฟกต์ที่ถูกต้องเมื่อแตะ ดังนั้นฉันจึงอยากปรับแต่งมันเล็กน้อย ฉันต้องการเข้าใจว่ามันทำงานอย่างไร เพื่อจะได้แนะนำเอเจนต์ของฉันได้อย่างถูกต้อง
ฉันกลับไปดูโค้ด และฉันไม่สามารถอธิบายให้คุณฟังได้ว่าฟีเจอร์นั้นทำงานอย่างไร ที่เก็บโค้ดนี้เป็นของฉัน ใช่ไหม? ฉันอนุมัติการเปลี่ยนแปลง ฉันเข้าใจว่าส่วนใหญ่ของมันทำงานอย่างไร ส่วนใหญ่ของ repo ทำงานอย่างไร แต่ความเข้าใจของฉันตามไม่ทันโค้ดทั้งหมดที่ถูกสะสมขึ้นมา
สิ่งที่ฉันไม่สามารถซึมซับได้คือฟีเจอร์ที่ถูกเพิ่มเข้ามานี้ทำงานอย่างไรจริงๆ UI ทำงานอย่างไร เอฟเฟกต์บนมันทำงานอย่างไร ฉันต้องทำฟีเจอร์นี้ใหม่และลงมือทำทีละขั้นตอนจริงๆ ว่า "สิ่งนี้ทำงานอย่างไร? ฉันจะเข้าใจมันได้อย่างไร?"
งานแบบขนานส่งผลต่อความเข้าใจอย่างไร
เมื่อคุณทำงานแบบขนาน มันจะขยายปัญหานี้โดยรวม และมันยิ่งขยายมากขึ้นเมื่อคุณทำในซอฟต์แวร์แฟคทอรี เมื่อคุณทำห้าหรือสิบเซสชัน พวกมันสร้างมากกว่าแค่ปัญหาปริมาณการตรวจทาน พวกมันสร้างแบบจำลองทางความคิดหลายแบบที่อาจจะเย็นชาลงไปในขณะที่คุณทำงานที่อื่น
ในอดีตเราเคยพูดถึงความท้าทายเกี่ยวกับการสลับบริบท และทันทีที่แชทถูกบีบอัด คุณจะปฏิเสธวิธีการบางอย่าง ลองทำสิ่งที่แตกต่าง จับคู่กับเอเจนต์ คุณจะจำทุกอย่างที่เกิดขึ้นในเซสชันของคุณได้ยาก
คุณสามารถเลื่อนขึ้นไปดู และเมื่อการบีบอัดเกิดขึ้น คุณจะไม่มีทุกอย่างอยู่ที่นั่น และคุณจะไม่สามารถเก็บมันทั้งหมดไว้ในหัวของคุณได้ โค้ดมักจะเก็บรักษาการตัดสินใจที่เกิดขึ้น แต่ไม่ใช่เหตุผลว่าทำไมถึงตัดสินใจนั้น
นี่คือสิ่งที่ฉันคิดว่าอาจเป็นบทเรียนที่มีประโยชน์สำหรับคุณ โดยที่มันสำคัญ ให้พิจารณาขอให้เอเจนต์ของคุณจัดเก็บข้อมูลเกี่ยวกับเส้นทางของมัน หรือบทเรียนที่น่าสนใจเกี่ยวกับวิธีการที่มันเข้าถึงปัญหา เพื่อที่คุณจะได้กลับไปดูมันในภายหลัง
สิ่งนี้อาจจะหรืออาจจะไม่ใช่สิ่งที่คุณตัดสินใจที่จะคอมมิตลงใน repo คุณสามารถเก็บไว้ในเครื่องถ้าคุณต้องการ คุณสามารถแชร์กับทีมถ้าคุณต้องการ แต่นั่นอาจเป็นสิ่งที่สามารถนำมาปรึกษาในภายหลังได้ แทนที่คุณจะพึ่งพามันอาจจะอยู่ในเซสชัน หรือคุณอาจจะจำมันได้ในภายหลัง
มันสร้างอะไรขึ้นมาจริงๆ?
@threepointone และ @bentlegen โพสต์ ความคิดเห็น เกี่ยวกับ ซอฟต์แวร์แฟคทอรีที่ฉันเห็นด้วยอย่างยิ่ง:
มันง่ายที่จะหลงใหลในกลไกของการทำ ปรับแต่งกลไกให้เหมาะสม และลืมว่ามันควรจะผลิตอะไรออกมา ถ้าแฟคทอรีของคุณส่วนใหญ่ผลิตแฟคทอรีที่ดีกว่า แสดงว่าคุณสร้างซอฟต์แวร์ที่ผลิตภัณฑ์ของมันคือตัวมันเอง
ฉันคิดว่าการลงทุนในลูปนั้นโอเคและมันทบต้น ความล้มเหลวเกิดขึ้นเมื่อลูปปิด เมื่อทุกอย่างที่แฟคทอรีผลิตถูกบริโภคโดยแฟคทอรี และไม่มีใครภายนอกจะสังเกตเห็นถ้าคุณปิดมัน การทดสอบที่ฉันจะใช้คือการดึง บางสิ่งภายนอกต้องเป็นผู้ขอการปรับปรุง ถ้าคุณบอกไม่ได้ว่าใครเป็นคนดึง แสดงว่าคุณกำลังขัดเงา
ความเป็นเจ้าของไม่ได้หายไป
มีหลักการที่กว้างกว่าอยู่ภายใต้ทั้งหมดนี้
เปอร์เซ็นต์ของโค้ดที่มนุษย์พิมพ์จริงอาจลดลงอย่างมาก ฉันไม่คิดว่าความเป็นเจ้าของของมนุษย์จำเป็นต้องลดลงตามไปด้วย
- ยังมีคนที่เลือกปัญหา
- ยังมีคนที่เลือกสถาปัตยกรรม
- ยังมีคนที่กำหนดมาตรฐานคุณภาพ
- มีคนตัดสินใจว่าสัญญาณการตรวจสอบใดที่ควรได้รับความไว้วางใจ
- มีคนตัดสินใจว่าเมื่อใดที่หลักฐานเพียงพอที่จะปล่อย
และเมื่อระบบที่เกิดขึ้นล้มเหลว "เอเจนต์เขียนมัน" ไม่ใช่ข้อแก้ตัว นี่คือเหตุผลที่ฉันไม่คิดว่าอนาคตของวิศวกรรมซอฟต์แวร์จะถูกอธิบายได้ดีที่สุดว่ามนุษย์ออกจากลูป แต่ การตัดสินใจของมนุษย์กำลังถูกย้ายตำแหน่ง
เราควรนำผู้คนออกจากส่วนต่างๆ ของลูปที่เครื่องจักรสามารถสร้างสัญญาณที่แข็งแกร่งกว่า เร็วกว่า และแน่นอนกว่า ในเวลาเดียวกัน เราควรกระจุกผู้คนไว้รอบๆ สถานที่ที่บริบท รสนิยม ความเสี่ยง และความเป็นเจ้าของในระยะยาวมีความสำคัญมากที่สุด
ซอฟต์แวร์แฟคทอรีที่ดีที่สุดจะไม่ถูกกำหนดโดยว่าพวกเขากำจัดการมีส่วนร่วมของมนุษย์ได้สมบูรณ์เพียงใด
พวกเขาจะถูกกำหนดโดยว่าพวกเขา วาง มันอย่างชาญฉลาดเพียงใด
ให้การตัดสินใจของมนุษย์อยู่ต้นน้ำในเรื่องเจตนา รูปร่างของระบบ และมาตรฐานคุณภาพ ตรวจสอบโค้ดที่แรงดันย้อนกลับอัตโนมัติอ่อนลงหรือผลที่ตามมาเป็นเรื่องส่วนตัว ดันสัญญาณที่แน่นอนทุกตัวให้เร็วและต่อเนื่องที่สุดเท่าที่เป็นไปได้เข้าไปในลูป ผ่อนคลายและกระชับข้อจำกัดอย่างจงใจเมื่อระบบได้รับหรือสูญเสียความไว้วางใจ
มนุษย์ยังคงต้องเป็นเจ้าของสิ่งที่โค้ดปล่อยออกมาในที่สุด โค้ดที่ดีพอที่จะปล่อยยังคงเริ่มต้นจากคนที่ใส่ใจว่ามันควรจะมีอยู่หรือไม่
