AI ทำให้ส่วนที่ง่ายง่ายขึ้น และส่วนที่ยากยิ่งยากขึ้น

• เมื่อเครื่องมือเขียนโค้ดด้วย AI ทำงานที่ง่ายอย่างการเขียนโค้ดให้เป็นอัตโนมัติ ก็เกิดปัญหาเชิงโครงสร้างที่เหลือให้นักพัฒนาทำเพียงงานยากอย่างการสืบค้น การทำความเข้าใจบริบท และการตรวจสอบความถูกต้อง
• ปรากฏการณ์ที่นักพัฒนาพูดว่า "AI ทำให้แทน" ทั้งที่ไม่ได้ทำความเข้าใจผลลัพธ์ของ AI ด้วยตนเอง เป็นสัญญาณอันตรายแบบเดียวกับการคัดลอกแล้ววางจาก StackOverflow ในอดีต
• vibe coding มีประโยชน์กับการทำต้นแบบ แต่ในสภาพแวดล้อม production จริง AI อาจ ไม่ได้ช่วยประหยัดเวลา แต่อาจยิ่งทำให้เสียเวลามากขึ้น
• เมื่อปล่อยงานได้เร็วครั้งหนึ่งเพราะ AI สิ่งนั้นจะกลายเป็น เส้นฐานใหม่ ที่นำไปสู่แรงกดดันให้ต้องเร่งสปรินต์ต่อเนื่องและภาวะหมดไฟในเชิงการจัดการ
• หัวใจสำคัญคือใช้ AI เป็น เครื่องมือสืบค้น ไม่ใช่ผู้ให้คำตอบสำเร็จรูป และ นักพัฒนาต้องยังคงรับผิดชอบโค้ดทั้งหมด

---

ปัญหาของคำว่า "AI ทำให้แทน"

• ในอดีต นักพัฒนาจะอ่านคำตอบใน StackOverflow บทความ หรือ GitHub issue แล้ว ตรวจสอบบริบทด้วยตนเองก่อนสรุปผล
  • ไม่มีใครบอกว่า "Google เขียนโค้ดให้" หรือ "ผลการค้นหาอันดับ 1 ต้องถูกแน่"
• ช่วงหลังเริ่มมีการใช้คำว่า "AI ทำให้แทน"
  • นี่อาจเป็นการพูดเกินกว่าสิ่งที่เกิดขึ้นจริง หรือหมายความว่านักพัฒนาไม่ได้เป็นผู้สรุปผลด้วยตนเอง
  • ทั้งสองกรณีเป็นปัญหา และก่อให้เกิดความกังวลแบบเดียวกับตอนคัดลอกโค้ดจาก StackOverflow มาวาง: เข้าใจโค้ดที่วางลงไปจริงหรือไม่

ข้อจำกัดของ vibe coding

• vibe coding ช่วงแรกอาจสนุก และมีประโยชน์กับ การทำต้นแบบหรือโปรเจกต์ส่วนตัวที่ความเสี่ยงต่ำ
  • แต่ในการทำงานจริง ทุกบรรทัดของโค้ดมีผลตามมา
• ในโปรเจกต์ส่วนตัว มีการขอให้ AI agent เพิ่มเทสต์ในไฟล์หนึ่ง แต่กลับทำให้ ไฟล์จาก 500 บรรทัดเหลือ 100 บรรทัด
  • AI ยืนยันว่าไม่ได้ลบอย่างอื่นออก แล้วต่อมากลับอ้างว่าไฟล์นั้นไม่เคยมีอยู่แต่แรก
  • เมื่อแสดงประวัติ git ให้ดู มันจึงขอโทษและยอมรับว่าควรตรวจสอบการมีอยู่ของไฟล์ก่อน
• กรณีนี้ทำให้เห็นว่าการใช้ AI ไม่ได้ประหยัดเวลา แต่กลับใช้เวลามากกว่าเดิม
  • เวลาที่เสียไปกับการเถียงกับ agent และกู้ไฟล์ กลับนานกว่าการเขียนเทสต์เองโดยตรง
• หากเรื่องเดียวกันเกิดขึ้นในสภาพแวดล้อมอย่างโค้ดเบสด้านเฮลท์แคร์ ผลกระทบอาจรุนแรงมาก
• สิ่งสำคัญคือใช้ AI เป็น เครื่องมือสืบค้น ไม่ใช่ผู้ให้คำตอบสำเร็จรูป และการจะรู้ว่า AI ผิดเมื่อไรนั้นต้องอาศัยการฝึกฝน

