Why CI Exists: The Feedback Loop Is the Product

Before CI, "it works on my machine" was a valid status update. CI is the machine that answers "does it work anywhere?" on every commit — and its real product is the feedback loop, not the artifacts.

The contract CI enforces

Every pushed commit: builds, passes tests, passes lint. If main is green, anyone can branch from it confidently. If red, the highest priority is making it green — a red main is a team's collective debt because every new branch inherits the breakage.

What belongs in the gate

• Build: the code compiles/packages on a clean machine — catches "works on my machine."
• Tests: the suite — catches behavior regressions.
• Lint/typecheck: the cheap consistency checks — catches the classes of bugs tests miss.
• Security scans: dependency audit at minimum — catches known-vulnerable packages.

What doesn't belong: flaky tests (they train people to ignore red), hour-long jobs (they train people to skip CI), manual steps (they make the gate optional).

The speed budget is the feature

Under 10 minutes is the working target — longer and developers route around it: batching pushes, merging without waiting, ignoring failures. Every optimization (caching, parallelism, job splitting) is an investment in the gate being respected.

Field notes

• CI fails the build; it doesn't shame people — treat red as information, not blame.
• Green main is a team responsibility, not the last committer's alone — who broke it matters less than unbreaking it.
• A pipeline nobody trusts is worse than none — it teaches that red is normal.