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

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

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

การสิ้นสุดของการเขียนโค้ดแบบบรรทัดต่อบรรทัด

เวิร์กโฟลว์แบบเดิมบังคับให้คุณต้องแปลทุกเจตจำนงเป็นภาษาเฉพาะที่คอมไพเลอร์เข้าใจ คุณเก็บความต้องการทางธุรกิจไว้ในหัว จากนั้นจึงแยกย่อยมันออกเป็นฟังก์ชัน, การนำเข้า (imports), การจัดการข้อผิดพลาด (error handling) และกรณีทดสอบ (test cases) ด้วยตัวเอง Intent-Driven Development จะช่วยยุบเลเยอร์การแปลนั้นลง

สมมติว่าคุณต้องการรวม payment webhook ในอดีต คุณจะต้องเขียน route handler, parse payload, ตรวจสอบ signature, อัปเดตฐานข้อมูลภายใน transaction และคิวอีเมลใบเสร็จ แต่ตอนนี้คุณเพียงแค่อธิบายความต้องการว่า: “ตรวจสอบ Stripe webhook ที่ส่งเข้ามา, บันทึกเหตุการณ์แบบ idempotently, และเริ่มขั้นตอนการส่งใบเสร็จ หากการเขียนฐานข้อมูลล้มเหลวให้ rollback” เอเจนต์จะเขียน handler, เลือกกลยุทธ์การ parse, วางโครงสร้าง retry logic และสร้างการทดสอบ บทบาทของคุณจะเปลี่ยนจากผู้เขียน (author) เป็นผู้กำกับ (director)

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

เจาะลึกภายใน Agent Loop

งานหลักไม่ใช่การพิมพ์ของมนุษย์หรือการดีบั๊กด้วยมืออีกต่อไป แต่มันคือวงจรที่กระชับระหว่างการสร้าง (generation) และการตรวจสอบ (validation) เอเจนต์จะสร้างโค้ด รันโค้ดนั้นกับชุดทดสอบ (test suite) ของคุณ อ่านผลลัพธ์ และแก้ไขความล้มเหลวด้วยตัวเอง ไม่ว่าจะเป็นการลืม import, ประเภทข้อมูลไม่ตรงกัน (type mismatch) หรือ assertion ที่ไม่ผ่าน — เอเจนต์จะเห็น stack trace, แก้ไขไฟล์ และรันชุดทดสอบใหม่ คุณไม่ได้อยู่ในลูปนั้น วงจรนี้ดำเนินไปด้วยความเร็วของเครื่องจักร

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

งานที่แท้จริงของคุณ: ผู้ออกแบบข้อกำหนด (Constraint Designer) และผู้ล่า Edge Case

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

อย่างแรก คุณต้องเขียนข้อกำหนด (constraints) เพื่อควบคุมให้เอเจนต์ทำงานอยู่ในเส้นทาง เอเจนต์มีความรู้ที่กว้างขวางแต่ไม่เข้าใจสภาพแวดล้อมเฉพาะของคุณ คุณต้องบอกมันว่า: “ใช้เฉพาะ internal billing API เท่านั้น, ห้าม log raw card tokens โดยเด็ดขาด และรักษา latency ของการตอบกลับให้ต่ำกว่าสองร้อยมิลลิวินาที” ขอบเขตเหล่านี้ไม่ใช่แค่ prompt ที่เขียนทิ้งเขียนขว้าง แต่มันคือข้อกำหนด (specifications) ที่ตัดสินความสำเร็จหรือความล้มเหลว

อย่างที่สอง คุณต้องดักจับกรณี 10% ที่เอเจนต์ล้มเหลว เอเจนต์จัดการเส้นทางปกติได้ดี แต่มันจะสะดุดเมื่อเจอ race conditions ที่ซับซ้อน, edge cases ของตรรกะทางธุรกิจที่คลุมเครือ และสมมติฐานด้านความปลอดภัยที่แฝงอยู่ในข้อมูลที่ใช้เทรน ความเหนือชั้นของคุณมาจากการตรวจพบ race ระหว่าง webhook handler และ cron job สำหรับการคืนเงิน หรือการตระหนักว่า retry logic ที่สร้างขึ้นอาจทำให้เกิดการเรียกเก็บเงินซ้ำ เครื่องจักรแก้ปัญหามาตรฐาน แต่คุณคือผู้ดักจับข้อยกเว้นที่อันตราย

