Hacker News Digest

Автор утверждает, что изречение "Если хочешь идти быстро - иди один; если хочешь идти далеко - иди вместе" медленно убивает компании. Он сравнивает сотрудничество с вождением автомобиля: полезно получать навигационную помощь, но вредно постоянно менять водителей или получать комментарии о вождении. В компании PostHog ценят принцип "ты - водитель", нанимают хороших специалистов и не мешают им работать, но избыточное сотрудничество замедляет работу, снижает мотивацию и уверенность.

Причины избыточного сотрудничества включают желание быть полезным, недостаточную конкретность в запросах обратной связи и отсутствие ясности в определении ответственного. Автор предлагает решения: по умолчанию отправлять код (pull requests), а не обсуждать в Slack, и сокращать количество участников в обсуждениях. В компании даже подсчитали 175 упоминаний фразы "давайте обсудим" в Slack, что свидетельствует о проблеме.

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

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

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

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

Краткий перевод и сжатие

Инженер Sanity Винсент Куигли за 6 недель перешёл от ручного кода к 80 % генерации ИИ.
Ключевые идеи:

• 4 этапа: «пишу сам» → «ИИ как Stack Overflow» → «ИИ пишет, я ревью» → «я ставлю задачи, ИИ решает».
• 3 попытки:
  1. 95 % мусора, но быстрое черновое решение.
  2. 50 % мусора, структура ясна.
  3. Рабочий код после уточнений.
• Контекст: claude.md в корне проекта хранит архитектуру, стандарты, примеры.
• Команда агентов: один пишет код, другой тесты, третий документацию; ежедневно «забывают» контекст.
• Ревью: ИИ → я → команда; человек смотрит только критические места.
• Фоновые агенты: ночью чинят мелкие баги, утром присылают PR.
• Цена: 400 $/мес на токены, но экономит 30 % времени инженера (≈ 6 000 $).
• Риски: регрессии, безопасность, зависимость от ИИ.
• Эмоции: ушла «владение кодом», пришло «владение проблемой».
• Советы тимлиду: начинать с экспериментов, выделять «зоны ИИ», усиливать ревью.
• Советы разработчику: заведи claude.md, ставь ИИ задачи помельче, проверяй критикуй, не верь на слово.

• Участники сходятся: LLM хороши для отладки и брейншторма, но не способны самостоятельно писать сложный продакшен-код без доработки.
• Все обсуждают Claude Code: кто-то активно использует и хвалит, кто-то жалуется на переусложнённый код и высокие расходы (до $1500/мес).
• Повторяется один и тот же набор советов: дробить задачи, писать тесты, держать короткие циклы обратной связи, использовать линтеры и логирование.
• Некоторые инженеры предпочитают сначала строить архитектуру сами, а LLM оставляют для рутины; другие наоборот.
• Общий вывод: AI-ассистенты становятся стандартным инструментом, но пока не заменяют разработчиков и требуют постоянного контроля.

Что за ад творится?

Инженеры выгорают. Компании заставляют сеньоров ревьюить «вайб-код», который не работает. Лучшие разрабы рады помогать новичкам учиться, но вместо разбора фидбека джуны просто вставляют его в следующий промпт LLM.

На недавнем тан-холле команда джунов показала фичу, которую, похоже, не понимали сами. Сеньор-менеджер похвалил их за «4 000 строк кода, написанных Claude», и все аплодировали.

Мне попросили доработать фичу. Я связался с последним автором изменений, чтобы уточнить контекст. Ответ выглядел как прямое копирование из LLM — я почувствовал себя оскорблённым.

Друг жаловался: месяц ревьюит ПР, сгенерированный ИИ, командой из пяти человек. Экономия? ChatGPT за 20 $ в месяц, а потом армия инженеров пытается вмержить сгенерированный мусор.

Мы хотим помогать, учить, строить полезные вещи. Но какой смысл вкладываться в людей, если всё сводится к копипасту в «модель, в шаге от AGI»?

Попробуйте эксперимент: отключите «ИИ» хотя бы на день. Я сбросил комп, удалил Claude Pro — поиск и чтение доков дают более точный результат.

Кому вообще приносит прибыль ИИ? Схема: стартап на ИИ → венчур → деньги OpenAI → стартап исчезает. Даже OpenAI не в плюсе: технология жрёт электричество и не масштабируется. Это просто лохотрон.

• Разочарование от общения с коллегой, который просто пересылал вывод ChatGPT.
• Опасения, что AI-«вайб-кодинг» приводит к хрупкому, непонятному и ненадёжному софту.
• Мнение, что компании хотят быстрой «ценности», а не качественной разработки, и AI лишь усиливает эту проблему.
• Опыт разных людей: кто-то отказался от AI на дни/недели и почувствовал облегчение; кто-то использует AI как «умного джуна» под присмотром старшего инженера.
• Прогноз: через 10 лет младшие разработчики, не умеющие писать код вручную, станут «сеньорами», но системы будут всё хуже понимать и поддерживать.

Вместо «умных» функций — просто работающие.

Везде впихивают ИИ, который никто не просил: браузеры, ОС, конференц-приложения ломаются, но деньги текут в «искусственный интеллект».
Gamescom добавил ИИ-расписание: люди получили сотни ненужных встреч, функцию быстро убрали.
Те же деньги могли бы починить DM, поиск, перенос встреч — базовые вещи, из-за которых все возвращаются к почте и LinkedIn.

Мотив один: быстрая прибыль. В итоге продукты гниют, а инвесторы кормят обещания «вот-вот будет AGI».
Один бюджет крупной компании хватило бы на 100 лет развития Godot, Blender, Ladybird — реальных инструментов, которые нужны сегодня.

Потерянные годы не вернуть.

• Участники жалуются, что вместо починки старых багов и улучшения базовых функций компании впихивают «AI-фичи», которые никому не нужны.
• Многие считают, что инвесторы сознательно выбирают технологии, которые трудно децентрализовать, чтобы сохранить контроль и монополию.
• Одни видят в нынешнем AI-хайпе очередную моду, как было с UML, блокчейном и облаками; другие – шанс на прорыв, оправдывающий «пузырь».
• Популярная идея: деньги лучше бы пошли на документацию, API и совместимость, а не на обучение моделей водить мышкой по браузеру.
• Подводный тезис – проблема не в AI, а в концентрации капитала и в том, что «зелёное поле» проще финансировать, чем ремонт «коричневого».