Hacker News Digest

Flowistry - это плагин для IDE, разработанный специально для языка программирования Rust. Его основная функция - помочь разработчикам сосредоточиться на релевантном коде, упрощая навигацию и понимание сложных проектов. Плагин использует статический анализ для определения связей между различными частями кода, что позволяет быстро понять, как разные компоненты взаимодействуют друг с другом.

Проект создан разработчиком Will Crichton и доступен на GitHub. Flowistry стремится решить распространенную проблему в больших кодовых базах - необходимость просматривать множество несвязанного кода для понимания контекста. Плагин предоставляет инструменты для визуализации зависимостей и определения путей данных в программе, что значительно ускоряет процесс отладки и рефакторинга кода на Rust.

• Инструмент Flowistry показывает, как данные течут в коде, но требует MIR и работает только с Rust.
• Обсуждение развилось вокруг того, почему это нельзя сделать для других языков и почему это не входит в rust-analyzer.
• Некоторые участники выразили желание увидеть подобные визуализации для TypeScript, C#, Python и других языков.
• Обсуждались вопросы товарного знака VSCode и ограничений, которые накладывает набор инструментов на то, что можно включить в IDE.
• Участники также обсудили, какие еще инструменты могли бы помочь в понимании кода и какие еще есть инструменты для других языков.

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

• LLM-агенты не умеют копировать-вставлять код, а только переписывают его из памяти, что может привести к ошибкам.
• Модели не задают уточняющих вопросов, что приводит к тому, что они делают предположения и ошибаются.
• LLM не могут использовать встроенные инструменты рефакторинга и вместо этого пытаются реализовать его самостоятельно, что может привести к ошибкам.
• Агенты не могут взаимодействовать с IDE и другими инструментами, что делает их менее эффективными.
• Модели не могут задавать уточняющие вопросы, что приводит к тому, что они делают предположения и ошибаются.

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

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

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

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

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

• Разработчики отмечают, что ИИ-ассистенты полезны для быстрого поиска API, рефакторинга и работы в незнакомых средах, но часто мешают из-за навязчивого автодополнения.
• Оптимальной стратегией считается использование ИИ как "младшего разработчика": задание интерфейсов и тестов, а затем поручение реализации, либо написание кода самостоятельно с последующей оптимизацией ИИ.
• Чрезмерное доверие к генерации кода по промптам приводит к потере понимания кодовой базы, ошибкам и необходимости постоянно править вывод ИИ.
• Многие отключают автодополнение или переназначают горячие клавиши, так как агрессивные подсказки часто некорректны и отвлекают от работы.
• Высказываются опасения о влиянии ИИ на рынок труда, но скептицизм относительно полного замещения разработчиков в ближайшие 1-2 года.

FernFlower — это декомпилятор от JetBrains, преобразующий байт-код Java обратно в читаемый исходный код. Он интегрирован в IntelliJ IDEA и известен высокой точностью восстановления логики, включая обработку исключений, циклов и локальных переменных. Инструмент активно используется разработчиками для анализа и отладки скомпилированных приложений, когда исходники недоступны.

Проект открыт под лицензией Apache 2.0, что позволяет свободно использовать и модифицировать код. Несмотря на конкуренцию с другими декомпиляторами, FernFlower выделяется качеством output’а и поддержкой современных функций Java. Практический плюс — его встроенная доступность в популярной IDE, что ускоряет работу без необходимости установки сторонних утилит.

• Обсуждается Java-декомпилятор Fernflower (Vineflower), его история, технические особенности и превосходство над аналогами.
• Участники делятся опытом использования Fernflower и других инструментов (jadx для Android, dnSpy для .NET), отмечая их эффективность.
• Поднимаются технические вопросы: возможность повторной компиляции, работа с обфусцированным кодом, корректность отображения строк.
• Обсуждается потенциальное применение LLM для присвоения осмысленных имен переменным и рефакторинга декомпилированного кода.
• Упоминается создатель Fernflower и его другие проекты, а также доступные GUI-интерфейсы и веб-инструменты для работы с JAR-файлами.

Стремительный рост использования ИИ-генерации кода привёл к появлению новой рыночной ниши — услуг по исправлению ошибок, допущенных алгоритмами. Хотя 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», если каждый шаг не привязан к новой фиче или бизнес-ценности; политика и мотивация команды важнее любой методики.

Погружён в технический долг
Книга-манифест о том, как разработчики и компании увязают в «техдолге» и выбираются из него.

• Что такое техдолг?
  Упрощения в коде, которые экономят время сейчас, но замедляют работу потом.

• Почему он растёт?
  Жёсткие дедлайны, отсутствие тестов, «потом поправим».

• Как измерить?
  Метрики времени на исправление багов, частота откатов, удовлетворённость команды.

• Как уменьшить?

  1. Выделять 20 % времени на рефакторинг.
  2. Писать тесты до кода (TDD).
  3. Проводить ревью каждого PR.
  4. Удалять мёртвый код.

• Культура
  Признайте проблему публично, отпразднуйте первый «день выплаты долга».

• Читатели спорят: кто-то хвалит тему и пользу книги, кто-то ругает «воду», анекдотичность и сомневается в ИИ-авторстве.
• Критикуют метафору «плавание против течения» и длинные главы; просят внятную структуру и кликабельное оглавление.
• Автор (loumf): 18 месяцев писал без ИИ, 4 раунда редакторов, половина текста за 1 $ – чтобы покупали только заинтересованные.
• Печать через месяц; Show HN подача съехала в обычную.
• Вывод: тема ценна, но подача и навигация пока спорны – автор собирает конструктив и правит.

• Цель стажировки – заложить основу для системы рефакторинга в Merlin, вдохновлённой IntelliJ и Gleam.

• Первый эксперимент – команда «вынести выражение на верхний уровень» (extract to toplevel).

• Как работает

  1. Выделяется наибольшее выражение внутри выбранного фрагмента.
  2. Оно переносится в новое let-связывание на уровень выше.
  3. Если выражение не чистое, создаётся thunk unit -> …, чтобы сохранить семантику.
  4. Свободные переменные превращаются в параметры новой функции.

• Примеры

  • Константа 3.14159 → let const_name1 = 3.14159.
  • print_endline внутри блока → оборачивается в fun () -> ….
  • a + b + c + (c * x * y) + z → функция, принимающая x, y, a, b, c.

• Результат – работающий прототип, готовый к расширению другими командами.

• Участники рады появлению базового рефакторинга «extract expression» и обсуждают, какие более продвинутые преобразования (например, map ↔ for) хотели бы видеть.
• Уточняли, будет ли автоматически заменяться одинаковый код в той же области видимости: пока нет, чтобы не «угадать» намерения пользователя.
• Кто-то делится самописными vim-скриптами для поиска и рефакторинга, работающими на любом языке.
• Поднимался вопрос о поддержке VS Code: разработчики утверждают, что вкладывают время и в VS Code, и в Emacs, но Emacs проще расширять.
• Обсуждали родство OCaml и F#, а также возможность использования ИИ для крупных рефакторингов.