ปัญหาที่เกิดจากการเขียนโค้ดแบบ Vibe ซึ่งเราได้กล่าวถึงในบทความก่อนหน้านี้ มีความร้ายแรงมากพอที่จะเป็นสาเหตุของหายนะทางคอมพิวเตอร์ครั้งใหญ่ครั้งต่อไปได้ ถึงเวลาแล้วที่จะเปลี่ยนไปใช้การเขียนโปรแกรมโดยใช้ AI ช่วย ซึ่งเป็นวิธีการที่มืออาชีพกว่า (และมีความเสี่ยงน้อยกว่า) เหมาะอย่างยิ่งเมื่อคุณต้องการโปรแกรมในสถานการณ์ที่ต้องการความปลอดภัยและความเสถียร
ในบทความนี้ เราจะเริ่มต้นด้วยการ discussing ปัญหาที่พบบ่อยที่สุดเกี่ยวกับ vibe coding และเหตุผลว่าทำไม แม้จะมีผู้สนับสนุนบางรายกล่าวอ้างอย่างมากมาย แต่มันก็ไม่ได้เป็นการปฏิวัติอุตสาหกรรมครั้งใหม่แต่อย่างใด ในส่วนต่อไปนี้ เราจะอธิบายขั้นตอนการเปลี่ยนจากการเขียนโค้ดแบบใช้ความรู้สึก (vibe coding) ไปสู่การเขียนโปรแกรมโดยใช้ AI ช่วยเหลือในระบบลินุกซ์
ปัญหาของการเข้ารหัสความรู้สึก
ลองยกตัวอย่าง: คนสองคนไปร้านอาหารหรู คนหนึ่งไม่รู้เรื่องการทำอาหารเลย ส่วนอีกคนเป็นเชฟมืออาชีพ คนแรกรู้แค่ว่าตัวเองอยากกินอะไร และอย่างมากก็จะตัดสินคุณภาพของอาหารจากราคาหรือจากรสชาติที่ลิ้นของเขาบอก ส่วนคนที่สองจะสามารถแยกแยะได้ว่าใช้ส่วนผสมสดใหม่หรือไม่ เครื่องปรุงรสใช้ในปริมาณที่เหมาะสมหรือไม่ และเขาถูกคิดราคาเกินจริงหรือเปล่า
ไม่ใช่เรื่องบังเอิญที่เราเลือกใช้ร้านอาหารเป็นตัวอย่าง แอนเดรจ คาร์ปาธี ผู้เชี่ยวชาญด้านปัญญาประดิษฐ์ เป็นหนึ่งในผู้ร่วมก่อตั้ง OpenAI และดำรงตำแหน่งผู้อำนวยการฝ่ายปัญญาประดิษฐ์ของ Tesla ด้วยความต้องการที่จะแก้ปัญหาเรื่องไม่รู้จะสั่งอะไรดี เขาจึงสร้างแอปพลิเคชันโดยใช้การเขียนโค้ดแบบ Vibe เพื่อแสดงรูปภาพของอาหารแต่ละจาน นี่คือคำอธิบายประสบการณ์ของเขา:
"การสร้าง MenuGen ด้วย vibe coding นั้นสนุกดีในฐานะเดโมในเครื่อง แต่ค่อนข้างยากเมื่อทำเป็นแอปจริง การสร้างแอปสมัยใหม่ก็เหมือนกับการประกอบเฟอร์นิเจอร์ IKEA แห่งอนาคต: มีบริการ API การตั้งค่า ข้อจำกัด และราคามากมาย" ผู้ที่จบปริญญาโทด้านกฎหมายมักมีความรู้ที่ล้าสมัย ทำผิดพลาดอย่างแนบเนียน และมีอาการประสาทหลอน และที่ตลกก็คือ ผมแทบไม่ได้ใช้เวลาเขียนโค้ดเลย แต่ใช้เวลาไปกับการตั้งค่าบริการต่างๆ ในเบราว์เซอร์มากกว่า ทั้งหมดนี้แม้แต่ผู้ที่จบหลักสูตร LLM ก็ยังเข้าไม่ถึง แล้วเราจะทำให้ทุกอย่างเป็นระบบอัตโนมัติได้ภายในปี 2027 ได้อย่างไรกัน?
เรามาดูรายละเอียดเพิ่มเติมเกี่ยวกับสิ่งที่เกิดขึ้นกับอันเดรจกันดีกว่า ซึ่งเอาจริง ๆ แล้ว เขา... เขาไม่ใช่ผู้พัฒนาเว็บไซต์ ซึ่งอาจเป็นสาเหตุที่เขาทำให้เรื่องต่างๆ ซับซ้อนเกินความจำเป็น
“ฉันใช้ Cursor + Claude 3.7 ใส่คำอธิบายแอปเข้าไป แล้วมันก็เขียนส่วนประกอบฝั่ง frontend ทั้งหมดด้วย React อย่างรวดเร็ว สร้างเว็บไซต์ที่สวยงามด้วยฟอนต์หลากสีอ่อนๆ แอนิเมชั่น CSS เล็กๆ การออกแบบที่ตอบสนองต่อทุกอุปกรณ์ และอื่นๆ อีกมากมาย ยกเว้นฟังก์ชันการทำงานฝั่ง backend จริงๆ”
ในการออกแบบแอปพลิเคชันนั้น ส่วนหน้า (Frontend) และส่วนหลัง (Backend) เปรียบเสมือนเหรียญสองด้าน ส่วนหน้า (Frontend) คือส่วนที่ผู้ใช้โต้ตอบด้วย ในขณะที่ส่วนหลัง (Backend) คือส่วนที่ประมวลผลและจัดเก็บข้อมูล ส่วนหน้าทำงานบนเครื่องคอมพิวเตอร์ของผู้ใช้เอง ในขณะที่ส่วนหลังมักถูกพัฒนาบนเซิร์ฟเวอร์ภายนอก
อย่างน้อยในกลุ่มผู้ที่ชื่นชอบการเขียนโค้ดแบบ Vibe Coding นั้น Claude ถือเป็นภาษาสร้างแบบจำลองที่ยอดเยี่ยมที่สุดในขณะนี้ สาเหตุของเรื่องนี้เป็นเรื่องของอุดมการณ์มากกว่าเรื่องทางเทคนิค บริษัท Anthropic ซึ่งเป็นผู้พัฒนาเทคโนโลยีนี้ ขัดแย้งกับกระทรวงกลาโหมสหรัฐฯ เกี่ยวกับการนำแบบจำลองของบริษัทไปใช้ในกองทัพโดยไม่มีการควบคุมดูแล
Cursor คือโปรแกรมแก้ไขโค้ดที่ใช้โมเดลปัญญาประดิษฐ์ (AI) ที่ได้รับการพัฒนาแล้วมาเป็นผู้ช่วยในการเขียนโปรแกรม เราจะพูดถึงวิธีการติดตั้ง Cursor บน Linux ในภายหลัง
React เป็นไลบรารีสำหรับสร้างส่วนติดต่อผู้ใช้แบบกราฟิกแบบไดนามิก ฉันไม่คุ้นเคยกับแอปพลิเคชันนี้ ดังนั้นจึงไม่สามารถตัดสินได้ว่าการใช้ React นั้นเหมาะสมหรือไม่ แต่จากประสบการณ์ของฉันเองในการเขียนโค้ดด้วย Vibe โมเดลต่างๆ มักใช้ไลบรารีสำหรับสิ่งต่างๆ ที่สามารถทำได้ดีอย่างสมบูรณ์แบบด้วย HTML, CSS และ JavaScript เพียงอย่างเดียว
สิ่งที่ทำให้ Karpathy เริ่มซับซ้อนขึ้นคือส่วนของระบบเบื้องหลัง แอปพลิเคชันของพวกเขาเริ่มต้นด้วยการถ่ายภาพเมนูอาหาร แล้วใช้เทคโนโลยีการรู้จำอักษรด้วยแสง (Optical Character Recognition) เพื่อค้นหารายละเอียดเกี่ยวกับอาหารแต่ละจาน ลองมาดูคำอธิบายของพวกเขาว่าเกิดอะไรขึ้นบ้าง:
“ตรงนี้แหละที่เริ่มมีปัญหา ผมจำเป็นต้องเรียกใช้ API ของ OpenAI เพื่อทำการ OCR กับรายการเมนูจากภาพ ผมต้องขอรับคีย์ API และต้องเข้าไปใช้งานเมนูที่ค่อนข้างซับซ้อนเกี่ยวกับ “โปรเจกต์” และสิทธิ์การเข้าถึงโดยละเอียด” Claude รู้สึกประหลาดใจกับ API ที่เลิกใช้งานแล้ว ชื่อโมเดล และข้อกำหนดการรับ/ส่งข้อมูลที่เพิ่งเปลี่ยนแปลงไปเรื่องนี้ค่อนข้างสับสน แต่ก็แก้ไขได้หลังจากคัดลอกและวางเอกสารหลายครั้ง เมื่อการเรียกใช้ API ทำงานได้แล้ว ฉันก็พบกับข้อจำกัดด้านอัตราการใช้งานที่ค่อนข้างเข้มงวดทันที ซึ่งอนุญาตให้ฉันทำการเรียกใช้ได้เพียงไม่กี่ครั้งทุกๆ 10 นาทีเท่านั้น
นี่เป็นตัวอย่างคลาสสิกของแนวโน้มที่นางแบบมักใช้ปืนใหญ่เพื่อฆ่าแมลงวัน การจดจำภาพเมนูสามารถทำได้โดยใช้ไลบรารีภายในเครื่อง เช่น Tesseract.js
Tesseract.js พัฒนามาจากเครื่องมือชื่อเดียวกันของ Google และรองรับมากกว่า 100 ภาษา สามารถใช้งานได้อย่างราบรื่นจากเบราว์เซอร์ และที่สำคัญที่สุดคือ ไม่ใช้โทเค็น ไม่ต้องใช้คีย์ API และไม่มีข้อจำกัดใดๆ
น่าเสียดายที่ไม่มีวิธีแก้ไขปัญหาภาพหลอนที่เกิดจาก API ที่ล้าสมัยและการทำงานโดยใช้เอกสารประกอบที่ไม่ทันสมัย ยกเว้นการเรียนรู้การเขียนโปรแกรมและไม่ใช้เครื่องมืออัตโนมัติ
เขาประสบปัญหาคล้ายกันกับส่วนที่สองของแอปพลิเคชัน นั่นคือการแปลงคำอธิบายของแต่ละเมนูให้เป็นรูปภาพ
"ฉันลงทะเบียนและได้รับคีย์ API ของ Replicate แล้วก็พบปัญหาคล้ายๆ กัน การสืบค้นข้อมูลไม่ทำงานเนื่องจากความรู้ของ LLM ล้าสมัย และคราวนี้แม้แต่เอกสารอย่างเป็นทางการก็ยังล้าสมัยไปบ้างเนื่องจากการเปลี่ยนแปลง API ล่าสุด ซึ่งตอนนี้ไม่ได้ส่งคืนข้อมูล JSON โดยตรงอีกต่อไป แต่เป็นอ็อบเจ็กต์แบบสตรีมมิ่งที่ทั้งคลอดด์และผมไม่เข้าใจอย่างถ่องแท้ จากนั้นผมก็เจอปัญหาเรื่องข้อจำกัดการใช้งานอีกครั้ง ทำให้การแก้ไขข้อผิดพลาดทำได้ยาก ต่อมาผมได้รับแจ้งว่านี่เป็นมาตรการป้องกันการฉ้อโกงทั่วไป แต่ก็ทำให้การสร้างบัญชีใหม่ที่ถูกต้องตามกฎหมายทำได้ยากขึ้นด้วย ผมได้รับแจ้งว่า Replicate กำลังเปลี่ยนไปใช้โมเดลเครดิตแบบเติมเงิน ซึ่งอาจช่วยได้”
อันเดรจสามารถแก้ไขปัญหานี้ได้โดยไม่ต้องพึ่งโปรแกรมสร้างภาพ มีเครื่องมือหลายอย่างที่สามารถค้นหารูปภาพอาหารจริงได้ (โดยหลีกเลี่ยงภาพลวงตาที่อาจเกิดขึ้นจาก AI) หนึ่งในนั้นคือ API ฐานข้อมูลสูตรอาหารสองตัว ได้แก่ TheMealDB และ Spoonacular Food API
ปัญหาของเพื่อนเราที่เป็นนักเขียนโค้ด Vibe ยังไม่จบลงแค่นั้น เมื่ออัปโหลดแอปพลิเคชันไปยัง Vercel (แพลตฟอร์มที่อนุญาตให้ปรับใช้และโฮสต์แอปพลิเคชันจากที่เก็บข้อมูล GitHub) เกิดข้อผิดพลาดที่ไม่พบในเครื่องคอมพิวเตอร์ของตนเองใช้เวลาหนึ่งชั่วโมงกว่าจะรู้ว่าคีย์ API ยังไม่ได้ถูกอัปโหลดไปยังเซิร์ฟเวอร์ โปรแกรมเมอร์ที่มีประสบการณ์คงจะรู้และประหยัดค่าใช้จ่ายเรื่องโทเค็นไปได้
แนวคิดของผู้เขียนคือการคิดค่าบริการสำหรับการใช้งานแอปพลิเคชัน (ผมสงสัยว่าใครจะยอมจ่ายเงินสำหรับสิ่งที่พวกเขาสามารถใช้ได้ฟรีโดยการถาม Gemini หรือ Siri) เพื่อการนี้ เขาจึงต้องการการยืนยันตัวตนผู้ใช้ ตามคำแนะนำของ Claude Karpathy จึงหันไปใช้แพลตฟอร์มบนคลาวด์อีกตัวหนึ่งที่เรียกว่า Clerk Clerk จัดการทุกอย่างที่จำเป็นสำหรับการลงทะเบียนและการเข้าถึง ผมไม่มีข้อโต้แย้งใดๆ ต่อการตัดสินใจนี้
ปัญหาคือว่า Claude เขียนโค้ดสำหรับเวอร์ชันที่เลิกใช้งานแล้วของ Clerk API และลืมบอกเขาว่าหากเขาต้องการใช้งานในระบบจริง เขาจำเป็นต้องมีโดเมนของตัวเองด้วย ไม่ใช่เวอร์ชันฟรีที่ Vercel ให้มา เขาต้องซื้อและตั้งค่าเอง
นอกจากนี้ยังมีปัญหาแทรกซ้อนในการตั้งค่าแพลตฟอร์มการชำระเงิน เมื่อเขาสามารถส่งระบบไปใช้งานได้จริงในที่สุด เขาก็พบว่า:
“การประมวลผลทั้งหมดเป็นแบบเรียลไทม์ โดยไม่มีการบันทึกข้อมูล หากใช้เวลานานเกินไปก็จะล้มเหลว หากคุณรีเฟรชข้อมูล คุณก็จะสูญเสียทุกอย่าง วิธีแก้ปัญหาที่ถูกต้องคือการใช้ฐานข้อมูลร่วมกับระบบจัดคิว แต่หมายความว่าต้องใช้บริการเพิ่มเติม (เช่น Supabase, Upstash) และมีความซับซ้อนมากขึ้น มากเกินไป ผมจึงปล่อยมันไว้สำหรับอนาคต”
จริงๆ แล้ว วิธีแก้ปัญหาคือเรียนรู้การเขียนโปรแกรม หรือจ้างผู้ที่มีความรู้ความสามารถมาทำ ในบทความถัดไป เราจะเริ่มดูขั้นตอนในการทำอย่างแรกกัน
