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

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

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

การเปลี่ยนแปลงนิสัย

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

สิ่งนี้ทรงพลัง แต่มันเปลี่ยนปัญหา คำถามไม่ได้มีแค่ "โปรแกรมโมเดลสามารถได้หรือไม่" อีกต่อไป คำถามกลายเป็น:

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

ขั้นตอนการทำงานที่ดีจะมีลักษณะเช่นนี้มากกว่าไม้กายสิทธิ์:

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

พรอมต์ที่ดีเกือบจะเป็นตั๋วที่ดี

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

ข้อความที่เป็นประโยชน์นั้นน่าเบื่อกว่า ตัวอย่างเช่น: ใช้การส่งออก CSV สำหรับหน้าใบแจ้งหนี้ โดยรู้ว่าตารางอยู่ใน app/(dashboard)/invoices/page.tsx ข้อความค้นหาอยู่ใน src/server/invoices.ts และมีรูปแบบที่คล้ายกันอยู่แล้วใน app/(dashboard)/reports

จากนั้นเพิ่มข้อจำกัดที่ชัดเจน: อย่าเปลี่ยนสคีมาฐานข้อมูล อย่าเพิ่มการพึ่งพาหากยูทิลิตี้ขนาดเล็กเพียงพอ คงสไตล์ UI ที่มีอยู่ไว้ และปิดด้วยการยืนยัน: npm test -- invoices และ npm run build

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

สามงานที่ฉันเต็มใจมอบหมาย

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

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

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

สามอาชีพที่มนุษย์เก็บเอาไว้

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

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

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

การตรวจสอบนี้ไม่ใช่ทางเลือก

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

ฉันมักจะดูอย่างน้อยห้าสิ่ง:

1. แพตช์แก้ไขเฉพาะงานที่ร้องขอหรือไม่?
2. เขาสัมผัสไฟล์ที่ไม่เกี่ยวข้องกับมันหรือไม่?
3. การทดสอบครอบคลุมถึงพฤติกรรมใหม่ๆ หรือแค่โอกาสแห่งความสุข?
4. รหัสเป็นไปตามรูปแบบท้องถิ่นหรือไม่
5. มีการจัดการข้อผิดพลาดเช่นเดียวกับส่วนที่เหลือของโครงการหรือไม่

เมื่อมีสิ่งผิดปกติเกิดขึ้น คำติชมจะต้องมีความเฉพาะเจาะจง “ซ่อมมัน” ขี้เกียจ ดีกว่า: ยูทิลิตี้นี้ทำซ้ำ parseMoney ลงใน src/lib/money.ts; ใช้ฟังก์ชันนั้นซ้ำ เพิ่มการทดสอบสำหรับกรณี EUR และไม่เปลี่ยน API สาธารณะของโมดูลการเรียกเก็บเงิน

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

Guardrails คุ้มค่ากับความพยายาม

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

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

จำกัดสิทธิ์ คำสั่งเช่น rg, git diff, npm test และ npm run build นั้นค่อนข้างจะฟรี การปรับใช้ การย้ายฐานข้อมูล การเข้าถึงข้อมูลลับ และคำสั่งทำลายล้างจะต้องชัดเจน

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

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

วิธีง่ายๆ ในการเริ่มต้นเป็นทีม

หากผมแนะนำเจ้าหน้าที่เข้าสู่ทีมเล็กๆ ผมจะเริ่มโดยไม่มีการปฏิวัติครั้งใหญ่

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

หลังจากผ่านไปสองสัปดาห์ ฉันจะดูข้อมูล: งานไหนที่เร็วขึ้นจริงๆ, งานไหนที่รีวิวหนักมาก, ซึ่งการแจ้งเตือนนั้นสร้างความสับสน, ส่วนไหนของโค้ดเบสที่เปราะบางเกินกว่าจะมอบหมายได้

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

ส่วนที่เป็นมนุษย์มากที่สุด

สิ่งที่น่าตลกก็คือ ยิ่งตัวแทนที่เป็นอิสระมากขึ้น ทักษะคลาสสิกก็มีความสำคัญมากขึ้นเท่านั้น: การเขียนตั๋วที่ดี การตัดทอนเล็กๆ การสร้างการทดสอบ การอ่านความแตกต่าง การสื่อสารการแลกเปลี่ยน ตัวแทนเร่งคนที่รู้วิธีทำงานได้ดีอยู่แล้ว ยังขยายความโกลาหลของผู้ที่มอบหมายไม่ดีด้วย

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

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

แหล่งข้อมูลที่เป็นประโยชน์

• Codex สำหรับ (เกือบ) ทุกอย่าง - OpenAI
• ใช้งาน Codex อย่างปลอดภัยที่ OpenAI
• ขอแนะนำ Codex - OpenAI
• มีอะไรใหม่ในตัวแทนการเข้ารหัส GitHub Copilot