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.
These guardrails are what make it safe for a designer to build. Without them, ask your engineer to set them up first.