Или почему искусственный интеллект уже меняет 1С, управление проектами и саму профессию
Есть фраза, которая звучит грубо, но довольно точно описывает текущий момент:
джуниор с ИИ - обезьяна с гранатой;
мидл с ИИ - почти сеньор;
сеньор с ИИ - сеньорище в кубе.
На первый взгляд - шутка. На второй - наблюдение из практики. На третий - почти стратегия выживания на ближайшие годы.
Если вы джуниор и уже тянетесь поставить минус, не спешите. Я не про то, что начинающие специалисты глупые. Все мы когда-то начинали и копировали код с форумов, не дочитав ветку до конца. Просто новый инструмент в разных руках даёт очень разный результат.
ИИ не сделал всех разработчиками, архитекторами и руководителями проектов. Опыт и здравый смысл никуда не делись. Зато появилась скорость: огромная у того, кто понимает, куда едет, и ровно такая же у того, кто уверенно едет не туда.
Особенно хорошо это видно в мире 1С.
1С всегда была не только про код
Со стороны может показаться, что 1С - это конфигуратор, справочники, документы, регистры, отчёты, обработки, формы и язык запросов.
Но человек, который реально вёл внедрение, знает: код - только видимая часть айсберга.
Под кодом лежит организация. Под организацией - люди. Под людьми - привычки, страхи, должностные обязанности, прошлые ошибки, «так у нас всегда было» и, конечно, «а в старой программе эта кнопка была слева».
Проекты редко проваливаются только из-за плохой процедуры в модуле. Гораздо чаще проблемы начинаются с неясной постановки, слабого обследования, незафиксированных ожиданий, размытой ответственности или попытки автоматизировать хаос.
Ошибка в коде хотя бы имеет строку, стек и шанс быть воспроизведённой. Неправильно понятая цель проекта способна месяцами выглядеть как нормальная работа.
Вот сюда и приходит ИИ. Волшебной кнопки «сделай проект успешным» у него нет. Зато есть способность разогнать самого специалиста. Дальше всё зависит от того, кого именно разгоняют.
Джуниор с ИИ: обезьяна с гранатой
Самая опасная история сегодня - начинающий специалист, который получил доступ к ИИ и решил, что теперь умеет делать проекты.
Он может за полчаса написать письмо заказчику, подготовить протокол, составить план внедрения, сгенерировать техническое задание и получить кусок кода. Всё выглядит убедительно: текст гладкий, план аккуратный, код похож на рабочий. В документе даже есть красивые подзаголовки.
Проблема в том, что джуниор ещё не всегда понимает, что именно ему выдали.
Он может не заметить, что в плане нет опытной эксплуатации. Что в ТЗ отсутствуют критерии приёмки. Что письмо создаёт лишнее обязательство перед заказчиком. Что предложенный код можно запускать на копии, но очень не хочется видеть на продуктивной базе.
ИИ дал гранату. А человек радуется, что она блестит.
Раньше джуниор ошибался медленно. Теперь он может ошибаться быстро, красиво и с хорошим форматированием.
Запрещать начинающим ИИ было бы странно. С ним действительно можно учиться быстрее. Но я бы не убирал из этой схемы тестовую базу, ревью и старшего коллегу, который успеет посмотреть результат до того, как граната окажется у заказчика.
Мидл с ИИ: почти сеньор
У мидла уже есть внутренняя система координат.
Он понимает, что за просьбой «сделайте кнопку» скрывается процесс. Что бухгалтерия, кадровики, расчётчики, ИТ-служба и руководство могут видеть одну задачу совершенно по-разному.
Он уже обжигался на исходных данных, которые «вот-вот пришлют», на незафиксированных договорённостях и на приёмке без нормальных сценариев. Обычно отличает ошибку от нового требования, симптом от причины, срочность от громкости голоса в телефонной трубке.
И главное - мидл уже способен спорить с ИИ.
Он не воспринимает первый ответ как истину. Просит конкретику. Добавляет контекст. Отбрасывает ерунду. Требует второй вариант. Сверяет с документацией. Переписывает половину ответа и не испытывает по этому поводу никакой религиозной драмы.
Именно поэтому мидл с ИИ становится почти сеньором.
За ночь он, конечно, не получает десять лет опыта. Просто путь от сырого вопроса к рабочему решению становится короче. На встречу с сеньором можно принести не туманную проблему, а список вопросов, черновик ТЗ, тестовые сценарии и несколько вариантов решения.
ИИ не выдаёт вместе с подпиской ответственность и архитектурную зрелость. Но он заметно укорачивает лестницу до следующего профессионального уровня.
Сеньор с ИИ: сеньорище в кубе
Сеньор и раньше мог разобраться в сложной задаче, провести обследование, выбрать архитектуру, увидеть риск за маленькой просьбой и отстоять позицию перед заказчиком.
С ИИ он не становится автоматически умнее. Он становится шире.
За один вечер он успевает разобрать проблему, проверить несколько гипотез, подготовить письмо, собрать проверочный список, набросать код и объяснить всё это человеческим языком руководству заказчика. Раньше на такую обвязку легко уходило несколько вечеров.
ИИ работает как интеллектуальный экзоскелет: не заменяет мышцы и голову, но позволяет поднять больше.
Так и появляется «сеньорище в кубе». Не сверхчеловек со всеми ответами, а нормальный опытный специалист, который успевает сделать больше и реже вязнет в оформительской рутине.
Ответственность, разумеется, остаётся у человека. Модель акт не подпишет и на неприятный разговор с заказчиком вместо нас не пойдёт. Пока что.
ИИ как джинн: желание нужно формулировать правильно
В детстве я любил истории про джиннов. В них всегда была одна важная деталь: джинн действительно исполнял желание, но формулировать его нужно было очень аккуратно.
Попросил богатство - сундук золота упал на голову. Попросил вечную жизнь - получил вечную старость. Попросил дворец - оказался с ним посреди пустыни.
Я ходил и думал: а что, если когда-нибудь встречу джинна? Как загадать желание так, чтобы он не выкрутился? Нужно описать контекст, предусмотреть исключения, указать ограничения и обязательно добавить: «без вреда для меня и окружающих».
Прошли годы. Джинна из лампы я не встретил.
Зато встретил искусственный интеллект.
Вместо лампы - окно чата. Вместо дыма - токены и контекстное окно. А принцип тот же: желание нужно формулировать правильно.
Если попросить:
Напиши план внедрения 1С.
ИИ напишет план. Красивый, общий и вполне приличный. Такой документ можно вставить в презентацию, если очень хочется. Управлять реальным проектом по нему будет сложно.
Если уточнить:
Подготовь план внедрения 1С:ЗУП 3.1 КОРП для производственного предприятия. Учти обследование, методологию расчёта, загрузку начальных данных, права доступа, интеграцию с бухгалтерией, обучение, опытную эксплуатацию, параллельный расчёт, критерии приёмки и риски запуска.
результат станет гораздо полезнее.
А если добавить:
Раздели зоны ответственности исполнителя и заказчика. Для каждого этапа укажи входящие данные, результат, критерий завершения, риск задержки и способ фиксации замечаний.
получится уже не просто текст, а рабочий черновик управленческого документа.
ИИ не читает мысли. Он не знает, кто у заказчика принимает решение, почему спорят главный бухгалтер и директор по персоналу, когда заканчивается договор и что слово «доработка» означает для каждой из сторон.
Если не дать ему этот контекст, он выдаст красивый средний ответ.
А проектам не нужны красивые средние ответы. Им нужны конкретные решения в конкретных обстоятельствах.
Как превратить «нам неудобно» в задачу
Заказчик часто приходит не с задачей, а с ощущением боли:
- «Нам неудобно».
- «У нас не сходится».
- «Сделайте как раньше».
- «Нужно автоматизировать».
- «Нужно срочно».
Для джина все эти пожелания прекрасны: исполняй как понял, а потом наблюдай за последствиями. Для проекта они плохи. Непонятно, где границы, кто принимает результат и по чему вообще определять, что задача сделана.
Руководителю проекта или аналитику приходится распутывать это руками.
Не «сделайте удобно», а: какой сценарий выполняет пользователь, сколько раз в день, где теряет время, что должно появиться на экране и кто подтвердит корректность.
Не «у нас не сходится», а: какой отчёт, за какой период и организацию, с каким источником сравниваем и где именно возникает расхождение.
Не «сделайте как раньше», а: какое поведение старой системы обязательно сохранить, какое сложилось исторически, а какое противоречит новой методологии.
Не «нужно срочно», а: какой бизнес-риск наступит сегодня, завтра или через неделю; что можно сделать временно, а что потребуется для промышленного решения.
Маленький пример: «не сходится зарплата»
Возьмём простой обезличенный пример. Такое в том или ином виде происходило у каждого, кто занимался расчётом зарплаты.
Исходная просьба:
У нас опять не сходится зарплата. Нужно срочно исправить.
Прежде чем просить ИИ найти решение, я бы задал хотя бы такие вопросы:
- За какой период и по какой организации обнаружено расхождение?
- Что сравнивается: расчётный листок, свод начислений, отражение в учёте или выплата?
- Проблема у всех сотрудников или у отдельной группы?
- Какие виды расчёта и документы затронуты?
- Есть ли контрольный пример и ожидаемый результат?
- Что менялось перед появлением проблемы?
- Кто подтверждает правильность методологии?
После этого ИИ можно дать обезличенные факты и попросить:
Отдели подтверждённые данные от предположений. Сформулируй гипотезы причин, недостающую информацию, безопасный план диагностики и критерии устранения проблемы. Не предлагай изменять данные до проверки гипотез на копии базы.
Ответ после этого становится заметно лучше, но запускать предложенные действия всё равно рано. Сначала сверяем конфигурацию и релиз, отделяем методологию от технической ошибки и проверяем всё на копии.
Со временем у меня сложилась простая шпаргалка для таких запросов:
Контекст → исходные данные → сценарий → ограничения → ожидаемый результат → критерии приёмки → риски → формат ответа → способ проверки.
Магии в ней нет. Просто с такой заготовкой красивой бесполезности получается меньше.
ИИ в проекте - не только про код
Код никуда не делся. Запросы, расширения, обработки, формы, обмены, регистры, роли и фоновые задания остаются.
ИИ может написать черновик процедуры, объяснить ошибку, предложить структуру запроса, проверить очевидные проблемы и помочь с интеграцией.
Но реальная задача обычно начинается раньше кода и заканчивается позже него. Нужно понять, что делать, согласовать границы, проверить результат, запустить изменение и объяснить его пользователям.
Я использую ИИ для подготовки вопросов к обследованию, черновиков ТЗ, протоколов, планов запуска, тестовых сценариев, писем и инструкций. Именно для подготовки. Письмо перед отправкой читаю сам, архитектуру проверяет архитектор, код должен пережить ревью и тесты. Если документ получился плохим, объяснение «это нейросеть написала» заказчика почему-то не успокаивает.
Когда красивому ответу нельзя верить
ИИ может сослаться на несуществующий механизм платформы, смешать возможности разных релизов, предложить код для упрощённого примера или превратить предположение участника встречи в установленный факт.
Опаснее всего не очевидная глупость, а правдоподобный ответ. Явную ерунду мы замечаем сразу. Хорошо оформленная ерунда получает номер задачи и спокойно едет дальше.
Я обычно смотрю на три вещи. Сначала проверяю факты: существуют ли вообще упомянутые объекты и механизмы. Потом примеряю ответ к нашей конфигурации, организации и договору. И наконец задаю неприятный вопрос: что случится, если выполнить эту рекомендацию буквально?
Раньше опытный специалист отличался тем, что знал ответ. Теперь он ещё и понимает, какой ответ можно принять, какой нужно уточнить, а какой лучше сразу отправить обратно джинну.
Разные ИИ - разные роли
Одной универсальной кнопки «сделай хорошо» пока не получилось. Для кода 1С логично смотреть в сторону 1С:Напарника: он работает в 1C:EDT и видит контекст проекта. ChatGPT у меня чаще выступает собеседником и редактором, когда нужно покрутить требования, письмо или документ. Claude Code удобен там, где нужно пройтись по файлам проекта, разобраться в логике и внести изменения в кодовую базу.
Через год названия и возможности наверняка поменяются. А рабочая формула, думаю, останется:
человек + ИИ + проверенные данные + рабочий процесс + ответственность.
Новые языки больше не выглядят стеной
Есть ещё один эффект, который мне особенно нравится. Раньше новый язык программирования выглядел стеной: сначала курсы, документация, сотня непонятных ошибок, и только потом какой-то результат. Сейчас ИИ помогает хотя бы найти дверь.
Для интеграций вокруг 1С нужны программные интерфейсы (API), Python, JavaScript, SQL, Docker, локальные модели. Появляется и поиск по корпоративной базе знаний с подстановкой подходящих фрагментов, тот самый Retrieval-Augmented Generation (RAG). Во всё это стало проще зайти через маленький рабочий прототип.
Профессионалом во всех стеках от этого не становишься. Синтаксис модель переведёт, а особенности среды выполнения, безопасность и эксплуатацию придётся изучать самому. Но первого шага я теперь не боюсь так, как раньше.
Мечта о локальном ИИ в закрытом контуре
Для промышленности, предприятий государственного оборонного заказа (ГОЗ) и организаций с жёсткими требованиями к безопасности публичное облако подходит не всегда.
Сейчас я ещё не приезжаю к заказчикам с готовым локальным ИИ в чемодане. Но именно так я хочу работать примерно через год.
Первые подходящие инструменты уже появляются. Например, компактные системы класса NVIDIA DGX Spark и ASUS Ascent GX10 на чипе GB10 позволяют запускать серьёзные модели локально. Это уже не серверная стойка и не фантастика - скорее мощный настольный ИИ-компьютер, который можно поставить рядом с рабочим ноутбуком.
Мой ближайший план: собрать и обкатать такой переносной рабочий контур. Хочу приезжать на обследование, поднимать локальную модель на собственном оборудовании и показывать её на разрешённых или обезличенных материалах. Данные заказчика никуда не увозим и в облако не отправляем. На месте можно показать поиск по документации, сопоставление регламентов, разбор ошибок и подготовку проектных документов.
Но настоящая мечта выглядит ещё интереснее.
Я хочу, чтобы вся эта мощность со временем поместилась в обычный ноутбук. Если же работа идёт с реальными данными, модель и база знаний должен разворачивать сам заказчик внутри своего контура. Мы привозим методику, сценарии и требования к модели, помогаем всё настроить, но данные остаются там, где им положено быть.
Начну со своего прототипа на компактном оборудовании и демонстраций на синтетических данных. Дальше хочется дойти до нормальной схемы: заказчик разворачивает модель в своей инфраструктуре, а уже там подключает документацию, регламенты и проектные материалы с привычными для предприятия правами доступа.
Слово «локально» само по себе ничего не гарантирует. Придётся согласовывать модель и среду выполнения, разбираться с внешними соединениями, телеметрией, правами, журналами и обновлениями. Зато всё это уже похоже на обычную инженерную работу, а не на фантастику. До ИИ в ноутбуке мы ещё не дошли, но дорога хотя бы стала видна.
Что будет дальше
Честный ответ: не знаю. Неясно, насколько глубоко ИИ войдёт в конфигуратор, какие модели нормально заработают локально и что останется от привычного разделения на разработчика, консультанта и руководителя проекта.
Пока очевидны две вещи. Игнорировать эти инструменты становится всё труднее, а верить им на слово всё ещё нельзя. Значит, придётся учиться работать с ними: давать контекст, не разбрасываться данными и не перекладывать ответственность на окно чата.
Главный вывод
ИИ не превращает плохого специалиста в хорошего. Если у человека хаос в голове, хаос просто начнёт выпускаться быстрее и в красивом оформлении. Знания дают возможность проверить ответ, а опыт помогает понять, о чём вообще стоило спросить.
Поэтому формула остаётся прежней:
джуниор с ИИ - обезьяна с гранатой;
мидл с ИИ - почти сеньор;
сеньор с ИИ - сеньорище в кубе.
Грубо? Конечно. Зато запоминается.
Гранату можно научиться использовать аккуратно. До сеньора всё равно придётся дорасти. А «сеньорище» остаётся обычным человеком, которому в конце концов отвечать за результат.
В детстве я мечтал встретить джинна и долго думал, как правильно загадать желание.
Похоже, мечта сбылась. Только джинн оказался не в лампе, а в окне чата.
Теперь вопрос не в том, исполнит ли он желание. Вопрос в том, понимаем ли мы сами, чего хотим.
А как у вас? Где ИИ уже дал измеримую пользу в 1С-проекте, а где вы получили убедительный, но неверный результат?
Автор: Файзрахманов Айрат, руководитель «Акрус-Про».
Вступайте в нашу телеграмм-группу Инфостарт