Modernizing yonka.dev with GitHub Copilot CLI: An Engineering Case Study

I'm not particularly fond of command-line tools, so spending eleven development sessions working almost entirely with GitHub Copilot CLI wasn't something I expected to enjoy. But I did.

The project was the modernization of yonka.dev, my professional website. I wanted to replace an older ASP.NET Core Razor Pages implementation and explore a different approach to AI-assisted development.

While building WeeklyBoard, a web application for weekly plans and recurring activities, I had discussed features with AI, reviewed the code it produced, and integrated changes manually in Visual Studio. This time, I wanted to see what happened when Copilot could investigate and modify the repository itself.

I wanted to understand what working with a coding agent across a complete project would actually involve, rather than using one only for isolated coding tasks.

The framework recommendation I didn't expect

After years of working with .NET, I would probably have chosen another .NET solution for my website without considering much else. Instead, I asked Copilot CLI in Plan mode to examine my existing ASP.NET Core Razor Pages application and assess what would best serve the new requirements: product pages, a growing article archive, English and German content, responsive design, and simple deployment.

To my surprise, Copilot suggested Astro, a framework I hadn't used. That recommendation made sense once I reconsidered the site's only server-dependent feature: its contact form. I decided to replace it with professional email and LinkedIn links, so the new website no longer needed a backend.

I could have kept ASP.NET Core or built the site with plain HTML. The real question was how much structure a content-focused website needed as it grew.

Astro offered the balance I needed: reusable pages and Markdown content without a continuously running application server.

Copilot broadened the options I considered, but I made the final decision after reviewing the trade-offs. For me, that was an unexpectedly valuable use of AI before writing any code.

It also reinforced something important to me as a product engineer: the technology I know best is not necessarily the best fit for the product I am building. Whether it is my own project or a customer’s, the requirements should guide the technology choice, not just familiarity with a particular stack.

From discovery to implementation planning

With the architecture decided, I continued using Copilot CLI's Plan mode to work through the implementation approach. Copilot examined the existing repository and its dependencies, helping me identify what could be reused, what needed to change, and what could be removed as part of the migration to Astro.

During this process, I encountered a couple of situations where I had to redirect Copilot. In one instance, it moved toward implementation planning before completing the investigation I'd requested. In another, it proposed deleting and recreating a discovery document rather than updating it, which would have risked losing earlier findings.

Neither was a major problem, but both showed me the importance of reviewing not only Copilot's proposed results, but also how it intended to achieve them.

As planning progressed, I documented the website requirements in docs/modernization/product-discovery.md and the development expectations in .github/copilot-instructions.md. The distinction was useful: one described what the website should become, while the other guided how Copilot should work within the repository, including engineering conventions, verification and approval boundaries.

The instructions evolved as I encountered situations that called for clearer guidance.

Make the implementation reviewable

Choosing Astro was only the beginning. The migration required more than creating a new homepage. The site needed shared page layouts, navigation, content organization, localization, responsive styling, a persistent theme preference, legal pages and a publication archive. Copilot worked directly in the repository as I implemented those parts of the site.

I moved between Copilot's Plan, Interactive and Autopilot modes as the work changed. Plan was useful for open questions; Interactive gave me more control while I learned how the agent operated; and Autopilot suited bounded implementation tasks with clear acceptance criteria. In later sessions, I also tried Claude Sonnet as the underlying model.

Execution permission was not decision-making authority. Copilot could edit files and run checks within an approved task, but requirements, design decisions and final acceptance remained with me.

The initial website design shows why that mattered. A technically functional, newspaper-inspired prototype didn't match what I wanted for a product-focused professional site.

An early Astro exploration. A working page wasn't yet an accepted design.

Sharing concrete design references and explaining what I valued in them gave Copilot a more useful direction than another series of adjectives. I then refined navigation, content and visual details against that direction.

The later product-focused design, after further review and iteration.

From implementation to a production-ready website

I rebuilt the site incrementally, reviewing individual pages and features before moving on. Preparing it for publication meant checking not only the pages and language switching, but also what the build would actually deploy.

Astro produces static HTML, CSS, JavaScript and other assets during the build. That made two hosting options worth considering: GitHub Pages, which could serve the generated website from the GitHub ecosystem, and Azure Static Web Apps, a separate static-hosting service with deployment integration. Both were viable for a site without a backend. I chose Azure Static Web Apps, partly because I wanted to explore that platform as part of the modernization.

The distinction between GitHub and GitHub Pages is worth making here. I used GitHub to store the source code and GitHub Actions to run verification and deployment; choosing Azure meant that the generated website itself was hosted on Azure, not GitHub Pages.

I also learned to pay attention to the boundary between repository content and public output. The old ASP.NET Core files stayed in the repository longer than necessary, adding irrelevant context for Copilot. And although Astro generated only the static site for deployment, I still needed to check that repository instructions, scripts, drafts and other development-only files were not included in the published output.

Automated checks helped me verify routes, links, localization and generated files, while browser review remained necessary for layout and interactions.

The result was a static website that no longer required a running application server, supported by a GitHub Actions CI/CD workflow for automated verification and deployment as the site continues to grow.

Reviewing the implementation independently

Before considering the modernization complete, I asked Copilot CLI to review the implementation against the project's requirements and engineering standards. I also requested a separate, read-only review of the repository from OpenAI Codex.

The independent review raised issues worth investigating in automated verification, localization and deployment safeguards. It did not establish a critical application defect. However, the review revealed that some automated tests could pass without actually verifying the requirements they were meant to check. I used Copilot to address the findings, reran verification and sought another independent review of the corrections.

I considered adding a rubber-duck agent, whose role would have been to question assumptions and challenge the approach. At that point, however, working through the concrete review findings seemed more useful than introducing another broad review with potentially overlapping feedback.

Where the CLI was less convenient

As sessions grew longer, it became harder to find earlier decisions and compare output from multiple agents in the terminal. I enjoyed the CLI workflow, but a more visual way to navigate conversations and agent activity would have helped with complex sessions.

I also underestimated the usage cost. I started with GitHub Copilot Pro but increased my budget several times as the project progressed, even though the website itself was relatively small.

What I learned from the modernization

Modernizing yonka.dev with GitHub Copilot CLI taught me several lessons that I'll carry into future projects:

• Question familiar technology choices. Copilot's recommendation to consider Astro challenged my .NET-first thinking. Evaluating alternatives against actual product requirements led me to a solution I might otherwise have overlooked.
• Use AI throughout development, but own the decisions. Copilot helped with investigation, implementation, and verification, while architectural choices, requirements, and final acceptance remained my responsibility.
• Build incrementally and review the results. Working through manageable milestones made it easier to assess progress and adjust the direction when necessary.
• Seek independent evidence before accepting the result. Reviewing the implementation with both Copilot and Codex helped identify weaknesses that existing checks hadn't caught. Passing checks alone weren't enough to establish that important requirements were covered.

Would I use Copilot CLI again? Yes. Eleven development sessions didn't establish whether AI-assisted development was faster or cheaper than doing the work manually, but they gave me a modernized website and a better understanding of how to use coding agents effectively.

In upcoming articles, I'll explore some of the more interesting experiences in greater detail, including custom agents, automated verification and AI-assisted UI design.