จุดตรวจโดยมนุษย์ในการพัฒนา AI ที่ช่วยประหยัดเวลาเป็นวันๆ

ทำไมการทบทวนโดยมนุษย์ 5 นาทีถึงช่วยประหยัดเวลาได้มาก

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

จุดตรวจ (checkpoint) คือการหยุดโดยมนุษย์สั้น ๆ ก่อนยอมรับหรือส่งการเปลี่ยนแปลง มันไม่ใช่การประชุมและไม่ใช่วง QA ยาว ๆ แต่มันคือการสแกน 5 นาทีอย่างตั้งใจที่ถามว่า: ถ้ามันผิด อะไรจะพังที่สุด?

งานทำความสะอาดที่เจ็บปวดส่วนใหญ่มาจากสี่พื้นที่เสี่ยงสูง:

• สคีมา (Data schema): ชนิดผิด ขาดข้อจำกัด ชื่อสับสน ขาดดัชนี
• การพิสูจน์สิทธิและการอนุญาต (Auth and permissions): ผู้ใช้เห็นหรือแก้สิ่งที่ไม่ควรเห็น หรือแอดมินทำงานไม่ได้
• การกระทำที่ทำลายข้อมูล (Destructive actions): ลบ/เขียนทับ/อัปเดตเป็นกลุ่มที่ทำได้ง่ายเกินไป โดยไม่มีการกู้คืน
• การตั้งค่า deployment: env vars ผิด ข้อมูล dev/prod ผสมกัน จัดการความลับไม่ดี การตั้งค่าโดเมนผิด

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

ไม่ว่าคุณจะโค้ดด้วยมือหรือใช้เครื่องมือ vibe-coding เช่น Koder.ai กฎเหมือนกัน: เร็วได้ แต่ใส่ราวกันตกเล็ก ๆ ในที่ที่ความเสียหายมาก

รูทีนจุดตรวจ 5 นาทีแบบง่าย

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

เลือกช่วงเวลาที่จะทริกเกอร์จุดตรวจเสมอ: หลังเสร็จฟีเจอร์, ก่อน deploy, และหลัง refactor ที่แตะข้อมูล, สิทธิ, บิลลิ่ง หรืออะไรที่เกี่ยวข้องกับโปรดักชัน

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

รูทีน

1. อธิบายการเปลี่ยนแปลงในหนึ่งประโยค (ผู้ใช้ทำอะไรได้บ้างตอนนี้)
2. เช็ก blast radius (ข้อมูล บทบาท และสภาพแวดล้อมที่มันแตะ)
3. สแกนขอบเสี่ยง (สคีมา กฎการพิสูจน์สิทธิ การกระทำทำลายข้อมูล การตั้งค่า deploy)
4. รันการทดสอบความเป็นจริงหนึ่งอย่าง (ลำดับที่ง่ายที่สุดที่พิสูจน์ว่ามันทำงาน)
5. ตัดสินใจ: ดำเนินการต่อ ปรับ prompt แล้วสร้างใหม่ หรือ rollback

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

เทมเพลตเล็ก ๆ ช่วยให้คุณสม่ำเสมอ:

Change:
Risky areas touched:
1 quick test to run:
Decision (proceed / adjust prompt / rollback):

ถ้าคุณกำลังสร้างใน Koder.ai ให้ทำให้ขั้นตอนสุดท้ายทำได้ง่ายโดยตั้งใจ Snapshot และ rollback จะแปลง "ฉันไม่แน่ใจ" ให้เป็นการตัดสินใจที่ปลอดภัย

ความสมเหตุสมผลของสคีมา: จับปัญหาข้อมูลให้เร็ว

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

เริ่มด้วยการตรวจว่าหน่วยแกนหลักตรงกับโลกจริงหรือไม่ CRM ง่าย ๆ มักต้องการ Customers, Contacts, Deals, และ Notes หากคุณเห็นชื่อคลุมเครือเช่น "ClientItem" หรือ "Record" แสดงว่าคุณเริ่มเบี้ยวแล้ว

