ในเดือนกุมภาพันธ์ 2025 Andrej Karpathy ได้อธิบาย "vibe coding" ว่าเป็นการฝึกที่อธิบายความตั้งใจด้วยภาษาธรรมชาติ ยอมรับการเปลี่ยนแปลงของ LLM โดยตรวจสอบน้อยที่สุด และปล่อยให้โค้ดเติบโตเกินกว่าความเข้าใจปกติของคุณ ซึ่งให้ความเร็วที่น่าประทับใจสำหรับโปรเจกต์ส่วนตัวและต้นแบบ
หนึ่งปีต่อมา เขาสังเกตว่าความสามารถของเอเจนต์พัฒนาไปมาก และเสนอ "agentic engineering" เป็นชื่อที่เขาชอบสำหรับแนวทางที่พัฒนาขึ้นในการจัดระเบียบเอเจนต์ในขณะที่ยังคงการควบคุมของมนุษย์อย่างเข้มงวดต่อสถาปัตยกรรมและกระบวนการ เป้าหมายตามที่เขากำหนดคือการได้รับประโยชน์จากเอเจนต์โดยไม่ลดทอนคุณภาพของซอฟต์แวร์
ความแตกต่างนี้สำคัญ Vibe coding ทำงานได้ดีสำหรับผู้ใช้คนเดียวในงานส่วนตัวที่มีความเสี่ยงต่ำ แต่มันสะสมหนี้ทางเทคนิคที่ซ่อนอยู่ ช่องโหว่ด้านความปลอดภัย และปัญหาการบำรุงรักษาอย่างรวดเร็วทันทีที่มีคนอื่นต้องพึ่งพาผลลัพธ์ Agentic engineering รักษาความเร็วและประโยชน์ของเอเจนต์สมัยใหม่ แต่ยึดทุกอย่างไว้ในโครงสร้างที่ชัดเจน สิ่งประดิษฐ์ที่สามารถตรวจสอบย้อนกลับได้ และความรับผิดชอบของมนุษย์
ขั้นตอนการทำงานของ Agentic Engineering
เริ่มต้นด้วยความตั้งใจคร่าวๆ และสนทนาออกแบบกับ AI ในขณะที่บันทึกฟังก์ชันการทำงานลงในบันทึกการประชุมออกแบบที่อธิบายฟังก์ชันการทำงานออกเป็นส่วนประกอบย่อย เมื่อการออกแบบดูมั่นคงแล้ว ให้จับภาพมุมมองระดับสูงและแผนที่ส่วนประกอบในลำดับชั้นการออกแบบ (นี่คือสิ่งที่ผู้คนแสดงเมื่อพวกเขาแสดง "สมอง" ใน Obsidian) ซึ่งเป็นโครงสร้างที่สามารถนำทางได้ที่ให้ทั้งคุณและเอเจนต์เข้าถึงบริบทโดยรอบ การตัดสินใจที่เกี่ยวข้อง และการพึ่งพาได้อย่างสะดวก นอกจากนี้ยังเป็นที่ที่ไดอะแกรมการออกแบบอยู่ เช่น UML (Universal Model Language) โค้ดหรือโฟลว์การโต้ตอบของผู้ใช้ พร้อมกับลิงก์ไปยังบันทึกการตัดสินใจทางสถาปัตยกรรม (ADR) เพื่อชี้แจงว่าส่วนประกอบเกี่ยวข้องกันอย่างไร
สำหรับแต่ละโมดูลหรือบล็อกฟังก์ชันที่เล็กที่สุด ให้สร้าง spec.md ที่เจาะจงภายใน LLD ซึ่งกำหนดพฤติกรรมที่แม่นยำ ลายเซ็นของฟังก์ชัน กรณีขอบ ความคาดหวังในการทดสอบ และจุดเชื่อมต่อ ใช้โครงสร้างทั้งหมดเป็นพรอมต์บริบทการออกแบบเพื่อให้ AI สร้างลำดับชั้นแบบตั๋วที่สามารถตรวจสอบย้อนกลับไปยังหน้า wiki และ spec ได้โดยตรง ดำเนินการทีละตั๋วโดยให้เอเจนต์ปฏิบัติตาม spec.md ที่เกี่ยวข้องเป็นสัญญา จากนั้นคุณรันเกตการตรวจสอบ ปรับใช้ สังเกต และอัปเดตสิ่งประดิษฐ์ที่มีชีวิตเมื่อข้อกำหนดพัฒนาไป
ตัวอย่างจริง: ตัวตรวจสอบการสำรองข้อมูลรายวัน
พิจารณาเครื่องมือ CLI ระดับการผลิตขนาดเล็กที่ตรวจสอบการสำรองข้อมูล S3 รายวันและส่งการแจ้งเตือน Slack เมื่อเกิดความล้มเหลว
เริ่มต้นด้วยเป้าหมายคร่าวๆ: "ฉันต้องการสิ่งที่เชื่อถือได้ที่ตรวจสอบว่าการสำรองข้อมูลของฉันสมบูรณ์ทุกวัน" จากนั้นสนทนาทางสถาปัตยกรรมกับ AI เพื่อเปิดเผยข้อกำหนดและกรณีขอบ:
- อะไรคือโหมดความล้มเหลวที่สมจริงสำหรับการสำรองข้อมูล S3 ในทางปฏิบัติ?
- เราควรตรวจสอบอะไรกันแน่ (อายุ จำนวนไฟล์ ขนาด อัตราความสำเร็จ) และเกณฑ์ใดที่เหมาะสม?
- ควรจัดการการกำหนดค่าและความลับอย่างไรในการพัฒนาท้องถิ่นและบทบาท IAM ในการผลิต?
- คำสั่ง CLI และรูปแบบผลลัพธ์ใดที่จะมีประโยชน์ในชีวิตประจำวัน?
- ข้อกำหนดที่ไม่ใช่เชิงฟังก์ชันใดสำคัญที่สุดสำหรับเครื่องมือที่ทำงานตามกำหนดการรายวัน?
การสนทนาเหล่านี้ทำให้ขอบเขตชัดเจนและช่วยแยกเครื่องมือออกเป็นส่วนประกอบหลัก: การดึงข้อมูลเมตา S3 ด้วยลอจิกลองใหม่, เอ็นจินกฎการตรวจสอบ, ระบบแจ้งเตือน, ตัวโหลดการกำหนดค่า, อินเทอร์เฟซ CLI, การบันทึกที่มีโครงสร้าง และการจัดการข้อผิดพลาด
เมื่อการออกแบบชัดเจน คุณจะบันทึกมุมมองระดับสูงและแผนที่ส่วนประกอบใน wiki ลำดับชั้นการออกแบบ โดยทุกเพจจะมีเวอร์ชันและสามารถลิงก์ได้
wiki ให้บริบทรอบข้างแก่ผู้อ่านในอนาคตซึ่งเอกสารแบบเรียบไม่สามารถให้ได้ ในฐานะส่วนหนึ่งของงานออกแบบเดียวกัน คุณสร้าง spec.md ที่เจาะจงในระดับย่อยของ LLD สำหรับแต่ละโมดูล นี่คือสัญญาสำหรับตัวดึงข้อมูลเมตา S3
spec.md นี้คือสัญญาที่คุณส่งให้เอเจนต์ เช่น "ใช้งานตาม spec.md ในไดเรกทอรี s3_client/ ปฏิบัติตามมาตรฐานโปรเจกต์ และรวมการทดสอบที่ครอบคลุม" เมื่อมี wiki และข้อกำหนดของโมดูลพร้อมแล้ว คุณจะพรอมต์ AI ให้สร้างลำดับชั้นตั๋วโดยตรงจากสิ่งเหล่านั้น ทุกรายการสามารถตรวจสอบย้อนกลับไปยังข้อกำหนดเชิงฟังก์ชันและไปยัง spec ที่กำหนดสัญญาของมัน
จากนั้นการดำเนินการดำเนินไปทีละตั๋ว แต่ละอันถูกส่งให้เอเจนต์พร้อมกับ spec.md ที่ตรงกันเป็นสัญญา นี่คือสิ่งที่เกิดขึ้นในทางปฏิบัติ: การรันตามกำหนดการที่ตรวจพบชุดสำรองข้อมูลที่สั้นและส่งการแจ้งเตือน
การรันออกด้วยรหัสที่ไม่ใช่ศูนย์เพื่อให้ cron job สังเกตเห็น และส่งการแจ้งเตือนที่ลงใน Slack
การแจ้งเตือนมีบริบตกฎที่วิศวกรที่ปฏิบัติหน้าที่ต้องการเพื่อดำเนินการ: การตรวจสอบใดล้มเหลว พบอะไร คาดหวังอะไร และชุดสำรองข้อมูลใด
ประโยชน์ของแนวทางแบบชั้นนี้
- เอเจนต์จัดการปริมาณการดำเนินการในขณะที่มนุษย์เป็นเจ้าของสถาปัตยกรรมและคุณภาพในทุกชั้น
- wiki ให้ความสามารถในการค้นพบและการตัดสินใจในระดับโปรเจกต์ ในขณะที่ไฟล์ spec.md ให้สัญญาระดับโมดูลที่แม่นยำโดยไม่ทำให้การออกแบบระดับสูงบวม
- ข้อกำหนดและการตัดสินใจไหลโดยตรงจากหน้า wiki และ spec ไปยังตั๋วและโค้ด
- การเปลี่ยนแปลงเริ่มต้นจากสิ่งประดิษฐ์การออกแบบที่มีชีวิต แทนที่จะ Reverse Engineer โค้ดเบส
- การแยกความกังวลที่ชัดเจนรองรับการทำงานคู่ขนาน การเริ่มต้นใช้งาน และการตรวจสอบ
- ผู้เชี่ยวชาญรูปตัว T นำทางด้วยความกว้างและตั้งคำถามด้วยความแม่นยำ และเอเจนต์ให้ความลึกตามต้องการโดยไม่บังคับให้ใครต้องจดจำทั้งระบบไว้ในหัว
Vibe coding ยังคงเป็นโหมดที่ยอดเยี่ยมสำหรับการสำรวจและการสร้างต้นแบบส่วนบุคคลที่รวดเร็ว Agentic engineering คือวิธีที่คุณใช้พลังการสนทนาแบบเดียวกันนั้นไปสู่ระบบที่ผู้อื่นสามารถไว้วางใจและบำรุงรักษาได้
บทบาทของผู้เชี่ยวชาญรูปตัว T
ขั้นตอนการทำงานนี้มีประสิทธิภาพโดยเฉพาะสำหรับผู้เชี่ยวชาญรูปตัว T: วิศวกรที่มีความรู้กว้างขวางทั่วทั้งพื้นที่แอปพลิเคชันด้วยความสามารถในการลงลึกเมื่อจำเป็น
เพราะคุณไม่จำเป็นต้องมีแบบจำลองทางจิตที่สมบูรณ์และทันสมัยว่าทั้งแอปพลิเคชันทำงานอย่างไรในทุกขณะ เอเจนต์สามารถแบกรับความลึกนั้นและอธิบายส่วนใดก็ได้ใหม่เมื่อต้องการ ตราบใดที่มันมีบริบทที่ถูกต้องจาก wiki ไฟล์ spec.md และประวัติการสนทนา
สิ่งที่คุณต้องการคือความสามารถในการรู้ว่าควรมองหาอะไรและที่ไหน รวมถึงวินัยในการถามคำถามที่แม่นยำจนกว่าคุณจะเข้าใจรายการเฉพาะที่กำลังทำงาน ส่วนกว้างของตัว T ให้แผนที่ของระบบแก่คุณ เอเจนต์ AI รองรับทักษะที่จำเป็นในการเจาะลึกเข้าไปในโมดูล กรณีขอบ หรือจุดเชื่อมต่อที่สำคัญตรงนั้น เอเจนต์ให้รายละเอียดที่ครบถ้วนทุกครั้งที่คุณถาม
สิ่งนี้เปลี่ยนบทบาทของมนุษย์จาก "ฉันต้องเข้าใจทุกอย่างตลอดเวลา" เป็น "ฉันรู้วิธีนำทาง ตั้งคำถาม และตรวจสอบในระดับความสูงที่เหมาะสม" นั่นคือทักษะที่แท้จริงของ agentic engineering
