Your GitHub Workflow Is Slower Than You Think. Here Is What Replacing It Looks Like.

The first time you noticed it, you probably called it a Monday.

You sit down to ship something. Maybe it is a fix for a customer-reported bug, maybe a feature you have been thinking about since Friday. You know exactly what needs to happen. The code is clear in your head. And then you open GitHub.

You open the repo. You open a second tab to find the related issue. You open a third tab to check whether the pull request you submitted last week has been reviewed. You open a fourth tab because someone tagged you in a discussion. You open the terminal to switch branches. You open a fifth tab because you need to remember which workflow the deploy is gated behind. Twenty minutes have passed. You have not written a single line of code.

This is the part of engineering that nobody puts on a roadmap. It is the part that does not show up in OKRs, that does not appear in stand-ups, that does not have a Jira ticket. It is the slow leak of focus that happens between the work that matters. Most teams have learned to live with it. The best teams have learned to be quietly furious about it.

The interface mismatch

GitHub is one of the most important pieces of infrastructure on the internet. It also happens to be designed for a specific kind of task: browsing. Reading. Reviewing. Inspecting. If you want to look at something, GitHub gives you a beautiful interface to look at it. If you want to do something, you are on your own.

Want to cherry-pick a commit from one branch to another? Open the terminal. Want to find every open pull request not touched in the last two weeks? Hope you remember the search syntax. Want to trigger a workflow with custom inputs? Click into Actions, find the workflow, click the right run, click the Run workflow dropdown, fill in the fields, click run, wait, come back, refresh. Each step is reasonable on its own. Together they form a quiet tax on every release.

The official answer is that this is what command-line tools are for. The unofficial reality is that command-line tools have their own cognitive overhead. The flags are not always memorable. The error messages are not always helpful. The mental model of git itself is famously hostile to anyone who has not internalized it after years of use. And the moment you need to do something that crosses tool boundaries, say, find a failing CI run, read the relevant code, and open a fix PR, you are back in the browser, opening tabs.

This is not a complaint about GitHub specifically. It is a structural observation about the entire developer tooling stack as it exists today. We have built an industry on tools that are excellent at the parts they were designed for and stubbornly indifferent to the parts they were not. Engineers compensate. Engineers always compensate. But the compensation has a cost, and that cost compounds.

What context switching actually costs you

There is no clean academic answer for how much time engineers lose to logistics, because the time is invisible by design. It is the four minutes you spent looking for the right repo. The two minutes spent remembering which branch you were on. The eight minutes spent figuring out why a deploy failed before you even started looking at the code. None of these moments feel large. All of them add up.

The leadership-friendly framing is that engineering velocity is bottlenecked by code review, by infrastructure, by hiring. Those are real bottlenecks. They are also the obvious ones. The less obvious one, the one we have spent the last two years thinking about, is the time between the work. The friction that lives in the space your tools were never designed to span. The minutes that turn into hours that turn into days that turn into the difference between a team that ships and a team that always feels close.

The other thing nobody puts a number on is the cognitive cost. Every time you switch contexts, you pay a tax in working memory. You drop the thread of the problem you were solving. You pick it back up incompletely. You think you remembered everything. You did not. You forgot the edge case you noticed earlier. The bug ships. The post-mortem is written. The lesson is filed under "we need better processes." It was never a process problem. It was the cumulative cost of asking your brain to switch worlds forty times a day.

A different premise

What if the way you interacted with your code was not through a series of interfaces, but through a single conversation?

This is not a hypothetical. It is the premise that has slowly reshaped the developer tools landscape over the last 18 months. The people building the next generation of dev tools have noticed something that the old generation either did not see or could not act on: the bottleneck is no longer how fast a machine can run your command. The bottleneck is how fast you can express what you want.

A good conversation removes the navigation. You do not click into a tab to look up a teammate's name. You say "ask Sarah." You do not browse a directory of restaurants to make a reservation. You say "book us for seven at the place near the park." The interface gets out of the way. The intent becomes the interaction.

Apply that to engineering. You do not navigate to the Branches tab. You say "create a branch off main called feature/auth-refactor and open a draft PR against main." You do not open three tabs to triage notifications. You say "what needs my attention this morning?" You do not search GitHub for stale PRs. You say "find every open PR I have not reviewed in two weeks and surface the ones blocking releases."

This is not a chatbot bolted onto an existing product. A chatbot wrapper around GitHub is a worse GitHub. The interface we are describing is the opposite: it is what happens when you take the entire surface area of GitHub and re-express it as a series of operations the assistant knows how to plan, approve, and execute on your behalf.

