1. Вступление
Обычно, чтобы понять, куда мы движемся, полезно оглянуться назад и посмотреть, что там, а там, как обычно, лежат ответы на вопросы "почему сегодня всё так устроено" и "что будет дальше".
Смотрите сами, весь прогресс программирования - это история повышения уровня абстракции. Каждый следующий шаг уводил нас все дальше и дальше от железа и ближе к удобству человека (программиста).
Машинные коды - ты должен был знать, какой код у микропроцессора для сложения, где лежит результат, как переключить страницу памяти.
Ассемблер - появились мнемоники, не нужно помнить коды операций микропроцессора, но всё ещё нужно думать про его регистры, стек, сегменты памяти. Где в памяти лежит переменная - это твоя забота.
C - уже можно думать алгоритмами, а не регистрами. Появились функции, типы данных. Но память всё ещё ручная: выделил - не забудь освободить, иначе утечка.
C++ - добавились объекты и полиморфизм, можно писать более крупными блоками. Но память - всё ещё твоя головная боль, хотя уже появились умные указатели.
Java/C# - пришла виртуальная машина, со сборщиком мусора. Можно вообще забыть про ручное управление памятью. Не думаешь, где объект лежит, ты просто создаёшь и работаешь.
Python/JavaScript/1С - уже не просто не думаешь про память, ты не думаешь про типы. Всё динамическое, гибкое, и все прощающее. Можно быстро набросать нужное решение, не заботясь о строгости.
Сейчас в эпоху развития ИИ мы на пороге следующего шага, но и он, мне кажется, будет НЕ последним в этой цепочке.
2. История из 90-х
Середина 90-х я учусь в университете. Наш преподаватель по дискретной математики собрал группу ребят, в которую попал и я, уж не знаю, чем он руководствовался при выборе, но тем не менее. Оказалось, что он собирал себе проектную группу для адаптации языка FORTH под новую тогда x386 архитектуру. Тогда он сумел нас заразить не только элегантностью своего предмета "Дискретная математика", но и языком FORTH, и все ребята, кого он тогда выбрал, остались в этой группе разработки до конца своего обучения.
Интересная особенность FORTH - это язык, который в основном написан на самом себе. Только ядро (базовые слова) реализовано на ассемблере - примитивы для чтения с клавиатуры, вывода на экран, работы с памятью. Всё остальное - написано на самом же языке FORTH.
Мы разделились. Кто-то из нас писал ядро, работающее в защищенном режиме микропроцессора, на ассемблере. В то время у нас была одна единственная книга про защищенный режим микропроцессора x386, выданную нам преподавателем, которую реально зачитали практически до дыр. Другие ребята писали прикладные слова для прикладного уровня языка. Мне же досталась очень объемная задача, это написание среды разработки, по типу, как тогда выглядела среда разработки борландовского Паскаля, с менюшками, окошками, многооконным редактором и отладчиком. Я сильно вдохновился этой идее и начал ее реализовывать, а впоследствии по этой теме я и защищал свой диплом.
История про текстовый редактор для моей среды разработки
Помню, в самом начале, преподаватель поставил мне задачу - подумать, как можно реализовать работу с большим текстом в моей среде разработки. Чтобы можно было вводить символы, вставлять в середину, в начало, в конец. И главное - чтобы всё работало без задержек, независимо от того, 100 символов в тексте или 100 тысяч.
Я пошёл думать. Тогда интернета не было, книжек умных по этой теме, тоже не дали - только собственная голова. День думаю, два думаю... ничего нормально не придумал. Казалось, что любое решение будет тормозить, если текст будет большой.
На третий день руководитель рассказал алгоритм, как это должно работать, и всё оказалось гениально простым.
Технология "Два стека"
Первый стек - текст до курсора.
Второй стек - текст после курсора.
Курсор - это граница между ними.
Хочешь подвинуть курсор влево на один символ? Берёшь символ из первого стека и перекладываешь во второй.
Вправо? Берёшь из второго, кладёшь в первый.
Вводишь новый символ - просто кладёшь его в первый стек.
Нажал Backspace - убрал символ из первого стека.
Вставка текста из буфера? Достаточно переложить символы из буфера в первый стек. И неважно, сколько их - сто или сто тысяч.
И никаких сдвигов массива. Никаких перестроений строки. Никаких тормозов.
Всё работает с одинаковой скоростью при любом размере текста. Потому что операция всегда одна - переложить символ из стека в стек. Стек - это просто вершина, туда класть и забирать можно мгновенно.
Это было красиво и настолько просто, что я тогда даже расстроился, что сам до этого не додумался.
Почему я так подробно разобрал эту технологию сейчас? Я хотел показать, что даже когда ИИ заменит синтаксис, фундаментальные алгоритмы никуда не денутся. Архитектору будущего не нужно будет помнить, как объявить массив в 1С или Python, но ему жизненно необходимо понимать, почему в данной задаче решение с двумя стеками лучше, чем сдвиг массива. ИИ может сгенерировать байт-код для обоих вариантов, но только человек-архитектор сможет оценить элегантность и эффективность этого решения в контексте всей системы.
Мое вдохновение и энтузиазм в то время просто зашкаливал. Помню, как после лекции по Машине Тьюринга я пришел домой, сел за свой ZX Spectrum и на встроенном Бейсике набросал программу, которая была полноценной эмуляцией этой машины. Она честно двигала виртуальную ленту, читала символы и выполняла команды согласно таблице переходов. Для меня тогда это было маленьким чудом: я увидел на практике, что любую сложную задачу можно свести к набору простейших операций. Именно тогда пришло понимание, что программа - это не просто текст, это логический механизм.
К чему все эти воспоминания? Тогда программист должен был знать железо, понимать и создавать алгоритмы. Вот реально знать: как переключать страницы памяти, прерывания микропроцессора, прерывания биоса, защищенный режим микропроцессора и т.д. Даже когда ты писал прикладные слова на FORTH, ты понимал, что под капотом - код, который дергает порты, вызывает то или иное прерывание из биос. Другого способа общаться с машиной просто не было.
Конечно тогда уже были и C и C++, но для нас в середине 90-х FORTH был способом залезть внутрь и понять, как всё устроено с нуля, а потом пришли Java, C#, Python, 1С и каждый новый язык уводил нас от железа все дальше и дальше.
3. Наше настоящее, переход от чата к агентам
Сейчас мы в эпохе, когда можно просто написать в чат "напиши алгоритм", "сделай запрос", кинуть туда процедуру и попросить что-то исправить и получить код. Правда, он не всегда может рабочий, потому что ИИ ничего не знает о вашей конфигурации. Я раньше именно так и делал. И казалось, что это круто, когда ИИ за тебя пишет код.
Но недавно наткнулся на Инфостарте, на разработку Сергея (Prepod2003) - это MCP-сервер для EDT, который позволяет ИИ напрямую работать с конфигурацией 1С. Для меня открылся вообще другой уровень.
Я установил в очередной (уже в третий раз) EDT и начал в нем разбираться, скачал плагин и попробовал ИИ в деле. Это не просто "ВАУ! КАК КРУТО!", это реально другой уровень разработки, когда ты пишешь не ПО, а ставишь задачу AI-агенту и он ее выполняет, САМ.
Правда, надо честно сказать: весь его потенциал, как и потенциал других плагинов действительно раскрывается только с платными подписками на Cursor или Claude. Лимиты, которые есть в бесплатных вариантах ИИ, не дают нормально работать. Ты больше времени тратишь на ожидание и борьбу с лимитом контекстного окна, чем на саму задачу. И в итоге выгода от работы с ИИ сводится к нулю.
Но если подписка есть - ощущения будут совсем другие.
Дисклеймер
Я не имею отношения к разработке плагина Сергея и не получаю никакой выгоды от его использования или упоминание в этой статье. Я хочу лишь сказать, что это первый инструмент, который показал мне практическую работу AI-агента с 1С. Да, похожих MCP-серверов для EDT уже несколько, я попробовал разные, но именно этот оказался для моих задач, самым удобным.
Не так давно я посмотрел новое видео, где автор, в режиме онлайн с помощью ИИ пишет обработку для ЗУП с нуля. ИИ сам создаёт форму, сам пишет код, сам его отлаживает, конечно не без участия человека, но это на порядок упрощает как разработку так и отладку, когда ИИ можно просто скопировать ошибку и он сам все поправит. Рекомендую посмотреть, хотя бы для понимания того, как уже сейчас можно вести разработку на 1С.
https://m.vkvideo.ru/video-236008654_456239021
https://www.youtube.com/watch?v=R_OMEPEk28E
Вот мой реальный кейс
Пишу запрос в курсоре:
Используй mcp сервер 1c-edt для доступа в 1с. Проблема: иногда, при пробитии чека в кассе - чек печатается, документ "ЧекККМ" сохраняется, данные в ОФД уходят, но статус чека в 1с остается как "отложен". Посмотри, в чём может быть проблема как в основной конфигурации, так и во всех расширениях, особенно в расширении "ИМЯ_РАСШИРЕНИЯ". Обрати внимание на обработку "РабочееМестоКассира", почему так может получаться?
Через пару минут получаю полный разбор: где именно (как оказалось в моём расширении) ошибка и в каком месте логика нарушается и сразу готовый вариант исправления. Где достаточно было нажать на кнопку "Принять изменения" и код будет исправлен сразу в EDT.
При этом, мне не нужно выгружать конфигурацию в файлы, править файлы, затем загружать их обратно в конфигуратор. У вас открыт EDT и код с помощью ИИ правиться там же, не закрывая при этом EDT. Ребята это фантастика!
Для меня это был момент, когда у меня в голове "щёлкнуло". Да это же не просто "чат с ИИ", а настоящий инструмент, который реально понимает контекст конфигурации. Он видел мою конфигурацию, все мои расширения, понимает всю логику, как в основной конфигурации, так и в расширениях. Он не угадывал, не придумывал, не галлюцинировал - он анализировал и выдавал готовый, рабочий код.
Экономия времени? Колоссальная.
Про лень как двигатель прогресса
Переписываясь с автором этого плагина в телеграмме, я написал ему фразу, которая, кажется, про многих из нас:
Я тоже люблю новое, но с возрастом всё труднее выходить из зоны комфорта привычного конфигуратора. Но в качестве дополнительного "пинка" для изучения EDT, может сработать, как ни странно, лень. Когда ты попробовал ИИ в работе, тебе уже лень писать все эти Если... Тогда... Иначе... самому. Ты всё понимаешь, ты можешь это сделать сам, но тебе уже просто лень.
Вот еще мой один реальный кейс:
Вчера вечером я искал косяк в древней конфигурации "Кортес" (адресное хранение). Проблема вылезла после обновления платформы. Загрузил конфигурацию в EDT, прошёлся с ИИ по коду. Проверили всё. Проблема оказалась не в коде, а в ужесточении прав в новой платформе.
Сколько времени потратил бы сам? Не знаю. Но явно больше.
Конечно, нашёл бы. Но попробовал ИИ в деле, искать самому было лень.
4. Прогноз. Почему языки программирования станут не нужны
Повторю свою мысль.
Если посмотреть на эволюцию - от машинных кодов до того, как сейчас ведется разработка ПО с помощью ИИ - видна простая закономерность.
Каждый новый уровень абстракции делал старые навыки ненужными. Кто-то должен писать компиляторы и оптимизировать ядро, но массовый программист перестал думать о регистрах микропроцессора.
Сейчас - следующий шаг, любой язык программирования, будь-то 1С, Python, Java или C# - это костыли для человеческого мозга. Нам нужен понятный синтаксис, читаемость, возможность отлаживать глазами.
Языки программирования - это костыли для человеческого мозга.
ИИ вообще не нужен синтаксис. Ему нужна семантика. Логика, связи, ограничения.
Почему языки отомрут
Зачем ИИ писать на Python или 1С, если можно сразу генерировать байт-код? Зачем этот лишний шаг - человекочитаемый синтаксис, который потом всё равно компилировать в машинный или байт-код?
ИИ может мыслить в терминах виртуальной машины. Синтаксических деревьев. Потоков данных. Ему не нужно промежуточное звено в виде языка, придуманного людьми для других людей.
Посмотрите на современные компиляторы: LLVM, MSIL. Это уже промежуточные представления, ближе к машине, чем к человеку. Сейчас мы пишем на высокоуровневом языке, компилятор транслирует в это представление. Если человек будет только ставить задачу ИИ и не будет править код руками, то зачем ИИ писать в какой-то промежуточный язык, если он может сразу подготовить байт-код?
Единая виртуальная машина
Я думаю, лет через 10 мы придём к одному из двух сценариев. Пока неясно, какой именно победит, но оба ведут к исчезновению языков программирования как прослойки.
Первый сценарий: единая глобальная виртуальная машина
Появится глобальная виртуальная машина с единой спецификацией команд. Как у Intel - есть набор инструкций, и любой процессор их понимает. Только здесь это будет виртуальная машина для бизнес-логики, единая для всех платформ.
Не важно, на чём "думал" ИИ. Важно, куда выполнить результат. Он сгенерирует универсальный байт-код, и любая платформа (1С, Java, .NET) сможет его исполнить.
Представьте: вы говорите системе (голосом, текстом - не важно) "сделай мне учёт товаров с партионным учётом и списанием по FIFO". И она не пишет код на 1С, а сразу компилирует это в байт-код для глобальной VM.
Второй сценарий: экосистема вендорских VM
Честно говоря, я больше склоняюсь к этому сценарию. Ведь крупные игроки вряд ли захотят отдавать рынок единому стандарту. У Microsoft будет своя VM, у 1С - своя, у Oracle - своя, а у SAP - своя. Возможно будет Open Source VM или другие варианты. Каждая со своей спецификацией, со своей оптимизацией под конкретные задачи.
И тогда возникает новая роль ИИ - транслятор.
Вы пишете техзадание на естественном языке: "нужен учёт товаров с партионкой и FIFO". ИИ анализирует, в какой среде это будет работать, и генерирует байт-код под конкретную VM. Для 1С - свой, для .NET - свой, для SAP - свой.
По сути, ИИ становится универсальным компилятором с естественного языка на любой целевой байт-код. А разработчик превращается в постановщика задач, который уже не думает о синтаксисе, а только о логике и ограничениях.
Что их объединяет
В обоих сценариях привычные нам языки программирования (1С, Python, Java, C#) исчезают. Потому что они были нужны как промежуточное звено между человеком и машиной. Когда это звено берёт на себя ИИ, необходимость в языках отпадает.
Остаются только:
-
постановка задачи (на естественном языке или в виде схем)
-
байт-код (как единый или как набор под разные VM)
-
ответственность человека за результат
5. Что останется человеку
Мы не исчезнем. Мы превратимся в архитекторов.
ИИ не может взять на себя ответственность. Он не понимает, почему бухгалтер на самом деле просит "разрешить отрицательные остатки" и какие будут последствия для налоговой. Не проведёт переговоры с заказчиком, не объяснит, что его хотелка сломает систему.
Роль программиста сместится от написания кода к постановке задач, проектированию архитектуры, контролю результатов. Мы будем описывать бизнес-логику на естественном языке, а ИИ-агенты - транслировать это в машинный или байт код.
Ручное написание Если ... Тогда ... Иначе станет анахронизмом, как сегодня перфокарты или как написание программы загрузки данных из EXCEL в базу данных на ассемблере.
А вы хотели бы сейчас написать такую программу именно на ассемблере?
Безусловно, в процессе работы вы бы невероятно "прокачали" свой навык программирования. Вы бы узнали многое о регистрах микропроцессора, о работе с прерываниями и распределении памяти под каждую ячейку таблицы. Но какой в этом будет смысл для бизнеса, кроме впустую потраченного времени?
Заказчику не нужны ваши глубокие познания в архитектуре CPU, ему нужны работающие бизнес-процессы, верные остатки и сданная вовремя декларация. Архитектор - это тот, кто понимает, какой инструмент (пусть даже это будет "черный ящик" от ИИ) принесет результат быстрее и надежнее. Роль программиста сместится от написания кода к постановке задач, проектированию архитектуры и контролю результатов.
Что это значит для 1С-специалистов
Если мой прогноз хоть немного похож на правду, через 10-20 лет "программист 1С" как профессия исчезнет. Останется "архитектор бизнес-процессов", который умеет:
-
Понимать, что реально нужно бизнесу
-
Проектировать учётные системы
-
Ставить задачи ИИ-агентам
-
Нести ответственность за результат
Код будет писать машина. Думать - человек.
Можно, конечно, до пенсии сидеть в конфигураторе, править отчёты для мелких клиентов. Но если работаете с серьёзным бизнесом, где цена ошибки - миллионы, меняться придётся в любом случае. Инструмент будет нужен всегда. Но инструмент станет другим.
6. Вместо заключения
Мы прошли путь от регистров до промптов. От книжки про защищённый режим, зачитанной до дыр, до MCP-сервера, который анализирует код быстрее, чем я формулирую запрос.
Остался один шаг. Когда ИИ научится писать не на языках для людей, а сразу в байт-код и тогда это будет точка невозврата. Привычные языки сразу станут не нужны. Как сегодня перфокарты и машинные коды.
Коллеги, а что думаете вы?
А я свой выбор уже сделал - пошел дальше изучать возможности EDT, промпт-инжиниринг и архитектуру агентов.
Другие статьи автора:
Вступайте в нашу телеграмм-группу Инфостарт
