หัวข้อบทความ: ความคิดเกี่ยวกับการชะลอความเร็ว
ผู้เขียนบทความ: Mario Zechner
แปล: Peggy, BlockBeats

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

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

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

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

ต่อไปนี้คือเนื้อหาต้นฉบับ:

ใบหน้าของเต่าคืออารมณ์ที่ฉันมีเมื่อมองดูอุตสาหกรรมนี้

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

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

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

ปัจจุบัน เอเจนต์การเขียนโค้ดก็เริ่มเข้าสู่โค้ดเบสการผลิตแล้ว 12 เดือนที่ผ่านมา เราเริ่มเห็นผลที่ตามมาของ “ความก้าวหน้า” นี้ นี่คือความคิดเห็นของฉันในขณะนี้

ทุกอย่างพังทลาย

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

อินเตอร์เฟซผู้ใช้เต็มไปด้วยบั๊กที่ไร้สาระหลายประเภท ซึ่งปกติแล้วทีม QA จะสามารถจับได้ในมุมมองแรก

ฉันยอมรับว่าสถานการณ์นี้มีอยู่ก่อนที่เอเจนต์จะมา แต่ตอนนี้ ปัญหาเห็นได้ชัดว่าเร่งขึ้น

เราไม่สามารถเห็นสภาพจริงภายในบริษัท แต่บางครั้งก็มีข้อมูลรั่วไหลออกมา เช่น ข่าวลือเกี่ยวกับ “AWS ล่มจาก AI” Amazon Web Services ได้ “แก้ไข” เรื่องนี้ในทันที แต่ตามมาด้วยการเริ่มแผนการปรับโครงสร้างภายในเป็นเวลา 90 วัน

Satya Nadella (CEO ของ Microsoft) ได้เน้นย้ำว่าตอนนี้มีโค้ดจำนวนมากในบริษัทที่เขียนโดย AI แม้จะไม่มีหลักฐานโดยตรง แต่รู้สึกได้ว่าคุณภาพของ Windows กำลังลดลง แม้จากบล็อกที่ Microsoft เองเผยแพร่ พวกเขาก็ดูเหมือนจะยอมรับสิ่งนี้

บริษัทที่อ้างว่า “ผลิตภัณฑ์ 100% ถูกสร้างจากโค้ด AI” มักจะผลิตสินค้าที่เลวร้ายที่สุดที่คุณสามารถจินตนาการได้ ไม่ได้มุ่งหวังใคร แต่มีการรั่วไหลของหน่วยความจำที่วัดเป็น GB โครงสร้าง UI ที่ยุ่งเหยิง ฟังก์ชันที่ไม่สมบูรณ์ การล่มบ่อยครั้ง… สิ่งเหล่านี้ไม่ใช่ “การรับรองคุณภาพ” ที่พวกเขาคิด แต่ก็ไม่ใช่ “ให้เอเจนต์ทำทุกอย่างแทนคุณ” ที่เป็นตัวอย่างเชิงบวก

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

ทำไมเราจึงไม่ควรใช้เอเจนต์แบบนี้

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

คุณกำลังสร้างชั้นการจัดการเพื่อควบคุมกองทัพเอเจนต์ที่ทำงานอัตโนมัติ คุณติดตั้ง Beads แต่ไม่รู้ว่ามันแทบจะเป็น “มัลแวร์” ที่ไม่สามารถลบออกได้ แค่เพราะมีคนบอกว่า “ทุกคนทำแบบนี้” ถ้าไม่ทำแบบนี้ คุณ “จะพัง” (ngmi)

คุณกำลังเผาผลาญตัวเองใน “วงจรซ้อน” ที่ไม่สิ้นสุด

ดูสิ—Anthropic ใช้เอเจนต์หลายตัวสร้างคอมไพเลอร์ C แม้ว่าตอนนี้จะมีปัญหา แต่โมเดลรุ่นถัดไปจะต้องสามารถแก้ไขได้ใช่ไหม?

