Прогресс нейросеток за год

На примере кейса.

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

Как бы я решал год назад:
- Настроил тех. журнал на CALL и LEAKS
- Погрузился в воспоминания о том как пользоваться grep'ами, sed'ами, чтобы посчитать топ по memory в calls
- То же самое для регулярок — и как говорится, если у тебя 1 проблема, в которой тебе необходимо пользоваться регулярками, то у тебя уже как минимум 2 проблемы
- Ну и дальше небыстрая ручная отладка кода, т.к. сам процесс в котором течет память может около часа выполняться

Как сделал сейчас:

Настроил тех. журнал (надо же руками самому хоть что-нибудь делать). Попросил copilot в vscode написать скрипт на питоне для выборки событий с top по memory в CALLS, потом скрипт который по связанным с call событиям leaks посчитает частоту всех стеков вызовов.

Передал результаты в Claude Code (sonnet 4.5, opus тогда еще не вышел) - попросил сделать deep research с субагентами по исходникам. CC нашел проблему: в ДокументDOM устанавливаются пользовательские данные со ссылками на узлы этого документа, которые в свою очередь ссылаются на этот ДокументDOM - циклическая ссылка, утечка найдена.

Предложил 2 варианта: полный с существенным рефакторингом (ок, добавим в бэклог в redmine) и быстрый - сделать а-ля деструктор, просто в цикле очистить пользовательские данные во всех узлах DOM.

У меня сомнения - не верю что можно так просто безболезненно почистить DOM, наверняка он используется по стеку далее.

Ок, но мы уже хорошо знаем LLM и его вероятностную природу, когда при разных запусках получаем отличающийся результат. Использую методику мультисэмплинга (подсмотрено у GPT 5 Pro и Gemini DeepThink): прошу Claude Code сделать ревью через группу субагентов, каждый из которых делает один и тот же ревью с небольшими различиями в инициирующем промпте, а затем оркестратор выбирает лучший ответ или агрегирует результаты. Оркестратор подтверждает — все ок, объект можно чистить. Верим.

Но смущает чистка DOM циклом - это не самая дешевая операция, размер дерева может быть приличным.

Ок, у нас есть более ленивый, но более эрудированный Gemini 3 в copilot — отправляю ему результаты исследования, прошу предложить другие варианты (не уточняя, что мне не нравится цикл). Gemini и без моих наводок приходит к выводу, что циклы не подходят, и предлагает найти нужные узлы через XPath — это будет гораздо быстрее, т.к. поиск по сути на голом C++ (на libxml). Круто, а я об этом и не подумал!

Gemini пишет код → скриптами загружаю в ИБ → запускаем процесс → проверяем память в Grafana (дашборды которой тоже настроил с gemini) → проверяем тех. журнал → и с первой же попытки утечки пофикшены. Ну и куда без супервизии — решение со своей стороны еще раз детально проверил.

Секундомером не замерял, но ускорение x2 получил точно. Еще и в параллели занимался другой задачей.

Может и выглядит немного хаотично — но такие точечные задачи идеальны чтобы потестить разные подходы. Сам R&D — самое сложное, а автоматизировать отлаженный процесс уже дело техники. Параллельно у себя выстраиваем инфраструктуру: промпты под типовые задачи, документация для ИИ, MCP-серверы, AI-assisted сервисы.