После вебинара мне несколько раз задали один и тот же вопрос: «И что, ИИ теперь сам хорошо пишет ABAP и программисты станут не нужны?»

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

Но в SAP так почти никогда не бывает.

Вебинар позволил увидеть, что аудиторию интересует не красивая теория. Вопросы были о другом: какой инструмент выбрать, где появляется реальное ускорение, что уже проверено на практике, как работать без утечки данных, что делать со старым кодом, документацией, закрытым контуром и интеграцией (см. Рис. 1). Иными словами, вопрос не в том, пишет ли ИИ ABAP. Пишет. Вопрос в том, когда этот код можно использовать как черновик, а когда он начинает выглядеть надежнее, чем есть на самом деле.

Рис. 1. Актуальные интересы аудитории

Почему тема стала острой

У ABAP-команд сейчас понятная ситуация. С одной стороны, ИИ действительно помогает на отдельных участках работы: при генерации кода, составлении документации, анализе старой логики, рефакторинге legacy-кода, поиске ошибок и разборе дампов.

С другой стороны, команды работают не с какой-то известной учебной системой. На практике приходится сталкиваться с неопределенностью, неполнотой и даже противоречивостью. Годы доработок, Z-код, слабая документация, нестандартные зависимости и объекты, которые писали люди, давно ушедшие из проекта, не проходят бесследно. Для таких сценариев удачная демонстрация легко сбивает с толку. Кажется, что еще немного — и модель можно будет пустить в боевую систему разработки почти без оговорок.

Вот здесь и нужна осторожность.

Спорить о том, умеет ли ИИ писать ABAP, уже поздно. Умеет. Настало время для следующего вопроса: «В каких задачах он безопасно экономит время, а где выдает красивую заготовку, которую еще рано считать готовым решением?»

Где ИИ уже помогает

Есть класс задач, где ИИ выглядит вполне уместно.

На вебинаре я показывал пример генерации ABAP-кода по стандартным таблицам учебной системы. Модель строит метод по таблицам SPFLI и SFLIGHT, делает JOIN, вычисляет свободные места, добавляет фильтрацию. На слайде с агентством путешествий это хорошо видно: такие задачи подходят для ИИ, потому что они локальны, шаблонны и легко проверяются (см. Рис. 2).

Рис. 2. Генерация ABAP-кода с ИИ

Здесь ИИ полезен не потому, что «понял систему лучше разработчика». Он просто быстро собирает повторяемую конструкцию. Если задача короткая, понятная и проверяемая, выигрыш по времени появляется без вопросов.

В таких местах ИИ снимает рутину:

• набрасывает «болванку» метода;
• помогает собрать черновик отчета;
• пишет первичные комментарии;
• предлагает структуру;
• объясняет старый фрагмент кода;
• помогает быстрее понять чужой код.

То же относится к документации и первичному разбору legacy. В презентации это вынесено отдельно: FORM → CLASS, ABAP Doc, объяснение старой программы, точки входа, зоны риска, черновик функциональной спецификации (см. Рис. 3). Это не отменяет проверки человеком. Но снижает порог входа в неприятную задачу.

Рис. 3. Рефакторинг и автодокументация

Короткий критерий: чем легче человеку проверить результат, тем спокойнее можно использовать ИИ как ускоритель. Чем больше результат зависит от скрытого контекста системы, тем опаснее принимать его за готовое решение.

Где начинается риск

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

Опаснее другое: код выглядит правдоподобно, активируется и возможно даже запускается. В этот момент разработчик может решить, что программа почти готова. Но для SAP-разработки «запускается» еще не значит «можно переносить».

На вебинаре я отдельно говорил о галлюцинациях. Модель может придумать несуществующий функциональный модуль, класс или объект. Может сослаться на то, чего нет в вашей версии системы. В ABAP это особенно заметно: публичного кода для обучения моделей меньше, чем для Python или JavaScript, поэтому уверенно написанный ответ не всегда означает соответствие реальной конфигурации.

Но есть и более серьёзные риски.

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

В боевом контуре сразу появятся другие вопросы:

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

Именно здесь демонстрация заканчивается и начинается инженерная работа.

Контекст: чего модель не знает сама и что ей можно дать

Здесь важно не упростить мысль.

Нельзя сказать, что ИИ вообще не может работать с контекстом SAP-системы. Может. Как раз этому была посвящена важная часть вебинара.

Обычный чат без подключения к системе действительно работает почти вслепую. Он не видит ваши Z-таблицы, классы, пакеты, зависимости, дампы, транспортную историю и бизнес-правила. В таком режиме он опирается на общие знания и на то, что вы сами вставили в запрос.

Но есть другие варианты применения ИИ.

GitHub Copilot в Eclipse уже работает ближе к среде разработчика: он видит часть контекста рабочей области и может помогать прямо в редакторе (см. Рис. 4).

Рис. 4. Cursor и GitHub Copilot: под капотом

LSP-подобный механизм в ADT дает редактору сведения о типах, методах, ошибках и структуре кода (см. Рис. 5).

Рис. 5. Протокол языкового сервера LSP (Language Server Protocol)

RAG позволяет подложить модели документы и данные (см. Рис. 6).