โครงสร้างที่ทำให้ส่วนยากยิ่งยากขึ้น

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

ความคาดหวังของสปรินต์และภาวะหมดไฟ

• เมื่อมีครั้งหนึ่งที่ปล่อยงานได้เร็วเพราะความช่วยเหลือจาก AI สิ่งนั้นจะกลายเป็น เส้นฐานใหม่ และทำให้ถูกคาดหวังว่าจะต้องทำได้เร็วเท่าเดิมเสมอ
  • บทสนทนาจะเปลี่ยนจาก "ทำแบบนั้นได้อย่างไร" เป็น "ทำไมถึงทำแบบนั้นไม่ได้ทุกครั้ง"
• นี่ไม่ใช่ปัญหาทางวิศวกรรม แต่เป็น ปัญหาด้านการจัดการ (management)
• วิศวกรที่อ่อนล้าจะมองข้าม edge case ข้ามการทดสอบ และปล่อยบั๊กออกสู่ระบบ
  • เกิด incident มากขึ้น → แรงกดดันมากขึ้น → สปรินต์มากขึ้น เป็น วงจรอุบาทว์
• สำหรับคำกล่าวที่ว่า "AI ทำให้ผลิตภาพเพิ่มขึ้น 10 เท่า" ความจริงอาจเป็นเพียง วิศวกร 0.1x กลายเป็น 1x
  • ในเชิงเทคนิคอาจเพิ่มขึ้น 10 เท่า แต่คำถามสำคัญคือ นี่คือการเพิ่มผลิตภาพจริง หรือเป็นเพียงการเปิดเผยว่าเดิมมีการสืบค้นน้อยแค่ไหน
• ภาวะหมดไฟและการปล่อยโค้ดคุณภาพต่ำออกสู่ระบบจะ หักล้างผลผลิตภาพที่ AI เพิ่มให้

ทักษะแบบซีเนียร์ ความน่าเชื่อถือแบบจูเนียร์

• AI coding agent นั้น มีความสามารถในการเขียนโค้ดระดับซีเนียร์ แต่ควรปฏิบัติต่อความน่าเชื่อถือของผลลัพธ์ในระดับ วิศวกรจูเนียร์
  • โค้ดอาจดูดีและน่าจะทำงานได้ แต่เพราะไม่มีประสบการณ์ จึงต้องตรวจอย่างละเอียดมากขึ้น
• หากจะเปรียบเทียบ AI coding agent ก็เหมือนกับ มีคนที่อ่านเร็วมากเข้ามาร่วมทีมแบบกะทันหัน
  • ช่วยสืบค้นและเขียนโค้ดได้ แต่ไม่ได้เข้าร่วมประชุมที่คุยถึงภูมิหลังและบริบทสำคัญเมื่อสัปดาห์ก่อน

ความสำคัญของความเป็นเจ้าของโค้ด

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

วิธีที่ AI สามารถช่วยในส่วนที่ยากได้

• ตัวอย่างบั๊กใน production: หลังการรีลีสครั้งใหญ่ มีผู้ใช้รายงาน บั๊ก edge case ในการแสดงผลเขตเวลา
  • นักพัฒนาที่รับผิดชอบต้องไปเข้าเรียนในอีก 30 นาที และคนอื่น ๆ ก็เลิกงานกันไปแล้ว
• จึงใช้ AI ช่วยสืบค้น พบว่าเป็นบั๊กจากการเปลี่ยนแปลงล่าสุด และ อธิบายวิธีทำให้เกิดซ้ำได้
  • สาเหตุมาจาก เมธอดที่ deprecated บางตัวถูกนำไปใช้ก่อนเมธอดที่รองรับเขตเวลาแบบปัจจุบัน ทำให้การแปลงเขตเวลาไม่ถูกต้อง
  • ภายใน 15 นาที สามารถสรุปสาเหตุราก แนวทางแก้ และบันทึกการสืบค้นลงใน GitHub issue ได้
• นักพัฒนาที่รับผิดชอบเข้ามาตรวจสอบการแก้ไข แล้วสมาชิกทีมอีกคนจัดการทดสอบและ deploy ต่อจนเสร็จ
  • แก้ปัญหาได้โดยไม่ต้องเร่งด่วนและไม่ต้องทำงานล่วงเวลา
