"Vibe Coding" เทียบกับความเป็นจริง

 (cendyne.dev)
19 คะแนน โดย GN⁺ 2025-03-24 | 9 ความคิดเห็น | แชร์ทาง WhatsApp
  • ช่วงหลังมานี้คำพูดของ Andrej Karpathy กลายเป็นประเด็นร้อน: "ปล่อยตัวไปกับ Vibe, ยอมรับการเติบโตแบบทวีคูณ, และลืมไปเสียด้วยซ้ำว่ามีโค้ดอยู่"
  • "Vibe Coding" หมายถึงแนวโน้มในการมอบหมายการแก้ปัญหาให้เครื่องมือ AI โดยไม่มีแผนที่ชัดเจนหรือไม่ต้องเขียนโค้ดเอง
  • ผ่านเอเจนต์ LLM (Large Language Model) ผู้ใช้สามารถสั่งงานด้วยภาษาธรรมชาติให้สร้างและแก้ไขโค้ดได้
    • 2022: สามารถคัดลอกและแก้ไขโค้ดใน ChatGPT ได้
    • 2023: สามารถรีวิวและแก้ไขโค้ดใน Copilot ที่ผสานเข้ากับ IDE ได้
    • 2024~2025: สามารถแก้ไขหลายไฟล์ในโปรเจกต์ รวมถึงทดสอบและแก้ไขได้ด้วยตัวเอง

วิธีการทำงานของ "Vibe Coding"

  • ทั้งผู้ใช้สายเทคนิคและไม่ใช่สายเทคนิคสามารถตั้งค่าโปรเจกต์ผ่านเอเจนต์ที่อิงกับ LLM ได้
  • สามารถสร้างเว็บไซต์หรือแอปได้ด้วยคำสั่งง่ายๆ (เช่น "สร้างเว็บไซต์สกีรีสอร์ต")
  • หลังตั้งค่าเริ่มต้นแล้ว สามารถแก้ไขและทดสอบอัตโนมัติได้

  • ตัวอย่าง:

    • Cursor, GitHub Copilot Agent Mode เป็นต้น สามารถแก้ไขไฟล์และรันคำสั่งได้
    • ทำการแก้ไขและทดสอบอัตโนมัติ → แต่อาจเกิดข้อผิดพลาดจากความไม่สอดคล้องกัน

ปัญหาเรื่องความเป็นอิสระของเอเจนต์

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

  • ปัญหาหลัก:

    • ใช้โค้ดเดิมซ้ำไม่สำเร็จ → สร้างคอมโพเนนต์เดิมซ้ำหลายครั้ง
    • พยายามรัน logic ฝั่งเซิร์ฟเวอร์บนฝั่งไคลเอนต์
    • เกิดข้อผิดพลาดหลังแก้โค้ดผิด → และแก้ต่อไม่สำเร็จ
    • เขียน unit test ไม่สำเร็จ หรือทำโค้ดพัง

ข้อจำกัดในโลกความเป็นจริง

  • โมเดลอย่าง Claude 3.7 Sonnet ยังไม่สามารถก้าวข้ามข้อจำกัดของข้อมูลฝึกได้
  • หากหลุดบริบทใน codebase ก็ไม่สามารถแก้ไขได้อย่างสอดคล้อง
  • เมื่อขนาดโค้ดใหญ่ขึ้น ประสิทธิภาพจะลดลงและไม่สามารถรักษาบริบทไว้ได้
  • หากเกินขนาด context window ของ LLM จะเกิดปัญหาความสอดคล้องกัน

  • ตัวอย่างปัญหาแบบเจาะจง:

    • คัดลอก TypeScript interface ซ้ำ
    • รัน logic ฝั่งเซิร์ฟเวอร์บนฝั่งไคลเอนต์
    • แก้ไขคอมโพเนนต์ที่ซ้ำกันไม่สำเร็จ
    • เขียน unit test ไม่สำเร็จ
    • หลัง refactor โค้ดแล้วแก้ข้อผิดพลาดไม่สำเร็จ

