ทำไม Replit Agent 4 ถึงกล้าปล่อยให้ทำงานยาวขึ้นโดยไม่ต้องคอยเช็กทุกก้าว

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

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

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

สิ่งที่เปลี่ยนจริงใน Agent 4 เทียบกับรุ่นก่อน

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

อีกจุดที่ต่างชัดคือการตรวจสอบงานตัวเองระหว่างทาง (Self-verification) เดิมทีถ้า Agent เขียนโค้ดผิด ผู้ใช้ต้องเป็นคนเจอบั๊กเองตอนรันแอป แต่ Agent 4 ถูกออกแบบให้พยายามรันโค้ดหรือเทสต์บางส่วนก่อนส่งงานกลับ เพื่อจับข้อผิดพลาดที่เห็นได้ชัด เช่น Syntax ผิด Import ไม่ครบ หรือฟังก์ชันที่เรียกแล้ว Error ทันที ก่อนที่คนจะต้องมาเจอเอง

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

วิธีที่ Agent วางแผนก่อนลงมือเขียนโค้ด

เวลาป้อน Prompt ยาว ๆ เข้าไป Agent 4 มักจะสรุปแผนงานคร่าว ๆ กลับมาให้เห็นก่อนเริ่มเขียนจริง เช่น จะสร้างตารางฐานข้อมูลอะไรบ้าง จะใช้ Framework ฝั่ง Backend และ Frontend แบบไหน และจะแบ่งงานเป็นกี่ช่วง ขั้นตอนนี้สำคัญมากเพราะเป็น 'จุดเดียว' ที่คนควรหยุดอ่านให้ละเอียดก่อนปล่อยให้มันทำงานต่อยาว ๆ

1. อ่านแผนที่ Agent สรุปกลับมาทีละบรรทัด อย่ากดยอมรับผ่าน ๆ เพราะถ้าโครงสร้างฐานข้อมูลหรือ Framework ที่มันเลือกผิดตั้งแต่ต้น การแก้ทีหลังจะเสียเวลากว่าการแก้แผนตอนนี้มาก
2. ถ้าเห็นว่าแผนพลาดจุดสำคัญ เช่น ลืมระบบสิทธิ์ผู้ใช้ (Authentication) ให้แก้ Prompt เพิ่มตรงนั้นก่อนกดให้ทำต่อ ไม่ใช่ปล่อยให้มันเขียนไปก่อนแล้วค่อยแก้ทีหลัง
3. ตั้งขอบเขตงานให้ชัดในรอบแรก เช่น ระบุว่า 'เฉพาะ MVP ที่มีฟีเจอร์ A B C เท่านั้น ยังไม่ต้องทำ D' เพราะ Agent ที่ทำงานยาวต่อเนื่องมีแนวโน้มจะพยายามทำให้ครบทุกอย่างที่ตีความได้จาก Prompt ถ้าคุณไม่กันขอบเขตไว้ก่อน
4. หลังแผนเริ่มลงมือทำจริง ให้ปล่อยเป็นช่วง ๆ แล้วกลับมาดูที่ Checkpoint สำคัญ เช่น หลังสร้างโครงสร้างฐานข้อมูลเสร็จ หรือหลังต่อ API เสร็จ แทนที่จะรอจนจบแล้วค่อยดูทีเดียว

การตรวจงานตัวเองช่วยได้แค่ไหน และช่วยไม่ได้ตรงไหน

การที่ Agent รันเทสต์หรือเช็กโค้ดตัวเองก่อนส่งกลับมา ช่วยจับข้อผิดพลาดระดับ 'โค้ดรันไม่ได้เลย' ได้ดีขึ้นจริง เช่น Import ผิด ฟังก์ชันเรียกชื่อไม่ตรง หรือ Endpoint ที่ลืมต่อกับ Route แต่สิ่งที่มันจับไม่ได้คือข้อผิดพลาดเชิงตรรกะทางธุรกิจ (Business Logic) ที่รันได้แต่ผลลัพธ์ผิด เช่น คำนวณส่วนลดผิดสูตร หรือให้สิทธิ์ผู้ใช้ผิดระดับ

เหตุผลคือ Agent ตรวจสอบจากมุม 'โค้ดทำงานตามที่เขียนไว้ไหม' ไม่ใช่ 'โค้ดทำในสิ่งที่ธุรกิจต้องการจริงไหม' สองอย่างนี้คนละเรื่องกัน โค้ดคำนวณส่วนลด 10% ผิดเป็น 100% ก็ยังรันผ่านได้สบาย ๆ ไม่มี Error ให้เห็น เพราะฉะนั้นขั้นตอนที่คนต้องทำเองเสมอคือทดสอบ Flow สำคัญด้วยมือ โดยเฉพาะจุดที่เกี่ยวกับเงินหรือสิทธิ์การเข้าถึงข้อมูล

อีกจุดที่ควรรู้ไว้คือการตรวจสอบตัวเองของ Agent ไม่เท่ากับ Security Review Agent อาจเขียนโค้ดที่รันได้และผ่านเทสต์พื้นฐาน แต่ยังมีช่องโหว่ เช่น เก็บ Secret ไว้ใน Client-side Code หรือไม่มีการตรวจสิทธิ์ก่อนเข้าถึง API บาง Endpoint เรื่องนี้จะพูดถึงลึกกว่านี้ในบทความเรื่อง ความเสี่ยงด้าน Security ของการเขียนโค้ดด้วย Prompt

ตัวอย่างสมมติ: สร้างระบบจองคิวจาก Prompt เดียว

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

