Писать код руками - моветон

Писать код руками - моветон

Скажу неприятную вещь: просто писать код руками уже становится моветоном.

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

ИИ пишет быстрее. Не всегда правильно, часто самоуверенно, иногда откровенно мимо. Но быстрее. И спорить с этим бессмысленно.

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

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

Это продолжение трех предыдущих материалов:

• как устроен конвейер разработки 1С-задач;
• практический кейс работы конвейера на задаче 1С;
• 1C Skills для ИИ-агентов.

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

Ручной код больше не подвиг

У 1С-разработчиков есть понятная гордость за ремесло. Мы привыкли знать, где что лежит, как устроены формы, как собрать внешнюю обработку, где поправить роль, как вытащить данные запросом, как не развалить макет. Это нормальная инженерная память, она никуда не делась.

Но давайте честно: огромное количество нашей работы - это не гениальное проектирование, а повторяемые действия. Создать каркас. Добавить команду. Прокинуть реквизиты. Написать типовой запрос. Собрать EPF. Проверить, что форма открывается. Еще раз поправить. Еще раз собрать.

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

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

А результат в 1С - это не текст в модуле. Результат - это собранный артефакт, который загружается, открывается, работает на нужной конфигурации и проходит проверку.

Агент без среды начинает фантазировать

Когда начинаешь давать ИИ задачи по 1С, первые результаты реально радуют. Он быстро пишет код, уверенно объясняет, что сделал, прикладывает файл. Смотришь и думаешь: ну все, сейчас разработка поедет.

А потом открываешь результат в нормальной тестовой базе.

И выясняется, что EPF не подключается. Или CFE собрался, но не накладывается. Или форма есть, но команда в интерфейсе не появилась. Или агент взял реквизит, которого в этой конфигурации нет, потому что "обычно он там бывает". Особенно мило, когда в ответе написано "проверено", а проверка состояла из просмотра собственного diff.

Вот тут романтика заканчивается.

Проблема не в том, что ИИ плохой. Проблема в том, что агент без фактов и ограничений начинает достраивать мир сам. Для текста это терпимо. Для кода хуже. Для 1С с метаданными, формами, ролями, СКД, MXL и расширениями - совсем веселая история.

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

Новый навык разработчика: строить условия

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

Что это значит на практике:

• дать агенту точные метаданные выбранной конфигурации, а не заставлять его гадать;
• разложить задачу на стадии, чтобы разработка не притворялась проверкой;
• выдать skills под конкретный тип работы: CFE, EPF, формы, MXL, СКД, роли;
• дать инструменты, через которые агент может спросить факты;
• подготовить тестовую базу;
• описать критерии готовности так, чтобы их можно было проверить;
• собрать артефакт, а не оставить набор исходников;
• потребовать доказательства проверки;
• не выпускать результат без review.

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

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

Skills: не инструкция "будь умным", а короткий поводок

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

А импровизация внутри XML формы 1С - удовольствие на любителя.

Хороший skill говорит агенту не "сделай красиво", а примерно следующее:

• если делаешь CFE, работай через правильную структуру расширения и валидируй результат;
• если делаешь EPF, собирай обработку, а не оставляй набор исходников;
• если трогаешь форму, не пиши хрупкий XML руками, когда есть генератор;
• если делаешь MXL, используй компиляцию из описания;
• если меняешь роль, проверь Rights.xml;
• если задача видимая пользователю, не забудь bridge или UI-проверку.

То есть skill - это не магия. Это список мест, где агент уже раньше бился лбом, и теперь мы не хотим смотреть этот сериал заново.

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

MCP: не гадать, а спрашивать

Вторая часть - инструменты. Можно сколько угодно писать агенту "не угадывай метаданные", но если у него нет способа их получить, он все равно начнет угадывать. Просто с более виноватым видом.

MCP в такой схеме нужен как канал к фактам. Агент должен иметь возможность спросить:

• какие объекты есть в конфигурации;
• как устроена форма;
• какие реквизиты реально существуют;
• какая версия платформы и конфигурации;
• собрался ли артефакт;
• загрузилось ли расширение;
• открылся ли объект в 1С;
• что реально получилось после рендера отчета или печатной формы.

