- บทความนี้นำเสนอ หลักการด้าน context engineering และเวิร์กโฟลว์การทำงานจริง เพื่อให้โมเดลภาษารุ่นใหม่สร้างผลงานได้ใน production codebase ขนาดใหญ่
- แกนสำคัญคือ Frequent Intentional Compaction ซึ่งเป็นการจัดโครงสร้างและบีบอัดคอนเท็กซ์ตลอดกระบวนการพัฒนา เพื่อทำให้คุณภาพการตัดสินใจและ trajectory ของเอเจนต์มีเสถียรภาพ
- ใช้กระบวนการ 3 ขั้นคือ วิจัย→วางแผน→ลงมือทำ เพื่อสร้าง เอกสารผลลัพธ์จากการวิจัยล่วงหน้าและเอกสารแผนงาน พร้อมวางการตรวจทานโดยมนุษย์ไว้ในจุดที่มี leverage สูง เพื่อลด slop และงานแก้ซ้ำ
- พิสูจน์ให้เห็นว่าใช้ได้จริงแม้ใน สภาพแวดล้อมแบบ brownfield ผ่านกรณีของ BAML ที่สร้างด้วย Rust ขนาด 300,000 LOC ซึ่งสามารถทำงานซับซ้อนอย่าง แก้บั๊ก และเพิ่มการรองรับ cancel/WASM ได้ภายในเวลาสั้น
- สรุปคือ AI coding ไม่ใช่ของเล่น แต่เป็น งานวิศวกรรมเชิงช่างฝีมือที่ประณีต และ การเปลี่ยนผ่านด้านกระบวนการ/วัฒนธรรม ในระดับทีมคือปัจจัยชี้ขาดความได้เปรียบในการแข่งขัน
พื้นหลัง: ข้อจำกัดของ AI และโจทย์สำคัญในโค้ดเบสที่ซับซ้อน
- นักพัฒนาส่วนใหญ่ทราบดีว่า เครื่องมือ AI coding มักทำงานได้ไม่ดีอย่างที่คาดใน production codebase จริง
- มีงานวิจัยที่ชี้ว่าเครื่องมือ AI coding อาจทำให้ผลิตภาพลดลงเมื่อเจอกับโค้ดเบสขนาดใหญ่และ งานที่ซับซ้อน
- งานวิจัยของ Stanford พบว่าโค้ดส่วนใหญ่ที่ AI เพิ่มเข้ามา กลับเป็นการย้อนมาแก้โค้ดที่ AI เคยสร้างไว้อย่างไม่ดีอีกครั้ง จนก่อให้เกิด งานวนซ้ำ
- เอเจนต์ AI coding มีประสิทธิภาพกับโปรเจกต์ใหม่หรือการเปลี่ยนแปลงเล็กน้อย แต่ในโค้ดเบสขนาดใหญ่อาจกลับทำให้ผลิตภาพของนักพัฒนาลดลง
- เพราะแบบนี้ ปฏิกิริยาในภาคสนามจึงมักเป็นท่าทีระมัดระวังว่า “ตอนนี้ยังยากอยู่ ถ้า มีโมเดลที่ฉลาดกว่านี้ออกมา ค่อยว่ากัน”
- แต่เมื่อทดลองใช้ context engineering กับโค้ดเบส Rust ขนาดใหญ่ระดับ 300,000 LOC จริง ก็พบว่าแม้ใช้เพียงโมเดลที่มีอยู่ ก็สามารถยกระดับทั้งผลิตภาพและคุณภาพเกินมาตรฐานตลาดได้
- แก่นหลักคือ frequent intentional compaction หรือการทำให้คอนเท็กซ์ที่ป้อนให้ AI มีโครงสร้างและถูกจัดการอย่างต่อเนื่องตลอดกระบวนการพัฒนา
- ท้ายที่สุดแล้ว ‘AI coding’ คือพื้นที่ที่ต้องอาศัย ความประณีตเชิงช่างทางเทคนิค
รากฐานทางความคิด: “Specs are the new code” และงานวิจัยด้านผลิตภาพ
- การบรรยาย 2 หัวข้อใน AI Engineer 2025 เป็นตัวผลักดันการเปลี่ยนวิธีคิดนี้
- ในการบรรยาย Sean Grove's "Specs are the new code" มีการเสนอว่าให้ “เลิกใช้ conversational prompt แล้ว เก็บสเปกไว้เป็นโค้ด”
- แนวปฏิบัติที่ทิ้ง prompt แล้ว commit แค่โค้ดผลลัพธ์ ถูกเปรียบเหมือน การ check-in แค่ไบนารีโดยไม่มีซอร์ส
- งานวิจัยของ Stanford เรื่องผลกระทบของ AI ต่อผลิตภาพนักพัฒนา ชี้ว่าแม้ AI จะเพิ่มผลลัพธ์ระยะสั้น แต่ คุณภาพที่ลดลงและงานแก้ซ้ำ อาจทำให้ผลสุทธิหายไป
- จากการวิเคราะห์ commit ของนักพัฒนา 100,000 คน พบปรากฏการณ์ที่เครื่องมือ AI เพิ่มงานแก้ซ้ำจนหักล้างประโยชน์ด้านผลิตภาพ
- มีข้อสังเกตว่าแม้จะได้ผลในงาน greenfield แต่ใน brownfield และ งานยากระดับสูง มักเกิดผลลัพธ์ด้านลบบ่อยครั้ง
หลักการ: แนวคิดของ Frequent Intentional Compaction
- จัดการ context window ให้อยู่ราว 40–60% ตลอดเวลา และใช้ กลยุทธ์การบีบอัดอย่างต่อเนื่อง เพื่อลดทั้งข้อมูลล้น ข้อมูลตกหล่น และข้อมูลผิดพลาด
- สิ่งที่ควรถูกบีบอัดคือ noise อย่าง บันทึกการค้นหาไฟล์, การไล่ตาม flow ของโค้ด, ประวัติการแก้ไข, log การทดสอบ/บิลด์, JSON ขนาดใหญ่ เป็นต้น
- เก็บผลลัพธ์ของแต่ละขั้นไว้เป็น structured artifact เพื่อรับประกันคุณภาพของอินพุตในเทิร์นถัดไป
- เช่น สร้างเอกสาร progress ที่บันทึกสรุปความคืบหน้า เป้าหมายและแนวทาง ขั้นที่เสร็จแล้ว และ จุดที่ยังล้มเหลวอยู่ในปัจจุบัน
เวิร์กโฟลว์: Research → Plan → Implement
- ในขั้น Research จะสำรวจไฟล์ที่เกี่ยวข้อง flow ต่าง ๆ และสมมติฐานของสาเหตุ เพื่อสร้าง เอกสารสรุปการวิจัย
- หากจำเป็นสามารถใช้ sub-agent เพื่อสำรวจขอบเขตและสรุปผลในคอนเท็กซ์ใหม่ที่สดสะอาดได้
- ในขั้น Plan จะเขียน แผนการ implement ที่อธิบายอย่างละเอียดถึงไฟล์ที่จะต้องแก้ วิธีเปลี่ยนแปลง และ ขั้นตอนการตรวจสอบ/ทดสอบ
- แผนนี้ถูกใช้เป็นจุดตรวจทานที่ ให้ leverage สูงกว่าการรีวิวโค้ด
- ในขั้น Implement จะลงมือทำตามแผนทีละขั้น และหลังตรวจสอบแต่ละขั้นแล้วจะ บีบอัดสถานะกลับเข้าเอกสารแผน เพื่อสะสมเป็นบริบทต่อเนื่อง
- งานที่ซับซ้อนจะมีการ จัดเรียงคอนเท็กซ์ใหม่ ทุกครั้งที่รวมผลของแต่ละช่วง
แพตเทิร์นที่ควรหลีกเลี่ยงและการยกระดับแบบค่อยเป็นค่อยไป
- แนวทางแบบ naive มีปัญหาที่คอนเท็กซ์ในกระแสการคุยแบบแชตจะปนเปื้อน จนนำไปสู่วงจรขอโทษหรือหลุดประเด็น
- วิธีที่ดีขึ้นเล็กน้อยคือ รีเซ็ตเซสชัน และเพิ่ม “prompt คำสั่งเสริม” แต่ก็ยัง ควบคุม noise ที่ต้นตอไม่ได้
- การบีบอัดอย่างตั้งใจ เป็นวิธีที่ดีกว่า โดยใช้สรุปความคืบหน้า (ไฟล์) และ commit message มาช่วยสร้างคอนเท็กซ์ใหม่
- มีการยกตัวอย่างรูปแบบผลลัพธ์การบีบอัดที่เหมาะสม โดยตั้งเป้าหมายให้เหมาะที่สุดทั้งด้าน ความถูกต้อง/ความครบถ้วน/ขนาด/trajectory
มุมมองเชิงเทคนิคของการเพิ่มประสิทธิภาพคอนเท็กซ์
- LLM เป็น ฟังก์ชันแบบไร้สถานะ ดังนั้นคุณภาพจึงขึ้นอยู่กับ input context ทั้งหมด
- ลำดับความเลวร้ายที่สุดคือ ข้อมูลผิด > ข้อมูลตกหล่น > noise มากเกินไป
- ยิ่งคอนเท็กซ์เล็กยิ่งได้เปรียบ ดังนั้นแก่นสำคัญคือการบีบอัดเพื่อให้ได้ ความสอดคล้องสูงสุด ด้วย อินพุตให้น้อยที่สุด
- ยังมีการกล่าวถึงมุมมองทางเลือก เช่น กลยุทธ์รันเอเจนต์แบบลูปง่าย ๆ (เช่นกระบวนการ “Ralph”)
บทบาทของ sub-agent: ไม่ใช่การสวมบทบาทแทนคน แต่เป็นการควบคุมคอนเท็กซ์
- sub-agent ทำงาน ค้นหา/สรุป/จัดระเบียบ ในคอนเท็กซ์แยกต่างหาก เพื่อรักษาหน้าต่างของ เอเจนต์หลัก ให้สะอาด
- คำตอบในอุดมคติควรถูกส่งกลับมาในรูปของผลลัพธ์การบีบอัดแบบมีโครงสร้าง ที่ประกอบด้วย เป้าหมาย/สถานะปัจจุบัน/เส้นทาง
- sub-agent ช่วยจำกัด ต้นทุนของการสำรวจ ให้อยู่เฉพาะจุด และเพิ่ม สมาธิ ของคอนเท็กซ์งานหลัก
กรณีศึกษา 1: แก้บั๊ก BAML ผ่านในรอบเดียว
- มีกรณีของผู้ที่เพิ่งเข้ามาใหม่ใน BAML ขนาด 300,000 LOC ที่เขียนด้วย Rust แต่สามารถส่งและได้รับการอนุมัติ PR แก้บั๊ก ได้ภายในไม่กี่ชั่วโมง
- มีการวนทำ เอกสารวิจัย หลายรอบเพื่อยกระดับคุณภาพ และลงมือ implement ตามแผนสุดท้ายจน ผ่านตั้งแต่ครั้งแรก
- เป้าหมายหลายข้อสำเร็จ ทั้งด้าน ความเหมาะกับ brownfield, การกำจัด slop และ การรักษา alignment
กรณีศึกษา 2: เพิ่มการรองรับ cancel/WASM ให้ BAML 35k LOC
- มีการสาธิตงานแก้ไขขนาดใหญ่ที่คน 2 คนใช้เวลา 7 ชั่วโมง เพื่อเพิ่ม ฟีเจอร์ cancel และการรองรับ WASM compile
- จากที่ทีมประเมินว่าแต่ละงานจะใช้เวลา 3–5 วัน ก็ถูกย่นลงด้วย pipeline แบบ วิจัย/วางแผน/ลงมือทำ
- บาง PR ถูก merge ทันที ขณะที่บางส่วนเปิดทิ้งไว้ในระดับ เดโมที่ใช้งานได้ เพื่อพิสูจน์ว่า งานยากมากก็ยังมีโอกาสแก้ได้
ข้อจำกัดและบทเรียนจากความล้มเหลว
- ความพยายามตัด dependency ของ Hadoop ออกจาก Parquet Java กลายเป็นกรณีล้มเหลว เพราะเจาะลึก dependency tree ได้ไม่เพียงพอ
- บทสรุปคือ ไม่ใช่ทุกปัญหาที่แก้ได้ด้วย การพรอมป์ติดต่อกัน 7 ชั่วโมง และยังต้องการการมีส่วนร่วมของ ผู้เชี่ยวชาญโดเมน
- leverage ของการตรวจทานโดยมนุษย์ จะมากขึ้นตามลำดับจาก research > plan > code และการวิจัยที่ผิดเพียงบรรทัดเดียวก็อาจขยายเป็น ข้อผิดพลาดหลายพันบรรทัด ได้
เอกสารต้องมาก่อน เพื่อการจัดแนวของทีม
- มีการเสนอว่าหัวใจของ code review คือการรักษา mental alignment
- ชุด PR ขนาดใหญ่ต่อเนื่องกันอาจทำให้ทีม สูญเสียความเข้าใจต่อผลิตภัณฑ์ และเกิดความกังวล ดังนั้นการใช้ สเปก/แผน/งานวิจัย จะช่วยลดต้นทุนในการจัดแนว
- วิศวกรสามารถอ่าน เอกสารแผน 200 บรรทัด ได้บ่อยและแม่นยำกว่าโค้ด 2,000 บรรทัด
- แม้ในกรณีรับมือปัญหาในพื้นที่ที่ไม่คุ้นเคย research prompt ก็ยังทำหน้าที่เป็นไกด์ได้อย่างรวดเร็ว
สรุปภาพรวมและโครงสร้างต้นทุน
- แนวทางนี้บรรลุเป้าหมายทั้งหมด ได้แก่ รองรับ brownfield, แก้ปัญหาซับซ้อน, ลด slop, และ รักษา alignment ของทีม
- ในมุมต้นทุนการใช้งาน ทีม 3 คนดำเนินงานด้วย ค่า Opus token ราว $12k ต่อเดือน
- แม้จะมีข้อยกเว้นอยู่บ้าง แต่โดยรวมก็เน้นย้ำว่านี่คือ วิธีการที่ใช้ได้ผลจริง
การเปลี่ยนแปลงในอนาคตและการทำให้เป็นผลิตภัณฑ์
- coding agent จะกลายเป็น สินค้าโภคภัณฑ์ และโจทย์ที่แท้จริงคือ การเปลี่ยนแปลงองค์กรและเวิร์กโฟลว์
- ในโลกที่ AI เขียนโค้ด 99% ได้ การยกเครื่องรูปแบบการทำงานร่วมกันทั้งหมด จะเป็นจุดแบ่งด้านความสามารถในการแข่งขัน
- เพื่อรองรับสิ่งนี้ จึงเปิด private beta ของเครื่องมือ “post-IDE” ชื่อ CodeLayer
- เครื่องมือนี้ตั้งเป้าเป็น Superhuman for Claude Code และช่วยเร่งการพัฒนาแบบ agentic ที่ยึดแนวคิด specs-first
3 ความคิดเห็น
จบโฆษณา...
ปิดท้ายด้วยการแนะนำบริการชื่อ CodeLayer...
ความคิดเห็นบน Hacker News
เป็นบทความที่น่าสนใจและมีไอเดียใหม่ ๆ แต่ผมคิดว่าคำกล่าวอ้างแบบนี้มีปัญหา Sean คาดการณ์ว่าเมื่อ AI พัฒนาขึ้น เอกสารสเปกจะกลายเป็นโค้ดจริง และในอีก 2 ปีข้างหน้า คนจะเปิดดูไฟล์ Python ใน IDE บ่อยพอ ๆ กับทุกวันนี้ที่คนเปิด hex editor เพื่อดู assembly เขาบอกว่าตอนแรกก็รู้สึกแปลก ๆ แต่สุดท้ายก็ยอมรับแนวทางที่เลิกอ่านโค้ดใน PR ทีละบรรทัด แล้วไปโฟกัสที่การทดสอบแทน พร้อมมองว่าสเปกคือแหล่งความจริงหลัก อย่างไรก็ตาม ปัญหาเรื่องความไม่เป็นเชิงกำหนด (non-determinism) ของ LLM ทำให้ต่อให้เขียนพรอมป์ต์ดีแค่ไหน ก็ไม่อาจคาดหวังการ implement ที่สมเหตุสมผลได้เสมอไป คอมไพเลอร์เป็นแบบกำหนดผลลัพธ์ได้ และถึงจะมีบั๊กก็ยังทำซ้ำและดีบักได้ แต่ LLM ไม่เป็นแบบนั้น
แม้แต่เวลาทำงานกับนักพัฒนาระดับจูเนียร์ การ implement ก็ยังมีความเป็นเชิงกำหนดอยู่พอสมควร แต่กับโมเดล AI ต่อให้สั่งชัดเจน ก็ยังได้การ implement ที่ต่างกันอย่างสิ้นเชิงซ้ำแล้วซ้ำอีก
ที่น่าสนใจก็คือจริง ๆ แล้วตัวเอกสารสเปกเองก็ไม่เป็นเชิงกำหนดอยู่แล้ว ถ้าพยายามเขียน requirements เป็นภาษาอังกฤษให้ไม่มีใครตีความผิดได้ สุดท้ายมันก็จะกลายเป็นภาษาโปรแกรมอยู่ดี
เห็นด้วยกับความกังวลที่ว่า "พรอมป์ต์อาจสมบูรณ์แบบ แต่ก็ยังไม่มีหลักประกันว่า LLM จะเปลี่ยนมันเป็นการ implement ที่สมเหตุสมผลได้" ยิ่งไปกว่านั้น พรอมป์ต์ที่เขียนด้วยภาษาธรรมชาติก็มักคลุมเครือและไม่สมบูรณ์โดยเนื้อแท้ เพราะแบบนี้มันจึงเหมาะในงานที่ต้องการผลลัพธ์เชิงสร้างสรรค์ แต่ถ้าภาษาธรรมชาติเหมาะกับการนิยามข้อกำหนดซอฟต์แวร์จริง ปัญหานี้คงถูกวิศวกรรมซอฟต์แวร์แก้ไปตั้งหลายสิบปีแล้ว ผมเคยตื่นเต้นกับ LLM มาก แต่คิดว่าการพยายามให้มันแก้ทุกปัญหานั้นเกินจริงไปหน่อย สำหรับการระบุข้อกำหนด ความรู้สึกมันคล้ายกับระบบเชิงรูปแบบและความพยายามพิสูจน์เชิงคณิตศาสตร์ในอดีต แต่ไปอยู่คนละขั้ว ถึงสุดท้ายมันจะล้มเหลวบางส่วน ก็ยังเป็นการทดลองที่ให้มุมมองใหม่ต่อการพัฒนาซอฟต์แวร์ได้ บางโดเมนอาจเกิดคุณค่าจริง แต่อีกหลายที่อาจถูกทิ้งไปเลย เป็นช่วงเวลาที่น่าสนใจ
เอาจริง ๆ ก็แทบไม่มีใครเขียนสเปกเชิงเทคนิคหรือเอกสารที่ชัดเจนและละเอียดได้ดีนัก ต่อให้มี ก็ดูไม่เหมือนว่าจะกลายเป็นเรื่องปกติภายใน 2 ปี นักเขียนเอกสารเทคนิคที่เข้าใจวิศวกรรมซอฟต์แวร์อย่างลึกซึ้งจะพอใจจริงหรือ ถ้าไม่ดูโค้ดเลยแล้วแค่ป้อนพรอมป์ต์ให้ AI agent ดี ๆ ผมไม่เห็นด้วย มันใกล้เคียงกับวิธีคิดแบบ "วิศวกรมองคนเหมือนเครื่องจักร" ตามสูตรสำเร็จมากกว่า
คำกล่าวที่ว่า "เพราะมีคอมไพเลอร์ เราเลยไม่ต้องเปิด hex editor ไปดู assembly ทุกครั้งที่ build" ก็จริงในแง่ที่ว่าเครื่องมือดีขึ้น แต่ในงานวิจัยวิทยาศาสตร์สาย HPC จริง ๆ ก็มักมีคนแกะ assembly โดยตรงผ่าน Intel VTune และเครื่องมืออื่น เพื่อเช็กว่าคอมไพเลอร์ทำ vectorization ให้ลูปสำคัญได้ถูกต้องหรือไม่
ผมเคยใช้แพตเทิร์นนี้กับ codebase ที่ต่างกันสองแบบ แบบหนึ่งคือ monolithic repo ขนาดใหญ่ของ apache airflow ที่มี 500,000 บรรทัด อีกแบบคือโปรเจกต์ side project ส่วนตัวที่เริ่มจากศูนย์ด้วย flutter ซึ่ง flutter และ dart เป็นโลกที่ผมไม่รู้จักเลย แต่ถึงอย่างนั้นก็ยังรู้สึกว่าวิธีนี้ได้ผล โปรเจกต์แบบ greenfield แทบจะรันแค่ /create_plan ก็พอ และใช้ความสามารถของ agent ได้เต็มที่ สิ่งสำคัญคือการรีวิวเอกสารที่ AI สร้างออกมาอย่างละเอียด ตรวจเองว่ามันครอบคลุม edge case ที่ผมห่วงหรือที่อาจตกหล่นหรือไม่ และตัวเลือกทางเทคนิคสมเหตุสมผลหรือเปล่า เช่น ถ้ามันตัดสินใจผิดแบบแนะนำ postgres ทั้งที่ควรใช้แพตเทิร์น sqlite ผมจะรู้ได้ทันที ปกติแล้วก็แก้แผนได้ทันทีผ่านการคุยกับ agent โดยตรง ที่บริษัทผมต้องใช้ GitHub Copilot เลยต้องเขียนพรอมป์ต์ต่างออกไปหน่อย แต่ก็ยังทำการสรุปย่ออย่างตั้งใจระหว่างแต่ละขั้นตอนอยู่ดี Copilot ยังไม่รองรับ sub-agent แบบ Claude Code แต่ก็ยังรักษาระดับ productivity ได้พอสมควร
อยากแชร์ประสบการณ์ส่วนตัวอย่างหนึ่งด้วย ก่อนยุคที่มี AI ช่วยเขียนโค้ด ผมเคยซึมเศร้าหนักเพราะรู้สึกว่างานตัวเองน่าเบื่อเกินไป การทำงานกับ codebase ขนาดใหญ่ที่เกี่ยวข้องกับหลาย repo หลายทีม และนิสัยคนหลากหลาย มักเต็มไปด้วยงานจุกจิกเสมอ สิ่งที่ดีที่สุดของ AI coding สำหรับผมคือมันช่วยจัดการงานเล็ก ๆ น้อย ๆ พวกนี้ได้ลื่นไหลมาก ผมรู้สึกคุ้มค่ามากเวลาสร้างสิ่งที่ทำงานได้ดี แต่ความสุขนั้นมักหายไปเพราะติดอยู่กับงานหยุมหยิมพวกนี้ ตอนนี้ผมสร้างผลลัพธ์ที่ดีได้อย่างสม่ำเสมอ และก็รู้สึกภูมิใจกับตัวเองอีกครั้ง
ผมสร้างแพ็กเกจที่ใช้ตอนทำงานกับ codebase ขนาดใหญ่ชื่อ [GitHub.com/iambateman/speedrun] ก่อนอื่นจะใส่คำอธิบายฟีเจอร์ผ่าน /feature แล้วมันจะเริ่มวิเคราะห์ codebase และถามคำถามกลับมา พอผมตอบ มันก็จะเขียนแผนออกมาเป็น markdown ระหว่างทางจะได้ไฟล์ markdown 8-10 ไฟล์ ที่บอกว่าต้องทำอะไรและมีตัวอย่างโค้ดให้ด้วย จากนั้นจะเข้าสู่ขั้น "code critic" ซึ่งพยายามหาข้อผิดพลาด แต่จริง ๆ แล้วผิดเองประมาณ 60% ผมก็จะกรอง feedback ที่เพี้ยน ๆ ออก ถึงจุดนี้ก็จะได้โฟลเดอร์ที่สะอาด มีคำอธิบายฟีเจอร์และรายการแก้ไขที่ต้องการครบ จากนั้นแค่บอก Claude Code ว่า “ดำเนินการต่อ” มันก็จะเริ่มทำงานทีละขั้น วิธีนี้ช่วยกันไม่ให้หลุดทิศทาง และทำให้ผมมั่นใจกับผลลัพธ์ ผมใช้ workflow นี้กับงานใหญ่วันละหลายครั้ง และถ้าเป็นงานที่ค่อนข้างเฉพาะเจาะจงก็ใช้ Claude code ธรรมดา ผมคิดว่าเป็น workflow ที่ค่อนข้างมีประสิทธิภาพ
ผมไม่เข้าใจเลยว่าทำไมถึงอยากทำให้มันซับซ้อนขนาดนี้ สำหรับผม การเขียนโค้ดแบบปกติที่แค่ให้ LLM ช่วยเล็กน้อยดูจะ productive กว่าวิธีนี้
ปัญหาใหญ่ของการใช้ LLM กับ codebase ขนาดใหญ่คือมันทำความผิดซ้ำ ๆ อยากรู้ว่าคุณติดตามการตัดสินใจด้านสถาปัตยกรรมของแต่ละงานให้ต่อเนื่องในบริบทได้อย่างไร
ดูเจ๋งมาก มีช่วงหนึ่งที่เป็นขั้น pseudo code เลยอยากรู้ว่าการนิยาม workflow หรือ process ล่วงหน้าช่วยได้จริงไหม แล้วก็เคยได้ยินว่าการพยายามคุมให้แต่ละไฟล์ไม่เกิน 100 บรรทัดสำคัญมาก อยากรู้ว่าคุณก็รู้สึกแบบนั้นเหมือนกันหรือเปล่า
บทความนี้เหมือน time capsule ของช่วงเวลาที่ผมยอมแพ้กับการจัดการ context ใน Claude code อย่างสิ้นเชิง ผมทำสเปกแยกเป็นโฟลเดอร์สำหรับแต่ละส่วนของโค้ด และเก็บ log แยกตามฟีเจอร์ ผมดูแลหลาย subsystem ของ API server ที่เขียนด้วย Python เช่น account, notification, subscription และอื่น ๆ พอสถานการณ์ซับซ้อนขึ้น Claude ก็เริ่มเข้าใจ business logic ไม่ถูก และการจัดการ context ก็ยากมาก เช่น ตอนจะสร้างระบบ RBAC ง่าย ๆ ผมยังต้องให้ทั้งไดอะแกรม UML และตัวอย่างที่อธิบายความสัมพันธ์ระหว่าง account กับ profile ถึงจะได้ผลใกล้เคียงกับที่คาดไว้
มีคำประกาศและคำอ้างเรื่องการใช้ AI เต็มไปหมด แต่แทบไม่มีใครเปิดเผยกระบวนการหรือพรอมป์ต์อย่างเป็นรูปธรรมเลย พูดให้ดูน่าเชื่อนั้นง่าย แต่ถ้าจะให้มีประโยชน์จริง ต้องมี log ของพรอมป์ต์ให้ดู คอมมิตที่ AI สร้างควรมี log ว่าใช้พรอมป์ต์อะไรบ้าง เพื่อให้เราตามดูขั้นตอนการเขียนโค้ดได้เหมือนที่ไล่อ่าน commit log
ผู้เขียนบอกอย่างภูมิใจว่าศึกษาและ implement โค้ด 35K บรรทัดได้ภายใน 7 ชั่วโมง แต่ในความเป็นจริงกลับมี 40 คอมมิตตลอด 7 วัน เลยอดสงสัยไม่ได้ว่าทำวันละชั่วโมงหรือเปล่า แล้วหนึ่งในคอมมิตล่าสุดก็ตลกดีเพราะชื่อว่า "ignore some tests"
มีประโยคหนึ่งว่า "ไม่กี่สัปดาห์ต่อมา เราเพิ่มอีก 35k LOC เข้าไปใน BAML กับ @hellovai เพื่อรองรับการยกเลิก การคอมไพล์ WASM และฟีเจอร์ใหม่อื่น ๆ ทีมเดิมประเมินว่าแต่ละฟีเจอร์จะใช้เวลา 3-5 วัน" ถ้าอย่างนั้นหมายความว่าเขาคิดว่าวิศวกรอาวุโสจะเขียนได้วันละ 4-6KLOC งั้นหรือ? (ก่อนยุค genAI)
ข้อเท็จจริงที่หายไปคือ ถ้าเป็นวิศวกรอาวุโสจริง ๆ อาจแก้ปัญหานี้ได้ด้วยแค่ 2KLOC
และจริง ๆ แล้วผู้เขียนเองก็ยอมรับในที่อื่นว่างานนี้ใช้เวลาหนึ่งสัปดาห์ https://news.ycombinator.com/item?id=45351546
เห็นด้วยเต็มที่กับประโยคที่ว่า "ตอนแรกมันอึดอัด แต่สุดท้ายผมก็เลิกอ่านโค้ดทั้งหมดใน PR และหันไปดูการทดสอบอย่างจริงจังแทน สเปกกลายเป็นแหล่งความจริงหลัก" ผมรู้สึกว่าบทบาทของเรากำลังย้ายจากการเขียนรายละเอียดการ implement เอง ไปสู่การนิยามและตรวจสอบพฤติกรรม ช่วงหลังผมต้องเพิ่ม recursive upload ให้กับ Python operator แบบ S3-to-SFTP ซึ่งมี path flag ที่ซับซ้อนเยอะมาก กระบวนการของผมคือ 1) ดึงพฤติกรรมเดิมออกมาให้เป็นสเปกที่ชัดเจน โดยใช้ unit test เป็นตัวผ่าน 2) ขยายสเปกให้รองรับฟีเจอร์ใหม่ 3) ส่งปัญหาและชุดทดสอบให้ coding agent สุดท้ายผมก็ตระหนักว่าไม่จำเป็นต้องเข้าใจโค้ดเก่าเลย จุดโฟกัสของผมมีแค่ว่าโค้ดใหม่ทำตามสเปกหรือไม่ อนาคตคุณค่าของเราน่าจะอยู่ที่การตรวจสอบความถูกต้อง ส่วนโค้ดจริงจะกลายเป็นรายละเอียดที่ agent จัดการเอง
เห็นด้วยกับประโยคที่ว่า "บทบาทของเรากำลังย้ายจากการเขียนรายละเอียดการ implement ไปสู่การนิยามและตรวจสอบพฤติกรรม" จริง ๆ ก็เหมือนว่านี่เป็นงานหลักมาโดยตลอดอยู่แล้ว เพียงแต่ภาษาระดับสูง คอมไพเลอร์ และ abstraction อื่น ๆ ทำให้เวลาที่ใช้เขียนรายละเอียดการ implement ลดลงเรื่อย ๆ
พอเห็นประโยคว่า "จุดโฟกัสของผมมีแค่ว่าโค้ดใหม่ทำงานตามสเปกหรือไม่" ก็ทำให้นึกถึงกฎของ Postel (Postel's Law) เพราะพฤติกรรมที่ผู้คนสังเกตได้จากระบบที่ใช้กันแพร่หลาย มักจะกลายเป็น public interface และสเปกโดยพฤตินัยของระบบนั้น รวมถึงข้อผิดพลาดและบั๊กในการ implement ด้วย ดังนั้นฝั่ง client ของโค้ดก็จำเป็นต้องทดสอบด้วยว่าปฏิบัติตามสเปกจริงหรือไม่ และถ้ามีความคลาดเคลื่อนก็ต้องตรวจจับและรับมือให้ได้
Claude Plays Pokemon ก็แสดงให้เห็นเรื่องเดียวกัน AI อ่อนในการตัดสินว่าอะไร "ใช้งานได้จริง" มันมักวนอยู่จุดเดิม แต่ถ้ามีมนุษย์คอยช่วยปรับทิศทางเป็นระยะ ก็จะกลายเป็นคู่ผสมที่ทรงพลังมาก
ถ้าพยายามนิยามพฤติกรรมทุกด้านให้ครบจริง ๆ สุดท้ายก็แทบไม่ต่างจากการเขียนโค้ดเกือบทั้งหมดเอง ถ้ามีแม้แต่บรรทัดเดียวใน PR ที่คุณยังไม่เข้าใจความหมายทันที ก็อาจแปลว่ายังนิยามพฤติกรรมรวมได้ไม่เพียงพอ
มีคำกล่าวว่า "ในอีกไม่กี่ปี เอกสารสเปกจะกลายเป็นโค้ดจริง และเราจะแทบไม่ต้องเปิดไฟล์ Python อีกเลย" ถ้าจะให้เป็นจริง AI ที่สร้างโค้ดต้องแม่นยำระดับ 99.9% และแทบไม่มี hallucination เลย ที่เรากล้าเชื่อคอมไพเลอร์และไม่เปิดดู assembly ก็เพราะมั่นใจว่าผลลัพธ์จะเหมือนเดิมทุกครั้งและไม่มีข้อผิดพลาด แม้จะมีบั๊กหรือปัญหา optimization อยู่บ้างแต่ก็มักแก้ได้รวดเร็วมาก ตอนนี้ถ้าโค้ดที่ AI สร้างทำงานไม่ตรงกับสเปก ซึ่งก็คือโค้ดต้นฉบับ สุดท้ายมนุษย์ก็ยังต้องกลับมาแก้อยู่ดี
เคล็ดลับเรื่องการแยกการ implement ออกเป็นหน่วยงานย่อยเพื่อจัดการหรือรีวิวทีละส่วนทำให้ประทับใจมาก