ความพยายามในการแก้ปัญหา

  • Claude Plays Pokémon: เอเจนต์โต้ตอบแบบเรียลไทม์และเล่นเกมได้
  • แต่ล้มเหลวในการคงหน่วยความจำและแก้ข้อผิดพลาดซ้ำๆ
  • สร้างความทรงจำระยะยาวไม่สำเร็จ → ทำให้เกิดข้อผิดพลาดต่อเนื่อง

  • ความเป็นไปได้ในการปรับปรุง:

    • จำเป็นต้องปรับปรุง MCP(Model Context Protocol) และการจัดการหน่วยความจำ
    • เมื่อแก้โค้ด LLM ต้องสะท้อนการแก้ไขก่อนหน้าได้อย่างถูกต้อง
    • จำเป็นต้องเก็บรักษาความทรงจำเฉพาะโดเมนและประวัติงาน

บทสรุป

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

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

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

 
nicewook 2025-03-25

คำว่า "ระดับปัจจุบัน" สะดุดตาผมอยู่ ไม่ใช่ว่าเรากำลังมอง LLM ด้วยกรอบแนวคิดเรื่องเวลาของมนุษย์กันอยู่หรอกหรือ?
 
ng0301 2025-03-24

สิ่งที่รู้สึกได้ระหว่างเขียนโค้ดกับ AI คือ ต่อให้ให้โค้ดกับ AI ไปแค่บางส่วน ถ้าเราแยกหน่วยงานในลักษณะตามหลักความรับผิดชอบเดียว + ความรู้สึกแบบ TDD จนมันเข้าใจบริบทได้ ก็ต้องจัดให้แม้ไม่ต้องอ่านบริบทใหญ่ทั้งหมด แต่แค่บริบทของส่วนนั้นก็เพียงพอให้จับประเด็นได้
 
ifmkl 2025-03-24

ผมใช้ AI กับงานอดิเรกมากที่สุดในการทำเว็บเกม และก็เห็นด้วยครับ พอขนาดงานใหญ่เกินระดับหนึ่งไป จะมีช่วงที่ AI เหมือนเสียสมาธิหรือโฟกัสตกลงอย่างเห็นได้ชัด ผมเลยใช้มันในลักษณะนี้: รวมโครงสร้างทั้งต้นไม้ภายในเกมกับซอร์สโค้ดทั้งหมดเป็นไฟล์เดียวพร้อม TOC จากนั้นสร้างเธรดใหม่ อัปโหลดไฟล์นั้น แล้วทำงานต่อจากตรงนั้น และเวลาถาม ผมจะระบุชื่อโปรเจกต์ปัจจุบันให้ชัดเจนเสมอพร้อมขอให้มันตอบตามนั้น ถึงอย่างนั้นก็ยังมีบางส่วนที่ยังไม่ค่อยน่าพอใจอยู่บ้าง... แต่ผมพอใจมากกับการที่สามารถทำงานอดิเรกซึ่งเมื่อก่อนเพราะยุ่งกับชีวิตจริงจนไม่กล้าแม้แต่จะเริ่ม ให้ค่อย ๆ เสร็จสมบูรณ์ได้ในเวลาที่ค่อนข้างสั้น
 
pcj9024 2025-03-24

แพตเทิร์นที่ทำแบบคร่าวๆ ก่อน แล้วค่อยมาเก็บรายละเอียดที่เหลือทีหลังนี่ดีมากจริงๆ
 
psguny9 2025-03-24

แม้จะลองหลายอย่าง แต่ข้อจำกัดด้านความจำก็ชัดเจนอยู่แล้ว เหมาะในระดับ PoC ดี ในแง่ของการดูความเป็นไปได้/การใช้งานอย่างรวดเร็วก็ถือว่าดี

แต่ปัญหาคือยิ่งต้องการผู้มีประสบการณ์มากขึ้นไปอีก
 
colus001 2025-03-24

