Программирование без знания языка: как ИИ уволил Doxygen
· 4 min read
В прошлой части мы остановились на том, что выбросили HTML-выдачу Doxygen в мусорное ведро. План «быстро поправить стили» полностью провалился, потому что невозможно адаптировать структуру из вложенных таблиц родом из девяностых под современный дизайн. Идея второго прототипа звучала солидно: отключить генерацию HTML, взять сырой структурированный XML от того же Doxygen и написать для него нормальный парсер.
Рабочим языком, как и в прошлый раз, выбрали Python. Он идеально подходит для создания утилит, обработки текста и автоматизации рутины. К тому же вся современная экосистема вокруг искусственного интеллекта строится именно на нем. Логика была проста: если мы хотим активно использовать нейросети для помощи в написании кода, лучше сразу писать на языке, который они знают лучше всего.
Пришло время раскрыть небольшой секрет, о котором я специально умолчал в первой части: я не знаю Python. Чужой код я плюс-минус понимаю, но сам на нём никогда ничего не писал.
Архитектор, который не умеет кодить
Это был чистый эксперимент в стиле «программирование без знания языка». Я решил выступить в роли системного архитектора и постановщика задач. ИИ должен был выполнять всю техническую работу: писать готовый код, рефакторить функции и собирать всё воедино.
Поначалу всё шло подозрительно гладко. Мы накидывали логику разбора гигантских XML-файлов. Я открывал сгенерированный Doxygen файл, видел там узлы, классы, параметры методов, и просто писал в чат: «Найди все элементы с нужными тегами, вытащи оттуда тип, имя и описание, а затем сложи это в JSON». Благодаря прямому доступу ИИ к терминалу мне даже не пришлось копировать код руками. Нейросеть сама писала скрипты, сразу их запускала и выдавала готовый результат.
Файл наполнялся функциями, скрипт рос. Мне казалось, что мы строим отличную систему. Я даже не вчитывался в код — зачем, если я и так вижу, что документация собирается всё лучше и лучше? Так продолжалось до тех пор, пока один диалог полностью не изменил ход разработки.
Когда ИИ внезапно попросил компилятор
В какой-то момент мы обсуждали переносимость нашего движка (мы уже начали называть его UDE) на другие платформы. Я хотел убедиться, что парсер заведется у любого разработчика на любой операционной системе без сложных дополнительных настроек.
ИИ выдал будничный ответ: «Конечно, проблем не возникнет. Только для полной переносимости нам потребуется настроить скачивание clang в процессе инсталляции пакета».
Я смотрел на монитор в полном недоумении. Какой ещё clang? Мы разбираем XML-документацию для Python-обертки. При чём здесь компилятор языка C? Я так прямо и спросил у нейросети, не сошла ли она с ума.
ИИ тут же извинился и выдал новую формулировку: «Прошу прощения, я имел в виду библиотеку tree-sitter. Нам понадобится компилировать её биндинги».
Инсайт из потери контроля
И тут до меня дошло: ИИ больше не парсил XML от Doxygen. Ему это надоело.
В процессе наших долгих обсуждений архитектуры нейросеть незаметно для меня подключила парсер абстрактных синтаксических деревьев (AST). ИИ сам решил, что читать оригинальный исходный код C++ и Python напрямую через tree-sitter гораздо надёжнее, чем возиться с костыльной XML-выдачей сторонней утилиты. Он просто исключил Doxygen из цепочки, пока я думал, что мы всё ещё парсим теги.
Был ли написанный им код хорошим? Понятия не имею, ведь я совершенно не умею писать на Python и не способен оценить архитектурные решения. Алгоритм мог оказаться потрясающе оптимизированным и изящным, либо представлять собой нестабильный набор костылей, работающий исключительно за счет случайного стечения обстоятельств.
Проблема заключалась в абсолютной потере контроля. Если ИИ в фоновом режиме втихую меняет архитектуру и тянет за собой тяжелые библиотеки парсинга, а ты даже не можешь прочитать его код — проект обречён. Получается классический «черный ящик». Любой минорный баг заставит тебя часами выпытывать у нейросети причины поломки. То же самое касается и нетипичных комментариев в исходниках.
Этот инцидент подарил нам важнейшее открытие. Мы поняли, что ИИ действительно способен писать собственные прямые парсеры для любых языков программирования, вытаскивая структуру классов и параметры прямо из живого кода. Нам больше не нужны сторонние утилиты.
Однако, чтобы такой сгенерированный код работал стабильно, его необходимо жёстко контролировать. Нам требовался строгий набор автоматических проверок. Такая система, которая гарантировала бы работоспособность парсера независимо от того, понимаю я написанный код или нет.
Так мы выкинули наш второй, вполне рабочий прототип в корзину. И начали всё заново, уже в третий раз. Но теперь по совершенно другим правилам — с тестированием на каждом шагу. Об этом я расскажу в следующей части.