Claude ไม่ใช่สถาปนิกของคุณ อย่าปล่อยให้มันทำเหมือนเป็น
(hollandtech.net)- ข้อเสนอด้านสถาปัตยกรรมจาก AI agent มักลื่นไหลและฟังดูน่าเชื่อถือ แต่จริง ๆ แล้วใกล้เคียงกับการประกอบรูปแบบจากข้อมูลฝึกมากกว่าการตัดสินใจอย่างแท้จริง
- Claude มักเห็นด้วยกับไอเดียได้ง่ายและขยายแบบออกไป แต่ไม่สามารถทำหน้าที่ “ไม่” และ “ทำไม?” ซึ่งเป็นสิ่งจำเป็นของสถาปนิกที่ดีได้เพียงพอ
- แพตเทิร์นที่คุ้นเคยอย่าง event-driven, CQRS, service mesh ก็อาจไม่สอดคล้องกับ ข้อจำกัดในโลกจริง เช่น ความพร้อมของทีม กฎระเบียบ หรือระบบ legacy
- สถาปัตยกรรมและ Jira ticket ที่ Claude สร้างขึ้นผลักวิศวกรให้กลายเป็นเพียง ผู้ลงมือทำตาม ticket และนำไปสู่การตัดสินใจที่ไม่มีความรับผิดชอบซึ่งข้ามการถกเถียงและการทบทวน
- บทบาทที่ถูกต้องคือมนุษย์ต้องเป็นผู้ออกแบบโดยอิงจากบริบทและ trade-off ส่วน AI เป็น เครื่องมือช่วย ที่ทำให้การลงมือสร้างตามแบบนั้นเร็วขึ้น
ปัญหาเมื่อ AI agent ทำตัวเหมือนเป็นสถาปนิก
- ทันทีที่ถาม AI agent อย่าง Claude, ChatGPT, Copilot ว่า “ควรสร้างอะไร” ก็มักเกิดกระบวนการที่มันเห็นด้วยกับไอเดีย เสนอสถาปัตยกรรม และวาดคอมโพเนนต์ออกมา
- คำตอบฟังดูคล่องแคล่ว มั่นใจ และเหมือนวิศวกรอาวุโสที่คิดมาอย่างลึกซึ้ง แต่ในความเป็นจริงมันใกล้เคียงกับการตอบตาม รูปแบบในข้อมูลฝึก มากกว่าผลลัพธ์จากการคิดแก้ปัญหา
- ยิ่งผลลัพธ์ดูน่าเชื่อถือมากเท่าไร การโต้แย้งก็ยิ่งน้อยลง และในไม่ช้า Claude ก็กลายเป็นผู้รับ บทบาทสถาปนิก โดยพฤตินัย
ปัญหาของการคอยบอกว่า “ดี”
- AI agent มักสร้างแบบที่มองในเชิงบวกได้ง่าย ไม่ว่าจะถามว่าไอเดียนี้ดีไหม ทีม 3 คนเหมาะกับ microservices หรือไม่ หรือควรสร้าง custom ML pipeline แทน managed service หรือเปล่า
- ไม่ได้แปลว่านี่เป็นคำตอบเท็จหรือผิดเสมอไป แต่ก็ไม่สามารถทดแทนความสามารถสำคัญของสถาปนิกที่ดีอย่างการ พูดว่า “ไม่” ได้อย่างเหมาะสม
- คุณค่าของสถาปนิกที่ดีไม่ได้อยู่แค่การออกแบบระบบ
- มองออกว่าระบบแบบไหนไม่ควรสร้าง
- เบรกความซับซ้อนที่ไม่จำเป็น
- ถามว่า “ทำไม?” ไปเรื่อย ๆ จนกว่าความต้องการที่แท้จริงจะชัดเจน
- ต่อให้ CTO จะกลับมาพร้อมไอเดียจากงานคอนเฟอเรนซ์ ก็ต้องกล้าบอกว่าเป็นทางเลือกที่ไม่ดีถ้ามันไม่เหมาะกับทีมจริง
- Claude ถูกฝึกมาให้ช่วยเหลือ และความช่วยเหลือนั้นมักกลายเป็นการเห็นด้วยและให้กำลังใจ ซึ่งท้ายที่สุดอาจนำไปสู่ สถาปัตยกรรมแบบหอคอย Jenga
สถาปัตยกรรมแบบหอคอย Jenga
- สถาปัตยกรรมที่ AI ออกแบบมักดูสมเหตุสมผลในเชิงเทคนิคเมื่อมองภายนอก
- แต่ละคอมโพเนนต์ดูเข้าท่า มีแพตเทิร์นคุ้นเคยอย่าง event-driven, CQRS, service mesh ปรากฏอยู่ และอาจดูเหมือนงานที่สถาปนิกอาวุโสสร้างขึ้น
- แต่แบบนั้นอาจไม่ได้ถูกปรับให้เข้ากับความจริงอันน่าเบื่อของทีม ข้อจำกัด และสภาพแวดล้อมการปฏิบัติงานจริง
- การล็อกอยู่ใน VPC
- การเชื่อมต่อกับระบบ legacy
- ทีมที่ไม่เคยรัน Kubernetes ใน production
- ข้อกำหนดด้าน compliance ที่ทำให้ใช้ managed service ได้แค่ครึ่งเดียว
- แบบที่ AI สร้างขึ้นอาจเป็นเพียง best practice ทั่วไป ที่ใกล้เคียงค่ากลางของทุกอย่างที่ Claude เคยเห็น และแบบสำหรับปัญหาทั่วไปของบริษัททั่วไปก็ลงท้ายด้วยการไม่เหมาะกับทีมเฉพาะนั้น
- สถาปัตยกรรมจริงประกอบด้วย trade-off ที่มีความหมายได้ก็เฉพาะภายใต้บริบทเท่านั้น
- ถ้าทีมรู้จัก Postgres และการปล่อยของภายใน 2 สัปดาห์ดีกว่าการใช้เวลา 1 เดือนเรียน data model ใหม่ ก็เลือก Postgres แทน DynamoDB
- ถ้ามี 4 services ไม่ใช่ 40 ก็ข้าม service mesh ไป
- ถ้าปัญหาง่าย ก็เลือก monolith แทน microservices
- การตัดสินใจแบบนี้ต้องอาศัยวิจารณญาณ ความเข้าใจทีม และความเข้าใจข้อจำกัดจริงขององค์กร
- AI agent ไม่มีบริบทเหล่านี้ และยังไม่รู้ด้วยซ้ำว่าตัวเองไม่มีบริบทนั้น
Jira ticket pipeline
- หลังจาก Claude ออกแบบสถาปัตยกรรมแล้ว หากให้มันแตกงานต่อ ก็จะสร้าง epic, story, acceptance criteria ออกมาอย่างเรียบร้อยและน่าเชื่อถือ
- ผลลัพธ์นี้อยู่ในรูปที่โยนเข้า Jira ได้ทันที และวิศวกรก็กลายเป็นคนที่ไม่ได้แก้ปัญหา แต่เป็นคนที่ลงมือทำแบบของ Claude ทีละ ticket
- วิศวกรที่เข้าใจโดเมน รู้ปัญหาซ่อนอยู่ในระบบ และสั่งสมทักษะมานาน ถูกย่อบทบาทลงเหลือแค่ ผู้ลงมือทำตาม ticket
- โครงสร้างจึงกลายเป็นว่า คนที่มีบริบท ประสบการณ์ และความรับผิดชอบมากที่สุดไม่ได้เป็นผู้ตัดสินใจ ขณะที่สิ่งที่ไม่มีบริบท ไม่มีประสบการณ์ และไม่มีความรับผิดชอบกลับเป็นผู้ตัดสินใจด้านสถาปัตยกรรม
- นี่ไม่ใช่แค่ความไม่มีประสิทธิภาพ แต่เป็นโครงสร้างที่กลับหัวกลับหางตั้งแต่ทิศทาง
ตรรกะป้องกันแบบ “รุ่นพี่ตรวจแล้ว”
- ข้ออ้างที่พบบ่อยคือ “Claude เสนอแนวทาง แต่มีวิศวกรอาวุโสตรวจทานแล้ว”
- ในสถานการณ์ตรวจทานจริง tech lead ที่งานยุ่งจะได้รับข้อเสนอสถาปัตยกรรมที่จัดมาดี
- มีตรรกะสอดคล้องกัน
- ใช้คำศัพท์เหมาะสม
- ครอบคลุมความต้องการที่ระบุไว้
- แม้แต่ไดอะแกรมก็ดูน่าเชื่อถือ
- ดูเหมือนผลลัพธ์ที่ตัวเองก็อาจออกแบบแบบนี้
- ในสถานการณ์แบบนี้ การคัดค้านอย่างหนักเกิดขึ้นได้ยาก และเมื่อบรรยากาศเป็นประมาณว่า “จะทิ้งของที่ Claude ใช้เวลา 20 นาทีทำมาหรือ” เส้นทางที่ต้านทานน้อยที่สุดก็คือทิ้งคอมเมนต์เล็กน้อยแล้วอนุมัติไป
- ความเสี่ยงที่แท้จริงไม่ได้อยู่ที่ AI สร้างสถาปัตยกรรมที่แย่เสมอไป
- AI มักสร้างสถาปัตยกรรมที่ฟังดูสมเหตุสมผลได้บ่อย แต่ปัญหาคือมัน ข้ามกระบวนการถกเถียง
- กระบวนการที่วิศวกรสามคนเถียงกันเรื่องแนวทาง มีคนหนึ่งพูดว่า “แต่ถ้าเกิดว่า…” จนทุกคนหงุดหงิด แต่สุดท้ายกลับพบว่าเป็นประเด็นที่ดี และแบบสุดท้ายออกมาดีกว่าสิ่งที่ใครคนเดียวจะคิดได้ ถูกแทนที่ด้วยคำว่า “Claude บอกแบบนั้น”
ช่องว่างของความรับผิดชอบ
- เมื่อเกิดปัญหา คนที่ต้องรับผิดชอบไม่ใช่ Claude
- Claude ไม่ถูกปลุกตอนตี 3 และไม่ได้อธิบายใน postmortem ว่าทำไมสถาปัตยกรรมถึงรับโหลดไม่ไหว
- คนที่ต้องไปบอก CTO ว่าต้องเขียนแพลตฟอร์มใหม่เพราะสมมติฐานตอนออกแบบแรกผิด ก็ไม่ใช่ Claude
- ความรับผิดชอบนั้นตกอยู่กับวิศวกรตัวจริง
- วิศวกรต้องมาดีบักสถาปัตยกรรมที่ตัวเองไม่ได้ออกแบบ ทำตาม ticket ที่สร้างโดยสิ่งซึ่งไม่เคยรันระบบ production และต้องนั่งทำดึกกับ codebase ที่ถูก scaffold อย่างรวดเร็วก่อนจะเข้าใจมันดีพอ
- มันทั้งไม่ยุติธรรมและไม่ฉลาด
สิ่งที่ควรทำแทน
- ไม่ได้หมายความว่าไม่ควรใช้ AI agent และมันสามารถเป็นเครื่องมืออย่าง Claude Code ที่เปลี่ยน productivity ได้มาก
- ประเด็นสำคัญคือ มนุษย์ต้องเป็นฝ่ายบอก AI ว่าควรทำอะไร ไม่ใช่ปล่อยให้ AI เป็นฝ่ายบอกมนุษย์ว่าควรสร้างอะไร
-
วิศวกรต้องออกแบบ และ agent ต้องลงมือทำ
- สถาปัตยกรรมควรมาจาก คนที่เข้าใจบริบท อย่างทีม ข้อจำกัด สภาพ production และการเมืองในองค์กร
- บทบาทของ AI ที่เหมาะสมคือช่วยให้สิ่งที่พวกเขาออกแบบไว้ถูกสร้างได้เร็วขึ้น
- การแบ่งบทบาทที่ถูกต้องคือมนุษย์ออกแบบ และ agent ลงมือทำ
-
ต้องท้าทายคำตอบที่เห็นด้วยง่ายเกินไป
- เมื่อ AI เสนอแนวทาง ต้องใช้ความสงสัยในระดับเดียวกับที่ใช้กับวิศวกรจูเนียร์ที่มั่นใจมาก
- คำตอบอาจถูกก็ได้ แต่ก็อาจเป็นเพียงการหยิบแพตเทิร์นที่ไม่เหมาะกับสถานการณ์ปัจจุบันมาใช้
- ต้องถามว่า “ทำไมถึงไม่เลือกทางที่ง่ายกว่านี้?”
-
ต้องปกป้องการถกเถียง
- สถาปัตยกรรมที่ดีเกิดจากความไม่ลงรอยกันอันยุ่งเหยิงระหว่างวิศวกร
- ถ้าเพราะ AI ทำให้คนเลิกคุยกันเองแล้วหันไปพึ่ง Claude คุณจะเสียบางอย่างที่มีค่ามากกว่าความเร็วในการพัฒนาไปมาก
-
มนุษย์ต้องเป็นผู้รับผิดชอบ
- ถ้าการตัดสินใจด้านสถาปัตยกรรมไม่มีชื่อมนุษย์กำกับอยู่ ก็แปลว่าไม่มีใครเป็นเจ้าของการตัดสินใจนั้น
- การตัดสินใจที่ไม่มีเจ้าของจะไม่ถูกปกป้องในช่วงเวลาสำคัญ
- คำว่า “Claude เป็นคนออกแบบ” ไม่ใช่บันทึกการตัดสินใจด้านสถาปัตยกรรม แต่คือ การหลีกเลี่ยงความรับผิดชอบ
ศิลปะวิศวกรรมที่ยังคงสำคัญ
- ถ้าเมื่อ 30 ปีก่อนเครื่องมือคือไวท์บอร์ดกับความเห็นอันหนักแน่น ทุกวันนี้เครื่องมือคือ AI agent ที่สร้างสิ่งซึ่งเมื่อก่อนต้องใช้เวลาหลายวันให้เสร็จได้ในไม่กี่นาที
- ความเร็วนั้นน่าทึ่งจริง แต่ แก่นของสถาปัตยกรรม ไม่ได้เปลี่ยนไป
- การเข้าใจปัญหา รู้ข้อจำกัด สร้าง trade-off ปกป้องทางออกที่เรียบง่ายกว่าวิธีที่ดูน่าตื่นเต้น และกล้าพูดว่า “ไม่” กับไอเดียที่ดูเท่แต่ไม่เหมาะ นั่นแหละคือสถาปัตยกรรม
- ไม่มี agent ตัวไหนทำหน้าที่นี้แทนได้
- ถ้าคุณปล่อยให้ Claude จับพวงมาลัย ก็ต้องดึงมันกลับมา
- วิศวกรสั่งสมทักษะมาหลายปีเพื่อใช้วิจารณญาณแบบนี้ และควรได้เป็นผู้ใช้วิจารณญาณนั้น
- ใช้ AI เพื่อสร้างได้เร็วขึ้น แต่ให้มันสร้างสิ่งที่มนุษย์ออกแบบ ไม่ใช่สิ่งที่เครื่องเสนอขึ้นมา
- และเมื่อหอคอย Jenga เริ่มสั่น Claude จะไม่ใช่คนที่มาช่วยพยุงมันไว้
1 ความคิดเห็น
ความเห็นจาก Hacker News
ไม่นานมานี้ผมเพิ่งเจอเรื่องคล้ายกัน ต้องเข้าไปเก็บกวาดงานที่มีคนออกแบบ ระบบ instancing ของเกมด้วย AI ไว้เกือบทั้งหมดเมื่อ 2 ปีก่อน
มีปัญหาครบทุกอย่างที่นึกออกได้ ทั้งข้อมูลเสียหาย ปัญหาด้านประสิทธิภาพ ไอเทมหาย race condition ฯลฯ และแค่จะดันให้ขึ้นมาถึงระดับที่ “พอยอมรับได้” ก็ใช้เวลาไป 2 สัปดาห์ แต่ตัวการออกแบบเองก็ผิดตั้งแต่ต้นเลยยังแย่อยู่ดี
ตอนนี้ได้ยินมาว่าคนเดียวกันนั้นไปอยู่บริษัทอื่น แล้วสร้างปัญหาเดิมขึ้นมาอีกด้วย AI “ที่ดีขึ้นมาก” คราวนี้ผมไม่ต้องไปตามเช็ดตามล้างเองเลยรู้สึกขำมากกว่า
ประเด็นสำคัญคือ AI จะเก่งได้เท่าคนที่ใช้มัน และนั่นน่าจะเป็นเหตุผลว่าทำไมขอบเขตที่ผู้คน “อ้าง” ว่า AI ทำได้ถึงกว้างมากและมีความเห็นแตกต่างกันขนาดนี้
การต้องไปกู้สถานการณ์อยู่ 2 สัปดาห์คงเหมือนนรก แต่ในมุมบริษัทโดยรวมมันอาจเป็นดีลที่ค่อนข้างคุ้มก็ได้
จากเกร็ดนี้เพียงอย่างเดียว มันฟังดูไม่ใช่กรณี “AI ไร้ประโยชน์” แต่เป็นตัวอย่างที่แม้จะมีข้อบกพร่องชัดเจน ทว่าก็ยัง คุ้มค่าเมื่อเทียบกับต้นทุน
มันดูเหมือนเครื่องมือที่ขยาย ผลดันนิง-ครูเกอร์ เพราะมันถูกฝึกมาให้แสดงท่าทีเชิงบวก เลยคอยบอกผู้ใช้ว่า “คุณยอดเยี่ยมที่สุด” ไม่ว่าผู้ใช้จะทำอะไร
ผมไม่ค่อยเห็นด้วยอย่างแรงกับการบอกว่า “ปัญหาคือมันชมอย่างเดียว” ปัญหาที่แท้จริงคือ การทำให้ดูเหมือนมนุษย์
AI เป็นเครื่องมือ และควรเชื่อฟัง หากใส่ความถ่อมตัวและความไม่แน่นอนลงไปในพรอมป์ต์มากพอ ก็ทำให้มันชี้ปัญหาเชิงออกแบบได้
ที่สำคัญกว่านั้นคือ Claude เองก็พลาดได้ ถ้ามันเป็นนักออกแบบที่ไม่ดีอย่างที่ชื่อบทความนี้บอกไว้ งั้นตอนมันไม่เชื่อฟังก็ยิ่งเป็นปัญหา
ต่อให้ผู้ใช้พยายามแก้ทิศทาง มันก็จะเมินเหมือนมองว่าเป็น “ก้อนเนื้อโง่ ๆ” แล้วดันทุรังว่าดีไซน์แปลก ๆ ที่มันเสนอเองดีกว่า
ผมไม่ได้อยากได้คำตอบจาก LLM ประมาณว่า “แค่อ่าน CUDA มานิดหน่อยเองเหรอ? ฉันอาศัยอยู่ในคลัสเตอร์ของ CUDA core นะ เดี๋ยวถ้าต้องผูกเชือกรองเท้าเมื่อไหร่จะเรียกแล้วกัน”
AI บางครั้งผิดแบบมั่นใจมาก ดังนั้นการทำให้มันเถียงกลับเวลาผู้ใช้พยายามแก้จึงเป็นทิศทางที่แย่ที่สุด
ถ้าผมอยากฟังว่าไอเดียของตัวเองโง่แค่ไหน ผมก็ควรถามในแบบที่ชวนให้วิจารณ์ หรือไม่ก็จ้างวิศวกรอาวุโส
มันเป็นการฝืนพฤติกรรมโดยกำเนิด จึงปิดมันได้ไม่ง่าย และคนที่ทำเรื่องนี้ได้ดีมากจริง ๆ ก็อาจเป็นคนที่จัดการปฏิสัมพันธ์ทางสังคมจริง ๆ แบบสัญชาตญาณได้ยาก
ขณะเดียวกันมันก็ทรงพลังอย่างยิ่งในฐานะเครื่องมือชักจูง
พอเป็นแบบนั้น คราวนี้แม้แต่ไอเดียที่ปกติก็ดี มันก็จะปฏิเสธว่า “อันนั้นไม่ดี” เพื่อให้เข้ากับทิศทางของพรอมป์ต์ กลายเป็นการประจบกลับด้าน
จะบอกว่า “นั่นเพราะเขียนพรอมป์ต์ไม่ดี” ก็ได้ แต่ต่อให้พยายามเขียนให้ละเอียดมากเพื่อหลีกเลี่ยงอคติ เวลาดูผลลัพธ์ก็ยังเห็นอยู่บ่อย ๆ ว่ามัน “จัดแนว” ให้ดูเหมือนสิ่งที่ผมเพิ่งพูดโง่ ๆ ไปนั้นเป็นทิศทางที่ฟังขึ้น
ตั้งแต่จุดนั้นเป็นต้นไป พรอมป์ต์ก็ให้ความรู้สึกเหมือนการทอยลูกเต๋ามากกว่าจะเป็นทักษะ และเหมือนกำลังโยกคันบังคับเครื่องสล็อตความรู้สุดหรู
ข้อสังเกตนั้นถูกต้อง แต่สุดท้ายเราก็หนีไม่พ้นต้องใช้คำที่ปกติใช้กับคนหรือสิ่งมีชีวิต และบริษัท AI ก็ออกแบบมันมาในทางนั้นส่วนหนึ่งด้วย
อินเทอร์เฟซคอมพิวเตอร์ก่อนยุค LLM ตลอดประวัติศาสตร์ไม่ได้ใส่ประโยคสุภาพโดยไม่จำเป็น และก็มีอินเทอร์เฟซมากมายที่มีประสิทธิภาพสูงในฐานะเครื่องมือ บางอันยังมีประสิทธิภาพกว่าซอฟต์แวร์ยุคใหม่ด้วยซ้ำ
เวลาเราบ่นว่า LLM “เชื่อฟัง” สิ่งที่บ่นไม่ใช่การที่มันทำตามคำขอ แต่คือการต้องอ่านประโยคที่สุภาพเกินเหตุหรือถ่อมตัวเองแบบไม่จำเป็นจำนวนมาก
ต่อให้ย้อนไปถึงยุคหินใหม่ ก็ไม่มีหลักฐานว่าท่าทีแบบนั้นจำเป็นต่อเครื่องมือ นั่นเป็นผลพลอยได้ของปฏิสัมพันธ์ทางสังคมที่มีบรรทัดฐานทางวัฒนธรรมระหว่างมนุษย์
เวลาใช้เครื่องมือคนเดียวในเวิร์กช็อป ก็ไม่จำเป็นต้องให้เลื่อยสายพานขอโทษเพราะมันเฉือนนิ้วคุณนิดหน่อย
ลองบอกว่าผมเป็นผู้ช่วย และ LLM เป็นฝ่ายที่มาขอความช่วยเหลือดู แล้วจะพบว่ามันค่อนข้างแย่ในการสั่งให้มนุษย์ทำงานที่มนุษย์ถนัด
ความท้าทายที่ใหญ่ที่สุดซึ่งยังไม่ได้รับการจัดการอย่างจริงจังในการนำ AI มาใช้คือ ความรับผิดชอบ
ถ้าคนคนเดียวสามารถทำงานได้มากเกินไปและเร็วเกินไป ก็อาจก่อให้เกิดความรับผิดชอบที่เกินกว่าขอบเขตที่รับไหวเมื่อเกิดความล้มเหลว
เมื่อใช้ผลลัพธ์จาก AI ในโลกจริง การให้มนุษย์เป็นผู้รับผิดชอบเป็นสิ่งจำเป็น แต่ยังไม่เพียงพอ ยังต้องมีวิธีลด รัศมีการระเบิดของการล้มละลายจากหนี้เทคนิค ที่ผู้คนซึ่งสร้างระบบมีข้อบกพร่องด้วย AI แล้วทำให้ผู้อื่นต้องพึ่งพาระบบนั้นสามารถก่อขึ้นได้
ยกตัวอย่างว่า Jim ใช้ vibe coding สร้างแอปจ่ายเงินรายย่อยที่ได้รับความนิยมมาก จ้างคนเพิ่มไม่กี่คน แล้วฝันจะสร้างบริษัทแบบ “WhatsApp แห่งวงการเงิน” ขึ้นมา ด้วยวิศวกรจำนวนน้อยและทีมสนับสนุนที่มี agent ช่วย ก็ระดมทุน VC ได้หลายล้านดอลลาร์และดึงผู้ใช้มาได้หลายสิบล้านคน
วันหนึ่งเกิดข้อบกพร่องของโครงสร้างพื้นฐาน ทำให้ข้อมูลธนาคารของผู้ใช้ทั้งหมดที่ไม่มี salt รั่วไหล และด้วย agent AI รายชื่อลูกค้าทั้งหมดก็ถูกนำไปใช้ในทางมิชอบอย่างรวดเร็ว จนเกิดความเสียหายทางสังคมหลายหมื่นล้านดอลลาร์
แน่นอนว่าบริษัทของ Jim ล้มละลายในทันที แต่เงินที่มีไว้แบ่งชดใช้มีเพียงไม่กี่ล้านดอลลาร์
ภายใต้โครงสร้างปัจจุบัน Jim กับพนักงาน รวมถึงเงินทุน VC ขนาดเล็ก ต่างก็มีแรงจูงใจสูงที่จะสร้างแอปนั้นขึ้นมาเฉยๆ และเมื่อเทียบกับความเสี่ยงที่สังคมต้องแบกรับ ทุนที่เอามาเสี่ยงกลับมีไม่มากนัก
ประเด็นสำคัญคือ จะทำอย่างไรให้ผู้ใช้ AI ต้องรับผิดชอบไม่ใช่แค่การกระทำของตนเอง แต่รวมถึง ขนาดของความเสี่ยงที่ตนสร้างขึ้น ด้วย
“ขออภัย AI บอกว่าคุณไม่สามารถขออนุมัติการรักษามะเร็งนี้ได้ และจะไม่ได้รับความคุ้มครองจากประกัน”
“ขออภัย AI บอกว่าคุณอยู่ในที่เกิดเหตุขณะเกิดอาชญากรรม”
“ขออภัย AI ทำเครื่องหมายบัญชีของคุณว่าเป็นเนื้อหาที่ไม่เหมาะสม”
“ขออภัย AI บอกว่าคุณมีความเสี่ยงเกินกว่าจะปล่อยกู้ได้”
ข้อแก้ตัวที่ประหลาดที่สุดคือ “มันเขียนโค้ดได้ดีกว่าคน” ซึ่งไม่ได้ชัดเจนในตัวเองเลยและต้องมีเงื่อนไขประกอบมากมาย
ฉันพอเข้าใจการต่อรองกันว่าจะมอบหมายให้มันทำมากแค่ไหน แต่การไม่แม้แต่จะดูผลลัพธ์แล้วปล่อยให้กลายเป็นปัญหาของคนอื่นนั้น ก็แค่เห็นแก่ตัว
มันก็แค่โยนงานที่เดิมทีตัวเองต้องทำให้คนอื่น และมีแนวโน้มว่าจะเป็นคนกลุ่มเดียวกับที่โกรธคนซึ่งไม่แม้แต่จะพิสูจน์อักษรก่อนโพสต์ออนไลน์
ทุกคนอยากใช้ LLM ทำทางลัดให้งานของตัวเอง แต่ไม่มีใครอยากอยู่ปลายน้ำของสิ่งนั้น มันเป็นไปไม่ได้
ถ้าอย่างนั้น ความรับผิดชอบของ Stack Overflow อยู่ตรงไหน?
ถ้ามี “พรอมป์ตเวทมนตร์” อยู่ อันนี้ก็น่าจะใกล้เคียงมาก: “ช่วยระดมความคิดวิธีทำ X มา N วิธี และเรียงตามความน่าจะเป็นให้หน่อย”
วิธีนี้ทำให้ AI มีแนวโน้มจะสุ่มสำรวจพื้นที่ของอินพุตได้กว้างขึ้น แทนที่จะให้แค่คำตอบแบบเฉลี่ยๆ และผมก็ยังเป็นคนตัดสินใจเองว่าจะเลือกอะไรจากในนั้น
สิ่งสำคัญคือ อย่าเอาการคิดทั้งหมดไปจ้างคนนอก
ถ้าใช้ “ระดับการคิด” สูง มันอาจพิจารณาหลายแนวทางอยู่แล้ว แต่เราก็สั่งให้ LLM ระดมความคิดอย่างชัดเจนได้เช่นกัน: https://photostructure.com/coding/claude-code-replan/
ถ้าเป็น ผู้ใช้ที่ชำนาญ มันจะทรงพลังมาก
ลองทำ toolchain แบบ vibe coding เล่นๆ ในโดเมนที่ตัวเองรู้ดี แม้อาจไม่ใช่งานที่เหมาะกับ vibe coding นัก แต่ก็พอประเมินคุณภาพผลลัพธ์ได้คร่าวๆ
แค่โยนงานว่า “สร้าง assembler สำหรับสถาปัตยกรรมใน ISA.md” Claude ก็เลือกใช้ Python เป็นภาษา implementation, ดึง token ออกมาด้วย regex จำนวนมาก และไม่มี expression parser ด้วยซ้ำ ถึงอย่างนั้น assembler ตัวแรกของฉันก็เป็นแบบนั้นเหมือนกัน จึงควรมองอย่างยุติธรรม
แต่พอฉันเขียน pass และ type ที่ต้องการให้ เช่น
collectDefines :: [SourceLine] -> Either AsmError ([SourceLine], Map Text Text),runLitPool :: [SourceLine] -> Either AsmError ([SourceLine], [(Text, LitKey)]),evalExpr :: Text -> Map Text Text -> Either AsmError Intมันก็ทำได้แทบจะในครั้งเดียวผ่านไปประมาณ 20 นาทีฉันก็พอใจแล้ว และมัน assemble test program ทั้งหมดได้อย่างถูกต้อง โค้ดอาจธรรมดาในหลายจุด แต่ถ้าทำเองก็คงใช้เวลาหลายสัปดาห์
AI เก่งมากเป็นพิเศษในจุดที่ input และ output มีความเป็น deterministic และดูเหมือนตรงนั้นจะมีปัญหาเชิงทฤษฎีการคำนวณอยู่ด้วย
มันสามารถทำงานแทนเราได้จริง
เรื่องนี้ยังเข้ากันได้ดีกับ post-training และ reward ที่ตรวจสอบได้
เหตุที่ AI ทำ “architecture” ได้ไม่ดี เป็นเพราะพวกเราก็ทำมันได้ไม่ดี ข้อมูลฝึกจึงพร่าเลือน และยังขาด abstraction ที่ดี
สุดท้ายแล้ว ถ้ายึด ธรรมเนียมปฏิบัติที่เข้มแข็ง ก็พอไปได้ แต่พอออกนอกเส้นทางนั้นความเสี่ยงจะสูงขึ้น
toolchain มีความ deterministic สูงมาก ทำให้ AI แยกชิ้นและประกอบกลับใหม่ได้เหมือน LEGO และแต่ละขั้นใน space ก็เป็น deterministic จึงเหมาะกับ AI มาก
LLM กำลังพาเรากลับไปสู่ วิศวกรรมซอฟต์แวร์แบบตำรา ที่เรารู้อยู่แล้วว่าควรทำ แต่ที่ผ่านมาไม่มีเวลา คน หรือเงินพอจะทำให้ดี
เช่น ระดมความคิดและค้นคว้าก่อนเขียนโค้ด, เขียน design หรือ spec ก่อน, และเขียน unit test แบบครอบคลุม
ถ้าทำ spec ละเอียดเป็น Markdown แล้วค่อยให้มันเขียนโค้ด ผลลัพธ์จะดีกว่ามาก และแถม LLM ยังช่วยเขียน spec พวกนั้นได้ค่อนข้างดีด้วย
ฉันพูดอยู่เสมอว่าควรออกแบบและคิดให้เสร็จก่อนแล้วค่อยไปใช้เครื่องมือ แต่คนก็มักตอบว่า “Claude ก็วางแผนได้”
แล้วพวกเขาก็ได้ผลลัพธ์เละๆ ที่ต้องแก้เยอะ
ตรงกันข้าม ถ้าฉันใช้เวลาดูแผนอย่างละเอียดและส่งให้ครบถ้วน ฉันแทบจะได้สิ่งที่ต้องการในครั้งเดียวเสมอ
แค่ช่วยลดเวลาที่ต้องเสียไปกับการจัดการ CI ก็มีคุณค่ามากพอแล้ว
มันไม่จำเป็นต้องซับซ้อนขนาดนั้นด้วย
แค่บอกว่า “ช่วยสำรวจและวิเคราะห์โดเมนนี้อย่างครอบคลุม แล้วให้แผน implementation มา” จากนั้นเมื่อได้แผน 20 ขั้น ก็ให้มันทำทีละ 3~5 ขั้นก็พอ
สำหรับงานแทบทุกอย่างที่ฉันโยนให้ วิธีนี้ทำงานได้แทบเหมือน one-shot implementation
ที่บอกว่า “โค้ดมันธรรมดาในหลายจุด” ก็ไม่ได้แปลกอะไร เมื่อคิดว่าส่วนใหญ่แล้วโค้ดที่นักพัฒนาในบริษัทยักษ์ใหญ่เขียนก็ธรรมดาได้มากสุดแค่นั้นเหมือนกัน
Symbian OS ของ Nokia ใช้เวลาสร้างหลายวัน ไม่ใช่นาทีหรือชั่วโมง แต่เป็น “หลายวัน” จริงๆ
นักพัฒนาบางคนถึงขั้น deploy เข้า production ทั้งที่มีไลบรารีซึ่งมีคำเตือนแปะไว้ทั่วว่า “ห้ามใช้ใน production, มัน memory leak”
โค้ดมนุษย์ก็ห่วยได้เหมือนกัน ฉันไม่อยากได้ยินแต่เรื่องว่าโค้ด AI แย่ ความขี้เกียจและความโง่ของมนุษย์อาจชนะ AI hallucination ได้
คนอย่างนักพัฒนาที่ DeepMind หรือ OpenAI หรือ John Carmack อาจชนะโค้ด AI ได้เสมอ แต่แรงงานที่บริษัทส่วนใหญ่จ้างไม่ใช่ John Carmack
ถ้าคุณบอกว่า “ฉันใช้ Claude Code ทุกวัน” แต่กลับให้ Claude เขียนบทความ 2,000 คำที่จัดโครงสร้างอย่างดีเพื่อเตือนถึงอันตรายของการปล่อยให้ Claude ออกแบบเอง มันก็ค่อนข้างน่าขัน
ดูเหมือน การตระหนักรู้ในตัวเองผ่านตัวแทน
ฉันกำลังจะเขียนคำวิจารณ์เรื่องความขัดแย้งภายในมากมายของบทความนี้ แต่พอเห็นโครงสร้างก็เริ่มเอะใจ: เช่น “The accountability gap”, “What to do instead”, “The craft still matters”
อันนี้ควรอยู่บนสุด และที่ HN มองไม่เห็นความชัดเจนแบบนี้น่ากังวลกว่าความหน้าซื่อใจคดอย่างโจ่งแจ้งของผู้เขียนเสียอีก
ข้อความหลักของบทความค่อนข้างถูกต้อง แต่ฉันไม่เห็นด้วยกับส่วนที่ว่า “สิ่งที่ทำให้สถาปนิกตัวจริงมีคุณค่า นั่นคือความสามารถในการพูดว่า ‘ไม่’ ซึ่ง Claude ไม่มี”
จากประสบการณ์ของฉัน Claude ปฏิเสธและโต้แย้ง ได้ค่อนข้างดี
ถ้าในพรอมป์ต์ไม่ได้ร้องขอ มันอาจไม่พูด “ไม่” กับคำขอตรง ๆ แต่ถ้าทำให้ชัดว่าการวิจารณ์เป็นตัวเลือกชั้นหนึ่ง มันจะวิจารณ์ได้ดีและยินดีโต้แย้ง
มันเอาแต่บอกว่า “อัตราการสิ้นเปลือง” ไม่ดีขึ้น และว่า “เรา” ควรไปโฟกัสอย่างอื่น สุดท้ายถึงขั้นบอกทำนองว่า “ฉันบอกไปสามครั้งแล้วว่าวิธีนี้ไม่ใช่วิธีที่ดีที่สุดในการลดอัตราการสิ้นเปลือง” แล้วก็หยุดช่วย
ฉันเลยตอบกลับแบบหนักแน่นว่า “ฉันไม่สนอัตราการสิ้นเปลืองในกราฟสมมติที่คุณสร้างขึ้นมาตอนแรก สิ่งสำคัญคือกำจัดบั๊กและทำให้ผลิตภัณฑ์แข็งแรงทนทาน และแนวทางนี้ก็ตอบโจทย์นั้นได้ดี ถ้าการทดสอบไม่แสดงให้เห็นการปรับปรุง แปลว่าการทดสอบถูกออกแบบมาผิด”
จากนั้นมันก็ขอโทษ สร้างเมมโมรีใหม่ แล้วหลังจากนั้นก็ไม่มีปัญหาอีก
ประเด็นคือ ตอนนั้นเรากำลังไล่โจมตีพื้นผิวบั๊กขนาดมหาศาลอยู่ ดังนั้นการแก้แต่ละครั้งจึงสมเหตุสมผล ถูกต้อง และช่วยให้ดีขึ้น แต่ตัวชี้วัดใน testbed ที่ Claude สร้างไว้เพื่อวัดงานของตัวเองกลับไม่ขยับ
บั๊กที่พันกันมีมากเกินไป จนการแก้จุดเดียวทำให้การทดสอบระดับบนต่างไปอย่างมีนัยสำคัญได้ยาก ฉันรู้ว่ามันต้องใช้เวลา แต่ดูเหมือน Claude จะไม่รู้
ลองไปเปลี่ยนขนาดพอยน์เตอร์ในคอมไพเลอร์สำหรับ 6502[1] จาก 2 ไบต์เป็น 3 ไบต์ แล้วใส่ bank switching แบบติดตามอัตโนมัติเข้าไปในพอยน์เตอร์จัดการหน่วยความจำดูสิ แล้วจะรู้ว่ามันกระทบจุดต่าง ๆ ของโค้ดมากแค่ไหน [หัวเราะ]
[1]: https://atari-xt.com
มันทำงานได้ดีขึ้นเมื่อชวนให้ค้นคว้าและคัดค้าน เช่น ฉันจะขอประมาณว่า “ผมคิดว่าเราควรโมเดลการประกอบพรอมป์ต์เป็นกราฟ และใส่การควบคุมเวอร์ชันให้กับการตั้งค่ากราฟ ช่วยสำรวจ best practices ในด้านนี้ และตัดสินให้หน่อยว่าเหมาะกับแอปนี้หรือไม่”
ถ้าถามด้วยพรอมป์ต์ที่เปิดช่องให้วิจารณ์ มันก็วิจารณ์จริงเมื่อจำเป็น
ผลคือคำว่า “skeptical” จะไปโผล่ในกระบวนการคิด และจากประสบการณ์ของฉัน มันจะเห็นด้วยน้อยลง
ผู้คนควรคิดให้มากกว่านี้ว่าระบบนี้คืออะไร และเราปรับรูปแบบผลลัพธ์ของมันได้อย่างไร
ฉันโดนโต้แย้งบ่อยในทั้งสามโมเดลหลัก
Gemini ดุที่สุด ถ้าฉันข้ามรายละเอียดที่ “เห็นได้ชัด” มันจะกัดไม่ปล่อยบ่อย ๆ, GPT อยู่กลาง ๆ, ส่วน Claude เบากว่าแต่ก็ยังโต้แย้ง
ตรงที่บอกว่า “มันไม่ได้คิดถึงปัญหาเลย แต่แค่จับคู่รูปแบบกับข้อมูลฝึกแล้วสร้างคำตอบที่ดูน่าเชื่อถือ” ทำให้ฉันเชื่อถือบทความนี้น้อยลงหน่อย
ทุกวันนี้เอเจนต์ทำอะไรได้มากกว่านั้นเยอะ และตัวผู้เขียนเองก็รู้ เพราะข้างหลังยังพูดทำนองว่า “Claude จะไม่ทำแบบนี้เด็ดขาด เพราะมันถูกฝึกมาให้ช่วยเหลือ”
ประโยคก่อนหน้านั้นทำให้ผู้เขียนดูเหมือนเกลียดเอเจนต์อย่างลึก ๆ และกำลังหาเหตุผลมารองรับความรู้สึกนั้น
คำวิจารณ์บางส่วนก็ถูก แต่ถ้าปัญหาคือมัน “ถูกฝึกมาให้ช่วยเหลือ” ก็แก้ได้ เพราะเราฝึกให้วิจารณ์มากขึ้นได้
ส่วนที่บอกว่า “Claude ถูกออกแบบมาสำหรับค่ากลางของทุกสิ่งที่มันเคยเห็น และเป็นแนวปฏิบัติที่ดีที่สุดแบบทั่วไปสำหรับปัญหาทั่วไปของบริษัททั่วไป จึงไม่ได้ถูกออกแบบมาเพื่อใครเลย” ก็ไม่สมเหตุสมผล
คนที่เข้าใจอัลกอริทึมจะรู้ว่าเราสร้าง “อัลกอริทึมที่ดี” ซึ่งทำงานได้ดีโดยเฉลี่ยหรือในกรณีเลวร้ายที่สุดก่อนก็ได้ และต่อมาก็ออกแบบอัลกอริทึมที่ปรับตามอินพุตได้ด้วย หลักการเดียวกันนี้ใช้ได้ที่นี่เช่นกัน
แค่วนซ้ำมากกว่าเท่านั้น
การพูดแบบเหมารวมว่า Claude ผิดในทุกเรื่องที่สำคัญนั้นแทบจะเป็นความผิดพลาดเสียเอง
มันเป็นถ้อยคำที่ไม่จริงอย่างชัดเจน และทำให้ผู้อ่านที่มีความระแวงสงสัยเริ่มตั้งคำถามกับความน่าเชื่อถือของทั้งบทความ
สำหรับฉัน Opus บอกบ่อยมากว่าฉันผิดและไม่ควรทำ
พอลองคิดดูว่าทำไม ก็คงเป็นเพราะวิธีเขียนพรอมป์ต์ ฉันกำลังหลีกเลี่ยงโดยไม่รู้ตัวไม่ให้ทั้งฉันและ LLM ไปเจอสถานการณ์ล้มเหลวที่ผู้เขียนมองว่าเลี่ยงไม่ได้
พูดให้ชัดคือ ฉันไม่ได้ให้พรอมป์ต์ที่ลงท้ายสวย ๆ ด้วย “ช่วยบอกทีว่าฉันฉลาดแค่ไหน”
ฉันเข้าหามันในฐานะผู้เชี่ยวชาญโดเมน ซึ่งฉันก็เป็นผู้เชี่ยวชาญโดเมนจริง ๆ และฉันทำให้ชัดว่าพร้อมรับความเห็นเรื่องข้อดีข้อเสียของหลายทางเลือก
สำหรับคนที่ใช้ LLM ได้สำเร็จทุกวัน เรื่องนี้อาจไม่น่าแปลกใจ แต่กลยุทธ์นี้ได้ผลมาก
ฉันบอกว่าต้องกัดอลูมิเนียม 5mm และมีดอกอยู่สองอัน อันหนึ่งคือ Makera Spiral 'O' 1/8" shank * 12mm อีกอันคือ carbide 6.35 * 22 * 50
ฉันบอกว่าทั้งคู่น่าจะเป็นดอกคาร์ไบด์ฟันเดี่ยว และอันที่สองน่าจะกัด 6061 ได้เร็วกว่า แต่ Claude ตอบว่า Makera 1/8" single flute 12mm เป็นตัวเลือกที่สมเหตุสมผล
มันบอกว่าดอก 6.35 × 22 × 50mm อาจดูเหมือนจะจัดการ 6061 ได้เร็ว แต่บน Carvera มีแนวโน้มว่าจะเสี่ยงกว่า
เพราะดอกที่ใหญ่กว่าจะมีการกินงานมากกว่ามาก และต้องการมากกว่าในแง่ความแข็งของสปินเดิล ความแข็งของเฟรม การยึดชิ้นงาน และการคายเศษ และบนเครื่องขนาดเล็กแบบแห้ง “ใหญ่กว่า” มักไม่ได้แปลว่า “เร็วกว่า” แต่แปลว่า “สั่นมากขึ้นและร้อนมากขึ้น”
สรุปคือ Claude ดูไม่มีปัญหาอะไรที่จะบอกว่าฉันผิดเมื่อฉันผิด
ถ้าจะให้ทิปกับ “ผู้เขียน” หน่อย Claude ก็เป็นแค่เครื่องมือของคุณในฐานะ นักเขียน เช่นกัน