Для систем на годы фреймворки по-прежнему оправданны
В споре о vibe coding frameworks мой ответ для сложных систем с долгим сроком жизни - да, фреймворки нужны. ИИ может сократить работу над кодом. Но тестирование, исправление ошибок, обновление зависимостей и поддержка результата по-прежнему требуют времени и внимания.
Я Андрей Попов, технический директор и сооснователь Webdelo. Это мой взгляд, основанный на работе нашей команды над сложным ПО. Это инженерная оценка, а не правило, доказанное для любого проекта.
Вайб-кодинг - это когда вы описываете задачу обычными словами, а ИИ-агент пишет код. Фреймворк - готовая основа приложения с общими правилами. Зрелую основу вроде Laravel, Spring Boot или Django нужно оценивать иначе, чем небольшой пакет для подключения к одному внешнему сервису.
ИИ сокращает набор кода, но ответственность остаётся
Довод против фреймворков прост: если агент может сгенерировать код, зачем принимать чужие правила? Этот довод касается первой версии. Нас же волнует, что произойдёт, когда программа изменится или сломается.
Фреймворки избавляют от повторяющейся работы, и ИИ уменьшает эту выгоду. Но кто-то всё равно должен проверить результат и объяснить его следующему инженеру. При разработке сайтов мы учитываем передачу проекта и будущие изменения, когда выбираем основу.
Кроме того, словом "фреймворк" называют инструменты с разными задачами:
- Серверные фреймворки, такие как Laravel, Spring Boot и Django, организуют логику приложения и доступ к данным.
- Инструменты для интерфейсов, такие как Vue.js и Next.js, помогают создавать части приложения, с которыми работают пользователи.
- Go Fx связывает компоненты приложения и управляет их запуском и остановкой.
- Библиотеки выполняют более узкие функции, к которым приложение обращается по мере необходимости.
- SDK - наборы готовых инструментов для работы с внешним API, интерфейсом, через который системы обмениваются запросами и ответами.
- Агентные фреймворки координируют ИИ-модели, инструменты и шаги рабочего процесса.
Причина отказаться от одного небольшого SDK - не повод отказываться от фреймворка для всего приложения.
Зрелые фреймворки дают ИИ-агентам знакомую структуру
При разработке с ИИ зрелые фреймворки дают команде и агенту готовые компоненты, документацию и средства диагностики. Это позволяет уделить больше внимания бизнес-правилам. По нашему опыту, такая структура особенно полезна, когда приложение нужно поддерживать годами.
Готовые компоненты и общие правила
Серверные фреймворки и их экосистемы решают типовые задачи:
- Направляют входящий запрос нужному коду.
- Читают и записывают данные в базе данных.
- Проверяют отправленные данные.
- Управляют пользователями и правами доступа.
- Запускают фоновые задачи через очереди.
Crm система помогает управлять отношениями с клиентами. Правила распределения клиентов могут быть уникальными для бизнеса. Но базовые механизмы приёма запросов и проверки входных данных обычно не нужно проектировать заново.
Общие соглашения также показывают агенту, где нужно внести изменение. Инженер, знакомый с Django или Laravel, уже примерно понимает, как устроен проект. В самописной основе сначала придётся разобраться.
Документация помогает людям и агентам
Официальная документация и подробные примеры дают агенту полезные ориентиры. Обсуждения в сообществе также могут объяснить известные причины сбоев. Если основа самописная, команде приходится самой собирать и обновлять больше таких знаний.
Популярные фреймворки открыто проверяют и исправляют. Однако популярность не гарантирует безопасность. За правильную настройку и своевременные обновления по-прежнему отвечает команда.
Готовые компоненты также могут сократить объём кода, который генерирует агент, и расход токенов. Я считаю это возможностью для отдельных задач, а не измеренной экономией.
Диагностика важна, когда что-то ломается
Разобраться в сбое фоновой задачи проще, когда инструменты уже есть. Зрелые экосистемы предлагают удобные средства для изучения работы приложения:
- Laravel Horizon отслеживает очереди задач на базе Redis.
- Laravel Telescope помогает изучать запросы, ошибки и обращения к базе данных.
- Spring Boot Actuator предоставляет проверки работоспособности приложения и метрики.
Uber Fx решает другую задачу. Он управляет зависимостями компонентов и их жизненным циклом в Go. Он задаёт структуру, а не заменяет эти средства мониторинга.
Для нас эти инструменты особенно важны при сбоях в рабочей системе. Это неподходящий момент, чтобы начинать создавать средства наблюдения за приложением.
Вайб-кодинг без фреймворков подходит для небольших, чётких задач
Вайб-кодинг без фреймворков имеет смысл, когда задача почти не требует инфраструктуры. Разовый скрипт или небольшую утилиту бывает проще понимать и поддерживать в виде минимальной программы. Крупный фреймворк может добавить больше работы, чем сэкономить.
Например, скрипту для преобразования локального CSV-файла в другой формат может хватить стандартной библиотеки. Фреймворк приложения потребует настройки и обновлений, но не поможет решить задачу.
Я бы сравнивал затраты труда за весь срок жизни решения:
- Изучение и подключение выбранных инструментов.
- Проверка обычной работы и сбоев.
- Установка обновлений и исправлений безопасности.
- Передача кода другому инженеру.
Рекомендации Anthropic по созданию эффективных агентов тоже отдают предпочтение простым решениям из сочетаемых компонентов. Речь прежде всего о координации агентов, а не о веб-фреймворках вроде Laravel или Django. Полезный вывод - избегать слоёв, которые ничего не дают.
Если прототип становится постоянным сервисом, пересмотрите его архитектуру. У программы на один запуск и сервиса, на который клиенты полагаются каждый день, разные требования к поддержке.
Поддержку небольшого SDK нужно оценивать отдельно
SDK может сократить работу над интеграцией, но его ценность зависит от набора функций и поддержки. Пакет, который поддерживают один-два человека, может отстать от внешнего API. Тогда вашей команде придётся делать работу, которую вы рассчитывали поручить пакету.
Перед выбором SDK я бы проверил следующие тревожные признаки:
- Долгие перерывы между обновлениями, хотя API продолжает меняться.
- Отсутствие методов, нужных продукту.
- Слабые тесты, особенно для ошибок.
- Скрытые детали запросов или ответов, нужные для отладки.
- Устройство пакета, которое вынуждает вносить неудобные изменения в другие части приложения.
При выборе между SDK и собственной интеграцией с API ИИ меняет начальные затраты на создание узкоспециализированного клиента. Слабый пакет больше не выигрывает лишь потому, что уже существует. Но SDK с хорошей поддержкой всё ещё может быть лучшим выбором.
Binance и Bitget показали нам разную стоимость поддержки
Мы поддерживаем высоконагруженную платформу для алгоритмической торговли и анализа рынка. Сторонний SDK для Binance помог нам начать, а затем стал кодом, который пришлось поддерживать самим. Для Bitget мы с помощью ИИ-агентов создали собственный клиент с узким набором функций.
Это опыт нашей команды с конкретными интеграциями. Это не внешний аудит бирж и не оценка всех доступных для них SDK.
Binance: от готового пакета к своему форку
Пакет для Binance уже поддерживал функции, которые понадобились нам вначале. Это сэкономило работу на старте.
Позже он отстал от API, и в нём не хватало нужных методов. Его структура также мешала нам организовать интеграцию так, как мы хотели. Мы создали форк - собственную копию пакета, которую могли менять.
Теперь нам пришлось расширять и поддерживать чужой код. Первоначальная экономия превратилась в технический долг: решение, из-за которого последующие изменения стали дороже. Этот вывод касается конкретного пакета в конкретном проекте.
Bitget: узкоспециализированный клиент, созданный с агентами
Для Bitget мы выбрали собственный клиент. Агенты опирались на документацию API и проверяли поведение сервиса:
- Выполняли реальные запросы и запросы в тестовой среде.
- Проверяли тестовые операции.
- Тестировали WebSocket-соединения, которые остаются открытыми для постоянного получения обновлений.
- Записывали различия между документацией и фактическим поведением в README и отчёт.
По моей оценке, рабочая основа была готова примерно за один рабочий день. У API были подробная документация и тестовая среда. Мы также ограничили набор нужных функций.
Этот срок относится только к нашему проекту. Результат первого дня ещё требовал тестирования и доработок для надёжной обработки сбоев.
За что мы по-прежнему отвечаем
Собственный клиент позволяет нам управлять его устройством. Но ответственность за каждый сценарий сбоя тоже остаётся на нас:
- Обработка ошибок: решить, что делать, если запрос завершился ошибкой или пришёл неожиданный ответ.
- Повторные запросы и идемпотентность: убедиться, что повторный запрос не выполнит одну операцию дважды.
- Ограничения запросов: не превышать разрешённую биржей частоту запросов.
- Восстановление соединения: подключаться заново после обрыва и проверять, не пропущены ли обновления.
- Защита ключей: не допускать попадания учётных данных в исходный код и журналы.
- Тестирование и поддержка: проверять изменения по мере развития API и нашего приложения.
Исследования разработки с ИИ дают контекст, но не решают вопрос о фреймворках
Исследования ниже не дают прямого ответа на вопрос о фреймворках. Они показывают, что эффект ИИ зависит от задачи и инструментов, а сгенерированный код нужно проверять. Моя оценка архитектуры - отдельное суждение, а не результат этих исследований.
Скорость зависит от условий
В эксперименте METR 2025 года 16 опытных разработчиков выполнили 246 задач в зрелых проектах с открытым исходным кодом. С ИИ-инструментами начала 2025 года они потратили на 19% больше времени. Этот результат описывает конкретные условия, а не всех разработчиков.
Обновление METR за 2026 год рассматривает смещение выборки: состав участников эксперимента и выбранные ими задачи могут исказить результат. Исследователи считают, что новые инструменты, вероятно, полезнее. Они также объясняют, почему надёжно измерить текущий эффект сложно.
Эксперимент Google с 96 инженерами дал оценку сокращения времени на задачи примерно на 21% в конкретных условиях компании. У этой оценки была значительная неопределённость. Нет единого показателя продуктивности с ИИ, который подскажет, какую архитектуру выбрать.
Доверие и безопасность требуют проверок
В опросе разработчиков Stack Overflow за 2025 год около 66% ответивших на вопрос о разочарованиях при работе с ИИ выбрали ответы, которые "почти верны, но не совсем". В вопросе о точности 46% не доверяли результатам ИИ, а 33% доверяли. Это ответы на разные вопросы, а не измерения качества кода.
Для сравнения с опросом за 2026 год нужно сопоставлять формулировки вопросов и группы респондентов. Доверие к ответу, который легко проверить, отличается от общего доверия к точности.
Компания в сфере безопасности Veracode сообщила о небезопасных результатах примерно в 45% выбранных ею задач на генерацию кода. Задачи проверяли сценарии, в которых безопасность особенно важна. Эта цифра не означает, что 45% всего ПО, созданного с ИИ, небезопасно.
Мой практический вывод - не писать без необходимости собственный код для задач, связанных с безопасностью. Использование поддерживаемых компонентов сокращает объём нового кода, который нам нужно проверить. При этом тестирование безопасности самого приложения остаётся обязательным.
Сохраняйте структуру и проверяйте, нужны ли лишние слои
Кейс OpenAI Harness engineering описывает разработку силами агентов, которым помогают чёткие архитектурные границы и документация. В нём также подчёркивается роль автоматических проверок, метрик и средств наблюдения за системой. Это опыт одной компании, а не сравнение веб-фреймворков.
Я вижу общий принцип в этом кейсе и рекомендациях Anthropic: дайте агентам понятные правила и избегайте ненужных слоёв. Зрелые фреймворки могут дать такие правила. Но команде всё равно нужно решить, какие части действительно нужны проекту.
Фреймворк или собственный код: оцените сложность и поддержку
Я начинаю с двух вопросов: насколько сложна система и насколько она должна учитывать особые требования? Затем оцениваю стоимость поддержки. ИИ меняет затраты на разработку, но не принимает это решение за нас.
| Ситуация | С чего можно начать | Что проверить в первую очередь |
|---|---|---|
| Сложная система с долгим сроком жизни и типовыми задачами приложения | Зрелый фреймворк | Подходит ли его структура продукту и команде поддержки? |
| Сложная система с особыми бизнес-правилами или интеграциями | Гибрид: зрелая основа и собственные компоненты | Можно ли чётко отделить собственные части? |
| Простая разовая задача | Минимальная программа или небольшая библиотека | Останется ли задача в прежних границах? |
| Узкая интеграция с хорошей документацией, тестовой средой и слабым SDK | Небольшой собственный клиент | Кто отвечает за обработку сбоев, безопасность и обновления API? |
Для сложных B2B-систем мы часто предпочитаем гибридный подход. Мы сохраняем зрелую основу приложения, а отдельные интеграции создаём сами. Подходящая библиотека или SDK тоже может решить эти задачи.
Эта матрица - ориентир, а не правило. Проверяйте конкретный пакет и API. Для криптографии и критически важной инфраструктуры используйте проверенные реализации, а не просите агента придумать замену.
В нашей веб студии этот выбор - часть планирования долгосрочной поддержки. Полезный вопрос напоследок: кто будет понимать и поддерживать этот код через два года?
Выбирайте основу, которую сможете поддерживать
Для сложного ПО я по-прежнему предпочитаю зрелые фреймворки с небольшими собственными компонентами там, где они оправданны. Для скрипта с чёткими границами задачи - минимальное решение. Главное - сколько работы потребует поддержка после запуска первой версии.
Обсудите с Webdelo архитектуру и долгосрочную поддержку ПО, от которого зависит ваш бизнес.
Часто задаваемые вопросы
Нужны ли фреймворки при вайб-кодинге?
Для сложных систем с долгим сроком жизни - да. ИИ сокращает работу над кодом, но тестирование, исправление ошибок, обновление зависимостей и поддержка по-прежнему требуют времени. Зрелый фреймворк вроде Laravel, Spring Boot или Django даёт команде и ИИ-агенту готовые компоненты, документацию и средства диагностики. Это мнение CTO Webdelo Андрея Попова, а не правило, доказанное для каждого проекта.
Что такое вайб-кодинг и что такое фреймворк?
Вайб-кодинг - это когда вы описываете задачу простыми словами, а код пишет ИИ-агент. Фреймворк - готовая основа для приложения с общими правилами его устройства. Серверные фреймворки, такие как Laravel, Spring Boot и Django, закрывают типовые задачи: направляют запросы к нужному коду, работают с базой данных, проверяют входные данные, управляют пользователями и запускают фоновые задачи.
Когда вайб-кодинг без фреймворков оправдан?
Он подходит для небольших, чётко ограниченных задач, которым почти не нужна инфраструктура. Разовому скрипту, который переводит локальный CSV-файл в другой формат, может хватить стандартной библиотеки. Большой фреймворк добавит настройку и обновления, но задаче не поможет. Если прототип позже станет постоянным сервисом, архитектуру стоит пересмотреть.
Как выбрать между сторонним SDK и собственным клиентом для API?
Проверьте, как SDK поддерживается и покрывает ли он ваши задачи. Тревожные признаки: долгие перерывы между обновлениями, нехватка нужных методов, слабые тесты, скрытые детали запросов и устройство, которое заставляет неудобно менять остальное приложение. Если SDK слабый, а у API хорошая документация и тестовая среда, небольшой собственный клиент, написанный с ИИ-агентами, может оказаться лучше. Но хорошо поддерживаемый SDK по-прежнему может быть правильным выбором.
Чему Webdelo научили интеграции с Binance и Bitget?
Сторонний пакет для Binance сэкономил работу на старте, но потом отстал от API, и в нём не хватало нужных методов. Команде Webdelo пришлось сделать форк и самой поддерживать чужой код. Для Bitget ИИ-агенты собрали узкий собственный клиент по документации, реальным и тестовым запросам и проверкам WebSocket. По оценке CTO, рабочая основа появилась примерно за один рабочий день, но это частный случай, и результат ещё требовал тестирования.
За что вы отвечаете сами, если пишете собственный клиент для API с помощью ИИ?
Вы отвечаете за каждый сценарий сбоя. Это обработка ошибок, безопасные повторы, чтобы повторный запрос не выполнил одну операцию дважды, соблюдение лимитов запросов и восстановление оборванного соединения. Ещё нужно не допускать попадания ключей в исходный код и логи и проверять клиент при изменениях API и приложения.
Почему исследования разработки с ИИ не решают вопрос о фреймворках?
Они измеряют работу ИИ в конкретных условиях, а не выбор фреймворка. В эксперименте METR 2025 года 16 опытных разработчиков с ИИ-инструментами начала 2025 года тратили на 19% больше времени. В обновлении METR 2026 года сказано, что новые инструменты, вероятно, полезнее, но надёжно измерить это трудно. Эксперимент Google с 96 инженерами показал примерно на 21% меньше времени на задачу, с заметной неопределённостью. Veracode нашла небезопасные результаты примерно в 45% отобранных задач, связанных с безопасностью, поэтому сгенерированный код всё равно нужно проверять.
