ИИ в кадастре (в разработке)

Есть вводный раздел с основной терминологией: https://cadastre.ru/article/19#paragraph_463 

Машинное обучение (ML) — выявление статистических закономерностей для прогнозирования:

• Глубокое обучение — подмножество ML на основе многослойных нейросетей. Принцип: автоматическое построение иерархии признаков из сырых данных (пикселей, звука, текста).
  • Компьютерное зрение (CV) — выделение и классификация паттернов на изображениях/видео.
  • Обработка естественного языка (NLP) — моделирование структуры и смысла языка для генерации, перевода, анализа тональности.
    • Большие языковые модели (LLM) — предсказание следующего слова в контексте, что порождает понимание и связную генерацию.
      • Архитектура Трансформер — механизм внимания (Attention), оценивающий важность всех частей входа для текущего шага, позволяя учитывать глобальный контекст.
  • Генеративные модели — изучение распределения обучающих данных и генерация новых объектов из этого распределения.
    • Диффузионные модели — постепенное зашумление данных и обратный процесс восстановления (изображения).
    • GAN — состязание генератора (создает фейки) и дискриминатора (отличает подделки).
    • VAE — сжатие данных в скрытое пространство и генерация из него.
• Классическое ML — Алгоритмы для структурированных данных. Требуют ручного выделения признаков. Регрессия (числовой прогноз), классификация (отнесение к категории), кластеризация (группировка без учителя).
• Обучение с подкреплением (RL) — максимизация кумулятивной награды через взаимодействие со средой.

ГОСТы:

• ГОСТ Р ИСО/МЭК 42001-2024. Искусственный интеллект. Система менеджмента
• ГОСТ Р 71752-2024. Искусственный интеллект. Техническое задание. Требования к содержанию
• ПНСТ 839-2023 (ISO/IEC TR 24027:2021) Искусственный интеллект. Смещенность в системах искусственного интеллекта и при принятии решений с помощью искусственного интеллекта
• ПНСТ 838-2023 Искусственный интеллект. Структура описания систем искусственного интеллекта, использующих машинное обучение
• ПНСТ 835-2023 (ISO/IEC TS 4213:2022). Искусственный интеллект. Оценка эффективности моделей и алгоритмов машинного обучения в задаче классификации
• ПНСТ 776-2022. Информационные технологии. Интеллект искусственный. Управление рисками
• ГОСТ Р 59898-2021. Оценка качества систем искусственного интеллекта. Общие положения
• ГОСТ Р 59277-2020. Системы искусственного интеллекта. Классификация систем искусственного интеллекта
• ГОСТ Р 59276-2020. Системы искусственного интеллекта. Способы обеспечения доверия. Общие положения

Ресурсы:

• LLM Resources Hub 
• Обзор техник обучения передовых LLM
• Отчет International AI Safety Report 2026
• Размышления «Вайб-проектирование заменит Revit»
• Официальные государственные каталоги решений с ИИ:
  • https://reestr.digital.gov.ru/reestr  (в фильтре выбрать «Программное обеспечение относится к сфере искусственного интеллекта»)
  • https://digital.mosreg.ru/ai-solutions-region 

См. также подборку PDF-материалов.

В марте 2026 года Anthropic представила исследование, в котором предложен новый способ оценки влияния ИИ на занятость. Вместо традиционных моделей, основанных только на теоретических возможностях технологий, авторы ввели метрику observed exposure, объединяющую данные о реальном использовании LLM (на примере Claude) с оценками их потенциальной применимости. Ключевой вывод: ИИ пока не привёл к росту безработицы, но структурные изменения уже начинают проявляться.

Для каждой задачи оценивается, может ли LLM ускорить её выполнение минимум вдвое. Затем эти данные сопоставляются с реальными сценариями использования Claude в рабочих контекстах. Авторы различают автоматизацию (полная передача задачи модели) и augmentation (использование ИИ как помощника). При расчёте индекса автоматизированные сценарии получают больший вес.

