AI ต้องการวินัยทางวิศวกรรมมากขึ้น ไม่ใช่น้อยลง
(charitydotwtf.substack.com)- คุณภาพของโค้ดที่ AI สร้างดีขึ้น ไม่ได้เป็นสัญญาณให้เลิก code review แต่หมายความว่าในสภาพแวดล้อมที่โค้ดสามารถสร้างใหม่ได้อย่างรวดเร็วและราคาถูก เราจำเป็นต้องเข้มงวดกับ วินัยด้านการตรวจสอบและการปฏิบัติการ มากขึ้น
- หลัง Opus 4.5 ช่วงปลายปี 2025 เป็นต้นมา AI สามารถสร้างโค้ดสำหรับแพตเทิร์นที่พบบ่อยได้เร็วและถูกกว่าเดิมมาก โดยมีคุณภาพใกล้เคียงวิศวกรซอฟต์แวร์ระดับกลาง และ agentic harness, การใช้เครื่องมือ, function calling และ MCP คือสิ่งที่หนุนการเปลี่ยนผ่านนี้
- เมื่อค่าใช้จ่ายในการผลิตโค้ดเข้าใกล้ศูนย์ บรรทัดของโค้ดก็ไม่ใช่ทรัพย์สินล้ำค่าที่ต้องเก็บรักษาอีกต่อไป แต่ใกล้เคียงกับ แคชที่สร้างใหม่ได้ ซึ่งทำหน้าที่ทำให้ความเข้าใจปัจจุบันกลายเป็นรูปธรรม
- เช่นเดียวกับที่ immutable infrastructure ทำให้เราเปลี่ยนเซิร์ฟเวอร์แทนการแก้เครื่องที่กำลังรันอยู่ ในยุค AI โค้ดแอปพลิเคชันก็ให้ความสำคัญกับ การตรวจสอบพฤติกรรม, characterization test, capture/replay, การแยกทราฟฟิก และ observability มากกว่าการแก้ไขตัวโค้ดโดยตรง
- ระบบที่ไม่เป็น deterministic ต้องการ วินัยทางวิศวกรรม เช่น trace, production eval และวงจร feedback ที่รวดเร็ว มากกว่าการพึ่งมนุษย์คอยยืนเป็นด่านคุณภาพ และ AI ไม่ได้ลบความจริงที่ว่าซอฟต์แวร์ยังต้องการทั้งผู้เชี่ยวชาญและวินัย
เศรษฐศาสตร์ของการผลิตโค้ดที่พลิกกลับในปี 2025
- ตลอดเกือบทั้งปี 2025 มุมมองที่ว่าโค้ดที่ AI สร้างเป็น “slop” และอาจจะยังคงเป็นแบบนั้นต่อไป ถือเป็นความเห็นที่สมเหตุสมผลและเป็นกระแสหลัก
- หลัง Opus 4.5 ในเดือนพฤศจิกายน 2025 AI ก็สามารถสร้างโค้ดที่อย่างน้อยในแพตเทิร์นที่พบบ่อย มีคุณภาพใกล้เคียงวิศวกรซอฟต์แวร์ระดับกลาง ได้เร็วกว่าและถูกกว่ามาก
- Opus 4.5 ไม่ใช่สาเหตุเดียว แต่ใกล้เคียงกับ จุดเปลี่ยนสำคัญ
- agentic harness คือโครงสร้างโค้ดที่นำ LLM เข้าไปทำงานเป็นลูปร่วมกับเครื่องมือ
- harness แบบนี้เริ่มใช้งานได้จริงในช่วงกลางปี 2025 และมีสัญญาณล่วงหน้าย้อนกลับไปถึงปลายปี 2024
- tool use, function calling และ MCP ค่อย ๆ สะสมตลอดปี 2025 จนกลายเป็นการใช้งานทั่วไปได้จริงในช่วงปลายปี
- ในการเปลี่ยนแปลงระลอกแรก ความสงสัยแบบ “ขอเห็นกับตาก่อนแล้วค่อยเชื่อ” ยังพอรับได้ แต่เมื่อการเปลี่ยนแปลงด้วยความเร็วระดับเดียวกันเกิดขึ้นอีกครั้ง ก็ยากจะคงท่าทีเดิมไว้
โค้ดเปลี่ยนจากทรัพย์สินล้ำค่าเป็นผลลัพธ์ที่สร้างใหม่ได้
- การเปลี่ยนแปลงสำคัญที่เกิดขึ้นในปี 2025 คือ เศรษฐศาสตร์ของการผลิตโค้ด ถูกพลิกกลับ
- จากเดิมที่การสร้างโค้ดยาก ใช้เวลานาน และมีราคาแพง กลายเป็นสิ่งที่ทำได้แทบจะทันทีและมีต้นทุนต่ำ
- บรรทัดของโค้ดย้ายจากสิ่งที่ต้องนำกลับมาใช้และทะนุถนอม ไปเป็นสิ่งที่ทิ้งแล้วสร้างใหม่ได้
- ยังมีมุมมองที่ว่าผลผลิตที่แท้จริงของทีมวิศวกรรมซอฟต์แวร์คือความเข้าใจร่วมกัน
- ความเข้าใจนั้นถูกเก็บไว้ในหัวของผู้คนเหมือนแคช และถูกเขียนลงดิสก์ผ่าน GitHub commit กับการ deploy สู่ production
- แต่ความจำของมนุษย์ลืมง่าย ชาชินกับการทำซ้ำ และมักพลาดรายละเอียดเล็กน้อย
- โมเดลในหัวจึงค่อย ๆ คลาดเคลื่อนจากโลกที่ผู้ใช้เจอจริง
- จากมุมมองของ SRE ผลผลิตที่แท้จริงของทีมซอฟต์แวร์ที่ดีอยู่ใน production
- “Only prod is prod”
- production ไม่ควรถูกมองว่าเป็นสถานที่หลังจบการพัฒนา แต่ควรถูกปฏิบัติเป็นหนึ่งในขั้นตอนของการพัฒนา
ความคล้ายกันระหว่าง Phoenix Architecture กับ immutable infrastructure
- Honeycomb ออก AI mandate ในเดือนสิงหาคม 2025 และมองว่าในฐานะบริษัท devtools จำเป็นต้องรับมือปัญหาที่ยากของเทคโนโลยีล่าสุด
- Phoenix Architectures ของ Chad Fowler เชื่อมโยงยุคของ AI coding เข้ากับ immutable infrastructure
- Chad Fowler คือผู้ที่บัญญัติคำว่า “immutable infrastructure” ในปี 2013
- Relocating Rigor คือบทความที่ Martin Fowler กล่าวถึงในสรุป meetup ของ Thoughtworks
- ใจความสำคัญของ The Death and Rebirth of Programming คือหลักการที่ว่าอย่าแก้สิ่งที่กำลังรันอยู่ แต่ให้แทนที่มัน
- immutable infrastructure, stateless services, containers, blue-green deployments และ infrastructure as code ต่างตั้งอยู่บนสมมติฐานเดียวกัน
- AI ขยายสมมติฐานนี้จากระดับโครงสร้างพื้นฐานมาสู่โค้ดแอปพลิเคชัน
- เมื่อต้นทุนในการเขียนใหม่ต่ำลง การแก้ของเดิมในที่เดิมจะยิ่งเสี่ยง mutation จะสะสม entropy ขณะที่ replacement จะรีเซ็ตมัน
- The Deletion Test ชวนให้ลองจินตนาการถึงการลบ implementation ทั้งหมดทิ้ง
- เหตุผลที่เรากลัวการลบ ไม่ใช่เพราะตัวโค้ดเอง แต่เพราะเราไม่รู้ว่าพฤติกรรมอะไรจำเป็น ความล้มเหลวแบบไหนยอมรับไม่ได้ invariant อะไรต้องรักษาไว้เสมอ และจะตัดสินความถูกต้องของเวอร์ชันใหม่จากอะไร
- การไม่รู้ว่าบั๊กใดเคยถูกแก้เพื่อรับมือ edge case ที่ถูกลืมไปแล้ว ก็เป็นปัญหาแบบเดียวกัน
- นี่ไม่ใช่ปัญหาเรื่องโค้ด แต่เป็น ปัญหาเรื่องการประเมินผล
- เมื่อโค้ดเป็นที่เดียวที่ความรู้ดำรงอยู่ โค้ดจึงมีค่าอย่างยิ่ง
- ในอดีต แรงงานในการสร้างโค้ดคือคอขวด จึงสมเหตุสมผลที่จะปฏิบัติต่อโค้ดเหมือนทรัพย์สินถาวร
- เมื่อการสร้างใหม่ทำได้ง่ายขึ้น โค้ดจึงทำหน้าที่คล้าย มุมมองที่ทำให้ความเข้าใจกลายเป็นรูปธรรม ซึ่งมีประโยชน์ในปัจจุบัน แต่เมื่อเก่าก็ทิ้งได้
โค้ดควรถูกสร้างใหม่ได้เหมือนที่เราสร้างเซิร์ฟเวอร์ใหม่
- ประสบการณ์การย้ายจากเซิร์ฟเวอร์แบบ pets ที่ทำมือ ไปสู่ cattle ในโลก immutable infrastructure ทิ้งบทเรียนไว้ว่า mutability คือศัตรูของความเข้าใจ
- เมื่อเราแก้ผลลัพธ์ที่กำลังรันอยู่ในที่เดิม จะเกิด drift
- drift ทำให้การบำรุงรักษาระบบยากขึ้น
- Honeycomb ตั้ง cron ไว้ให้ฆ่า Kafka node ที่เก่าที่สุดทุกวันอังคาร
- วิธีนี้ทำให้มั่นใจได้ว่ากระบวนการ bootstrap และ balancing สามารถทำซ้ำได้
- ข้อมูลสร้างใหม่ได้ และคำมั่นสัญญาสำคัญจริง ๆ อยู่ที่อื่น
- หากเราไม่สามารถสร้างโค้ดใหม่แบบเดียวกันได้ นั่นคือสัญญาณว่าเรายังเข้าใจโค้ดนั้นไม่มากพอ
- เราไม่รู้ว่าได้ให้คำมั่นอะไรไว้
- เราไม่รู้ว่า dependency อะไรจะพัง
- ส่วนใหญ่ต้องค้นพบด้วยการลองทำให้มันพัง
- migration ที่กินเวลานานและเจ็บปวด การ rewrite การแทนที่ legacy code และ strangler fig ล้วนเป็นกรณีที่บรรทัดของโค้ดแบกรับความรับผิดชอบมากเกินไป
- ในโค้ดนั้นมีทั้งเจตนาของนักพัฒนา ความคาดหวังของผู้ใช้ พฤติกรรมทั้งแบบ implicit และ explicit รวมถึงร่องรอยของบั๊กในอดีตที่ถูกผูกไว้ด้วยกัน
สิ่งที่ต้องรีวิวไม่ใช่แค่บรรทัดของโค้ด
- เพราะต้นทุนในการคงรักษาและแก้ไขบรรทัดของโค้ดสูง ผลลัพธ์ประเภทอื่นจึงพัฒนาได้ไม่เต็มที่
- เราขาดผลลัพธ์ที่จะใช้ทำความเข้าใจและถกเถียงกันว่าสถาปัตยกรรมกำลังเปลี่ยนอย่างไร
- ตัวสถาปัตยกรรมเองก็มักถูกอนุมานอย่างเลือนรางจากโค้ด
- ทิศทางในอุดมคติคือการอภิปรายและตกลงกันบน diagram ของสถาปัตยกรรมก่อน แล้วค่อยสร้างโค้ดใหม่จากการเปลี่ยนแปลงนั้น
- ไม่อาจฟันธงได้ว่าโค้ดทั้งหมดจะถูกสร้างโดย AI ตามสเปกจนข้ามความเข้าใจของมนุษย์ไปเลย
- ขอบเขตของความเป็นไปได้นั้นขึ้นอยู่กับว่า spec คืออะไร หรือสามารถกลายเป็นอะไรได้บ้าง
- ใครก็ตามที่เคยผ่าน database migration อันเจ็บปวดมาแล้ว ย่อมรู้ดีว่าการดึงและทำให้ความคาดหวังของผู้ใช้กลายเป็นรูปแบบที่เล่นซ้ำและทำอัตโนมัติได้ เป็นเรื่องยาก
- แม้เครื่องมือจะยังไม่พร้อม แต่แนวคิดที่เกี่ยวข้องมีอยู่แล้ว
- behavioral test, characterization test, capture/replay และ traffic splitter จากฝั่ง operation และ QA คือสิ่งเหล่านั้น
- เทคนิคเหล่านี้ใกล้เคียงกับการสังเกตและเข้ารหัสว่าในความเป็นจริงมีอะไรเกิดขึ้น มากกว่าการระบุว่าอะไร “ควร” ถูกต้อง
- observability ในความหมายที่ดี ก็อยู่ในกลุ่มนี้ด้วย
มนุษย์ไม่เหมาะจะเป็นด่านคุณภาพสำหรับการตรวจสอบ
- โค้ดที่ไม่เป็น deterministic ใน production บังคับให้เราต้องทำสิ่งที่ควรทำมาตั้งนานแล้ว
- trace instrumentation
- test และ eval บน production
- การปฏิบัติต่อ production ว่าเป็นขั้นตอนหนึ่งของการพัฒนา ไม่ใช่สิ่งที่อยู่หลังการพัฒนา
- สมองของมนุษย์ไม่เหมาะกับ การตรวจสอบความถูกต้อง
- ในงานที่ต้องคอยเช็กความต่างเล็ก ๆ ซ้ำ ๆ อย่างต่อเนื่อง มนุษย์สู้เครื่องจักรไม่ได้
- หากจำกัดบทบาทมนุษย์ไว้แค่ความสามารถในการเป็นด่านคุณภาพ คุณภาพซอฟต์แวร์ก็จะเปราะบาง
- มนุษย์อาจยังมีบทบาทได้นานในเรื่องความคิดสร้างสรรค์ แรงบันดาลใจ และการกระโดดทางตรรกะ แต่ยากที่จะวางมนุษย์ไว้ในฐานะผู้ชนะเครื่องจักรในงาน validation
บทสรุปของยุค AI คือการกลับมาของวินัย
- เหตุผลที่วาทกรรม AI ตลอด 2 ปีที่ผ่านมาให้ความรู้สึกแปลกแยกและน่ากังวลต่อวิศวกรจำนวนมาก เป็นเพราะเสียงบางส่วนในวงการ AI ฟังเหมือนกำลังบอกว่าซอฟต์แวร์ไม่ใช่ปัญหาทางวิศวกรรมอีกต่อไป
- “SaaS is dead”
- “Making AI great at coding was the strategy that unlocks everything else”
- Adam Jacob ถูกพูดถึงในฐานะคนที่คาดการณ์การเปลี่ยนแปลงครั้งใหญ่ของงานซอฟต์แวร์
- หากปี 2025 เป็นปีแห่ง vibe coding ปี 2026 ก็ดูเหมือนจะเป็น การกลับสู่วินัย
- เมื่อ AI สามารถสร้างบรรทัดของโค้ดได้พอ ๆ กับวิศวกรซอฟต์แวร์ระดับกลาง ขอบเขตของอนาคตที่เป็นไปได้ก็ขยายกว้างขึ้นอย่างไม่มั่นคง
- ความรู้ที่อยู่ในหัวจะยังถูก AI ใช้ไม่ได้ จนกว่าจะถูกเข้ารหัสลงในระบบ
- มีทีมซอฟต์แวร์น้อยมากที่ทำงานด้วยวงจร feedback ที่เร็วและสั้น
- สัดส่วนถูกประเมินไว้ราว 5% และแน่นอนว่าน้อยกว่า 10%
- เครื่องมือ AI อาจทำให้แนวทางนี้เข้าใกล้ความจริงได้มากกว่าเดิม
- ในระยะใกล้ ยังไม่ใช่เรื่องน่ากังวลว่า AI เพียงอย่างเดียวโดยไร้วินัยทางวิศวกรรมจะสร้างผลตอบแทนการลงทุนมหาศาลได้
- หลายทีมจะลองทำ แต่สิ่งที่มีคุณค่าไม่ได้ถูกรองรับด้วยความทิ้งได้ หากถูกรองรับด้วยความทนทาน
- ผู้ใช้ไม่ได้ต้องการให้ทุกวันที่ล็อกอินเข้า Slack แล้วปุ่มกับเมนูเปลี่ยนไปเล็ก ๆ น้อย ๆ
- และก็ไม่ต้องการให้ธุรกรรมการเงินสำเร็จแค่ในกรณีส่วนใหญ่
- determinism จะไม่หายไป
- AI ไม่ใช่เวทมนตร์ และซอฟต์แวร์ก็ยังคงเป็นงานวิศวกรรม
- เทคโนโลยียังต้องการ technologist
- ต่อจากนี้ สิ่งที่ต้องพิจารณาทบทวนจะไม่ใช่แค่บรรทัดของโค้ด แต่จะขยายไปสู่ผลลัพธ์ทางวิศวกรรมประเภทอื่นด้วย
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ตอนนี้แยกได้ยากขึ้นมากว่าใครคือคนที่เข้าใจระบบและ ใช้ AI ได้อย่างมีประสิทธิภาพ กับใครที่ไม่รู้อะไรเลยแล้วเอาแต่ก็อปวางจาก LLM
ก่อนปี 2025 คนที่ผลงานต่ำหรือแค่ประคองตัวไปวันๆ มักเห็นได้ค่อนข้างชัด เพราะมีส่วนร่วมน้อย แต่ตอนนี้วิศวกรทุกคนสามารถปั่น PR, รีวิวโค้ด, เอกสารออกแบบทางเทคนิค และอื่นๆ ที่ดูน่าเชื่อถือออกมาได้เป็นกอง
ส่วนหนึ่งก็เพราะแรงกดดันอย่างหนักจากผู้บริหารระดับ C ที่อยากให้ใช้ AI ให้มากที่สุด และในมุมของวิศวกรแต่ละคนเอง การผลิตออกมาให้มากที่สุดก็เป็น การตอบสนองเชิงทฤษฎีเกม ที่ได้เปรียบ
เรากำลังจมอยู่กับเอกสารและโค้ดที่ดูน่าเชื่อถือ และเพื่อจะจัดการปริมาณนั้นก็ต้องกลับไปพึ่ง AI อีก
แรงสะท้อนกลับของยุคนี้น่าจะกลายเป็น หนี้เทคนิค รูปแบบประหลาดที่เด่นชัดมากในระดับของขนาด
LLM ชอบผลิตอะไรออกมาเยอะๆ และชอบเพิ่มสิ่งใหม่เข้าไป แต่วิศวกรที่เก่งจริงจะสร้าง ผลลัพธ์ทางธุรกิจ ได้มากกว่าด้วยโค้ดที่น้อยกว่าและชิ้นส่วนที่ต้องขยับน้อยกว่า
ผมได้ยินบ่อยว่า “เราอยากใช้ AI ทำกระบวนการให้เป็นอัตโนมัติ แต่เอกสารกระบวนการยังไม่สมบูรณ์ เลยหวังว่า AI จะช่วยได้”
ต่อให้อธิบายว่าเราไม่สามารถสร้างผลลัพธ์จากความว่างเปล่าได้ บทสนทนาเรื่อง AI ทั้งหมดก็มักวนกลับมาที่จุดเดิม
แม้แต่ทางออกในการสร้างเอกสารเพื่อใส่เข้าไปในระบบอัตโนมัติด้วย AI ก็ยังกลายเป็นว่าให้ใช้ AI ทำอีก เหมือน อูโรโบรอส ที่ใช้ AI สร้างเอกสาร ใช้ AI สรุป แล้วให้ AI อธิบายอีกที
กับโค้ดก็จะเหมือนกัน คือใช้ AI สร้างออกมาหลายพันบรรทัด แล้วก็ใช้ AI มาอธิบายอีกที
ทุกวันนี้ด้วย LLM มันง่ายเกินไปที่จะดูเหมือนเป็นคนขยัน หากวัดจากปริมาณงานที่ส่งออกมา
ความต่างตอนนี้คือคนที่ไร้ความสามารถอาจผลิตผลลัพธ์ได้มากกว่าวิศวกรที่รอบคอบและมีประสบการณ์อย่างเป็นตัวเลขคนละหลายหลัก
PR ไม่ใช่ด่านที่สมบูรณ์แบบ แต่ก็เป็นแทบจะด่านเดียวที่เรายังมีอยู่ในตอนนี้ และค่อนข้างชัดว่าใครพยายามจริงและใครไม่พยายาม
ก็เพราะ คำถามอัลกอริทึม ในรอบสัมภาษณ์คงคัดคนที่แกล้งทำเป็นมีความรู้เรื่องระบบออกไปได้หมดแล้ว ไม่ใช่เหรอ?
ผมเห็นด้วยกับประโยคที่ว่า “นั่นไม่ใช่ปัญหาเรื่องโค้ด แต่เป็นปัญหาเรื่องการประเมิน” และ “โค้ดจะมีคุณค่าก็ต่อเมื่อความรู้มีอยู่แค่ในโค้ด”
การต้องอ่าน โค้ดที่ AI เขียน ทั้งวันเป็นเรื่องทรมาน และเป็นวิธีที่เลวร้ายในการทำให้สมองละลายในช่วงเวลาที่คนเราจำเป็นต้องมีความสามารถมากที่สุด
การเขียนโปรแกรมแบบลงมือเองมีวงจรป้อนกลับที่ทั้งมีประสิทธิภาพและน่าพอใจ คืออ่านโค้ด เขียนโค้ด คอมไพล์หรือรัน แล้วแก้จนมันทำงานหรือทำสิ่งที่ต้องการ
โค้ดจาก AI ไม่เพียงมาแทนที่ไปครึ่งหนึ่งของวงจรนี้ แต่ยังทำให้จังหวะ “คลิก” สุดท้ายไม่น่าประทับใจเท่าเดิม เพราะเราไม่แน่ใจว่าระหว่างทางเราได้แอบหลอกอะไรบางอย่างไปหรือเปล่าเพื่อให้ไปถึงจุดนั้น
การยึดโค้ดที่ AI สร้างเป็นผลผลิตถาวรเพียงอย่างเดียวของการเขียนโปรแกรมคือทางตันของอุตสาหกรรม
สิ่งที่ Charity ชี้ว่าเป็นพื้นที่ทำงานที่น่าสนใจ และควรถูกทิ้งอย่างถูกต้อง คือแผนภาพสถาปัตยกรรมและสเปก
ผมสงสัยว่ามันน่าจะใกล้กับ พรอมป์ต์ แผนใน Markdown และข้อความชี้นำ ที่มนุษย์เขียนเองมากกว่า
เราควรโฟกัสกับสิ่งที่มนุษย์สร้างขึ้นด้วยตัวเอง เพราะนั่นเป็นฐานของลูปสำคัญว่า “AI ทำตามคำสั่งของฉันหรือไม่” และยังเป็นคานงัดที่มีประสิทธิภาพสูงกว่าในการรีวิวโค้ดด้วย
พอถึงจุดที่กลายเป็น PR แล้ว คุณก็น่าจะป้อนข้อมูลให้ Claude มากพอที่จะสร้างโค้ดขึ้นมาใหม่ได้อยู่แล้ว แต่ค่าปริยายของอุตสาหกรรมตอนนี้คือทิ้งเซสชันทั้งหมดนั้นไป แล้วปล่อยเฉพาะโค้ด ซึ่งกลับหัวกลับหางมาก
ก้อนโค้ดขนาดใหญ่เป็นสิ่งที่มนุษย์แทบรีวิวไม่ได้อยู่แล้ว แต่พอมี LLM เข้ามาเกี่ยว หลายคนเหมือนจะลืมข้อเท็จจริงนี้ไป
ทุกวันจะมีกองโค้ดมหาศาลส่งมาให้รีวิว แล้วมันเหนื่อยมาก
ถึงอย่างนั้น AI ก็ยังรู้สึกดีกว่า เพราะถ้าเขียนกฎไว้ มันก็ยังมีแนวโน้มจะทำตาม
นักพัฒนาออฟชอร์จำนวนมากกลับทำผิดแบบเดิมซ้ำทุกวัน
ดูเหมือนบริษัทเราน่าจะต้องจ้างนักพัฒนาออฟชอร์ที่ดีกว่านี้
เมื่อก่อน ส่วนหนึ่งของแบบจำลองทางความคิดเกี่ยวกับระบบที่ผมสร้างขึ้นมาผ่านการเขียนโค้ด ตอนนี้กลับต้องอาศัย การรีวิวโค้ด เพื่อประกอบมันขึ้นมา
การเข้าใจและจดจำรายละเอียดของระบบกำลังยากขึ้น ซึ่งก็ไม่น่าแปลกใจ เพราะข้อมูลที่เรา “สร้างขึ้น” เองมักจำได้ดีกว่าข้อมูลที่แค่อ่าน
ผมกำลังนำบทเรียนจากศาสตร์ด้านการศึกษามาใช้กับการขยายบทบาทของการรีวิวโค้ด และถ้าประเด็นนี้โดนใจคุณ ผมก็อยากคุยต่อ
วิธีแก้ขัดคือลองให้ Claude เขียนสรุปเซสชันเป็นส่วนหนึ่งของข้อความคอมมิตได้ แต่ผมอยากรู้ว่ามีเครื่องมือที่เป็นระบบกว่านี้และอยู่ในระดับที่สูงกว่านี้หรือไม่
ถ้าคุณต้องการโค้ดที่ตรวจสอบได้และสอดคล้องกับแผนที่ออกแบบไว้อย่างดี คุณแทบต้องเขียน ซูโดโค้ด แล้วให้ AI แปลให้อยู่ดี
ถ้าอย่างนั้นก็ชวนให้สงสัยว่าตั้งแต่แรกจะให้ AI เขียนโค้ดไปทำไม
สำหรับผม การวางแผนเอง เขียนเอง และดีบักเองสนุกกว่า นั่นแหละคือสิ่งที่ทำให้ผมชอบการเขียนโปรแกรมตั้งแต่แรก
ช่วงนี้ฉันคิดเรื่องนี้อยู่บ่อยมาก
สัญชาตญาณส่วนใหญ่ของฉันเกี่ยวกับการพัฒนาซอฟต์แวร์ตั้งอยู่บนประสบการณ์ 25 ปีว่า “การเขียนโค้ดบางอย่างใช้เวลานานแค่ไหน”
เวลาลังเลว่าจะเพิ่มการตรวจสอบ edge case ที่ไม่ได้ทำให้ทั้งระบบพัง แต่ถ้าใครไปเจอเข้าก็จะทำให้ดูเลอะเทอะนิดหน่อยดีไหม ถ้าต้องเสียเวลาเขียนโค้ดเพิ่มอีกหลายชั่วโมงก็อาจจะข้ามไป
แต่ถ้าใช้แค่พรอมป์ต์เดียว แล้วทำไมจะไม่ทำล่ะ?
ถ้าจะทำให้ฟีเจอร์ใหม่เข้าใจง่ายขึ้น การมี API explorer เฉพาะก็คงดี แต่เมื่อก่อนคงอธิบายความคุ้มค่าของการลงทุนไม่ได้
แต่ถ้าใช้เวลา 10 นาทีด้วย Codex เรื่องก็เปลี่ยนไป และมันก็เป็นแบบนั้นจริง ๆ: https://tools.simonwillison.net/datasette-extras-explorer#ur... และมีลิงก์ใน release notes ด้วย https://docs.datasette.io/en/latest/changelog.html#extra-sup...
ในสเกลที่ใหญ่กว่านั้น ก็มีโปรเจ็กต์ที่เมื่อก่อนฉันไม่เคยคิดจะพิจารณาเลย แม้ว่าจะต้องมีไลบรารีสำหรับ parse custom SQLite
SELECTquery แต่ก็ไม่คุ้มจะทุ่มเวลาเกินหนึ่งสัปดาห์แต่ตอนนี้ทำได้แล้ว: https://github.com/simonw/sqlite-ast
พอพูดว่าการผลิตบรรทัดโค้ดได้เร็วขึ้นมีคุณค่า ผู้คนก็มักจะโกรธมากและดูแคลน
แน่นอน การวัดผลงานด้วย “จำนวนบรรทัดโค้ด” เป็นเรื่องโง่
แต่การวัด จำนวนบรรทัดโค้ดที่ผ่านการพิสูจน์แล้วว่าส่งมอบคุณค่าได้ ไม่ใช่เรื่องโง่ และตอนนี้เราทำสิ่งนั้นได้เร็วขึ้น
เหตุผลที่ Google มีคุณค่าก็เพราะมันดูดข้อมูลไปสร้างรายได้จากโฆษณา และมีค่าใช้จ่ายต่ำเมื่อเทียบกับรายได้
แล้ว “การเดิมพัน” ทั้งหมดนั้นล่ะ? ตลกดี สุดท้ายเป็นยังไงบ้าง?
วิศวกรรมเพื่อวิศวกรรมเองไม่มีคุณค่าทางเศรษฐกิจเลย พูดอีกอย่างก็คือไม่มีความหมาย
ความจริงอันเย็นชาที่ไม่มีใครอยากฟังคือ สิ่งที่สามารถดำรงอยู่ได้ในระบบเศรษฐกิจ ณ ช่วงเวลาใดช่วงเวลาหนึ่งมีอยู่อย่างจำกัด และมีแต่สิ่งที่มีคุณค่าและยั่งยืนทางเศรษฐกิจเท่านั้นที่อยู่รอด
หลายคนไม่สนใจ แต่ก็มีคนที่สนใจเหมือนกัน
ฉันชอบบทความนี้ และดูเหมือนคอมเมนต์อื่น ๆ หลายอันจะไม่คิดแบบนั้น เลยขอเขียนความเห็นของตัวเองไว้
เวลาเริ่มเข้าไปใน codebase ใหม่ จะทำอย่างไรให้กลายเป็นผู้มีส่วนร่วมที่ช่วยงานได้เร็วที่สุด? ฉันจะไปหาคนและเอกสารที่คนเขียนไว้ก่อนเลย
เพื่อดูว่าระบบนี้เดิมตั้งใจจะแก้ปัญหาอะไร แบบออกแบบเดิมเป็นอย่างไร ปัญหาใหญ่ที่สุดคืออะไร และตอนนี้ใครเป็นคนใช้งานมัน
ถ้ารู้สิ่งเหล่านี้ ก็จะพอเดาได้ว่าทำไมมันถึงถูกสร้างมาแบบนั้น ทำให้อ่านโค้ดได้ง่ายขึ้นมาก
บล็อกโพสต์นี้ก็ได้รับความนิยมเช่นกัน: https://blog.gpkb.org/posts/just-send-me-the-prompt/
ดูเหมือนว่า Charity กำลังมองปัญหาที่เก่าแก่มาก แล้วคาดหวังว่าเทคโนโลยีใหม่จะนำไปสู่ทางแก้แบบใหม่บางอย่าง
ฉันไม่คิดว่าเครื่องมือรุ่นปัจจุบันคือบทสรุปสุดท้ายของเรื่อง AI กับการพัฒนาซอฟต์แวร์
และไม่ได้หมายความว่าแค่โยนเอกสารออกแบบให้ Claude code แล้วเดินจากไป เอกสารออกแบบเองก็ไม่สมบูรณ์ ตอน onboarding จึงยังต้องคุยกับคน และอ่านตั๋วงานเก่า ๆ กับ postmortem ด้วย
ใน production เราทำ Infrastructure as Code กันอยู่ตอนนี้ เพราะเราไม่ชอบการที่รู้ได้ยากว่าโครงสร้างพื้นฐานมาอยู่ในสภาพปัจจุบันได้อย่างไร
codebase ก็เช่นกัน สภาพพื้นฐานคือ “รู้ได้ยากว่าทำไมมันถึงกลายมาเป็นแบบนี้” และนี่เป็นปัญหาที่ถูกสังเกตเห็นมาตั้งแต่ก่อน “Programming as Theory Building” แล้ว
เพราะฉะนั้น เหมือนกับฝั่ง infrastructure ฉันคาดว่าการพัฒนาซอฟต์แวร์ก็จะเปลี่ยนไปสู่เครื่องมือที่ช่วยให้เห็นชัดขึ้นว่า “ทำไมโค้ดถึงมาอยู่ในสภาพปัจจุบัน”
วิธีเริ่มจากคนและเอกสารที่คนเขียนไว้ก่อนเมื่อเข้า codebase ใหม่เป็นแนวทางที่ถูกต้อง แต่ในหลายทีมวิศวกรรมกลับไม่มีเอกสารแบบนั้นอยู่เลย
การตัดสินใจถูกทำอยู่ในหัวของวิศวกรคนใดคนหนึ่ง หรือในแชตที่ไม่ได้ถูกเก็บไว้ ส่วนสเปกก็อาจเป็นโน้ตไม่กี่บรรทัดในตั๋วงานที่ถูกลบระหว่างการเก็บกวาด หรือหายไปตอนเปลี่ยนระบบติดตามงาน
ไม่มีทั้งแผนที่ของ codebase หรือฟีเจอร์ ไม่มี ADR และมี observability แค่น้อยนิด
สุดท้ายเหลือแค่โค้ด คุณเลยต้องอ่านโค้ดเพื่อหาว่าเกิดอะไรขึ้น และไปถามวิศวกรที่เพิ่ง commit ในส่วนนั้นว่าเขายังจำได้ไหมว่าทำไมถึงทำแบบนั้น
แล้วพอมีใครเปลี่ยนอะไรบางอย่าง โค้ดอีกฟากหนึ่งของ codebase ที่คิดว่าไม่เกี่ยวกันเลยก็อาจพังได้
จริงอยู่ว่า AI ต้องการวินัยมากขึ้น แต่ในทางทฤษฎี วินัยแบบนั้นเรียนรู้ได้ง่ายกว่าการเป็นวิศวกรที่ดีมาก
เมื่อ 20 ปีก่อน ถ้าจะเขียนโค้ด C ที่ขยายระบบได้ดี คุณต้องเป็นอัจฉริยะ หรือไม่ก็ทุ่มเทชีวิตให้กับเทคโนโลยีนั้น
คุณต้องรู้จักเครื่องมือมากมายอย่าง ASan, LSan, UBSan, TSan, GDB แบบทะลุปรุโปร่ง และถ้าต้องถึงขั้นอ่านไฟล์ DWARF เองก็ยิ่งโหดเข้าไปอีก
ในเวลาสั้น ๆ แทบเป็นไปไม่ได้ที่จะเชี่ยวชาญสิ่งพวกนี้ และในเวลาเดียวกันก็ยังต้องเรียนรู้การออกแบบระบบ ซึ่งเป็นทักษะแยกอีกชุดหนึ่งที่แทบตั้งฉากกัน
ตอนนี้แค่รู้จุดเสี่ยงของภาษาและเฟรมเวิร์กที่ใช้ สั่งให้ LLM ทดสอบจุดเหล่านั้น มี infrastructure สำหรับตรวจว่าทดสอบเพียงพอหรือยัง แล้วอ่านการทดสอบจริงกับตัว implementation ก็พอ
การอ่านและเข้าใจ Rust ง่ายกว่าการ debug ข้อผิดพลาดชวนงงเหมือนเวทมนตร์ที่เกิดขึ้นระหว่างการพัฒนา Rust มาก
การมองออกว่าในบางสถานการณ์ต้องมี Loom test และการทำเครื่องมือเพื่อตรวจว่ามีการเขียนมันจริงหรือไม่ ก็ง่ายกว่าเช่นกัน
ต่อให้ยังใช้ C หรือ Zig ต่อไป การรู้ว่าเมื่อไรควรใช้เครื่องมือแต่ละตัวและตรวจจับให้ได้ ก็ง่ายกว่าการต้องไปเชี่ยวชาญทุกเครื่องมือแบบแยกกันมาก
การอ่าน SQL ไม่ใช่เรื่องยาก และคนทำธุรกิจแทบครึ่งหนึ่งก็ทำได้ Python ยากกว่าแค่นิดเดียว ส่วน Rust ก็พอเข้าใจได้ถ้าอ่านคู่มือ 50 หน้า ซึ่งเป็นราคาที่เล็กมากเมื่อเทียบกับการเสียเวลา 10 ปีไปกับการลองผิดลองถูก
เส้นทางจาก “LLM ทำงานในแบบที่เราไม่อาจรู้ได้” ไปสู่ “ดังนั้นจึงต้องมีวินัยมากขึ้น” แล้วต่อไปยัง “ทุกอย่างโอเค” มันไม่ได้ชัดเจนสำหรับฉัน
ฉันเห็นด้วยว่าทุกอย่างโอเค แต่ไม่คิดว่ากระบวนการคิดนั้นเป็นเส้นทางที่ชัดเจน
ถ้าใครมีความตั้งใจจะทำให้มันใช้ได้จริง และยอมใช้เวลาสักหน่อยเพื่อเข้าใจว่าอะไรทำให้มันล้มเหลว คนคนนั้นก็สามารถใช้ LLM ทำเรื่องใหญ่มาก ๆ ได้
เพราะ LLM ทำให้ต้นทุนในการสร้างของซับซ้อนลดลงจนแทบฟรี มันจึงน่าจะยิ่งทำให้สถานการณ์ซับซ้อนขึ้นไปอีกมาก
วิศวกรรมเป็นเรื่องของวินัยและการทำให้สิ่งต่าง ๆ ใช้งานได้มาโดยตลอด แต่เมื่อก่อนถ้าจะสร้างคุณค่าได้ คุณต้องมีชุดทักษะพื้นฐานจำนวนมากก่อน
ตอนนี้สิ่งเหล่านั้นส่วนใหญ่หายไปแล้ว และมันง่ายกว่าเดิมมาก
วินัยยังจำเป็นอยู่ แต่เมื่อเทียบกับการคลุกไฟอยู่ 10 ปี ฉันมองว่า วินัยนั้นราคาถูก
เมื่อกี้ฉันเพิ่งใช้เวลาหนึ่งสัปดาห์รีวิว PR ประมาณ 200 บรรทัดนี้: https://github.com/ncruces/wasm2go/pull/37
มันถูกส่งมาโดยผู้ใช้ที่มีประสบการณ์ และมีความเป็นไปได้สูงว่าเขาถาม LLM ระดับแนวหน้ามาด้วย
ถึงอย่างนั้นมันก็ยังให้ความรู้สึกว่ามีบางอย่างผิด ฉันไม่เข้าใจมัน และก็ไม่คิดจะ merge มันทั้งที่ยังไม่เข้าใจ
ฉันยังสงสัยด้วยว่ามันน่าจะผิดในแบบที่จะก่อปัญหาในอนาคต
เลยรีวิวมันด้วยสี่วิธี: ทำความเข้าใจและปรับปรุงมัน, ทำใหม่ด้วยอัลกอริทึมที่ดีกว่า, แก้ปัญหาที่ upstream เพื่อจะได้หลีกเลี่ยงมัน, และเขียนใหม่ตั้งแต่ต้นให้เข้ากับวิธีคิดของฉัน
เดิมฉันคิดว่าคำตอบคงเป็นข้อสองหรือข้อสาม แต่ข้อสองแม้จะเป็นคำตอบที่ถูกต้อง ทว่าถ้าจะใช้ก็ต้องทำโปรเจกต์ใหม่ตั้งแต่ต้น ส่วนข้อสามฉันหวังมากว่าจะได้ผล แต่มันไม่ได้ผล
สุดท้ายเลยต้องผสมข้อหนึ่งกับข้อสี่ และถึงตอนนี้ฉันก็ยังไม่มั่นใจเต็มร้อย แต่ตอนนี้เข้าใจทั้งปัญหาและวิธีแก้แล้ว
แน่นอนว่าฉันย่อมคิดว่าวิธีของฉันดีกว่า
ถึงอย่างนั้น ฉันก็ให้ LLM รีวิวทั้งสองฝั่งหลังจากลบคอมเมนต์ออกแล้ว
LLM ตอบว่า PR เดิมดีกว่าอย่างชัดเจน และพอฉันอธิบายว่าทำไมถึงไม่ใช่ มันก็ตอบว่าฉันถูก
ถ้าใส่คอมเมนต์กลับเข้าไปแล้วลองใหม่ พวก LLM จะบอกว่าของฉันดีกว่า เพราะฉันเจอปัญหาที่แท้จริง
แต่ฉันก็ไม่รู้ว่าที่มันบอกว่าของฉันดีกว่า เป็นเพราะฉัน ชี้นำให้มันพูดแบบนั้น หรือเปล่า
พออ่านแล้วรู้สึกว่าเหมือนลืมสุภาษิตที่ว่า “All models are wrong” ไป
นี่ก็เป็นความผิดพลาดที่คนชอบ RPG แบบ “สมจริง” และ “จำลองสถานการณ์” มักทำกันบ่อย
ถ้าคุณจำลองบางสิ่งได้ครอบคลุมมากพอ โมเดลนั้นก็จะกลายเป็นสิ่งนั้นเอง
ถ้าจะสร้างโมเดลของสถานที่ที่มีรายละเอียดครบทุกอย่างของสถานที่จริง คุณก็ต้องใช้โมเดลสเกล 1:1 ซึ่งสุดท้ายก็คือสำเนาของสถานที่นั้น
พรอมป์ต์ต่อโมเดลที่มีการวางแผนมากพอจะจำลองการทำงานของระบบได้อย่างน่าเชื่อถือ 100% ก็น่าจะเป็น ซอร์สโค้ด ของระบบนั้นเอง
ฉันมักสงสัยว่า IT และการเขียนโปรแกรมจำนวนมาก แท้จริงแล้วก็แค่การเอาชิ้นส่วนที่เข้าใจดีอยู่แล้วมาต่อเข้าด้วยกันหรือเปล่า
เมื่อ 8 ปีก่อน ฉันเคยคิดว่าทำไมเราถึงแทนที่ LLVM ด้วยระบบที่ง่ายกว่ามาก และแทนที่การปรับแต่งด้วยมือด้วย “ตัวปรับแต่ง” AI แบบง่าย ๆ ไม่ได้
ฉันมองว่าแค่ฝึกมันให้แปลงโค้ดคอมไพล์แบบธรรมดาให้เป็นโค้ดที่ “ปรับแต่งแล้ว” ก็น่าจะพอ แต่ฉันทามติในตอนนั้นคือ ระบบ AI ยังยากที่จะสร้างโค้ดที่ถูกต้องได้อย่างน่าเชื่อถือพอสำหรับการใช้งานจริง
ถ้า AI ยังแทนที่ โค้ดระดับล่าง แบบนั้นไม่ได้ ปัญหาระดับสูงกว่าก็ควรจะยิ่งอยู่อีกไกลมาก
แต่ผู้คนกลับใช้ AI กับปัญหาระดับสูง
สมมติฐานของฉันคือ งานวิศวกรรมดิจิทัลสมัยใหม่จำนวนมากเป็นแบบ plug-and-play
จำได้ว่าก่อนปี 2023 บน HN ทุกคนยกย่องว่าการลดจำนวนบรรทัดโค้ดคือสัญญาณของความเป็นซีเนียร์ที่ทรงพลังที่สุด
เพียงแต่กระแสโค้ดจำนวนมหาศาลจาก LLM มันแรงเกินกว่าจะว่ายทวนแล้วชนะได้
และฉันก็ไม่เห็นด้วยกับสมมติฐานของบทความที่ว่า LLM เขียนโค้ดดีได้
มันเขียนโค้ดที่ทำงานได้ แต่ดูเหมือน Demogorgon เป็นคนเขียน จนอ่านแล้วรู้สึกคลื่นไส้นิด ๆ
มันแย่ แต่แย่ในแบบที่มนุษย์ไม่มีวันเขียน
มันไม่เหมือนความรู้สึกเวลาอ่านสปาเกตตีโค้ดที่นักพัฒนาจูเนียร์เขียน แต่เป็นความน่าขยะแขยงแบบเหมือนไข่ของ Cthulhu กำลังฟักตัวอยู่ลึก ๆ ในท้อง
ฉันจำได้ว่าที่บริษัทเก่า มีซีเนียร์คนหนึ่งตั้งแต่เข้ามาทำงานจนได้เป็นผู้จัดการ เขาแทบทำแค่ลบโค้ดออกอย่างเดียว
บทความนี้อ่านไม่สนุก
ตัวประโยคเองหรือแต่ละย่อหน้าก็ใช้ได้ แต่พอมองทั้งชิ้นแล้วมันกระจัดกระจาย และพูดตรง ๆ คือดูไร้ความหมาย
มีคำอยู่มากจริง แต่สิ่งที่พูดจริง ๆ ดูน้อยเกินไป
ตัวอย่างเช่น การบอกว่าเศรษฐศาสตร์ของการผลิตโค้ดกลับหัวในปี 2025 นั้นไม่แม่นยำ
แต่ก่อนถ้ากระบวนการผลิตเป็นแบบเพิ่มเข้าไปอย่างเคร่งครัดเหมือน 3D printing ตอนนี้มันใกล้เคียงกับการมีวิธีแบบลบออกอย่าง CNC milling เข้ามาเสริมมากกว่า
“รูปทรง” ที่ต้องการไม่ได้เปลี่ยนไปมากนัก และถ้าคุณยังใส่ใจกับค่าความคลาดเคลื่อนบางอย่าง ความพยายามของมนุษย์ก็ไม่ได้เปลี่ยนไป
เรายังต้องให้คุณค่ากับผลิตภัณฑ์ นำกลับมาใช้ซ้ำ ดูแล และคิวเรตมัน เท่าที่ตลาดยังต้องการอยู่
ฉันก็ไม่เห็นด้วยกับคำพูดที่ว่า “จำนวนบรรทัดโค้ดไม่ใช่ผลลัพธ์ที่เหมาะที่สุดสำหรับการรีวิว”
คำว่า “เหมาะที่สุด” ที่นี่หมายถึงอะไร?
ตอนเด็ก ๆ ในการสอบทุกครั้งมีกฎว่า “แสดงวิธีทำ”
เหตุผลคือไม่ใช่แค่เพื่อผลิตภัณฑ์ที่จะออกพรุ่งนี้ แต่เพื่อพัฒนาแบบจำลองทางความคิดและกระบวนการคิดของคนรุ่นถัดไปด้วย
ภาษาตามได้ยากมากจริง ๆ และประเด็นหลักของบทความก็ไม่เด่นชัด
พอเห็นบทความแบบนี้ ฉันยิ่งสงสัยคำพูดที่ว่า งานซอฟต์แวร์เอนจิเนียร์ จะหายไป
งานของซอฟต์แวร์เอนจิเนียร์ในปี 2026 ต่างจากปี 2020 อยู่แล้ว และยิ่งไม่ต้องพูดถึงปี 1990 แล้วทำไมเราต้องเชื่อการแบ่งแบบปลอม ๆ ว่างานในปี 2026 จะคงเดิมทั้งหมดหรือหายไปทั้งหมดอย่างใดอย่างหนึ่งด้วย?
เมื่อนานมากแล้วตอนทำงานที่ Google ความคิดเรื่องการรีวิวโค้ดทุกชิ้นเป็นเรื่องใหม่สำหรับฉัน
ก่อนหน้านั้นที่ MS โค้ดจะถูกเขียนลง CD แล้วใส่กล่อง ดังนั้นส่วนใหญ่จึงไม่ถูกรีวิวจนถึงช่วงท้ายโปรเจกต์ซึ่งมีความเสี่ยงสูง
ระหว่างปี 2000 ถึง 2004 วิธีที่ซอฟต์แวร์เอนจิเนียร์ใช้เวลาทำงานเปลี่ยนไปอย่างรวดเร็ว และฉันคิดว่ามันดีขึ้นเพราะเพิ่มความเข้าใจร่วมกันและส่งเสริมการทำงานร่วมกัน
ถ้า AI เขียนโค้ดและมนุษย์ใช้เวลารีวิวมากขึ้น มันก็อาจไม่ใช่เรื่องแย่ไปเสียทั้งหมด
แต่ถ้าโค้ดจาก AI ดีพอ ผู้คนก็จะเริ่มมองว่าการรีวิวอย่างละเอียดเป็นทางเลือก
ถ้าเป็นแบบนั้น งานของซอฟต์แวร์เอนจิเนียร์ก็จะต่างจากเดิมมาก และจะไม่ได้ทั้งเขียนโค้ดเยอะหรือใช้เวลารีวิวมาก
IDE อาจหายไปเหมือนนกโดโดก็ได้
จุดโฟกัสอาจย้ายไปอยู่ที่การตั้งเป้าหมายและการตั้งค่าการทดสอบ เพื่อให้ทีมเขียนโค้ด AI ไม่ออกนอกโจทย์
ซอฟต์แวร์เอนจิเนียร์ที่รู้ดีว่าโปรเจกต์กำลังมุ่งไปทางไหน อาจใช้เวลากับสถาปัตยกรรมมากขึ้น เพราะเมื่อปลายทางเปลี่ยนไปอย่างมีเหตุผล คุณคงไม่อยากให้ AI เขียนนั่นเขียนนี่ใหม่ไปหมด
อาจใช้เวลากับการสำรวจมากขึ้นด้วย เช่น สร้างแบบหนึ่ง สร้างอีกแบบหนึ่ง แล้วอีกแบบหนึ่ง จากนั้นค่อยนำมาเปรียบเทียบและสร้างไอเดียใหม่จากแนวทางที่ต่างกัน
ฉันไม่ได้มีคำทำนายที่ดีกว่าใคร แต่ฉันคัดค้านอย่างหนักกับแนวคิดที่ว่าบทบาทนี้จะหายไป และเห็นด้วยว่ามันจะวิวัฒน์เหมือนที่เคยเป็นมาหลายครั้ง เพียงแต่อาจไม่เคยเร็วเท่าครั้งนี้
ฉันไม่คิดว่าคำพูดที่ว่า “ผู้คนมองว่าโค้ดเป็นสิ่งถาวรเพราะแรงงานในการผลิตโค้ดคือคอขวด” จะถูกต้อง
คนมองว่าโค้ดเป็นสิ่งถาวร เพราะมองโค้ดว่าเป็น แหล่งความจริง
คอมพิวเตอร์ไม่ได้รันเอกสาร แต่มันรันโค้ด
ถ้าเอกสารความต้องการขัดแย้งกับโค้ด โดยปกติเราจะถือว่าเอกสารความต้องการผิด
แยกโค้ดออกจากสเปกไม่ได้ เพราะ โค้ดก็คือสเปก นั่นเอง