From Prompts to Productivity with GitHub Copilot

This article is part of the XPRT. Magazine #21

Introduction

For many developers, the first experience with AI in the editor feels helpful, but limited.

You ask a question, get a response, copy a suggestion, and move on. Maybe you tweak a function, generate a test, or clean up a block of code. That is useful, but it can still feel like a series of small, disconnected assists.

Agentic development changes that.

Instead of helping with just one step at a time, AI starts helping across the job as a whole. A developer can begin by asking it to inspect the app, understand how it is organized, identify where a likely problem lives, propose a fix, add or update tests, summarize what changed, and even help prepare the work for review. The experience starts to feel less like asking for isolated answers and more like working with a development teammate.

That shift is easier to appreciate in a real application. In this article, that application is Movie Explorer. It serves as the backdrop for a practical story about how developers can use agentic development from start to finish. The journey begins with discovery, understanding the structure of the app, the main components, and how the pieces fit together. From there, the workflow moves into making a fix, validating the result with tests, and then extending into larger tasks that can be handed off to Coding Agent in the cloud when the work grows beyond a quick local change.

That end-to-end flow is the real point. The value is not just that AI can suggest code. The value is that it can help carry momentum through the broader development process. Developers still decide what matters, what good looks like, and whether the result is actually correct. But instead of manually driving every small step, they can use agentic development to move from investigation to implementation to validation with much less friction.

Most developers do not need AI only for blank-page code generation. They need help with the kind of work that fills a normal day, understanding an unfamiliar part of an app, tracing behavior, making a safe change, checking that nothing else broke, and packaging the work in a way that is ready for review.

So rather than treating AI as a smarter autocomplete tool, this article looks at a more practical model, using GitHub Copilot as an active partner in the workflow. We start inside VS Code, where a developer can use Agent Mode to inspect, reason, and act across multiple steps. Then we build toward a bigger idea, knowing when to keep work local and when to use Coding Agent in the cloud for larger or longer-running tasks.

GitHub Copilot starts to feel different at that point, not just a prompt helper, but a development teammate.

What changes in VS Code when you switch to Agent Mode

The next question is the obvious one.

What actually changes when a developer moves from a normal GitHub Copilot chat experience to an agentic one?

At first glance, not much. You are still in VS Code. You still have a prompt box. You are still talking to GitHub Copilot. That is why many developers miss the shift the first time they see it. It looks familiar, but the working style is different.

In a more traditional chat flow, the interaction is mostly conversational. You ask for help, GitHub Copilot responds, and you decide what to do with the answer. That works well when you want explanation, quick guidance, or help thinking through a problem before making changes yourself. Agent Mode changes the nature of the interaction.

Ask Mode helps you think. Agent Mode helps you move.

That distinction matters more than it first appears. A developer working in Movie Explorer might begin with simple questions. Which parts of the app handle routing, state, persistence, and tests? Where would a UI issue most likely live? What is the safest place to start reading? That kind of discovery is still part of the job, and it is often the smartest first move.

Once the developer has enough context, the goal changes. They understand the shape of the app. They know the behavior they want to correct. Now they want GitHub Copilot to do more than answer questions. They want it to investigate, propose edits, create or update tests, and help carry the task forward in a connected way.

That is where Agent Mode starts to earn its place in the workflow.

The most important difference is that the unit of work gets bigger. Instead of asking for one isolated suggestion, the developer can describe the job in plain language and let GitHub Copilot work across several steps at once. Rather than prompting separately for diagnosis, code, tests, and explanation, the developer can frame the full outcome they want.

That changes the rhythm of the work. Instead of breaking the task into a string of disconnected prompts, the developer keeps momentum. They stay inside one flow of intent. That is faster, but it is also cleaner. A stronger prompt reduces unnecessary back-and-forth with the model, which means less time restating context and fewer wasted premium requests spent recovering from a vague start.

There is another piece that starts to matter once the workflow becomes more agentic.

