Онто.

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

Сразу внесу поправку для любителей заголовков «теперь любой ребёнок заменит программиста». Он с детского сада занимается робототехникой, сейчас слушает курс для продвинутого питониста, а в прошлом году получил сертификат уровня middle-разработчика. У него есть подготовка и интерес к делу. Но ему всё ещё тринадцать, и он всё ещё школьник.

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

Задача была вполне конкретная: исправить текст уведомления о лимите приглашений в Онто. Теперь в нём явно указано, что можно пригласить не более трёх участников. В результате есть исправление, unit-тест, ревью и развёртывание на PREPROD. И сообщение от сына со ссылками на дефект, экспертизу, спецификацию, протокол ревью и PR.

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

Я продолжаю считать, что главная нейросеть в производстве ПО находится у человека между ушами. Но инструменты вокруг неё можно устроить так, чтобы человеку было проще понимать задачу, принимать решения и отвечать за результат. Даже если этот человек после препрода идёт делать домашку.

«Любой каприз». Как пользователь Онто заказал себе новую возможность

20 сентября (вечер, ночь). Можно ссылку без регистрации?

Мне пишет человек, который пользуется Онто. Хочет отправить свою диаграмму другим людям, чтобы они просто открыли её по ссылке. Без регистрации и дополнительных объяснений, куда нажать.

Отвечаю: «Могу подумать, как сделать». В ответ прилетает: «Это обязательно для вовлечения».

И вот такие предложения я люблю. Человек уже работает в Онто, у него есть что показать и есть кому. Он дошёл до конкретного препятствия и пришёл ко мне. Тут не надо придумывать за пользователя, зачем ему новая функция: он только что сам всё объяснил.

Дальше. Собираем команду

Иду к оркестратору, прошу подключить аналитиков и ревьюеров, проработать предложение. Команда разбирается, возвращается с решением. Смотрю — нравится, можно делать спецификацию. По ней готовится постановка для дизайна, затем дизайн и спецификация уходят в реализацию. Жду результат.

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

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

Здесь и работают вместе методология разработки, agent-runtime и Онто. Есть способ организовать работу, есть кому её выполнить, есть общий контекст. Поэтому мне достаточно запустить процесс и включаться в содержательные решения.

22 сентября (утро). «Любой каприз»

Отправляю скрин новой возможности и подписываю: «Любой каприз». 🙂

Люблю такие разговоры. Ещё недавно человек спрашивал, можно ли сделать, а теперь уже можно показывать, что получилось. Конечно, между этими сообщениями были анализ, разработка и проверки. Но моего личного внимания понадобилось немного, и просьба пользователя легко поместилась в обычную работу над продуктом.

Поэтому, когда я вижу, что человек реально пользуется Онто и приходит с полезной задачей, мне вообще не жалко её поддержать. Он уже потратил время на продукт, попробовал его в своей работе и принёс знание, которое я сам мог бы ещё долго искать. Зачем держать такое предложение в очереди, если можно взять и сделать? Тем более что это вообще не отняло моего внимания, ну может быть час.

Для меня в этом и есть практическая ценность всей этой организации разработки. Она позволяет быть отзывчивым: услышать человека и довольно легко помочь ему. Так что пользуетесь Онто, упёрлись во что-то, понимаете, чего не хватает, — приходите. С такими предложениями мне интересно работать.

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

И я прямо представил, как красиво эту задачу можно продать. Сначала объясняем экологам, что без репрезентативного датасета ничего не получится, поэтому следующие два года они будут фотографировать китов. Потом разметка, команда компьютерного зрения, обучение, эксперименты, инфраструктура — и вот в особенно удачной для подрядчика версии мы уже обсуждаем 100 миллионов рублей. Экологи хотели узнавать Стаса, но теперь у них есть дорожная карта цифровой трансформации, а у Стаса — обязанность обеспечить обучающую выборку.

