- ความสามารถของเครื่องมือเขียนโค้ดด้วย AI ในการสร้างผลลัพธ์ได้ทันที นั้นน่าประทับใจ แต่ความสมบูรณ์ของรายละเอียดการติดตั้งและองค์ประกอบของระบบก็ยังไม่เพียงพอ
- กระบวนการพัฒนาได้ หลุดออกจากสมดุลระหว่าง ‘การคิดและการเขียน’ กลายเป็นรูปแบบที่มอบการคิดให้ AI และเขียนโค้ดเพียงขั้นต่ำ
- พฤติกรรมเช่นนี้คล้ายกับ ‘การพนันแบบดึงสล็อตแมชชีน’ และมีลักษณะเหมือนกลไกเสพติดในอุตสาหกรรมเทคโนโลยีโดยรวม
- AI ทำให้การหาแรงบันดาลใจและการนำโค้ดกลับมาใช้ใหม่ทำได้ง่ายขึ้น แต่กลับ พรากความสุขของการเชื่อมโยงอย่างสร้างสรรค์และการแก้ปัญหา ไป
- ท้ายที่สุดแล้ว นักพัฒนาต้องการ การทบทวนตนเองและการฟื้นคืนปฏิสัมพันธ์โดยตรงกับโค้ด มากกว่าประสิทธิภาพ
ประสิทธิภาพผิวเผินและข้อจำกัดของการเขียนโค้ดด้วย AI
- AI สามารถสร้าง ผลลัพธ์โค้ดที่ดูน่าเชื่อถือได้ในทันที แต่ยังขาดความแม่นยำและความสมบูรณ์ของรายละเอียดการติดตั้ง
- แม้ภายนอกจะดูเหมือนโค้ดที่เสร็จสมบูรณ์ แต่ในความเป็นจริงมักมีข้อผิดพลาดหรือส่วนที่ไม่ครบถ้วนอยู่มาก
- บ่อยครั้งที่เพียงแค่ AI ‘ทำท่าเหมือนกำลังประมวลผล’ ก็มีผลลัพธ์ออกมาแล้ว ทำให้ โครงสร้างที่ละขั้นตอนการคิดของนักพัฒนา เกิดขึ้น
- วิธีการเช่นนี้แตกต่างจากการเขียนโค้ดแบบเดิมที่ต้องการ ‘การคิดอย่างลึกซึ้งและการลงมือเขียนอย่างละเอียด’ โดยเปลี่ยนไปเป็น รูปแบบการทำงานที่เน้นผลิตภาพเชิงผิวเผิน
การเขียนโค้ดด้วย AI ในฐานะการพนัน
- การเขียนโค้ดด้วย AI มีโครงสร้างคล้ายกับ ‘การดึงสล็อตแมชชีน’ ที่ทำซ้ำและแสวงหารางวัลในทันที
- ผู้ใช้จะประสบกับ ความคาดหวังแบบนักพนัน ระหว่างกระบวนการป้อนคำสั่งและรอผลลัพธ์
- อุตสาหกรรมเทคโนโลยีโดยรวมได้ทำให้โครงสร้างรางวัลแบบทำซ้ำ เช่น ‘การรีเฟรช’ กลายเป็นเรื่องปกติไปแล้ว และ AI ก็ทำงานในฐานะรูปแบบที่ขยายสิ่งนี้ให้สุดยิ่งขึ้น
- ความเสพติดเช่นนี้ทำให้การเขียนโค้ดด้วย AI ไม่ได้เป็นเพียงเครื่องมือที่มีประสิทธิภาพ แต่ยังทำหน้าที่เป็น กลไกที่ก่อให้เกิดการพึ่งพาทางจิตวิทยา
การสูญเสียความคิดสร้างสรรค์และความพึงพอใจ
- นักพัฒนาแบ่งงานออกเป็น ‘งานที่ดีต่อจิตวิญญาณ’ และ ‘งานที่ไม่ใช่’ และโดยดั้งเดิมแล้วการเขียนโค้ดจัดอยู่ในประเภทแรก
- AI มอบแหล่งอ้างอิงและแรงบันดาลใจได้อย่างไร้ขีดจำกัด แต่กลับ พรากความสนุกจากกระบวนการแก้ปัญหาด้วยตนเองและการทำความเข้าใจโครงสร้าง ไป
- ผลลัพธ์คือ นักพัฒนาถูกลดบทบาทให้เป็นเพียง ผู้คอยเติมเต็มการเชื่อมโยงที่ไม่สมบูรณ์ซึ่ง AI สร้างขึ้น และความพึงพอใจจากงานก็ลดลง
- การแก้ปัญหานี้ขึ้นอยู่กับ การเปลี่ยนทัศนคติของนักพัฒนาและการมีส่วนร่วมกับโค้ดอย่างกระตือรือร้น
บริบทส่วนตัวและอัตลักษณ์ทางอาชีพ
- ผู้เขียนเป็นนักพัฒนาและนักออกแบบที่ทำงานใน ทีมขนาดเล็กหรือสภาพแวดล้อมการพัฒนาแบบเดี่ยว และคุ้นเคยกับการนำโค้ดกลับมาใช้ใหม่และการปรับให้เหมาะสม
- AI กลายเป็นโอกาสในการลองใช้เฟรมเวิร์กใหม่ ๆ และ ช่วยเพิ่มความมั่นใจ แต่ก็ยังน่าสงสัยว่ามันทำให้กลายเป็นนักพัฒนาที่ดีขึ้นจริงหรือไม่
- โครงเรื่องนี้เป็นการย้อนถามตนเองว่าการใช้ AI นั้นเกิดจากการเพิ่มประสิทธิภาพจริง ๆ หรือเกิดจาก ‘การทำซ้ำแบบนักพนันที่รอแจ็กพอต’ กันแน่
บทสรุป: บทบาทของนักพัฒนาในยุค AI
- การเขียนโค้ดด้วย AI ช่วยเพิ่มผลิตภาพ แต่ก็เสี่ยงที่จะทำให้ ความสามารถในการคิดเชิงสร้างสรรค์และการแก้ปัญหาด้วยตนเอง อ่อนแอลง
- นักพัฒนาไม่ควรพึ่งพาความสะดวกของ AI มากเกินไป แต่ควรฟื้นคืน คุณค่าของกระบวนการคิดและการลงมือจัดการกับโค้ดด้วยตนเอง
- สิ่งที่สำคัญยิ่งกว่าความก้าวหน้าทางเทคโนโลยีคือ การควบคุมตนเองและการทบทวนตนเองเพื่อให้ ‘การเขียนโค้ด’ ยังคงเป็นงานที่ดีต่อจิตวิญญาณ
5 ความคิดเห็น
ถ้าดึงมากพอก็แปลว่าจะมีแจ็กพอตออกมาสินะ
แต่มันสนุกชะมัดเลยใช่ไหมล่ะ ?
ถ้าในเชิงสถิติแล้วมันมีความน่าจะเป็นเกินระดับหนึ่ง มีค่าคาดหวังเป็นบวก และยังมีวิธีเชิงวิศวกรรมที่ออกมาอย่างต่อเนื่องเพื่อเพิ่มค่าคาดหวังให้สูงขึ้น แบบนี้เราควรเรียกมันว่าการพนันจริงหรือ? แต่ดูเหมือนว่าในทางสังคมพวกเราจะตกลงกันแล้วว่าจะเรียกสิ่งนี้ว่า การลงทุน
จ้า รุ่นเก่านี่มาอีกแล้ว
ความเห็นจาก Hacker News
ไม่นานมานี้เพราะเครื่องมือ AI สำหรับเขียนโค้ด เลยตระหนักได้ว่าเหตุผลที่ผมชอบการเขียนโปรแกรมนั้นไม่เหมือนเดิมแล้ว
เมื่อก่อนสิ่งที่สนุกคือ กระบวนการทำความเข้าใจอย่างลึกซึ้งและขุดปัญหาลงไป แต่ตอนนี้สิ่งที่ดึงดูดใจกว่าคือ ความสามารถในการเปลี่ยนสิ่งที่คิดให้กลายเป็นจริงได้ทันที
การมีเครื่องมือที่ตามความเร็วของไอเดียได้แม้ไม่ต้องเขียนโค้ดเองนั้นน่าตื่นเต้นมาก
Claude Code ในตอนนี้จริง ๆ ก็แทบจะเป็นเวอร์ชันที่ยังไม่สมบูรณ์ของสิ่งนั้นอยู่แล้ว เหตุที่เรายังรู้สึกเหมือนกำลังสร้างอะไรด้วยตัวเองก็เพราะว่า กระบวนการยังไม่สมบูรณ์
การที่ไอเดียถูกทำให้เป็นจริงได้ทันทีนั้นเร้าใจมาก แต่สักวันหนึ่งเมื่อคุณสร้างสิ่งที่ต้องการได้อย่างสมบูรณ์แล้ว คุณอาจเจอกับ ความว่างเปล่า
ตอนนั้นอาจเกิดความรู้สึกว่า ‘นี่ไม่ใช่สิ่งที่ฉันสร้างเอง’ และสุดท้ายก็ต้องไปหาไอเดียถัดไป
ถึงอย่างนั้นมันก็ยังเป็นประสบการณ์ที่มีค่า และวันหนึ่งเราอาจมาถึงจุดที่เราไม่ใช่โปรแกรมเมอร์ในความหมายแบบดั้งเดิมอีกต่อไป
สำหรับผมกลับรู้สึกพึงพอใจมากกว่ากับกระบวนการแก้ปัญหาด้วยตัวเอง
ถ้า AI มาแก้ปัญหาแทน ความรู้สึกสำเร็จก็ลดลง เหมือนกับการคัดลอกคำตอบจาก StackOverflow มาแปะ
ถึงอย่างนั้นบริษัทก็คงยังบังคับให้ใช้ AI เพื่อเพิ่มผลิตภาพอยู่ดี
กำแพงในการสร้างแอปที่ซับซ้อนจะต่ำลง และการทำต้นแบบจะง่ายขึ้น
แต่ ระบบเลกาซี หรือโค้ดโปรดักชันก็ยังคงเป็นพื้นที่ของผู้เชี่ยวชาญอยู่ดี
สุดท้ายเวลาระบบล่ม ก็ยังต้องการคนที่เข้าใจโครงสร้างและปฏิสัมพันธ์ของมันอยู่ดี
ถ้า AI coding คือการพนัน การทำ project managing ที่ต้องดูแลนักพัฒนาหลายคนก็อาจเป็นการพนันอีกรูปแบบหนึ่งได้เหมือนกัน
ทั้งคนและโมเดลต่างก็ ไม่เป็นดีเทอร์มินิสติก ดังนั้นแม้มอบหมายงานเดียวกัน ผลลัพธ์ก็ออกมาไม่เหมือนกัน
บางคนตื่นมาตอนตีสี่เพื่อเช็กเอเจนต์ หรือถึงขั้นให้ สิทธิ์เข้าถึงบัญชีธนาคาร เลยก็มี
AI เร็วก็จริงแต่คุณภาพต่ำกว่า และเพราะแบบนั้น วงจรรางวัลฉับพลัน จึงทำงานแรงกว่า
เพียงแต่ AI ยังต้องใช้เวลาอีกพอสมควรกว่าจะไปถึงระดับนักพัฒนาชั้นนำได้
เพราะฉะนั้นมันจึงไม่ใช่การพนัน
การสร้างโค้ดด้วย LLM ก่อให้เกิด พฤติกรรมเสพติด ที่มากกว่าแค่ ‘การยอมรับความเสี่ยง’
มันให้ความรู้สึกเหมือน อุปกรณ์ไซเบอร์พังก์ที่รวมสล็อตแมชชีนกับแชตบอตเพื่อนไว้ด้วยกัน
แทนที่จะใช้ความคิดเชิงวิพากษ์ กลับไปโฟกัสที่ ‘ลองรันอีกที’ มากกว่า และถ้าจะหยุดวงจรนั้นก็ต้องใช้ความพยายามอย่างมีสติ
นักพัฒนาโดยเฉลี่ยในญี่ปุ่นยังไม่ได้ใช้ Claude Code กันเป็นกิจวัตร
บริษัทส่งเสริมก็จริง แต่พวกเขายังยึด วิธีเดิม กันอยู่
กลับกลายเป็นว่าด้วยเหตุนี้เราจึงได้เห็น สภาพแวดล้อมที่ยังไม่ถูกกัดกร่อนทางจิตใจ
สำหรับการรวมเข้ากับโค้ดเบสขนาดใหญ่ก็ยังน่ากังวลอยู่
ในมุมบริษัท ROI ยังไม่ชัดเจน แต่ในระดับบุคคลก็จำเป็นต้องเข้าใจศักยภาพของเครื่องมือนี้
โครงสร้างรางวัลแบบแปรผัน ของ AI coding คือสิ่งที่ทำให้มันมีความเป็นการพนัน
ต่อให้ถามคำถามเดิม ผลลัพธ์ก็ยังต่างกันได้ และความต่างนั้นก็สร้าง ภาพลวงตาว่าควบคุมได้
ยิ่งตอบสนองเร็ว สมองก็ยิ่งเสพติดแรงขึ้น
เพราะแม้แต่ในการพนันเองก็มีกรณีที่ต้องรอนานอยู่บ่อย ๆ
ถ้าผลลัพธ์ไม่สม่ำเสมอ เราก็จะยิ่งกดปุ่มนานขึ้น
สุดท้ายสิ่งสำคัญคือการนิยาม สเปก (spec) ให้ชัดเจน และตรวจสอบว่าการนำไปทำจริงตรงตามนั้นหรือไม่
ถ้ามีสเปกที่สมบูรณ์แบบอยู่แล้ว การเขียนโค้ดเองจะเร็วกว่า
มันไม่ค่อยเข้ากับความจริงที่ต้องรับมือการเปลี่ยนแปลงของตลาดและการทดลองแบบวนซ้ำ
อ้างอิงที่เกี่ยวข้อง: Efficient cause, บทความของ Naur
HN ยังแตกเป็นสองฝั่งกับเรื่อง ‘Vibecoding’ อยู่เหมือนเดิม
บางคนยอมรับว่ามันได้ผล แต่การถกเถียงแบบ แบ่งขั้ว ก็ยังเกิดซ้ำ ๆ
ทั้งที่การพูดคุยเรื่อง requirements และประสบการณ์ของนักพัฒนา ซึ่งสำคัญกว่ากลับถูกกลบไป
คำถามที่ว่า “ต้องชนะบ่อยแค่ไหน มันถึงจะไม่ใช่การพนัน?” น่าสนใจดี