← На главную

AOP с LLM: ИИ-ткач собирает код из аспектов

25.06.2026 22:12 · hackernews

Программисту приходится держать в голове целую кучу вещей одновременно. Корректность (программа делает то, что нужно). Эффективность (не жрёт память и CPU почём зря). Возможность отладки, поддержка, тестируемость, логирование, безопасность, расширяемость, приватность, управление зависимостями, развёртывание, мониторинг, сохранение состояния между перезапусками, проверка входных данных, обработка ошибок, интернационализация с локализацией и доступность для людей с ограничениями. И это ещё не всё — в список не попали, например, оценка сроков и общение с коллегами.

Идея Aspect Oriented Programming (AOP), которую в середине 90-х придумал Грегор Кичалес с коллегами из Xerox PARC, заключалась в том, чтобы программист мог работать с каждым из этих аспектов по отдельности, а не вплетать всё сразу в каждую строчку кода. Звучит прекрасно. Но реализация подвела. Механизм «join point model» — это, по сути, сопоставление с образцом на стеке вызовов во время выполнения. «Каждый раз, когда в стеке оказывается вызов функции открытия файла, записать имя файла в лог». Как справедливо замечает Wikipedia, это очень близко к шуточному оператору COME FROM — настолько же трудно отлаживать и поддерживать.

Однако автор считает, что новым возможностям LLM дают AOP второй шанс. Теперь в роли «ткача» (weaver) выступает языковая модель. Программист пишет отдельные документы для каждого аспекта (concern). Документ по корректности будет самым длинным, а гайд по стилю кода компании можно переиспользовать в разных проектах как документ о поддерживаемости. LLM (или несколько агентов, каждый из которых критикует код со своей точки зрения) просто собирает из этих документов итоговую программу.

Почему это лучше старого join point? Тот был хрупким: чтобы логировать каждое открытие файла, надо было жёстко прописать имена функций. Коллега добавит новую — и лог сломается. LLM же использует фоновое знание о том, что такое «открыть файл», и сопоставляет сама. К тому же результат такого «ткачества» статичен — это просто читаемый код, а не сырой байткод, как в AspectJ. LLM будут генерировать код в любом случае, так что идея AOP даёт просто удобный способ организовать инструкции (промпты), которые мы в них передаём.

Читать оригинал →