How much time do you spend repeating context in Claude?
by•
Curious if this is just me or other devs face it too. I use Jira and GitHub MCPs inside claude code to fetch my tickets and complete them as autonomously as possible.
But it always keeps messing up finding the correct repos, branching properly or delivering a PR without CI failing. And I end up repeating instructions and copy-pasting CI errors and asking to fix it. I tracked this and I spent on avg 75mins a day repeating context and instructions.
Anyone also facing this or found a way around it?
41 views
Replies
Honestly, 75 minutes a day is pianful. I've had the same issue where I spend more time explaining the task again than actually working on it.
I've had to paste thr same error more than once too. I really wish the agent could keep that context and learn from the previous failure.
things like the right repo, branch rules , test command and CI steps are worth writing down once instead od explaining them in every chat.
75 minutes a day is a real number and it is worth splitting, because the two halves have different fixes and only one of them is yours.
Half of what you are repeating is derivable from the repo — which repo, how branches are named, what a PR has to look like. An agent gets those wrong when nothing in the tree states the convention, and stating it once in a file the agent reads every session ends it.
The other half is not in any code, and that is where your CI failures live. A concrete one from ours: the pipeline starts by copying the production env template, which turns debug on, while everyone developing has it off. Under debug the framework serves its own error page, so a test comparing a 404 body passed on every machine and failed only on the runner, with a diff that named the assertion and not the cause. Nothing in the repository says those two environments disagree. You can paste that error in and get it fixed, and you will paste it again next month, because the fix was in the code and the cause was in the environment. Nine of our test classes now pin that value themselves rather than reading it.
The one I would look for first in your setup is a tool that behaves differently when there is no terminal. Our schema migration generator is not generate-only — it runs every outstanding migration before it diffs anything, and it asks first, with the default answer being yes. Anywhere there is nobody to answer, which includes an agent, the answer is taken. The only trace is one line inside its own output. That is not a bug in our code, and no amount of context about our code would prevent it.
So the file is not a description of what the code does — the agent can read the code faster than you can write about it. Ours is about 1700 lines and almost none of it is structure. It is why, and where the traps are, and each entry got in because something had to be explained twice.
I do not have a before-and-after minute count to put against your 75. The test I use instead is whether the same correction comes back a third time. What this will not fix is the agent picking the wrong repo or fumbling a branch — that is a tool problem, and prose will not help it. It fixes the other class, where the agent does exactly what the code implies and the code is not where the truth is.
I've started thinking of persistent project context as almost as important as the code itself. if the agent already knows the basic rules I don't have to keep stopping and explaining the same things.
I have experienced the same agents making small workflow mistakes. I started documenting commands, repo structure and deployment rules before asking the agent to work.
Do you create a project and define the context and project instruction? Because that's something I do and I have not encountered what you're describing.