Why pipeline results belong in the terminal

You just ran git push. You are in the terminal. You are thinking about the change you just made. On every other platform, the next step is: open a browser, navigate to the repo, find the pipeline run, and wait for results. That is a context switch away from the place where you do your work.

The notification trap

CI platforms try to solve the feedback loop with notifications. A Slack message when the build passes. An email when it fails. A browser notification if you remembered to enable it. None of these are good. Slack messages get buried. Emails are slow. Browser notifications pop up at the wrong time.

The fundamental issue is that notifications are asynchronous. They arrive later, in a different context, when you are doing something else. By the time you see the notification, you have moved on. Now you have to context-switch back to figure out what broke.

Synchronous feedback

gittan streams pipeline output to your terminal during git push. The push does not complete until the pipeline finishes. You see each step start, run, and complete — in real time, in the same window where you ran the command.

If a step fails, you see the error output immediately. You are already in the terminal. You can fix the issue, commit, and push again. The feedback loop is seconds, not minutes.

This only works because gittan pipelines are fast. If a pipeline takes 20 minutes, blocking the push is not practical. But when pipelines run in single-digit seconds — which they do when you pre-pull images, use warm runners, and parallelize steps — blocking is not just practical, it is the better developer experience.

The web dashboard still exists

gittan has a web UI. It shows pipeline history, team metrics, team activity, and repo status. It is useful for managers, for debugging intermittent failures, and for getting a high-level view of team health.

But the web UI is not where developers live. Developers live in the terminal and the editor. The feedback loop for "did my push succeed" should happen where the developer already is, not where the platform vendor thinks they should be.

Why this matters

Developer experience is not about polish. It is about removing friction from the feedback loop. Every tab switch, every page load, every notification that arrives 30 seconds late is friction. Terminal feedback removes all of it.

When the cost of checking CI results is zero — because you are already looking at them — developers push more often, catch issues earlier, and spend less time waiting. That is not a minor workflow improvement. It compounds across every push, every day, every developer on the team.