เอเจนต์เขียนโค้ดเข้ามาแทนที่ทุกเฟรมเวิร์กที่ผมเคยใช้
(blog.alaindichiappari.dev)> "วิศวกรรมซอฟต์แวร์กลับมาแล้ว"
- เมื่อยุคของ การเขียนโปรแกรมอัตโนมัติ เปิดฉากขึ้นจากความก้าวหน้าของโมเดล AI ระดับแนวหน้าและเอเจนต์เขียนโค้ด งานพิมพ์โค้ดด้วยมือลงไปทีละบรรทัดก็หายไป ทำให้วิศวกรซอฟต์แวร์กลับมาโฟกัสกับการออกแบบและการคิดเชิงแก่นแท้ได้อีกครั้ง
- ตั้งแต่ปลายปีที่แล้ว ความสุกงอมของเครื่องมือและโมเดลพัฒนาขึ้นอย่างมาก จนในสภาพแวดล้อมที่จัดวางไว้อย่างดี เราสามารถ ทุ่มเทให้บทบาทสถาปนิก พร้อมทั้งเข้าไปแก้ไขเองได้เมื่อจำเป็น
- ในการพัฒนาเว็บ โมบายล์ และเดสก์ท็อป มีการสะสมของ เฟรมเวิร์กและชั้น abstraction ที่ไม่จำเป็น มายาวนาน ซึ่งไม่ได้แก้ความซับซ้อนที่แท้จริง แถมยังเพิ่มปัญหาเข้าไปอีก
- ในสามปัญหาที่เฟรมเวิร์กอ้างว่าช่วยแก้—ความเรียบง่าย การทำงานอัตโนมัติ และการลดต้นทุนแรงงาน—มีเพียงการทำงานอัตโนมัติเท่านั้นที่เคยมีคุณค่าจริง แต่ตอนนี้ AI automation สามารถเข้ามาแทนที่สิ่งนี้ได้เช่นกัน
- อย่าปล่อยให้ตัวเองกลายเป็นเพียง ผู้ปฏิบัติการ (operator) ของระบบที่ออกแบบโดย hyper-scaler อย่าง Google, Meta, Vercel แต่จงกลับไปสู่วิศวกรรมที่แท้จริง ด้วยการสร้างแบบออกแบบและผลิตภัณฑ์ของตัวเองโดยตรง
การผงาดขึ้นของการเขียนโปรแกรมอัตโนมัติ
- กรอบความคิด "automated programming" ที่ Antirez ตั้งชื่อไว้ จับแก่นของเรื่องนี้ได้ดีกว่า "vibe coding" มาก
- เช่นเดียวกับแท่นพิมพ์ เครื่องทอผ้า และสายการประกอบ ระบบอัตโนมัติคือหัวใจของนวัตกรรมทางประวัติศาสตร์ และความเปลี่ยนแปลงครั้งนี้ก็อยู่บนเส้นทางเดียวกัน
- หลังเดือนธันวาคม 2025 เป็นต้นมา ความสามารถของ frontier model และ coding agent เปลี่ยนไปอย่างมาก จนสำหรับคนที่เฝ้าดูอย่างใกล้ชิด มันชัดเจนอยู่แล้ว
บทบาทของวิศวกรที่เปลี่ยนไป
- งานที่ต้องใช้ การคิดอย่างลึกซึ้ง เช่น สถาปัตยกรรม trade-off การตัดสินใจด้านผลิตภัณฑ์ และ edge case ยังคงอยู่เหมือนเดิม
- สิ่งที่หายไปคือ งานใช้แรงและน่าเหนื่อยล้า จากการต้องพิมพ์โค้ดทุกบรรทัดด้วยตัวเอง
- หากใช้โมเดลและเครื่องมือในสภาพแวดล้อมที่จัดไว้อย่างสะอาดและรัดกุม ก็สามารถ ทำหน้าที่แบบสถาปนิก ได้โดยไม่ต้องลงมือก่ออิฐทุกก้อนเอง
- สิ่งนี้ต้องมีพื้นฐานจากประสบการณ์เขียนโค้ดด้วยตนเองตลอด 20 ปี และถ้าไม่พอใจก็ยังสามารถลงไปดู ทำความเข้าใจ แก้ไขเอง แล้วอัปเดตการตั้งค่าได้
- เราสามารถสร้างเครื่องมือที่ต้องใช้ขึ้นมาได้ทันที ทำให้มี เวลามากขึ้นในการทำให้เทคโนโลยีที่คิดไว้เกิดขึ้นจริง
เฟรมเวิร์กกับความซับซ้อนที่ไม่จำเป็น
- ตลอดหลายปีที่ผ่านมา ในการพัฒนาเว็บ โมบายล์ และเดสก์ท็อป ได้เกิด มลพิษขนาดใหญ่จากเฟรมเวิร์ก ไลบรารี และทูลลิง สะสมขึ้นเรื่อย ๆ
- ชั้น abstraction ที่ไม่ได้ abstract สิ่งที่มีความหมายจริงถูกซ้อนทับกันหลายชั้น อ้างว่าแก้ปัญหาหนึ่งอย่าง แต่กลับ สร้างปัญหาใหม่เพิ่มอีกสิบอย่าง
- ทั้งอุตสาหกรรมเลือกวิธี ซื้อรูปแบบการคิดสำเร็จรูป แทนที่จะลับคมความคิดเพื่อต่อกรกับความซับซ้อนที่แท้จริงของการสร้างซอฟต์แวร์
- มันเหมือนกับ เอาผ้าไหมมาพันขาที่หัก ภายนอกอาจดูดีขึ้น แต่ ขายังคงหักอยู่เหมือนเดิม
สามปัญหาที่เฟรมเวิร์กอ้างว่าช่วยแก้
- "ความเรียบง่าย (Simplification)": ปรากฏการณ์ที่วิศวกรกลัวการออกแบบด้วยตัวเอง จึงยอมรับโครงสร้างของคนอื่นแบบไม่ตั้งคำถาม
- แทนที่จะออกแบบย้อนกลับจากเป้าหมาย กลับนำ การออกแบบแบบ one-size-fits-all ไปใช้กับทุกที่
- สิ่งนี้ไม่ใช่การทำให้ง่ายขึ้น แต่คือ การยอมแพ้ทางปัญญา (intellectual surrender)
- การทำงานอัตโนมัติ (Automation): คุณค่าเดียวที่พอฟังขึ้นได้ คือการกำจัดโค้ด boilerplate
- เช่น การทำงานอัตโนมัติของ ORM, การจัดการ CRUD, การสร้างโค้ด, การทำเอกสาร API และ งานซ้ำ ๆ แต่จำเป็น อื่น ๆ
- แต่ตรงจุดนี้เองที่ AI กำลังเปลี่ยนทุกอย่าง
- การลดต้นทุนแรงงาน (Labour cost): เหตุผลเงียบ ๆ ที่ไม่เคยอยู่บนสไลด์งานคอนเฟอเรนซ์
- หากปล่อยให้ Google, Meta, Vercel เป็นผู้กำหนดวิธีสร้างผลิตภัณฑ์และดีพลอยโค้ด คุณก็สามารถ จ้าง "React developer" แทน software engineer ได้
- ไม่ต้องฝึกเพิ่ม เสียบแล้วใช้ได้เลย และเปลี่ยนออกได้ง่าย เหมือน แรงงานที่เป็นฟันเฟือง (cog)
- นี่ไม่ใช่วิศวกรรม แต่คือ การปฏิบัติการ (operating)
ความจริงของวิธีการทำงานแบบใหม่
- ใช้วิธีนี้พัฒนามานานกว่า 2 ปีโดยแทบไม่มีปัญหา และการปฏิวัติที่แท้จริงเกิดขึ้นตั้งแต่เดือนธันวาคมปีที่แล้ว
- นี่เปิดโอกาสให้เราตัดความซับซ้อนที่ไม่จำเป็นออก แล้วไปโฟกัสกับ ความซับซ้อนที่มีศูนย์กลางอยู่ที่ตัวไอเดีย
- ต้นทุนในการกำจัด boilerplate ลดลงจนเกือบเป็นศูนย์ จึงไม่จำเป็นต้องเขียนโค้ดเดิมซ้ำสองครั้ง
- สามารถสร้าง เครื่องมือขนาดเล็กที่ออกแบบเฉพาะเพื่อจุดประสงค์ และตรงกับปัญหาได้ทันที
- โดยไม่ต้องมี monorepo manager หรูหรา Makefile แบบเรียบง่าย ก็รองรับได้ถึง 99% ของ use case
- ถ้าปัญหาซับซ้อนมากจริงค่อยคิดตอนนั้น แต่ก่อนถึงจุดนั้น อย่าเพิ่งแก้ปัญหาล่วงหน้าเด็ดขาด นั่นแหละคือวิศวกรรม
- เราต้องแก้ ปัญหาที่มีอยู่ตอนนี้ ไม่ใช่ปัญหาที่ใครบางคนบนเวทีคอนเฟอเรนซ์บอกว่าอาจเกิดขึ้นสักวัน
การค้นพบ Bash และเครื่องมือพื้นฐานอีกครั้ง
- เอเจนต์มีความสามารถสูงมากกับ เครื่องมือพื้นฐาน (basic tools) ที่มีอยู่มานานหลายทศวรรษ
- Bash เกิดขึ้นในปี 1989 และตอนนี้แม้แต่โมเดลธรรมดาที่สุดก็รู้จัก Bash ดีกว่าคนคนไหนในโลก
- กำลังเกิดแนวโน้มที่ coding agent เปลี่ยนจากการตั้งค่า MCP ที่ซับซ้อนและมีต้นทุนสูง ไปเป็น agent loop แบบเรียบง่ายที่ใช้ Bash เป็นฐาน
- เครื่องมือที่เก่าแก่ที่สุดกลับเป็น เครื่องมือที่พร้อมรับอนาคตมากที่สุด (most future proof)
ต้นทุนของการพึ่งพาเฟรมเวิร์ก
- ใน use case ส่วนใหญ่ ไม่จำเป็นต้องใช้เฟรมเวิร์กราคาแพง มีข้อบกพร่อง และไลบรารีประกอบ ที่สุดท้ายใช้จริงเพียง 10% ของความสามารถ
- ต้นทุนแฝงอย่างการบำรุงรักษา การอัปเดตความปลอดภัย และข้อจำกัดด้านการออกแบบนั้นสูงมาก และสิ่งเหล่านี้จำกัดอิสรภาพของนักพัฒนา
- หากยังยอมรับ trade-off นี้ต่อไป ก็เท่ากับพลาดโอกาสครั้งใหญ่ที่สุดในรอบหลายทศวรรษ
- จงระวังโครงสร้างที่ ต้องขึ้นต่อปรัชญาการออกแบบของบริษัทใหญ่ อย่าง Google, Meta, Vercel
- นักพัฒนาควรเชื่อมั่นในความคิดและสุนทรียะของตัวเอง และ สร้างเครื่องมือกับผลิตภัณฑ์ของตนเอง
> “อย่าเอาผ้าไหมมาพันขาที่หัก แต่จง สร้างสิ่งที่เป็นของตัวเองจริง ๆ”
- นักพัฒนาควรเชื่อมั่นในความคิดและสุนทรียะของตัวเอง และ สร้างเครื่องมือกับผลิตภัณฑ์ของตนเอง
5 ความคิดเห็น
นี่แหละคือวิธีพัฒนาซอฟต์แวร์แบบทำให้บำรุงรักษายากอย่างแท้จริง เป็นคนที่กำลังลงมือทำตามแนวทางรักษาตำแหน่งงานของตัวเองไปตลอดชีวิตในยุคใหม่ให้เข้ากับยุค AI
ผมไม่ค่อยเห็นด้วยกับคำพูดที่ว่า “เฟรมเวิร์กราคาแพงและมีข้อบกพร่อง พร้อมไลบรารีประกอบ ที่ในกรณีใช้งานส่วนใหญ่เราใช้แค่ 10% ของความสามารถ” เท่าไรนะครับ.. การเลือกสภาพแวดล้อมที่มีขนาดเหมาะกับโปรเจกต์ไม่ใช่สิ่งที่ควรทำอยู่แล้วหรือครับ ถ้าคิดว่าจะไม่ได้ทำฟีเจอร์อะไรมาก ก็ใช้ตัวเบา ๆ อย่าง express ก็ได้อยู่แล้วนี่ครับ จะต้องสร้างของที่จะมาแทน express ขึ้นมาตั้งแต่แรกจริง ๆ เหรอ..
ถ้าจะบอกว่ามีฟีเจอร์เยอะแต่ใช้นิดเดียว จริง ๆ แล้วเว็บเซิร์ฟเวอร์อย่าง Apache หรือ nginx น่าจะเข้าข่ายมากกว่าด้วยซ้ำ แต่เพราะมันหนักแล้วถึงกับต้องสร้างเว็บเซิร์ฟเวอร์ใหม่ขึ้นมาตั้งแต่ต้นเลยหรือ ก็แค่ตั้งค่าแล้วใช้งานก็พอไม่ใช่หรือ
มีเฟรมเวิร์กที่จัดระเบียบมาดีและมีข้อมูลที่ AI เรียนรู้ไว้มากอยู่แล้ว แบบนี้จำเป็นต้องสร้างของใหม่ในแบบของตัวเองขึ้นมาจริง ๆ เหรอ กลับรู้สึกว่าเป็นเรื่องที่ทำให้ประสิทธิภาพการทำงานลดลงมากกว่า
ผมคิดว่าไม่มีความจำเป็นต้องทิ้งสิ่งที่ช่วยลดต้นทุนในการออกแบบสถาปัตยกรรม และทำให้เราโฟกัสกับแก่นแท้ของงาน (บริการ) ได้
อืม... แนวปฏิบัติแบบนี้น่าจะเป็นตอนที่ Cursor ให้ใช้งานได้ไม่จำกัดมากกว่านะ... กลับกัน อย่างน้อยในช่วงนี้ ทิศทางต่อจากนี้น่าจะเป็นว่าเราจะประหยัดโทเคนและช่วยเสริม AI ให้ดีได้อย่างไร?
ทั้งที่สามารถลดความซ้ำซ้อนได้โดยไม่ต้องจ่ายค่าโทเคนแพง ๆ แล้วทำไมถึงจะไม่มีเหตุผลให้ใช้เฟรมเวิร์กล่ะ?
ความคิดเห็นจาก Hacker News
ดูเหมือนว่าในอนาคตอันใกล้ นักพัฒนาและบริษัทจำนวนมากจะเจอกับแรงกระแทกครั้งใหญ่จาก กระแส AI แบบสร้างภาพลักษณ์
ตอนนี้อาจสร้างอะไรบางอย่างด้วย AI ได้ แต่ปัญหาที่แท้จริงคือมีหลายเรื่องที่ไม่รู้จนกว่าจะลงไปชนด้วยตัวเอง
สุดท้ายคนที่ทำแค่ ‘vibe code’ ก็จะชนเข้ากับข้อจำกัดในโลกจริง และจะเหลือรอดเฉพาะคนที่เข้าใจว่าระบบทำงานจริงอย่างไร
พวกมันแก้บั๊กและ merge ได้ภายใน 2 นาที และการ “เข้าใจระบบ” กับ “ไม่ต้องเขียนโค้ดด้วยตัวเอง” ก็สามารถอยู่ร่วมกันได้
AWS กำลังเดิมพันครั้งใหญ่มากกับทิศทางนี้ และเมื่อ เครื่องมือแบบไม่กำหนดผลลัพธ์แน่นอน เสถียรขึ้นเรื่อย ๆ ก็มีโอกาสสูงที่จะไปไกลเกินคุณภาพระดับมนุษย์
ถ้ามอบงานไปโดยไม่เข้าใจ ก็รับประกันไม่ได้ทั้งความถูกต้อง ความดูแลรักษาง่าย และความขยายระบบได้
แต่ถ้าต้องทำงานกับคนแบบนั้น ก็อดสงสัยไม่ได้ว่าทำไมต้องจ่ายเงินเป็นแสนดอลลาร์ให้พวกเขา แถมยังต้องออกค่า LLM subscription อีก
แน่นอนว่าจะมีกรณีที่แอปที่สร้างด้วย ‘vibe coding’ พัง แต่ทีมที่ทำควบคู่กับการทดสอบ การจัดการเวอร์ชัน และการทำเอกสาร จะยิ่งรุ่งเรืองมากกว่าเดิม
สุดท้ายแล้วแนวทางที่สมดุลสำคัญที่สุด
สักวันอาจมี ‘de-slopper bot’ โผล่มาก็ได้
เหตุผลที่ใช้เฟรมเวิร์กก็เพราะคนออกแบบมันเคยเจอ ปัญหาและสเกลที่หนักกว่าที่ผมเจอ
ช่วงต้นโปรเจกต์มันอาจดูง่าย แต่พอขยายใหญ่ขึ้น การออกแบบใหม่จะเจ็บปวดมาก
อ่านบทความแนวนี้ไปบ่อย ๆ จะรู้สึกเหมือนตัวบทความเองก็เขียนโดย LLM
อุปมาแบบ ‘ตัดและเย็บก้อนอิฐ’ ยิ่งสะท้อนความขัดแย้งนั้นชัดขึ้น
การทำทุกอย่างในสแตกขึ้นมาเองยังคงไม่มีประสิทธิภาพ และมีต้นทุนการดูแลรักษาสูง
แต่สิ่งที่ต่างออกไปตอนนี้คือ เราสามารถสร้าง คอมโพเนนต์ที่ปรับให้เหมาะกับปัญหา ได้ง่ายขึ้น
ไม่จำเป็นต้องไปเรียนรู้อะไรใหม่ ใช้เฟรมเวิร์กที่คุ้นเคยก็พอ
ปัญหาของผม ปัญหาของแพลตฟอร์ม และปัญหาจากการต้องหาทางอ้อมเฟรมเวิร์ก
บทความที่พูดถึงความเจ็บปวดของการเขียนโค้ดฟังดูแปลก ๆ เพราะจริง ๆ แล้วการโค้ดเป็นส่วนที่ง่ายกว่า
ถ้า Tolkien ใช้ AI เขาคงเสียเวลาไปกับการขัดเกลาพรอมป์ต์
โดยเฉพาะส่วนที่ยาก ยิ่งให้ AI ช่วยกลับยิ่งเป็นโทษ
ถ้าเป็นคนกลุ่มเดียวกันก็ดูขัดแย้งดี
เดี๋ยวนี้ถ้าโยนให้ Claude Code ทำ ส่วนใหญ่ก็แก้ได้ภายในไม่กี่นาที
แต่ผมเชื่อโค้ดที่ตัวเองเขียนมากกว่า สุดท้ายแล้วสิ่งสำคัญไม่ใช่ความเร็ว แต่คือ ความลึกของความเข้าใจ
ถ้าใช้เครื่องมือใหม่เก่งแบบ Warhol นั่นก็นับเป็นศิลปะ
LLM เป็นแค่เครื่องมือที่ช่วยในช่วงต้นของการสร้างสรรค์เท่านั้น ส่วน ความเป็นอัจฉริยะยังมาจากมนุษย์ เหมือนเดิม
การมองว่า Node.js security patch เป็นเรื่องน่ารำคาญนั้นเป็นความเข้าใจผิด
นั่นคือ อภิสิทธิ์ ต่างหาก โซลูชันที่ทำเองไม่มีทั้งชุมชนด้านความปลอดภัยและมีช่องโหว่มากกว่า
หา React developer ได้ง่าย แต่ไม่มีใครหา developer สำหรับ “เฟรมเวิร์กเฉพาะที่ AI สร้างขึ้น” ได้
ไม่ได้เป็นเรื่องยิ่งใหญ่อะไร
มี จุดกึ่งกลางระหว่าง coding agent กับ framework อยู่
ผมยังใช้เครื่องมือชุดเดิม แต่ให้อีกฝั่งทำงานซ้ำ ๆ แทน
ส่วนผมโฟกัสกับสถาปัตยกรรมและ edge case
การเมิน agent ไปเลย หรือการเชื่อมันแบบสุดโต่ง ล้วนเป็นสุดขั้วทั้งคู่
ทักษะที่แท้จริงคือ การรู้ว่าเมื่อไรควรจับพวงมาลัยเอง
ปัญหาของบทความนี้คือมันมองเฟรมเวิร์กกับ ‘วิศวกรรมจริง’ แบบ เป็นคู่ตรงข้ามกัน
แพลตฟอร์มอย่าง Vercel, Next.js, Firebase ทำให้ deploy ได้ทันทีและทำ CI/CD ได้
เมื่อนึกถึงยุคก่อนที่ต้องตั้ง Jenkins เอง มันแทบเป็นการปฏิวัติ
วิศวกรรมจริงไม่ใช่การ ‘ประดิษฐ์ใหม่อีกรอบ’ แต่คือ การส่งมอบให้ลูกค้าได้อย่างรวดเร็ว
การที่ AI ไป นำเฟรมเวิร์กเดิมมาสร้างใหม่โดยไม่ผ่านการพิสูจน์ในสนามจริง เป็นเรื่องไม่มีประสิทธิภาพ
ถ้าไม่มี ecosystem และรูปแบบร่วมกัน การทำงานร่วมกันก็ยาก
นักพัฒนาที่ประสบการณ์น้อยใช้ AI ผิดทาง ก็ไม่ได้ต่างจากอดีตเลย
ถ้าทำเอง คุณจะเสียทั้งเอกสาร middleware และการดูแลรักษา
อยู่ในระดับที่เพิ่งตระหนักว่า “อ้อ API เอามาต่อกันได้”
แต่การค้นพบแบบนี้ไม่ได้มาพร้อมกับ ความเข้าใจเรื่อง trade-off
ช่วง 6 เดือนที่ผ่านมา ผมทำ embedded development ด้วย Cursor + Opus 4.x
LLM ช่วยได้ไม่ใช่แค่ซอฟต์แวร์ แต่รวมถึง การออกแบบวงจร, CAD, CNC ด้วย
ตัวอย่างเช่น ผมทำ wrapper function สำหรับจอที่ใช้ ST7789 ได้เสร็จภายในสามพรอมป์ต์
ตอนนี้แทบไม่ใช้ไลบรารีแล้ว ยกเว้น LVGL, TinyUSB, การบีบอัด และการเข้ารหัส
ฟังก์ชันเฉพาะงาน ที่ LLM สร้างให้มีขนาดเล็ก เร็ว และไม่มี abstraction ที่ไม่จำเป็น
ผมคิดว่าไลบรารีจำนวนมากถึงเวลา ต้องหลีกทาง แล้ว
ของอย่าง .NET แทนไม่ได้ แต่ชุดฟังก์ชันทั่วไปนั้นแทนได้สบาย
มันก็ให้โค้ดที่เสร็จสมบูรณ์มาทันที รวมถึง double frame buffer ด้วย
ส่วนที่หนักของการเขียนโค้ดไม่ใช่การพิมพ์ แต่คือ การทำงานร่วมกับคน การทดสอบ และการคิดเชิงออกแบบ
สิ่งที่ยากที่สุดเมื่อไม่นานมานี้สำหรับผมคือการออกแบบ lock-free data structure
ยิ่งเป็นยุค LLM คุณค่าของเฟรมเวิร์กก็ยิ่งมากขึ้น
ด้วยข้อมูลฝึกฝน LLM จึงเก่งกับแพตเทิร์นคุ้นเคยอย่าง React
และการที่มนุษย์ยังเข้าไป debug ต่อได้ก็สำคัญมาก
ต่อให้ AGI มาจริง ก็ไม่มีเหตุผลที่จะไม่ เรียนรู้เฟรมเวิร์กที่มีประสิทธิภาพ ใหม่อีกครั้ง
บทสนทนาแบบนี้เองก็นับเป็นการทดลองที่น่าสนใจ