Из вайбкодера в CEO: Personal Corp на GitHub
Утро. Открываешь GitHub. Issues разобраны. Два pull request ждут ревью. Документация обновлена. CI-провалы расследованы.
Ты ничего из этого не делал. Вчера написал три issue и ушёл спать.
Это не фантазия — дословная цитата из блога GitHub про Agentic Workflows от 13 февраля 2026. И это уже работает.
GitHub Issues — командный язык для AI-агентов. Единый интерфейс, через который один человек управляет роем: назначает задачи, отслеживает прогресс, принимает результаты. Кто научился думать задачами вместо промптов — уже строит Personal Corp. Компанию из одного человека и десятка агентов.
Три уровня: от промпта к компании
Вайбкодер проходит три стадии. Я точно прошёл.
┌──────────────────────────────────────────────────────┐
│ Уровень 1: ПРОМПТ В ЧАТ │
│ "Сделай мне лендинг с формой" │
│ → Один агент, одна задача, контекст теряется │
├──────────────────────────────────────────────────────┤
│ Уровень 2: ISSUE КАК ЗАДАЧА │
│ Issue #42: "Добавить форму подписки" │
│ → Агент берёт задачу, делает PR, отчитывается │
├──────────────────────────────────────────────────────┤
│ Уровень 3: ОРКЕСТРАТОР КАК МЕНЕДЖЕР │
│ Задача → Оркестратор → Декомпозиция → Агенты │
│ → Код, тексты, аналитика — параллельно │
└──────────────────────────────────────────────────────┘
На первом уровне ты — человек с терминалом. Пишешь промпт, получаешь результат, пишешь следующий. Закрыл окно — потерял контекст.
На втором — менеджер. Issue содержит описание, acceptance criteria, связанные задачи. Агент работает асинхронно. Ты занимаешься другим.
На третьем — CEO. Ты описываешь задачу, оркестратор сам декомпозирует, раздаёт агентам, проверяет результат. Агенты работают параллельно — и не только над кодом: тексты, аналитика, стратегия.
Разница между уровнями — не в инструментах. В мышлении.
Почему Issues, а не промпты в чате
Когда я попросил Claude Code “сделай бот-флоу предзаписи”, результат был нормальный. Но через неделю я не мог вспомнить, что именно попросил, что агент сделал, и где это в коде.
Когда я создал issue #74 — всё изменилось. Три причины.
Контекст не теряется. Issue — документ. Описание, обсуждение, linked PR, комментарии агента — всё в одном месте. Через месяц открываю issue и вижу полную картину: что хотел, что получилось, какие решения принимались.
Параллельность. Промпт в чат — последовательная работа. Один агент, одна задача. С Issues я запускаю пять агентов на пять задач одновременно. Каждый в своём worktree, каждый со своим контекстом. Продолжаю тему из GitHub Projects как память для AI-агента — Projects добавляет координацию и приоритизацию.
Единый источник правды. Промпты разбросаны по чатам и терминалам. Issue board — единственное место, где видно: что в работе, что заблокировано, что сделано. Это не мой вывод — это центральная идея CCPM, проекта, который превращает PRD в эпики, эпики в Issues, Issues — в параллельных агентов.
Как это уже работает
В феврале 2026 GitHub выкатил серию агентных возможностей. По-моему, каждая из них указывает в одну точку.
Copilot Coding Agent. Назначаешь issue на Copilot — он сам делает PR. Берёт задачу, агент пишет код, запускает тесты, просит ревью. Оставляешь комментарии — дорабатывает. Запущено ещё в июне 2025, к февралю 2026 стало стандартом.
Agent HQ. С 5 февраля 2026 Claude и Codex доступны прямо внутри GitHub. Назначаешь задачу на Copilot, Claude или Codex — или на всех троих, чтобы сравнить. Один интерфейс, разные “мозги”.
Agentic Workflows. Автоматизация на Markdown вместо YAML. /plan в комментарии к issue — агент разбивает задачу на sub-issues. В Peli’s Agent Factory Plan Command сгенерировал 514 merged PR из 761 — 67% success rate.
Spec Kit. GitHub выпустил open-source тулкит с 71k+ звёздами. Четыре фазы: /specify — /plan — /tasks — /implement. Спецификации становятся исполняемыми артефактами. Поддерживает 20+ агентов, включая Claude Code.
IssueOps. Паттерн, описанный GitHub ещё в марте 2025: Issues как центр управления. Labels и комментарии — команды. Issue открылся — воркфлоу запустился.
Всё сходится: Issue — единица работы для агента.
Реальный кейс: Personal Corp через issue #74
Я запускаю предзапись на Personal Corp — формат “компания одного человека с агентами”. Нужен был бот-флоу: deeplink, обработчик в Telegram-боте, сегмент для рассылок, terminal-стиль экран с текстом.
Раньше я бы писал промпт на 40 строк с деталями реализации. Сейчас — создал issue с описанием задачи и дал его оркестратору.
Написал Claude Code на Opus 4.6:
Я описал что нужно. Оркестратор сам декомпозировал задачу, раздал подзадачи агентам, проверил результат.
Что произошло:
- Оркестратор разбил задачу на части: deeplink, хендлер, сегмент, terminal-стиль экран
- Агенты параллельно создали код, тексты, кнопки-реакции с трекингом
- Коммиты с пометкой (#74) — каждый привязан к issue
- Оркестратор отчитался комментарием и поставил Done
Я не следил за процессом. Открыл проект через час — зелёная галочка. Подробнее про механику — в Хуки Claude Code: агент сам ведёт задачи.
Вся история решения — в issue. Не в голове, не в логах терминала.
Personal Corp: не только код
Сэм Альтман говорил, что первые компании-на-10-человек с оценкой в миллиард появятся скоро. В феврале 2026 это уже произошло: один человек, open-source проект, торги между Meta и OpenAI.
Но тебе не нужен миллиард. Personal Corp — про другое. Один человек делает работу десяти, если умеет описывать задачи и доверять оркестратору.
И тут важно: Personal Corp — это не про код. Код — частный случай. Агенты умеют больше: анализировать стратегию, находить проблемы в продукте, писать тексты, считать метрики. Я запускал консилиум из трёх агентов-экспертов — UX, архитектура, бизнес — и они нашли разные проблемы в проекте, которые один агент пропустил бы. Это уже не вайбкодинг. Это управление.
GitHub Issues — интерфейс для такой “компании”. Но необязательно раскладывать задачи на доске вручную. Оркестратор — агент-менеджер — сам берёт issue, декомпозирует на подзадачи и раздаёт.
Agentic Project Management формулирует это прямо: главная причина, по которой нужна структура задач — ограничение контекста агента. Агент не может держать в голове весь проект. Но он идеально выполняет одну чётко описанную задачу.
┌──────────────────────────────────────────┐
│ PERSONAL CORP │
│ │
│ Ты: описал задачу │
│ │ │
│ ▼ │
│ оркестратор │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ код тексты аналитика │
│ │ │ │ │
│ └─────┼─────┘ │
│ ▼ │
│ ревью и деплой │
└──────────────────────────────────────────┘
Ты не пишешь код. Ты даже не раскладываешь задачи. Ты описываешь что нужно — оркестратор делает остальное. Это и есть Personal Corp.
Как начать прямо сейчас
Не нужно ждать идеального стека.
Шаг 1. Следующую задачу для агента оформи как Issue. Не промпт в чат — issue. С описанием, acceptance criteria и ожидаемым результатом.
Шаг 2. Создай GitHub Project. Перенеси задачи. Расставь приоритеты. Подробнее — в Контекст проекта в GitHub Issues: делегируй агенту.
Шаг 3. Попробуй назначить issue на Copilot. Или попроси Claude Code взять issue и отчитаться комментарием. Я видел, как люди после первого такого issue уже не возвращаются к промптам в чат.
Промпт — разговор. Issue — контракт. Агенты хорошо работают по контрактам.
Частые вопросы
Нужен ли GitHub Pro или Enterprise для работы с агентами?
Copilot Coding Agent доступен с Copilot Pro+. Но сам подход — оформлять задачи как Issues и использовать Project Board — работает бесплатно с любым агентом, включая Claude Code.
Чем Issues лучше TaskMaster, Linear или Notion для управления агентами?
Issues живут рядом с кодом. PR привязывается к issue через (#N) в коммите. Агент может читать issue, комментировать, закрывать. Нативная интеграция, а не мост между системами.
С чего начать, если я только пробую вайбкодинг?
С одного issue. Опиши задачу, попроси агента взять её и отчитаться. Сравни с тем, как обычно пишешь промпт в чат.
Я строю Personal Corp — формат, где один человек управляет агентами через задачи и оркестратора. Не код, а результаты. Не промпты, а контракты.
Если хочешь попробовать — запишись в waitlist. Расскажу, как это устроено изнутри.
Подписаться на обновления — @sereja_tech