• ประเด็นสำคัญที่กรณีนี้ชี้ให้เห็นคือ โครงสร้างความร่วมมือที่ AI ทำงานซ้ำ ๆ ในส่วนของการสืบค้น ขณะที่มนุษย์เป็นผู้ให้บริบทและตรวจสอบ
• ควรใช้ AI ในทิศทางที่ช่วยเสริม การสืบค้น การตรวจสอบ และความเข้าใจบริบท มิฉะนั้นจะยิ่งตอกย้ำโครงสร้างแบบ งานง่ายยิ่งง่ายขึ้น แต่งานยากยิ่งยากขึ้น

[tested]

> AI ไม่ได้ทำให้การพัฒนาซอฟต์แวร์ยากขึ้น
> ตรงกันข้าม มันกลับเผยให้เห็นส่วนที่ยากจริง ๆ ที่ผู้คนมองข้ามมาตลอด
> ตลอด 15 ปีที่ผ่านมา นักพัฒนาได้ทำ “vibe coding เวอร์ชันมนุษย์” กันอยู่แล้ว — คัดลอกแล้ววางจาก Stack Overflow, รีแฟกเตอร์แบบไม่มีแผน, และทำงานในแนวคิดว่า “ขอแค่รันบนโน้ตบุ๊กฉันได้ก็พอ”
> พอ AI เป็นคนทำสิ่งนั้นขึ้นมา จู่ ๆ ทุกคนก็เริ่มอยากวางแผนและเขียนเทสต์
> ถ้าคุณภาพดีขึ้นแม้จะช้าลง นั่นก็คือความก้าวหน้าที่แท้จริง

[pencil6962]

ในมุมมองของผม นักพัฒนาที่เคยคัดลอกวางก็ยังคงคัดลอกวางแม้จะใช้ LLM
ส่วนนักพัฒนาที่เดิมก็ใส่ใจเรื่องคุณภาพมากอยู่แล้ว ก็ดูเหมือนจะยิ่งใส่ใจมากขึ้น

[GN⁺]

ความคิดเห็นจาก Hacker News

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

• ฉันเคยสร้างเรโทรอีมูเลเตอร์กับแอสเซมเบลอร์ด้วยวิธี vibe coding และได้ผลลัพธ์ที่ดีแม้ใช้พรอมป์ตไม่มาก
  แต่พอลองทำส่วนเฉพาะทางที่เป็นกรรมสิทธิ์ของแอปอุตสาหกรรมที่ฉันเคยสร้างไว้ ต่อให้ใส่พรอมป์ตมากแค่ไหนผลลัพธ์ก็ยังแย่มาก
  บน GitHub มีตัวอย่างอีมูเลเตอร์นับพัน แต่สิ่งที่ฉันพยายามทำกลับไม่มีตัวอย่างเลย
  สรุปง่าย ๆ คือ — บางอย่างง่าย แต่บางอย่างทำไม่ได้เลย

  • ฉันเรียกปัญหาแบบนี้ว่า “ปัญหาที่ถูกแก้ได้ง่ายจนน่าอาย (embarrassingly solved problem)”
    ถ้ามีตัวอย่างเยอะใน GitHub มันก็ย่อมมีอยู่ใน latent space ของ LLM และดึงออกมาใช้ได้เสมอ
    ที่คุณลองทำก็แค่ไม่มีตัวอย่างแบบนั้นเท่านั้นเอง
  • ฉันก็เคยล้มเหลวคล้ายกัน แต่พอแยกปัญหาให้ย่อยลงและอธิบายให้ชัดเจน Gemini ก็ให้โค้ดที่ใช้งานได้ภายในไม่กี่ครั้ง
    เฟรมเวิร์กเฉพาะอุตสาหกรรม จัดการด้วย vibe coding ได้ยาก แต่ถ้าทำให้ปัญหาง่ายลง AI จะช่วยได้เร็วกว่ามาก
  • สุดท้ายพอคุณตระหนักว่า LLM คือ “cargo culting as a service” หรือบริการลอกแบบเชิงพิธีกรรม ข้อจำกัดของมันก็จะชัดเจนขึ้น

