เมื่อผมเลิกเลือกระหว่าง Lovable และ Claude


นักพัฒนาส่วนใหญ่มักมองเรื่องนี้เป็นการเปรียบเทียบเครื่องมือ
ตอนแรกผมก็คิดแบบนั้นเหมือนกัน
“โปรเจกต์นี้ควรใช้ตัวไหนดี?”
แต่หลังจากที่ได้ลองสร้างผลงานจริงๆ ด้วยทั้งสองตัว คำถามนั้นก็เริ่มฟังดู… ไม่ค่อยเข้าท่าเท่าไหร่
เพราะมันไม่ใช่เรื่องของตัวเครื่องมือ
แต่มันคือเรื่องของ จังหวะ ที่คุณเลือกใช้มันต่างหาก
ผมเลือกใช้ Lovable เมื่อต้องการอะไรที่ใช้งานได้จริงและรวดเร็ว
ไอเดียในช่วงเริ่มต้นมักจะยังไม่เป็นรูปเป็นร่าง
คุณยังไม่รู้หรอกว่ามันจะเวิร์กไหม คุณแค่มีทิศทางคร่าวๆ ในหัว
ในจุดนั้น ผมไม่อยากมานั่งถกเถียงเรื่องโครงสร้างระบบ (Architecture)
ผมแค่ต้องการเห็นอะไรบางอย่างที่มันทำงานได้จริง
และนั่นคือสิ่งที่ผมใช้ Lovable
ผมแค่อธิบายสิ่งที่ต้องการ ปรับแต่งนิดหน่อย และทันใดนั้นผมก็มีตัวต้นแบบที่คลิกเล่นได้เลย
ตัวอย่างงานที่ผมมักจะใช้:
เครื่องมือที่ใช้ภายในองค์กร (Internal tools)
หน้า Admin dashboard
แอปพลิเคชันประเภท CRUD
MVPs
โปรเจกต์เสริมที่ผมยัง “ลองผิดลองถูกในหัว” อยู่
ในระยะนี้ ความเร็วคือเป้าหมายหลัก
แต่พอมันถึงจุดหนึ่ง ทุกอย่างจะเริ่มเปลี่ยนไป
และนี่คือส่วนที่ผมไม่ได้คาดคิดไว้ในช่วงแรก
โปรเจกต์มักจะเริ่มจากอะไรง่ายๆ:
ผู้ใช้สร้างข้อมูล, ผู้ใช้ดูข้อมูล, อาจจะมีขั้นตอนการทำงาน (Flow) สักสองสามอย่าง
แล้วมันก็ค่อยๆ เติบโตขึ้น
มีกฎเกณฑ์มากขึ้น มีกรณีพิเศษ (Edge cases) มากขึ้น มีคำถามประเภท “เดี๋ยวก่อนนะ แล้วถ้าเกิดว่า… ล่ะ?” โผล่มาเรื่อยๆ
และทันใดนั้น สิ่งที่เคยรู้สึกว่าทำได้เร็วก็เริ่มรู้สึกเปราะบาง
เหมือนกับว่าการแก้ไขแค่จุดเดียวกลับไปกระทบส่วนอื่นๆ มากเกินความจำเป็น
นั่นคือจุดที่ผมรู้ตัวว่าต้องเริ่มช้าลงหน่อยแล้ว
นั่นคือจุดที่ Claude เข้ามามีบทบาท
Claude ให้ความรู้สึกที่ไม่ใช่แค่เครื่องมือ “สร้างฟีเจอร์นี้ให้หน่อย”
แต่มันเหมือนกับใครสักคนที่กำลังมองดูระบบของคุณ แล้วตั้งคำถามที่เฉียบคมกว่าที่คุณคิดได้เอง
ผมใช้มันเมื่อทุกอย่างเริ่มซับซ้อนขึ้น:
ทำไมส่วนนี้ถึงเริ่มแก้ไขยากขึ้นเรื่อยๆ?
การออกแบบส่วนไหนที่กำลังทำให้เกิดปัญหา?
พอมันโตขึ้น มันจะไปพังตรงไหน?
มีโครงสร้างที่เรียบง่ายกว่านี้ซ่อนอยู่หรือเปล่า?
บ่อยครั้งผมแค่ก๊อปปี้โค้ดจริงๆ วางลงไป แล้วขอให้มันช่วยรีวิวแนวคิดเบื้องหลังให้หน่อย
ซึ่งมีประโยชน์มากสำหรับ:
ผลิตภัณฑ์ที่เน้นการใช้ AI เป็นหลัก
ระบบ Workflow ต่างๆ
ตรรกะการเทรด (Trading logic)
แอป SaaS ที่กำลังเติบโตอย่างรวดเร็ว
อะไรก็ตามที่ต้องอยู่รอดให้ได้เกินกว่าช่วง MVP
จุดเปลี่ยนที่ทำให้วิธีการสร้างงานของผมเปลี่ยนไป
ถึงจุดหนึ่งผมก็ได้เรียนรู้อะไรง่ายๆ อย่างหนึ่ง:
ที่ผมเคยติดขัด ไม่ใช่เพราะผมเลือกเครื่องมือผิด
แต่เป็นเพราะผมใช้เครื่องมือที่ใช่ ในเวลาที่ผิดต่างหาก
วิธีการทำงานของผมในตอนนี้
ผมไม่ได้ “เลือก” ระหว่างสองตัวนี้อีกต่อไปแล้ว
แต่ผมใช้มันตามลำดับขั้นตอน
ผมเริ่มด้วย Lovable เมื่อ:
ต้องการทดสอบไอเดีย (Validation) อย่างรวดเร็ว
ยังไม่แน่ใจด้วยซ้ำว่าไอเดียนี้คุ้มค่าที่จะสร้างจริงไหม
แค่อยากมีอะไรที่ใช้งานได้จริงไปโชว์ให้ผู้ใช้ดู
แล้วผมจะเปลี่ยนมาใช้ Claude เมื่อ:
ระบบเริ่มขยายใหญ่ขึ้น
การเปลี่ยนแปลงเริ่มส่งผลกระทบต่อหลายส่วน
ผมให้ความสำคัญกับโครงสร้าง (Structure) มากกว่าความเร็ว
กฎง่ายๆ ที่ผมยึดถือ
ถ้าอยากได้งานที่ใช้งานได้คืนนี้ → ใช้ Lovable
ถ้าอยากได้งานที่ไม่กลายเป็นโค้ดเน่าๆ เมื่อต้องขยายระบบ → ใช้ Claude
โปรเจกต์ส่วนใหญ่ในโลกความเป็นจริงมักจะคาบเกี่ยวอยู่ทั้งสองโลกนี้
แค่คนละช่วงเวลากันเท่านั้นเอง
บทความที่เกี่ยวข้อง

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


สร้างเอง หรือ ซื้อใช้? เมื่อสมการการตัดสินใจเปลี่ยนไป
คุณควรสร้างซอฟต์แวร์ขึ้นมาเองหรือซื้อ SaaS ดี? มาดูกันว่า AI เข้ามาเปลี่ยนจุดคุ้มทุนและวิธีคำนวณระหว่างการสร้างเอง (Build) เทียบกับการซื้อ (Buy) อย่างไร


ต้นทุนไม่ได้เป็นศูนย์
AI ช่วยให้การพัฒนาซอฟต์แวร์เร็วขึ้น แต่ไม่ใช่ของฟรี มาดูกันว่าทำไมงานวิศวกรรม สถาปัตยกรรม การประกันคุณภาพ (QA) และนักพัฒนาที่มีประสบการณ์ยังคงเป็นสิ่งจำเป็นในยุค AI

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