Как небольшой косяк LLM мне спать не давал

posted on 2026-02-25

На днях ввечеру буквально пару часов времени потерял на пустом месте, пытаясь отдебажить кейс, в котором у меня определение функции не появлялось в пакете после перекомпиляции приложения.

• Глазами вижу в файле определение функции. Оно есть.
• Компилирую её с помощью Ctlr-C Ctrl-C – она в пакете появляется.
• Перезапускаю REPL, делаю (asdf:load-system ... ) - функции в пакете нет. Как так???

При этом при загрузке модуля с помощью asdf:load-system компилятор выдает только одно предупреждение о том, что функция не определена, но она где-то используется.

В конце концов нашел проблему – иллюстрация на картинке выше. И эта проблема была принесена LLM.

В чем же было дело? Дело в том, что, внося очередные изменения, LLM у одного определения функции убрала закрывающую скобку, а у другого определения функции добавила лишнюю закрывающую скобку. В итоге весь код, который был между первым и вторым определением функции, оказался внутри тела первой функции.

Если коротко проиллюстрировать это, можно сделать это таким кодом:

(defun foo ()
  (loop repeat 3
        do (format t "Iterating"))
  
(defun blah ()
  (format t "Blah called"))

(defun bar ()
  (blah)))

На первый взгляд тут все ок. Проблема еще состоит в том, что настоящий LISPR скобки не считает. Мы судим о структуре кода по отступам, и здесь на первый взгляд все хорошо.

Проблема в глаза не бросается, потому что LLM не заботится о том, чтобы сохранять отступы так, как это делает нормальный LISP редактор.

Если отформатировать этот код в соответствии с правилами форматирования LISP, проблема станет очевидна. Вот во что он превратится:

(defun foo ()
  (loop repeat 3
        do (format t "Iterating"))
  
  (defun blah ()
    (format t "Blah called"))
  
  (defun bar ()
    (blah)))

Внезапно сразу оказывается, что определения функций blah и bar попали внутрь определения функции foo. И компилятору Common Lisp это нормально. Никаких ошибок он не выдаёт. Такие дела :(

Осторожно: skill с сюрпризом!

posted on 2026-08-12

В одном из последних проектов я решил попробовать подход Atomic Spec. Это когда системные требования фиксируются в отдельных файлах, чтобы кодовый ассистент мог сверяться с ними при добавлении новых фич.

Начал искать skill для работы с Atomic Spec и наткнулся на GitHub репу lovely392/atomic-spec. На первый взгляд — вроде бы свежая и улучшенная версия. Но устанавливать его не спешите.

Похоже, автор взял существующий репозиторий, внёс косметические правки и залил результат как новый. Это не fork, поэтому связи с исходным проектом на GitHub не видно.

А дальше в README начинается совсем странное. Вместо инструкции по установке навыка предлагается скачать ZIP-архив, распаковать его и запустить файл на Windows. Причём там отдельно объясняют, как пройти системные предупреждения и продолжить запуск. Для skill-а кодового ассистента это выглядит, мягко говоря, подозрительно.

То есть получается такой вирус, который нужно установить самому. И это особенно неприятно в эпоху кодовых ассистентов: ассистент вполне может прочитать README, сходить по ссылке, скачать архив и выполнить инструкцию. В итоге вместо нового skill-а на компьютер может попасть какой-нибудь троян.

Это хороший повод помнить, что skills, MCP-серверы и их инструкции — тоже часть supply chain. Перед установкой стоит посмотреть, откуда взялся репозиторий, является ли он форком, что именно менялось и почему «навык» вдруг требует запустить .exe.

А тем, кому интересно попробовать Atomic Spec в работе, вот оригинальный репозиторий. Там Atomic Spec — это именно методология и skill для кодового ассистента, а не Windows-приложение из архива.

Циклическая зависимость в mgl-pax

posted on 2026-04-19

В эти выходные решал проблемку с отвалившейся named-readtables на UltraLisp.

Named-readtables библиотека довольно много где используется, и то что она стала недоступна - большая проблема.

Дебажить пришлось долго, и вот что оказалось.

Звёзды так сошлись, что:

• Ultralisp выкидывает из диста проект при ошибках проверки очередного коммита (это стоит починить • Gábor Melis намутил в своих либах циклическую зависимость, когда mgl-pax зависит от свежей версии dref и наоборот и попытался это решить с помощью либы autoload. • Процесс, проверяющий проекты в Ultralisp сам по себе зависел от старой версии mgl-pax, которая была притянута как транзитивная зависимость • Новый mgl-pax конфиликтовал со старым и не мог просто подгрузиться в образ где уже была старая версия. • Из-за этого не мог провериться dref которому нужна новая версия mgl-pax. • То есть, эти три либы mgl-pax, dref и autoload надо было обновлять все разом, а Ultralisp так не умеет.

В итоге, чтобы обновить эту пачку либ пришлось пересобрать сам Ultralisp так, чтобы там была вкомпилирована свежая версия mgl-pax. Теперь всё заработало.

Вывод - надо уменьшать количество зависимостей в бинаре, который чекает загрузку других библиотек. В идеале - до нуля!

This blog covers commonlisp, llm, codabrus, ai, codeassistant, clos, actors, learning, news, automation, voice, projects, holism, zerocoder, python, aider, cursor, project, i18n, poftheday, visualization, closed, tips, seo, telegram, bot, прототип, smarthome, yandexcloud, logging, ideas, experiment, software, thoughts, programming, hackathon, mtstruetech, robotics, problems, salebot, bots, notes, emacs, macos, lisp, failures, infrastructure, lispworks, life, идеи, mcp, sql, nix, ultralisp, tutorials, reblocks, yandex, cloud