AI กำลังทำให้ฉันโง่ลง
(jpain.io)- การเขียนด้วย AI เป็นสิ่งยั่วยวนอย่างมากในการเขียนบทความ โค้ด และเอกสาร แต่ก็ทำให้ความกังวลเพิ่มขึ้นว่าความสามารถในการเขียนและคิดด้วยตัวเองกำลังลดลง
- เมื่อกลับมาอ่านผลงานที่ AI สร้าง ก็ให้ความรู้สึกว่า “มันก็แค่ดูเป็น AI” และไม่สามารถถ่ายทอดน้ำเสียงหรือเจตนาของตัวเองได้อย่างเหมาะสม
- ตลอด 1~2 ปีที่ผ่านมา ผู้เขียนพึ่งพา AI อย่างมากในการเขียนโค้ด จนแทบจะ เขียนแต่พรอมป์ต์ และความรู้สึกสูญเสียก็เพิ่มขึ้นเรื่อย ๆ ราวกับลืมวิธีเขียนโค้ดด้วยตัวเองไปแล้ว
- ตอนนี้จึงพยายามกลับมาเรียนรู้ การเขียนโค้ดด้วยมือตัวเอง อีกครั้ง และมองว่าแม้หลังยุค AI คนที่อ่านและเขียนโค้ดได้ก็ยังคงจำเป็น
- แรงกระตุ้นที่อยากคัดลอกงานเขียนไปวางใน Claude เพื่อตรวจสอบนั้น แท้จริงแล้วคือ ความสงสัยในตัวเอง และ AI ก็กลายเป็นสิ่งที่ต้องเผชิญหน้าเพราะอาศัยความไม่มั่นคงนี้เป็นที่พึ่ง
ความกังวลว่า AI ทำให้ทักษะการเขียนและการเขียนโค้ดอ่อนแอลง
- การเขียนด้วย AI เป็นสิ่งที่ยั่วยวนอย่างมากในการเขียนบทความ โค้ด และเอกสาร แต่ก็ให้ความรู้สึกว่าความสามารถในการเขียนด้วยตัวเองกำลังลดลง
- แต่ก่อนแม้จะไม่ได้มองว่าตัวเองเก่งมากในด้านการเขียนหรือการพัฒนาซอฟต์แวร์ ก็ยังคิดว่าตัวเองพอมีความสามารถอยู่บ้าง แต่ยิ่ง ใช้ AI มากขึ้น ก็ยิ่งรู้สึกว่าทักษะของตัวเองแย่ลง
- เมื่อกลับมาอ่านผลลัพธ์ที่เขียนด้วย AI จะให้ความรู้สึกว่า “ก็ดูเป็น AI เฉย ๆ” ไม่เข้ากับน้ำเสียงหรือเจตนาของตัวเอง และไม่สามารถสื่อสิ่งที่อยากพูดได้อย่างแท้จริง
- ความกังวลนี้ยิ่งเพิ่ม ความสงสัยในตัวเอง และภาวะ impostor syndrome จนถึงขั้นทำให้เริ่มสงสัยว่าจริง ๆ แล้วตัวเองสามารถสร้างผลงานนั้นได้หรือไม่
เหตุผลที่อยากกลับไปเรียนรู้การเขียนโค้ดด้วยมือตัวเองอีกครั้ง
- ตลอด 1~2 ปีที่ผ่านมา ผู้เขียนใช้ AI ในการเขียนโค้ดแทบทั้งหมด และรู้สึกราวกับว่า เขียนแต่พรอมป์ต์ โดยไม่ได้เขียนโค้ดด้วยตัวเองแม้แต่บรรทัดเดียว
- ผลก็คือเหมือนลืมวิธีเขียนโค้ดไปเกือบหมด และการสูญเสียสิ่งที่ครั้งหนึ่งเคยเป็นศูนย์กลางของชีวิตอย่างการเขียนโค้ด ก็ทำให้รู้สึกเศร้าและหดหู่
- ตอนนี้จึงกำลังกลับมาเรียนรู้ การเขียนโค้ดด้วยมือตัวเอง ใหม่อีกครั้งด้วยตัวเอง
- มองว่าแม้จะมี AI ความสามารถในการพัฒนาซอฟต์แวร์ก็ไม่ได้หายไปอย่างสิ้นเชิง
- คนที่อ่านและเขียนโค้ดได้ยังคงจำเป็นต่อไป
- จำนวนคนที่ต้องการอาจลดลงได้ แต่คนประเภทนี้ก็ยังจำเป็นอยู่ดี
- หวังว่า AI อาจช่วยย้อนกระแส อุปสงค์ที่มากกว่าอุปทานของนักพัฒนาซอฟต์แวร์ ที่ดำเนินต่อเนื่องมา 20~30 ปีได้
- ตามแนวคิดในการบรรยายของ Robert Martin (Uncle Bob) ก่อนที่วิทยาการคอมพิวเตอร์จะกลายเป็นอาชีพ ผู้ที่ทำการเขียนโปรแกรมคือผู้เชี่ยวชาญอย่างนักฟิสิกส์ นักคณิตศาสตร์ และนักวิชาการ
- เมื่อความต้องการนักพัฒนาซอฟต์แวร์พุ่งสูงขึ้น ก็ทำให้ความเป็นวิชาชีพเฉพาะทางเลือนรางลง
- แม้จะเป็นงานเขียนที่เขียนขึ้นโดยไม่มี AI ก็ยังกังวลว่าอาจมีส่วนที่แปลกหรือขาดหายไป จนเกิดแรงกระตุ้นอยากนำไปวางใน Claude เพื่อตรวจสอบ
- แรงกระตุ้นนั้นเองคือ ความสงสัยในตัวเอง ที่ AI ใช้เป็นเชื้อเพลิงในการอยู่รอด และยังคงเป็นสิ่งที่ต้องต่อสู้ต่อไป
1 ความคิดเห็น
ความเห็นจาก Hacker News
ผมไม่ค่อยเห็นด้วยกับข้ออ้างนี้เท่าไร ทุกครั้งที่ใช้ AI เขียนโค้ด ผมต้องคอยสู้กับความรู้สึกคาใจว่าต้องไล่ดูทั้งหมดที่ AI ทำ แล้วเสริมหรือแก้ให้เป็นโค้ดของตัวเอง
มันมีโดพามีนจากการได้แอปที่ใช้งานได้ด้วย vibe coding ภายในไม่กี่นาทีอยู่หรอก แต่ความคาใจนั้นหักล้างมันไปหมด และดูไม่น่าจะหายไปในเร็ว ๆ นี้
แต่ก็คิดว่าน่าจะเป็นเพราะผมมีประสบการณ์ ถ้าเป็นนักพัฒนาระดับจูเนียร์หรือมิดเลเวล ผมเองก็คงตกหลุมนี้ได้เหมือนกัน ถ้าไม่ได้มีแผลเป็นจากช่วงต้นอาชีพที่โดนรีวิวโค้ดอย่างหนักจากเมนเทอร์ที่มีความรู้ ก็คงไม่มีเซนส์แบบนี้เหมือนกัน
สิ่งที่ Claude สร้างต้องรีวิวโค้ดอย่างละเอียดมาก ไม่งั้น codebase จะพองต่อไปเรื่อย ๆ จนเข้าใกล้หนี้เทคนิค 100%
ผมรีวิวผลลัพธ์จาก Claude ทุกครั้ง และประมาณ 90~95% จะลงเอยที่ “ว้าว มันทำงานนะ แต่โค้ดเยอะเกินไป งั้นมาจับมือกันตัดมันลงอีก 3 ชั่วโมงจนกว่าจะตัดอะไรออกไม่ได้แล้วดีกว่า”
เราต้องหาวิธีร่วมงานกับเอเจนต์ให้ดีกว่านี้ ถ้าให้คนรีวิวส่วนสำคัญที่ต้องดูเอง แล้ว “จ้างช่วง” ส่วนที่เหลือ คุณจะไปถึงโค้ดและดีไซน์ที่ทำงานได้แบบเดียวกับการเขียนเองได้เร็วกว่า
ผมเองก็รีวิวโค้ดที่เอเจนต์เขียนราว 90% แต่การเขียนหรือพูดแค่ไม่กี่พรอมป์ต์มันสนุกกว่าการต้องพิมพ์เป็นหมื่นตัวอักษรแล้วสลับไฟล์ไปมาเยอะมาก อาจเป็นเพราะผมเหนื่อยกับการพิมพ์ก็ได้
แต่ถ้าเป็นงานจุกจิกที่กินเวลาและน่าเบื่อ ผมจะออกแบบสถาปัตยกรรมให้ชัดเจนก่อน แล้วให้ AI ไปลงมือทำ ส่วนหลังจากนั้นก็ยังต้องกลับมาตรวจอีกทีว่ามันไม่ได้ทำอะไรเพี้ยน ๆ
ตัวอย่างที่ดีล่าสุดคือ ในเกมที่ทำด้วย Godot, Codex พยายามจะเขียนพฤติกรรมที่ Area2D มีให้อยู่แล้วขึ้นมาใหม่ทั้งหมดตั้งแต่ต้น
ถ้าคุณให้ AI ทำงานที่มีความหมายจริง ๆ มันจะเต็มไปด้วยกับระเบิดและการตัดสินใจประหลาด ๆ อาจต่างออกไปถ้าคุณยอมเผาโทเคนไปหลายร้อยดอลลาร์ แต่สำหรับผมที่จ่ายเดือนละ 10 ดอลลาร์ มันไม่คุ้มกับความปวดหัว
อีกอย่างโปรเจกต์ของผมเป็นงานอดิเรก และการเขียนโค้ดยังสนุกอยู่ ผมเลยให้ AI ทำแค่ส่วนที่น่าเบื่ออย่างบันทึก/โหลด การ parse ไฟล์ข้อมูล หรือเมนูตั้งค่า แล้วให้ห่างจากส่วนที่ต้องใช้วิจารณญาณแบบมนุษย์
ผมอยากคิดว่าถ้าเป็นตัวเองคงใช้เอเจนต์เพื่อขุดลึกและเรียนให้เร็วขึ้น แต่เมื่อก่อนการประกอบวิธีแก้จาก Stack Overflow, หลายช่อง IRC, Reddit ฯลฯ มันค่อนข้างยากอยู่แล้ว
แต่สมัยมหาวิทยาลัยผมก็ลอกการบ้านและไม่ได้ตรวจคำตอบให้ดีนัก เลยไม่กล้าฟันธง ถึงอย่างนั้นผมก็ไม่ได้เรียนเอาแค่ปริญญา ผมเขียนโปรแกรมเพราะสนใจ มันอาจเลยต่างออกไป
ยังไงก็เถอะ ผมดีใจที่มีประสบการณ์และความล้มเหลวมาเยอะแล้วก่อนจะเข้าสู่ยุค LLM
โค้ดที่ผมเขียนเองดีกว่า Claude หรือ GPT ทุกครั้ง
ครั้งหนึ่งผมเคยดึงสเปกจากโปรเจกต์ที่เขียนเสร็จแล้ว ให้ LLM เอาแต่สเปกนั้นไปเขียนใหม่ แล้วเอาโค้ดมาเทียบกัน เวอร์ชันของ LLM นี่เละเหมือนอ้วก
ในฐานะนักพัฒนา ทั้งหมดนี้ให้ความรู้สึกคล้าย ความมั่นคงในการจ้างงาน อยู่บ้าง
ผมใช้ LLM มาพักหนึ่งแล้ว มันค่อนข้างดีและผมก็ชอบใช้มัน ผมลอง vibe coding แอปไปบ้าง และการได้เห็นไอเดียมีชีวิตทันทีนี่โดพามีนแรงมาก
แต่จากประสบการณ์ของผม ถ้าเชื่อมันแบบไม่ลืมหูลืมตา ยังไงก็โดนกัดแน่ แม้แต่โปรเจกต์ที่ vibe coding มันก็ยังคอยเพิ่ม “ฟีเจอร์” ที่ผมไม่ได้ขอเข้ามาเรื่อย ๆ
ถ้าเป็นโปรเจกต์ส่วนตัวแล้วผลลัพธ์สุดท้ายได้อย่างที่หวังก็ไม่ค่อยเป็นไร แต่บริษัทคงยืดหยุ่นแบบนั้นไม่ได้ ลูกค้าก็คงไม่ชอบให้ฟีเจอร์เปลี่ยนหรือเพิ่มใหม่ทุกครั้งที่มีการแก้ไขหรืออัปเดต
ถ้าสรุปสถานการณ์ตอนนี้ ก็คือหลายบริษัทกำลังมุ่งไปทางนี้ และถ้าไม่มีวิศวกรรมที่เหมาะสม AI สามารถเขียนโค้ดมากขึ้นพร้อมทั้งเปลี่ยนแอปโดยไม่ตั้งใจได้
เพราะความกลัว AI และการจ้างงานที่ลดลง วิศวกรจูเนียร์ที่จะเข้าสู่ตลาดก็น่าจะลดลง
ถ้าการใช้ AI ไปถึงจุดวิกฤต มันจะเกิดการเปลี่ยนแปลงมหาศาล และคนที่คอย “พรอมป์ต์” มันอาจเริ่มรับมือไม่ไหว
สิ่งที่ต้องคงไว้ในหัวจะยิ่งมากขึ้น เพราะเราเชื่อถือ LLM ได้ไม่ 100% นักพัฒนายังจำเป็นต้องรู้ว่าแอปพลิเคชันกำลังทำอะไรอยู่กันแน่
สุดท้ายบั๊กจะเยอะขึ้น และนักพัฒนาจะเริ่มบ่นว่าต้องการคนเพิ่ม จากนั้นการจ้างงานก็จะกลับมาอีกครั้ง
ตอนนี้ตำแหน่งที่ลำบากที่สุดคือคนเริ่มต้นใหม่ ส่วนตำแหน่งที่ดีที่สุดน่าจะเป็นคนที่อยู่ในตลาดแล้ว
แทบไม่ได้เตรียมอะไรเพื่อให้มันสำเร็จเลย เอาแต่จ้างตัวเลือกที่ถูกที่สุดแบบไม่ลืมหูลืมตา โยน requirement กำกวมให้ แล้วแทบไม่มีการรีวิวทางเทคนิคหรือการกำกับดูแลอย่างต่อเนื่อง
แพตเทิร์นก็คล้ายที่คุณพูด ตอนแรกมันดูเหมือนสำเร็จเพราะโปรโตไทป์ขึ้นเร็วมากด้วยโค้ดที่สกปรกที่สุดเท่าที่จะจินตนาการได้ แต่พอเวลาผ่านไป หนี้เทคนิคและการตัดสินใจแย่ ๆ ก็กลายเป็นแรงต้านที่ใหญ่ขึ้นเรื่อย ๆ ทำให้ความคืบหน้าช้าลง จนสุดท้ายโปรเจกต์หยุดหรือไม่ก็ตายไปเลย
ครั้งนี้อาจต่างออกไปก็ได้ แต่ช่วงต้นอาชีพของผม งานส่วนใหญ่คือการเข้าไปเก็บกวาดโปรเจกต์ลักษณะนี้ ผมหวังว่านักพัฒนารุ่นใหม่จะยังได้โอกาสแบบเดียวกัน
อย่างแรกคือประสิทธิภาพที่เพิ่มขึ้นมหาศาล มันมากกว่าเครื่องมือใด ๆ ในทุกช่วงราคา ผลิตภัณฑ์หลักของบริษัทเราคือเว็บแอป และช่วงหลายปีที่ผ่านมาเรากำลังรีไรต์ผลิตภัณฑ์หลักนี้
บ่ายวันหนึ่งผมสามารถสร้างโปรเจกต์ใหม่ด้วยสแตกที่ต้องการ แล้ว vibe coding MVP ของผลิตภัณฑ์ที่เราทำกันมาหลายปีได้ภายในไม่กี่ชั่วโมง
มันไม่สมบูรณ์แบบ แต่ผมขอฟีเจอร์ทีละอย่างด้วยพรอมป์ต์เล็ก ๆ แต่ละอย่างใช้เวลา 5~10 นาที มันดูเป็นมืออาชีพพอสมควร และตามทุกมาตรฐานก็ถือว่า “ดีพอ”
ถ้าให้เวลาเพิ่มอีกหน่อย ผมคิดว่าอาจปล่อยและดูแลสิ่งที่ทีมพัฒนาขนาดเล็กใช้เวลาหลายปีสร้างได้เพียงลำพังก็ได้ น่าเสียดายที่นี่ไม่ใช่แค่เครื่องมือเพิ่มประสิทธิภาพ แต่มันใกล้เคียง “ตัวแทนทีมทั้งทีมราคาถูก” มากกว่า
อีกอย่างคือกระแส AI แบบร้อนแรงของ CEO ที่ไม่ใช่สายเทคนิค CEO และผู้บริหารของเรารับชุดเครื่องมือเอเจนต์ของ Claude ไปเต็ม ๆ และทุกวันก็ทำ mockup, แอป และ toolchain กันออกมา
ดูออกเลยว่าเขาติด และรับรู้ผลประโยชน์ได้ด้วยตัวเอง ถึงยังไม่เกิดขึ้น แต่ผมคงไม่แปลกใจถ้า CEO ปลดทีมพัฒนาเกือบทั้งหมด แล้วเหลือนักพัฒนาฝีมือดีไม่กี่คนช่วยกัน vibe coding ทั้งแอป
ตอนนี้พวกเขายังพูดว่า “AI ไม่ใช่ตัวแทน มันเป็นตัวคูณ!” แต่ในประโยคเดียวกันก็พูดต่อว่า “ถ้าสิ่งนี้ทำให้เราไม่ต้องจ้างคนอีกหลายปี ก็ถือว่าชนะ!”
ผมโดนถามตรง ๆ ว่าทำไมถึงไม่ควร vibe coding ทั้งแอป และผมก็ไม่มีคำตอบชัด ๆ ความคิดทำนอง “คุณจะไม่รู้วิธีดูแลรักษาแอป” ฟังดูพอมีเหตุผล แต่ Claude ในมือนักพัฒนาแค่คนเดียวก็ทำอะไรได้เยอะมาก
ยังมีข้อพูดว่า “AI อาจเปลี่ยนแอปโดยไม่ตั้งใจและใส่บั๊กเข้ามาได้” แต่ด้วย observability, การทดสอบ และพรอมป์ต์เพิ่มที่เหมาะสม มันก็แก้ได้ในไม่กี่นาทีถึงไม่กี่ชั่วโมง
พูดตามตรง การที่บริษัทจะยังคงรักษาทั้งทีมพัฒนาไว้เหมือนเดิมมันเริ่มไม่สมเหตุสมผลอีกต่อไป ไม่ว่าจะเริ่มโปรเจกต์ใหม่หรือเดิน initiative มากแค่ไหน backlog ก็ลดลงเร็วมาก และ throughput ของนักพัฒนาแต่ละคนก็พุ่งแบบเหลือเชื่อ
CEO ที่ไม่ใช่สายเทคนิคไม่ได้สนใจหนี้เทคนิค หนี้ทางความคิด แนวปฏิบัติการออกแบบซอฟต์แวร์ที่แย่ การเรียนรู้การเขียนโค้ด การทำให้นักพัฒนายังคมอยู่ ความสนุกในการแก้ปัญหา หรือความงามของอัลกอริทึมหรือสถาปัตยกรรมที่ดี
สิ่งที่พวกเขาต้องการคือผลิตภัณฑ์ที่ใช้งานได้พอประมาณ ให้คุณค่า น่าจ่ายเงิน และเปิดตัวด้วยต้นทุนที่ต่ำที่สุดเท่าที่จะทำได้ ซึ่งน่าเสียดายที่ AI ตอบโจทย์นั้นแทบทุกข้อ
ผมหวังว่าปริมาณซอฟต์แวร์ใหม่มหาศาลที่จะถูกสร้างขึ้นจะช่วยเพิ่มอุปสงค์ได้ แต่ก็กลัวว่ามันจะไม่พอชดเชยกำลังการผลิตที่เพิ่มขึ้นอย่างมหาศาลจาก AI
เดือนหน้าผมกันเวลาไว้เพื่อเรียนTypeScript ผมไม่ได้คิดจะตัด AI ออกไปหมดในกระบวนการนั้น
แผนคืออ่านหนังสือตั้งแต่ต้นจนจบ แล้วค่อยเขียนโค้ดต่อ คิดว่าน่าจะเคยได้ยินวิธีนี้จาก Mitchell Hashimoto ในพอดแคสต์รายการหนึ่ง
เพราะผมใช้เวลากับ prompt coding มาเยอะเหมือนต้นฉบับ เลยทั้งตื่นเต้นและกลัว
เป็นไปไม่ได้หรอกที่การไม่เขียนโค้ดด้วยมือจะทำให้คุณฉลาดน้อยลง ถ้ามันเป็นไปได้ เราก็ควรโง่ลงทุกครั้งที่ไปพักร้อน
การคุยกับแชตบอตไม่ได้ทำให้การเชื่อมต่อของเซลล์ประสาทในสมองตายลง
สิ่งที่เกิดขึ้นจริงคือคุณแค่พักจากทักษะที่มีความเฉพาะทางสูงชั่วคราว ใครก็ตามบนโลกนี้ ถ้าไม่ได้ใช้ทักษะใดทักษะหนึ่งพักหนึ่ง ก็จะ “ลืม” บางส่วนของทักษะนั้น
แต่มันไม่ใช่ว่าข้อมูลหายไป แค่ถูกลดความสำคัญลงเพราะมีข้อมูลที่เกี่ยวข้องมากกว่ามาแทน พอทบทวนสักหน่อยก็กลับมาได้
ก่อนยุค AI ผมเองก็เคยเว้นไปหลายเดือนกว่าจะได้เขียนโปรแกรมเต็ม ๆ ด้วยภาษาใดภาษาหนึ่ง ผมลืมแม้กระทั่งเรื่องง่าย ๆ อย่างจะเริ่มนิยามฟังก์ชันยังไง
แต่มันไม่ใช่การลืมจริง ๆ แค่เห็นฟังก์ชันที่มีอยู่สักตัวเดียว ผมก็นึกไวยากรณ์แบบอื่นที่เป็นไปได้ทั้งหมดของการนิยามฟังก์ชันออก ไม่ต้องตื่นตกใจ สมองคุณยังทำงานปกติดี
ที่โรงเรียนมีการพูดถึงอันตรายของ AI เยอะมาก แต่ความเสี่ยงแบบเดียวกันนี้ใช้ได้กับสภาพแวดล้อมการเรียนรู้ทุกแบบ
ผมเพิ่งเริ่มงานใหม่ไม่นาน และ AI กำลังทำให้การ onboarding ยากขึ้นมาก ผมปรับตัวเข้ากับบทบาทได้ช้ากว่าเพื่อนร่วมงานที่ใช้ AI น้อยกว่าอย่างเห็นได้ชัด
ผมกำลังเขียนโค้ดด้วยภาษาที่ไม่คุ้นเคย เลยยิ่งมีแรงล่อใจให้ vibe coding มากขึ้น ถึงอย่างนั้นผมก็ยังมีฝีมือพอจะรู้ว่าเมื่อ Claude ตอบไร้สาระหรือเยิ่นเย้อเกินจำเป็น
แต่ยิ่งผมใช้เวลาให้ Claude เขียนโค้ดมากขึ้น ผมก็ยิ่งรู้สึกน้อยลงว่าตัวเองกำลังพัฒนาความสามารถที่งานนี้ต้องการ แม้แต่ตอนส่ง PR ผมก็รู้สึกไม่ดีเพราะไม่มีความมั่นใจในงานของตัวเองเท่าที่ควร
พูดตรง ๆ อีกส่วนหนึ่งคือ ผมกำลังให้ Claude ไปค้นใน Slack กับเอกสารแทนคำถามที่ผมควรถามคนจริง ๆ
AI กำลังหล่อเลี้ยงความวิตกกังวลทางสังคมของผม และล่อลวงให้ผมหลีกเลี่ยงการปะทะกับมนุษย์ ทั้งที่มันดีต่อความเข้าใจ และจำเป็นต่อปฏิสัมพันธ์ทางสังคมขั้นพื้นฐานด้วย
มันอาจฟังเหมือนโยนความรับผิดชอบทิ้ง แต่ก็ควรพูดถึงว่าบางเทคโนโลยีสามารถเสพติดอย่างแรงสำหรับคนบางประเภท และขังพวกเขาไว้ในลูปพฤติกรรมเชิงลบได้
ถ้าผมชะลอการพึ่งพา AI ตอนนี้ ต่อไปก็น่าจะมีทักษะมากพอที่จะมอบงานที่ตรวจผลได้ง่ายและทำซ้ำให้ AI ทำแทนได้ มันยาก แต่จำเป็น
คุณจะได้เรียนรู้ไปพร้อมกับกระบวนการ ไม่จำเป็นต้องใช้มันเหมือนเสิร์ชเอนจิน แค่ถามสิ่งที่คุณต้องรู้ในตอนนั้น มันจะเขย่าห่วงโซ่โทเคนออกมาเป็นอะไรบางอย่างที่มีประโยชน์ โดยเฉพาะสำหรับคนที่ยังใหม่กับภาษา
แบบนี้คุณจะทำตามแผนที่ตั้งใจไว้ได้ คือสร้างความสามารถก่อน แล้วค่อยเริ่มมอบหมาย
ผมทำแบบนี้มาตลอด และสำหรับผมมันเป็นสมดุลที่ดี การให้ Claude เขียนโค้ดที่คุณยังประเมินไม่เป็น ดูเหมือนเรื่องบ้าสำหรับผม แต่ดูเหมือนผมจะเป็นเสียงส่วนน้อย
อันที่จริงนี่เป็นหนึ่งในไม่กี่ use case จริงที่ผมเจอ นอกเหนือจาก vibe coding
ผมไม่ได้ใช้ AI เพื่อทำลายความคิด แต่ใช้เพื่อหลีกหนีการเขียนโค้ดซ้ำ ๆ ที่น่าเบื่อ หลังจากทำโปรโตไทป์เสร็จแล้ว AI ก็มีความสามารถพอจะเขียนโค้ดต่อได้
ผมจะเขียนโปรโตไทป์หยาบ ๆ สำหรับพิสูจน์แนวคิดเองก่อน ไม่มีคอมเมนต์ ฮาร์ดโค้ดตัวแปรไว้แบบนั้น จากนั้น AI ค่อยขัดเกลาให้เป็นระดับผลิตภัณฑ์
สิ่งนี้ทำให้ผมสามารถบังคับการทีมเอเจนต์ได้ แทนที่จะต้องมาคอยจัดการคนที่มีจรรยาบรรณการทำงาน ทักษะ และความสามารถในการรักษาคุณภาพโค้ดสูง ๆ ไม่เท่ากัน
AI มักเก่งพอสมควรในการรักษาแพตเทิร์นที่มีอยู่ใน codebase หรือปรับให้เข้ากับแนวปฏิบัติที่ดีของอุตสาหกรรม
เมื่อใช้ AI คุณจะไม่ได้เขียนด้วยภาษาโปรแกรมมากเหมือนเดิมอีกต่อไป ไม่ว่าจะเป็นภาษาอังกฤษหรือภาษาที่ใช้คุยกับ LLM นั่นจะกลายเป็นภาษาหลักของคุณ
ทุกวันนี้วันทำงานของผมส่วนใหญ่หมดไปกับการแก้ความไม่สมบูรณ์ที่หุ่นยนต์สร้างโค้ดทำไว้
แน่นอนว่างานของผมไม่ใช่ขัดเกลาโปรโตไทป์ แต่เป็นการดูแล พัฒนา และทำให้ผลิตภัณฑ์สำคัญที่มีอายุกว่า 8 ปีทันสมัยขึ้น
ในโปรเจกต์หนึ่ง ๆ มันมีโค้ดซ้ำที่น่าเบื่อแบบนั้นมากขนาดไหนกันเชียว?
คุณต้องมีพรอมป์ต์ที่ออกแบบอย่างประณีต ซึ่งหมายความว่าต้องเข้าใจเฟรมเวิร์กและภาษาพื้นฐานให้ดี ไม่งั้นทั้งหมดจะกลายเป็นความเละเทะน่ากลัว
ผมก็ไม่รู้จะจัดการหลายเอเจนต์ยังไง เพราะปกติมันเสร็จเร็วมาก คุณทำอย่างอื่นคั่นระหว่างรันแทบไม่ได้ มันจะอยู่ในสภาพ “อีกนาทีเดียวก็เสร็จ” ตลอด
พอเสร็จแล้วคุณก็ต้องประเมินผลลัพธ์ต่อ เพราะงั้นระหว่าง “ทำงาน” คุณคิดลึก ๆ ไม่ได้เลย มันมีแพตเทิร์นคล้ายโซเชียลมีเดีย ต้องคอยเฝ้าดูต่อเนื่อง และได้รางวัลแทบจะทันที
สุดท้ายช่วงความสนใจก็พังต่อเนื่อง และพังจริงจังด้วย
ปัญหาคือแผนพวกนี้หายไปในไม่กี่ชั่วโมง แล้วหลังจากนั้นก็ต้องมานั่งวิเคราะห์ผลลัพธ์และวนแก้อีกทีเพื่อกรองส่วนโง่ ๆ ออก
การรับมือกับผลลัพธ์จากหลายเอเจนต์คือการสลับบริบทอย่างต่อเนื่อง ขอให้คุณไปได้ดีในระยะยาว
ถ้าปล่อยให้เอเจนต์วิ่งเล่นตามใจและสร้างอะไรก็ได้ ผลลัพธ์แทบจะแน่นอนว่าเป็นความเละเทะน่ากลัว จบ
ในโปรเจกต์ปัจจุบัน ผมเขียนโค้ดด้วย Java, Ruby, JavaScript ทุกวัน ทุกวันนี้ผมเผาโทเคนไปเยอะเพื่อเช็กความต่างระหว่างภาษาที่เมื่อก่อนแค่ค้น Google ง่าย ๆ ก็พอ
ผมสับสนอยู่เรื่อยเรื่องความต่างของ null-safe operator ระหว่าง Ruby กับ JavaScript หรือคำสั่ง continue/break ของ Ruby กับ Java
Claude คงผิดหวังมากถ้างานที่ผมให้ซับซ้อนที่สุดเป็นแค่รีแฟกเตอร์ลูป Java เก่า ๆ ให้เป็นสตรีมแบบสมัยใหม่ ซึ่งบางทีโค้ดแบบนั้นอาจแทบเป็นไปไม่ได้เลยที่คนจะเขียนสด ๆ ได้
ถ้าได้เขียน collector เองหรือใช้ส่วนที่ค่อนข้าง obscure ของ standard library ก็ยิ่งได้คะแนนโบนัส
ก็มีตัวอย่างฝั่งตรงข้ามเหมือนกัน การโยนไอเดียไปมากับ AI ในโหมด /plan โดยที่ผมคอยจับสมมติฐานผิด ๆ ของมัน และมันก็คอยอธิบายช่องว่างความรู้ให้ชัดเจนเมื่อจำเป็น เป็นกระบวนการที่กระตุ้นสติปัญญาพอสมควรและเหมือนจะทำให้ผมเป็นวิศวกรที่ดีขึ้น
หัวใจสำคัญคือเข้าหา AI แบบโสกราตีส คิดอย่างรอบคอบกับทุกข้อเสนอของมัน และอย่าถูกสะกดด้วยน้ำเสียงมั่นใจและตรรกะที่จัดโครงสร้างมาอย่างสมบูรณ์แบบ
ผมเจอประสบการณ์ตรงกันข้ามเลย น่าจะเพราะในสายงานของผม โค้ด/ซอฟต์แวร์ไม่ใช่ผลิตภัณฑ์ แต่เป็นเครื่องมือ
ผมเรียนรู้ได้เร็วขึ้นและมากขึ้นมาก ตัวอย่างเช่นตอนนี้ผมกำลังทำงานกับฮาร์ดแวร์สเปกโทรสโกปีอย่าง Raman, NMR และให้ Claude เขียนโค้ดที่เชื่อมต่อกับอุปกรณ์ในระดับฮาร์ดแวร์
แทนที่ผมจะต้องไล่อ่าน datasheet และเขียน wrapper code กองโต Claude จัดการให้
ผมสามารถคุยเทคนิคหลายแบบกับ Claude แล้วลงมือทำและทดสอบได้เร็วขึ้นมาก ถ้าเป็นเมื่อก่อนลูปนี้คงใช้เวลานานกว่านี้ 5~10 เท่า
เพราะไม่ต้องเสียแรงสมองไปกับการเขียนโค้ดจุกจิกเพื่อดูผลลัพธ์ ผมเลยได้เรียนรู้เกี่ยวกับอุปกรณ์ เทคนิค และข้อมูลพวกนี้มากขึ้นกว่ามาก
ผมเป็นนักพัฒนามากว่า 10 ปีแล้ว และดีใจที่ในที่สุดเหมือนจะได้ไปสู่โลกที่ผมใช้โค้ดเป็นเครื่องมือ ไม่ได้คิดถึงมันเป็นผลิตภัณฑ์อยู่ตลอดเวลา
ผมไม่คิดว่าจะมีคนมากนักที่มีอภิสิทธิ์พอจะใช้เวลาเขียนโค้ดด้วยมือต่อไปได้
เอาเข้าจริง ถ้าดูโค้ดที่พวกเราเขียน ในกรณีของผม ส่วนใหญ่มันไม่ใช่อะไรใหม่หรือเท่เลย แต่เป็นงานเดิม ๆ อย่าง “ทำ backend สำหรับ X” แก้บั๊กง่าย ๆ หรืองานจุกจิกสำหรับโปรแกรมเมอร์ระดับมิดถึงซีเนียร์
งานที่ยากกว่ามักเป็นการตัดสินใจเชิงสถาปัตยกรรมเหนือโค้ดขึ้นไป และผมก็กำลังคิดว่าจะสร้างระบบยังไงไม่ให้ LLM หลุดจากการทำฟังก์ชันที่ต้องการ
ที่อยากบอกคือ ตอนนี้การเขียนโค้ดด้วยมืออาจยังโอเค แต่ต่อไปผู้ถือหุ้นหรือหัวหน้าจะอยากให้เราปล่อยฟีเจอร์และแก้บั๊กได้เร็วขึ้นด้วยความช่วยเหลือของ LLM
ถ้าคุณไปไม่ถึงความเร็วแบบนั้น ผลงานของคุณก็จะดูต่ำลง สุดท้ายสิ่งสำคัญไม่ใช่ว่าเราอยากได้อะไร แต่คือผู้ถือหุ้นอยากได้อะไร
แน่นอน ถ้าคุณยังมีแรง ก็อาจใช้เวลาว่างเขียนโค้ดด้วยมือได้ ผมไม่ได้อยากฟังดูมองโลกในแง่ร้าย แต่คิดว่าอีกไม่นานมันจะเป็นจริงพอสมควร