- OpenAI Codex คือ เอเจนต์โค้ดแบบมัลติทาสก์ที่ทำงานบนการเชื่อมต่อกับ GitHub โดยมีอินเทอร์เฟซที่ให้สั่งงานหลายอย่างพร้อมกันผ่านภาษาธรรมชาติได้
- ผู้ใช้สามารถ เทงานทั้งวันเข้าไปได้อย่างรวดเร็ว และให้ระบบสร้าง branch กับเปิด PR โดยอัตโนมัติ ได้ อีกทั้งยัง ใช้งานบนมือถือได้ ทำให้รองรับเวิร์กโฟลว์ที่เน้นการทำงานจากระยะไกลได้ในที่สุด
- อย่างไรก็ตาม ตอนนี้ยังมีปัญหาอย่าง การจัดการข้อผิดพลาดที่ยังไม่ดีพอ คุณภาพโค้ดที่ไม่สม่ำเสมอ การอัปเดต branch เดิมที่ทำได้ยาก และ sandbox ที่บล็อกเครือข่าย จึงไม่เหมาะกับงานรีแฟกเตอร์หลัก
- Codex มีประโยชน์กับ การทำงานบำรุงรักษาขนาดเล็กแบบอัตโนมัติ และใช้งานได้จริงในการจัดการงานที่ทำซ้ำได้อย่างรวดเร็ว
- หากในอนาคตมี การปรับปรุงโมเดล การผสมหลายโมเดล และฟีเจอร์ integration ขั้นสูง ก็มีโอกาสที่จะ พัฒนาไปเป็นเครื่องมือ orchestration ระดับสูง ได้
วิธีการทำงานของ OpenAI Codex
- OpenAI Codex มี UI แบบแชต ที่เข้าถึงได้ผ่านการเชิญหรือการสมัคร Pro ราคา $200/เดือน
- ผู้ใช้ต้องผ่าน การยืนยันตัวตนหลายขั้นตอน และอนุมัติแอป Codex GitHub แยกตามแต่ละองค์กร จากนั้น Codex จะโคลน repository ไปยัง sandbox ของตัวเองเพื่อรันคำสั่งและจัดการงานสร้าง branch แทน
- หากต้องดูแลทั้ง repository แบบสาธารณะและส่วนตัวจำนวนมาก ประสิทธิภาพด้าน การสลับหลายโปรเจกต์และการจัดการคิวงาน ถือว่าดีมาก
- แต่ถ้าดูแลเพียง 1–2 repository การใช้ LLM เดิมหรือ editor ที่มีฟีเจอร์ AI อาจเป็นตัวเลือกที่เบากว่า
จุดแข็งของ Codex
-
การประมวลผลงานหลายงานพร้อมกันและอินเทอร์เฟซ
- สามารถ ระบุ repository และ branch แยกตามแต่ละงาน ได้ ทำให้การลงงานทั้งวันแบบขนานผ่านภาษาธรรมชาติดูเป็นธรรมชาติ
- Codex สนับสนุนแนวทางการจัดการหลายงานพร้อมกัน และสอดคล้องกับสไตล์การทำงานของผู้รีวิวเป็นอย่างดี
-
เวิร์กโฟลว์ที่ยืดหยุ่นและรองรับมือถือ
- Codex ทำงานได้แบบ เป็นมิตรกับมือถือ แม้บนสมาร์ตโฟน จึงมีศักยภาพสูงสำหรับการทำงานนอกออฟฟิศอย่างมีประสิทธิภาพ
- แนวทางใช้งานในอุดมคติคือเริ่มต้นวันด้วยการลงงานหลายอย่างไว้ แล้วคอยวางแผนและติดตามความคืบหน้าต่อได้แม้อยู่ข้างนอก
-
ฟีดแบ็กผ่านแชตและการสร้าง PR
- สามารถดู log และสถานะ ของงานที่กำลังดำเนินอยู่ผ่านอินเทอร์เฟซแชตได้สะดวก และยังสั่งงานเพิ่มเติมได้
- หากพอใจกับการเปลี่ยนแปลง Codex จะสร้าง Pull Request (ต่อไปจะเรียกว่า PR) และเขียนคำอธิบายให้อัตโนมัติ
- สามารถตรวจสอบ log การทำงานและรายการคำสั่งในแต่ละขั้นตอนได้ ซึ่งถือว่าใช้งานได้ดี
จุดที่ควรปรับปรุง
-
การจัดการข้อผิดพลาดที่ยังไม่เพียงพอ
- การไม่มี ฟีดแบ็กที่ชัดเจน เมื่อเริ่มงานไม่สำเร็จหรือสร้าง PR ไม่ได้ ทำให้ประสบการณ์ใช้งานลดลง
-
คุณภาพโค้ดและการทำงานแบบจบในครั้งเดียว
- แม้โมเดล Codex จะอยู่ในตระกูล GPT-3 และรองรับมากกว่า 12 ภาษา แต่เมื่อรันแบบขนานแล้ว ให้ผลที่น่าพอใจได้เพียงราว 40–60%
- แม้จะมีประโยชน์กับงานบำรุงรักษาเล็กน้อย แต่กับ การรีแฟกเตอร์ขนาดใหญ่ที่ต้องสร้าง PR ซ้ำ ๆ ประสิทธิภาพการใช้งานจะลดลง
-
ไม่รองรับการอัปเดตต่อเนื่องภายใน branch เดิม
- การ เชื่อมต่อ commit แบบต่อเนื่องกับ PR และ branch เดิมทำได้ยาก ทำให้งานรีแฟกเตอร์หลายขั้นตอนไม่มีประสิทธิภาพ
- ตอนนี้ Codex จึงเหมาะกับงานง่าย ๆ ที่สั่งจบได้ภายในงานเดียวมากกว่า
-
ข้อจำกัดการเข้าถึงเครือข่ายของ execution sandbox
- ด้วยการออกแบบโดยตั้งใจให้ ไม่สามารถเข้าถึงเครือข่ายภายนอกได้ จึงมีข้อจำกัดกับงานจริงหลายประเภท เช่น การอัปเดตแพ็กเกจหรือจัดการ dependency
- ตัวอย่าง: หากขอให้ติดตั้งแพ็กเกจภายนอก ระบบจะไม่ทำงาน
- งานลักษณะนี้ยังคงต้องจัดการเองบนเครื่องโลคัล หรือพึ่งความสามารถของบอตเดิม เช่น Dependabot
Did it unlock insane productivity gains for me?
- ตอนนี้ยัง ไม่รู้สึกถึงการเพิ่มขึ้นของผลิตภาพแบบก้าวกระโดด
- หาก Codex จะไปสู่ นวัตกรรมด้านผลิตภาพ อย่างแท้จริง ก็จำเป็นต้องมี
- การออกแบบเฉพาะทางและการปรับปรุงอัลกอริทึม เพื่อให้รองรับงานได้มากขึ้นแบบ จบในครั้งเดียว
- การปรับปรุงเวิร์กโฟลว์การอัปเดต PR บน branch เดิม
- การเสริมความสามารถด้าน การมอบหมายงาน/การจัดการแบบรวมศูนย์ และขยายการเชื่อมต่อกับ OpenAI API หลายตัว
- Codex ต้องพัฒนาเป็น orchestrator ระดับสูง
- ในตอนนี้ Codex เหมาะกับงานอัตโนมัติประเภท บำรุงรักษาตามรูทีนและการอัปเดตขนาดเล็ก มากกว่า
- ส่วนการพัฒนาฟีเจอร์ขนาดใหญ่และการรีแฟกเตอร์ยังเหมาะกับการทำงานร่วมกันระหว่าง IDE และ LLM มากกว่า
ความเห็นส่งท้าย
- Codex เป็นเครื่องมือที่ดูเงียบ ๆ แต่ชวนให้คาดหวัง
- เมื่อมองจากฟีเจอร์ที่จะถูกขัดเกลาในอนาคต ก็มีโอกาสสูงที่จะ กลายเป็นจุดเริ่มต้นและเครื่องมือประสานงานของงานประจำวัน
- ตอนนี้ยังเป็นช่วงที่ควร โฟกัสกับงานเบา ๆ ที่ทำซ้ำได้ พร้อมรอการปรับปรุงต่อไป
3 ความคิดเห็น
ดูเหมือนว่ายังไม่ใช่จังหวะที่จะเผาเงิน 200 ดอลลาร์นะ
ความเห็นจาก Hacker News
ฉันเป็นสมาชิก Plus และอยากลอง Codex เลยอัปเกรดเป็น Pro แต่พูดตามตรงจากประสบการณ์ของฉัน ผลลัพธ์ค่อนข้างน่าผิดหวัง
UX ก็ยังให้ความรู้สึกว่ายังไม่ลงตัวดี และน่าหงุดหงิดตรงที่ไม่รู้ว่าจะต้องรอผลนานแค่ไหน
จุดที่ยังพอเป็นข้อดีคือด้วยความที่ Codex ทำงานแบบ asynchronous เลยรันหลายงานพร้อมกันได้
อีกเรื่องที่ไม่ชอบคือ ถ้าจะใช้เครื่องมือนี้ให้มีประโยชน์ ต้องกำหนด environment แยกต่างหาก
มันรัน container ที่จำเป็นสำหรับการทดสอบไม่ได้ ทำให้ประโยชน์ใช้งานลดลงมาก
environment ถูกแยกจากอินเทอร์เน็ตอย่างสมบูรณ์ ทำให้การใช้งานมีข้อจำกัด
ที่ ChatGPT o3 ทรงพลังเพราะมันใช้เว็บค้นข้อมูลเองได้ด้วย แต่ Codex ยังขาดจุดนั้น
ถ้าเทียบกันแล้วฉันก็ใช้ Claude บ่อยเหมือนกัน พอสร้างโปรเจ็กต์จาก GitHub repo เป็น source มันหาบั๊กแปลกๆ ในแอป React ที่ซับซ้อนได้ดี
Gemini ก็รองรับฟีเจอร์แนวนี้ได้ดีเหมือนกัน เพราะมี context window กว้าง
แน่นอนว่าฉันก็เข้าใจทิศทางที่ OpenAI อยากไป
ฉันหวังให้ Codex เป็นเหมือนเพื่อนร่วมงานจริงๆ ที่รับหลายงานไปจัดการให้ แต่ ณ ตอนนี้มันยังให้ความรู้สึกว่าโฟกัสกับ pull request มากเกินไป
เลยคิดว่าจะลดกลับไปใช้ Plus แล้วรอดูไปอีกหน่อย
ฉันทำงานที่ OpenAI แต่ไม่ได้อยู่ทีม Codex และเคยใช้ Codex กับหลายโปรเจ็กต์ได้สำเร็จ
วิธีทำงานของฉันเป็นแบบนี้
ฉันจะรัน prompt เดิมหลายครั้งเสมอ เพื่อให้ได้ผลลัพธ์ที่ต่างกัน
แล้วก็เปรียบเทียบหลาย implementation เพื่อหาอันที่ดีที่สุด พร้อมคิดว่าถ้าปรับ prompt ยังไงถึงจะชี้นำให้ได้ผลลัพธ์ที่ดีขึ้น
ส่วนที่โมเดลทำผิดก็เอาไปแก้ใน prompt แล้ววนทำซ้ำ
ถ้าแบ่งงานออกเป็นหน่วยเล็กๆ แบบนี้แล้วทำการทดลองแบบขนานซ้ำไปเรื่อยๆ แม้แต่โปรเจ็กต์ใหญ่ก็จบได้ในไม่กี่ชั่วโมงด้วยการปรับ prompt และรีวิวโค้ดเป็นหลัก
วิธีนี้มีประโยชน์มากไม่ใช่แค่งานแปลง API แต่รวมถึงโค้ดลึกๆ อย่าง Triton kernel ด้วย
"เลือกอันที่ดีที่สุดจากหลาย implementation แล้วคิดว่าควรเพิ่มอะไรใน prompt ถึงจะพาไปสู่ผลลัพธ์ที่ดีกว่า"
คนที่ไม่ใช่ผู้เชี่ยวชาญอาจสงสัยว่าจะรู้ได้ยังไงว่าอะไรคือ 'ดีที่สุด'
สุดท้ายแล้วการหาทิศทางที่ถูกต้องก็ยังต้องอาศัยความเชี่ยวชาญในสาขานั้น และผมคิดว่านี่เป็นเหตุผลว่าทำไม LLM ยังทำให้งานวิศวกรรมซอฟต์แวร์หายไปไม่ได้
คิดว่าวิธีทำงานที่ลงมือแบบ manual แบบนี้ จริงๆ แล้วอาจเป็นพื้นฐานของ reinforcement learning (RL) ได้
ถ้าปรับประสบการณ์ใน UI แค่นิดหน่อยแล้วเอาไปใช้เป็นข้อมูลจริง ก็น่าจะได้ชุดข้อมูลฝึกที่ดี
สงสัยว่าวิธีนี้เร็วกว่าเขียนโค้ดเองจริงแค่ไหน
สงสัยว่าถ้าพอเปลี่ยน prompt ใหม่แล้วมีจุดสำคัญเปลี่ยนไป จะมีกรณีที่ต้องทิ้งงานที่ทำมาทั้งหมดไหม
ดูเหมือนว่าการเปลี่ยนเล็กน้อยก็อาจส่งผลใหญ่กับผลลัพธ์ได้ และถ้าเป็นปัญหาที่ไม่มีตัวอย่างล่วงหน้า ก็น่าจะยิ่งยาก
ถ้าทำงานแบบนี้วนไปเรื่อยๆ ก็อาจทำให้เหนื่อย หรือหลุดจากแก่นของปัญหาได้เหมือนกัน
สำหรับผมมันอาจดูไม่มีประสิทธิภาพ เลยสงสัยว่าคนอื่นมีความอดทนกับงานวนซ้ำแบบนี้มากกว่าหรือเปล่า
ฉันแชร์รีวิวเกี่ยวกับ Codex ให้ pod ในทีมฉันแล้ว (https://latent.space/p/codex)
มันเป็นโมเดลที่เก่งมากสำหรับการเขียนโค้ดรวดเดียวให้จบในครั้งเดียว (ใน pod ยืนยันว่าได้รับการ fine-tune มาเพื่อโจทย์ OpenAI SWE โดยเฉพาะแบบ oneshot)
แต่ฟีเจอร์ด้าน integration ยังขาดอยู่พอสมควร (เช่น ไม่มี browser integration และ GitHub integration ก็ยังไม่ดี — มันให้เปิด pull request ใหม่ทุก iteration เลย ทำให้การใส่ commit ต่อเนื่องใน branch เดิมไม่สะดวกจนน่าหงุดหงิด)
ถึงอย่างนั้นก็คิดว่าฟีเจอร์ integration พวกนี้น่าจะดีขึ้นเรื่อยๆ ตามเวลา
การที่รัน Codex instance พร้อมกันได้ 60 ตัวต่อชั่วโมง ถือว่าเป็นความต่างเชิงคุณภาพจาก Devin (พร้อมกัน 5 ตัว) หรือ Cursor (ก่อนมี background agent คือพร้อมกัน 1 ตัว)
ฉันเองยังไม่ได้รู้สึกถึงความต่างด้านความสามารถของโมเดล Codex อย่างชัดเจน แม้ OpenAI จะอธิบายว่า Codex สืบสายมาจาก GPT-3 แต่ในความเป็นจริงมันคือ o3 ที่ถูก fine-tune
คิดว่าคำกล่าวว่า “o3 ที่ถูก fine-tune” เองก็ชวนสับสนได้
OpenAI เองก็มีปัญหาเรื่องกฎการตั้งชื่อที่ทำให้คนสับสน และนี่ก็เป็นปัญหาที่บริษัท AI ส่วนใหญ่เจอกัน
เดิม Codex เป็นโมเดลรุ่นเก่าที่อิง GPT-3 และตอนนี้ชื่อเดียวกันก็ถูกนำกลับมาใช้ซ้ำกับ CLI และเครื่องมืออีกหลายอย่าง
Google ก็ทำแบบเดียวกัน โดยใช้ชื่อ “Gemini Ultra” ทั้งเป็นชื่อโมเดลและชื่อแพ็กเกจสมัครสมาชิก จนทำให้สับสน
ส่วนที่ไม่สะดวกที่สุดสำหรับฉันคือการจำกัดการเข้าถึงเครือข่าย
git fetch, sync กับ upstream หรือแก้บั๊กตอน integration ไม่ได้ดูเหมือนว่าจะบล็อกโดเมนไว้จนแม้แต่
apt installใน setup script ก็ทำไม่ได้ตัว agent เองก็ดูมีแนวโน้มจะเริ่มจาก
git grepไปก่อน มากกว่าจะพยายามทำความเข้าใจบริบทของโค้ดทั้งก้อน (เห็นได้จาก UI) เลยให้ความรู้สึกเฉยๆอยากรู้ว่าถ้าเทียบกับ Claude Code แล้วต่างกันตรงไหนบ้าง
คิดว่าความสามารถในการแก้หลาย repo ได้เร็วมากเป็นอะไรที่สุดยอดจริงๆ
ฉันดูแล example app จำนวนมากพร้อมกัน และการเปลี่ยนฟอร์แมต README หรือแก้ลิงก์ ถ้าต้องทำซ้ำเกิน 20 ที่ มันน่าเบื่อมาก
ถ้ายกงานจุกจิกแบบนี้ให้ Codex แล้วฉันค่อยมากดปุ่ม merge ทีหลังได้ ฉันคงมีความสุขมาก
คาดว่าอีกไม่นานมันจะพัฒนาไปถึงจุดนั้น
ในช่วงนี้น่าจะยังใช้ Codex กระจายงานบำรุงรักษาเล็กๆ น้อยๆ ไปก่อน ส่วนงานรีแฟกเตอร์ใหญ่หรือการพัฒนาสำคัญก็คงยังทำต่อใน IDE
สงสัยว่าเครื่องมือประเภทนี้จะช่วยให้คนที่ไม่ใช่นักพัฒนาทำการแก้โค้ดได้ไหม
งานอย่างแก้คอนเทนต์หรือปรับ CSS ง่ายๆ เป็นอะไรที่ฉันไม่อยากทำเองจริงๆ และการทดสอบก็แค่ดูด้วยสายตาก็พอ เลยคิดว่าแค่ฉันรีวิวโค้ดก็น่าจะเพียงพอ
ให้คนที่ไม่ใช่นักพัฒนาเปิดดู ticket เริ่มงาน แล้วส่งผลลัพธ์มาแบบ "อันนี้ดูโอเค" จากนั้นฉันค่อยตรวจอีกที
คิดว่านี่เป็น workflow ที่เหมาะมากสำหรับบั๊กเล็กๆ หรือการปรับปรุงฟีเจอร์เล็กๆ ใน backlog
คิดว่าเครื่องมืออย่าง AI Assist สุดท้ายแล้วอาจกลายเป็นแพลตฟอร์ม low-code ที่ดีที่สุด
ก็เลยแอบหวังว่าวันหนึ่งวิศวกรซอฟต์แวร์อาจถูกแทนที่ได้จริง
แต่แม้แต่การแก้คอนเทนต์ก็ยังต้องคิดลึกอยู่บ่อยๆ
แค่ระบบมีขนาดเพิ่มขึ้นนิดหน่อย ก็มี dependency ต้นน้ำปลายน้ำตามมา และแค่เพิ่ม field เดียว ทั้งระบบก็มีเรื่องให้ต้องคำนึงถึงมากมาย
แม้แต่การเปลี่ยน CSS เล็กๆ ก็ดูเหมือนเล็ก แต่ในความเป็นจริงมันเล็กแค่ไหน ผู้ใช้ก็มักตอบได้ยาก
ประเด็นอย่าง accessibility, multi-platform (มือถือ/เดสก์ท็อป) และปัญหาอีกมากมาย ก็น่าจะได้เรียนรู้อย่างรวดเร็วในไม่ช้า
ถึงขั้นมองได้เลยว่ากระแสนี้เป็นเหมือน funnel ที่พาคน "ไหลเข้า" สู่งานวิศวกรรมซอฟต์แวร์
สำหรับงานเล็กๆ ฉันคิดว่าอัตราสำเร็จ 40~60% ก็ถือว่าใช้ได้ทีเดียว
การได้รู้ว่ามันยังลำบากกับงานที่ซับซ้อนขึ้นและต้องใช้ตรรกะลึกกว่านี้ก็เป็นข้อมูลอ้างอิงที่ดี
ประสิทธิภาพตอนนี้อยู่ในระดับวิศวกรจูเนียร์ที่แย่มาก
ตัวอย่างเช่น พอสั่งให้แก้บางอย่าง มันกลับแก้ค่าในคลาสทั้งหมดให้เป็น nullable เพื่อกำจัด compiler warning
ภายนอกดูเหมือนทำงานได้และคอมไพล์ผ่าน แต่จริงๆ คือผลลัพธ์ที่ผิดโดยสิ้นเชิง เพราะทำลาย data integrity ไปด้วย
เคสแบบนี้มีค่อนข้างเยอะ
ถ้าปล่อย codebase ทั้งหมดให้ Codex ดูแลแบบไม่มีคนกำกับ เทคนิคัลเด็บต์คงพอกพูนเร็วมาก
ความคาดหวังที่ว่า Codex จะช่วยให้พวกเราปล่อยให้มันทำงานแทนตอนเราไม่อยู่ ดูจะมองโลกสวยเกินไป
สำหรับหลายคน คำว่า "ทำงานได้มีประสิทธิภาพแม้เราไม่อยู่" มันแตะกับความหมายของ "แถวคนตกงาน" อยู่ไม่น้อย
น่าประหลาดใจเหมือนกันที่นักพัฒนาหลายคนดูตื่นเต้นกับการเปลี่ยนแปลงนี้
บรรยากาศมันเหมือนมีคนหลงคิดว่าสักวันเราจะได้นั่งดู agent ทำทุกอย่างแทนแล้วรับเงินไปเฉยๆ
ต่อให้งานง่ายขึ้น สุดท้ายมันก็อาจพาไปในทิศทางที่ตำแหน่งงานหายไปอยู่ดี
ในประวัติศาสตร์ของการเพิ่ม productivity แทบไม่มีตัวอย่างเลยที่แรงงานจะได้เวลาอิสระเพิ่มขึ้น
สุดท้ายก็มักลงเอยเป็นกำไรของผู้ถือหุ้นและผู้บริหาร ภาระงานของพนักงานที่เหลือเพิ่มขึ้นครึ่งหนึ่ง และที่เหลือก็ตกงาน
คิดว่าอย่างน้อยในระยะสั้นคงยังต้องใช้เวลาอีกกว่าจะไปถึงขั้นตกงาน
การทำให้โมเดลพวกนี้ทำงานได้ถูกต้อง 90~95% ในงานหลากหลายประเภท ต้องใช้ความพยายามมหาศาล
เพราะอะไรก็ตาม 60~70% แรกมักง่าย แต่ 5~10% สุดท้ายนั่นแหละที่ยากจริง
อย่างที่พูดไว้ข้างบน ทุกวันนี้การรันหลายครั้งเพื่อให้ได้ผลหลายแบบแล้วคัดเลือก ยังมีต้นทุนสูงกว่ามาก และถ้าจะใช้กับทุกงานแบบเหมารวม ต้นทุน inference ก็จะสูงมากด้วย
พอถึงจุดหนึ่ง code review ก็จะยิ่งจำเป็น โดยเฉพาะเมื่อเป็นโค้ดที่เครื่องเขียน
สำหรับโปรเจ็กต์เล็กหรือฟีเจอร์เล็กๆ อาจพอเชื่อใจงานจากเครื่องได้ แต่ถ้าเป็น codebase ที่ต้องอยู่ยาว มนุษย์ก็คงยังต้องทำสถาปัตยกรรมและการตรวจทานต่อไป
AI ช่วยให้ลองสำรวจวิธีได้หลากหลายขึ้นและเร็วขึ้น แต่การตัดสินใจสุดท้ายก็ยังเป็นหน้าที่ของมนุษย์ และต้องรักษาคุณภาพด้วยการออกแบบหรือรีวิวเอง
ในอนาคตอันใกล้ ทีมวิศวกรรมคงเริ่มมองหาวิธีใช้ background agent อย่างจริงจังมากขึ้น
แต่ฉันยังสงสัยกับแนวทางที่โยนทุกอย่างให้โมเดลแรงๆ ทำแทนแบบทุกวันนี้
งาน AI code review ตอนนี้ค่อนข้างชวนหงุดหงิด จึงต้องการ workflow ที่ดีกว่านี้
อีกหลายปีข้างหน้า “background agent” เองน่าจะกลายเป็นโครงสร้างพื้นฐานจำเป็นของแต่ละบริษัท
บริษัทส่วนใหญ่คงใช้โครงสร้างพื้นฐาน agent ผ่าน API มากกว่าจะโฮสต์เอง
โครงสร้างพื้นฐานด้านวิศวกรรมแบบ agent-based ยังอยู่ในช่วงเริ่มต้นมาก จึงน่าจะมีโอกาสงานใหม่ๆ เพิ่มขึ้นอีกมากเช่นกัน (ในอีก 3~5 ปีข้างหน้า)
ถ้ามองในแง่ดี ยิ่งของบางอย่างผลิตได้ถูกลง (เช่น โค้ด) ความต้องการต่อสิ่งนั้นก็อาจยิ่งเพิ่มขึ้น
คนที่ไม่ใช่นักพัฒนาอาจทำหน้าที่เป็นผู้จัดการได้ แต่จากประสบการณ์ของฉัน เวลางานสำคัญจริงๆ ผู้คนก็มักอยากมอบให้คนที่เชื่อถือได้กว่า ซึ่งก็คือมนุษย์
มีความคิดว่าอาจเปรียบนักพัฒนาซอฟต์แวร์เป็นม้า และ agent โมเดลรุ่นใหม่อย่าง Codex หรือ Claude Code เป็นรถยนต์
กำลังคิดอยู่ว่ากรอบเปรียบเทียบแบบที่ม้าบางตัวจะกลายเป็นคนขับรถ ส่วนบางตัวไม่ต้องลากเกวียนอีกต่อไปเลยกลายเป็นคนตกงาน แบบนี้จะตรงไหม
ฉันหาแหล่งที่รวบรวมรายชื่อภาษาที่รองรับไว้ไม่เจอ
ทั้งในหน้าแนะนำทางการหรือรีวิวต่างๆ ก็ไม่ได้บอกไว้อย่างชัดเจน และส่วนใหญ่ก็อธิบายด้วยตัวอย่างอย่างการแก้คำผิดบนหน้าเว็บเท่านั้น
ดูเหมือนเป็นของที่ทำขึ้นได้แบบรวดเร็วในเวลาแค่สัปดาห์เดียวด้วย gptel-tool
ถ้าใช้เป็นคนรับใช้ ก็ถือว่าใช้ได้ดีเลย!