คุณไม่ได้ขาดความสามารถ คุณแค่ยังไม่ได้จัดการความซับซ้อน
คุณเคยใช้ AI สร้างของขึ้นมาได้จริง มันทำงาน คุณรู้สึกเก่งขึ้นมาเลย แล้วคุณแก้นิดเดียว มันพัง คุณค้าง บทนี้อธิบายว่าทำไมมันถึงเหวี่ยงจากของเทพเป็นหายนะ และทำไมช่องว่างตรงนั้นไม่ใช่ "คุณเขียนโค้ดไม่เป็น" แต่เป็นเรื่องการจัดการความซับซ้อน ที่เรียนรู้ได้
คุณไม่ได้ขาดความสามารถ คุณแค่ยังไม่ได้จัดการความซับซ้อน
คุณเคยลองใช้ AI สร้างของขึ้นมาสักอย่าง อาจเป็นเว็บเล็ก ๆ หน้าเดียว คุณพิมพ์บอกมันว่าอยากได้อะไร มันก็เขียนออกมาให้ กดรัน แล้วมันทำงานได้จริง ของที่คุณคิดในหัวปรากฏขึ้นบนจอตรงหน้า คุณรู้สึกเหมือนเพิ่งปลดล็อกพลังบางอย่าง ทั้งที่เมื่อกี้คุณยังไม่รู้เลยว่าจะเริ่มยังไง
แล้วคุณก็แก้อะไรนิดเดียว เปลี่ยนสีปุ่ม ขยับข้อความ เพิ่มฟีเจอร์เล็ก ๆ อีกอัน กดรันอีกที คราวนี้มันพัง หน้าจอขึ้นแดง หรือไม่ก็ขาวโพลน ของที่เพิ่งทำงานได้เมื่อกี้หายไปหมด คุณนั่งมองมันแล้วค้าง ไม่รู้ว่าตัวเองทำอะไรผิด ไม่รู้ว่าจะถอยกลับยังไง ความรู้สึกเก่งเมื่อกี้กลายเป็นความรู้สึกว่า "เรื่องนี้มันไม่ใช่ของเรา"
ความเหวี่ยงจากของเทพเป็นหายนะในไม่กี่นาทีนั้น ไม่ได้แปลว่าคุณไม่มีหัวด้านนี้ มันมีคำอธิบายที่ชัดเจน และพอคุณเข้าใจมัน ทั้งหมดจะเปลี่ยนวิธีที่คุณมอง "การสร้างซอฟต์แวร์" ไปเลย
💡 ใจความสำคัญ: ตัวอย่างเล็ก ๆ ที่คุณสร้างมัน "ทำงาน" เพราะมีคุณคนเดียวใช้ ใช้แบบที่มันคาดไว้พอดี ในวันที่คุณยังจำทุกอย่างได้ ของจริงในโลกที่คนใช้เยอะ ใช้แบบแปลก ๆ และคุณในอีกหกเดือนข้างหน้าที่ลืมหมดแล้ว เป็นคนละปัญหากันโดยสิ้นเชิง ช่องว่างตรงนั้นไม่ใช่ "เขียนโค้ดไม่เป็น" แต่คือ "ยังจัดการความซับซ้อนไม่เป็น" และอันหลังเรียนรู้ได้
บทนี้คือบานพับของ Section 5 ทั้ง Section แบ่งเป็นสองครึ่ง ครึ่งแรกที่คุณเพิ่งอ่านจบไป คือพื้นฐาน เรารู้จักเครื่องมือทีละชิ้น ตั้งแต่ build loop ที่คุณคุยกับ AI (บท 5.1) ส่วนประกอบของเว็บแอป (บท 5.2) ไฟล์กับ repo (บท 5.3) git (บท 5.4) terminal (บท 5.5) เครื่องคุณกับ localhost (บท 5.6) ไปจนถึงการ deploy (บท 5.7) ตอนนี้คุณรู้แล้วว่าเครื่องตรงหน้าคุณมีอะไรบ้าง ปัญหาที่เหลือไม่ใช่การพิมพ์ มันคือการจัดการ ครึ่งหลังที่กำลังจะเริ่มจากบทนี้ไป คือวินัย คือชุดวิธีคิดที่ทำให้ของที่คุณสร้างไม่พังคามือ และบทนี้คือจุดที่อธิบายว่าทำไมวินัยพวกนั้นถึงจำเป็น
ของที่ "ทำงานได้" บนเครื่องคุณ ยังไม่ใช่ของจริง
ก่อนอื่นต้องแยกสองคำที่คนมักคิดว่าเป็นเรื่องเดียวกัน ระหว่าง "มันรันได้" กับ "มันใช้ได้จริง"
ตอนคุณกดรันแล้วเว็บโผล่มาบนเครื่องคุณ สิ่งที่เกิดขึ้นคือ มีคุณคนเดียวเปิดมัน คุณกดปุ่มตามลำดับที่คุณตั้งใจไว้ คุณกรอกข้อมูลแบบที่มันออกแบบมาให้กรอก และคุณทำตอนที่เพิ่งสร้างเสร็จ ยังจำได้ทุกอย่างว่าอะไรอยู่ตรงไหน ในเงื่อนไขที่สมบูรณ์แบบแบบนั้น แทบทุกอย่างจะดูทำงานได้
คำว่าของจริง คือสิ่งที่ บท 5.7 เรียกว่า production สถานะที่ของมันออกไปอยู่บนอินเทอร์เน็ตให้คนอื่นใช้จริง ไม่ใช่บนเครื่องคุณคนเดียวอีกต่อไป มีคนเข้ามาใช้ที่คุณไม่รู้จัก เข้ามาพร้อมกันหลายคน กดอะไรก็ได้ที่เขาอยากกด และมันต้องทำงานได้แม้ในวันที่คุณไม่อยู่ตรงนั้นคอยดู
ระยะห่างระหว่างสองอย่างนี้ใหญ่กว่าที่เกือบทุกคนคิด และมันคือต้นตอของความเหวี่ยงที่คุณเจอ
ทำไมของที่ทำงานได้ ถึงพังตอนเอาไปใช้จริง
ของที่รันได้บนเครื่องคุณ พังตอนเอาออกไปข้างนอก ด้วยเหตุผลที่จับต้องได้สามข้อ ไม่ใช่เพราะคุณดวงไม่ดี
ข้อหนึ่ง คนเดียว เทียบกับ คนเยอะพร้อมกัน ตอนทดสอบมีคุณคนเดียวกดทีละอย่าง ของจริงมีคนเข้ามาพร้อมกันสิบคน ร้อยคน บางคนกดปุ่มเดียวกันในวินาทีเดียวกัน บางคนเปิดทิ้งไว้ครึ่งวันแล้วค่อยกดต่อ สิ่งที่ไม่เคยมีปัญหาตอนมีคนเดียว เริ่มชนกันเองตอนมีคนเยอะ
ข้อสอง ทางที่คุณตั้งใจให้เดิน เทียบกับ ทางที่คนจริงเดิน ตอนคุณทดสอบ คุณเดินตามทางที่คุณวางไว้ กรอกชื่อในช่องชื่อ กรอกเบอร์ในช่องเบอร์ กดถัดไปตามลำดับ ทางเส้นนี้เรียกว่าทางที่ทุกอย่างเป็นไปตามคาด แต่คนจริงไม่ได้เดินตามทางนั้นเสมอ เขาเว้นช่องว่างไว้ เขาวางเบอร์โทรในช่องอีเมล เขากดปุ่มย้อนกลับกลางคัน เขาวางข้อความยาวห้าพันตัวอักษรในช่องที่คุณคิดว่าจะมีคนพิมพ์แค่ชื่อ ทุกกรณีแปลก ๆ ที่คุณไม่ได้นึกถึง คือสิ่งที่ของต้องรับมือให้ได้
ข้อสาม คุณวันนี้ เทียบกับ คุณอีกหกเดือน วันนี้คุณเพิ่งสร้างเสร็จ คุณจำได้ว่าทำไมตรงนี้ถึงเขียนแบบนี้ ตรงนั้นห้ามแตะเพราะอะไร อีกหกเดือนคุณกลับมาแก้ คุณลืมหมดแล้ว มองโค้ดของตัวเองเหมือนของคนแปลกหน้า แตะอะไรนิดเดียวก็เสี่ยงไปโดนสิ่งที่คุณลืมไปแล้วว่ามันเชื่อมกันอยู่
สามข้อนี้รวมกันคือสิ่งที่เรียกมันสั้น ๆ ว่า "90% ที่มองไม่เห็น" ตอนคุณสร้างของให้ทำงานได้หนึ่งรอบในเงื่อนไขที่ดีที่สุด คุณทำเสร็จไปแค่ส่วนที่มองเห็น อีก 90% ที่เหลือคือทุกกรณีที่ผิดไปจากนั้น คนเยอะ อินพุตแปลก ๆ และเวลาที่ผ่านไป งานส่วนนั้นมองไม่เห็นตอนที่มันยังไม่พัง แต่มันคืองานส่วนใหญ่จริง ๆ ของการทำของให้ใช้ได้จริง
เปรียบเทียบให้เห็นภาพ: ทำกับข้าวจานเดียว กับ เปิดร้านรับ 500 คน
ลองคิดถึงคนที่ทำกับข้าวเก่งที่บ้าน ทำผัดกะเพราจานหนึ่งให้คนในครอบครัวกิน อร่อยมาก ทุกคนชม เขาแก้ปัญหา "ทำกะเพราให้อร่อย" ได้เรียบร้อย จบ
ทีนี้ให้คนคนเดียวกันนี้ไปเปิดร้าน รับลูกค้า 500 คนในชั่วโมงเร่งช่วงเที่ยง ทันใดนั้นมันกลายเป็นคนละปัญหากันเลย ออเดอร์เข้าพร้อมกันยี่สิบโต๊ะ ของในครัวหมดกลางคัน ลูกค้าคนหนึ่งแพ้กุ้ง อีกคนขอไม่ใส่พริก เด็กเสิร์ฟลาป่วยกะทันหัน เตาแก๊สดับตอนไฟแลบ ฝีมือทำกะเพราเท่าเดิมไม่ได้ช่วยอะไรเลยในนาทีนั้น สิ่งที่ต้องมีคือการจัดคิว การเตรียมของล่วงหน้า การรับมือเมื่อมีอะไรพัง การจัดการคน
นั่นคือความต่างระหว่างของที่ทำงานได้บนเครื่องคุณ กับของที่อยู่ใน production การทำกะเพราจานเดียวให้อร่อยคือ "มันรันได้" การเปิดร้านรับ 500 คนคือ "มันใช้ได้จริง" และงานส่วนใหญ่อยู่ที่อย่างหลัง ซึ่งมองไม่เห็นตอนที่คุณทำจานเดียวอยู่ที่บ้าน
จุดที่การเปรียบเทียบนี้ใช้ไม่ได้ และต้องระวัง คือในร้านอาหาร "ความวุ่น" มาจากคนเยอะเป็นหลัก แต่ในซอฟต์แวร์ ความพังไม่จำเป็นต้องมาจากคนเยอะ ลูกค้าคนเดียวที่กรอกข้อมูลแปลก ๆ แค่คนเดียว ก็ทำของพังทั้งระบบได้ เหมือนมีลูกค้าเดินเข้าร้านมาคนเดียว แต่สั่งเมนูที่ทำให้ครัวทั้งครัวหยุดทำงาน นั่นเป็นเรื่องที่ร้านอาหารจริงไม่เจอ แต่ซอฟต์แวร์เจอประจำ
ช่องว่างที่แท้จริง ไม่ใช่ "เขียนโค้ดไม่เป็น"
ตรงนี้คือหัวใจของทั้งบท ทั้งหมดที่เล่ามา ลองสังเกตว่าไม่มีข้อไหนเลยที่เกี่ยวกับ "เขียนโค้ดเป็นหรือเปล่า"
คนเยอะพร้อมกัน อินพุตแปลก ๆ ตัวคุณเองที่ลืม ของที่เชื่อมกันจนแตะตรงนี้ไปกระทบตรงโน้น ทั้งหมดนี้คือปัญหาเดียวกันที่ฐานราก คือ ไม่มีใคร ไม่ว่าคนหรือ AI ที่ถือทั้งระบบใหญ่ ๆ ไว้ในหัวได้พร้อมกันทั้งหมด สมองคนรับไหวทีละไม่กี่อย่าง พอของซับซ้อนขึ้น มีชิ้นส่วนที่เชื่อมโยงกันมากขึ้น มันเกินที่หัวใครจะถือไหว และเมื่อคุณถือทั้งระบบในหัวไม่ได้ คุณก็มองไม่เห็นว่าการแก้ตรงนี้จะไปทำพังตรงไหน
ชุดของวิธีการที่คนคิดค้นขึ้นมาเพื่อรับมือกับปัญหา "ของมันใหญ่เกินกว่าจะถือไว้ในหัว" นี่แหละ คือสิ่งที่เรียกว่า engineering หรือวิศวกรรมซอฟต์แวร์ หลายคนเข้าใจว่า engineering คือการเขียนโค้ดเก่ง ๆ จริง ๆ แล้วการพิมพ์โค้ดเป็นแค่เปลือกนอก แก่นของมันคือเทคนิคในการจัดการความซับซ้อน วิธีถอยกลับเมื่อพัง วิธีแก้ทีละนิดให้รู้ว่าอะไรทำพัง วิธีจดบันทึกไว้ให้ตัวเองในอนาคตอ่าน วิธีดมกลิ่นอันตรายก่อนแตะของเสี่ยง ทั้งหมดนี้คือเครื่องมือทางความคิด ไม่ใช่ทักษะการพิมพ์
แล้ว AI มาเกี่ยวตรงไหน ตรงนี้คือข่าวดี ตอนคุณ vibe code อย่างที่ บท 5.1 วางพื้นไว้ AI ได้ยกงานส่วน "การพิมพ์โค้ด" ออกไปจากคุณฟรี ๆ ส่วนที่เคยกั้นคนทั่วไปออกจากการสร้างซอฟต์แวร์มาตลอด คือการต้องเรียนภาษาโปรแกรม ถูก AI จัดการให้แล้ว
แต่ AI ไม่ได้ยกงานอีกส่วนออกไปด้วย คือส่วน "การจัดการ" AI เขียนโค้ดให้ได้ก็จริง แต่มันก็ถือทั้งระบบใหญ่ไว้ในหัวไม่ได้เหมือนกัน มันลืมสิ่งที่คุยกันเมื่อสิบนาทีก่อนได้ มันแก้ตรงนี้แล้วเผลอทำพังตรงโน้นได้ มันไม่รู้ว่าอันไหนในระบบของคุณที่อันตรายห้ามแตะ เพราะมันไม่ได้ถือภาพรวมไว้ คนที่ต้องถือภาพรวม ตัดสินใจว่าจะแก้อะไร ตรวจว่าของยังดีอยู่ไหม และรู้ว่าตรงไหนเสี่ยง คือคุณ
💡 ใจความสำคัญ: AI ยกการพิมพ์โค้ดออกไปให้คุณฟรี แต่ไม่ได้ยกการจัดการความซับซ้อนออกไปด้วย และการจัดการนั่นแหละคือแก่นจริงของ engineering มันเป็นเรื่องของแนวคิดและวิธีคิด ไม่ใช่ไวยากรณ์ของภาษาโปรแกรม เพราะฉะนั้นมันเรียนรู้ได้ โดยไม่ต้องเขียนโค้ดเป็น
สามขั้นของคนที่ใช้ AI สร้างของ
พอเข้าใจว่าช่องว่างคือ "การจัดการ" ไม่ใช่ "การพิมพ์" เราจะวางตัวเองได้บนเส้นทางที่ชัดเจน คนที่ใช้ AI สร้างซอฟต์แวร์มีอยู่สามขั้น และความต่างระหว่างขั้นไม่ใช่ "เขียนโค้ดเก่งแค่ไหน" แต่คือ "จัดการความซับซ้อนได้ดีแค่ไหน"
ขั้นที่หนึ่ง Prompter หน้าตาในทางปฏิบัติคือ สั่งรวดเดียวห้าอย่าง แล้วลุ้น คือคนที่พิมพ์บอก AI ให้สร้างของ แล้วภาวนาให้มันทำงาน สร้างแล้วลุ้น พังแล้วงง ไม่รู้จะถอยกลับยังไง ไม่รู้ว่าอะไรทำพัง แก้หลายอย่างพร้อมกันจนสาวไม่ออกว่าตัวไหนเป็นต้นเหตุ นี่คือจุดที่เกือบทุกคนเริ่ม และคือจุดที่คุณยืนอยู่ตอนที่หน้าจอขึ้นแดงแล้วคุณค้าง มันไม่ใช่เรื่องน่าอาย มันคือจุดเริ่ม
ขั้นที่สอง Operator หน้าตาในทางปฏิบัติคือ commit ก่อนแตะ แก้ทีละอย่าง มีไฟล์ความจำ คือคนที่มีจุดเซฟ ก่อนแตะอะไรเขาเซฟสถานะที่ใช้ได้ไว้ก่อน พังเมื่อไหร่ถอยกลับมาจุดเซฟได้ทันที เขาแก้ทีละอย่าง ไม่แก้รวด ๆ ทำให้รู้เสมอว่าการเปลี่ยนไหนทำให้เกิดอะไร และเขาจดบันทึกความจำไว้นอกหัว เป็นไฟล์ที่เขากับ AI กลับมาอ่านได้ ไม่ฝากทุกอย่างไว้กับความจำตัวเองหรือความจำของ AI ที่ลืมง่าย
ขั้นที่สาม Architect หน้าตาในทางปฏิบัติคือ ดมกลิ่นเขตแดงได้ก่อนแตะ รู้ว่าเช่าตรงไหน คือคนที่ถือภาพรวมทั้งระบบและประวัติของมันไว้ในมือ รู้ว่าอะไรเชื่อมกับอะไร แตะตรงนี้แล้วจะกระทบตรงไหนบ้าง ดมกลิ่นอันตรายได้ก่อนลงมือ รู้ว่างานไหนเสี่ยงเกินกว่าจะเสี่ยง และที่สำคัญ รู้ว่าเพดานของวิธีนี้อยู่ตรงไหน ของแบบไหนที่ vibe code ไหว ของแบบไหนที่ควรไปยืนบนแพลตฟอร์มที่คนอื่นสร้างไว้แล้ว หรือควรเรียกคนที่เชี่ยวชาญมาช่วย
ครึ่งหลังของ Section 5 นี้ คือการพาคุณเดินจาก Prompter ขึ้นไป ทักษะของ Operator และ Architect ที่ว่ามาทั้งหมด เราจะแกะออกมาสอนทีละอย่างในบทถัด ๆ ไป การถอยกลับเมื่อพังอยู่ใน บท 5.10 การแก้ทีละนิดอยู่ใน บท 5.11 การทดสอบก่อนปล่อยของจริงอยู่ใน บท 5.12 การจดความจำไว้นอกหัวอยู่ใน บท 5.13 ไปจนถึงการรู้เพดานของตัวเองใน บท 5.19 คุณไม่ต้องจำชื่อบทพวกนี้ตอนนี้ แค่รู้ว่าทุกขั้นที่ขาด มีบทที่สอนมันอยู่
เคลียร์สามความเข้าใจผิดก่อนไปต่อ
ก่อนปิดบท มีสามความเชื่อที่ทำให้คนไม่กล้าเริ่ม และทั้งสามผิด
ความเชื่อแรก "vibe code มันไปถึง production ไม่ได้หรอก เอาไว้ทำเล่น ๆ" ผิด สิ่งที่ตัดสินว่า vibe code ไปถึงของจริงได้ไหม ไม่ใช่ตำแหน่งงานของคุณ แต่คือ ความเสี่ยงของงานนั้น คูณกับ ความซับซ้อนของมัน เว็บให้คนอ่านเนื้อหากับเก็บข้อมูลผู้ใช้ทั่วไป ความเสี่ยงต่ำ vibe code ไปถึงได้สบาย ระบบโอนเงินของธนาคาร ความเสี่ยงสูงมาก คนละเรื่องกัน เรื่องนี้ไม่เกี่ยวกับว่าคุณเป็นโปรแกรมเมอร์หรือเปล่า
ความเชื่อที่สอง "ฉันต้องไปเรียนเขียนโค้ดก่อน ถึงจะทำของจริงได้" ผิด สิ่งที่คุณต้องเรียนคือการจัดการความซับซ้อน ไม่ใช่ไวยากรณ์ของภาษาโปรแกรม การพิมพ์โค้ด AI ทำให้แล้ว สิ่งที่ยังเหลือให้คุณเรียนคือส่วนแนวคิด ซึ่งเป็นคนละเรื่องกับการนั่งท่องคำสั่ง
ความเชื่อที่สาม "ใช้ AI ก็คือ AI ทำให้หมดสิ" ผิด AI ทำการพิมพ์ให้ แต่การตัดสินใจยังเป็นของคุณ จะแก้อะไร อะไรเสี่ยงเกินไป ของยังดีอยู่ไหม เมื่อไหร่ควรถอย ทั้งหมดนี้ AI ตัดสินแทนคุณไม่ได้ เพราะมันไม่ได้ถือภาพรวมและไม่ได้แบกผลลัพธ์ คนที่ถือและแบกคือคุณ
หลักฐานว่ามันทำได้จริง
ทั้งหมดนี้ไม่ใช่ทฤษฎี เว็บที่คุณกำลังอ่านอยู่ตอนนี้ คือ "AI ภาษาคน" เป็นของจริงที่อยู่บน production แล้ว มันรันอยู่ที่ aipasakon.com มีคนเข้ามาใช้จริง สมัครเข้าระบบได้ด้วยอีเมลหรือบัญชี Google มีหน้า dashboard ที่จำได้ว่าคุณบันทึกบทไหนไว้ อ่านจบบทไหนแล้ว ทั้งหมดนี้ทำงานอยู่จริง ๆ บนอินเทอร์เน็ต ไม่ใช่ของทดลองบนเครื่องคนเดียว
คนที่สร้างมันขึ้นมา ไม่ใช่โปรแกรมเมอร์ เป็นผู้บริหารสายธุรกิจคนหนึ่งที่ไม่ได้เรียนเขียนโค้ดมา เขาสร้างเว็บนี้ขึ้นมาด้วยการพิมพ์บอก AI ล้วน ๆ และเขาทำได้ ไม่ใช่เพราะอยู่ ๆ เขาเขียนโค้ดเป็น แต่เพราะเขาเรียนรู้ที่จะจัดการความซับซ้อน เขาไม่ได้สร้างระบบล็อกอินเองตั้งแต่ศูนย์ เขาไปยืนบนแพลตฟอร์มที่มีคนทำเรื่องนั้นไว้ให้ดีแล้ว เขาทดสอบของบนเครื่องตัวเองก่อนเสมอ ไม่เอาของเสี่ยงขึ้นของจริงตรง ๆ และเขาเก็บจุดเซฟไว้ก่อนทำอะไรที่ถอยกลับยาก ทั้งหมดนี้คือทักษะของ Operator และ Architect ที่บทนี้เพิ่งวางภาพไว้ และที่บทถัด ๆ ไปจะสอนคุณทีละอย่าง
นี่คือเดิมพันของทั้ง Section นี้ คือคนที่ไม่ได้เขียนโค้ดเป็น ถ้าได้เครื่องมือพื้นฐานในครึ่งแรกครบ บวกกับวินัยจัดการความซับซ้อนในครึ่งหลัง ก็สร้างของที่อยู่บน production ได้จริง ไม่ใช่แค่ของเล่นบนเครื่องตัวเอง เว็บที่คุณกำลังอ่านอยู่นี่คือหลักฐานว่าเดิมพันนั้นจ่ายจริง
คุณยืนอยู่ตรงจุดที่เขาเคยยืน ตอนหน้าจอขึ้นแดงแล้วเขาก็เคยค้างเหมือนกัน ความต่างไม่ได้อยู่ที่พรสวรรค์ แต่อยู่ที่ชุดวิธีการที่เขาค่อย ๆ เก็บมา และวิธีการพวกนั้นเรียนรู้ได้ ทั้งหมดอยู่ในบทถัด ๆ ไปของ Section นี้
อ่านต่อ: จุดเซฟ ทำไมการถอยกลับได้คือกฎข้อแรก