Рис. 6. Генерация с дополнением данными из поиска RAG (Retrieval-Augmented Generation)

MCP идет еще дальше: через серверы и инструменты модель может видеть объекты системы, обращаться к данным, запускать действия и работать уже не только с текстом запроса (см. Рис. 7).

Рис. 7. Протокол контекста модели MCP (Model Context Protocol)

Это и есть одна из главных тем мастер-класса.

Но подключение контекста не отменяет проверку. Оно меняет характер риска.

Когда модель ничего не знает о системе, главный риск — правдоподобная выдумка.
Когда модель получает контекст, риск становится другим: права доступа, возможности подключения, зрелость MCP-сервера, read-only или write-доступ, работа под учетной записью разработчика, пакет, транспорт, аудит изменений (см. Рис. 8).

Рис. 8. Интернет-мем о новой реальности ABAP-разработки

То есть вопрос не в том «может ли ИИ узнать именно вашу систему».
Пора разбираться: «Какой именно контекст открывать для доступа ИИ, что ему разрешать делать и кто возьмет ответственность за проверку результата?»

Как очертить границу фронта работ ИИ на середину 2026 года

Я бы проводил границу не между «ИИ умеет» и «ИИ не умеет». Такая постановка вопроса слишком груба.

Пока перед нами типовая выборка, черновой отчет, «болванка» класса, комментарии к методу, первичный разбор старого фрагмента или другая типовая задача, ИИ можно использовать как ускоритель (см. Рис. 9).

Рис. 9. Реальный эффект использования ИИ SAP-командами на первую половину 2026 года

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

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

Мини-пример: что значит «получили — проверили — поправили»

Допустим, модель сгенерировала метод для выборки рейсов по SPFLI и SFLIGHT (см. Рис. 2). На первом шаге все хорошо: JOIN есть, условие по свободным местам есть, код читается.

Но дальше начинается проверка.

Мы смотрим:

• есть ли такие таблицы и поля именно в нашей системе;
• не нужна ли логика по SBOOK;
• что будет на реальных объемах;
• достаточно ли фильтрации;
• нужен ли ALV, CDS view или другой формат результата;
• где будет жить объект;
• пойдет ли он в транспорт;
• не спрятано ли бизнес-правило в словах промпта.

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

Это нормальная роль ИИ в ABAP-разработке на сегодняшний день.

Что проверять перед тем, как брать результат в работу

Минимальный список я бы держал перед глазами каждый раз.

Проверьте:

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

Этот список не выглядит сложным. Но именно на нем отделяется полезное ускорение от самообмана.

Отдельно про закрытый контур

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

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

В презентации были разведены несколько вариантов:

• универсальные облачные модели;
• локальные модели внутри периметра;
• SAP Joule и BTP AI;
• инструменты с IDE-интеграцией;
• сценарии с MCP.

У каждого варианта своя цена (см. Рис. 10). Облачные модели сильны, но требуют осторожности с данными. Локальные модели помогают удержать данные внутри периметра, но требуют инфраструктуры и настройки. SAP-native инструменты ближе к экосистеме SAP, но не всегда подходят для on-premise и российского контекста. MCP может дать модели доступ к системе, но именно поэтому требует особенно внимательного отношения к вопросам прав, безопасности и зрелости сервера.

Рис. 10. Сравнение ИИ-инструментов для ABAP-разработчика на первую половину 2026 года

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

Вопросы, с которыми стоит прийти на мастер-класс

Перед мастер-классом я бы предложил каждому участнику ответить на несколько вопросов:

1. Какие ABAP-задачи вы уже пробовали отдавать ИИ?
2. Где результат выглядел рабочим, но потребовал серьезной ручной проверки?
3. Какие Z-объекты, таблицы или бизнес-правила чаще всего мешают перенести удачный пример в вашу систему?
4. Какой контекст нужен модели: код, таблицы, дампы, спецификации, транспортная история?
5. Где вашей команде достаточно read-only доступа?
6. Где вы уже думаете о сценариях, в которых агент меняет систему?
7. Что для вас опаснее: утечка данных, неверный код, неконтролируемый write-доступ или уверенность команды в непроверенном результате?

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

Вместо заключения

Главный вывод после вебинара я бы сформулировал так.

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

Но из этого не следует, что ИИ уже можно считать готовым исполнителем в реальной SAP-системе.

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

Что дальше

На вебинаре мы успели показать это в обзорном формате: инструменты, живые примеры, ограничения, вопросы безопасности и первые сценарии с контекстом системы. На мастер-классе «ABAP + AI: новая скорость SAP-разработки» 19 мая 2026 года я собираюсь разобрать эту тему уже подробнее: что действительно работает в ABAP-разработке, как давать модели контекст, где уместен MCP, как не создать лишние риски и как выстроить работу с ИИ без иллюзий.

Автор

Никита Калуцкий

Эксперт по программированию на ABAP.
Разработчик на АВАР с 2008 года.
Участник разработки стандартного кода SAP. Эксперт по качеству продуктов SAP в компании САП СНГ.
Ведущий программист компании Северсталь до 2019 года.
Главный программист корпорации «Транснефть».
Более 5 лет опыта преподавания в Учебном центре Эксперт РП.
Создатель авторских курсов по языку программирования АВАР.