Rakita Book Demo
Back to blog
AI at Work

From ticket to pull request

How Kurt picks up a task, writes the code in your repo, runs the tests, and opens a review-ready PR — while your engineers stay on the hard problems.

CR
Cengiz Reis
The Storyteller · 5 min read

Ask any engineering lead where the week actually goes, and you’ll rarely hear “the big, hard features.” Those are the fun part. The week goes to the steady drip underneath them: the small fixes, the version bumps, the form that needs one more field, the migration nobody wants to write, the third “can you just…” of the afternoon. None of it is hard. All of it breaks focus. And focus, once broken, is expensive to rebuild.

That drip is the problem Kurt was built for.

What Kurt actually is

Kurt is an AI software factory — a fleet of coding agents that pick up a task, do the work in your codebase, and open a pull request for your team to review. Not a chat window that suggests snippets. An agent that takes a task from “ready” to a PR you can merge.

Each agent runs in its own isolated container, against its own repository, in a toolchain built for your stack. It reads the task, reads the existing code, writes the change, installs dependencies, runs the build, runs the tests, applies migrations if they’re needed — and when everything’s green, it commits, pushes, and opens the pull request.

The important word in that paragraph is review. Kurt opens PRs. Your team merges them. Nothing ships unseen.

It fits the workflow you already have

The fastest way to kill a good tool is to make people adopt a new ritual for it. Kurt doesn’t ask for one.

You already have a task board. You already write tickets. With Kurt, you mark a task ready the way you always do — and an agent picks it up. Drop a comment on the task, and that kicks off another run. Prefer to nudge it from chat? It works from Telegram too. Want to drive a run by hand and watch it build live? There’s a console for that.

You don't change how you assign work. You just start getting pull requests back.

No migration of your process. No “Kurt-shaped” rewrite of how your team operates. The work goes in where it already goes in, and the result comes back as a PR where you already review them.

The Kurt console — agents running in parallel, each in its own container, with live logs.

Where the value actually lands

The headline metric everyone reaches for is “more shipped,” and yes — a fleet of agents working in parallel ships more than a team typing every line by hand. But that’s not where the real value is.

The real value is what your engineers do with the time they get back. When the routine drip handles itself, your best people spend their best hours on the architecture, the tricky edge cases, the decisions that genuinely need human judgement — instead of the fourth boilerplate CRUD endpoint of the day.

A few things change at once:

  • Throughput scales with the work, not the headcount. Need to clear a backlog before a release? Point more agents at it. They run in parallel, each on its own task, in its own container.
  • Momentum stops stalling. The small stuff that used to wait for “when someone has a minute” gets done while someone has a meeting.
  • Design gets to code faster. Hand an agent a UI ticket and it can read the Figma design directly, then implement against your codebase — less pixel back-and-forth, more shipped screens.

The honest part

It would be easy to write that Kurt is magic. It isn’t, and pretending otherwise would set you up to be disappointed.

Agents work independently, in parallel — they don’t secretly coordinate with each other on a grand plan. Each one does its task well and opens its PR. The orchestration that matters is still yours: you decide what’s ready, you review what comes back, you merge what’s good.

And it’s built so you can stay in control of that. Every agent is isolated by container, so there’s no shared blast radius. Logs stream live, with secrets and tokens redacted. You can see which agents are busy, what phase they’re in, and stop or rebuild any of them from one place. Autonomy you can actually govern — which is the only kind worth having in a codebase.

What the role becomes

Here’s the shift worth sitting with. When the routine work writes itself, the engineer’s job moves up a level — from producing the change to directing and reviewing it. Less typing of the obvious. More deciding what good looks like, and checking that the work meets it.

That’s not a smaller job. It’s a better one. The same way a great editor makes more writers productive than a faster typist ever could, an engineering team pointed at a fleet of agents gets more leverage from the same people — and spends their judgement where judgement is rare.

The backlog was never going to clear itself. Now it has help.

CR
Cengiz Reis
The Storyteller

Turns the way Rakita builds into words — and the way Rakita's customers work into product. Writes about AI at work, the craft behind the platform, and the people shipping it.

More from Cengiz

Related reading

See what Kurt does with your backlog

Bring a real ticket and watch it come back as a pull request.