I've been experimenting with GitHub Copilot agents, and my latest experiment took things further than I expected. I used Copilot agents to build a fully functional SharePoint quick links web part, one of the most common components you'll find on any intranet. What's fascinating about this experiment is that the Copilot agents did 100% of the development work. I was the orchestrator or basically the product manager with technical background.
I went from zero to an almost production-ready solution within 3–4 hours, and in this blog post, I'm sharing my experience and findings.
What is GitHub Copilot?
GitHub Copilot is an AI-powered coding assistant, or coding "genius", developed by Microsoft. It integrates directly into your development environment, such as Visual Studio Code, and helps developers write code faster by suggesting completions, generating functions, and even explaining existing code.
Beyond code suggestions, GitHub Copilot now supports Copilot agents (currently in preview). Copilot agents are autonomous AI agents that can create pull requests (PRs), run PR reviews, and work on GitHub issues independently. For example, you can assign an issue to a Copilot agent, and it creates a PR with the implementation. The agent can write code, create files, run tests, maintain the PR description, document its progress, and iterate on its own work. In a nutshell, think of it as having an AI developer on your team that you can assign issues to from your GitHub repository and that will deliver PRs for review.
How the experiment worked
In my test, I started with a simple prompt that kicked off the development of the quick links web part. Everything began from there. After some iterations, I had a very professional-looking and functional web part, ready to be used.
My role in this experiment was that of a product manager. I defined the user stories and assigned them to Copilot. I also requested code reviews from other Copilot agents to ensure the development work done by the initial Copilot agent was correct. Sometimes I asked clarification questions or adjusted the development direction by "discussing" changes with Copilot.
The only hands-on technical work I did was in Visual Studio Code: cloning the repository, building the solution, and generating the SPFx package that I could then install in the SharePoint app catalog. I'm lucky I have enough experience as a former developer, so these steps weren't difficult for me. However, I was expecting much more involvement in Visual Studio Code, and that wasn't required. The code I pulled from the GitHub repo was always functional.
First deployment and beyond
After I deployed the quick links web part for the first time in SharePoint, I was already impressed that it was actually functional. It then became fun, as I wanted to understand how far I could go. I kept adding new tasks for Copilot to work on and ended up making significant improvements:
- Improved the UI and the web part configuration settings, including proper validation for the URL field
- Added support for custom images
- Made the web part responsive
- Added support for WCAG 2.2 AAA accessibility standards, which is so important for inclusivity
- Added unit tests that Copilot kept maintaining with each new functionality it developed
- Added support for multilingual
At some point, I chose to stop. I had a feeling I could take that web part in any direction I wanted, while having the Copilot agents be my developers.
Scope and the golden question
I appreciate that a quick links web part is a very simple type of component. Nothing really complex. But a quick links web part has been part of every intranet I've seen running in SharePoint or from SaaS vendors. Somewhere in the intranet, there is at least a launch pad from where applications can be linked out to. So, a quick links web part is an extremely useful component, and it was impressive to see how, as a product manager with technical background, I could get Copilot to create this functional solution.
However, could it also be used to build more complex solutions, bigger web parts, or work with scenarios where there are dependencies across multiple solutions? This is for me right now the golden question and something I want to explore further.
In any case, seeing Copilot agents working on assigned issues makes them an incredibly helpful assistant for solving proper bugs in applications or even implementing small enhancements. I can definitely see how teams can benefit from this.
Speed, time, and human oversight
An AI agent takes little time to start and complete a task. Within 30 minutes, you might have a PR that a professional developer or another Copilot agent (or both) can review.
I believe that humans should be involved in any of these loops that involve the work of autonomous AI agents, so we can have someone in control, overseeing and approving what an autonomous AI agent created.
In my experiment, as I didn't work on it uninterrupted, it's hard to estimate the exact amount of time it took me. But I think to create all 8 user stories (simple stories but sufficient for Copilot to deliver), coordinate and merge all 10 PRs, plus build, deploy, and test the solution, I might have spent a total of 3–4 hours. I still see a few minor things that could be improved on the quick links web part, but I think it is enough as-is and after some minor tweaks the solution could be used in a production environment.
Closing thoughts
It's fascinating how capable these autonomous AI agents have become, and we must keep in mind that the Copilot agents in GitHub are still in preview. I appreciate, as mentioned previously, that this is a simple scenario. But a lot of the work done in development also contains simple scenarios. These simple tasks could be assigned to an autonomous AI agent, and then you have another developer validating and improving the AI's work.
Thanks for reading,
Jarbas
