Evil Martians cleared its three-year-old Gatsby migration in two weeks with Claude

The reason this sat for three years is in the shape of the deliverable. Evil Martians wrote that the output of a successful migration is no visible change, and that this makes it the hardest possible thing to fund. That is why teams keep running production on frameworks they would not choose today ^[14]. The site is how new clients find the consultancy, and it serves technical articles to half a million developers ^[1]. The internal case still lost, because the honest pitch was engineers pulled off client projects for potentially months in exchange for a site that looks exactly the same ^[15].

Irina Nazarova, the consultancy's CEO, put the staffing side plainly. "We're a consultancy, so client work comes first, and the site has never had a proper team," she said, describing one engineer who knows it end-to-end plus occasional help ^[16]. "But it cannot absorb a framework migration since that's really the kind of work that can't be handed off half-finished to whoever's free next," she said ^[17].

Evil Martians split the job in two. The small pile was design: what replaces GraphQL, what hydrates in the browser, how content gets compiled. The large pile was mechanical, moving the build from Webpack to Vite, replacing plugins, migrating page skeletons, and restating the same behavior in a different framework's idiom several hundred times without drift ^[12]. The first of three preparatory steps was choosing a framework that would minimize migration risk ^[18]. The company's condition on handing the mechanical pile to a model is specific: someone has to state precisely what "the same behavior" means and test it ^[19].

The diff gives the scale. Between the first Astro commit and the cutover it covered 470 files, with 30,403 lines added and 32,061 removed ^[11]. Add them and you get 62,464 lines touched, and the codebase came out 1,658 lines smaller than it went in ^[20][21].

Evil Martians put the before and after as "a team spending 2-3 months engaged" against "the one engineer who already knows the codebase, spending a couple of weeks" ^[22]. On calendar time that is a factor of roughly four to six and a half ^[23]. In person-hours it is larger, and the post does not give the size of the team it avoided staffing. Its headline puts the work at under 9 3/4 days; the text says two weeks ^[24][3].

This is the friendliest test case available: a consultancy's own marketing site, no payments and no regulated data, and an acceptance criterion of nothing visible changing. It also understates what deferral cost. A pnpm audit against the last Gatsby lockfile reported 19 advisories, 13 of them rated high, and closing one in practice meant forcing a newer version through a pnpm override by hand, adding another patch to a dependency combination the framework was never tested against ^[8][9]. Seventeen Gatsby plugins sat in package.json, and four dependencies needed hand-written patches to behave ^[6][7]. A cold production build took 18 minutes, and because Gatsby generated every responsive image variant at build time, fixing a typo cost the same 18 minutes as a redesign ^[10].

Four bugs would have shipped had the agent run wild, by the company's own account ^[13]. It does not say which four. Every hour the model saved came off the mechanical pile; the specification and the review stayed with the one engineer who could say what sameness meant. For a CTO with a specific repo in mind, the question this quarter is whether that repo still has such an engineer, because the two weeks here were bought on top of his knowledge of the old codebase.