Vibe Coding - การเขียนโค้ดตามฟีล

 (x.com/karpathy)
3 คะแนน โดย GN⁺ 2025-02-04 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • นำเสนอแนวคิดใหม่ของ “Vibe Coding” ใน สภาพแวดล้อมการพัฒนาที่ขับเคลื่อนด้วย LLM ซึ่งผู้ใช้ไม่ต้องเขียนโค้ดด้วยตนเอง แต่สร้างผลลัพธ์ผ่านการสนทนาและคำสั่ง
  • ใช้ Cursor Composer และ SuperWhisper เพื่อแก้ไขโค้ดด้วยคำสั่งเสียง โดยทำงานได้ด้วยคำขอเรียบง่ายอย่าง “ลด padding ของ sidebar ลงครึ่งหนึ่ง”
  • ใช้ เวิร์กโฟลว์การแก้ไขอัตโนมัติ โดยไม่อ่าน diff ของการเปลี่ยนแปลงโค้ด กด ‘Accept All’ เพื่ออนุมัติทั้งหมดรวดเดียว และคัดลอกข้อความ error วางเข้าไปตรง ๆ เพื่อให้ช่วยแก้
  • โค้ดจะค่อย ๆ ซับซ้อนขึ้นจนทำความเข้าใจได้ยาก แต่ในระดับ โปรเจ็กต์ทดลองสำหรับทำเล่นช่วงสุดสัปดาห์ ก็ยังใช้งานได้ดีพอ
  • แม้แต่ เกม Battleship ที่ให้ LLM สองตัวแข่งกันแบบเรียลไทม์ก็ถูกสร้างขึ้นด้วยวิธีเดียวกัน พร้อมข้อสังเกตว่า “4o แข็งแกร่งกว่า 4o-mini”

แนวคิดของ Vibe Coding

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

เครื่องมือที่ใช้และวิธีทำงาน

  • ใช้ Cursor Composer และ โมเดล Sonnet ในการสร้างโค้ด
    • สนทนากับ Composer ด้วยเสียงผ่าน SuperWhisper และแทบไม่ต้องพิมพ์คีย์บอร์ด
  • ส่งคำขอแก้ไขด้วยคำสั่งง่าย ๆ อย่าง “ลด padding ของ sidebar ลงครึ่งหนึ่ง”
    • อนุมัติด้วย ‘Accept All’ โดยไม่ตรวจ diff ของการเปลี่ยนแปลงโค้ด
    • ข้อความ error ส่วนใหญ่สามารถแก้ได้เพียงคัดลอกไปวาง โดยไม่ต้องอธิบายเพิ่มเติม

การจัดการโค้ดและข้อจำกัด

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

โปรเจ็กต์ทดลอง: เกม Battleship

  • ใช้ “Vibe Coding” ราวหนึ่งชั่วโมงเพื่อสร้าง เกม Battleship
    • เป็นโครงสร้างที่ให้ LLM สองโมเดลแข่งกันแบบเรียลไทม์
    • มีการกล่าวถึง ข้อสังเกตแบบไม่เป็นทางการ ว่า “4o แข็งแกร่งกว่า 4o-mini”
  • ขณะนี้ ยังไม่มี สถิติแบบละเอียดหรือค่าการเปรียบเทียบประสิทธิภาพที่ชัดเจน

