An extension of Company culture applied to engineering.

Core principles

Unshipped work is work not done

Shipping some value is always the top priority, always. If we ship and people use our product, then we can worry about making it better. If no one uses the product, you can delete the code.

The smaller a pull request is, the better

All pull requests should be single-focused, meaning solve one problem at a time.

There is one exception for bundling changes together, if both conditions are met:

• The change is trivial, meaning we could ask any member of the team, and they will be able to understand the full scope of the change by looking at the git diff.
• The change is very small in scope. For example, it should have no public API implications.

The why https://github.com/mui-org/material-ui-x/pull/1319#issuecomment-811786628

When a PR review process becomes too overwhelming, it’s a strong sign to close the PR and break it down into smaller ones, or to reduce its scope and to give up on the more ambitious changes, as they are not ready.

Use AI agent as an initial reviewer of your work

Before opening a PR, ask Codex or Claude Code to review your work. This will surface any potential issues earlier in the stage, before other humans are involved in the work.

Use @claude review for high-impact/large PRs

We have an code review bot for reviewing high-impact/large PRs. The idea is to run one thorough review of these PRs before they are being merged, without compromising the whole individual tokens budget.

Note: This is not a replacement for using agents locally on multiple iterations for reviewing work in progress PR.

The work is not done until it’s done

Go to the root. We always choose to reduce the scope of what we work on when needed so we can focus on the few things that matter, and do them right, rather than covering more ground in a half-hearted form.

Undocumented solutions are as if no solutions exist

Developers use the documentation to find solutions to their problems. They don't run a treasure hunt in the source. A problem without documentation is a problem unsolved; it's work not done. Developers should also consider undocumented API as private, which might break without following SemVer.