Hacker News Digest

Hypothesis 6.145.1 — это библиотека для property-based тестирования в Python. Вместо написания тестов для конкретных входных данных, разработчики описывают диапазон входных значений, а Hypothesis самостоятельно генерирует случайные тесты, включая граничные случаи, которые могли быть упущены. Пример тестирования функции сортировки демонстрирует использование декоратора @given со стратегиями для списков целых чисел или чисел с плавающей точкой, где библиотека генерирует случайные списки для сравнения пользовательской реализации со встроенной функцией sorted().

Документация структурирована для разных уровней пользователей: от краткого руководства для начинающих до подробного API-справочника. В ней представлены разделы с обучающими материалами, практическими руководствами для специфических сценариев и объяснениями для углубленного понимания библиотеки. Библиотека активно развивается с 2013 года и поддерживается сообществом, что делает её надежным инструментом для повышения качества тестирования в Python-проектах.

• Property-based testing (PBT) выявляет крайние случаи, которые обычные тесты могут пропустить, но требует «оракула» или спецификации, что делает его менее универсальным инструментом.
• Основной барьер внедрения PBT — это не только отсутствие знаний, но и необходимость переосмыслить подход к тестированию и, возможно, саму архитектуру кода.
• В отличие от классических примеров, PBT требует, чтобы разработчик формализовал свой код и его свойства, что делает его менее доступным для специалистов, не знакомых с формальными методами.
• Несмотря на то, что Hypothesis и подобные инструменты делают PBT доступным на практике, они не решают фундаментальную проблему: для сложных систем требуется либо сравнение с другой реализацией, либо формальная спецификация, что делает PBT менее применимым в таких случаях.

• Обсуждение сосредоточено на том, что PR объемом 9000 строк кода и 63 файла невозможно ревьюить и должен быть разбит на части или отвергнуться без разбора.
• Участники подчеркивают, что такие PR нарушают базовые практики разработки и требуют автора разбить PR на меньшие, самодостаточные части.
• Сообщество подчеркивает, что такие PR часто не сопровождаются тестами или документацией, что делает невозможным проверить их корректность.
• Некоторые участники отмечают, что такие PR могут быть результатом использования AI, что вызывает дополнительные вопросы о качестве и поддержке кода.
• В конечном счете, большинство участников соглашаются, что такие PR должны быть отвергнуты с просьбой к автору разбить их на меньшие части, если это возможно, или начать с RFC или документации.

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

При таком разделении добавление новых функций становится проще - достаточно создать новые чистые функции и переиспользовать существующие. Например, для напоминаний о подписке можно создать функцию generateReminderEmails, используя уже существующую getExpiredUsers. Этот паттерн, впервые описанный Гэри Бернхардтом, помогает создавать более тестируемый, поддерживаемый и адаптивный код, избегая "спагетти" из смешанной логики и побочных эффектов.

• Обсуждение вращается вокруг идеи "functional core, imperative shell" (FCIS) и противоположного ей подхода "generic core, specific shell", а также влияния этих подходов на тестируемость, производительность и читаемость кода.
• Участники обсуждают, что FCIS делает код более тестируемым, но может привести к проблемам с производительностью при работе с большими объемами данных, особенно если язык не поддерживает ленивые коллекции.
• Также обсуждается, что важно разделять логику и эффекты, но пример кода в статье вызывает вопросы, потому что он не демонстрирует лучшие практики, такие как пагинация или фильтрация на уровне базы данных.
• Некоторые участники подчеркивают, что важно не только следовать паттерну, но и использовать здравый смысл, чтобы не плодить сущности, которые не масштабируются, и не создавать ситуаций, где пример кода в статье может быть использован как оправдание для плохого кода.

Проект h3o представляет собой полную переработку библиотеки Uber H3 на языке Rust, а не просто обертку. Основные цели - упрощение интеграции в Rust проекты (особенно для WASM), создание более безопасного API с использованием строгой типизации, достижение сопоставимой или превосходящей производительности и 100% покрытие API H3 версии 4.0. Для обеспечения качества использовалось дифференциальное тестирование против эталонной реализации, включая 756 тестов, 166 интеграционных тестов, 42 юнит-теста и 15 fuzz-целей.

