ฉันรู้ได้ทันทีว่าเมื่อคุณกำลังทำ 'vibe coding'

 (alexkondov.com)
7 คะแนน โดย GN⁺ 2025-08-01 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • เราเริ่มรู้ได้ง่ายขึ้นว่ามี โค้ดที่สร้างโดย LLM ในทีม
  • โค้ดประเภทนี้อาจดูชัดเจนและมีการทดสอบที่ดี แต่ไม่ยึดตาม ขนบการเขียนของโปรเจกต์
  • มักจะเมินเฉยต่อ รูปแบบหรือตัวช่วยเดิม ๆ และเขียนการใช้งานใหม่ด้วยตนเอง
  • ความกังวลเพิ่มขึ้นว่าการพัฒนาซอฟต์แวร์กำลังมุ่งเน้น เพียงความเร็ว
  • สุดท้ายสิ่งที่สำคัญที่สุดคือ คุณภาพและความสอดคล้อง และความสามารถในการดูแลรักษา

ร่องรอยของ "vibe coding"

  • ในทีมมีโค้ดบางส่วนที่เพิ่งเขียนขึ้นดู ชัดเจนและทำงานได้ครบถ้วน แต่สามารถรู้ได้ทันทีว่าเป็นโค้ดที่สร้างโดย LLM เพราะไม่ยึดตาม ขนบการเขียนเฉพาะของโปรเจกต์
  • ตัวอย่างเช่น แม้โปรเจกต์จะมี ไลบรารีสำหรับดึงข้อมูล อยู่แล้ว ก็ยังเขียนการนำไปใช้เองแบบสมบูรณ์สำหรับ การทำคำขอ HTTP ที่รองรับ กรณีข้อยกเว้นทุกแบบ
  • ฟังก์ชัน ยูทิลิตี้ ของโมดูลเดิมถูกสร้างขึ้นใหม่ซ้ำ ๆ และแม้มี กลไกการเปลี่ยนค่าการตั้งคือตามระดับโมดูล ก็ยังเปลี่ยนการตั้งค่าทั่วไป
  • แม้ในวัฒนธรรมทีมจะวางแนวทางการเขียนแบบ ฟังก์ชันนัล แล้ว ก็มีการเขียนโค้ดแบบ เชิงคลาส ใหม่อีกครั้ง
  • โค้ดเหล่านี้เป็นสไตล์ที่คนเขียนเมื่อหลายปีก่อน ย่อมไม่เคยเขียน

ความสำคัญของการบำรุงรักษาและหลักการซอฟต์แวร์

  • ในการพัฒนาซอฟต์แวร์ เราได้ทุ่มเทเวลาสร้าง รูปแบบและมาตรฐาน ที่ดูแลรักษาได้อย่างยั่งยืน
  • โค้ดที่ทำงานได้จริง ๆ ใครก็ทำได้ แต่ความท้าทายที่แท้จริงคือการเขียนโค้ดที่ แก้ไขและบำรุงรักษาได้ง่าย เมื่อเวลาผ่านไป
  • ประเด็นสำคัญไม่ใช่แค่การทำงานของฟังก์ชัน แต่คือโค้ดเบสที่สามารถดูแลได้เมื่อเวลาผ่านไป
  • “vibe coding” อาจทำลาย ปรัชญาและเกณฑ์มาตรฐาน เหล่านี้ได้

