เอเจนต์เขียนโค้ด AI กำลังทลายกำแพงของภาษาโปรแกรม
(railsatscale.com)- ความก้าวหน้าของเครื่องมือเขียนโค้ด AI กำลังสร้างสภาพแวดล้อมที่ช่วยให้นักพัฒนาเริ่มต้นกับภาษาใหม่ได้อย่างรวดเร็ว
- ผู้เขียนเคยเป็นนักพัฒนาที่ใช้ Ruby เพียงภาษาเดียวตลอด 10 ปี แต่ในปีนี้ด้วยการทำงานร่วมกับเอเจนต์เขียนโค้ด AI (เช่น Cursor, Claude Code) จึงสามารถมีส่วนร่วมจริงกับภาษาระบบอย่าง C, C++ และ Rust ได้
- เครื่องมืออย่าง Claude Code และ Cursor มีบทบาทช่วยเหลืออย่างมาก โดยเฉพาะในด้านไวยากรณ์ภาษา สำนวนการเขียน และทฤษฎีทั่วไป
- AI ไม่ใช่แค่ตัวสร้างโค้ด แต่เป็น "วิศวกรคู่คิดผู้เชี่ยวชาญด้านภาษา" ที่ทำงานร่วมกับประสบการณ์เดิม เพื่อตอบคำถามแบบเรียลไทม์ อธิบายบริบท และวิเคราะห์ตัวอย่าง ช่วยเพิ่มประสิทธิภาพการเรียนรู้สูงสุด
- แม้ AI จะไม่ได้รู้บริบทเฉพาะของแต่ละโปรเจกต์หรือโครงสร้างภายในเชิงลึกทั้งหมด แต่ก็สามารถให้คำแนะนำได้ทันทีเกี่ยวกับไวยากรณ์ภาษา แพตเทิร์นที่พบบ่อย และ standard library ทำให้สามารถมีส่วนร่วมจริงได้โดยไม่ต้องเรียนล่วงหน้านานกว่า 100 ชั่วโมง
- การใช้เครื่องมือ AI กำลังเปลี่ยนมุมมองแบบดั้งเดิมต่อความเชี่ยวชาญด้านภาษาโปรแกรมอย่างรวดเร็ว และกำลังเปิดทางให้นักพัฒนาจำนวนมากขึ้นทำงานได้อย่างมีประสิทธิภาพในหลายภาษา
นักพัฒนา Ruby 10 ปี สู่การเปลี่ยนผ่านไปหลายภาษา
- ผู้เขียนทำงานเป็นนักพัฒนาที่ดูแลระบบนิเวศ Ruby และ Rails โดยเฉพาะ ระหว่างปี 2014~2024
- ตลอดช่วงเวลานั้นได้สั่งสมประสบการณ์พัฒนาและบำรุงรักษาเครื่องมือหลักในระบบนิเวศ Ruby เช่น Rails, IRB, RDoc, debug gem
- ตั้งแต่ปี 2025 เป็นต้นมา ได้มีส่วนร่วมกับโปรเจกต์ในชั้น system layer นอกเหนือจาก Ruby เช่น Sorbet(C++), RBS parser(C), ZJIT(Rust)
- ปัจจัยสำคัญที่ทำให้การเปลี่ยนแปลงนี้เกิดขึ้นได้คือการนำเอเจนต์เขียนโค้ด AI มาใช้ (Cursor, Claude Code)
- ภายใน Shopify เองก็มีการสนับสนุนให้ใช้งานเครื่องมือ AI เหล่านี้อย่างจริงจัง
จังหวะที่ทุกอย่างลงตัว
- ไม่ได้เป็นเพราะ AI เพียงอย่างเดียว แต่ยังมีเงื่อนไขสำคัญหลายอย่างที่เกิดขึ้นพร้อมกัน
- การเปลี่ยนโรดแมปของทีม Ruby DX ทำให้ต้องมีการรองรับ RBS ใน Sorbet → ส่งผลให้จำเป็นต้องมีประสบการณ์ด้าน C/C++
- สมาชิกทีมโครงสร้างพื้นฐาน Ruby & Rails ของ Shopify มีการแบ่งปันความรู้และสร้างสภาพแวดล้อมการติวที่เข้มแข็ง
- แม้ในอดีตก็มีทั้งเมนเทอร์ที่ยอดเยี่ยมและโอกาสทำโปรเจกต์จริงอยู่แล้ว แต่AI ช่วยย่นกำแพงการเรียนรู้และ learning curve ลงอย่างพลิกโฉม
ความซับซ้อนของ system programming
- กรณีของโปรเจกต์ ZJIT (JIT Ruby compiler ตัวใหม่):
- ต้องใช้ทั้งความรู้และทักษะที่ซับซ้อนหลายด้านพร้อมกัน
- Rust (ภาษาหลัก), C (ภาษาที่ใช้ในแกนหลักของ Ruby), ทฤษฎี JIT/คอมไพเลอร์, โครงสร้างและการออกแบบเฉพาะของ ZJIT, หลักการทำงานภายในของ Ruby, ระบบ build ของ Ruby (autoconf, Makefile เป็นต้น)
- Pull Request หนึ่งครั้งมักแตะพร้อมกัน 2~4 ด้าน
- ประสิทธิภาพของ Claude Code
- มีความแม่นยำสูงในด้านไวยากรณ์ รูปแบบการเขียน และทฤษฎีคอมไพเลอร์ทั่วไป รวมถึงไวยากรณ์ภาษาและแพตเทิร์นการเขียนของ Rust/C/C++
- แต่ยังมีข้อจำกัดบ้างในด้านบริบทเฉพาะของโปรเจกต์ การทำงานภายในของ Ruby และการรองรับระบบ build ที่ซับซ้อน
- ถึงอย่างนั้นก็ยังช่วยลดกำแพงในการเริ่มต้นเรียนรู้ลงได้มากกว่าครึ่ง
- AI ช่วยสนับสนุนการเรียนรู้ไวยากรณ์ภาษา ทฤษฎี และแพตเทิร์นได้ทันที ขณะที่บริบทเฉพาะของโปรเจกต์ยังเป็นหน้าที่ของมนุษย์
pair programming กับ AI
- ผู้เขียนเริ่มมอง AI ไม่ใช่แค่ตัวสร้างโค้ด แต่เป็นพาร์ตเนอร์ที่ช่วยเสริมกัน
- รูปแบบการทำงานร่วมกันจริง
- นักพัฒนาส่งต่อความต้องการของงานและบริบทให้ AI
- AI ค้นหาแพตเทิร์นและทำหน้าที่เป็นผู้เชี่ยวชาญด้านภาษา
- นักพัฒนาตั้งคำถามถึงเหตุผลด้านการออกแบบ
- AI ปรับแก้โค้ดหรือสำรวจทฤษฎี แล้วส่งผลลัพธ์กลับมา
- ผ่านการเรียนรู้แบบโต้ตอบ ทำให้เรียนรู้ทั้งตัวภาษาและวิธีใช้งานจริงไปพร้อมกัน
- ตัวอย่าง: ในงานทำ profiling ของคำสั่ง bytecode ของ Ruby สามารถให้ AI ช่วยค้นหา PR ในอดีตและอธิบายทีละบรรทัดได้
- สามารถถาม**"คำถามโง่ ๆ"** ได้โดยไม่ต้องกังวล (เช่น “ทำไม JIT compiler ถึงต้องมี profiling?”)
- ได้รับ feedback ทันทีเกี่ยวกับไวยากรณ์ที่ยังไม่คุ้นเคย
- ก็มีกรณีล้มเหลวเช่นกัน
- หากทิศทางของโปรเจกต์ผิดพลาด สุดท้ายก็ยังต้องให้เพื่อนร่วมทีมที่เป็นเมนเทอร์ช่วยปรับแก้
- ในท้ายที่สุด ความสามารถของผู้เชี่ยวชาญมนุษย์ในการปรับเส้นทาง ก็ยังคงจำเป็น
การรื้อกำแพงของภาษาโปรแกรม
- ตอนนี้ไม่ใช่ยุคที่ต้องใช้เวลาเรียนล่วงหน้า 100 ชั่วโมงเพื่อจะเริ่มมีส่วนร่วมกับโปรเจกต์ C ใหม่อีกต่อไป
- แม้แต่ภาษาอย่าง C และ Rust ที่ "เริ่มต้นยาก" ก็สามารถเข้าไปมีส่วนร่วมได้ทันทีด้วยความช่วยเหลือจาก AI
- AI ช่วยจับความผิดพลาดแบบมือใหม่ (syntax error, type error, ความเข้าใจผิดเรื่องการใช้เครื่องมือ ฯลฯ) ได้อย่างรวดเร็ว จึงเริ่มสร้างผลงานจริงได้ทันที
- แม้ความเชี่ยวชาญเชิงลึกยังคงสำคัญ แต่นักพัฒนาจำนวนมากขึ้นสามารถทำงานได้อย่างมีประสิทธิภาพในหลายภาษา
- ให้ AI ดูแลเรื่องไวยากรณ์ ฟังก์ชันมาตรฐาน และแพตเทิร์น ส่วนให้นักพัฒนามุ่งแก้ปัญหาที่แท้จริง
- การเปลี่ยนแปลงที่ทำให้นักพัฒนา Ruby แบบเฉพาะทางอย่างผู้เขียนกลายเป็นนักพัฒนาหลายภาษาได้ภายในเวลาไม่ถึง 1 ปี คือเทรนด์ที่พลิกวงการ
- การเปลี่ยนจาก**"นักพัฒนาที่ใช้ภาษาเดียว"** ไปเป็น**"ผู้สร้างผลงานหลายภาษา"** กำลังเกิดขึ้นจริง
- นี่อาจเป็นจุดเริ่มต้นของกระแสที่ทำให้แนวคิดเรื่องความเชี่ยวชาญแยกตามภาษาเปลี่ยนไปโดยสิ้นเชิงในอนาคต
บทสรุป
- เอเจนต์เขียนโค้ด AI กำลังลดกำแพงในการเข้าสู่ภาษาโปรแกรมลงอย่างรวดเร็ว และกำลังเปิดยุคใหม่ที่นักพัฒนาสามารถทำงานได้อย่างมีประสิทธิภาพทันทีในหลายภาษา
5 ความคิดเห็น
การสร้างโค้ดอาจใช่ แต่ใครจะเป็นคนตรวจและรีวิวโค้ด...
ถึงจะเขียนภาษาที่ไม่ถนัดไม่ได้ แต่บ่อยครั้งก็พออ่านแบบคร่าวๆ ได้ เลยคิดว่าเมื่อเทียบกับเมื่อก่อนก็น่าจะช่วยประหยัดเวลาได้จริง
ดูเหมือนว่าตอนนี้เราสามารถก้าวไปข้างหน้าได้เร็วขึ้นมากกว่าเดิมจริง ๆ เมื่อต้องเจอกับเทคโนโลยีที่ยังไม่เคยใช้หรือขอบเขตงานที่ยังไม่เคยมีประสบการณ์
ความเห็นจาก Hacker News
สงสัยว่า AI กำลังเปลี่ยน learning curve จริง ๆ หรือแค่ทำให้การใช้ประสบการณ์เดิมสะดวกขึ้น
จากประสบการณ์ของคนที่บอกว่า ทำแต่ Ruby มา 10 ปี แล้วกลายเป็นนักพัฒนาที่ใช้ได้หลายภาษาในเวลา 1 ปีจนรู้สึกว่าเป็นเรื่องพลิกวงการนั้น กลับมองว่านั่นน่าจะเป็นเรื่องของ “สิ่งที่ไม่เคยลองมาตลอด 10 ปี” มากกว่า
การเรียนภาษาโปรแกรมภาษาแรกกับการเรียนภาษาใหม่หลังมีประสบการณ์มาหลายปีแล้ว เป็น ประสบการณ์ที่ต่างกันโดยสิ้นเชิง
ฉันก็คิดเหมือนกัน
รู้สึกเชื่อมโยงกับนักพัฒนาที่ใช้ภาษาเดียวมา 10 ปีได้ยาก
ช่วงแรก ๆ เคยมี อัตลักษณ์ผูกกับภาษาที่เลือกใช้ อย่างแรง แต่พอเจอนักพัฒนาที่มีประสบการณ์จริงมาก ๆ ก็ได้เรียนรู้ว่า “ภาษาเป็นแค่เครื่องมือ”
พอได้สัมผัสหลายภาษา มุมมองจะกว้างขึ้นมาก และมีความเข้าใจบางอย่างที่อธิบายเป็นคำพูดได้ยาก
การได้มีประสบการณ์แบบนั้นเป็น ความสุข จริง ๆ
คิดว่าความเห็นที่ว่า “ต่อให้ไม่มี AI ภายใน 1 ปีก็เรียนได้หลายภาษาอยู่แล้ว” ก็ จริงอยู่พอสมควร
จากประสบการณ์ของฉัน ตอนทำมินิโปรเจกต์ Python กับ o4 เจอ edge case สนุก ๆ หลายอย่าง ซึ่งถ้าไม่มี AI งานจำนวนมากคงสะดุดไปเลย
ตัวอย่างเช่น วิธีที่ unraid จัดการ xml vm หรือปัญหาที่เกิดใน dockers ถ้าจะขุดเองก็หมดไปเป็นวัน
แต่ตอนนี้ AI ช่วยไกด์เรื่องพวกนี้ให้ ทำให้ผ่านไปได้ ลื่นขึ้นมาก
เลยทั้งน่ากลัวและน่าทึ่ง เพราะมันใช้งานได้ดีจริง ๆ
และภาษาโปรแกรมภาษาแรกของฉันก็คือ BASIC ยุคเก่า
AI ทำให้ ภาษากระแสหลัก ยิ่งได้รับความนิยมมากขึ้น
ภาษาที่ AI พลาดน้อยที่สุดมักเป็นภาษาอย่าง Python, JS, Ruby ที่มีชุมชนใหญ่และมีชุดข้อมูลมหาศาล
เพราะแบบนี้ ภาษานอกกระแสจึงไม่ได้อานิสงส์ด้านการเข้าถึงมากนัก
เนื่องจากโปรแกรมเมอร์ส่วนใหญ่ไม่ได้ชำนาญภาษานอกกระแสพอจะจับบั๊กเล็ก ๆ น้อย ๆ ได้
เหมือนบทเรียนจาก machine learning สุดท้ายฝั่งที่มี training data มากกว่าก็ได้เปรียบ
AI เก่งเรื่อง pattern matching
ถ้าจัดปัญหาให้เข้ากับแพตเทิร์นที่มีอยู่ ก็จะยกตัวอย่างโค้ดดี ๆ ให้ได้ทันที
แต่ยิ่งปัญหาซับซ้อนหรือแปลกมากเท่าไร AI ก็ยิ่งมีประโยชน์น้อยลง
มนุษย์ยังจัดการกับ แนวคิดเชิงนามธรรมและพลวัต ได้อย่างยืดหยุ่นกว่า
คนที่ใช้ภาษานอกกระแสมักให้ความสำคัญกับ คุณค่าอื่นมากกว่าความนิยม (เช่น ประสิทธิภาพ เงิน การเรียนรู้)
ถ้าความนิยมของภาษาเป็นสิ่งจำเป็น ผู้เชี่ยวชาญอาจสร้าง ตัวอย่างโค้ดที่ดีตาม idiom เอาไว้จำนวนมาก แล้วให้ AI สร้างรูปแบบดัดแปลงต่าง ๆ ต่อก็ได้ ซึ่งอาจลดกำแพงการเริ่มต้นได้อย่างมาก
ถ้าการเขียนโค้ดขนาดเล็กทำได้ง่ายขึ้น คนก็อาจเริ่มสนใจตัวภาษามากขึ้น
LLM มีแนวโน้มจะพูดมั่วบ่อยกว่าใน ภาษานอกกระแส
ฉันเป็นนักพัฒนา Scala และมองว่าการถกเถียงเรื่องประโยชน์ของ AI ส่วนใหญ่ขึ้นกับว่าคุณใช้ภาษาอะไร
ถ้าเป็นภาษาอย่าง JS มันอาจจะมีประโยชน์มากกว่าก็ได้
กังวลว่าเมื่อมีภาษาใหม่หรือเฟรมเวิร์กใหม่ออกมา ถ้า AI รองรับได้ไม่แม่นยำพอ คนอาจยิ่งไม่อยากเปลี่ยน
เพราะอาจรู้สึกว่าความไม่สะดวกมีมากกว่าประโยชน์
ทุกครั้งที่มีรีลีสใหม่ ก็ยิ่งจำเป็นต้องมี เอกสาร MCP หรือข้อมูลเสริมที่เป็นมิตรกับ AI
สำหรับฉัน การใช้ claude กับ Elm เป็นประสบการณ์ที่ดีมาก
ด้วยระบบ static type ทำให้ความแม่นยำสูงและช่วยได้มาก
แน่นอนว่าบางครั้งก็ยังตอบแปลก ๆ แต่คิดว่าทุกคนน่าจะเคยเจอแบบนั้น
คิดว่ายุคนี้แทบไม่มี กำแพง ระหว่างภาษาใหญ่ ๆ แล้ว
แค่ดู 10 ภาษาที่ใช้กันแพร่หลายในการพัฒนาแอปพลิเคชันตอนนี้ ส่วนใหญ่ก็เป็นสาย C หรือ ALGOL ที่มี ไวยากรณ์คล้ายกัน, call-by-reference, และ การจัดการหน่วยความจำอัตโนมัติ ร่วมกัน
ถ้าเป็นนักพัฒนามืออาชีพ ก็มักจะ สลับไปมาระหว่างภาษาเหล่านี้ได้ โดยไม่ลำบากมาก
การเรียนรู้เรื่องการจัดการหน่วยความจำครั้งแรกอาจจะยากนิดหน่อย แต่ถ้าใช้แพตเทิร์นที่คุ้นเคย คำเตือน และ linter ให้ดี ก็พอรับมือได้
ภาษาที่มี learning curve สูงจริง ๆ คือ Rust, Ada SPARK, Lisp, Forth, ML เป็นต้น ซึ่งไม่ได้เป็นภาษากระแสหลัก
กำลังใช้ AI เป็น พาร์ตเนอร์ช่วยเขียนโปรแกรม
ใช้ประโยชน์จาก “ความรู้กว้างแต่ตื้น” ของ AI เพื่อสำรวจก่อน แล้วค่อยขอความช่วยเหลือเมื่อต้องเจาะลึกในบางด้าน
ใช้มันกับการเรียนรู้ แนวคิดหรือเทคโนโลยีใหม่ (เช่น webauthn backend, การรวม passkey) มากกว่าการเรียนภาษาโปรแกรมใหม่
แม้แต่ในมุมของมือใหม่ AI ก็ช่วยได้มาก
แต่ AI ก็เคยยกตัวอย่างผิด ๆ (เช่น dependency ที่เลิกใช้แล้ว) เหมือนกัน ซึ่งสุดท้ายกลับทำให้ เข้าใจลึกขึ้น จึงถือว่าเป็นประสบการณ์ที่ดี
ไม่อยากปล่อยให้ AI พัฒนาแอปแบบอัตโนมัติทั้งหมด แทนเรา
เพราะมันยังพลาดเล็ก ๆ น้อย ๆ อยู่บ่อย จึงต้องตรวจทานเสมอ
AI ช่วยได้มากในการศึกษากับ โค้ดเบส Swift ที่เพิ่งได้เจอไม่นานนี้
มันช่วยตอบข้อสงสัยได้เร็วและเพิ่มความเร็วในการเรียนรู้
แต่ถ้าจะมีส่วนร่วมกับโปรเจกต์ที่ซับซ้อนอย่างแท้จริง ก็ยังต้องมี ทักษะและประสบการณ์ อยู่ดี
แม้แต่ในภาษาที่ฉันรู้ ก็ยังเจอจุดผิดพลาดได้เยอะ ถ้าเป็นภาษาที่ไม่รู้ก็ยิ่งตรวจยาก
ทุกครั้งที่ขุดภาษาใหม่ ต่อให้จะรีวิวงาน ก็ต้องใช้เวลานานกว่าจะคุ้นเคย
บอกว่ากำแพงภาษาลดลงแล้ว แต่ในความเป็นจริงก็ยังมีกรณีอย่าง WhatsApp ย้ายจากแอปเดสก์ท็อปไปเป็นเว็บแอป อยู่ดี ดังนั้นกำแพงไม่ได้หายไปหมด
ทำให้นึกถึงตอนที่ Microsoft เคยผลักดันแพลตฟอร์ม .Net เพื่อให้ทีมเดียวกันทำงานร่วมกันได้ด้วยหลายภาษา เช่น J#, Fortran.Net, Cobol#
ตอนนั้นยังเคยโฆษณาว่าวิธีนี้จะช่วยให้คนเก่ง #Intercal เพิ่มผลิตภาพได้สี่เท่าด้วย
คาดว่าเพราะ AI ภาษาโปรแกรมจะค่อย ๆ วิวัฒน์ไปทางฝั่งที่มี ระบบชนิดแบบ Hindley Milner ที่ทรงพลัง
Haskell แม้จะเรียนยาก แต่ถ้ามีชุดข้อมูลเพียงพอ ก็เป็นเป้าหมายที่ เหมาะกับ coding agent อย่างสมบูรณ์แบบ
มันอยู่ในระดับสูงและยัง ตรวจสอบเชิงรูปนัยได้ รวมทั้งเชื่อม language server กับ AI ได้สะดวก
แต่ความจริงดูเหมือนจะตรงกันข้าม คือ Haskell อาจกลับกลายเป็นภาษาที่ ถูกทอดทิ้งในแง่การรองรับจาก AI
ถ้าคุณชอบภาษาฟังก์ชัน ก็น่าจะลองคิดดูว่าทำไมการเขียนโปรแกรมด้วยภาษาธรรมชาติจึงน่าสนใจ
ภาษาธรรมชาติสามารถ อธิบายผลลัพธ์ได้อย่างกำกวม แล้วให้เครื่องมาช่วยเติมส่วนที่ขาดโดยอัตโนมัติ
ถ้าจะให้เป็นนวัตกรรมจริง อาจต้องมีวิธีเขียนโปรแกรมที่รวม ตรรกะที่เข้มแข็ง + ความกำกวม เข้าไว้ด้วยกัน เช่น การนำแนวคิดเชิงตรรกะแบบ MTL มาใช้
น่าเสียดายที่งานวิจัยด้านนี้แทบหยุดไปแล้ว และตอนนี้ neural network กลายเป็นกระแสหลัก
สำหรับ LLM แล้ว Haskell เป็นภาษาที่มีคุณสมบัติเชิงลึกเยอะ จึงไม่ค่อยเป็นมิตรนัก
เพราะ LLM ทำงานกับ แพตเทิร์นของข้อความ เป็นหลัก
ภาษาที่มี คุณลักษณะเรียบง่ายและข้อความ error จากคอมไพเลอร์ที่เป็นมิตร (เช่น Go) เป็นสิ่งที่ AI รับมือได้ดี
ส่วนตัวฉันชอบ ภาษาที่มี type inference ดี แต่จากมุมของ AI มันเป็นอีกเรื่องหนึ่ง
เคยลองใช้ LSP MCP tool + LLM แล้ว รู้สึก ผิดหวังนิดหน่อย
เดิมที LSP ถูกออกแบบมาเพื่อผู้ใช้ที่เป็นมนุษย์ จึงไม่ได้เข้ากับ AI อย่างสมบูรณ์แบบ
LLM เก่งเรื่อง pattern matching และถ้าโครงสร้าง type ไม่ซับซ้อน ก็มักแทบไม่มี type error
แต่ถ้าโครงสร้างซับซ้อน LLM อาจแก้ไม่ได้ หรือผู้ใช้เองก็อาจไม่เข้าใจคำตอบ
ยังมีคำถามด้วยว่า “มีกรณี การตรวจพิสูจน์เชิงรูปนัย ขนาดใหญ่ที่ใช้ Haskell ไหม” ซึ่ง seL4, CompCert เป็นต้น ส่วนใหญ่ก็อยู่บน C หรือ Coq+OCaml
การใช้ ภาษาแบบ dependent type อย่าง Agda อาจเพิ่มขึ้นก็ได้
แต่ถ้าชุดข้อมูลมีน้อยเกินไป AI ก็อาจถ่ายทอดความรู้ได้ยาก
ควรมอง AI เป็น พาร์ตเนอร์ pair programming
ยิ่งผู้ใช้เรียนรู้มากขึ้น บทบาทของ AI ก็จะเปลี่ยนจากช่วงแรกที่ช่วย อธิบายพื้นฐานและสร้างโค้ดเล็ก ๆ ไปเป็น การถกเชิงลึก + การสร้างโค้ดหน่วยใหญ่ขึ้น และการรีวิวโค้ด
เมื่อเวลาผ่านไป คุณจะเริ่ม เจอบั๊กได้เอง มากขึ้น
ถ้าไม่มอง AI เป็นแค่ตัวสร้างโค้ด แต่เป็น พาร์ตเนอร์ที่มีทักษะเสริมกัน มันจะมีประโยชน์จริง ๆ
ถ้าเป็นภาษาที่เราไม่รู้ ต้อง ถามไล่รายละเอียด กับโซลูชันที่ AI เสนอ
ถามให้เฉพาะเจาะจง เช่น “ทำไมถึงทำแบบนี้” หรือ “ถ้าเป็นอีกสถานการณ์หนึ่งล่ะ?” จะช่วยให้เรียนรู้ได้มากจริง ๆ
การถามคำถามทำให้ AI ช่วยตรวจสอบความคิดของฉันได้ แต่พอทำไปหลายรอบก็เริ่มรู้สึกว่า เชื่อทั้งหมดไม่ได้จริง ๆ
ควรฝึกนิสัย “ให้ AI ถามคำถามที่ชัดเจนกลับมา ด้วย”
แบบนั้นจะช่วยให้พบได้เร็วขึ้นว่าความเข้าใจของเราผิดตรงไหน หรือเหตุผลยังไม่แน่นพอ
เคยขอ bash script จาก Gemini เพื่อทดสอบความสามารถด้านการสร้างโค้ด แต่มีข้อผิดพลาด
โชคดีที่ฉันรู้ bash เลยแก้ได้ทันที แต่ถ้าเป็น ภาษาที่ไม่รู้ ก็คงบอกได้ยากว่านี่คือการทำลายกำแพงภาษา
คิดว่านี่เป็นปัญหาเฉพาะของ bash มากกว่า
อย่างเช่นตอนให้ LLM ทำงาน automation คล้ายกันด้วย Go มัน ทำงานได้ถูกต้องตั้งแต่ครั้งแรก
ไม่คิดว่าเป็นปัญหาของ Gemini มากกว่า bash และก็ไม่เห็นด้วยกับการวิจารณ์ด้วยชื่อแบรนด์อย่างเดียวโดยไม่มี ข้อมูลการตั้งค่ารุ่น AI ที่ชัดเจน
จริง ๆ แล้วพอตั้งเป็น “Gemini 2.5 Pro (Jan 2025), อุณหภูมิ 0.15” มันก็สร้าง idiomatic bash script ที่ยอดเยี่ยมได้ทันที
(ละตัวอย่างโค้ด)
นอกจากนี้ยังเคยเจอปัญหาเรื่องการขึ้นบรรทัดใหม่ในไฟล์ที่แก้ผ่าน Windows Notepad บน WSL2 ซึ่ง Gemini ก็ ช่วยอธิบายวิธีแก้ให้แบบเป็นมิตร
ที่น่าสนใจคือ ใน bash ถ้าบรรทัดสุดท้ายไม่มีการขึ้นบรรทัดใหม่ มันอาจทำงานไม่ถูกต้อง ซึ่งเป็นข้อจำกัดของ bash เอง
ส่วน PowerShell สามารถทำงานเดียวกันได้แทบจะเป็น one-liner และไม่มีปัญหาถึงแม้ท้ายไฟล์จะไม่มีการขึ้นบรรทัดใหม่
และด้วยความช่วยเหลือของ Gemini ก็ยังปรับโค้ด PowerShell ให้สั้นลงได้ด้วย
https://ruby-news.kr/articles/…
สรุปจากบริการที่ผมทำขึ้นเอง เป็นสิ่งที่แปลไว้แล้วจึงคล้ายกัน แต่ของ GeekNews เรียบเรียงได้ดีกว่าและอ่านสบายกว่าครับ