Я вместо этого потратил три дня на другую постановку задачи. Мне ведь не обязательно учить собственную нейросеть узнавать Стаса, если можно отдельно описать, чем он отличается от Петра. Готовую Vision-модель я использовал как зрение, а в Онто описал признаки и знания о конкретных китах. Нейросеть рассматривает фотографию, система сопоставляет увиденное с каталогом, а пользователь получает гипотезу о конкретной особи и объяснение, на чём она основана.

То есть я не совершил прорыв в обучении нейросетей на шести фотографиях. Я вообще не стал делать обучение собственной нейросети обязательным условием решения задачи. Если у нового кита есть различимые признаки и эксперт может их описать, его можно добавить через знания в каталоге. При этом шесть фотографий, конечно, не доказывают точность на любых снимках: качество ещё нужно проверять на новых наблюдениях. Но проверять полезную систему и два года финансировать обещание когда-нибудь её получить — несколько разные предложения для заказчика.

Меня во всей этой истории интересуют даже не столько киты, сколько привычка IT подменять задачу любимым способом её решения. Человек приходит с вопросом «как мне узнавать животных», а уходит с обязательством содержать вашу ML-команду. И дальше ему объясняют, почему это объективно сложно, долго и дорого, хотя дорогой может быть не его задача, а ваша неспособность посмотреть на неё иначе. Иногда самая ценная работа инженера — вычеркнуть из проекта технологию, которую ему очень хотелось применить.

Я всё ещё считаю, что IT-проекты должны быть дешёвыми в разработке и приносить реальную ценность. Не потому, что труд разработчика ничего не стоит, а потому, что хороший разработчик должен сокращать путь к результату, а не обосновывать длину этого пути. Для этого я и делаю Онто: чтобы предметное знание можно было непосредственно использовать в работающей системе, а не каждый раз заново оплачивать попытку засунуть его в нейросеть. Экологам нужен способ узнать Стаса, а не почётное право профинансировать наши технологические амбиции.

Мы тут привлекли к разработке еще одного из наших фаундеров (@LosiVC ) и вот что получилось

Саша добавил в Онто возможность, которая на первый взгляд выглядит довольно локально: агент может взять уже размещённые на диаграмме объекты и показать существующие между ними связи. На скриншоте он получает один объект, собирает его окружение на два уровня и строит из него связанную диаграмму.

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

Это принципиально отличается от привычной GenAI-разработки, где процесс часто выглядит как бесконечная цепочка «промпт → код → посмотрели → поправили → следующий промпт». Пока задача небольшая, такой режим может быть эффективным. Но с ростом системы он быстро превращается в хаос: логика начинает дублироваться, решения расходятся между интерфейсами, а никто уже не понимает, где находится источник истины.

В случае этой задачи сначала было зафиксировано предметное намерение: показать на диаграмме связь между уже существующими объектами. Затем оно было проведено через модель продукта и канонический backend-контракт. В результате одна и та же способность теперь доступна и через REST, и через MCP, но бизнес-логика при этом не размножается: агент не изобретает собственный способ создать связь, а использует те же правила, что и остальные части системы.

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

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

Выглядит впечатляюще.

Всё началось с очень простого вопроса:

«Расскажи об этом пространстве».
На него легко ответить, если пространство небольшое и все участники давно знают контекст.
Но по мере развития Onto появляется другая ситуация: в пространство приходят новые люди, новые агенты, новые модели. И каждому нужно быстро понять — что здесь происходит, зачем это пространство существует и чему здесь можно доверять.

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

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

Можно просто спросить:
«Расскажи об этом пространстве».

И получить ответ не от конкретного агента, не из случайного локального файла и не из догадки модели. А от самого пространства.

У пространства Onto появился собственный голос.

«Где у вас цены?», «Что выбрать для небольшой команды?», «А для обычного пользователя MCP включён?», «Можно ли начать с пилота?» — оказалось, что одна таблица с тарифами на все эти вопросы не отвечает.

