ยิ่ง AI เร็ว เรายิ่งต้องคิดให้เล็กลง

มีเพื่อนคนหนึ่งถามผมว่า ถ้าเป็น non coder หรือ non dev จะ vibe coding ยังไงให้ไม่เปลือง token และงานออกมาดี

ผมกลับมานั่งคิดเรื่องนี้อยู่พักหนึ่ง

เพราะถ้าเป็น developer คำตอบหนึ่งอาจเป็นเรื่องการอ่าน code การแตก task การดู diff การ review สิ่งที่ AI แก้ให้

แต่สำหรับคนที่ไม่ได้เขียน code อยู่แล้ว เขาไม่ได้อ่าน code

และเอาจริงๆ AI วันนี้ก็ฉลาดพอจนหลายงานไม่จำเป็นต้องเริ่มจากการอ่าน code แบบละเอียดเหมือนเดิม

คนกลุ่มนี้ส่วนใหญ่ไม่ได้อยากสร้าง software เพื่อเป็น developer

เขาอยากสร้าง tool ที่ช่วยงานใน domain ที่เขาเข้าใจอยู่แล้ว

งาน finance

งาน legal

งานลงทุน

งาน trading

งาน operation บางอย่างที่เขาทำซ้ำทุกวัน

ตรงนี้น่าสนใจ เพราะความรู้ที่สำคัญที่สุดของเขาอาจไม่ใช่ code

แต่เป็นความเข้าใจในงานจริง

เขารู้ว่า input คืออะไร

เขารู้ว่า decision สำคัญอยู่ตรงไหน

เขารู้ว่าคำนวณผิดตรงไหนแล้วจะพัง

เขารู้ว่าคนใช้จริงจะกดอะไร งงตรงไหน และต้องเห็นข้อมูลแบบไหนถึงจะตัดสินใจได้

สิ่งนี้ AI ไม่มี ถ้าเขาไม่บอกมันดีพอ

ปัญหาไม่ใช่ไม่รู้ code อย่างเดียว

ผมเริ่มรู้สึกว่า ปัญหาของคนที่ vibe coding แล้วงานออกมาไม่ดี อาจไม่ใช่แค่เขาไม่รู้ code

แต่เป็นเพราะเขาเริ่มจากภาพที่ใหญ่เกินไป

เขาอยากได้ทั้งแอปในครั้งเดียว

มี login

มี dashboard

มี form

มี report

มี export

มี user หลาย role

มี logic การคำนวณ

มีหน้าตาสวยๆ

มีทุกอย่างตั้งแต่ prompt แรก

พอโยนทั้งหมดให้ AI ทำทีเดียว สิ่งที่ได้มักจะกว้าง แต่ไม่ลึก

เหมือนมีทุกหน้า แต่แต่ละหน้าขาดอะไรบางอย่าง

logic ยังไม่แน่น

UI กดได้บางจุด

บาง feature ดูเหมือนมี แต่ใช้จริงไม่ได้

แล้วพอเริ่มสั่งแก้ ปัญหาจะหนักขึ้น

เพราะ codebase ใหญ่ขึ้นแล้ว

AI ต้องอ่านหลายไฟล์มากขึ้น

context เริ่มเต็ม

จะแก้ feature เดียว อาจไปกระทบอีก feature หนึ่ง

สุดท้าย token ที่คิดว่าจะประหยัด กลับหมดไปกับการแก้สิ่งที่ควรจะยังไม่ถูกสร้างตั้งแต่แรก

คนที่ไม่อ่าน code ต้องมีอะไรให้กด

สำหรับ non coder วิธี test งานไม่ใช่การอ่าน code

วิธี test คือการกดใช้

สิ่งสำคัญมากคือ ต้องมี UI ให้กดตั้งแต่ต้น

ไม่ต้องสวย

ไม่ต้องครบ

แต่ต้องมีหน้าที่ทำให้เราทดสอบความคิดได้

ถ้ากำลังทำ calculator บางอย่าง ต้องมีช่องให้ใส่ตัวเลข กดคำนวณ แล้วเห็นผลลัพธ์

ถ้ากำลังทำ dashboard ต้องมีข้อมูลตัวอย่าง แล้วเห็นว่า chart หรือ table ตอบคำถามที่อยากตอบจริงไหม

