From Ticket to Merge Request: How AI Handles the Whole Fix for Me

For years, a customer ticket was my nightmare. Someone complains about something or has an idea — and you have to read it, understand it, plan it, code it, test it, and only then deploy it. Every ticket, from scratch. Context switching that shreds your whole day.

I haven’t worked that way for months. AI handles it for me — the whole ticket, from request to merge request.

What it looks like in practice

The customer writes down what bugs them or what they’d like done differently. That’s my entire input. The rest happens without me:

1. The agent plans it. It breaks the request into concrete steps and finds the spots in the code it touches.
2. It executes. It writes the change — not one line, but the whole edit across the codebase.
3. It checks its own work. It runs the build, the tests, reviews its own output, and fixes what doesn’t fit.
4. It opens a merge request. With a description of what it did and why.

And that’s where its job ends. The rest is on me.

What I actually do

I read the final merge request. That’s my entire job on that ticket.

I decide one thing: do I like the solution? Does the change the customer asked for make sense, and am I happy with the way the agent solved it? If yes, I merge — and the change goes to staging or straight to production. If not, I tell the agent what’s wrong and it opens a new MR.

I don’t write code. I judge it.

This site runs exactly like that

You don’t have to take my word for it. The site you’re reading this on runs on the same principle. I assign work through a GitLab Issue — I write down what I want. The agent plans it, implements it, opens a merge request, and if it doesn’t need special approval, it deploys to production on its own once merged. No manual deploy, no “I’ll push it later.”

And this very article went down that same path. Request → agent → merge request → my review → production.

Where it works and where it doesn’t

I won’t pretend this runs everywhere. It doesn’t.

• It works on bounded, repeatable changes with a clear “done”: a bug fix, a behavior tweak, a small feature, content. Where there’s fast feedback — a build, tests, a preview — the agent has a way to know it’s finished.
• It doesn’t work where “done” is a matter of taste, company politics, or context the agent simply doesn’t have. Big architectural calls, sensitive production changes, anything where a mistake costs months — there the human stays deep in the loop.
• And I would never let an agent reach production without that review step. “I like it” isn’t a formality. It’s the entire safety net.

Why I’m writing this now

Because this is exactly what I teach. I’m running a workshop, Stavíme AI agenty (Building AI Agents, June 25, Prague, in Czech) — five hours where everyone builds their own agent on their own use-case. And it’s not just about building one. We also get into how to run it: how to wire it into a real workflow (issue → merge request works fine), where to keep the human safety net, and where to give the agent room.

If “I’d like to be able to do this too” crossed your mind while reading — that’s what the workshop is for.

You might also like

• AI Agents Are Not Ready for Your Business
• Skills vs. Agents: When You Need a Recipe and When You Need a Cook
• Loop: An Autonomous Agent in Your Terminal