เหมาะกับใคร และเหมาะกับงานแบบไหนจริง ๆ

Agent 4 เหมาะมากกับช่วง Prototype หรือ MVP ที่ต้องการเห็นภาพแอปทำงานได้เร็ว โดยเฉพาะทีมเล็กที่ไม่มี Developer ประจำครบทุกตำแหน่ง หรือ Developer ที่อยากลัดขั้นตอนงาน Boilerplate ซ้ำ ๆ เช่น สร้างฟอร์ม CRUD พื้นฐาน ต่อฐานข้อมูลเบื้องต้น หรือวางโครง Layout เริ่มต้น

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

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

เทียบรุ่นต่อรุ่น: อะไรที่ไม่ควรคาดหวังเกินจริง

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

อีกเรื่องที่ควรรู้คือ Agent ยังตัดสินใจเลือก Library หรือแนวทางออกแบบตามรูปแบบที่พบบ่อยในข้อมูลที่มันเรียนรู้มา ไม่ใช่ตามบริบทเฉพาะของธุรกิจคุณเสมอไป เช่น อาจเลือก Library จัดการ State ที่ 'ใช้กันทั่วไป' แต่ไม่เหมาะกับทีมที่คุ้นเคยกับแนวทางอื่นอยู่แล้ว ตรงนี้ต้องให้ Prompt ที่ระบุข้อจำกัดของทีมชัดตั้งแต่ต้น เพื่อลดโอกาสได้โค้ดที่ทำงานได้แต่บำรุงรักษายาก

วางขั้นตอนให้ทีมทำงานร่วมกับ Agent อย่างปลอดภัย

ทีมที่ใช้ Agent 4 อย่างได้ผลจริงมักไม่ปล่อยให้มันทำงานแบบ 'ไม่มีคนดู' ตั้งแต่ต้นจนจบ แต่วางขั้นตอนตรวจสอบเป็นจังหวะ คล้ายกับการรีวิว Pull Request ของ Developer จริงคนหนึ่ง เพียงแต่ Developer คนนั้นทำงานเร็วกว่ามากและต้องการคนคุมทิศทางบ่อยกว่า

1. กำหนดให้ทุก Checkpoint สำคัญ (หลังสร้างฐานข้อมูล, หลังต่อ API, หลังทำ UI หลัก) ต้องมีคนอ่านโค้ด diff ก่อนกดให้ทำต่อ
2. แยก Branch หรือ Environment ทดสอบออกจาก Production เสมอ อย่าให้ Agent แก้โค้ดที่รันอยู่จริงตรง ๆ โดยไม่มีขั้นตอน Review
3. เก็บ Prompt และการตัดสินใจสำคัญไว้เป็นบันทึก เพื่อให้คนอื่นในทีมเข้าใจว่าทำไมโครงสร้างถึงออกมาแบบนี้ ไม่ใช่แค่ 'AI เขียนมาแบบนี้' โดยไม่มีเหตุผลบันทึกไว้
4. ก่อน Deploy จริง ให้ Developer อย่างน้อยหนึ่งคนไล่อ่านโค้ดทั้งระบบรอบสุดท้าย โดยเฉพาะจุดที่เกี่ยวกับสิทธิ์ผู้ใช้ การจัดการ Secret และการจัดการข้อมูลลูกค้า

ใช้แบบนี้แล้วพัง เพราะอะไร

มีรูปแบบความผิดพลาดที่เจอซ้ำ ๆ เวลาทีมเริ่มใช้ Agent 4 แบบไม่ระวัง ลองดูสามแบบนี้ก่อนเริ่มโปรเจกต์จริง:

• ปล่อยให้ทำงานยาวข้ามคืนโดยไม่ตั้ง Checkpoint ระหว่างทาง พอเช้ามาเจอว่ามันตีความ Prompt ผิดตั้งแต่ชั่วโมงแรก ทุกอย่างหลังจากนั้นต้องรื้อใหม่หมด เพราะไม่มีจุดย้อนกลับที่ใกล้ปัญหาพอ
• เขียน Prompt กว้างเกินไปแบบ 'สร้างระบบ E-commerce ที่ครบทุกอย่าง' โดยไม่กำหนดขอบเขต ทำให้ Agent ต้องเดาเองว่าครบแค่ไหนถึงพอ ผลคือได้ระบบที่กว้างแต่ตื้น ไม่มีจุดไหนทำได้ลึกพอใช้งานจริง
• ปล่อยขึ้น Production ทันทีโดยไม่มีใครไล่เช็กเรื่อง Secret และสิทธิ์การเข้าถึง เพราะเข้าใจผิดว่า Self-verification ของ Agent ครอบคลุมเรื่อง Security ด้วย ทั้งที่จริงมันเช็กแค่ว่าโค้ดรันได้ไม่ใช่ว่าโค้ดปลอดภัย

สรุป

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

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

• จุดเปลี่ยนหลักคือวางแผนก่อนเขียนและตรวจงานตัวเองระหว่างทาง ไม่ใช่แค่เขียนโค้ดเก่งขึ้น
• อ่านแผนงานที่ Agent สรุปมาให้ละเอียดก่อนปล่อยให้ทำงานต่อเนื่องยาว ๆ
• Self-verification จับได้แค่โค้ดรันไม่ได้ ไม่ครอบคลุมตรรกะธุรกิจหรือ Security
• ตั้ง Checkpoint ให้ถี่พอ และให้ Developer รีวิวโค้ดรอบสุดท้ายก่อน Deploy จริงเสมอ

คำถามที่พบบ่อย