ถ้ากำลังทำ tool ช่วย review เอกสาร ต้องมีที่ใส่ข้อความ กดวิเคราะห์ แล้วอ่านผลที่ออกมาได้

คนที่ไม่อ่าน code ต้องเอาประสบการณ์ของตัวเองไปตรวจผ่าน UI

กดแล้วถามว่า ใช่ไหม

ตัวเลขถูกไหม

flow นี้ตรงกับงานจริงไหม

ถ้าคนใน domain นี้มาใช้ เขาจะเข้าใจไหม

คำถามพวกนี้สำคัญกว่า code สวยหรือไม่สวยในช่วงแรกมาก

Agile ในวันที่ loop สั้นลงมาก

คำตอบที่ผมคิดได้ กลับเป็นเรื่องเก่ามากของคนทำ software

Agile

ไม่ใช่ในความหมายพิธีกรรมของบริษัท

ไม่ใช่ sprint planning ที่ต้องมี meeting เยอะๆ

แต่เป็น mindset ง่ายๆ ว่า ทำทีละส่วน ทดสอบ แล้วค่อยปรับ

plan

implement

reflect

แล้วกลับไป plan ใหม่

เมื่อก่อน iteration หนึ่งอาจกินเวลา 2 สัปดาห์

ทีมต้องคุยกัน เลือก story ทำ feature เขียน code test deploy แล้วกลับมาดูผล

แต่พอมี AI loop นี้สั้นลงมาก

บางครั้งหนึ่งรอบอาจเหลือไม่กี่นาที

บางครั้งอาจเป็นหนึ่งชั่วโมง

เราวางแผน feature เล็กๆ ให้ AI ทำ

ลองกด

เห็นว่ามันผิดตรงไหน

กลับไปแก้ prompt

ให้มันปรับ

แล้วกดใหม่

สิ่งที่เปลี่ยนคือความเร็ว

แต่สิ่งที่ไม่เปลี่ยนคือ เรายังต้องคิดเป็นรอบอยู่ดี

เริ่มจากหน้า index ก็พอ

ถ้าเป็น tool ที่มีหลาย feature ผมคิดว่าไม่ควรเริ่มจากการให้ AI สร้างทั้งแอป

เริ่มจากหน้า index ธรรมดาก็พอ

หน้านี้มีชื่อ tool

มีคำอธิบายสั้นๆ

มีปุ่มไป feature แรก

แค่นั้นพอแล้ว

แล้วค่อยเลือก feature ที่สำคัญที่สุดขึ้นมาทำก่อน

feature แรกควรเป็นแกนหลักของ tool

ไม่ใช่ feature เสริม

ถ้า tool นี้เกิดมาเพื่อช่วยคำนวณอะไรบางอย่าง ก็ทำ flow คำนวณนั้นก่อน

ถ้าเกิดมาเพื่อช่วยตัดสินใจ ก็ทำ flow ที่ทำให้ตัดสินใจได้ก่อน

ถ้าเกิดมาเพื่อสรุปข้อมูล ก็ทำ flow ที่รับข้อมูลแล้วสรุปให้ได้ก่อน

ทำฐานของ feature นั้นให้กดได้ก่อน

แล้วค่อย iterate

เพิ่ม field

แก้สูตร

ปรับข้อความ

เพิ่ม validation

ทำผลลัพธ์ให้อ่านง่ายขึ้น

เพิ่ม chart ถ้าจำเป็น

เพิ่ม export ทีหลัง ถ้ามันจำเป็นจริงๆ

พอ feature นี้ใช้ได้จริง ค่อยกลับมาที่หน้า index แล้วเพิ่มปุ่มไป feature ต่อไป

หรือเพิ่ม tab dashboard ที่เอาข้อมูลจาก feature แรกมาแสดง

ทำแบบนี้ไปทีละก้อน

แอปจะค่อยๆ โตขึ้นจากของที่ test แล้ว ไม่ใช่โตขึ้นจากจินตนาการก้อนใหญ่ที่ยังไม่มีใครกดใช้

plan ไม่ได้ทำให้ช้า