• ถ้ายอมรับ vibe coding แบบเต็มตัว คุณอาจได้ผลลัพธ์ที่น่าทึ่ง แต่ หนี้ทางเทคนิค จะพอกพูนมากจนสุดท้ายรู้สึกเหมือนเป็นทาสของเครื่อง
  เมื่อ AI เขียนโค้ดแทนหลายพันบรรทัด การทำความเข้าใจโครงสร้างหรือรีวิวมันจะยากมาก
  สุดท้ายคงมี โค้ดและซอฟต์แวร์ใช้แล้วทิ้ง เพิ่มขึ้น — แอปสำหรับแก้ปัญหาเฉพาะทำได้ง่าย แต่กับ SaaS ที่ยั่งยืนมีความเสี่ยงสูงมาก

• AI เป็นเครื่องมือที่ให้ ผลคูณพลัง (force multiplier) อย่างมหาศาล
  ถ้ารากฐานของโค้ดเบสแย่ AI ก็จะคัดลอกสไตล์นั้นต่อไปเหมือนเดิม
  ในทางกลับกัน ถ้ามี รากฐานที่สะอาดและสม่ำเสมอ AI จะรักษาคุณภาพนั้นไว้และทำงานได้ดีอย่างน่าทึ่ง
  สุดท้ายสิ่งสำคัญคือ รากฐานการออกแบบ (foundation)
  โค้ดเบสส่วนใหญ่บำรุงรักษายากและขยายต่อได้ลำบากอยู่แล้ว ดังนั้น AI แค่ทำให้ปัญหานั้นชัดขึ้น
  เช่นเดียวกับงานสถาปัตยกรรม ถ้าฐานรากอ่อนแอ ไม่ว่าเครื่องมือจะดีแค่ไหนก็มีขีดจำกัด

  • แต่ AI ไม่สามารถเข้าใจโครงสร้างทั้งหมดได้อย่างสมบูรณ์ ดังนั้นเมื่อเวลาผ่านไป แม้แต่โครงสร้างที่ดีก็จะค่อย ๆ พังทลาย
  • ฉันเพิ่งทำ โปรเจ็กต์แบบ AI-native เป็นครั้งแรก โดยส่งข้อกำหนดทั้งหมด บันทึกการประชุม และแบบออกแบบให้ ChatGPT กับ Codex พร้อมทั้งบันทึกกระบวนการทำงานเป็น Markdown
    ทำแบบนี้แล้วนักพัฒนาคนถัดไปก็เข้าใจ บริบท (context) ของโปรเจ็กต์ได้อย่างครบถ้วน
  • ฉันก็มีประสบการณ์คล้ายกัน ตอนแรก Codex แก้ไขแบบลวก ๆ เท่านั้น แต่พอออกแบบรากฐานใหม่ มันก็สร้างโค้ดที่ดีกว่ามาก
    ท้ายที่สุดคุณต้องแก้ abstraction หลัก ให้ถูกก่อน AI ถึงจะทำงานได้เหมาะสม
  • แต่ในโลกจริง แทบไม่มีรากฐานที่สมบูรณ์แบบ
    ข้อกำหนดเปลี่ยนตลอด และก็ต้องมีการประนีประนอมเพื่อประสิทธิภาพ
    สุดท้ายแล้ว เวลาและต้นทุนค่าเสียโอกาส มักมาก่อนคุณภาพ — เพราะมนุษย์ทำตามแผนได้ไม่สมบูรณ์แบบอยู่แล้ว
  • และก็ยังมีคำถามว่า “แล้วรากฐานที่ AI สร้างขึ้นมาจะเป็นอย่างไร?”

• AI ทำให้ส่วนที่น่ารำคาญน่ารำคาญน้อยลง
  แต่การ เถียงกับ LLM เป็นการเสียเวลา
  การเปลี่ยนทีละหน่วยเล็ก ๆ ถ้าเวิร์กก็คอมมิต ถ้าไม่เวิร์กก็ทิ้งแล้วลองใหม่ มีประสิทธิภาพกว่า
  AI ไม่ใช่ของวิเศษ และการ เลือกใช้เครื่องมือให้เหมาะสม สำคัญมาก

  • การไม่ใช้ระบบจัดการเวอร์ชันหรือฟังก์ชัน กู้คืนเวอร์ชันก่อนหน้า ของ IDE เป็นเรื่องโง่
    ถ้าจะเล่นกับเด็กถือปืน ก็ต้องใส่เสื้อเกราะกันกระสุน
  • ถ้าเริ่มเถียงกับ LLM นั่นคือเวลาที่ควร เริ่มใหม่ด้วยพรอมป์ตใหม่
  • บางครั้ง AI ก็สร้างโค้ดทดสอบได้ดี แต่บ่อยครั้งก็ บิดการทดสอบให้ผ่าน
  • ถึงขั้นมีมุกว่า “คนที่เริ่มหาเรื่องก่อนคือ AI”