บริบทโดยรวม

  • แสดงให้เห็นว่า จาก พัฒนาการของ LLM นักพัฒนาสามารถ สร้างแอปพลิเคชันที่ใช้งานได้อย่างรวดเร็ว โดยไม่ต้องลงมือจัดการโค้ดรายละเอียดเอง
  • “Vibe Coding” อาจมองได้ว่าเป็นตัวอย่างเชิงทดลองของ กระบวนทัศน์การเขียนโปรแกรมแบบใหม่ที่มี AI เป็นศูนย์กลาง

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

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

 
GN⁺ 2025-02-04
ความคิดเห็นจาก Hacker News

  • ทุกปีฉันคิดว่ามาตรฐานด้านคุณภาพของซอฟต์แวร์คงต่ำลงไปกว่านี้ไม่ได้แล้ว แต่ก็ต้องพบทุกครั้งว่าตัวเองคิดผิด

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

  • ฉันเองก็รู้สึกสนุกเวลาใช้วิธีนี้ทำโปรเจ็กต์เบาๆ

    • แต่เรื่องความปลอดภัยห้ามทำลวกๆ เด็ดขาด
    • ผู้ช่วยเขียนโค้ด AI เคยสร้าง API ที่ไม่มีการยืนยันตัวตน หรือสร้างเทมเพลตที่มีความเสี่ยง XSS บ่อยมาก
    • ฉันใช้ LLM ทุกวัน แต่ก็มั่นใจว่าบทบาทของวิศวกรความปลอดภัยจะยังคงมีความจำเป็นอีกมากในอนาคต

  • พอเห็นแนวทางแบบนี้ ก็ให้ความรู้สึกเหมือนเป็นผลงานที่ส่งโดย**‘คนที่กินไปเขียนโค้ดไป’**

  • กังวลว่าถ้าเริ่มเขียนโค้ดด้วยวิธีนี้ ความสามารถในการแก้ปัญหายากๆ จะเสื่อมลงไหม

    • แต่อีกฝ่ายก็บอกว่ายังสามารถทำส่วนที่จำเป็นด้วยมืออย่างละเอียดได้เหมือนเดิม
    • แถมยังลดกำแพงในการเริ่มต้นลองสิ่งใหม่ๆ ลง ทำให้สำรวจได้อย่างอิสระมากขึ้นมาก

  • ช่วงนี้มีนักพัฒนาแบบ AI nativeที่เริ่มเรียนรู้ด้วยวิธีนี้ตั้งแต่แรกมากขึ้นเรื่อยๆ

    • ตอนนี้ดูเหมือนจะเป็นยุคที่ใกล้เคียงกับการบริหารจัดการ AI coderมากกว่าการเขียนโค้ดเสียอีก

  • เครื่องมือแนว “WYSIWYG ที่แก้ไขได้ด้วยคำสั่งภาษาธรรมชาติ” ดูเหมือนจะมีหน้าผาความยากที่ชันมากแบบเดียวกับข้อจำกัดของเครื่องมือ RAD

  • บางคนบอกว่า “ไม่ควรเรียนแบบนี้” แต่ฉันคิดว่าสิ่งสำคัญคือการปรับสมดุลระหว่างความพยายามกับระดับความสมบูรณ์

    • Vibe Coding เป็นวิธีที่ดีสำหรับการเรียนรู้และการสำรวจ
    • มันอาจเปิดสเปกตรัมใหม่ของความพยายาม–ความสมบูรณ์ขึ้นมาได้
    • เพียงแต่ตามคำของ Fred Brooks ถ้าความพยายามครั้งแรกออกมาไม่ดีพอ ก็ต้องกล้าทิ้งมัน
      • ถ้ายึดติดกับ implementation แรกที่ LLM สร้างไว้ ก็อาจถูกผูกติดกับจุดอ้างอิงที่ผิดทั้งที่ยังเข้าใจปัญหาไม่ดีพอ

  • คิดว่าแค่ CSS นี่แหละที่ Vibe Coding น่าจะเอาอยู่

    • แต่อีกคนแย้งว่า ถ้าคำนึงถึงการเข้าถึงหรือresponsive design มันก็ไม่ได้ง่ายขนาดนั้น
    • CSS ที่ทำมาดีจริงๆ กลับยิ่งกระชับและดูแลง่าย
    • การยัด AI เข้ามาอาจกลับกลายเป็นตัวขัดขวางเสียมากกว่า
    • อีกคนหนึ่งบอกว่าเคยใช้ Claude สร้างเว็บยูทิลิตีขนาดเล็กได้ครบถ้วนทั้งตัว
    • บางคนยังเล่าว่าเคยสร้างsearch DSLบน React หรือGUI pipeline editorด้วยวิธีเดียวกัน และอธิบายว่าแนวทางนี้ไปไกลเกินกว่าระดับ CSS ง่ายๆ แล้ว