AI coding assistants can double development velocity. But our sprint boards told a different story – half the work was invisible. The problem wasn't that developers stopped caring about tracking. The problem was that every existing integration captured work at the wrong moment.
We built an MCP-based system that captures developer intent when they start thinking about work, not when they finish it. This post covers what we learned wiring DevRev's work-tracking into Cursor through the Model Context Protocol.
That gap showed up clearly on a DevRev LinkedIn Live from May 2025, where Ahmed Bashir and Shivam demoed the flow end to end: AI-assisted coding had pushed internal team productivity to roughly 2×, yet work still failed to show up in the system of record until long after it mattered for day-to-day visibility.
The productivity paradox
Here's a pattern we kept seeing. A developer would pick up a task, spend two hours in Cursor with Copilot or Claude, push a PR, and move on. Fast. Productive. Exactly what you'd want.
Except none of that work showed up on the sprint board until the PR landed. No stage transitions, no progress updates, no breadcrumbs. The sprint review would arrive and half the completed work was untracked. Managers asked for status. Developers context-switched to update tickets. The 2x coding speedup quietly eroded into overhead.
The core tension: AI made coding faster, but the gap between doing work and recording work got wider. Every hour saved writing code was partially lost to manual bookkeeping after the fact.
Why GitHub hooks weren't enough
Our first instinct was the obvious one – GitHub webhooks. On PR creation, automatically update the linked DevRev issue. Transition the stage. Post a comment.
It worked, technically. But it solved the wrong problem.
GitHub hooks capture completion, not intent. By the time a PR exists, the developer has already context-switched away from the planning mindset. The issue title is stale. The description is an afterthought. The categorization – is this new development, a bug fix, or tech debt? – never happens at all. As we said in that session, hooks can feel too little, too late: the PR collapses days of work into a single moment, so you lose the temporal view you need for questions like what moved on Tuesday versus Thursday, or who needs help before the week ends.
To be fair, MCP updates also happen after the fact – after writing code, after creating a PR. The difference isn't that MCP is synchronous with thought. It's that MCP updates happen at finer granularity, triggered naturally within the developer's existing conversation rather than at a single end-of-cycle hook. The developer is still in context. The mental model is still warm.
We also found a subtler issue. Developers who knew the webhook would eventually update their issue felt even less motivation to keep it current during development. The automation became an excuse to defer, and "deferred" often meant "forgotten."
The hooks were too little, too late.
Meeting developers where they already are
Developers rightly avoid context switches. This isn't a character flaw – it's a rational response to the cost of interruption. Any work-tracking solution that requires opening a browser tab has already lost.
Model Context Protocol gave us a different entry point. MCP lets an AI assistant call external tools mid-conversation, which means the developer's existing Cursor session becomes the interface for everything – not just code, but project management too.
We configured two MCP servers in Cursor: one for DevRev (work tracking, sprint management, categorization) and one for GitHub (repository operations, PR creation). The developer never leaves the IDE. The AI assistant becomes the glue layer between thinking and tracking.
The same DevRev MCP server can plug into other clients too – for example Raycast and Warp – so work context stays on the surface you already use, not only in the IDE.
The key insight was positional. We weren't building a better integration. We were moving the integration earlier in the workflow – from the moment of completion to the moment of thought.
Zero-friction issue creation
The simplest interaction looks like this: a developer creates a new branch, types "create issue" in Cursor's chat, and has not committed code yet – the moment they want intent on the record before implementation.
Behind the scenes, the MCP server does several things without being asked. It detects the developer's identity from their local Git configuration and maps it to their DevRev user account. It infers the part – DevRev's concept of a business area or product component – from the repository and directory context. With no diff yet, the first title may be as thin as the branch name; that is enough to create a real issue and refine it on the next update. Correct part attribution can trigger downstream automation – in our setup, that included assigning the active sprint and an initial stage as soon as the record landed, without opening the web UI.
The developer gets back a formatted issue with a link. One sentence in, one tracked work item out.
What matters here isn't the automation itself – it's the timing. The issue exists before a single line of code is written. The developer's intent is captured at the moment they articulate it, while the context is fresh and the mental model is complete.
No browser tab. No form fields. No dropdown menus for priority, part, or sprint. The defaults are inferred, and they're right often enough that overriding them is the exception.
Code-aware updates
Creation was the easy part. The harder problem was ongoing updates – keeping the issue accurate as work progresses.
When a developer types "update issue" after writing code, the MCP server reads the current context: which files changed, what the recent Git diff looks like, what the developer said in the chat. From that, it does three things.
First, it transitions the issue stage. If you just started coding, the issue moves to "In Development." If you're writing tests, it stays in "In Development" – tests are part of building, not reviewing. The issue only moves to "In Review" when the developer creates a PR and it's ready for a teammate to look at. These are heuristic defaults – rule-based anchors that the AI can override based on conversational context. If a developer says "I'm done but waiting on feedback before merging," the AI can move to "In Review" even without a formal PR. The principle is consistent: "In Review" means another human needs to act, not that the developer is still iterating.
Second, it generates or refines the issue title. Early in development, issue titles tend to be vague ("fix the thing"). After the code exists, the MCP server can propose a precise title derived from what was actually built. The developer approves or edits with a single message.
Third, it posts a timeline update on the DevRev issue – a breadcrumb that says what happened and when. Over a multi-day task, these accumulate into a narrative that didn't require any deliberate documentation effort.
The result is an issue that stays current without the developer ever visiting it directly. The tracking system becomes a side effect of the development conversation, not a separate chore.
Automatic categorization
One of the quieter wins was classification. Every piece of work falls into a category: new development, bug fix, technical debt, or something else. Teams need this data for planning and retrospectives. Developers almost never provide it voluntarily.
We built a categorization agent that runs when an issue is created or updated through MCP. It examines the issue description, the code context, and the conversation history, then assigns a category with a written justification – or holds off when context is too thin, then classifies once commits and description make the work legible.
The justification turned out to be important. A bare label – "tech debt" – invites argument. A label with reasoning – "tech debt: refactors the authentication middleware to remove deprecated dependencies, no user-facing behavior change" – invites agreement. Teams trusted the classification because they could read the rationale and verify it in seconds.
The agent also catches miscategorizations early. A developer might think they're doing new feature work, but if the code change is entirely within existing modules with no new endpoints or UI, the agent flags it as a refactor. This isn't about overriding the developer – it's about giving the team accurate data for capacity planning.
PRs without leaving the IDE
The last piece was closing the loop. A developer finishes coding, updates their issue through MCP, and then says "create PR."
The GitHub MCP server handles the rest: branch naming from the issue ID, commit message formatting, PR description generated from the issue and code context, and the link back to the DevRev issue embedded in the PR body. In the live walkthrough, the client also filled the team's checked-in PR template section by section instead of replacing it with a blob of text.
This is where the two MCP servers – DevRev and GitHub – work in concert. The DevRev server provides the work-tracking context (issue ID, title, description, part). The GitHub server provides the repository operations. The AI assistant in Cursor orchestrates between them in a single conversation turn.
The developer's full workflow – from "I need to fix this" to "PR is up for review" – happens in one tool. The sprint board, the issue tracker, and the repository all stay synchronized as a natural consequence of the conversation.
What changed
We didn't set out to build a project management tool. We set out to solve a data quality problem: sprint boards that didn't reflect reality.
The fix was architectural, not motivational. Developers weren't failing to track work because they were careless. They were failing because every existing touchpoint for tracking was in the wrong place at the wrong time. Moving that touchpoint into the IDE – into the exact moment when a developer is already describing what they want to build – eliminated the friction that caused the data gap.
In practice, issues created through MCP had richer descriptions, more accurate categorizations, and more frequent stage updates than issues created through the web UI. Not because we nagged developers into compliance, but because the system met them where they were already working.
There are limits. Complex multi-part epics still benefit from deliberate planning sessions. Not every workflow fits a chat-based interaction. But for the daily rhythm of picking up tasks, writing code, and shipping PRs, capturing intent at the moment of thought turned out to be the difference between a sprint board that misleads and one that reflects reality.
The next post in this series covers the technical implementation: how we structured the MCP server, handled authentication across tools, and managed the state synchronization between DevRev and GitHub.
Get started
If you want to try this workflow, visit https://developer.devrev.ai/mcp to connect your IDE and start tracking work from Cursor.
---
MCP for Product Managers: Ahmed Bashir and Shashank discuss PM-facing workflows
MCP for Product Managers: Ahmed Bashir and Shashank discuss PM-facing workflows
Explore Raycast and Warp: A session on extending MCP beyond the IDE