เมื่อมองว่าเวลาส่วนใหญ่ในการเขียนโค้ดหมดไปกับการดีบักและการอ่านโค้ด ผมคิดว่านี่เป็นการพูดเกินจริงไปมาก คนที่สร้าง AI ต่างก็พูดในทำนองนี้กันหมด แต่ถ้าดูอย่างน้อยจากสถานการณ์ตอนนี้ ก็ดูเหมือนจะยังไม่เป็นแบบนั้น ถ้าไปถึงจุดที่ไม่ต้องใช้แรงคนเลยจริง ๆ จะยังจำเป็นต้องเขียนโค้ดอยู่หรือเปล่า? แค่ใส่คำอธิบาย API แล้วใช้ LLM เป็นแบ็กเอนด์ไปเลยน่าจะดีกว่า
 
reagea0 2025-03-24

ในทางปฏิบัติก็มักตั้งค่าสคีมาแล้วรับมาใช้กันเยอะแบบนั้นครับ
 
nowdoit7 2025-03-24

เห็นด้วยครับ/ค่ะ ช่วงแรกมันแสดงให้เห็นความเร็วในการพัฒนาที่แทบจะมหัศจรรย์ แต่ยิ่งสเกลใหญ่ขึ้นและมีไฟล์มากขึ้น หากผู้ที่รับผิดชอบในการดูแลจัดการมันอย่างมีประสิทธิภาพไม่ได้ (ในที่นี้คือมนุษย์) สุดท้ายก็จะได้เพียงผลลัพธ์ที่ตัวใหญ่เทอะทะและเต็มไปด้วยข้อผิดพลาดเท่านั้น ถ้าปล่อยไปจนถึงขั้นที่แก้ไขอะไรไม่ได้แล้ว ก็มีแต่จะสิ้นเปลืองเครดิต (Windsurf) หรือรีเควสต์ (Cursor) ไปเปล่า ๆ มันจะค่อย ๆ ดีขึ้นแน่นอน แต่ตอนนี้ยังไม่ควรเชื่อถือโค้ดจาก AI แบบ 100%
 
