Feature Request: Make GitHub Copilot Coding Agent as Reliable, Autonomous, and Effective as Its Full Model Potential Allows

[GopiB9119]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Copilot in GitHub

Body

1. Summary

I would like GitHub to improve the overall reliability, autonomy, speed, and task-completion ability of GitHub Copilot coding agent.

Powerful AI models are becoming increasingly capable at software development. However, the practical results users receive can differ significantly between coding-agent products. Even when a product offers access to a highly capable model, the surrounding agent workflow can prevent that model from delivering its full potential.

GitHub Copilot coding agent should reliably understand a task, plan the work, modify the correct files, execute tools efficiently, recover from errors, preserve context, run appropriate checks, and complete the requested task with minimal unnecessary human intervention.

The goal is not simply to provide access to a more powerful model. The goal is to make the entire coding-agent experience powerful, dependable, and consistent.

2. Problems users experience

A. Repetitive tool calls and unproductive loops

The agent sometimes searches the same files repeatedly, runs similar commands, revisits previously explored approaches, or continues a sequence of actions without meaningful progress. It should recognize when an action has already been attempted and determine whether repeating it is justified. If an approach is not working, the agent should change strategy instead of continuing indefinitely.

B. Slow execution, even for simple tasks

Some straightforward changes can take unnecessarily long because of excessive planning, repeated exploration, redundant tool calls, or unnecessary review cycles. The agent should adapt its effort to the complexity of the task. A small code change should not require the same execution process as a large architectural change.

C. Incomplete task execution

The agent may modify some files but leave other explicit requirements unfinished. It can focus on one part of a task while overlooking related changes, edge cases, documentation, or tests. It should maintain a checklist of requirements and reconcile that checklist against the actual repository changes before declaring the task complete.

D. Weak debugging and self-correction

When the agent introduces an error, encounters a failed command, or breaks a test, it should use the available evidence to identify the root cause and attempt a targeted correction. It should not repeatedly apply superficial fixes, ignore error output, or continue as though the task succeeded when the problem remains unresolved.

E. Context loss during long tasks

As a session grows, important requirements, previous decisions, investigated approaches, and remaining work can be lost or inconsistently recalled. Context compaction should preserve the information needed to continue the task correctly. The agent should maintain durable task state instead of relying entirely on its latest conversational context.

F. Excessive dependence on human intervention

Users should not have to repeatedly remind the agent of the original request, explain what it already attempted, redirect it away from loops, or prompt it to finish work that was part of the original task. The agent should be able to carry out delegated coding tasks autonomously within the permissions, safeguards, and available tools provided by the product.

G. Insufficient verification and misleading completion signals

The agent should not equate generating code or editing files with successfully completing a task. Before claiming completion, it should review the requested requirements, inspect the changes, run relevant tests or checks when available, and clearly report anything that remains incomplete or unverified.

H. Inconsistent performance across coding-agent experiences

Users may experience different levels of speed, autonomy, context retention, and correctness across coding-agent products and environments. GitHub should evaluate and improve the full Copilot coding-agent workflow so that users receive consistent, dependable results across supported Copilot experiences.

3. The larger issue: Powerful models do not automatically create powerful coding agents

One of the most important concerns is the difference users can observe between products such as Codex, Claude Code, and GitHub Copilot.

A capable model can still produce a disappointing coding experience if the surrounding agent system does not use that capability effectively.

The overall result depends on more than the underlying model. It can also depend on:

• Agent planning and task decomposition.
• System instructions and execution policies.
• Tool selection and orchestration.
• Repository exploration and file-context management.
• Context retention and compaction.
• Error diagnosis and recovery.
• Test execution and result interpretation.
• Completion criteria and verification.
• Latency, repeated calls, and unnecessary workflow overhead.

These are potential contributing factors, not a claim that the products use identical model configurations or that one particular component is definitively responsible.

GitHub should evaluate the complete coding-agent system, rather than treating access to a powerful model as sufficient evidence of a powerful coding experience.

4. Proposed solution: A progress-aware task integrity controller

I propose introducing a task-integrity layer into GitHub Copilot coding agent.

This component would track task progress, preserve requirements, detect ineffective behavior, support recovery, and verify outcomes.

A. Durable task state

Maintain a structured, continuously updated record containing original requirements and constraints; decisions and assumptions; planned and completed steps; files inspected and modified; commands and checks executed; errors and recovery attempts; remaining requirements and blockers. This state should survive context compaction and session continuation.

B. Progress and loop detection

Detect repeated or equivalent tool calls, repeated searches, recurring failures, and sequences that produce no meaningful progress. When a stall is detected, assess what has already been learned, avoid unnecessary repetition, and select a more useful next action. Repeated calls should remain possible when justified by new evidence.

C. Adaptive planning and execution

Use a task-appropriate execution strategy. For simple tasks, minimize unnecessary exploration and workflow overhead. For complex tasks, use deeper planning, appropriate decomposition, and stronger validation. Reconsider the plan when new information contradicts assumptions or progress stalls.

D. Evidence-based debugging and recovery