Бенчмарки, состоящие из 911 тестов, показывают, что в 862 случаях h3o превосходит оригинальный H3 по производительности. В 463 тестах h3o работает в 2-5 раз быстрее, в 117 тестах - в 5-10 раз быстрее, и в 24 тестах - более чем в 10 раз быстрее. Однако в 44 тестах H3 все еще быстрее, особенно при работе с пятиугольными ячейками и преобразованиями координат. Основные оптимизации h3o включают использование предвычисленных таблиц вместо формул на лету и применение битовых операций вместо циклов для достижения постоянного времени выполнения.

• H3/Hexagonal tiling vs. S2/Square tiling: обсуждение сфокусировалось на том, что H3 обеспечивает равные расстояния между соседними ячейками, что важно для анализа данных и моделирования потоков, в то время как S2 не обеспечивает равные расстояния между соседними ячейками. Однако, S2 имеет преимущество в том, что он может быть более эффективен для запросов, которые включают родительские и дочерние ячейки, тогда как H3 может быть более удобен для визуализации и анализа данных, особенно если важно сохранить равные расстояния между ячейками.

• Использование H3 в различных контекстах: обсуждение включало примеры использования H3 в различных контекстах, включая Uber, FCC, ClickHouse, Overture Maps и другие. Это показывает, что H3 используется в различных контекстах, включая телематика, анализ данных, визуализация и хранение данных.

• Сравнение H3 с другими системами: обсуждение также коснулось сравнения H3 с другими системами, включая S2 и другие геометрические системы. Это показывает, что H3 имеет свои уникальные преимущества и недостатки, которые важно учитывать при выборе системы для конкретного применения.

• Развитие и будущее H3: обсуждение также коснулось будущего развития H3, включая возможность создания новой версии, которая может быть более эффективна и удобна для пользователей.

В предоставленном материале отсутствует сама статья для пересказа. Это лишь нижний колонтитул сайта YouTube с навигационными ссылками на различные разделы платформы, включая информацию для создателей, рекламодателей, разработчиков, а также юридические документы и политику конфиденциальности. Указано, что ресурс принадлежит Google LLC и защищен авторскими правами.

Для выполнения задания по созданию точного и ёмкого пересказа статьи Hacker News в Markdown на русском языке необходимо предоставить саму статью, содержащую ключевую информацию, факты, цитаты или цифры. Без основного контента невозможно создать качественный пересказ в соответствии с указанными требованиями.

• Случай с миссией "Венера-8" иллюстрирует, как мелкая ошибка может привести к каскаду сбоев, что подчеркивает важность тщательного тестирования и отладки.
• Проблема с антенной "Галилео" показывает, как отказ оборудования может заставить миссию полагаться на менее эффективную резервную систему, что влияет на объем и качество собранных данных.
• Случай "Вояджер-1" демонстрирует, как даже при таком расстоянии можно было провести "первое межзвездное обновление программного обеспечения" и спасти миссию.
• Обсуждение также затрагивает вопрос о том, что значит быть "в межзвездном пространстве", и какие критерии следует использовать для таких заявлений.

Митчелл Хашимото делится личным опытом, как не теряя мотивации довести большие проекты до конца. Он начинает с маленького, но ощутимого результата: например, вместо «сделать терминал» он берёт подпроект «распарсить VT-коды» и уже через пару дней имеет живой результат и тесты. Далее он итеративно добавляет новые фичи, каждый раз имея что-то, что можно показать. Это позволяет сохранять энтузиазм и не терять фокус. Под конец он напоминает, что не стоит стыдиться незавершённых проектов — главное, чтобы они были интересны самому автору.

• Собеседники подчеркнули, что ключ к быстрому прогрессу — это умение разбивать задачу на мелкие, легко демонстрируемые фрагменты и не застревать в «анализ-парализе»; главное — быстро получать обратную связь и не бояться «грязного» MVP.
• Подчеркнуто, что выбор инструмента (язык/стек) влияет на скорость итераций: REPL-языки и инструменты вроде hot-reload позволяют видеть эффект изменений почти мгновенно, что снижает порог входа и удерживает мотивацию.
• Участники обсуждения подтвердили: чем раньше показать работающий прототип, тем меньше вероятность, что проект застрянет в вечной «доработке»; демо-ориентированная разработка заставляет фокусироваться на ценности для пользователя, а не на перфекционизме.
• Сообщество отметило, что даже в личных проектах важно документировать и тестировать как будто ты передашь его другу: это упрощает возврат к контексту спустя месяцы и служит живым примером.
• Несколько человек поделились личным опытом, что их подход к разработке ПО вдохновил их начать вклад в open-source, и что их опыт в open-source в свою очередь улучшил их навыки ведения личных проектов.

