Hacker News Digest

Linear утверждает, что прибыльность для стартапа — это не признак недостатка амбиций, а способ контролировать свою судьбу. Основатель Karri Saarinen рассказывает, как Linear случайно стал прибыльным через 12 месяцев после запуска благодаря небольшому команде и почти 100% конверсии бета-пользователей в платящих клиентов. Он ссылается на эссе Пола Грэма "ramen profitability" (2009) и утверждает, что сегодня стало не только легче достичь такой точки, но и традиционной прибыльности при быстром росте.

Автор критикует тенденцию нанимать большие команды, утверждая, что небольшие команды работают лучше и быстрее. Linear удваивал команду каждый год, фокусируясь на качестве, а не количестве. "Люди должны удивляться, насколько маленька ваша команда, а не насколько она велика", — подчеркивает Saarinen. Прибыльность дает душевное спокойствие и позволяет сосредоточиться на создании ценности, а не на следующем раунде финансирования.

Для достижения прибыльности советуют измерять выручку на сотрудника (цель $500k-$1M для стартапов), понимать профиль риска и нанимать осознанно. "Десять человек до подтверждения продукт-рыночного соответствия должны быть вашим потолком, а не целью", — отмечает автор. Медленный рост штата защищает культуру и обеспечивает более качественный найм.

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

Jules — это ИИ-агент для автоматизации разработки, который теперь предлагает API для интеграции в рабочие процессы. С его помощью можно автоматизировать создание задач, исправление багов и внедрение фич через инструменты вроде Slack, Linear или Jira, а также встраивать в CI/CD-пайплайны GitHub Actions. Например, можно отправить запрос на создание сессии через cURL, указав промпт и контекст репозитория.

Кроме API, в обновлениях появилась поддержка командной строки, веб-серфинг, тестирование веб-приложений с визуализацией результатов, работа с обратной связью из PR, загрузка изображений и увеличение размера VM до 20 ГБ. Агент стал быстрее и надёжнее, добавлена критика кода, интерактивное планирование и поддержка Bun.

• Перенос инфраструктуры на Railway и использование Jules для самостоятельного создания PR клиентом для мелких правок
• Критика Jules как продукта Google: фрагментация предложений, опасения по поводу закрытости и возможного прекращения поддержки
• Обсуждение различий между Jules, Claude Code, Copilot и другими агентами, их интеграций и безопасности
• Сравнение моделей использования: асинхронные агенты vs. интерактивные инструменты в IDE, вопросы доверия и ROI
• Критика антропоморфных названий продуктов и размышления о целесообразности разработки в личное время

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

Гибкое ПО поглотит SaaS

Победителями эпохи ИИ станут не те инструменты, к которым привыкаешь ты, а те, что подстраиваются под тебя.

Linear — красивый, но жёсткий: ИИ может лишь ускорить рутину, но не изменить процесс.
Fibery — сложный, но гибкий: ИИ превращает недели настройки в несколько запросов. Когда «как» исчезает, побеждает «что».

От решения к проблеме

Раньше: описал задачу → сам собрал решение.
Сейчас: описал задачу → ИИ собрал решение. Барьер входа упал, прототип готов за минуты.

Почему гибкое ПО выиграет

До ИИ кастомизация была уделом гиков. Простые вертикальные продукты побеждали, потому что «как» было дорого.
Когда «как» стало дешёвым, нет смысла мириться с чужим процессом. Нужно изменить инструмент — ИИ подстроит его за минуты.

Траектория

• 2025–2027 ИИ сглаживает крутые кривые обучения; миграции ускоряются.
• 2028–2030 Вопрос покупателя: «Насколько легко изменить потом?» Жёсткие инструменты теряют позиции.
• 2030–2035 Настройка = диалог; большинство вертикальных SaaS становятся нишевыми.

Жёсткие решения не исчезнут полностью, но большинству достаточно ПО, которое гнётся, но не ломается.

• Участники спорят, заменят ли LLM-инструменты классические SaaS: одни уже делают «самоделки» под себя, другие считают, что большинству нужна стабильность и стандартизация.
• Ключевой аргумент против: гибкое ПО легко превращается в хрупкий «спагетти-код», а жёсткие, «опиниейтед» системы заставляют компании пересмотреть процессы и масштабироваться.
• Опыт HR-стартапа показывает: главная ценность SaaS не в адаптации к бардаку, а в том, чтобы навести порядок в процессах клиента.
• Некоторые верят, что дёшевый код приведёт к «один клиент — один кастом», но сомневаются в надёжности и безопасности таких решений в финансах, здравоохранении и других регулируемых отраслях.
• Итог: гибкость и жёсткость — ортогональные свойства; SaaS как модель монетизации никуда не исчезнет, но границы между «настроить» и «написать с нуля» могут размыться.

async-server — это CLI-утилита, объединяющая Claude Code, Linear и GitHub PR.
Она позволяет:

• Планировать задачи прямо в терминале (как в Linear).
• Писать код с помощью Claude Code: создавать ветки, коммиты, PR.
• Ревьюить изменения и мержить без выхода из консоли.

Установка:

npm i -g async-server
async-server init

Команды:

• async task "добавить логин" – новая задача.
• async code – Claude генерирует код.
• async pr – создаёт PR и связывает с задачей.

Полностью асинхронный workflow: задачи, код, ревью — всё в одном потоке.

• Пользователи хвалят темную тему и концепцию, но сомневаются в необходимости платить GCP за каждое взаимодействие и просят локальный режим.
• Критика: не хватает полноценного тестирования (сборка/запуск кода), а упоминание Linear в заголовке кажется лишним.
• Автор подтверждает: сейчас большая часть выполняется в облаке, но команда работает над локальной версией и улучшенным тестированием изменений.

Начав использовать Linear, я углубился в «локально-ориентированные» приложения: клиент хранит полную БД, изменения сначала пишутся локально, а фоновый sync-рантайн рассылает их по WebSocket/GraphQL. Пользователь видит мгновенные обновления без сетевой задержки.

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

В 2025-м экосистема уже готова:

• Electric SQL — Postgres-синхронизация
• PowerSync — корпоративный уровень
• Jazz — «обновляешь локальный state — всё синхронизируется»
• Zero, Instant, Triplit, LiveStore — упрощают разработку

Jazz предлагает CoValues: схема на Zod + автоматическая репликация. Пример:

const Post = co.map({
  title: z.string(),
  comments: co.list(Comment)
});

Меняешь post.title — изменение мгновенно отражается у всех участников.

• Участники обсуждают преимущества и недостатки подходов local-first (Zero, Electric, Jazz, CRDT, PouchDB, Turso и др.).
• Ключевые плюсы: мгновенный UX, офлайн-работа, упрощённая синхронизация через запросы (Zero) и отсутствие конфликтов (CRDT).
• Минусы: рост данных, проблемы разрешения конфликтов, сложность прав и миграций, ограниченная поддержка SSR-ценящих разработчиков.
• Некоторые считают, что SSR всё ещё важен для первой загрузки, но не решает офлайн/коллаборацию.
• Подводный камень: большинство инструментов заточены под веб, хотя мобильные сценарии офлайна выглядят более естественными.