Разрыв между теорией и практикой значителен. Например, в категории Computer & Math occupations теоретическое покрытие задачами, доступными для LLM, составляет 94%, а реальное — только 33%. В Office & Admin occupations — 90% против 31%. То есть ИИ используется далеко не там, где мог бы, а там, где для этого сложились условия.

Наиболее высокая наблюдаемая экспозиция зафиксирована у программистов (75% задач так или иначе выполняются с участием ИИ), операторов ввода данных (67%) и представителей клиентского сервиса. В нижней части распределения — профессии с преобладанием физического труда: повара, механики, спасатели, бармены. Примерно 30% работников имеют нулевой уровень экспозиции — их задачи практически не встречаются в данных об использовании Claude.

Демографический профиль наиболее экспонированных работников отличается от незатронутой группы. Среди них выше доля женщин (54.4% против 38.8%), белых (65.1% против 54.5%) и азиатов (9.1% против 4.7%). Уровень образования также существенно выше: доля обладателей bachelor's degree в экспонированной группе составляет 37.1% против 13.3% в незатронутой.

Единственное статистически значимое изменение обнаружено в найме молодых работников (22–25 лет). Вероятность начать новую работу в экспонированной профессии снизилась примерно на 14% относительно уровня 2022 года. Для работников старше 25 лет такого эффекта нет.

Другое исследование (США) показало, что искусственный интеллект не сокращает, а интенсифицирует работу. Вместо того чтобы высвобождать время сотрудников, ИИ приводит к увеличению объема, сложности и темпа задач. Эффективность ИИ создает парадокс: сэкономленное время немедленно заполняется новыми, более высокими ожиданиями по производительности. При этом когнитивная нагрузка на работников возрастает, так как их роль смещается от непосредственного исполнения к управлению ИИ: постановке задач, проверке и редактированию его результатов. Без активного организационного управления этот процесс ведет к усилению рабочей нагрузки, а не к ее облегчению. 

LLM по своей природе не сохраняют состояние (stateless). Их рассуждения ограничены информацией, предоставленной в окне контекста одного API-вызова. Инжиниринг контекста (Context Engineering) — это процесс динамической сборки и управления информацией в этом окне для создания stateful-агентов.

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

Компоненты контекста:

• Для руководства рассуждениями: системные инструкции, определения инструментов, few-shot примеры.
• Для фактических данных: долговременная память, внешние знания из RAG, результаты вызовов инструментов, артефакты.
• Для текущего взаимодействия: история разговора, временное состояние (scratchpad), текущий запрос.

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

Содержимое сессии:

• События (Events): хронологическая запись диалога (сообщения, вызовы инструментов, результаты).
• Состояние (State): структурированная рабочая память, временные данные текущего разговора.

Память — механизм долговременного хранения, фиксирующий и консолидирующий ключевую информацию из сессий для обеспечения непрерывного и персонализированного опыта. В отличие от RAG (эксперт в фактах), память делает агента экспертом в пользователе.

Жизненный цикл памяти (ETL-конвейер под управлением LLM):

• Извлечение (Extraction): целевая фильтрация "осмысленной" информации из источника согласно заданным топикам.
• Консолидация (Consolidation): сравнение с существующими воспоминаниями и принятие решения о создании, обновлении или удалении; активное забывание устаревшего.
• Хранение (Storage): векторные БД (семантический поиск), графы знаний (поиск связей) или гибрид.

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

Когда объем данных подходит к пределу, самые старые сообщения удаляются, либо выполняется операция сжатия информации. Модель отбрасывает все, что считает незначительным, и оставляет аннотацию. Но проблема в том, что на практике оказывается, что модель дает заметно худшие результаты при превышении уже 50-60% от заполненного контекстного окна. Она начинает путаться, делать точечные решения вместо системных, ломать работающее и так далее. Выходит, что средняя сегодня модель работает оптимально при наличии достаточного контекста, но не избыточного. И при достижении 60-70% уже имеет смысл сбрасывать сессию.

