We didn’t set out to build a new category of product. We set out to stop juggling.

That’s the word Gyo, the senior engineer who built the first version of Kepler, keeps coming back to when he talks about where it started. “I have a lot of terminals opened, and with all those tabs, it was very difficult for me to keep focused on what I was doing,” he says. “I’m not a juggler.”

The problem wasn’t writing code. It was managing everything around it.

Adam, one of Gyo’s colleagues, asked if he had any ideas for how to work with multiple AI agents at once, how to orchestrate them instead of babysitting them one tab at a time. Gyo already had a proof of concept sitting around, something he’d built out of his own frustration with the tooling that existed. It was rough. But the idea underneath it was solid enough that it became Kepler.

Here’s the workflow Gyo was trying to escape: open Jira, find an issue, copy the URL, paste it into a terminal or into Claude Code Desktop, ask the agent to start working. Then do the same thing again for the next issue, and the next agent, and the next tab. Somewhere in there, switch over to GitHub to check on a PR. Switch back. Lose track of which terminal is running which task.

“It has worked fine,” Gyo says, “but it was a little bit too manual, and it was also a difficult way of relating what issue I’m working on.” He didn’t want to just trust an agent to update a ticket’s status and move on. He wanted to stay in the loop, steer the work while it was happening, and review it before it published rather than after.

The plan: one place, not twelve tabs

That’s what Kepler does. Developers can start working on issues or reviewing PRs from inside Kepler, without leaving it to check Jira in one tab and GitHub in another. Gyo calls the tab-switching “another thing related to juggling,” and it’s a pain point that isn’t unique to him. Anyone running more than one agent across more than one repository has felt it.

The current build is version 0.8. Not even a 1.0 yet, by design. GitKraken has plenty of ideas for where it goes next, including giving developers access to the full codebase inside Kepler rather than just commits and work in progress.

Is the IDE dead? Gyo doesn’t think so.

InfoWorld ran a piece recently arguing the IDE is dead and the ADE has taken its place. Gyo, self-described as “an old dog,” doesn’t fully agree, even though he admits the IDE gets used less than it used to.

His reasoning is practical, not sentimental. Someone still has to read the code an agent writes. Not line by line, every time, but enough to catch it when an agent builds a new function instead of using one that already exists. “You need really still to read the code,” he says, “and the best way to read code is still an IDE.”

That’s the tension Kepler sits inside rather than tries to resolve. It gives developers a way to read commits and works in progress, human-in-the-loop, without becoming a full IDE itself. Gyo is direct about that boundary: “Are we rebuilding an IDE into a new product? The answer is definitely no.” IDEs still have a place. Kepler isn’t trying to take it.

What this means for developers running multiple agents

Generating code fast was never the hard part. Coordinating what a dozen agents produce across a dozen branches, and getting it from a prompt to something mergeable, is. Kepler is GitKraken’s answer to that gap: a place where developers stay in control while agents do the work, instead of a place where agents run and developers hope for the best.

Kepler is available now through GitKraken’s Public Preview. If you’re the kind of developer who’s been running Claude in one terminal and Cursor in another, it’s worth a look.

Try Kepler in Public Preview →