Hacker News Digest

Кратко: автор высмеивает идею «поставь себе счётчик, и машина поедет быстрее» — когда проблему многозадачности и выгорания сваливают на самого работника.

Почему мы тут оказались:

• Люди «тормозят» не из-за личной рассеянности, а потому что им одновременно вбросили кучу нерасставленных по приоритету задач.
• Руководство поощряет реакцию на каждый пинг вместо сосредоточенной работы, а потом удивляется, что все вымотаны.
• Статьи вроде «просто не отвлекайся» — это перекладывание вины: «ты сам виноват, что система сломана».

Инструменты:

• Trello, Asana и им подобные — не инструменты производства, а инструменты отчётности, переложенные на подчинённых.
• Настоящие инструменты (git, CI, IDE) — без них работа встает; без доски задач — нет.

Вывод:
Перестать многозадачить и перестать выгорать можно только тогда, когда за это возьмётся руководство. Ответственность за культуру и процессы никогда не лежит в кармане у людей внизу табели о рангах.

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

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

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

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

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

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