ทุกสิ่งเป็นโค้ด: วิธีบริหารบริษัทด้วย monorepo เดียว

 (kasava.dev)
3 คะแนน โดย GN⁺ 2026-01-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Kasava จัดการกระบวนการพัฒนาผลิตภัณฑ์ทั้งหมดภายใน monorepo เดียว โดยรวมทั้งโค้ด เอกสาร การตลาด และข้อมูลการดำเนินงานไว้ทั้งหมด
  • การเปลี่ยนแปลงทั้งหมดถูกรวมใน คอมมิตเดียว ทำให้สามารถอัปเดตแบ็กเอนด์ ฟรอนต์เอนด์ เว็บไซต์ และเอกสารได้พร้อมกัน
  • เครื่องมือ AI อ้างอิงโค้ด เอกสาร และเว็บไซต์ได้โดยตรง เพื่อทำการตรวจสอบความสอดคล้อง อัปเดตเอกสารอัตโนมัติ และตรวจทานคอนเทนต์
  • ใช้ CLAUDE.md, Selective CI/CD, โครงสร้างโปรเจกต์ npm แบบแยกอิสระ เป็นต้น เพื่อลดความซับซ้อนของรีโพขนาดใหญ่
  • แนวทางนี้ช่วยเสริมสร้าง วัฒนธรรมการพัฒนาแบบ AI-native และลบเส้นแบ่งระหว่างผลิตภัณฑ์ คอนเทนต์ และการดำเนินงาน ทำให้ปล่อยงานและทำงานร่วมกันได้รวดเร็ว

ความหมายของการพัฒนาแบบ AI-native และ monorepo

  • Kasava รวมองค์ประกอบของทุกแพลตฟอร์มไว้ใน Git repository เดียว ครอบคลุมไม่เพียงโค้ด แต่ยังรวมถึงเอกสาร การตลาด อีเมล และเอกสารสำหรับนักลงทุน
    • ตัวอย่าง: ประกอบด้วยไฟล์ TypeScript มากกว่า 5,470 ไฟล์ใน frontend/, backend/, website/, docs/, marketing/, external/ เป็นต้น
  • AI สามารถเข้าถึงทั้งโค้ดและเอกสารพร้อมกันเพื่อทำ ระบบอัตโนมัติที่อิงตามบริบท
    • การแก้ไขเอกสาร การเปลี่ยนราคาบนเว็บไซต์ และการตรวจสอบบล็อก สามารถจัดการได้ด้วยการสนทนาเดียวกับ AI
  • ทุกการเปลี่ยนแปลงถูกดีพลอยผ่าน Git workflow เดียว (git push)
    • โค้ด คอนเทนต์ เอกสาร และการตลาด ผ่านกระบวนการรีวิว CI/CD และการตรวจสอบย้อนหลังแบบเดียวกัน
  • วิธีนี้ช่วยเพิ่มทั้ง ความเร็วและความสอดคล้อง และทำให้วัฒนธรรม “จัดการทุกสิ่งเป็นโค้ด” ฝังรากในองค์กร

เหตุผลที่รวมทุกอย่างไว้ในรีโพเดียว

  • Atomic Changes ข้ามขอบเขต
    • เมื่อแก้ไข Backend API ก็สามารถอัปเดต type definition ของฟรอนต์เอนด์และเอกสารในคอมมิตเดียวกันได้
    • ตัวอย่าง: เมื่อเพิ่มฟีเจอร์เชื่อมต่อ Asana แบ็กเอนด์ ฟรอนต์เอนด์ เอกสาร และเว็บไซต์จะถูกรวมเข้าใน PR เดียว
  • Single Source of Truth
    • ใช้ billing-plans.json เพียงไฟล์เดียวในการกำหนดข้อจำกัดของแพ็กเกจราคา และทุกบริการอ้างอิงจากไฟล์นี้
    • AI ตรวจสอบความสอดคล้องระหว่างแบ็กเอนด์ ฟรอนต์เอนด์ และเว็บไซต์โดยอัตโนมัติ
  • Cross-project refactoring
    • ค้นหาและแก้ไขได้ทั้งโค้ด เอกสาร และตัวอย่างในบล็อกทั่วทั้งระบบจากใน IDE
  • เครื่องมือและไปป์ไลน์ที่ใช้ร่วมกัน
    • ลดความซับซ้อนของการจัดการด้วย CI/CD ร่วมกัน dependency ร่วมกัน และสภาพแวดล้อมการค้นหาร่วมกัน

