История и опыт создания axium.pass с помощью ИИ

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

Большинство материалов о разработке с ИИ строятся вокруг небольших проектов:

• лендингов;
• чат-ботов;
• простых CRM;
• тестовых проектов.

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

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

Как мы решили задействовать ИИ

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

Результат оказался интереснее, чем ожидалось. Разработку, которую коллеги оценивали примерно в 350–400 часов, удалось завершить за 120. При этом ИИ не написал продукт самостоятельно и не избавил инженера от сложных технических решений. Он взял на себя другую роль — ускорил работу там, где раньше уходили часы рутинной разработки, поиска информации и проектирования.

Когда проблема не в паролях, а в управлении доступами

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

1. Кто имеет доступ к продакшен-серверу?
2. Почему маркетолог видит пароли, которые нужны только разработчикам?
3. Кто поменял пароль от рекламного кабинета?
4. Что произойдет, если сотрудник уволится, а доступы останутся привязаны к его личному аккаунту?
5. И самый неприятный вопрос: можно ли восстановить историю действий, если произошел инцидент?

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

Одной из самых болезненных проблем оказались поиск и невозможность корректно настроить права на отделы и на каждого сотрудника, функция удаления не работала. Чтобы найти нужную запись, приходилось помнить ее точное название. Нельзя было найти запись по URL, логинам, комментариям или заметкам. Когда в хранилище несколько тысяч записей, поиск становится не просто неудобством, а отдельной задачей. 

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

Тогда и появилось решение разрабатывать собственный сервис.

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

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

Когда говорят об использовании ChatGPT (Codex) в разработке, обычно представляют, как разработчик открывает редактор кода, пишет промпт и получает готовую функцию. Но все произошло иначе.

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

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

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

1. Как разделить ответственность между сервисами?
2. Каких пользователей стоит изолировать?
3. Где провести границы между модулями?
4. Как избежать сильной связанности компонентов?

На поиск ответов уходит время, особенно если разработчик работает один.

Диалог с языковой моделью заметно ускорил процесс. ChatGPT предлагал варианты, объяснял их сильные и слабые стороны, помогал посмотреть на архитектуру под другим углом. Часть рекомендаций вошла в финальную реализацию практически без изменений. Некоторые пришлось серьезно переработать. От отдельных решений отказались полностью.

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

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

При этом нельзя сказать, что ИИ «написал сервис». Большая часть пользовательского интерфейса создавалась в тесной связке разработчика и нейросети. Логика отображения секретов, работа с вложенными папками, темная тема, адаптивность, оформление элементов, фавиконы, логотипы сервисов и десятки небольших UX-решений реализовывались с помощью ChatGPT и Cursor. Разработчик не писал этот код вручную — он формулировал промпты, анализировал результат, уточнял требования и дорабатывал запросы до тех пор, пока реализация не стала соответствовать задумке. 

Где искусственный интеллект действительно экономит время

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

Во-первых, это работа с типовыми конструкциями. Любой современный сервис состоит не только из уникальной бизнес-логики. Значительную часть проекта занимают контроллеры, DTO, схемы валидации, модели данных, сервисы, обработка ошибок, типизация и другие элементы, которые разработчики пишут практически в каждом проекте. На их создание уходит много времени, хотя они редко представляют инженерную сложность.

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

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

Еще одна область, где ИИ оказался неожиданно полезен

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

Почему самые сложные задачи остались за человеком

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

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

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

Похожая ситуация сложилась с интеграцией Битрикс24. На первый взгляд задача выглядела довольно простой: авторизовать пользователя через корпоративную учетную запись и автоматически синхронизировать организационную структуру. Но синхронизация оказалась значительно сложнее самой авторизации.

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

Промежуточный вывод

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

Не менее сложной оказалась система управления правами. В большинстве менеджеров паролей доступ предоставляется так: пользователь либо видит запись, либо нет. В корпоративной среде такой модели недостаточно.

Во время разработки была реализована трехуровневая система наследования прав: хранилище, папка и отдельная запись. Пользователь может получить доступ ко всему хранилищу, только к определенному разделу или даже к одному конкретному паролю. При этом важно учитывать наследование прав, запреты, роли подразделений и синхронизацию со структурой компании в Битрикс24.

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

Почему скорость работы зависит не только от кода

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

Поэтому одной из задач стала оптимизация производительности.

В качестве технологической основы были выбраны:

• React и Vite — для клиентской части;
• NestJS и TypeScript — для серверной логики;
• PostgreSQL 16 — в качестве основной базы данных;
• Prisma ORM — для работы с ней;
• Redis 7 — для кэширования.

Такое сочетание технологий позволило разделить ответственность между слоями приложения и избежать лишних обращений к базе данных. 

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

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

После релиза работа только начинается

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

Основная часть замечаний касалась не стабильности системы, а сценариев использования. Где-то некорректно наследовались права после изменения структуры папок. В отдельных случаях пользователи видели не тот набор записей, который ожидали. Некоторые элементы интерфейса по-разному вели себя в светлой и темной теме. Отдельной доработки потребовала адаптивная версия сервиса и работа с перекрывающимися панелями.

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

Что нельзя проверить без реальных пользователей

Безопасность — область, где ИИ не может быть последней инстанцией

В проекте использовалось шифрование AES-256-GCM, журналирование действий пользователей, разграничение прав доступа, ограничение частоты запросов, авторизация через Битрикс24 и HTTP-only cookies. Каждое из этих решений решает свою задачу, но вместе они формируют многоуровневую систему защиты.

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

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

Что показал этот проект

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

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

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

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

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

Это не отменяет необходимости разбираться в технологиях. Скорее наоборот. Чем выше квалификация разработчика, тем больше пользы он получает от таких инструментов.
В нашем случае такой подход позволил сократить сроки разработки почти втрое — с предполагаемых 350–400 часов до 120. Однако было бы неправильно объяснять эту разницу только использованием ИИ. Результат стал возможен благодаря сочетанию нескольких факторов: продуманной архитектуре, современному стеку технологий, глубокому пониманию предметной области и использованию искусственного интеллекта там, где он действительно помогает ускорить работу.

Вместо заключения

История создания axium.pass показала одну простую вещь. Искусственный интеллект уже сегодня способен существенно изменить процесс коммерческой разработки. Но его роль сильно отличается от той, которую ему часто приписывают:

• Он не принимает архитектурные решения.
• Не знает особенностей конкретного бизнеса.
• Не отвечает за безопасность.
• Не проектирует удобный пользовательский опыт.

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

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