Hacker News Digest

Почему LLM не могут строить ПО

Эффективный инженер постоянно прокручивает цикл:

1. формирует ментальную модель требований,
2. пишет код,
3. проверяет, что он реально делает,
4. сверяет модели и правит код или требования.

LLM умеют писать и обновлять код, запускать тесты, логировать, но не умеют держать в голове ясную модель. Они путаются: считают, что всё работает, не понимают, где ошибка — в коде или в тесте, и при раздражении сносят всё и начинают заново. Человек же, столкнувшись с проблемой, может «свернуть» контекст, сфокусироваться на детали, затем вернуться к общей картине.

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

LLM полезны: быстро генерируют код и документацию, справляются с простыми задачами. В сложных случаях человек всё равно должен контролировать требования и проверять результат. В Zed верят в совместную работу человека и агента, но руль остаётся за инженером, а LLM — лишь инструмент.

• LLM хороши как инструменты-ассистенты: быстро пишут boilerplate, находят мелкие ошибки, экономят время на рутине.
• Главный недостаток — неспособность удерживать и «поддерживать» целостную ментальную модель задачи; контекст «размывается» или меняется непредсказуемо.
• Поэтому при росте кодовой базы отладка превращается в «чтение спагетти», и инженер всё равно вынужден начинать заново.
• Решение — не «больше контекста», а системы-обёртки: TDD-циклы, пошаговое планирование, документация-модель, строгие промпты.
• Вывод: сейчас LLM заменяют джунов и Google-поиск, но полноценное ПО без человека, который держит «теорию» проекта в голове, построить не могут.

Введение

Я часто использую отладчик, но привык и к выводной отладке, особенно в юнит-тестах. Хотелось улучшить её и чаще подключать отладчик.

Улучшение выводной отладки

Главная проблема — «шум»: в цикле интересна одна итерация, а печатается всё. Или удобнее читать форматированную структуру, но приходится раскидывать print’ы по коду. В Zig тесты используют error’ы, значит можно печатать только при падении теста через errdefer:

test { errdefer std.debug.print("{f}", .{ast}); // ... }

Так контекст появляется только при ошибке, без засорения лога.

Запуск тестов в отладчике

Просто запустить seergdb или gdb -tui неудобно: тестовые бинарники лежат в zig-cache. Трюк из ziggит: build.zig может запускать команды и передавать путь артефакта:

// seergdb — GUI фронтенд для gdb const debugger = b.addSystemCommand(&.{ "seergdb", "--run", "--" }); debugger.addArtifactArg(exe_unit_tests);

const debug_step = b.step("debug", "Run unit tests under debugger"); debug_step.dependOn(&debugger.step);

Это запускает правильный бинарник. Но отладчик сработает лишь на брейкпоинте или панике, тогда как раннер тестов «проглатывает» ошибки.

Комбинация трюков

Добавим @breakpoint через errdefer:

test { errdefer @breakpoint(); }

Так мы попадаем в точку ошибки, видим контекст и вывод std.testing.expect*. Минус: при zig build test отчёт показывает падение всего шага тестов, а не отдельных кейсов. Нужна возможность включать брейкпоинты выборочно.

Условная компиляция

Через build options пробрасываем флаг, решающий, вызывать ли @breakpoint в тестах.

Минимальный скрипт сборки, запускающий тесты, дополняем опциями:

const std = @import("std");

pub fn build(b: *std.Build) void { const target = b.standardTargetOptions(.{}); const optimize = b.standardOptimizeOption(.{});

const lib = b.addModule("zig-test-patterns", .{
    .root_source_file = b.path("src/root.zig"),
    .target = target,
    .optimize = optimize,
});

const options = b.addOptions();
options.addOption(bool, "debugger", false);
lib.addImport("config", options.createModule());

const mod_tests = b.addTest(.{ .root_module = lib });
const run_mod_tests = b.addRunArtifact(mod_tests);

const test_step = b.step("test", "Run tests");
test_step.dependOn(&run_mod_tests.step);

}

В коде тестов:

const std = @import("std"); const config = @import("config");

test "errdefer @breakpoint()" { errdefer if (config.debugger) @breakpoint(); return error.FixMe; }

test "no breakpoint" { return error.FixMe; }

zig build test — без брейкпоинтов. Но менять значение флага так — значит пересобирать build.zig. Добавим опцию прямо в систему сборки:

var options = b.addOptions(); const use_debugger = b.option( bool, "debugger", "Enables code intended to only run under a debugger", ) orelse false; options.addOption(bool, "debugger", use_debugger);

Теперь можно переключать поведением командой:

zig build -Ddebugger test

И, при желании, привязать шаг запуска отладчика к этому флагу.

• Участники хвалят согласованность базовых конструкций Zig: минимализм синтаксиса и мощь comptime позволяют элегантные решения без излишней сложности.
• Особый интерес вызвал errdefer: многие отмечают, что это упрощает тесты и отладку; звучит мнение, что такую возможность «стоит иметь каждому языку».
• Обсуждают практики отладки: полезны советы по интеграции дебаггера в build.zig, что избавляет от ручного поиска исполняемого файла в кэше.
• Поднимается вопрос об ошибках без полезной нагрузки в Zig: при парсинге (например, JSON) типовые ошибки вроде UnexpectedToken недостаточно информативны; интересуются паттернами передачи дополнительного контекста.
• Есть замечание о смешении стилей именования (camelCase в stdlib vs snake_case у автора), что может сбивать с толку.
• Отмечают эстетику сайта и блога: шрифты (Berkeley Mono), цветовую схему и ретро-оформление — «как в старых DOS-играх».
• Проводится параллель с D: аналогичная идея реализована через scope(failure), что подчеркивает общность концепции.