Hacker News Digest

pyscn — это интеллектуальный анализатор качества Python-кода с открытым исходным кодом. Он использует статический анализ для выявления проблем вроде неиспользуемых переменных, избыточных конструкций и нарушений стиля, помогая разработчикам писать более чистый и эффективный код.

Инструмент предлагает детальные отчёты с рекомендациями по исправлению, интеграцию в CI/CD и поддержку кастомных правил. Особенность — акцент на объяснении ошибок, что ускоряет обучение и улучшает практики кодинга.

• Обсуждение инструмента для анализа качества кода, который использует tree edit distance на AST для обнаружения структурных дубликатов, в отличие от текстовых сравнений
• Споры о "vibe coders" (разработчиках, полагающихся на ИИ): одни считают их безразличными к качеству, другие защищают как прагматичный подход для определенных задач
• Вопросы о технических деталях: влияние языков со статическим анализом, обобщаемость на другие языки через tree-sitter, сравнение с существующими инструментами (Pylint, Ruff)
• Предложения по интеграции: как инструмент для инженеров, поддерживающих legacy-код, или как MCP-сервер для AI-агентов
• Обсуждение будущего: роль инструментов анализа в эпоху ИИ-ассистентов и их потенциал для улучшения качества в доминирующих языках (Python/JS)

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

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

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

Код — это долг

«Что ты думаешь об ИИ-инструментах для программирования?»
Отвечаю примером двух компаний.

Они одинаковы по доходу и продукту, но первая живёт с 1 млн строк кода, вторая — с 100 тыс. Какая выгоднее?
Очевидно, та, что меньше. Меньше кода — быстрее понимать и менять. Код — это долг. ИИ, генерируя код, даёт тебе этот долг.

Брать ли его? Зависит. Долг бывает полезным или разрушительным, с процентами или без. Главное — иметь доступ к инструментам и использовать их ответственно.

Спасибо Ани Талахадзе за рецензию.

• Участники спорят, можно ли считать количество строк кода (LOC) мерой технического долга: одни считают LOC бесполезной метрикой без учёта качества, другие — формой риска и обязательств.
• Подчёркивается, что «меньше кода» ≠ «лучше», если он нечитаем, плохо документирован и не поддерживается; главное — скорость понимания и изменения.
• AI-генерация кода ускоряет объём, но усиливает долг: код быстро появляется, но никто не понимает, кто за него отвечает, и как его отлаживать.
• Код описывается как актив, который амортизируется: чем больше кода, тем выше ежегодные «выплаты» на его поддержку и рефакторинг.
• Третьи сервисы и зависимости тоже создают долг: при смене условий или закрытии поставщика страдает бизнес.

Удаляйте тесты
Тесты нужны для уверенности: «не сломал ли я старое?». Но если тесты сами подрывают эту уверенность — их надо выбрасывать.

• Флаки (падают случайно) учат игнорировать красный CI и скрывать реальные баги. Удаляйте.
• Слишком хрупкие (150 правок ради одной строки) замедляют разработку. Оставьте пару ключевых, остальные — в мусор.
• Долгие (не успевают прогнаться между мержами) превращаются в «всегда зелёные», но не запускаются. Это ложная уверенность — удаляйте.
• Устаревшие (проверяют поведение, которое больше не нужно) мешают внедрять новые требования. Удаляйте и пишите новые.

Если тест не приносит уверенности прямо сейчас, он вредит. Удаляйте без страха: при настоящем баге напишете лучший.

• Участники спорят, стоит ли удалять «шаткие» (flaky) или медленные тесты, или их нужно чинить.
• Большинство считает, что лучше чинить: хрупкие тесты часто указывают на проблемы в архитектуре или race condition.
• Некоторые предлагают компромисс: временно игнорировать или выносить в отдельный набор, но не удалять окончательно.
• Автор статьи призывает удалять тесты, если они не приносят ценности, но критики считают это «кликбейтом» и предлагают просто улучшать тесты.
• Общий вывод: тесты — это код, который тоже может стать техническим долгом; решать нужно не «удалять vs оставлять», а «как сделать полезные тесты быстрыми и стабильными».