การสแกนสคีมา 5 นาที:

• ชื่อตรงกับความเป็นจริง: ตารางแสดงสิ่งที่คุณพูดถึงจริง ๆ (users, invoices, subscriptions)
• ชื่ออ่านได้และสม่ำเสมอ: เลือกสไตล์หนึ่งแล้วยึดไว้ (created_at vs createdAt)
• ความสัมพันธ์ครบถ้วน: one-to-many ที่ควรเป็น และ many-to-many เมื่อบทบาทหรือการเป็นสมาชิกมีความหมาย
• ข้อจำกัดตั้งใจใช้: ฟิลด์ที่ต้องมีไม่ควรเป็น nullable, หลีกการซ้ำที่สร้างปัญหา (email, invoice_number), ฟิลด์สถานะมีชุดค่าที่รู้จัก
• การเติบโตไม่ทำให้แอปพัง: การค้นหาทั่วไปมีดัชนี และคุณไม่เก็บบล็อบขนาดใหญ่ในที่ผิด

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

ถ้าจะถามคำถามเดียว ให้เป็นคำถามนี้: คุณอธิบายสคีมาให้เพื่อนร่วมทีมใหม่ฟังได้ในสองนาทีไหม? ถ้าไม่ได้ ให้ปรับก่อนสร้างต่อ

กฎการพิสูจน์สิทธิ: ใครทำอะไรได้บ้าง (และตรวจอย่างไร)

บักด้าน auth แพงเพราะเดโมทางบวกปิดบังพวกมัน ความล้มเหลวสองอย่างที่พบบ่อยคือ "ทุกคนทำได้ทุกอย่าง" และ "ไม่มีใครทำอะไรได้เลย"

เขียนบทบาทด้วยคำง่าย ๆ: admin, staff, customer หากแอปมีทีม ให้เพิ่ม workspace member และ workspace owner ถ้าคุณอธิบายบทบาทไม่เป็นประโยคเดียว กฎจะกระจาย

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

เพื่อยืนยันอย่างรวดเร็ว ให้ใช้ตารางการเข้าถึงเล็ก ๆ และทดลองจริงใน UI และ API:

• สำหรับแต่ละบทบาท ยืนยัน create/read/update/delete บนวัตถุหลัก
• ตรวจสอบการเป็นเจ้าของ: ผู้ใช้ควรเห็นเฉพาะข้อมูลของตัวเอง เว้นแต่มีการแชร์อย่างชัดเจน
• ลองเดา: เปิดไอเท็มของผู้ใช้อื่นโดยเปลี่ยน ID
• ยืนยันการกระทำเฉพาะแอดมินจริง ๆ ว่าเป็นเฉพาะแอดมิน (บิลลิ่ง, export, จัดการผู้ใช้)
• อย่าพลาดการเข้าถึง "ที่ซ่อน" เช่น endpoints รายการ การค้นหา การดาวน์โหลด

การเช็กการเป็นเจ้าของต้องให้ความสนใจเป็นพิเศษ: "User can read Task" ยังไม่พอ ควรเป็น "user can read Task where task.ownerId == user.id" (หรือผู้ใช้เป็นสมาชิก workspace)

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

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

การกระทำที่ทำลายข้อมูล: ป้องกันการสูญหายโดยไม่ตั้งใจ

การกระทำที่ทำลายข้อมูลคือเส้นทางเร็วที่สุดจากข้อผิดพลาดเล็ก ๆ ไปสู่การทำความสะอาดเป็นวัน

ก่อนอื่น จดทุกอย่างที่อาจลบหรือเขียนทับข้อมูล มันไม่ใช่แค่ปุ่มลบ มันคือ reset, sync, import/replace, rebuild index, seed actions และเครื่องมือแอดมินแบบกว้าง ๆ

มองหาสัญญาณความปลอดภัยชัดเจน:

