งานอัตโนมัติยามค่ำคืน: ตอนที่ผมเริ่มปล่อยให้ AI เขียนโค้ดแทนระหว่างที่ผมนอนหลับ
U-PRO Build Journal — ตอนที่ 4
ตอนที่ 3 จบลงด้วยฟีเจอร์ที่สร้างขึ้นเพื่อกลุ่มผู้ใช้ที่ผมไม่ได้วางแผนจะให้ความสำคัญก่อน — ลานซากรถ ไม่ใช่อู่ซ่อมทั่วไป สิ่งที่ผมยังไม่ได้เล่าคือเรื่องที่เกิดขึ้นกับชั่วโมงทำงานของผมเองในช่วงเวลาเดียวกันนั้น ที่ไหนสักแห่งในช่วงนั้น — โดยไม่มีการตัดสินใจครั้งไหนที่ชัดเจนว่าจะทำแบบนี้ — ผมก็เลิกเป็นคนเดียวที่เขียน commit ให้โปรเจกต์นี้
ผมอยากพูดให้แม่นยำว่าเรื่องนี้เกิดขึ้นยังไงจริงๆ เพราะโน้ตที่ผมใช้อ้างอิงตอนนั่งเขียนตอนนี้ พอเอาไปเทียบกับหลักฐานจริงแล้วกลับไม่ตรงกัน โน้ตพวกนั้นเล่าเหมือนเป็นการทำงานข้ามคืนรวด — เริ่มตอนหัวค่ำ จบลงตอนดึกดื่นเข้าเช้ามืด มี commit ยี่สิบกว่าตัวลงในช่วงนั้น แต่พอผมไปดึงประวัติ commit จริงเพื่อให้ตัวเลขถูกต้อง กลับไม่ใช่แบบนั้นเลย commit สุดท้ายที่เป็นฝีมือผมเองในเย็นวันนั้นลงเวลา 19:41 หลังจากนั้นไม่มี commit จากผมอีกเลยตลอดคืน commit ถัดไปที่ขึ้นชื่อผู้เขียนคนละคน — ผู้ช่วย AI ที่ผมเพิ่งเริ่มทำงานด้วย — ไม่ปรากฏจนกระทั่งเลย 5 โมงเช้าไปนิดหน่อย มีสิบสามตัวลงเวลาห่างกันแค่ไม่กี่วินาที ตามด้วยชุดที่สองอีกสิบเจ็ดตัวลงเวลาเลย 10 โมงเช้าไปนิดหน่อย เกาะกลุ่มกันแน่นจนเห็นชัดว่าถูก commit เข้าไปเป็นชุดทีเดียว ไม่ใช่ทีละตัวตามจังหวะที่งานเกิดขึ้นจริง
ส่วนที่ผมมองย้อนกลับไปแล้วรู้สึกขำคือ โน้ตชุดแรกไม่ได้แต่งตัวเลขขึ้นมาเองเลย ตัวเลขในนั้น — commit ที่ลงเวลาประมาณ 22:15 และอีกครั้งประมาณ 03:03 — เป็นเวลาจริงที่มีอยู่ในประวัติ git จริงๆ เพียงแต่บันทึกด้วยนาฬิกาคนละเรือนกับที่แขวนอยู่บนผนังบ้านผม เครื่องที่รัน commit ชุดนั้นตั้งนาฬิการะบบเป็น UTC ไม่ใช่เวลากรุงเทพฯ และระหว่างขั้นตอนที่ดึง log ดิบมาแล้วเอาไปเขียนต่อ ไม่มีใครบวกเจ็ดชั่วโมงกลับเข้าไป อ่านตามตัวอักษรแบบเวลาท้องถิ่น 22:15 ถึง 03:03 ดูเหมือนช่วงทำงานข้ามคืนที่ดราม่ามาก แต่พอแปลงเป็นเขตเวลาที่ผมอยู่จริง มันกลายเป็น 5:15 น. ถึง 10:03 น. — งานก้อนใหญ่ที่โผล่มาตอนช่วงกินข้าวเช้า ไม่ใช่ตอนที่ผมกำลังหลับอย่างที่ชื่อตอนนี้บอกเป็นนัย งานเบื้องหลังนั้นอาจจะเกิดขึ้นข้ามคืนจริงๆ ก็ได้ — ข้อความ commit หลายอันบอกคำว่า "คืนนี้" ตรงๆ — แต่ผมบอกไม่ได้แล้วว่าชั่วโมงไหนตามเวลากรุงเทพฯ ที่งานนั้นเกิดขึ้นจริง โน้ตที่ผมเริ่มต้นด้วยก็บอกไม่ได้เหมือนกัน สิ่งที่หลักฐานบอกได้ชัดเจนคือมี commit สามสิบตัวลงภายใต้ชื่อที่ไม่ใช่ผม ครอบคลุมฟังก์ชันการทำงานราวสิบกว่าชิ้น ก่อนที่ผมจะกลับมาแตะคีย์บอร์ดอีกครั้งในเช้าวันถัดไป
ที่ผมใช้พื้นที่เยอะขนาดนี้ไปกับเรื่อง timestamp แทนที่จะเข้าเรื่องน่าสนใจไปเลย มีเหตุผลที่สำคัญกว่าสำหรับซีรีส์นี้ในตอนต่อๆ ไป: ตัวเลขที่ดูแม่นยำ กับตัวเลขที่ถูกต้องจริงๆ ไม่ใช่สิ่งเดียวกัน และช่องว่างระหว่างสองอย่างนี้อยู่รอดผ่านการเขียนทั้งรอบได้โดยไม่มีใครสังเกตเห็นเลยก็ได้ เรื่องนี้จริงกับรายละเอียดเล็กๆ น้อยๆ อย่าง "เหตุการณ์นี้เกิดตอนกี่โมง" และกลายเป็นว่ามันจริงกับคำกล่าวอ้างที่ใหญ่กว่านั้นมากด้วย — รวมถึง อย่างที่ผมจะเล่าต่อในตอนนี้เอง คำกล่าวอ้างว่างานชิ้นหนึ่งเสร็จจริงหรือเปล่า
commit สามสิบตัวจากอีกคนหนึ่ง หน้าตาเป็นยังไงกันแน่
ขอบเขตของงานก้อนนั้นควรค่าแก่การนั่งคิดสักหน่อย เพราะไม่ใช่เรื่องเล็กที่จะปล่อยมือให้คนอื่นทำ ระหว่าง commit สองตัวที่ผมชี้ได้ว่าเป็นตัวอย่างชัดที่สุด งานที่ทำครอบคลุม: ระบบลืมรหัสผ่านที่ทำให้เจ้าของอู่ไม่ต้องถูกล็อกออกถาวรถ้าทำสิทธิ์เข้าถึงหาย, สิทธิ์ platform-admin สามระดับ, การแก้บั๊ก audit-log ที่ไม่เคยบันทึกตัวตนของคนที่แก้ไขข้อมูลเอาไว้เลย, ช่องทาง import ข้อมูลลูกค้าเดิมจากไฟล์ CSV, ครึ่งแรกที่ใช้งานได้จริงของฟีเจอร์รับซากรถเข้าระบบจากตอนที่ 3, และเอกสารภายในอีกสองฉบับ — คู่มือขั้นตอนทำงานประจำวันกับคู่มืออ้างอิงฟีเจอร์ — ที่ควรจะมีอยู่แล้ว แต่พอเช็คจริงกลับไม่มี
เอกสารสองฉบับหลังนี่แหละคือส่วนที่ผมอยากเล่าจริงๆ ในตอนนี้ เพราะมันไม่ใช่เรื่องว่า AI ทำงานได้เยอะแค่ไหนในครั้งเดียว แต่เป็นเรื่องว่าเกิดอะไรขึ้นเมื่อบันทึกที่เราพึ่งพาให้บอกว่าอะไร "เสร็จแล้ว" กลับผิด และต้องทำอะไรถึงจะจับได้ก่อนที่จะสร้างของเพิ่มทับลงไปบนมัน
เส้นโค้งของความไว้ใจ ไม่ใช่สวิตช์เปิด-ปิด
ก่อนจะเข้าเรื่องสำคัญจริงๆ ของคืนนั้น ผมอยากพูดถึงรูปร่างของการเปลี่ยนผ่านครั้งนี้ก่อน เพราะมันง่ายมากที่จะทำให้เรื่องทั้งหมดแบนราบเหลือแค่โมเมนต์เดียว — "ผมตัดสินใจให้ AI เขียนโค้ดแทนผม" — ทั้งที่ความจริงมันไม่ได้เกิดขึ้นแบบนั้นเลย
มีสัญชาตญาณตามธรรมชาติเวลาเราเห็น AI ทำอะไรที่น่าประทับใจครั้งแรก คือกระโดดไปคิดทันทีว่า "ตอนนี้ปล่อยมือให้มันทำทุกอย่างได้เลย" ผมก็รู้สึกแบบนั้นเหมือนกัน แต่ไม่ได้ทำตามสัญชาตญาณนั้น ซึ่งส่วนใหญ่เป็นเพราะบังเอิญมากกว่าวินัย เพราะงานชุดแรกที่ลงมาภายใต้ชื่อคนอื่นในคืนนั้น ไม่ใช่ฟีเจอร์เดี่ยวๆ ที่จบในตัวเองซึ่งผมจะประเมินแยกได้ — มันคือสิบกว่าเรื่องพร้อมกัน แต่ละเรื่องมีระดับความเสี่ยงต่างกัน ตั้งแต่ช่องทาง import CSV ไปจนถึงการแก้ไขที่แตะเรื่องล็อก/ปลดล็อกบัญชีลูกค้า ไม่มีทางให้ความไว้ใจแบบเหมารวมกับทุกอย่างเท่ากันได้เลย เพราะความเสี่ยงมันไม่เท่ากัน และถ้าทำเหมือนมันเท่ากันหมด ก็จะกลายเป็นว่าหย่อนยานเกินไปกับส่วนที่อันตราย หรือไม่ก็ระแวงเกินจำเป็นกับส่วนที่ปลอดภัย
สิ่งที่เกิดขึ้นจริง มองย้อนกลับไปแล้วมันเหมือนเส้นโค้งมากกว่าสวิตช์ — ความไว้ใจขยายไปตามสัดส่วนว่าคำกล่าวอ้างนั้นตรวจสอบได้ง่ายแค่ไหน และถ้าคำกล่าวอ้างนั้นกลายเป็นเท็จจะเสียหายหนักแค่ไหน การ import CSV จะให้แถวข้อมูลตรงตามที่คาดไว้หรือไม่ก็ได้ — เช็คได้ในสามสิบวินาทีแค่ดูข้อมูลตรงๆ คำกล่าวอ้างว่า "เอกสารนี้สร้างไว้แล้ว" ก็เช็คได้เร็วพอๆ กัน ถ้านึกจะเช็ค ซึ่งนั่นแหละคือนิสัยที่ยังไม่เคยสร้างมาก่อน แล้วคืนนั้นเองที่บังคับให้มันเกิดขึ้น ส่วนคำกล่าวอ้างว่าการแก้ช่องโหว่ความปลอดภัยลงไปถึงฐานข้อมูลที่ใช้งานจริงหรือเปล่า — ซึ่งเป็นเรื่องที่เรื่องเดียวกันนี้จะไปโผล่อีกครั้งในอีกสองตอนข้างหน้า — ต้องใช้ความพยายามจริงจังและตั้งใจถึงจะตรวจสอบได้ถูกต้อง และเป็นคำกล่าวอ้างแบบที่ถ้าข้ามขั้นตอนตรวจสอบไป จะสร้างความเสียหายมากที่สุดพอดี เส้นโค้งนี้ไม่ได้เกี่ยวกับว่าชอบหรือไม่ไว้ใจผู้ช่วยที่ทำงานให้ แต่เกี่ยวกับการปรับความลึกของการตรวจสอบให้เข้ากับต้นทุนความเสียหายถ้าผิด ทุกครั้งไป ไม่ว่ารายงานที่ได้กลับมาจะฟังดูมั่นใจแค่ไหนก็ตาม
คืนที่มันเริ่มต้น ผมยังไม่มีคำพูดจะอธิบายเรื่องพวกนี้เลยด้วยซ้ำ ผมมีกองการ์ดงานที่ต้องทำให้จบ มีผู้ช่วยที่ดูมีเหตุผลว่าน่าจะทำได้มากกว่าที่ผมทำเองในเวลาเท่ากันข้ามคืน และมีกฎข้อหนึ่ง — ยังไม่ใช่นิสัย แค่กฎที่ผมบังเอิญใส่เข้าไป — ที่บอกว่า ก่อนจะบอกผมว่าอะไรเสร็จแล้ว ให้เช็คก่อนว่ามันเสร็จจริงเทียบกับระบบจริง ไม่ใช่เทียบกับสิ่งที่การ์ดเขียนไว้ กฎข้อเดียวนั้นแหละคือเหตุผลทั้งหมดที่ทำให้ตอนที่เหลือของ episode นี้มีเรื่องให้เล่า
เอกสารที่ควรจะมีอยู่แล้ว
ผมติดตามงานของโปรเจกต์นี้ด้วยการ์ด เหมือนที่ผมเดาว่าคนส่วนใหญ่ทำกันเวลาต้องจัดการรายการงานที่ต้องสร้างยาวและเพิ่มขึ้นเรื่อยๆ การ์ดใบหนึ่งสำหรับเอกสารขั้นตอนทำงานประจำวัน มีโน้ตลงวันที่สองสามวันก่อนหน้าเขียนไว้ประมาณว่า "เสร็จแล้ว — สร้างพร้อมกับ README" ตรงไปตรงมา ไม่มีอะไรดูผิดปกติเลย ถ้าผมเปิดดูเองผมคงเชื่อโน้ตนั้นตามตัวอักษรแล้วไปทำการ์ดใบถัดไปเลย
แต่นั่นไม่ใช่สิ่งที่เกิดขึ้น เพราะคำสั่งที่ส่งออกไปคืนนั้นไม่ใช่ "เขียนเอกสารนี้" แต่ใกล้เคียงกับ "เขียนเอกสารนี้ และก่อนจะเขียน ให้เช็คก่อนว่าโน้ตก่อนหน้าจริงไหม" คำตอบที่ได้กลับมามีอะไรบางอย่างที่ผมไม่ได้คาดไว้ นั่นคือโน้ตนั้นผิด ไม่เคยมี commit ไหนที่เพิ่มไฟล์นั้นเข้ามาเลย ไม่มีบน main branch ไม่มีบน working branch ไม่มีที่ไหนในประวัติทั้งหมด มีใครสักคน — ผมเวอร์ชันสองสามวันก่อนหน้า ที่กำลังรีบผ่านรายการการ์ดยาวๆ — ทำเครื่องหมายว่าเสร็จแล้ว เพราะรู้สึกว่าเสร็จแล้ว หรือเพราะร่างไว้ที่ไหนสักแห่งที่ไม่เคยกลายเป็น commit จริง หรือแค่เพราะการ์ดเขียนว่า "เสร็จแล้ว" แล้วไม่มีใครย้อนกลับไปเช็คอีก
เรื่องเดียวกันนี้เกิดขึ้นอีกครั้งในคืนเดียวกัน กับเอกสารฉบับที่สอง — คู่มืออ้างอิงฟีเจอร์ที่ควรอธิบายว่าระบบทำอะไรได้บ้างจริงๆ แยกตาม role รูปแบบเดียวกันเป๊ะ การ์ดอ้างว่ามีร่างแรกอยู่แล้ว โดยอ้างอิงถึงเซสชันรีวิวก่อนหน้าราวกับว่าเซสชันนั้นสร้างไฟล์ที่ commit ไว้จริง แต่ไม่มี ไม่มีไฟล์ ไม่มี commit คำกล่าวอ้างกับความจริงเริ่มเหินห่างจากกันเงียบๆ ที่ไหนสักจุด และไม่มีอะไรในกระบวนการที่จับได้ จนกว่าจะมีใครสั่งชัดเจนให้เช็คก่อนจะเชื่อการ์ด
ผมอยากพูดให้เป็นธรรมว่าอะไรควรได้รับเครดิตจริงๆ ในเรื่องนี้ เพราะมันง่ายมากที่จะเล่าว่า "ผมสร้างระบบที่จับความผิดพลาดของตัวเองได้" ซึ่งก็ไม่ซื่อตรงเท่าไหร่เหมือนกัน สิ่งที่เกิดขึ้นจริงคือคำสั่งที่ผมให้ไปมีขั้นตอนที่ระบุชัดเจน — ตรวจสอบกับโค้ดจริงและประวัติ git จริง อย่าเพิ่งเชื่อสิ่งที่การ์ดเขียนไว้ — และขั้นตอนนั้นแหละคือเหตุผลเดียวที่ทำให้ความคลาดเคลื่อนโผล่ขึ้นมาให้เห็นเลย ถ้าตัดขั้นตอนนั้นออก เอกสารทั้งสองฉบับก็คงถูกทำเครื่องหมายว่า "เสร็จแล้ว" ค้างอยู่แบบนั้นไปเรื่อยๆ ได้เลย เพราะไม่มีอะไรอื่นใน workflow ตอนนั้นที่ถูกออกแบบมาให้สังเกตเห็นเรื่องนี้
การแก้ไขที่ซ่อนอยู่ในการแก้ไข
มีโมเมนต์เล็กๆ ที่ซ่อนอยู่ในงานคืนเดียวกันนั้น ที่ผมคิดว่าสำคัญกว่าความคลาดเคลื่อนที่เป็นพาดหัวเสียอีก เพราะมันดราม่าน้อยกว่าแต่สะท้อนภาพจริงของการสร้างระบบแบบนี้ในชีวิตประจำวันได้มากกว่า
ระหว่างจัดทำคู่มืออ้างอิงฟีเจอร์ ฉบับร่างแรกที่อธิบายสิทธิ์ของ role หนึ่ง — ว่าพนักงานระดับจูเนียร์ควรเห็นหรือแก้ไขอะไรได้บ้าง ไม่ได้บ้าง — เขียนขึ้นจากความจำ ผลที่ได้ผิดในจุดเล็กๆ ที่เจาะจง คือสิทธิ์ที่ควรขึ้นว่า "อนุญาต" กลับถูกเขียนว่า "ไม่เกี่ยวข้อง" แทน เพราะรู้สึกว่าแบบนั้นถูกต้องโดยไม่ได้เปิดไปเช็คจริง ก่อนที่ร่างนั้นจะถูก commit มีการตรวจรอบที่สองย้อนกลับไปดูไฟล์ config จริงที่กำหนดสิทธิ์พวกนั้นไว้ในโค้ด เทียบทีละบรรทัดกับสิ่งที่เพิ่งเขียนไป แล้วแก้จุดที่ไม่ตรงกัน
ไม่มีใครขอให้ตรวจรอบที่สองนั้น ไม่มีคำสั่งไหนบอกว่า "แล้วก็ตรวจงานตัวเองซ้ำอีกทีเทียบกับต้นฉบับความจริงก่อน commit ด้วย" มันเกิดขึ้นเพราะมาตรฐานที่ใช้ — ตรวจสอบกับสิ่งที่จริง ไม่ใช่สิ่งที่รู้สึกว่าจริง — ถูกใช้อย่างสม่ำเสมอ รวมถึงกับงานที่เพิ่งผลิตออกมาในเซสชันเดียวกันนั้นเองด้วย นี่เป็นรายละเอียดเล็กๆ และผมไม่อยากโอ้อวดให้มันกลายเป็นคำกล่าวอ้างที่ใหญ่เกินความเป็นจริง แต่มันคือความต่างระหว่าง "ผู้ช่วยที่ผลิตเอกสารที่ฟังดูน่าเชื่อถือ" กับ "ผู้ช่วยที่จับความผิดพลาดของตัวเองที่ฟังดูน่าเชื่อถือได้ก่อนจะปล่อยออกไป" และความต่างตรงนั้นแหละคือเหตุผลทั้งหมดที่ทำให้ผมยังปล่อยมือให้ทำงานมากขึ้นหลังจากคืนนั้น ไม่ใช่น้อยลง
สิ่งที่ผมเรียนรู้ว่าไว้ใจได้จริง และสิ่งที่ไม่ได้เรียนรู้
ผมอยากพูดให้ชัดเจนถึงรูปร่างที่แท้จริงของบทเรียนนี้ เพราะ "ผมเรียนรู้ที่จะไว้ใจให้ AI เขียนโค้ดแทนระหว่างที่ผมหลับ" เป็นประโยคที่เรียบร้อยกว่าสิ่งที่เกิดขึ้นจริงมาก และความเรียบร้อยไม่เท่ากับความจริง
สิ่งที่ผมเรียนรู้ว่าไว้ใจได้จริงคือเรื่องที่เฉพาะเจาะจงและแคบมาก นั่นคือ เมื่อผมให้คำสั่งชัดเจนให้ตรวจสอบคำกล่าวอ้างเทียบกับสถานะจริงปัจจุบันของโค้ดและประวัติ git จริง — ไม่ใช่เทียบกับสิ่งที่การ์ดเขียนไว้ ไม่ใช่เทียบกับสิ่งที่รู้สึกว่าจำได้ — การตรวจสอบนั้นจะเกิดขึ้นจริง และจะเผยความคลาดเคลื่อนจริงออกมาถ้ามันมีอยู่ นั่นไม่เหมือนกับการไว้ใจผลลัพธ์โดยอัตโนมัติ แต่เป็นการไว้ใจกระบวนการ โดยมีเงื่อนไขว่ากระบวนการนั้นต้องมีการตรวจสอบจริงรวมอยู่ด้วยทุกครั้ง ไม่ใช่แค่ตอนที่ดูน่าสงสัยเท่านั้น
สิ่งที่ผมไม่ได้เรียนรู้ในคืนนั้น และจะยังไม่ได้เรียนรู้อีกพักหนึ่ง คือเกิดอะไรขึ้นเมื่อการตรวจสอบนั้นขาดหายไป — เมื่อรายงานที่ได้กลับมาบอกว่าอะไรเสร็จแล้ว หรือตรวจสอบแล้ว หรือผ่านแล้ว และไม่มีใครคิดจะใส่ขั้นตอน "ไปยืนยันกับหลักฐานจริงก่อน" ไว้ก่อนจะเชื่อมัน นั่นเป็นรูปแบบความล้มเหลวคนละแบบกับที่ตอนนี้พูดถึง และอันตรายกว่าด้วย เพราะคำกล่าวอ้างที่ผิดล้วนๆ จะดูเหมือนกันเป๊ะจากภายนอกกับคำกล่าวอ้างที่ถูกต้องจริง จนกว่าจะมีใครไปเช็ค ผมจะเจอเวอร์ชันที่รุนแรงกว่าของปัญหาเดียวกันนี้อีกครั้งในภายหลัง โดยมีเดิมพันสูงกว่าแค่เอกสารขั้นตอนทำงานที่หายไปมาก — โมเมนต์ที่ผู้ช่วยรายงานผลลัพธ์ที่ประวัติ commit ของมันเองขัดแย้งอยู่เงียบๆ และผมเกือบจะส่งต่อไปโดยไม่ทันสังเกต นั่นเป็นเรื่องของตอนหลังๆ ใน journal นี้ ไม่ใช่ตอนนี้ แต่ปัญหาตรงนี้มีรูปร่างเดียวกันกับตอนนั้น เพียงแต่ตัดตาข่ายนิรภัยออกไป
ตอนนี้ บทเรียนที่ผมได้กลับมาจริงๆ จากสัปดาห์นั้นแคบกว่า และผมคิดว่าคงทนกว่า คำว่า "ไว้ใจ AI ได้" — ความไว้ใจต้องถูกสร้างขึ้นแบบเดียวกับที่สร้างกับผู้ร่วมงานใหม่คนไหนก็ตาม ไม่ว่าจะเป็นมนุษย์หรือไม่ใช่ก็ตาม — ได้มาตามสัดส่วนของหลักฐาน ขยายออกไปอีกนิดทุกครั้งที่หลักฐานนั้นยืนยันได้จริง และไม่เคยสันนิษฐานเอาเองแค่เพราะประโยคที่ได้กลับมาฟังดูมั่นใจ ประโยคที่มั่นใจกับประโยคที่จริง อ่านแล้วเหมือนกันเป๊ะจนกว่าเราจะสร้างนิสัยตรวจสอบขึ้นมา ผมยังสร้างนิสัยนั้นได้ไม่เต็มที่ในตอนนี้ ผมเพิ่งค้นพบโดยบังเอิญว่าผมต้องการมันมากแค่ไหน
นี่คือตอนที่ 4 ของ U-PRO Build Journal ตอนที่ 3 เล่าเรื่องฟีเจอร์แรกที่สร้างขึ้นเพื่อกลุ่มผู้ใช้ที่ผมไม่ได้วางแผนจะให้ความสำคัญก่อน ตอนที่ 5 จะเล่าเรื่องที่เกิดขึ้นเมื่อการตรวจสอบความปลอดภัยอัตโนมัติบอกผมว่าฐานข้อมูลของผมมีช่องโหว่ที่ถูกโจมตีได้จริง — แล้ววันถัดมาก็บอกผมอีกครั้งว่ารอบแรกที่แก้ไปนั้นยังไม่เสร็จจริงด้วยซ้ำ