ตอนนี้เอเจนต์เป็นคนเขียนโค้ด นี่คือหน้าตาใหม่ของงานนักพัฒนา

คำถามนี้โผล่ขึ้นมาบนโต๊ะอาหารทุกบ้านที่มีนักพัฒนาอยู่ในครอบครัว ถ้าเครื่องเขียนโค้ดเองได้แล้ว ยังเหลืออะไรให้คุณทำ

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

ส่วนที่ถูกทำให้เป็นอัตโนมัติไม่เคยเป็นงานทั้งหมด

ทุกอย่างที่ถูกปล่อยออกไปใช้จริงต้องผ่านข้อต่อหกข้อ:

1. มีคนอยากได้อะไรสักอย่าง แล้วพูดมันออกมาได้ไม่ดีนัก
2. มีคนตัดสินว่ามันคุ้มที่จะทำ และคุ้มตอนไหน
3. มีคนแปลงมันเป็นคำอธิบายที่ละเอียดพอจะลงมือทำได้
4. มีคนสร้างมันขึ้นมา
5. มีคนตรวจว่ามันไม่ได้ทำอย่างอื่นพัง
6. มีคนปล่อยมันออกไปแล้วบอกคนที่เป็นคนขอ

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

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

ข้อต่อหนึ่งข้อยุบลง อีกห้าข้อที่เหลือต้องแบกน้ำหนักที่ข้อนั้นเคยบังเอาไว้

นั่นคือเรื่องทั้งหมด และส่วนที่เหลือของบทความนี้คือหน้าตาของทั้งห้าข้อ ตอนที่คุณต้องลงมือทำมันเองจริง ๆ ทุกวัน

ข้อต่อที่ 1: การรับฟังว่าต้องสร้างอะไร โดยไม่ทำหล่นหายไปครึ่งหนึ่ง

โหมดความล้มเหลวแบบใหม่นั้นชัดเจนและแพง คุณสร้างอะไรก็ได้ คุณจึงสร้างของผิดได้เร็วขึ้น

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

สองอย่างต้องเกิดขึ้น และมันเป็นคนละอย่างกัน

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

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

ผลลัพธ์ของข้อต่อนี้ไม่ใช่แบ็กล็อก แต่คือคลังข้อความที่คุณอ่านได้

ข้อต่อที่ 2: การตัดสินใจ ซึ่งตอนนี้คือทรัพยากรที่หายาก

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

สองท่าที่สำคัญอยู่ตรงนี้

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

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

ข้อต่อที่ 3: การเขียนบรีฟ ฝีมือที่เข้ามาแทนการพิมพ์

นี่คือจุดที่ทักษะจริง ๆ ย้ายไปอยู่

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

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

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

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

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

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

สามอย่างแรกต้องจ่ายใหม่ทุกครั้งที่มีงานใหม่ ส่วนอย่างที่สี่จ่ายครั้งเดียวแล้วเก็บเกี่ยวได้ตลอดไป

ข้อต่อที่ 4: การคุมงาน บนเครื่องที่ถูกตัว

เอเจนต์ตัวเดียวคือเครื่องมือ เอเจนต์หลายตัวคือระบบ และระบบต้องมีคนคุม

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

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

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

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

ข้อต่อที่ 5: การรีวิว จุดที่ความรับผิดชอบอาศัยอยู่

นี่คือข้อต่อที่มอบหมายต่อไม่ได้ และเหตุผลไม่ใช่เรื่องเทคนิค

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

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

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

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

เราเขียนไว้ทั้งบทความแล้วว่าควรลงแรงตรวจตรงไหน ควรรีวิวโค้ดที่เอเจนต์ AI เขียนหรือไม่

ข้อต่อที่ 6: การปล่อยออกไปใช้จริง และการปิดวงกลับ

การปล่อยงานออกไปคือครึ่งที่ง่ายของข้อต่อนี้ ครึ่งที่มักถูกข้ามคือการบอกคนที่เป็นคนขอ

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

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

โซ่ปิดครบวง นั่นคือสิ่งที่ทำให้มันเป็นอาชีพ ไม่ใช่คิวงาน

สิ่งที่หดลงจริง และสิ่งที่โตขึ้นจริง

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

AgentsRoom อยู่ตรงไหนในเรื่องทั้งหมดนี้

เราสร้างเครื่องมือที่ถือโซ่ทั้งเส้นเอาไว้ด้วยกัน เพราะทางเลือกอีกทางคือเครื่องมือหกตัวที่ไม่รู้จักกันเลย

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

ชิ้นส่วนแต่ละชิ้นมีอยู่ที่อื่นอยู่แล้ว สิ่งที่ไม่มีใครส่งมอบคือรอยต่อระหว่างชิ้นส่วนเหล่านั้น และรอยต่อคือจุดที่งานรั่วออกไป

คำถามที่คนถามกันจริง ๆ

AI จะแทนที่นักพัฒนาซอฟต์แวร์หรือไม่?

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

นักพัฒนาทำอะไรจริง ๆ เมื่อเอเจนต์เป็นคนเขียนโค้ด?

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

ยังต้องเขียนโค้ดเป็นอยู่หรือไม่?

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

อะไรพังเป็นอย่างแรกเมื่อยกงานเขียนโค้ดให้เอเจนต์?

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

ทักษะที่ยากที่สุดในวิธีทำงานแบบใหม่นี้คืออะไร?

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

ควรรันเอเจนต์เขียนโค้ดบนเครื่องตัวเองหรือบนเครื่องระยะไกล?

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

สรุปสั้น ๆ

งานไม่ได้หายไปไหน มันแค่ย้ายออกจากเอดิเตอร์ไปอยู่ในโซ่ที่ล้อมรอบเอดิเตอร์อยู่

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