Jorge Silva’s Post

I recently asked a coworker for advice on using GitHub Copilot more strategically. Their answer clarified a distinction that can be confusing early on: the difference between Copilot’s coding agent capabilities and Agent Mode. Copilot Coding Agent refers to an autonomous, task-oriented way Copilot can do coding work for you, like implementing a change, refactoring code, or updating tests based on a request. In practice, you do not always “pick Coding Agent” as a separate option in the UI. Instead, the experience is typically presented as Copilot taking on an assigned task and working through it, often using repository context and producing a concrete set of changes for you to review. A key point is that this style of Copilot interaction is scoped and goal-driven. You give it a defined objective, and it focuses on completing that objective with minimal extra orchestration. Agent Mode is the broader workflow behavior. When Agent Mode is enabled, Copilot is set up to operate more like an orchestrator: it can plan multi-step work, keep track of progress across steps, and coordinate tools or “skills” to complete a larger workflow. Rather than just making one change, it is oriented around executing a sequence, like: inspect code, propose an approach, modify files, update tests, validate assumptions, and iterate. So the practical takeaway my colleague emphasized was: - Use coding agent style tasks when you want a scoped change completed quickly and you want to review a focused set of edits. - Use Agent Mode when you want Copilot to manage a multi-step workflow that would otherwise require you to repeatedly prompt, context switch, and coordinate the sequence manually. For anyone using GitHub Copilot, what’s your rule of thumb for when you keep things scoped versus when you lean on Agent Mode for multi-step workflows? https://msft.it/6047QRkOF #GitHubCopilot #AgentMode #DeveloperWorkflow #Automation #Productivity (Interesting note: Agent Mode is less about “a different helper” and more about Copilot taking responsibility for planning and coordinating steps. Even then, you still stay in control by reviewing changes and deciding what gets merged.)

One of GitHub Copilot’s best features is access to the best closed models across major providers. That flexibility means you’re not limited to a single generalist. You can choose the right model for the job and, if you’re deliberate, build a fleet of specialised agents. One of GitHub’s worst features is its UI. As I pushed Copilot CLI harder, I became increasingly frustrated by the lack of visibility and control. I couldn’t see how tasks were being decomposed, how delegation was happening between agents, which model was handling which responsibility, or what the system was actually doing on my behalf. I’ve always believed the best way to learn is to build. So instead of complaining, I built my own terminal UI on top of Copilot. Under the hood, it uses @github/copilot-sdk to talk to Copilot CLI. I didn’t replace the plumbing. I wrapped it. Agents are registered as SDK custom agents, and delegation flows through the SDK’s task tooling. What I changed is the interface and the orchestration around it. My TUI exposes the execution plan, active agents, subagents, escalation paths, model selection per role, files modified, and real-time progress. On top of that, I structured a set of agents to operate like a small engineering team: Intake clarifies requirements, a Tech Lead decomposes and coordinates, architects and investigators design, engineers implement, specialists contribute domain depth, and a Reviewer acts as a quality gate. All orchestrated within a single request. It feels less like pair programming and more like leading a team. It didn't take long to get something functional with Copilot CLI before I was able to start dogfooding it from the TUI itself. It's still a little rough around the edges, but my engineering team can fix that. I’m not releasing this. It’s a hobby project. If you want one, you’ll have to build your own. That’s intentional. If you’re trying to understand how agentic coding works and how it changes the role of senior engineers, don’t just consume content about it. Design the roles. Choose the models. Define delegation and escalation paths. Debug coordination failures. You’ll learn more by building your own system than by watching anyone explain it.

