AI в разработке: Почему аутсорс стал «испорченным телефоном»
За 3 года в роли руководителя веб‑направления в РОСМЭН (Игрушки) я привыкла к разным форматам разработки. Запуск сайта турнира Инфинити Надо (wsa.infinitynado.ru) показал, как развитие ИИ меняет рынок аутсорса — и какие риски несёт отсутствие глубокой экспертизы.
Контекст и проблема Дедлайны были горящими, подрядчик — проверенный (несколько спецпроектов в 2022–2024 гг.), ожидания — реалистичными: нужен был функционал, который сможет поддерживать контент‑менеджер, и стабильная работа ключевых механик. Требования к проекту были приземлёнными: - правки силами контент‑менеджера без прав администратора; - определение местоположения посетителя по IP; - масштабируемая карта с динамической подстройкой списка точек под видимую область. Результат оказался противоречивым: визуально страница с турнирами соответствовала утверждённой стилистике, а функционально — нет. Причина — ТЗ «скормили» нейросети без ручной проработки UX‑сценариев и адаптации кода под архитектуру Bitrix. Даже имея доступ к структуре сайта, подрядчик не вынес логику за рамки монолитного решения.
Последствия Подход «без ручной доработки» привёл к системным проблемам: - Монолитный HTML. Любые правки требовали прав администратора — контент‑менеджер не мог работать самостоятельно. - Нестабильная JS‑логика карты. Фильтры не применялись при скроллинге, а при смене города список точек с магазинами‑участниками не обновлялся. Это уже не мелкие недочёты: накопившиеся недоработки усложняют работу с проектом и делают каждое новое изменение более трудоёмким и дорогим.
Решение: «сам себе промпт‑инженер» Вместо передачи задач через менеджера аутсорса я взяла роль промпт‑инженера: сама формулировала инструкции для ИИ с учётом стека, архитектуры ядра Bitrix и стандартов чистого кода. Ключевой принцип — не ставить задачу в общем виде, а задавать точные технические рамки: где подключать JS‑методы, как работать с компонентами Bitrix и как обрабатывать краевые случаи. Это позволило держать код поддерживаемым и избежать накопления технического долга.
Результаты - Сроки. Страница с городами‑участниками и регистрацией запущена за 2 дня. - Метрики. За первые 3 дня на турнир в Казани зарегистрировано 20 участников. - Критичные инциденты. 1 critical ticket: письма с номерами участия попадали в спам из‑за высокого спам‑рейтинга шаблона. Проблему диагностировали и исправили. - Админка. Полностью кастомизирована под задачи модератора.
Вывод AI не заменяет разработчика, но радикально трансформирует роль менеджера. Теперь критически важно не просто ставить задачи, а уметь формулировать точные технические промты и понимать архитектуру продукта. Исправление результатов работы AI‑джуна при глубокой экспертизе оказывается в разы эффективнее долгих согласований через посредников без понимания стека — особенно в проектах на Bitrix, где архитектура и стандарты решают всё.
· 15.10
Мда.. )
Понимаю что силы, время и деньги потрачены, но это опыт.
Про монолит - сначала меня стриггерило, хотел сразу возразить, но остановился и дочитал до конца.
Битрикс "Управление сайтом" и Битрикс24 - это ядро плюс модули, ну и всё это зовётся "модульным монолитом". Фреймворк по сути монолитный, но есть микросервисные решения внутри у многих проектов, не суть.
В вашем примере, исполнитель не озаботился соблюдением достаточно не сложных рекомендаций вендора (Битрикс) для разработчиков. Возможно по причине спешки, необязательности, уровня подготовки, но также возможно ограниченности бюджета и деталей в договоре - либо чего-то вместе из всего.
То о чём вы пишете, когда контент-менеджер может безопасно и эффективно создавать, изменять и удалять страницы, новости, товары, менять заголовки, телефоны и например страницу контактов - это "Эрмитаж", специальный дружелюбный интерфейс для всего этого.
Ну и.. Я вот также себе первый интернет-магазин делал, меня кинул фрилансер в 2007/08 годах, взялся сам. А дальше стал разбираться и постепенно ушёл из торговли в разработку.
ИИ может готовить хорошие прототипы, но без хорошего дообучения не охватит и половины багажа знаний опытных синьор-разработчиков. Здесь нужен он, прямо в штат, насколько вижу ситуацию.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 15.10
Ну не знаю )) когда открываешь index.php и видишь вот такое:
SetPageProperty("title"); ?>
.map-cards-wrapper { margin: 30px auto 0 auto; ...
контенщика, который знает только html, подпускать к правкам на странице как-то боязно )) И Эрмитаж тут контент-менеджеру не сильно бы помог.
Опять-таки, с подрядчиком работали несколько лет, и к созданным ими сайтам ранее не было нареканий. Если сроки дедлайна и загрузка разработчика в команде позволяет отдать заказчику только mvp - этично было бы об этом предупредить.
Нанимать же сеньора (да и вообще брать отдельного разработчика в штат) имеет смысл только если у компании есть долгосрочные проекты - на полугодовой спец.проект логичнее все же нанимать агенство
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 15.10
Ну.. То что вы увидели - это прототип, в моём понимании просто первый этап в развитии продукта.
Тайтла для страницы мало, но всё зависит от целей которые решают раздел и страница.
Если индексная страница единственная, а раздел предполагает динамический контент (новости/материалы, товары и т.п.) внутри должен быть вызов компонента и не всегда кастомного. По регламентам разработки Битрикс важно обходиться решениями близким к нативным, чтобы обеспечить высокую ремонтопригодность.
Хотите - могу подлететь, посмотреть как-нибудь, дать обратную связь (онлайн удаленно) - где что стоит и не стоит переделать, помочь прийти к нужным решениям. Я в отпуске на данный момент.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 15.10
Спасибо, откажусь, проект уже на финальной стадии)) И, кстати, по версии подрядчика - это финальный продукт, переданный нам по акту (с правами, РИМ и прочим).
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 15.10
Ну.. Не зачёт за такой финал.
Вот рабочие три уровня: 1. Прототип (работает/решает задачу); 2. Общее соответствие некоему регламенту (у нас свой - классы с методами, psr, ооп и прочее подходящее), с выносом всего кастомного в /local/; 3. Завершенное решение (модуль, компонент, темплейт).
Выработайте свои для приёмки в будущем и успехов 🤝🫡
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён