Hacker News Digest

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

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

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

Джеймс Шор в своем выступлении на Agile Cambridge 2025 поднимает проблему подотчетности отделов разработки ПО. Он утверждает, что разработчикам необходимо самостоятельно определять критерии своей подотчетности, чтобы бизнес-партнеры не навязывали свои метрики. Шор, имеющий 23-летний опыт консультирования и сейчас работающий VP of Engineering в OpenSesame, фокусируется на поздних стартапах с предпринимательским мышлением, которые пытаются масштабироваться, сохраняя инновационность.

Автор подчеркивает важность контекста, отмечая, что его советы применимы в основном для компаний, создающих и продающих ПО. Шор использует метафору "Хронофага" (часов с монстром) для иллюстрации ценности времени и цитирует LP Hartley: "Прошлое — это чужая страна: там всё делают иначе", намекая на необходимость новых подходов к подотчетности. Он также уточняет, что контент создавался без ИИ, хотя декоративные изображения для слайдов были сгенерированы.

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

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

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

Традиционное продуктовое планирование часто страдает от чрезмерной бюрократии, реактивных решений и зависимости от мнения основателей. Попытки внедрить OKRs в креативных инженерных командах часто проваливаются, поскольку метрики плохо сочетаются с творческими задачами и создают больше ритуалов, чем реальной ясности.

Railway разработала альтернативу — Problem Driven Development. Это четырёхдневный квартальный процесс, где команда фокусируется на идентификации проблем (а не решений), совместном приоритизировании и публичных обязательствах. Такой подход сохраняет скорость разработки даже при масштабировании до 1.7M+ пользователей, заменяя жёсткие планы гибкой системой, ориентированной на реальные вызовы.

• Критика практик ежеквартального планирования как негибких и не учитывающих реальные проблемы продукта
• Предложения альтернативных подходов, таких как Shape Up с 6-недельными циклами или фокус на проблемах, а не решениях
• Обсуждение важности открытого продукт-дискавери и кросс-функционального согласования целей между командами
• Указание на системные проблемы: неверные метрики (деньги вместо ценности), организационные барьеры и плохие стимулы
• Замечания о качестве статьи: сложный язык, избыток жаргона и недостаточная глубина раскрытия темы

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

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

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

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

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

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

Инженер 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, а в концентрации капитала и в том, что «зелёное поле» проще финансировать, чем ремонт «коричневого».