Разработчики часто сталкиваются с тем, что официальная документация описывает функцию, но не показывает, как её использовать. Пример: вместо того, чтобы показать, как вызывать max() в Python, документация тратит абзацы на то, чтобы объяснить, что такое iterable и что значит key=. А ведь достаточно было бы показать, как передавать кастомную функцию сортировки в max().

Проект ClojureDocs берёт на себя роль «примеры — лучшая документация». Пользователи добавляют примеры к встроенным функциям, и это оказывается куда более полезным, чем формальное описание API. Примеры показывают, как вызывать функцию, какие есть подводные камни и какие есть альтернативы.

• Документация должна включать и примеры, и полное API-описание; оба формата дополняют, а не конкурируют.
• Примеры важны для новичков, но не заменяют полное описание параметров и контрактов; примеры без спецификации приводят к тому, что разработчики вынуждены читать исходники.
• Примеры должны быть живыми: если они не запускаются как часть CI или не покрыты тестами, они быстро устаревают и вводят в заблуждение.
• Документация должна быть двух типов: краткий пример для быстрого старта и полное руководство для продвинутых пользователей.
• Примеры должны быть частью тестов и наоборот: примеры в документации должны быть тестируемыми как часть CI.

Автор делится программными эссе, которые повлияли на его мышление за 20 лет карьеры. Среди них — «Тест Джоэла» Джоэла Спольски, который предлагает 12 вопросов для оценки качества работы команды, подчеркивая уважение к разработчикам и их времени. Эссе Алексис Кинг «Парси, а не валидируй» показывает, как использование типов данных повышает безопасность, превращая сырые строки в проверенные структуры. Фред Брукс в «No Silver Bullet» утверждает, что не существует волшебного решения сложности ПО, поскольку её корни — в сущностных, а не случайных проблемах.

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

• Обсуждаются влиятельные эссе и статьи о разработке ПО, включая "Parse, don't validate", "Choose Boring Technology" и анализ инцидентов с Therac-25.
• Поднимаются вопросы о качестве тестового кода: спор о допустимости логики в тестах и важности их простоты для избежания ложных срабатываний.
• Обсуждается влияние ИИ на классическую теорию Brooks'а об отсутствии "серебряной пули" и его способность снижать essential complexity.
• Упоминаются ключевые работы, повлиявшие на мышление разработчиков, такие как "Grug Brained Developer", "Code Complete" и "Don't Call Yourself A Programmer".
• Затрагивается проблема цифровой идентификации и доступа к аккаунтам в сравнении с аналоговым миром, где проще доказать свою личность.

Новички в программировании часто зацикливаются на изучении структур данных и алгоритмов (DSA), потому что это проверяется на собеседованиях. Однако в реальной работе редко приходится реализовывать сложные алгоритмы вручную — вместо этого стоит понять базовые структуры, их trade-offs и основы Big O, чтобы эффективно организовывать и обрабатывать данные.

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

• Участники обсуждают важность знания структур данных и алгоритмов (DSA) для разработчиков, отмечая, что понимание их характеристик (например, сложности операций) часто важнее умения реализовывать их с нуля.
• Подчеркивается необходимость баланса между теоретическими знаниями (DSA) и практическими навыками тестирования, при этом многие отмечают, что эти навыки не исключают, а дополняют друг друга.
• В дискуссии звучит критика статьи, указанной в исходном посте, за её провокационный заголовок, который, по мнению участников, упрощает сложную проблему и создает ложную дихотомию между DSA и тестированием.
• Несколько комментаторов приводят примеры из практики, где незнание базовых принципов DSA (например, сложности алгоритмов) приводило к серьезным проблемам с производительностью в продакшене.
• Обсуждается роль тестирования: одни видят в нем ключевой навык для обеспечения качества, другие указывают на его ограничения (например, сложность тестирования многопоточных систем) и необходимость сочетать его с другими методами, как property-based тестирование или формальные доказательства.

Параллельная разработка с Claude Code: коротко

Запустил 3 агентов (product-manager, ux-designer, senior-engineer) одной командой — за минуту получил полный тикет в Linear.
Далее те же агенты кодят, ревьюят, тестируют в отдельных терминалах, пока я занят другим.
Ошибка стоит копейки — просто перезапускаю.

Ключевые принципы