• การยืนยันชัดเจน สำหรับการกระทำอันตราย (การพิมพ์ยืนยันดีที่สุด)
• ผลกระทบที่จำกัดขอบเขต (หนึ่งระเบียน หนึ่งผู้ใช้ หนึ่ง workspace) ไม่ใช่ "all" ง่าย ๆ
• ล็อก ว่าใครเป็นคนเรียกใช้งานและอะไรได้รับผลกระทบ
• ดีฟอลต์ที่ปลอดภัย เช่น dry run, preview, หรือ archive แทนการลบ

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

ปฏิบัติต่อการเปลี่ยนสคีมาเป็นการกระทำที่อาจทำลายได้ด้วย การลดคอลัมน์ เปลี่ยนชนิด และเข้มงวดข้อจำกัดสามารถทำให้ข้อมูลหายได้ แม้ไม่มีใครเรียก endpoint ลบ ถ้า AI เสนอ migration ถามว่า: เกิดอะไรขึ้นกับแถวที่มีอยู่ และเรากู้คืนอย่างไร?

ถ้าคุณอธิบายแผนการ rollback ไม่ได้ในประโยคเดียว อย่าส่งการเปลี่ยนแปลงที่ทำลายได้

การตั้งค่า deployment: ข้อผิดพลาดคอนฟิกเล็ก ๆ ที่เจ็บ

เรื่องเล่าการทำความสะอาดส่วนใหญ่เริ่มเหมือนกัน: แอปทำงานใน dev แล้วโปรดักชันพฤติกรรมต่างออกไป

แยก dev และ prod ด้วยเจตนา: ฐานข้อมูล คีย์ บัคเก็ต และผู้ให้บริการอีเมลต่างกัน ถ้าทั้งสองชี้ไปที่ฐานข้อมูลเดียว สคริปต์ทดสอบเดียวอาจปนเปื้อนข้อมูลจริง และ "reset ด่วน" อาจลบทิ้ง

จากนั้นดูที่ความลับ หากเห็นคีย์ในไฟล์คอนฟิก, prompt, หรือ commit ให้ถือว่ามันจะรั่ว ควร inject ความลับในเวลาที่ deploy (env vars หรือ secrets manager) โปรดักชันควรล้มการเริ่มถ้าขาด secret ที่จำเป็น ความล้มแบบนี้ถูกกว่าการ fallback แบบเงียบ

แล้วยืนยันการตั้งค่าที่เห็นในเบราเซอร์: allowed origins (CORS), redirect URLs, OAuth callback URLs เหล่านี้ง่ายที่จะเกือบตรง และนั่นคือสาเหตุที่คุณต้องดีบัก "login พัง" ทั้งที่โค้ดถูกต้อง

การตรวจสอบ deployment 5 นาที:

• Dev และ prod ใช้ฐานข้อมูลและคีย์ต่างกัน
• ความลับถูก inject ไม่ได้ถูก hardcode
• Origins, redirects, และ callbacks ตรงกับโดเมนจริง
• พื้นฐานโดเมนที่กำหนดเองถูกต้อง (DNS ชี้ถูกที่, คาดหวัง HTTPS)
• เปิด logging และการรายงานข้อผิดพลาดในโปรดักชัน (โดยไม่ล็อกข้อมูลอ่อนไหว)

ถ้าคุณ deploy จาก Koder.ai นี่ก็เป็นเวลาที่ดีในการยืนยันว่าคุณ deploy ใน environment ที่ถูกต้องและมี rollback หากมีอะไรผิดปกติ

เช็คลิสต์ก่อน merge 60 วินาที

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

