AI สร้างผลคูณให้กับทักษะทางเทคนิคที่มีอยู่เดิม
(joshwcomeau.com)- โมเดล AI ใช้งานได้ดีพอสำหรับงานเขียนโปรแกรมจำนวนมาก แต่ใกล้เคียงกับการเป็นเครื่องมือที่ขยายขีดความสามารถทางเทคนิคที่มีอยู่เดิม มากกว่าจะเข้ามาแทนที่นักพัฒนา
- ยังไม่เห็นหลักฐาน ว่า LLM จะสามารถออกแบบและสร้างโปรเจ็กต์ทุกขนาดได้อย่างสมบูรณ์ จนมนุษย์นักพัฒนาใกล้หมดความจำเป็น
- Matt Perry ปิดงานใน Motion ได้ 160 รายการ มากกว่าเป้าหมายไตรมาส 1 ที่ 60 รายการ และยังจบการรีแฟกเตอร์ครั้งใหญ่สำหรับไตรมาส 2 ได้ภายในบ่ายวันหนึ่งของเดือนมกราคม
- vibe-coding ของผู้ใช้ที่มีประสบการณ์พัฒนาน้อยมักไปต่อได้ยากหลังผ่าน MVP และการตัดสินใจด้านสถาปัตยกรรมกับความรู้โดเมนเป็นตัวสร้างความแตกต่างของผลลัพธ์
- AI ทรงพลังเหมือนชุดเกราะของ Iron Man แต่ไม่ได้สร้างผลงานเดียวกันได้ด้วยตัวเอง และ การเรียนรู้อย่างมีโครงสร้าง กับความชำนาญเป็นตัวกำหนดประสิทธิผลของการใช้งาน
กรณีศึกษาด้านประสิทธิภาพการทำงานของ Matt Perry
- Matt Perry เป็นนักพัฒนาที่สร้างไลบรารีแอนิเมชันหลายตัว เช่น Popmotion, Motion One และ Motion (เดิมคือ Framer Motion)
- เอนจิน layout projection ของ Motion เป็นผลลัพธ์ของงานวิศวกรรมที่ประณีต
- Matt Perry เพิ่มการใช้ AI อย่างจริงจังในปี 2026 และปิดอีชูได้ 160 รายการ มากกว่าเป้าหมายไตรมาส 1 ที่ตั้งไว้ 60 รายการ
- การรีแฟกเตอร์ครั้งใหญ่ของ Motion ที่เดิมวางไว้สำหรับไตรมาส 2 ก็เสร็จในรวดเดียวภายในบ่ายวันหนึ่งของเดือนมกราคม
- สิ่งนี้แสดงให้เห็นว่าไม่ใช่ตัว LLM เองที่เก่งกว่านักพัฒนามนุษย์ระดับสูงสุด แต่เมื่อผู้พัฒนาที่ชำนาญใช้ AI ประสิทธิภาพการทำงานสามารถถูกขยายขึ้นอย่างมาก
ข้อจำกัดของ vibe-coding เมื่อขาดความรู้โดเมน
- ใน
/r/vibecodingมีคนจำนวนมากที่แทบไม่มีหรือมีประสบการณ์พัฒนาเพียงเล็กน้อยมาแชร์ประสบการณ์ vibe-coding และมักติดขัดในช่วงหลังจาก MVP - LLM ที่ถูกใช้งานโดยไม่มีการชี้นำจะมุ่งไปที่การสร้างโค้ดเพื่อแก้แต่ละพรอมป์ต์ และเพราะมองสถาปัตยกรรมของแอปพลิเคชันแบบองค์รวมไม่ได้ จึงพาโครงการไปสู่ทางตันได้ง่าย
- นักพัฒนาที่ชำนาญสามารถขยายสิ่งที่ทำได้ด้วย AI แต่ผู้ใช้ที่ขาดความรู้โดเมนมักก้าวข้ามขั้น “MVP” ได้ยาก
- แม้จะใช้เครื่องมือ AI เดียวกัน ผลลัพธ์ก็ไม่ได้เหมือนกัน และวิจารณญาณกับความเข้าใจเชิงโครงสร้างของผู้ใช้คือปัจจัยที่สร้างความแตกต่างสำคัญ
วิธีคิดที่มอง AI เป็นเครื่องมือ
- AI คือเครื่องมือ และเครื่องมือจะเกิดผลก็ต่อเมื่อใช้อย่างชำนาญ
- ต่อให้มีทั้งกีตาร์ของ Jimi Hendrix ห้องครัวของ Gordon Ramsey หรือไม้เทนนิสของ Serena Williams ก็ไม่ได้แปลว่าจะสร้างผลลัพธ์แบบเดียวกันได้
- ผู้คนมักประเมินความสำคัญของเครื่องมือสูงเกินจริง และการตลาดก็ใช้ประโยชน์จากอคตินี้ เช่น รองเท้าที่มี “air technology” ของ Michael Jordan ที่ชวนให้คิดว่าจะช่วยให้ดังก์ได้
- AI agent ถูกทำให้ดูมีความเป็นมนุษย์มากขึ้น จึงยิ่งมองว่าเป็นเครื่องมือได้ยาก และหากปฏิบัติต่อมันเหมือนหุ่นยนต์อัตโนมัติ ก็อาจยกเครดิตให้มันมากเกินความจริง
- อุปมาที่เหมาะสมกว่าคือ ชุดเกราะของ Iron Man: มันทำให้สิ่งน่าทึ่งเกิดขึ้นได้ แต่ไม่ใช่สิ่งที่ทำงานเองแล้วสร้างผลงานแบบเดียวกันได้
- ต่อให้ Matt Perry มอบสิทธิ์เข้าถึงรีโพซิทอรี Motion และเครื่องมือ LLM ให้ ถ้าพยายามทำงานด้วยความเร็วเท่าเขา ผลลัพธ์ก็น่าจะไม่ใช่แบบเดียวกัน แต่อาจกลายเป็นความวุ่นวายครั้งใหญ่
- เมื่อเห็นสิ่งที่นักพัฒนาฝีมือดีทำได้ด้วย LLM ปัจจัยสำคัญจึงไม่ใช่ตัว LLM เอง แต่เป็นความสามารถของนักพัฒนาที่ชำนาญ
Whimsical Animations และการเรียนรู้อย่างมีโครงสร้าง
- Whimsical Animations เป็นคอร์สเว็บแอนิเมชันที่เพิ่งเปิดตัวใหม่
- ตลอดราว 20 ปีของการสร้างเว็บไซต์และเว็บแอปพลิเคชัน ผู้เขียนได้สั่งสมวิธีสร้างแอนิเมชันและอินเทอร์แอ็กชันที่น่าจดจำและทรงอิทธิพล
- สื่อการสอนด้านแอนิเมชันสำหรับนักพัฒนาเว็บมีไม่มากนัก จึงนำแนวคิดจากสายพัฒนาเกมมาปรับใช้ให้เข้ากับเว็บมาโดยตลอด
- แนวคิดอย่าง linear interpolation, simplex noise, และ delta time มักไม่อยู่ในขอบเขตทักษะทั่วไปของนักพัฒนาเว็บ แต่สามารถทำให้โปรเจ็กต์โดดเด่นขึ้นได้
- แม้เครื่องมืออย่าง ChatGPT จะทำให้การเรียนรู้หัวข้อใหม่เป็นเรื่องง่ายขึ้น แต่การเรียนรู้อย่างมีประสิทธิภาพก็ยังต้องรู้ว่าควรถามอะไร
- คอร์สนี้มีหลักสูตรที่คัดสรรมาอย่างเป็นระบบเพื่อแนะนำเทคนิคที่หลากหลาย
- แพลตฟอร์มคอร์สแบบกำหนดเองได้รับการอัปเดต ทำให้สามารถรันแบบฝึกหัดและโค้ดสไนเป็ตทั้งหมดบนเครื่องโลคัลได้
- การรองรับการรันบนเครื่องโลคัลทำให้สามารถทำชาเลนจ์ต่าง ๆ ได้ในสภาพแวดล้อมและเวิร์กโฟลว์การเขียนโค้ดที่ใช้อยู่เป็นประจำ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
สัปดาห์ก่อนฉันลอง vibe coding งานออกแบบ UI โดยเปิดการทดสอบคอมโพเนนต์ไว้อีกหน้าจอหนึ่ง แล้วรู้สึกเหมือนมีโมเมนต์แบบ Iron Man
ฉันสั่งให้มันย้ายองค์ประกอบ เพิ่มลดจุดเน้น และลองตัวเลือกเลย์เอาต์ไปเรื่อย ๆ ซึ่งวนลูปกันแทบจะเรียลไทม์และน่าทึ่งมาก
โค้ดที่สร้างออกมานั้นแย่มาก แต่กลับพาไปสู่ดีไซน์ที่ถ้าทำคนเดียวคงไปไม่ถึงได้อย่างง่ายดาย และหลังจากนั้นฉันก็นำดีไซน์อ้างอิงนั้นมาลงมือเขียนใหม่เองด้วยโค้ดที่ดีกว่าได้
นักออกแบบอาจพูดกลับกันว่า “Claude Design Studio สร้าง UI ห่วย ๆ มา แต่ฉันแก้เองได้ และมันก็เขียนโค้ดดี ๆ ที่ฉันคงเขียนเองไม่ได้ให้แทน”
ไม่ต้องกังวลว่ามันเชื่อมกันอย่างไร แค่ใช้งานได้ก็พอ และถ้ามันพังก็ให้ AI แก้ให้
มันให้ความรู้สึกปลดปล่อยอยู่บ้าง แต่ฉันก็ยังไม่แน่ใจว่าตัวเองไปถึงนิพพานแบบ AI ที่ยอมรับสิ่งนี้ได้หรือยัง แม้จะรู้สึกว่าใกล้แล้วก็ตาม
ตอนนี้คือช่วงที่เราเข้าใจทักษะพื้นฐานและยังสร้างเองได้ แต่ก็เลือกการวนซ้ำที่เร็วกว่าแม้จะรู้ว่ามีโค้ดยุ่งเหยิงกองอยู่ตรงไหนสักแห่งที่พอจะจัดระเบียบได้
มันทำได้เพราะเรารู้รูปร่างคร่าว ๆ ของสิ่งที่ “มันควรจะเป็น” และสามารถชี้นำเฟรมเวิร์กอัตโนมัติไปทางนั้นได้ โดยเฉพาะในโปรเจ็กต์ที่เราสร้างเอง
ถ้าบริษัทต่าง ๆ อยู่รอดไปได้นานพอ ความรู้นั้นอาจหายไปจนหมด เหลือแต่เครื่องมือ และตอนนั้นมันจะไม่ใช่ Iron Man แต่จะใกล้กับ iron lung มากกว่า
การทำต้นแบบแทบจะฟรีไปแล้วจริง ๆ แค่ให้ AI ลองทางเลือกด้านสถาปัตยกรรมหรือสไตล์ทีละแบบ แล้วดูว่าเราชอบโค้ดแบบไหนมากกว่า
การเขียนใหม่และออกแบบใหม่ก็ใช้ได้ผลดีพอสมควร ฉันเลยชอบแพตเทิร์นที่ให้ vibe coding สร้างหลายแนวทางขึ้นมาก่อน แล้วค่อยเลือกแนวทาง เพิ่มการทดสอบ และทำรีแฟกเตอร์ครั้งใหญ่เพื่อให้ดูแลรักษาได้
ทักษะที่ต้องใช้ตรงนี้คือการรู้ว่าอะไรคือสถาปัตยกรรมที่ดี และรู้วิธีออกแบบ prompt กับการตรวจสอบว่าระดับการทดสอบแบบไหนจะทำให้วงจร feedback เร็วขึ้น หรือทำให้การเปลี่ยนแปลงจาก LLM อ่านง่ายขึ้น
มันไม่ได้ทำตามครบ 100% แต่ผลที่ได้ก็ดีพอ และจากนั้นฉันก็รีวิวสิ่งที่สร้างออกมา ปรับให้เข้ากับเทมเพลต และถ้ามีไอเดียไหนถูกใจก็ใส่กลับเข้าไปในเทมเพลตทักษะอีกที
เรื่องนี้ใช้ได้ไม่ใช่แค่กับสถาปัตยกรรมระบบ แต่รวมถึงแบ็กเอนด์ ฟรอนต์เอนด์ การทดสอบแบบ end-to-end และการเขียนเอกสารด้วย
เพราะฉันรู้เป้าหมายที่ต้องการ วิธีจัดโครงสร้างโค้ด และวิธีเขียนการทดสอบอยู่แล้ว LLM จึงช่วยลดความน่าเบื่อของการต้องทำตามเทมเพลตเดิมซ้ำ ๆ
แต่ก็ยังต้องมี การกำกับดูแลอย่างต่อเนื่อง และบางครั้งมันก็ไปแตะส่วนที่ห้ามแตะหรือไม่ทำตามคำสั่ง อีกทั้งปริมาณผลลัพธ์อาจมากจนน่วมได้ ดังนั้นการรีวิวโดยเพื่อนร่วมงานก็ยังจำเป็น
ยิ่งฉันใช้เครื่องมือ AI เร่งงานมากขึ้น ก็ยิ่งรู้สึกชัดว่าการปล่อยซอฟต์แวร์ที่ใช้งานได้จริงนั้นเป็น งานช่างฝีมือ ที่ยากแค่ไหน
Claude Code กับ Codex อาจเขียนโค้ดส่วนใหญ่ให้ได้ แต่ความรู้ทางเทคนิคที่ต้องใช้ในการตัดสินใจว่าจะสร้างอะไรและสร้างอย่างไรนั้นยังมหาศาล
ตอนนี้ฉันกำลังสร้างระบบที่รันแอป HTML+JS แบบกำหนดเองได้อย่างปลอดภัยภายใน iframe sandbox ของแอปพลิเคชันขนาดใหญ่ คล้าย Claude Artifacts และการจะเข้าใจว่าทำไมสิ่งนี้ถึงมีประโยชน์และเป็นไปได้ ต้องมีความรู้ลึกเรื่อง sandboxing, ภัยคุกคามด้านความปลอดภัย, โมเดลความปลอดภัยของเบราว์เซอร์ และฟีเจอร์แพลตฟอร์มหลากหลายที่วิวัฒน์มานานหลายสิบปี
ถ้าไม่มีความเข้าใจเหล่านี้ คนที่ทำแค่ vibe coding ก็แทบไม่มีทางสร้างสิ่งแบบนี้ให้เกิดขึ้นได้ ไม่ว่า LLM จะช่วยชี้ทางแค่ไหนก็ตาม
เวลาฉันเห็นนักพัฒนาพูดว่าจะเลิกสายงานเพราะ AI ก็รู้สึกเศร้า เพราะนี่คือช่วงเวลาที่ประสบการณ์เชิงลึกทางเทคนิคที่สั่งสมมา กลับมีคุณค่ามากกว่าที่เคย
ฉันชอบเขียนโค้ด แต่ไม่ชอบการหาคาถาวิเศษเพื่อให้เครื่องเขียนโค้ดที่ถูกต้อง หรือคอยแก้ตอนมันทำผิด
ถ้ารู้ว่าอนาคตจะเป็นแบบนี้ ฉันคงไม่เข้ามาในสายนี้
อีกอย่าง วิธีที่เครื่องมือเหล่านี้ถูกสร้างขึ้น ในมุมฉันคือ การขโมย และฉันมองว่าการใช้เครื่องมือที่ถูกสร้างขึ้นอย่างไร้จริยธรรมก็เป็นเรื่องไร้จริยธรรมเช่นกัน
แถมยังไม่แน่ว่าฉันจะได้ค่าตอบแทนมากขึ้นสำหรับทักษะที่มีมูลค่าสูงกว่าไหม และโดยรวมแล้วค่าแรงวิศวกรก็กำลังลดลง
ถ้านายจ้างเป็นฝ่ายเอามูลค่าทั้งหมดไป ฉันก็ไม่มีเหตุผลอะไรจะต้องสนใจว่าตัวเองสร้างมูลค่าเพิ่มได้มากขึ้น
วิศวกรซอฟต์แวร์รอบตัวหลายคนสรุปไปแล้วว่า AI จะมาแย่งงาน และเริ่มคิดเปลี่ยนอาชีพกันแล้ว แต่ฉันยังรู้สึกว่ามันเร็วเกินไปที่จะตัดสิน
prompt ที่ฉันใช้ล้วนมีความเป็นเทคนิคสูงมาก และยากจะจัดการให้ได้ผลด้วยการคุยกับเอเจนต์อย่างเดียวโดยไม่มีความเชี่ยวชาญของตัวเอง
ทุกครั้งที่ทำงานนอกขอบเขตความชำนาญ มันไม่ได้เร็วอย่างที่คนจินตนาการ และ ความเชี่ยวชาญ ก็ช่วยรักษาความเป็นระเบียบได้มาก
ถ้าพวกเขาเชื่อว่า AI แทนวิศวกรได้ เรื่องก็มีแนวโน้มจะไหลไปแบบนั้น และผู้บริหารเองก็มักไม่ค่อยรู้ด้วยซ้ำว่าคุณภาพที่ดีคืออะไร
พวกเขามองแต่รายได้กับกำไร ดังนั้นถึงจะจริงที่ประสบการณ์เชิงเทคนิคลึก ๆ มีค่ามากขึ้น แต่ความจริงที่น่าเศร้าคือโลกอาจไม่เป็นแบบนั้น
น่าจะค่อย ๆ ถูกผลักไปสู่ภาวะว่างงานทีละนิดมากกว่า
LLM ก็ไม่ได้เปลี่ยนความจริงข้อนี้ในโลกจริง
นั่นจึงเป็นเหตุผลว่าทำไมผลิตภัณฑ์มูลค่าสูงถึงไม่ได้เพิ่มขึ้นแบบระเบิด และที่จริงแล้วการสร้างผลิตภัณฑ์ที่สร้างมูลค่าได้นั้นยากมาก มากจริง ๆ
ท่าทีที่มองข้ามเรื่องนี้เพียงเพราะมี LLM อยู่ ฟังดูน่าขันสำหรับฉัน
เรื่องที่ว่า “เครื่องมือ AI ใกล้เคียงกับชุด Iron Man” นั้น มีรีโพซิทอรีหนึ่งที่น่าสนใจบน GitHub ซึ่งมีดาว 63,600 ดวง
ผู้พัฒนาเป็นผู้มีส่วนร่วมยอดนิยมอันดับ 1 ประจำสัปดาห์บน GitHub แต่ตัวแอปพลิเคชันกลับดูไม่ตรงกับที่อธิบายไว้ และดูเหมือนนักพัฒนาเองก็ยังตอบไม่ชัดว่ามันเป็นของจริงหรือไม่
สุดท้ายมันดูเหมือนเป็นเพียงผลลัพธ์ LLM ที่เละเทะ ซึ่งแสดงให้เห็นว่า มีแค่ชุดก็ไม่ได้ทำให้เป็น Iron Man ได้
https://github.com/ruvnet/RuView
https://github.com/trending/developers?since=weekly
https://github.com/deletexiumu/wifi-densepose
AI สร้างโปรเจ็กต์ที่ใช้งานไม่ได้ แล้ว AI ก็พิสูจน์อีกทีว่ามันใช้งานไม่ได้ ช่างเป็นโลกใหม่อันน่าพิศวงจริง ๆ
มีหลายโปรเจ็กต์ที่ดูเหมือนเป็นแค่ผลลัพธ์จาก AI จำนวนมหาศาล ราวกับกำลังท่วมโครงสร้างพื้นฐานของ GitHub จึงไม่ยากที่จะเข้าใจว่าทำไม GitHub ถึงกำลังลำบาก
ในฐานะนักคณิตศาสตร์ สัปดาห์ที่แล้วฉันเองก็มี โมเมนต์แบบ Iron Man เหมือนกัน
ฉันทำวิจัยคณิตศาสตร์ร่วมกับเพื่อนสองคนที่เป็นอาจารย์มาหลายปี และลองใช้ ChatGPT สำรวจบางส่วนของงานวิจัย
พอมีไอเดียขึ้นมา ฉันก็โยนให้ GPT ดู ให้มันเขียนทฤษฎีบทที่พิสูจน์ได้ง่าย แล้วให้สร้างบทพิสูจน์เป็น LaTeX โดยฉันตรวจบทพิสูจน์อย่างระมัดระวังทุกครั้ง
จากนั้นก็ให้มันสร้างโค้ด Mathematica แล้วใช้ผลลัพธ์ที่รันได้มาตรวจสอบบทพิสูจน์หรือหาไอเดียเพิ่มเติม ก่อนวนลูปกลับไปอีก
ตรงกลางมีช่วงหนึ่งที่ฉันติดเรื่องการหาขอบเขตบนของนิพจน์บางตัวเพราะยังเข้าใจไม่พอ การกลับไปไล่อนุพันธ์เองด้วยกระดาษกับดินสอช่วยได้มาก
กระบวนการทั้งหมดเร็วกว่าเวลาทำโดยไม่มี GPT ประมาณ 10 เท่า และไม่กี่ชั่วโมงต่อมาก็ได้ทั้งบทพิสูจน์ที่ถูกต้องยาวราว 20 หน้า พร้อมโค้ดที่จำเป็นสำหรับการจำลองเชิงตัวเลขที่เกี่ยวข้อง
ฉันมองว่า AI ไม่ใช่ตัวคูณความสามารถ แต่เป็น เครื่องมือที่ช่วยลดเวลา
สำหรับนักพัฒนาที่ประสบการณ์น้อย มันช่วยลดเวลาตั้งแต่ต้นโปรเจ็กต์ได้ทันที แต่การตัดสินใจช่วงแรกอาจย้อนมาทำร้ายภายหลัง
สำหรับนักพัฒนาระดับซีเนียร์ ถ้าอธิบายให้ดีพอ มันก็ทำตัวเหมือนนักพัฒนาระดับจูเนียร์หรือมิดเลเวลที่ลงมือทำงานภายในขอบเขตความสามารถได้ทันที
แต่ถ้าโยนการตัดสินใจสำคัญให้ มันอาจผิดแบบผิดหมดจดหรือผิดแบบละเอียดอ่อนก็ได้ และโดยเฉพาะข้อผิดพลาดแบบละเอียดอ่อนนี่แหละที่อันตรายที่สุดเพราะจับได้ยาก
ถ้าซีเนียร์วางแนวทางได้ดีและรู้ทันปัญหา ความเร็วในการพัฒนาจะเพิ่มขึ้นแบบเหลือเชื่อจริง ๆ
ถ้ามีใจอยากเรียนรู้ AI ก็สามารถลดเวลาที่ใช้ในการขัดเกลาและฝึกทักษะได้ และด้วยเหตุนี้มันอาจกลายเป็น ตัวคูณความสามารถ จริง ๆ ก็ได้
ตอนนี้ฉันใช้ AWS เก่งกว่าตอนที่เคยใช้มาหลายปีเสียอีก และใช้ command line ได้มีประสิทธิภาพมากขึ้น
แม้เดิมข้อมูลเหล่านี้จะหามาได้อยู่แล้ว แต่ใช้เวลานานเกินไป พอสเกลเวลาที่ใช้ไปถึงคำตอบที่ต้องการลดลงมาก ผลงานจริงและความสามารถก็เปลี่ยนตามไปด้วย
ฉันอยากรันเว็บเซิร์ฟเวอร์เล็ก ๆ บน Raspberry Pi เลยให้ Gemini เขียนทั้งโค้ดและสคริปต์ Bash สำหรับตั้งค่าเพื่อรันผ่าน systemd service
มันเป็นงานที่ฉันทำเองได้แม้ตอนง่วง แต่ก็ต้องใช้เวลาและสมาธิ ซึ่งในช่วงเวลาที่ฉันนั่งเขียนคอมเมนต์นี้ มันกลับสร้างสิ่งที่ฉันต้องการได้พอดีเป๊ะ
แม้ดูแยกเดี่ยวจะไม่ใช่เรื่องใหญ่ แต่เพราะมีหน้าที่อื่นจนหมดพลังและผัดวันประกันพรุ่งมาตลอด ตอนนี้ฉันเลยเริ่มจัดการงาน home automation ที่ค้างไว้ได้
ใช่เลย AI ไม่ได้ทำให้ความสามารถหรือพรสวรรค์ล้วน ๆ กลายเป็นของล้าสมัย ตรงกันข้ามมันกลับยิ่งทำให้สิ่งเหล่านั้นมีค่ามากขึ้น
ความรู้ทางเทคนิคเชิงลึกสร้าง แรงงัด ในโลกจริงได้มากกว่า เพราะมีจุดให้เอา AI ไปใช้ประโยชน์ได้มากขึ้น
เพราะตระหนักแบบนี้ ฉันจึงเลิกพึ่งบริการคลาวด์อย่าง AWS แล้วหันมาสร้างดาต้าเซ็นเตอร์ home lab ของตัวเองเพื่อโฮสต์เทค SaaS ของฉัน
คุณค่าของการเรียนรู้พื้นฐานด้าน networking, DevOps และฮาร์ดแวร์เซิร์ฟเวอร์ กลับถูก AI ทำให้เอาไปใช้ได้เร็วขึ้นและกว้างขึ้น
ถ้าเป็นเมื่อก่อน การเรียน RouterOS เพื่อคอนฟิกเราเตอร์ Mikrotik ระดับดาต้าเซ็นเตอร์อาจกินเวลาหลายชั่วโมงหรือหลายวัน แต่ด้วย Claude มันกลายเป็นงาน 20 นาที และฉันก็ได้เรียนรู้เรื่องการตั้งค่า routing ไปมากด้วย
มันทำให้ฉันมีอำนาจควบคุมเฉพาะตัวในแบบที่คงไม่มีถ้าใช้แต่คลาวด์ และถึงขั้นทำให้อยากลองสร้าง ระบบปฏิบัติการของตัวเอง ซึ่งก่อนยุค AI ฉันคงไม่กล้าคิดด้วยซ้ำ
ตอนที่มีเครื่องมือไฟฟ้าและปืนยิงตะปูเข้ามา คนก็คงคิดคล้ายกัน แต่ผลคือบ้านสร้างได้เร็วขึ้นมากก็จริง ทว่าแรงกลับลดลง คุณภาพงานก็ตกลง และมูลค่าของทักษะกับประสบการณ์ก็ลดลงอย่างมาก
งานฉาบปูนผนังเคยเป็นงานฝีมือค่าแรงสูง และเมื่อ drywall เข้ามา คนก็คงคิดว่าจะได้ใช้เวลาน้อยลงกับผนังเรียบ ๆ น่าเบื่อ แล้วไปทุ่มเวลาให้มุมและงานปูนตกแต่งมากขึ้น แต่สุดท้ายของตกแต่งเหล่านั้นก็หายไป
ของตกแต่งใช้เวลามากเกินไปเมื่อเทียบกับผนังส่วนที่เหลือ และคนที่ยังรักษาหรือเรียนทักษะนั้นไว้ก็ยังต้องการค่าตอบแทนที่ decent
แม้แต่งาน drywall ธรรมดา ความคาดหวังด้านปริมาณงานก็สูงขึ้น ค่าแรงกลับหยุดนิ่ง และทุกวันนี้รอยต่อยังมักทำออกมาแย่ สิ่งที่ขายได้จริงมีแค่ความเร็วในการผลิตกับการไม่บ่นเท่านั้น
“ช้างในห้อง” หมายถึงประเด็นใหญ่ที่ไม่มีใครพูดถึง แต่เรื่อง AI นั้นทุกคนกำลังพูดถึงอยู่แล้ว
ชื่อที่ดีกว่าน่าจะเป็น “ทำไม AI ถึงขยายทักษะของนักพัฒนาแทนที่จะมาแทนที่” มากกว่า
มันเป็น “ช้างในห้อง” ในความหมายที่ว่า จนถึงจุดนั้นแคมเปญการตลาดดังกล่าวยังไม่ได้พูดถึง AI เลย
ลิงก์นี้เป็นลิงก์สำหรับอ่านบนเว็บในกรณีที่แสดงผลในอีเมลไคลเอนต์ได้ไม่ดี จึงไม่ได้ตั้งใจเขียนเพื่อผู้อ่านวงกว้างกว่านั้น
ถ้าต้องใช้จำนวนนักพัฒนาน้อยลงเพื่อทำงานเดิมให้สำเร็จ คนจำนวนมากก็จะตกงาน
เงินเดือนของคนที่เหลืออยู่ก็น่าจะลดลงด้วย
ถ้าคุณคิดว่าสามารถจ่ายแค่เงินเดือนจูเนียร์บวกค่าสมาชิก AI แล้วได้ “ผลลัพธ์แบบเดียวกัน” ทำไมถึงจะยอมจ่ายเงินเดือนซีเนียร์ล่ะ
ดูเหมือนนักพัฒนาซอฟต์แวร์กำลังจะเจอช่วงเวลายากลำบาก ฉันทำงานมา 15 ปีแล้วแต่ก็ไม่ได้รู้สึกตื่นเต้นเลย
พูดตามตรงฉันกำลังคิดเรื่อง reskill ไปสู่อุตสาหกรรมอื่น และถึงจะได้เงินน้อยลง การหนีความวุ่นวายนี้ออกไปอาจดีกว่า
โดยรวมฉันเห็นด้วยกับ Josh แต่บทความจำนวนมากที่พูดถึงประสบการณ์ของซีเนียร์กับจูเนียร์เวลาทำงานร่วมกับ AI ฟังดูเพ้อเจ้อไปหน่อย
เป็นความจริงที่ซีเนียร์ได้ผลลัพธ์ที่ดีกว่าจากเครื่องมือ AI และจูเนียร์ลำบากกว่า แต่สิ่งที่เปลี่ยนไปมีแค่ว่าช่องว่างนั้นถูก ขยาย ให้ใหญ่ขึ้นเท่านั้น
สิ่งที่คนไม่ค่อยพูดถึงคือ จูเนียร์สามารถเรียนรู้ในแทบทุกสาขาได้เร็วขึ้นมากด้วยผู้ช่วยวิจัยแบบ AI และสำหรับคนที่มีแรงจะขุดลึก ความเร็วในการเติบโตเป็นผู้เชี่ยวชาญก็เพิ่มขึ้นด้วย
ฉันถามเครื่องมือ AI ไม่ใช่แค่ “ช่วยสร้างให้หน่อย” หรือ “ช่วยแก้ให้หน่อย” แต่ยังถามว่า “สิ่งนี้ทำงานอย่างไร”, “ช่วยแนะนำเครื่องมืออื่นได้ไหม” ด้วยบ่อยพอ ๆ กัน
หลายคนมอง AI เป็นแค่ความสัมพันธ์แบบ input/output แต่ไม่ว่าจะมี AI หรือไม่ กระบวนการลองผิดลองถูกและปรับแต่งระหว่างทางก็สำคัญเสมอ
มือใหม่อาจทำแบบนี้ไม่ได้ในช่วงแรก แต่เดิมก็เป็นแบบนั้นอยู่แล้ว และฉันคิดว่าคนที่เก่งจริงจะผ่านช่วงที่ทำไม่เป็นไปได้เร็วกว่าที่ฉันเคยผ่านมามาก
อย่างไรก็ตาม ความพึงพอใจฉับพลันที่ AI มอบให้อาจทำให้กระบวนการผ่าน แรงเสียดทาน อ่อนแรงลง และคนที่เป็น AI native อาจไม่เข้าใจหรือไม่เห็นคุณค่าของแรงเสียดทานนั้น
จากสิ่งที่เห็นในระดับมหาวิทยาลัย ก็ยิ่งยากจะคาดหวังแบบนั้น
จุดนี้ถูกกลบด้วยความไม่พอใจต่อคำกล่าวอ้างเรื่อง vibe coding ห่วย ๆ หรือความเร็ว 10 เท่า
การเรียนรู้ที่สำคัญที่สุดไม่ได้เกิดขึ้นตอนเราถามแล้วได้คำตอบทันที แต่เกิดตอนพยายามหาคำตอบ ล้มเหลวหลายครั้ง คิดอย่างลึกซึ้ง พักสั้น ๆ แล้วกลับมาแก้ปัญหาได้
ความรู้แบบนั้นมีค่ามาก เพราะมันไม่ให้แค่คำตอบ แต่ยังบอกถึงเส้นทางผิดที่ควรหลีกเลี่ยงในอนาคต และสร้างความเชื่อมั่นในกระบวนการคิดของตัวเองด้วย
ถ้าคนรุ่นถัดไปข้ามขั้นตอนนี้ไป พวกเขาจะเริ่มคิดว่าคำตอบควรถูกหาเจอได้ง่าย และจะพึ่งพา AI มากขึ้นเรื่อย ๆ พร้อมกับมั่นใจในสมองของตัวเองน้อยลง
ในกรณีนี้ การอ่านผลลัพธ์จาก LLM อย่างเดียวไม่ได้ทำให้ได้รับการฝึกฝนอย่างมีสาระ
ฉันยังไม่เคยเห็นใครใช้เครื่องมือ AI แล้วขุดลึกลงไปกว่าเดิมเลย
นักพัฒนาซีเนียร์เรียนรู้มาจากการปีนข้ามภูเขาของโปรเจ็กต์ล้มเหลวนับไม่ถ้วนที่ตัวเองเคยสร้าง
ถ้าใครเสนอให้ทำฐานข้อมูลแบบ flat file หรือสร้างสถาปัตยกรรมไมโครเซอร์วิสด้วย Lambda มากกว่า 50 ตัว ฉันรู้ทันที เพราะเคยลองมาแล้ว และรู้ว่าถึงจะทำได้ในทางเทคนิคก็ไม่ควรทำ
สำหรับฉัน AI เหมือนทำให้วิ่งไปในทิศทางที่ถูกต้องด้วยความเร็ว 100 ไมล์ต่อชั่วโมง แต่จูเนียร์หลายคนกำลังขับด้วยความเร็ว 100 ไมล์ต่อชั่วโมงพุ่งลงทะเลหรือชนกำแพง
เหมือนที่ AWS ทำให้เราโง่ลงจนเกิดจูเนียร์ที่ไม่รู้จัก reverse proxy และเหมือนที่ภาษาระดับสูงทำให้คนไม่เข้าใจการจัดการหน่วยความจำ AI ก็เป็นเพียงห่วงโซ่ข้อถัดไป
อีก 10 ปีข้างหน้า ฉันคิดว่านักพัฒนาส่วนใหญ่คงอ่านโค้ดไม่ออกแล้ว
วิศวกรซอฟต์แวร์จำนวนมาก หรืออาจจะส่วนใหญ่ เป็นผู้เชี่ยวชาญใน codebase ของตัวเองอยู่แล้ว ดังนั้นวิศวกรไม่น้อยจึงได้คุณค่าสูงจาก AI
สิ่งที่ยังไม่ชัดคือ เมื่อวิศวกรหนึ่งคนเขียนโค้ดได้มากขึ้น จำนวนผู้พัฒนาจะลดลงหรือไม่ หรือจะกลายเป็นว่ามี ซอฟต์แวร์มากขึ้น ในด้านที่แต่เดิมมักถูกดองไว้ เช่น UX, การทดสอบ, developer experience และเอกสาร
หรือบางทีอาจเป็นแค่การยกระดับเส้นฐานขึ้นเท่านั้น
ตอนคุยกับ Claude ฉันสังเกตเห็นบางอย่างแบบนี้
ฉันพูดว่า “ไม่น่าทึ่งเหรอที่ X ดีกว่า Y” แต่ Claude กลับตอบว่าเป็น “คำวิจารณ์ที่มีมุมมองลึกซึ้ง” พร้อมแจกแจงเหตุผลอย่างดีว่าทำไม Y ถึงดีกว่า X
ตัวคำตอบนั้นดี รอบคอบ และมีเหตุผล แต่กลับตรงข้ามกับสิ่งที่ฉันตั้งใจจะพูด ฉันเลยต้องแก้ว่า “ไม่ใช่ ฉันกำลังพูดข้ออ้างที่สวนทางสัญชาตญาณว่า X ดีกว่า Y”
จากนั้น Claude ก็เปลี่ยนมาบอกว่า “ใช่ X ดีกว่า Y” พร้อมสรุปเหตุผลไว้อย่างเป็นระบบอีกครั้ง
มันเหมือนมีมอัจฉริยะฉลาดแต่ก็งี่เง่าในเวลาเดียวกัน
บางทีก็แกว่งไปมาระหว่าง “มันก็แค่ autocomplete” กับ “ไม่ใช่ มันมีโมเดลอยู่ในใจ” แต่สุดท้ายมันก็เหมือน หอสมุดแห่งบาเบล คือมีความอัจฉริยะทั้งหมดของโลกอยู่ก็จริง แต่จะใช้ประโยชน์ได้ก็ต่อเมื่อมีคีย์ดัชนีที่ถูกต้องเท่านั้น
ในการประมาณครั้งแรก LLM ทำนายคำตอบที่ผู้ใช้ต้องการหรือคาดหวังจะได้
คำตอบต่อ prompt แรกจึงออกมาตลก เพราะ LLM เข้าใจผู้ใช้ผิดทั้งหมด และทำนายจากสิ่งที่มันคิดว่าผู้ใช้เขียน
คำตอบต่อ prompt ที่สองยิ่งแสดงให้ชัดว่าเป้าหมายของ LLM คือการทำนายสิ่งที่ผู้ใช้ต้องการหรือคาดหวัง
หนึ่งในตัวกระตุ้นสำคัญของอาการหลอนคือจังหวะที่ความคาดหวังของผู้ใช้ตามที่ LLM ตีความไม่ตรงกับความจริง และ LLM ก็พยายามทำให้ความจริงสอดคล้องกับความคาดหวังที่มันเข้าใจ
วิธีที่ดีอย่างหนึ่งในการลดอาการหลอนคือการลด ข้อความเชิงยืนยัน ใน prompt ให้มากที่สุด
ประโยค “ไม่น่าทึ่งเหรอที่ X ดีกว่า Y” มีข้อยืนยันชัดเจนอยู่ และแม้ LLM จะเข้าใจทิศทางผิด แต่มันเข้าใจว่ามีข้อยืนยันอยู่ จึงพยายามให้เหตุผลว่าทำไมความจริงจึงสอดคล้องกับข้อยืนยันนั้น
กรณีทนายอ้างอิงคำพิพากษาปลอมแล้วเจอปัญหาก็คล้ายกัน ดังนั้น “ช่วยหาคำพิพากษาที่แสดง X” จึงเสี่ยงกว่า และ “มีคำพิพากษาอะไรเกี่ยวกับ X บ้าง” เป็นจุดเริ่มต้นที่ดีกว่า