อีกดู—Cursor ใช้เอเจนต์มากมายสร้างเบราว์เซอร์ แม้ว่าตอนนี้จะใช้ไม่ได้เลย และต้องมีคนแทรกแซงเป็นครั้งคราว แต่โมเดลรุ่นถัดไปจะต้องสามารถทำได้ใช่ไหม?

“การกระจาย” “แบ่งแยกและปกครอง” “ระบบอัตโนมัติ” “โรงงานมืด” “แก้ปัญหาซอฟต์แวร์ในหกเดือน” “SaaS ตายแล้ว คุณยายของฉันเพิ่งใช้ Claw สร้าง Shopify”…

เรื่องเล่าเหล่านี้ฟังดูดีมาก

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

แต่ในวงการนักพัฒนาที่อยู่รอบตัวฉัน ฉันยังไม่เคยเห็นว่าวิธีนี้ได้ผลจริง ๆ แน่นอนว่าอาจเป็นเพราะเราทุกคนยังไม่เก่งพอ

ข้อผิดพลาดสะสมโดยไม่มีการเรียนรู้ ไม่มีอุปสรรค และการระเบิดที่ล่าช้า

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

แต่ “เครื่อง” ไม่ใช่มนุษย์ มนุษย์ที่ทำผิดซ้ำ ๆ มักจะเรียนรู้ที่จะไม่ทำผิดอีก—หรือถูกกระตุ้นด้วยการถูกด่า หรือในการเรียนรู้ที่แท้จริงก็แก้ไขได้

แต่เอเจนต์ไม่มีความสามารถในการเรียนรู้นั้น อย่างน้อยก็โดยค่าเริ่มต้นไม่มี มันจะทำผิดซ้ำแล้วซ้ำอีก และอาจสร้างข้อผิดพลาดที่แตกต่างกันจากข้อมูลการฝึกอบรม

แน่นอนว่าคุณสามารถพยายาม “ฝึก” มันได้: เขียนกฎใน AGENTS.md เพื่อไม่ให้มันทำผิดพลาดนี้อีก; ออกแบบระบบความจำที่ซับซ้อนเพื่อให้มันตรวจสอบข้อผิดพลาดในอดีตและแนวทางปฏิบัติที่ดีที่สุด ในบางประเภทของปัญหานั้นจริงๆ แล้วได้ผล แต่เงื่อนไขคือ—คุณต้องสังเกตเห็นว่ามันทำผิดพลาดนี้

ความแตกต่างที่สำคัญคือ มนุษย์เป็นอุปสรรค ในขณะที่เอเจนต์ไม่ใช่

มนุษย์ไม่สามารถสร้างโค้ด 20,000 บรรทัดในไม่กี่ชั่วโมง แม้ว่าจะมีข้อผิดพลาดบ่อยแค่ไหน ในหนึ่งวันก็สามารถสร้างข้อผิดพลาดได้จำนวนจำกัด การสะสมของข้อผิดพลาดเหล่านี้จะช้า โดยปกติ เมื่อ “ความเจ็บปวดจากข้อผิดพลาด” สะสมถึงระดับหนึ่ง มนุษย์ (จากการเกลียดความเจ็บปวดตามสัญชาตญาณ) จะหยุดเพื่อแก้ไข หรือถูกแทนที่ด้วยคนอื่นที่มาช่วยแก้ไข สุดท้าย ปัญหาจะได้รับการจัดการ

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

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

ในขณะนั้นคุณจะตระหนักว่า: คุณไม่สามารถเชื่อถือโค้ดชุดนี้ได้อีกต่อไป

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

ขอแสดงความยินดี คุณได้ทำให้ตัวเอง (และบริษัท) ตกอยู่ในสถานการณ์ที่เลวร้ายที่สุด

ผู้ค้าความซับซ้อน

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

