Building with Copilot

The Project

The application was made for the sales team to receive notifications and communicate through chat while working from their phones.

• Users: the sales team, working away from their desks.
• Platform: a React Native mobile application.
• Backend: already available. My responsibility was to consume its APIs and turn them into a complete mobile experience.
• Timeline: from September to December 2025.

This was not a small practice project. The application needed authentication, a chat list, detailed chat conversations, notifications, settings, and the supporting states that connect those features.

Learning by Building

I had to learn how React Native handled navigation, component state, API requests, and device behavior while continuing to build the product.

Copilot helped shorten the distance between a question and a working implementation. I could describe what I wanted to build, review the generated code, run it, and then ask for changes when the result did not fit the application.

When I encountered an unfamiliar React Native pattern, it gave me a practical starting point that I could study in the context of a real feature, instead of learning everything only through isolated examples.

What Changed From the Web

My experience with Next.js and React still mattered, but mobile development introduced new constraints:

• Lifecycles: screens have different lifecycles than web pages.
• Keyboards: the on-screen keyboard affects layouts.
• Networks: connections are not always stable.
• Notifications: they must behave correctly when the application is active, in the background, or reopened.

Copilot accelerated the implementation, while the application itself taught me which details required more attention.

What I Built

I used Copilot across the application rather than for one isolated feature. It helped me create and refine:

• Login flows: connected the mobile interface to the existing authentication API and handled loading, success, and error states.
• Chat lists: presented conversations clearly and kept the most relevant information easy to scan.
• Chat details: where users could read messages, send replies, and move naturally through an active conversation.
• Notifications: brought sales users back to the information and conversations that needed their attention.
• Settings and supporting screens: made the application feel complete instead of like a collection of disconnected features.

How I Used Copilot

The useful part was not simply that Copilot could produce code. It helped maintain momentum. Without leaving the development flow every few minutes, I could use it to:

• Draft components.
• Connect API responses to the interface.
• Investigate errors.
• Refactor repeated logic.
• Explore alternative solutions.

Iterating on the Result

From September to December 2025, the application continued to evolve. Shipping the first version of a screen was only the beginning. I repeatedly improved the user experience, adjusted interactions that felt awkward on a phone, reduced unnecessary work, and looked for places where the application could respond faster and more reliably.

Copilot was especially valuable during these iterations. Once a feature worked, I could use it to examine the implementation, suggest cleaner structures, reduce duplication, and help identify possible performance problems. I still needed to test the behavior and decide whether a suggestion was appropriate, but I could explore more improvements in the same amount of time.

From Premium Requests to AI Credits

How Copilot measured usage changed a lot between the time I built this application and a year later.

In 2025, the allowance felt almost unrestricted in practice. I could keep Copilot involved throughout the day, including when working with Claude Sonnet models. It felt less like a tool reserved for difficult moments and more like a coding partner that was continuously available while I built and learned.

By September 2026, GitHub had moved eligible Copilot usage to AI credits. In my own usage dashboard, one sustained day of agent work could leave only 0-20% of the monthly allowance. These percentages are not universal limits, but they show how much more carefully I now have to think about the cost of long agent sessions. That change is part of why I started looking at other tools, which I describe in Working with GPT.

Speed Is Not Understanding

Using a coding agent did not remove the need to understand the application. Generated code could be incomplete, use the wrong assumption about an API, or solve a problem in a way that did not match the experience I wanted. I still had to read the code, connect it to the existing backend, test it on a real device, and take responsibility for the final behavior.

What changed was the speed of the feedback loop. Instead of spending too much time getting from an idea to the first implementation, I could reach that point quickly and spend more time evaluating the result. That helped me learn React Native through building, debugging, and improving a real product.

Lessons

Learn inside a real feature
Studying a pattern in the context of a screen I actually needed taught me more than isolated examples.

Review every result
Generated code is a starting point. Reading it, testing it on a real device, and owning the final behavior are still the developer's job.

The first version is only the beginning
Most of the value came from iterating on screens that already worked.

By December 2025, I had developed a complete set of mobile chat features and iterated on their user experience and performance. GitHub Copilot did not build the application on its own, but it gave me leverage: I could learn faster, produce more, and improve the work through more frequent iterations. For me, that is the most useful role of a coding agent, not replacing the developer, but accelerating the path from learning to delivering.