The shape of a new workflow

The pattern we keep seeing, both from our own team and from the engineers we have shipped to, is that conversational workflows reorganize a developer's day around outcomes instead of operations.

A typical morning under the old model looks like this. You open your laptop. You open Slack. You scroll for context. You open GitHub. You open the notifications tab. You open a few of them. You open the related PRs. You scan diffs. You open the relevant files in your editor. You realize CI failed on something you pushed last night. You open the failed run. You read logs. You hypothesize. You make a change. You commit. You push. You go back to the notifications tab. You realize an hour has passed and you have not done any of the deep work you sat down to do.

A typical morning under the new model looks like this. You open your laptop. You open one window. You ask: "what needs my attention?" The assistant reads your notifications, identifies which ones are blocking other people, surfaces the failing CI run from your latest push, and tells you what error pattern it found in the logs. You respond: "draft a fix for the failing test and open it as a PR." A plan appears. You approve it. The branch is created, the fix is committed, the PR is opened. You move on to the next thing.

Notice what changed. The number of tools did not decrease. GitHub is still doing all the work underneath. What decreased was the number of decisions, the number of clicks, the number of context switches. You stayed in one conversation. The conversation stayed in one window. Your focus stayed where it belonged: on the actual problem.

The trust question

The honest question that always comes up at this point is: do I want an AI making changes to my repository?

The short answer is: only if you say so. Every write operation in a well-designed conversational interface should be gated by your approval. Reading is free. Inspecting is free. Asking questions is free. But the moment something is about to mutate state, create a branch, open a PR, trigger a deploy, delete anything, the system stops and asks. It tells you what it is about to do. It tells you what will change. You either approve or you do not.

This is not a UX detail. It is the difference between a useful tool and an irresponsible one. We have seen the alternative. We have read the post-mortems for AI agents that confidently push to main. The lesson is not that AI cannot be trusted with infrastructure. The lesson is that AI must be trusted in proportion to how cheap the reversal is. Reading a file? Trust it. Searching for stale PRs? Trust it. Force-resetting a branch? Pause, summarize, and wait for your fingerprint.

The result is a system that is fast where speed is safe and deliberate where deliberation matters. It is the difference between an assistant who knows what you want and a coworker who does what you ask. Both are useful. Only one belongs near your infrastructure.

What you actually buy back

If you collapse all of this into something a CFO can understand, the trade is this. You give up a small amount of clicking. You get back focus.

Focus is the most expensive thing in modern engineering. Every minute an engineer spends on logistics is a minute they are not spending on the problem you hired them to solve. Multiply that by the number of times a day they switch tools. Multiply that by the team. Multiply that across a quarter. The number is large. It is large enough that most teams stop counting because the answer would be uncomfortable.

What conversational developer tools offer is not faster tools. They offer the elimination of the friction between tools. The interface becomes invisible. The work becomes obvious. The engineers you already hired and already trust suddenly have more of their day back, and they have it back specifically during the hours when they are doing their best thinking.

That is the version of the story your finance team will hear. The version your engineers will hear is simpler. The thing you sat down to do is the thing you actually get to do. You stop arriving at the end of the day with the same feeling you had at the start, the feeling that you spent eight hours busy and finished one real thing.

The bet we are making with GitChat

We started building GitChat because we kept losing the minutes between the work. We tried every workflow tool, every productivity app, every keyboard shortcut. They all helped a little. None of them changed the shape of the day.

The thing that changed the shape of the day was the realization that GitHub did not need a better interface. It needed a different one. Not a redesign. A rethink. An interface where the unit of interaction was intent, where the tool was responsible for figuring out the steps, and where the human was responsible for the decisions that actually required a human.

That is what GitChat is. One conversation across the entire GitHub and Vercel surface area. Every write gated by your explicit approval. Plans surfaced before multi-step actions execute. The AI model of your choice, with your own key, so you are never locked into a vendor's roadmap. The repositories you already own, the workflows you already trust, the platform you already pay for. Just without the tabs.

We are not trying to replace GitHub. GitHub remains the source of truth. GitChat is the interface that finally treats your time the way you treat your code: as something worth protecting.

If you have read this far, you already know what the pitch is. The work is the work. The tools should get out of the way. We built GitChat because we wanted to spend our day on the problems we are good at, not on the logistics of describing them to a series of dropdowns. If that sounds familiar, this might be the right interface for you.

Either way, the next time you find yourself opening a fifth tab to do something you already know how to do, ask yourself what the interface is really costing you. The answer is almost always more than you think.