Most enterprises adopt GitHub Copilot the same way.! 𝗟𝗲𝗮𝗱𝗲𝗿𝘀𝗵𝗶𝗽 𝗮𝗽𝗽𝗿𝗼𝘃𝗲𝘀 𝗶𝘁. 𝗜𝗧 𝗱𝗲𝗽𝗹𝗼𝘆𝘀 𝗶𝘁. 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝗹𝗼𝘃𝗲 𝗶𝘁. 𝗗𝗼𝗻𝗲. What nobody does — and I mean almost nobody — is look at token usage before the first big invoice. 𝗪𝗲 𝘄𝗲𝗿𝗲 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲.! Once Co-pilot was available as an extension to popular IDE's like Visual Studio Code and the various JetBrains IDEs (including IntelliJ IDEA, PyCharm) usage was sky-rocketed. The tool is genuinely brilliant and helping developers in most cases. But this burst of lavish usage turns out to have a hidden cost — 𝘁𝗵𝗲 𝘄𝗮𝘆 𝗺𝗼𝘀𝘁 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝗻𝗮𝘁𝘂𝗿𝗮𝗹𝗹𝘆 𝘂𝘀𝗲 𝗖𝗼𝗽𝗶𝗹𝗼𝘁 𝗶𝘀 𝗮𝗹𝘀𝗼 𝘁𝗵𝗲 𝗺𝗼𝘀𝘁 𝗲𝘅𝗽𝗲𝗻𝘀𝗶𝘃𝗲 𝘄𝗮𝘆 𝘁𝗼 𝘂𝘀𝗲 𝗶𝘁. Here's what was silently burning tokens for most of us: ❌ 10+ tabs open at all times in VS Code — Copilot reads all of them as context, whether you're using them or not ❌ Broad Copilot Chat prompts like "review this codebase" instead of "refactor this one function" ❌ Long chat threads on github.com that re-send the full conversation history with every single message ❌ Massive 600-line files that flood the context window before Copilot even gets to the useful part Nobody was doing anything wrong. We just didn't know these things mattered. What we actually changed — and it wasn't complicated: ✅ Close tabs not relevant to your current task. Sounds obvious. Almost nobody does it. ✅ Start fresh chat threads when switching topics. Don't carry a 40-message auth thread into your dev work. ✅ Write specific prompts and comments. "Validate email format, return boolean" beats "handle the email thing" — for output quality and cost. ✅ Scope your Copilot Chat with #file: or highlight a selection first. Give it less to think about, not more. ✅ Break large files into smaller modules. Good engineering practice that also happens to be significantly cheaper. If you're rolling out Copilot at scale right now — build these habits early. The tool ROI is real, but so is the cost of undisciplined usage across a large team. 𝗦𝗺𝗮𝗹𝗹 𝗵𝗮𝗯𝗶𝘁𝘀. 𝗖𝗼𝗺𝗽𝗼𝘂𝗻𝗱𝗶𝗻𝗴 𝗶𝗺𝗽𝗮𝗰𝘁. What's your experience been with Copilot usage at scale? Would love to hear what others have found. 👇 #GitHubCopilot #EnterpriseAI #DeveloperProductivity #SoftwareEngineering #AITools

Your PR review just got a co-pilot with a choice of engines. GitHub Copilot now lets you pick your AI model directly inside a Pull Request comment — just mention @copilot, and a model picker appears right in the comment box. This means your team can now choose the right model for the right task, right where the work happens. This is model-agnostic agentic code review becoming a reality inside your existing Git workflow. Think about what this actually enables: → Use a reasoning-heavy model for complex architectural PRs → Use a faster, leaner model for routine bug fixes or formatting changes For enterprise engineering leaders, this is a meaningful signal: the PR is becoming an agentic interface, not just a review artifact. AI is no longer a "plugin"—it's a core component of the SDLC. Architect accordingly. #GitHub #Copilot #AIEngineering #PullRequest #AgenticAI #EnterpriseArchitecture #DevOps #SoftwareEngineering #AIGovernance #SolutionArchitect