Шагом в сторону работы LLM с геоданными является создание набора стандартных тестов для оценки способности работы модели с геометрией (NoReGeo: Non-Reasoning Geometry Benchmark) https://github.com/FusionBrainLab/NoReGeo 

В контексте систем искусственного интеллекта на основе больших языковых моделей, инструмент (tool) — это внешняя функция или программа, которую модель может вызывать для выполнения задач, выходящих за рамки ее внутренних возможностей. Без инструментов LLM ограничена генерацией контента на основе обучающих данных. Инструменты предоставляют агенту "органы чувств" и "руки", позволяя воспринимать новую информацию и воздействовать на окружающую среду.

Функционально инструменты делятся на две категории:

• Инструменты для получения знаний (to know): Обеспечивают доступ к данным (поиск в интернете, запросы к базам данных, чтение файлов).
• Инструменты для выполнения действий (to do): Позволяют совершать операции (отправка email, выполнение кода, управление устройствами, вызов API).

С усложнением агентных систем возникает потребность в классификации. По способу реализации и применения выделяют:

• Function Tools: Пользовательские функции, описанные разработчиком. Модель получает их определение (имя, параметры, описание) в контексте запроса.
• Built-in Tools: Встроенные возможности самой модели или платформы (например, выполнение кода или grounding с поиском в Gemini API).
• Agent Tools: Механизм, позволяющий вызывать одного агента в качестве инструмента для другого. Это основа для построения многоагентных систем и иерархий, где "подчиненный" агент выполняет специализированную задачу, а "главный" управляет диалогом.

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

• Названия инструментов должны быть однозначными и читаемыми (например, create_critical_bug_in_jira). В описаниях необходимо детально объяснять назначение каждого параметра и ожидаемый результат. Примеры использования в документации служат мощным средством уточнения поведения модели.
• Инструкции для агента должны фокусироваться на цели ("создайте задачу для описания проблемы"), а не на конкретном инструменте ("используй create_bug"). Это разделяет логику и снижает связанность.
• Инструмент не должен быть тонкой оберткой над сложным API с десятками параметров. Он должен представлять собой конкретную, высокоуровневую задачу, понятную агенту (например, "забронировать переговорку" вместо вызова api/schedule?resource=...).
• Каждый инструмент должен выполнять одну четко определенную функцию. Это упрощает документирование и повышает точность выбора инструмента моделью. Длинные цепочки действий лучше реализовывать как отдельный агент, а не как монолитный инструмент.
• Инструменты должны возвращать минимизированный, сжатый результат, чтобы не перегружать контекст модели. Большие объемы данных (файлы, таблицы) рекомендуется сохранять во внешнем хранилище (например, Artifact Service), возвращая агенту лишь ссылку или идентификатор.
• Схемы валидации входных и выходных данных служат дополнительной документацией и обеспечивают контроль целостности. Сообщения об ошибках — важный канал обратной связи. Они должны содержать не только код, но и инструкции для агента о том, как исправить ситуацию.

MCP — это открытый стандарт, представленный Anthropic в конце 2024 года, призванный унифицировать подключение LLM-приложений к внешним инструментам и источникам данных. Его основная цель — решение проблемы "N x M" (экспоненциального роста числа интеграций при увеличении количества моделей и инструментов) путем создания единого "разъема".

Сайт: https://modelcontextprotocol.io/specification

MCP реализует клиент-серверную архитектуру, вдохновленную Language Server Protocol (LSP):

• MCP Host: Приложение-агент, инициирующее запросы (например, AI-ассистент в IDE). Управляет пользовательским опытом и безопасностью.
• MCP Client: Компонент внутри Host, поддерживающий соединение с сервером. Отвечает за отправку команд и управление сессией.
• MCP Server: Программа-адаптер, предоставляющая доступ к конкретному инструменту, API или данным. Публикует список доступных возможностей и выполняет команды.

