- ใช้ AI agent หลายตัว (claude/o3/sonnet ฯลฯ) เพื่อ ทำให้ตั้งแต่การสร้างโค้ดไปจนถึงการตรวจสอบเป็นอัตโนมัติ ในเวิร์กโฟลว์ "AI Factory" ส่วนตัว
- เมื่อเกิดปัญหา หัวใจสำคัญคือ ปรับปรุงอินพุต (Input) เช่น แผน พรอมป์ต์ และการจัดโครงสร้างของ agent เพื่อยกระดับความอัตโนมัติ แทนการแก้โค้ดที่เป็นผลลัพธ์ (Output) โดยตรง
- เมื่อ ปรับปรุงอินพุตซ้ำอย่างต่อเนื่อง agent ก็จะพัฒนาขึ้นเรื่อย ๆ และเพิ่มประสิทธิภาพงานที่ทำซ้ำได้สูงสุด
- แบ่งบทบาทของแต่ละ agent เช่น วางแผน (o3/sonnet4), ลงมือทำ (sonnet3.7/4), ตรวจสอบ (o3/sonnet4) เพื่อทำงานแบบขนานและสร้างลูป feedback อัตโนมัติ
- แม้แต่ข้อผิดพลาดของโค้ดหรือปัญหาด้านสไตล์ก็ถูก สะท้อนกลับไปยังเทมเพลตแผน เพื่อให้การสร้างครั้งถัดไปดีขึ้น ทำให้ตัว factory เองเติบโตได้ผ่าน การปรับปรุงอินพุตแบบวนซ้ำ
ภาพรวมของ AI Factory และหลักการสำคัญ
- เปิดหน้าต่าง claude code หลายหน้าต่างบน git-worktree ที่ต่างกัน เพื่อคง สภาพแวดล้อมการทำงานที่แยกจากกัน
- o3 และ sonnet 4 ใช้สำหรับ การวางแผน, sonnet 3.7 หรือ sonnet 4 ใช้สำหรับ การลงมือทำ, และ o3 ใช้สำหรับ การประเมินผลลัพธ์
- แบ่ง การวางแผน การลงมือทำ และการตรวจสอบ ให้ agent ต่าง ๆ ทำงานคู่ขนานกันเพื่อเพิ่มประสิทธิภาพ
หลักการแกนกลาง – "ปรับปรุงอินพุต (Input) แทนการแก้ผลลัพธ์ (Output)"**
- เมื่อเกิดปัญหา จะไม่ แพตช์โค้ดที่ถูกสร้างขึ้นโดยตรง แต่จะปรับแผน พรอมป์ต์ และสัดส่วนการผสม agent เพื่อมุ่งไปสู่การปรับปรุงแบบอัตโนมัติ
- แนวคิดคือสร้าง เครือข่าย AI agent แบบโรงงานที่เติบโตได้เองโดยอัตโนมัติ คล้ายเกม Factorio
- ในโครงสร้างนี้ ลูปตั้งแต่วางแผน-เขียนโค้ด-ตรวจสอบ-ปรับปรุง จะหมุนเวียนต่อเนื่อง สร้างสภาพแวดล้อมที่ AI agent ผลิต/ตรวจสอบ/ปรับปรุงโค้ดได้ด้วยตัวเอง
เวิร์กโฟลว์ประจำวัน – โครงสร้างของ factory
- อินเทอร์เฟซหลักคือ claude code และบนเครื่องโลคัลใช้ mcp, Goose (สำหรับเชื่อมต่อโมเดล Azure OpenAI), o3 ฯลฯ
ขั้นที่ 1: การวางแผน (Planning)
- ป้อนงานระดับสูง (task) ให้ claude code → o3 ถามคำถามเพิ่มเติมแล้วสร้างแผน (
<task>-plan.md)
- ในแผนจะมีทั้งคำขอเดิมและแผนการนำไปใช้งานจริง
ขั้นที่ 2: การลงมือทำ (Execution)
- sonnet 4 ตรวจทานแผนแล้วแปลงเป็น รายการงาน
- claude code ลงมือทำงาน โดยเลือกใช้ sonnet 3.7 หรือ 4 ตามความซับซ้อนของงาน
- claude จะทิ้ง บันทึก commit ในแต่ละขั้นของงาน จึง rollback ได้ง่ายเมื่อเกิดปัญหา
ขั้นที่ 3: การตรวจสอบและ feedback (Verification → Feedback)
- sonnet 4 ทำ การตรวจสอบเบื้องต้น กับโค้ดที่สร้างขึ้นโดยเทียบกับแผน
- จากนั้น o3 จะตรวจอย่างเข้มงวดยิ่งขึ้นโดยเทียบกับ แผนและข้อกำหนดเริ่มต้น
- o3 จะชี้ข้อบกพร่องอย่างเข้มงวด เช่น โค้ดที่ไม่จำเป็น (เช่น lint ignore flag) หรือโครงสร้างที่ล้าสมัย
- ปัญหาที่พบจากการตรวจสอบจะไม่ถูกแก้ด้วยการแก้โค้ดโดยตรง แต่จะสะท้อนกลับไปเป็น การปรับปรุงเทมเพลตแผน
- ใช้ git worktree เพื่อรัน claude code หลายอินสแตนซ์แบบขนาน ทำให้ ทำงานหลายอย่างพร้อมกัน ได้
ทำไม "อินพุต" จึงสำคัญกว่า "เอาต์พุต"
- ผลลัพธ์ (Output) ทิ้งได้ แต่แผน/พรอมป์ต์ (Input) เป็นทรัพย์สินสะสม ที่ยังคงถูกเก็บและพัฒนาต่อได้
- หากดีบักที่ส่วนอินพุต (แผน, พรอมป์ต์) ก็สามารถขยายผลไปยังงานทุกชิ้นในอนาคตได้
- เปลี่ยน agent จากตัวสร้างธรรมดาให้กลายเป็น สิ่งที่เรียนรู้และทำงานร่วมกันได้ด้วยตัวเอง
- ตัวอย่าง: เปลี่ยนโค้ดที่โหลด CSV ทั้งหมดเข้า memory ให้เป็นการประมวลผลแบบสตรีม และสะท้อนแพตเทิร์นนี้เข้าไปในแผนสำหรับ CSV ทั้งหมด เพื่อให้ตรวจสอบอัตโนมัติได้ในภายหลัง
การขยาย factory และการทำงานร่วมกันของ agent
- ใช้ MCP เพื่อจัดสรร agent เฉพาะทาง ไปทำงานต่าง ๆ และทำงานแบบขนาน
- ตัวอย่าง: รวบรวมโค้ด Clojure ทั้งหมดแล้วให้ agent เฉพาะทางสำหรับ ใช้กฎสไตล์แบบโลคัล เข้ามาจัดการ เพื่อให้ claude แก้ปัญหาด้านสไตล์ที่เกิดขึ้นในรอบ lint/test/debug
- แม้แต่ในโค้ดของไลบรารีภายใน ก็เพิ่ม ประสิทธิภาพและความสม่ำเสมอ เช่น แทนที่การใช้ retry และ
Thread/sleep แบบเก่าด้วยไลบรารี retry ภายในของตนเอง
- สร้าง agent หน่วยย่อย หลายตัว แล้วนำมาประกอบกันตามงานย่อยเฉพาะทาง เพื่อทำให้ เวิร์กโฟลว์ที่ซับซ้อน เป็นอัตโนมัติได้
- ตัวอย่าง: จากสเปก API และกรณีธุรกิจ สามารถใช้การผสม agent เพื่อ ทำ integration, test และเอกสารประกอบแบบอัตโนมัติ
- แกนหลักคือปรับอินพุตต่อเนื่องแล้วรันซ้ำ พร้อม สะท้อน feedback ไปยังความพยายามครั้งถัดไปเมื่อเกิดความล้มเหลว การชะงัก หรือบริบทไม่ครบ
- ตัวโค้ดเองเป็นของสิ้นเปลือง ส่วนทรัพย์สินที่แท้จริงคือ คำสั่ง (อินพุต) และการจัด agent
- นำบทเรียนจากทุกปัญหา เช่น ความล้มเหลว การชะงัก หรือบริบทไม่เพียงพอ ไปสะท้อนในอินพุตครั้งถัดไปเพื่อทำให้ ลูปของ factory สมบูรณ์
ขั้นถัดไปและทิศทางในอนาคต
- จะเสริม การประสานงานภาพรวมระหว่าง agent เพื่อผลักดันการติดตามและระบบอัตโนมัติของเวิร์กโฟลว์ทั้งระบบ
- จะปรับปรุงการเชื่อมโยง เอกสารทางธุรกิจกับข้อมูลของ agent และเน้นเก็บ ข้อมูลเชิงนามธรรมระดับสูง เพื่อให้ใช้งานได้อย่างมีประสิทธิภาพยิ่งขึ้น
- กำลังมุ่งไปสู่การสร้าง เวิร์กโฟลว์ที่ซับซ้อนขึ้นเรื่อย ๆ พร้อมขยายความร่วมมือและปฏิสัมพันธ์ที่ซับซ้อนระหว่าง agent
- ยังมองหาวิธี ใช้โควตาโทเค็นของผู้ให้บริการหลายรายให้เต็มที่ และสลับใช้งานได้ง่าย (โดยเฉพาะเพื่อรับมือข้อจำกัดโทเค็นของ bedrock sonnet 4)
บทสรุป
- ตอนนี้ AI Factory ทำให้ การสร้างและตรวจสอบโค้ดอัตโนมัติกลายเป็นเรื่องปกติในชีวิตประจำวัน จนสามารถ deploy โค้ดได้ภายในช่วงเวลาดื่มกาแฟหนึ่งแก้ว
- แม้จะยังไม่ถึงขั้นอัตโนมัติเต็มรูปแบบ แต่หลักการ "ปรับปรุงอินพุตแทนการแก้เอาต์พุต" ได้กลายเป็นแก่นแท้ของ factory แล้ว
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ผมคิดว่าบทความนี้คงแทบจะเข้าใจไม่ได้เลยสำหรับคนที่ยังไม่เคยมีโมเมนต์แบบ "aha" กับ Claude Code
ถ้าปลดข้อจำกัดสิทธิ์ด้วย
claude --dangerously-skip-permissionsแล้วปล่อยให้จัดการปัญหาซับซ้อน คุณจะได้เห็น Claude ใช้เครื่องมือต่าง ๆ ได้อย่างอิสระเพื่อแก้ปัญหาวันนี้ผมก็ให้มันคอมไพล์ รัน และดีบักตัวสร้าง Mandelbrot fractal ที่เขียนด้วย 486 assembly ผ่าน Docker
มันทำได้ยอดเยี่ยมมาก
ลิงก์ gist
ผมคิดว่านี่เป็นตัวอย่างที่ง่ายมากสำหรับ IDE หรือ LLM พวกนี้
assembly ก็มีอยู่มากพอในชุดข้อมูลฝึกอยู่แล้ว และ Docker ก็เหมือนกัน
ผมก็เคยปล่อยให้ Cursor วิ่งเล่นเต็มที่ใน codebase ของผม
หวังว่าเครื่องมือรุ่นใหม่ ๆ จะไปถึงจุดนั้นได้จริงสักวัน แต่รู้สึกว่าตอนนี้ยังไม่ถึงขั้นนั้น
อยากแนะนำเพิ่มเป็นวิดีโอนี้ของ Dagger (และผู้ก่อตั้ง Docker) ที่ไปพูดในงาน AI Engineer conference
วิดีโอนี้ อาจจะเข้าใจยากอยู่บ้างเหมือนกัน
เผื่อว่าจะช่วยใครได้เลยมาแชร์ไว้
ผมลดจาก Claude max มาเป็น pro แล้ว และลิมิตการใช้งานที่ 20 ดอลลาร์ต่อเดือนก็ยังเหลือเฟือ
ดูเหมือนกำลังแข่งกับ Gemini CLI เลยดีใจที่ตอนนี้จ่ายน้อยลง
ผมคิดว่าตัวอย่างหรือบริบทระดับนี้แทบทุก LLM จัดการได้โดยไม่ลำบากนัก
ผมเคยให้จัดการงานอัปเกรด dependency ของ Rust ที่ซับซ้อนกว่านี้มาก โดยวนซ้ำเกิน 30 รอบ และมี custom wasm code เข้ามาเกี่ยวด้วย
Claude จะเชื่อมต่อเครื่องมือหลายอย่างอย่าง context7 หรือ mcp-lsp เพื่อรวบรวมรายละเอียด
แต่พอใช้ไปเรื่อย ๆ ก็จะเริ่มชนข้อจำกัด และถ้าผลักให้ละเอียดและยากขึ้น จุดอ่อนก็จะโผล่มา
เรื่องประโยคที่ว่า ถ้าใช้
claude --dangerously-skip-permissionsแล้วปล่อยให้จัดการปัญหาซับซ้อน มันจะใช้หลายเครื่องมือเพื่อแก้ปัญหาผมเคยดู Claude พยายามแก้โค้ดด้วยวิธีที่ผิดอยู่นานเกินชั่วโมง
สุดท้ายผมต้องเข้าไปแทรกเองแล้วสั่งว่า "ให้เขียน unit test ก่อน แล้วค่อยเขียนโค้ดให้ผ่านเทสต์ จากนั้นค่อยกลับมาบอกผม"
Claude Code เป็นเครื่องมือที่เจ๋งจริง แต่ความเป็นจริงคือยังต้องคอยย้ำแผนที่สถาปัตยกรรมพื้นฐานให้อยู่เรื่อย ๆ
ผมคิดว่ายากที่จะประเมินเซ็ตอัปแบบนี้โดยไม่รู้ว่าผลงานโค้ดถูกนำไปใช้งานจริงอย่างไร
ถ้าเป็นแอป vibe coding ที่ใช้เองส่วนตัวก็ฟังดูน่าเชื่อได้ง่าย
แต่ถ้าบอกว่าใช้เขียนโค้ดคุณภาพสูงใน production environment ที่ซับซ้อน มันยังฟังดูไม่น่าเชื่อเท่าไร
เห็นด้วยอย่างยิ่ง
ผมใช้ Claude Code เพื่อเพิ่มความเร็วในการเขียนโค้ดได้มาก แต่ทุกการเปลี่ยนแปลงของโค้ดผมก็ยังต้องตรวจเองเสมอว่าได้ระบบที่เหมาะสมที่สุดหรือไม่
ไม่กี่ครั้งที่ปล่อยให้มันทำไปเองเฉย ๆ สุดท้ายก็ส่งบั๊กไปให้ผู้ใช้
จริง ๆ แล้วผมไม่ค่อยเข้าใจ workflow หรือแนวคิดที่บทความนี้อธิบายเท่าไร
น่าจะเป็นเพราะอธิบายค่อนข้างกว้าง ๆ
ผมจัดการ production system ที่ซับซ้อนเป็นประจำด้วยโครงสร้างที่มีหลาย agent คุยกันเอง, agent แบบ asynchronous, และ git work tree
ไม่ใช่ว่าผมจะไม่เคยแก้ผลลัพธ์เลย แต่ถ้าผลลัพธ์ไม่เป็นอย่างที่ต้องการ ผมมักมองว่านั่นเป็นสัญญาณให้ปรับปรุง workflow ของตัวเอง
ผมก็กำลังลอง workflow คล้าย ๆ กันอยู่ เลยอยากแชร์ประสบการณ์บ้าง
codebase ภาษา Go ที่ผมดูแลมีขนาดหลายแสนบรรทัด และมีผู้ใช้ B2C จริงตั้งแต่หลายหมื่นถึงหลายแสนคน
มีเผื่อเรื่องประสิทธิภาพพอสมควร แต่เป็นสายการเงินที่ความถูกต้องและความน่าเชื่อถือสำคัญมาก
ผมอยู่ในสภาพแวดล้อมที่ใช้ได้แค่คีย์ OpenAI เลยใช้เพียง codex-cli กับสคริปต์ง่าย ๆ สำหรับเซ็ตอัปพื้นฐานอย่าง clone repository, จัด agent, และรัน prompt
ตัวอินสแตนซ์ของ codex จะเตือนผมผ่าน system notification เมื่อถึงคิว และผมใช้ fzf เพื่อเข้าไปเกาะ tmux session ตอนที่ต้องการ
ยังไม่ได้ลอง MCP แต่ก็อยู่ในลิสต์ที่สนใจ
วิธีนี้ช่วยมากกับงานเล็ก ๆ ที่กระจัดกระจาย และตอนนี้ผมก็ทำ PR เล็ก ๆ ได้มากขึ้นเยอะ
metaphor แบบ "cattle not pets" ยังใช้ได้ดี ผมแค่โยน prompt ให้งานเล็ก ๆ อย่างรวดเร็วเพื่อลดการเสียสมาธิ
แต่งานที่ใหญ่กว่านี้ดูเหมือนยังไม่ค่อยเหมาะ หรืออาจเป็นเพราะผมเองยังสร้าง context flywheel ได้ไม่พอ
ส่วนใหญ่ผมยังอ่านและเกลาโค้ดผลลัพธ์เองเสมอก่อนส่งเข้า code review
การจัดการการเปลี่ยนแปลงก็ยังทำด้วยมือเกือบทั้งหมด ทั้ง branch/commit/push ก็ทำเอง
ผมลองเครื่องมืออัตโนมัติไปบ้างแล้ว แต่ยังข้ามไปใช้เต็มตัวไม่ได้
ผมเห็นด้วย 100% กับแนวคิด "อย่าแก้ output ให้แก้ input"
มันเป็นหลักการที่ทรงพลังมากแม้ไม่มี AI และวงการก็กำลังยอมรับกันมากขึ้นเรื่อย ๆ
กับกระบวนการที่ไม่เป็นเชิงกำหนดแบบ LLM มันนำไปใช้ได้ไม่ง่าย และให้ความรู้สึกว่าใกล้เคียงการฝึกฝนมากกว่าวิทยาศาสตร์
ขอบคุณสำหรับบทความดี ๆ
ผมมีบทความชื่อ "Vibe Specs" ที่เสนอ workflow คล้ายกันแต่เรียบง่ายกว่าเล็กน้อย
บทความบล็อกที่เกี่ยวข้อง
ผมใช้กฎนี้กับทั้ง codebase และทำให้ AI ทำสองอย่างต่างออกไป
(1) ให้ถามคำถามก่อนเป็นอันดับแรก
(2) ให้สร้างเอกสาร
spec.mdก่อนเริ่มเขียนโค้ดใจความหลักคล้ายกัน แต่ของผมจำกัดอยู่ที่ LLM ตัวเดียว
ดูเหมือนพวกเราส่วนใหญ่กำลังลองทำสิ่งนี้ในรูปแบบคล้าย ๆ กัน
ในฐานะนักพัฒนาเดี่ยว ผมทดลองระบบอัตโนมัติด้านการผลิตหลากหลายแบบด้วยมุมมองเชิงวิศวกรรม
สำหรับผม เป้าหมายสูงสุดคือการได้ความเชื่อมั่นในโค้ดจาก e2e tests ที่ agent สร้างให้อัตโนมัติ โดยไม่ขึ้นกับตัว implementation
แต่ก็ยังไม่สำเร็จเต็มที่
ตอนนี้ Claude Code ก็รองรับ flow แบบนี้แบบเนทีฟแล้วผ่าน “plan mode”
การต้องมานั่งสร้างไฟล์ .md เองจริง ๆ แล้วรู้สึกช้าและน่ารำคาญ
แนวคิดพื้นฐานคือ เราสามารถทำเอกสารต่อเนื่องได้ว่า system ควรทำอะไรบ้าง ทั้งในระดับสูงและฟังก์ชันย่อย จะพิสูจน์การทำงานอย่างไร รวมถึงแนวทาง implementation เช่น architecture และ code style
เหตุผลที่ใช้หลายโมเดลก็เพื่อช่วยลดอคติ และเพิ่มทางเลือกในการเลือกการปรับจูนให้เหมาะกับงานแต่ละแบบ
สักวันหนึ่ง ระบบขนาดใหญ่และซับซ้อนก็อาจถูกสร้างขึ้นใหม่จากชุด requirement ได้ และเมื่อนั้นซอฟต์แวร์ก็จะตรงกับข้อกำหนดจริงเสียที
เมื่อถึงตอนนั้น "legacy code" ที่เหลืออยู่จะมีเพียงเอกสารสเปกแบบ legacy เท่านั้น
เป็นมุมมองที่ว่าให้แก้ requirement specification ไม่ใช่ generated code
มีมรูปภาพที่เกี่ยวข้อง
ผมสงสัยจริง ๆ ว่าสุดท้ายแล้วกำลังสร้างอะไรกันอยู่
พอคุยเรื่อง AI workflow ทีไร ก็มักแยกไม่ออกว่ากำลังพูดถึง flow ในฝันครึ่งหนึ่ง หรือใช้งานแบบ productive จริง ๆ
ถ้า LLM เขียนโค้ดให้หมด ผมกลับหมดความสนใจไปเลย
จากโปรเจกต์ราว 50 โปรเจกต์ มีแค่ 2 โปรเจกต์ที่สร้างด้วย LLM และถึงอย่างนั้นผมก็ยังลงมือแก้เอง
ที่เหลือก็แค่รู้สึกว่า "น่าจะดีถ้ามี" แต่จริง ๆ ไม่ได้สนใจผลลัพธ์นัก
สุดท้ายก็จะติดอยู่ในลูปที่ต้องต่อสู้กับคอมพิวเตอร์ ด้วยการงัดทั้งเอกสารออกแบบ prompt และข้อมูลตัวอย่างมาใช้ทุกครั้งที่พฤติกรรมที่ต้องการไม่ออกมา
ให้มันช่วยเติมโค้ดทีละนิดยังเร็วกว่าและเครียดน้อยกว่าเยอะ
พอมองย้อนกลับไปก็รู้สึกว่าเสียทั้งเวลาและเงิน แต่ผลลัพธ์คือซอฟต์แวร์ที่พอใช้งานได้แบบฝืด ๆ
ถ้ามี requirement ชัดเจนหรือมี codebase เดิมอยู่แล้ว และผมเป็นคนคอยกำกับนำทาง agent ก็ช่วยได้มากพอสมควร แต่กระแสแบบ vibe coding ถ้าไม่ใช่สคริปต์เล็ก ๆ หรือแอปเฉพาะทางเล็กน้อย ก็ไม่สนุกเลยและแทบไม่ได้คุณภาพตามที่ต้องการ
มันแพงเกินไปด้วย และโค้ดก็ยังรกอยู่ดี
สุดท้ายรู้สึกเหมือนเสียเวลาไปกับการเถียงกับคอมพิวเตอร์ไม่รู้จบ
แบบนี้ทำเองยังดีกว่ามาก
ปัญหาที่เจอเวลาให้หลาย agent ทำงานกันคนละ work tree คือแต่ละตัวจะเสนอไอเดียต่างกันสุดขั้วในทุกรายละเอียด ทำให้ประสบการณ์ผู้ใช้ไม่เป็นหนึ่งเดียวเลย
ตัวอย่างเช่น agent ที่สร้างแดชบอร์ด Documents กับ agent ที่สร้างแดชบอร์ด Design จะออกแบบจากคนละมุมมองโดยสิ้นเชิง
ทั้งความสม่ำเสมอด้านดีไซน์ โครงสร้าง schema ฐานข้อมูล หรือการออกแบบ API ล้วนไม่ไปในทิศทางเดียวกัน
แม้ input จะเหมือนกัน output ก็ยังต่างกัน
สุดท้ายพอพยายามเพิ่มไฟล์ instruction เพื่อรักษาความสม่ำเสมอ โปรเจกต์ใหญ่ก็ลงเอยที่หลายพันบรรทัดเป็นอย่างต่ำ จน context window ก็ไม่พออีก
สรุปแล้วผมคิดว่าการใช้ LLM ขนาดเล็กที่เรียนรู้กฎและ schema เฉพาะทางมาแล้วน่าจะเหมาะกว่า
LLM ขนาดเล็กน่าจะเป็นคำตอบ มากกว่า LLM ขนาดใหญ่ที่ต้องรับมือกับไอเดียกว้างระดับจักรวาลผ่าน prompt
ผลลัพธ์ต่างกันสุดขั้วในแต่ละ agent ความสม่ำเสมอของดีไซน์ก็ไม่มี
สุดท้ายยังไงก็ต้องมี senior อยู่ดี
ไม่ว่าจะเป็น AI หรือคน เราก็ยังต้องเป็นฝ่ายจัดโครงสร้างขั้นต่ำและความยืดหยุ่นที่พอเหมาะ เพื่อให้มันเดินไปในทิศทางที่ต้องการ
ถ้าไม่มีโครงสร้าง แบบนั้นเขียนโค้ดเองยังดีกว่ามาก
ผมสร้างเวอร์ชันแรกด้วยตัวเองก่อน แล้วหลังจากนั้นก็ให้ Claude Code ทำงานต่อด้วยคำสั่งว่า "ทำให้เหมือนตัวอย่างนี้" ซึ่งช่วยรักษาความสม่ำเสมอได้ง่ายกว่า
การเขียนโค้ดแบบ ADHD คือพยายามสร้างโปรดักต์แบบไม่ยั้งแล้ววนซ้ำไปเรื่อย ๆ จนกว่าจะพอดีงั้นเหรอ?
แบบนั้นเขียนโค้ดที่ขยายต่อในอนาคตได้เองเลยไม่ดีกว่าหรือ
ผมมองว่าไม่ควรเพิ่ม carbon footprint โดยไม่จำเป็น
เป้าหมายสุดท้ายคือเอานักพัฒนาออกจากกระบวนการนี้ไปเลย
เจ้าของธุรกิจขอ CRUD app ใหม่ปุ๊บก็เอาขึ้น production ได้ทันที
แน่นอนว่าผลลัพธ์จะเต็มไปด้วยบั๊ก ช้า และบันทึกลงฐานข้อมูลที่ไม่ได้รับการยืนยัน แต่ก็ด้วยท่าทีประมาณว่าไม่ใช่งานของผม
ปิดท้ายด้วยถ้อยคำรุนแรงเชิงเปรียบเปรยเรื่องซดชาร้อนรวดเดียว
การเขียนโปรแกรมเปลี่ยนไปตลอดกาลแล้ว และเราต้องยอมรับการเปลี่ยนแปลงนั้นให้เร็ว
การบอกว่า "ก็แค่เขียนโค้ดเองสิ" ก็เหมือนกับการบอกให้ทุกคนกลับไปดูแลรถม้าด้วยตัวเอง
รถยนต์ก็พังได้เหมือนกัน แต่ไม่ได้แปลว่าเราควรยึดติดกับวิธีแบบเก่า
ผมสงสัยว่าทำไมถึงมีคนพูดอยู่เรื่อยว่า "ก็เขียนเองให้มันขยายต่อได้สิ"
ทุกวันนี้ coding assistant ก็เขียนโค้ดที่ขยายต่อและดูแลรักษาได้แบบ zero-shot กันได้แล้ว อยากถามจริง ๆ ว่าเคยลองขอให้มันทำแบบนั้นหรือยัง
มนุษย์เองสุดท้ายก็ใช้ trial and error เพื่อหาคำตอบต่อไปเรื่อย ๆ เหมือนกัน
ต่างกันก็แค่ว่ายิ่งมีประสบการณ์มากเท่าไร การจำลองในหัวก็ยิ่งดีขึ้น
ถ้าจะหยิบเรื่อง carbon footprint ขึ้นมาเป็นประเด็น งั้นถ้า AI data center ใช้พลังงานหมุนเวียนทั้งหมดก็ถือว่าโอเคหรือเปล่า
ผมคิดว่าเราต้องหาวิธีผสาน AI เข้ากับ workflow ให้มีประสิทธิภาพกว่านี้
คนที่ลองนำ AI มาใช้แบบจริงจังน่าจะเจอปัญหาคล้ายกัน และตอนนี้ก็ยังไม่มีคำตอบที่ชัดเจน
ในขั้นนี้ผมมองว่ากุญแจสำคัญคือการมอบหมายบทบาทที่จำกัดและชัดเจนให้ AI
ตัวอย่างเช่น ใน workflow แบบ agent ที่ใช้ทำ stock research ผมสร้าง AI สองตัวชื่อ ‘Bullish Guy’ กับ ‘Bearish Guy’ ให้มาถกข้อดีข้อเสียของหุ้นตัวเดียวกัน
เมื่อให้ทั้งสองฝั่งค้นข้อมูลจากจุดยืนตรงข้ามกัน ผลวิเคราะห์ที่ได้จะทั้งครอบคลุมและลึกขึ้น
ไอเดียนี้ได้แรงบันดาลใจมาจากการเห็นวิธีที่คนเถียงกันบนโซเชียลมีเดีย
ใน vibe-coding ผลลัพธ์ดูเหมือนแทบไม่ไปไกลเกินกว่าการพูดถึงตัวเอง และสุดท้ายก็เหมือนงานอดิเรกราคาแพงที่สืบทอดจาก 3D printing เป็นการทำของเล่นไม่รู้จบ
ทุกวันนี้ตัวอย่างที่ใช้กันใน vibe coding แบบที่ benchy เป็นให้ 3D printing ก็คงประมาณแอป todo ไม่ใช่เหรอ
คนที่ออกแบบผลิตภัณฑ์หรือทำงานวิศวกรรมต่างก็ใช้กัน
เหตุผลเดียวที่ผู้บริโภคทั่วไปไม่ใช้มากนัก ก็เพราะทุกวันนี้ของพลาสติกแทบทุกอย่างที่ต้องการสามารถสั่งจาก Amazon ได้ทันทีอยู่แล้ว
ถ้าเป็นยุคก่อนมีการช้อปปิ้งออนไลน์ มันคงมีประโยชน์กับคนทั่วไปมากกว่านี้มาก
ต่อไปเทคโนโลยีนี้ก็น่าจะจำเป็นจริง ๆ เฉพาะกับคนที่สามารถออกแบบไฟล์ custom ได้ด้วยตัวเองเท่านั้น