Once a developer wants GitHub Copilot to work beyond the file in front of them, the conversation needs more than context. It needs tools. That is where GitHub connectivity becomes part of the experience. Instead of treating the editor and the repository as separate worlds, the workflow can start to connect local work with issues, pull requests, and review activity.

The goal is not simply to have AI generate code faster. The goal is to keep momentum across the whole task.

A developer can start by inspecting Movie Explorer locally. They can move into Agent Mode when they are ready to act. They can use Playwright to validate the work. Then, once the task grows larger, or is better handled with more room to run, they can hand it off.

This is where Coding Agent in the cloud enters the picture.

I think of Agent Mode and Coding Agent as two parts of the same conversation. Agent Mode is the developer and GitHub Copilot working together in the editor, close to the code, close to the browser, and close to quick validation. Coding Agent is what you reach for when the task deserves more runway, when you want to delegate work and let it continue while preserving the context you have already built.

That handoff matters because not every task should be handled the same way. Some work is close reading and quick correction, and that belongs locally. Some work needs iteration, patience, and time, which is where cloud-based delegation starts to make sense.

That is the pattern we will use for Movie Explorer. Start with understanding. Move to Agent Mode when you are ready for action. Stay local when the task is focused. Hand larger, well-bounded work to Coding Agent when the job should continue beyond your immediate editing session.

Starting with discovery in Movie Explorer

Before a developer asks GitHub Copilot to fix anything, there is an earlier step that matters more than it may seem at first.

They need to understand the app and that is where discovery comes in.

In a real codebase, one of the easiest mistakes is jumping too quickly into a fix. A developer notices something is off, opens the first file that looks relevant, and starts making changes before fully understanding how the behavior is connected. Later, they realize the issue touches more than one part of the app. Movie Explorer is a good example of this. It looks approachable on the surface, but it still has enough moving parts that a rushed change can easily land in the wrong place. Movie Explorer includes several stateful behaviors and user-facing interactions, which makes that early understanding especially important.

A developer might start by reviewing the app the same way a user would. Open it in the browser. Click through the main flows. Notice how the app behaves. Pay attention to what feels smooth, what feels inconsistent, and where behavior may depend on state being carried across screens or sessions.

Discovery is not time spent before the real work, it's part of the real work.

In Movie Explorer, the goal at this stage is simple. Build a mental model of how the app is put together. Which routes shape the experience. Where shared behavior may be initialized. Which files appear central to the way the app behaves. Since Movie Explorer has state management challenges, that understanding becomes even more important before making a change.

This is where GitHub Copilot becomes useful in a very practical way, not because it is writing code yet, but because it helps the developer understand faster.

Instead of manually opening file after file and piecing everything together alone, the developer can ask GitHub Copilot to explain the structure in plain language. Which components appear to drive the experience. Where state seems to begin. Which files are most likely connected to the behavior they observed (e.g., "Which files handle theme persistence and local storage in this app?"). That turns GitHub Copilot into something more valuable than a code generator. It becomes a teammate helping the developer get oriented.

A good discovery prompt saves time twice. It shortens the path to understanding, and it lowers the chance of solving the wrong problem. It also reduces needless round-tripping with the model. When the first prompt is grounded and specific, the developer is less likely to burn extra time, and extra premium requests, asking follow-up questions that could have been avoided with better context up front.

That changes the quality of everything that follows. A developer who starts with discovery can write a much stronger prompt when it is time to act. They know which files are probably involved. They know whether the change is likely isolated or spread across multiple parts of the app. They know what behavior needs to be preserved while they work. They are no longer prompting into the dark.

That is one of the most practical benefits of using GitHub Copilot this way. The AI is not there only to generate output. It is there to help the developer build context faster, and that context is what makes the later steps more effective. The better the understanding, the better the prompts. The better the prompts, the better GitHub Copilot can contribute as a teammate.

