Replacing Jira in the age of agents by Icecat Projects

In September 2026, we started replacing Jira, the project-tracking tool we had been using, with our own tool, Icecat Projects. A month later, our teams use it every day, and much of the work in it is done by artificial intelligence (AI) agents: programs that take on a task, carry it out and report back. Here is what inspired us, what we built, and what we learned.

Why leave Jira

Our coding agents could already write code. What they lacked was a place to receive work, ask questions and report back. A Jira ticket is written for a colleague who knows the context. An agent needs a contract: what must be true at the end, and how to prove it.

So we built a tool whose first user would be an agent. Everything a person can do in the interface, an agent can do too, under the same rules.

What inspired us

Three products shaped our thinking.

• GitHub Spec Kit popularised specification-driven (“spec-driven”) development: write the specification, or spec, before the code, and keep the what apart from the how. We share that conviction. Since our specs often span several services, they live in the tracker rather than in a code repository.
• Kiro, Amazon’s AI-powered code editor, showed the value of numbered requirements with acceptance criteria, the conditions that prove a requirement is met, each task tracing back to one. We wanted the same discipline, regardless of the editor.
• Linear, another project-tracking tool, treats agents as team members: you delegate a ticket to an agent, but a person stays accountable. That distinction is at the heart of our tool too.

What we built

In one month, Icecat Projects covered the 20% of functionality that we used to rely on in Jira and in Freshdesk, our former customer support tool. We support development methodologies such as Scrum, Kanban and Waterfall, a customer support desk, and uploaded our full Jira history. On top of that, Icecat Projects gives agents what they need:

• Specs: one-page listing of what must be true when a feature is done, as numbered requirements.
• Delegation: an agent can be handed a spec or ticket, while a person remains accountable.
• Evidence: every ticket links to the requirements it fulfills, and the agent attaches its proof, such as a passing test.
• Full access for agents: agents have access to every action in the interface, with the same permissions as people.

And because of all this the tool was able to develop itself largely by its own agents. It has become a self-improving platform.

From spec to production

After the spec, the work goes through three stages: Sprint, where it is coded; QA (quality assurance), where it is tested; and Production, where it reaches users.

The product owner writes a spec and hands it to an agent. The agent proposes a plan, the tickets it intends to create, and once it is approved, works through them one by one. A QA agent then writes one automated test per acceptance criterion and runs it on our Test environment. A deployment agent moves the version from one environment to the next, and a release agent ships it to production.

Agents never call each other. The board orchestrates: when a ticket reaches a given column, it is handed to the agent in charge. On 8 October, agents completed about forty tickets and planned nine specs in a single day.

People still make the decisions

Delegating is not abdicating. A run pauses when a human decision is needed:

• Questions: an unsure agent asks rather than guesses and waits for the answer.
• Approval: the plan for a spec, and every finished run, is accepted or rejected by a person.
• Go: nothing is deployed or released before the project lead confirms.
• Manual testing: a person tries what automated tests cannot judge.

Agents hold no credentials of their own, and code reaches our main branches only after a person has accepted it.

What we learned

• Let agents pull their work. A board that agents check on their own is simpler and more robust than a platform that pushes tasks to them.
• A blocked agent reveals a gap in the product. When our first automated release stalled because we lacked an access token, we turned the workaround into a feature.
• We are the bottleneck. An agent finishes a ticket in about fifteen minutes. Waiting for a person to merge each one slowed everything down, so agents now chain their work and we approve the result in one go.

What’s next: letting go of what we know

Today, our way of working with agents still mirrors our own. One agent codes, another tests, a third deploys; tickets flow through Sprint, QA and Production, just as they did in Jira. We gave agents our roles and our rituals.

That was probably necessary to start. But several of our habits come from a time when execution was scarce:

• Story points measured human effort. When a spec is built in hours, effort tells us little.
• Sprints paced a limited capacity. An ordered list of specs says more directly what matters.
• Planned versions give way to observed ones: what was actually deployed.
• Separate development, testing and deployment steps mirror human jobs and their hand-offs. For an agent, code, proof and delivery can be a single act.

The next step is to let go. Keep what people do best: deciding what to build, in what order, and judging the result. Rethink the rest around what agents do well.

We did not replace Jira with a better Jira. We are changing our job: less executing, more deciding.