CASE STUDY –- OPEN SOURCE PRODUCT ANALYTICS

Case study: PostHog Analytics

Kerno indexed PostHog's Django REST codebase and analysed all 2,386 endpoints in under 10 minutes. It then launched a PostHog environment with its real dependencies, including Kafka, ZooKeeper and Postgres, and generated white-box tests against two endpoints.

Set up Kerno for this repo: install the CLI, bind it to this workspace, register MCP with my coding tool, then trigger workspace analysis and list the available apps for me to choose from. Follow the Kerno MCP's instructions throughout. Don't run any tests, and don't set up the environment yet.

Read rather than improvise. kerno init prints what you need, and once MCP is live every Kerno tool carries a What/When description saying what to call next. Follow those, and call kerno_guide for detail. The commands below are the happy path; if kerno init prints something different, its output wins.

Prerequisites that must already exist. If any of these is missing, stop and tell me: Node.js 18+, npm, Docker running, and a git repo.

  npm install -g @kerno/cli
  kerno login
  kerno init -w "<absolute path to this repo>"

Don't run kerno login yourself. It renders an interactive terminal UI and dies immediately in an agent shell with "Raw mode is not supported on the current process.stdin", so the browser never opens. Instead, tell me to run ! kerno login in the prompt myself, then pause and wait for me to confirm I've logged in before continuing.

Run kerno init -w even if something seems to be listening already, never two at once, then use the workspace, port and registration snippet it prints verbatim. The port is per-session, so never reuse one from docs, an old config, or memory. Be aware that init's port and registration snippet render through the same terminal UI, so in an agent or piped shell the plain output may stop at "Starting agent..." with no port and no registration line. If that happens, don't guess: either re-run under a pseudo-TTY to force the full snippet to render (script -q /dev/null kerno init -w "<path>"), or read the port from ~/.kerno/agent.stdout.log (the line "Kerno MCP server started on port N") and build the endpoint as http://localhost:N/mcp. kerno doctor --clean fixes an orphan or inconsistent agent.

Default to registering with the host you are running in, but confirm r, and ask if I want a different one. Don't infer my preference fromthe tool alone. Register at one scope only, project or user, and merge rather than overwrite other servers.                                                           Then allowlist Kerno before calling any tool. A single task runs manypeated status and job polling, so without this I am clicking approveevery few seconds. Explain that to me, show me the change, and apply it once I accept. If it's already present, tell me and move on. Claude Code: "mcp__kerno__*" in permissions.allow in .claude/settings.json or ~/.claude/settings.json. Codex: default_tools_approval_mode = "approve" under [plugins."kerno@kerno".mcp_servers.kerno] in ~/.codex/config.toml. Cursor: no file, tell me to set Run Mode to r id you registered if it isn't "kerno".

Registering the server does not load its tools into a session that was already running. Before you try to call anything, expect the kerno_* tools to be absent, and tell me to reconnect: in Claude Code run /mcp, select the server, and reconnect, or restart the tool. A "Connected" line from claude mcp list is not proof your current session can call the tools, because that check opens its own  Verify only with kerno_get_applications.

Verify with kerno_get_applications; that succeeding means connected. Don't use a healthcheck, which blocks 120 seconds and can report a schema error while MCP is fine, and don't use kerno status, which needs a TTY and exits 1 in agent shells even with CI=true.

Also note: any stop, restart or workspace switch kills the MCP session even on the same port. Re-parse the MCP endpoint URL from the registration snippet and reconnect the same way.

Once connected, let Kerno finish analyzing the workspace, then list the apps it found and present them to me so I can choose which one to test. Stop there and follow the Kerno MCP's tool guidance for what comes next.

COPY SETUP PROMPT

COPY CLI COMMAND

Get started for free | Works with your AI stack

COMPANY

PostHog

LANGAUGE

Python 3.11+

FRAMEWORK

Django REST

LINES OF CODE

6.4M

ENDPOINTS

2, 386

ABOUT POSTHOG

What is PostHog

