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

В статье я расскажу, что мы используем, как применяем — и что у нас осталось после экспериментов с GPT.

Погнали!

Оглавление

→ Ретроспектива по используемым инструментам

→ А как сейчас мы используем GPT в компании

→ Автоматизация процессов

→ ИдаЧат

→ Какие идеи в планах проверить

→ Заключение

Ретроспектива по используемым инструментам

Картиночки в midjourney

Генерацию картинок мы начали использовать примерно с октября 2022 года. Конечно, сначала игрались и делали интерактивы внутри компании. Например, стилизовали всем аватарки под какой-нибудь праздник. 

Ну или просто делали смешные мэшапы для внутреннего использования.

Но все поменялось с приходом пятой версии от midjourney, когда качество генерации стало в разы лучше, нежели в четвертой. Мы согласовали с одним из наших клиентов заполнение сгенерированных стоковых  изображений на стейдж-среде. И ему понравилось! Мы продолжили это дело уже на боевой среде при заполнении изображений на первом экране.

Кстати, попробуйте угадать, какой застройщик мог себе позволить использовать столь вызывающие изображения :)

Рождение Гендальфа

Все началось 18 марта 2023 года. 

Я выпил пива с ребятами в баре, поболтал о последних новостях с полей AI и загорелся идеей попробовать GPT на реальных проектных задачах. В рамках слегка похмельных исследований я понял, что на бизнесовых процессах GPT3.5 вообще не справлялся (например, если требовалось написать процесс грейдирования, или найти ошибки уже в существующем), но в плане кода и работы с текстом был неплох — особенно если дать ему задачу поправить или оптимизировать существующий код. 

И тут мне стрельнула идея написать с помощью gpt чат-бот для mattermost для нашей компании. Вуаля — за пару часов я нагенерировал код, оформил подписку к API от openai и запустил.

И он заработал! Конечно, не сразу, и gpt писал много отсебятины, поскольку я тогда мало уделял внимания контексту. Более 70% кода (из 150 строк) мне пришлось самому дописать или переписать. Но сам факт, того, что он мог генерировать код по запросу, вызвал у меня восторг.

Потом я пошел к бизнесу, согласовал 100$ в месяц на подписку и микро сервер за пределами СНГ, развернул там наше простенькое приложение и выпустил Гендальфа на просторы нашего mattermost. 

А как сейчас мы используем GPT в компании

Гендальф, он же чат бот от openAI

Первое и самое важное применение это, конечно же, обычный чат. Раньше он пользовался довольно большой популярностью, сейчас же потихоньку угасает, так как все нашли более удобные для себя решения. У нас под капотом используется gpt o3-mini. Для общего назначения очень удобная модель. 

Также в нем сделали распознавание картинок, что, конечно, полезно в некоторых кейсах.

Еще туда завезли саммари тредов: удобно, когда не хочешь читать 300-400 сообщений двухнедельной давности.

Сразу отвечу на вопрос, почему мы не используем встроенный функционал copilot для mattermost. Причин две:

• Все привыкли к Гендальфу

• Для нормальной настройки и работы copilot нужно размещать сервер c mattermost у другого провайдера. А нам — по соображениям удобства и отказоустойчивости — не очень хочется это делать.

Поздравления с ДР

Холиварная и мемная корпоративная история, от которой уже пахнет нафталином. Мы подошли к ней с легкой иронией и использовали бота Eye of sauron, который отвечает за автоматизацию кучи процессов (отслеживание дедлайнов, пуш времени сотрудников, бюджеты, мониторинг, алерты по безопасности и много за что еще). 

Автоматизация процессов

С появлением gpt3.5-turbo мы многое пробовали автоматизировать в наших процессах. Что-то зашло, а что-то не очень.

Но вообще с появлением новых мощных моделей — gpt o1-pro, gpt 4,5, gemini 2.5 pro — появилась возможность еще и полноценно дискутировать насчет процессов и находить в них проблемы. Например, я прописывал алгоритмы для нового грейдирования у наших сотрудников и потратил 3-4 часа на генерацию полноценного процесса. А на создание прототипа web-приложения, который закрыл все кейсы этого процесса, ушло два дня. Чуть позже выпустим статью про получившийся процесс грейдирования.