โครงสร้างรีโพและองค์ประกอบ

  • Core Application:
    • frontend/ ใช้ Next.js 16 + React 19 ส่วน backend/ ใช้ Cloudflare Workers + Hono + Mastra
    • เมื่อ API เปลี่ยน ก็สามารถแชร์ทั้ง type safety และ utility สำหรับการทดสอบได้
  • Marketing:
    • รวม website/, marketing/blogs/, investor-deck/, email/
    • บล็อก อีเมล และเอกสารสำหรับนักลงทุนทั้งหมดถูกจัดการเวอร์ชันแบบโค้ด และย้อนกลับได้ด้วย git revert
  • Documentation:
    • docs/ คือเอกสารสาธารณะที่ใช้ Mintlify และ docs-internal/ คือเอกสารสถาปัตยกรรมภายใน
    • ค้นหาร่วมกับโค้ดได้ และคงข้อมูลให้ทันสมัยแบบเรียลไทม์แทนการใช้วิกิ
  • External Services:
    • รวมบริการที่ดีพลอยแยกภายนอก เช่น Chrome extension, Google Docs Add-on, GCP Functions
    • เมื่อมีการเปลี่ยนแปลงก็สะท้อนพร้อมกันผ่านการแชร์สัญญา API
  • Development Infrastructure:
    • รวม mock server และเครื่องมือทดสอบสำหรับการพัฒนาในเครื่อง เช่น github-simulator/, infra-tester/, scripts/

วิธีดำเนินงานและวัฒนธรรมการพัฒนา

  • ไม่ใช้ workspace
    • คงแต่ละไดเรกทอรีให้เป็นโปรเจกต์ npm แยกอิสระ เพื่อป้องกันการชนกันของ dependency
  • Selective CI/CD
    • GitHub Actions ถูก trigger ตาม path และรันเฉพาะการทดสอบที่เกี่ยวข้อง
  • กฎใน CLAUDE.md
    • บันทึก tech stack คำสั่ง และการตัดสินใจด้านสถาปัตยกรรมไว้ในแต่ละไดเรกทอรีหลัก
    • ผู้ช่วย AI อ่านไฟล์เหล่านี้เพื่อทำความเข้าใจบริบทของโปรเจกต์
  • การตั้งค่าเครื่องมือที่สอดคล้องกัน
    • รักษาค่ากลางร่วมกัน เช่น .prettierrc, .eslintrc, tsconfig.json

ความท้าทายและการรับมือ

  • ขนาดรีโพ: ปัจจุบันใช้เวลา clone ราว 20 วินาที และยังไม่มีปัญหาด้านประสิทธิภาพของ Git
    • มีแผนแยก asset ขนาดใหญ่ไปไว้ที่ R2/S3
  • เวลา build: แต่ละโปรเจกต์ build แยกกัน และใช้ Turbopack, Wrangler, WXT เพื่อให้ rebuild ได้รวดเร็ว
  • ขอบเขตสิทธิ์การเข้าถึง: ทีมขนาดเล็กสามารถเข้าถึงทั้งหมดได้ และหากจำเป็นก็สามารถใช้ CODEOWNERS และ branch protection ได้
  • การสลับบริบท: การสลับไปมาระหว่างหลายภาษา เช่น TypeScript, Apps Script, MJML ถูกบรรเทาด้วย CLAUDE.md และรูปแบบที่เป็นมาตรฐานเดียวกัน

