Vibe Coding คืออะไร: เขียนโปรแกรมด้วยการคุยกับ AI

ช่วงหลังเราได้ยินคำว่า "Vibe Coding" บ่อยมาก ทั้งในกลุ่มนักพัฒนาและคนที่ไม่เคยเขียนโปรแกรมมาก่อน บางคนบอกว่ามันคืออนาคตของการเขียนโปรแกรม บางคนบอกว่ามันคือการสร้างหนี้ทางเทคนิคแบบเร่งด่วน บทความนี้จะอธิบายว่า Vibe Coding คืออะไรจริง ๆ ต่างจากการเขียนโค้ดแบบที่เราคุ้นเคยอย่างไร มีข้อดีข้อเสียอะไร ใครควรใช้แบบไหน และจะพาดูวงจรการทำงานจริงตั้งแต่บอกความต้องการจนได้โปรแกรมที่รันได้ เพื่อให้คุณตัดสินใจได้เองว่าจะนำไปใช้กับงานของตัวเองแค่ไหน

Vibe Coding คืออะไร และคำนี้มาจากไหน

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

คำนี้เริ่มแพร่หลายเมื่อ Andrej Karpathy นักวิจัยด้าน AI ที่คนในวงการรู้จักดี เขียนโพสต์เล่าถึงการทำโปรเจกต์เล็ก ๆ โดยแทบไม่แตะโค้ดเอง แค่พูดหรือพิมพ์บอก AI แล้วยอมรับผลลัพธ์ไปตาม "vibe" หลังจากนั้นคำนี้ก็ถูกนำไปใช้กว้างขึ้น จนปัจจุบันหลายคนใช้เรียกการเขียนโปรแกรมด้วย AI แทบทุกรูปแบบ

เพื่อให้คุยกันเข้าใจตรงกัน ในซีรีส์นี้เราจะแยกสองแบบออกจากกัน

• Vibe Coding แบบเต็มตัว คือให้ AI เขียนเกือบทั้งหมด ผู้ใช้ดูแค่ผลลัพธ์ ไม่ได้อ่านหรือเข้าใจโค้ดละเอียด เหมาะกับงานทดลองหรืองานทิ้งได้
• AI-assisted development คือใช้ AI ช่วยเขียน แต่เรายังอ่าน review ทดสอบ และรับผิดชอบโค้ดทุกบรรทัดที่เข้าโปรเจกต์ นี่คือแบบที่เหมาะกับงานจริงที่มีผู้ใช้

ทั้งสองแบบใช้เครื่องมือเหมือนกัน ต่างกันที่ "ระดับความรับผิดชอบ" ของคนที่กดยอมรับโค้ด

ต่างจากการเขียนโค้ดเองอย่างไร

ถ้าเทียบกับวิธีที่เราคุ้นเคย การเขียนโค้ดเองคือเราคิดโครงสร้าง เลือก library เขียนทีละฟังก์ชัน และรู้ว่าทุกบรรทัดทำอะไร ส่วน Vibe Coding เปลี่ยนบทบาทเราจาก "คนพิมพ์โค้ด" ไปเป็น "คนกำหนดความต้องการและตรวจรับงาน"

ข้อสังเกตสำคัญคือ ทักษะพื้นฐานยังจำเป็นเหมือนเดิม คนที่เข้าใจ HTTP, SQL, การจัดการ session และความปลอดภัย จะสั่ง AI ได้แม่นกว่าและจับผิดได้เร็วกว่าคนที่ไม่รู้ AI ไม่ได้ทำให้ความรู้เหล่านี้หมดค่า แต่ทำให้มันกลายเป็นเครื่องมือตรวจสอบแทนเครื่องมือพิมพ์

วงจรการทำงาน: บอก → AI เขียน → รัน → ปรับ

ลองดูตัวอย่างจริง สมมติเราอยากได้สคริปต์ PHP เล็ก ๆ อ่านไฟล์ CSV รายชื่อลูกค้าแล้วสรุปยอดซื้อรวมรายจังหวัด

รอบที่ 1: บอกสิ่งที่ต้องการ

เขียนสคริปต์ PHP 8 แบบ CLI อ่านไฟล์ customers.csv (คอลัมน์ name, province, amount มี header แถวแรก) แล้วพิมพ์ยอด amount รวมของแต่ละจังหวัด เรียงจากมากไปน้อย ถ้าไฟล์ไม่มีให้แสดง error และ exit code 1

