Hacker News Digest

CI стал узким местом из‑за ускорения разработки: тестовый набор вырос в четыре раза, но проверка изменений отстаёт, увеличивая время ожидания и стоимость инфраструктуры. Чтобы ускорить обратную связь, мы оптимизировали время ожидания PR и потребление раннер‑времени, снизив среднее время ожидания с более 6 минут до чуть более 5 и вдвое сократив машинное время на тест.

Улучшения реализованы в четырёх направлениях: переход на более быстрые сторонние раннеры с лучшим кэшем ускорил задачи в среднем на 34 % (tsc — на 52 %); замена tsc на tsgo сократила медианное время проверки типов на 73 %; переписывание линт‑правил на работу с AST вместо TypeScript уменьшило время линтинга API на 68 % и полного репозитория — на 55 %, а также подготовило почву для перехода на Oxlint; увеличение количества тестовых шардов с 4 до 8 при одновременном улучшении параллелизма сократило время настройки с 8,3 до 7,5 минут, позволив запускать больше тестов одновременно. Без этих усилий тестовый набор занимал бы около 11 минут — почти вдвое дольше текущего показателя. С темпом роста около 2000 тестов в неделю дальнейшая оптимизация CI останется непрерывным процессом.

Ускорение разработки с помощью ИИ создало новый системный узкий пункт в виде CI. Решение проблемы требует не только оптимизации инфраструктуры, но и пересмотра архитектуры, процессов и ролей. Для ускорения пайплайнов и снижения затрат рекомендуют: — переход с GitHub Actions на сторонние раннеры с быстрыми CPU, производительным хранилищем и кэшем (например, blacksmith.sh); — использование Bazel для достижения времени сборки около 10 секунд при разогретом кэше в крупных проектах; — применение RWX как более гибкой альтернативы Bazel с кэшированием по содержимому и графовым выполнением задач. Для повышения эффективности разработки и тестирования: — разделять сервисы на изолированные компоненты с чёткими контрактами; — в Vitest балансировать нагрузку по длительности выполнения тестов, а не по количеству файлов. После оптимизации CI критическими узкими местами становятся деплой, откат и человеческое тестирование (QA), так как важно обеспечить удобство и любовь пользователей к продукту. Автоматизация продукт-менеджмента остается более сложной и важной задачей, чем автоматизация кода. Для соло-разработчиков целью является сокращение времени сборки до 5 минут для комфортной работы с агентами. Компании (например, Linear) обычно приступают к глубокой оптимизации инфраструктуры при достижении масштабов вроде 100M ARR. Существует спор о влиянии ИИ: одни считают, что погоня за скоростью ведет к падению качества, энергозатратности и неэффективному «бросанию кода на стену», другие отмечают рост числа приложений и незаметные, но частые улучшения UX (например, в YouTube для Android). Стартапы YC растут быстрее благодаря ИИ, в то время как крупные корпорации (Apple, Microsoft, Nintendo) не используют передовые инструменты разработки. Системы неизбежно становятся громоздкими со временем, и сейчас этот цикл проходят Linear и другие инструменты.

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

Автор экспериментально тестировал метрики: оценка кода самими LLM — нестабильна и часто случайна; ручная проверка неприменима в масштабе; изменение числа строк (LOC) — простая, но хрупкая метрика, подверженная закону Гудхарта. Два новых показателя из SlopCodeBench — на основе анализа AST и структурных паттернов — лучше разделяют «LLM-грязь» от устаревшего кода. Они выявляют избыточную связанность функций и низкую когезию, но всё ещё опираются на ручные хэристики. В итоге, даже при прогрессе в автоматизации, человеческая интуиция остаётся неотъемлемой частью оценки качества кода.

