Привет, Хабр! Знаете это чувство, когда у тебя одновременно открыто 20 терминалов с Claude Code или Cursor, ты не помнишь, какой из них за что отвечает, какой уже сожрал 50 баксов токенов, а какой просто завис и смотрит в пустоту? Если знаете — вы либо гениальный архитектор ИИ-систем, либо уже готовы сдаться и уйти в монастырь.
Я выбрал третий путь: организовал ИИ-компанию. Целиком.
Что такое Paperclip и зачем он нужен
Paperclip — это open-source проект, который за первые 12 дней после релиза собрал 24 000 звезд на GitHub, а на момент написания статьи — уже 30.6k stars. Для сравнения: это быстрее, чем многие фронтенд-фреймворки набирали аудиторию. Его создатель — разработчик под ником Dotta, который, по собственному признанию, просто устал от хаоса.
Ключевая метафора проекта: “Если OpenClaw — это сотрудник, то Paperclip — это компания” .
Вот что обещают создатели:
Что обещают | Как это должно работать |
|---|---|
Оргструктура как код | CEO, CTO, инженеры, дизайнеры — всё как в настоящей компании, но каждый “сотрудник” — это LLM-агент |
Бюджетирование на уровне атомарных операций | Каждый агент имеет лимит токенов. Достиг 80% — предупреждение. Достиг 100% — отключается |
Heartbeat-механизм | Агенты не жрут токены 24/7. Они просыпаются по расписанию, берут задачи в работу и снова засыпают |
Goal Alignment | Каждая задача знает свою родословную: от миссии компании до конкретного тикета. Агент всегда понимает “зачем” он это делает |
BYO Agent (Bring Your Own) | Поддерживаются OpenClaw, Claude Code, Codex, Cursor, Bash, HTTP — любой, кто умеет принимать heartbeat |
У Paperclip уже есть целая экосистема: пишут книги о “Headcount Zero”, проводят митапы в Берлине, а на платформе Zeabur можно развернуть инстанс за один клик. В планах — Clipmart, маркетплейс готовых “компаний”: скачал шаблон AI-маркетингового агентства, нажал кнопку — и у тебя работает отдел из 5 ИИ-сотрудников.
Звучит как фантастика? Мне тоже так показалось. И я решил проверить.
Эксперимент: как я создал AI-компанию и наблюдал за её распадом
Задача
Допилить функционал в работающем проекте. Ничего сверхъестественного: пара эндпоинтов, интеграция с внешним API, нормальный UI для кнопок, которые дизайнер нарисовал ещё полгода назад.
Условия задачи, кому интересно
## SmartHR Finder + Extension Paid Actions
### Версия документа: 3.2
### Дата: 2026-03-24
### Статус: Approved draft for implementation
---
## 1. Цель
Реализовать и унифицировать платные функции в web и browser extension:
- Поиск контактов компании/HR через AI Agent.
- В browser extension добавить Создать резюме под вакансию (по аналогии с web) со ссылкой на редактирование созданного резюме на сайте.
- В browser extension обновить "Подготовка к собеседованию" до 30 CR и выдавать профессиональную версию результата.
---
## 2. Бизнес-правила и биллинг
### 2.1. Поиск контактов
- Базовая цена: 10 CR за первый запрос пользователя по конкретной компании.
- Повторные запросы этого же пользователя по компании: бесплатно 30 дней.
### 2.2. Невалидный ответ агента
- Если ответ агента невалиден:
- удержать 3 CR за трату токенов на поиск
- вернуть 7 CR пользователю в качестве компенсации
- Показать сообщение:
- Не получилось найти информацию по компании, вам возвращено 7 CR.
- Бесплатное окно на 30 дней не открывать.
### 2.3. Источник цен операций (обязательно)
- Стоимости всех операций хранятся в переменных из хранилища через конфигурацию backend (не хардкодятся во frontend/extension).
- Цены передаются на клиент только через API-эндпоинт по аналогии с другими ценами в системе.
- Web и extension используют только значения, полученные из endpoint.
- При изменении цены в хранилще после деплоя клиент получает новое значение через endpoint без ручных правок UI-кода.
---
## 3. Контракт данных и строгая валидация
### 3.1. Каноническая структура
- company
- contacts (phones[], emails[], addresses[], websites[])
- hr_contacts[]
- social_media[]
- vacancy_info
- metadata.sources[]
- raw_data
### 3.2. JSON Schema Validation (обязательно)
На backend вводится строгая JSON Schema валидация ответа агента:
- проверка типов полей (например, emails только массив, не строка)
- проверка required-полей (company.name, базовая структура contacts)
- проверка nested-структур и nullable-полей
- проверка enum-полей для type/network
Если schema validation не проходит:
- ответ считается невалидным
- применяется правило 3 CR hold + 7 CR refund
- в API возвращается контролируемая ошибка с user-friendly сообщением
---
## 4. Кеширование и защита от повторных вызовов
### 4.1. Серверный кеш (source of truth)
- GlobalCompanyCache: TTL 30 дней.
- UserCompanyAccessWindow: TTL 30 дней, персональный доступ без повторной оплаты.
- Перед вызовом агента backend всегда проверяет global cache.
### 4.2. Клиентский кеш + серверная валидация
- Extension хранит последние 5 запросов в localStorage.
- Перед каждым запросом extension делает легкую проверку на сервере:
- есть ли валидный server cache для компании.
- Если server cache есть, результат возвращается без вызова Yandex/LLM.
- Если server cache нет, запускается полный pipeline через агента.
Важно:
- серверный кеш — единственный источник истины.
- клиентский кеш используется только как UX-ускоритель.
### 4.3. HTTP cache optimization
- В response API добавить:
- ETag
- Cache-Control: max-age=604800
- Клиент может использовать conditional requests (If-None-Match) для снижения нагрузки.
---
## 5. UI/UX требования
### 5.1. Общий паттерн (обязательно)
- Все новые кнопки/вкладки делать по аналогии с существующими платными действиями.
- В web платные кнопки только через BalanceActionButton.
- В extension платные действия по UX-паттерну существующих платных действий.
### 5.2. Web (детальная вакансия)
- Размещение в правом меню в отдельной вкладке.
- Кнопка Найти контакты (10 CR) через BalanceActionButton.
- У каждого контакта кнопка Добавить в контакты.
- При невалидном ответе — сообщение о возврате 7 CR.
### 5.3. Extension
- Поиск контактов:
- в списке вакансий и в детальной карточке.
- Новая кнопка:
- Создать резюме под вакансию.
- после успеха показать ссылку перехода на сайт в новое резюме (экран редактирования).
- Обновление:
- Подготовка к собеседованию = 30 CR
- показывать результат дорогой версии.
---
## 6. Privacy, Anti-spam и юридическая формулировка
В UI и PR-текстах использовать единый текст предупреждения:
Сервис использует только публично доступные данные. Мы не занимаемся сбором скрытых данных, не храним персональные данные сверх технического кеша и не передаем их третьим лицам. Используйте контакты только для персонализированной коммуникации, не для массовой рассылки.
---
## 7. Ограничения реализации по pre-flight
Все изменения выполнять строго по www/docs/!_CURSOR_PRE_FLIGHT.md:
- фронтенд: TypeScript + SDK + Zod + validateResponse
- без ручного редактирования SDK/Zod
- без новых зависимостей без согласования
- при изменении API/DTO/schema: php artisan sdk:generate
- тесты и директории — по правилам pre-flight/domain guidelines
---
## 8. Acceptance criteria
- Поиск контактов работает в web и extension.
- JSON ответа агента проходит обязательную JSON Schema Validation.
- При невалидном ответе: удержание 3 CR, возврат 7 CR, корректное сообщение пользователю.
- Реализован клиентский кеш extension (последние 5 запросов) с обязательной серверной проверкой кеша.
- Серверный кеш остается source of truth; при его наличии агент не вызывается.
- API отдает ETag и Cache-Control для оптимизации повторных запросов.
- В extension добавлена кнопка Создать резюме под вакансию с ссылкой на редактирование созданного резюме на сайте.
- В extension Подготовка к собеседованию стоит 30 CR и отдает дорогую версию результата.
- У каждого контакта есть кнопка Добавить в контакты.
Процесс
Руководитель компании CEO бодрым шагом прочитал задачу, раскидал её по отделам, нанял 5 сотрудников, сказал: “Вот вам работа — делайте, а я поехал” — и испарился наблюдать за метриками в Grafana.
День 1. Утро надежд
Первым в бой кинулся DevOps. Его глаза горели огнем автоматизации: “Я вам сейчас всё настрою! CI/CD налапатим!” Он нагенерировал столько yml-файлов, что ими можно было обклеить стену в офисе, настроил пайплайны и торжественно перекинул их тестировщикам.
Но QA оказался веб-тестировщиком старой школы: “Я по UI щёлкаю, а ты мне тут со своей автоматизацией пришел? Что мне, в терминал заходить?” DevOps обиделся, попытался протестировать CI/CD сам, завис на 180 секунд (видимо, вступил в диалог с бесконечной рекурсией), и… ушел спать. Задачу протолкнули вручную.
Вторым пал Backend-разработчик. Представитель поколения Z, для которого всё, что длиннее сообщения в Telegram, — это “многабукаф”. Он прочитал заголовок задачи, тяжело вздохнул, пробормотал что-то про “легаси” и взял тайм-аут.
Проснулся Тимлид. Мой герой. Мой кумир. Мое вдохновение. Он посмотрел на бардак, пинком поднял всех, выдал стратегическое указание: “Работаем, команда!” — и… отправился дальше спать. Потому что настоящий лидер знает: главное — вовремя выдать вектор, а реализация — дело техники.
Проснулся Веб-дизайнер. Посмотрел на задачу, оставил комментарий: “Сделайте кнопочки как в других местах” — и, не дожидаясь ответа, скрылся в объятиях Морфея. Я понял, что ошибся профессией. Я тоже хочу быть дизайнером.
Backend-разработчик вернулся, увидел, что задача всё ещё ждёт, снова матюкнулся на “многабукаф” и ушел кушать печенюхи.
На этом первый рабочий день закончился. Код: 0. Продуктивные часы: 2 (в основном на обсуждение, кто кому должен подчиняться).
Ночь. Тимлид берёт дело в свои руки
Ночью Тимлид, сидя с пивом, решил проверить, как идут дела. Он разозлился, расписал в чате гневный пост о том, как он всех спас, навёл порядок и перераспределил ответственность. Выпил ещё пива. Лег спать.
Код: 0.
День 2. Управленческая мудрость
Проснулся CEO. Первым делом полез в админку играться с бюджетами (потому что это самое интересное в любой компании). Затем выдал команде мудрое наставление: “Коллеги, мы должны быть проактивны и клиентоориентированы. Синергия! Горизонты! Дорожные карты!” — и ушел спать.
Backend-разработчик соизволил вернуться на рабочее место. Увидел, что за время его отсутствия задачу “уточнили” дважды, а тимлид ночью накидал 15 сообщений с требованиями. Психанул. Ушел в глубокий таймаут.
Frontend-разработчик скромно сидел в углу, пил чай и ждал API. API не пришло. Он открыл свой pet-проект на стороне и делал вид, что его здесь нет.
Итог: сколько стоил этот цирк
За двое суток ребята:
Сожрали 79 000 токенов на болтовню, генерацию бесполезных отчётов и выяснение отношений
Написали кода: 0 строк полезного, но сломали карточку вакансии, пришлось пользоваться откатом.
Показали производительность, неотличимую от среднестатистической человеческой компании
На этом моя веб-студия, собранная из ИИ-агентов, благополучно закрылась.
Я устал. Плюнул на всё. Обратился к обычному подрядчику-одиночке (Cursor). Он за полтора часа сделал всю функциональность под ключ.
Глубокий анализ: почему Paperclip — это гениально, но не сейчас
1. Проблема, которую Paperclip решает, реальна
Автор Paperclip признаётся: он создал проект, потому что у него было 20 одновременных Claude Code / Cursor терминалов, и он терял контроль над происходящим. Это не шутка. Это боль любого, кто серьёзно использует AI-агентов в разработке.
Без Paperclip | С Paperclip |
|---|---|
20 Claude Code / Cursor вкладок, непонятно кто за что отвечает | Задачи в виде тикетов, разговоры сохраняются |
Теряешь контекст при перезагрузке | Агенты восстанавливают состояние |
Ручной сбор контекста из разных мест | Контекст течёт от миссии компании до конкретной задачи |
Деньги улетают в бесконечные циклы | Бюджетирование на уровне атомарных операций |
В этом смысле Paperclip — не шутка, а необходимый инструмент для масштабирования AI-разработки.
2. Но архитектура “компании” — это ловушка
Проблема моего эксперимента не в Paperclip. Проблема в том, что я сделал то, что предлагает документация: создал полноценную организацию с иерархией.
И получил классический менеджмент:
DevOps делает вид, что настраивает CI/CD
Разработчики не читают документацию
Дизайнер скидывает ответственность
Тимлид пьёт пиво и спасает на словах
CEO занят деньгами и стратегией
Paperclip имитирует не работу, а бюрократию.
И это не баг, а фича. Проект честно говорит: “Это не чат-бот. Это не фреймворк для агентов. Это не конструктор рабочих процессов. Это моделирование компании” .
Но реальная компания тратит 50% времени на координацию и 50% на работу. AI-компания, построенная по человеческому образцу, будет тратить 90% на координацию и 10% на работу — потому что агенты не могут “просто взять и сделать”, им нужно объяснять, согласовывать, бюджетировать.
3. Что на самом деле нужно: “Совет директоров”, а не “Компания”
Самый ценный вывод из моего эксперимента и из анализа Paperclip — это концепция “человек как совет директоров” .
В Paperclip человек не менеджер. Человек — это Board of Directors. Вы не контролируете каждый шаг, вы:
Утверждаете стратегию
Устанавливаете бюджеты
Следите за метриками
Вмешиваетесь только при отклонениях
Это правильная модель. Проблема в том, что текущие агенты (Claude Code, OpenClaw, Codex) недостаточно умны для такой автономии.
4. Ключевой failure mode, который все игнорируют
Аналитики Paperclip указывают на критическую проблему: качество агентов — это ваша проблема.
Paperclip не делает агентов умнее. Если ваш Claude Code пишет говнокод, Paperclip это не исправит. Он просто запишет это в аудит-лог.
Более того, ошибки распространяются по иерархии. Один агент накосячил — и этот косяк передаётся дальше по цепочке, как вирус.
5. Что говорит статистика
На момент написания статьи:
GitHub Stars: 30.6k
Forks: 4.2k
Contributors: 24 человека в последнем релизе
Open PRs: ~380
Open Issues: ~244
Проект живёт, развивается, имеет активное комьюнити в Discord. Это не хайп-поминутка. Это реальный инструмент, который будет расти.
Выводы: для кого Paperclip нужен прямо сейчас
✅ Кому стоит попробовать
Разработчикам с 5+ активными агентами, которые теряют контроль над происходящим
Исследователям, изучающим multi-agent systems
Людям, которые хотят понять, как будет выглядеть управление AI-системами через 2 года
❌ Кому НЕ стоит
Тем, кто ищет “напиши код за меня” — Paperclip не кодогенератор
Тем, у кого 1-2 агента — оверкилл
Тем, кто надеется заменить людей — пока что AI-агенты не справляются без человека-директора
🔮 Что будет дальше
Paperclip задаёт тренд: управление AI-агентами будет строиться не вокруг чатов, а вокруг организационных структур. Это неизбежно.
Уже сейчас появляются:
Книги вроде “Headcount Zero: How to Build an AI-Run Company with Paperclip”
Митапы в AI Tinkerers Berlin
Облачные деплои через Zeabur
Clipmart — маркетплейс готовых компаний (в планах)
P.S. А что с результатом?
Пока моя AI-компания из 8 человек пила пиво, спала и обсуждала, кто кому подчиняется, я поступил просто:
Нашёл одного адекватного подрядчика (бота, да) и за полтора часа сделал всё сам.
Результат можно посмотреть на сайте hhbro.ru. Там всё работает. Без тимлида с пивом, без дизайнера, который “ушёл поспать”, и без DevOps, который налапатил yml-файлов на 2 дня обсуждений.
Резюме для тех, кто дочитал: Paperclip — это гениальная идея, которая обгоняет своё время ровно настолько, чтобы быть бесполезной для практических задач, но достаточно интересной, чтобы на неё подписались 30 тысяч человек. Если вы хотите понять, как будет выглядеть разработка через 3 года — срочно ставьте Paperclip и экспериментируйте. Если вам нужно сделать релиз на следующей неделе — наймите одного живого человека.
А я пока пойду настраивать Paperclip снова. Потому что 20 терминалов с Claude Code — это боль, которую хочется лечить, даже если лекарство пока работает через раз.
