Analytics tool ส่วนใหญ่บอกได้แค่ว่า bug อยู่ที่ไหน
PostHog กำลังสร้างระบบที่เปิด PR แก้ bug ให้เองตอนที่คุณนอนหลับ
มันคนละเรื่องกัน
PostHog คืออะไร?
Product analytics tool แบบ open-source — event tracking, session
replay, A/B testing, feature flags ครบในที่เดียว ถ้าเคยใช้ Mixpanel หรือ
Amplitude จะนึกภาพออก แต่ PostHog เป็น developer-first กว่าและมี self-hosting
option
ลอง sign up บัญชีฟรีดู — onboarding ง่ายผิดคาด มี SDK สำหรับทุก stack และมี
“PostHog AI” tab แยกออกมาสำหรับ LLM analytics โดยเฉพาะ ถ้าสร้าง AI product
อยู่มันจะ track token usage, model latency, conversation quality ได้ด้วย
แต่นั่นยังไม่ใช่จุดที่น่าสนใจที่สุด
“จาก read-only สู่ doing
company”
CEO James Hawkins เขียนในบล็อกล่าสุดชัดเจนว่า PostHog อยากเลิกเป็น “chat with
your data” และเป็น agents ที่ “code in response to problems we find”
แทน
เดิม PostHog บอกว่ามีปัญหา → คุณต้องไปแก้เอง ต่อไป PostHog จะแก้ให้เลย
Joshua Snyder วิศวกรใน team อธิบาย pipeline
ที่กำลังสร้างเพื่อทำสิ่งนี้ให้เกิดขึ้นจริง
5 ขั้นของ Self-Driving
Product Pipeline
1 — Ingest & Filter ระบบดูด signal ทุกอย่างเข้ามา —
error log, session replay, feedback, experiment result ผ่าน LLM
classifier ที่กรองขยะออกและกัน prompt injection ด้วย
2 — Group Signal
ที่ต่างประเภทแต่เกี่ยวกับเรื่องเดียวกันถูกรวมเข้าหากัน ตัวอย่างที่ Snyder ยกคือ: error log
“checkout null pointer” + Slack message ว่า “checkout พัง” → กลายเป็น issue
เดียว
ตรงนี้น่าสนใจมากเพราะเขาบอกว่า structural similarity ทำงานได้ดีกว่า semantic
similarity — การดูโครงสร้างและ context สำคัญกว่าแค่ความหมายของคำ
3 — Research AI agent วิเคราะห์ root cause ของแต่ละ
issue โดยใช้ PostHog MCP เพื่อดู product data + GitHub API เพื่อดู codebase
4 — Assess ระบบแบ่ง issue ออกเป็นสามกลุ่ม: แก้ได้เลย /
ต้องถามคนก่อน / ไม่คุ้มแก้
5 — Execute สำหรับ issue ที่แก้ได้เลย — ระบบ generate PR
อัตโนมัติ พร้อม merge
5 ขั้นนี้ไม่ได้ซับซ้อนอย่างที่คิด ถ้าแยกทีละขั้น แต่ละอันก็คืองานที่ AI ทำได้ดีอยู่แล้ว — กรอง,
จัดกลุ่ม, วิเคราะห์, ตัดสิน, เขียนโค้ด สิ่งที่ PostHog ทำคือเอา 5 ขั้นนี้มาต่อกันเป็น
pipeline ที่รันเองได้
ประโยคที่น่าหยุดคิด
Snyder พูดไว้ประโยคหนึ่ง — “Agents Will Always Fix a
Problem”
ถ้าโยน problem ให้ agent มันจะแก้ เสมอ ปัญหาคือถ้า problem ที่ให้ไปไม่ดี
คำตอบที่ได้ก็ไม่ดีตามไปด้วย
งานที่สำคัญที่สุดในระบบแบบนี้จึงไม่ใช่การเขียน agent — แต่คือการ define problem
ให้ชัด
ลองคิดกับ workflow ของตัวเองดู ขั้น “Assess” น่าจะยากที่สุดในทุก context —
ตัดสินว่าอะไรควรทำอะไรควรข้ามต้องใช้ judgment ที่ AI ยังไม่มี ระบบ self-driving
ทำงานได้ดีในงานที่ problem definition ชัด แต่งานที่ต้องการ editorial sense
ยังต้องการคนอยู่
MCP เป็นกระดูกสันหลัง
อีกอย่างที่ Snyder พูดถึงคือ MCP (Model Context Protocol) ซึ่ง PostHog
กำลังขยาย เพื่อให้ AI agent จาก Claude, Slack, WhatsApp, หรือ code editor
เรียกใช้ข้อมูล PostHog ได้โดยตรง
ตัวเลขที่น่าสนใจ: MCP usage ของ PostHog กำลัง double
ทุกเดือน
ซึ่งบอกว่าทิศที่ developer กำลังไปคือการใช้ AI agent เป็น interface กับ tool
แทนที่จะเปิด dashboard เอง PostHog เห็นเทรนด์นี้และกำลังสร้างโครงสร้างรองรับ
พร้อมใช้แล้วหรือยัง?
ตรงไปตรงมา — pipeline 5 ขั้นที่ Snyder พูดถึงยังอยู่ในช่วงพัฒนา ไม่ใช่ feature ที่กด
on ได้วันนี้
PostHog AI tab และ MCP integration มีให้ใช้แล้ว แต่ส่วน “แก้ bug อัตโนมัติ”
ยังเป็น vision ที่กำลังสร้าง
และนั่นทำให้น่าติดตามมากขึ้น ไม่ใช่น้อยลง เพราะเห็น architecture
ของระบบก่อนที่มันจะสมบูรณ์ และสิ่งที่น่าสนใจไม่ใช่แค่ feature — แต่คือทิศที่ devtool กำลังไป
ซึ่งไม่ใช่ “ข้อมูลเยอะขึ้น” แต่คือ “ลดงานที่คนต้องทำมากขึ้น”
analytics tool ที่เก่งที่สุดในอนาคตอาจไม่ใช่ตัวที่แสดง dashboard สวยที่สุด
แต่คือตัวที่ทำให้คุณไม่ต้องเปิด dashboard เลย
PostHog มี free tier ให้ลองที่ posthog.com — ถ้าคุณสร้าง product หรือ AI
app อยู่ LLM analytics tab น่าลองดูครับ