ทำไมยังต้องเขียนโค้ดในปี 2026
(softwaredoug.com)- บทบาทของวิศวกรซอฟต์แวร์ขยายจากการผลิตโค้ดไปสู่การสร้างและดูแล โรงงานซอฟต์แวร์ แต่หากต้องการเข้าใจและปรับปรุงระบบ ก็ยังจำเป็นต้องลงมือจัดการโค้ดด้วยตนเอง
- หากชี้นำเอเจนต์ด้วยพรอมป์,
AGENTS.mdและฐานความรู้ พร้อมปกป้องผลลัพธ์ด้วยการทดสอบ, linting, type system และการประเมิน แม้แต่ โมเดลที่ประสิทธิภาพต่ำ ก็สามารถสร้างการเปลี่ยนแปลงที่ใช้งานได้ดีพอ - การเขียนโค้ดเองทำให้สามารถ คิดภายในสภาพแวดล้อมที่รันจริง โดยไม่ต้องผ่านภาษาอังกฤษเป็นตัวกลาง จึงสัมผัสได้ถึงช่องโหว่ การทดสอบที่อ่อนแอ และข้อยกเว้นที่ไม่จำเป็น ซึ่งมักพลาดได้ง่ายหากเพียงตรวจทานโค้ดแบบตั้งรับ
- เอเจนต์คล้ายเด็กฝึกงานที่เพิ่งเข้ามามากกว่าคอมไพเลอร์ มันมักทำตามโค้ดเดิมและข้อกำหนดที่ไม่แม่นยำอย่างระมัดระวัง และอาจขยายข้อผิดพลาดครั้งเดียวของมนุษย์ให้กลายเป็น ชั้น wrapper และชั้นอ้อม เพิ่มเติม
- มนุษย์ควรทดลองแนวทางด้วยตนเอง กำหนดแพตเทิร์น แล้วให้เอเจนต์ทำซ้ำตามนั้น เพื่อใช้ประโยชน์จากผลิตภาพของระบบอัตโนมัติ ขณะยังคง ความรู้สึกเป็นเจ้าของและวิจารณญาณ ไว้
โรงงานซอฟต์แวร์ที่เอเจนต์ทำงาน
- วิศวกรซอฟต์แวร์ไม่ได้ดูแลแค่ซอฟต์แวร์ แต่ยังดูแล สายการประกอบ ที่ทำให้ใครก็สามารถขอการเปลี่ยนแปลงด้วยพรอมป์และ deploy ได้ทันที
- จัดเตรียมโครงสร้างพื้นฐานล่วงหน้าผ่านพรอมป์, skill,
AGENTS.mdและฐานความรู้ เพื่อให้เอเจนต์ทำงานสำเร็จได้ - ปกป้องผลลัพธ์ภายหลังด้วยการทดสอบ, linting, type system, การประเมิน และ การประเมินอัตโนมัติ โดยใช้ AI ตัวอื่น
- จัดเตรียมโครงสร้างพื้นฐานล่วงหน้าผ่านพรอมป์, skill,
- หากให้ข้อจำกัดที่เพียงพอและบริบทล่าสุด แม้โมเดลที่มีความฉลาดต่ำก็สามารถสร้างการเปลี่ยนแปลงที่ใช้ได้โดยไม่หลุดเส้นทาง จนอาจดูเหมือนมนุษย์ไม่จำเป็นต้องอ่านหรือเขียนโค้ดเอง
- อย่างไรก็ตาม ต่อให้มีเอเจนต์ที่ฉลาดระดับ Fable การเขียนโค้ดเองก็ยังทำให้เรา คิดโดยตรงภายในสภาพแวดล้อมที่รันจริง โดยไม่มีภาษาอังกฤษเป็นชั้นกลาง
- การอ่าน diff และ patch ที่เอเจนต์สร้างขึ้นแบบตั้งรับเพียงอย่างเดียว ทำให้เชื่อมโยงกับสถาปัตยกรรมของระบบในเชิงลึกได้ยาก
- เมื่อลงมือจัดการโค้ดเอง จะรู้สึกได้ว่าเมื่อเพิ่มฟีเจอร์ทับลงไปแล้วอะไรจะแตก
- หากจัดระเบียบโค้ดและบันทึกหลักการสถาปัตยกรรมที่สอดคล้องกันโดยไม่ต้องพ่วงข้อยกเว้นมากมาย โรงงานซอฟต์แวร์ก็จะทำงานได้เสถียรมากขึ้น
- หากพบและแก้จุดอ่อนของกลยุทธ์การทดสอบระหว่างการดีบัก ก็สามารถสกัดบั๊กชนิดใหม่ทั้งกลุ่มได้
- การเขียนโค้ดเองไม่ใช่วิธีเดียวในการเข้าใจซอฟต์แวร์ และไม่จำเป็นต้องยึดติดกับงานทำมือแบบสุดโต่งเหมือน เข็มแม่เหล็กกับมือที่ไม่สั่น
- แม้โค้ดจริงส่วนใหญ่จะถูกสร้างโดย AI การเขียนโค้ดเองก็ยังคงเป็นเครื่องมือที่มีประโยชน์
รักษาพลังคิดและความเป็นเจ้าของด้วยการเขียนโค้ดเอง
- หากหยุดอยู่แค่บทบาท เซนทอร์ย้อนกลับ ที่ทำหน้าที่อ่านและอนุมัติโค้ดเท่านั้น สมาธิและความรู้สึกเป็นเจ้าของจะลดลง โค้ดคุณภาพต่ำจะผ่านการตรวจทานได้ง่ายขึ้น และการปรับแต่งอย่างละเอียดก็ทำได้ยากขึ้น
- หากไม่ใส่ใจรายละเอียด ช่องโหว่จะสะสม และในระยะยาว โค้ดคุณภาพต่ำจะส่งผลเสียต่อเอเจนต์ด้วย
- หากมนุษย์ทดลองแนวทางด้วยตนเองก่อน แล้วให้เอเจนต์ทำซ้ำตามแพตเทิร์นที่กำหนดไว้ ก็จะยังมีส่วนร่วมและเป็นเจ้าของผลลัพธ์ต่อไปได้
- ภาษาอังกฤษเป็น ภาษาที่มีสเปกไม่เพียงพอ สำหรับแสดงการคำนวณอย่างแม่นยำ
- ในงานอัลกอริทึม จำเป็นต้องออกแบบและคิดเป็นขั้นตอนที่รันได้
- สามารถปรับระดับความแม่นยำที่ต้องการได้ โดยเลือกภาษาระดับต่ำที่มีพื้นที่ออกแบบกว้าง หรือภาษาระดับสูงที่มีสภาพแวดล้อมการคำนวณจำกัดกว่า ตามสถานการณ์
- หากปฏิบัติกับเอเจนต์เขียนโค้ดเหมือนเป็นคอมไพเลอร์ ก็อาจนำไปสู่ทัศนคติว่าโค้ดที่เขียนแย่ก็ deploy ได้
- เอเจนต์คล้าย เด็กฝึกงานที่เพิ่งเข้ามา มากกว่าคอมไพเลอร์
- มันอ่านโค้ดเดิมที่อาจไม่สมบูรณ์และมีคุณภาพต่ำ แล้วสร้างการเปลี่ยนแปลงใหม่จากคำอธิบายการเปลี่ยนแปลงที่ไม่แม่นยำ
- มนุษย์ไม่สามารถส่งต่อความคิดและรสนิยมของตนให้กลุ่มเด็กฝึกงานได้ทั้งดุ้น จึงไม่ควรเป็นเพียงผู้บริโภค แต่ต้องเข้าไปมีส่วนร่วมโดยตรง
- เอเจนต์ทำตาม กฎลูกเสือ ที่ปล่อยให้โค้ดอยู่ในสภาพดีกว่าตอนพบได้เองค่อนข้างยาก และการมอบหมายเรื่องนี้ให้เอเจนต์ก็เป็นภาระหนัก
- มันมีแนวโน้มทำให้การเปลี่ยนแปลงปัจจุบันปลอดภัยที่สุดเท่าที่ทำได้ และรักษาการตัดสินใจเดิมไว้อย่างอนุรักษนิยม
- ใน codebase หนึ่ง เมื่อมนุษย์เผลอใช้ local storage ของเบราว์เซอร์กับสถานะบางส่วน ทั้งที่สถานะที่เหลือถูกเก็บในฐานข้อมูล backend เอเจนต์กลับพยายามรักษาการตัดสินใจนั้นไว้ โดยเพิ่ม wrapper และชั้นอ้อม จนจำนวนบรรทัดโค้ดเพิ่มขึ้นประมาณ 3 เท่า
- ความอนุรักษนิยมแบบนี้อาจขยายการตัดสินใจผิดพลาดแบบครั้งเดียวของมนุษย์ให้ใหญ่ขึ้น
- กระบวนการลบและสำรวจโค้ดด้วยตนเองช่วยให้ไปถึงสถาปัตยกรรมที่ดีกว่าการสั่งเป็นภาษาอังกฤษเพียงอย่างเดียว
- ยิ่งใส่ใจโค้ดมากเท่าไร พลังคิด ความรู้สึกในฐานะผู้สร้าง และความสามารถในการนำโรงงานซอฟต์แวร์ก็ยิ่งแข็งแกร่งขึ้น
- ในโรงงานซอฟต์แวร์ รายละเอียด สำคัญ ตั้งแต่แพตเทิร์นสถาปัตยกรรมไปจนถึงอัลกอริทึมและประสิทธิภาพ
- เอเจนต์ทำให้ความจำเป็นของการประเมิน การวัดผล และกลไกป้องกันสูงขึ้น และกระตุ้นให้แม้แต่โปรเจกต์ส่วนตัวก็เพิ่ม CI ตั้งแต่ช่วงต้น ไม่ใช่ทำเป็นงานภายหลัง
- สิ่งนี้ทำให้สภาพของการพัฒนาซอฟต์แวร์ดีขึ้นอย่างมาก แต่สายการประกอบทุกแห่งก็ยังมีจุดอ่อนเหลืออยู่
- แม้แต่ในโรงงานรถยนต์ ก็มีเวลาที่ต้องถอดสายการประกอบออกมาดู เจาะลึกรายละเอียดของเครื่องยนต์สันดาปภายในเพื่อปรับปรุงให้ดีขึ้น 10% หรือเฝ้าดูการทดสอบผ้าเบรกทั้งวันเพื่อหาว่าทำไมจึงไม่พบปัญหาหน้างานตั้งแต่เนิ่น ๆ
- ในซอฟต์แวร์ก็เช่นกัน หากต้องการเชื่อมรายละเอียดเข้ากับโครงสร้างทั้งหมด ไม่ควรขีด เส้นแบ่งตามอำเภอใจ ว่าอะไรที่เราจะลงมือจัดการเองได้หรือไม่ได้
2 ความคิดเห็น
เพราะไม่มีเงินค่าทोकเคนน่ะสิ T_T
ความคิดเห็นจาก Hacker News
ดูเหมือนชัดเจนว่า ถ้าเขียนโค้ดไม่ได้ก็ตรวจทานโค้ดไม่ได้เช่นกัน แต่ก็มีทั้งคนและบริษัทที่บอกว่าให้ Claude เขียน แล้วให้ Codex ตรวจทานก็พอ ถึงอย่างนั้น เหตุผลที่ยังขอผลลัพธ์เป็นภาษาระดับสูงอย่าง Python, Java ไม่ใช่แอสเซมบลีหรือไบนารีที่คอมไพล์แล้ว สุดท้ายก็เพราะ มนุษย์ต้องอ่านโค้ดได้
มันเป็นท่าทีที่ขัดแย้งกันเอง คืออยากให้นักพัฒนาอ่านโค้ด ดีบัก และให้เหตุผลกับโค้ดได้ แต่กลับไม่อยากจัดให้มีการฝึกฝนเพื่อพัฒนาความสามารถนั้น
ยังน่าสงสัยว่าอุตสาหกรรมจะพัฒนาต่อไปได้หรือไม่ หากยกงานสร้างสรรค์ทั้งหมดให้ LLM
ไม่ได้หมายความว่าฝั่งไหนดีกว่า คนที่ให้ความสำคัญกับรายละเอียดน้อยกว่าอาจเป็นคนขับเคลื่อนโลกก็ได้ และแต่ละปัญหาอาจต้องการระดับความละเอียดไม่เท่ากัน
คอมไพเลอร์ช่วยให้ LLM เขียนโค้ดที่คอมไพล์และรันได้จริง แต่ถ้าให้ส่งออกภาษาเครื่องโดยตรง ก็มีโอกาสสูงที่จะรันไม่ได้เลย แน่นอนว่าถ้าเขียนโค้ดไม่ได้เลย การตรวจทานก็จะยากกว่ามาก
“ในอุตสาหกรรม เราเรียกข้อกำหนดโปรเจกต์ที่ครอบคลุมและแม่นยำพอจะสร้างโปรแกรมได้ว่าอะไร? เราเรียกว่า โค้ด” — CommitStrip
หากเขียนได้ถูกต้อง แก่นของโค้ดควรเป็นการแสดงตรรกะทางธุรกิจที่เป็นพื้นฐานให้ง่ายที่สุด อาจไม่จำเป็นต้องตรวจทานเลเยอร์สนับสนุนทั้งหมด แต่ถ้าไม่ได้อ่านโค้ด ก็ยากจะบอกว่าเข้าใจตรรกะทางธุรกิจอย่างครบถ้วน
https://softwaredoug.com/blog/2026/07/04/write-code-not-specs
คำถามสำคัญคือ ใครจะยอมจ่ายเงินให้การเขียนโค้ดด้วยมือ ลูกค้าไม่ได้จ่ายเพื่อตัวการเขียนหรือสร้างโค้ดเอง แต่จ่ายเพื่อ การแก้ปัญหา ดังนั้นฝ่ายที่แก้ได้ด้วยต้นทุนและความวุ่นวายน้อยที่สุดก็จะได้ธุรกิจไป และประโยชน์ของเครื่องมือ AI ที่ช่วยบีบตารางเวลาให้สั้นลงก็เป็นสิ่งที่มองข้ามได้ยาก
ผมอยู่ในอุตสาหกรรมนี้มาตั้งแต่ทศวรรษ 1990 งานที่นักพัฒนาที่ไม่ได้เก่งกาจสร้างผลลัพธ์ธรรมดา ๆ นั้นมีอยู่มากเสมอ เรามักโรแมนติไซซ์โค้ดที่เขียนด้วยมือมากเกินไป แต่โค้ดเบสจริงมักดูแลรักษายากขึ้นตามเวลาและเต็มไปด้วยบั๊กได้ง่าย และโปรเจกต์ที่ทำออกมาลวก ๆ ก็ไม่ใช่ปรากฏการณ์ใหม่แต่อย่างใด
ตอนนี้เหมือนกำลังพยายามสร้างโรงงานซอฟต์แวร์ทั้งที่สองมือถูกมัดไว้
หากต้องการมีสมาธิและเข้าใจจริง ๆ ไม่ควรแค่นั่งดูเอเจนต์จากไกล ๆ แล้วอ่านโค้ดแบบเฉื่อย ๆ แต่ต้องสัมผัสโค้ดด้วยตัวเอง สุดท้ายหมายความว่า ต้องฝึกโมเดลทางความคิดของตนเอง
เวลาเขียนโค้ด จิตใต้สำนึกจะตัดสินหลายอย่างเช่น “แบบนี้รู้สึกว่าใช่” ซึ่งพัฒนาได้จากการทำซ้ำและการจดจ่ออย่างลึกซึ้งเท่านั้น การตรวจทานโค้ดหรืออ่านเอกสารเพียงอย่างเดียวมีข้อจำกัด หากมีโมเดลทางความคิดที่ก่อตัวแบบนี้ แค่เห็นข้อความผิดพลาดจากปัญหาในระบบปฏิบัติการจริงก็ชี้สาเหตุได้ทันที แต่กับโค้ดที่ถูกสร้างขึ้นมา ต้องใช้การคิดอย่างมีสติที่ช้ากว่าและค้นหาอยู่นาน
ถ้าจะให้ LLM มีประโยชน์จริง ๆ เราต้องสามารถสมมติได้ว่ามันรับผิดชอบการบำรุงรักษาโค้ดทั้งหมดและทำงานเหมือนไลบรารีภายนอก ไม่เช่นนั้นปัญหาก็จะเกิดขึ้นต่อไปอย่างหลีกเลี่ยงไม่ได้
ยังไม่รู้ว่าฝั่งไหนถูก และกำลังศึกษาต่ออยู่
แม้ในปี 2026 โค้ดที่ AI สร้างก็ยังแย่มาก ไม่ว่าจะเป็น Fable หรือฮาร์เนส LeetCode แบบ Pi/opencode ที่ปรับแต่งเอง ผลลัพธ์ก็เลวร้าย และถ้าแยกคุณภาพระหว่างโค้ดของตัวเองกับโค้ดของ AI ไม่ออก ก็มีข่าวร้ายจะบอก
ได้ระบุไว้ใน กฎ แล้วว่าให้เอเจนต์ทำตามกฎลูกเสือ เช่น รันโปรไฟล์ ตรวจสอบ code coverage ทบทวนเชิงวิพากษ์ และเขียนรายงานกับงานติดตามผล LLM ระดับแนวหน้าในปัจจุบันทำตามกฎแบบนี้ได้ดีกว่า 90% ของคนที่เคยร่วมงานด้วย จึงสงสัยว่านี่หมายความว่ามันแย่หรือไม่
เอเจนต์ค่อนข้างอนุรักษนิยม จึงอาจขยายความผิดพลาดเฉพาะครั้งของมนุษย์ให้ใหญ่ขึ้นได้ มีหลายวิธีในการแก้เรื่องนี้ และแต่ละคนก็มีวิธีคิดต่างกัน ดังนั้นทั้งแนวทางที่ไม่อ่านโค้ด และแนวทางที่อ่านและเขียนเองโดยตรงต่างก็เป็นไปได้ แต่ข้อดีจากความแม่นยำของโค้ดที่ไม่ผ่าน LLM ก็มีมากเช่นกัน
เหตุผลที่ผมต้องเขียนโค้ดเองคือ ไม่อย่างนั้น LLM จะสร้างโค้ดมากเกินไป ต้องเข้าใจปัญหาอย่างถ่องแท้และทำให้เป็น generalization ให้ได้ จึงจะป้องกันไม่ให้ “Hello World” กลายเป็น โค้ด 10,000 บรรทัดพร้อม abstraction 5 ชั้น
เพราะ LLM เป็นตัวทำนาย token ยิ่งมีปัญหาที่ต้องแก้มากเท่าไร ก็มีแนวโน้มจะส่งออก token ของโค้ดมากขึ้นเท่านั้น
ผู้ที่มีปัญหาที่ต้องแก้คือมนุษย์ ดังนั้นหากไม่เข้าใจปัญหา ก็อาจเกิดปัญหาแบบ X/Y ที่ LLM ไปแก้ปัญหาที่ไม่เกี่ยวกับความต้องการจริง LLM ช่วย abstraction สิ่งที่ไม่ใช่แก่นได้ดีกว่า เช่น ไลบรารีหรือภาษาระดับสูง แต่แก่นของปัญหายังคงต้องถูกแสดงออกในรูปแบบที่เป็นทางการ
แม้แต่ vibe coding ที่ค่อย ๆ เพิ่มข้อจำกัดทีละข้อจนได้ผลลัพธ์ที่ต้องการ สุดท้ายก็ยังเป็นการเขียนโปรแกรมแบบหลวม ๆ และไม่เป็นทางการอยู่ดี ควรมอบส่วนรอบนอกของปัญหาให้ LLM แล้วเขียนและทำความเข้าใจแก่นเองจะดีกว่า
มองจากภายนอกเหมือนมันแก้คำขอได้อย่างสมบูรณ์ แต่เป็นโค้ดที่ไม่จำเป็นและลวก บริษัทที่ขาย token แบบคิดตามการใช้งานมีแรงจูงใจทางเศรษฐกิจที่จะสร้างวิธีแก้แบบ Rube Goldberg ที่แก้ปัญหาแบบคร่าว ๆ พร้อมกับใช้ token ให้มากที่สุด ไม่ใช่แค่ตอนสร้าง แต่ตอนหลังที่ต้องจัดการโค้ดกองใหญ่ที่มีบั๊กใหม่ปะปนอยู่ก็ยังใช้ token เพิ่มอีก
น่าขำที่คนที่เคยหัวเราะเยาะโค้ด copy-paste ตอนนี้กลับตื่นเต้นกับโค้ดที่เอามาปะติดปะต่ออย่างลวก ๆ
เมื่อดูความก้าวหน้าตั้งแต่ ChatGPT 3.5 ในเดือนพฤศจิกายน 2022 จนถึงตอนนี้ ก็สงสัยว่า อีก 4 ปีข้างหน้าเราจะยังรีวิวโค้ดกันอยู่ไหม แม้ไม่ใช่พวก AI สุดโต่ง แต่ถ้าความเร็วปัจจุบันยังคงอยู่ อีก 5–10 ปีข้างหน้า วิศวกรรมซอฟต์แวร์และการพัฒนาในรูปแบบปัจจุบันอาจหายไปเป็นส่วนใหญ่
มนุษย์อาจเหลือแค่การออกแบบ UI ส่วนที่เหลือทั้งหมดถูก abstract ออกไป แล้ว AI จัดการงานจริง
เว็บก็เละเทะพออยู่แล้ว อย่างน้อยในสถานการณ์ตอนนี้ก็ขอให้ยังโทษมนุษย์ไร้ความสามารถได้เถอะ
ไม่เกี่ยวกับแรงกดดันจาก KPI ผมยังเขียนโค้ดเองทุกครั้งที่มีโอกาส และคาดหวังจาก AI แค่ระดับ code autocomplete ที่ฉลาดขึ้น เท่านั้น
ผมเขียนโค้ดเองเพราะรักการโค้ด และมันทำให้มีความสุขอย่างแท้จริง ไม่มี เหตุผลที่จะเลิกทำสิ่งที่ชอบ