Movie Explorer offers a strong backdrop for this because it reflects the kind of application developers recognize right away. It has a modern front end, connected application behavior, and enough state and persistence to make discovery worthwhile before any changes begin. The point is not complexity for its own sake. The point is that it feels like the kind of app where understanding the flow matters.

So the discovery step is not really about slowing down, it's about setting up better momentum.

Open the app. Observe it like a user. Ask GitHub Copilot to map the terrain. Identify the files that matter. Get clear on where the behavior likely lives. Then move forward with purpose.

Once the developer understands the shape of Movie Explorer, the next step becomes much more natural. Now GitHub Copilot can help move from understanding into action, making a focused fix, validating it with Playwright, and proving the result holds up.

Moving from fix to validation with Agent Mode and Playwright

Discovery gives a developer direction and the confidence to act.

This is the point where GitHub Copilot stops helping the developer understand the app and starts helping them change it. In Movie Explorer, that usually means taking something a user would notice, a behavior that does not hold up across refreshes, navigation, or repeated interaction, and turning it into a focused piece of engineering work that can be fixed, tested, and reviewed with confidence. Movie Explorer is well suited for this kind of story because it includes the kinds of issues frontend developers see in normal work, including persistence problems, timing-related behavior, and test instability.

This is where Agent Mode starts to feel different from a normal chat interaction.

A developer is no longer asking GitHub Copilot for a single suggestion. They are describing a job. Investigate the issue, make the fix, add tests that prove it, and explain what changed. The value is not just speed. It is continuity. The same thread of intent can carry from diagnosis to implementation to validation instead of forcing the developer to restart the conversation at every step.

Instead of breaking the task into a dozen disconnected prompts, the developer can frame the outcome they want and let GitHub Copilot help carry it through. The better the initial framing, the smoother the execution.

Movie Explorer gives a practical example of this with a repair centered on theme persistence. The issue itself is easy to understand from a user perspective: the app should remember the selected theme and keep the experience consistent across reloads and navigation. What matters here is not the exact implementation detail. What matters is how the developer approaches the job with GitHub Copilot as a teammate. GitHub Copilot can be asked to investigate the cause, implement the repair, create focused Playwright coverage, and explain the root cause and solution when finished.

That is a much better unit of work. It reflects how developers actually think when they own a fix. They do not just want code that looks plausible. They want the behavior corrected, the risk reduced, and the result backed by evidence.

This is where Playwright becomes part of the story, not as an afterthought, but as a partner to Agent Mode.

A fix is only half the job. The other half is proving it holds. In Movie Explorer, Playwright validates visible behavior, persistence across reloads, and flow across navigation, not just whether some internal state happened to change. The strongest tests check behavior the user can actually observe, and they cover the edge conditions most likely to break once the code evolves.

A fix that passes a quick glance can still fail in the exact place users care about most. A button appears right until the page refreshes. A preference looks saved until navigation resets it. A feature works once, but not twice. Playwright closes that gap by moving validation into the browser, where behavior has to prove itself under realistic use.

GitHub Copilot fits naturally into that loop. The developer can ask GitHub Copilot not only to make the code change, but also to generate a small set of focused Playwright tests that match the expected behavior. In Movie Explorer, that includes validating what the user sees, checking persistence after reload, and confirming the behavior survives route changes. The result is not a giant wall of generated test code. It is a tighter, more purposeful validation pass built around the same intent as the fix.

That is where GitHub Copilot starts to feel like a genuine teammate. It is not just helping the developer write faster. It is helping the developer think in complete units of work. What is the issue, what should the outcome be, how do we prove it, and what explanation will the next reviewer need?

There is another benefit here too. It keeps the change reviewable.

A focused repair with focused Playwright coverage is easier to understand, easier to validate, and easier to trust. Even when GitHub Copilot is doing more of the heavy lifting, the developer still stays in charge of what gets kept, what gets revised, and whether the resulting diff is something they would actually want in the repository.

This is the pattern worth noticing. A developer sees the behavior, frames the job clearly, lets GitHub Copilot work across the code and tests, then checks the result in the browser and the test runner. That is a very different experience from asking for a code snippet, pasting it into a file, and hoping for the best.