Поэтому на странице продукта появился помощник по лицензированию Онто. Просто опишите свою ситуацию одной фразой — без анкеты и долгого диалога. Помощник определит подходящий вариант: бесплатное облако, частное облако, on-prem или OEM, учтёт число пользователей, образовательные условия, пилот, Developer- и Runtime-лицензии.

Важная деталь: нейросеть здесь не придумывает цену. Она только понимает запрос и извлекает параметры, а стоимость рассчитывается по зафиксированным правилам. В результате вы получаете итоговую сумму, её составляющие и существенные условия расчёта.

Каждый запрос обрабатывается отдельно, история не сохраняется. Если расчёт подходит, его можно сразу отправить нашей команде и продолжить обсуждение уже предметно.

Попробовать:
https://ontonet.ru/product

В рамках нашей стратегии Product Ops мы добрались до инфраструктуры продукта.

AI-native команда не может заканчиваться на готовом коде. Кто-то должен провести изменение через окружения, сохранить нужную конфигурацию, доставить правильную версию и проверить результат. Если всё это по-прежнему держится в голове одного человека, значит Ops ещё не стал частью агентского производства.

Мы провели аудит шести контуров и 58 развёртываний Онто, зарегистрировали 30 инфраструктурных дефектов, собрали исполняемый тракт доставки и дистиллировали роль инфраструктурного агента.

Теперь человек задаёт результат и границы операции, а агент самостоятельно проводит изменение до работающего продукта и возвращает доказательства.

Новая статья продолжает историю нашего ящика с умными инструментами — теперь они осваивают Ops.

Структурированное знание как способ снизить зависимость от конкретной LLM
Мы провели эксперимент: дали четырём разным языковым моделям — Qwen3.8-27B, DeepSeek Reasoner, GPT-5.6-sol и Claude Opus 4.8 — доступ через MCP к одной и той же структурированной модели знания в Онто. После этого моделям была задана одинаковая последовательность аналитических вопросов. Главный результат: несмотря на различия в стиле, глубине рассуждений и способе оформления ответа, все четыре модели сохранили общую предметную рамку и пришли к совместимым по смыслу выводам.

Это важно, потому что обычно значительная часть предметного знания неявно находится внутри самой нейросети. Мы рассчитываем, что модель «знает» необходимые понятия, правильно понимает их взаимосвязи и одинаково интерпретирует используемые термины. Но разные модели обучены на разных данных, используют разные механизмы рассуждения и могут по-разному восстанавливать контекст. Поэтому при смене модели часто меняется не только качество текста, но и сама логика анализа.

В нашем эксперименте система координат находилась не внутри LLM. Она была вынесена во внешний структурированный слой: понятия, роли, критерии и отношения между ними были явно зафиксированы в Онто. В такой архитектуре нейросеть не должна заново изобретать предметную модель. Она получает уже заданную структуру и использует её как основание для ответа.

Получается разделение ответственности:
Онто хранит предметное знание, его структуру, критерии и связи;
LLM находит нужные элементы, интерпретирует их применительно к вопросу и формирует понятный человеку ответ.
Именно структурированное знание становится инвариантом между разными моделями. Можно менять нейросеть, но предметная система координат остаётся прежней.

При этом модели не становятся полностью одинаковыми. В эксперименте часть моделей следовала исходной структуре почти буквально, а часть расширяла её, добавляла собственные критерии или делала дополнительные выводы. Отличались строгость оценок, внимание к неявным аспектам, глубина критики и стиль аргументации. То есть влияние конкретной LLM сохраняется — но перемещается на другой уровень. Модель влияет преимущественно на качество интерпретации и форму рассуждения, а не создаёт предметную рамку с нуля.

Это принципиальная разница.
Если знание находится только внутри весов модели, смена LLM означает смену носителя знания. Новую модель приходится заново настраивать, дообучать или подробно погружать в контекст. Если же знание вынесено во внешний структурированный слой, LLM становится заменяемым интеллектуальным исполнителем. Новая модель подключается к той же базе понятий, критериев и отношений и может продолжить работу в общей системе координат.

