На что способен бесплатный Devin: тест на реальном проекте

Меня зовут Завур, я фронтенд-разработчик в Selectel. Каждый день я работаю в привычной многим среде разработки VS Code. Однако в личных проектах, которые создаю для исследования новых инструментов и методов написания кода, часто использую Cursor.

Он классно ускоряет разработку, но мне давно хотелось проверить: способен ли искусственный интеллект самостоятельно воплотить сырую идею в полноценное рабочее приложение? Иногда хочется быстро увидеть прототип в действии, чтобы решить, стоит ли развивать проект дальше. Именно поэтому я не смог пройти мимо многообещающего сервиса Devin.

Давайте посмотрим, как на практике выглядит реализация идеи с помощью Devin, и попробуем разобраться, действительно ли перед нами потенциальный конкурент Cursor.

Кто такой Devin

Разработчики из Cognition AI анонсировали Devin в 2024 году как полноценного автономного ИИ-инженера. Позиционируется он принципиально иначе, чем привычные ассистенты: не просто как умный текстовый редактор, а как полноценный автономный агент. Вы описываете задачу обычным текстом, а дальше Devin сам планирует работу, пишет код, запускает его, исправляет возникающие ошибки и развертывает готовое приложение без вашего постоянного участия. Звучит как заманчивый маркетинговый лозунг, поэтому я решил проверить его заявления на реальной задаче.

При регистрации я выбрал бесплатный тариф и приятно удивился безлимитным автодополнениям и возможности построчного редактирования кода. Подобной щедростью встроенные в VS Code инструменты вроде GitHub Copilot или Cursor похвастаться не могут.

Как устроен Devin Desktop

Инструмент доступен в трех форматах: в виде интерфейса командной строки Devin CLI, облачного веб-приложения Devin Cloud и десктопной среды разработки Devin Desktop. Я остановился на десктопной версии, так как это наиболее привычный формат. По сути, перед нами обычный редактор кода, где можно работать в стандартном режиме как в VS Code или Cursor, но в любой момент делегировать задачу ИИ-агенту.

И тут стоит сделать важную оговорку: Devin Desktop — это не продукт, написанный Cognition с нуля, а переименованная среда разработки Windsurf (в прошлом Codeium и по совместительству один из главных конкурентов Cursor), которую компания Cognition приобрела в 2025 году примерно за 250 млн долларов, а летом 2026 года официально представила под брендом Devin Desktop. Таким образом, выбирая версию Desktop, я по факту получаю готовую, обкатанную годами IDE с AI-автодополнением.

Открыв программу, я сразу увидел интересную особенность. В отличие от аналогов, здесь есть два режима: Agent и Editor. Причем это не просто два варианта одного и того же чата, а два разных интерфейса.

Режимы Editor и Agent: в чем разница

Режим Editor представляет собой IDE-обвязку вокруг VS Code. Слева находится привычный проводник Explorer с файлами проекта, по центру — сам редактор кода, а справа — панель чата с ИИ, очень похожая на боковую панель в Cursor.

Интерфейс режима Agent выглядит совсем иначе. Здесь нет открытых файлов кода, вместо них перед нами открывается полноценная доска сессий с переключателями Board и List, фильтрами, поиском, кнопкой New session и списком запущенных задач. По сути, это канбан-доска для параллельных фоновых процессов.

В этом и проявляется ключевая разница между подходами Devin и Cursor. В Cursor агентный режим — это лишь дополнительная функция внутри чата, расположенного рядом с вашим кодом. 

У Devin же управление агентами вынесено на отдельный экран верхнего уровня, и это прямое отражение философии продукта — можно запустить несколько задач параллельно, уйти по своим делам, а затем вернуться и проверить статус каждой из них в таск-трекере. Проще говоря, в этом режиме Devin — не ассистент, а скорее личный разработчик, работу которого вы контролируете.

Облачная инфраструктура для ваших проектов

Виртуальные машины в Москве, Санкт‑Петербурге и Новосибирске с оплатой по потреблению.

Подробнее →

Создаем Telegram-бота «Cheap Flights Alert»

Не хотелось давать Devin слишком легкую задачу вроде калькулятора или todo-приложения. Поэтому я поручил ему сервис с Telegram-ботом для уведомлений о дешевых авиабилетах и веб-панелью для настройки маршрутов и ценовых порогов. Задача требует планирования сразу нескольких компонентов: БД, фронтенда, интеграции с Telegram API и работы с внешним API перелетов. Думаю, это раскроет возможности агента и покажет его умение раскладывать работу на шаги.

Формулируя задачу, я намеренно не расписывал стек и архитектуру — указал только функциональные требования и жесткие ограничения (например, контейнеризацию проекта, потому что в планах развернуть его на VDS). Если бы я прописал все до деталей, то проверял бы не автономность Devin, а его умение следовать четким инструкциям. Мне же было интересно посмотреть именно на то, какие архитектурные решения он примет самостоятельно и как объяснит их.

На бесплатном тарифе пользователям доступна только модель SWE-1.6 Slow, в то время как платные подписки открывают доступ к более быстрым и производительным моделям.

Я отправил Devin свой первый запрос. Сначала интерфейс выдал предупреждение о высокой нагрузке на серверы, но через пару минут работа все же началась. Агент автоматически составил план действий из 10 пунктов и запустил циклическую цепочку шагов, за которой очень удобно наблюдать на экране. Цикл состоит из трех основных фаз:

1. Thoughts (внутренние рассуждения модели);

2. Searched web (активный поиск информации в интернете — в моем случае агент изучал бесплатные API через Aviasales, Travel Payouts, Skyscanner и Kiwi);

3. Updated todo list (корректировка и детализация исходного плана на основе найденных данных).

Для меня это стало показательным моментом. Я намеренно не указывал стек технологий и конкретные API для интеграции, и модель не стала выдумывать несуществующие методы. Вместо этого она сначала проверила, какие инструменты доступны бесплатно в сети. 

Работая в Cursor, мне пришлось бы самостоятельно выбирать API или расспрашивать модель в соседнем чате. В Devin же процесс больше напоминает контроль за работой джуна: он аргументирует свои решения, ищет информацию, на ходу правит план, а вы просто наблюдаете за логом сессии.

Вся подготовительная фаза уложилась примерно в 20 минут. Важно подчеркнуть, что это время ушло именно на глубокое планирование и поиск оптимальных путей интеграции, а не на мгновенное написание случайных строк кода.

В конце работы над запросом Devin выдал итоговый отчет, самостоятельно определив архитектуру и стек технологий, так как изначально я не задавал жестких рамок для проекта.

Для бэкенда агент выбрал FastAPI и базу данных PostgreSQL. Фронтенд-часть он реализовал на React, а самого Telegram-бота интегрировал непосредственно в общий проект. Всю эту систему Devin упаковал в контейнеры, настроив оркестрацию через docker-compose для удобного запуска. Здесь обошлось без экзотики — это стандартный рабочий выбор.

Запустить проект Devin предлагает буквально одной командой. В README-инструкции описан классический процесс: нужно скопировать файл настроек cp .env.example .env, прописать в нем API-ключи и выполнить команду docker-compose up --build или запустить готовый скрипт ./start.sh.

В логе было видно, как он выбирал источник данных о перелетах: сначала погуглил бесплатные варианты (Aviasales, Skyscanner, Kiwi) и остановился на Travelpayouts из-за простой регистрации и цен в рублях. Для русскоязычного сервиса это хороший выбор, но у их данных есть задержка до двух суток. В отчете агента это подается как плюс («быстро и стабильно»), однако для системы оповещений это скорее минус: уведомление может прийти, когда дешевый билет уже купили.

При разработке веб-панели Devin решил не усложнять систему OAuth-авторизацией через Telegram Login. Вместо этого он предложил простой и надежный механизм: при первом запуске бота по команде /start пользователь получает свой уникальный Telegram ID и затем просто вводит его в панели для входа. Поскольку в ТЗ я сам предложил выбор между авторизацией через Telegram и просто ID, а также запретил сложную систему входа, Devin не стал ничего накручивать. Он пояснил, что для черновика этого достаточно: меньше мест, где все может сломаться. Тут агент попал в рамки и ничего не додумал.

С датами получилось иначе. Я намекал на гибкий поиск «плюс-минус три дня», но ИИ упростил логику и выбрал фиксированный промежуток от одной конкретной даты до другой конкретной. Это снизило нагрузку на внешнее API, сделало проще и код, и поиск билетов. Однако минус в том, что сервис проверяет цены строго в заданном окне, а не ищет самый дешевый вылет около нужных дней. Для сценария «хочу улететь примерно в эти выходные» гибкий вариант подошел бы лучше, но агент упростил то, что было неудобно писать, и преподнес это как удобство для пользователя.