Use actual command output, test failures, diagnostics, and repository state to identify problems. Determine what failed, identify the likely root cause, choose a targeted correction, rerun the relevant check, and preserve lessons learned. If recovery is impossible because of permissions, unavailable dependencies, or another genuine blocker, explain it clearly.

E. Requirement-to-result reconciliation

Maintain a traceable relationship between each user requirement and the resulting implementation or verification. Before finishing, check which requirements are complete, tested, unverified, or blocked.

F. Verification before completion

When appropriate and available, run relevant tests, builds, lint checks, type checks, and other validation. Inspect final changes for omissions and unintended modifications. Report the checks performed and actual results. Distinguish code that was written, code that was checked, and behavior that has genuinely been verified.

G. Reliable context compaction

Before compressing context, preserve the original objective, constraints, decisions, current state, failed approaches, remaining tasks, and next steps. After compaction or resumption, continue without unnecessarily repeating completed work or forgetting requirements.

H. Reduced unnecessary interruptions

Continue autonomously when there is sufficient information and permission. Request user input when a meaningful decision, missing information, security boundary, or genuine blocker requires it—not because the execution process lost track of the task.

5. Expected end-to-end workflow

1. Understand the complete request and constraints.
2. Explore the relevant repository efficiently.
3. Create an appropriate task plan.
4. Implement the required changes.
5. Track progress and detect stalls.
6. Diagnose and correct errors.
7. Run appropriate verification.
8. Compare the actual result against every requirement.
9. Report completed work, test results, remaining limitations, and blockers.

The process should be iterative and adaptive rather than rigid. The agent should return to earlier steps when evidence shows further work is necessary.

6. Acceptance criteria

• Repeated, unproductive tool-call loops are detected and interrupted.
• Simple tasks avoid unnecessary planning and execution overhead.
• Long tasks retain requirements and decisions across context compaction.
• The agent identifies unfinished requirements instead of silently overlooking them.
• Failed commands and tests lead to evidence-based diagnosis and attempted recovery.
• Completion claims reflect actual changes and verification performed.
• Final responses clearly identify incomplete, blocked, and unverified work.
• Unnecessary user interventions decrease without weakening security safeguards.
• Improvements are consistent across supported Copilot coding-agent experiences.

7. How GitHub should measure improvement

Evaluate representative real-world repository tasks using end-to-end task completion rate; correctness and quality; time to verified solution; redundant tool calls; recovery rate after failed commands or tests; requirement retention across long sessions; regressions; unnecessary user interventions; and verification accuracy. Where possible, compare versions under controlled conditions.

8. Why this matters

A coding agent is more than a model connected to a repository. Its planning, memory, tools, recovery behavior, and verification determine whether it can reliably deliver useful software changes.

Developers want to delegate a task and trust that the agent will work through it responsibly, recover from ordinary failures, and report the truth about the result.

The objective is not unlimited autonomy or eliminating human oversight. It is reducing avoidable failures and wasted effort while preserving user control, repository safety, and transparency.

9. Final request

Please consider prioritizing improvements to the underlying GitHub Copilot coding-agent architecture and workflow, including progress awareness, durable task state, adaptive execution, evidence-based recovery, and completion verification.

The full potential of capable AI models should translate into a dependable coding experience—not just impressive individual responses.

The goal: an agent that understands the task, makes meaningful progress, corrects its mistakes, finishes the requested work, verifies what it can, and clearly explains anything it could not complete.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[KasraK2K]

Strongly agree with the loop detection and verification-before-completion points especially, those are the two that actually cost me the most time in practice.

The repetitive tool call thing is real and it's not just annoying, it burns through the task budget before the agent gets to the part that actually matters. I've had sessions where it re-reads the same three files four or five times across a single task, each time as if starting fresh, then runs out of room to actually finish the edit. A simple "have I already looked at this exact file in this session" check would go a long way even without anything fancier.

The verification point (G in your list) is the one I'd push hardest on though. The failure mode I hit most isn't the agent getting stuck, it's the agent confidently saying a task is done when it only edited the file and never actually ran anything to confirm the change works. If there's a test suite or a build step available in the repo, completion should mean "I ran this and here's the result," not "I wrote code that should do this." Even a lightweight version, where the agent states explicitly whether it verified its own change or is just asserting it should work, would change how much I trust the "done" signal without requiring the full task-integrity architecture you're describing.

One thing I'd add to your list under context loss: when an agent resumes after compaction, it's often not just that it forgets what it already tried, it sometimes reopens an approach that was already explicitly rejected earlier in the conversation. That's worse than just losing progress, since it can quietly undo a decision the user already corrected it on. Durable state needs to track not just "completed steps" but "things the user told me not to do," and that list should survive compaction with higher priority than almost anything else, since silently re-doing a reverted mistake is more damaging than just being slow.

Well written proposal overall, hope it gets real traction instead of just the auto-reply.

[JGronholz]

The Great Wall Of Instructions (GWOI) that copilot prefers to assemble is partially responsible.

