Hacker News Digest

Cognition представила Windsurf Codemaps — AI-аннотированные структурные карты кода, которые помогают разработчикам понимать свои проекты перед тем, как вносить изменения. В отличие от большинства AI-инструментов, которые увеличивают разрыв между программистом и его кодом, Codemaps нацелены на углубление понимания. Как отмечает Пол Грэм: "Ваш код — это ваше понимание проблемы, которую вы исследуете. Только когда код у вас в голове, вы действительно понимаете проблему". Новая функция основана на SWE-1.5 и Claude Sonnet 4.5, предлагая два режима работы: быстрый и интеллектуальный.

Проблема понимания кода стоит остро: новым разработчикам требуется 3-9 месяцев для полного освоения проекта, а старшие специалисты тратят более 5 часов в неделю на помощь коллегам. По данным Stripe, поддержка легаси-кода — главный фактор, снижающий продуктивность. Codemaps решает эту задачу, позволяя создавать контекстные карты кода по запросу для конкретных задач. Это следующий шаг после Ask Devin и DeepWiki, делающий процесс онбординга и навигации по кодовой базе более эффективным.

• Обсуждение в основном вращается вокруг трёх тем: визуализация кода (CodeMaps), инструментов вроде Windsurf и Cursor, а также влияние LLM на понимание и навигацию по коду.
• Участники обсуждают, насколько полезны визуализации кода в больших кодовых базах и как они справляются с контекстом и бизнес-логикой.
• Также поднимается вопрос о том, что такие инструменты могут быть полезны для онбординга в новых кодовых базах, но критики утверждают, что без контекста эти визуализации не имеют ценности.
• Некоторые участники высказывают мнение, что вместо того, чтобы полагаться на визуализации, разработчики должны уделять внимание созданию и поддержанию хорошей документации.
• Обсуждение также затрагивает влияние инструментов на продуктивность и то, как они могут быть использованы в больших и сложных кодовых базах.

Разработчики всё чаще сталкиваются с увеличением времени на модификацию или исправление кода, сгенерированного большими языковыми моделями. Это явление, названное «долгом понимания», напоминает работу с унаследованными системами, где перед внесением изменений необходимо глубоко разобраться в логике и контексте кода. Однако масштаб проблемы стал беспрецедентным из-за лавинообразного роста объёмов нечитаемого кода, который ИИ-инструменты производят с огромной скоростью.

Команды, заботящиеся о качестве, тратят время на ревью и рефакторинг такого кода, сводя на нет первоначальную экономию времени. Другие же просто коммитят непроверенные и непонятые фрагменты, создавая риски на будущее. Хотя ИИ может помочь с 70% правок, остальные 30% приводят к «петлям безысходности», когда модели не справляются с задачей, и разработчикам приходится разбираться в чужом коде самостоятельно. Это накопление долга понимания становится бомбой замедленного действия для миллионов проектов.

• LLM-генерация кода ускоряет разработку, но часто приводит к сложному, плохо понятному коду, что создает долгосрочные проблемы с поддержкой и увеличивает "долг понимания".
• Мнения разделились: одни считают проблему поддержки LLM-кода преувеличенной или временной, другие видят в ней фундаментальный сдвиг, усугубляющий существующие проблемы с legacy-кодом.
• Предлагаются стратегии работы: строгий ревью, использование LLM только для тривиальных задач/черновиков, написание тестов и документации, либо полное принятие модели "черного ящика".
• Многие ожидают, что будущие LLM смогут сами понимать и поддерживать сгенерированный код, что изменит роль разработчика на более высокоуровневую.
• Параллель с прошлыми проблемами (офшорная разработка, копипаст с Stack Overflow), но масштаб и скорость генерации LLM создают беспрецедентные вызовы.

На RustConf 2025 обсуждалась совместимость Rust и C/C++, где Чендлер Каррут сравнил подходы Rust и экспериментального языка Carbon. Rust предлагает инструменты вроде bindgen и cxx для взаимодействия, но они слабо подходят для сложного legacy-кода C++ (brownfield), где тесные связи и большой API усложняют миграцию. Carbon же задуман как полностью совместимый с C++ язык, позволяющий постепенно переписывать проекты файл за файлом без смены компилятора, с акцентом на аннотации для безопасности памяти.

