Why I built Label2Prod

I have spent my career in software engineering, across many clients, products and teams. One problem followed me the whole way, and Label2Prod is my answer to it.

The same problem from every seat

Every delivery team carries a queue of small issues: a total that is wrong after a refresh, a form that rejects a valid address, a report that shows yesterday’s numbers. Each one is understood. Each one is contained. And each one waits for a developer.

I have seen that queue from every seat I have held:

• Engineer. I was the one pulled out of feature work to fix it, then left to find my way back in.
• Head of Frontend. I saw how much of it lands on the screens customers use every day, where a small mistake is in front of every user.
• Head of Software Engineering. I set aside capacity for it in every plan, and it still pushed features out.
• Architect. I wrote the standards that keep a change safe, and saw them skipped first on small fixes made in a hurry.
• Interim CTO. I answered to the business for the dates it moved.

A small issue is expensive because it is small: too small to plan for, too visible to leave. So it either waits behind feature work or interrupts it, and someone pays either way: the person who reported it, the customer who hit it, or the plan the team committed to. Plans do not only slip on hard problems. They slip under dozens of easy ones.

The change itself is usually the smallest part of the work. The time goes into everything around it: chasing missing details, reproducing the problem, finding the right code, writing a test, waiting for review, and rebuilding the focus the interruption broke. None of that shows up in an estimate. All of it shows up in the delivery date.

It is not only my experience. In Stripe’s 2018 survey, The Developer Coefficient, developers estimated that more than 17 hours of a 41-hour week went to maintenance: debugging, refactoring and dealing with errors. In 2025, IDC reported that application development took only 16% of developers’ time in 2024. The hours developers spend building the product are the scarcest hours a team has.

Why does every issue wait for a developer?

The people who find issues usually understand them best: the QA engineer who filed it, the product owner who wrote the story, the support lead who heard it from a customer. What they lack is not knowledge of the problem. It is the engineering around the change: reproducing it in code, proving it with a test, changing only what needs to change, and explaining what was done.

That engineering is a discipline, not a talent. It can be written down precisely: how a change is reproduced, how it is proven, what it may touch and how it is reviewed. Anything that can be written down that precisely can be built into a product. Then the people who understand an issue can solve it themselves, and developers keep their time for the features and the delivery the business is waiting for.

What I built

Label2Prod turns a labeled Jira issue into a tested GitLab merge request. Whoever knows what is wrong adds the label. Label2Prod does the engineering and explains the result in plain words: what was wrong, what changed and how it was proven. No developer skills required.

A person still approves and merges every change. It just does not have to be a developer.

Writing the code was never the hard part of a small issue, and now AI can write both code and tests. Two things were still missing. The first is proof: a change is not worth reviewing until it shows the problem and shows it gone, whether a person or an AI wrote it. The second is access: most AI coding tools are built for developers and live in an editor or a terminal, and teams that plan in Jira and ship from GitLab were largely left out of the agents that start from Jira. Label2Prod holds the AI to proof, and it starts where the rest of the team already works.

The bar I set for every team I led

I built Label2Prod, so I am not a neutral judge. That is why it is built so you never have to take its word, or mine. On every issue, it follows the rules I set for the engineers on my teams:

• Reproduce first, prove after. A fix without a failing test is a guess. Every change comes with a new test that fails before it and passes after it, and your own test suite must pass on a clean copy of the repository. The new test stays in your suite, so the issue cannot quietly come back.
• No proof, no merge request. An unproven change costs a reviewer more than no change at all. If it cannot prove a change, it opens nothing and says why on the issue.
• Ask, don’t guess. A wrong assumption turns one small issue into two. When an issue leaves something out, it asks on the issue and waits for the answer.
• Small enough to review. A change nobody can review is a change nobody should merge. If a change grows too large to review by hand, it is discarded, not opened.
• Least privilege. It gets the access the job needs and nothing more. It pushes only to its own branches and never merges, and it will not change your pipeline settings, secrets or key files.
• Keep an audit trail. Every update is a new Jira comment and every revision a new commit. Nothing is rewritten, so the record is complete for reviews and audits.
• Your keys, your limits. The AI runs on your own Anthropic account, each attempt stops at a fixed spend ceiling, and Label2Prod does not use your code or issues to train AI models.

These are the practices of a secure software development lifecycle, applied one issue at a time. Label2Prod brings them, so the person who asks does not need to know they exist.

Where I would use it, and where I would not

If your team plans in Jira Cloud, ships from GitLab and has more small, clear issues than developer time, I recommend trying it. It works best when:

• the issue says what is wrong, with exact values and steps to reproduce;
• the change fits in one repository and a test can check it;
• the code has tests that run without outside services.

The better an issue is written, the better the result. That is true of every engineer I have worked with, too.

I would not use it for architecture decisions or large features, and today it does not take them on. It does not replace your developers. It takes the queue of small, clear issues off their desks, so their time goes to the work only they can do.

How I would roll it out

If I were introducing it to your team, I would treat it like any change to how a team delivers: start small, keep the guardrails on and measure the result.

1. Pick a handful of small, well-described issues from the backlog.
2. Let the people who reported them add the label: QA, product owners, support.
3. Connect Jira with a service account, keep your default branch protected, and give Label2Prod its own Anthropic workspace with a spend limit.
4. Judge it by its merge requests. Read the proof, merge what holds up, and ask for changes in plain words where it does not.
5. Measure it: how long those issues took from report to production compared with your usual lead time, and how often developers still had to stop planned work. Then decide how far to widen it.

Where this goes

Today Label2Prod takes an issue to a tested merge request. That is the first step, not the destination. My goal is that anyone, engineer or not, can take software from an idea to production with the discipline of a senior engineering team built in, from planning and design to release and operation, with every step proven in plain words. Put simply, I want the standards I spent my career building into teams to be within reach of any team, with or without engineers of its own.

Every step after this one will follow the same rules as the first: start where the work is described, prove every change, and leave the decision to a person.

Try it

Label2Prod is free for early-access teams on Jira Cloud and GitLab, with no credit card, and fixes run on your own Anthropic API key. Setup takes about five minutes in your browser. See what early access includes, or go straight to the setup guide.

If you lead engineering or delivery, I would value your judgment, especially on the issues Label2Prod could not handle. Write to me at hello@label2prod.com.

Sources

• Stripe: The Developer Coefficient (September 2018)
• InfoWorld: Developers spend most of their time not coding, IDC report (24 February 2025)