เราควรให้ความเร็วเป็นเส้นตรงสูงสุดหรือไม่?

  • เปรียบเสมือนบาริสต้าคนใหม่ในร้านกาแฟที่รีบจัดกาแฟจนอาจทำให้กาแฟหก เปรียบเทียบเพื่อเน้นว่าการยึดติดกับ ความเร็ว ไม่ได้นำไปสู่ผลลัพธ์ที่ถูกต้องเสมอไป
  • ทีมพัฒนายุคใหม่ก็เช่นกัน บ่อยครั้งเร่งสร้างซอฟต์แวร์ใหม่อย่างเร่งรีบจนเกิดการ ลดคุณภาพ
  • คนทั่วไปอยากได้ ผลลัพธ์ที่ถูกต้อง แม้ต้องรอให้นานขึ้นเล็กน้อย
  • ก่อนหน้านี้คิดว่าความเร็วเป็นปัญหาของคนในสายอาชีพที่ไม่ใช่การพัฒนา แต่ตอนนี้รู้สึกผิดหวังกับความเป็นจริงที่เพื่อนนักพัฒนาหลายคนก็กำลังละทิ้งหลักการและมุ่งแต่ความเร็ว

สิ่งที่เราต้องการจริง ๆ

  • ไม่ว่าใส่โค้ดลงใน IDE แบบไหนก็ไม่สำคัญ
  • สิ่งที่สำคัญคือ ทัศนคติของนักพัฒนาที่ใส่ใจคุณภาพ
  • ยอมรับว่า LLM เป็นนวัตกรรมด้านเทคโนโลยีที่ยอดเยี่ยม แต่ย้ำเสมอว่าความรับผิดชานในการสร้างซอฟต์แวร์จริงยังคงเป็นหน้าที่ของนักพัฒนา
  • แนะนำให้ใช้ หลักการที่มีอยู่แล้ว เช่น “การเขียนพรอมต์ให้ดีขึ้น”, “ระบุไลบรารีที่ถูกต้อง”, “ให้ตัวอย่างประกอบ”, “ทำงานทีละไฟล์เล็ก ๆ”
  • ทักท้วงว่าอย่า คุณภาพโค้ดและการบำรุงรักษา ให้เป็นภาระของ “น้ำหนัก” ของโมเดลเพียงอย่างเดียว

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
GN⁺ 2025-08-01
ความเห็นจาก Hacker News

  • อยากทำงานกับทีมที่ไม่มีใครไปเขียน implementation สำหรับ HTTP fetching ขึ้นมาใหม่ ถ้าไลบรารีดึงข้อมูลที่มีอยู่ในโปรเจ็กต์ครอบคลุมทุกกรณียกเว้นอยู่แล้ว, ไม่ไปเขียนซ้ำทั้งที่มีโมดูล utility function อยู่แล้ว, ไม่ไปเปลี่ยนค่าตั้งค่าระดับ global ทั้งที่ทำได้ในแต่ละโมดูล, และไม่สร้างคลาสใหม่ทั้งที่ทีมใช้แนวทาง functional เป็นหลัก, แต่ในความเป็นจริงนักพัฒนาหลายคนก็มักทำเรื่องพวกนี้ซ้ำๆ อยู่บ่อย

    • พูดตามตรง ถ้าโปรเจ็กต์ขนาดใหญ่มีเอกสารไม่ดี เรื่องแบบนี้เกิดขึ้นได้ง่ายมาก, เอกสารโค้ดของโปรเจ็กต์วิจัยเชิงวิชาการที่ฉันทำอยู่บอกแค่ว่าโค้ดนั้น self-documenting อยู่แล้ว และพูดสั้นๆ แค่เรื่องการตั้งค่า CMake, การ build, หรือวิธี benchmark, ส่วนกฎหรือธรรมเนียมภายในต้องเรียนรู้เอาเองจากการลงมือทำ, พอมีคนใหม่เข้ามาก็มักเกิดการทำฟีเจอร์ที่มีอยู่แล้วขึ้นมาใหม่หรือไปเปลี่ยนค่าตั้งค่าระดับ global, สุดท้ายทางที่ดีที่สุดคือทำดัชนี codebase แล้วถาม LLM ตรงๆ (เพราะคนสำคัญของโปรเจ็กต์ย้ายออกไปแล้วหรือกว่าจะตอบก็นานมาก)

    • คิดว่าหลายคนกำลังพลาดประเด็นของผู้เขียน, ถ้าความเร็วคือคุณค่าสูงสุด เรื่องพวกนี้ก็จะเกิดซ้ำไปเรื่อยๆ, ถ้าความเร็วเป็นค่าสัมบูรณ์ ปริมาณงานที่ผลิตได้ต้องเพิ่มแบบทวีคูณถึงจะชดเชย technical debt ได้, ถ้ามีปัจจัยอื่นสำคัญนอกเหนือจากความเร็ว ก็ต้องจัดการและชำระหนี้อย่างชาญฉลาด, แต่ทุกวันนี้ให้ความรู้สึกเหมือนหลายคนแค่แบกหนี้ก้อนโตแล้วหวังว่ามันจะพอเอาตัวรอดได้, และคนจำนวนมากก็ไม่เก่งเรื่องการจัดการหนี้จริงๆ

    • หลายคนพร้อมจะ reinvent the wheel ทุกครั้งที่มีโอกาส, เมินธรรมเนียมที่ควรคาดเดาได้ หรือใช้ pattern ปนกันไปมา, ผู้เขียนอาจเรียกสิ่งนี้ว่า "vibe coding" แต่จริงๆ แล้วมันไม่ใช่ปัญหาเฉพาะของ LLM, มันเกิดได้กับทุกคนเวลาต้องรีบส่งงานหรือยังมีประสบการณ์ไม่มาก, พอเห็นคำว่า "โค้ดที่ไม่มีใครในทีมเขียนกันแบบนั้น" ก็รู้สึกว่ามันอาจเป็นการระบายใส่ใครบางคนเป็นการเฉพาะ, การเอามุมมองนี้ไปใช้กับบริบทอื่นจึงควรระวัง

    • เคยเห็นนักพัฒนาที่เพิ่ม ORM library อีกตัวเข้ามาด้วย, ทั้งที่ตัวแรกก็เพียงพออยู่แล้ว แต่ดันใส่ตัวที่สองเพราะ "กำลังฮิต", ไม่ว่าจะเป็นนักพัฒนาหรือ LLM ต่างก็มีอคติของตัวเอง, การเข้าใจกฎและ pattern ในโปรเจ็กต์แล้วทำงานภายในกรอบนั้นสำคัญมาก, การทำตามสไตล์ตัวเองโดยไม่สนบริบทอันตรายมาก, สำหรับคน เรื่องนี้แก้ได้ด้วยวัฒนธรรม code review และการสนับสนุนให้อ่านโค้ด, แต่สำหรับ LLM ต้องบอกทุก pattern และทุกกฎให้ชัดเจน, ไม่อย่างนั้นก็เสี่ยงมากที่จะสร้างโค้ดที่ไม่เข้ากับโปรเจ็กต์, สิ่งสำคัญคือการกำหนดค่านิยมและเกณฑ์ที่ชัดเจนอย่าง explicit

    • ฉันเคยทำงานในทีมดีๆ แบบนั้นมาก่อน, เป็นโปรเจ็กต์สำคัญหลายตัวที่มีทีมเล็กๆ (2-4 คน), ในสภาพแวดล้อมแบบนี้การสร้างวัฒนธรรมการพัฒนาที่บาลานซ์คุณภาพกับความเร็ว รวมถึงสร้างฉันทามติร่วมกันทำได้ง่าย, ในทีมแบบนั้น ไม่ว่าจะเป็นคนหรือ LLM ก็ไม่มีทางได้ PR approval ถ้าเป็นโค้ดลักษณะแบบข้างบน

  • ส่วนตัวฉันมอง LLM ว่าเป็นนักพัฒนาจูเนียร์มากๆ, ตั้งใจทำงานและทำตามคำสั่ง แต่ยังเข้าใจ codebase และ pattern ไม่พอ, ต้องคอยบอกทีละขั้นตอน อธิบายแม้กระทั่งข้อผิดพลาดที่อาจเกิดขึ้น, ต้องมอบงานเป็นชิ้นเล็กๆ ที่เฉพาะเจาะจงและรีวิวโค้ดอย่างละเอียด, ฉันเองจะนึก data model ในหัวให้เสร็จก่อนแล้วค่อยลงมือเขียนโค้ด, คำอธิบายที่เฉพาะเจาะจงสำคัญมาก, กฎข้อหนึ่งที่ไม่เคยละคือให้ใส่ block comment ไว้บนสุดของไฟล์เสมอเพื่ออธิบายว่าไฟล์นี้มีอะไร, มันทำหน้าที่เหมือน prompt ที่สองเวลาเริ่ม session ใหม่, วิธีนี้ทำงานได้ดีโดยไม่รู้สึกว่า "มหัศจรรย์" เกินจริง, แต่ระหว่างทางประมาณ 30% ของงานก็ยังต้องมาจัดระเบียบโค้ด, เปลี่ยนชื่อ, และ refactor ถึงจะดูดี, ถึงอย่างนั้น การมี LLM ก็ยังทำให้งานเร็วขึ้นมากเมื่อเทียบกับการเขียนมือทั้งหมด

    • คำว่า "นักพัฒนาจูเนียร์" หรือ "copilot" บางทีก็สะท้อนทั้งข้อดีและข้อเสียของ LLM ได้ไม่ครบ, ต่างจากมนุษย์ตรงที่มันลืมง่ายและทำพลาดขั้นพื้นฐานมากๆ ได้, แต่ก็มีบางอย่างที่มันทำได้ดีกว่าฉัน (เช่นปัญหา off-by-one เกี่ยวกับ array), และยังรู้แทบทุกอย่างบนอินเทอร์เน็ตแบบสารานุกรม, จากประสบการณ์ใช้งานจริง ฉันคิดว่า LLM คล้ายสุนัขล่าสัตว์, เจ้าของต้องเป็นคนคุมการล่าและเป็นคนปิดงานเอง

    • ความต่างระหว่าง LLM กับนักพัฒนาจูเนียร์อยู่ที่ความสามารถในการเรียนรู้, จูเนียร์เรียนรู้และเติบโตขึ้นได้เรื่อยๆ แต่ LLM ไม่ได้เป็นแบบนั้น, ยิ่งยัดคำสั่งเข้า prompt มากเท่าไร ก็ยิ่งมีโอกาสลืมมากขึ้นและไหลกลับไปตอบแบบทั่วไป, ทุกครั้งที่เริ่ม prompt ใหม่ก็ต้องสอนใหม่ตั้งแต่ต้น

    • ฉันรู้สึกว่า LLM ก็ไม่ได้ต่างจากการค้นหาโค้ดบนอินเทอร์เน็ตแล้วคัดลอกมาวางมากนัก, สุดท้ายคนพัฒนาก็ต้องตรวจโค้ดเองว่าใช้งานได้จริงไหม, ช่วงนี้เพราะปัญหาสุขภาพตาเลยต้องทำงานเป็นรอบละ 20 นาทีแล้วพัก ทำให้ประสิทธิภาพสำคัญขึ้นมาก, LLM สร้างโค้ดได้เร็วกว่ามนุษย์มาก ดังนั้นแค่ให้มันจัดการส่วนพื้นฐานก็มีประโยชน์มากแล้ว, ตอนนี้ฉันกำลังสร้าง struct สำหรับ SIMD ด้วย Unity C# และ LINQ, แค่บอกเงื่อนไขที่ต้องการกับ LLM ก็ได้โค้ดหรือสตริงที่ต้องการเร็วกว่าการไปคัดลอกมาวางเองมาก, แนวคิดการใช้ AI เหมือน HUD เริ่มจับต้องได้จริง, ฉันต้องการเครื่องมือช่วยพัฒนาที่ทรงพลังในหน่วยย่อยๆ มากกว่า AI ที่มาสร้างทั้งโปรแกรม

    • สำหรับฉัน LLM เป็นทางเลือกแทน StackOverflow ที่ดีกว่ามาก, ถามสิ่งที่สงสัยได้ทันทีและมันตอบได้แม่นยำ, ฉันเอาคำตอบมาอ้างอิงแล้วเขียนใหม่ให้เข้ากับโค้ดของตัวเอง หรือให้มันสร้างแค่ฟังก์ชันก็ได้, ก่อนคัดลอกฉันพยายามทำความเข้าใจโค้ดทั้งหมดให้ครบก่อนเสมอ, บางครั้งก็เคยคิดว่าการส่ง PR ขนาด 400,000 บรรทัดไปยังโปรเจ็กต์โอเพนซอร์สในภาษาที่ตัวเองไม่ค่อยรู้ อาจให้ผลกับอาชีพมากกว่าการทำงานอย่างซื่อสัตย์และเน้นคุณภาพเสียอีก, เพราะในโลกจริง Years of Experience มักถูกให้ค่าน้ำหนักมากกว่าสกิล

    • ถ้าจะให้ LLM ทำงานสำเร็จ สิ่งที่ได้ผลคือจำกัดมันไว้แค่ขั้นตอน coding จริงๆ ไม่ใช่ขั้นคิด, ต้องแตก task ให้ย่อยและส่งรายละเอียดให้มากที่สุด ทั้งสเปกที่ชัดเจน, ไฟล์ที่ต้องแก้, ตำแหน่งตัวอย่างอ้างอิง ฯลฯ, ไม่จำเป็นต้องละเอียดทุกเม็ด แต่ยิ่งมีเบาะแสมาก โอกาสสำเร็จก็ยิ่งสูง, โค้ดที่มันสร้างมาก็ยังต้องตรวจทีละก้อนด้วย git add -p, แม้จะเสียเวลาไปกับการเตรียมและการทบทวน แต่ก็ยังประหยัดเวลาและพลังงานกว่าการเขียนเองทั้งหมดหรือปล่อยให้โค้ดหละหลวมคาอยู่แบบนั้นแน่นอน

  • ความเสี่ยงใหญ่ที่สุดของ vibe coding คือ นักพัฒนาฝีมือดีอาจแค่เร็วขึ้นเล็กน้อย แต่คนที่ฝีมือไม่พอกลับสามารถสร้างโค้ดแย่ๆ จำนวนมากได้เร็วขึ้นมาก, ประเด็นคือคนกลุ่มนั้นจะพัฒนาฝีมือขึ้นจากการ vibe coding ได้หรือไม่ หรือจะหยุดนิ่งอยู่ตรงนั้นเฉยๆ

    • จากประสบการณ์ นักพัฒนาระดับ mediocore ก็สามารถกลายเป็นนักพัฒนาที่แย่ได้อย่างรวดเร็ว, เหตุผลคือความมั่นใจผิดๆ และปริมาณโค้ดที่พุ่งสูงขึ้น, โค้ดที่ AI สร้างแทบไม่ค่อยสนใจสถาปัตยกรรมโดยรวม, การไหลของข้อมูล, หรือหลัก single responsibility, มันมักประกอบโค้ดให้ "ปลอดภัย" โดยคืนค่า placeholder แทนที่จะโยน exception, ทำให้โค้ดฝั่งเรียกต้องคอยเช็กทุกครั้งว่าผลลัพธ์เป็น placeholder หรือไม่, ตั้งแต่แรกถ้า input parameter ไม่ดี AI ก็จะพยายามแก้เองจนละเลยโครงสร้าง gather_parameters → call → process_results, และพอไปถึงขั้นทดสอบ ปัญหาก็ยิ่งใหญ่ขึ้นอีกมาก

    • ตอนนี้นักพัฒนาจำนวนมากคงกำลังจะกลับมาค้นพบแนวคิดเรื่อง net-negative programmer (นักพัฒนาที่มีอยู่แล้วทำให้คุณภาพโปรเจ็กต์แย่ลง) กันอีกครั้ง

  • สำหรับฉัน ทรัพยากรที่ขาดที่สุดในเรื่องนี้คือความใส่ใจ, vibe coding เองไม่ใช่ต้นเหตุของการขาดความใส่ใจ, AI ก็เป็นแค่เครื่องมือ, ทุกปัญหาที่ผู้เขียนพูดถึงใช้ได้เหมือนกันกับนักพัฒนาจูเนียร์ที่เป็นมนุษย์ และถ้าแนะนำหรือสื่อสารให้ดีขึ้นก็ปรับปรุงได้, ฉันไม่คิดว่า AI ทำให้ความใส่ใจต่อคุณภาพลดลง (คนที่ไม่แคร์ก็ไม่แคร์มาตั้งนานแล้ว), เวลามีคนโต้แย้งก็มักพูดว่า "มันทำให้เสียโอกาสในการฝึกจูเนียร์" แต่หลายกรณีก็แค่ไม่มีทรัพยากรพอเลยต้องใช้ AI เป็นทางออกชั่วคราว (สตาร์ตอัปของฉันที่จ้างคนไม่ได้ก็เหมือนกัน), เครื่องมือ AI อาจทำให้มาตรฐานคุณภาพซอฟต์แวร์เปลี่ยนไปได้ และฉันคิดว่าส่วนนี้ยังเปลี่ยนแปลงได้อีกมากในอนาคต

  • LLM ควรใช้ไม่ใช่แค่บริบทปัจจุบัน แต่รวมถึงประวัติ commit ก่อนหน้าด้วย, codebase จำนวนมากกำลังค่อยๆ migrate จาก pattern A ไป B และมีหลาย pattern อยู่ร่วมกัน, การย้ายมักทำทีเดียวไม่ได้จึงมักเห็นของเก่ากับของใหม่ปะปนกันอยู่นาน, เหมือนตัวอย่าง HTTP ต่อให้ LLM มองเห็น pattern ก็ยังขึ้นกับดวงว่าจะตามอันไหน

    • ฉันเคยทำงานกับ codebase ขนาดใหญ่ที่ผ่านการควบรวม เปลี่ยนชื่อบริษัท และการเข้าซื้อมานานกว่า 20 ปี, ยังมีตัวอย่างการเรียก API เก่าๆ อยู่เต็มไปหมด ทั้งที่จริงก็มีโค้ดเวอร์ชันใหม่กว่าแยกอยู่ แต่หลายอย่างยังต้องเก็บไว้เพื่อรองรับลูกค้าบางราย, ยังมี API คล้ายๆ กันอีกจำนวนมากที่ไม่มีเอกสารเลย จนต้องไล่หาทีละตัวว่าอันไหนจะคืนข้อมูลที่ฉันต้องการ

    • วิธีหนึ่งคือมีไฟล์อย่าง CLAUDE.md เพื่อระบุให้ชัดว่า "ให้ทำตาม pattern นี้, หลีกเลี่ยง pattern นั้น"

    • แต่ฉันคิดว่าการบอกวิธีทำงานของแต่ละส่วนพร้อมตัวอย่างอย่างเจาะจงจะได้ผลมากกว่า

    • ปัญหาคือความสามารถในการรับรู้บริบทแบบนี้เองที่คนทำ vibe coding มักขาดมาก, หลายคนมีประสบการณ์เขียนโค้ดน้อยตั้งแต่ก่อนยุค LLM แล้ว

    • เรื่องแบบนี้จะเป็นไปได้ก็ต่อเมื่อ commit message ถูกเขียนไว้อย่างเหมาะสม, แต่ในความจริงส่วนใหญ่มีแต่ข้อความอย่าง "แก้ไฟล์นี้" หรือ "แก้บั๊ก"

  • เวลาใช้ LLM เครื่องมืออัตโนมัติอย่าง linter, formatter, และการตรวจ type แบบเข้มงวดช่วยได้มาก, โดยเฉพาะเมื่อมีการส่งโค้ดมาจากคน (หรือ LLM agent) ที่ไม่รู้ style โค้ดหรือกฎแฝงต่างๆ, ระบบอัตโนมัติสามารถตรวจและแก้สิ่งที่แก้ได้ทันที, เรื่อง test ก็เหมือนกัน, ระบบตรวจสอบอัตโนมัติมีประโยชน์มากต่อการรักษาคุณภาพ ไม่ว่าจะเป็นมนุษย์หรือ agent

    • แต่ฉันคิดว่าในทางปฏิบัติ เครื่องมือพวกนี้ไม่ได้กันกรณี vibe coding ส่วนใหญ่ที่บทความพูดถึงได้จริง

    • เครื่องมือพวกนี้บางทีก็แค่กลบปัญหาแล้วทำให้ผิวหน้าดูเรียบร้อยขึ้นเท่านั้น

  • AI assistant หลักๆ ทุกตัวมีวิธีลดปัญหาแบบนี้ติดมาอยู่แล้ว, เช่น /init ของ Claude Code หรือ /Generate Cursor Rules ของ Cursor, ซึ่งทำให้บังคับใช้ได้ทั่วทั้งองค์กรในแบบอัตโนมัติมากกว่าการทำ context engineering แบบง่ายๆ, สุดท้ายก็เป็นประเด็นที่น่าสนใจว่าเครื่องมือพวกนี้กำลังแบ่งชุมชนนักพัฒนาออกอย่างไร

    • แต่ในความเป็นจริง ต่อให้กำหนดไว้ชัดแค่ไหนใน CLAUDE.md ก็ยังมีบ่อยครั้งที่ CC (Claude Code) ไม่สนใจ, ยิ่งคุยต่อเนื่องก็ยิ่งรู้สึกว่าปัญหาเดิมๆ วนกลับมาอีก และจนถึงตอนนี้ฉันก็ยังไม่เจอวิธีแก้ที่น่าพอใจจริงๆ, เพราะงั้นฉันไม่คิดว่าควรปัดบทความนี้ทิ้งว่าเป็นแค่การต่อต้าน AI

    • ฉันกำลังกลับไปประเมิน Cursor ใหม่, เหตุผลที่มันยังไม่เร็วอย่างที่หวังคือไม่ใช่แค่ข้อผิดพลาดเล็กๆ น้อยๆ (เช่น LM เปลี่ยน : เป็น ,) แต่ยังเป็นเพราะ codebase ใหญ่เกินไป เก่าเกินไป และคุณภาพไม่สม่ำเสมอ, สุดท้าย LLM ก็มักหยิบ pattern ที่พบบ่อยที่สุด (= แย่ที่สุด) มาใช้บ่อยกว่า, ต่อให้สั่งชัดๆ ว่า "ให้อ้างอิงส่วนนี้" มันก็ยังโดนอิทธิพลจาก codebase ทั้งก้อนอยู่ดี, ต่อให้กำหนดเป็น rule ก็ดูไม่ต่างจากยัดลงไปใน prompt ตรงๆ มากนัก, เลยสงสัยว่ามีทางแก้ไหม

    • แก่นของปัญหาไม่ใช่เครื่องมือ แต่คือ "coder" ที่ให้ความสำคัญกับ vibe มากกว่า, ไม่ได้ใส่ใจและเขียนโค้ดแบบหลวมๆ

  • จากประสบการณ์ของฉัน ปัญหาแทบทั้งหมดมาจาก context window ที่จำกัดและ context engineering ที่ยังไม่เหมาะนัก, ถ้า LLM ได้รับบริบทสำคัญอย่างฟังก์ชันระดับ global อย่างถูกต้อง มันก็มักนำไปใช้ได้ค่อนข้างดี, ปัญหาคือจะเลือกบริบทอะไรและส่งต่ออย่างต่อเนื่องโดยไม่ขาดได้อย่างไร, ฉันคาดหวังว่าจะมีพัฒนาการมากในเรื่องนี้ผ่านแนวทางอย่าง sub-agent

    • มีคนบอกว่า "ถ้า agent รู้คำอธิบายของฟังก์ชันระดับ global ก็จะใช้มันได้ดี" แต่จริงๆ แล้วไม่มีสิ่งที่เรียกว่า "agent" อยู่เลย, มันก็แค่ฟังก์ชันทางคณิตศาสตร์ที่เชื่อม input กับ output เท่านั้น, การเปรียบ LLM กับมนุษย์เป็นสิ่งที่ไม่แม่นยำ, มนุษย์กับเครื่องจักรต่างกันโดยสิ้นเชิง

  • ฉันคิดว่าทั้งหมดนี้ถูกต้อง, วิธีที่ดีที่สุดในการใช้ LLM คือใช้มันเหมือนกับที่ compiler มอบระดับนามธรรมสูงกว่า assembly, คืออธิบาย requirement และ input/output ให้ชัด แล้วมันจะสร้างโค้ดออกมาเป็นการแปลเชิงตรรกะ, เพราะงั้นต้องลดความสับสน (entropy) ใน input ให้มากที่สุด, โดยธรรมชาติแล้ว LLM คือ translation engine, ถ้าใช้มันเพื่อ "แปล" มากกว่าจะ "สร้าง" จะมีประสิทธิภาพกว่า, ถึงอย่างนั้นก็ยังมีโมเดลใหม่ๆ ที่ฉลาดขึ้นและใช้งานแบบตรงสัญชาตญาณมากขึ้นออกมาเป็นระยะ ทำให้ต้องคอยกำกับน้อยลงแต่ได้ผลลัพธ์ดีขึ้น, สุดท้ายวันหนึ่งย่อมมาถึงที่ LLM จะทำงานบาง task ได้ดีกว่านักพัฒนามนุษย์ และก็คงเหมือนกันกับบทบาทอื่นของมนุษย์

    • นี่เป็นการเปรียบเทียบที่ผิด, LLM ไม่ใช่เอนจินที่ "compile" ภาษาธรรมชาติให้เป็นโค้ดระดับสูง, ภาษาโปรแกรมกับภาษาเครื่องต้องการระบบความหมายที่ชัดเจนและสม่ำเสมอ แต่ภาษาธรรมชาติมีชั้นนามธรรมต่างออกไปตั้งแต่ต้น, แม้จะเป็น LLM ตัวเดียวกัน หากเปลี่ยน seed หรือเวอร์ชันใหม่ก็อาจให้ผลลัพธ์ต่างกัน, แต่ compiler ต้องให้ output เดิมเสมอเมื่อ input เดิม

    • ฉันไม่เห็นด้วยเลยกับการมอง LLM เป็นชั้นนามธรรมแบบ compiler, ในความจริง LLM ก็เป็นแค่ตัวสร้าง token แบบสุ่ม, ฉันยังไม่เคยเห็นผลลัพธ์ที่สร้างด้วย LLM แล้วใช้งานได้ดีจริง, แนวคิดมองโลกในแง่ดีทางเทคโนโลยีเรื่อง singularity หรือการมีข้อมูลอย่างไม่จำกัดนั้นขาดหลักฐานความจริงรองรับ, ท้ายที่สุดการได้มาซึ่งข้อมูลคุณภาพสูงมีต้นทุนมหาศาล, ณ ตอนนี้การคาดการณ์ในแง่หวังยังไม่มีความหมายมากนัก

  • ฉันเข้าใจช้ากว่าผู้เขียนเสียอีกว่า "คนส่วนใหญ่ต้องการกาแฟที่เร็วและถูกมากกว่ากาแฟที่ดี", ในโลกจริงคนส่วนใหญ่ให้ความสำคัญกับความเร็วและราคามากกว่าคุณภาพ

    • แค่ดูความนิยมของเครื่องชงกาแฟ Keurig ก็พอเห็นแนวโน้มนั้นได้
 
dkmin 2025-08-02

โพสต์ใน HN หวานยิ่งกว่าตัวบทความเสียอีก