PostHog is an open-source product analytics platform built for engineers and technical product teams. It bundles product analytics, session replay, feature flags, experimentation, surveys, error tracking, LLM observability and a built-in data warehouse into a single product.

The API is large: 2,386 endpoints, with authorization, billing gates and multi-tenant scoping present in most read paths. Testing it accurately requires access to the data layer, not only the route.

KERNO SETUP

What Kerno did

Full Codebase Indexation

Kerno indexed the PostHog codebase and completed endpoint analysis across all 2,386 routes. This index is the foundation for test generation

Live Environment

A PostHog environment was launched with access to its real dependencies, including Kafka, ZooKeeper and Postgres. Tests therefore run against the same behaviour as production

Data Layer Control

Kerno handles the data layer itself. It seeds tenants, reads rows back and cleans up afterwards, so it can create high fidelity tests and runtime scenarios that mimic production.

Baseline Test

Kerno generated, executed and verified baseline tests on two endpoints, covering validation and security scenarios.

Verified execution

Kerno verified the execution of the tests through a two implementation strategy, running each scenario twice to confirm the result. It produced reusable artifacts, so these tests persist if the baseline moves.

EXPERIMENT -- ENDPOINT 1

GET/api/0/organizations/{organization_id_or_slug}/projects/

What the endpoint does

It lists the projects inside one organisation, but only the ones the caller is allowed to see. PostHog starts from every project, then narrows the list to the teams the user is a member of. That filter is the real permission check, so getting it wrong would leak another company's projects.

If the caller used a scoped API key or OAuth token, the list is narrowed again to the organisations that key is scoped to. The response uses a lighter serializer that also copies a few fields from each project's team record for backward compatibility.

Access Control

Caller must be signed in, hold the project:read scope, and be on a plan that allows multiple projects. Six auth methods are accepted, and role-based rules are checked per project before anything is returned.

Postgres Tables

Read-only, across seven tables: the organisation and its memberships, teams and projects, the API key or OAuth token used, and the access control rules. Team membership is where the real permission decision is made.

Side Effects

None. Nothing is written and no events are fired, so the risk here is leakage rather than corruption.

EXPERIMENT -- ENDPOINT 2

POST/api/projects/{project_id}/feature_flags/

What the endpoint does

It creates a feature flag in one project. PostHog first checks the whole payload is valid: the flag key, its release conditions, any multivariate split and payloads, tags and the dashboards it should link to.

It then stamps the record with who created it, which project it belongs to and version 1, fills in default release conditions, and encrypts payload values if the flag is set up to hold secrets.

Key reuse is handled carefully. A key still held by a deleted flag is freed, and a genuine duplicate returns a clear validation error rather than a database crash.Once the flag is saved, PostHog does the follow-up work: attaching tags and evaluation contexts, creating a usage dashboard by default, linking any analytics dashboards, and recording that a flag was created.

Access Control

Caller must be signed in, hold the feature_flag:write scope, and pass role-based and project membership checks. Six auth methods are accepted, with rate limits per key type.

Postgres Tables

One request can write to eleven tables: the flag itself, tags, evaluation contexts, dashboard links, a usage dashboard with its tiles and insights, the sidebar index and the activity log. It reads teams, cohorts, experiments, properties and early access features while validating.

Encryption and Side Effects

Secret payloads are encrypted before saving, a usage telemetry event is sent, and writes are attributed correctly when an admin is impersonating a user.

VERDICT

Claude’s Review of Kerno

The Bottom Line

Kerno delivers real value for a specific job: characterizing untested endpoints and locking their observed contract, including the error shapes and authz behaviour people forget, as a regression net. In this case it added meaningful coverage to endpoints that had zero tests, and the generated code is high quality and honest about what it is asserting.It creates a feature flag in one project. PostHog first checks the whole payload is valid: the flag key, its release conditions, any multivariate split and payloads, tags and the dashboards it should link to.

The framing of working purely from the codebase oversells the autonomy. The interesting truth of a running system lives in the environment, not the repo, and Kerno needs a knowledgeable operator to hand it that truth. Think of it as a very good, reality-grounded test writer that needs a well-briefed pairing partner rather than a fire-and-forget generator. Used selectively, on important endpoints, with a human reviewing actual against intended, it is worth the setup.