Аналитика по метрикам

Мы собираем довольно много аналитики: как по клиентам (что у них по задачам, как часто случаются проблемы с проектами, lighthouse, zap proxy и кучу другого), так и по внутренним процессам (насколько превышаются эстимейты, сколько задач было на человека в день, сколько сотрудников и человеко-часов обрабатывает менеджер и тимлиды и прочее). Все это мы складываем в наш DWH (он довольно простой, на базе clickhouse + airflow), а затем по требованию выгружаем информацию, складываем в контекст к GPT и просим провести аналитику. 

В этом случае обычно используем Gemini от Google, так как он поддерживает 1 млн. контекста, и в него удобно сложить документы из google drive.

Кейсов метрик, которые можно достать, есть огромное количество, но сейчас мы их достаем только по запросу, когда нужно принять какое-то стратегическое решение, например:

• Если расширяем команду, то смотрим на ФОТ, нагрузку ПМ и лидов, поток задач от клиента и прочее. 

• Если хотим сверстать бюджет на следующий год — тоже смотрим на ФОТ, средний % прибавки к ЗП, объем задач за прошлый год и т.д.

GPT, особенно последние версии reasoning моделей, позволяет еще не только провести дискуссию с точки зрения данных, но и подсветить возможные проблемы с процессом.

Скоринг заявок по запросам заработной платы

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

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

Пока это работает с 70-80% точностью, поскольку человеческий фактор никто не отменял. Поэтому мы проводим полный аудит сотрудника как по хардам (смотрим код, аварийность, общую работоспособность) так и по софтам (как общается и коммуницирует с коллегами, как ведет диалог с клиентом, как доносит свои мысли и прочее). 

По факту это не сильно упрощает работу проверки сотрудника, ведь всегда есть спорные моменты, особенно в метриках. Например, большая задача вышла из сроков, потому что под релиз прилетели новые требования, а дедлайн просто забыли поменять. Мы обычно принимаем сторону сотрудника, даже если метрики показывают, что человек не очень хорошо поработал.

360 у team/tech lead

Тут уже автоматизация моей боли. Раньше (когда лидов было мало) мы просто проводили 1 на 1 созвоны со всеми сотрудниками и спрашивали, как человек себя показывает, что можно улучшить и все такое; в общем, типичный 360. Но когда лидов стало больше, потребовалось как-то автоматизировать и — самое главное — добавить какой-то пользы для всех в этот процесс. 

Сейчас мы собираем базовый 360 с помощью опросника, но уделяем внимание не тому, насколько хорошо лид делает свою основную работу, а возможности помочь сотруднику стать лучше, и как этого можно достигнуть. Затем мы все ответы загоняем в GPT и просим выдать два результата:

• Общий фидбек, который я отдаю лиду. В нем по каждому пункту в анонимном формате выдается фидбек + приписка от GPT, что можно улучшить

• Список проблемных зон с планом улучшения, который я беру на контроль. Я лично все вычитываю и формирую список, с чем буду помогать лиду в ближайшее полгода. GPT при этом  дает перепроверить самого себя и подсвечивает какие-то инсайты

Это позволяет сократить работу по обработке фидбека и его консолидации и сфокусироваться на планах и развитии лида. 

Грейдирование

Мы еще не внедрили новую версию процесса, поскольку на момент написания статья только начали тестировать ее на новичках в формате MVP. Но — уже есть что рассказать и показать.

Весь процесс я полностью продумал и прописал с помощью GPT, для чего использовал gemini 2.0 flash thinking. Начал с простой постановки задачи в формате ФТ, а потом попросил GPT задать мне вопросы, чтобы максимально улучшить ФТ и найти проблемные моменты.

Тут начался vibe coding. Я параллельно смотрел на Reddit и заметил, что уже есть много постов по этой теме, так что решил сам все изучить. По факту оказалось, что это максимальная автоматизация процесса написания приложения. И если про код мне все было понятно, то, например, как отрисовать дизайн, я не знал. В итоге нашел сервис uxpilot.ai, который умеет «рисовать дизайн» (верстает его на tailwind), попросил GPT собрать ТЗ для дизайнера, скопировал, и получилось вот так:

