HarnessOS

# Строю инструмент, которого мне самому не хватает

Хочу понять, нужен ли он ещё кому-то.

Последние месяцы я работаю над HarnessOS — платформой для разработки с помощью AI-агентов. Но не очередным «AI-помощником в редакторе». А инструментом, который ставится на свой сервер и держит весь процесс под контролем.

---

Почему я это начал

Я пробовал Cursor, Windsurf, Claude Code. Они классные. Но есть три вещи, которые меня не устроили:

1. Код уходит в облако. Ты не знаешь, что с ним происходит. Для многих команд это неприемлемо. 2. Нет контроля. Агент сказал «готово» — значит готово. Хочешь проверить, что реально сделано — иди разбирайся сам. 3. Нет памяти и порядка. Каждый раз начинаешь с нуля. Никто не помнит, что делал вчера, какие решения принял и почему.

---

На чём это построено

В основе HarnessOS лежит моя собственная разработка — Prompt Factory.

Это не фреймворк. Не библиотека. Не «ещё один AI-инструмент».

Это методология и инструмент дисциплины для AI-разработки. Я собрал его за годы работы над сложными проектами — и он уже прошёл проверку на реальных продуктах, не на демо.

---

Что это такое

Prompt Factory превращает хаос AI-разработки в процесс.

Когда ты работаешь с AI без структуры, происходит одно и то же: быстро генерируется код, который выглядит правильно, но ломается на первом же нетривиальном сценарии. Потому что AI не думает о последствиях. Он думает о следующей строке.

Prompt Factory заставляет сначала договориться — что именно строится, зачем, какие границы и как проверить результат. И только потом — писать код.

---

Из чего состоит дисциплина

Без деталей реализации, но по сути:

- Ясность до кода. Сначала фиксируется цель, бизнес-смысл, KPI. Не «сделай мне фичу», а «вот зачем, вот как измерим, вот что НЕ входит». - Декомпозиция. Большая задача режется на тонкие куски, каждый из которых можно проверить отдельно. Не «сделай всё», а «сделай шаг — проверь — сделай следующий». - Проверяемость. Каждый шаг имеет критерии приёмки. Не «работает», а «вот сценарий, вот ожидаемый результат». Критерий не выполнен — шаг не закрыт. - Ограничения. Агент не может выйти за рамки задачи. Не «попутно отрефакторить весь модуль», не «добавить фичу, которую никто не просил». - Память и след. Каждое решение фиксируется. Не «мы это уже обсуждали», а «вот запись, вот причина, вот дата».

---

Почему это важно

AI-разработка без дисциплины — это скорость без направления. Ты быстро пишешь код, который потом дорого разгребать. Verification Tax съедает всю сэкономленную скорость.

Prompt Factory — это дисциплина, встроенная в инструмент. Не «постарайся писать аккуратно». А «система не даст сделать иначе».

HarnessOS — это исполняющая оболочка для этой дисциплины. Prompt Factory описывает что и как должно быть. HarnessOS исполняет это — с ролями, проверками, памятью и контролем.

---

А чем это отличается от Cursor + OpenSpec?

Справедливый вопрос. Cursor — отличный инструмент. OpenSpec — умный подход к спецификациям. Вместе они дают spec-driven workflow: сначала описываешь, что хочешь, потом агент делает.

Но это IDE + методология. Ты работаешь внутри Cursor. Код уходит в облако. Память живёт в чате — закрыл чат, контекст пропал. Оркестрации нет — ты сам решаешь, что делать дальше.

HarnessOS — это control plane. Ты работаешь над процессом. Агенты подчиняются плану, проверкам и лимитам, которые ты задал. Код остаётся у тебя. Память и решения не теряются между сессиями.

---

Кто уже на рынке — и почему это хорошая новость

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

Вот кто решает похожие задачи. Три ветки.

1. Spec-Driven Development

Это инструменты, которые заставляют работать по спецификациям. Сначала договориться — потом делать.

- OpenSpec — лёгкий CLI. «Built for brownfield» — для существующих проектов. Workflow: propose → apply → archive. Работает с Cursor, Claude Code и другими. 55k+ звёзд на GitHub. - GitHub Spec Kit — официальный от GitHub. Тяжелее, с конституцией и планированием. 115k+ звёзд. - Kiro — IDE от AWS. Встроенный spec-driven workflow.

Что они делают: дают дисциплину спецификаций. Ты описываешь, что строится, — и только потом пишешь код.

Чего у них нет: они не runtime. Они дают структуру. Исполнять её ты должен сам.

2. Agent Harness

Это инструменты, которые исполняют задачи. Runtime для агентов.

- DeepSeek Harness — открыт в августе 2026. MIT, «всё есть плагин». 150k+ звёзд. Модель + Harness = Agent. Сандбокс, оркестрация, память, UI. Пока Developer Preview. - OpenHarness — от HKUDS. 10 подсистем, 43+ инструмента, MCP, permissions, skills, multi-agent. - OpenHands — self-hostable платформа для автономной разработки. Может работать с репозиториями, выполнять команды, модифицировать код.

Что они делают: дают двигатель. Агенты работают, tools вызываются, память пишется.

Чего у них нет: они не заставляют работать по спецификации. Это мощные двигатели — но без процессной дисциплины.

3. Memory-слой

Это компоненты для памяти агентов.

- mem0 — $24M Series A, ~48k звёзд. Universal memory SDK. - Zep / Graphiti — temporal knowledge graph. Enterprise-фокус, $12M seed. - total-agent-memory — local, MCP-native, для coding agents.

Что они делают: дают агентам память.

Чего у них нет: они не управляют процессом. Память — это компонент, а не control plane.

---

Попытки склеить это уже есть

На рынке уже появились плагины, которые пытаются соединить SDD + Harness:

- specpowers — плагин для DeepSeek Harness, склеивает OpenSpec + TDD в Phase 0→4 workflow. - dsh-spec-loop — добавляет /spec команды в Harness: propose → approve → implement → verify → archive. - openspec-agents — multi-agent orchestration поверх OpenSpec.

Они работают. Для индивидуального разработчика или небольшой команды — возможно, достаточно.

Но они — плагины. Надстройки над чужим runtime. И это принципиально.

---

Почему «DeepSeek Harness + OpenSpec» — это не то же самое

Три причины.

1. Ты зависишь от чужого runtime. DeepSeek Harness — «всё есть плагин», но состояние сессии, память, решения — в его архитектуре. Ты зависишь от его plugin API, который ещё в Developer Preview и может ломаться. 2. «Всё есть плагин» — это сила и слабость. Любой может написать плагин. Но нет гарантии, что плагин делает то, что обещает. specpowers, dsh-spec-loop, openspec-agents — community-плагины, не часть ядра. 3. Три продукта ≠ один процесс. OpenSpec даёт specs. Harness даёт runtime. Плагины их склеивают. Но они не решают проблемы escalation, budget, RBAC, isolation.

HarnessOS — это control plane, который делает всё сам. Не «склейка трёх инструментов». А цельная система: specs, runtime, gates, memory, escalation — в одном месте.

---

И вот почему я думаю, что я на правильной стороне рынка

Когда DeepSeek выпускает Harness — это сигнал. Крупный игрок видит ту же боль, что и я. Значит, проблема реальна, и рынок формируется.

Когда GitHub выпускает Spec Kit, а AWS — Kiro — это второй сигнал. Гиганты не вкладываются в то, что никому не нужно.

Когда появляются community-плагины вроде specpowers — это третий сигнал. Люди уже хотят соединить SDD и Harness. Но делают это своими руками, потому что готового решения нет.

Я не изобретаю проблему. Я отвечаю на реальный спрос.

Разница в том, что именно я строю. DeepSeek Harness — двигатель. OpenSpec — слой дисциплины. Плагины — склейка.

HarnessOS — control plane. Не «двигатель плюс слой». А система, которая держит процесс целиком: план, роли, проверки, память, лимиты, эскалация.

Три сигнала от трёх крупных игроков. Если это не правильная сторона рынка — я не знаю, что тогда правильная.

---

Про Verification Tax — или почему «быстрее писать» не значит «быстрее выпускать»

Есть одна вещь, о которой почти никто не говорит, когда хвалит AI-разработку.

AI пишет код быстро. Правда быстро. Проблема в том, что проверка этого кода не ускоряется. Иногда — замедляется.

Это называют Verification Tax — налог на проверку. Ты экономишь час на написании, но тратишь полтора на то, чтобы понять, что именно агент сделал, не сломал ли он что-то, и почему тесты вроде зелёные, а поведение — нет.

Когда AI генерирует код, он выглядит правильно. Синтаксис чистый, линтер доволен, компилируется. Ошибки — тонкие. Пропущенный edge case, неверный статус, молчаливое исключение. Их не видно, пока не начнёшь копать.

И чем больше агентов и шагов в цепочке, тем хуже. Система с 90% точностью на каждом шаге после шести шагов даёт ~53% надёжности. Ошибки накапливаются, а не усредняются.

