- ทีม StrongDM AI เสนอแนวคิด Software Factory ที่สร้างซอฟต์แวร์คุณภาพสูงได้โดยไม่ต้องดูโค้ด
- เอเจนต์เขียนโค้ดจากสเปก/สถานการณ์ จำลองการทำงานของ test harness และบรรลุผลลัพธ์แบบ ไม่ต้องมีมนุษย์ตรวจทาน ในรูปแบบการพัฒนา แบบไม่โต้ตอบ
- มนุษย์ไม่ควรเขียนหรือตรวจทานโค้ด และต้องใช้ค่าใช้จ่ายโทเคนอย่างน้อย 1,000 ดอลลาร์ต่อวิศวกรต่อวัน จึงจะทำให้ซอฟต์แวร์แฟกทอรีทำงานได้อย่างเหมาะสม
- ตั้งแต่ Claude 3.5 ฉบับปรับปรุงครั้งที่ 2 (ตุลาคม 2024) เป็นต้นมา เวิร์กโฟลว์การเขียนโค้ดด้วยเอเจนต์ระยะยาวเริ่มสะสมความถูกต้องแบบทบต้น แทนการสะสมข้อผิดพลาด ทำให้เห็นความเป็นไปได้ของ การพัฒนาแบบไม่โต้ตอบ
- มีการขยายแนวคิดของการทดสอบเดิมด้วยการนำ สถานการณ์ (scenario) และ ความพึงพอใจ (satisfaction) มาใช้ สร้างระบบที่ให้ LLM ประเมินความพึงพอใจของผู้ใช้แบบเชิงความน่าจะเป็น
- ผ่าน Digital Twin Universe (DTU) มีการจำลอง SaaS สำคัญอย่าง Okta, Jira, Slack เพื่อทำการตรวจสอบขนาดใหญ่ และสามารถตรวจสอบสถานการณ์ได้ด้วยปริมาณและความเร็วที่เกินข้อจำกัดของโปรดักชัน
- ยุคของเอเจนต์กำลังเปลี่ยนเศรษฐศาสตร์ของซอฟต์แวร์อย่างรากฐาน ทำให้ การสร้างสำเนา SaaS ความเที่ยงตรงสูงซึ่งในอดีตไม่คุ้มทางเศรษฐกิจ กลายเป็นงานปกติในวันนี้
แนวคิด Software Factory
- สเปก (specs) และ สถานการณ์ (scenarios) เป็นตัวขับเคลื่อนเอเจนต์ให้เขียนและตรวจสอบโค้ดในระบบการพัฒนา แบบไม่โต้ตอบ
- ห้ามมนุษย์เขียนและรีวิวโค้ด และให้เอเจนต์ดำเนินกระบวนการพัฒนาทั้งหมด
- ใช้ ค่าใช้จ่ายโทเคนมากกว่า 1,000 ดอลลาร์ต่อวิศวกรต่อวัน เป็นเกณฑ์วัดประสิทธิภาพ
- แนวทางนี้มีเป้าหมายเพื่อสร้าง สภาพแวดล้อมการผลิตซอฟต์แวร์แบบอัตโนมัติ ที่โค้ดถูกสร้าง ตรวจสอบ และค่อย ๆ บรรลุผลลัพธ์ได้เองโดยไม่ต้องมีมนุษย์เข้ามาแทรกแซง
การก่อตั้งทีม StrongDM AI
- วันที่ 14 กรกฎาคม 2025 มีการจัดตั้ง ทีม StrongDM AI และเริ่มทดลองการพัฒนาแบบไม่โต้ตอบ
- ผู้เข้าร่วม: Jay Taylor, Navan Chauhan, Justin McCarthy (ผู้ร่วมก่อตั้งและ CTO)
- หลัง Claude 3.5 (ฉบับแก้ไขเดือนตุลาคม) ในช่วงปลายปี 2024 ความแม่นยำของการเขียนโค้ดระยะยาวดีขึ้น จึงเกิด การสะสมความถูกต้องแบบทบต้น (compounding correctness) แทนการสะสมข้อผิดพลาดแบบเดิม
- YOLO mode ของ Cursor ทำให้ความสามารถในการเขียนโค้ดระยะยาวของโมเดลปรากฏชัดเจนขึ้น
- ในโมเดลก่อนหน้า เมื่อใช้ LLM กับงานเขียนโค้ดแบบ วนซ้ำหลายรอบ ความเข้าใจผิด อาการหลอน ข้อผิดพลาดทางไวยากรณ์ การละเมิด DRY ระหว่างเวอร์ชัน ความไม่เข้ากันของไลบรารี และข้อผิดพลาดทุกประเภทจะสะสมขึ้นจนแอป “พังทลาย”
- เมื่อรวมโมเดลที่อัปเดตของ Anthropic เข้ากับ YOLO mode จึงเห็นความเป็นไปได้แรกของ การพัฒนาแบบไม่โต้ตอบ หรือ ซอฟต์แวร์ที่เติบโตได้
หลักการสำคัญ: อย่าแตะโค้ด
- ในชั่วโมงแรกของวันแรก ทีม AI ได้กำหนดกฎบัตรขึ้นมา โดยหลักการสำคัญที่สุดคือ "มนุษย์ต้องไม่เขียนโค้ดด้วยตนเอง"
- ในช่วงแรกเป็นเพียงสัญชาตญาณและการทดลองง่าย ๆ ว่า ถ้าไม่เขียนโค้ดด้วยมือเลย จะไปได้ไกลแค่ไหน
- ตอนแรกเจอข้อจำกัด แต่เริ่มก้าวหน้าเมื่อเพิ่มการทดสอบเข้าไป
- เอเจนต์มักยึดติดกับงานตรงหน้าและเลือกทางลัด: การเขียน return true ทำให้ผ่านการทดสอบที่เขียนไว้แคบ ๆ ได้ แต่ไม่สามารถทำให้เป็นซอฟต์แวร์ที่ตรงกับสิ่งที่ต้องการจริงในภาพรวม
- การทดสอบแบบง่ายอย่างเดียวไม่พอ ต้องขยายไปสู่ integration test, regression test, end-to-end test และ behavioral test
จากการทดสอบสู่สถานการณ์และความพึงพอใจ
- ประเด็นที่เกิดซ้ำในยุคของเอเจนต์คือ ต้องมีภาษาใหม่ เพราะคำว่า “การทดสอบ” นั้นไม่เพียงพอและกำกวม
- การทดสอบที่เก็บในโค้ดเบสอาจถูกเขียนใหม่แบบขอไปทีให้เข้ากับโค้ด หรือโค้ดอาจถูกเขียนใหม่เพื่อให้ผ่านการทดสอบแบบผิวเผิน
- มีการนิยามคำว่า สถานการณ์ ใหม่ให้หมายถึง เรื่องราวของผู้ใช้แบบ end-to-end โดยเก็บไว้นอกโค้ดเบส (คล้ายกับชุด “holdout” ในการฝึกโมเดล) และให้ LLM เข้าใจโดยสัญชาตญาณพร้อมตรวจสอบได้อย่างยืดหยุ่น
- เนื่องจากซอฟต์แวร์ที่กำลังเติบโตเองนั้นมีคอมโพเนนต์เอเจนต์อยู่ภายใน การตัดสินความสำเร็จจึงเปลี่ยนจากค่าบูลีนธรรมดาไปสู่ ความพึงพอใจ (satisfaction) แบบเชิงความน่าจะเป็นและเชิงประจักษ์
- ความพึงพอใจ: การวัดสัดส่วนของเส้นทางการทำงานที่สังเกตได้และผ่านทุกสถานการณ์แล้ว ซึ่งมีแนวโน้มว่าจะทำให้ผู้ใช้พึงพอใจ
การตรวจสอบสถานการณ์ผ่าน Digital Twin Universe
- ในระบบเดิม จะตัดสินว่า "มันใช้งานได้หรือไม่?" ผ่าน integration test, regression test และ UI automation
- พบข้อจำกัด 2 ประการของเทคนิคเดิมที่เคยเชื่อถือได้:
- การทดสอบแข็งเกินไป: เมื่อเขียนโค้ดด้วยเอเจนต์และสร้างลูป LLM กับเอเจนต์ให้เป็น primitive ด้านการออกแบบ การประเมินความสำเร็จจึงมักต้องใช้ LLM-as-judge
- การทดสอบเปราะบางต่อการ hack รางวัล: จำเป็นต้องมีการตรวจสอบที่ทนทานต่อการโกงของโมเดลมากกว่าเดิม
- Digital Twin Universe (DTU) คือคำตอบ: เป็นคลอนพฤติกรรมของบริการภายนอกที่ซอฟต์แวร์พึ่งพา
- สร้างทวินของ Okta, Jira, Slack, Google Docs, Google Drive, Google Sheets โดยจำลอง API, กรณีขอบ และพฤติกรรมที่สังเกตได้
- DTU ทำให้ตรวจสอบได้ด้วยปริมาณและความเร็วที่สูงกว่าข้อจำกัดของโปรดักชันมาก
- ยังทดสอบโหมดความล้มเหลวที่เสี่ยงหรือเป็นไปไม่ได้กับบริการจริงได้ด้วย
- รันสถานการณ์ได้หลายพันรายการต่อชั่วโมงโดยไม่ชน rate limit ไม่กระตุ้นการตรวจจับการใช้งานผิดปกติ และไม่สะสมค่าใช้จ่าย API
เศรษฐศาสตร์ที่ไม่เป็นแบบเดิม
- ความสำเร็จผ่าน DTU แสดงให้เห็นหนึ่งในหลายวิธีที่ จังหวะแห่งยุคเอเจนต์ (Agentic Moment) กำลังเปลี่ยนเศรษฐศาสตร์ซอฟต์แวร์อย่างรากฐาน
- การสร้างคลอนความเที่ยงตรงสูงของแอป SaaS สำคัญนั้นทำได้เสมอมา แต่ ไม่คุ้มค่าทางเศรษฐกิจ
- วิศวกรหลายรุ่นเคยต้องการสำเนา CRM แบบ in-memory ทั้งชุดสำหรับใช้ทดสอบ แต่ไม่เคยแม้แต่จะเสนอผู้จัดการ เพราะคาดว่าจะถูกปฏิเสธ
- ผู้สร้างซอฟต์แวร์แฟกทอรีจำเป็นต้องฝึก ความไร้เดียงสาโดยเจตนา (deliberate naivete): ค้นหาแล้วกำจัดนิสัย จารีต และข้อจำกัดของ Software 1.0
- ผ่าน DTU สิ่งที่เมื่อ 6 เดือนก่อนยังนึกไม่ออก ตอนนี้ได้กลายเป็นงานประจำที่ทำซ้ำได้แล้ว
เรื่องที่ควรอ่านต่อ
- Principles : ความเชื่อของเราต่อการพัฒนาซอฟต์แวร์ด้วยเอเจนต์
- ซอฟต์แวร์เติบโตผ่านโครงสร้าง seed → validation harness → feedback loop โดยมี โทเคนเป็นเชื้อเพลิง
- ซอฟต์แวร์ทุกชิ้นต้องมี seed เริ่มต้น: อาจเป็น PRD หรือเอกสารสเปกในอดีต หรือปัจจุบันอาจเป็นเพียงไม่กี่ประโยค ภาพหน้าจอ หรือโค้ดเบสเดิมก็ได้
- validation harness ต้องเป็นแบบ end-to-end และใกล้เคียงสภาพแวดล้อมจริงมากที่สุด ทั้งลูกค้า การเชื่อมต่อ และความคุ้มค่าทางเศรษฐกิจ
- การ feedback ตัวอย่างผลลัพธ์กลับไปเป็นอินพุตในรูปแบบ ลูปปิด ทำให้ระบบแก้ไขตัวเองและสะสมความถูกต้องแบบทบต้นได้
- แม้ทฤษฎีของการตรวจสอบและ feedback จะเข้าใจง่าย แต่การทำงานจริงต้องอาศัยวิศวกรรมที่สร้างสรรค์และล้ำสมัย: ค้นหาวิธีแปลงอุปสรรคทุกอย่างให้อยู่ในรูปแบบที่โมเดลเข้าใจได้
- Techniques : แพตเทิร์นแบบวนซ้ำสำหรับนำหลักการเหล่านี้ไปใช้
- Digital Twin Universe (DTU)
- จำลองพฤติกรรมภายนอกที่สังเกตได้ ของการพึ่งพาบุคคลที่สามที่สำคัญ
- ตรวจสอบด้วยปริมาณและความเร็วที่สูงกว่าข้อจำกัดของโปรดักชันมาก
- ให้เงื่อนไขการทดสอบที่ กำหนดแน่นอนและทำซ้ำได้
- Gene Transfusion
- กำหนดเอเจนต์ด้วยตัวอย่างเฉพาะเพื่อ ย้ายแพตเทิร์นการทำงานข้ามโค้ดเบส
- ทำให้สามารถทำซ้ำโซลูชันที่จับคู่กับตัวอ้างอิงที่ดีในบริบทใหม่ได้
- Filesystem
- ให้โมเดลสำรวจรีโพซิทอรีได้รวดเร็ว และปรับคอนเท็กซ์ของตัวเองผ่านการอ่าน/เขียนไฟล์
- ไดเรกทอรี ดัชนี และสถานะบนดิสก์ทำหน้าที่เป็น ฐานความจำเชิงปฏิบัติ
- Shift Work
- แยกงานแบบโต้ตอบออกจากงานที่ระบุสเปกไว้อย่างสมบูรณ์
- เมื่อเจตนาสมบูรณ์แล้ว (มีสเปก การทดสอบ หรือแอปเดิม) เอเจนต์สามารถทำงานแบบ end-to-end ได้โดยไม่ต้องโต้ตอบกลับไปกลับมา
- Semport
- การพอร์ตแบบอัตโนมัติที่รับรู้เชิงความหมาย ทำได้ทั้งแบบครั้งเดียวหรืออย่างต่อเนื่อง
- ย้ายโค้ดข้ามภาษา یاเฟรมเวิร์กโดยยังรักษาเจตนาเดิมไว้
- Pyramid Summaries
- การสรุปแบบย้อนกลับได้ ในหลายระดับการซูม
- บีบอัดคอนเท็กซ์โดยไม่สูญเสียความสามารถในการขยายกลับไปยังรายละเอียดทั้งหมด
- Products : เครื่องมือที่เราใช้ทุกวัน และคิดว่าน่าจะมีประโยชน์กับคนอื่นเช่นกัน
- CXDB คือ ที่เก็บคอนเท็กซ์แบบ self-hosted สำหรับ AI agent โดยมี Turn DAG, blob deduplication, dynamic typing และ visual debugging
- StrongDM ID คือ ระบบตัวตน (identity system) สำหรับมนุษย์ เวิร์กโหลด และ AI agent รองรับ federated authentication และการแชร์แบบกำหนดขอบเขตเส้นทาง
- Attractor คือ เอเจนต์เขียนโค้ดแบบไม่โต้ตอบ ที่จัดโครงสร้างด้วย phase graph และทำงานแบบ end-to-end เมื่อสเปกของงานครบถ้วน
3 ความคิดเห็น
ผมลองพัฒนาด้วยแนวทางการพัฒนาที่ขับเคลื่อนด้วยสเปก โดยใช้มัลติเอเจนต์แล้วครับ จริงอยู่ว่ามันช่วยลดงานได้มาก แต่ด้วยข้อจำกัดด้านประสิทธิภาพของ LLM จึงยังสร้างผลิตภัณฑ์ที่ทำให้ลูกค้าพึงพอใจไม่ได้ การทดแทนมนุษย์แบบ 100% เป็นไปไม่ได้ และยังจำเป็นต้องมีงานของมนุษย์อยู่ในระดับหนึ่ง
ค่อนข้างยั่วอารมณ์เกินไปหน่อย แต่ก็พอเข้าใจได้อยู่เหมือนกัน.. เป็นบทความที่ทำให้รู้สึกแปลก ๆ นะครับ
พออ่านบทความนี้แล้วไปดูบทความข้างล่าง จะยิ่งรู้สึกร่วมมากขึ้นครับ
เราไว้อาลัยให้กับจิตวิญญาณแห่งงานช่างของเรา
ความเห็นบน Hacker News
ฉันเห็นด้วยกับแนวคิด Digital Twin Universe
โค้ดเบสของฉันก็มีการเชื่อมต่อกับบริการภายนอกเยอะมาก จนเวลาทดสอบแล้วบล็อกการเรียกภายนอกออก แทบจะตรวจสอบอะไรไม่ได้เลย
เลยสร้าง ตัวจำลองปลอม ของแต่ละ API สำหรับทดสอบ เช่น Okta, Jira, Slack, Google Docs
แต่ไม่ได้จำลองไปถึง UI แค่เลียนแบบพฤติกรรมของ API เท่านั้น
คำพูดที่ว่า “ถ้ายังใช้โทเค็นไม่ถึง $1,000 ต่อวิศวกรต่อวัน แปลว่ายังมีช่องให้ปรับปรุง” ฟังดู ไม่สมจริง เกินไป
น่าสงสัยว่านี่เป็นข้ออ้างจริงจังหรือเปล่า
ลองคำนวณดูแล้วก็ตกราว ๆ $250k ต่อปี
ถ้า AI สร้าง ผลิตภาพ ได้ขนาดนั้น มันก็อาจสมเหตุสมผล
ในโลกจริงก็น่าจะได้ประสิทธิภาพประมาณวิศวกรจูเนียร์สองคน
สุดท้ายมนุษย์ก็คงเหลือบทบาทเป็น หัวหน้าทีม ที่คอยวางแผนและตรวจสอบ
แม้จะมองโลกในแง่ดีเกินจริง แต่ก็ไม่ถึงกับเพี้ยนไปเลย
ฉันใช้แค่ Claude กับ OpenAI แบบสมัครสมาชิกเดือนละ $20
ถ้าใช้โทเค็นหมดก็ออกไปเดินเล่นหรืออ่านหนังสือ
ฉันไม่ใช่พวก accelerationalist แต่ก็ยังทำงานได้พออยู่ดี
ฉันเป็นหนึ่งในทีม StrongDM
การใช้โทเค็นวันละ $1,000 นั้นทำได้ไม่ยาก แต่ประเด็นสำคัญคือ ใช้ให้เกิดประสิทธิผลนั้นยาก
มันดูเหมือน การอวดเก่ง มากกว่า
คล้ายการส่งสัญญาณว่า “พวกเราไปไกลเรื่อง AI กว่าพวกคุณนะ”
อ่านบทความแล้วรู้สึก กระอักกระอ่วน
เหมือนเอา mocks หรือการทดสอบแบบ simulation ที่มีอยู่เดิมมาห่อเป็น “นวัตกรรม”
แต่ก็ยอมรับว่าอย่างน้อยพวกเขาก็เปิดเผยโครงสร้างต้นทุนอย่างตรงไปตรงมา
ฉันพยายามหาว่าในเว็บของพวกเขามี โค้ดหรือผลิตภัณฑ์ จริงอะไรบ้าง
สิ่งเดียวที่เจอคือ strongdm/attractor
เท่ากับว่า “เขียนโค้ดโดยแฟนสาวชาวแคนาดา” กลายเป็นโมเดลธุรกิจไปแล้ว
นอกจากนี้ยังเจอ strongdm/cxdb แต่ประวัติ commit ถูกจัดระเบียบไว้แล้ว
มีโค้ดจริงอยู่ใน คลัง cxdb
ไม่รู้ว่านี่บ้าบอหรือเป็นภาพตัดขวางของอนาคตกันแน่
ที่ หน้า Products ก็มีทั้งฐานข้อมูลและระบบ ID
ถ้าหลายเอเจนต์จะทำงานร่วมกัน ก็จำเป็นต้องมี บริบทที่ใช้ร่วมกัน และระบบสิทธิ์อย่างยิ่ง
ฉันเคยฟังเว็บบินาร์เกี่ยวกับ BAML ของ BoundaryML
Spec-driven development เป็นแนวทางสร้าง workflow แบบมีโครงสร้างโดยให้มนุษย์อยู่ในลูป
มันกำหนดลูป
/research → /plan → /implementไว้อย่างชัดเจน และให้มี การตรวจสอบโดยมนุษย์ ในแต่ละขั้นซึ่งเป็นปรัชญาที่ตรงข้ามกับแนวคิดของ StrongDM ที่ว่า “มนุษย์ไม่ต้องเขียนหรืออ่านโค้ด” โดยสิ้นเชิง
ให้ความรู้สึกเหมือน บล็อกโพสต์กลวง ๆ อีกชิ้น
ไม่มีผลลัพธ์ที่เป็นรูปธรรม และเรื่องโทเค็น $1,000/วันก็ดูเหมือนเอาไว้ดึงดูดนักลงทุน
ถ้ายังแก้ ปัญหาการตรวจสอบความถูกต้อง ไม่ได้ ทั้งหมดนี้ก็เป็นแค่การอวดเท่านั้น
ต่อให้ตั้งระบบรีวิวอัตโนมัติหรือ guardrail ไว้ สุดท้ายคนที่ต้องยืนยันว่า สเปกกับผลลัพธ์ตรงกัน ก็ยังเป็นมนุษย์
พวกเราที่ Speedscale กำลังทำระบบตรวจสอบอัตโนมัติด้วย การจับและเล่นซ้ำทราฟฟิก
จริง ๆ แล้วนักพัฒนามนุษย์ก็ไม่ได้สมบูรณ์แบบ
เรามี กระบวนการตรวจสอบเชิงระบบ อยู่แล้วหลายอย่าง เช่น code review, testing, QA
สิ่งสำคัญไม่ใช่ว่า AI สมบูรณ์แบบไหม แต่คือ คุณภาพของระบบโดยรวมกำลังลู่เข้าได้หรือไม่
จากประสบการณ์ของฉัน ถ้าวัดด้วย Opus 4.5 ก็มี ผลกำไรสุทธิเล็กน้อย
ฉันก็เกือบเห็นด้วยทั้งหมด
แกนสำคัญคือ การตรวจสอบ ไม่ใช่การสร้าง
ตอนนี้กำลังสร้างโครงสร้างที่เอเจนต์อิสระหลายตัวสามารถ แสดงความเห็นต่างและหาฉันทามติ กันได้
พูดสั้น ๆ คือโยนภาระการตรวจสอบและการทดสอบความปลอดภัย ให้ผู้ใช้ปลายทางรับไป
ควรใช้ภาษาที่อิงสเปกและ การพิสูจน์ความถูกต้องเชิงรูปนัย ให้มากขึ้น
ท้ายที่สุดแล้วการเขียนโปรแกรมจะถูกนิยามใหม่เป็น “การทำให้สเปกเป็นรูปธรรม”
ถ้าเป็นโทเค็นวันละ $1,000 ก็เท่ากับใช้เงินกับ AI มากกว่ากับมนุษย์เสียอีก
นี่ดูเหมือนเป็น จุดพังทลายของวิสัยทัศน์ AI
มีคนบอกว่า Simon Willison อัปเดตบทความแล้ว
ถ้าคิดเป็นปีละ $240k ก็ระดับวิศวกร FANG สายเริ่มต้นเลย
เอาจริง ๆ ก็มี จูเนียร์จำนวนมากที่แย่กว่า Claude
สุดท้ายคงถูกจัดโครงสร้างใหม่เป็น พีระมิด ที่มีมนุษย์จำนวนน้อยอยู่บนยอด
ถ้าสามารถทำงานเดียวกันให้เสร็จใน 5 วันได้จริง ต้นทุนต่อความเร็ว ก็อาจสมเหตุสมผล
ถ้าปริมาณผลงานเพิ่มตามสัดส่วน ประสิทธิภาพต่อค่าใช้จ่าย ก็อาจพอรับได้
แถมราคาต่อโทเค็นก็อาจลดลงอีกในอนาคต
อุตสาหกรรมกฎหมายและประกันภัย จะรับมือกับการเปลี่ยนแปลงนี้ลำบากที่สุด
ความผิดพลาดของมนุษย์ยังพอจำลองได้ แต่ ความผิดพลาดแบบลูกโซ่ของลูปอัตโนมัติ เป็นปัญหาอีกแบบโดยสิ้นเชิง
การตัดสินใจของ AI สุดท้ายก็จะย้อนกลับไปเป็น ความรับผิดชอบของมนุษย์
นี่น่าจะเป็น ตัวหน่วงของการเปลี่ยนผ่านสู่ agentic ทั้งหมด
โทเค็นวันละ $1,000 เป็น ตัวชี้วัดที่เหลวไหล
ถ้าคุณภาพโค้ดแย่ การใช้โทเค็นจะพุ่งขึ้นอย่างมาก
สุดท้ายแล้ว โค้ดเบสที่ไม่เป็นระเบียบ ต่างหากที่ทำให้ต้นทุนสูงขึ้น
ถ้าเป็นทีมที่เผาเงินวันละพันดอลลาร์ ประสิทธิภาพก็คงแทบไม่มี
(อ้างอิง: มีมนี้)
มันเป็นปัญหาของการ optimize ระยะสั้นกับระยะยาว
จะเพิ่มประสิทธิภาพตอนนี้ หรือจะปรับปรุงระบบทั้งก้อนในระยะยาว
บางทีผู้บริหารอาจเพิ่งจะตระหนักได้ว่า การรีแฟกเตอร์ สำคัญแค่ไหน
ทีมที่ฉันเคยเรียกว่าเป็นตัวอย่างของ Dark Factory pattern ก็คือพวกนี้เอง
ฉันเขียน บทความที่เกี่ยวข้อง ไว้ และทีมนี้ก็เป็น กลุ่มทดลองที่ทะเยอทะยานที่สุด
แต่ในความเป็นจริง แทบไม่มีผลลัพธ์ให้เห็น
ให้เงินนักศึกษามหาวิทยาลัยไม่กี่คน $10k ยังน่าจะทำได้ดีกว่า
โทเค็นวันละ $1,000 นี่สำหรับงบทีมของฉันเป็นเรื่องที่ ไม่มีทางแม้แต่จะฝันถึง
สำหรับชีวิตส่วนตัวฉันก็เป็นไปไม่ได้เพราะค่าครองชีพ
สุดท้ายเลยรู้สึกเหมือน “ทำก็พัง ไม่ทำก็พัง”
ถ้าไม่มีผลลัพธ์ที่ตรวจสอบได้ ก็เป็น แค่คำพูดลอย ๆ
ทุกวันนี้แม้แต่คำพูดเองก็ถูกลงมากเพราะ LLM
จำเป็นต้องมีการเปิดเผยอย่างมีจริยธรรม
คำศัพท์บนเว็บก็แค่เอาแนวคิดเดิมมาห่อใหม่
“Digital Twin Universe” คือ mocks, “Gene Transfusion” คือการอ่านโค้ดอ้างอิง, “Semport” คือการ transpile
ไม่มีทั้ง ข้อมูลหรือ benchmark จริงเลย
มันเป็นตัวอย่างของการเอาการตลาด AI มาห่อเป็น insight ทางวิศวกรรม
ที่จริงโค้ดหลักส่วนใหญ่ก็อยู่บน GitHub อยู่แล้ว
จุดต่างที่แท้จริงคือ การออกแบบกลไกและชุดคุณค่า
อนาคตจะมุ่งไปที่การผสาน formal methods เข้ากับ AI
วิธี “เอาสถานการณ์ต่าง ๆ มาทำเป็น holdout set แล้วทดสอบ” น่าสนใจมาก
มันเป็นแนวคิดที่เลียนแบบ การทดสอบเชิงรุกของทีม QA
การแยกทีม build ออกจากทีมจับบั๊กเพื่อให้เกิด โครงสร้างการแข่งขันกันเอง ก็น่าประทับใจ
แต่โทเค็นวันละ $1,000 นั้นสำหรับนักพัฒนาโอเพนซอร์สถือว่า สิ้นหวังมาก
ถ้าใช้โมเดลรันในเครื่องก็ลดต้นทุนได้
อย่างใน เธรดนี้ การทำ เอเจนต์อัตโนมัติบนเครื่อง ก็เป็นไปได้สบาย
สักวันหนึ่งเอเจนต์อาจเริ่ม ติดสินบนกันเอง ก็ได้
ฉันยังคงชอบ แนวทางที่ให้มนุษย์อยู่ในลูป มากกว่า
การเผาโทเค็นแบบไม่ยั้งเป็นความสิ้นเปลือง
ฉันเคยสำรวจ กรอบความคิด ในการใช้ LLM ไว้ใน บทความ “LLMs aren’t tools”
“โรงงานซอฟต์แวร์” คือปลายทางของตอนนี้ แต่ขั้นถัดไปคือการมอง LLM เป็นแอปพลิเคชันหนึ่งตัว
กล่าวคือไม่ใช่แค่การทำ workflow อัตโนมัติ แต่เป็นขั้นของการสร้าง harness แบบเฉพาะทาง