Джуниор с ИИ - обезьяна с гранатой. Мидл с ИИ - почти сеньор. Сеньор с ИИ - сеньорище в кубе

Или почему искусственный интеллект уже меняет 1С, управление проектами и саму профессию

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

джуниор с ИИ - обезьяна с гранатой;
мидл с ИИ - почти сеньор;
сеньор с ИИ - сеньорище в кубе.

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

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

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

Особенно хорошо это видно в мире 1С.

1С всегда была не только про код

Со стороны может показаться, что 1С - это конфигуратор, справочники, документы, регистры, отчёты, обработки, формы и язык запросов.

Но человек, который реально вёл внедрение, знает: код - только видимая часть айсберга.

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

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

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

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

Джуниор с ИИ: обезьяна с гранатой

Самая опасная история сегодня - начинающий специалист, который получил доступ к ИИ и решил, что теперь умеет делать проекты.

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

Проблема в том, что джуниор ещё не всегда понимает, что именно ему выдали.

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

ИИ дал гранату. А человек радуется, что она блестит.

Раньше джуниор ошибался медленно. Теперь он может ошибаться быстро, красиво и с хорошим форматированием.

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

Мидл с ИИ: почти сеньор

У мидла уже есть внутренняя система координат.

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

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

И главное - мидл уже способен спорить с ИИ.

Он не воспринимает первый ответ как истину. Просит конкретику. Добавляет контекст. Отбрасывает ерунду. Требует второй вариант. Сверяет с документацией. Переписывает половину ответа и не испытывает по этому поводу никакой религиозной драмы.

Именно поэтому мидл с ИИ становится почти сеньором.

За ночь он, конечно, не получает десять лет опыта. Просто путь от сырого вопроса к рабочему решению становится короче. На встречу с сеньором можно принести не туманную проблему, а список вопросов, черновик ТЗ, тестовые сценарии и несколько вариантов решения.

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

Сеньор с ИИ: сеньорище в кубе

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

С ИИ он не становится автоматически умнее. Он становится шире.

За один вечер он успевает разобрать проблему, проверить несколько гипотез, подготовить письмо, собрать проверочный список, набросать код и объяснить всё это человеческим языком руководству заказчика. Раньше на такую обвязку легко уходило несколько вечеров.

ИИ работает как интеллектуальный экзоскелет: не заменяет мышцы и голову, но позволяет поднять больше.

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

Ответственность, разумеется, остаётся у человека. Модель акт не подпишет и на неприятный разговор с заказчиком вместо нас не пойдёт. Пока что.

ИИ как джинн: желание нужно формулировать правильно

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

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

Я ходил и думал: а что, если когда-нибудь встречу джинна? Как загадать желание так, чтобы он не выкрутился? Нужно описать контекст, предусмотреть исключения, указать ограничения и обязательно добавить: «без вреда для меня и окружающих».

Прошли годы. Джинна из лампы я не встретил.

Зато встретил искусственный интеллект.

Вместо лампы - окно чата. Вместо дыма - токены и контекстное окно. А принцип тот же: желание нужно формулировать правильно.

Если попросить:

Напиши план внедрения 1С.

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

Если уточнить:

Подготовь план внедрения 1С:ЗУП 3.1 КОРП для производственного предприятия. Учти обследование, методологию расчёта, загрузку начальных данных, права доступа, интеграцию с бухгалтерией, обучение, опытную эксплуатацию, параллельный расчёт, критерии приёмки и риски запуска.

результат станет гораздо полезнее.

А если добавить:

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

получится уже не просто текст, а рабочий черновик управленческого документа.

ИИ не читает мысли. Он не знает, кто у заказчика принимает решение, почему спорят главный бухгалтер и директор по персоналу, когда заканчивается договор и что слово «доработка» означает для каждой из сторон.

Если не дать ему этот контекст, он выдаст красивый средний ответ.

А проектам не нужны красивые средние ответы. Им нужны конкретные решения в конкретных обстоятельствах.

Как превратить «нам неудобно» в задачу

Заказчик часто приходит не с задачей, а с ощущением боли:

• «Нам неудобно».
• «У нас не сходится».
• «Сделайте как раньше».
• «Нужно автоматизировать».
• «Нужно срочно».

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

Руководителю проекта или аналитику приходится распутывать это руками.

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

Не «у нас не сходится», а: какой отчёт, за какой период и организацию, с каким источником сравниваем и где именно возникает расхождение.

Не «сделайте как раньше», а: какое поведение старой системы обязательно сохранить, какое сложилось исторически, а какое противоречит новой методологии.

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

Маленький пример: «не сходится зарплата»

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

Исходная просьба:

У нас опять не сходится зарплата. Нужно срочно исправить.

Прежде чем просить ИИ найти решение, я бы задал хотя бы такие вопросы:

1. За какой период и по какой организации обнаружено расхождение?
2. Что сравнивается: расчётный листок, свод начислений, отражение в учёте или выплата?
3. Проблема у всех сотрудников или у отдельной группы?
4. Какие виды расчёта и документы затронуты?
5. Есть ли контрольный пример и ожидаемый результат?
6. Что менялось перед появлением проблемы?
7. Кто подтверждает правильность методологии?

После этого ИИ можно дать обезличенные факты и попросить:

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

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

Со временем у меня сложилась простая шпаргалка для таких запросов:

Контекст → исходные данные → сценарий → ограничения → ожидаемый результат → критерии приёмки → риски → формат ответа → способ проверки.

Магии в ней нет. Просто с такой заготовкой красивой бесполезности получается меньше.

ИИ в проекте - не только про код

Код никуда не делся. Запросы, расширения, обработки, формы, обмены, регистры, роли и фоновые задания остаются.

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

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

Я использую ИИ для подготовки вопросов к обследованию, черновиков ТЗ, протоколов, планов запуска, тестовых сценариев, писем и инструкций. Именно для подготовки. Письмо перед отправкой читаю сам, архитектуру проверяет архитектор, код должен пережить ревью и тесты. Если документ получился плохим, объяснение «это нейросеть написала» заказчика почему-то не успокаивает.

Когда красивому ответу нельзя верить

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

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

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

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

Разные ИИ - разные роли

Одной универсальной кнопки «сделай хорошо» пока не получилось. Для кода 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С-проекте, а где вы получили убедительный, но неверный результат?

Автор: Файзрахманов Айрат, руководитель «Акрус-Про».