1. Параллельность: backend, frontend, тесты, доки пишутся одновременно.
2. Специализация: каждый агент видит только нужный контекст (Stripe-интеграция, UI-форма, тесты).
3. Минимальные требования: чёткая цель + границы (/docs, /tests, /ui).

Как повторить

• Положи .md-инструкции для ролей в agents/.
• Один bash-скрипт: claude -p agents/pm.md & claude -p agents/dev.md & claude -p agents/qa.md.
• Результаты сливаются автоматом; если rate-limit — добавь sleep 1.

Готово: спеку, код и тесты получаешь быстрее, чем пишешь Jira-таск.

• Подавляющее большинство участников считают «ролевых» суб-агентов (product-manager, frontend, backend и т.д.) маркетинговым трюком: они не получают полного системного промпта и CLAUDE.md, быстро теряют контекст, пишут «моки» или ломают уже рабочий код.
• Практический итог: вместо ускорения появляется «казино» — много запусков, загрязнённый контекст, регрессии и перерасход токенов; проекты приходится переписывать вручную.
• Кто всё-таки использует суб-агентов, делает их не «по ролям», а «по задачам»: короткий запрос → агент жрёт много токенов → возвращает компактный отчёт (покрытие тестами, соответствие гайдам, рефакторинг-чек-лист), чтобы основной чат не засорять.
• Альтернатива — уйти от чёрного ящика: Tmux + два独立的 CLI-агента в соседних панелях, ручной синх через файлы или GitHub-issues; так проще остановить и подправить.
• Общий вывод: для реального кода достаточно обычного Claude Code с хорошим промптом, правилами в /commands и лаконичным CLAUDE.md; «мульти-агент» пока не приносит выгод, зато точно приносит лишние траты и головную боль.

from-bash-to-go-part-ii
Репозиторий курса «Go для бывалых bash-скриптеров, часть II» — практика по созданию CLI-утилит на Go.

• В Go пакет *_test — единственное исключение из правила «один пакет на каталог», позволяя тестировать только публичное API.
• Участники хвалят стиль статьи: сначала показывается «ошибочный» шаг новичка, затем объясняется, почему он не работает, и даётся правильное решение.
• Такая линейная подача материала ускоряет реальное обучение, экономя время на поиск разрозненных советов.
• Доп. совет: в каталоге не-main-пакета можно разместить package main-файлы, что удобно для go generate.

• Автор предлагает запускать только «релевантные» e2e-тесты, выбранные Claude Code, и заявляет о 84 % экономии времени.
• Критики считают это не оптимизацией, а сокрытием покрытия: вероятность пропустить сломанный тест становится ненулевой.
• Детерминированные решения (статический анализ графа зависимостей, Test Impact Analysis, merge-queue) существуют давно и надёжнее.
• Некоторые допускают вероятностный подход, но только если полный набор тестов всё равно прогоняется перед деплоем или в cron.
• Без публикиции baseline-экспериментов (намеренные баги, сравнение «запущено vs надо») эффективность остаётся недоказанной.

Disciplined-AI-Software-Development
Методика структурирует совместную работу с ИИ над кодом:

• убирает раздутость,
• фиксирует архитектуру,
• сохраняет контекст.

Контрольные точки и жёсткие ограничения не дают проекту съехать в хаос.

• Пользователи спорят, стоит ли погружать Claude-Code в тонны контекста: одни делают «глубокий research-цикл» (Gemini/GPT-5 → план → агент), другие считают это медленнее ручного кода.
• Работает только жёсткий pipeline: план → ревью плана → промежуточный код-ревью → тесты/линтеры → финальное ревью; полный автомат без человека проваливается.
• LLM заставили разработчиков наконец писать документацию, но сами агенты плохо планируют и «заплывут» по мере роста кодовой базы.
• Эффективность высока лишь при маленьких, чётко заскоупленных задачах: 10-минутный спецификация → 3 часа генерации → 85 % покрытие тестами; большие коммиты всё ещё быстрее делать вручную.
• Главный риск: технология убирает бюрократию, но не переносит человеческую ответственность; ошибки агента = ошибка конкретного разработчика.

Краткий конспект «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», если каждый шаг не привязан к новой фиче или бизнес-ценности; политика и мотивация команды важнее любой методики.

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

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

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

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