Set up Kerno for this repo: install the CLI, bind it to this workspace, register MCP with my coding tool, then trigger workspace analysis and list the available apps for me to choose from. Follow the Kerno MCP's instructions throughout. Don't run any tests, and don't set up the environment yet.

Read rather than improvise. kerno init prints what you need, and once MCP is live every Kerno tool carries a What/When description saying what to call next. Follow those, and call kerno_guide for detail. The commands below are the happy path; if kerno init prints something different, its output wins.

Prerequisites that must already exist. If any of these is missing, stop and tell me: Node.js 18+, npm, Docker running, and a git repo.

  npm install -g @kerno/cli
  kerno login
  kerno init -w "<absolute path to this repo>"

Don't run kerno login yourself. It renders an interactive terminal UI and dies immediately in an agent shell with "Raw mode is not supported on the current process.stdin", so the browser never opens. Instead, tell me to run ! kerno login in the prompt myself, then pause and wait for me to confirm I've logged in before continuing.

Run kerno init -w even if something seems to be listening already, never two at once, then use the workspace, port and registration snippet it prints verbatim. The port is per-session, so never reuse one from docs, an old config, or memory. Be aware that init's port and registration snippet render through the same terminal UI, so in an agent or piped shell the plain output may stop at "Starting agent..." with no port and no registration line. If that happens, don't guess: either re-run under a pseudo-TTY to force the full snippet to render (script -q /dev/null kerno init -w "<path>"), or read the port from ~/.kerno/agent.stdout.log (the line "Kerno MCP server started on port N") and build the endpoint as http://localhost:N/mcp. kerno doctor --clean fixes an orphan or inconsistent agent.

Default to registering with the host you are running in, but confirm r, and ask if I want a different one. Don't infer my preference fromthe tool alone. Register at one scope only, project or user, and merge rather than overwrite other servers.                                                           Then allowlist Kerno before calling any tool. A single task runs manypeated status and job polling, so without this I am clicking approveevery few seconds. Explain that to me, show me the change, and apply it once I accept. If it's already present, tell me and move on. Claude Code: "mcp__kerno__*" in permissions.allow in .claude/settings.json or ~/.claude/settings.json. Codex: default_tools_approval_mode = "approve" under [plugins."kerno@kerno".mcp_servers.kerno] in ~/.codex/config.toml. Cursor: no file, tell me to set Run Mode to r id you registered if it isn't "kerno".

Registering the server does not load its tools into a session that was already running. Before you try to call anything, expect the kerno_* tools to be absent, and tell me to reconnect: in Claude Code run /mcp, select the server, and reconnect, or restart the tool. A "Connected" line from claude mcp list is not proof your current session can call the tools, because that check opens its own  Verify only with kerno_get_applications.

Verify with kerno_get_applications; that succeeding means connected. Don't use a healthcheck, which blocks 120 seconds and can report a schema error while MCP is fine, and don't use kerno status, which needs a TTY and exits 1 in agent shells even with CI=true.

Also note: any stop, restart or workspace switch kills the MCP session even on the same port. Re-parse the MCP endpoint URL from the registration snippet and reconnect the same way.

Once connected, let Kerno finish analyzing the workspace, then list the apps it found and present them to me so I can choose which one to test. Stop there and follow the Kerno MCP's tool guidance for what comes next.

COPY SETUP PROMPT

COPY CLI COMMAND

Install in 5 mins | No credit card required

Case study: PostHog Analytics

What is PostHog

What Kerno did

Full Codebase Indexation

Live Environment

Data Layer Control

Baseline Test

Verified execution

Results

2,386

<10 mins

16

2

GET/api/0/organizations/{organization_id_or_slug}/projects/

What the endpoint does

Access Control

Postgres Tables

Side Effects

POST/api/projects/{project_id}/feature_flags/

What the endpoint does

Access Control

Postgres Tables

Encryption and Side Effects

Claude’s Review of Kerno

The Bottom Line