ข้อจำกัดที่ดีได้หล่อหลอมยุคที่ดีที่สุดของซอฟต์แวร์และอาชีพของผมเอง แนวทางที่มีความคิดเห็นชัดเจนบางอย่าง เช่น หลักการ 12-factor app หรือ MVC ได้มอบภาษากลางให้เราใช้ในการสร้างบริการที่เชื่อถือได้และออกแบบการแยกส่วนความรับผิดชอบ สิ่งเหล่านี้เป็นกฎง่ายๆ ที่บอกได้ง่าย แต่ปฏิบัติตามได้อย่างสมบูรณ์แบบนั้นยาก กฎเหล่านี้ให้กำเนิดอุตสาหกรรมทั้งหมด: SaaS, PaaS, โครงสร้างพื้นฐานคลาวด์ ทั้งหมดสร้างขึ้นบนพื้นฐานของข้อจำกัดที่คิดมาอย่างดี ซึ่งบอกกับผู้สร้างว่า: นี่คือขอบเขต จงอยู่ในขอบเขตนี้ แล้วสิ่งดีๆ จะตามมา ผมเองก็ได้รับประโยชน์จากการใช้ข้อจำกัดเหล่านี้ในผลงานที่ดีที่สุดบางชิ้นของผม
ผมเชื่อว่าซอฟต์แวร์ที่ใช้ AI เป็นหลักต้องการข้อจำกัดของมันเอง นี่คือข้อจำกัดที่ผมคิดขึ้นมา
โค้ดเบสของคุณมีขนาดสูงสุด นี่ไม่ใช่เรื่องของรสนิยม ขีดจำกัดนั้นมีอยู่จริง วัดผลได้ และเล็กกว่าที่คุณคิด
ขีดจำกัดคือ: ครึ่งหนึ่งของหน้าต่างบริบท (context window) ของโมเดล AI ที่เอเจนต์ของคุณใช้สร้างและบำรุงรักษาผลิตภัณฑ์ของคุณ ซึ่งหมายความว่าขนาดของตรรกะทางธุรกิจหลักและบริบทของระบบของคุณไม่ควรเกินครึ่งหนึ่งของหน้าต่างบริบทของ LLM ที่คุณพึ่งพา
ทำไมต้องครึ่งหนึ่ง? หน้าต่างบริบททำหน้าที่สองอย่าง ครึ่งแรกเก็บโค้ดของคุณ ครึ่งที่สองคือที่ที่เอเจนต์ใช้เหตุผล วางแผน และสร้าง ถ้าคุณเติมโค้ดให้เต็มหน้าต่างทั้งหมด คุณจะไม่เหลือพื้นที่ให้คิดเลย ครึ่งหนึ่งเพื่อความเข้าใจ ครึ่งหนึ่งเพื่อการคิด
ส่วนที่ยากที่สุดของธุรกิจซอฟต์แวร์ไม่เคยอยู่ที่การสร้างฟีเจอร์
ผู้ก่อตั้งเทคโนโลยีที่มีประสบการณ์ทุกคนรู้ดี สิ่งที่ยากคือการระบุซอฟต์แวร์ชิ้นเล็กที่สุดที่มีประโยชน์สำหรับกลุ่มลูกค้าที่ใหญ่พอ จากนั้นก็รวบรวมผู้คนให้ทำงานที่ยากลำบากในการหาลูกค้า การบริการลูกค้า และการรักษาลูกค้า
การสร้างซอฟต์แวร์เคยมีราคาแพง วิศวกรมีต้นทุนสูง สิ่งนี้สร้างแรงเสียดทาน ทำให้เกิดกระบวนการพัฒนาแบบวนซ้ำ แต่มันก็สร้างวินัยด้วย คุณต้องเลือก: ลูกค้าต้องการอะไรมากที่สุด? อะไรคือสิ่งที่เล็กที่สุดที่คุ้มค่าจะสร้าง? ต้นทุนของมนุษย์ในการสร้างวิศวกรรมทำให้ทีมมีสมาธิ ข้อจำกัดสร้างความชัดเจน บริษัทที่ดีที่สุดใน Silicon Valley เติบโตมาแบบนี้
ตอนนี้เอเจนต์ AI สร้างเกือบทุกอย่างที่คุณขอให้สร้าง คอขวดได้หายไปแล้ว วินัยก็หายไปพร้อมกับคอขวด
การผลิตแบบไม่มีต้นทุนนำไปสู่การผลิตมากเกินไป การผลิตมากเกินไปคือโหมดความล้มเหลวโดยปริยายของบริษัทที่ใช้ AI เป็นหลัก
ผู้ก่อตั้งที่ไม่ใช่สายเทคนิคและนักลงทุนจำเป็นต้องเข้าใจ这一点 ฟีเจอร์มากขึ้น โค้ดมากขึ้น และพื้นที่ผิวผลิตภัณฑ์ที่ต้องดูแลมากขึ้น ไม่ใช่สัญญาณของความก้าวหน้าอีกต่อไป สิ่งเหล่านี้บ่งชี้ถึงบริษัทที่ขาดข้อจำกัดที่มีคุณภาพ และบางครั้งก็บ่งชี้ถึงการขาดความชัดเจนขั้นพื้นฐาน
การผลิตมากเกินไปโดยไม่มีการกระจายและการบริโภคที่ปรับขนาดได้ สร้างการรั่วไหลครั้งใหญ่ในการดึงมูลค่า คุณส่งฟีเจอร์สิบอย่าง สองอย่างขับเคลื่อนการรักษาผู้ใช้ อีกแปดอย่างเพิ่มความซับซ้อนที่ทำให้สองอย่างที่สำคัญนั้นช้าลง โค้ดทุกบรรทัด กลายเป็นหนี้สินที่ปลอมตัวเป็นสินทรัพย์
ผู้สร้างที่มีประสบการณ์รู้จุดเปลี่ยน โค้ดเปลี่ยนจากการให้บริการลูกค้ามาเป็นการให้บริการตัวเอง ความซับซ้อนกลายเป็นศัตรูของผลิตภัณฑ์ ทีมใช้เวลาจัดการซอฟต์แวร์มากกว่าการปรับปรุงประสบการณ์ของลูกค้า ระบบเริ่มรู้สึกเทอะทะ ผู้ใช้เริ่มออกไป และทีมที่ติดต่อกับลูกค้าก็เริ่มหงุดหงิดอย่างเงียบๆ
ในโลกเก่า คุณไปถึงจุดเปลี่ยนนั้นในเวลาเป็นปี ในโลกที่ใช้ AI เป็นหลัก คุณไปถึงจุดเปลี่ยนในเวลาเป็นสัปดาห์ เอเจนต์ไม่เคยรู้สึกเหนื่อย ไม่เคยโต้แย้ง และไม่เคยพูดว่า "มันซับซ้อนเกินไป เราควรหยุด"
คุณจะรู้ได้อย่างไรว่าเมื่อไหร่ควรหยุด? เมื่อ AI เขียนโค้ดไม่จำกัดให้ฟรี สัญญาณอะไรที่บอกคุณว่าพอแล้ว?
มันคือกฎครึ่งหน้าต่าง (Half-Window Rule)
ตรรกะทางธุรกิจหลักของคุณต้องพอดีกับครึ่งหนึ่งของหน้าต่างบริบทของโมเดลที่ดูแลโค้ดเบสของคุณ วัดโค้ดเบสของคุณเป็นโทเค็น เปรียบเทียบกับครึ่งหนึ่งของหน้าต่างบริบท ถ้าคุณเกิน แรงงาน AI ของคุณก็กำลังเสื่อมลงแล้ว—ไม่เห็นได้ชัด ไม่รุนแรง แต่เงียบๆ และสม่ำเสมอ
อันตราย: ไม่มีอะไรพังอย่างเห็นได้ชัดเมื่อคุณข้ามเส้นนี้ เอเจนต์ไม่ปฏิเสธ โค้ดดูถูกต้อง การทดสอบผ่าน บั๊กที่คุณรายงานได้รับการแก้ไข
แต่ตอนนี้เอเจนต์ทำงานโดยไม่เข้าใจระบบทั้งหมดของคุณ เอเจนต์จับคู่รูปแบบกับชิ้นส่วนแทนที่จะใช้เหตุผลเกี่ยวกับภาพรวม การถดถอยที่ละเอียดอ่อนปรากฏขึ้น ตรรกะถูกทำซ้ำในส่วนของโค้ดเบสที่เอเจนต์มองไม่เห็น ปัญหาถูก "แก้ไข" โดยการเพิ่มโค้ดในที่ที่ควรจะเปลี่ยนโค้ดที่มีอยู่
คุณจะไม่สังเกตเห็นทันที ความเร็วในการทำงานยังคงรู้สึกสูง Pull requests ยังคงไหล แต่ละอันทำให้อันถัดไปแย่ลงเล็กน้อย การเสื่อมสภาพแบบทบต้นทำงานต่อต้านคุณ
เมื่อถึงเวลาที่คุณถาม "ทำไมเอเจนต์ของเราถึงวนเวียนอยู่ตลอด?" คุณก็อยู่ในปัญหาที่ลึกแล้ว
กฎนี้คือวินัยทางธุรกิจที่ปลอมตัวมาเป็นเรื่องเทคนิค
ความเรียบง่ายกลายเป็นข้อได้เปรียบทางการแข่งขันของคุณเมื่อต้นทุนการผลิตเป็นศูนย์ สร้างโค้ดเบสที่เล็กที่สุดที่ส่งมอบคุณค่าที่แท้จริงให้ลูกค้า ฟีเจอร์ที่ไม่จำเป็นทุกอย่าง สิ่งที่เป็นนามธรรมที่ไม่จำเป็นทุกบรรทัด และโค้ดที่คาดเดาเหตุการณ์ล่วงหน้าทุกบรรทัด จะกินงบประมาณการรับรู้ของแรงงาน AI ของคุณ ในที่สุด สิ่งเหล่านี้จะกินความสามารถของบริษัทคุณในการเคลื่อนไหว
ผลิตภัณฑ์ที่ดีที่สุดมักจะเป็นผลิตภัณฑ์ที่เรียบง่ายที่สุดที่แก้ปัญหาจริงได้อย่างสมบูรณ์ บทลงโทษสำหรับการละเมิดหลักการนี้ตอนนี้มาถึงเร็วขึ้นและทบต้นมากขึ้น เอเจนต์ AI ของคุณจะไม่โต้แย้งแบบที่วิศวกรอาวุโสที่หงุดหงิดเคยทำ
กฎปรับขนาดตามสถาปัตยกรรม สตาร์ทอัพผลิตภัณฑ์เดียว: ใช้กับโค้ดเบสทั้งหมด บริษัทที่มีหลายบริการ: ใช้กับแต่ละบริการอย่างอิสระ ส่วนใดๆ ของระบบของคุณที่ต้องเข้าใจเป็นองค์รวมจะต้องพอดีกับขอบเขตที่เอเจนต์ของคุณใช้เหตุผลเกี่ยวกับภาพรวม
สถาปัตยกรรมผลิตภัณฑ์ของคุณจะสะท้อนถึงขอบเขตการรับรู้ของเอเจนต์ของคุณ ไม่ว่าคุณจะวางแผนไว้หรือไม่ก็ตาม ผู้ก่อตั้งที่ออกแบบโดยเจตนาสำหรับสิ่งนี้จะนำหน้าผู้ที่เรียนรู้ผ่านความเจ็บปวด
นี่ไม่ใช่เรื่องความสมบูรณ์แบบ คุณจะไม่ได้อยู่ใต้เส้นตลอดไป โค้ดเบสเติบโต ฟีเจอร์ถูกเพิ่ม ความซับซ้อนสะสม จุดสำคัญคือความทะเยอทะยาน ไม่ใช่การปฏิบัติตามอย่างเคร่งครัด ถ้าคุณจำกฎนี้ไว้และอยู่ใกล้ขอบเขต คุณจะตัดสินใจได้ดีขึ้นเกี่ยวกับสิ่งที่จะสร้าง สิ่งที่จะแยกออก และสิ่งที่จะลบ ข้อจำกัดให้จุดอ้างอิงแก่คุณเมื่อทุกอย่างอื่นพูดว่า 'สร้างเพิ่ม' บางครั้งนี่หมายถึงการออกแบบสถาปัตยกรรมย่อยของเอเจนต์ใหม่ให้สอดคล้องกับกฎ—คล้ายกับวิธีที่ทีมมนุษย์แบ่งความเป็นเจ้าของเมื่อพวกเขาเติบโต
ผมตั้งใจจะปฏิบัติตามกฎนี้ในงานของผมเอง ไม่ใช่เพราะการละเมิดกฎหมายถึงความล้มเหลวทันที แต่เพราะการอยู่ใกล้ข้อจำกัดนี้ช่วยให้ผมสร้างซอฟต์แวร์ที่ยังคงมีประโยชน์ บำรุงรักษาได้ และมีคุณค่าเมื่อเวลาผ่านไป ผู้ก่อตั้งที่ปรับทิศทางตามสิ่งนี้จะไปได้ไกล ผู้ที่เพิกเฉยต่อข้อจำกัดโดยสิ้นเชิงจะเรียนรู้ผ่านความเจ็บปวด
ข้อจำกัดที่ดีไม่ได้รับประกันความสำเร็จ พวกมันทำให้ความสำเร็จมีแนวโน้มมากขึ้นโดยการกำจัดวิธีที่พบได้บ่อยที่สุดในการล้มเหลว 12-factor app คือชุดหลักการที่ไม่ได้สร้างบริษัท SaaS ของคุณให้คุณ แต่ถ้าคุณทำตาม โครงสร้างพื้นฐานของคุณก็ใช้งานได้เมื่อคุณต้องการปรับขนาด Half-Window Rule ทำงานในลักษณะเดียวกันทุกประการ ทำตามเจตนารมณ์ อยู่ใกล้ขอบเขต สร้างธุรกิจซอฟต์แวร์ที่มีประโยชน์และยั่งยืน
ความเรียบง่ายชนะเสมอ ตอนนี้ความเรียบง่ายชนะเร็วขึ้น
เกี่ยวกับผู้เขียน: Abhishek Parolkar คือ CEO ของ https://brain.pe - ซึ่งช่วยให้บริษัท Private Equity สร้างสมอง AI ดิจิทัลของตนเองสำหรับบริษัทหรือดีลเฉพาะ คุณอาจนำ AI มาใช้แล้ว แต่ AI นำคุณมาใช้หรือยัง?