• Простота — главное в долгоживущем коде: понятность и уверенность при изменениях.
• Программы должны быть «одноразовыми», как Кенни, а не «неубиваемыми», как Терминатор.
• Laravel начинался как хобби на PHP 5.3 и вырос до 70 человек; Тейлор всё ещё единственный куратор ядра.
• Первым коммерческим продуктом стал Forge — решение собственной боли.
• Не ломай обратную совместимость без крайней нужды; «умники» всегда уходят, а их хитрости остаются.
• Лучшие проекты — те, кто не изобретает велосипеды и следует конвенциям.
• Споры закрываются сравнением реального кода: «покажи, как будет выглядеть».
• Фасады остаются популярнее DI, но Laravel постепенно добавляет типы и статический анализ.
• Культура тестирования изменилась после курса Adam Wathan.
• Сейчас задача — передать ответственность команде и оставаться интересным.

• Участники обсуждают, что Laravel учит «не писать код как Laravel»: пример — баг в cache tagging, который просто убрали из документации.
• Поддержка старых версий Laravel (3–4) описывается как кошмар, требующий полного переписывания, тогда как Rails и Symfony позволяют плавные апгрейды.
• Сообщества Laravel, Symfony, Drupal и WordPress различаются культурно: Laravel ориентирован на быстрый MVP и продажу продуктов, Symfony — на стандарты и долгосрочную поддержку.
• Несколько человек жалуются на плохое качество аудио и просят поп-фильтр.

Я начал с примитивного подхода: описывал задачу, ждал результат, указывал на ошибки. Для простых вещей сойдёт, но при росте сложности появились проблемы:

• беседа становится единственным источником истины;
• старые инструкции могут быть затёрты новыми;
• контекст ограничен, и старые детали «забываются».

Решение — план-документ. Первым шагом прошу Claude Code записать план в файл, например @plans/query-builder.md. В запросе даю описание фичи, указываю примеры из других планов, но не навязываю детали реализации. Ожидаю:

• переформулировку требований;
• черновой код или псевдокод;
• команды для проверки качества (типы, линтер, тесты).

Если план не устраивает, объясняю, что не так, и Claude переписывает. Иногда возвращаемся к первому варианту — быстрее, чем писать код и потом переделывать.

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

Проверь, что план в @plans/query-builder.md актуален, и закоммить изменения.

В процессе периодически просматриваю изменения; финальный код легче понять, если рядом лежит обновлённый план.

• Участники делятся опытом «один-шот» разработки: предварительно создают подробный план в нескольких .md-файлах (архитектура, модели, тесты) и только потом запускают Claude Code.
• Ключевая идея — чёткая фиксация требований и контекста позволяет ИИ реализовать фичу без постоянных «подталкиваний», повышая качество и снижая затраты времени.
• Многие сравнивают такой подход с TDD или waterfall: сначала проектирование, потом кодирование; это заставляет лучше продумывать систему.
• Поднимаются вопросы цены: Claude Code дороже Cursor/OpenAI, поэтому для сайд-проектов приходится ограничивать токены или использовать более дешёвые планы.
• Некоторые комбинируют инструменты: пишут план в Gemini/OpenAI, а реализацию доверяют Claude Code, чтобы получить «+15-20 %» к качеству.

Разработчики тоже сталкиваются с «блоком» — аналогом писательского, но часто более тяжёлым. Причины и способы выбраться.

Почему зависаем

Новый проект
Хочется сделать «лучше всех»: покрыть тестами, написать документацию, придерживаться стиля, CI, кросс-компиляция, обработка ошибок, конкурентность… Практики полезны, но вместе превращаются в стену.

Старый проект
• Новый код — перегруз: спешишь понять, язык незнаком.
• Старый код — упал мотивация или переутомление.

Как разблокироваться

• Учись постепенно
  Запусти как пользователь, почитай тесты, спрашивай коллег. Не знаешь язык — выдели время на основы.

• Отдыхай
  После большой фичи бери «мелкие дела» или техдолг.

• Двигайся мелкими шагами
  Минимально реализуй задачу, потом улучшай тесты и доки.

• Прототипируй
  «Спайк» — быстрый черновик по happy path. Оставь в ветке, потом перепиши аккуратно.

• Документируй черновиком
  Не полируй раньше времени: простой формат, потом доведёшь.

• Сон, прогулки, спорт и медитация — лучший способ «разблокировать» мозг и получить новые идеи.
• Ранние «грязные» MVP и повторное использование boilerplate снижают страх перед чистым листом.
• LLM помогают быстро набросать черновик, преодолеть ступор и даже подсказать имена.
• Когда совсем застрял, начни писать любой код или даже инфраструктуру для отладки — движение разгоняет.
• Главное — не игнорировать сигналы тела: делай паузы, иначе выгоришь.

