Vibe coding หลังจากฮันนีมูน

Vibe coding เป็นหนึ่งในสำนวนที่ดูเหมือนเกิดมาเพื่อถูกเกลียด และต่อมาก็มีประโยชน์อย่างช้าๆ

ตอนแรกเสียงประมาณว่า ไม่คิด ถาม AI ยอมรับสิ่งที่ออกมา ทำต่อไป วิธีที่ร่าเริงในการสร้างหนี้ทางเทคนิคโดยมีพื้นฐานทางดนตรี

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

ขั้นแรกคุณมีความคิดแล้วจึงปีนขึ้นไปไกล ตอนนี้คุณมักจะครุ่นคิด และครึ่งชั่วโมงต่อมาก็มีบางอย่างเคลื่อนไหวบนหน้าจอ มันยากที่จะไม่ถูกล่อลวงโดยมัน

คำถามที่น่าสนใจในปี 2569 ไม่ใช่ว่า Vibe Coding เป็นจริงหรือไม่ มันคือ. คำถามคือจะเกิดอะไรขึ้นหลังฮันนีมูน?

ต้นแบบมีความประหยัดแล้ว

นี่คือส่วนที่สำคัญที่สุด

เครื่องมือ AI ช่วยลดต้นทุนทางอารมณ์ในการเริ่มต้น ก่อนหน้านี้ หากคุณต้องการลองไอเดีย คุณต้องลงมือก่อน: เลือกสแต็ก สร้างโปรเจ็กต์ จำต้นแบบ เขียนเลย์เอาต์ เชื่อมต่อ API ทะเลาะกับรายละเอียดที่น่าเบื่อ

ตอนนี้คุณสามารถพูดได้ว่า: ขอเวอร์ชันแรกให้ฉันหน่อย

และเวอร์ชั่นแรกก็มาถึง

ไม่ได้สวยงามเสมอไป ไม่ถูกต้องเสมอไป มักจะเปราะบาง แต่มันก็มา และเมื่อมาถึงก็เปลี่ยนบทสนทนา คุณไม่ทะเลาะกันในสุญญากาศอีกต่อไป คุณกำลังสัมผัสอะไรบางอย่าง

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

การเขียนโค้ดของ Vibe ถือเป็นเรื่องฮือฮาเพราะมันทำให้ผู้คนจำนวนมากขึ้นได้สัมผัสถึงความรู้สึกทางกายภาพของซอฟต์แวร์ที่ถูกสร้างขึ้น

ปัญหาคือซอฟต์แวร์ใช้งานได้อยู่

ส่วนที่เมมบอกน้อยที่สุดคือวันถัดมา

ต้องอ่านต้นแบบ ถูกต้อง. ผ่านการทดสอบแล้ว ปรับใช้แล้ว ปลอดภัย. ได้มาจากคนอื่น.. เชื่อมต่อกับข้อมูลจริง ทำให้สามารถเข้าถึงได้ ได้รับการดูแลเมื่อการพึ่งพาเปลี่ยนแปลง

ที่นี่การเข้ารหัสกลิ่นอายที่แท้จริงกระทบผนัง

โมเดลสามารถสร้างโค้ดจำนวนมากได้อย่างรวดเร็ว แต่โค้ดไม่ได้มีคุณค่าในตัวเอง เป็นสัญญาแห่งพฤติกรรม และคำสัญญาจะต้องได้รับการตรวจสอบ

ความเสี่ยงของการเขียนโค้ดแบบ Vibe ไม่ใช่การเขียนโค้ดที่น่าเกลียด เราทำมันมาตลอดแม้ไม่มี AI ความเสี่ยงคือการสูญเสียความรู้สึกเป็นเจ้าของ: "แบบจำลองที่ทำ" กลายเป็นข้อแก้ตัวสำหรับการไม่เข้าใจมากพอ

แต่รันไทม์ไม่ยอมรับข้อแก้ตัว หากโค้ดทำงานจริง รหัสนั้นเป็นของคุณ

จากการเขียนโค้ดแบบ Vibe ไปจนถึงวิศวกรรมตัวแทน

Vibe Coding เวอร์ชันผู้ใหญ่ไม่ได้หยุดใช้ตัวแทน มันคือการใช้วงจรที่รุนแรงมากขึ้น

ไม่ใช่: มันสร้างทุกสิ่งและเราหวัง

แต่:

