Как всё началось
Коронавирус изменил не только формат встреч. В нашей компании он изменил и взгляд руководителя на 1С-разработку.
Однажды появилась почти революционная идея: уйти от разработки «внутри базы» и внедрить EDT вместе с Git. Реализацию поручили мне. Внешняя жизнь тогда заметно замедлилась, срочных задач меньше не стало, но появилась возможность вложиться не в очередную заплатку, а в фундамент.
Нужно было перевести конфигурацию в файловый проект, настроить ветки, договориться о правилах и убедить команду, что Git — не разновидность наказания. В EDT Git штатно используется для групповой разработки и связывает ветки с отдельными информационными базами.
Главной проблемой оказался не EDT и не репозиторий. Главной проблемой был менталитет: привычка править напрямую, держать важные знания в голове, обходить проверки «потому что срочно» и считать ручную сборку признаком профессионализма.
Постепенно появился контур: задача, ветка, разработка, проверка, сборка, тесты, релиз. Фичи стали выходить быстрее, ошибок стало меньше, а ночные ритуалы по ручной сборке — реже. Уже неплохо.
Мы строили CI/CD ради скорости и надёжности. Но заодно сделали конфигурацию доступной для автоматизации: с историей изменений, правилами, тестами и предсказуемым способом проверить результат. Позже оказалось, что именно этого AI в 1С-разработке обычно и не хватает.
Через три года
Затем я почти на три года ушёл в большой архитектурный проект. Он, как и положено серьёзному проекту, занял больше времени, чем хотелось бы. Но обещанного три года ждут — результат всё-таки появился.
Вернувшись в общий контур, я ожидал увидеть знакомую картину: накопившиеся проблемы, зависимость от нескольких незаменимых людей и срочную потребность всё спасать. Вместо этого увидел работающую архитектурную команду. Люди были на местах, процессы не развалились, контур развивался без меня.
Это, вообще-то, лучший итог архитектурной работы. Но для самолюбия есть нюанс: оказывается, система может работать и без архитектора. Невероятно, но факт.
Неприятное открытие
Вернуться в роль типового разработчика я уже не мог: опыт и интерес давно сместились в сторону архитектуры, интеграций и процессов. А сама роль типового разработчика за это время изменилась.
Коллеги внедрили AI-инструменты. Для части задач уже не нужно прежнее число junior-разработчиков: AI готовит заготовки кода, объясняет чужие модули, генерирует тесты, находит типовые ошибки и помогает пройти путь до pull request. В 1С это давно не фантастика: AI-агенты уже умеют работать с проектами 1C:EDT и создавать рабочие конфигурации.
Это не значит, что программисты исчезнут. Но ручное производство предсказуемого типового кода под постоянным контролем старшего коллеги становится менее востребованным. А контроль, архитектура и ответственность за результат — наоборот, никуда не деваются.
Получается, я не внедрял AI. Я всего лишь помог построить для него уютную квартиру: EDT, Git, тесты и CI/CD. А потом обнаружил, что новый жилец неплохо справляется без меня.
AI и рефакторинг
Наиболее сильное применение AI, по моему опыту, — не генерация кода с нуля, а рефакторинг.
Есть большая функция, где проверка прав, бизнес-логика, запросы, запись данных, сообщения и обработка ошибок живут дружной коммуналкой. Человек смотрит на неё, откладывает задачу до понедельника и заваривает кофе. AI может быстро предложить декомпозицию: выделить ответственности, убрать дублирование, дать нормальные имена и вынести повторяемые куски в отдельные функции.
То же происходит с монолитными модулями. AI хорошо раскладывает их на логические части и предлагает план миграции. Но именно предлагает: границы подсистем, контракты и порядок изменений должен подтверждать человек, который знает предметную область, а не только длину контекстного окна.
Хорошо AI помогает и с запросами: замечает лишние поля, соединения, повторные обращения к данным и подозрительные условия. Но «безошибочно оптимизирует» — слишком смелая формулировка. Запросы нужно проверять измерениями на реальных объёмах, планами выполнения и тестами. Нейросеть может написать красивый запрос, который станет красиво и медленно выполняться на десяти миллионах строк.
1С:Напарник уже способен объяснять код, искать ошибки, формировать комментарии и переписывать фрагменты по описанию — в том числе для рефакторинга. Для быстрых действий прямо в EDT это удобный помощник.
Более продвинутые модели обычно сильнее на больших контекстах, планировании и многошаговых изменениях. Но ни один из инструментов не отменяет простого правила: маленькое изменение, тесты, ревью, возможность отката.
Когда AI ведёт релиз
Я попробовал пойти дальше: некоторые небольшие изолированные проекты удавалось доводить до релиза почти без ручного погружения в каждую строку.
На входе было обычное ТЗ: сообщения заказчика, противоречивые пожелания и знаменитое «сделайте как в том отчёте, только немного иначе». Первая нейросеть превращала этот поток в постановку: сценарии, роли, ограничения, критерии приёмки и список вопросов, о которых никто заранее не подумал.
Вторая работала с формализованной задачей и файловым проектом: предлагала структуру, генерировала код, меняла модули и метаданные. Третья проверяла результат: искала противоречия, предлагала тест-кейсы, анализировала дифф и результаты прогона. После финального ревью такие релизы успешно сдавались.
AI не гарантирует качество. Он способен уверенно написать ерунду, сломать рабочую функциональность и объяснить, почему так было задумано. Поэтому ему нужен независимый контур обратной связи: тесты, ревью и CI/CD.
TDD как контракт
Здесь снова становится актуальной идея Кента Бека — Test-Driven Development. Цикл прост: сначала тест на ожидаемое поведение, затем минимальная реализация, после — рефакторинг.
В AI-разработке тест становится не просто защитой от регрессии, а машиночитаемым контрактом. Если критерии приёмки выражены проверками, AI может реализовывать задачу, запускать тесты, находить отклонения и исправлять результат. Но право отключить неудобный тест у него, конечно, должно отсутствовать.
Рабочая схема выглядит так: заказчик формулирует потребность, человек с AI превращает её в проверяемые требования, один агент реализует, другой проверяет, CI/CD фиксирует результат. Человек отвечает за то, что именно и зачем мы выпускаем.
Не отставать
В массовой разработке AI уже встроен в анализ требований, написание кода, тестирование и ревью. В 1С это движение идёт медленнее, но все технические предпосылки уже есть.
Надеяться, что будущее не наступит, — плохой план. Оно наступит в любом случае. Вопрос только в том, будем ли мы его проектировать или наблюдать за ним из очереди на обновление конфигурации.
Нам важно развивать не только умение писать код. Возрастает ценность тех, кто умеет говорить с бизнесом и заказчиком, находить настоящую потребность, формализовать её в проверяемую задачу для AI, проектировать ограничения и принимать результат.
То есть пора переставать быть только кодерами. Строки кода теперь умеет производить и машина. А вот ответственность за смысл, последствия и результат пока всё ещё подозрительно часто остаётся на людях.
Вступайте в нашу телеграмм-группу Инфостарт