Каррут считает, что Rust не скоро решит проблему полной интероперабельности с C++, тогда как Carbon предлагает эволюционный путь, аналогичный переходу от JavaScript к TypeScript. Это даёт пространство для Carbon, особенно в крупных legacy-проектах, где полный переход на Rust непрактичен. Вывод: два языка могут сосуществовать, решая разные аспекты миграции к безопасным языкам.

• Обсуждается сложность и подходы к миграции с C/C++ на современные языки (Rust, Kotlin, Swift), включая инструменты для конвертации и постепенного перехода.
• Поднимаются вопросы о важности качественной интероперабельности между языками и недостатках C как языка-«клея» из-за отсутствия современных функций безопасности.
• Высказываются сомнения в универсальности Rust для полного переписывания из-за архитектурных несовпадений с идиоматическим C++.
• Отмечается, что такие проекты, как Carbon, нацелены на крупные кодобазы (вроде Google) и инкрементальный рефакторинг без полного переписывания.
• Упоминается, что принятие Rust в Linux пока ограничено (драйверы, отдельные подсистемы), а будущее Kotlin и Swift вне их экосистем (Android/Apple) остается под вопросом.

Современные ИИ-модели демонстрируют впечатляющие способности в генерации кода, но сталкиваются с серьёзными трудностями при работе с реальными задачами компиляции — устаревшими инструментами, зависимостями и кроссплатформенной сборкой. CompileBench протестировал 19 моделей на 15 практических заданиях, включая сборку проектов вроде curl и jq, компиляцию под Windows/ARM64 и даже оживление 22-летнего кода 2003 года. Некоторые агенты выполняли до 135 команд за 15 минут для получения рабочего бинарного файла.

Anthropic модели Claude Sonnet и Opus заняли лидирующие позиции по успешности сборки, подтверждая свою репутацию среди разработчиков. OpenAI модели, особенно GPT-5-mini, показали лучшую ценовую эффективность, балансируя между скоростью и качеством. Gemini от Google неожиданно провалился: модели часто игнорировали спецификации задач, например, создавали динамические вместо статических сборок, несмотря на чёткие требования.

• Сложность сборки и кросс-компиляции legacy-проектов (Chocolate Doom, curl) на современных системах, включая ARM64.
• Способность ИИ (особенно Claude Opus) автоматически исправлять ошибки сборки, хотя процесс может занимать много времени и команд.
• Предложения расширить бенчмарки более сложными проектами (FFmpeg, Chromium, Qt) и проверкой корректности через тесты и санитайзеры.
• Скептицизм относительно способности ИИ гарантировать корректность итогового бинарного кода после автоматических правок.
• Практическая ценность автоматизации рутинных задач по настройке toolchain и портированию старого кода.

Стремительный рост использования ИИ-генерации кода привёл к появлению новой рыночной ниши — услуг по исправлению ошибок, допущенных алгоритмами. Хотя 92% разработчиков уже применяют инструменты вроде Copilot, анализ 150 млн строк кода показал, что ИИ-сгенерированный код на 41% чаще подвергается правкам или откатам в течение двух недель. Исследователи из Стэнфорда обнаружили, что такой код содержит больше уязвимостей, при этом разработчики ошибочно считают его более безопасным.

Спрос на «чистку» ИИ-наследия растёт: инженеры вроде Хамида Сиддики управляют десятками проектов одновременно, беря $200–400 в час за исправление «спагетти-кода». Специализированные платформы вроде VibeCodeFixers.com уже объединяют сотни исполнителей и заказчиков. По данным ThoughtWorks, 60% проектов с ИИ требуют серьёзного рефакторинга перед выходом в продакшен. Это создаёт новые карьерные траектории: младшие разработчики, освоившие исправление ИИ-кода, могут быстро достигать уровня зарплат сеньоров.

