- GenAI (LLM) กำลังเพิ่มผลิตภาพของนักพัฒนาด้วยความสามารถในการสร้างและช่วยเขียนโค้ดโดยอัตโนมัติ
- แม้ในอดีตจะมีเครื่องมือประเภท “ไม่ต้องเขียนโค้ด” อยู่แล้ว แต่ในท้ายที่สุด กระบวนการวิศวกรรมซอฟต์แวร์จริงก็ยังคงมีความซับซ้อนเฉพาะตัวอยู่เสมอ
- หลังการเปิดตัว ChatGPT ความเร็วในการพัฒนาของเครื่องมือ AI นั้นโดดเด่นชัดเจน แต่แทนที่จะเปลี่ยนทุกขั้นตอนแบบพลิกวงการ เครื่องมือเหล่านี้กลับมีบทบาทในการย่นบางขั้นตอนของโจทย์ที่ได้รับลงอย่างมาก
วิธีใช้งานจริงของนักพัฒนาแยกออกเป็นสองสาย
- bootstrappers
- ใช้เครื่องมืออย่าง Bolt, v0, Screenshot-to-code เพื่อสร้างโปรเจกต์ใหม่หรือ MVP ได้อย่างรวดเร็ว
- AI สามารถสร้างโค้ดเบสเริ่มต้นที่สมบูรณ์จากดีไซน์ (เช่น Figma) หรือแม้แต่คอนเซปต์แบบหยาบ ๆ ได้
- สร้างต้นแบบที่ใช้งานได้ภายในไม่กี่ชั่วโมงถึงไม่กี่วัน
- แม้จะยังไม่สมบูรณ์พอสำหรับระดับ production แต่มีจุดแข็งด้านการพิสูจน์ไอเดีย
- ให้ความสำคัญกับการทดสอบสมมติฐานและทำซ้ำอย่างรวดเร็ว
- iterators
- ใช้ Cursor, Cline, Copilot, WindSurf และอื่น ๆ ในกระบวนการพัฒนาประจำวัน
- ใช้ AI สำหรับ autocomplete โค้ด, การ refactor ที่ซับซ้อน, การสร้างเทสต์และเอกสาร
- มอบหมายงานอย่างการทดสอบที่ซับซ้อน การทำเอกสาร และการ refactor ให้ AI แต่ยังตรวจสอบผลลัพธ์อย่างต่อเนื่อง
- ใช้งานในลักษณะคล้าย “pair programmer” ที่ช่วยกันแก้ปัญหา
- นักพัฒนาจะวนลูปเลือก แก้ไข และเติมเต็มข้อเสนอของ AI เพื่อพัฒนาให้เป็นโค้ดที่เหมาะสมที่สุด
ปัญหา 70%: ความยากของ “30% สุดท้าย” - ความย้อนแย้งของเส้นโค้งการเรียนรู้ของ AI
- AI สามารถสร้างโค้ดได้รวดเร็วถึงราว 70% แต่ 30% สุดท้ายกลับเป็นคอขวดใหญ่
- มักเกิดวงจรแย่ ๆ แบบแก้บั๊กจุดเล็กแล้วไปพังอีกส่วนหนึ่งแทน
- โดยเฉพาะคนที่ไม่ได้จบสายนี้หรือจูเนียร์ มักเผลอรับโค้ดที่ AI เสนอทั้งหมดจนก่อปัญหาต่อเนื่องได้ง่าย
- มักยากที่จะเข้าใจว่าทำไมสิ่งที่ AI เสนอให้แก้ถึงทำให้เกิดปัญหา
- นักพัฒนาระดับซีเนียร์ที่มีประสบการณ์สามารถอนุมานสาเหตุของบั๊กได้เร็ว ปรับโครงสร้างโค้ดใหม่ และคำนึงถึงความปลอดภัยกับประสิทธิภาพเพิ่มเติมเพื่ออุดช่องที่ AI มองข้าม
- แม้จะใช้ AI อย่างเต็มที่ ก็ยังรีวิวและ refactor อย่างต่อเนื่องเพื่อทำให้เป็น “โค้ดที่ดูแลรักษาได้”
- หากจูเนียร์หรือคนที่ไม่ใช่นักพัฒนารับโค้ดที่ AI สร้างมาแบบไม่ทันคิด ก็มีความเสี่ยงที่จะได้ “house-of-cards code” ที่พังง่ายเมื่อขึ้นสภาพแวดล้อมจริง
- ความย้อนแย้งของความรู้
- ซีเนียร์สามารถใช้ AI ช่วยสร้างสิ่งที่ตัวเองเข้าใจอยู่แล้วได้อย่างรวดเร็ว
- ส่วนจูเนียร์ควรใช้ AI เพื่อเรียนรู้ แต่ถ้าพื้นฐานไม่พอ ก็จะลำบากมากในขั้นตอน debug และตรวจสอบความถูกต้อง
รูปแบบการใช้งานที่มีประสิทธิภาพ
- ให้ AI ร่างก่อนแล้วค่อยแตกละเอียด
- เมื่อ AI ทำ implementation เริ่มต้นให้แล้ว มนุษย์จะเป็นผู้ตรวจทาน, refactor และทดสอบด้วยตัวเอง
- เพิ่มการจัดการข้อผิดพลาดและกรณียกเว้นด้วยมือ พร้อมเสริมกระบวนการทดสอบอัตโนมัติและรีวิวเพื่อเพิ่มความน่าเชื่อถือ
- เสริมความเป็นโมดูล, การจัดการข้อผิดพลาด, การกำหนด type และการออกแบบสถาปัตยกรรม เพื่อให้บำรุงรักษาได้
- คงบทสนทนาแยกตามหน่วยงาน
- แทนที่จะโยนบริบทใหญ่ทั้งหมดในครั้งเดียว ให้ใช้พรอมป์ต์แยกสำหรับปัญหาเล็กแต่ละเรื่องเพื่อให้ได้คำตอบที่โฟกัสกว่า
- ทบทวนและ commit การเปลี่ยนแปลงบ่อย ๆ พร้อมนำ feedback กลับมาใช้ในรอบสั้น ๆ
- แนวทางแบบ “เชื่อใจแต่ต้องตรวจสอบ”
- ให้ AI สร้างฉบับร่าง แต่ตรรกะสำคัญ การจัดการข้อผิดพลาด และประเด็นด้านความปลอดภัยยังต้องให้คนดูเอง
- เขียน test case เสมอ และตรวจสอบประสิทธิภาพ ความปลอดภัย และความสมเหตุสมผลเชิงโครงสร้างอย่างละเอียด
สิ่งที่นักพัฒนาควรได้คิด
- เริ่มจากเล็ก ๆ
- ลองใช้ AI กับงานเล็กที่นิยามชัดเจนหรือปัญหาที่มีขอบเขตชัดก่อน แล้วตรวจโค้ดที่สร้างมาอย่างละเอียด
- ก่อนขยับไปฟีเจอร์ขนาดใหญ่ ควรจัดการเรื่องเทสต์และเอกสารให้รัดกุม แล้วค่อยขยายขอบเขตทีละขั้น
- รักษาความเป็นโมดูล
- แยกโค้ดเบสอย่างเหมาะสมเพื่อไม่ให้โค้ดที่ AI สร้างปะปนกันจนโครงสร้างสับสน
- แยกไฟล์และฟังก์ชันเป็นหน่วยเล็ก ๆ พร้อมกำหนด interface และทิศทาง dependency ให้ชัดเจน
- เชื่อในประสบการณ์ของตนเอง
- ใช้ AI เป็นผู้ช่วย แต่การตัดสินใจสุดท้ายให้ยึดประสบการณ์ของตัวเอง
- ควรตั้งข้อสงสัยกับโค้ดหรือดีไซน์ที่ดูน่าสงสัย และยึดตามมาตรฐานทางวิศวกรรม
การมาของวิศวกรรมซอฟต์แวร์แบบ agentic
- เดิมทีเครื่องมือ AI อยู่ในระดับตอบคำสั่งแล้วสร้างโค้ด แต่ต่อจากนี้จะพัฒนาไปสู่แนวคิดแบบ agentic
- AI แบบ agentic สามารถวางแผน เป้าหมาย ลงมือทำ และตรวจสอบได้ด้วยตัวเองมากขึ้น จึงทำงานได้อัตโนมัติกว่าเดิม
- Claude (Anthropic), Cline และอื่น ๆ ไปไกลกว่าแค่ autocomplete โดยสามารถเปิดเบราว์เซอร์อัตโนมัติและรันเทสต์ได้
- กระบวนการ debug ก็จะเปลี่ยนไป
- agent สามารถค้นหาปัญหาที่อาจเกิดขึ้น รันชุดทดสอบ และตรวจสถานะ UI เพื่อเสนอแนวทางแก้ไขได้เอง
- เครื่องมือในอนาคตจะไม่ได้จัดการแค่โค้ด
- แต่จะเข้าใจและผสานหลายช่องทางรับข้อมูล เช่น ภาพหน้าจอ UI, ไดอะแกรม และบทสนทนาด้วยเสียง
- ในกระแสนี้ สิ่งที่นักพัฒนาต้องทำคือ
- ปล่อยให้ AI ทำงานอย่างสร้างสรรค์ได้ แต่ยังต้องอยู่ภายใต้คำแนะนำของมนุษย์และทำงานในสถาปัตยกรรมที่แข็งแรง
- สร้าง feedback loop ที่แข็งแรงระหว่างมนุษย์กับ AI
- คาดว่าจะเกิดโมเดลการทำงานร่วมกันที่มนุษย์กำหนดภาพใหญ่และเป้าหมาย ส่วน agent จัดการงานรายละเอียด
- ดังคำพูดที่ว่า “ภาษาโปรแกรมที่สำคัญที่สุดคือภาษาอังกฤษ” ความสามารถในการอธิบายความต้องการด้วยภาษาธรรมชาติที่ชัดเจนและแม่นยำจะยิ่งสำคัญขึ้น
งานช่างฝีมือซอฟต์แวร์จะกลับมาหรือไม่?
- ด้วย AI ทำให้ต้นแบบและเดโมสร้างได้เร็วขึ้น
- แต่เมื่อผู้ใช้จริงเริ่มใช้ซอฟต์แวร์ในสภาพแวดล้อมที่หลากหลายและมี edge case มากมาย ปัญหาก็จะเริ่มเกิดขึ้น
- ข้อความ error ที่ผู้ใช้ไม่สามารถเข้าใจได้
- สภาพแวดล้อมเฉพาะที่ทำให้เกิดการ crash (edge case)
- การออกแบบที่ไม่คำนึงถึง accessibility เลย
- ปัญหาด้านประสิทธิภาพบนอุปกรณ์ที่ช้า
- รายละเอียดอย่าง UI/UX เป็นตัวตัดสินคุณภาพ
- หากจะทำให้เป็นผลิตภัณฑ์ที่ “ขัดเกลา” ดีจากมุมมองผู้บริโภค ก็ต้องอาศัยความละเอียดและความใส่ใจแบบมนุษย์
- เมื่อ AI ช่วยลดงานซ้ำ ๆ นักพัฒนาก็จะมีเวลาโฟกัสกับความสมบูรณ์ในรายละเอียดเหล่านี้มากขึ้น
- สามารถทุ่มเวลาให้กับด้านที่เป็นทั้งความเป็นมนุษย์และความเป็นมืออาชีพ เช่น ประสบการณ์ผู้ใช้, edge case และการจัดการข้อผิดพลาดที่มีความหมาย
ข้อคิดเพิ่มเติม
- กระบวนการวิศวกรรมซอฟต์แวร์ ครอบคลุมหลายด้าน เช่น การวางแผน การออกแบบ การพัฒนา การตรวจสอบ การมอนิเตอร์ และการบำรุงรักษา โดยปัจจุบัน AI ช่วยเพิ่มประสิทธิภาพได้มากที่สุดในส่วน “การเขียนโค้ด”
- ในอดีตก็เคยมีความพยายามแนว “คนที่ไม่ใช่นักพัฒนาก็สร้างซอฟต์แวร์ได้ง่าย” ผ่าน COBOL, Visual Basic, แพลตฟอร์ม no-code และอื่น ๆ แต่เมื่อความซับซ้อนเพิ่มขึ้น สุดท้ายก็ยังต้องพึ่งนักพัฒนาที่มีทักษะ
- ยิ่งเครื่องมือ LLM เพิ่มปริมาณโค้ดได้แบบก้าวกระโดดมากเท่าไร ในโปรเจกต์ที่ซับซ้อนก็ยิ่งมีแนวโน้มต้องการวิศวกรระดับซีเนียร์มากขึ้นเท่านั้น
- นักพัฒนาที่มีทักษะและรู้วิธีใช้ AI สามารถยกระดับคุณค่าของตนเองได้มากขึ้น
- โดยสรุป เครื่องมือ AI มีแนวโน้มจะไม่ได้มาแทนนักพัฒนาอย่างสมบูรณ์ แต่จะพัฒนาไปในทิศทางที่ทำให้นักพัฒนาที่มี insight และประสบการณ์ยิ่งทรงพลังขึ้น
ข้อคิดเพิ่มเติม (รวมคอมเมนต์ของ Gergely)
- ในงานวิศวกรรมซอฟต์แวร์ สัดส่วนของการเขียนโค้ดเองนั้นไม่ได้มากนักมาตั้งแต่อดีตแล้ว
- ในอดีต Fred Brooks เคยประมาณเวลาการทำงานด้านซอฟต์แวร์ไว้ประมาณ
- ⅓ การวางแผน
- ⅙ การเขียนโค้ด
- ¼ การทดสอบคอมโพเนนต์และระบบ
- ¼ การทดสอบระบบ (รวมทุกคอมโพเนนต์ด้วยมือ)
โดยจัดประเภทไว้เช่นนี้
- จากมุมมองปัจจุบัน เวลาที่ใช้กับการเขียนโค้ด (รวมเทสต์) เพิ่มขึ้น แต่การวางแผน การรีวิวโค้ด การมอนิเตอร์ และการ rollout ก็ยังคงกินสัดส่วนสำคัญ
- 20% การวางแผน
- 40% การเขียนโค้ด (โค้ด + เทสต์)
- 20% การรีวิวโค้ด (โค้ดของผู้อื่น)
- 20% การเตรียมพร้อม production + rollout + การแก้ไขย่อยระหว่างช่วงนั้น + การมอนิเตอร์ + การแจ้งเตือน
- กระบวนการสร้างซอฟต์แวร์ให้ดี
- 1. What: ตัดสินใจว่าจะสร้างอะไร
- รวมถึง brainstorming, การออกแบบ, การทดสอบกับผู้ใช้, และการทำงานร่วมกับ product manager และผู้มีส่วนได้ส่วนเสียทางธุรกิจ
- สำหรับสตาร์ตอัป ขั้นตอนนี้อาจสั้นมาก (“ลองทำออกมาดูแล้วดูปฏิกิริยา”)
- แต่ถ้าเป็นบริษัทที่มั่นคงแล้ว อาจต้องใช้เวลามากขึ้นในการตัดสินใจว่าจะสร้างอะไร เพื่อไม่ให้ลูกค้าเดิมสับสน
- 2. How: วางแผนว่าจะสร้างอย่างไร
- ออกแบบอย่างเป็นรูปธรรมว่าจะทำผลิตภัณฑ์/ฟีเจอร์/บริการนั้นอย่างไร
- พิจารณาผลกระทบต่อสถาปัตยกรรม, dependency และกลยุทธ์การทดสอบ
- สตาร์ตอัปอาจข้ามขั้นนี้แล้วลงมือเลยได้ แต่ในองค์กรใหญ่ หากมองข้ามการออกแบบล่วงหน้า ปัญหาอาจหนักขึ้นในภายหลัง
- ทีมส่วนใหญ่มักใช้ Design doc, RFC, ADR และอื่น ๆ เพื่อผ่านกระบวนการวางแผนในระดับหนึ่ง
- 3. Build: ลงมือพัฒนาฟีเจอร์จริง
- เขียนฟีเจอร์หรือผลิตภัณฑ์ที่ต้องการออกมาเป็นโค้ด และตรวจให้แน่ใจว่าทำงานได้ถูกต้อง
- 4. Verify: ตรวจสอบ
- ก่อน deploy ไป production ต้องตรวจอย่างละเอียดว่าทำงานได้ตามคาดหรือไม่
- โดยเฉพาะในบริการทางการเงินที่ความผิดพลาดอาจก่อผลร้ายแรง กระบวนการ QA จะต้องเข้มงวดมาก
- 5. Ship it: ปล่อยใช้งาน
- merge การเปลี่ยนแปลงและ release ให้ลูกค้า
- วิธี deploy ไป production มีได้หลากหลาย
- 6. Monitoring and oncall: มอนิเตอร์และ oncall
- เมื่อตัวผลิตภัณฑ์มีปัญหา ต้องตรวจพบและแก้ไขให้ได้ทันที
- พร้อมทั้งทำ postmortem หรือมาตรการติดตามผลเพื่อไม่ให้เหตุขัดข้องเดิมเกิดซ้ำ
- 7. Maintain: บำรุงรักษา
- รวบรวมข้อร้องเรียนและ feedback จากผู้ใช้ แล้วตัดสินใจว่าควรแก้บั๊กไหนหรือให้ความสำคัญกับการปรับปรุงฟีเจอร์ใดก่อน
- รวมถึงกระบวนการคัดกรอง feedback ที่สามารถมองข้ามได้
- 8. Migrate: ย้ายระบบ
- เมื่อผลิตภัณฑ์เปลี่ยนแปลงครั้งใหญ่หรือ tech stack เปลี่ยน ก็อาจจำเป็นต้องมี migration ขนาดใหญ่
- ปัจจุบันเครื่องมือ AI ช่วยได้มากในขั้น “Build” แต่ก็น่าคิดต่อว่าในอีก 7 ส่วนที่เหลือที่กล่าวมา มันจะมีประโยชน์ได้มากแค่ไหน
- นับตั้งแต่ทศวรรษ 1960 ก็มีความฝันเรื่อง “คนที่ไม่ใช่นักพัฒนาสามารถสร้างซอฟต์แวร์ได้โดยไม่ต้องมีนักพัฒนา” ต่อเนื่องมา
- COBOL, Visual Basic, no-code คือบางตัวอย่าง
- เว็บไซต์ง่าย ๆ อาจสร้างได้โดยไม่ต้องเขียนโค้ดเลย แต่เมื่อเป็นผลิตภัณฑ์ที่ซับซ้อน งานวิศวกรรมก็ยังจำเป็นอยู่ดี
- ยิ่งเครื่องมือมีพลังในการแสดงออกสูงขึ้น ก็ยิ่งต้องสั่ง AI แบบละเอียดเฉพาะเจาะจงว่า “ควรทำงานอย่างไร” ทำให้ความซับซ้อนเพิ่มขึ้นตามไปด้วย
- ยิ่ง AI สร้างโค้ดได้มาก ความต้องการวิศวกรมืออาชีพที่ดูแลการบำรุงรักษาและสถาปัตยกรรมก็ยิ่งมีแนวโน้มเพิ่มขึ้น
- ซีเนียร์ที่เรียนรู้วิธีทำงานร่วมกับ LLM ได้ดีในปัจจุบัน จะมีผลิตภาพสูงขึ้นและสร้างคุณค่าให้บริษัทได้มากกว่าเดิม
AI agent: คำสัญญาสำคัญ แต่ในปี 2025 ก็ยังเป็น 'พื้นที่ที่ยังไม่รู้'
- สองปีหลังการเปิดตัว LLM นักพัฒนาจำนวนมากได้เรียนรู้วิธีใช้ LLM กับงานเขียนโค้ดและวิศวกรรมซอฟต์แวร์มากขึ้นเรื่อย ๆ
- LLM มีส่วนช่วยอย่างมากในงานทำต้นแบบ การย้ายไปใช้ภาษาที่ไม่คุ้นเคย การตรวจสอบความถูกต้องของผลลัพธ์ และการจับคำตอบผิดพลาดหรือ hallucination
- อย่างไรก็ตาม AI agent ยังอยู่ในระยะแรก
- ตอนนี้ agent ที่ใช้งานได้ทั่วไปมีประมาณ Devin ซึ่งมีค่าใช้จ่ายสูงถึง 500 ดอลลาร์ต่อเดือน และเสียงประเมินก็ยังแตกเป็นสองฝั่ง
- เมื่อเงินทุนจาก venture ไหลเข้า คาดว่าจะมีเครื่องมือ AI coding agent ออกมาอีกมาก
- ราคาก็น่าจะค่อย ๆ ลดลง
- GitHub Copilot มีแนวโน้มจะเปิดให้ Copilot Workspace ที่เป็น agent-based ใช้งานทั่วไปในปี 2025
- /dev/agents ที่ก่อตั้งโดยอดีต CTO ของ Stripe ก็มีแผนจะเปิดตัวเช่นกัน
- AI agent มุ่งแลกเวลาตอบสนองที่ช้าลง (กระบวนการ “คิด”) และต้นทุนที่สูงขึ้น เพื่อหวังเพิ่มความแม่นยำ
- แต่ก็ยังไม่แน่ชัดว่าแนวทางนี้จะเพิ่มความแม่นยำได้มากเพียงใด และจะสร้างผลิตภาพที่ดีขึ้นอย่างมีนัยสำคัญในกรณีงานวิศวกรรมแบบไหนบ้าง
ความเป็นไปได้ที่ความต้องการวิศวกรซอฟต์แวร์ที่มีประสบการณ์จะเพิ่มขึ้น
- วิศวกรซอฟต์แวร์ที่มีประสบการณ์สูง (ระดับซีเนียร์ขึ้นไป) อาจเป็นที่ต้องการมากกว่าเดิม
- คนกลุ่มนี้ใช้เครื่องมือ AI ได้มีประสิทธิภาพกว่า และรู้ว่า “ผลลัพธ์ที่ยอดเยี่ยม” หน้าตาเป็นอย่างไร จึงสามารถ “สั่งงาน” ได้อย่างแม่นยำ
- เมื่อจับได้ว่าเกิดการสร้างโค้ดผิด ก็สามารถตัดสินใจได้ว่าเมื่อไรควรหยุดกระบวนการสร้างแล้วลงมือแก้ซอร์สโค้ดเอง
- ด้วยความช่วยเหลือของ AI จะมีการเขียนโค้ดมากขึ้นอย่างมหาศาล และทั้งบุคคลกับองค์กรก็มีแนวโน้มจะสร้างโซลูชันของตัวเองมากขึ้น
- แต่เมื่อความซับซ้อนเพิ่มขึ้น ก็ยิ่งต้องการวิศวกรที่มีประสบการณ์มาควบคุมมัน
- บริษัทเทคที่มีอยู่เดิมเองก็มีแนวโน้มต้องการคนมารับมือกับความซับซ้อนที่ AI ทำให้เพิ่มขึ้นด้วย
- หากวิศวกรซอฟต์แวร์พัฒนาความสามารถในการทำงานร่วมกับ AI ได้ ก็จะเป็นวิศวกรที่มีผลิตภาพสูงขึ้นและมีคุณค่ามากขึ้น
- เพราะต้องใช้เวลาพอสมควรกว่าจะเรียนรู้วิธี “ฝึก” เครื่องมือเหล่านี้ให้เข้ามือ จึงสำคัญที่จะต้องทดลองและเรียนรู้อย่างจริงจังท่ามกลางสภาพแวดล้อมของเครื่องมือที่เปลี่ยนแปลงเร็ว
11 ความคิดเห็น
เป็นบทความที่ดีมากจริง ๆ ครับ
เห็นด้วยมากกับย่อหน้าสุดท้ายเรื่อง "ความเป็นไปได้ที่ความต้องการวิศวกรซอฟต์แวร์ที่มีทักษะสูงจะเพิ่มขึ้น" คงเป็นประมาณว่า ยิ่งรู้มาก ก็ยิ่งเขียนได้ดี ใช่ไหมล่ะ? ^^
เหมือนกับ Expo 52 ในช่วงหลัง ๆ ที่มีการเปลี่ยนแปลงครั้งใหญ่ แม้แต่ Claude ที่ฉลาดก็ช่วยอะไรไม่ได้มากนัก
มีประสบการณ์ว่าเขาชอบแนะนำโค้ดเก่าที่เลิกใช้ไปแล้วอยู่เรื่อย ๆ จนกลับกลายเป็นการรบกวนมากกว่า
สุดท้ายแล้ว ดูเหมือนว่าจะใช้ AI ให้ได้ผลจริงก็ต้องมี "สายตาในการดู" ที่ผ่านการฝึกฝนมาด้วยเช่นกัน
เป็นเรื่องเล็กน้อย แต่เท่าที่ทราบ
/dev/agentsไม่ใช่โค้ดดิงเอเจนต์ครับ แม้จะยังไม่เปิดตัว แต่ก็บอกตัวเองว่าเป็น "OS สำหรับ AI เอเจนต์" อยู่ครับโดยส่วนตัวแล้วผมคิดและเดิมพันว่าในอนาคต (หรือมองในระยะกลางแล้วแต่แต่ละมุมมอง) บทบาทของการเป็นโค้ดเดอร์จะลดลงในทุกตำแหน่งของวิศวกร และบทบาทแบบ TPM จะขยายใหญ่ขึ้น
เพราะ Cursor เขียนโค้ดได้ดีกว่า เราน่าจะมอบหมายให้มันทำ แล้วมนุษย์ก็คงทำงานส่วนใหญ่บนเลเยอร์นามธรรมที่อยู่เหนือขึ้นไป
ขอบคุณสำหรับการแชร์ครับ/ค่ะ ผม/ฉันเองก็เพิ่งเขียนบทความที่เกี่ยวข้องไปชิ้นหนึ่งเมื่อเร็ว ๆ นี้ ซึ่งก็มีบางแง่มุมที่คล้ายกันครับ/ค่ะ https://www.stdy.blog/can-junior-beat-coding-agent/
สรุป: อนาคตของนักพัฒนาจากอิทธิพลของ AI (มุมมองด้านบวก)
?? : ตอนนี้ไม่ต้องมีนักพัฒนาแล้วสินะ (ฉบับบริษัทห่วยแตก)
โห 5555555
1+ 555
ฮ่าๆ 100 คะแนน