"Глубокой ночью в июле я записал голосовое сообщение нашему продакт-менеджеру: 'Мария, делаем хакатон. 48 часов. AI-ревьювер кода.' Утром она ответила: 'Олег, ты серьёзно?' Я был серьёзен как никогда."
P. S. Да, в комментариях к прошлой статье меня уже захейтили за ночные сообщения ? Но это была не рабочая задача, а спонтанная идея, которая не могла ждать до утра.
Я уже рассказывал, как мы собрали working MVP за выходные. Но там история получилась очень позитивная и гладкая. А я хочу рассказать правду — как CEO принимает технические решения в 2 ночи, почему рискует репутацией компании и что чувствует, когда понимает: либо мы делаем breakthrough прямо сейчас, либо упускаем поезд навсегда.
Цель, которая не давала спать
Всё началось с техлида Ивана и его фразы "у чат-GPT спросил?", которая стала мемом в нашей команде. Пока коллеги подшучивали, я видел, как AI меняет всё вокруг. Наши 40 разработчиков каждую неделю тратят 6 часов на просмотр чужого кода. Финальное одобрение pull request'а — ещё 15-20 часов. И я каждый день наблюдал, как талантливые люди тонут в рутине вместо решения творческих задач.
Цель сформулировалась чётко: за 48 часов создать AI-ревьювер, который интегрируется в CI/CD, анализирует код и оставляет осмысленные комментарии в merge request'ах. Не demo, не концепт — рабочий продукт, который в понедельник можем показать первым клиентам.
Почему такая спешка? 15 лет на рынке научили меня чувствовать momentum. Пока конкуренты обсуждают AI в комитетах и планируют бюджеты на следующий год, у небольшой команды есть уникальный шанс. Но окно возможностей не будет открыто вечно.
Препятствия, которые пугали с самого начала
Когда я объявил хакатон в корпоративном чате, откликнулись 12-15 человек — именно те, кто готов экспериментировать и рисковать. Идеальная команда для breakthrough проекта: люди, которые не боятся неопределенности и верят в потенциал новых идей.
Технические вызовы тоже казались пугающими. Мы — полностью распределённая команда в разных городах и часовых поясах. Нужно было через Zoom синхронизировать backend, frontend, .NET и Angular разработчиков, DevOps-инженеров, маркетинг и дизайн. За два дня создать интеграции с GitHub и GitLab, настроить webhook'и, научить AI анализировать код и генерировать человеческие комментарии.
Но самый большой страх был не технический, а репутационный. Если провалимся — покажем себя как CEO, который тратит время команды на непонятные эксперименты. Если получится — откроем новое направление и выйдем на рынок AI-инструментов раньше конкурентов.
День первый: когда планы встречаются с реальностью
Суббота, 26 июля, 10:00. Стендап в общем Zoom'е. Я разложил задачи по блокам, но внутри понимал — план продержится максимум до обеда.
Разработчики сразу взялись за самое сложное. CLI-runner нужно было написать так, чтобы он запускался при каждом push'е, считывал diff и отправлял на анализ. Gateway API — слой между Git-платформами и нашей системой. И самое главное — научить модель анализировать код так, чтобы комментарии были полезными, а не генерическими.
Здесь нас спас опыт Ивана с AI-инструментами. Вместо того чтобы писать всё с нуля, мы использовали n8n для быстрых интеграций — визуальное построение связей между сервисами. Replit AI помог генерировать шаблонный код за минуты вместо часов. А ChatGPT и Claude мы натренировали на паттернах хороших code review комментариев.
Параллельно DevOps творили магию. Поднимали инфраструктуру в Kubernetes, готовили Helm-шаблоны для on-premises развёртывания — я настоял на этом с первого дня, понимая, что enterprise-клиенты захотят держать данные у себя.
А тем временем маркетинг и дизайн... делали то, чего я не ожидал. Они не просто рисовали логотип — они погрузились в проблематику, придумали название MergeSensei, проработали позиционирование и даже начали готовить контент для первых продаж. Это было неожиданно и очень ценно.
К вечеру у нас был первый работающий прототип. Runner запускался, API отвечал, AI анализировал простые примеры кода. Но самое главное — команда поверила, что это реально возможно.
День второй: от прототипа к продукту
День второй: от прототипа к продукту
Воскресенье, 27 июля. Если первый день был про доказательство концепции, то второй — про превращение эксперимента в продукт.
Интеграции с GitHub и GitLab оказались сложнее, чем казалось. Webhook'и нужно было настроить так, чтобы система корректно обрабатывала разные типы событий. YAML-конфигурация должна была быть достаточно гибкой для разных команд, но не слишком сложной для понимания.
Самое интересное началось с обучением AI. Мы поняли, что просто скормить модели код недостаточно. Нужно было научить её понимать контекст: какие правила важны для JavaScript, а какие для Python, как различать стилистические замечания и серьёзные архитектурные проблемы, когда предлагать автоматические исправления, а когда просто указать на проблему.
DevOps-команда к этому времени добила Helm-чарты и развернула систему в облаке. Мы могли продемонстрировать полный цикл: push в репозиторий → webhook → анализ AI → комментарии в merge request.
К вечеру воскресенья у нас был working MVP, который умел:
Подключаться к CI/CD pipeline
Анализировать изменения в коде
Выявлять проблемы по стилю, безопасности и архитектуре
Оставлять комментарии прямо в merge request'ах
Предлагать автоматические исправления
Работать как в облаке, так и on-premises
Поддерживать несколько LLM-провайдеров
Генерировать Markdown-отчёты
Мы не говорим, что MergeSensei — единственный или лучший.
Мы просто знаем, что он уже блокирует MR'ы, которые могли бы уехать в прод с багами. Он встроен в CI/CD, адаптируется под кодстайл команды, учитывает архитектурные паттерны и работает on-prem, если нужно.
Что мы поняли про AI и разработку
Что мы поняли про AI и разработку
AI действительно ускоряет в разы. Там, где раньше писали классы и тесты часами, с n8n-нодами и правильно настроенным LLM-роутингом хватало 5-10 минут. Но не потому, что AI пишет код за нас, а потому, что помогает быстрее находить правильные решения и избавляет от рутины.
Пока конкуренты обсуждают AI в комитетах и пилят бесконечные PoC, мы просто взяли и сделали. Да, знаю — сейчас появятся комменты в духе "а чем вы лучше Coderabit или Snyk?" — давайте обсудим.
Мы готовы к честному сравнению.
Но не всё взлетело с первого раза. Слишком глубокие контексты для LLM в больших монорепах — дорого и медленно. Решили "нарезать" контекст по слоям (архитектура → юниты → строки) и кешировать эмбеддинги. Авто-фиксы без валидации тестами — рискованно. Добавили "Patch Validator": компиляция + запуск минимального набора тестов. Единая модель на всё — компромисс. Для security-советов лучше строгие правила + короткий LLM-постпроцессинг, для стиля — наоборот.
Производительность: мы не гнались за миллисекундами, но хотели укладываться в < 90 сек на 1kLoC diff. После включения RAG и профилирования цепочек добились ~45–70 сек на типичных PR (микросервисы .NET/Angular).
Инструменты имеют значение. ABP Framework дал готовые модули для бизнес-логики. n8n позволил визуально строить пайплайны агентов. vLLM обеспечил гибкое переключение между SaaS и локальными моделями. Kubernetes — готовность к масштабированию с первого дня.
Но главное — люди. Самые крутые прорывы происходили не когда каждый сидел в своей "комнате", а когда дизайнеры советовались с DevOps про цвета в графиках, маркетологи обсуждали с разработчиками техническую терминологию, а все вместе придумывали, как лучше объяснить пользователям ценность продукта.
Честно про MVP и поиск beta-тестеров
Давайте будем откровенными — MergeSensei пока что MVP. Да, он работает и уже помогает нашим командам экономить время на ревью. Но AI иногда ошибается в контексте, интерфейс местами сырой, а некоторые edge cases мы ещё не покрыли.
Именно поэтому нам критически важна обратная связь от технических руководителей, которые каждый день сталкиваются с болью code review.
Мы подготовили короткую анкету для CTO и техлидов — 5 минут вашего времени помогут нам понять реальные потребности команд и правильно развивать продукт.
Заполните форму и получите:
Early access к MergeSensei до публичного релиза
Особые условия использования для участников исследования
Влияние на roadmap развития продукта
Прямую связь с командой разработки для feedback
Интересно участвовать? Напишите в комментариях "хочу форму" или в личку — отправлю ссылку на анкету.
Нам важно понять, как разные команды организуют code review, какие есть болевые точки и что критически нужно автоматизировать. Ваш опыт поможет сделать MergeSensei действительно полезным инструментом.
Что дальше: планы развития MVP
За два месяца после хакатона мы не остановились. MergeSensei уже используют несколько команд, и фидбек помогает понять, в каком направлении двигаться.
Ближайшие планы:
Улучшение точности анализа на основе реального фидбека пользователей
Поддержка дополнительных языков программирования (Java, Go, Ruby)
Гибкая настройка правил под специфику разных команд
Интеграции с Slack, Teams и популярными task-трекерами
Система обучения AI на паттернах конкретной команды
Техническое развитие:
Более глубокая интеграция с GitHub/GitLab API
Поддержка monorepo и сложных архитектур
Анализ не только отдельных файлов, но и архитектурных зависимостей
Кастомные правила для enterprise-клиентов
Главный урок для CEO
Хакатон показал: иногда самые важные бизнес-решения нужно принимать не в переговорной комнате, а в 2 ночи, когда в голове складывается правильная картинка.
48 часов сфокусированной работы могут стоить месяцев обычной разработки. Но только если у тебя есть команда, которая готова рисковать вместе с тобой.
MergeSensei пока что MVP, далёкий от идеала. Но это живой продукт, который уже помогает разработчикам тратить меньше времени на рутину. И это только начало.
Используете ли вы AI-инструменты в своих процессах разработки? Готовы ли протестировать наш MVP и поделиться фидбеком? Пишите в комментариях или напрямую — давайте вместе делать code review эффективнее!