AI Wrote the Code. Now What?

Six months ago, a friend of mine timed himself.

He kept a stopwatch open in the background of his day for two weeks. Every time he started actually writing code, he hit the timer. Every time he stopped to do something else, he hit it again. At the end of the two weeks, he added it up. He had spent eleven percent of his working hours actually writing code. The rest was everything else.

This is not a story about a productivity-obsessed developer. He is a senior engineer at a company you have heard of. He is good at his job. His ratio is normal. The version of this story we used to tell, that engineers spend most of their time thinking and not typing, was always partially true. What we missed was that the part of the day that was not thinking was not typing either. It was navigation.

Now the typing part is faster.

The bottleneck moved

The last three years have done something to developer workflows that nobody fully predicted. The tools that write code on your behalf, autocomplete on steroids, AI pair programmers, in-editor agents, actually work. They are not perfect. They are not autonomous. But they are good enough that the code-writing part of the day has compressed. A task that used to take forty minutes now takes ten. A boilerplate file that used to take an hour is now seven minutes.

The reasonable expectation, when this happened, was that engineering output would scale proportionally. If writing the code is the bottleneck, and we removed the bottleneck, then the output of every engineer should be many times higher.

It is higher. But not by as much as you would expect. And the reason is something nobody on the tooling side wanted to admit. The bottleneck was never writing the code.

It was everything around the code.

The pull request you have to open. The branches you have to manage. The conflicts you have to resolve. The reviewer you have to chase. The CI run that failed for reasons you do not understand. The deploy that needs to be scheduled around the team's Wednesday freeze. The label that needs to be updated. The release notes nobody wants to write. The milestone you keep meaning to close. The notification you opened, scanned, and forgot.

This is the part of the day that AI coding tools do not touch. And it is, by every honest measurement, where most of your engineers' time still goes.

What the new tools are good at

Let us be specific about where the current generation of AI developer tools shines. They are excellent at writing a function when you describe what you want it to do. They refactor a block of code into something cleaner. They suggest completions as you type. They explain a section of unfamiliar code. They generate tests for code that already exists. They translate intent into a file that does the thing.

This is a real and valuable category of work. It is the category of work that happens inside the editor. The boundary of this category is the editor window. The moment you tab out of the editor, the assistant cannot help you anymore.

And the moment you tab out of the editor is exactly the moment the rest of the day begins.

The other half of the workflow

If you sat down and made a list of every interaction a working engineer has with their code outside the editor, you would surprise yourself. Most of it lives inside GitHub. Some of it lives in the CI dashboard. A portion lives in Slack threads, in Jira tickets, in the deploy console, in the database admin panel. None of it has the focused-attention quality of writing code. All of it adds up to most of the day.

The interactions are unglamorous. They look like this.

You finished a feature. You need to open a pull request. You click into GitHub. You navigate to the repository. You click new pull request. You select the base and compare branches. You write a description. You request reviewers. You add labels. You assign yourself. You click create. That was three minutes.

Three minutes is nothing. Until you remember you do this six times a day. And so does everyone on your team. And before any of those pull requests gets merged, somebody has to review them, which is another twelve minutes per pull request, multiplied across the team, multiplied across the week. Then the pull requests need to be merged, which is another navigate-and-click cycle. Then sometimes they need to be deployed, which is its own set of dropdowns. Then the issues that the pull requests closed need to be updated, which is more clicking.

The cumulative cost of all this is invisible because each piece is small. But the engineers know. They feel it on Friday afternoons when they realize they shipped one real thing this week even though they were busy every minute of every day.

This is the half of the workflow that the current AI tools do not touch. And it is the half where the time is.

Why a different shape

You might ask why nobody has built a Copilot for everything outside the editor. The honest answer is that it requires a different shape of tool entirely.

The editor is a typing surface. The natural way to assist a typing surface is with suggestions and completions. You are typing; the assistant predicts what comes next; you accept or reject. The interaction model is short, frequent, and tied to keystrokes.

The workflow surface is a clicking surface. It is not about completion. It is about navigation, decision, and execution across many independent tools. The natural way to assist a clicking surface is not to suggest the next click. It is to remove the clicks entirely.

The shape that does this is conversation.

When you describe what you want, "open a pull request from this branch against main, request the platform team as reviewers, add the security label, and link issue 4012," you are describing a sequence of operations that, in the old shape, would have taken you nineteen clicks and four tabs. In the conversational shape, it is one sentence. The assistant figures out the steps. You approve or correct. The work happens.

This is not a replacement for the editor. The editor remains the best place to write code. But it is the missing half of the developer toolchain, the one that finally addresses the part of the day where the time actually goes.

Where the trust line should be

The reasonable concern when you suggest letting an AI take action on a repository is that it might do something irreversible. This concern is correct. It is also tractable.

The right shape of a conversational developer tool is one where reading is free, asking is free, but acting is gated. The assistant can search your repository, summarize pull requests, find stale issues, surface failing tests, analyze logs, identify duplicates. None of these actions change anything. They cost you nothing if they are wrong.

The moment the assistant is about to do something that changes state, create a branch, open a pull request, merge, deploy, delete anything, it stops. It tells you what it is about to do. You confirm. It does the thing. The trust is calibrated to the cost of being wrong.

This is the difference between a tool that helps you and a tool you have to babysit. The tools that babysit get turned off. The tools that help get embedded into the daily workflow and stay.

What this changes about how a team operates

When the workflow half of the developer's day collapses from clicks to conversation, something interesting happens to team dynamics. The engineers who used to lose forty minutes a day to logistics suddenly have those forty minutes back. They do not use them to write more code. They use them to think. To review more carefully. To pick up the harder problem. To leave on time.

This is the part that is hard to measure and easy to dismiss. If a CFO asks how much time the new tool saved, the answer in minutes is one thing. The answer in compounded cognitive availability is much larger. Engineers who are not constantly switching contexts make better decisions. Better decisions ship better products. Better products win in the market.

The old story about AI coding tools was that they would replace developers. The honest story is that they made the writing part of the job faster while leaving the rest untouched. The next story is that the rest is finally getting addressed.

What GitChat actually does

GitChat is the missing half. It is the tool that picks up where AI coding assistants stop. You finished writing the code. Now there is a pull request to open. Reviewers to request. CI to monitor. Issues to triage. Releases to cut. A deploy to schedule. A teammate's pull request to review.

You used to do all of that across nine tabs. Now you do it in one conversation. The AI plans the steps. You approve the writes. The work happens.

We do not write your code. The tools that do that are already good. We handle everything else. Pull requests, issues, branches, releases, deployments, code reviews, security alerts, CI failures, labels, milestones, contributors, gists, notifications. The full surface area of the work that happens after the code is written.

You bring your own LLM key. We do not lock you into a model. You use the one you already pay for, the one you already trust. The chat lives in one window. The repository lives where it always has. The team works the way it always has, just without the friction.

The bottleneck in modern software is not how fast your engineers can type. It is how fast they can move from the typing to the shipping. The AI tools you already pay for handle the first half. The rest is still waiting to be solved. We solved it.