1. บรรยายถึงเจตนา;
2. ให้สร้างแบบร่าง
3. ขอให้ตัวแทนอธิบายแผน
4. สร้างความแตกต่างเล็กน้อย
5. การทดสอบการเปิดตัว
6. ทำการวิจารณ์;
7. ถูกต้อง;
8. จากนั้นจึงเข้าร่วม

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

ประเด็นคือไม่ต้องใช้พลังงานไปจากการเขียนโค้ดแบบ Vibe มันทำให้เธอติดตาม

มันใช้งานได้ดีที่ไหน

การเข้ารหัส Vibe จะทำงานเมื่อต้นทุนของข้อผิดพลาดต่ำและมูลค่าของการสำรวจสูง

ตัวอย่าง:

• ต้นแบบอินเทอร์เฟซ
• เครื่องมือส่วนตัว
• แดชบอร์ดภายใน
• เกมเล็ก ๆ
• สคริปต์ครั้งเดียว
• การสแกน API;
• การพิสูจน์แนวคิด
• รีแฟกเตอร์เชิงกลพร้อมการทดสอบที่ดี
• เนื้อหาทางเทคนิคที่จะแปลงเป็นการสาธิต

ในกรณีเหล่านี้ความเร็วคือประเด็น คุณต้องการดูว่าแนวคิดนั้นมีขาหรือไม่ คุณต้องการค้นหาสิ่งที่คุณไม่เข้าใจ คุณต้องการสนทนาที่เป็นรูปธรรม

การเข้ารหัส Vibe เหมาะอย่างยิ่งสำหรับการสร้างแบบฟอร์ม

##ไปไหนก็อันตราย.

มันจะเป็นอันตรายเมื่อระบบมีผลกระทบและไม่มีใครทำงานช้าลง

การชำระเงิน ข้อมูลส่วนบุคคล การรับรองความถูกต้อง การอนุญาต โครงสร้างพื้นฐาน การย้ายฐานข้อมูล รหัสดั้งเดิมที่ละเอียดอ่อน การปฏิบัติตามข้อกำหนด การผลิต ที่นี่บรรยากาศไม่เพียงพอ เราต้องการความเข้มงวด

ไม่ได้หมายความว่า AI ช่วยไม่ได้ จริงๆแล้วมันสามารถช่วยได้มาก แต่จะต้องทำงานภายในขอบเขตที่แคบ: แบรนช์, แซนด์บ็อกซ์, การทดสอบ, lint, การตรวจทาน, แฟล็กคุณลักษณะ, การย้อนกลับ

วลีที่จะสักบนจอภาพนั้นง่าย: ยิ่งตัวแทนเร็วเท่าไหร่ กระบวนการก็ต้องอ่านได้มากขึ้นเท่านั้น

หากคุณอธิบายไม่ได้ว่ามีอะไรเปลี่ยนแปลง แสดงว่าคุณไม่ได้เร่งความเร็ว คุณเพิ่งเปลี่ยนหนี้จากเวลามาเป็นความเข้าใจ

บทบาทใหม่ของนักพัฒนา

ส่วนที่น่าสนใจที่สุดคืองานของนักพัฒนาไม่ได้หายไปไหน เปลี่ยนความหนาแน่น

ใช้เวลาน้อยลงในการวางแบบสำเร็จรูป มีเวลามากขึ้นในความตั้งใจ การสลายตัว การทบทวน การบูรณาการ การทดสอบ และขอบเขต

นักพัฒนาซอฟต์แวร์จะกลายเป็นบรรณาธิการด้านเทคนิคประเภทหนึ่ง ไม่ได้อยู่ในความรู้สึกง่อยของ "การพิสูจน์อักษร" ในแง่ที่แข็งแกร่ง: มันตัดสินใจว่าอะไรต้องมีอยู่ อะไรต้องตัด อะไรสอดคล้องกับระบบ อะไรสมควรได้รับความไว้วางใจ

บรรณาธิการที่ดีไม่ได้ยึดถือทุกสิ่งที่พวกเขาได้รับ เขาไม่ได้เขียนซ้ำทั้งหมดด้วยความภาคภูมิใจ รับรู้ถึงเนื้อหาดีๆ นำมาเป็นรูปธรรม ปกป้องผู้อ่าน

เมื่อใช้ตัวแทน ผู้อ่านก็จะเป็นผู้ดูแลในอนาคตเช่นกัน บ่อยครั้งนั่นคือคุณในสามสัปดาห์

รูปแบบที่ฉันเห็นกำลังเกิดขึ้น