Измерение «грязи» кода требует учета глобальных архитектурных свойств — разделения обязанностей, слоистой архитектуры и четких интерфейсов — а не только локальных метрик. Человеческий опыт и управление ментальной моделью команды остаются критически важными, даже при использовании LLM: если AI становится основным автором кода, человеческое понимание теряется через «потерянный» канал коммуникации. Метрики вроде циклической сложности и LCOM известны давно, но их эффективность для LLM не изучена, и их применение требует осторожности из-за риска Goodhart's law. Изменение числа строк кода (LOC) как метрика работает в практике, но теряет смысл при оптимизации под неё. Тесты, которые не проверяют ничего (например, всегда возвращают True), не обнаруживаются статическим анализом или покрытием, но выявляются mutation testing — это важный, но игнорируемый индикатор грязи. Сложность, вводимая LLM, может превышать их способность к управлению — неизвестно, есть ли предел, при котором модели теряют контроль над собственной сложностью. Для оценки качества кода следует использовать комбинацию метрик (циклическая сложность, churn, авторство) и анализировать их динамику во времени, а не только статические значения. Использование LLM как судьи в оценке кода (harness evals) перспективно при правильном проектировании метрик и контекста. Оптимизация под минимальное количество LOC, проходящее тесты, не гарантирует чистоту кода и может усугубить проблему без учета архитектурной целостности. Для улучшения качества кода, генерируемого LLM, необходима обратная связь на основе качественных репозиториев и комплексных метрик, а не только на корректность выполнения задач. Споры: - Код «решен» LLM? Работающий код ≠ поддерживаемый, особенно в сложных системах. - AI-генерируемый код — эволюция существующего «мусора» или его объем превышает человеческие возможности управления? - Стоимость токенов делает AI-генерацию экономически нецелесообразной? Или это временный этап? - Один участник отметил, что его репозиторий, написанный агентами, показал более низкую «verbose» метрику, чем у людей — что противоречит ожиданиям. Качество кода не измеряется только техническими метриками — ключевой индикатор — способность команды понимать и поддерживать систему, что требует коммуникации, а не автоматизации.

Синтаксическое выделение цветом полезно, но недоиспользует возможности цвета как канала информации. Цвет может нести гораздо больше информации, чем просто выделение синтаксиса. Например, можно использовать разные цвета, чтобы показать уровень вложенности скобок, что улучшает читаемость кода.

Другой пример — выделение импортов: можно подсвечивать идентификаторы, импортированные из других файлов, что помогает быстро понять зависимости. Также можно выделять аргументы функций иначе, чем локальные переменные, или использовать цвет для указания типов данных, даже если язык этого не требует.

Ещё одна идея — выделение функций, которые вызывают исключения, или функций, которые были изменены в последнее время. Это превращает подсветку из чисто декоративной функции в мощный инструмент для анализа кода и отладки.

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

В итоге, хотя современные IDE уже предоставляют некоторые из этих функций, мы далеки от полноценного использования цвета как информационного канала. Расширение этих возможностей может значительно улучшить читаемость и понимание кода.

• Обсуждение показало, что большинство участников считают современные редакторы кода не используют цвет как информационный канал, а лишь как декоративный элемент.
• Участники подчеркнули, что вместо того, чтобы использовать цвет для передачи дополнительной информации, редакторы ограничиваются лишь базовой подсветкой синтаксиса.
• Некоторые участники упомянули, что такие вещи как подсветка потока данных, подсветка переменных и подсветка ошибок уже реализованы в таких IDE как IntelliJ IDEA, но не используются в других редакторах.
• Были также упомянуты такие вещи как подсветка важных частей кода, подсветка области видимости и подсветка неиспользуемого кода.
• Несколько участников выразили мнение, что цветовая схема должна быть более гибкой и адаптивной, чтобы отражать структуру и смысл кода, а не только его синтаксическую категорию.

Метод FCA (Function Calling Abstraction) предлагает новый подход к инженерии контекста для ИИ-агентов, работающих с кодом. Вместо передачи полного кода функции в контекст, он использует абстрактные описания её поведения, что значительно сокращает объём передаваемых данных. Это позволяет агентам точнее понимать предназначение функций без перегрузки контекста избыточной информацией.

Ключевое преимущество — повышение эффективности обработки запросов и снижение затрат на вычисления, так как модель фокусируется на семантике, а не на синтаксисе. Метод особенно полезен в больших проектах, где количество функций может быть огромным. Практический результат — ускорение разработки и улучшение качества генерируемого кода за счёт более релевантного контекста.

• Участники обсуждают эффективность подхода "исследование -> план -> реализация" для работы с ИИ в больших кодовых базах, отмечая рост производительности, но и сложности управления контекстом.
• Поднимаются вопросы о надежности ИИ: необходимость почти идеальной точности генерации кода, проблемы с галлюцинациями и сложность верификации поведения без чтения каждой строки.
• Критикуется масштабируемость подхода: управление контекстом становится сложным при больших объемах, а стоимость использования мощных моделей (например, Opus) может быть высокой.
• Отмечается сдвиг роли инженера: от написания кода к определению спецификаций и верификации поведения, что требует новых навыков и вызывает сопротивление у некоторых разработчиков.
• Обсуждаются технические детали и инструменты: важность компрессии контекста, использования AST для анализа кода, необходимость ведения логов промптов и стилистического единообразия кода.

