I don't think most teams are slowed down by lack of effort.
I think they're slowed down because the context for the work is scattered.
The task is in Jira.
The decision is in a doc.
The code is on a branch.
The AI prompt that explains the reasoning is in chat history somewhere.
Everything exists.
But not in one place where the next person can actually use it.
So every handoff starts with reconstruction.
What were we trying to do?
Why did we make that tradeoff?
Which branch has the latest version?
Where did that decision happen?
I've been noticing this more and more as I work with AI.
At first I thought AI would reduce the need for documentation and coordination. Instead it made the problem easier to see.
If the context is stale, incomplete, or spread across five tools, the output drifts.
That is true for AI.
And it's true for teams.
That's the shared context problem.
The Problem Isn't Just Missing Information
Most teams don't actually have a shortage of information.
They have a shortage of shared, current, easy-to-find information.
That's a different problem.
I've seen this over and over:
- the story is technically written down, but the real reasoning lives in comments
- the latest implementation details are only visible on a feature branch
- the best explanation of the problem lives in an AI prompt that nobody else can see
- a key decision was made in chat and never made it back into the work itself
So when someone else picks up the task, they have to reconstruct the thought process before they can move forward.
That reconstruction work is expensive. It slows down handoffs, reviews, onboarding, and AI-assisted development.
The Workarounds I've Seen
Most teams know this is a problem, so they try to patch around it.
Keep the context in the repo
This is usually the first instinct, and honestly, I think it's directionally right.
Keeping context near the code is better than keeping it in a detached system no developer wants to live in all day.
But if the context lives in the main repo, another problem shows up fast:
Which branch has the latest version?
If the plan changed on a feature branch, the rest of the team has to know that branch exists. If multiple branches each have part of the story, then the source of truth depends on knowing where to look.
That works for one developer who remembers everything.
It breaks down for a team.
Keep the context in another repo
I've seen teams try this too.
The idea is clean: separate the context from the product repo so it doesn't interfere with the codebase.
But now every meaningful context update becomes its own coordination problem.
You need context PRs.
You need someone to review them.
You need to wait for them to merge.
So instead of making context easier to maintain, you create a second workflow around maintaining the workflow.
That overhead adds up quickly.
Leave it spread across tools
This is where most teams end up by default.
A little in Jira.
A little in GitHub.
A little in Notion.
A little in Slack.
A little in AI prompts.
People can usually find enough to keep moving, but not without friction.
And friction compounds.
What AI Made Obvious to Me
Working with AI made this problem impossible for me to ignore.
When an AI assistant gets a bad prompt, incomplete files, or missing constraints, the result is usually disappointing. Not because the model is useless, but because the context is weak.
That reminded me of how humans work too.
We expect teammates to make good decisions with partial tickets, outdated notes, and disconnected artifacts. Then we're surprised when they miss the intent.
AI didn't create the shared context problem.
It just exposed it more clearly.
What I Actually Want
I want the context for the work to be:
- close to the code
- visible to the team
- easy to update while working
- available to AI
- tied to the task, not floating in some disconnected place
In other words, I want the "why," the "what," and the supporting artifacts to travel with the work itself.
That's the idea behind what I've been building with imdone.
How imdone Helps
imdone turns Jira and GitHub issues into a shared context repository next to the code.
That means the issue, comments, attachments, plans, and working notes can live in a local structure that developers can open in their editor and work with directly.
For me, that's a much better model than treating Jira like a separate universe you visit in the browser.
It keeps context close at hand.
It makes it easier to update while the work is happening.
And it gives AI access to the same local context the team is using.
I've also been pairing that with hypothesis-driven workflows, where each story captures:
- the outcome we're trying to create
- the hypothesis behind it
- the success metrics
- the design and plan
- the demo path
That structure helps both humans and AI stay grounded in the same goal.
To me, that's the real opportunity here.
Not just better issue management.
Better alignment.
Why This Matters
I don't think most teams are blocked because they lack tools.
I think they're blocked because too much of the reasoning around the work is fragmented.
When the context is shared and current:
- handoffs are easier
- reviews are faster
- AI is more useful
- product decisions stay connected to implementation
- the team spends less time reconstructing and more time building
That's a meaningful shift.
A Simple Test
If your team has ever asked:
- "Which branch has the latest plan?"
- "Where did we decide that?"
- "Can you send me the prompt you used?"
- "Why did we do it this way?"
...then you're already feeling the shared context problem.
The question isn't whether the context exists.
The question is whether the whole team, and your AI tools, can see the same current version of it without hunting for it.
If not, it's probably time to change the workflow.
If you want to see how I'm approaching this, take a look at imdone.io.
Top comments (0)