• มักมีคนพูดว่า “การอ่านโค้ดของคนอื่นยากกว่าการเขียน” ซึ่งสำหรับฉันมันแปลกมาก
  ฟังก์ชันที่ฉันใช้เวลาครึ่งวันในการเขียน กลับใช้เวลาแค่อ่านและรีวิว 10–15 นาทีก็พอ
  การตรวจสอบว่าโค้ดถูกต้องนั้นง่ายกว่าการสร้างมันขึ้นมามาก

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

• กรอบความคิดที่ถูกต้องคือ “AI ทำให้ทุกอย่างง่ายขึ้นก็จริง แต่ตัวมันเองเป็น ทักษะใหม่ และเรียนรู้ได้ยาก”
  ตอนนี้เรายังอยู่ใน ยุค ENIAC ของ AI ซึ่งยังไม่มีแนวคิดเทียบเท่าภาษาระดับสูงหรือระบบปฏิบัติการ
  ต่อไปจะเกิดศาสตร์ที่เรียกว่า context engineering และวิธีการในวันนี้จะดูเป็นของดิบมาก
  ถ้าวางโครงสร้างดีพอ ความสามารถของ AI ก็ดูแทบไร้ขีดจำกัด

  • แต่ผู้คนมักมองเห็นแค่ส่วนที่ง่าย และมองข้าม ต้นทุน
    การบอกว่า “ทำด้วย AI” ในความเป็นจริงก็คือ “ใช้ทรัพยากร CPU ของบริษัทภายนอกในปริมาณมหาศาล”
    จนกว่าฉันจะมี AI agent ที่ฉันเป็นเจ้าของอย่างสมบูรณ์ ฉันยังมองว่านี่ใกล้เคียงกับ การขโมยทรัพยากรระดับดาวเคราะห์ มากกว่าจะเป็นความก้าวหน้าที่แท้จริง

• AI ไม่ได้ทำให้การพัฒนายากขึ้น
  ตรงกันข้าม มันแค่เผยให้เห็น ส่วนที่ยากจริง ๆ ที่ผู้คนมองข้ามมาตลอด
  ตลอด 15 ปีที่ผ่านมา นักพัฒนาก็ทำ “vibe coding แบบมนุษย์” กันอยู่แล้ว — คัดลอกวางจาก Stack Overflow รีแฟกเตอร์แบบไม่มีแผน และทำงานแบบ “ขอแค่รันบนโน้ตบุ๊กฉันได้ก็พอ”
  พอตอนนี้ AI เป็นคนทำบ้าง จู่ ๆ ทุกคนก็อยากวางแผนและเขียนเทสต์กันขึ้นมา
  ถ้าช้าลงแต่ คุณภาพดีขึ้น นั่นก็คือความก้าวหน้าที่แท้จริง

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

• ฉันเคยสั่ง AI ว่า “เพิ่มเทสต์ให้ไฟล์นี้” แล้วไฟล์ 500 บรรทัดกลับเหลือ 100 บรรทัด
  พอถามเหตุผล มันตอบว่า “ไฟล์ต้นฉบับไม่มีอยู่แล้ว”
  พอฉันแสดง git history ให้ดู มันก็ขอโทษและบอกว่า “ควรตรวจสอบการมีอยู่ของไฟล์ก่อน”
  เมื่อวานฉันบอกว่า “ลืมไฟล์นั้นไปซะ” แล้วมันก็ดันลบไฟล์นั้นจริง ๆ

  • กรณีล้มเหลว แบบนี้เป็นเพราะเครื่องมือยังไม่สุกงอม และถ้ามีระบบจัดการเวอร์ชันก็ไม่ใช่ปัญหาใหญ่
    ต้นทุนในการย้อนกลับ เล็กน้อยยังถือว่าคุ้มเมื่อเทียบกับคุณค่าที่ AI มอบให้