สิ่งที่คุณได้รับคือ: ระบบที่ซับซ้อนมาก ซึ่งมีการเลียนแบบที่ไม่ดีของ “แนวทางปฏิบัติที่ดีที่สุดในอุตสาหกรรม” ผสมผสานกัน และคุณไม่ได้ควบคุมมันก่อนที่ปัญหาจะควบคุมไม่ได้

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

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

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

แต่ในชุดของมนุษย์ + เอเจนต์ กระบวนการนี้จะถูกเร่งอย่างมาก สองคน พร้อมกับเอเจนต์จำนวนมาก สามารถสร้างความซับซ้อนได้ในไม่กี่สัปดาห์

อัตราการเรียกคืนในการค้นหาของเอเจนต์ต่ำมาก

คุณอาจหวังให้เอเจนต์ “จัดการปัญหา” ช่วยคุณรีแฟกเตอร์ ปรับแต่ง ทำให้ระบบสะอาด แต่ปัญหาคือ: พวกมันไม่สามารถทำได้แล้ว

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

ก่อนที่เอเจนต์จะพยายามแก้ไขระบบ มันต้องค้นหาทุกโค้ดที่ต้องแก้ไขและการดำเนินการที่มีอยู่ที่สามารถนำกลับมาใช้ใหม่ได้ ขั้นตอนนี้เราจะเรียกว่า agentic search (การค้นหาโดยเอเจนต์)

เอเจนต์จะทำสิ่งนี้อย่างไร ขึ้นอยู่กับเครื่องมือที่คุณให้มัน: อาจเป็น Bash + ripgrep, ดัชนีโค้ดที่สามารถค้นหาได้, บริการ LSP, ฐานข้อมูลเวกเตอร์…

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

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

แล้วเราจะหลีกเลี่ยงสิ่งนี้ได้อย่างไร?

เราควรทำงานร่วมกับเอเจนต์อย่างไร (อย่างน้อยในขณะนี้)

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

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

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

ตัวอย่างเช่น ใช้วิธี auto-research ที่เสนอโดย Andrej Karpathy เพื่อปรับปรุงเวลาในการเริ่มแอปพลิเคชัน? ดีมาก แต่เงื่อนไขคือคุณต้องรู้ว่ามันสร้างโค้ดที่ไม่มีความสามารถในการใช้งานในผลิตภัณฑ์จริง auto-research มีประสิทธิภาพเพราะคุณได้ให้ฟังก์ชันการประเมินให้มันสามารถปรับปรุงตามตัวชี้วัดบางอย่าง (เช่น เวลาในการเริ่มต้นหรือการสูญเสีย) แต่ฟังก์ชันการประเมินนี้ครอบคลุมเพียงมิติที่แคบมาก เอเจนต์จะไม่สนใจตัวชี้วัดทั้งหมดที่ไม่อยู่ในฟังก์ชันการประเมิน เช่น คุณภาพโค้ด ความซับซ้อนของระบบ หรือแม้แต่ในบางกรณีความถูกต้อง—ถ้าฟังก์ชันการประเมินของคุณมีปัญหา

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

แต่สิ่งที่ฉันต้องการเน้นคือ: ถึงเวลาแล้วที่คุณต้องชะลอความเร็วลง

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

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

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

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

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

ทั้งหมดนี้ต้องการวินัย ทั้งหมดนี้ต้องการมนุษย์

[ลิงก์ต้นฉบับ]

คลิกที่นี่เพื่อเรียนรู้เกี่ยวกับตำแหน่งที่เปิดรับสมัครของ BlockBeats

ยินดีต้อนรับสู่ชุมชนทางการของ BlockBeats:

กลุ่ม Telegram สมัครสมาชิก: https://t.me/theblockbeats

กลุ่ม Telegram สนทนา: https://t.me/BlockBeats_App

บัญชี Twitter อย่างเป็นทางการ: https://twitter.com/BlockBeatsAsia