Фреймворки будували для людей. То для чого вони тепер?

Кожен фреймворк, який ви знаєте, проєктувався під читача, який щойно перестав мати значення: людину, що набирає код. AI звільнив цю аудиторію. Спокуслива думка — що фреймворки тепер мертвий вантаж: якщо все пише машина, повертаймося до vanilla JS, CSS і HTML.

Ця думка хибна, бо фреймворки виконували дві роботи одночасно, а ми помічали лише одну.

Робота, яка померла

Видима робота — ергономіка. Гарний синтаксис, менше boilerplate, API, які приємно набирати. Ціле десятиліття маркетинг фреймворків крутився навколо "developer joy". JSX — щоб шаблони відчувались як код. Svelte — щоб компоненти не відчувались взагалі.

Ця робота померла. Нікому не потрібен приємний у наборі код, якщо його ніхто не набирає. Svelte оптимізувався під зручність написання людиною сильніше за всіх — а саме цей критерій щойно вийшов із гри.

Робота, яка вижила

Невидима робота — координація і верифікація. Кодова база на React має передбачувану форму. Інший розробник — або інша сесія AI через пів року — зможе в ній зорієнтуватися. Vanilla JS у масштабі означає, що кожен застосунок вигадує власну архітектуру, і тепер AI мусить щоразу реверс-інженерити чужі конвенції з нуля. Фреймворк — це стиснення контексту.

І ось що важливо про серію stateless-сесій AI: вона поводиться точнісінько як велика команда нормальних розробників без спільної пам'яті. Усе, що ми вивчили про виживання кодових баз у таких командах — строгі типи, явні контракти, один спосіб робити речі — раптом перестало бути опціональною дисципліною і стало самою суттю.

Шість речей, які тепер важать

Прогоніть будь-який фреймворк крізь цю призму — і постійно спливатимуть шість критеріїв:

1. Статична верифікованість. Чи можна перевірити коректність, не запускаючи код? AI генерує швидко, але не вміє "відчути", що щось не так. Ревʼюером має бути компілятор.
2. Локальність поведінки. Усе, що робить код, має бути видно в тексті поруч із місцем, де він написаний. Магія — отрута: AI читає файл, який ти йому показав, і якщо поведінка живе десь у конвенції, він упевнено нагалюцинує.
3. Малий контекстний слід. Скільки застосунку треба завантажити, щоб безпечно змінити один файл?
4. Маса тренувальних даних і стабільність. Нудно, але реально: моделі пишуть React краще за Svelte 5 не тому, що React кращий, а тому, що його на порядки більше, і API роками не ламався. Фреймворк із breaking changes вічно воює з пріорами моделі.
5. Машиночитні петлі зворотного звʼязку. Агентний цикл — це згенерувати → запустити → прочитати помилку → виправити. Якість повідомлень про помилки колись була DX. Тепер це буквально канал сприйняття AI.
6. Один спосіб робити речі. Якщо фреймворк благословляє пʼять ідіом, AI використає всі пʼять у твоїй кодовій базі — по одній на сесію.

Зверніть увагу, чого немає в списку: елегантного синтаксису, лаконічних API, задоволення.

Короткий тур по руїнах

JS. React + TypeScript оцінюється несподівано добре — якщо прибрати Next.js, який побудований на магії файлових конвенцій і винагороджує hydration-помилками, які ніхто не вміє читати. Angular — темна конячка: його DI-магія шкодить локальності, але цю магію хоча б перевіряє компілятор, а "один благословенний шлях" вартий багато, коли код торкають сто stateless-сесій. Vue не бʼє React за жодним критерієм і благословляє два офіційні стилі API, тож моделі радісно їх змішують. Svelte — повчальна історія: чудовий дизайн, крихітний корпус, а розрив 4→5 означає, що AI досі впевнено пише торішній синтаксис.

Python. FastAPI і Django — дзеркальні відображення. Django виграє минулим: колосальна маса тренувальних даних, API настільки стабільний, що код 2015 року досі працює. FastAPI виграє теперішнім: Pydantic робить типи несучою конструкцією, помилки валідації точні й машиночитні, звʼязування явно видно в сигнатурі функції. Greenfield, де основний автор — AI: FastAPI, і навіть не близько.

Go. Тут фреймворк майже не має значення, бо шість критеріїв уже забезпечує мова: статичні типи, gofmt, явні помилки, обіцянка сумісності Go 1 — тренувальні дані, які ніколи не гниють. stdlib net/http плюс chi — мабуть, найбільш AI-нативний бекенд-стек із наявних, і дійшов він туди випадково, оптимізуючись під великі команди в Google без спільного контексту. Та сама форма проблеми.

CSS — крайній випадок. У CSS найгірша з можливих властивостей для AI: він не вміє падати голосно. Невалідна властивість — мовчки проігнорована. Селектор нічого не матчить — тиша. Агентний цикл ламається на кроці "прочитати помилку", бо помилки немає. А каскад — це буквально дія на відстані як принцип дизайну. BEM і компанія — це люди, які вигадували дисциплінарні конвенції, щоб симулювати скоупінг, якого в мові не було.

Тому Tailwind — випадковий чемпіон. Роками його висміювали як "inline styles with extra steps" — критика була про читабельність і DRY, обидві — про людський набір тексту. Саме ті властивості, за які його висміювали (усе видно в елементі, ніякого каскаду, фіксований словник токенів), тепер і важать. Tailwind — не так абстракція над CSS, як фаєрвол проти нього.

Одне уточнення заради точності: Tailwind — це один представник класу, атомарного CSS з обмеженим токенами словником. Panda CSS і StyleX архітектурно кращі (типізовані токени, помилки на етапі компіляції) і практично гірші, бо їхній корпус — похибка округлення поруч із Tailwind. Та сама форма, що Svelte проти React: правильний дизайн, не та маса даних.

Куди це все приземляється

Поріг "просто пиши vanilla" справді піднявся. Маленькі тули, внутрішні дашборди, одноразові сторінки — AI миттєво пише пристойний vanilla, і пропустити build-крок — реальний виграш. Але для всього, що має стан і горизонт підтримки, логіка веде рівно в протилежний бік.

Фреймворки нікуди не зникають. Вони змінюють аудиторію. Двадцять років вони оптимізувалися під людину, яка пише код. Тепер їм треба оптимізуватися під машину, яка пише, і людину, яка перевіряє — а це означає: нудно, явно, статично перевірювано, стабільно. Властивості, які роблять фреймворк добрим для AI, — рівно ті, що робили його добрим для великої посередньої команди. Тут немає жодної нової чесноти. Це стара дисципліна, яка перестала бути опціональною.

Фреймворки перестають бути інструментами, щоб менше думати, і стають контрактами, щоб більше перевіряти. Виживуть не ті, з якими приємно набирати код. Виживуть ті, з якими коректність можна перевірити.

І найсильніші кандидати взагалі не проєктувалися під AI. Їх проєктували під другого найгіршого читача коду, якого ми знали: колегу без контексту. Виявляється, ми весь цей час тренувалися саме до цього.