Для 1С это критично. Название объекта может быть почти очевидным, но "почти" потом превращается в час отладки. Реквизит может называться не так. Команда может лежать не там. Форма может быть заимствована не полностью. Расширение может собраться локально, но не загрузиться в конкретную базу.

Без инструментов агент изображает опытного разработчика. С инструментами у него меньше поводов играть в экстрасенса.

Конвейер вместо большого промпта

Первое желание понятное: написать агенту огромную инструкцию.

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

На бумаге отлично. В жизни так себе.

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

Поэтому нужна не простыня текста, а конвейер:

• Research разбирается в задаче, конфигурации и рисках.
• Development меняет исходники.
• Build собирает CFE, EPF, ERF или другой артефакт.
• Runtime checks проверяют поведение в тестовой базе.
• UI checks открывают клиент 1С, если задача видимая пользователю.
• Review смотрит не на красивые слова, а на артефакт и доказательства проверки.

Главное правило простое: стадия разработки не объявляет победу. Она только передает результат дальше.

Dev-agent может быть хоть трижды уверен, что все сделал правильно. Без сборки, проверки и review это не "готово", а "я очень надеюсь".

Пример: печатная форма

Пользователь просит сделать печатную форму заказа клиента с товарами, ценами и итоговой суммой.

Старый подход:

• агент написал код;
• приложил EPF;
• сказал "готово".

На этом месте надо не радоваться, а задавать занудные вопросы. EPF вообще подключается? Команда появилась? Документ выбран правильный? Табличная часть читается из реальных данных? Итог считается так, как нужно? Макет формируется? В MXL есть то, что обещано?

Нормальный процесс выглядит иначе. Сначала агент выясняет конфигурацию и документ. Потом создает или меняет обработку. Потом сборка EPF. Потом подключение к тестовой базе. Потом формирование печатной формы на реальном тестовом документе. Потом сохранение MXL/HTML/TXT. И только после этого можно говорить предметно.

Если есть только файл без проверки - это заготовка.

Если есть скриншот без MXL/HTML/TXT - это слабое доказательство.

Если есть слова "я проверил" без артефактов проверки - это вообще не доказательство.

Пример: расширение CFE

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

Поэтому для CFE важны простые вещи:

• расширение реально собралось;
• оно реально загрузилось в тестовую базу;
• база после этого обновилась;
• нужный сценарий реально работает;
• итоговый CFE - тот самый файл, который будет отдан дальше.

Слова "должно работать" тут не принимаются. В 1С вообще надо осторожнее с этим "должно". Платформа иногда имеет свое мнение, и спорить с ней бесполезно.

Доказательства проверки

Сбор доказательств проверки звучит как лишняя бюрократия. Но без него агентная разработка превращается в спор по ощущениям.

Что можно считать доказательствами:

• лог сборки;
• JSON-результат проверки;
• MXL печатной формы;
• HTML или TXT рендера;
• скриншот UI, если он действительно нужен;
• ссылка на собранный артефакт;
• сведения о тестовой базе и версии платформы;
• список стадий, которые прошла задача.

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

"Агент проверил" - слабая фраза.

"EPF собран, подключен к тестовой базе, печатная форма сформирована на таком-то документе, сохранены MXL и HTML" - уже разговор.

Review должен быть вредным

Самая бесполезная версия review - это когда он пересказывает отчет dev-agent:

Агент внес изменения, ошибок не обнаружено.

Спасибо, очень помогло.

Нормальный review должен быть вредным. В хорошем смысле. Он должен блокировать результат, если нет сборки, нет проверки в 1С, нет reusable-теста, нет доказательств проверки, непонятны acceptance criteria или артефакт невозможно воспроизвести.

Да, это замедляет процесс. Но знаете, что замедляет сильнее? Отдать пользователю "готовый" файл, который не открывается.

В агентной разработке review - это не украшение. Это тормоз, который мешает уверенной ерунде доехать до пользователя.

К чему я пришел

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

Разработчик будущего в 1С - это не человек, который просто быстрее всех печатает BSL. Это человек, который умеет:

• подготовить метаданные;
• описать задачу проверяемо;
• выбрать нужные skills;
• дать агенту инструменты;
• собрать артефакт;
• прогнать проверки;
• потребовать доказательства;
• заблокировать результат, если он не готов.

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

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