• Рост числа проектов с низкокачественным кодом, сгенерированным ИИ (vibe coding), требующих дорогостоящей последующей доработки и "очистки".
• Сравнение ситуации с аутсорсингом: проблемы те же (плохие спецификации, низкое качество), но ИИ ускоряет генерацию кода и ошибок.
• Споры об общей эффективности: экономия времени на MVP vs. скрытые затраты на поддержку и риски безопасности.
• Сдвиг навыков: востребованы не генераторы, а "инженеры-уборщики", способные чинить и рефакторить AI-сlop.
• Прогнозы: AI-код станет новым легаси, а успех зависит от качества спецификаций и дисциплины, а не скорости генерации.

Краткий конспект «Working Effectively with Legacy Code»

«Легаси-код — это код без тестов»
(М. Фезерс, 2004)

Алгоритм работы

1. Тесты → изменения
   Сначала покрой тестами, потом трогай логику.
2. Парадокс легаси
   Чтобы добавить тесты, надо изменить код; чтобы изменять, нужны тесты.
   Решение: минимальные безопасные рефакторинги.

4 шага к тестам

1. Найти шов (Seam) – точку, где можно подменить поведение без правки исходника.
   Пример: унаследовать класс и переопределить метод.
2. Разорвать зависимости (БД, сеть, файлы).
3. Написать быстрый (< 100 мс) изолированный тест.
4. Вносить изменения и рефакторить.

Характеризационные тесты

Если логика не ясна, пишем тест, который фиксирует текущее поведение; потом рефакторим.

• Книга «Working Effectively with Legacy Code» М. Фезерса вызывает спор: кому-то она дала язык и инструменты, кому-то показалась тривиальной и неприменимой к реальному аду из VB.NET, COBOL, VBA, AS/400 и прочим диалектам.
• Главная идея «напиши тесты, потом трогай» часто невозможна: требований нет, классов нет, тест-фреймворка нет, а босс слышит «рефакторинг» как «тратить деньги впустую».
• Поэтому практики делятся на два лагеря: «сначала покрой тестами хотя бы то, что трогаешь» и «запусти новую систему параллельно, сравнивай выходы, переключайся кусочками (Strangler Fig)».
• UI, скрипты и «макро-ассемблеры» не поддаются юнит-тестам; тут спасают визуальные диффы, сторибук, продовые снимки и осторожный ручной прогон.
• Рефакторинг превращается в бесконечное «yak-shaving», если каждый шаг не привязан к новой фиче или бизнес-ценности; политика и мотивация команды важнее любой методики.

• Чёткое ТЗ — пишу заранее, чтобы агент видел контекст.
• Файл-инструкция по запуску линтервов и сборки.
• Саморевью — прошу Claude проверить свой код.
• Глобальный гайд ~/.claude/CLAUDE.md с правилами: мелкие шаги, TDD, простые решения, максимум 3 попытки при ошибке.

Качество
Я вручную читаю и тестирую всё, что выходит из LLM; отвечаю за PR независимо от автора кода.

• Ключ к успеху — писать подробные спецификации: кто-то тратит 2 часа на 12-шаговый документ и получает отличный результат, другие же считают, что даже «чистые» спеки не спасают от схода с курса и бесконечных правок.
• Мнения о CLAUDE.md разделились: одни держат файл коротким (<100 строк) и минималистичным, другие вообще не видят в нём пользы из-за «context rot» и субъективных инструкций.
• Работа с большими старыми кодовыми базами по-прежнему сложна: большинство признаёт, что Claude Code лучше справляется с новыми pet-project’ами, чем с «грязными» legacy-фичами.
• Популярные тактики: шаг-за-шагом микро-PR, TDD-агент, запуск puppeteer-тестов для «замыкания цикла», code-review собственных патчей самим агентом.
• Некоторые вообще отказались от спецификаций: инкрементально подсказывают «следующий шаг, какой сделал бы я», сразу коммитят дифф и правят на лету.