Case Study
How a Software Team Went from Two-Week Releases to Fixes in a Day or Two.
A client needed a better way to move everyday software requests from the business to its development team. We connected request intake, task tracking, AI-assisted code changes, and developer review, moving from a two-week sprint cycle to releases in 1–2 days.
- Time to deliver a fix, down from a two-week sprint cycle
- 1–2 Days
- Reduction in the development backlog
- 40%
- Development and QA for minor fixes, down from 5–6 hours
- <1 Hr
The Challenge
A Clear Request Still Needed a Way into the Code.
Give AI a defined part of the development work, and keep the people responsible for the system in charge of what is accepted.
The Business Context
The business relied on software that needed ongoing fixes and improvements. People using the systems could explain what was wrong, but a developer still needed to translate each request into a tracked task, find the relevant code, prepare a change, and bring it through review.
The development queue carried both implementation work and the preparation around it. A request described in a conversation still needed its context carried into the issue tracker and the code review. The opportunity was to give AI a practical role in that workflow while keeping developers responsible for the changes being accepted.
- People using the system could describe the problem, but preparing a code change still depended on developer availability.
- The original conversation, tracked issue, and proposed fix needed to stay connected.
- Developers needed a reviewable change with enough context to judge whether it addressed the request.
- Adding AI needed to fit the team’s review process and ownership of releases.
What We Delivered
We connected the development workflow from a business request through to a reviewed code change. Requests begin in the team’s everyday chat, become tracked work, and provide context for AI-assisted development. AI agents prepare code changes, and the team can also delegate a task to an AI assistant from the same conversation. Every proposed change goes to a developer to review and approve before it moves into release.
The Solution
Four Problems, and What We Built for Each.
01 / 04
“The invoice export is missing its tax column.”
Waits for the next two-week sprint
Bars drawn to scale: fourteen days beside two The Problem
A Small Fix Waited for the Next Sprint
People using the system could describe the problem clearly, but preparing the change depended on when a developer was free.
“The invoice export is missing its tax column.”
Delivered in 1–2 days
Bars drawn to scale: fourteen days beside two What We Built
The Request Starts the Work
A message in the team’s chat becomes a tracked task, and an AI agent prepares the change. The project owner reports fixes in 1–2 days, down from a two-week sprint.
How We Built It
The Request, in Plain WordsSlackWhoever sees the problem describes it where the team already talks
A Tracked TaskLinearThe request becomes an issue, like any other piece of work
AI Prepares the ChangeCursor Cloud AgentsThe agent uses the request and the task to propose a code change
Team members can also tag @Claude in Slack to delegate a task from the same conversation.
02 / 04
- The conversation
- The tracked task
- The code change
Three places, and the context carried by hand The Problem
The Context Got Lost between the Chat, the Task, and the Code
The original conversation, the tracked issue, and the proposed fix lived in three places, and a developer carried the context between them.
- The conversationOPS-142
- The tracked taskOPS-142
- The code changeOPS-142
One issue number ties all three together What We Built
One Thread from the Request to the Fix
The conversation points to the issue, and the issue points to the proposed change. Anyone can follow the work from where it was raised.
How We Built It
One Issue NumberLinearConnects the request, the agent’s work, and the proposed fix
A Linked Pull RequestGitHubThe proposed change carries its task with it
Updates in the Same ThreadSlackThe people who asked can see where the work has reached
03 / 04
“You could probably fix that in the export template.”
A suggestion, with nothing to inspect The Problem
Developers Needed Something They Could Actually Review
A suggestion is not a change. A reviewer needs the real difference in the code, and enough context to judge it.
Add the tax column back to the invoice export
Pull request · Review requested
What We Built
AI Hands Over a Reviewable Change
The agent investigates the relevant code and opens a pull request: a concrete difference a developer can inspect, question, and revise.
How We Built It
Investigates the CodeCursor Cloud AgentsFinds the relevant code from the request and task context
Opens a Pull RequestGitHubThe change arrives the same way a developer’s would
- 03
Context IncludedThe reviewer sees what was expected, and what happened instead
04 / 04
AI prepares a change
?
Release
Who decides what goes live? The Problem
AI Had to Fit the Team’s Ownership of Releases
Adding AI could not change who is responsible for what goes live.
AI prepares a change
Developer decides
Release
Every proposed change goes to a developer first What We Built
AI Prepares. A Developer Decides.
Every proposed change goes to a developer, who can inspect it, ask for revisions, and decide whether to approve it. Merging and releasing stay separate steps.
How We Built It
- 01
A Proposal, Not a ReleaseAn AI-prepared change is a starting point for review
Developer ReviewGitHubA developer assesses the change and the relevant validation
- 03
Approval before MergeRelease remains its own step, owned by the team
How the Pieces Fit Together
The Previous Handoff
- A Software Problem Is Reported
Wait in the Development Queue
Developer Prepares the Change
Code Review
A developer picks up the request, carries its context into the task, investigates the code, and prepares the change before review can begin.
Time to Deliver a FixTwo-Week Sprint Cycle
The Connected Development Workflow
01 · Business Team
Describe the Problem
The business team explains the issue in Slack
02 · Issue Tracker
Track the Work
Linear keeps the request attached to a development task
03 · AI Agent
Prepare the Change
The AI coding agent uses that context to propose a code change
04 · Developer
Review and Approve
A developer assesses the GitHub pull request before release
The AI agent prepares the change. A developer decides whether it is ready to merge and move through the release process.
Time to Deliver a Fix1–2 Days
One Request, Followed in a Single Thread.
# ops-support
Operations Lead10:02 AM
The invoice export is missing the tax column since this morning’s update. @Linear file this as a bug.
LinearAPP10:02 AM
LinearOPS-142 Invoice export is missing the tax column
Bug · Todo · Operations
Operations Lead10:03 AM
@Cursor can you fix OPS-142?
CursorAPP10:11 AM
I read the thread and found the cause in the export template. The fix is ready for review.
GitHub#318 Add the tax column back to the invoice export
Pull request · Open · Review requested
Developer10:24 AM
Reviewed and approved. Merging now.
✅2🙌1
Technologies Used
Slack
Business Requests & Team Context
Linear
Issue Tracking & Work Status
Cursor Cloud Agents
AI-Assisted Code Changes
Claude Tag
Task Delegation in Slack
GitHub
Pull Requests & Developer Review
How the System Was Built
- 01
Start Where the Business Describes the Problem
The workflow begins with a message about what is happening in the system and what needs to change. The person reporting the problem can contribute operational context without writing code or prescribing the technical fix.
Technical Detail: Start Where the Business Describes the Problem
Slack provides the conversation around the request. Team members can tag @Claude through Claude Tag to delegate a task using the connected tools and context it can access. Linear keeps development requests tracked, with the conversation available alongside the work.
- 02
Keep AI Work in the Development Queue
The request becomes a tracked issue before a code change is prepared. The team can refer to the same piece of work as it moves from reported problem to proposed solution and review.
Technical Detail: Keep AI Work in the Development Queue
Linear supplies the issue identifier and task status. That identifier connects the original request to the coding-agent request and the resulting pull request. AI-assisted work remains visible alongside the team’s other development tasks.
- 03
Use AI to Prepare a Change Developers Can Assess
The coding agent uses the request and task context to investigate the relevant code and prepare a proposed fix. That gives the developer something concrete to examine, rather than a suggestion detached from the codebase.
Technical Detail: Use AI to Prepare a Change Developers Can Assess
Cursor cloud agents use the request and task context to prepare code changes. Claude Tag provides another way to delegate work from Slack and receive the response in the thread. Proposed code changes move into GitHub as pull requests for a developer to review and approve.
- 04
Keep Approval with the Developer
The proposed change opens as a pull request. A developer can inspect the difference, assess the behaviour, request revisions, and decide whether to approve it. Preparing the change with AI does not make it ready for release on its own.
Technical Detail: Keep Approval with the Developer
GitHub provides the pull-request review step. Developer approval comes before merge and release. The reviewer remains responsible for assessing the change and the relevant validation.
- 05
Keep the Request Connected to the Outcome
The original discussion points to the issue and the proposed fix. The business team has a path to follow the work, while developers can return to the request when they need to check the intended result.
Technical Detail: Keep the Request Connected to the Outcome
The Slack example carries references to both the Linear issue and the GitHub pull request, followed by the developer’s review update. These links preserve context across the conversation, task, and code change. A merged pull request and a production release remain distinct steps.
The Results
From Two-Week Sprints to Releases in 1–2 Days.
What Was Delivered
The work connects business-side request intake, tracked tasks, AI-assisted code preparation, and developer review. The AI agent contributes a proposed change; the development team retains the decision about whether it should be accepted and released.
Faster Releases, with Developer Review
The project owner reports that releases moved from a two-week sprint cycle to 1–2 days and the development backlog fell by 40%. Minor fixes previously took 5–6 hours of development and QA; they now take under an hour, saving more than 80% of that effort. Request context stays connected through the issue and pull request, with a developer reviewing and approving changes before release.
The project owner supplied the release timings, 40% backlog reduction, and development-plus-QA effort for minor fixes. The effort saving uses the conservative five-hour baseline: reducing five hours to under one saves more than 80%. No measurement period or independent audit was provided. The illustrative conversation timestamps are not used as performance evidence.
What Changed for the People Doing the Work
- Business Teams
- Explain what is happening in the software and stay connected to the tracked request and proposed change.
- Developers
- Use an AI-prepared change as a starting point for assessment, revisions, and validation.
- Reviewers
- Inspect the code change alongside the request and decide whether it is appropriate to approve.
- Delivery Leads
- Keep AI-assisted changes within the issue and pull-request workflow used to track development work.
What This Project Reinforced
Fix the Handoffs as Well as the Coding Step
AI-assisted development is more useful when the request, issue, and code change stay connected. The surrounding workflow determines how the proposed fix reaches review.
Keep the Business Context with the Work
What the person expected and what happened instead help both the agent and the reviewer understand the change being requested.
Treat Generated Code as a Proposal
A prepared change is a useful starting point. Developers still assess the behaviour, validation, and suitability for the system.
Measure the Whole Path to Release
Future evaluation should distinguish time to a proposed change, time in review, and time to release, alongside rework and escaped defects.