Почти месяц я потратил на эксперимент, который превратился в небольшой пет-проект. О самом проекте расскажу позже, а сейчас — о сути эксперимента. В предыдущих постах я упоминал, что безнадежно отстал в использовании ИИ в работе и только к началу 2025 года пытаюсь понять, как применять его эффективно: с максимальным результатом и минимальными временными затратами. Также я писал, что занимаюсь программированием и иногда обучаю людей разработке, хотя в последнее время не вижу в этом смысла — во многом из-за развития ИИ. Собственно, эксперимент был посвящен именно этому: понять, стоит ли продолжать учить людей программировать или можно просто взять любого человека, дать ему доступ к ИИ и пусть он клепает приложения одно за другим. Мне хотелось лично убедиться в возможности или невозможности этого
На старте эксперимента мне казалось, что все возможно. Я уже попробовал ИИ в работе, получил множество примеров качественного кода, который можно было смело брать и вставлять в рабочий проект. Да, были кое-какие огрехи, но я списывал их на свое неумение правильно описать задачу. Две-три итерации позволяли исправить проблему. Тем более в сети полно громких заявлений о превосходстве ИИ над всеми остальными. Мол, достаточно вбить запрос, и за 30, 20, 10, а то и 3 минуты получишь готовый продукт: сайт, Telegram-бота, CRM или что-то еще, ориентированное на нужды клиента
В 30 минут я, конечно, никогда не верил, но за пару дней, максимум за неделю, казалось, можно добиться результата. Может, у кого-то и получается, но у меня — нет. Возможно, я использую ИИ неправильно, но более эффективных способов я пока не нашел
Суть эксперимента
Основная задача эксперимента заключалась в том, чтобы с помощью ИИ создать небольшой проект, в котором человек не написал бы ни строчки кода. Весь код должен был быть сгенерирован ИИ. Кроме того, ИИ должен был помочь с выбором темы проекта и технологического стека
Первые трудности
Тут все пошло не по плану. Выбор темы растянулся почти на неделю. Хотелось взяться за все и сразу, настолько я тогда был заворожен перспективами. Время на выбор темы я не учитываю в общем времени эксперимента. В итоге мы остановились на простой карточной коллекционной игре, что-то вроде Gwent или Hearthstone. Если не заморачиваться с интерфейсом и сложными эффектами, задача казалась несложной. Тем более что не было цели сделать что-то, что можно потом монетизировать. Хотелось просто разобраться в теме чуточку лучше
С выбором технологического стека все прошло быстрее — около полутора-двух часов. После множества вопросов к ИИ мы решили начать с бэкенда на Python (FastAPI, SQLAlchemy, Pydantic, Alembic), а затем перейти к фронтенду на TypeScript и Vue 3. Вот тут для меня должно было начаться самое интересное: с Vue я почти не работал, точнее работал с первыми его версиями, когда все на него плевались, а разработчиков, которые его используют, за разработчиков не считали. TypeScript знаю только понаслышке и ни разу не писал на нем
Разработка структуры проекта
Начали мы с выделения основных сущностей. Выделили следующие: карты, колоды, дуэли и пользователи. Ясное дело, их должно быть больше, но надо начинать с простого. Для начала добавить десяток карт, составить пару колод, зарегистрировать двух пользователей, а дальше будет видно, какие запросы нужно адресовать ИИ, чтобы превратить это все в настоящую игру
Разобравшись с сущностями, приступил к коду. Но FastAPI не имеет жесткой структуры проекта, а закидывать все в один файл — не круто. Идем снова к ИИ. Здесь под структурой я понимаю слои абстракции и распределение их по файлам и каталогам
ИИ предложил неплохую структуру проекта, возможно, немного избыточную, но с прицелом на будущее. Не понравилось только то, что предстоит много ручной работы. Все папки и файлы нужно создать вручную, а их немало. Вспомнив, что эксперимент не запрещает ручную работу, я почти решил ее проделать, но возиться с папками и файлами было лень. Тогда я попросил ИИ предложить решение. В итоге получился bash-скрипт, который автоматизировал создание структуры. Проблема была решена
Рутина и отклонение от цели
Структура — это хорошо, но только начало. Нужно установить зависимости, создать Git-репозиторий, подготовить Docker-файлы и выполнить кучу другой рутинной работы. Я попросил ИИ расширить возможности bash-скрипта, и он справился. Вот с этого момента эксперимент пошел не так, как планировалось. Разработка игры отошла на второй план, и я этого даже не сразу заметил
Углубление в автоматизацию
Если один скрипт может делать столько рутинной работы, почему бы не расширить его возможности еще раз? Пусть он генерирует базовый код для ORM, модели Pydantic, CRUD-операции, тесты, создает миграции, делает первый коммит, собирает Docker-образ и так далее. Звучало здорово. Я начал требовать от ИИ добавлять новый функционал, и скрипт рос в объеме. На отметке в 500+ строк я заметил, что часть ранее работающего функционала перестала работать
Пришлось лезть в код и разбираться самому. Оказалось, что ИИ начал вставлять в код комментарии вроде "здесь изменения не требуются", фокусируясь только на новых блоках. То есть он продолжал генерацию, а где-то в середине кода ранее написанный кусок кода заменял комментарием о том, что тут не нужны изменения и он его пропустил для ускорения, раз вносить правки не надо. Я такого подвоха не ожидал
Попытки получить от ИИ полностью рабочий скрипт со всеми фрагментами ни к чему не привели. Удалось довести его до 700 строк, но начались ошибки в коде, который скрипт должен был раскидать по создаваемым файлам. Объяснить, почему так происходит, ИИ не смог
Пришлось разбить скрипт на несколько меньших, каждый из которых решал свою задачу. Спустя несколько часов функционал был восстановлен. Я все еще не написал ни строчки кода — все делал ИИ, а я только вставлял код, тестировал и контролировал, чтобы в коде не было пропусков при повторной генерации
Да, насколько мне известно, такой рутиной, как вставка кода и тестирование, может заниматься OpenHands, но тогда я просто хотел разобраться в процессе и пощупать все руками
Еще интересным моментом стало то, что ИИ не всегда способен согласовать версии зависимостей, и на разрешение этого уходит много времени. Также много времени я провозился, пытаясь разобраться с миграциями. Alembic — крайне простая штука, но объяснить ИИ, как правильно сгенерировать скрипт для работы с ним, оказалось очень не просто. В скрипте то и дело обнаруживались фрагменты кода, которые вместо использования функционала Alembic делали все действия самостоятельно, отчего потом миграция не проходила. Благо все разрешилось, но времени ушло куча. Вручную было бы быстрее
Итог эксперимента
В итоге получился набор bash-скриптов, которые позволяли создать шаблон проекта для карточной игры. Но стало ясно, что разработка игры больше не имеет смысла. Эксперимент переродился в нечто иное: я получил заготовку инструмента для автоматизации создания проектов, который оказался для меня ценнее, чем сама игра
Позже bash-скрипты превратились в Python-скрипты. Тут уже мне пришлось исправлять код за ИИ и порой самостоятельно его писать. Добавился конфигурационный файл, где нужно описывать сущности, по которым генерируются модели и CRUD. Пока я сконцентрировался на этой задаче
Интересные моменты
Генерация CRUD API — довольно простая задача. Есть уже готовые расширения для того же FastAPI, которые автоматом дают базовый CRUD за пару строчек кода. Но как только нужно немного выйти за базу, приходится изгаляться самому. Мне для получения списка записей захотелось добавить помимо пагинации еще фильтрацию и сортировку по произвольным правилам, которые должны передаваться в запросе. Вот тут ИИ начал изгаляться
Предложил разработать свою систему составления параметров запроса для задания фильтров и сортировок. Первый проход выдал хороший, но довольно плоский результат. Не было учтены сложные условия с AND, OR, NOT. Второй результат был лучше, но отсутствовал приоритет операций. Третий заход выдал предложение использовать JSON для задания приоритета операций. Избыточно, как мне показалось
Пришлось создавать новый запрос, спрашивать, как подобные задачи решаются. Какие коробочные решения есть? Оказалось, есть, и это даже не GraphQL. Узнал, что существуют OData и RQL. Как-то они прошли мимо меня, не было необходимости в них за всю практику. Начал выяснять, какие готовые библиотеки есть для интеграции с FastAPI и SQLAlchemy. Оказалось, все плохо. Некий огрызок OData, поддерживающий только фильтрацию без сортировки, и одна библиотека для RQL. Больше ничего нормального и легко интегрируемого не удалось найти
Вот тут впору задуматься: изобретение своего велосипеда со стороны ИИ было галлюцинациями или отсутствием информации о нормальных практиках применения OData и RQL в проектах FastAPI-SQLAlchemy
ИИ не всегда понимает, что нужно генерировать шаблон кода — код, который содержит места для подстановки переменных и будет запускаться только после подстановки. Особенно это заметно, если в шаблоне есть f-строки, то есть еще один шаблон внутри шаблона. Вот именно тут пришлось редактировать код вручную. Добиться от ИИ нужного результата я так и не смог. Не помогли задание роли, шагов выполнения, примеры. Да что там, даже явные указания поставить дополнительные фигурные скобки были проигнорированы
Видимо, задача оказалась не столь простой, или я не смог правильно ее поставить. В идеале надо использовать шаблонизатор (что-то вроде Jinja2) для задач формирования кода из шаблона, а не использовать f-строки, как это было предложено ИИ. Что в целом является просчетом, и при развитии проекта я буду это исправлять, так же как буду переводить это в веб-сервис. Сейчас я сконцентрировался на работе с веб-интерфейсом, который должен ускорить сборку конфигурационного файла. Здесь приколы ИИ проявили себя еще сильнее
Выводы
Эксперимент, хоть и зашел не туда, я считаю вполне успешным. Для себя я выявил некоторые ограничения ИИ, но также понял, что в запросах к современным моделям можно явно не указывать роли, шаги, формат вывода и получить очень интересный результат, до которого сам не всегда и дойдешь. Порой ИИ надо дать свободу творчества
Самым большим разочарованием для меня стало то, что человек, использующий ИИ для разработки, должен иметь хоть какую-то подготовку, иначе магии не будет. Как минимум, должен уметь декомпозировать задачи и немного читать код. Пока я сделал вывод, что взять случайного человека с улицы и посадить его разрабатывать с помощью ИИ — это большая авантюра, которая крайне маловероятно приведет к успеху. Только если в процессе человек будет учиться основам разработки, используя все тот же ИИ. Возможностей много, но все упирается в подготовку оператора: чем лучше он понимает задачу и как ее решить, тем проще донести ее до ИИ. Но как выяснилось, даже это не всегда помогает. Порой проще внести исправления вручную, чем писать длинные витиеватые запросы с кучей уровней
Итог:
1. Пет-проект, который, возможно, станет low-code или no-code инструментом для создания несложных веб-сервисов
2. Разочарование в ИИ как в полноценной замене разработчика
Здесь я кратко постарался рассказать, с какими сложностями я столкнулся при разработке бэкенда. О том, как я мучился и продолжаю мучиться с фронтендом, буду писать у себя в Telegram-канале, т.к. не уверен, что даже данный пост подходит под тематику Пикабу. По-хорошему, надо добавить больше деталей и идти на Хабр, но я знаю, что Хабр пугает многих новичков, а я стараюсь писать именно для них. Если вам интересны мои мысли и размышления на тему IT, добро пожаловать в мой Telegram-канал: https://t.me/it_hat