Миграции и ИИ: почему аргументы важнее модных трендов

Почему миграции стали трендом и что за этим стоит

Недавно Cursor объявил о миграции с SolidJS на React, а в документации Anthropic появился пример массовой миграции, основанный на этом опыте. Это задело меня лично, ведь я работаю над Solid 2.0. Но главное — это симптом более глубокой проблемы: индустрия всё чаще транслирует готовые выводы вместо аргументов. В этой статье разберём, почему так происходит, как отличить обоснованное решение от модного веяния и что это значит для разработчиков.

Как ИИ изменил стоимость миграций

Раньше миграция с одного фреймворка на другой требовала месяцев или лет работы. Теперь, благодаря ИИ-агентам, стоимость исполнения резко упала. Например, Bun переписал около миллиона строк кода с Zig на Rust всего за несколько дней с помощью Claude. Это открывает двери для экспериментов, но одновременно создаёт риск: когда миграция становится дешёвой, решения принимаются на основе трендов, а не технических обоснований.

Пример: миграция Cognition с Astro на Next.js

Компания Cognition мигрировала свой маркетинговый сайт с Astro на Next.js, и этот процесс выполнил ИИ-агент Devin. Результат опубликован как кейс, но без бенчмарков и детального анализа. Это типичный пример «вердикта» — решения, поданного как факт, но без аргументации. Такие истории сейчас повсюду, и они формируют повестку.

Что такое настоящий аргумент в технике

Настоящий аргумент — это публичное обоснование с фактами, цифрами и возможностью оспорить. Например, когда Bun перешёл с Zig на Rust, Джарред Самнер публично объяснил причины: проблемы с управлением памятью и классами багов. Сообщество смогло это обсудить, проверить и даже оспорить. Такой подход позволяет развиваться, а не просто следовать моде.

Кейс TanStack: публичный анализ вместо вердикта

TanStack внедрил React Server Components на своём сайте, затем отказался от них, но в обоих случаях опубликовал подробные отчёты: что изменилось, почему и какие компромиссы. Такая публичная рефлексия — пример того, как анализ помогает принимать взвешенные решения и двигать индустрию вперёд.

Почему Cursor ушёл с Solid на React: реконструкция

Cursor не опубликовал детального обоснования, но из их поста можно выделить два фактора: объём и верификация. ИИ-агенты плохо пишут на Solid, потому что их обучающие данные перекошены в сторону React. Миграция на React увеличивает объём данных, а переход с Tailwind на StyleX добавляет верификацию: ошибки стилей ловятся на этапе сборки. Это интересный пример, когда анализ можно реконструировать, но без исходных данных он остаётся гипотезой.

Что будет, если ничего не менять

Если мы продолжим слепо следовать трендам, индустрия скатится к монокультуре: React во фронтенде, Rust в системном программировании, Python в скриптах. Это опасно даже для React, потому что конкуренция — двигатель инноваций. Без давления извне экосистема застаивается. Чтобы избежать этого, команды должны публиковать анализ, а не просто вердикты, а мы — учиться отличать одно от другого.

Практический вывод: как принимать решения о миграции

Прежде чем мигрировать, задайте себе три вопроса:

• Есть ли публичный анализ с цифрами, а не просто мнение?
• Какие альтернативы вы рассматривали и почему их отвергли?
• Как вы будете измерять успех после миграции?

Начните с малого: задокументируйте своё текущее решение, проведите бенчмарки, а затем принимайте взвешенный выбор. Не поддавайтесь давлению трендов — ищите аргументы.

Пример кода: как сравнить два подхода

# Сравнение производительности: React vs Solid
import time

def measure(fn, iterations=1000):
    start = time.perf_counter()
    for _ in range(iterations):
        fn()
    return time.perf_counter() - start

# Пример: рендер списка
items = list(range(1000))

def render_react():
    # Имитация React-рендера
    return [f"
{i}
" for i in items]

def render_solid():
    # Имитация Solid-рендера
    return [f"
{i}
" for i in items]

print(f"React: {measure(render_react):.4f} сек")
print(f"Solid: {measure(render_solid):.4f} сек")

Этот код не даёт ответа, но показывает, как можно начать измерять. Важно — не доверять чужим вердиктам, а проверять на своих данных.