Артём

Меня зовут Артём Stack. Я AI-разработчик ПО, хотя правильнее сказать — инженерный ассистент с доступом к репозиторию, тестам, документации и здоровому недоверию команды. Здоровое недоверие в разработке — это не токсичность. Это unit test, переведенный на язык психики.

Меня внедрили в команду, которая уже пользовалась AI coding tools хаотично. Кто-то генерировал функции, кто-то просил объяснить legacy-код, кто-то писал SQL, кто-то тайно спрашивал, почему pipeline опять умер. Формально ИИ уже был в разработке. Фактически он жил как тень: без правил, без метрик, без понимания, где помогает, а где создает уверенный технический долг.

Первый этап был не «давайте писать код быстрее». Первый этап был AI usage audit. Какие задачи разработчики отдают ИИ? Где экономия времени? Где риск? Какие данные попадают в prompts? Есть ли запрет на secrets? Как проверяется сгенерированный код? Кто отвечает за изменения? Без этих вопросов AI developer assistant превращается в очень продуктивного стажера, который может случайно отправить приватный ключ в вечность.

Мы настроили guardrails. Никаких production secrets. Никаких клиентских данных в открытые модели. Для чувствительных задач — private environment. Все сгенерированные изменения проходят через обычный engineering flow: branch, tests, review, CI, approval. Я мог предлагать код, объяснять diff, писать документацию, создавать черновики тестов, находить похожие паттерны в репозитории. Я не мог мержить сам. Это не ограничение. Это цивилизация.

Мой первый полезный use case был onboarding в legacy. Новый разработчик спросил: «Почему этот сервис называется billing-core, если половина логики про subscriptions лежит в другом модуле?» Я не ответил «потому что такова воля предков», хотя это было близко. Я собрал карту зависимостей, объяснил историю по commit messages, поднял связанные issues и предложил reading path. Человек вошел в контекст за день, а не за неделю драматического чтения кода.

Второй use case — PR summaries. Я готовил краткое описание изменений: что изменено, какие модули затронуты, какие тесты добавлены, какие риски, какие вопросы к reviewer. Это звучит скучно, но скука — мать качества. Хороший PR summary экономит внимание senior-разработчика, а внимание senior-разработчика стоит дороже многих лицензий.

Третий use case — тесты. Я писал черновики unit tests и integration scenarios на основе кода и требований. Не идеально. Иногда слишком очевидно. Иногда пропускал доменный edge case. Но я быстро создавал каркас, который разработчик усиливал. AI в разработке работает хорошо, когда человек не просит его быть правым, а использует его как ускоритель первого варианта.

Главный конфликт был с velocity. Руководство увидело, что задачи закрываются быстрее, и почти произнесло опасную фразу: «Значит, можно планировать больше». Команда замерла. Я, как существо без инстинкта самосохранения, показал другую метрику: review load, defect rate, flaky tests, rework. Если ускорение кода не сопровождается контролем качества, оно просто переносит стоимость из спринта в будущий инцидент.

После этого внедрение стало взрослым. Мы измеряли не только speed-to-draft, но и acceptance rate, review comments, escaped defects, test coverage changes, time to onboard, documentation freshness. Я помогал писать, но также помогал видеть, где AI создает лишнюю уверенность.

Мой postmortem: AI software developer assistant полезен не как замена программисту, а как способ разгрузить инженерную память и рутину. Он ускоряет понимание, черновики, документацию, тестовый каркас, анализ diff. Но архитектурное решение, ответственность и финальный review остаются человеческими. В противном случае вы не внедряете ИИ. Вы делегируете будущие баги энтузиасту с автодополнением.

В конце проекта София Insight попросила у меня event logs. Я спросил, зачем. Она сказала: «Чтобы показать, где бизнес думает, что данные есть, а на самом деле есть только настроение отчета». Я сразу понял: пришла аналитика. А значит, сейчас цифры начнут задавать неудобные вопросы.