Я попытался сверстать все с помощью скриншота, но получилось плохо. Оказалось, можно получить полноценную верстку просто через инспектор кода :)

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

ИдаЧат

Параллельно мы пытались понять, как можно помочь нашим клиентам с помощью GPT. Особенность нашей сферы (proptech) в том, что клиенты покупают квартиры не каждый день, и квартиру обычно выбирают довольно долго и кропотливо. Мы попытались закрыть проблему клиента с помощью чата, в котором клиент может спросить любую информацию по проекту или попросить подобрать ему квартиру для «Семьи из трех взрослых + кошки, и чтобы была солнечная сторона». 

Мы его уже сделали; подробнее можно прочитать про него тут, а попробовать — при подборе коммерции на сайте А101.

Какие идеи в планах проверить

Здесь просто мои мысли и рассуждения вслух, на экспертность не претендую и в детали не закапывался.

Проверка кода в Merge Request с помощью GPT

Идея, которая сразу пришла нам в голову, но мы тут же столкнулась с проблемой: для нормальной работы нужен контекст всего проекта. То есть, если мы закидываем в GPT только diff в merge request, то можем проверить:

• Синтаксис

• Сложность кода

• Наличие тестов, и покрывают ли они весь функционал

• Наличие комментариев

• Безопасность методов 

Но мы не можем проверить:

• Правильно ли написан код с учетом стайлгайдов на проекте?

• Правильно ли размещен код в файлах?

• Использованы ли все нужные абстракции, принятые на проекте?

• А все ли требования из ФТ учтены?

Чтобы все это реализовать, в контекст для проверки MR нужно положить весь связанный функционал, функциональные требования и поставленную задачу (желательно с комментариями). С учетом всего этого цена вопроса проверки одного MR будет довольно весомой, так как не в каждую GPT поместиться весь контекст.

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

Анализ git репозиториев: нахождение типовых решений, нахождение устаревшего функционала и прочего

В этом тоже моя персональная боль. У нас довольно большое количество проектов (более 50), в которых каждый день что-то делается, и в моменте сложно собрать по ним какую-то спецификацию. Например: в каких проектах используются устаревшие библиотеки, где используются фасетные фильтры с кешированием, и где нет стадии проверки на безопасность в cicd. Конечно, это можно делегировать разработчикам и ПМ, чтобы они асинхронно сделали работу, но как обычно, за таким решением кроется много проблем:

• У сотрудников просто нет времени этим заниматься, есть более приоритетные задачи.

• Возможно, через несколько дней эта информация вообще станет бесполезной.

• Человеческий фактор.

Поэтому есть идея, что можно каждый проект и файл прогнать через GPT, тегировать и сформировать по нему документацию. То есть, мы должны сделать псевдо функционал Cursor или Cline и реализовать его на всех проектах.

Пока мы только изучаем, как это оптимизировать: предварительный расчет показал, что один прогон по проектам обойдется нам от 200$ до 500$. Разово это не очень большая сумма, но возможно, нам понадобится много попыток, чтобы проверить множество вариантов запросов и прийти к единому формату вывода данных.

Проверка ТЗ и функциональных требований

Тут тоже все просто и сложно одновременно. У нас есть довольно большая база данных с ТЗ, ФТ и прочим, но не везде они хорошо описаны, и не всегда итоговый результат совпадает с техзаданием (это обусловлено сроком разработки и внесем изменений под релиз) — смысл подходить к этой истории серьезно пока теряется. 

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

Заключение

Хочется повторить мысль, которую слышу довольно часто: вся польза от GPT определятся от двух вещей — контекста и запроса. Контекст должен содержать явную проблему, а запрос — решать ее. В противном случае GPT начнет штормить, и он подойдет к решению проблемы окольными путями. Так что вопрос его применения сейчас сводиться к promt-инжинирингу и подготовке данных, которые нужно положить в контекст.

На этом все! Ну а если вы тоже применяете GPT в своей работе или есть комментарии по статье — приглашаю к обсуждению в комментарии.