How GitHub Copilot and I Split the Work of Building Memolog
Why I Wrote This Article
Memolog is an Astro blog deployed on Azure Static Web Apps. Over time, I have expanded it with Azure Functions, Table Storage, Azure AI Translator, Application Insights, and other services.
I built much of the code with GitHub Copilot. Looking back, though, the division of work was not as simple as “I wrote the requirements, and Copilot wrote the code.”
- At first, I used Agent Mode in VS Code to shape the requirements, design, and implementation plan through conversation.
- Later, I created GitHub Issues and delegated implementation asynchronously to the Copilot coding agent, which I call Cloud Agent in this article.
- I reviewed and integrated the pull requests created by Cloud Agent with local Copilot.
- After experiencing duplicate work and coordination overhead from parallel execution, I shifted toward local implementation while keeping an issue-first workflow.
For this retrospective, I cross-checked past conversation logs, GitHub Issues, pull requests, commits, and the repository’s current rules to clarify which responsibilities I kept and which I delegated to Copilot.
Table of Contents
- Key Takeaway
- What I Built for Memolog
- Stage 1: From Concept to Implementation with Agent Mode
- Stage 2: Handing Implementation from Issues to Cloud Agent
- Using Local Copilot as a Quality Gate
- When Parallel Work Produced the Same Fix Twice
- Stage 3: Shifting to Local Implementation While Staying Issue-First
- How GitHub Copilot and I Divide Responsibilities
- What the Execution Logs Showed
- When I Still Want to Use Cloud Agent
- Summary
Key Takeaway
In one sentence, this is how Copilot and I divide the work:
I decide why to build something, which approach to adopt, and what I am accountable for. Copilot accelerates research, organization, implementation, and validation.
Even when I delegate implementation to Copilot, I still decide the priority of requirements, the acceptable Azure cost and security constraints, the intended user experience, and whether a change should go to production. Copilot, meanwhile, has been especially effective at finding related code, comparing options, iterating on fixes, running tests, and checking production state.
The development workflow itself has also evolved.
What I Built for Memolog
Memolog started as a static blog, but it now has the following architecture.
| Area | Main components |
|---|---|
| Web | Astro, MDX, React Islands, Azure Static Web Apps |
| API | Azure Functions Flex Consumption |
| Data | Azure Table Storage, Private Endpoint |
| Multilingual support | Azure AI Translator, GitHub Actions OIDC authentication |
| Monitoring | Application Insights |
| Infrastructure as Code | Bicep |
| Development management | GitHub Issues, pull requests, Actions, Copilot |
The Azure environment had tenant-specific policies, including a prohibition on shared key authentication and disabled public network access. Instead of using typical samples as-is, I had to redesign the architecture around Managed Identity, Private Endpoint, and OIDC.
Discovering these constraints and deciding which architecture to adopt became a collaborative effort between Copilot and me.
Stage 1: From Concept to Implementation with Agent Mode
During the initial development, I told Agent Mode in VS Code that I wanted to proceed in this order:
- Document the architecture in docs
- Design the site
- Write the Phase 1 Bicep
- Scaffold the application
Based on those instructions, Copilot not only created the repository but also documented the reasoning in docs/architecture.md and docs/design.md. It then implemented the Astro pages, components, styles, and Bicep in the same flow.
At this stage, I was mainly responsible for:
- The goal of bringing my personal site back
- The decision to use Azure, centered on Static Web Apps
- Design and feature priorities
- The order in which design and implementation should proceed
Copilot’s role was to turn vague requests into documentation and code, then carry them through to an initial buildable state.
The strength of this approach was that the context connecting design and implementation remained intact. Decisions made in conversation could flow directly into documentation, code, and tests.
However, when decisions live only in a long conversation, it becomes difficult to trace later why an implementation took a particular shape. That led me to start using GitHub Issues as the unit of work.
Stage 2: Handing Implementation from Issues to Cloud Agent
For multilingual support, I first discussed the international SEO strategy with Agent Mode. Browser translation does not create actual English pages, which makes attracting traffic from English-language search difficult. I therefore chose to generate translated HTML under /en/.
I then broke the work into an Epic and individual Issues.
| Issue | Scope |
|---|---|
| #4 | Epic for multilingual support and international SEO |
| #1 | Astro multilingual routing foundation |
| #2 | Translation pipeline using Azure AI Translator |
| #3 | Final SEO work, including hreflang, canonical URLs, and the sitemap |
When I assigned the first Issue, #1, to Cloud Agent, it worked asynchronously and created a Draft Pull Request. I did not have to remain at my PC waiting for the implementation to finish, so I could work on something else in parallel.
The division of responsibilities during this period was clear.
- Me: Turn the purpose, priorities, constraints, and architecture decisions into Issues
- Cloud Agent: Implement the Issue scope and return a PR with test results
- Local Copilot: Read the PR diff, then build and validate it in my local environment
- Me: Review the results and decide whether to merge, request changes, or defer the work
Using Local Copilot as a Quality Gate
I did not merge a PR unchanged simply because Cloud Agent had created it.
In PR #11, which implemented the multilingual translation pipeline, the initial design used OIDC authentication from GitHub Actions to Azure. At the time, I could not create an App Registration in my tenant, so I concluded that the proposed architecture would not work as written.
I reviewed the diff with local Copilot and followed these steps:
- Check not only for code conflicts, but also for conflicts with the operating model
- Submit a Request Changes review on the PR
- Remove Azure authentication from CI and have the implementation changed to the local AAD authentication that was working at the time
- After the change, verify the local build and the generated English pages
Later, I confirmed that another system in the same tenant was successfully using OIDC with a User Assigned Managed Identity and a federated credential, so I revised my assumptions. Memolog now uses its own Managed Identity to run translation in GitHub Actions.
The important part was not clinging to the initial decision. When evidence from the actual environment disproved either Copilot’s answer or my understanding, I updated it.
When Parallel Work Produced the Same Fix Twice
Not every use of Cloud Agent went smoothly.
English article cards once appeared on the Japanese home page and linked to a nonexistent /blog/en/... path. I documented the cause and proposed fix in Issue #13, then assigned it to Cloud Agent.
However, another Issue, #15, was created for the same problem, which led to PR #14 and PR #16. Both added the same filter to the same two lines in src/pages/index.astro; the fixes were identical at the byte level.
I resolved the duplication as follows:
- Reviewed PR #14 and merged it after the build passed
- Closed PR #16 as a duplicate
- Closed Issue #15 as a duplicate of Issue #13
- Confirmed that the incorrect English links had disappeared from the production home page and that English articles displayed correctly
This experience showed me that parallel execution can reduce implementation time, but unclear work boundaries increase integration costs.
The problem was not Cloud Agent itself. It was insufficient coordination when defining the Issues. In a small, tightly coupled repository, dependencies and overlap between Issues need to be checked first so that multiple agents do not modify the same file or address the same defect.
Stage 3: Shifting to Local Implementation While Staying Issue-First
As the site gained features, a single fix increasingly required checking the Web app, API, Infrastructure as Code, GitHub Actions, and the production Azure environment.
For this kind of work, carrying forward the context of the current local conversation and the latest validation results can be faster. I now keep the rule of creating an Issue first, while doing more of the implementation with local Copilot.
The repository’s .github/copilot-instructions.md currently defines these rules:
- Link changes to an existing Issue before starting; create an Issue if none exists
- Do not create a duplicate Issue for the same objective
- Record implementation decisions, validation results, deployment results, and related PRs in the Issue
- If no executor is specified, work in the current local session
This approach preserves the speed of moving directly from conversation to implementation and validation, while making the purpose and results traceable later through the Issue.
How GitHub Copilot and I Divide Responsibilities
This is how the responsibilities are divided today.
| Work | Me | GitHub Copilot |
|---|---|---|
| Purpose | Decide what to accomplish and who it is for | Structure the purpose into requirements and tasks |
| Priorities | Decide what to do now, later, or not at all | Propose dependencies and implementation order |
| Architecture | Decide what to adopt based on cost, security, and operational constraints | Research and compare options, official information, and the existing implementation |
| Implementation | Define expected behavior and acceptable boundaries | Change code, tests, IaC, and documentation |
| Review | Decide whether to accept a risk and whether the experience is good enough | Detect problematic diffs, regressions, security issues, and missing tests |
| Validation | Decide whether to deploy to production and whether the problem is solved | Check builds, tests, CI, HTTP responses, and logs |
| Recordkeeping | Choose which decisions need to be preserved | Organize Issues and documentation so the work can be reproduced |
| Final accountability | Approve merges, publication, and Azure changes | Report results and uncertainty |
In particular, I do not give up these four responsibilities:
- Purpose: Being technically possible does not make something worth building.
- Accepting constraints: A person must decide how much cost, security risk, privacy impact, and operational burden is acceptable.
- Adoption decisions: Copilot’s proposals are options, not decisions.
- Production accountability: I remain responsible for the final decision to publish or deploy.
Conversely, I actively delegate tasks that suit Copilot: finding relevant areas in a broad codebase, narrowing hypotheses through tests, and repeating the same checks precisely.
What the Execution Logs Showed
For this retrospective, I compared session logs with GitHub records rather than relying only on memory. These were some of the representative events.
| Date | Recorded request or decision | Confirmed result |
|---|---|---|
| 2026-07-13 | Proceed with documentation, design, Phase 1 Bicep, and scaffolding in that order | Created architecture documents, the Astro site, Bicep, and the initial build |
| 2026-07-13 | Break multilingual support into Issues and assign #1 to Cloud Agent | Reviewed PR #5 locally and confirmed a build that included the English routes |
| 2026-07-13 | The authentication design in PR #11 did not fit the tenant constraints | Submitted Request Changes and validated again after the design was revised |
| 2026-07-14 | Review PR #14 and PR #16 together | Confirmed that the fixes were identical, merged one, and closed the other as a duplicate |
| 2026-07-20 | Revisit the OIDC assumptions using evidence from the actual environment | Built CI translation with Managed Identity and confirmed the English articles in production |
| 2026-07-31 | Write this article | Created Issue #117 and drafted the article locally after cross-checking execution logs, Issues, and PRs |
The logs showed me that developing with Copilot is not about receiving the correct answer once. It is a process of implementing a hypothesis, testing it in the real environment, and updating both the implementation and the record when it is wrong.
When I Still Want to Use Cloud Agent
Local implementation is now my default, but I have not stopped using Cloud Agent. I still expect it to be useful when:
- The target files and completion criteria are clear, with little risk of conflict with other work
- I want a longer test or investigation to run asynchronously
- I want work to continue on GitHub while my PC is closed
- I want the result delivered as a reviewable artifact in a Draft PR
By contrast, work that depends heavily on the latest local validation, incident response spanning multiple layers, or changes concentrated in the same files is easier to handle continuously with local Copilot.
The important question is not whether Agent Mode or Cloud Agent is better. It is which one fits the work’s independence, wait time, and integration cost.
Summary
As I built Memolog, the way GitHub Copilot and I divided the work gradually changed.
- I started with Agent Mode, connecting concept, design, and implementation in one continuous flow.
- I then handed Issues to Cloud Agent, combining asynchronous implementation with local review.
- Duplicate PRs and mismatches with environment constraints taught me the importance of well-defined Issues and quality gates.
- Today, I preserve the issue-first record while doing more implementation and validation with local Copilot, which already has the relevant context.
Copilot did more than increase the speed of writing code. It accelerated the entire loop across research, design, implementation, testing, production verification, and recordkeeping.
However, deciding what to build, what to trust, which risks to accept, and when to release to production remains my responsibility. Keeping that boundary in mind is what makes Copilot a development partner rather than merely a code generator.