Vibe coding: การใช้งานและข้อจำกัด

เปิดโอกาสให้คนสร้างซอฟต์แวร์

CTO ขององค์กรช่วยให้คนจำนวนมากขึ้นเปลี่ยนความรู้ของตนเป็นแนวคิดซอฟต์แวร์ได้ เชิญคนจากทีมการเงิน ปฏิบัติการ การขาย และวิศวกรรมมาเข้าร่วม จัดสรรเวลา ข้อมูลสังเคราะห์ sandbox API และความช่วยเหลือให้พวกเขา

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

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

ระบุสิ่งที่ต้องเรียนรู้

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

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

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

ต้นแบบแอปธนาคารที่สร้างในวันอังคาร

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

มีคนเสนอให้เชื่อมต่อบัญชีธนาคารของบริษัท ข้อเสนอนี้เปลี่ยนผลกระทบที่อาจเกิดขึ้น แม้แอปจะยังมีป้ายว่า “ต้นแบบ”

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

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

สำหรับ API ชำระเงิน idempotency หมายถึงการส่งคำขอซ้ำไม่ทำให้ผลที่ตั้งใจไว้เกิดซ้ำ Stripe อธิบายการนำหลักการนี้ไปใช้แบบหนึ่ง ตรวจสอบพฤติกรรม ข้อจำกัด และกฎ retry ของผู้ให้บริการที่ใช้งานจริง การ rollback แอปไม่ได้ย้อนรายการชำระเงินที่ธนาคารดำเนินการไปแล้ว

ตัวอย่างนี้ไม่ใช่หลักฐานว่ามีข้อบกพร่องใน Lovable แนวทางความปลอดภัยของ Lovable เอง ระบุให้ปกป้อง secret ตรวจสอบฝั่ง server ทดสอบนโยบายข้อมูล และทบทวนอย่างต่อเนื่อง ใช้มาตรฐานหลักฐานเดียวกันกับเครื่องมือสร้างแอป agent หรือแอปที่คนเขียนเองทุกตัว

ตรวจสอบสิทธิ์ก่อนเชื่อมต่อระบบจริง

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

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

ต้องตัดสินใจเรื่องเหล่านี้ก่อนนำข้อมูลลับหรือข้อมูลรับรองระบบจริงเข้าสู่ระบบ การรอจนถึงการออก release เข้า production อย่างเป็นทางการอาจช้าเกินไป เรียนต่อเรื่อง ขอบเขตข้อมูล และ โครงสร้างพื้นฐานองค์กร

กำหนดความรับผิดชอบก่อนขยายการใช้งาน

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

1. ระบุผู้รับผิดชอบ
2. ระบุผู้ใช้และข้อมูลที่อนุญาต
3. กำหนดวิธีตอบสนองเมื่อเกิดความผิดพลาด
4. เก็บ source code และ configuration ใน repository
5. ตรวจสอบว่าคนอื่นสามารถตรวจดูและสร้างระบบซ้ำได้

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

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

วางแผนรับมือช่องโหว่หลังจบ demo

Demo ที่สำเร็จอาจซ่อนช่องว่างสำคัญในการบำรุงรักษา อาจมีประกาศช่องโหว่ใหม่ของ dependency โดยที่โค้ดของคุณไม่เปลี่ยนเลย ผลสแกนตอนออก release อธิบายสถานะ ณ เวลาหนึ่งเท่านั้น

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

ตรวจสอบว่าเครื่องมือและ configuration ที่ใช้จริงมีอะไรให้บ้าง บทเรียน การจัดการช่องโหว่อย่างต่อเนื่อง จะอธิบายกระบวนการทั้งหมด รวมถึงการสแกนที่ล้มเหลวและเวอร์ชันที่ deploy แล้ว

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

มอบการเปลี่ยนแปลงเล็ก ๆ หนึ่งอย่างให้ agent พร้อมเกณฑ์การยอมรับที่ชัดเจน ระบุว่า agent ทำอะไรได้บ้าง ตรวจดู diff ที่ได้ ทำการตรวจสอบที่สามารถปฏิเสธการพัฒนาที่ไม่ถูกต้องได้ แยกการตัดสินใจ deploy ออกไว้จนกว่าความรับผิดชอบในการออก release จะชัดเจน

NIST Secure Software Development Framework อธิบายแนวปฏิบัติด้านการพัฒนาที่ปลอดภัยในขอบเขตกว้างขึ้น ใช้เป็นข้อมูลอ้างอิงเมื่อประเมินมาตรการควบคุมที่ยังขาด ไม่จำเป็นต้องท่องจำ framework แต่ต้องระบุหลักฐานที่ยังขาดก่อนซอฟต์แวร์จะส่งผลต่อคนอื่น