รอบที่ 2: AI เขียนโค้ด

ผลที่ได้อาจหน้าตาประมาณนี้

<?php
declare(strict_types=1);

$file = $argv[1] ?? 'customers.csv';
if (!is_readable($file)) {
    fwrite(STDERR, "ไม่พบไฟล์: {$file}\n");
    exit(1);
}

$handle = fopen($file, 'r');
$header = fgetcsv($handle);
$totals = [];

while (($row = fgetcsv($handle)) !== false) {
    $data = array_combine($header, $row);
    $province = trim($data['province']);
    $totals[$province] = ($totals[$province] ?? 0) + (float) $data['amount'];
}
fclose($handle);

arsort($totals);
foreach ($totals as $province => $sum) {
    printf("%-20s %12s\n", $province, number_format($sum, 2));
}

รอบที่ 3: รันและสังเกต

รัน php summary.php customers.csv แล้วพบว่าใช้ได้กับไฟล์ตัวอย่าง แต่พอเจอไฟล์จริงที่มีแถวว่างตอนท้าย สคริปต์ error เพราะ array_combine ได้ array ขนาดไม่เท่ากัน นี่คือจุดที่ "vibe" อย่างเดียวไม่พอ เราต้องรู้ว่าทดสอบด้วยข้อมูลจริงและข้อมูลผิดรูปแบบ

รอบที่ 4: ปรับ

ไฟล์จริงมีแถวว่างและบางแถวคอลัมน์ไม่ครบ ให้ข้ามแถวที่จำนวนคอลัมน์ไม่ตรง header และนับจำนวนแถวที่ข้ามแล้วพิมพ์ไว้ท้ายรายงาน ห้ามเปลี่ยนรูปแบบ output เดิม

สังเกตว่า prompt รอบหลังเจาะจงขึ้น บอกทั้งปัญหา สิ่งที่ต้องการ และสิ่งที่ห้ามเปลี่ยน วงจรนี้จะวนไปเรื่อย ๆ จนผลลัพธ์ผ่านเกณฑ์ที่เราตั้งไว้ ยิ่งเรากำหนดเกณฑ์ชัดเท่าไร จำนวนรอบก็ยิ่งน้อยลง

ข้อดีที่เห็นได้จริง

• เริ่มต้นเร็ว งาน prototype หรือ proof of concept ที่เคยใช้ครึ่งวัน อาจเหลือไม่กี่สิบนาที
• ลดงานซ้ำ ๆ เช่น เขียนฟอร์ม CRUD, แปลงข้อมูล, สคริปต์ย้ายไฟล์, boilerplate ของ framework
• เรียนรู้เรื่องใหม่ได้ไว ขอให้ AI เขียนตัวอย่างใน library ที่เราไม่เคยใช้ แล้วอ่านทำความเข้าใจ
• ทดลองไอเดียได้ถูก ลองหลายแนวทางแล้วทิ้งแนวที่ไม่เวิร์กได้โดยไม่เสียดาย
• เปิดโอกาสให้คนที่ไม่ใช่โปรแกรมเมอร์ สร้างเครื่องมือเล็ก ๆ ใช้เองได้ เช่น สคริปต์จัดการไฟล์ในสำนักงาน

ข้อเสียและความเสี่ยงที่ต้องรู้

• โค้ดที่ไม่มีใครเข้าใจ ถ้ารับโค้ดโดยไม่อ่าน วันที่ระบบพังจะไม่มีใครรู้ว่าต้องแก้ตรงไหน
• ช่องโหว่ความปลอดภัย AI อาจต่อ string เป็น SQL, ลืม escape output, ลืมตรวจสิทธิ์ หรือปิด CSRF เพื่อให้ฟอร์ม "ทำงานได้"
• Hallucination AI อาจเรียกฟังก์ชันหรือแพ็กเกจที่ไม่มีอยู่จริง หรือใช้ API ผิดเวอร์ชัน
• หนี้ทางเทคนิคสะสมเร็ว แก้ทีละจุดตามที่ AI เสนอโดยไม่มองภาพรวม ทำให้โครงสร้างโค้ดเละเร็วกว่าปกติ
• ความมั่นใจเกินจริง AI ตอบด้วยน้ำเสียงมั่นใจเสมอ แม้คำตอบจะผิด ทำให้เราลดการตรวจสอบโดยไม่รู้ตัว
• ข้อมูลรั่ว การแปะโค้ดที่มี API key หรือข้อมูลลูกค้าลงใน prompt คือการส่งข้อมูลออกนอกองค์กร