Два месяца писал код только с Claude Code. Поначалу — восторг: задачи летят, коммиты сыплются.
Сейчас, когда приложение разрослось, всё затормозилось. Парадокс: само приложение умеет запускать множество копий Claude Code, и я держу одновременно 5 инстансов, пока придумываю новые фичи.

Задержка появляется при проверке PR. Каждый приходится локально применять, читать логи, просить Claude чинить собственные ошибки.
Объём кода огромен, но скорость воспринимается как мучительно медленная: после первого «ускорения» хочется, чтобы всё так же летело. Это затягивает.

Пока Claude остаётся QA-инженером, который требует контроля. Не верю, что CLAUDE.md решит проблему: правил-то он едва придерживается, а уж комплексные интеграционные тесты — тем более.

Пока что продолжаю мёржить PR вручную, вешать git-хуки за качество и «мчаться» по задачам, пока не выяснится, что модель придумала несуществующие методы библиотеки, и придётся вырезать Clerk и писать GitHub OAuth с нуля.

• Участники обсуждают «проблему золушки»: задача должна быть достаточно большой, чтобы оправдать описание и ревью, но не настолько, чтобы LLM «утонула».
• Ключевой узкое место — человек: быстро генерируемый AI-код всё равно требует внимательного прочтения и понимания.
• Нужно сразу задавать архитектуру и контролировать её, иначе проект быстро разрастается хаотично; README и тесты помогают, но сами тесты иногда «ломаются» или игнорируются агентом.
• Эффективные подходы: дробление задач на 4-5 мелких, запуск нескольких специализированных агентов (док-мен, безопасность, оптимизация), строгая типизация и CI-хуки для поимки галлюцинаций библиотек.
• Некоторые считают, что LLM-программирование — это отдельная дисциплина, где привычные паттерны не работают, а «медленно и гладко» оказывается быстрее в итоге.

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

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

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

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

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

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

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

Задача: перенести TypeScript-утилиту Ruler на Rust, проверить идентичность через bash-тест.
Модели: GPT-5 (новый, превью) и Claude 4 Sonnet.

GPT-5

• Сразу прочитал код, составил подробный plan.md, получил одобрение.
• Работал почти без остановок, дважды отчитывался о статусе.
• Сначала написал bash-скрипт, который запускает оригинал и порт во временной папке и сравнивает вывод.
• Затем сгенерировал структуру src/, Cargo.toml, CLI-аргументы, логику apply/init/revert, обработку конфигов и MCP.
• Итеративно правил код, пока тест не прошёл «зелёным».
• Время: ~20 мин, 1 коммит, ветка feat/rust-port.

Claude 4 Sonnet

• Та же инструкция.
• Сразу начал писать Rust, но упустил bash-тест; пришлось напомнить.
• Тест написал быстрее, но менее читаемый.
• Порт делал «пачками»: сначала CLI, потом логика, потом MCP.
• После 3-х итераций тест прошёл.
• Время: ~30 мин, 3 коммита.

Вывод

• GPT-5 агентнее: сам планирует, реже спрашивает, меньше ошибок.
• Claude надёжнее в деталях, но требует чётких шагов.
• Оба справились, но GPT-5 ощущается «ближе к одной команде — один результат».

• Пользователи сомневаются в объективности сравнений: результаты сильно зависят от системных промптов, харнесов и задач.
• Критика выбора моделей: вместо топ-версии Claude Opus сравнивали более дешёвый Sonnet, что искажает оценку «лучшей» модели.
• Стоимость vs качество: большинство разработчиков не готовы платить 10× за Opus, поэтому GPT-5 рассматривают как «cost-effective» вариант.
• Опыт в продакшене: многие находят Claude Code (Sonnet/Opus) надёжнее при работе с большими кодовыми базами и TDD, тогда как GPT-5 хорош для разовых скриптов.
• Нет единой метрики: из-за недетерминированности моделей и субъективных критериев «хорошего кода» каждый получает разные результаты.

• Чёткое ТЗ — пишу заранее, чтобы агент видел контекст.
• Файл-инструкция по запуску линтервов и сборки.
• Саморевью — прошу 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 собственных патчей самим агентом.
• Некоторые вообще отказались от спецификаций: инкрементально подсказывают «следующий шаг, какой сделал бы я», сразу коммитят дифф и правят на лету.