แนะนำวงจรชีวิต Citizen Developer SDLC ของ Tenex วงจรชีวิตหกขั้นตอนที่เปลี่ยนสิ่งที่พนักงานที่ไม่ใช่สายเทคนิคสร้างด้วย AI จากการทดลองใช้ส่วนตัว ไปเป็นระบบที่ใช้งานจริงที่ทั้งบริษัทวางใจได้
โดย Alex Lieberman (@businessbarista), Arman Hezarkhani (@ArmanHezarkhani, Suchi Patel และ Ashwin Kadaru (@AshwinKadaru
กรอบความคิดจาก Tenex.co
สรุปย่อ
Citizen SDLC คือวงจรชีวิตหกขั้นตอน (แนวคิด, หน้าแรก, การคัดกรอง, การจัดเตรียม, การสร้าง, การใช้งานและการเปลี่ยนแปลง) ที่เปลี่ยนซอฟต์แวร์ที่สร้างโดยพนักงานที่ไม่ใช่สายเทคนิคด้วย AI จากการทดลองใช้ส่วนตัว ไปเป็นระบบที่ใช้งานจริงภายใต้การกำกับดูแล หลักการหนึ่งเดียวที่แทรกซึมอยู่ในทุกขั้นตอน: AI ทำงานหนัก, โค้ดที่กำหนดตายตัวเป็นตัวกำหนดขอบเขต, และมนุษย์จัดการกับข้อยกเว้น สิ่งนี้เกิดขึ้นเพราะ AI ทำให้ต้นทุนในการเขียนโค้ดลดลงจนเกือบเป็นศูนย์ และย้ายคอขวดไปยังขั้นตอนถัดไป นั่นคือการทำให้แน่ใจว่าสิ่งที่ถูกสร้างขึ้นนั้นมีคุณภาพ และการรักษาฝูงบินของแอปพลิเคชันที่กำลังเติบโตนี้ให้อยู่ภายใต้การกำกับดูแลเมื่อมันเปิดใช้งานแล้ว
ลูกค้ารายหนึ่งของเราคือบริษัทการลงทุน สมาชิกในทีมปฏิบัติการพอร์ตโฟลิโอของพวกเขา ซึ่งเป็นคนที่ไม่เคยเขียนโค้ดแม้แต่บรรทัดเดียว ได้สร้างแดชบอร์ดที่ทั้งทีมของเธอใช้ทุกวัน มันติดตามงานสร้างมูลค่าในบริษัทในพอร์ตหลายสิบแห่ง เธอสร้างมันขึ้นมาโดยใช้ Claude พร้อมปรับปรุงซ้ำประมาณสองเดือน ทุกบรรทัดถูกเขียนโดย AI
และมันก็ดี มุมมองถูกต้อง เวิร์กโฟลว์เข้ากับวิธีที่ทีมทำงานจริง การนำไปใช้เกิดขึ้นทันที เธอร่างผลิตภัณฑ์ที่ถูกต้องก่อนที่วิศวกรคนใดจะเข้ามาเกี่ยวข้อง
นั่นไม่ใช่โชค เป็นเวลาหลายสิบปีที่คนที่เข้าใจปัญหาทางธุรกิจมักจะไม่ใช่คนที่สามารถสร้างซอฟต์แวร์เพื่อแก้ไขมันได้ การปิดช่องว่างนั้นเป็นความพยายามที่ยิ่งใหญ่: ผู้จัดการผลิตภัณฑ์เพื่อเปลี่ยนปัญหาของเธอเป็นสเปก, วิศวกรเพื่อแปลสเปกเป็นโค้ด, และคิวรออยู่ข้างหลังสิ่งอื่นๆ ทั้งหมดในโรดแมป หลายเดือนผ่านไประหว่างแนวคิดและเครื่องมือ และสิ่งที่ส่งมอบในที่สุดก็คือการตีความของคนอื่นว่าเธอหมายถึงอะไร
ช่องว่างนั้นเพิ่งจะพังทลายลง อำนาจในการสร้างได้ย้ายไปยังคนที่เข้าใจกระบวนการจริงๆ รู้ว่าข้อมูลหมายถึงอะไร และใช้ชีวิตอยู่ในเวิร์กโฟลว์ทุกวัน เธอสร้างสิ่งที่ถูกต้องตั้งแต่ครั้งแรกเพราะเธอคือแหล่งที่มา ไม่มีใครมายืนเป็นตัวกลางเพื่อแปลสิ่งที่เธอพูด หรือทำให้มันผิดเพี้ยนไปเล็กน้อย นั่นคือคำมั่นสัญญาของการพัฒนาโดยพลเมือง (citizen development) และเธอก็ทำได้สำเร็จ
จากนั้นเราก็ดูภายใต้ฝากระโปรง
แอปพลิเคชันทั้งหมดเป็นไฟล์ HTML ไฟล์เดียว ขนาด 540 KB ประมาณ 5,300 บรรทัด ชุดข้อมูลหลักอาศัยอยู่ภายในนั้นเป็นก้อนข้อมูลขนาด 80 KB ในบรรทัดเดียว เมื่อไฟล์ต้องการการอัปเดต AI ก็ได้ต่อฟังก์ชันแพตช์ที่เขียนค่าทุกครั้งที่โหลดแอป การบันทึกงานหมายความว่าแอปเขียน HTML ของตัวเองใหม่ ดาวน์โหลดตัวเองไปยังแล็ปท็อปของคุณ และคุณอัปโหลดอีกครั้งไปยังไดรฟ์ที่ใช้ร่วมกันเป็นเวอร์ชันใหม่ หากสองคนแก้ไขพร้อมกัน คนที่บันทึกทีหลังจะเป็นผู้ชนะ และการแก้ไขของอีกคนจะหายไป
วันหนึ่ง ฟังก์ชันบันทึกไปค้นหาเครื่องหมายในไฟล์ ไม่พบ และเขียนกลับไปในสิ่งที่มันมีอยู่ anyway ไฟล์แอปพลิเคชันขนาด 540 KB ทั้งหมดถูกตัดทอนเหลือ 7 ไบต์ ในการเขียนแบบเงียบๆ เพียงครั้งเดียว แดชบอร์ดที่ทีมของเธอใช้ทุกวันก็หยุดดำรงอยู่ และไม่มีอะไรในวิธีการสร้างที่ถูกออกแบบมาเพื่อจับมัน หยุดมัน หรือนำมันกลับคืนมา
ผู้นำส่วนใหญ่เมื่อได้ยินเรื่องนี้ก็สรุปว่าการพัฒนาโดยพลเมืองเป็นความรับผิดชอบที่ต้องหยุดยั้ง เราคิดว่านั่นเป็นบทเรียนที่ผิด และบริษัทที่ทำตามนั้นจะเสียเปรียบ บทเรียนที่ถูกต้อง: เธอทำงานของเธอได้อย่างยอดเยี่ยม ไม่มีใครสร้างถนนสำหรับซอฟต์แวร์ที่จะส่งมอบได้
คอขวดได้ย้ายที่แล้ว
เป็นเวลาหลายสิบปีที่การสร้างซอฟต์แวร์เป็นส่วนที่แพงที่สุด มันช้า ขาดแคลน และมีต้นทุนสูง และวงจรชีวิตการพัฒนาซอฟต์แวร์ทั้งหมดก็เติบโตขึ้นมาเพื่อปกป้องมัน สเปก, ติ๊กเก็ต, สปรินต์, การตรวจสอบโค้ด: พิธีการทุกอย่างใน SDLC แบบดั้งเดิมมีอยู่เพราะการเขียนโค้ดคือคอขวด
AI ทำให้ขั้นตอนนั้นลดลงจนเกือบเป็นศูนย์ และคอขวดได้ย้ายที่แล้ว เมื่อใครก็ตามสามารถสร้างแอปที่ใช้งานได้ภายในบ่ายวันเดียว งานที่แพงก็ไม่ใช่การสร้างอีกต่อไป มันคือสิ่งที่เกิดขึ้นหลังจากนั้น: การทำให้แน่ใจว่าสิ่งที่ถูกสร้างขึ้นนั้นมีคุณภาพและปลอดภัย และการรักษาฝูงบินของแอปพลิเคชันที่กำลังเติบโตนี้ให้อยู่ภายใต้การกำกับดูแลเมื่อมันเปิดใช้งานแล้ว
GIF
และการสร้างก็ไม่ได้ชะลอตัวลง ทำให้เกิดปัญหาสองข้อที่ต้องแก้ไข:
ประการแรก คุณภาพภายใต้ฝากระโปรง เอเจนต์ที่ถูกพรอมต์จากหน้าว่างโดยผู้ที่ไม่ใช่วิศวกร จะมาบรรจบกันที่ซอฟต์แวร์ที่แก้ไขเฉพาะหน้า ซึ่งใช้งานได้วันนี้และไม่สามารถบำรุงรักษาได้ตลอดไป ไฟล์ 540 KB ไม่ใช่สิ่งผิดปกติ มันคือผลลัพธ์เริ่มต้นของการสร้างโดยไม่มีรางนำทาง
ประการที่สอง การกระจายตัว ทุกทีมต้องการแอปของตัวเอง และไม่มีฝ่าย IT ส่วนกลางใดที่จะสร้างและดำเนินการแอปหลายสิบตัวด้วยมือได้ หากไม่มีขอบเขตป้องกัน แต่ละแอปจะถูกสร้างบนสแต็กที่ผู้สร้างหรือโมเดลเอื้อมถึง: ฐานข้อมูลที่แตกต่าง, รูปแบบการรับรองความถูกต้องที่แตกต่าง, ความลับที่ถูกซ่อนไว้ตามที่มันลงไป หากปฏิเสธคำขอแทน พวกเขาก็ไม่หยุด พวกเขาแค่ย้ายไปอยู่นอกระบบ ไม่ว่าทางไหน คุณจะได้รับมรดกไม่ใช่แค่ฝูงบินของแอป แต่ยังรวมถึงโครงสร้างพื้นฐานที่ยุ่งเหยิงภายใต้พวกมัน และไม่มีสิ่งใดที่ IT จะสามารถรักษาความปลอดภัย สนับสนุน หรืออธิบายได้อย่างสมเหตุสมผล
ดังนั้นคำถามจริงที่ทุกบริษัทกำลังจะเผชิญ: คุณจะปล่อยให้พนักงานที่ไม่ใช่สายเทคนิคส่งซอฟต์แวร์ภายในองค์กรจริงๆ โดยไม่ได้รับมรดกฝูงบินนั้นได้อย่างไร?
คำตอบเริ่มต้นสามข้อล้วนล้มเหลว:
1) ล็อคมันลง คำขอเข้าคิว ความอดทนหมดลง และแอปเงียบก็ถูกสร้างขึ้นอยู่ดี ตอนนี้คุณมองไม่เห็นอะไรเลย คุณไม่สามารถกำกับดูแลสิ่งที่คุณมองไม่เห็นได้
2) ปล่อยมันไป ชี้ผู้ที่ไม่ใช่วิศวกรไปที่เครื่องมือ AI โดยไม่มีโครงสร้างและเฉลิมฉลองเดโม นี่คือวิธีที่คุณได้ไฟล์ 540 KB และคุณไม่สามารถตรวจสอบเพื่อหลุดพ้นจากมันได้หลังจากความจริงแล้ว เมื่อถึงเวลาที่โมโนลิธปรากฏขึ้นในการตรวจสอบโค้ด มันก็เป็นโมโนลิธอยู่แล้ว มันต้องถูกป้องกันตั้งแต่จุดเริ่มต้น
3) ตรวจสอบทุกอย่าง ใส่การอนุมัติโดยมนุษย์ในการเปลี่ยนแปลงทุกครั้ง ทีม IT ของคุณมีขนาดเล็ก ปริมาณการสร้างกำลังระเบิด และตอนนี้ทุกการปรับใช้ต้องรอตารางเวลาของผู้ตรวจสอบ การตรวจสอบไม่ว่าจะเป็นการฆ่าการนำไปใช้หรือถูกประทับตรายาง ผลลัพธ์ทั้งสองอย่างทำให้วัตถุประสงค์ล้มเหลว
ดังนั้นคำตอบไม่ใช่เอกสารนโยบายอีกฉบับ แต่เป็นวงจรชีวิต: SDLC จริง ออกแบบมาสำหรับคนที่ไม่เคยเรียกตัวเองว่านักพัฒนา โดยมีขอบเขตป้องกันที่สร้างไว้ในแพลตฟอร์มแทนที่จะเขียนไว้ในบันทึก ถนนที่นำพาการสร้างตั้งแต่แนวคิดภาษาธรรมดาไปจนถึงการผลิตภายใต้การกำกับดูแล โดยไม่ต้องขอให้ผู้สร้างเป็นวิศวกร บุคคลนั้นเป็นผู้ให้เจตนา; แพลตฟอร์มเป็นผู้ให้วินัย
หลักการหนึ่งเดียวที่แทรกซึมอยู่ในทุกขั้นตอน: AI ทำงานหนัก, โค้ดที่กำหนดตายตัวเป็นตัวกำหนดขอบเขต, และมนุษย์จัดการกับข้อยกเว้น AI ร่าง จัดประเภท และเขียน โค้ดตัดสินใจว่าสิ่งใดได้รับอนุญาต คนจะถูกใช้เฉพาะเมื่อจำเป็นต้องใช้ดุลยพินิจจริงๆ ยึดมั่นในการแบ่งแยกนั้น มันคือสิ่งที่ทำให้ทุกอย่างขยายขนาดได้
เราเรียกมันว่า Citizen SDLC หกขั้นตอน แต่ละขั้นตอนอยู่ภายใต้การกำกับดูแล
ขั้นตอนที่ 1
แนวคิด
บุคคลอธิบายแอปด้วยภาษาธรรมดา โดยได้รับความช่วยเหลือจาก AI: มันทำอะไร ใครใช้ มันแตะต้องข้อมูลอะไร ใครเป็นเจ้าของ ใช้เวลาไม่กี่นาทีและอ่านเหมือนบันทึก มันทำหน้าที่เป็นข้อมูลสรุปที่ทุกอย่างในขั้นตอนต่อๆ ไปใช้ดำเนินการ นี่คือการเคลื่อนไหวครั้งแรกของโมเดลการดำเนินงาน: AI ทำงานหนักในการเปลี่ยนคำพูดที่วกวนให้เป็นสิ่งที่จัดโครงสร้างแล้ว
นี่คือสิ่งที่ดูเหมือนในทางปฏิบัติ มีคนในฝ่ายการเงินกองทุนพิมพ์ว่า: "ฉันต้องการตัวติดตามสำหรับหนังสือเรียกทุน ตอนนี้มันเป็นสเปรดชีตที่ฉันอัปเดตด้วยมือและส่งอีเมลไปรอบๆ ทุกวันศุกร์" AI ถามในสิ่งที่นักวิเคราะห์รับเข้าเรียนจะถาม ใครอีกบ้างที่ต้องเห็นมัน? สิบสองคนทั่วฝ่ายการเงินกองทุนและ IR ข้อมูลอยู่ที่ไหนในวันนี้? สเปรดชีตใน Box และแบบอ่านอย่างเดียวก็พอ ใครเป็นเจ้าของเมื่อคุณไม่อยู่? ผู้จัดการของเธอ คำพูดที่วกวนกลายเป็นข้อมูลสรุป: วัตถุประสงค์ ผู้ใช้ แหล่งข้อมูล ระดับการเข้าถึง เจ้าของ แม้กระทั่งการเดารูปร่างของแอปครั้งแรก PRD ในทางปฏิบัติ เขียนโดยคนที่ไม่เคยได้ยินคำว่า PRD มาก่อน
GIF
ยังไม่มีอะไร存在 ไม่มีโค้ด ไม่มีการเข้าถึง ไม่มีโครงสร้างพื้นฐาน นั่นเป็นความตั้งใจ: บริษัทสร้างความเห็นเกี่ยวกับแอปก่อนที่แอปจะมีอยู่ แทนที่จะเป็นหกเดือนหลังจากที่มันรับน้ำหนักได้
ขั้นตอนที่ 2
หน้าแรก
ทุกคำขอผ่านหน้าแรกที่มีโครงสร้างเดียว และการเคลื่อนไหวเดียวกันที่ยื่นคำขอก็ส่งตรงไปยังการคัดกรอง ข้อมูลสรุปคือคำขอ ติ๊กเก็ตที่ IT เห็น บันทึกถาวร และรายการในแค็ตตาล็อกที่ทุกคนสามารถค้นหาได้ ทั้งหมดในครั้งเดียว ไม่มีการถามตามทางเดิน ไม่มีการช่วยเหลือพิเศษ ไม่มีไปป์ไลน์เงา คุณไม่สามารถกำกับดูแลสิ่งที่คุณมองไม่เห็นได้ และคุณไม่สามารถแบ่งปันสิ่งที่คุณหาไม่พบ หน้าแรกทำให้ทั้งสองอย่างเป็นจริงตั้งแต่วันแรก
นี่คือขั้นตอนที่ฆ่าไปป์ไลน์เงา การสร้างที่ข้ามหน้าแรกยังคงมีอยู่เป็นต้นแบบบนแล็ปท็อป แต่นั่นคือจุดที่มันหยุดอยู่ ทุกสิ่งที่เปลี่ยนต้นแบบให้เป็นซอฟต์แวร์ที่ทีมสามารถพึ่งพาได้นั้นอยู่ downstream ของขั้นตอนนี้: พื้นที่เก็บข้อมูลจริง การลงชื่อเข้าใช้บริษัท ไปป์ไลน์ปรับใช้ สถานที่ที่จะรันจริงๆ ไม่มีสิ่งใดไปถึงการสร้างที่ไม่เคยผ่านมา คุณสามารถเลี่ยงหน้าแรกได้; คุณแค่ไม่สามารถผ่านพ้นต้นแบบไปได้ถ้าคุณทำ
ขั้นตอนที่ 3
การคัดกรอง
AI จัดประเภทคำขอตามสองแกน รูปร่าง: มันเป็นแอปประเภทไหน? การตรวจสอบย้อนกลับว่าพนักงานสร้างอะไรจริงๆ มักจะยุบลงเป็นรายการสั้นๆ: เครื่องมือสร้างสิ่งประดิษฐ์, ระบบอัตโนมัติของเวิร์กโฟลว์, แอป CRUD และแดชบอร์ดแบบโต้ตอบ การตั้งชื่อรูปร่างจะบอกสถาปัตยกรรมที่มันต้องการ และมันส่งมอบถนนที่ปูไว้ให้กับขั้นตอนถัดไปเพื่อประทับตรา รัศมีการระเบิด: ความเสียหายที่การสร้างนี้สามารถทำได้หากมันผิดพลาด? เราประเมินสิ่งนี้ในสี่มิติ:
- ขอบเขตและความสามารถ: มันสามารถแตะต้องอะไรได้บ้าง และมันสามารถเขียนหรืออ่านได้อย่างเดียว?
- การย้อนกลับได้และความเป็นอิสระ: มีมนุษย์อยู่ในวงจรหรือไม่ และการกระทำนั้นสามารถยกเลิกได้หรือไม่?
- การเปิดเผย: ใครเห็นผลลัพธ์ และมันเดินทางออกนอกบริษัทไปไกลแค่ไหน?
- ความอ่อนไหวของข้อมูล: ข้อมูลที่มันโต้ตอบด้วยนั้นเป็นความลับแค่ไหน?
แต่กฎที่ทำให้สิ่งนี้เชื่อถือได้คือ: AI แนะนำ โค้ดตัดสินใจ โมเดลอ่านข้อมูลสรุปและจัดประเภทมัน; จากนั้นโค้ดนโยบายที่ IT เขียนจะตรวจสอบการจัดประเภทแต่ละครั้งกับกฎ ดูมันทำงานกับตัวติดตามหนังสือเรียกทุน รูปร่าง: แดชบอร์ดแบบโต้ตอบ รัศมีการระเบิด: ข้อมูลกองทุนภายใน ผู้ใช้ภายในสิบสองคน อ่านอย่างเดียว มีมนุษย์อยู่ในวงจร ไม่ทับซ้อนกับแอปที่มีอยู่ ทุกมิติอยู่ภายในเกณฑ์ที่อนุมัติ ดังนั้นจึงได้รับการอนุมัติ และไม่มีมนุษย์คนใดโต้แย้งเกี่ยวกับมัน
ตอนนี้เปลี่ยนข้อเท็จจริงหนึ่งอย่าง สมมติว่าตัวติดตามต้องการข้อมูลคำมั่นสัญญาของ LP ด้วย ข้อมูลสรุปสามารถโน้มน้าวใจได้มากเท่าที่ต้องการ; การเปลี่ยนแปลงครั้งเดียวนั้นทำให้มิติความอ่อนไหวของข้อมูลพุ่งสูงเกินเกณฑ์ที่ IT ตั้งไว้ และคำขอจะไปหาคน ไม่มีการตัดสินใจเกิดขึ้นในระหว่างนั้น กฎตรงกันหรือไม่ตรงกัน
สามเส้นทางออก:
- อนุมัติ รัศมีการระเบิดอยู่ในทุกเกณฑ์ ข้อมูลสรุปสมบูรณ์ ความมั่นใจสูง ที่ลูกค้าของเรา ประมาณ 9 ใน 10 คำขอได้รับการแก้ไขด้วยวิธีนี้ โดยอัตโนมัติ
- ใช้ซ้ำ มันทับซ้อนกับแอปที่มีอยู่แล้ว ดังนั้นผู้ขอจึงถูกส่งต่อไปยังเจ้าของแอปนั้นแทนที่จะสร้างซ้ำซ้อน สิ่งที่ซ้ำซ้อนจะถูกรวมเข้าด้วยกัน ไม่ใช่เพิ่มจำนวน
- ส่งต่อ มิติใดมิติหนึ่งข้ามเกณฑ์ หรือความมั่นใจต่ำ มนุษย์ที่ IT และ Security จะได้รับคำขอทั้งหมดพร้อมบริบท
GIF
คำขอที่สิบ ซึ่งเป็นคำขอที่แปลกแยก ยังคงลงจอดบนโต๊ะของมนุษย์โดยมีข้อมูลสรุปครบถ้วนแนบมา อีกเก้าคำขอไม่เคยต้องทำ
ขั้นตอนที่ 4
การจัดเตรียม
นี่คือการเคลื่อนไหวที่ทำให้ IT พูดว่า "ใช่" ในปริมาณมาก: การจัดเตรียมไม่ใช่ IT สูญเสียการควบคุมสิ่งที่ส่งออกไป แต่เป็นการควบคุมของ IT ที่ย้ายไปยัง上游 แทนที่จะตรวจสอบทุกแอปหลังจากความจริง IT เขียนถนนที่ปูไว้ครั้งเดียว และทุกแอปก็เกิดบนนั้น หนึ่งคนอนุมัติ และแพลตฟอร์มประทับตราแอปจากถนนสำหรับรูปร่างของมัน: repo, การลงชื่อเข้าใช้บริษัท, ตัวตนสำหรับปรับใช้, สภาพแวดล้อมส่วนตัว และฐานข้อมูลของตัวเอง ซึ่งทั้งหมดถูกกำหนดเป็นโครงสร้างพื้นฐานเป็นโค้ดที่ IT เป็นเจ้าของและควบคุมเวอร์ชัน จัดเตรียมภายในไม่กี่นาที
นี่เป็นช่วงเวลาเดียวที่อำนาจที่สูงขึ้นทำงาน และมนุษย์อยู่ข้างหน้ามัน ทุกแอปถูกสร้างขึ้นอย่างแยกตัว อยู่ภายใต้การกำกับดูแลและตรวจสอบได้: สภาพแวดล้อมที่มีกำแพงกั้นของตัวเอง ไม่มีที่อยู่สาธารณะ ไม่มีความลับของคลาวด์ที่ถูกเก็บไว้ ร่องรอยการตรวจสอบแบบ追加เท่านั้นตั้งแต่วันที่ศูนย์ งานรักษาความปลอดภัยเกิดขึ้นครั้งเดียว ในถนน ไม่มีแอปใดต้องทำซ้ำ
เนื่องจากถนนถูกเขียนต่อรูปร่าง การอนุมัติโดยมนุษย์จึงเป็นท่าทางเริ่มต้น ไม่ใช่ภาษีถาวร รูปร่างที่แปลกใหม่และการสร้างที่มีรัศมีการระเบิดสูงจะคงประตูมนุษย์ไว้ตลอดไป แต่เมื่อถนนของรูปร่างใดรูปร่างหนึ่งพิสูจน์ตัวเองผ่านการสร้างหลายครั้งแล้ว คำขอที่มีรัศมีการระเบิดต่ำบนถนนนั้นสามารถจัดเตรียมได้โดยอัตโนมัติ มันเป็นตรรกะ "บันทึกดุลยพินิจของมนุษย์ไว้สำหรับส่วนท้าย" แบบเดียวกันที่ใช้ในขั้นตอนก่อนหน้าก่อนหน้านี้: ในช่วงแรกคุณส่งต่อให้คนมากขึ้น และเมื่อรูปแบบคงที่ เส้นก็จะเลื่อนไปสู่ระบบอัตโนมัติ
และถนนยังนำพาอีกสิ่งหนึ่งที่สำคัญพอๆ กับโครงสร้างพื้นฐาน: กฎของ AI repo ที่สืบทอดมาส่งชุดคำสั่งให้กับเอเจนต์การเขียนโค้ดในทุกเซสชัน โดยเข้ารหัสรูปแบบที่ควรหลีกเลี่ยงซึ่งเรียนรู้จากความล้มเหลวจริง อย่าใส่ข้อมูล blob แบบอินไลน์ที่มีขนาดเกิน 1 KB อย่าเพิ่มฟังก์ชันที่เขียนข้อมูลใหม่เมื่อโหลดแอป นี่คือวิธีแก้ปัญหาคุณภาพภายใต้ฝากกระโปรงโดยไม่ต้องขอให้ผู้สร้างรู้หลักปฏิบัติที่ดีที่สุดแม้แต่ข้อเดียว: ถนนทำให้เอเจนต์ปฏิบัติตามพวกมัน ทุกกฎคือรอยแผลเป็นที่มีเรื่องราวอยู่เบื้องหลัง (คุณได้อ่านหนึ่งในนั้นแล้ว)
ขั้นตอนที่ 5
การสร้าง
ผู้สร้างพรอมต์เอเจนต์การเขียนโค้ดของพวกเขา (Claude Code, Codex ฯลฯ) ภายในเวิร์กสเปซคลาวด์ที่มีการควบคุม ไม่ใช่บนแล็ปท็อปของตัวเอง เอเจนต์เทอร์มินัลบนแล็ปท็อปสืบทอดทุกสิ่งที่อยู่ที่นั่น: อีเมล, ไดรฟ์ที่ซิงค์, คุกกี้เบราว์เซอร์, ข้อมูลรับรองที่ถูกแคช ในเวิร์กสเปซ เอเจนต์เห็นโปรเจกต์เท่านั้น ไม่มีอะไรอื่น
ทุกสิ่งที่วิศวกรจะพกติดตัวไปตามปกติจะถูกพัดพาโดยราง: ที่ลูกค้าของเรา มีขอบเขตป้องกัน 35 รายการในสี่ชั้นที่ผู้สร้างไม่สามารถปิดได้
ชั้นการรวม (merge layer) รวมถึงการตรวจสอบการไหลลอย (drift checks) ที่ออกแบบมาโดยเฉพาะสำหรับโค้ดที่สร้างโดย AI: งบประมาณขนาดไฟล์, ไม่มีข้อมูลอินไลน์ที่ใหญ่เกินไป, การปฏิบัติตามบันทึกการตรวจสอบ สีเขียวหรือไม่รวม (merge) เมื่อการตรวจสอบล้มเหลว ผู้สร้างขอให้เอเจนต์แก้ไขและผลักอีกครั้ง
มนุษย์ไม่ตรวจสอบการเปลี่ยนแปลงตามปกติ การตรวจสอบคือการตรวจสอบ การเปลี่ยนแปลงตามปกติเคลื่อนที่ด้วยความเร็วของ CI ไม่ใช่ด้วยความเร็วของปฏิทินผู้ตรวจสอบ สิ่งที่ไปถึงมนุษย์คือส่วนท้ายที่สำคัญ ซึ่งตรวจพบโดยอัตโนมัติ: การเปลี่ยนแปลงสคีมาที่ทำลายล้าง, การพึ่งพาใหม่, การเปลี่ยนแปลงข้อจำกัดของเอเจนต์เอง, อะไรก็ตามที่แตะต้องโครงสร้างพื้นฐาน สิ่งเหล่านั้นรอคน ไม่มีอะไรอื่น และเมื่อมีสิ่งใหม่หลุดรอดออกไป anyway วิธีแก้ไขคือการตรวจสอบอัตโนมัติใหม่ ไม่ใช่การตรวจสอบโดยมนุษย์เพิ่มเติม ระบบจะเข้มงวดขึ้นโดยการเข้ารหัสบทเรียน ไม่ใช่โดยการเพิ่มการประชุม
จำแดชบอร์ดจากตอนเปิดได้ไหม การตรวจสอบการไหลลอยสองครั้งคงจะถูกเรียกใช้กับมันในสัปดาห์แรก ก้อนข้อมูลบรรทัดเดียวขนาด 80 KB คงจะทำให้ CI ล้มเหลวในการคอมมิตครั้งแรก หลายเดือนก่อนที่โหมดความล้มเหลวใดๆ จะแข็งตัว
ขั้นตอนที่ 6
การใช้งานและการเปลี่ยนแปลง
หกเดือนต่อมา ตัวติดตามหนังสือเรียกทุนยังคงทำงานอยู่ และนี่คือจุดที่วงจรชีวิตพิสูจน์คุณค่าของมัน มีคนใน IR ตั้งคำถามเกี่ยวกับกำหนดเวลาการโอนเงินในหนังสือแจ้งเดือนมีนาคม ร่องรอยการตรวจสอบตอบภายในสามสิบวินาที: ใครเปลี่ยนฟิลด์ เมื่อไหร่ และมันบอกว่าอะไรก่อนหน้านี้ บันทึกในธุรกรรมเดียวกับการแก้ไขนั้นเอง ไม่มีใครสร้างความจริงขึ้นมาใหม่จากห่วงโซ่อีเมล เมื่อผู้สร้างเปลี่ยนทีม ความเป็นเจ้าของจะถูกโอนไปยังผู้สืบทอดที่ได้รับการเสนอชื่อ แทนที่จะสลายไปเป็นอาการยัก shoulders และถ้าเธอออกจากบริษัทไปเลย การลงชื่อเข้าใช้ของเธอจะตาย และทุกประตูที่มันเปิดไว้จะปิดลงพร้อมกัน รวมถึงตัวติดตามด้วย คำขอคุณสมบัติในไตรมาสถัดไปจะเดินบนรางเดียวกันกับการคอมมิตครั้งแรก
การกำกับดูแลทำงานบนสัญญาณ ไม่ใช่การตรวจสอบประจำปี ตัวชี้วัดการใช้งานของตัวติดตามแสดงให้เห็นว่าอีกสองทีมเริ่มพึ่งพามัน ดังนั้นมันจึงได้รับการเลื่อนระดับและลงทุน แดชบอร์ดสกุลเงินที่ไม่มีใครเปิดตั้งแต่เดือนเมษายนจะถูกเก็บถาวร ไม่ใช่ปล่อยให้เน่าในเมนู ไม่มีใครเสียใจกับมัน มีการกำหนดความเป็นเจ้าของตั้งแต่วันแรก ดังนั้นไม่มีอะไรมีอายุยืนยาวกว่าผู้สร้างโดยไม่มีเจ้าของ เอกสารจะถูกสร้างใหม่เมื่อแอปพัฒนา ดังนั้นมันจึงไม่เคยล้าสมัย แอปที่ไม่ได้ใช้คือความล้มเหลว ไม่ใช่ถ้วยรางวัล เป้าหมายไม่เคยเป็นจำนวนแอป: มันคือแคตตาล็อกที่มีชีวิตซึ่งคนของคุณเชื่อถือจริงๆ แทนที่จะเป็นสุสานของซอฟต์แวร์ที่ถูกลืม
เมื่อแคตตาล็อกเติบโตจากสิบแอปเป็นสองร้อยแอป ทีมกลางไม่สามารถจับตาดูทั้งหมดได้อีกต่อไป และการกำกับดูแลต้องผลักออกไปยังทีมที่เป็นเจ้าของแอป เมื่อใดและไกลแค่ไหนที่จะกระจายอำนาจนั้นเป็นเรื่องของดุลยพินิจ และมันจะเปลี่ยนไปเมื่อพอร์ตโฟลิโอเติบโต การกำกับดูแลที่นี่คือท่าทางที่คุณปรับแต่งอย่างต่อเนื่อง ไม่ใช่การควบคุมที่คุณตั้งไว้ครั้งเดียว
กฎที่ยึดทุกอย่างไว้ด้วยกัน
มีทริกเกอร์หนึ่งที่เราสอนลูกค้าทุกคน เพราะมันตอบคำถาม 90% ว่า "สิ่งนี้ต้องใช้กระบวนการเต็มรูปแบบหรือไม่?": กฎผู้บริโภคคนที่สอง มันใช้ได้เพราะนั่นคือช่วงเวลาที่โปรไฟล์ความเสี่ยงเปลี่ยนแปลง
มีคนสร้างการวิเคราะห์สำหรับตัวเอง บนแล็ปท็อปของตัวเอง ด้วยการเข้าถึงข้อมูลที่มีขอบเขต? รัศมีการระเบิดต่ำ การกำกับดูแลแบบเบา แผนภูมิ บันทึก และสคริปต์ที่พวกเขารันสำหรับตัวเองไม่จำเป็นต้องมีไปป์ไลน์ปรับใช้ แต่ทันทีที่คนที่สองต้องการใช้ผลลัพธ์โดยตรง แทนที่จะขอให้ผู้เขียนรีเฟรช? รัศมีการระเบิดพุ่งสูงขึ้น: ขอบเขตมากขึ้น ข้อมูลเดินทางไกลขึ้น มีคนอื่นเชื่อถือว่ามันถูกต้อง มันเป็นซอฟต์แวร์แล้ว และมันเลื่อนขั้นสู่วงจรชีวิตเต็มรูปแบบ อย่างจงใจ เป็นเหตุการณ์ที่ชัดเจน แหล่งข้อมูลเดียวกัน ตัวตนเดียวกัน ถนนใหม่
กฎข้อเดียวนั่นคือเหตุผลที่กระบวนการไม่ทำให้คนจมน้ำ การสร้างส่วนใหญ่ไม่เคยข้ามเส้น สิ่งที่ข้ามคือสิ่งที่คุ้มค่ากับพิธีการอย่างแน่นอน
สิ่งที่เราซื่อสัตย์เกี่ยวกับ
ไม่มีแพลตฟอร์มใดทำให้ผู้สร้างครั้งแรกเขียนโค้ดที่สมบูรณ์แบบ เราไม่อ้างว่าทำได้ ชั้นต่างๆ มีอยู่เพื่อให้ความผิดพลาดเป็นความไม่สะดวกภายในขอบเขตเล็กๆ แห่งหนึ่ง ไม่ใช่เหตุการณ์ที่เกิดขึ้นทั่วทั้งบริษัท แต่ละชั้นครอบคลุมสิ่งที่ชั้นที่อยู่เหนือมันไม่สามารถทำได้:
และการตรวจสอบไม่ได้ป้องกันอะไร แต่มันทำให้ทุกเหตุการณ์สั้น อธิบายได้ และระบุแหล่งที่มาได้ นั่นคือความแตกต่างระหว่างบ่ายที่แย่กับไตรมาสที่แย่
การพัฒนาโดยพลเมืองไม่ได้มีไว้เพื่อแทนที่วิศวกรรมมืออาชีพ ระบบบันทึกในกระบวนการที่มีการควบคุม อะไรก็ตามที่เผชิญหน้ากับลูกค้าหรือนักลงทุน แอปที่สร้างขึ้นสำหรับผู้ใช้ภายนอก อะไรก็ตามที่การหยุดทำงานมีโทษทางการเงิน: สิ่งเหล่านั้นยังคงเป็นของวิศวกรรม และหน้าแรกจะส่งต่อพวกมันไปที่นั่นตั้งแต่วันแรก สิ่งที่มันแทนที่คือคอขวด มันทำให้ประชาธิปไตยกับเครื่องมือภายในระยะยาวที่ไม่เคยคุ้มค่ากับโปรเจกต์วิศวกรรมที่เป็นทางการ และส่งมอบพวกมันด้วยความเร็วที่คิวโรดแมปไม่เคยให้ได้ กรอบการทำงานที่ไม่มีขอบเขตคือสโลแกน; อันนี้รู้ว่ามันไม่เหมาะสำหรับอะไร
สิ่งที่เปลี่ยนแปลงจริงๆ
ที่บริษัทการลงทุน แอปแรกที่ผ่านแพลตฟอร์มคือแอปที่กระตุ้นให้เกิดมัน: แดชบอร์ดจากเรื่องราวตอนเปิด สร้างใหม่บนราง หน้าจอเดียวกัน ผู้สร้างคนเดียวกัน ตอนนี้มีพื้นที่เก็บข้อมูลจริง การลงชื่อเข้าใช้บริษัท และประวัติของการแก้ไขทุกครั้ง มันไม่สามารถตัดทอนตัวเองเหลือ 7 ไบต์ได้อีกต่อไป เพราะคลาสของโค้ดที่ทำให้เกิดสิ่งนั้นไม่สามารถรวม (merge) ได้
ประมาณ 9 ใน 10 คำขอได้รับการแก้ไขโดยอัตโนมัติแล้ว และส่วนแบ่งนั้นมีแต่จะเพิ่มขึ้นเท่านั้น ส่วนใหญ่ที่ผู้สร้างที่ไม่ใช่สายเทคนิคทำนั้นมีรัศมีการระเบิดต่ำโดยธรรมชาติ เครื่องมือภายใน, อ่านเป็นส่วนใหญ่, ผู้ชมจำนวนน้อย เมื่อถนนของแต่ละรูปร่างพิสูจน์ตัวเอง การสร้างเหล่านั้นมากขึ้นจะปลอดภัยที่จะจัดเตรียมและปรับใช้โดยไม่มีมนุษย์อยู่ในวงจรเลย ความสนใจของมนุษย์จะยังคงมุ่งเน้นไปที่ส่วนท้ายที่สำคัญและบางลงในที่อื่นๆ
คำว่า "ใช่" ใช้เวลาไม่กี่นาทีในวันนี้ และมันมีแนวโน้มไปสู่ทันที เพราะ "ไม่" ถูกสร้างไว้ในนั้น
ทุกบริษัทกำลังจะมีผู้สร้างหลายร้อยคน บริษัทส่วนใหญ่ยังคงตัดสินใจว่าจะกลัวสิ่งนั้นหรือตื่นเต้นกับมัน บริษัทที่จะชนะจะไม่ใช่บริษัทที่มีผู้สร้างมากที่สุด แต่จะเป็นบริษัทที่มีถนนที่ดีที่สุด
