- บทสัมภาษณ์ว่าด้วยเวิร์กโฟลว์ของ Peter Steinberger ที่ใช้ AI agent ทำงานคนเดียวและทำ คอมมิตมากกว่า 6,600 ครั้งในเดือนมกราคมเพียงเดือนเดียว
- Moltbot (เดิมชื่อ Clawdbot) กำลังทำสถิติ การเติบโตของดาวบน GitHub ที่เร็วที่สุดตลอดกาล และมีปริมาณการค้นหาบน Google แซงทั้ง Claude Code และ Codex
- Peter พัฒนาโดยรันเอเจนต์พร้อมกัน 5~10 ตัว และโฟกัสที่ การถกเถียงด้านสถาปัตยกรรม แทนการรีวิวโค้ด
- หากต้องการทำงานร่วมกับ AI อย่างมีประสิทธิภาพ จำเป็นต้องออกแบบลูปที่ทำให้เอเจนต์ คอมไพล์, lint และทดสอบเพื่อตรวจสอบงานได้ด้วยตัวเอง
- วิศวกรที่คิดแบบเน้น ผลลัพธ์และการออกแบบระบบ มากกว่ารายละเอียดการเขียนโค้ด จะปรับตัวเข้ากับการพัฒนาแบบ AI-native ได้ดีกว่า
Peter Steinberger คือใคร
- ผู้ก่อตั้งที่พา PSPDFKit เติบโตเป็นธุรกิจเครื่องมือสำหรับนักพัฒนาระดับโลก
- กลับมาทำงานอีกครั้งหลังพักไป 3 ปี และครั้งนี้วาง LLM และ AI agent ไว้ที่ศูนย์กลางของเวิร์กโฟลว์
- ประสบการณ์จากการดูแลทีมพัฒนามากกว่า 70 คน สอนให้เขารู้จักปล่อยวางความสมบูรณ์แบบ และทักษะนี้ช่วยเพิ่มประสิทธิภาพในการทำงานกับ AI agent อย่างมากในปัจจุบัน
- ในเดือนมกราคม 2026 เดือนเดียว เขาทำ คอมมิตมากกว่า 6,600 ครั้ง แสดงให้เห็นถึงผลิตภาพที่ผิดปกติสำหรับนักพัฒนาเดี่ยว
- งานทั้งหมดเกิดขึ้นใน โปรเจ็กต์ส่วนตัว ไม่ใช่ของบริษัท และเขากำลังสนุกกับการพัฒนาอย่างแท้จริง
Moltbot กับการเติบโตแบบระเบิด
- ทำสถิติ อัตราการเติบโตของดาวที่เร็วที่สุดในประวัติศาสตร์ บน GitHub และเมื่อเทียบกับ Tailwind CSS แล้ว เส้นกราฟการเติบโตก็อยู่ในระดับที่แทบไม่เคยมีมาก่อน
- สัปดาห์ที่ผ่านมา มี ปริมาณการค้นหาบน Google มากกว่าผลรวมของ Claude Code และ Codex
- คำพูดของ Peter: "ถ้าดูจากคอมมิตอาจจะเหมือนบริษัท แต่จริง ๆ แล้วคือคนคนหนึ่งที่นั่งเขียนโค้ดเล่นอยู่บ้าน"
10 บทเรียนสำคัญจากเวิร์กโฟลว์ที่ขับเคลื่อนด้วย AI agent
- เลิกยึดติดกับความสมบูรณ์แบบ: หากยอมรับได้ว่าโค้ดอาจไม่ตรงกับรสนิยมของตัวเองเสมอไป ก็จะทำงานกับเอเจนต์ได้อย่างมีประสิทธิภาพมากขึ้น
- ปิดลูปให้ครบ: ต้องออกแบบระบบให้ AI agent สามารถคอมไพล์, lint, รัน และตรวจสอบได้ด้วยตัวเอง
- Pull Request ตายแล้ว และ "Prompt Request" กำลังมา: การดูพรอมป์ต์ที่ใช้สร้างโค้ดสำคัญกว่าการดูตัวโค้ดเอง
- รีวิวโค้ดกำลังหายไป และถูกแทนที่ด้วยการถกเถียงด้านสถาปัตยกรรม: แม้แต่ใน Discord เขาก็คุยกับทีมหลักเฉพาะเรื่องสถาปัตยกรรมและการตัดสินใจใหญ่ ๆ ไม่ได้คุยที่โค้ดโดยตรง
- รันเอเจนต์พร้อมกัน 5~10 ตัว เพื่อรักษา สภาวะลื่นไหล (flow)
- แต่ละเอเจนต์ทำงานกับฟีเจอร์คนละส่วนแบบขนาน
- ลงทุนเวลาไปกับการวางแผนอย่างมาก และชอบใช้ Codex
- คุยวนซ้ำกับเอเจนต์เพื่อสร้างแผนที่แข็งแรง
- ท้าทายแผน, แก้ไข, โต้แย้ง จนพอใจแล้วจึงลงมือทำและไปต่อ
- Codex สามารถทำงานยาว ๆ ได้อย่างอิสระ แต่ Claude Code มักกลับมาขอคำชี้แจงบ่อย ทำให้เสียสมาธิ
- ตั้งใจใช้พรอมป์ต์ที่เจาะจงน้อยลง เพื่อค้นพบวิธีแก้ปัญหาที่คาดไม่ถึง
- CI บนเครื่องดีกว่า CI ระยะไกล: แทนที่จะรอ remote CI 10 นาที เอเจนต์จะรันทดสอบบนเครื่องทันที
- โค้ดส่วนใหญ่คือการแปลงข้อมูลที่น่าเบื่อ: ไม่จำเป็นต้องยึดติดมาก และควรเอาพลังไปโฟกัสที่ การออกแบบระบบ
- วิศวกรที่สนใจผลลัพธ์มากกว่ารายละเอียดการเขียนโค้ด ทำงานร่วมกับ AI ได้ดี
- วิศวกรที่ชอบแก้โจทย์อัลกอริทึมแบบพัซเซิล มักลำบากกับการเปลี่ยนผ่านสู่ความเป็น "AI-native"
- คนที่ชอบส่งมอบผลิตภัณฑ์จะปรับตัวได้ดีกว่า
มุมมองต่ออนาคตของวิศวกรรมซอฟต์แวร์
- AI ไม่ได้ทำให้วิศวกรรมซอฟต์แวร์ตาย ตรงกันข้าม มันเป็นไปในทิศทางตรงข้ามเสียด้วยซ้ำ
- Peter เป็นสถาปนิกซอฟต์แวร์ที่ เก็บโครงสร้างระดับสูงของโปรเจ็กต์ไว้ในหัวได้เสมอ
- เขาใส่ใจกับสถาปัตยกรรม, หนี้ทางเทคนิค, ความสามารถในการขยายระบบ, ความเป็นโมดูลาร์ อย่างลึกซึ้ง
- หนึ่งในเหตุผลที่ Moltbot ประสบความสำเร็จคือ มีความสามารถในการขยายสูงมาก
- เขาลงแรงเพื่อให้เพิ่มฟีเจอร์ใหม่ได้ง่าย
- ในฐานะ "เผด็จการใจดี" ของโปรเจ็กต์ เขารักษาทิศทางและความสม่ำเสมอของสไตล์ไว้
บริบทและข้อจำกัด
- Moltbot เป็น โปรเจ็กต์เชิงทดลองที่ตั้งอยู่บนสมมติฐานของการทำซ้ำอย่างรวดเร็ว และยังอยู่ระหว่างดำเนินงาน
- "เคลื่อนที่ให้เร็วและทำให้พัง" คือวิธีเดียวที่จะทำให้โปรเจ็กต์แบบนี้สำเร็จ
- ไม่ใช่ทุกทีมและทุกผลิตภัณฑ์จะนำไปใช้แบบเดียวกันได้
- ถึงอย่างนั้น ก็ยังถูกมองว่าเป็นกรณีศึกษาของ การค้นพบความต้องการที่แม้แต่แล็บวิจัย AI รายใหญ่ก็ยังคาดไม่ถึง
26 ความคิดเห็น
ผมไม่เข้าใจเลยว่าทำไมถึงยังชอบเข้าใจผิดว่าเครื่องจักรทำนายผลเป็นเครื่องจักรที่คิดเป็น
เนื่องจากเครื่องคิดเลขทำงานบนพื้นฐานของอัลกอริทึมแบบกำหนดแน่นอน ผมจึงคิดว่าอุปมานั้นไม่เหมาะสม
และผมไม่ได้คัดค้านการใช้ AI แต่ผมมองว่ามีปัญหากับวิธีการใช้ AI ที่บทความนี้นำเสนอ
เป็นเพราะมันถูกสร้างขึ้นตามโครงสร้างที่เราคิดไว้
พื้นฐานคือยกเอาวิธีที่เซลล์สมองเชื่อมต่อกันมาทั้งหมด และเราไม่สามารถเห็นได้อย่างชัดเจนว่ามันคิดผ่านกระบวนการแบบใด
แม้แต่ "ความคิด" เอง เราก็ไม่รู้ว่ามันเกิดขึ้นผ่านกระบวนการใดในสมอง ดังนั้นรูปร่างพื้นฐานและปรากฏการณ์จึงเหมือนกัน
เพราะอย่างนั้นจึงมองว่าสมองของมนุษย์ก็เหมือนกับเครื่องจักรสำหรับการคาดการณ์
มีบางสาขาที่มองว่าสิ่งที่เราเรียกว่าการคิดเป็นปรากฏการณ์เชิงกลไก และจึงเห็นว่าการแฮ็กสมองก็เป็นไปได้ด้วย
ทั้งคู่เป็นกล่องดำ และแม้โครงสร้างพื้นฐานจะเหมือนกัน แต่ก็ไม่ควรฟันธงว่าเหมือนกัน
มันไม่เหมือนกันเสียทีเดียว และในขณะเดียวกันก็ไม่ได้ต่างกันเสียทั้งหมด
การที่บอกว่าคล้ายกันก็หมายความว่ามีส่วนที่ร่วมกันอยู่
ท้ายที่สุดแล้ว การที่ผู้คนมีความเห็นต่างกันก็น่าจะขึ้นอยู่กับมุมมองว่ามันคล้ายกันมากแค่ไหน
แม้จะมองว่าเหมือนกันทุกประการไม่ได้ แต่ผมมองว่ามันคล้ายกัน
และในมุมมองเรื่องการคาดการณ์และความคิดตามความเห็นของคุณ geek12356 ผมก็คิดว่าเป็นเช่นนั้น
ในขณะเดียวกัน ผมก็มีมุมมองด้วยว่า เพราะมันมีสติปัญญาสูงกว่ามนุษย์ จึงแตกต่างจากมนุษย์
อย่ากลายเป็นรุ่นพี่ประเภทที่คนอื่นใช้ฟังก์ชัน Excel คำนวณได้หลายร้อยบรรทัดใน 1 วินาที แต่ตัวเองกลับนั่งกดเครื่องคิดเลขคำนวณทีละอย่างแล้วบอกว่า "อย่าใช้ฟังก์ชัน"
ผมว่าการเปรียบเทียบกับฟังก์ชัน Excel กับเครื่องคิดเลขมันไม่ค่อยถูกนะ
ถ้า LLM มีความแม่นยำ 100% ก็ยอมรับครับ..
บอกว่าจะไม่ใช้เครื่องคิดเลขแต่กลับดีดลูกคิด ผมไม่เข้าใจเลย
อย่างแรกเลย ถ้าเป็นผลิตภัณฑ์ที่พัฒนาด้วยวิธีแบบนี้ ผมก็คงไม่อยากใช้ครับ
ถ้าเป็นซอฟต์แวร์รถยนต์หรือการบินที่พัฒนาแบบนี้ ผมยิ่งไม่คิดจะใช้เลยครับ
เพราะงั้นคนญี่ปุ่นส่วนใหญ่ก็ยังใช้แฟกซ์กันอยู่จนถึงทุกวันนี้
ถึงภายนอกมันจะดูเท่มาก แต่ถ้าภายหลังเกิดปัญหาจนต้องแก้ หรือมีช่องโหว่ขึ้นมา ค่าใช้จ่ายน่าจะมหาศาลเลยนะ..
ดูเหมือนว่ามีการรายงานช่องโหว่หลายรายการอยู่แล้วนะ
สุดท้ายแล้วคนก็กลับมามีความสำคัญอีกครั้ง
ไม่รู้ว่าควรมองเรื่องนี้ในแง่บวกหรือแง่ลบดี..
เหมือนว่าคุณอาจใช้อยู่แล้วโดยไม่รู้ตัวนะครับ
ถ้าโค้ดที่เขียนแบบส่งๆ แบบนั้นเกิดมีปัญหาขึ้นมา แล้วสุดท้ายใครกันล่ะที่จะต้องตามไปเก็บกวาด... ถ้ายังสร้างโค้ดกันแบบนี้ต่อไป.. สักวันหนึ่งนรกแบบนั้นจะต้องมาถึงอย่างแน่นอน
น่าทึ่งดีนะครับที่เป็น "Prompt Request" แทน Pull Request
เมื่อก่อนนานมากแล้วผมเคยสนใจ MDA มาก แต่รู้สึกว่ามันไม่สมจริงเลยเลยเลิกไป ตอนนี้มันกลับทำให้เป็นจริงได้แบบนี้นี่เอง
น่าจะดีถ้ามีให้เป็นฟีเจอร์ในที่อย่าง GitHub
"เคลื่อนที่ให้เร็วและพังให้ไว"
ประโยคนี้โดนใจนะ
ความผิดของผมเองอย่างมากที่พยายามจะอ่านโค้ดที่ AI เขียน
ดูเหมือนว่า MoltBot จะยิง PR สำหรับซ่อมตัวเองขึ้นมารัว ๆ จนเจ้าของคงตรวจทั้งหมดเองไม่ไหว 555 จำนวน issue กับ PR ที่พอ ๆ กันก็เพราะแทนที่จะเสียเวลาเขียน issue แล้วรอ แค่สั่งให้ MoltBot สร้าง PR แล้ว push ให้ก็จบเลย 555
มันก็แค่สถานการณ์ที่ AI แยกหมากับแมวได้ขยับเข้ามาใกล้ตัวพวกเราขึ้นอีกนิดเท่านั้นเอง.. ไม่แน่ใจว่ามันมีคุณค่าเกินไปกว่านั้นหรือเปล่า
ดูเหมือนว่าเขาจะชอบ Codex เลยอยากรู้ว่าตั้งค่าไว้อย่างไรบ้างครับ
ใช้ Codex มา 140 วัน ทำไป 115 โปรเจกต์ และน่าจะใช้โทเคนไปเกิน 2.5 แสนล้านโทเคนแล้ว - link
ประมาณ 75 ล้านวอนนะครับ นักพัฒนา AI-native แบบลุยเดี่ยวคงต้องเอ็กซิตก่อนแล้วมีเงินอยู่พอสมควร..
250 พันล้านโทเค็นนี่มันเยอะจนจินตนาการไม่ออกเลย...