• สคีมา: เอนทิตีสมเหตุสมผลไหม? ความสัมพันธ์ถูกไหม? ข้อจำกัดอยู่ไหม (unique, not null)? การเติบโตจะทำให้การค้นหาหรือพื้นที่เก็บพังไหม?
• Auth: เป็น default-deny ไหม? อธิบายได้ไหมว่าใครสร้าง/อ่าน/แก้/ลบแต่ละทรัพยากร? การเช็กการเป็นเจ้าของถูกบังคับที่ฝั่งเซิร์ฟเวอร์ไหม (ไม่ใช่แค่ UI)?
• การกระทำที่ทำลาย: มีการยืนยันสำหรับการกระทำที่ไม่ย้อนกลับไหม? ใช้ soft delete ที่ควรใช้ไหม? มีแผน rollback (snapshot, backup, migration กลับได้) ไหม?
• Deployment: แยก dev/prod ชัดเจนไหม? ความลับอยู่นอกโค้ดและล็อกไหม? โดเมนและ redirect ถูกต้องไหม?

ตัวอย่างหนึ่ง: คุณ merge ฟีเจอร์ "admin delete user" ใน 60 วินาทีคุณสังเกตว่าไม่มีการเช็กบทบาทที่ฝั่ง backend มีแค่ปุ่ม UI ที่ซ่อนอยู่ ผู้ใช้จริงยังเรียก endpoint ได้โดยตรง จุดจับนี้เดียวช่วยคุณหลีกเลี่ยงเหตุการณ์

จบด้วยคำถามที่บีบให้กลับสู่ความจริง:

อะไรคือสิ่งที่แย่ที่สุดที่ผู้ใช้จริงทำได้ที่นี่ โดยตั้งใจหรือไม่ตั้งใจ?

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

ตัวอย่าง: การทบทวน 5 นาทีที่ป้องกันการทำความสะอาดเป็นสัปดาห์

คุณกำลังสร้าง CRM เล็ก ๆ และขอให้เครื่องมือ AI เพิ่มปุ่ม "Delete customer" บนหน้าลูกค้า ในไม่กี่นาทีมันสร้าง UI, endpoint ฝั่งหลัง และการเปลี่ยนแปลงฐานข้อมูลเพื่อลบระเบียนที่เกี่ยวข้อง

ทุกอย่างดูทำงาน: ปุ่มแสดง ผลตอบกลับ 200 ลูกค้าหายจากรายการ หลายทีมคงไปต่อ

การทบทวน 5 นาทีจับปัญหาได้สองอย่าง:

1. การเปลี่ยนฐานข้อมูลใช้ cascade delete ที่ลบ invoices และ activity logs ด้วย อาจพอใช้กับข้อมูลทดสอบ แต่ใน CRM จริงมันทำลายการรายงาน, การตรวจสอบ และประวัติลูกค้า
2. Endpoint ตรวจแค่ผู้ใช้ลงชื่อเข้าใช้ ไม่มีการเช็กบทบาทแอดมิน พนักงานคนใดก็สามารถลบลูกค้าได้

การทบทวนจริงปฏิบัติ:

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

การปรับ prompt แก้ได้ก่อนส่ง:

"Make delete customer a soft delete. Keep invoices and logs. Only admins can delete. Add a confirmation step that requires typing DELETE. Return a clear error message when unauthorized."

เพื่อไม่ให้มันพังอีก ให้บันทึกสามอย่างในโน้ตโปรเจกต์: กฎการลบ (soft vs hard), ข้อกำหนดสิทธิ (ใครลบได้), และผลข้างเคียงที่คาดไว้ (ข้อมูลที่เกี่ยวข้องคงอยู่หรือไม่)

Prompt ที่บีบให้ชัดก่อนยอมรับการเปลี่ยนแปลง

ผลลัพธ์จาก AI ฟังดูมั่นใจได้แต่ซ่อนสมมติฐาน เป้าหมายคือทำให้สมมติฐานเหล่านั้นเปิดเผย

คำที่ควรกระตุ้นการถามต่อ: “assume”, “default”, “simple”, “should”, “usually” คำเหล่านี้มักหมายถึง "ฉันเลือกบางอย่างโดยไม่ยืนยันว่ามันพอดีกับแอปของคุณ"

รูปแบบ prompt ที่มีประโยชน์:

“Rewrite your proposal as acceptance criteria. Include: required fields, error states, and 5 edge cases. If you made assumptions, list them and ask me to confirm.”