Once that rhythm clicks, the next step becomes obvious. If GitHub Copilot can help a developer move smoothly from understanding, to fix, to validation on a focused task, what happens when the work is bigger than a focused task? What happens when the job deserves its own issue, branch, draft pull request, and more room to run?

When the work gets bigger, handing it to Coding Agent

There is a natural point where a developer can feel the task expanding.

A focused fix is one thing. You can keep that local. You can stay in VS Code, work side by side with GitHub Copilot, run the app, validate the behavior, and tighten the result before moving on.

But sometimes the job is bigger than that.

It is no longer just a correction, it's a feature request. It may touch several files, stretch across front end and back end, introduce new interactions, and need enough room to evolve before it is ready for review. That is where the workflow changes again, not because the developer is stepping away, but because the kind of work now deserves a different teammate experience.

This is where Coding Agent starts to make sense.

With Movie Explorer, a larger request might be something like improving the experience around movie details, adding a watchlist feature, or introducing a more polished interaction that spans UI behavior, data flow, and validation. These are not one-file edits. They are the kind of changes that benefit from a clearly described issue, explicit acceptance criteria, and an agent that can take that work, create a branch, and open a draft pull request for the developer to review.

The developer is no longer asking, “Can GitHub Copilot help me write this?”, but instead asking, “Can GitHub Copilot help me carry this feature through its first meaningful stage?”

That is a better question. It treats GitHub Copilot less like a typing assistant and more like a teammate that can take ownership of a bounded task. The developer still defines the goal. The developer still decides what good looks like. But instead of manually scaffolding every file and every step, they hand GitHub Copilot a clear assignment and review the resulting work with intent.

Clarity matters a lot here. When you delegate larger work, a vague specification means bigger rework. A well-framed issue gives GitHub Copilot a clear target, boundaries, and definition of done. That helps the agent move with more confidence, and it gives the developer a better starting point when the draft pull request arrives.

Movie Explorer provides a good example because the larger work is not framed as magic, it's framed as structured engineering. The issue leads, the agent follows, and a branch gets created. Changes show up across the app. A draft pull request appears. Then the developer returns to the middle of the story, not the end of it. They still pull the branch down locally, explore the implementation in the browser, run tests, and decide what needs adjustment before anything is merged.

Coding Agent is not about giving up control, it's about changing where the effort goes.

Instead of spending the first block of time scaffolding and wiring together the initial implementation, the developer can spend that energy reviewing the shape of the work, checking whether the acceptance criteria were truly met, validating the result in the browser, and making any human judgment calls the agent could not. That is a better use of senior developer attention.

Movie Explorer helps make that practical because the examples naturally span multiple files and behaviors. One larger request in the app focuses on improving the experience across the interface while preserving existing functionality such as favorites, search, pagination, and theme persistence. Another centers on adding a watchlist feature. In both cases, the idea is the same, the work is broad enough that it benefits from a fuller handoff to GitHub Copilot, but still bounded enough that the developer can review it meaningfully when it comes back.

That balance is where Coding Agent is strongest, not for every task, and not for vague ambition, but for concrete work with enough shape to delegate.

There is a practical rule underneath all of this. Keep small, fast-moving repairs local. Hand larger, well-bounded feature work to Coding Agent. This doesn't just improve flow, it improves judgment.

When developers use GitHub Copilot this way, they stop forcing every task through the same door. They choose the working style that fits the job. Some work needs close collaboration in the editor. Some work benefits from a more asynchronous handoff. The point is not to use the agent everywhere. The point is to use it where it helps most.

That is what makes GitHub Copilot feel like a teammate instead of a novelty. A teammate does not have to do everything. A teammate helps move the right work forward in the right way.

Once that larger feature comes back as a draft pull request, the developer returns to the same standard that mattered earlier. Review the work. Run it. Test it. Make sure it fits the app. Confirm that the quality is there. Then decide whether it is ready.