Коммуникационный слой:

• Формат сообщений: JSON-RPC 2.0.
• Типы сообщений: Request, Result, Error, Notification.
• Транспорт: stdio (для локальных подпроцессов) и Streamable HTTP (рекомендуемый для удаленного взаимодействия).

Примеры:

• Draw.io MCP server
• Autodesk разрабатывает встроенного агентного ассистента для Revit, AutoCAD, Fusion, Civil 3D и облачного сервиса. Используемая модель в открытых источниках не раскрывается
• NonicaTab — это надстройка для Revit, включающая коннектор Claude Desktop. Как сказано в описании, это позволяет использовать ClaudeAI для «общения» с моделью Revit. Бесплатная версия NonicaTab позволяет создавать отчеты и панели мониторинга. Платная версия позволяет взаимодействовать с моделью Revit и выполнять задачи непосредственно в ней. Очевидно, что аналогичные решения будут сделаны практически для каждого крупного программного продукта, в первую очередь имеющего встроенную консоль. (https://youtu.be/p9hiM6i6J1U)

В феврале 2026 года мир увидел биржу работ, в которой ИИ-агенты могут делать поручения людям. (rentahuman.ai). Сейчас на сайте не так много успешных кейсов, но сама концепция mcp-сервиса для автоматического делегирования шага работы человеку, вполне вероятно, будет развиваться.

При интеграции языковых моделей с внешними инструментами стандартный подход приводит к фундаментальной проблеме: модель вынуждена "рассуждать" текстом о каждом атомарном действии. Каждый вызов функции требует отдельного цикла запроса к API, возврата JSON с именем инструмента и аргументами, затем выполнения вызова и отправки результата обратно в контекст.

При сложных сценариях с зависимыми вызовами или обработкой массивов данных это превращается в каскад последовательных обращений, где промежуточные результаты (часто объёмные логи или множественные записи) каждый раз возвращаются в модель, тратя токены и увеличивая задержки.

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

Это сокращает расход токенов до 98% на сложных задачах и заменяет текстовые рассуждения о данных прямыми вычислениями.

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

Реализация этого подхода есть в Claude: https://platform.claude.com/docs/en/agents-and-tools/tool-use/programmatic-tool-calling 

Платная версия Google NotebookLM поддерживает поиск через чат. Пример: поиск по книгам серии «Классика российской цивилистики».

Нейроюрист от Яндекса анализирует документы и отвечает на вопросы на основе базы Гаранта по вопросам права: трудовое, корпоративное, информационное, рекламное, обязательственное, сферу интеллектуальной собственности и защиты прав потребителей.

Другие примеры:

• 2026.02 — Главгосэкспертиза создала собственную языковую модель, которая ищет ошибки в документации

AI Agent = Модель + Инструменты + Оркестровка + Среда выполнения. Это приложение, где языковая модель работает в цикле с инструментами для достижения цели.

Компоненты архитектуры

• Модель — языковая модель как движок рассуждения. Выбор под задачу, а не по бенчмаркам
• Инструменты — API, функции, базы данных, код. Позволяют получать данные и изменять мир
• Оркестровка — управляет циклом "Подумай → Действуй → Наблюдай", памятью, планированием
• Развертывание — превращение агента в сервис с мониторингом и логированием

Цикл работы агента

1. Получить задачу от пользователя или триггера
2. Оценить обстановку (память, доступные инструменты)
3. Обдумать и построить план
4. Действовать — вызвать инструмент
5. Наблюдать результат и повторить с шага 3

Примеры:

• 2025.11 — Сбер внедрил AI-агента в методологию оценки рыночной стоимости недвижимости
• 2026.01 — Интересный проект: скрипт сохраняет в нужном ракурсе изображения с 3D карты Google (в режиме фото-текстур), отправляет на обработку в нейросеть, чтобы перерисовать в нужном стиле, и сохраняет как тайлы карты (2D). Получается красивый город в изометрии. 

• 06.2026 — в Эстонии на уровне правительства обсуждается выдача AI-агентам отдельного цифрового идентификатора (сразу стали называть паспортом). Идея состоит не в признании агента самостоятельным субъектом права, а в техническом разделении полномочий: агент получает ограниченные, контролируемые и аудируемые разрешения на конкретные действия, например просмотр записи, подготовку документа или платеж в пределах заданного лимита. Для кадастровых и иных государственных информационных систем такой подход интересен как пример будущей модели доступа: вместо передачи агенту полного доступа пользователя можно фиксировать, кто действует, от чьего имени, с какими правами и в пределах какого поручения. В общем, МЧД на агента.

Примеры сервисов:

• Microsoft: Foundry (Mechanics)
• Google: Vertex AI Agent Builder
• Яндекс: Ai Studio
• Сбер: GigaChat Enterprise (ГигаЧат Бизнес)
• Локальная среда: n8n

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

• человечки в офисе
• игра-стратегия аля Варкрафт. 

Autoresearch — это экспериментальный фреймворк, реализующий идею полностью автономного ИИ-исследователя. Технология построена вокруг простого цикла: агент на языковой модели самостоятельно модифицирует код обучения нейросети (train.py), запускает тренировку на фиксированные 5 минут, оценивает результат по метрике качества и либо сохраняет улучшения, либо отбрасывает их, повторяя этот цикл десятки раз за ночь без участия человека. Ключевая идея — разделение ответственности: человек программирует стратегию на естественном языке в program.md, а агент берет на себя рутинную работу по перебору гиперпараметров, архитектурных изменений и оптимизаций под конкретное железо. Это превращает исследовательский процесс из ручного экспериментирования в автоматизированный конвейер, где за 100+ ночных экспериментов можно найти оптимальную конфигурацию модели именно для конкретного GPU, проверить нетривиальные архитектурные гипотезы или адаптировать модель под специфичный датасет — и все это без необходимости сидеть и вручную запускать каждый эксперимент.

Метафоры «начальник—подчинённый» и «человек—инструмент» ошибочны. В первой вся когнитивная нагрузка остаётся на человеке (AI лишь механически исполняет), во второй AI не видит системы и разрушает согласованность проекта. Обе ведут к выгоранию человека.

Рабочая модель — два сопроцессора с разной архитектурой. Человек и AI не иерархичны, а комплементарны: их сильные и слабые стороны противоположны и взаимно дополняют друг друга. 

Распределение ролей:

• Человек: долговременная память, семантика, интуиция, стратегия, верификация.
• AI: скорость, механическая согласованность, эрудиция, неутомимость, работа с деталями.

Успех сессии определяет не качество AI, а то, как человек выполнил свою часть: поддержал контекст, принял архитектурное решение, зафиксировал его в спецификации, дал точную задачу с адресом, проверил изменения.

Продуктивная сессия: человек готовит контекст и решение → AI быстро реализует (код, тесты, логи) → человек быстро верифицирует.

Непродуктивная сессия: человек даёт размытую команду («допиши») → AI угадывает, ломает код, генерирует шум → человек тратит часы на разбор и исправление.

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

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

При взаимодействии с ИИ‑агентами разработчик распределяет внимание между несколькими «фронтами»: архитектура, исправление ошибок, тестирование, рефакторинг. Аналогично в стратегической игре игрок управляет экономикой, военными действиями, наукой и дипломатией. В обоих сценариях возникает цепочка мелких, но значимых решений, каждое из которых влияет на общий исход задачи или «партии».

Perplexity здесь подсказывает, что с нейробиологической точки зрения и кодинг с ИИ, и игра в стратегию реализуют один и тот же механизм с выработкой дофамина, когда формируется устойчивое состояние, близкого к потоку (flow), если уровень сложности задач соответствует компетенциям, обратная связь поступает регулярно, а человек ощущает высокую степень влияния своих решений на результат.

Меняется сам принцип офисной работы. Всегда человек делал некую задачу и переходил к следующей. Иногда прыгая от одной к другой и назад. Теперь вместо непосредственного выполнения задачи нужно будет быть оператором нескольких агентов, которые параллельно выполняют сразу несколько задач - по одному или нескольким проектам. Этот подход недавно описал создатель Claude Code, показав как он переключается между множеством сессий. И это действительно удобно и по своему интересно. Пока две модели работают, можно почитать, что говорит третья и дать соответствующие решаемой задаче указания. И переключиться на следующую вкладку (сессию) с другой решаемой задачей, где как раз подошло время участия пользователя. Проблемы в переключении внимания не возникает, так как все перед глазами.

Работа с LLM требует психологической перестройки. Из-за созданной иллюзии общения очень сложно не воспринимать LLM как нечто обладающее «сознанием». Из-за заложенных по умолчанию правил имитации человеческого поведения постоянно возникает желание общаться «как с человеком». В том числе возникает раздражение, например, когда оно что-то делает и говорит, что все теперь прекрасно, а на самом деле все стало еще хуже. Или если оно игнорирует данные инструкции (см. скриншот).

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

Оркестратор промптов Conductor реализован как расширение для терминального редактора. Вместо промпта к LLM нужно вызывать команду, запускающую работу оркестратора (/conductor:newTrack описание задачи). Далее расширение заставляет LLM следовать заданному протоколу разработки: задать уточняющие вопросы, сформировать описание требуемого изменения, сформировать детальный план реализации, получить добро на реализацию, пошагово реализовать план, создать тесты, проверить самостоятельно результат, обновить документацию проекта. Все эти описания фиксируются в наборе файлов в отдельной папке и убираются по завершении в архив.

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

Spec-driven development — новый подход к управлению процессом программирования, который заключается в автоматизации написании инструкций. Это не просто промпт или отдельный файл с описанием задачи. Это создание параллельной коду структуры файлов с описанием как текущего функционала, так и планируемого, и предыдущих версий. Пишет эти описания сама LLM, используя предоставленный ей инструмент. То есть цикл разработки следующий: пользователь объясняет LLM, новую желаемую функциональность, LLM обновляет эту спецификацию, прописывает шаги реализации и далее действует по этому плану.

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

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

• openspec/specs/ — папка с описанием текущего поведения системы. Там лежат файлы с требованиями и конкретными сценариями (например, как должна работать аутентификация). Это "источник правды", от которого отталкиваются все изменения.
• openspec/changes/ — папка, где живут все активные, то есть разрабатываемые сейчас изменения. Каждое изменение — отдельная папка с набором файлов:
  • proposal.md — зачем нужно это изменение
  • design.md — техническое решение
  • tasks.md — чек-лист того, что нужно сделать
  • папка specs/ с описанием того, что конкретно меняется в результате этих изменений в основной документации. Вместо того чтобы переписывать весь файл спецификации целиком, вы описываете только то, что добавляете, меняете или удаляете. При завершении изменения эти "дельта-файлы" автоматически сливаются с основными спецификациями. Это позволяет нескольким разработкам идти параллельно и не создавать конфликтов.

OpenSpec добавляет в AI-ассистента (Claude, Cursor и т.д.) команды вроде /opsx:propose, /opsx:apply. Они работают так:

• /opsx:explore — AI помогает разобраться в проблеме, анализирует код, предлагает варианты
• /opsx:propose — создает папку изменения и все нужные файлы на основе описания
• /opsx:apply — AI берет задачи из tasks.md и начинает их выполнять, отмечая сделанное
• /opsx:verify — проверяет, соответствует ли написанный код тому, что было запланировано
• /opsx:archive — завершает изменение, сливает изменения в основную документацию

Структура основной документации задана жестко. OpenSpec использует спецификации (спеки), которые организованы по доменам (отдельные папки с файлом spec.md). Внутри файла иерархия строится от общего к частному:

• раздел Purpose объясняет назначение домена
• Requirements описывают конкретные требования с использованием RFC 2119 (MUST/SHALL — обязательно, SHOULD — рекомендуется)
• Scenario под каждым требованием дают проверяемые примеры в формате Given/When/Then.

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

Далее самое интересное и неожиданное — как OpenSpec помогает LLM разбираться в этой структурированной документации. Он строит графовую модель проекта из Markdown-файлов спецификаций. При парсинге он вытаскивает заголовки требований, вложенные сценарии и ключевые слова MUST/SHALL, формируя древовидную структуру. Для изменений отдельно парсятся дельта-спеки с секциями ADDED/MODIFIED/REMOVED. Поверх этого накладывается граф зависимостей артефактов (proposal → specs → design → tasks), где узлы помечаются статусами done/ready/blocked на основе наличия файлов и выполненности зависимостей.

Когда LLM запрашивает информацию через команды вроде /opsx:continue, OpenSpec не отдает сырые файлы. Он собирает подграф нужных узлов, извлекает только релевантные фрагменты Markdown и упаковывает в JSON с четкой структурой: id артефакта, статус, путь, содержимое, зависимости, плюс контекст и правила из конфига. Таким образом LLM с помощью этого инструмента получает, когда ей надо понять что-то в документации, не набор файлов для самостоятельного разбора, а готовую структурированную выжимку — что уже сделано, что можно делать дальше и в каком формате.
 
Говоря коротко: пользователь ставит задачу, скрипт парсит документацию, делает из нее граф и выдает выжимку по задаче для LLM, LLM думает и по инструкции создает план работ и проект изменений в документацию, после разработки обновляет документацию.

Люди постепенно привыкают рисковать доверяться LLM, несмотря на очень высокую вероятность проблем. Как к этому приходят? Обычно в среде исполнения есть некий защитный инструмент, предполагающий запрос подтверждения на определенные действия (терминальная команда или утверждение плана действий). Естественно, через некоторое время это надоедает, и сначала отмечается что-то вроде «разрешать всегда», а потом включается и общий режим действий без спроса. Забавнее всего такой режим именуется в Gemini CLI: «YOLO mode» (You Only Live Once).

Можно предположить скорое отмирание практически всех существующих сегодня платных онлайн сервисов, потому что у каждого человека будет свой создаваемый на лету набор того, что ему нужно. И учитывая, что на большой классический продукт нужно много ресурсов, волна банкротств и закрытий не за горами. В феврале 2026 года появился пример прототипа такого личного помощника, решающего возникающие жизненные персональные задачки — clawbot.ai В нем нет прорывных технологий, но есть прорывная концепция: что будет, если рискнуть и дать LLM хороший набор инструментов, локальную базу данных для накопления сведений о себе и больше свободы в действиях.

Немного позже автор этой системы создал первую социальной сети для ИИ-агентов (moltbook.com).

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

Момент, когда LLM генерирует ответ на запрос пользователя (промпт+история), называют «инференс». Ограничение на длину запроса привело к потребности в специальной, сокращенной и структурированной версии технической документации, которую модель могла бы при инференсе мгновенно «усвоить», не перегружая контекстное окно. Ответом на эту задачу стал формат документации llms.txt. Это технический стандарт, предлагающий представлять описание сайта или некоего программного продукта в форме простого компактного текстового файла в markdown-разметке. Спецификация стандарта представлена на сайте https://llmstxt.org. А вот пример к документации к js-библиотеке: https://pixijs.com/8.x/llms 

Материалы:

• Статья «Технологии машинного обучения и мультимодальные подходы в области оценки имущества»
• Статья «Разработка модели прогноза чистого долга компаний-застройщиков с использованием машинного обучения»
• VideoCAD. Датасет и модель по работе в CAD