รูปแบบที่ดีต่อสุขภาพที่สุดคือ:

• มนุษย์: ความตั้งใจ ข้อจำกัด รสชาติ ความรับผิดชอบ
• ตัวแทน: ตัวแปร, นั่งร้าน, การค้นหา, การปรับเปลี่ยนในพื้นที่, การทดสอบซ้ำ;
• โครงสร้างพื้นฐาน: แซนด์บ็อกซ์, CI, การติดตาม, การอนุญาต, การปรับใช้;
• ทีมงาน : ทบทวน ความเป็นเจ้าของ มาตรฐาน

เมื่อชิ้นส่วนใดชิ้นหนึ่งหายไป บางสิ่งบางอย่างก็จะผิดรูปไป

มนุษย์เท่านั้น: เชื่องช้า มักจมอยู่กับการทำงานซ้ำๆ

ตัวแทนเท่านั้น: รวดเร็ว แต่ไม่มีการตัดสิน

โครงสร้างพื้นฐานเพียงอย่างเดียว: กระบวนการที่หรูหราสำหรับการผลิตสิ่งที่ไร้ประโยชน์

เฉพาะทีม: การประชุมอย่างเป็นระเบียบเกี่ยวกับต้นแบบที่ไม่เคยมาถึง

สิ่งที่ดีที่สุดเกิดขึ้นเมื่อชิ้นส่วนพูดคุยกัน

รายการตรวจสอบเล็กๆ น้อยๆ

ก่อนที่จะปล่อยให้ต้นแบบที่มีรหัสความรู้สึกเติบโต ฉันจะถามตัวเองด้วยคำถามเหล่านี้:

• ฉันเข้าใจโครงสร้างของโค้ดหรือไม่?
• มีการทดสอบพฤติกรรมวิกฤตหรือไม่?
• ฉันรู้หรือไม่ว่าเจ้าหน้าที่สัมผัสไฟล์ใดบ้าง
• ฉันได้ลบโค้ดที่สร้างขึ้นแต่ไม่ได้ใช้หรือไม่?
• มีความลับ โทเค็น หรือข้อมูลปลอมที่จบลงผิดที่หรือไม่?
• การเข้าถึงขั้นต่ำเป็นไปตามนั้นหรือไม่?
• การใช้งานมีการย้อนกลับหรือไม่
• ใครนอกจากฉันจะเก็บมันไว้ได้ไหม?

ถ้าคำตอบคือไม่สำหรับคำถามมากเกินไป ก็ไม่ใช่ความล้มเหลว มันเป็นเพียงต้นแบบที่ต้องคงความเป็นต้นแบบไว้อีกสักหน่อย

การอ่านของฉัน

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

ฉันไม่อยากทิ้งมันไป นั่นคงจะเป็นเรื่องน่ารังเกียจ สิ่งดีๆ มากมายเกิดมาแบบนี้ กึ่งคดโกง และมีชีวิตชีวา

แต่ซอฟต์แวร์ที่เหลือยังต้องการมากกว่านี้ มันต้องการความเข้าใจ การทดสอบ ความเป็นเจ้าของ โครงสร้างพื้นฐาน และขอบเขต มันต้องการใครสักคนที่จะพูดว่า: เจ๋ง ตอนนี้เรามาทำให้มันเป็นจริงกันเถอะ

บางทีอนาคตอาจไม่เกี่ยวกับการเลือกระหว่างการเขียนโปรแกรมแบบ "จริงจัง" และการเขียนโปรแกรม "บรรยากาศ" บางทีอาจเป็นการเรียนรู้ที่จะเปลี่ยนเกียร์: สำรวจแบบสบายๆ แล้วรวบรวมสติด้วยความเคารพ

ส่วนของมนุษย์อยู่ที่นั่น รู้ว่าเมื่อใดควรวิ่งและเมื่อใดควรนั่งอ่านความแตกต่าง

แหล่งที่มา

• Simon Willison: การเขียนโปรแกรมที่ใช้ AI เพียงอย่างเดียวไม่ใช่การเข้ารหัสแบบ Vibe
• OpenAI: ผู้คนใช้งาน ChatGPT อย่างไร
• บล็อก GitHub: ตัวแทนการเข้ารหัส GitHub Copilot
• มานุษยวิทยา: การสร้างตัวแทนที่มีประสิทธิภาพ
• บล็อก Stack Overflow: ทำไมการเขียนโค้ด Vibe จึงเป็นอนาคต