การเขียนโค้ดด้วย AI
(geohot.github.io)- AI สำหรับการเขียนโปรแกรม มีโครงสร้างบทบาทคล้ายกับคอมไพเลอร์แบบเดิม
- พรอมป์ต์ภาษาอังกฤษ ในฐานะภาษาสำหรับการเขียนโปรแกรมมีลักษณะที่ไม่แม่นยำและไม่มีประสิทธิภาพ
- ผลของ AI ในด้าน การเพิ่มผลิตภาพ มีแนวโน้มที่จะถูกพูดเกินจริงหรือถูกรับรู้ผิดจากความเป็นจริง
- เครื่องมือ AI เปลี่ยนกระบวนการพัฒนา แต่ นวัตกรรมที่แท้จริง อาจเกิดจากภาษาและเครื่องมือที่ดีกว่า
- การนำ LLM มาใช้ไม่ได้หมายถึงการแทนที่นักพัฒนา แต่สะท้อนข้อจำกัดของสภาพแวดล้อมการพัฒนาในปัจจุบันมากกว่า
ความคล้ายคลึงกันระหว่าง AI กับคอมไพเลอร์
- ผู้เขียนบอกว่าเมื่ออายุมากขึ้นก็เลิกพยายามโน้มน้าวผู้อื่นแล้ว
- เน้นว่าหลายคนไม่ได้สนใจ ความจริง แต่เลือกยึดถือความเชื่อที่เป็นประโยชน์ต่อตัวเอง
- วิจารณ์ผู้ที่ยืนยันว่า 'Perception is reality(การรับรู้ก็คือความจริง)'
- ชี้ให้เห็นว่า เงินหลายพันล้านดอลลาร์ ที่ลงทุนในรถยนต์ขับเคลื่อนอัตโนมัติเป็นความสูญเปล่าที่เกิดจากความเชื่อที่ผิด
- มุมมองที่เชื่อว่า AI เขียนโค้ดได้ มีความคล้ายกับมุมมองที่คิดว่าคอมไพเลอร์เป็นผู้เขียนโค้ด
AI สำหรับการเขียนโค้ดเป็นโมเดลแบบเดียวกับคอมไพเลอร์
- อธิบายข้อโต้แย้งว่าโมเดลที่เหมาะสมที่สุดสำหรับ AI ด้านการเขียนโปรแกรมคือ คอมไพเลอร์
- ผู้ใช้ป้อนพรอมป์ต์(โค้ด) แล้วรับผลลัพธ์ที่ถูกคอมไพล์ออกมา
- แม้จะต่างกันตรงที่ป้อน Frprompt เป็นภาษาอังกฤษ แต่ภาษาอังกฤษก็มีข้อเสียหลายอย่าง เช่น ขาดความชัดเจน และไม่มีสเปก
- เมื่อต้องทำงานใหม่หรือซับซ้อน ท้ายที่สุด ความยืดยาวของพรอมป์ต์ ก็จะเพิ่มขึ้น
- เอาต์พุตของ AI มีลักษณะ ไม่เป็นเชิงกำหนด และการเปลี่ยนส่วนหนึ่งของพรอมป์ต์อาจส่งผลต่อผลลัพธ์ทั้งหมด
มุมมองเชิงวิพากษ์ต่อ AI สำหรับการเขียนโค้ด
- เหตุที่ AI สำหรับการเขียนโค้ดดูเหมือนเป็นเรื่องดี เป็นเพราะ เครื่องมือ ภาษา และไลบรารีในปัจจุบันมีคุณภาพย่ำแย่
- เทคโนโลยี "AI" ทำให้สามารถมีเครื่องมือ ค้นหา การเพิ่มประสิทธิภาพ และการดึงรูปแบบ ที่ดีกว่าเดิมได้
- ในความเป็นจริง ผู้ที่เขียนโค้ดยังคงเป็น ตัวโปรแกรมเมอร์เอง เพียงแต่ภาษาในการเขียนโค้ดเปลี่ยนไปเท่านั้น
- ถ้าเป็นบริษัทที่ LLM สามารถแทนที่นักพัฒนาได้ ก็หมายความว่า โค้ดเบสของบริษัทและเกณฑ์การจ้างงานอยู่ในระดับต่ำมาก
- AI สามารถค่อย ๆ เข้ามาแทนงานบางส่วนได้ เช่นเดียวกับคอมไพเลอร์หรือสเปรดชีต
AI เป็นเครื่องมือ และท้ายที่สุดยังต้องการภาษา·ไลบรารีที่ดีกว่า
- เน้นว่าจำเป็นต้องมีการคิดและความระมัดระวังอย่างมากต่อ มุมมองที่มอง AI เป็นเครื่องมือ
- การลงทุนกับความคาดหวังที่ผิดหรือภาพลวงตากำลังก่อให้เกิดความสูญเปล่ามูลค่าหลายพันล้านดอลลาร์
- กล่าวถึงการตอบสนองเกินจริงของตลาดต่อเครื่องมือเพิ่มผลิตภาพลวง ๆ อย่าง “vibe coding”
- มี ความเข้าใจผิด ว่า AI เพิ่มผลิตภาพได้ 20% แต่มีการอ้างถึงผลการศึกษา(งานวิจัย)ว่าจริง ๆ แล้วช้าลง 19%
- ความก้าวหน้าที่แท้จริงอาจเกิดจาก นวัตกรรมด้านภาษาโปรแกรม คอมไพเลอร์ และไลบรารี
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ฉันอายุเกือบ 50 แล้ว และเขียนโค้ดเป็นอาชีพมาตั้งแต่ช่วงปลายยุค 90 ฉันมองเห็นโปรเจกต์ในหัวได้ทันทีและรู้ชัดว่าต้องสร้างอะไร ได้เงินเดือนค่อนข้างสูงด้วย ภายนอกอาจดูเหมือนเป็นต้นแบบของคนต่อต้าน AI แต่จริง ๆ ไม่ใช่ ฉันสร้างอะไรก็ได้ แต่ก็มักเบื่อกับงานพื้นฐานสารพัด เลยชอบมากที่ใช้ AI ช่วยพาผ่านส่วนที่น่าเบื่อได้เร็ว แล้วไปโฟกัสกับงานแกนหลักที่ฉันชอบ AI สำหรับการพัฒนานั้นคล้ายกับการบอกความคิดไม่กี่ประโยคให้วิศวกรระดับระหว่าง junior กับ mid-level ไปทำงานหนึ่งชั่วโมงให้เรา แน่นอนว่ามีประเด็นจริงจังว่ามันอาจทำให้ junior ตัวจริงไม่ได้เติบโต จนทำให้จำนวน senior ในอนาคตลดลง แต่ผมมองว่านั่นเป็นอีกประเด็นหนึ่ง
คุณบอกว่าคุณใช้ AI จัดการส่วนที่น่าเบื่อแบบรวดเร็ว แต่ในบรรดา senior ที่มีประสบการณ์มาก ก็มีคนที่กลับกลัวส่วนที่ยากและเลยมีทัศนคติลบต่อ AI นักพัฒนาหลายคนหาความปลอดภัยทางใจจากส่วนที่ง่ายและน่าเบื่อ พอมี AI งานทั้งหมดอาจกลายเป็นความยากต่อเนื่องไม่หยุด สำหรับ senior ที่มีแค่อายุงานแต่ฝีมือไม่ถึง การต้องรับแต่งานท้าทายติด ๆ กันอาจทำให้หมดไฟเร็ว บริษัทต่าง ๆ ใช้ AI เพราะอยากเร่งความเร็วอย่างเดียว แต่กลับมองข้ามว่าคนต้องมีเวลาพักทางความคิด ถ้าเหลือแต่งานหนัก ๆ มันไม่ดีต่อคนแน่ ๆ แน่นอนว่านักพัฒนาที่เบื่อกับงานซ้ำ ๆ ง่าย ๆ อาจกลับมามีไฟได้เมื่อทำงานกับ AI สุดท้ายแล้วต้องใช้วิธีที่ต่างกันไปในแต่ละคน
ฉันอายุน้อยกว่าคุณนิดหน่อย แต่คิดเหมือนกันแทบทั้งหมด อาจจะหนักกว่าด้วยซ้ำ ฉันไม่ได้รู้สึกว่าสนุกกับการเขียนโค้ดเพื่อทำไอเดียที่น่าสนใจให้เป็นจริง แต่รู้สึกว่าสนุกกับการคิดไอเดียและทดลองมันมากกว่า ดังนั้นการเขียนโค้ดจึงเป็นสิ่งที่ทำเพราะจำเป็น ไม่ใช่สิ่งที่อยากทำโดยเนื้อแท้ ถ้าอยากทำไอเดียให้เกิดขึ้นจริงก็เลี่ยงไม่ได้ที่จะต้องเขียนโค้ด AI เป็นคู่คิดระดมสมองที่ยอดเยี่ยมมาก ถ้าขอไม่ให้มันประจบ มันจะชี้ตรง ๆ เลยว่าฉันกำลัง overengineering ตรงไหน มันดีบักก็เก่งมาก ฉันเลยอธิบายกับคอมพิวเตอร์เป็นคำพูดเพื่อระดมสมองเรื่องสถาปัตยกรรมและวิธีการ จากนั้นทำสเปก แล้วให้ AI ไปลงมือเขียน ถ้าความคิดฉันผิด ก็วนปรับกับ AI อย่างรวดเร็ว การวนซ้ำเร็วมากจนไม่ต้องกลัวพลาด เมื่อก่อนถ้าออกแบบผิดต้องแก้ทั้งโค้ดเบสเลยก็เลยมักจำใจอยู่กับมัน แต่ตอนนี้ด้วยเครื่องมือ Agentic coding การเปลี่ยนทั้งโค้ดเบสก็ไม่ใช่ปัญหา ฉันเคยเข้าไปในโดเมนเทคโนโลยีใหม่ทั้งที่ยังไม่ใช่ผู้เชี่ยวชาญ แต่ AI ช่วยให้เข้าไปได้อย่างมีประสิทธิภาพและพัฒนาฝีมือได้เร็ว พูดตรง ๆ ตอนนี้ฉันมีความสุขกับชีวิตโปรแกรมเมอร์มากที่สุดแล้ว และเครื่องมือเหล่านี้ก็ดีขึ้นทุกสัปดาห์ บางทีก็ดีขึ้นหลายครั้งต่อสัปดาห์ด้วยซ้ำ
ตรงกับประสบการณ์ของผมเป๊ะ ผมก็อายุงานใกล้เคียงกัน ผมใช้ AI อย่างหนักทั้งกับงานส่วนตัวและงานบริษัท อย่างแรก AI ทำหน้าที่เป็นคู่คิดเรื่องไอเดียที่มีอคติน้อยกว่า วงจร feedback ที่เร็วและการตรวจสอบทิศทางเป็นสิ่งจำเป็นมากสำหรับผม อย่างที่สองคือมันช่วยประหยัดเวลาพิมพ์และเวลาโดยรวม งาน “พื้นฐาน” ถ้าโยนให้ครั้งเดียว มันทำได้สมบูรณ์แบบอย่างน้อย 80% แม้ไม่ถึง 100% แต่เวลาที่ประหยัดได้นั้นมากกว่ามากจนคุ้มแบบชัดเจน เวลาใช้ AI ผมมักตั้ง guardrail ไว้เสมอ ส่งคำสั่งให้เจาะจงและละเอียดที่สุดเท่าที่ทำได้ และติดนิสัยต้องตรวจงานทุกชิ้นด้วยตัวเองเสมอ
ผมประสบการณ์น้อยกว่าราว 10 ปี แต่ยืนอยู่จุดคล้ายกัน แค่ผมไม่ค่อยอินเท่าไร พอส่วนไหนเริ่มน่าเบื่อ ผมก็มักจะเจอว่าการทำให้มันเป็นอัตโนมัติหรือทำให้เป็นทั่วไปนั้นยากและท้าทายพอ จนแทบไม่มีงานที่น่าเบื่อจริง ๆ เลย กลับกัน การพิมพ์เองมักเร็วกว่าอีกด้วย ระหว่างเขียนโค้ดเองในส่วนที่ไม่กลาง ๆ และไม่ง่าย ผมมักนึกโครงสร้างหรือไอเดียการทำอัตโนมัติที่ดีกว่าออกได้ ทำให้แทบไม่มีโค้ดที่อยากโยนต่อเลย และผมคิดว่าที่ผมมองแบบนี้ได้ก็เพราะอยู่บริษัทเดียวมานาน ถ้าต้องทำงานโค้ดใหม่ ๆ ตลอด ผมอาจคิดต่างออกไป
ผมก็อยู่ช่วงวัย 50 และเขียนโค้ดมาตั้งแต่ยุค 90 หาเงินได้มากพอจะใช้ทั้งชีวิตเกินสามรอบด้วยซ้ำ ตลอด 30 ปีที่ผ่านมา ลักษณะร่วมของนักพัฒนาที่เก่งที่สุดที่ผมเคยเจอมีอย่างเดียวคือ “ความขี้เกียจแบบสมบูรณ์แบบ” ฟังดูแปลก แต่คุณสมบัติร่วมของวิศวกรชั้นยอดมีแค่นี้จริง ๆ น่าทึ่งมากที่ความขี้เกียจกลายเป็น productivity ได้ เหตุผลคือพวกเขาจะทำทุกอย่างให้เป็นอัตโนมัติถ้าเป็นงานซ้ำ ผมได้เรียนกฎเหล็กว่า ถ้าทำสิ่งเดิมเป็นครั้งที่สอง ครั้งที่สามต้องมี automation แน่นอน พอ AI มา ระดับของ automation ก็เปลี่ยนไปโดยสิ้นเชิง ตอนนี้งานทุกแบบที่เมื่อก่อนทำไม่ได้ก็ทำให้เป็นอัตโนมัติได้ ผมค้นพบวิธีใช้ AI มากมาย และไม่ใช่แค่ผม เพื่อนร่วมงานที่ขี้เกียจเหมือนกันก็ใช้มันเก่งมาก ตอนนี้ผมนึกภาพการทำงานโดยไม่มี AI ไม่ออกแล้ว ไม่ใช่เพราะมันเป็น “เวทมนตร์” แต่เพราะสำหรับคนขี้เกียจอย่างผม AI เข้ามาทำทุกอย่างที่ทำให้เป็นอัตโนมัติได้แทน
ผมคิดว่านี่เป็นตัวอย่างสุดโต่งของ groupthink เรื่อง AI ที่เห็นกันบ่อยบน Hacker News Geohot อาจเป็นนักพัฒนาระดับบนสุด 99.999% แต่ 99.999% ของนักพัฒนาที่เขาไม่เข้าใจยังคงทำงานพื้นฐานกว่านั้นอยู่ มันคือ expert paradox ถ้าทุกคนเก่งระดับผู้เชี่ยวชาญ พวกเขาก็คงไม่ใช่ผู้เชี่ยวชาญแล้ว ผมเคยเห็นนักพัฒนาหลายคนที่ทำตัวเหมือน AI พวกเขาอธิบายโค้ดเบสที่ตัวเองสร้างยังไม่ได้ และดูแลมันให้สม่ำเสมอก็ไม่ได้ มันเหมือนวิศวกรอวกาศไปหัวเราะคนทำของเล่น Kinder Surprise เพราะไม่รู้ fluid simulation
ผมแปลกใจนะที่คุณคิดว่า HN มอง AI ในแง่ลบ เท่าที่ผมดูจากคอมเมนต์และโพสต์ยอดนิยม HN โดยรวมดูมองโลกเทคโนโลยีในแง่บวกมาก
การที่คนซึ่งก่อตั้งบริษัท self-driving มีจุดยืนแบบนี้ก็ดูไม่ค่อยสอดคล้องกันเท่าไร ถ้า AI model ยังเขียนโค้ดไม่ได้จริง จะไปแทนงานขับรถซึ่งยากกว่ามากได้หรือ
ต้นบทความก็อธิบายเรื่องนี้ไว้แล้ว ประเด็นคือ workflow การเขียนโปรแกรมทั่วไปหลายแบบมันเกิดขึ้นได้เพราะมันพบได้บ่อยมาก แต่ถ้าจะทำสิ่งใหม่จริง ๆ ก็ต้องอธิบายละเอียดถึงระดับภาษาเลย
ผมทำงานในสาย aerospace และวิศวกรที่นี่ก็ไม่ได้ดีกว่านั้นเท่าไร แต่ไม่ต้องกังวลมากหรอก บริษัทจะย้ายคนแบบนี้ไปอยู่ตำแหน่งที่ไม่ก่อความเสียหาย และส่วนใหญ่ก็ไปลงเอยที่งานบริหาร
ผมไม่แน่ใจว่า Geohot เป็นนักพัฒนาระดับท็อป 99.999% จริงหรือเปล่า “โมเดลที่เหมาะที่สุดของ programming AI ก็คือ compiler นั่นแหละ ให้ prompt (=code) ไป แล้วมันจะคืน compiled code มา แทนที่จะให้ feedback แล้วใช้งานแบบ interactive เหมือน IDE ส่วนใหญ่ การปรับ prompt → recompile น่าจะดีกว่า” ผมยังสงสัยอยู่ว่ามันจริงแค่ไหน
หนึ่งในแกนสำคัญของการถกเถียงนี้คือเราจำเป็นต้องนิยาม “ประเภทของการเขียนโปรแกรม” ให้ชัดเจนขึ้น ถ้าถามแค่ว่า “หุ่นยนต์ดีไหม แย่ไหม” ในการเอาหุ่นยนต์มาสร้างอะไรบางอย่าง มันก็ไม่มีความหมาย ต้องเริ่มจากคำถามว่า “กับอะไร” ก่อน การถกเถียงถึงจะไปต่อได้
ผมคิดว่าบทความนี้มีปัญหาหลายอย่าง อย่างแรกคือข้ออ้างว่า “AI coding คือ compiler” แต่ compiler แปลงภาษาตามสเปกอย่างกำหนดแน่นอน ขณะที่เครื่องมือเขียนโค้ดด้วย LLM เป็น program synthesizer ที่ค้นหา สร้าง และแก้โค้ดแบบวนซ้ำภายใต้ข้อจำกัดต่าง ๆ เช่น tests/types/linter/CI ซึ่งในโลกจริงมันแก้ปัญหา open source issue ขนาดใหญ่แบบ end-to-end ได้แล้วอย่าง SWE-bench Verified อย่างที่สองคือข้ออ้างว่า “ภาษาโปรแกรมคือภาษาอังกฤษ” ความจริงคือมันเป็นการผสมกันของ code, tests, spec, API, JSON schema, diff, เครื่องมือใน IDE ฯลฯ โดยภาษาอังกฤษเป็นแค่ตัวเชื่อมเท่านั้น ผู้เขียนเลือกหยิบเอา interface ที่อ่อนที่สุดมาวิพากษ์ อย่างที่สามคือข้ออ้างว่า non-determinism เป็นปัญหา ในโลกจริง ทั้ง fuzzing, SAT/SMT ฯลฯ ก็มีองค์ประกอบเชิงความน่าจะเป็นมากมาย แต่ determinism และความถูกต้องสุดท้ายมาจากสเปกภายนอก เช่น tests, type system, CI เป็นต้น และการบอกว่า LLM ได้รับความนิยมเพราะภาษาและไลบรารีแย่นั้นก็เป็น false dichotomy ตัวอย่างเช่น แม้ภาษาจะดีขึ้นอย่าง Rust หรือ TypeScript แต่ LLM ก็ยังช่วยได้ในเรื่อง API search, repo tracing, การเขียนโค้ดซ้ำ ๆ, migration, การเขียน tests, refactor เป็นต้น สุดท้าย ผู้เขียนเสนอทางเลือกแค่ว่า “สร้างภาษาและ compiler ที่ดีกว่าเดิม” แต่ในความเป็นจริงทีมสมัยใหม่ก็ได้รับคุณค่ามหาศาลจากการใช้ร่วมกับ AI อยู่แล้ว ดังนั้นแทนที่จะเชื่อ AI coding กับ LLM แบบเหมารวมว่าเป็น “compiler ภาษาอังกฤษมหัศจรรย์ที่สั่งด้วย prompt” การใช้มันให้เหมือน “junior pair programmer” ที่ช่วยงานตามข้อจำกัดของเราเอง เช่น types, tests, CI จะสมจริงกว่ามาก
(ผู้เขียนเอง) ผมเห็นด้วยกับความเห็นนี้ ถ้าเขียนบล็อกโพสต์ออกมาแบบนี้คงไม่ดังเท่าไร คำอธิบายว่า “เครื่องมือเขียนโค้ดด้วย LLM คือ search-based program synthesizer” ในมุมผมก็นับว่าเกือบจะเป็นนิยามของ compiler แล้ว เพียงแต่ compiler ส่วนใหญ่ไม่ได้ค้นหามากพอและพึ่ง heuristic มาก เพราะมันไม่ผนวกรวมกับ runtime เท่านั้นเอง ที่บอกว่า “เครื่องมือวิศวกรรมจำนวนมากก็ไม่ deterministic” นั้นถูกต้อง แต่ยกตัวอย่างเช่นใน SAT solver แม้จะใส่ randomness เข้าไปจนเวลาที่ใช้แก้เปลี่ยนไป มันก็ไม่กระทบความถูกต้องของคำตอบ ส่วน fuzzer นั้นมีไว้เพื่อการทดสอบ จึงไม่ได้คาดหวังความสมบูรณ์ตั้งแต่ต้น ผมไม่เคยเห็น fuzzer ที่ถูกเอาเข้า production เลย ข้อความที่ว่า “determinism มาจาก tests หรือ spec ภายนอก” นี่ผมเห็นด้วยเต็มที่ สิ่งที่ผมฝันถึงคือภาษาแบบที่เราไม่ต้องระบุวิธี implementation แต่ระบุพฤติกรรมผ่าน spec อย่างเดียว คล้ายการทำให้แนวคิด schedule ของ Halide ทั่วไปยิ่งขึ้น ให้คอมพิวเตอร์ไปหาวิธี implementation เอง ผมคิดว่า AI สามารถให้เครื่องมือแบบนี้ได้ และมันไม่จำเป็นต้องเป็น LLM แต่ต้องมีสเปกที่เข้มงวด ซึ่งนั่นเองสุดท้ายก็คือ programming จากมุมนี้ผมไม่เห็นด้วยกับการมอง AI เป็น “compiler ภาษาอังกฤษมหัศจรรย์” แต่ถ้ารู้จุดแข็งจุดอ่อนของมันแล้วใช้เป็นเครื่องมือช่วยงาน มันก็เป็น workflow ที่ดีมากจริง ๆ
คำตอบยอดเยี่ยม เห็นด้วยทั้งหมด
ไม่แปลกใจที่เขียนบทความมีปัญหาแบบนี้ ผู้เขียนคือ George Hotz หรือ Geohot นั่นเอง
ผมใช้ทั้ง Openpilot และ claude code บ่อยมาก และมองสองเครื่องมือนี้อยู่แทบระดับเดียวกัน Openpilot ขับบนทางด่วนหรือสถานการณ์ง่าย ๆ ได้ดีมากต่อเนื่องหลายชั่วโมง ส่วน claude code ก็ทำงานซ้ำ ๆ อย่างการ refactor แบบตรงไปตรงมา, boilerplate, scaffolding, git bisect ได้โดยแทบไม่ต้องให้ผมป้อนอะไรเพิ่ม แต่สุดท้ายทั้งคู่ก็ไม่ได้มาแทน “คนขับ” claude code จึงเป็นเหมือนการขับอัตโนมัติระดับ 2 ของโลกการเขียนโปรแกรม
งานวิจัยของ METR ได้ความนิยมมหาศาลเพราะพาดหัว คนที่อ่านละเอียดจริง ๆ น่าจะน้อย เพราะมันยาวมาก แต่จากข้อมูลจะเห็นว่ามีเพียงคนเดียวที่มีประสบการณ์ใช้ Cursor หรือ AI สูงที่สุดเท่านั้นที่เห็นความเร็วเพิ่ม 50% ซึ่งบ่งชี้ว่าผลลัพธ์เด่นชัดหลังจากเริ่มชำนาญแล้ว อีกทั้งขนาดตัวอย่างก็เล็ก ทำให้ความผันผวนทางสถิติสูง ภายหลังยังมีการแก้ไขว่าความต่างด้านความเร็วของอีกคนหนึ่งถูกบันทึกผิด ซึ่งยิ่งทำให้ตั้งคำถามกับความหมายของผลลัพธ์มากขึ้น ปัจจัยด้านความไม่มีประสิทธิภาพที่งานวิจัยวัดได้หลายอย่างก็น่าจะถูกแก้ได้ด้วยเทคโนโลยีที่ก้าวหน้ากว่า เช่น LLM รุ่นใหม่กว่า หรือ agent แบบทำงานขนานกัน และในตอนทำวิจัยนั้นก็ยังเป็นยุค Claude 3.7 เดิม ๆ ก่อน Claude Code ด้วยซ้ำ แม้แต่ความรู้สึกว่าได้ “ทำงานน้อยลง 20%” ก็ยังมีคุณค่าเพียงพออยู่ดี เวลาเราทำงานอย่างสนุก เวลาก็ผ่านไปเร็ว
ปัญหาคือห้องแล็บ AI ขายฝัน AI เกินจริงมาตลอด พวกคำพูดอย่าง “AI คิดจริง ไม่ได้เป็นแค่ pattern matching” มีเยอะมาก แต่ในฐานะคนที่ทั้งสร้างและใช้เครื่องมือ AI ผมกลับรู้สึกว่ามุมมองที่ปฏิบัติได้จริงกว่าคือมองมันเป็น pattern-matching แบบ “ตัวทำนายโทเคนถัดไป” เสียมากกว่า ถ้าใส่ข้อมูลที่ไม่จำเป็นเข้าไปในบริบทมากเกินไป AI มัก generalize ไม่ได้ ซึ่งก็ตรงกับ pattern matching/next token prediction นั่นเอง ผมคิดว่า “เทคโนโลยี AI ช่วยทำให้เกิดเครื่องมือที่ดีมากในปัจจุบันได้” แต่ทั้งหมดนี้เกิดจากการค้นหา/ปรับให้เหมาะสมจำนวนมากและการนำแพตเทิร์นเดิมกลับมาใช้ใหม่ ตัวอย่างเช่น ถ้าสั่ง Claude code ให้เขียน CRUD API ง่าย ๆ มันทำเสร็จใน 1 นาทีและประหยัดเวลาผมไป 1 ชั่วโมง ถ้าขออัลกอริทึมที่มีคนทำมาแล้วหลายแสนครั้ง มันก็พ่นโค้ดที่ถูกต้องออกมาได้แทบจะทันที AI ทำงานได้ดีมากเมื่อใช้ในขอบเขตความเชี่ยวชาญของมัน นอกเหนือจากนั้นผลลัพธ์จะไม่ค่อยดี
นี่คือปัญหาเรื่องความต่างของระดับ intelligence ไม่ใช่แค่ความรู้ แต่เป็นความต่างของความสามารถในการคิดโดยพื้นฐาน เรามักประเมิน effort ทางความคิดที่ใช้กับงานบางอย่างต่ำเกินไป แต่บางครั้ง AI ก็แสดงพฤติกรรมที่ “รอบคอบ” กว่าที่คาดไว้เหมือนกัน ซึ่งตอนนั้นมันให้ความรู้สึกเหมือนเวทมนตร์จริง ๆ
CRUD หรือ boilerplate จริง ๆ ก็พอจะแก้ได้ระดับหนึ่งด้วยการทำเป็นเครื่องมือ แต่ก็มีหลายอย่างที่ทำได้เพราะ AI เท่านั้น เช่น เวลาผมต้องทดสอบและวิเคราะห์ trace-level log ทั้งหมด ถ้านั่งไล่ดูทีละหลายร้อยบรรทัดด้วยตาใช้เวลามหาศาล แต่ถ้าบอก AI ว่า “รันเทสต์แล้วหาสาเหตุให้หน่อย” มันมักให้ผลที่ใช้งานได้ดีพอ ทุกวันนี้มันเลยกลายเป็นขั้นตอนแรกเสมอ
ผมคิดว่าความเห็นของคุณก็มีส่วนจริงอยู่ แต่โลกธุรกิจมี “ความโหยหาการจัดระเบียบใหม่” สูงมาก เงินทุนจำนวนมหาศาลต้องการผลตอบแทนแรงในเวลาสั้น ๆ และผู้จัดการกองทุนที่ตามเทรนด์ไม่ทันก็โดนปลด CIO หรือ CEO ก็ไม่ต่างกัน การแข่งขันด้านการนำ AI มาใช้จึงเหมือนการแข่งขันอาวุธนิวเคลียร์ที่หยุดไม่ได้แล้ว โดยเนื้อแท้มันอาจไม่ใช่เรื่องดีต่อใครเลย แต่เมื่อคนอื่นทุกคนวิ่งเข้าใส่ เราก็หยุดไม่ได้ ก่อนรถยนต์จะถือกำเนิด มนุษย์ก็มีความสุขกันได้ดีอยู่แล้ว แต่เมื่อรถมา เมืองก็ถูกจัดใหม่ ตึกห่างกันมากขึ้น และการเดินทางไปทำงานก็กลายเป็นเรื่องปกติ AI ก็เช่นกัน มันกำลังเปลี่ยนบริบทของการทำงานของเราเอง ตอนนี้เริ่มมีความคาดหวังว่าทุกคนต้องใช้ AI และเมื่อถึงจุดหนึ่งมันจะกลายเป็น “สิ่งจำเป็นพื้นฐาน” ยิ่งไปกว่านั้น ในบรรดาสินค้าที่วิทยาศาสตร์และเทคโนโลยีสร้างขึ้น แทบไม่มีอะไรที่เป็น “ความจำเป็น” ของมนุษย์จริง ๆ เทคโนโลยีมักสร้างปัญหาขึ้นมาก่อนแล้วค่อยห่อมันเป็นทางออก ปัญหาเดิมไม่มีอยู่ด้วยซ้ำ จนกระทั่งมีโซลูชันออกมาแล้วมันถึงกลายเป็นปัญหา นี่แหละแรงขับเคลื่อนสำคัญของโลกธุรกิจ
บทความแสดงความเห็นเรื่อง AI coding จำนวนมากดูเหมือนเขียนจากมุมของวิศวกรซอฟต์แวร์ที่มีประสบการณ์สูงมาก หรือมุม “ivory tower” (งานวิจัยนี้เองก็ศึกษาจาก “นักพัฒนาโอเพนซอร์สที่มีประสบการณ์สูง 16 คน” เท่านั้น) แต่สำหรับคนที่ไม่ใช่มืออาชีพ เครื่องมือพวกนี้มีคุณค่ามหาศาล ผมเองก็มีประสบการณ์เขียนโค้ดบ้าง แต่ไม่ใช่อาชีพหลักของผม ผมเป็นศิลปินภาพ ตอนนี้สิ่งที่เคยใช้เวลาหลายวันทำให้เสร็จได้ในบ่ายเดียว เมื่อสองเดือนก่อนผมลาออกจากงานมามุ่งทำเกมเต็มตัว งบไม่ได้มากนัก แต่ยังไงก็ต้องคง Claude กับ ChatGPT ไว้ อีกอย่าง การนอนอยู่บนเตียงตอนตีหนึ่งแล้วลองเขียนไอเดียอะไรบางอย่าง จากนั้นโยนให้ Codex ทำต่อ แล้วตื่นเช้ามาลองรันดู มันรู้สึกเหมือนเวทมนตร์จริง ๆ เมื่อก่อนผมมักลังเลจะเริ่มเพราะกังวลว่า “นี่เป็นวิธีที่ดีที่สุดจริงหรือเปล่า” แต่ตอนนี้การ refactor ง่ายมากจนความกังวลแบบนั้นหายไป ผลของมันไม่ได้มีแค่เรื่องช่วยเขียนโค้ด แต่ยังช่วยลดกำแพงทางจิตใจด้วย แน่นอนว่าผมก็เข้าใจว่าคำวิจารณ์ส่วนใหญ่จริง ๆ แล้วมุ่งไปที่การตลาดที่โอ้อวดเกินจริงของเครื่องมือนี้ และวาทกรรมว่า “ต่อไปวิศวกรจะตกงานหมด”
ผมอายุ 72 และทำงานเป็นนักพัฒนามา 40 ปีแล้ว ทุกวันนี้โฟกัสลึก ๆ ไม่ได้เหมือนเมื่อก่อน แต่ด้วย AI ผมก็ยังสร้างของได้อยู่ ผมเป็นคนกำหนดสเปกของโปรเจกต์ แล้ว agent ก็ไปลงมือ implement และทดสอบให้ ตอนนี้ผมเขียนโค้ดเพื่อความสนุกอย่างเดียวแล้ว