บทสรุป

  • monorepo ของ Kasava ไม่ใช่แค่เทรนด์ แต่เป็น เครื่องมือเพิ่มประสิทธิภาพสูงสุดผ่านการรวมบริบทเข้าด้วยกัน
  • แบ็กเอนด์ ฟรอนต์เอนด์ เอกสาร และการตลาด ทำงานร่วมกันผ่านการเปลี่ยนแปลงเดียว และ AI ตรวจสอบสิ่งนี้แบบเรียลไทม์
  • ผลลัพธ์คือ “monorepo ไม่ใช่ข้อจำกัด แต่เป็น ตัวเร่งประสิทธิภาพ (force multiplier) ”

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-01-01
ความเห็นจาก Hacker News

  • นี่ดูไม่ใช่การจัดการทั้งบริษัท แต่เป็นแค่ ผลิตภัณฑ์หนึ่งตัว (monorepo) มากกว่า
    ไม่มีพวกการเงิน, HR, สัญญา, รูปทีม อะไรแบบนั้น มีแค่โครงสร้าง frontend+backend ที่มีโฟลเดอร์การตลาดเพิ่มเข้ามาแบบแปลก ๆ นิดหน่อย

    • ถ้าไปดูบทความที่ลิงก์ไว้ จะเห็นว่าบริษัทนี้จริง ๆ แล้วแทบจะเป็น บริษัทคนเดียว
      ดังนั้นการใส่ทุกอย่างไว้ใน repo เดียวจึงเป็นไปได้ แต่ก็ทำให้ตั้งคำถามถึงคุณค่าของ “insight” ที่ได้จากสถานการณ์แบบนี้
    • “AI! AI!”
    • ใน repo ยังไม่ได้รวม โค้ดโครงสร้างพื้นฐาน (IaC) ไว้ด้วย
    • ฉันอยากเห็นกรณีที่เอาทุกอย่างใส่ไว้ใน GitHub repo จริง ๆ
      เช่นรวมไปถึง artifact ที่เข้ารหัสไว้ และใช้แนวทางแบบ “มีแค่ CEO ที่ถือกุญแจถอดรหัสจริง ๆ อยู่กับตัว”
      คงดีถ้า GitHub เพิ่มแนวคิดเรื่อง private folder ได้ แต่เรื่องนั้นเกี่ยวกับ ACL เลยอาจจะเป็นคำขอที่เกินไป

  • ฉันสนับสนุนแนวคิด monorepo และ no development branch
    แต่การพัฒนากับการรีลีสควรถูกแยกออกจากกัน
    ควรสามารถตัด stable release แล้ว cherry-pick ได้ และต้องรักษา เสถียรภาพของ API ระหว่าง frontend กับ backend ให้ได้

    • มีคนถามด้วยว่า “no development branch” หมายถึงอะไร
      ถ้าพัฒนาโดยตรงบน main branch ก็สงสัยว่าจะบริหารงานหลายขนาดที่ทำคู่ขนานกันได้อย่างไร
    • มีคนถามหาตัวอย่างที่จำเป็นต้องใช้ cherry-pick แบบชัดเจน
      เจ้าตัวบอกว่าตัวเองดูแลผลิตภัณฑ์มากกว่า 3 ตัวใน monorepo และก็ไม่มีปัญหาแม้จะ deploy เป็นหน่วยตาม stable release
    • บางคนบอกว่าควบคุมจังหวะ deploy ด้วย feature flag
    • อีกคนชอบคง branch เก่า ๆ ไว้
      เขาไม่ชอบ git squash และบอกว่าแนวทางแบบ forking ให้สภาพแวดล้อมที่อิสระกับนักพัฒนามากกว่า

  • คำพูดที่ว่า “เปลี่ยนครั้งเดียว ทุกที่อัปเดตพร้อมกัน” เป็น ภาพลวงตาที่อันตราย
    ในระบบที่มี DB หรือ API ต้องคำนึงถึง backward compatibility อยู่เสมอ
    ในองค์กรที่มีหลายทีม มักเกิดกรณีที่ทีมหนึ่งยังตรวจสอบการอัปเกรดไม่ได้จนทำให้ทั้งองค์กรติดขัด
    ดังนั้น gradual rollout จึงเป็นสิ่งจำเป็น

    • เห็นด้วยเต็มที่ บริษัทเล็ก ๆ (Kasava) อาจพอทำได้ แต่ใน SaaS ระดับโลก แค่ downtime ไม่กี่นาที ก็ร้ายแรงแล้ว
      monorepo เองไม่ใช่เรื่องแย่ แต่การบอกว่า “เปลี่ยนครั้งเดียวแล้ว deploy ทุกอย่างได้ทันที” นั้นเป็นไปไม่ได้
      เพราะ schema ของ DB กับโค้ดไม่สามารถเปลี่ยนพร้อมกันเป๊ะ ๆ ได้
      บทความแบบนี้ดูเหมือน บล็อกที่ AI เขียน และก็ดูเหมือนจะมีลูกค้าจริงน้อยมากด้วย
    • ก็มีคนโต้แย้งว่าที่เก็บโค้ด (repo) กับวิธี deploy ควรถูกแยกออกจากกัน
      อย่าสับสนปัญหาเชิงองค์กรกับปัญหาเชิงเทคนิค แต่ควรประสานด้วย นโยบายระหว่างทีมและภาวะผู้นำ
    • บางคนบอกว่าใช้ monorepo ร่วมกับ การสร้างโค้ดอัตโนมัติ (openapi-generator) เพื่อให้การเปลี่ยน API ระหว่างบริการสะท้อนผลได้ทันที
      และเสริมว่านี่เป็นแนวทางที่ทำได้เพราะทีมเล็ก
    • กับคำกล่าวที่ว่า “ข้อดีคือรวม AI context ไว้ที่เดียว” ก็มีความเห็นว่าแค่ clone หลาย repo มาเป็น workspace ก็พอ
    • ในทางกลับกันก็มีคนบอกว่าสถานการณ์ที่แต่ละบริการถือเวอร์ชันของตัวเองแล้วไม่ยอมอัปเดตนั้นแย่กว่าอีก

  • เมื่อก่อนฉันไม่ชอบ monorepo แต่พอใช้ Claude Code แล้วก็เปลี่ยนความคิด
    ถ้า frontend กับ backend อยู่ใน repo เดียวกัน การซิงก์จะง่าย

    • มีคนบอกว่าแม้จะเปิด Claude จาก parent directory ก็ยังทำงานได้ดี แต่ข้อดีคือ เปลี่ยนทั้งสองฝั่งพร้อมกันใน commit เดียว ได้
    • ก็มีเสียงตอบกลับว่า “ถ้าเหตุผลที่ใช้ monorepo มีแค่เพื่อลด flag ของคำสั่ง มันก็ดูน่าขำอยู่เหมือนกัน”
    • ฉันเองก็เคยรีแฟกเตอร์มาใช้ monorepo เพราะเชื่อม เครื่องมือ LLM หลายตัวเข้าด้วยกันได้ยาก
    • บางคนเลี่ยง yarn workspace เพราะ ปัญหา hoisting ของ React Native แต่ก็บอกว่าการใส่เอกสาร PRD หรือเอกสารแผนงานไว้ใน repo มีประโยชน์ต่อการให้บริบทกับ AI
    • จริง ๆ แล้ว Claude Code จัดการหลายไดเรกทอรีพร้อมกันได้ จึงไม่ได้จำเป็นต้องใช้ monorepo เสมอไป

  • บทความนี้ให้ความรู้สึกเหมือน AI เป็นคนเขียน
    รู้สึกเหนื่อยเพราะหาเนื้อหาที่มนุษย์เขียนจริง ๆ ได้ยาก

    • ถ้าลองรันด้วย GPTZero ก็ดูเหมือนเกือบทั้งหมดเป็นงานที่ AI สร้าง
      ประโยคอย่าง “This isn’t just for...”, “The Challenges (And How We Handle Them)” เป็น สำนวนแบบ AI ชัดเจน
    • แต่อีกด้านหนึ่งก็มีคนบอกว่า “เบื่อเหมือนกันกับการบ่นว่าเป็นบทความ AI”
      ประมาณว่าแม้จะไม่สมบูรณ์แบบ แต่มันก็ยังดีกว่าบทความที่มนุษย์เขียนไม่ใช่หรือ

  • ตรงที่บอกว่า “สั่งให้ Claude อัปเดตหน้า pricing” มันดูแปลก
    ในเมื่อจัดการหน้า marketing ไว้ใน repo เดียวกันอยู่แล้ว การเอางานที่แค่ อ่านข้อมูลจากไฟล์ config ก็พอ ไปให้ LLM ทำมันฟังไม่ค่อยสมเหตุสมผล

    • มีคนชี้ว่า AI กำลังกลายเป็น การเสพติดหรือการพึ่งพา
    • แต่ก็มีคนโต้ว่า “code review ก็ยังมีอยู่”
      การมี AI ไม่ได้แปลว่ามนุษย์จะไม่ตรวจทานอีกต่อไป

  • การเอา “frontend, backend, website” ไว้ใน repo เดียวกันทำให้สับสน
    การรวมกันในระดับ commit ฟังดูดี แต่จริง ๆ แค่ 3 repo ก็จัดการได้พอแล้ว
    ถ้าจะดูแล monorepo ให้ดี ต้นทุนในการบำรุงรักษาก็สูงพอสมควร

  • แม้บทความจะดูเหมือน AI เขียน แต่ตัว แนวคิดที่ขยาย IaC ไปจนสุดทาง นั้นก็น่าสนใจ
    เลยทำให้รู้สึกก้ำกึ่ง

    • น่าแปลกที่คอมเมนต์ส่วนใหญ่จับกลิ่นความเป็น AI ไม่ได้
      ถ้าในอนาคตผู้คนคุ้นกับ สไตล์แบบ LLM มากขึ้น บทความทุกวันนี้อาจดูเชยไปเลยก็ได้
    • มีคนบอกว่าอย่างน้อยก็น่าจะเปลี่ยนคำอย่าง “Why This Matters” เสียบ้าง
    • อีกคนบอกว่าการใช้ AI แต่ไม่ระบุ แล้วโพสต์ในชื่อมนุษย์นั้นให้ความรู้สึกเหมือน ขาดความซื่อสัตย์ทางปัญญา

  • ถ้าเอาเว็บไซต์บริษัทไว้ใน repo เดียวกัน ก็จะหา สื่อด้านแบรนด์และโทนภาษา ได้ง่าย
    จึงเหมาะกับการสร้างสไลด์สำหรับลูกค้าหรือวิดีโอเดโมแบบอัตโนมัติ
    และถ้าขยายไปถึงการรวม เอกสาร, บั๊ก, อิชชู ไว้ในที่เดียวก็ยิ่งน่าสนใจ

  • ที่สตาร์ตอัปเก่า Pangea ก็เคยทำโครงสร้างคล้าย ๆ กัน
    โดยรวมถือว่าดี แต่ก็ไม่ถึงกับสมบูรณ์แบบ

    • พอพยายามจัดการทุกอย่างผ่าน repo ก็ทำให้การเปลี่ยน feature flag ช้า และดูแลเรื่องความไม่เปลี่ยนแปลงของ branch ได้ยาก
    • พอบริการมีราว 20 ตัว GitLab CI ก็เริ่มช้าและซับซ้อนขึ้น
    • การทดสอบ E2E ทั้งช้าและไม่เสถียร ทำให้ pipeline พังบ่อย
      ถึงอย่างนั้นก็ยังมีผลงานอย่างการย้ายไป ARM แล้ว ลดค่า compute ได้ 70%
      ลิงก์ Pangea
    • มีคนถามกลับด้วยว่าเคยใช้เครื่องมือ monorepo อย่าง turbo, buck, Bazel หรือไม่
      เพราะถ้าไม่มีเครื่องมือพวกนี้ ก็มักจะชนข้อจำกัดด้านการขยาย CI ในที่สุด