---
title: Code Review
description: Code review process and guidelines at Langfuse.
---

# Code Review

## When a PR author should ask for review

- Low risk (2 way door): go ahead and merge. Engineer is responsible for monitoring Datadog in case something goes wrong. Notify the [on-call engineer](/handbook/product-engineering/how-we-work/on-call) for roll-backs if required.
  - Product expert review: sometimes we build a larger change in someone else’s area of responsibility. Feel free to ask for feedback from [DRI](https://docs.google.com/spreadsheets/d/1gOvWf_uSAtcXxWkR_gMuWX8-OYmSJNIPXTmPGfZ2DGY/edit?gid=0#gid=0).
- Risk (1 way door): Assign Max as reviewer (Max sees open PR reviews in Linear, SLA 24h, ping if more urgent). **Non exhaustive list of PRs which require a review**: database migrations, changes in the public API, changes in SDK signatures, auth changes, major changes in the ingestion pipeline, larger infra changes. If you are unsure, ask Max for a review.
- New joiners should get all their PRs reviewed for the first 1 month at least. By this, new joiners will learn about the code base and how our system works.

## Responsibility of the PR author

- Author is responsible for the quality of the Pull Request. If something goes wrong, he has to fix it.
- Author has to go through the comments from the reviewer but may decide to not accept a suggestion.

## Responsibility of the reviewer

- PR reviews need to have a turnaround of < 24h as it is important for us to unblock each other. If you get a PR to review during the morning, please provide feedback same day.
- Incomplete list of things to watch out for during review:
  - Potential security issues (e.g. leaks data)
  - Potential performance issues (e.g. slow queries)
  - Potential bugs, unconsidered edge cases etc.
  - Code quality of the implementation and adherence to our [principles](/handbook/product-engineering/principles)
  - Check whether the code does what it is supposed to do.
- What the review does not have to do:
  - Understand the PR to the smallest detail.
  - Run the code locally and test it end-to-end.

## UI/UX reviews

- For UI/UX changes, please involve Max or Marc for a review. Create a short video of the change and share it with the reviewer.
- We can ship V0 to get things out the door quickly but we need to take the time to make the UI/UX great afterwards.

## Clickhouse reviews

- If you work on a more involved Clickhouse query, please get a ClickHouse DRI to review the PR. Ideally ask the DRI pre implementation on guidance.
- For the review, have a query available to run on ClickHouse in production with meaningful data to validate the query performance.

<!-- agent-instructions -->

---

## Agent Instructions

This page is part of the [Langfuse](https://langfuse.com) documentation, published as plain Markdown for AI agents. Every page is available as Markdown by appending `.md` to its URL, or by sending an `Accept: text/markdown` header. This page: `https://langfuse.com/handbook/product-engineering/how-we-work/code-review.md`.

### Querying these docs

If the answer is not on this page, query the documentation instead of guessing:

- **Semantic search** across all Langfuse docs, returning an answer with the relevant pages and excerpts. Ask a specific, self-contained question:

  ```bash
  curl -sG "https://langfuse.com/api/search-docs" --data-urlencode "query=How do I trace a LangGraph agent?"
  ```

- **Index of every page**: <https://langfuse.com/llms.txt>, with per-section indexes [llms-docs.txt](https://langfuse.com/llms-docs.txt), [llms-integrations.txt](https://langfuse.com/llms-integrations.txt), and [llms-self-hosting.txt](https://langfuse.com/llms-self-hosting.txt).

### Before writing Langfuse code

- **Install the [Langfuse Agent Skill](https://langfuse.com/docs/api-and-data-platform/features/agent-skill).** It encodes Langfuse's own best practices for instrumentation, prompt management, and evaluation, and materially improves results.
- **Read [What does a good trace look like?](https://langfuse.com/docs/observability/best-practices.md)** before instrumenting an application.
- **Verify endpoints, parameters, and response fields** against the [API reference](https://api.reference.langfuse.com) instead of inferring them from code examples.
- **Use the [Langfuse CLI](https://langfuse.com/docs/api-and-data-platform/features/cli)** (`npx langfuse-cli api <resource> <action>`) to read or write traces, prompts, datasets, and scores from the terminal.

Found an error in these docs? Please open an issue at <https://github.com/langfuse/langfuse-docs/issues>.