Most engineering teams are running two parallel systems that never quite talk to each other: a ticket tracker full of stale requirements, and a documentation tool full of out-of-date wikis. You spend half your planning time bridging the gap between them — and the code itself? It just sits there, quietly diverging from everything you wrote down.
We built Intent to collapse all of that into one place. Here's exactly how it replaces both your project management tool and your documentation system — and why the combination matters.
The Problem With Tickets
Jira tickets are written from memory. Someone opens a blank text box and describes what they think the system does today, what they think needs to change, and how long they think it will take. Three estimates, all guesses.
The result is work that starts with the wrong assumptions, blocker dependencies that nobody noticed until someone is blocked, and story point estimates that are essentially fiction negotiated in a planning poker session.
Changesets: Work Items That Know Your Code
The core unit of work in Intent is a changeset — not a ticket. The difference is fundamental: before a changeset is written, Intent's AI reads your actual indexed repositories and generates a structured spec grounded in the real current state of the code.
Depending on the type of work, the spec follows a specific format automatically:
- Feature → Summary, Acceptance Criteria, Testing Notes
- Bug → Summary, Steps to Reproduce, Expected vs. Actual Behaviour, Impact
- Refactor → Summary, Motivation, Approach, Testing Notes (including ADRs)
Every changeset also gets an AI-estimated effort on the Fibonacci scale (1, 2, 3, 5, 8, 13 points) — evaluated holistically against the full scope of the change, not summed up from individual spec fragments. Intent itself went through this design decision: effort estimation was explicitly moved from the spec level to the changeset level, because breaking a feature into multiple small specs was otherwise inflating estimates artificially.
Specs That Live in Your Repo
In most setups, documentation is a separate artifact from code — it lives in Confluence or Notion, quickly becomes stale, and isn't linked to any particular branch or pull request.
Intent takes a different approach. When a developer clicks Start Work, Intent automatically:
- Creates a feature branch in every linked repository (named
intent/<id>-<changeset-name>) - Commits all spec files directly to that branch under
.intent/specs/and.intent/rules/(for ADRs) - Opens a draft pull request with the spec documents linked in the PR description
From that moment, the spec lives alongside the code. Reviewers can read it on the branch. The PR description links back to Intent. And if the spec is updated mid-implementation — in the Intent UI — a background sync job automatically re-commits the updated files to the open branch within minutes. No manual copy-paste, no out-of-sync documentation.
The Pre-flight Check: Catching Conflicts Before They Happen
One of the most painful parts of working with a classic ticket tracker is discovering mid-sprint that two changesets touch the same code, or that a dependency shipped in the wrong order.
Intent runs an AI pre-flight readiness check before any branch is created. It:
- Detects conflicts with other in-progress changesets based on spec overlap
- Identifies suggested blockers across the entire project
- Flags unchecked prerequisite todos
This check streams live in the dialog — showing which tools the AI is calling in real time (e.g. "Searching changesets · SSO login") before summarising with a clear "Ready to start" or "Concerns found" result. The Start Work button stays disabled until the result arrives, so no work begins on a shaky foundation.
Delivery Forecasts Without Spreadsheets
Instead of asking teams to manually roll up estimates into a roadmap spreadsheet, Intent calculates delivery forecasts from each team's real historical throughput — points completed per day. Backlog items are chained sequentially per team, so leadership gets accurate projected completion dates that update automatically as work lands.
No quarterly planning theatre. No stale roadmap slide deck.
Progress Updates Itself
Once a changeset is in progress, Intent polls the connected git provider. When all pull requests are merged, the changeset automatically transitions to Completed and its specs are locked.
No standup update. No Jira status drag. No "can someone update the ticket?" Slack message.
One Live View for Everyone
The practical outcome is that product, engineering, and leadership share a single view of what the software actually does today — not what someone wrote down six months ago. Specs stay tied to real code. Decisions are captured inline in the changeset as comments, not lost in a Slack thread. Progress reflects merged PRs, not self-reported status.
That's the gap Intent closes: between what you planned, what you built, and what anyone can understand about the system right now.