I was responsible for running the Boring AI Hackathon. Throughout this case study, I'll walk through what my team and I learned from managing 100+ participants to scoring 43 codemods and spotting a clear pattern in the results.
Most developers enjoy building new features. The part that nobody talks about is everything that comes after. Maintenance, upgrades, migrations. That work takes a lot of time and quietly slows teams down.
The goal was to build a competitive space where developers could learn Codemod's open source technology, compete with peers, and contribute to real SDKs instead of toy projects. Rather than building apps or AI wrappers, participants picked actual migrations such as dependency upgrades, framework changes, and API updates, then tried to automate as much of that work as possible.
The main focus was making migrations predictable and fast. Codemods handled the clear, repetitive changes. AI handled the messy parts that are harder to fully automate.
When more than 100 people sign up, the support load adds up fast. The first few days are quiet. Then sign-ups pick up, and so does the message volume.
People ask about setup, rules, and what counts as a valid submission. Sometimes they ask the same question in five different ways. Getting everyone the right information so they could actually execute was a constant job throughout the event.
Going into the review, I thought it would be simple. It was not. Some submissions showed real care: proper tests, clean logic, thought put into edge cases. Others looked like a single AI prompt that nobody bothered to read before submitting.
Reviewing that many codemods back to back gave a clear picture of how different tools shape the way people think about migrations. You could see how each approach breaks down code changes and tries to turn a messy real-world upgrade into something structured.
A tale of codemod toolkits.
Some participants used external frameworks like jscodeshift or LibCST despite the hackathon guidelines encouraging JSSG. The Codemod platform can technically support other frameworks, but we provide first-class support for JSSG and recommend it by default. We only suggest reaching for other toolkits when JSSG clearly falls short for a specific case and the gap cannot be filled by adding to JSSG itself. You can read about how JSSG differs from other toolkits here.
Compared to jscodeshift or LibCST, which can feel manual and hard to scale on large codebases, JSSG is built with migrations in mind from the start. It gives a clearer way to express patterns, apply changes safely, and handle complex real-world scenarios without things getting messy.
Most participants were students working alone. There were experienced developers too, but the majority came in with fresh eyes.
Because the hackathon ran on DoraHacks, submissions leaned heavily toward web3. Most codemods tackled ethers.js, wagmi, or Solana migrations. That context matters when reading the results.
We calculated results based on a formula and scored submissions out of 100.
After going through 43 codemods, the thing that stayed with me wasn't really the scores. It was how much you could tell about someone's whole approach just from the tool they picked. The jscodeshift submissions often felt like the person was figuring things out as they built. The JSSG ones just felt cleaner and more thought through.