My team-mate has been digging into GitHub Copilot CLI’s new ACP server support, and explains it is a genuinely interesting step toward making coding agents easier to integrate anywhere. ACP stands for Agent Client Protocol, a standard way for a client (an editor, IDE, terminal UI, or even a pipeline runner) to talk to a coding agent (like Copilot CLI). Instead of every tool inventing its own bespoke integration, ACP provides a shared contract for how requests, responses, and agent actions flow. A quick note: ACP support in GitHub Copilot CLI is currently in public preview, so details may evolve. Why this matters: IDE integrations: Bring Copilot style agent workflows into editors or internal dev environments that do not have first class Copilot plugins. CI/CD pipelines: Orchestrate agentic coding tasks in automated workflows, like generating patches, refactoring, or assisting with test updates as part of builds. Custom frontends: Build purpose specific interfaces for your team’s workflow, like a lightweight internal “coding assistant console.” Multi-agent systems: Coordinate Copilot alongside other AI agents with a standard protocol, rather than stitching together fragile adapters. The bigger takeaway for me is that standard protocols are what turn “cool demos” into ecosystems. If you have ever built a custom IDE integration or tried to automate code changes in a pipeline, you know how much time disappears into glue code. ACP aims to reduce that friction. If you are experimenting with agentic workflows, ACP server support in Copilot CLI is worth a look, especially if you want Copilot assistance outside the usual editor plugin path. #GitHubCopilot #DeveloperTools #AIEngineering #DevEx #Automation #CICD #IDEs

My team-mate has been digging into GitHub Copilot CLI’s new ACP server support, and explains it is a genuinely interesting step toward making coding agents easier to integrate anywhere. ACP stands for Agent Client Protocol, a standard way for a client (an editor, IDE, terminal UI, or even a pipeline runner) to talk to a coding agent (like Copilot CLI). Instead of every tool inventing its own bespoke integration, ACP provides a shared contract for how requests, responses, and agent actions flow. A quick note: ACP support in GitHub Copilot CLI is currently in public preview, so details may evolve. Why this matters: IDE integrations: Bring Copilot style agent workflows into editors or internal dev environments that do not have first class Copilot plugins. CI/CD pipelines: Orchestrate agentic coding tasks in automated workflows, like generating patches, refactoring, or assisting with test updates as part of builds. Custom frontends: Build purpose specific interfaces for your team’s workflow, like a lightweight internal “coding assistant console.” Multi-agent systems: Coordinate Copilot alongside other AI agents with a standard protocol, rather than stitching together fragile adapters. The bigger takeaway for me is that standard protocols are what turn “cool demos” into ecosystems. If you have ever built a custom IDE integration or tried to automate code changes in a pipeline, you know how much time disappears into glue code. ACP aims to reduce that friction. If you are experimenting with agentic workflows, ACP server support in Copilot CLI is worth a look, especially if you want Copilot assistance outside the usual editor plugin path. #GitHubCopilot #DeveloperTools #AIEngineering #DevEx #Automation #CICD #IDEs

My team-mate has been digging into GitHub Copilot CLI’s new ACP server support, and explains it is a genuinely interesting step toward making coding agents easier to integrate anywhere. ACP stands for Agent Client Protocol, a standard way for a client (an editor, IDE, terminal UI, or even a pipeline runner) to talk to a coding agent (like Copilot CLI). Instead of every tool inventing its own bespoke integration, ACP provides a shared contract for how requests, responses, and agent actions flow. A quick note: ACP support in GitHub Copilot CLI is currently in public preview, so details may evolve. Why this matters: IDE integrations: Bring Copilot style agent workflows into editors or internal dev environments that do not have first class Copilot plugins. CI/CD pipelines: Orchestrate agentic coding tasks in automated workflows, like generating patches, refactoring, or assisting with test updates as part of builds. Custom frontends: Build purpose specific interfaces for your team’s workflow, like a lightweight internal “coding assistant console.” Multi-agent systems: Coordinate Copilot alongside other AI agents with a standard protocol, rather than stitching together fragile adapters. The bigger takeaway for me is that standard protocols are what turn “cool demos” into ecosystems. If you have ever built a custom IDE integration or tried to automate code changes in a pipeline, you know how much time disappears into glue code. ACP aims to reduce that friction. If you are experimenting with agentic workflows, ACP server support in Copilot CLI is worth a look, especially if you want Copilot assistance outside the usual editor plugin path. #GitHubCopilot #DeveloperTools #AIEngineering #DevEx #Automation #CICD #IDEs

