บทสนทนาส่วนใหญ่เกี่ยวกับการพัฒนาซอฟต์แวร์อัตโนมัติเริ่มต้นด้วยเอเจนต์ที่เขียนโค้ด เอเจนต์รับอ issue, implement ฟีเจอร์, เปิด pull request ระบบสาธิตทำงานได้ ผู้คนรู้สึกตื่นเต้น
ก่อนที่การส่งมอบอัตโนมัติใดๆ จะทำงานได้อย่างน่าเชื่อถือ ต้องมีคนออกแบบระบบวิศวกรรมที่ระบบอัตโนมัติจะทำงานอยู่ภายในก่อน โครงสร้างโปรเจกต์, การเลือกเทคโนโลยี, ขอบเขตทางสถาปัตยกรรม, ทิศทางการออกแบบ, ธรรมเนียมปฏิบัติทางวิศวกรรม, กลไกการตรวจสอบ, บทบาทเฉพาะทาง, ขอบเขตการอนุมัติ สิ่งเหล่านี้ไม่ควรเกิดขึ้นจากกลุ่มเอเจนต์อิสระที่คาดเดาแบบคู่ขนาน
แนวทางของฉันเริ่มต้นด้วยการแบ่งความรับผิดชอบที่แตกต่างกัน มนุษย์ออกแบบระบบวิศวกรรม เอเจนต์เฉพาะทางดำเนินการงาน ลูปแบบอะซิงโครนัสประสานงานว่างานนั้นจะเกิดขึ้นเมื่อใดและอะไรจะเกิดขึ้นต่อไป
เป้าหมายไม่ใช่การกำจัดมนุษย์ออกจากการพัฒนาซอฟต์แวร์ แต่เป็นการรวมการมีส่วนร่วมของมนุษย์ไว้ที่การตัดสินใจที่ต้องใช้ดุลยพินิจ, บริบท, และความเข้าใจในผลิตภัณฑ์ ขณะเดียวกันก็สร้างสภาพแวดล้อมที่การดำเนินการส่วนใหญ่สามารถดำเนินต่อไปได้ด้วยตัวเอง
นี่คือหกขั้นตอนที่ฉันทำทุกครั้งเมื่อเริ่มโปรเจกต์ที่ตั้งใจให้ทำงานได้ในที่สุดโดยไม่ต้องมีฉันคอยดู
ขั้นตอนที่ 1: มนุษย์ออกแบบระบบวิศวกรรม
เมื่อฉันเริ่มโปรเจกต์ ฉันไม่ได้ขอให้เอเจนต์อัตโนมัติคิดค้นรากฐานของมัน
ฉันตัดสินใจส่วนสำคัญก่อน: ควรจัดระเบียบ repository อย่างไร, ควรใช้เทคโนโลยีใด, ขอบเขตทางสถาปัตยกรรมหลักทำงานอย่างไร, ทิศทางการออกแบบคืออะไร, ต้องปฏิบัติตามธรรมเนียมปฏิบัติทางวิศวกรรมใดบ้าง, และระบบอัตโนมัติควรหยุดที่จุดใด การตัดสินใจเหล่านี้กลายเป็นรากฐานของทุกสิ่งที่จะตามมา
จากนั้นฉันใช้ opencode-onboard เพื่อเข้ารหัสการตัดสินใจเหล่านี้ลงใน repository
/make-engineer สร้างวิศวกร AI เฉพาะทางที่โปรเจกต์ต้องการ Frontend, Backend, Infrastructure, Testing, Security, Data, Mobile, อะไรก็ตามที่ผลิตภัณฑ์ต้องการ สิ่งเหล่านี้ไม่ใช่เอเจนต์ทั่วไปที่มีป้ายชื่อต่างกัน แต่ละคนมีความเชี่ยวชาญเฉพาะทาง, ชุดความสามารถ, และตำแหน่งที่ชัดเจนภายในขั้นตอนการทำงานทางวิศวกรรม
/make-architecture บันทึกโครงสร้างทางเทคนิคและขอบเขตไว้ใน ARCHITECTURE.md /make-design บันทึกภาษาภาพ, การออกแบบโทเค็น, และรูปแบบคอมโพเนนต์ไว้ใน DESIGN.md /make-guardrails แปลงการตัดสินใจทั้งหมดนั้นเป็นกฎที่เป็นรูปธรรมที่เอเจนต์ทุกตัวต้องเคารพ ขอบเขตทางสถาปัตยกรรม, ธรรมเนียมการตั้งชื่อ, ความคาดหวังในการทดสอบ, รูปแบบโค้ด, ข้อจำกัดด้านความปลอดภัย, แนวปฏิบัติ Git สิ่งเหล่านี้หยุดเป็นความรู้ที่เก็บไว้เฉพาะกับนักพัฒนาดั้งเดิมและกลายเป็นส่วนหนึ่งของสภาพแวดล้อมการทำงาน
repository สุดท้ายมีมากกว่าเอกสาร มันมีองค์กรวิศวกรรมที่ถูกเข้ารหัสและแหล่งความจริงร่วมกันสำหรับเอเจนต์ทุกตัวที่จะทำงานภายในนั้น
มนุษย์กำหนดระบบก่อน จากนั้นการดำเนินการอัตโนมัติจึงจะมีประโยชน์
ขั้นตอนที่ 2: รากฐานแบบอินเทอร์แอคทีฟมาก่อนระบบอัตโนมัติ
เมื่อระบบวิศวกรรมถูกกำหนดแล้ว ฉันสร้างรากฐานโปรเจกต์เริ่มต้นแบบอินเทอร์แอคทีฟ
โดยปกติฉันใช้ /plan-quick และ /plan-apply ในขั้นตอนนี้ /plan-quick วิเคราะห์เป้าหมายที่เน้นและเปลี่ยนเป็นลำดับงานที่เป็นรูปธรรมและเป็นระเบียบ มันตั้งใจให้เบากว่าขั้นตอนการทำงานแบบสเปกที่สมบูรณ์ ฉันใช้มันเมื่องานชัดเจนและฉันต้องการดำเนินการอย่างรวดเร็วโดยไม่สูญเสียการมองเห็นหรือการควบคุม /plan-apply ดำเนินการงานเหล่านั้นและตรวจสอบผลลัพธ์
นี่คือวิธีที่ฉันสร้างโครงสร้างพื้นฐานเบื้องต้นของโปรเจกต์ โครงสร้าง repository, โครงกระดูกแอปพลิเคชัน, การตั้งค่าฐานข้อมูล, รากฐานการยืนยันตัวตน, ระบบการออกแบบ, โครงสร้างพื้นฐานการทดสอบ, การกำหนดค่า CI/CD, รากฐานการปรับใช้
ช่วงแรกของโปรเจกต์มีการตัดสินใจที่ส่งผลต่อทุกอย่างที่สร้างขึ้นในภายหลัง abstraction ที่อ่อนแอ, โครงสร้างโฟลเดอร์ที่ไม่สอดคล้องกัน, กลยุทธ์การทดสอบที่ไม่ชัดเจน สิ่งใดสิ่งหนึ่งสามารถถูกทำซ้ำได้หลายร้อยครั้งเมื่อเอเจนต์อัตโนมัติเริ่มทำงาน ฉันเคยเห็นมันเกิดขึ้น มันไม่สวยงาม
ด้วยเหตุนี้ เฟสนี้จึงรวดเร็วและได้รับความช่วยเหลือจาก AI แต่ยังอยู่ภายใต้การดูแล
จุดประสงค์ไม่ใช่เพื่อเพิ่มระบบอัตโนมัติให้มากที่สุดเท่าที่จะเป็นไปได้โดยเร็วที่สุด จุดประสงค์คือเพื่อทำให้โปรเจกต์มีเสถียรภาพ, เข้าใจได้, และคาดเดาได้เพียงพอที่ระบบอัตโนมัติจะทำงานภายในได้อย่างปลอดภัยในภายหลัง
ขั้นตอนที่ 3: การมีส่วนร่วมของมนุษย์กลายเป็นนโยบายของโปรเจกต์
หลังจากรากฐานพร้อมแล้ว ฉันตัดสินใจว่าระบบส่งมอบควรมีอิสระในการทำงานอัตโนมัติมากน้อยเพียงใด
นี่ไม่ใช่ทางเลือกแบบไบนารีระหว่างการพัฒนาแบบแมนนวลและระบบอัตโนมัติเต็มรูปแบบ การมีส่วนร่วมของมนุษย์สามารถเกิดขึ้นได้ในจุดต่างๆ ของวงจรชีวิต และการกำหนดค่าที่เหมาะสมขึ้นอยู่กับโปรเจกต์
โปรเจกต์ที่มีการควบคุมเต็มรูปแบบอาจต้องการให้มนุษย์ปรับแต่ง issue, อนุมัติแผนการดำเนินการ, ตรวจสอบ pull request, อนุมัติการ merge, และอนุมัติการปรับใช้
โปรเจกต์ที่มีระบบอัตโนมัติบางส่วนอาจให้ AI ปรับแต่งและดำเนินการ ในขณะที่มนุษย์ตอบคำถามที่ยังไม่ได้รับการแก้ไข, ตรวจสอบ pull request ที่สำคัญ, หรือควบคุมการ merge สุดท้าย
โปรเจกต์ที่มีระบบอัตโนมัติสูงอาจให้ระบบปรับแต่ง, ดำเนินการ, ตรวจสอบ, และ merge การเปลี่ยนแปลงโดยอัตโนมัติเมื่อ guardrails, การทดสอบ, และการตรวจสอบคุณภาพที่จำเป็นผ่าน
ผลิตภัณฑ์ใหม่ที่มีข้อกำหนดไม่แน่นอนต้องการการมีส่วนร่วมของมนุษย์มากกว่าเครื่องมือภายในที่成熟 ระบบที่มีการควบคุมต้องการช่องทางการอนุมัติที่ชัดเจนซึ่งอาจไม่จำเป็นสำหรับการทดลองขนาดเล็ก และโปรเจกต์เดียวกันสามารถมีระบบอัตโนมัติมากขึ้นเมื่อเวลาผ่านไปเมื่อสถาปัตยกรรม, การทดสอบ, และกลไกการส่งมอบเติบโตขึ้น
ประเด็นสำคัญคือระบบอัตโนมัติถูกกำหนดโดยเจตนา การปรับแต่ง issue, การแก้ไขคำถาม, การอนุมัติแผน, การตรวจสอบ pull request, การอนุมัติ merge, การอนุมัติปรับใช้ สิ่งเหล่านี้ไม่ใช่การรบกวนโดยบังเอิญ แต่เป็นช่องทางที่กำหนดค่าได้ในระบบวิศวกรรม
ทุกโปรเจกต์เลือกระดับระบบอัตโนมัติที่แตกต่างกัน และขอบเขตเหล่านั้นก็พัฒนาตามไปด้วย
ขั้นตอนที่ 4: แนวคิดกลายเป็นรายการ backlog ที่คงทน
คอนโซลแบบอินเทอร์แอคทีฟยังคงเป็นสถานที่ที่ฉันตรวจสอบแนวคิด
เมื่อแนวคิดไม่สมบูรณ์ ฉันใช้ /plan-explore นี่ไม่ใช่คำสั่งการดำเนินการ มันเป็นกระบวนการสำรวจร่วมกัน เอเจนต์ตรวจสอบ repository, แมปคอมโพเนนต์ที่เกี่ยวข้อง, ระบุรูปแบบที่มีอยู่, ท้าทายสมมติฐาน, ตรวจสอบ dependencies, พิจารณาความเสี่ยง, และช่วยกำหนดว่าควรสร้างอะไรจริงๆ
ปัญหาการพัฒนาหลายอย่างในตอนแรกดูเหมือนเป็นงานเขียนโค้ด แต่จริงๆ แล้วเป็นปัญหาความเข้าใจ การส่งแนวคิดที่ไม่ชัดเจนเข้าสู่ขั้นตอนการทำงานแบบอัตโนมัติโดยตรงมักจะทำให้เกิดการดำเนินการที่ไม่ชัดเจน การสำรวจทำให้แนวคิดมีโครงสร้างเพียงพอที่จะนำไปปฏิบัติได้โดยไม่ต้องผูกมัดกับวิธีแก้ไขก่อนเวลาอันควร
เมื่อทิศทางชัดเจนแล้ว ฉันใช้ /ops-backlog เพื่อสร้างรายการงานที่มีโครงสร้างใน GitHub, Azure DevOps, หรือ Jira รายการงานกลายเป็นจุดเชื่อมต่อที่คงทนระหว่างการคิดแบบอินเทอร์แอคทีฟและการดำเนินการแบบอะซิงโครนัส มันสามารถประกอบด้วยบริบท, ขอบเขต, เกณฑ์การยอมรับ, ความเสี่ยง, คำถามที่ยังไม่ได้รับการแก้ไข, และ dependencies ที่จำเป็นสำหรับขั้นตอนถัดไปของขั้นตอนการทำงาน
ณ จุดนี้ backlog ไม่ใช่แค่สถานที่เก็บงานอีกต่อไป มันกลายเป็นเลเยอร์การประสานงานร่วมระหว่างมนุษย์, เอเจนต์, และลูป
มนุษย์สร้างแนวคิด, ตอบคำถาม, และตัดสินใจ ลูปสังเกตสถานะ issue และเลือกรานที่เหมาะสม เอเจนต์รับงานที่เน้นพร้อมบริบทที่จำเป็นในการดำเนินการ
backlog เปลี่ยนการสนทนาแบบอินเทอร์แอคทีฟให้เป็นงานที่คงทนซึ่งดำเนินต่อไปหลังจากการสนทนานั้นสิ้นสุดลง
ขั้นตอนที่ 5: loop-task ประสานงานแบบอะซิงโครนัส
เมื่อโปรเจกต์, วิศวกร, guardrails, backlog, และนโยบายการอนุมัติพร้อมแล้ว ฉันกำหนดค่า loop-task ภายในเครื่องท้องถิ่นหรือ VM
loop-task รันลูปการประสานงานภายนอก ลูปเหล่านี้ตรวจสอบ backlog อย่างต่อเนื่อง, ระบุงานที่เหมาะสม, เรียกใช้ขั้นตอนการทำงานทางวิศวกรรมที่เหมาะสม, และอัปเดตสถานะของแต่ละ issue
ลูปการปรับแต่งสามารถเลือก issue ใหม่, ตรวจสอบ, ปรับปรุงสเปก, และเพิ่มคำถามเมื่อข้อมูลขาดหาย เมื่อต้องการการตัดสินใจของมนุษย์ issue จะย้ายไปยังสถานะรอ มีคนตอบเมื่อพร้อม และลูปจะดำเนินการต่อเมื่อข้อมูลปรากฏขึ้น
เมื่อ issue ชัดเจนเพียงพอแล้ว มันจะย้ายไปยังสถานะพร้อมดำเนินการ ลูปการดำเนินการจะรับมันและเรียกใช้ขั้นตอนการทำงานทางวิศวกรรมอัตโนมัติ
ลูปการตรวจสอบสามารถตรวจสอบ feedback ของ pull request, ประสานงานการแก้ไข, รันขั้นตอนการทำงานที่จำเป็นอีกครั้ง, และย้ายการเปลี่ยนแปลงกลับไปสู่การยอมรับ ลูปการทำให้เสร็จสมบูรณ์สามารถ merge งานที่ได้รับการยอมรับ, ปิด issue ที่เกี่ยวข้อง, และอนุญาตให้รายการถัดไปที่เหมาะสมเข้าสู่ระบบ
ลูปไม่จำเป็นต้องสื่อสารกันโดยตรง พวกมันประสานงานผ่านสถานะ backlog ที่คงทน issue ทั่วไปจะเคลื่อนผ่านวงจรชีวิตแบบนี้:
ใหม่, กำลังปรับแต่ง, รอคำตอบ, พร้อมดำเนินการ, กำลังดำเนินการ, Pull request, กำลังตรวจสอบ, เสร็จสิ้น
มนุษย์สามารถเข้าสู่กระบวนการได้ทุกเมื่อที่นโยบายโปรเจกต์ต้องการ แต่ระบบไม่พึ่งพาใครสักคนที่คอยดู terminal อย่างต่อเนื่อง แม้ในขณะที่นักพัฒนาออฟไลน์ VM ก็ยังคงตรวจสอบ backlog และเคลื่อนย้ายงานที่เหมาะสมไปข้างหน้า
นี่คือความแตกต่างที่อยู่ใจกลางของวิศวกรรมลูป:
เอเจนต์ดำเนินการงาน ลูปตัดสินใจว่างานมีอยู่เมื่อใด, ควรเริ่มเมื่อใด, ขั้นตอนการทำงานใดควรดำเนินการ, และอะไรจะเกิดขึ้นต่อไป
ขั้นตอนที่ 6: /plan-goal ดำเนินการหนึ่ง issue ตั้งแต่ต้นจนจบ
เมื่อลูปการดำเนินการพบ issue ที่พร้อมแล้ว มันจะเรียก /plan-goal
คำสั่งนี้ไม่รับผิดชอบในการตัดสินทิศทางผลิตภัณฑ์หรือคิดค้นสถาปัตยกรรมโปรเจกต์ การตัดสินใจเหล่านั้นได้ทำไปแล้วและถูกเข้ารหัสลงใน repository ความรับผิดชอบของมันคือการดำเนินการรายการงานที่ได้รับการปรับแต่งอย่างเพียงพอหนึ่งรายการภายในระบบวิศวกรรมที่มีอยู่
/plan-goal อ่าน issue, สำรวจส่วนที่เกี่ยวข้องของ codebase, สร้างข้อเสนอ OpenSpec, สร้างงานที่มีโครงสร้าง, ระบุช่องว่างของสเปกหรือการทดสอบ, เลือกวิศวกรเฉพาะทางที่เหมาะสม, กำหนดระดับโมเดล, คำนวณ dependencies, และจัดระเบียบงานดำเนินการเป็นคลื่นการดำเนินการแบบคู่ขนาน
งานที่เป็นอิสระและแก้ไขส่วนต่างๆ ของ repository สามารถกำหนดให้กับวิศวกรที่แตกต่างกันพร้อมกันได้ งานที่ขึ้นอยู่กับงานก่อนหน้าหรือแตะไฟล์เดียวกันจะถูกดำเนินการตามลำดับที่ต้องการ
เอเจนต์นำประสานงาน, รวบรวมผลลัพธ์แต่ละรายการ, สร้าง commits ที่เน้น, รันการทดสอบ, linting, type checks, และ build มันจะหยุดมากกว่าที่จะส่งการเปลี่ยนแปลงเมื่อการตรวจสอบไม่สามารถเสร็จสมบูรณ์ได้สำเร็จ
เมื่อการดำเนินการถูกต้อง branch จะถูก push และ pull request จะถูกสร้างขึ้นพร้อมบริบทและหลักฐานที่จำเป็น
นโยบายโปรเจกต์ที่กำหนดค่าไว้จะกำหนดว่าเกิดอะไรขึ้นต่อไป มนุษย์อาจตรวจสอบ pull request ระบบ AI อื่นอาจทำการตรวจสอบ โปรเจกต์ที่มีระบบอัตโนมัติสูงอาจ merge โดยอัตโนมัติเมื่อการตรวจสอบที่จำเป็นทุกอย่างผ่าน ในโปรเจกต์อื่นๆ การตัดสินใจขั้นสุดท้ายยังคงเป็นของมนุษย์อย่างชัดเจน
สิ่งนี้เผยให้เห็นเลเยอร์การประสานงานสองชั้นในระบบ loop-task คือเลเยอร์การประสานงานภายนอก มันจัดการวงจรชีวิตของ backlog และตัดสินใจว่าเมื่อใดควรเกิดการปรับแต่ง, การดำเนินการ, การตรวจสอบ, หรือการทำให้เสร็จสมบูรณ์ /plan-goal และคำสั่ง opencode-onboard อื่นๆ สร้างขั้นตอนการทำงานทางวิศวกรรมภายใน พวกมันเข้าใจวิธีการสำรวจ, วางแผน, กำหนด, ดำเนินการ, ตรวจสอบ, และส่งมอบการเปลี่ยนแปลงเฉพาะหนึ่งรายการ
ระบบที่อยู่รอดจากการสนทนา
หนึ่งในข้อจำกัดของการพัฒนาที่ใช้ prompt คือสถานะมากเกินไปอาศัยอยู่ในการสนทนาชั่วคราว
สถาปัตยกรรมต้องถูกอธิบายอีกครั้ง การตัดสินใจก่อนหน้านี้ถูกลืม การดำเนินการที่ถูกขัดจังหวะยากที่จะกลับมาดำเนินการต่อ นักพัฒนาต้องอยู่เพื่อตัดสินใจว่าเอเจนต์ควรทำอะไรหลังจากทุกขั้นตอน
ขั้นตอนการทำงานนี้ย้ายสถานะนั้นไปยังระบบที่คงทน repository ประกอบด้วยสถาปัตยกรรม, กฎการออกแบบ, วิศวกร, และ guardrails OpenSpec ประกอบด้วยการเปลี่ยนแปลงที่วางแผนไว้และงานของมัน Git ประกอบด้วยประวัติการดำเนินการและจุดกู้คืน Backlog ประกอบด้วยสถานะการส่งมอบและการตัดสินใจของมนุษย์ เครื่องท้องถิ่นหรือ VM ให้สภาพแวดล้อมที่คงอยู่ซึ่งลูปยังคงทำงานต่อไป
ผลลัพธ์ไม่ใช่เอเจนต์อัตโนมัติตัวเดียวที่พยายามทำตัวเหมือนองค์กรซอฟต์แวร์ทั้งหมด มันเป็นระบบที่ประสานงานกันซึ่งคอมโพเนนต์ต่างๆ มีความรับผิดชอบที่แตกต่างกัน
มนุษย์กำหนดทิศทาง, ข้อจำกัด, และขอบเขตความรับผิดชอบ เอเจนต์เฉพาะทางดำเนินการงานทางวิศวกรรมที่เน้น ลูปประสานงานวงจรชีวิตแบบอะซิงโครนัส Backlog เชื่อมต่อพวกมันเข้าด้วยกัน
การเปลี่ยนแปลงที่สำคัญที่สุดไม่ใช่การที่เอเจนต์สามารถสร้างโค้ดได้มากขึ้น การเปลี่ยนแปลงที่ใหญ่กว่าคือการเปลี่ยนจากการโต้ตอบ AI แบบแยกส่วนไปสู่ระบบวิศวกรรมที่คงทน
แทนที่จะอธิบาย repository ก่อนทุกงาน โปรเจกต์จะมีสถาปัตยกรรมและ guardrails ของตัวเอง แทนที่จะขอให้เอเจนต์ทั่วไป implement ทุกอย่าง งานจะถูกกำหนดให้กับผู้เชี่ยวชาญ แทนที่จะตัดสินใจด้วยตนเองว่าควรเกิดอะไรขึ้นหลังจากทุกขั้นตอน ลูปจะตอบสนองต่อสถานะขั้นตอนการทำงานที่คงทน แทนที่จะเก็บกระบวนการทั้งหมดไว้ในการสนทนา ความคืบหน้าจะยังคงอยู่ใน issue, สเปก, commits, pull requests, และสถานะท้องถิ่น
บทบาทของมนุษย์ไม่ได้หายไป มันเปลี่ยนไปสู่การออกแบบสภาพแวดล้อมที่อนุญาตให้ดำเนินการอัตโนมัติทำงาน
นั่นคือโมเดลที่ฉันกำลังสร้างอยู่ในขณะนี้: AI SDLC ที่ออกแบบโดยมนุษย์ โดยนักพัฒนาจะสร้างสภาพแวดล้อมทางวิศวกรรมและขอบเขตของระบบอัตโนมัติก่อน จากนั้นลูปแบบอะซิงโครนัสจะประสานงานเอเจนต์เฉพาะทางผ่านวงจรชีวิตการส่งมอบที่ขับเคลื่อนด้วย backlog
จากศูนย์ไปจนถึงลูปที่ทำงานด้วยตัวเอง หกขั้นตอน แต่ละขั้นตอนสร้างจากขั้นตอนก่อนหน้า แต่ละขั้นตอนย้ายสถานะออกจากการสนทนาไปยังระบบที่ไม่ลืมอีกเล็กน้อย
PS: คุณสามารถหา loop-task, opencode-onboard และเครื่องมืออื่นๆ เหล่านี้ได้ที่ ckgrafico.com