หลายคนอาจรู้สึกว่า plan ทำให้ช้า

โดยเฉพาะในยุคที่ AI ทำอะไรให้เร็วมาก

แต่ผมกลับรู้สึกว่า plan คือสิ่งที่ทำให้ไม่เปลือง

เพราะ prompt ที่ใหญ่เกินไป ไม่ได้แปลว่าประหยัดกว่า

สั่งครั้งเดียวให้ทำทั้งแอป อาจดูเหมือนเร็ว

แต่ถ้าสิ่งที่ออกมาผิดทั้งโครง การแก้ทีหลังจะแพงมาก

แพงในที่นี้ไม่ใช่แค่เงินค่า token

แต่แพงด้วยเวลา

แพงด้วยความสับสน

แพงด้วยความรู้สึกว่า AI ทำไมทำไม่ได้สักที

ทั้งที่บางครั้งปัญหาไม่ได้อยู่ที่ AI

แต่อยู่ที่เราให้มันทำหลายเรื่องเกินไปในครั้งเดียว

plan ที่ดีสำหรับ vibe coding อาจไม่ต้องยาว

แค่เขียนให้ชัดว่า รอบนี้จะทำอะไร

feature นี้ต้องรับ input อะไร

ต้องคำนวณหรือประมวลผลอะไร

ผลลัพธ์ควรออกมาแบบไหน

เราจะกด test ยังไง

อะไรที่ยังไม่ทำในรอบนี้

ข้อสุดท้ายสำคัญมาก

อะไรที่ยังไม่ทำในรอบนี้

เพราะถ้าไม่เขียนไว้ AI มักจะช่วยคิดต่อให้เอง

บางครั้งมันช่วยดี

บางครั้งมันสร้างของเกินจำเป็น แล้วเราต้องเสียเวลาตามลบทีหลัง

domain expert ยังสำคัญมาก

ผมคิดว่า non coder มีข้อได้เปรียบบางอย่างที่ developer อาจไม่มี

เขาอยู่กับปัญหาจริง

เขารู้ detail ของงานจริง

เขารู้ว่ากฎบางอย่างในตำราใช้ไม่ได้กับสถานการณ์จริง

เขารู้ว่า edge case ไหนสำคัญ และ edge case ไหนไม่ต้องสนใจตอนนี้

ถ้าเขาเอาความรู้นี้มาใช้กับ AI ได้ดี เขาอาจสร้าง tool ที่มีประโยชน์มาก

ไม่ใช่เพราะเขาเขียน code เก่ง

แต่เพราะเขารู้ว่าของที่ดีใน domain นั้นควรทำงานยังไง

สิ่งที่ต้องเรียนเพิ่มจึงอาจไม่ใช่ syntax ของภาษา programming ก่อน

แต่อาจเป็นวิธีคิดของ product software

แตกของใหญ่ให้เล็ก

ทำทีละ feature

มี UI ให้ test

กดใช้จริง

reflect จากสิ่งที่เห็น

แล้วค่อยไปต่อ

ที่ผมอยากตอบเพื่อนคนนั้น

ถ้าจะ vibe coding ให้ไม่เปลือง token และงานออกมาดี โดยเฉพาะถ้าไม่ได้อ่าน code

อย่าเริ่มจากทั้งแอป

เริ่มจาก loop เล็กๆ

plan ให้ชัดว่า feature นี้คืออะไร

ให้ AI implement เฉพาะก้อนนั้น

กดใช้ผ่าน UI

reflect ว่ามันตรงกับงานจริงไหม

แก้จน feature นั้นใช้ได้

แล้วค่อยขึ้น feature ใหม่

AI ทำให้การสร้าง software เร็วขึ้นมาก

แต่ความเร็วไม่ได้แปลว่าเราควรคิดทีเดียวทั้งแอป

ยิ่ง AI เร็วเท่าไร ผมยิ่งรู้สึกว่าเราต้องแบ่งงานให้เล็กลงเท่านั้น

เพราะถ้า loop เล็กพอ เราจะเห็นความผิดเร็ว

แก้ถูกจุดเร็ว

และไม่ต้องเผา token ไปกับการแก้ความสับสนที่เราสร้างไว้ตั้งแต่ต้น