# Step 0: Prep guardrails

> Work with your engineer to make sure the repo has guardrails before you build.

You can experiment because the repo catches mistakes before they matter. If you're joining or starting a repo, work with your engineer to make sure these guardrails are in place.

## The guardrails

- **Checks that catch bad code.** Linting, type-checking, and tests, plus a build step. Your project has a command that runs them; your engineer will tell you what it is.
- **CI that runs those checks for you.** CI, or continuous integration, runs the same checks automatically on the server. Your team configures when it runs, usually on every pull request. GitHub shows the results on the pull request's **Checks** tab. GitLab runs them as a *pipeline* of *jobs*. If a check fails, it turns red, so a broken change is caught before it's merged.
- **Limits on the AI.** An automatic block on dangerous commands, like wiping files or a database. It also limits what the AI can touch on your computer and network.
- **Design checks.** A design harness that flags UI which breaks the design standard. On this repo that is the [DX Design Harness](/harness/install).

These guardrails are what make it safe for a designer to build. Without them, ask your engineer to set them up first.