Kyle Skrinak
Go back

AI-Assisted Modernization: Two Days, Ten Years Strong

ai modernization workflow

I have had my personal blog for many years now. It will be 10 years old next October. They grow up so fast, don’t they? What started as a way to share my thoughts, wins, and work notes has now become a “skin in the game” playground for me. Since my blog started its life. I have hosted it entirely in the cloud (minus local dev), which lets me practice for my own professional edification.

A playful “what if” session with VS Code’s integrated Copilot turned into mowing down long-standing issues in minutes. At my prompt, Copilot analyzed my repo and, in short order, generated a proposal for changes I have long put on hold. Examples include security hardening, modernized asset management, and gaps in workflow documentation. What followed was a 48-hour back-and-forth, condensing what would have been two weeks of evenings into two winter-break days. So, as per my learning preferences, I am sharing this experience as part of my learning process. I hope sharing my experience will help anyone evaluating whether these tools are worth the investment, even if just to play and see.

My changes, by the numbers (right from Copilot)

What I learned from all this

  1. Documentation is a necessary guardrail. The novelty and ease of natural-language interaction lead to a false sense of “memory and intuition.” Without a persistent context, the AI will re-analyze the same situation differently. My learning: Lead with your documentation. Keep workflow docs up to date and ensure I always reference them in prompts. Here is where I keep my work instructions for this blog.

  2. Hallucinations remain a critical issue. Roughly 1 in 3 prompts were problematic: confusing staging vs. main, implying I had completed the MM4 upgrade, trying to create blog files outside the documented workflow, ignoring that Reveal.js was already self-hosted, and even honoring an errant note I’d included about “.htmlproofer.yml.” Newsflash - you can become the parent of your own project’s hallucinations. Mitigation: always human-in-the-loop—review → approve/reject → execute.

  3. Effective prompting requires specificity. Specific prompts (exact colors, exact branches/SHAs, exact files/paths) reduce errors. When the AI gets it wrong, it often exposes vagueness in my own thinking. Now I use AI as a call-and-response stress test for clarity: if I can’t explain it precisely enough for an AI to understand, my phrasing probably isn’t clear enough for humans either.

  4. Verify all suggested actions. Never blind-trust AI output. Read commands, understand consequences, check diffs, run local builds, run tests, and confirm alignment with the workflow. Remember that you’re gaining a large amount of time. Skipping this (because you’re lulled into complacency) invites unresolvable complexity later on.

  5. The productivity multiplier is real. Two weeks compressed into two days. AI handled diffs, log analysis, boilerplate docs/scripts, and pattern recognition; I focused on real-time prompt decisions and verifying the results.

  6. AI helps best at scale—cohesion is human. AI can juggle best practices, assets, tests, docs, branch rules, and CSS precedence. Deciding what fits and what to reject is human work. Without that, the train goes off the rails.

Conclusion: New life in my Jekyll + Minimal Mistakes stack

I no longer wonder whether to migrate to faster/newer stacks (Hugo, Eleventy, etc.). The refactor gave my stack a new lease on life: reliable asset vendoring, far more complete documentation, visual regression testing for Reveal pages, and tighter theme integration. I’m sticking with this stack. It’s funny how radical and unexpected this all is—but I like it.

Hrm. I wonder if there’s a better way to manage Jekyll assets and serve device-dependent images? Stay tuned.

Epilogue: Post-Publication QA & Polish (2026-01-02)

After publishing to my local environment, I smelled a rat and found more snakes under the rocks. Did I inadvertantly change my visuals with the CSS update? Is my front matter correct across all my posts? Do I have a documentation on what front matter should be, and is it layout sensitive?

So, curious, I continued on with iterating visual fidelity and testing infrastructure:

Note: I asked Copilot to summarize the subsequent QA changes. Everything below is from Copilot’s chat thread.

Visual Regression Enhancements

Pixel-Perfect Local/Production Parity:

Interactive QA Tool:

Sitemap & Artifact Cleanup

Removed Non-Public Assets from Sitemap:

Playwright Artifact Consolidation:

Documentation & Workflow

README.md enhancements:

CHANGELOG.md expansion:

.github/CONTRIBUTING.md updates:

Changes Unpublished

Final Validation

All test suites pass with zero warnings:

Addendum: I used GitHub Copilot to help me draft portions of this post—for structure, phrasing, and technical articulation.

Share this post on:
Share this post via WhatsApp Share this post on Facebook Share this post on X Share this post via Telegram Share this post on Pinterest Share this post via email
Next Post
Modernizing an Old Jekyll Blog with GitHub Actions and AI