ความเสี่ยงเหล่านี้ไม่ได้แปลว่าห้ามใช้ แต่แปลว่าต้องมีกติกา ซึ่งเราจะลงรายละเอียดในบทความ "10 กติกาก่อนให้ AI เขียนโค้ดในโปรเจกต์จริง" และ "ช่องโหว่ที่พบบ่อยในโค้ดที่ AI สร้าง"

ใครเหมาะกับ Vibe Coding แบบไหน

งานที่ไม่ควร Vibe Coding แบบเต็มตัวเลย ได้แก่ ระบบการเงิน ระบบยืนยันตัวตน ระบบที่เก็บข้อมูลส่วนบุคคล และโค้ดที่ทีมต้องดูแลอีกหลายปี เพราะต้นทุนของความผิดพลาดสูงกว่าเวลาที่ประหยัดได้มาก

เริ่มต้นอย่างไรให้ได้ผล

1. เลือกงานเล็กที่ทิ้งได้ เช่น สคริปต์แปลงไฟล์ หรือหน้าเว็บ static
2. เขียนความต้องการเป็นข้อ ๆ ก่อนเปิด AI รวมถึงเกณฑ์ว่าแบบไหนถือว่า "เสร็จ"
3. ทำงานใน Git repository เสมอ commit ทุกครั้งที่ได้ผลที่ใช้ได้ จะได้ย้อนกลับง่าย
4. รันและทดสอบด้วยข้อมูลจริงและข้อมูลผิดรูปแบบทุกรอบ
5. ถาม AI ว่า "โค้ดนี้มีจุดไหนที่อาจผิดพลาดหรือไม่ปลอดภัย" แล้วตรวจคำตอบด้วยตัวเอง
6. ก่อนนำไปใช้จริง อ่านโค้ดทั้งหมดอย่างน้อยหนึ่งรอบ ถ้าอ่านไม่เข้าใจ ให้ AI อธิบายจนกว่าจะเข้าใจ

สรุป

• Vibe Coding คือการอธิบายสิ่งที่ต้องการให้ AI เขียนโค้ด แล้ววนรัน-ปรับจนได้ผล โดยเน้นผลลัพธ์มากกว่าการพิมพ์โค้ดเอง
• แยกให้ออกระหว่าง Vibe Coding เต็มตัว (งานทดลอง) กับ AI-assisted development (งานจริงที่เราอ่านและรับผิดชอบทุกบรรทัด)
• ข้อดีคือความเร็วและการเรียนรู้ ข้อเสียคือโค้ดที่ไม่มีใครเข้าใจ ช่องโหว่ และหนี้ทางเทคนิค
• ความรู้พื้นฐานด้านโปรแกรมและความปลอดภัยยังสำคัญ เพราะใช้ตรวจงานของ AI
• เริ่มจากงานเล็ก ใช้ Git และทดสอบด้วยข้อมูลจริงทุกรอบ

ลองทำ

เลือกงานเล็ก ๆ หนึ่งอย่างที่คุณทำซ้ำบ่อย เช่น เปลี่ยนชื่อไฟล์รูปในโฟลเดอร์ตามวันที่ หรือสรุปยอดจาก CSV แล้วลองทำตามวงจรในบทความนี้

1. เขียนความต้องการและเกณฑ์ "เสร็จ" ไม่เกิน 5 ข้อ ก่อนเปิด AI
2. ให้ AI เขียนโค้ดในรอบแรก แล้วรันกับข้อมูลจริง
3. จดว่าต้องวนแก้กี่รอบ และแต่ละรอบเกิดจากอะไร (ความต้องการไม่ชัด, AI เข้าใจผิด, ข้อมูลมีกรณีพิเศษ)
4. สุดท้ายอ่านโค้ดทั้งหมดและเขียนสรุปสั้น ๆ ว่าแต่ละส่วนทำอะไร ถ้าเขียนไม่ได้ แปลว่ายังไม่ควรนำโค้ดนี้ไปใช้งานจริง