My team-mate has been digging into GitHub Copilot CLI’s new ACP server support, and explains it is a genuinely interesting step toward making coding agents easier to integrate anywhere. ACP stands for Agent Client Protocol, a standard way for a client (an editor, IDE, terminal UI, or even a pipeline runner) to talk to a coding agent (like Copilot CLI). Instead of every tool inventing its own bespoke integration, ACP provides a shared contract for how requests, responses, and agent actions flow. A quick note: ACP support in GitHub Copilot CLI is currently in public preview, so details may evolve. https://msft.it/6049QdMMU Why this matters: IDE integrations: Bring Copilot style agent workflows into editors or internal dev environments that do not have first class Copilot plugins. CI/CD pipelines: Orchestrate agentic coding tasks in automated workflows, like generating patches, refactoring, or assisting with test updates as part of builds. Custom frontends: Build purpose specific interfaces for your team’s workflow, like a lightweight internal “coding assistant console.” Multi-agent systems: Coordinate Copilot alongside other AI agents with a standard protocol, rather than stitching together fragile adapters. The bigger takeaway for me is that standard protocols are what turn “cool demos” into ecosystems. If you have ever built a custom IDE integration or tried to automate code changes in a pipeline, you know how much time disappears into glue code. ACP aims to reduce that friction. If you are experimenting with agentic workflows, ACP server support in Copilot CLI is worth a look, especially if you want Copilot assistance outside the usual editor plugin path. #GitHubCopilot #DeveloperTools #AIEngineering #DevEx #Automation #CICD #IDEs

My team-mate has been digging into GitHub Copilot CLI’s new ACP server support, and explains it is a genuinely interesting step toward making coding agents easier to integrate anywhere. ACP stands for Agent Client Protocol, a standard way for a client (an editor, IDE, terminal UI, or even a pipeline runner) to talk to a coding agent (like Copilot CLI). Instead of every tool inventing its own bespoke integration, ACP provides a shared contract for how requests, responses, and agent actions flow. A quick note: ACP support in GitHub Copilot CLI is currently in public preview, so details may evolve. https://msft.it/6046QwNnp Why this matters: IDE integrations: Bring Copilot style agent workflows into editors or internal dev environments that do not have first class Copilot plugins. CI/CD pipelines: Orchestrate agentic coding tasks in automated workflows, like generating patches, refactoring, or assisting with test updates as part of builds. Custom frontends: Build purpose specific interfaces for your team’s workflow, like a lightweight internal “coding assistant console.” Multi-agent systems: Coordinate Copilot alongside other AI agents with a standard protocol, rather than stitching together fragile adapters. The bigger takeaway for me is that standard protocols are what turn “cool demos” into ecosystems. If you have ever built a custom IDE integration or tried to automate code changes in a pipeline, you know how much time disappears into glue code. ACP aims to reduce that friction. If you are experimenting with agentic workflows, ACP server support in Copilot CLI is worth a look, especially if you want Copilot assistance outside the usual editor plugin path. #GitHubCopilot #DeveloperTools #AIEngineering #DevEx #Automation #CICD #IDEs

GitHub Copilot Introduces Contextual Engineering Intelligence to Measure Developer Impact 📌 GitHub Copilot is revolutionizing how developers measure impact - not just effort, but business value. With Harness SEI 2.0’s AI-powered insights, teams now connect code quality, deployment speed, and team health to real outcomes. It’s engineering intelligence that turns metrics into strategy - because true productivity creates results, not just commits. 🔗 Read more: https://lnkd.in/dft7vC4Q #Githubcopilot #Developerimpact #Contextualai #Harnessio