An underrated usage for coding agents that I’m enjoying at the moment is migrating old static sites to later framework versions. Specifically for me that’s been two Astro sites that have been wallowing down at version 1.5 and updating them to the latest shiny v7. One of them is the very blog your on now.
Maybe I should update to Astro v7, let's check what am I currently running?
Oh no:
— Ian Wootten 🛸 ([https://bsky.app/profile/did:plc:backvnj6l2uozas5mtjigh7k/post/3mpjty4s7e22b?ref_src=embed">[image]or embed][https://bsky.app/profile/did:plc:backvnj6l2uozas5mtjigh7k?ref_src=embed">@ianwootten.co.uk])[https://bsky.app/profile/did:plc:backvnj6l2uozas5mtjigh7k/post/3mpjty4s7e22b?ref_src=embed">30]June 2026 at 21:33
My workflow was simple - start a new project in v7, copy across the content and get Opencode to figure out what API changes happened in Astro to make it work as before. In the case of my blog that specifically meant getting a whole host of routes to work again, including all category, tag, pagination and index pages for months and years. This place has been around since when wordpress was launched and originally ran on cafelog!
Handily, when creating a new Astro project now, it places an AGENTS.md in the project root to assist. Opencode figured out that my routes would need to be updated to use the content collection API introduced in 2.0.0. This alone was the bulk of the work and cleaned up a whole host of custom methods I originally had to fetch posts.
This is something that I likely wouldn’t have attempted without an agent because it’s never a priority, unfulfilling and probably a major time investment. I could always continue generating site builds in the older version until it completely failed. Now instead of dedicating hours to migrate each site, or worrying as it got further from latest I can focus on other tasks such as improving the design or optimising a deployment workflow.