Форматирование кода должно быть лишним

В 80-х это уже знали.
Мой школьный учитель информатики, мистер Пейдж, участвовал в разработке компилятора Ada. Когда я в 2016-м жаловался на линтеры, он напомнил: проблему решили 40 лет назад. В Ada исходники не хранили — использовали IR-дерево DIANA. Каждый смотрел его в своём стиле: отступы, пробелы — всё равно.

Сейчас, в 2025-м, мы всё ещё спорим о запятых.

Как это работало
Рабочая станция Rational R1000 (1985) хранила не текст, а DIANA. IDE позволял редактировать дерево напрямую — проекционное редактирование. Компиляция была инкрементной, рефакторинг мгновенным, а «исходник» — просто красивой печатью дерева.

Плюсы: никаких holy-war’ов о табах, быстрая интеграция, встроенный VCS и отладка.
Минус: требовалась железная станция и знание Ada.

Вывод
Не нужно возвращаться к проекционным редакторам, но можно ли встроить идею «храним структуру, а не текст» в современные языки и IDE? Тогда форматирование станет личным вкусом, а не командным законом.

• Одни считают форматирование важным каналом коммуникации и показателем вкуса/опыта разработчика, другие — пустым байкшедом, который должен решаться автоматическим линтером без обсуждений.
• Хранение кода не как текста, а как IR/AST (пример — Ada/DIANA, Unison) позволяет каждому видеть свой вариант форматирования, но ломает привычные grep, diff, git и другие текстовые инструменты.
• Проекционное редактирование (JetBrains MPS, Chrome DevTools «pretty») демонстрирует «один IR — много представлений», но требует специальных IDE и пока не стало массовым.
• Проблема смешанных языков, legacy, необходимости универсального стандарта IR и инерции экосистемы тормозит переход от plain-text.
• Автоформатеры (gofmt, Prettier, Black) уже закрывают 90 % вопросов: на сохранении/коммите единый стиль, локально можно настроить git-фильтры smudge/clean.

Claude Code IDE для Emacs

Обзор

• Интеграция с Claude Code CLI через MCP создает двусторонний мост между Claude и Emacs.
• Claude получает доступ к возможностям Emacs: LSP, проекты, Elisp-функции, что делает его «понимающим Emacs» помощником в вашем рабочем процессе.

Возможности

• Автоопределение проекта и управление сессиями
• Терминал с цветом (vterm/eat)
• Реализация MCP для IDE-интеграции
• Инструменты для файлов, состояния редактора и рабочего пространства
• Расширяемый сервер MCP для Emacs-команд (xref, tree-sitter, project и др.)
• Диагностики Flycheck/Flymake
• Расширенный дифф с ediff
• Поддержка tab-bar и отслеживание выделений/буферов

Интеграция инструментов Emacs

• LSP через xref (eglot, lsp-mode) для навигации по коду
• Tree-sitter для анализа AST
• Imenu для структуры символов
• Project для операций на уровне проекта
• Любую команду/функцию Emacs можно выставить как MCP-инструмент: поиск и рефакторинг по проекту, доступ к режимам, выполнение кастомного Elisp.

Скриншоты

• Осведомленность об активном файле — знает, какой файл открыт
• Контекст выделения — работает с выделенным текстом
• Продвинутый дифф с диагностикой — ediff и доступ к ошибкам/предупреждениям
• Автоматические упоминания текста — вставка ссылок на выделение в диалог
• Восстановление сессии — продолжение разговоров с флагом –resume

Установка Предварительные требования

• Emacs 28.1 или новее

• AI-инструменты вроде Claude Code делают Emacs/Vim конкурентоспособными: вместо самостоятельной реализации сложных IDE-функций редакторы просто интегрируются с готовыми агентами.
• Пользователи хвалят Emacs за полный доступ к состоянию редактора и возможность «на лету» менять поведение через Elisp, что идеально подходит для AI-агентов.
• Уже существует несколько реализаций интеграции (claude-code.el, eca, claude-code-emacs и др.); споры идут, какая из них лучше, но все признают, что встраивание в Emacs ускоряет рабочий процесс.
• Проблемы: сложность конфигурации, риск утечки чувствительных данных, привязка к конкретному провайдеру и необходимость локального запуска для приватности.