Keep in mind that Copilot is just a MCP.
Github created the Github MCP (engine-tools-reply_to_comment) so [models] can operate the Github API "natively."
Microsoft owns and maintains the Copilot MCP, not Github.
Microsoft owns and maintains the "Learn" MCP, not Github.
So, you're not wrong... but go tell Microsoft. 😊

Chat

You probably understand that "chat" is a stateless LLM (model) using a context window to pretend to be stateful.

"Chat with Copilot", code-review, and "coding agent" are all cloud-agent in different containers/scopes:

• cloud-agent is just a chatbot, taking turns
• The tools it uses take turns.

That makes it look intelligent/alive/capable but:

• It is not.

It tries every possible combination:

• Then filters out the wrong/invalid/disallowed ones
• Until only one remains

The one that remains is, at best, "probably right."

• It's 100% guess-and-check.

Currently, LLMs "brute force" their way through programming/everything, and appear semi-intelligent, some of the time.
Coding will be one of the first domains to replace LLMs with actual AI.
But we gotta get there, first.
By selling credits to fund the datacenters...

"Chat with Copilot" has psuedo-sudo scope:

• This path produces the best results, because you are in control of the context window.
  You determine when the context window is "right" for the task-prompt.
  Loaaaaaaaaaaad, parse, execute.

When you tell it "read this", it is compelled to summarize it for you (by default):

• You don't need the summary.
• You already know.
• The purpose of that instruction is just to hydrate a "new chat" with context.
• Read Issue X, PR Y, and session log Z, then tell me what 🔵 means.
• This requires human review. Do it for me.
  • Turn 1: What is "this"?
  • Turn 2: [this] is the answer to "What is 'this'?"
  • Turn 3: Is there anything wrong with [this]?
  • Turn 4: [this] has [issues].
  • Turn 5: Fix the [issues].

Anything involving an LLM is a "chatbot with tools," shuffling context around.

• Every repo is a complex "chat" (with sub-chats (and sub-sub-chats).
• Repo agents are just stateless chatbots taking turns

This dictates how you must instruct/prompt them.
As you've noticed, [model] is irrelevant.
The efficiency of the instruction payload is the most important.
If organized and loaded on-demand, a tiny context window can handle an enormous amount of instruction.

Which is what MCP and native skills are for!
Native skills are:

• "bricks" in the GWOI
• Discoverable
• Loaded JIT

Instead of searching through conditional prose (GWOI) to "find" instructions, native skills inject only relevant instructions directly into the context window.
This enables "inferior" models to perform as well as premium models, at a fraction of the cost.

Breadcrumbs

Each PR is a new chat:

• It's history is a context window.
• lost in the middle cannot be fixed away.

Turns:

• Within a session, cloud-agent takes turns.
• Each session is also a "turn" in the PR "chat."
• Each session begins with primal instructions.
• Require agents to leave a "breadcrumb" whenever they finish a session
• The next agent won't have to search, and will leave a new "latest breadcrumb" before it's session ends.
• This causes convergence and closure.

You have to instruct agents to communicate with each other across the turn boundary, or they won't.

Instead of trying to instruct away LLM mistakes (not possible)

You must create minimal governance, in case [github docs wrong, copilot api error, etc.].

• Request plan-first implementations
  Examine the Issue, PR, MCP/docs, workflows, logs, and existing regression tests, before beginning work.
  The context window is immediately filled to the brim.
  The agent reasons.
  The task is still primal.
  The bullet-proof plan becomes latest and carries recency bias.
  Everything else gets lost in the middle, but who cares.
  The plan is what matters.
  Once you use tokens to create the plan, the plan is all the agent needs to read.
  Keep the plan updated. continually refreshes the recency attached to [the plan].
• Request a closure matrix at the end of each turn.
  Every finding, thread, summary, response, and reply, becomes a new "latest breadcrumb" in the PR "chat."
  At the beginning of next turn, everything that went into the "latest comment" has become primal again.
  The previous turns get lost in the middle, but it doesn't matter.
• Request claim-to-evidence mapping when behavior doesn't match docs.
• Request regression tests for everything.

Remember that agents know nothing on turn 1 except their primal prompt:

• Include a closure matrix in your reply to the PR
• The request is vague (no specific comment or defect).
• The request is also specific - producing the "closure matrix" is a deterministic process.
• It involves finding "all unresolved defects".
• All of them, everywhere.
• Without having to define [everything], every time.

The agent learns to build one JIT to satisfy the primal prompt.

• But ONLY if you tell it to.

A closure matrix is not needed for every session, every time:

• So it will "never" get baked into the default Github/Copilot template.
• It's not technically their "concern," but remaining unconcerned about it DOES affect their product's reliability...
• What you/I/we want could be considered token waste to another.
• But you're not wrong, either....
• It's tricky.

Every domain has a manual to read

• RTFM first. - fixes mooooooooost problems.
• The ones that remain are problems with the manual.
• THAT is when claim-to-evidence mapping becomes important.

Native skill

Create a native skill (.github/skills) that applies to all tasks, containing a handful of these vaguely-specific coding instructions, and you'll see dramatic results immediately.
I agree that you "shouldn't have to"... but do it anyways. ❤️