How Atolio Migrated Svelte 4 to 5 Using Claude Code | Atolio
Security
Resources
Company
Book a Demo
Read about how we’re supporting the
U.S. Air Force →
×
A UI Framework Migration in the Age of AI: How We Migrated Svelte 4 to 5 with Claude Code in Six Hours<br>Pablo Arellano<br>Software Developer
Update:<br>June 2026
Summary: Atolio's engineering team migrated thousands of files from Svelte 4 to Svelte 5 using Claude Code. Months of human investigation produced a prompt detailed enough to let the agent run in auto mode for six hours on a Friday afternoon. Two days of QA surfaced one bug. The thinking happened first; the AI did the heavy lifting.<br>At Atolio, we use Svelte as our main UI framework. Svelte is compiler-first, unlike React (the most popular option, and technically a library), which works at runtime, meaning Svelte compiles components directly into highly optimized vanilla JavaScript. For those who are not too familiar with frontend development, you can think of Svelte as a set of ready-made building blocks that let you create a UI without starting everything from scratch. We think Svelte is a better fit for our case than React, though that is a topic for another day.<br>Why migrate from Svelte 4 to Svelte 5?<br>Choosing a newer framework comes with its own adventures, like updates that require major migrations. In our case, migrating from Svelte 4 to Svelte 5, which introduced some big paradigm changes, meant updating thousands of files while making sure everything went smoothly. This takes a whole project and a dedicated team of developers, all while you continue building new features.<br>So how do we optimize this process with AI?<br>How do you prepare a large codebase for AI-assisted migration?<br>The journey started with some investigation (you still need human input): checking for possible blockers and known issues, and setting up proper guardrails so the AI did exactly what we wanted.<br>I'm not going to go into the details of the investigation and its findings, but we had several developers looking into legacy issues, dependency compatibility, compiler versions, and testing libraries, as well as updating the syntax without breaking the codebase. We also tracked updates from the main Svelte channels and even built a proof of concept (POC) of how the migration would look.<br>What guardrails kept Claude Code on task?<br>That led to our first problem: how do we centralize all these findings, gathered over months and scattered across Linear, Zulip, GitHub, Notion, and even comments in the codebase? This step was easy, thanks to Atolio. I just asked it for a summary of the findings and everything related to the Svelte migration across every channel in the company. Once it pulled everything together, it helped me create a prompt for Claude Code. This way, I only gave Claude access to the code, not to our internal systems. That was the first guardrail: use data found by humans to improve the chances of getting the work done properly.<br>Our second guardrail came from a culture that strongly believes in thorough testing. Because of that, we could provide examples and feel more confident that the changes wouldn't break the UI.<br>So with good investigation, data to support it, clear goals, and examples for the AI to follow, we were able to write a prompt that contained everything we needed. People sometimes think of prompts as small conversations with AI, but anyone who has used it for a while knows that a good prompt takes investigation, careful work, and all the context the AI needs to do the job. Our job as engineers is to make sure the AI is going to do the right work before it does it. The more time you spend on the prompt, the less time you spend fixing what the AI got wrong.<br>What were the actual results?<br>So with a prompt we felt was good enough, we went to Claude Code and fed it in plan mode. It is important to read the plan thoroughly and make sure the AI (call it the agent, Claude, or any AI tool) is planning to do what you actually want. Once that checked out, the magic began: we let it run in auto mode for around six hours on a Friday afternoon.<br>After that, it took about two days and two developers to fix warnings and run QA before deploying to a testing environment. Once it was in testing, the team found only one bug during QA. And after months of preparation, watching a migration of thousands of files come down to a single bug is the kind of result that makes the whole approach worth it.<br>That result wasn't magic. Getting AI to do what it's supposed to do takes real knowledge on your part, and sometimes specialization, preparation, and investigation work, along with guardrails and good practices for the AI to follow. The AI did the heavy lifting, but only because humans did the thinking first.
Pablo Arellano<br>Software Developer
Update:<br>June 2026
Get the answers you need from your enterprise. Safely.<br>Experience how AI-powered enterprise search can transform your organization's knowledge management and unlock...