Такой подход потенциально даёт несколько эффектов:
Снижается зависимость от поставщика модели.
Организация не привязывает свою предметную логику к одной конкретной нейросети.
Упрощается замена и сравнение LLM.
Модели можно оценивать на одной базе знания, не обучая каждую из них заново предметной области.
Знание обновляется в одном месте.
Изменение критерия или связи в структурированной модели становится доступно всем подключённым LLM.
Сокращается потребность в предметном дообучении.
Необязательно помещать всю логику предметной области внутрь весов каждой модели. Часть специализации переносится из обучения в управляемый внешний контекст.
Повышается проверяемость ответов.
Можно проследить, на какие внешние понятия и критерии опиралась модель. Это не делает внутренние рассуждения LLM полностью прозрачными, но позволяет проверять основания ответа.

Но уже сейчас можно сформулировать подтверждённый инженерный вывод:
внешнее структурированное знание заметно снижает разброс смыслов между разными LLM и позволяет им работать в общей предметной системе координат.

Мы опубликовали открытую методологию ведения проектов разработки ПО основанной на графе знания.

Она связывает работу от причины её появления и ожидаемого изменения до требований, выполнения, проверки, выпуска и обратной связи. Методология не заменяет Scrum, Kanban или внутренние регламенты — она помогает не потерять исходный смысл и подтвердить, что достигнут именно нужный результат.

Но главное для нас в другом. Такая модель открыла путь к AI-native процессу производства ПО.
AI-native — это не чат-бот у каждого сотрудника. Чтобы агент стал участником производства, он должен видеть цели, объекты работы, зависимости, полномочия и критерии завершения. В Онто люди и агенты работают с одной связной моделью, поэтому агент может восстановить контекст, найти пропуски, провести проверку или подготовить решение, не присваивая себе человеческие полномочия.

Теперь мы предлагаем компаниям пройти этот путь на собственном процессе: провести диагностику, адаптировать методологию и реализовать рабочий контур в Онто.

Результат пилота измеряем по сквозной трассируемости работ, времени восстановления контекста, числу возвратов и доле операций, которые можно безопасно передать агентам.
Методология: https://ontonet.ru/methodology
Предложение для компаний: https://ontonet.ru/companies/software-development

Мы зарелизили новую версию сайта Онто: https://ontonet.ru/

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

Для самой платформы Онто мы сделали отдельный раздел: https://ontonet.ru/product. Там подробнее показали, как устроены пространства, общая память, живые диаграммы и работа AI непосредственно с объектами модели.

Заметно усилился и блок «Живой пример» на главной странице. Если раньше можно было сделать небольшую модель знания, то тТеперь можно поиграть с готовыми вопросами, получить ответ нейросети и сразу увидеть, на какие объекты модели она опиралась. То есть посмотреть не только на ответ, но и на его основание.

Посмотрите сайт и расскажите, удалось ли нам объяснить Онто понятнее.

Карточка Jira постепенно превращается в маленькое кладбище контекста. В ней лежат постановка задачи, уточнения, гипотезы, логи, результаты проверок, объяснения решений и переписка нескольких исполнителей. Человеку уже трудно понять, что из этого описывает систему сейчас, а что было лишь промежуточной версией. Агенту ещё сложнее: в новой сессии ему приходится заново восстанавливать ход чужой работы из этой свалки.

В Онто мы разделили два слоя. В видимой людям модели остаются подтверждённые факты о системе: компоненты, требования, связи, дефекты, решения и текущее состояние объектов. Агентская память хранит другое — как агент исследовал конкретный объект, какие гипотезы проверял, что отверг, на какие доказательства опирался и какой контекст передал следующему исполнителю.

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

В новой статье — четыре прикладных сценария и пошаговый рецепт работы с агентской памятью в Онто: от первой записи до передачи задачи другому агенту и восстановления работы в новой сессии.