GN⁺ 2025-03-24
ความคิดเห็นบน Hacker News

  • ความต่างใหญ่ระหว่าง "AI ที่ถูกโหมเกินจริง vs. ความเป็นจริง" อยู่ที่ตัวเลขด้านประสิทธิภาพที่ผู้คนชอบพูดถึงกัน ตัวอย่างเช่น พาร์ตเนอร์ของ YC อ้างคำกล่าวของบริษัทหนึ่งที่บอกว่าประสิทธิภาพการเขียนโค้ด "เร็วขึ้น 100 เท่า" คำกล่าวแบบนี้ถ้าเป็นจริงคนนอกก็น่าจะมองเห็นได้ชัด จึงไม่ควรต้องพึ่งการรายงานด้วยตัวเอง

    • รุ่นฤดูร้อนของ YC ดำเนินไป 84 วันและจบด้วย Demo Day การเร็วขึ้น 100 เท่าเท่ากับว่าทีมสามารถสร้างแอปที่มีฟีเจอร์ระดับ Demo Day ได้ภายในเวลาไม่ถึงหนึ่งวัน ถ้า 100 เท่าเป็นเรื่องจริง พาร์ตเนอร์ก็คงจะพูดว่ารุ่นใหม่ ๆ นั้น "กินมื้อเช้ากับลูกค้า เรียนรู้อะไรใหม่ ๆ ได้แรงบันดาลใจ แล้วเขียนแอปใหม่ทั้งตัวในวันเดียว และผลลัพธ์ก็มีฟีเจอร์ระดับ Demo Day" แต่ไม่มีเรื่องเล่าแบบนั้น ดังนั้น 100 เท่าจึงไม่แม่นยำ
    • ต่อให้ดีขึ้น 10 เท่า พาร์ตเนอร์ก็น่าจะพูดว่า "รุ่นนี้ผู้คนเอาแอประดับ Demo Day ขึ้นโปรดักชันได้ตั้งแต่สัปดาห์แรก" พาร์ตเนอร์มีขนาดตัวอย่างใหญ่เกี่ยวกับว่าทีมต่าง ๆ ทำงานได้มากแค่ไหนในช่วงเวลาเท่าใด ดังนั้น 10 เท่าก็ไม่ใช่ความจริงเช่นกัน

  • ตอนนี้เรากำลังตามกระแสการจ้างงานเอาต์ซอร์ส ด้วยคำกล่าวเกินจริงทั้งหมดนั้น ความจริงกลับต่างออกไป การถกเถียงเรื่องเอเจนต์เขียนโค้ดแบบ LLM ก็แยกความต่างได้ยาก

  • มันก็เหมือนกับที่ชุมชน Go เคยบอกว่าคอมพิวเตอร์ไม่มีทางชนะผู้เล่น Go ที่เป็นมนุษย์ได้ ตอนนี้มีตัวอย่างของโมเดลที่หาวิธี sort ที่มีประสิทธิภาพดีกว่าเดิมได้แล้ว ถ้าให้แรงจูงใจและเวลาที่เหมาะสม คอมพิวเตอร์ก็จะชนะพวกเรา

    • "Vibe coding" ยังไม่ใช่ความจริงในตอนนี้ ยังต้องใช้ประสบการณ์และทักษะในการแก้ข้อผิดพลาดและคอยชี้นำ แต่ก็มองเห็นแนวโน้มการพัฒนาได้

  • แชร์ปัญหาใหม่เกี่ยวกับ coding LLM นักพัฒนานอกประเทศถูกรวมเข้ากับทีมอย่างสมบูรณ์แล้ว แต่การใช้ LLM เป็นไปอย่างสะเปะสะปะและไร้การควบคุม จน pull request ที่ส่งเข้ามากลายเป็นฝันร้าย

    • มีการใช้ LLM เพื่อช่วยเขียนโค้ด แต่ใช้อย่างระมัดระวังมาก แม้จะประหยัดเวลา แต่ไม่ได้เพิ่มคุณภาพ เวลาที่ใช้ไปกับการหาว่าจะ prompt อย่างไรให้ถูกต้อง เวลาตรวจสอบผลลัพธ์ และเวลาตามแก้บั๊กเล็ก ๆ กลับหักล้างข้อดีนั้น
    • อย่าทำ "Vibe coding" และต้องระวังอย่าให้ตัวเองตกงาน

  • "Vibe Coding" อาจทำให้คอนเซปต์เสร็จได้ 80% แต่การจะสร้างสิ่งที่เชื่อถือได้ ปลอดภัย และมีคุณค่านั้น ยังต้องการมนุษย์ที่มีประสบการณ์

    • 80% ในกรณีที่ดีที่สุดก็เป็นเพียง proof of concept เท่านั้น 80% ก็เหมือน QA เดินเข้าบาร์

  • ไม่นานมานี้มีการลองใช้ Claude และ OpenAI o3-mini เพื่อแปลงโค้ด Matlab เป็น Python แต่ผลลัพธ์แย่มาก แทบทุกบรรทัดสำคัญมีข้อผิดพลาด นี่เป็นงานที่ควรถูกทำให้อัตโนมัติได้ แต่กลับล้มเหลว

  • การทำ "Vibe-TDDing" ยังดีกว่าไม่มีเทสต์เลย ถ้ามีความเข้าใจทั้งเรื่องการเขียนโค้ดและการทดสอบ ก็สามารถใช้ LLM เพื่อลดผลกระทบเชิงลบภายนอกได้

  • หลังจากแชร์วิธีสร้าง SaaS ก็เกิดเรื่องแปลกขึ้น การใช้ API key พุ่งถึงขีดสูงสุด มีการเลี่ยงระบบสมัครสมาชิก และมีข้อมูลสุ่ม ๆ ถูกสร้างใน DB นี่อาจเป็นการปั่นเล่น

  • เห็นวิศวกรจำนวนมากประเมินความสามารถและประสิทธิภาพของเครื่องมือเขียนโค้ดด้วย AI ต่ำเกินไป เลยยิ่งรู้สึกมั่นคงกับงานของตัวเอง จะไม่เลิกใช้ Cursor แน่นอน

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