Сейчас у многих возникает ощущение, что искусственный интеллект переворачивает всё, что мы знали о разработке. Ещё недавно он был забавной игрушкой, способной придумать несуществующий метод платформы и уверенно объяснить, почему именно так и нужно писать. Затем он научился дополнять процедуры, разбирать ошибки и создавать небольшие фрагменты программы. А теперь мы постепенно привыкаем к мысли, что перед нами уже не подсказчик, а полноценный участник процесса разработки.
В наш тихий мир 1С, где годами царствовали понятные вещи вроде закрытия месяца, тормозов у пользователей и исправления интеграций, созданных неизвестным героем много лет назад, ИИ ворвался довольно резко. Кто-то пишет MCP-серверы, кто-то собирает собственные наборы инструкций и инструментов, кто-то уже пытается передавать агентам законченные задачи. Пока значительная часть этих решений напоминает гаражную разработку: много энтузиазма, ручной настройки, нестабильных связок и обещаний светлого будущего.
Спор вокруг происходящего обычно сводится к одному вопросу: сможет ли ИИ заменить программиста? Одни уверены, что через несколько лет большую часть кода будут писать машины. Другие указывают на ошибки моделей, отсутствие понимания предметной области и сложность реальных корпоративных систем.
Но, возможно, этот спор начинается слишком поздно.
Гораздо интереснее не то, кто будет писать код, а то, каким станет сам код, когда его основным автором и потребителем окажется не человек, а ИИ.
Мир, который казался полным
В повести Эдвина Эбботта «Флатландия» главный герой, Квадрат, живёт в двумерном мире. Для него этот мир не выглядит ограниченным. Он просто не знает, что существует направление, в котором можно выйти за пределы плоскости.
Обитатели Флатландии строят дома, создают законы, определяют общественное устройство и развивают собственную науку. Все их представления о правильном и возможном выросли из устройства двумерного пространства. Плоскость для них не упрощённая модель реальности — она и есть вся реальность.
Однажды в этот мир приходит Сфера. Но увидеть её целиком жители Флатландии не способны. Для них она появляется как точка, затем превращается в увеличивающуюся окружность, после чего снова уменьшается и исчезает. Трёхмерный объект доступен им только в виде сечения, которое помещается в привычную плоскость.
Возможно, сегодня разработка находится в похожем положении.
Мы привыкли считать понятные имена переменных, небольшие процедуры, отсутствие дублирования и знакомые архитектурные слои объективными свойствами хорошего кода. Нам кажется, что именно так и должна быть устроена качественная программа.
Но значительная часть этих правил появилась не из потребностей компьютера. Они помогают человеку разделить сложную систему на части, удержать её в голове, объяснить другому разработчику и безопасно изменить спустя несколько лет.
Процедуру рекомендуют делать небольшой, потому что человеку сложно удерживать в голове несколько сотен строк. Переменная должна иметь осмысленное имя, потому что через месяц разработчик уже не вспомнит, что означало условное Значение1. Повторение логики считается опасным, поскольку человек может исправить одну копию и забыть про остальные.
Комментарии объясняют намерение автора тому, кто придёт после него. Архитектурные слои помогают обсуждать систему на общем языке. Модули и подсистемы создают границы, внутри которых можно рассуждать о небольшом фрагменте, не пытаясь одновременно понять всю конфигурацию.
Все эти правила разумны. Без них крупная система быстро превращается в набор фрагментов, которые никто не решается трогать. Но разумны они прежде всего внутри мира, где программу пишут, читают и изменяют люди.
Мы живём внутри созданной нами Флатландии кода и почти не замечаем её границ.
Сфера пока притворяется окружностью
Современный ИИ всё ещё работает внутри нашей плоскости. Он пишет процедуры и функции, использует понятные имена переменных, разделяет логику на блоки и воспроизводит знакомые архитектурные шаблоны.
В этом нет ничего удивительного. Модели обучались на коде, созданном людьми. Задачу им ставит человек, результат оценивает человек, а принять изменения должен человеческий ревьюер. Поэтому ИИ старается быть похожим на примерного разработчика.
Иногда даже слишком старательно. Простая операция разбивается на несколько вспомогательных процедур. Вокруг локальной задачи вырастает универсальный механизм. Появляются комментарии, повторяющие название метода, дополнительные проверки и промежуточные переменные.
Мы оцениваем ИИ по тому, насколько хорошо он умеет соблюдать правила нашего мира. Радуемся, когда он правильно оформляет запрос, не путает клиентский и серверный контекст, добавляет области и даёт процедурам понятные имена.
Но это всё ещё только сечение его возможностей нашей средой разработки.
Мы просим машину написать человеческий код, потому что пока не умеем принимать другой результат. Нам нужно открыть изменения, просмотреть строки и убедиться, что новый участник команды не сделал ничего странного.
Поэтому ИИ сегодня не создаёт новую культуру разработки. Он подражает старой.
Но если код будет создавать одна машина, проверять вторая, а изменять третья, человеческая читаемость может перестать быть главным критерием качества.
Для машины длинная процедура не обязательно представляет ту же проблему, что для человека. Ей не нужно помнить спустя полгода, что означает переменная: смысл можно каждый раз восстанавливать из структуры программы, тестов и связанных объектов. Она способна находить несколько похожих реализаций, одновременно изменять их и проверять общий результат.
Человек последовательно открывает форму, модуль объекта, общий модуль и движения документа, постепенно собирая картину происходящего. Машина потенциально может воспринимать их как единый граф данных, зависимостей, состояний и ограничений.
То, что для нас является естественной структурой программы, для неё может оказаться только способом уложить объёмную систему в доступную человеку плоскость.
За пределами человеческой архитектуры
Представим разработку, в которой человек больше не просматривает каждую строку реализации. Он описывает ожидаемое поведение, задаёт ограничения и определяет, как проверить результат. После этого один агент строит программу, другой анализирует её, а автоматический контур выполняет тесты и сопоставляет фактическое поведение с заданным.
Код в такой системе всё ещё существует, но его форма и роль меняются.
Он может стать значительно более подробным или, наоборот, предельно компактным. В нём могут появляться повторения, которые сегодня сочли бы архитектурным дефектом. Для разных сценариев агент сможет создавать отдельные реализации вместо единого универсального механизма. Часть программы, возможно, вообще перестанет существовать как привычный текст и будет представлена графами, моделями или структурами, удобными для машинной обработки.
Главным станет не то, насколько легко человек может прочитать программу, а то, насколько надёжно машина способна её создать, проверить и изменить.
Особенно заметно это станет в отношении дублирования и универсальности.
Сегодня одинаковая логика в нескольких местах считается опасной, потому что человеку трудно сопровождать её синхронно. Поэтому разработчик стремится вынести повторение в общий модуль или универсальный механизм. Но вместе с устранением дублирования появляется новая связанность: общий механизм получает параметры, режимы, исключения и должен учитывать потребности нескольких подсистем одновременно.
Если агент способен находить все реализации, изменять их вместе и заново проверять, баланс может измениться. Несколько простых специализированных процедур иногда окажутся выгоднее единой абстракции с десятком параметров.
То же относится к универсальным конструкторам. Мы создаём их не только из любви к хорошей архитектуре, но и потому, что ручная разработка стоит дорого. Если нескольким документам требуется похожее согласование, кажется естественным построить один универсальный механизм.
Однако универсальность постепенно обрастает условиями и исключениями. В какой-то момент механизм, созданный ради упрощения, сам превращается в отдельную сложную систему.
Если реализацию можно быстро восстановить из общего описания, машина сможет создавать несколько локальных решений вместо одного универсального. При изменении общего правила она просто пересоздаст их.
Для человека это выглядит расточительством: зачем делать пять реализаций, если можно сделать одну? Для машины вопрос может звучать иначе: зачем сопровождать сложную универсальную абстракцию, если пять простых реализаций можно каждый раз автоматически получить из одного набора правил?
ИИ не просто ускорит создание привычных архитектурных решений. Он может изменить экономические причины, по которым мы эти решения выбираем.
Это не будет мир без правил. Просто вместо человеческой культуры читаемости возникнет машинная культура проверяемости.
Когда код станет результатом сборки
Сегодня код считается одним из главных активов проекта. Его стараются сохранить, аккуратно расширять и не переписывать без необходимости. В этом есть понятная причина: создание работающей реализации требует времени, а при её замене легко потерять накопленные знания и неочевидные исключения.
Но что произойдёт, если реализацию можно будет заново получить за несколько минут?
Первые признаки такого отношения уже заметны в небольших задачах. Иногда проще повторно сгенерировать тест, преобразование данных или прототип интерфейса, чем разбираться в неудачной первой версии. Пока это работает в простых и изолированных фрагментах, но по мере развития инструментов границы будут расширяться.
Если система достаточно полно описана требованиями, тестами и ограничениями, код можно будет воспринимать как результат сборки. Изменилось правило — изменилась спецификация, после чего агент заново создал затронутую часть реализации.
Разработчики давно привыкли не редактировать вручную машинные инструкции, сформированные компилятором. Мы изменяем исходный текст и выполняем сборку снова. В будущем привычный исходный код тоже может стать промежуточным представлением, которое создаётся для выполнения на конкретной платформе.
Тогда проекту потребуется другой устойчивый источник истины:
-
модель предметной области;
-
правила изменения данных;
-
ограничения и инварианты;
-
контракты интеграций;
-
сценарии поведения;
-
требования к безопасности;
-
критерии производительности;
-
автоматические тесты.
Фактически исходным текстом станет не программа, а формальное описание того, как система должна себя вести.
Например, вместо указания, в какой процедуре нужно сформировать движения документа, можно определить правила хозяйственной операции. После проведения количество товара на одном складе должно уменьшиться, а на другом увеличиться. Общее количество в рамках операции не должно измениться. Проведение запрещено при недостаточном остатке, а повторная операция не должна создавать дополнительные движения.
Сегодня разработчик переводит эти условия в код, опираясь на собственное понимание платформы и конфигурации. В машинной разработке агент сможет выбрать техническую реализацию, а другой инструмент — проверить соблюдение заданных свойств.
Важнее станет правильно описать операцию, чем заранее определить структуру процедуры проведения.
Особенно наглядно этот подход проявляется в интеграции с внешней системой.
Сегодня разработчик изучает документацию API, создаёт структуры запросов и ответов, пишет преобразование данных, обработку ошибок, повторные попытки и журналирование. Значительная часть работы представляет собой перевод контракта внешней системы в код конкретной конфигурации.
В будущем человек сможет описать сам контракт обмена: какие данные передаются, как сопоставляются объекты двух систем, какие поля обязательны, что считать успешной операцией и как действовать при частичном отказе.
Отдельно задаются гарантии. Один документ не должен отправляться дважды. Повторный запрос не должен создавать дубли. Ошибка связи не должна приводить к потере данных. Результат каждой операции должен оставаться доступным для расследования.
На основании этих условий агент создаёт объекты метаданных, очередь, обработчики отправки, преобразование форматов, повторные попытки и диагностические механизмы.
Если внешняя система выпускает новую версию API, человеку не обязательно вручную переделывать старый адаптер. Он изменяет контракт, после чего техническая реализация создаётся заново.
Главным активом становится не конкретная процедура формирования JSON и не ручной разбор HTTP-ответа, а правила обмена и гарантии, которые интеграция обязана обеспечивать. Код превращается в одну из возможных реализаций контракта.
Для мира 1С это не настолько далёкая идея, как может показаться. Мы уже работаем не только с программным текстом. Конфигурация состоит из документов, справочников, регистров, ролей, форм и правил их взаимодействия. Значительная часть системы описана декларативно, а код является лишь одним из элементов реализации.
В будущем конфигурацией может стать набор моделей, правил и ограничений, из которых агент создаёт конкретное прикладное решение. Человек определяет, какие сущности существуют, как они связаны, что разрешено и каким должно быть наблюдаемое поведение. ИИ выбирает техническую форму: какие метаданные создать, где разместить логику и каким способом обеспечить заданные свойства.
Возможно, разработка будущего действительно окажется ближе к конфигурированию. Только конфигурировать мы будем уже не готовую систему, а интеллектуального исполнителя, который эту систему построит.
Следующее измерение
Здесь возникает самый неприятный вопрос.
Готовы ли мы принять в промышленную систему код, который никто из команды не понимает построчно, если его поведение описано и автоматически проверено?
Первой реакцией, вероятно, будет отрицание. В корпоративной системе слишком высока цена ошибки. Нельзя доверять реализации, которую человек не способен прочитать и объяснить.
Но насколько хорошо мы понимаем системы уже сейчас?
Ни один прикладной разработчик не читает исходный код платформы перед использованием транзакций, блокировок или механизма запросов. Мы не проверяем вручную каждую машинную инструкцию, которую компилятор создаёт из нашего кода. Мы пользуемся СУБД, операционными системами и библиотеками, устройство которых знает лишь небольшая группа специалистов.
Доверие к ним строится не на способности каждого разработчика прочитать всю реализацию. Оно возникает из воспроизводимого поведения, тестирования, наблюдаемости и накопленного опыта эксплуатации.
Возможно, с машинно-генерируемым кодом появится похожая модель. Мы не будем понимать каждую строку, но будем знать, какие свойства система обязана сохранять, как они проверяются и что произойдёт при нарушении ограничения.
Конечно, полностью описать поведение сложной корпоративной системы чрезвычайно трудно. Но и сегодня программа не становится правильной только потому, что её способен прочитать человек. Большинство серьёзных ошибок возникает не из-за непонятного синтаксиса, а из-за неполных требований, неверных предположений и неучтённых взаимодействий.
Читаемость помогает найти ошибку. Она не гарантирует её отсутствия.
При этом ответственность никуда не исчезает. Она перемещается на другой уровень.
Уже нельзя будет ограничиться выводом, что разработчик неправильно написал условие. Реализацию создала машина, формально выполнившая поставленную задачу. Причину ошибки придётся искать в неполной спецификации, противоречивых правилах, слабых тестах или неверно заданных ограничениях.
Чем меньше человек участвует в написании кода, тем больше он отвечает за условия, в которых код возникает: за качество исходной модели, полноту проверок, доступ агента к данным и границы его самостоятельности.
Это потребует более зрелой разработки, а не меньшего участия специалистов.
Сегодня часть неоднозначности можно спрятать внутри реализации. Разработчик самостоятельно трактует неполное требование и пишет код, который кажется ему разумным. В мире автоматической генерации такие пробелы станут опаснее: агент способен последовательно распространить неверную трактовку по всей системе.
ИИ может взять на себя реализацию. Но человеку придётся намного точнее определить, что считать правильным результатом.
Самая интересная сцена «Флатландии» происходит уже после того, как Квадрат поверил в существование третьего измерения. Увидев свой мир сверху, он почти сразу предполагает, что за третьим должно существовать четвёртое.
Но Сфера, только что учившая его мыслить шире, сама отвергает эту возможность.
Выход из одного ограничения не гарантирует освобождения от всех остальных. Новое устройство мира очень быстро тоже начинает казаться окончательным.
Возможно, машинно-генерируемый код не станет последней стадией. Пока мы всё ещё представляем, что ИИ будет создавать процедуры, модули и метаданные — пусть непонятные человеку, но похожие на сегодняшнюю программу.
Однако реализация может перестать существовать как устойчивый текст вообще. Она будет возникать из правил под конкретную задачу, среду и момент исполнения, а затем пересоздаваться при изменении условий.
Сегодня программа похожа на построенное здание: мы дополняем его, ремонтируем и стараемся не разрушить несущие стены. В будущем она может стать больше похожа на результат расчёта, который каждый раз заново возникает из модели и заданных ограничений.
Когда Квадрат увидел Флатландию из третьего измерения, её законы не перестали действовать. Они просто перестали казаться единственно возможными.
Вероятно, то же произойдёт и с культурой разработки. Понятный человеку код ещё долго будет необходим там, где люди отвечают за сопровождение и проверку реализации. Но постепенно рядом появится другой класс программ — создаваемых, изменяемых и анализируемых машинами по правилам, которые уже не обязаны учитывать ограничения человеческого восприятия.
Это не будет мир без правил. Просто читаемость, красота и привычная архитектура перестанут быть его главными законами. Их место займут проверяемость поведения, сохранение инвариантов, воспроизводимость и возможность заново получить реализацию из её описания.
Возможно, текстовый код окажется лишь первым измерением программирования. Мы прожили в нём достаточно долго, чтобы принять его границы за границы самой разработки.
Теперь перед нами появляется направление, которого раньше мы просто не видели.
И главный вопрос новой эпохи заключается уже не в том, сможет ли ИИ написать программу.
Нам предстоит понять, как определить правила, по которым ИИ будет формировать код.
Вступайте в нашу телеграмм-группу Инфостарт