Today, we're releasing the PostHog Slack app into beta.
We built it for those times when a colleague flags an annoying UI quirk, or a customer mentions a bug. The issues that normally end up on a backlog, untouched and ignored.
With the PostHog Slack app, you @PostHog to "fix this" or "build that". It spins up a sandbox, makes a plan, edits files, runs checks, opens a draft PR, and answers review comments in the thread.
The bot uses your product data as context and follows your repo's rules. It even reacts with emojis while it works, which makes it feel less like a coding tool and more like chatting with a clever teammate.
Try it yourself → setup docs
Paul D'Ambra was the first to fall in love with @PostHog. Among other important blitzscale duties, he owns the #papercuts Slack channel, where anyone can post the small bugs and nits they hit in the app. He'd been fixing them with PostHog Code like a good engineer. Now he mentions @PostHog in nearly every thread.
It's awesome when a prolific engineer gets even more productive, but what makes @PostHog really magical is that it empowers every role. Sales, marketing, customer support – anyone can tag the bot with a bug, a papercut, or a feature idea.
Here's a few examples of @PostHog usage across the org chart:
Will Wearing (technical account manager) asked @PostHog to add support to copy and paste for markdown into PostHog notebooks with proper rendering. The bot wrote the code, added 20 test cases, and auto-closed a related stale GitHub issue.
PostHog/posthog is a massive production repo that most people in a sales role would never feel empowered to touch. Will's PR got merged in less than 24 hours, and the only hiccup was a flaky test (nothing wrong with the code, just CI being CI).
Clearing CI is as much of a job as the code generation itself, and the bot sticks with a PR through red checks and reruns until it's mergeable.
It's not just code generation. You can tag @PostHog with a data question and it runs the same agent loop as PostHog AI. The only difference is that answers turn up where you're already working (i.e. wasting time searching for the perfect reaction emoji).
Cory Slater (product manager) asked @PostHog to pull context on a Session Replay user he was interviewing that afternoon. The bot came back with a full brief: account value, product usage, how long she'd been a customer.
Then it went further. In addition to detecting zero MCP activity, it noticed she works across two PostHog projects with replicated feature flag configs. The bot flagged it as odd and suggested Cory ask about that in the interview. Clever robot.
Lizzie (product marketer), asked in #team-marketing what URL format to use when linking to the PostHog app in emails. She got an answer in the thread – then asked @PostHog to write it into the company handbook. She didn't specify which repo, but the bot figured it out.
Lucas Ricoy (product engineer) asked @PostHog to check whether a recent PR, which aimed to tag WebStats queries by strategy for better performance visibility, actually worked. The logs API was returning stale data (which threw off the bot), but once Lucas confirmed the cutover had happened, the bot not only confirmed the new ones were appearing, but also that one query – stats_table_path_bounce_query – was showing up as a bottleneck.
Then there's Richard (product engineer). He broke his foot at the recent company offsite, posted his x-ray, and asked @PostHog to add it to the secret company feet pics folder. The bot grabbed the image link, labeled it broken bone (real).jpg, and passed 19 CI checks. The resulting PR was merged a lot quicker than Richard's anticipated 4-6 week recovery period.
Over the past two weeks, we've merged 116 contributions from @PostHog into production across AI Observability, Session Replay, Error Tracking, Feature Flags, Workflows, billing, MCP, and the Data Warehouse. No corner of the codebase is off-limits (except our secrets).
The work it's taken off our hands sorts into roughly these categories – and yours probably looks similar:
You'd expect engineers to hate this. A bot opening hundreds of PRs for them to review, non-technical people shipping AI-generated code to production – that sounds like a mess!
It's not, and here's why: the PostHog Slack app understands your codebase and your product data. It doesn't merge its own work. It follows a rigorous review process, and runs a flurry of tests (which most engineers would rather not do).
If CI fails, it fixes the failure. If you add a review comment, it addresses the comment. It pokes you when the PR sits idle until the merge is clean or it runs out of ideas.
The code generation that lands from one sentence prompts are surprisingly good. So good that even Cory Watilo, our resident webmaster, is pleased to @PostHog.
Generating PRs with @PostHog in Slack is so easy it feels illegal, and it's a glimpse at what the self-driving product means in practice.
Despite being a coding agent, it won't answer every @mention with a PR. Every @PostHog mention runs through a two-stage classifier before any work happens:
Both classifiers use Claude Haiku (tiny, fast, cheap) and we track latency and cost with AI Observability.
This simple routing is why Paul's prompt "@PostHog can you generate a team photo of team blitzscale as the Spice Girls" – was correctly classified as non-actionable work.
Paul was disappointed, but the bot knew what it was doing.
The PostHog Slack app is in beta – we skipped alpha by dogfooding it to the extreme.
It's free to install, and free to uninstall when you realize this means you can ship production code from your phone (which, frankly, might be too much power for anyone).
The agent that runs behind @PostHog mentions consumes PostHog AI credits for the LLM work it does. This includes tokens used when planning a task, editing files, reasoning about your data. For credit mechanics, the free monthly tier, billing limits, and the live pricing calculator, see PostHog AI pricing.
Other tools only write code. PostHog is connected to your product data, so you can start from a problem – tag @PostHog with a message like "conversion dropped on signup". It finds the cause in your analytics and replays, explores solutions, and opens a PR to propose a fix. No hopping between a dashboard, a replay tab, and your editor.
No. It runs the same frontier models everyone else does. The difference is context – an agent that can read your funnels, replays, and errors is working from evidence, not guessing at what matters.
Both, in one thread. Explore data and build in the same conversation.
No. It sticks with the PR through failing checks and reruns until it's mergeable – we call that babysitting. On a big repo, getting through CI is often more work than the code.
It only touches repos you connect, and every change goes through a PR you review. Nothing merges without a human saying yes.
Not at all! It's a Slack message. Our sales and marketing teams regularly use it make fixes to our main app. Describe the problem or idea, and the agent takes it from there.
It classifies each @mention first – code task or data question, and which repo. Data questions get answered, not turned into PRs.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。