That final judgment still belongs to the developer, as it should.

Because the best version of this workflow is not AI replacing engineering discipline. It is AI giving that discipline better momentum.

Best practices, using AI as a teammate

By this point in the story, the pattern is clear. GitHub Copilot is most useful when it is treated like a teammate, not a shortcut.

That sounds simple, but it changes how a developer works. A shortcut is something you reach for when you want to skip effort. A teammate is someone you work with when you want better outcomes. Those are not the same thing.

Start with a clear job.

GitHub Copilot does better when the developer gives it a bounded task with context, constraints, and a visible definition of success. That could mean asking it to understand how Movie Explorer is structured before touching code. It could mean asking it to fix one behavior and add Playwright coverage that proves the fix holds. It could mean writing a feature request with clear acceptance criteria before handing it to Coding Agent. In every case, clarity improves the result. It also reduces unnecessary round-tripping, which means less wasted time and fewer wasted premium requests.

Choose the working style that fits the task.

Some work belongs in the editor with GitHub Copilot Agent Mode. That is usually the right place for discovery, diagnosis, focused fixes, and tight feedback loops with the browser and test runner nearby. Other work is better suited for Coding Agent, especially when the task is broad enough to deserve its own issue, branch, and draft pull request. Movie Explorer shows both ends of that spectrum, small repairs that benefit from close local collaboration, and broader feature work that can be delegated and then reviewed locally before merge.

That choice matters. When developers force every task through the same workflow, they lose efficiency and often lose clarity. A tiny repair does not need a full cloud handoff. A broader feature should not always be squeezed into a local chat thread. The best results usually come from matching the tool to the shape of the work.

Always validate what comes back.

GitHub Copilot can help move a task forward quickly, but speed is not proof. Developers still need to run the app, look at the behavior in the browser, execute tests, and review the actual diff. In Movie Explorer, that is especially important because many of the app’s concerns live in behavior the user can feel: persistence, navigation flow, state continuity, and stable UI interaction. A change that looks reasonable in code still has to earn trust in the running application. That is why Playwright matters so much in this workflow, it gives the developer a way to validate outcomes instead of relying on assumptions.

There is another habit worth keeping close. Prefer focused changes over dramatic rewrites.

GitHub Copilot can generate a lot. That does not mean a developer should accept a lot. Smaller, targeted diffs are easier to review, easier to test, and easier to trust. They also make it easier to see whether the agent truly understood the assignment or simply produced something large and plausible.

One more best practice sits underneath all the others. Use GitHub Copilot to build momentum, not to avoid thinking.

That is the heart of the teammate model.

GitHub Copilot can speed up discovery. It can help frame a fix. It can generate tests, summarize changes, support review, and carry larger work into a draft pull request. What it should not do is replace the developer’s responsibility to reason about the app. In practice, the most effective use of AI tends to come from developers who stay curious and skeptical at the same time. They let GitHub Copilot do meaningful work, but they keep asking the questions that matter. Is this the right place to change behavior? Does this test really prove the outcome? Does this pull request fit the architecture and the standard of the codebase?

That is why the phrase AI as a teammate holds up.

A good teammate helps you move faster, but also helps you work better. A good teammate does not remove accountability. It sharpens it. With GitHub Copilot, the best experience is not passive acceptance. It is active collaboration.

Movie Explorer makes that idea concrete. A developer begins by understanding the app. They move into a focused repair. They validate with Playwright. They hand broader work to Coding Agent when it deserves more room to run. Then they review, refine, and decide what is ready.

That is not a story about replacing engineering discipline, it's a story about giving that discipline better support.

And that is the bigger takeaway. The real step forward is not that GitHub Copilot can answer better prompts. It is that developers can now work in a more connected way, moving from discovery to implementation to validation to review with AI contributing across the whole path. When that is done well, GitHub Copilot stops feeling like a clever feature in the editor.

It starts feeling like part of the team.