สอง prompt เพิ่มเติมที่เปิดความเสี่ยงได้เร็ว:

• “Show the data model changes as a before/after table. For each field: type, nullability, default, and migration risk.”
• “List all destructive operations you introduced (drop table/column, delete endpoints, cascade rules). For each, show how to undo it and what data is lost.”

สำหรับ auth:

“Show roles and permissions for each API route and UI action. For every role: allowed actions, denied actions, and one example request that should fail.”

ตัดสินใจว่าต้องมีการตรวจโดยมนุษย์เสมออะไรบ้าง แล้วทำให้สั้น:

• กฎ auth และการกระทำของแอดมิน
• การลบ, cascade, มิเกรชันที่ไม่ย้อนกลับ
• การตั้งค่า environment และ deployment (prod vs staging)
• การทำงานเกี่ยวกับการชำระเงิน อีเมล และข้อมูลผู้ใช้
• แผน rollback (snapshot หรือ release point)

ข้อผิดพลาดที่พบบ่อยซึ่งทำให้ต้องทำความสะอาดเป็นวัน

การทำความสะอาดยาว ๆ ส่วนใหญ่เริ่มจากการตัดสินใจเล็ก ๆ เดียว: เชื่อผลลัพธ์เพราะมันทำงานในตอนนี้

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

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

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

การกระทำที่ทำลายข้อมูลทำให้เกิดหายนะที่สุด "Delete project" หรือ "reset database" ทำได้ง่ายแล้วก็เสียใจง่ายถ้าไม่มี soft delete, snapshot, หรือแผน rollback

สาเหตุซ้ำ ๆ ของการแก้เป็นวัน:

• การเปลี่ยนสคีมาโดยไม่มีข้อจำกัด (unique, not null, foreign keys)
• กฎสิทธิที่อยู่แค่ใน UI แทนการเช็กฝั่งเซิร์ฟเวอร์
• Endpoint ลบไม่มีการยืนยันและไม่มีการกู้คืน
• ถือว่า staging และ production "แทบจะเหมือนกัน"
• ไม่มีบันทึกว่าใครเปลี่ยนอะไร

ขั้นตอนต่อไป: ทำให้จุดตรวจเป็นส่วนหนึ่งของวิธีการสร้าง

ทางที่ง่ายที่สุดให้จุดตรวจยึดติดคือผูกมันกับช่วงเวลาที่คุณมีอยู่แล้ว: เริ่มฟีเจอร์, merge, deploy, และยืนยัน

จังหวะน้ำหนักเบา:

• ก่อนสร้าง: ตกลงรูปร่างข้อมูล (ตาราง ฟิลด์สำคัญ) และบทบาท (ใครอ่าน/สร้าง/แก้/ลบ)
• ก่อน merge: ทำการสแกน 60 วินาทีสำหรับ auth, การกระทำที่ทำลาย, และทุกอย่างที่แตะข้อมูลโปรดักชัน
• ก่อน deploy: ยืนยันการตั้งค่าสภาพแวดล้อม (โดเมน, ความลับ, อีเมล, สตอเรจ, ภูมิภาค) ตรงกับเป้าหมาย
• หลัง deploy: รันลำดับผู้ใช้จริงหนึ่งรอบจากต้นจนจบ

ถ้าคุณใช้ Koder.ai โหมดวางแผนสามารถใช้เป็นจุดตรวจ "ก่อนสร้าง": เขียนการตัดสินใจเช่น "orders สามารถสร้างโดยผู้ใช้ที่ลงชื่อเข้าใช้ได้ แต่มีแอดมินเท่านั้นที่เปลี่ยนสถานะ" ก่อนจะสร้างการเปลี่ยนแปลง Snapshot และ rollback ยังช่วยให้คุณมองว่า "ฉันไม่แน่ใจ" เป็นเหตุผลเพียงพอจะย้อนกลับอย่างปลอดภัยแล้วสร้างใหม่ด้วย prompt ที่ชัดเจนกว่า

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