APScheduler отвечает за регулярную проверку цен. Частоту агент настроил на раз в четыре часа, что вполне соответствует моему требованию «раз в несколько часов». Планировщик при этом живет на том же сервере: если упадет сервер, встанут и проверки, но для MVP такой подход вполне нормален.

Сам бот поддерживает стандартный набор команд — /start, /routes и /help, а также отправляет push-уведомления, как только стоимость билета опускается ниже заданного пользователем порога. Чтобы избежать отправки дублирующих сообщений, Devin предусмотрел защиту на уровне базы данных, добавив уникальные ограничения (constraints) для связок маршрута, даты и цены.

Для проверки надежности кода агент написал тесты, покрывающие ключевые функции: валидацию кодов аэропортов IATA, сравнение найденных цен с лимитами пользователей, дедупликацию предложений и сборку самих уведомлений. 

Архитектурные решения понятны, теперь оценим работоспособность проекта.

Запуск созданного приложения

Попробуем запустить проект, следуя файлу README, который составил агент. Для начала я создал Telegram-бота и аккаунт на Travelpayouts, чтобы получить токены и внести их в файл .env. 

Запускаем все сервисы:

docker-compose up --build

Первый билд прошел неудачно, но агент быстро нашел причину: в Docker использовалась старая версия Node, тогда как сборщик фронтенда требовал более свежую. 

Ответ агента: «Проблема в зависимости rolldown, которая требует более новую версию Node.js. Давайте используем Node.js 22».

Ответ агента: «Бот не может запуститься из-за отсутствия модуля requests. Проблема в файле telegram_bot.py — там есть неиспользуемый импорт requests».

Дальше начались знакомые сложности: лишние импорты, кривые аргументы функций, сломанная авторизация, некорректные запросы с фронтенда, неотслеживаемые пользователи в базе и поля с ошибочным форматом. В итоге пришлось потратить еще пару часов и дорабатывать код совместно с агентом.

Тем не менее веб-панель заработала, и мне даже удалось добавить несколько маршрутов, которые сразу можно отслеживать в боте.

Интерфейс выглядит ровно так, как задавалось в ТЗ: вход по Telegram ID, маршрут, порог в рублях и диапазон дат (правда, как я уже упоминал выше, фиксированным окном, а не ±3 дня).

Команда /routes выводит тот же список направлений, что и панель, — значит, бот и веб-часть завязаны на общую базу. 

Для проверки я поставил порог 30 000 ₽ на направление Москва — Санкт-Петербург. Вскоре бот прислал предложение прямого рейса за 5 332 ₽ с датой и ссылкой на покупку. Цепочка «панель → проверка через /routes → уведомление» в итоге отработала как надо. 

Что получилось. Devin за один промпт и ~20 минут сессии собрал цельный проект: бэкенд, бота, веб-панель, Docker и README. Он сам подобрал API, обосновал свои решения и сделал все это на тарифе Free без каких-либо предупреждений о лимитах.

Из минусов: выдать готовый продукт «под ключ» с первой попытки у него не вышло. Сборка упала, бот отказался стартовать, а авторизацию и запросы с фронтенда пришлось допиливать руками. Без живого разработчика проект так и не дошел бы до отправки первых уведомлений.

Так что на вопрос из начала статьи ответ простой: Devin действительно способен превратить сырую идею в рабочий прототип, но отменять программистов пока рано. Будьте готовы потратить пару часов на дебаг и правки.

На этом можно было бы поставить точку: идея в целом работает, бот исправно посылает уведомления. Но в задании для Devin я просил Docker под сервер, чтобы проект поднимался на чистой машине одной командой. Давайте проверим, встанет ли он на VDS от Selectel так же, как на ноутбуке.

Деплой проекта на VDS от Selectel

Мне нужен был обычный сервер без лишней возни: Ubuntu, Docker, свой IP. Для этого я сначала взял минимальный тариф в Selectel — около 200 ₽ в месяц. На сайте продукт описан достаточно подробно, поэтому с выбором проблем не возникло.

Я зарегистрировался и получил доступ к панели управления, в которой создал VDS-сервер.

Процесс создания сервера предельно прост, так что не будем на нем останавливаться и сразу перейдем к переносу проекта. Попросим Devin развернуть его на нашем VDS.

Началась стандартная работа: перенос проекта на сервер, установка зависимостей, заполнение переменных окружения. К сожалению, сразу результат я увидеть не смог, так как лимиты у Devin все же исчерпались.