Что это значит для HarnessOS

Я строю платформу, которая снижает Verification Tax, а не увеличивает его.

Не «AI пишет код, а ты потом разгребаешь». А «AI пишет код, а система сама проверяет его на каждом шаге — и останавливается, если что-то не так».

Это не «AI проверяет AI» — это тупик. Это детерминированные проверки: тесты, линтер, типы, соответствие плану. То, что не может быть «уговорено» агентом.

Если проверка не прошла — код не идёт дальше. Он откатывается. Ты видишь, что именно сломалось.

---

Какие технологии я использую для обвязки

Не буду углубляться в реализацию, но скажу категории:

- Память. Агент помнит, что делал вчера, какие решения принял и почему. Это не «история чата», а структурированная база знаний о проекте. - Оркестрация. Не один агент, а роли: один планирует, другой пишет, третий проверяет. Работают по очереди, не мешают друг другу. Модели выбираются под задачу — слабая для простого, сильная для сложного. - Проверки. После каждого кусочка — автоматическая проверка. Не «агент сказал готово», а «тесты прошли, линтер чист, план выполнен». - Изоляция. Агент работает в песочнице. Если что-то сломает — откатывается, не трогая остальное.

Всё это — на твоём сервере. Модель — облачная или локальная, на твой выбор. Код, память, логи — у тебя.

---

Про токены — честно

Да, это будет дороже, чем один короткий чат в Cursor. За один осмысленный цикл HarnessOS съест больше токенов. Вопрос не «дешевле ли чата», а «дешевле ли хаоса» — бесконечных переписок, переписывания с нуля и «агент сказал готово».

Где реально уходят токены:

| Что | Расход | Комментарий | |-----|--------|-------------| | Plan | Самый выгодный | План до кода = меньше переписываний целых модулей | | Execute с узким контекстом | Средний | Берётся только то, что нужно для задачи, а не полрепы | | Reviewer / QA вторым проходом | +30–80% к задаче | Ловит дыры до merge, а не после | | Debug retry | Очень дорого | Поэтому — жёсткий лимит и escalation вместо 15 бесполезных попыток | | «Засунуть полрепы в каждый шаг» | Катастрофа | Это я запрещаю архитектурно |

Дорого не «наличие Plan/Execute/Debug». Дорого — толстый контекст и бесконечные ретраи без проверок.

Качество растёт не от «больше токенов», а от того, на что они тратятся:

- План до кода — меньше переписываний. - Узкий контекст — меньше галлюцинаций. - Проверки — «готово» без зелёных тестов не проходит. - Память — не платишь второй раз за ту же ошибку. - Лимиты — стоп вместо выжигания бюджета.

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

Честно: если ты пишешь мелкие правки одним сообщением и тебе ок качество «как получится» — HarnessOS будет избыточен. Он оправдан там, где цена бага выше цены лишнего Plan и Verify.

---

Что я хочу сделать

Платформу, которую ты ставишь у себя. Твой код остаётся у тебя. Модель выбираешь сам — облачную или локальную. И весь процесс AI-разработки идёт по шагам, с проверками и с твоим участием.

Если коротко, как это выглядит:

1. Ты ставишь задачу. 2. AI предлагает план — что и как он собирается делать. 3. Ты смотришь, соглашаешься или правишь. 4. Только после этого он начинает работать. 5. Дальше он делает — но не всё сразу, а по кусочкам. 6. После каждого кусочка — проверка. Если что-то сломалось, он откатывает и переделывает. Не тихо, а с понятным объяснением, что пошло не так. 7. Если он находит что-то, чего не было в плане — он не делает это сам. Спрашивает тебя: «Нашёл ещё вот это, делаем?»

Всё, что происходит, видно на экране: что сделано, сколько потрачено, где застряло.

---

Зачем это нужно

Не всем. Если ты просто хочешь быстро дописать функцию — Cursor справится лучше.

Это для тех, кому важно:

- чтобы код не уходил наружу; - чтобы AI не делал лишнего без спроса; - чтобы был порядок, а не «AI навайбкодил и ушёл»; - чтобы можно было доверять результату, а не перепроверять всё вручную.

---

Честно про стадию

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

---

Зачем я это пишу

Хочу понять, нужно ли это кому-то, кроме меня.

Если ты:

- разработчик, которому важно, чтобы код не уходил в облако; - в команде, где AI уже используют, но бардак; - или просто пробовал такие инструменты и тебе чего-то не хватило —

напиши в комментариях.

Что тебе важно? Что мешает в существующих решениях? Что бы ты хотел видеть?