แทนที่การ Code Review ด้วยระบบตรวจสอบ (Verification Harness)

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

ระบบตรวจสอบนี้ตั้งอยู่บนเสาหลักสามประการ

Durable execution. งานของเอเจนต์มักจะรันนานกว่า timeout ของการเรียกใช้งานเพียงครั้งเดียว หากขั้นตอนใดล้มเหลวเนื่องจากปัญหาเครือข่ายชั่วคราว ระบบตรวจสอบจะหยุดพัก, ลองใหม่ และดำเนินการต่อโดยไม่ทำให้สถานะ (state) เสียหาย งานจะดำเนินต่อไปได้แม้จะมีการขัดจังหวะ

Structured outputs. แทนที่จะหวังว่าเอเจนต์จะส่งคืนไฟล์คอนฟิกที่ถูกต้องตามรูปแบบ คุณควรบังคับใช้สัญญา (contract) ไว้ล่วงหน้า เครื่องมืออย่าง JSON Schema จะช่วยตรวจสอบผลลัพธ์ทันที หากเอเจนต์ข้ามฟิลด์ที่จำเป็นหรือใช้ประเภทข้อมูลผิด ระบบตรวจสอบจะปฏิเสธมันก่อนที่โค้ดจะถูกส่งไปยัง repository ของคุณ

Dynamic guardrails. เอเจนต์ไม่ควรมีสิทธิ์อิสระในการอ่านความลับ (secrets) หรือเขียนข้อมูลลงในฐานข้อมูล production ระบบตรวจสอบจะควบคุมสิทธิ์แบบไดนามิก โดยการทำ sandboxing ให้เอเจนต์สามารถเข้าถึงได้เฉพาะฐานข้อมูลทดสอบและ endpoint ภายในที่กำหนดไว้เท่านั้น คุณไม่ได้กำลังรีวิวโค้ดทุกบรรทัด แต่คุณกำลังตรวจสอบรั้วที่ล้อมรอบเอเจนต์อยู่

When the Code Works but the Product Fails

Here is the paradox. The harness catches bad code. It cannot catch bad intent.

If your specification says, “Send a welcome email to every new user,” the agent will write clean, tested code that sends that email. It will not know you meant, “Send the welcome email only if the user verified their address, opted into marketing, and signed up during business hours in their local timezone.” The code is technically flawless and commercially dangerous.

The real risk in Intent-Driven Development is ambiguous specification. Unclear intent produces software that solves the wrong problem with textbook elegance. This is why you must treat your specifications as real assets. Version them. Review them with stakeholders. Validate them against actual workflows before the agent starts building. A prompt scribbled into a chat box is not a specification. It is a liability.

Engineering Judgment Moves Upstream

Engineering judgment is not disappearing. It is migrating to a higher altitude.

You no longer spend mental energy on how to iterate a map or structure a class hierarchy. You spend it on what the system must do under failure, what data it must never expose, and which invariants must hold across distributed services. The craft of coding is becoming the craft of requirements.

This means your specifications need the same rigor you once applied to your code. Name your constraints precisely. Define the failure modes explicitly. State the business rules as clearly as you once declared your types. The agent will handle the implementation. You must guarantee that the implementation is worth building.

Move your quality bar from the pull request to the prompt. Build the harness first. Write the specification second. Then let the machine handle the syntax while you focus on whether the problem is defined correctly and the boundaries are drawn safely.

If you want to explore the ideas behind this shift in more depth, the original discussion on Intent-Driven Development is available here. For ongoing conversations around AI-native engineering, you can also join the GyaanSetu community.