Далее Devin сообщил, что сборка Docker-образов проходит слишком долго или обрывается, поэтому лучше увеличить ресурсы сервера. Так я и поступил, увеличив RAM до 2GB.

Несколько раз лимиты у агента заканчивались, но в итоге Devin справился и поднял весь стек: Backend API, Веб-панель, Telegram-бот и PostgreSQL! Все работает исправно, так же как и в локальной версии.

Как вы внедряете ИИ?

Поделитесь своим опытом за 7–10 минут. Разыгрываем 5 сертификатов по 1 500 ₽ на маркетплейсе и 10 наборов мерча.

Ответить на вопросы →

Devin и Cursor — конкуренты или нет

Попробовав Devin, я могу ответить на вопрос из заголовка так: они слишком разные, чтобы прямым образом конкурировать. Это как сравнивать такси и личный автомобиль.

Cursor — это среда, где ты работаешь сам, а ИИ помогает. Открыл файл, написал код, агент подсказал или поправил, ты видишь каждый diff. Когда при запуске бота падала сборка из-за версии Node или ломалась авторизация на фронте, в Cursor я бы правил Dockerfile и смотрел логи прямо в редакторе — без ожидания, пока агент сам найдет причину и предложит фикс. В Devin же ты можешь переключиться в режим Editor и посмотреть код, но сам ритм работы здесь другой: сначала агент думает и действует, и только потом ты подключаешься к проверке.

Devin в режиме агента — это скорее делегирование, чем совместная работа. Конечно, всегда можно переключиться в редактор, посмотреть код или сравнить версии. Это удобно для задач вроде «создай сервис с нуля», когда не хочется тратить вечер на базовую настройку. Для быстрой проверки идей — отлично. 

Разница в подходах видна и по интерфейсу. У Cursor агент встроен прямо в боковую панель рядом с кодом — это надстройка над привычной IDE. У Devin под агента вынесен отдельный экран с доской сессий, где по умолчанию кода вообще не видно. У этих инструментов разная философия: Cursor говорит «я помогу тебе писать», тогда как Devin — «скажи, что нужно, я сделаю и отчитаюсь».

Тут важно понимать, как работает тариф Free. В редакторе автодополнение работает почти без ограничений, и это заметное преимущество по сравнению с Cursor, где в бесплатной версии лимиты на агента заканчиваются очень быстро — особенно при активной работе или обработке больших объемов контекста. С агентом Devin ситуация иная: без платной подписки доступна только одна медленная модель SWE-1.6 Slow, а количество сессий строго ограничено. Я сам уперся в эти лимиты, когда пытался развернуть проект на VDS, из-за чего пришлось несколько раз возвращаться, чтобы продолжить.

Devin убийцей Cursor так и не стал — да и скорее всего, даже не собирался. Это инструмент для тех, кому нужно получить готовый прототип, почти не прикасаясь к клавиатуре самому. Cursor же остается выбором тех, кто пишет код своими руками и просто хочет делать это быстрее. 

Заключение

Эту статью я начал с довольно простого вопроса: может ли искусственный интеллект самостоятельно превратить идею в рабочее приложение? После этого эксперимента ответ скорее «да», но с важными оговорками.

Devin, получив одно лишь текстовое описание задачи, собрал целый проект: бэкенд, веб-интерфейс, Telegram-бота и Docker-окружение. Он сам выбрал API и логично объяснил свои решения. В итоге я поднял сервис и локально, и на сервере — бот исправно присылал уведомления, а команда /routes выдавала нужные данные. 

Однако путь от первого отчета агента до реально работающего сервиса оказался сложнее, чем просто запуск одной команды. Пришлось потратить несколько часов на ручные правки, столкнуться с ограничениями при деплое и даже докупать оперативку на VDS. Так что сообщение Devin «все полностью готово» скорее описывало состояние репозитория, а не реальную готовность к продакшену.

Для меня Devin занял свою нишу: если нужно быстро проверить идею и не хочется тратить весь вечер на настройку стека с нуля — вполне рабочий вариант. Для повседневной работы с кодом я все равно предпочитаю VS Code и Cursor.

Если захотите протестировать инструмент самостоятельно, советую ставить задачу посложнее обычного todo-приложения и сразу закладывать время на доработку после того, как придет красивый отчет от агента. Именно тут начинается настоящая работа, и становится понятно, где заканчивается автономность ИИ.

А какие у вас мысли на счет Devin? Возможно, вы уже успели протестировать его на собственных проектах? Поделитесь своим опытом в комментариях!