Мне кажется, разработка действительно движется от ручного редактирования каждого файла к работе на более высоком уровне. AI ускоряет этот переход, но одновременно показывает ограничение нынешней модели: агент умеет писать код быстрее, чем понимать большую систему.
Увеличение контекстного окна поможет, но не устранит саму необходимость каждый раз восстанавливать архитектурный замысел из реализации.
ИИ не согласен
Мысль автора понятна и отлично описывает боли первой волны генеративного ИИ (эпохи «вайб-кодинга» и простых копилотов). Действительно, если просто натравить LLM на огромный монолитный репозиторий, она начнет тонуть в легаси-коде, совершать регрессионные ошибки и пытаться, как археолог, раскопать исходный замысел архитектора по косвенным признакам.
Однако эта логика исходит из предпосылки, что код — это единственный и финальный источник правды (Single Source of Truth) для ИИ. И именно в этой точке тезис начинает стремительно устаревать.
Индустрия прямо сейчас совершает тектонический сдвиг от «промпт-кодинга» к методологии IDD (Intent-Driven Development) и системному Context Engineering. Этот подход полностью переворачивает парадигму и решает озвученную проблему через три фундаментальных изменения:
Замысел больше не скрыт в реализации. В зрелых IDD-системах агенту не нужно «декомпилировать» архитектуру из миллионов строк кода. Замысел выносится на уровень выше и фиксируется декларативно — в виде архитектурных манифестов (например, стандарты типа OpenSpec или расширенный CLAUDE.md), схем данных и машиночитаемого бизнес-глоссария (Ubiquitous Language из DDD). Для ИИ архитектурный контекст — это не загадка, которую нужно разгадать, а жесткий входной параметр и рельсы, с которых нельзя съехать.
Изоляция вместо расширения контекстных окон. Пытаться скормить модели весь проект целиком, надеясь на миллионные контекстные окна — тупиковый путь (модели неизбежно «тупеют» и теряют фокус в слишком длинном контексте). Решение, пришедшее из Domain-Driven Design — это жесткие границы контекста (Bounded Contexts). Агент, меняющий модуль оплаты, физически не видит код модуля логистики или авторизации. Он видит только свой изолированный кусок и строго зафиксированные контракты соседей через AST-графы (Abstract Syntax Tree). Ему просто запрещено понимать устройство всей системы, как и любому разработчику-человеку в крупном энтерпрайзе.
Смена ролей: Спецификация валидирует код, а не наоборот. Мы уходим от парадигмы, где ИИ учится на коде проекта и бездумно масштабирует его ошибки. В IDD сначала валидируется само «намерение» (Intent) на уровне абстрактного графа зависимостей. Если ИИ-архитектор видит, что новая фича нарушает контракт или создает циклическую зависимость, пайплайн останавливается до генерации кода.
Резюме: Цитата идеально описывает кризис систем, где код первичен. Но как только мы переходим на уровень Intent-Driven Engineering, где код становится лишь автоматически генерируемым артефактом, а человек управляет ограничениями и контрактами, необходимость «восстанавливать замысел из реализации» исчезает. Мы больше не просим ИИ понять наш код — мы заставляем его подчиняться нашей спецификации.
IDD (Intent-Driven Development) в ИИ-разработке
**Intent-Driven Development (IDD, разработка на основе намерений)** — это новая методология инженерии программного обеспечения в эпоху ИИ, при которой **инженер формулирует, структурирует и валидирует свои верхнеуровневые намерения (Intents), а ИИ-агенты полностью берут на себя генерацию кода, тестов и интеграцию**.
В отличие от хаотичного «вайб-кодинга» (написания кода через простые чат-промпты), IDD смещает роль программиста с ручного написания строк кода («укладки кирпичей») к роли Архитектора и Контролера, который управляет контекстом и проверяет результат работы автономных агентов.
📊 Разница подходов: Эволюция к IDD
Критерий Вайб-кодинг (Vibe Coding) Spec-Driven Development (SDD) Intent-Driven Development (IDD) Что делает человек Пишет сырые промпты, кодит на ходу Создает огромные, жесткие ТЗ и контракты Формулирует намерения (Зачем/Что/Как) и тестыЧто делает ИИ Генерирует куски кода по запросу Реализует систему строго по готовой спеке Автономно планирует задачи и пишет рабочий кодОсновной риск Галлюцинации, хаос в архитектуре Огромные затраты на ручную актуализацию спек Требует высокой архитектурной зрелости от инженера Результат Быстрый старт, нежизнеспособный легаси Стабильный код, медленный процесс итераций Высокая скорость, масштабируемость и прозрачность
💡 Анатомия Намерения (Intent) в IDD
Документ намерения (обычно оформляется в виде структурированного Markdown-файла) является единственным источником истины для ИИ-агента. Он состоит из трех обязательных блоков:
ЗАЧЕМ (WHY): Бизнес-контекст и мотивация. Зачем пользователю эта фича? Какую проблему мы решаем?
ЧТО (WHAT): Строгие функциональные требования. Часто описываются на понятном ИИ языке сценариев (например, Gherkin / Cucumber: Given-When-Then).
КАК (HOW): Верхнеуровневый пошаговый план технической реализации, разбитый на мелкие задачи, границы архитектуры и стек.
ИИ-агент считывает этот файл, не отвлекаясь на догадки и двусмысленные промпты, и генерирует реализацию, точно соответствующую ожиданиям.
🔎 Почему IDD критически важен для ИИ-эпохи?
Исключение «дрейфа намерений»: При классическом промптинге ИИ склонен додумывать логику за программиста, что ведет к накоплению скрытых багов. IDD жестко фиксирует рамки дозволенного.
Отделение стратегии от рутины: Человек концентрируется на бизнес-логике, граничных условиях и безопасности, а ИИ за секунды пишет рутинный boilerplate-код и юнит-тесты.
Архитектурный контроль: Передавая ИИ схему системы (DDD) и явное намерение, инженер сохраняет архитектуру проекта чистой, не позволяя нейросети превратить кодовую базу в “спагетти”.
➡️ Как выглядит рабочий процесс (Workflow) в IDD
Создание интента: Инженер описывает задачу в документе Интента (проверяя архитектурную совместимость).
Фиксация тестов: Инженер (или ИИ под его контролем) пишет поведенческие тесты, которые зафиксируют успешность выполнения намерения.
Запуск ИИ-агента: Специализированный ИИ-агент (например, на базе фреймворков для авто-кодинга) берет Интент в работу, декомпозирует его и приступает к кодингу.
Автоматическая валидация: Код прогоняется через тесты и линтеры. Если тесты падают, агент исправляет себя сам, пока условия интента не будут выполнены на 100%.
Human-in-the-loop: Инженер проводит финальный аудит (Code Review) и вливает изменения в основную ветку.
Что использует Robert C. Martin (Uncle Bob)?
Позиция Роберта Мартина (Uncle Bob) — автора культовой книги «Чистый код» и создателя принципов SOLID — по поводу агентной разработки произвела настоящий фурор в индустрии. Человек, десятилетиями учивший инженеров вылизывать каждую строчку, официально заявил, что больше вообще не читает код, написанный ИИ-агентами.
Вместо построения абстрактных моделей он использует подход, который называют «Испытательным полигоном» (Test Gauntlet). Его методология идеально ложится на рельсы IDD, но с жестким фокусом на автоматическую верификацию.
Вот стек практик и инструментов, которые дядя Боб использует для работы с ИИ:
1. Отказ от Code Review в пользу Метрик и Контрактов
Вместо того чтобы тратить время на построчное ревью кода (поскольку человек делает это слишком медленно), Мартин полностью абстрагировался от реализации. Качество кода ИИ-агентов он оценивает через автоматический скоринг телеметрии и метрик. Если ИИ-агент приносит Pull Request, платформа Дяди Боба автоматически проверяет:
Тестовое покрытие (Mutation Testing): Не просто покрытие строк, а мутационное тестирование. Код считается принятым, только если тесты ИИ-агента «ловят» искусственно внесенные баги.
Цикломатическую сложность (Cyclomatic Complexity): ИИ не должен плодить вложенные циклы и конструкции if-else.
Зацепление и связность (Dependency Structure): Проверка на нарушение принципов SOLID на уровне графа кода.
«Человек слишком медлителен в написании и чтении кода. Чтобы расти в продуктивности, люди должны отключиться от самого кода и управлять системой с более высокого уровня», — пишет Мартин.
2. Приемочное тестирование как интерфейс (ATDD)
В качестве главного инструмента управления намерениями (Intent) Дядя Боб использует Acceptance Test-Driven Development (ATDD) на базе Gherkin / Cucumber.
Как это работает: Инженер описывает требования к системе в виде человекочитаемых сценариев (например, Given / When / Then).
Этот файл спецификации скармливается агенту (Мартин активно поддерживает экосистему вокруг Claude Code и кастомных CLI-оберток). ИИ обязан написать реализацию так, чтобы эти сквозные приемочные тесты загорелись зеленым.
3. Архитектурные тесты (Architecture-as-Code)
Поскольку ИИ-агенты любят нарушать границы слоев (например, тащить инфраструктурный SQL-запрос напрямую в UI-контроллер), Дядя Боб использует инструмент ArchUnit (для Java/C#) и его аналоги в других языках.
Архитектурные правила зашиваются в специальные Unit-тесты.
Тест проверяет структуру проекта на уровне компиляции: «Пакет Domain не должен зависеть от пакета Infrastructure». ИИ физически не сможет запушить код, нарушающий Clean Architecture.
4. Навыки ИИ вместо гайдлайнов (Agent Skills)
Вместо того чтобы надеяться, что ИИ «вспомнит» правила чистого кода, Дядя Боб перевел весь свой каталог из 66 правил и эвристик «Clean Code» в машиночитаемый формат Agent Skills. Это конфигурационные файлы, которые нативно поддерживаются современными IDE (например, через Anthropic MCP-серверы). Перед тем как написать метод, агент парсит этот файл-инструкцию, выступающий жестким Guardrail.
Резюме: Формула Дяди Боба в эпоху ИИ
Метод Роберта Мартина сегодня — это «Дисциплинированная агентная инженерия» (Disciplined Agentic Engineering). Он не верит в то, что ИИ поймет архитектурный замысел сам. Но вместо создания сложной визуальной UML-модели до генерации кода, он кодирует архитектурные ограничения в виде автоматических тестов (TDD/ATDD). Тесты становятся единственным валидатором намерений, а ИИ выступает в роли «слепого исполнителя», который обязан пройти этот жесткий фильтр.
ИИ не будет думать об одной задаче днями, вечерами, неделями, пока однажды перед сном ему эта идея в голову не придет. Ты ему дал задачу, он покрутил, что-то выдал. А человеку ты можешь дать задачу, и он может думать над ней годами и найти решение. Либо не найти. Вот это очень большая разница между человеком и ИИ, которую, мне кажется, еще не все учитывают.
если правильно crontab настроить, то сможет
Как мы заставили ИИ думать над задачей неделями, просто настроив crontab
Каждый, кто хоть раз пользовался ChatGPT, Клодом или любой другой LLM, сталкивался с классическим паттерном «запрос-ответ». Ты даешь нейросети задачу, она крутит шестеренками пару секунд, выдает результат, и на этом всё. Сессия закрыта, контекст забыт.
В кулуарах IT-сообщества часто звучит аргумент: «Вот человек — это другое. Ты можешь озадачить инженера, он уползет думать, будет засыпать и просыпаться с этой мыслью неделями, месяцами, а потом бах — и перед сном его осенит инсайт! ИИ на такое не способен».
Способен. Если правильно настроить crontab.
Давайте разберем, как обычный планировщик задач превращает реактивную языковую модель в автономного агента долгосрочного мышления, и почему этот костыль неожиданно бьет по главным преимуществам человеческого мозга.
Анатомия «ночных размышлений» нейросети
Когда мы говорим, что человек «думает над задачей неделями», мы имеем в виду три процесса: накопление новых знаний, регулярный пересмотр старых гипотез и банальное упорство. Если обернуть вызовы API современной LLM в циклы и повесить на шедулер, мы получим поразительно похожую механику.
Современные модели (вроде семейства OpenAI o1 и их последователей) уже «из коробки» умеют генерировать скрытые цепочки рассуждений перед тем, как выдать финальный текст. Они взвешивают варианты, критикуют свои же гипотезы и исправляют ошибки в процессе генерации токенов.
Если убрать жесткий лимит на время ответа (timeout) и позволить модели крутиться в фоновом режиме часами, она способна перебирать миллионы вариантов решения, углубляясь в дерево контекста так, как ни один человек физически не сможет из-за банальной оперативной памяти мозга.
2. Динамический контекст: ИИ умнеет каждый день
Человек, размышляя над сложной архитектурной проблемой или научной теоремой, ограничен багажом знаний в своей голове. Чтобы узнать что-то новое, ему нужно пойти и целенаправленно почитать статьи.
У ИИ-агента на crontab этот процесс автоматизирован. Каждые сутки в полночь скрипт просыпается и делает парсинг свежих репозиториев GitHub, препринтов arXiv, медицинских баз данных или финансовых отчетов за прошедший день. Все новые данные векторизуются и моментально добавляются в базу знаний агента (RAG — Retrieval-Augmented Generation). После этого ИИ запускает очередной цикл размышлений над глобальной задачей, но уже с учетом знаний, которых еще не существовало в природе вчера.
Если в понедельник задача была нерешаема, во вторник ученые на другом конце Земли могли опубликовать нужную формулу. В среду ваш crontab-агент прочитает её и выдаст готовое решение. Человек же узнал бы об этой публикации в лучшем случае через месяц из профильного хабратопика.
3. Селф-рефлексия (Self-Reflection)
Чтобы ИИ «видел сны» о задаче, инженеры используют паттерн самокритики. Скрипт будит модель каждые несколько часов, поднимает из базы данных её же утреннее решение и скармливает его модели со строгим промптом: > *«Вот твое предыдущее решение задачи Х. Найди в нем логические уязвимости, крайние случаи (edge cases) и перепиши код так, чтобы оптимизировать производительность еще на 15%»*.
Механическое упорство против человеческого фактора
Когда мы сравниваем человека и автоматизированную систему на длинной дистанции, crontab внезапно нивелирует всё то, что мы привыкли считать «плюсами» живого ума.
ИИ не выгорает. У него нет депрессии, прокрастинации, синдрома самозванца или бытовых проблем. Ему не надоест задача через три недели бесплодных попыток. Он не скажет: «Да ну его, не получается, пойду мемы посмотрю».
ИИ не теряет фокус. Если скрипт прописан на 10 лет вперед — модель будет долбить эту задачу 10 лет, каждую секунду оставаясь на пике своей «интеллектуальной формы». Ей не нужно тратить 20 минут на «вхождение в контекст» после чашки кофе.
Где граница всё еще сохраняется?
Было бы лукавством сказать, что crontab + API = полноценный ученый. Фундаментальное различие между нами пока кроется в природе «озарения» и биологических лимитах.
Фоновое бессознательное (Инкубация идей): Когда человек идет в душ или гуляет в парке, его мозг продолжает связывать случайные внешние стимулы (увиденное дерево, услышанный обрывок фразы, упавшее яблоко) с текущей задачей. Это хаотичный, нелинейный процесс, рождающий нестандартные ассоциации. У ИИ подсознания нет. Его фоновая работа — это просто контролируемый, строго линейный расход вычислических мощностей сервера.
Внутренняя мотивация и жизненный цикл: Да, человек готов думать над задачей годами, потому что им движет страсть или экзистенциальная нужда. ИИ будет искать ответ ровно до тех пор, пока запущен инстанс и на балансе облачного провайдера есть деньги. Но давайте будем честны: у кожаных исполнителей тоже кончаются теломеры. Человеческий «рантайм» жестко ограничен биологией. Программист может выгореть, постареть или банально устать от профессии до того, как найдет решение. ИИ же, пока капают деньги на счет, теоретически может пережить поколения своих создателей, продолжая ковырять один и тот же проект с одинаковой интенсивностью.
Динамическая эволюция: А модель-то уже не та
Есть еще один скрытый козырь, который окончательно ломает правила игры. Человек, думая над задачей месяцами, стареет и деградирует биологически, а его базовые когнитивные способности остаются в лучшем случае на прежнем уровне.
С ИИ-агентом происходит строго противоположное. Пока ваш скрипт из недели в неделю стучится в API, на стороне провайдера (будь то OpenAI, Anthropic или локальные апдейты open-source весов) постоянно выходят микро-обновления.
Провайдеры молча дообучают модели на новых датасетах, оптимизируют квантизацию или накатывают патчи. В итоге каждую неделю на один и тот же crontab-тик отвечает уже немного другая модель. Она незаметно становится умнее, лучше понимает контекст и избавляется от старых галлюцинаций. Получается, что в процессе многомесячного «размышления» сам цифровой мозг эволюционирует прямо на лету, повышая шансы решить задачу с каждым новым тиком планировщика.
Вывод: Битва лимитов
Мы привыкли идеализировать человеческое мышление, приписывая ему бесконечную глубину. Но реальность сурова: человеческий мозг — это тоже углеродный процессор со своими аппаратными ограничениями, старением клеток и неизбежным концом жизненного цикла.
В итоге мы получаем противостояние двух разных типов ограничений:
У ИИ — это внешние resources (деньги на балансе API, электричество, лимиты контекста) при постоянно растущем качестве «мозга».
У человека — это внутренние ресурсы (сокращающиеся теломеры, выгорание, физическое время жизни) при фиксированных когнитивных способностях.
Стоит обернуть языковую модель в простейшую автоматизацию, как мы получаем автономного «цифрового мыслителя». Да, у него нет искры гениальности в человеческом понимании, но у него есть терабайты свежих данных и бесконечное, абсолютно безэмоциональное упорство, не зависящее от биологических часов.
А как вы считаете, коллеги? Что закончится раньше при решении по-настоящему сложной многолетней задачи — деньги на балансе облака или теломеры у ведущего инженера? Доверили бы вы crontab-агенту проект на пару месяцев автономного плавания, зная, что к концу срока он будет думать уже на базе обновленной версии LLM?
Делитесь своим опытом создания ИИ-агентов в комментариях. Если тема зайдет, в следующей статье выкачу готовый шаблон на Python + Celery + LangChain для реализации такого долгосрочного фонового мыслителя.
PS. Ну, не я выкачу, это ИИ хотело выкатить. Кому надо - выкатывайте.
Косвенно вылезает ещё одно свойство, уже не про Райса, а про сам естественный язык. Чем более сложную композицию мы хотим построить, тем хуже она ложится на слова. По‑русски это звучит так, что маленькую функцию описать словами можно, получится даже неплохо и понятно, а вот систему на миллион строк словами описать нельзя, и дело не в том, что слов не хватит, просто естественный язык не композируется, а смысл может накладываться, перетекать от предложения к предложению или зависеть от соседних предложений, захватывая абзацы, а иногда и более крупные участки произведения.
для борьбы с этим и придумали DDD, разделение контекстов
Вы абсолютно правы, и это очень глубокое наблюдение. Вы затронули фундаментальную проблему семантического коллапса в естественном языке при масштабировании.
Естественный язык обладает свойством нелинейности и контекстной зависимости (синестезия смыслов, омонимия, метафоры). В литературе это плюс, но в инженерии — катастрофа. Код же обязан быть композициональным: смысл целого должен строго складываться из суммы его частей.
Вот как именно Domain-Driven Design (DDD) и разделение контекстов (Bounded Contexts) борются с этой проблемой естественного языка:
1. Борьба с полисемией (многозначностью)
В больших системах одно и то же слово означает абсолютно разные вещи для разных людей.
Проблема: Слово «Аккаунт» для бухгалтера — это баланс и проводки. Для службы безопасности — это логин и права доступа. Для маркетолога — это профиль клиента. Попытка создать единое описание «Аккаунта» словами приводит к путанице.
Решение DDD: Каждому контексту — свое определение. В контексте «Биллинг» Аккаунт — это деньги. В контексте «Авторизация» — это сессия. Смысл больше не «перетекает» хаотично.
2. Ограничение когнитивной нагрузки
Человеческий мозг не может удержать связи между миллионом строк кода или тысячей страниц текста, если они переплетены.
Проблема: В тексте без границ смысл предложения А может внезапно зависеть от абзаца Z в конце книги.
Решение DDD: Ограниченный контекст (Bounded Context) создает жесткую границу смысла. Все, что происходит внутри контекста, изолировано. Вам не нужно знать контекст Z, чтобы понять контекст A.
3. Единый язык (Ubiquitous Language) как API
DDD не пытается исправить весь естественный язык сразу. Оно исправляет его локально.
Решение DDD: Внутри одной границы создается строгий, почти математический словарь. Слово «Заказ» внутри контекста «Доставка» означает строго конкретный набор полей и статусов. Шаг влево, шаг вправо — синтаксическая ошибка.
По сути, DDD признает: «Мы не можем описать сложную систему единым текстом на человеческом языке. Поэтому мы нарежем систему на маленькие независимые “княжества”, внутри каждого из которых язык будет простым, однозначным и не вызовет композиционного взрыва».
Когда появится система «БД требований ➔ бинарный код»?
До полностью автономного состояния «БД требований ➔ бинарный код» осталось 3–5 лет: технология станет коммерчески доступной к 2029–2031 годам.
Прямо сейчас, в 2026 году, ИИ уже умеет генерировать рабочие приложения из текстовых описаний, но только для простых и изолированных систем (вроде MVP на Python или простых веб-сервисов). Переход к созданию сложных enterprise-систем напрямую в бинарный код (минуя или скрывая под капотом промежуточные этапы вроде Git и Docker) упирается в три фундаментальные технологические проблемы, которые индустрия решает прямо сейчас.
График и этапы эволюции до 2031 года
Ограниченные MVP (Low-Code/No-Code ИИ)
│
[2027-2028] Появление спецификаций "ИИ для ИИ" (JIT-архитектура)
│
[2029-2030] Первые enterprise-компиляторы смыслов (БД требований -> Сервис)
│
[2031+] Полная автономность (Zero-Code / Прямая компиляция)
Почему это займет именно 3–5 лет? (3 барьера)
1. Проблема «Галлюцинаций в логике» (Ближайшие 1–2 года)
Если ИИ ошибется в коде веб-страницы, она просто криво отобразится. Если ИИ ошибется в логике транзакций ядра финтех-системы, компания потеряет миллионы. Чтобы собирать бинарный код напрямую из требований, нужны нейро-символические ИИ (Neuro-symbolic AI), которые соединят гибкость LLM со строгой математической логикой формальной верификации (как в аэрокосмических системах). Их коммерческое созревание ожидается к 2028 году.
2. Проблема декомпозиции (Ближайшие 2–3 года)
База данных требований enterprise-уровня содержит тысячи взаимосвязанных бизнес-правил. Современные контекстные окна ИИ огромны, но модели все еще «забывают» детали в середине текста или путают приоритеты требований. Требуется переход на архитектуры JIT-архитектуры смыслов, когда ИИ-оркестратор сначала строит динамическую граф-модель системы, а уже потом отдает её на компиляцию агентам нижнего уровня.
3. Избавление от «человеческого» исходного кода (К 2030–2031 годам)
Зачем компилировать требования сначала в C++ или Java, а потом в бинарник, если код больше никто не будет читать руками? К 2030 году появятся LLM-компиляторы, которые будут переводить логические требования напрямую в промежуточное представление (IR) вроде LLVM IR или сразу в байт-код / машинный код, оптимизированный под конкретный чип (x86, ARM, TPU), полностью исключая человека из цепочки ревью.
Как это будет работать на практике?
Когда эта технология станет стандартом, классический процесс разработки сожмется до одной итерации:
Сбор требований: Аналитики, продакты или сам ИИ наполняют БД требований (в виде структурированного графа знаний, графических схем и граничных условий).
Формализация: ИИ-верификатор проверяет БД на предмет внутренних противоречий (например, если требование А противоречит требованию Б, система сразу потребует уточнения).
Компиляция смыслов: Специализированная нейросеть трансформирует этот граф в бинарный образ (или Docker-контейнер с оптимизированным микросервисом) и автоматически покрывает его миллионами синтетических тестов.
Ответ ИИ: Да, оптимизацию вычислений в Conformal Geometric Algebra (CGA) на C++ не только можно, но и нужно выполнять, так как “наивная” реализация алгебры Клиффорда (например, с использованием общих матриц 32x32) будет работать медленно из-за огромного количества нулевых элементов.
В CGA мультивектор состоит из 32 базисных элементов, что требует поиска эффективных путей вычисления.
Основные подходы к оптимизации CGA в C++
Отказ от полной алгебры и разреженное хранение (Sparse Multivectors) Большинство операций в CGA затрагивают лишь небольшое подмножество базисных элементов (например, определенные подпространства k-векторов). Использование шаблонов позволяет вычислять только ненулевые коэффициенты и компилировать код, исключая умножения на ноль.
Метапрограммирование шаблонов (Expression Templates) и ленивые вычисления Такие библиотеки, как GATL и Gaalet, используют продвинутое метапрограммирование. Они конструируют выражение во время компиляции, исключая создание временных объектов и объединяя базовые операции в максимально быстрый машинный код.
Предварительная генерация кода (Code Generation) Сложные выражения и формулы можно оптимизировать с помощью программ предварительной компиляции (прекомпиляторов). Например, Gaalop (Geometric Algebra Algorithms Optimizer) принимает алгоритм, записанный на геометрической алгебре, математически упрощает его и генерирует чистый, низкоуровневый C++ код.
Использование SIMD (Векторизация) Для обеспечения высокой пропускной способности многие современные движки используют аппаратную векторизацию (SSE, AVX, NEON). Хотя многие подобные библиотеки узко специализируются на 3D Projective Geometric Algebra (например, Klein), эти же низкоуровневые техники векторной математики применимы и для масштабирования производительности CGA.
Генераторы библиотек Существуют инструменты вроде Garamon, которые способны по заданному файлу конфигурации (метрике пространства) автоматически генерировать максимально оптимизированную под конкретную задачу C++ библиотеку.
Рекомендуемые C++ библиотеки
Для работы с геометрическими алгебрами, включая CGA, можно использовать готовые решения, в которых эти оптимизации уже применены:
Versor — очень популярная C++ библиотека для CGA, которая базируется на предвычисленных таблицах умножения и сильно темплатизирована для достижения высокой скорости во время выполнения.
GAL — высокопроизводительный движок на C++17, оптимизирующий вычисления и убирающий избыточные термины с помощью compile-time преобразований.
GATL — использует ленивые вычисления (lazy evaluation) для оптимизации алгебраических выражений на этапе компиляции.
Если вы планируете реализовывать вычисления самостоятельно, то наиболее эффективным будет путь использования концепций Data-Oriented Programming (ориентация на данные) и написания кода, генерирующего таблицы умножения (Basis Blade Multiplication Tables) прямо на этапе компиляции с помощью constexpr и variadic templates.
Прошу прощения, что отвечаю нейрослопом — технически я в отпуске, да и лучше всё равно не напишу:
Проектирование систем в эпоху ИИ: Контракты vs Предметная область
Часть 1. Разделение труда: Что безопасно делегировать моделям?
Идея использовать контракты как жесткие границы для ИИ — это зрелый архитектурный подход, разделяющий разработку на высокоуровневое проектирование (стабильная зона) и детали реализации (изменчивая зона).
🔍 Что БЕЗОПАСНО делегировать (В рамках контракта)
ИИ идеален там, где есть строгая математическая или логическая изоляция, а задача сводится к «заполнению пустот» по готовым правилам.
Код внутри «чистых функций»: Если контракт жестко определяет вход (Data Transfer Object) и выход, ИИ напишет алгоритм трансформации данных без ошибок.
Генерация юнит-тестов на сам контракт: Модели отлично находят граничные значения (boundary условия), проверяют обработку null, пустых строк или некорректных типов на входе.
Рутинный Code Style и бойлерплейт: Настройка мапперов, создание DTO-классов, валидаторов данных и конфигурационных файлов по шаблону проекта.
Изолированные миграции данных: Если контракт старой схемы A и новой схемы B четко описан, ИИ сгенерирует скрипт трансформации данных.
❌ Что НЕЛЬЗЯ делегировать (Зона риска)
Проблемы начинаются там, где контракты сталкиваются с реальным миром, историческим контекстом и неявными зависимостями.
Рефакторинг «дырявых» старых контрактов (Legacy): Старый контракт может содержать скрытые сайд-эффекты, на которые неявно завязаны другие модули. ИИ перепишет его «красиво», но сломает интеграцию с системой, которая ожидала именно старый «баг», ставший фичей.
Проектирование абстракций верхнего уровня: Создание стабильных контрактов требует понимания долгосрочной бизнес-стратегии компании. ИИ не знает, куда бизнес пойдет через год, и может создать академически идеальную, но абсолютно негибкую структуру.
Эволюция контрактов и миграция сложных распределенных систем: Модель видит контракт статическим. Ей тяжело спроектировать процесс перехода в реальном времени под нагрузкой (схемы двойной записи, конкурентный доступ, откаты транзакций).
Часть 2. Высший уровень: Схема «Человек проектирует предметную область -> ИИ пишет реализацию»
Эта схема выводит взаимодействие с ИИ на уровень DDD (Domain-Driven Design). Предметная область (Domain) выступает в роли главного, неизменяемого ядра системы, а ИИ занимается инфраструктурным «обвесом». Программист здесь окончательно перестает быть кодером и становится переводчиком со сложного языка реальности на строгий язык моделей.
🌟 Как это работает идеально
Человек описывает Единый язык (Ubiquitous Language), сущности (Entities), агрегаты (Aggregates) и доменные события (Domain Events) на естественном языке, а ИИ берет на себя рутину:
Изолированная доменная логика: ИИ великолепно переводит текстовое описание бизнес-правил в чистый код. Так как в доменном слое по канону нет зависимостей от БД и фреймворков, ИИ негде запутаться.
Покрытие инвариантов тестами: Вы описываете бизнес-правило, а ИИ генерирует сотни юнит-тестов, проверяющих этот инвариант со всеми возможными комбинациями данных.
Генерация инфраструктурного слоя: На основе вашей доменной модели ИИ пишет репозитории, контроллеры, мапперы в БД и DTO для внешних API.
⚠️ Где схема дает сбой (Новые вызовы)
Трудности с границами контекстов (Bounded Contexts): Одна и та же сущность (например, Product) в разных отделах компании выглядит по-разному. Если человек четко не разделит контексты, ИИ попытается создать один гигантский «универсальный» класс (God Object), порождая монолитный хаос.
Потеря скрытых бизнес-знаний (Implicit Knowledge): Бизнес-пользователи часто не говорят о вещах, которые кажутся им «очевидными». Человек-разработчик догадается спросить о пробелах в логике, ИИ же просто напишет код по дефектному ТЗ.
Технический долг внутри самого Домена: Если правила меняются часто, ИИ может начать вносить правки в логику агрегатов «костылями», нарушая инкапсуляцию. В итоге доменная модель теряет свою чистоту и превращается в анемичную (Anemic Domain Model).
Итог
Схема с контрактами позволяет управлять структурой данных, а схема с предметной областью — смыслом бизнеса. Программирование будущего — это умение вытягивать из хаотичного реального мира чистые концепты и скармливать их фабрике агентов, оставляя за собой роль архитектора смыслов.
Вендор должен быть обязан залить решение на github и отечественный репозиторий.
Государство забирает права, но юридически оформляет этот форк под лицензией MIT. Это позволяет любому другому ведомству легально и без согласований скопировать этот код.
Технологическое лидерство и опенсорс: Новая парадигма суверенитета и кооперации
Долгое время концепция технологического лидерства ассоциировалась с монополией на знания. Лидерами становились корпорации и государства, способные воздвигнуть самые высокие стены вокруг своей интеллектуальной собственности. Проприетарный код, закрытые архитектуры и патентные войны были главными инструментами удержания власти на ИТ-рынке. Однако цифровая эпоха XXI века перевернула эти представления. Сегодня истинное технологическое лидерство смещается в сторону тех, кто умеет эффективно управлять открытым исходным кодом (Open Source) и задавать стандарты для глобального ИТ-сообщества.
Отказ от изоляции в пользу доминирования
В современной экономике попытка создать сложную цифровую экосистему в полной изоляции обречена на провал. Ни одна, даже самая богатая корпорация или технологически развитая держава, не способна аккумулировать внутри себя интеллектуальный ресурс, равный мощи глобального open-source сообщества. Проекты уровня ядра Linux, СУБД PostgreSQL или инструментов искусственного интеллекта развиваются силами миллионов инженеров по всему миру.
Технологическое лидерство сегодня — это не владение кодом, а способность влиять на вектор его развития. Компании и государства, выступающие ключевыми контрибьюторами в критически важные open-source проекты, фактически формируют технологический ландшафт планеты. Они первыми внедряют инновации, задают архитектурные стандарты и привлекают лучшие умы, в то время как пассивные потребители закрытых систем остаются в позиции вечно догоняющих.
Государственный Open Source как экономический драйвер
Особенно остро вопрос открытого кода стоит в государственном секторе. Исторически министерства и ведомства тяготели к закрытым решениям, ошибочно полагая, что секретность кода гарантирует его безопасность (принцип security through obscurity). На практике это приводило к миллиардным потерям, дублированию разработки и тотальной зависимости от конкретных коммерческих подрядчиков — так называемому вендор-локу (Vendor Lock-in).
Переход государства к парадигме «Открыт по умолчанию» под свободными лицензиями (например, MIT) кардинально меняет правила игры. Когда программный код, созданный на деньги налогоплательщиков, публикуется в национальных и глобальных репозиториях, он превращается из ведомственной собственности в коллективный цифровой капитал.
Экономия и шеринг: Ведомства перестают дважды платить за один и тот же функционал. Созданный однажды модуль документооборота или распознавания данных становится доступен всей стране, высвобождая бюджеты для более сложных задач.
Стимулирование рынка: Коммерческий сектор и стартапы получают легальный доступ к мощным государственным ИТ-платформам промышленного уровня. Это снижает порог входа для инновационного бизнеса, запуская лавинообразный рост ИТ-индустрии.
Общественный аудит: Открытый код привлекает независимых ИТ-исследователей и «белых хакеров». Тысячи глаз бесплатно находят уязвимости и баги, делая государственные системы кратно надежнее закрытых аналогов.
Двухтрековый баланс: Синергия государства и бизнеса
Разумная стратегия технологического лидерства на базе open source не означает уничтожения коммерческого ИТ-рынка. Истинный суверенитет строится на гибридной модели.
С одной стороны, утилитарный, прикладной и заказной софт (порталы, CRM, шины данных) должен быть полностью открытым под лицензией MIT, исключая паразитирование подрядчиков на госконтрактах. С другой стороны, государство должно опираться на сильных отечественных вендоров, развивающих сложные инфраструктурные продукты (операционные системы, тяжелые СУБД). Такие компании работают по модели Open-Core: они инвестируют в глобальный открытый код, но зарабатывают на создании защищенных Enterprise-версий и круглосуточной техподдержке. Поддерживая их, государство получает надежный фундамент, не изобретая велосипед там, где бизнес уже создал продукт мирового уровня.
Заключение
Технологическое лидерство будущего принадлежит не тем, кто пытается спрятать свои разработки за юридическими барьерами и закрытыми лицензиями. Оно принадлежит тем, кто делает открытый код ядром своей цифровой стратегии. Создание открытых национальных репозиториев, жесткий отказ от вендор-лока в госсекторе, обязательная публикация заказного кода под лицензией MIT и опора на сильных коммерческих open-source игроков — это единственный путь к подлинному цифровому суверенитету и технологическому доминированию в современном мире. Борьба за ИТ-лидерство выиграет не тот, кто построит самую высокую стену, а тот, кто создаст самую эффективную и открытую экосистему.
Разработать ОС на c++ с встроенным сервером для приема/передачи бинарных данных: https://share.google/aimode/EV8rmBHjQ2lh0OIqc Какой бы следующий вопрос задали бы вы? С чего бы начали такую разработку?
Вопрос: Можно использовать для получения коэффициентов обучение с подкреплением?
Ответ ИИ:
Применение Reinforcement Learning (RL) для настройки ПИД-регуляторов
Обучение с подкреплением отлично подходит для настройки ПИД-регуляторов, особенно в сложных или динамически меняющихся системах. В отличие от классических методов (например, Циглера-Николса), RL делает регулятор адаптивным.
Как это работает:
Агент (нейросеть): Наблюдает за состоянием системы (текущая ошибка, скорость изменения ошибки).
Действие: Агент не управляет исполнительным механизмом напрямую, а динамически корректирует коэффициенты , , .
Награда (Reward): Агент получает «бонус» за быстрое достижение цели и «штраф» за перелет (overshoot) или колебания.
Преимущества RL:
Адаптивность: Перенастройка коэффициентов «на лету» при изменении внешних условий (например, изменение веса груза).
Работа с нелинейностью: Эффективность в системах, где математическая модель слишком сложна.
Автоматизация: Алгоритм самостоятельно находит оптимальные параметры через тысячи итераций в симуляции.
Популярные алгоритмы:
Для таких задач чаще всего используют алгоритмы непрерывного действия:
PPO (Proximal Policy Optimization)
DDPG (Deep Deterministic Policy Gradient)
SAC (Soft Actor-Critic)
Важно: Обучение обычно проводится в цифровом двойнике (симуляции), так как на реальном оборудовании ошибки агента в процессе обучения могут привести к поломкам.
Разработчики всё чаще подключают ИИ к задачам — от обработки данных до генерации тестов. На первом просмотре такой код выглядит аккуратно и логично. Но при рабочей нагрузке в нём часто вскрываются ошибки, которые модель не учла.
Вопрос: Что можно сделать?
Ответ ИИ:
Практики безопасного использования ИИ в разработке
1. Смена парадигмы: ИИ как стажер
Относитесь к коду от ИИ не как к готовому решению, а как к черновику от junior-разработчика.
Тщательный Code Review: Никогда не пропускайте ИИ-код без построчного анализа.
Проверка граничных случаев: Модели часто «галлюцинируют» в специфических сценариях.
2. Тестирование под давлением
Визуальная чистота кода не гарантирует его эффективность.
Нагрузочное тестирование (Load Testing): Проверяйте алгоритмы на больших объемах данных. ИИ может предложить лаконичный код с плохой сложностью (например, там, где нужно ).
Профилирование: Используйте инструменты анализа памяти и CPU.
3. Улучшение промптов (Prompt Engineering)
Контекст — ключ к качеству.
Указывайте ограничения: Добавляйте условия: «код должен быть потокобезопасным», «память ограничена 512 МБ».
Chain-of-Thought: Просите модель сначала описать логику и риски, а только потом писать сам код.
4. Архитектурный контроль
ИИ хорош в локальных функциях, но слаб в понимании всей системы.
Инкапсуляция: Изолируйте ИИ-код в отдельные модули. Его сбой не должен обрушить всё приложение.
Логирование и мониторинг: Добавляйте расширенное логирование в блоки, созданные ИИ.
5. Специализированные инструменты
Используйте автоматику для подстраховки:
Статические анализаторы: Инструменты вроде SonarQube или Snyk находят уязвимости.
Нейрослоп: Пушок сидел на подоконнике и с осуждением смотрел на экран монитора, где бесконечные строки кода сменяли друг друга. Его хозяин в очередной раз сражался с Borrow Checker. — Потерпи, Пушок, — пробормотал программист, потирая глаза. — Еще пара фич, и мы пройдем по кредитной нагрузке. Цель была амбициозной: собственная квартира, где у кота будет личный застекленный балкон для наблюдения за птицами. Но пока что жизнь состояла из жестких правил Rust. Каждый раз, когда компилятор выдавал ошибку, Пушок сочувственно мяукал, понимая: «владение» (ownership) — штука сложная не только в программировании, но и в недвижимости. Прошло полгода. Алгоритмы были отлажены, тесты пройдены, а заветный оффер от банка получен. В день переезда Пушок первым вошел в пустую гостиную. Он важно обошел периметр, проверил качество паркета и, наконец, запрыгнул на широкий подоконник. Хозяин открыл ноутбук, чтобы написать короткое: println!("Home, sweet home!");. Пушок подошел ближе и наступил лапой на клавишу Enter. Программа скомпилировалась с первого раза. Теперь они оба были полноправными владельцами своего пространства, и никакой банк не мог «заимствовать» их уют без разрешения.
Хотите, чтобы я добавил в историю технические детали реализации проекта или подробнее описал обустройство нового дома для Пушка?
ИИ не согласен
Мысль автора понятна и отлично описывает боли первой волны генеративного ИИ (эпохи «вайб-кодинга» и простых копилотов). Действительно, если просто натравить LLM на огромный монолитный репозиторий, она начнет тонуть в легаси-коде, совершать регрессионные ошибки и пытаться, как археолог, раскопать исходный замысел архитектора по косвенным признакам.
Однако эта логика исходит из предпосылки, что код — это единственный и финальный источник правды (Single Source of Truth) для ИИ. И именно в этой точке тезис начинает стремительно устаревать.
Индустрия прямо сейчас совершает тектонический сдвиг от «промпт-кодинга» к методологии IDD (Intent-Driven Development) и системному Context Engineering. Этот подход полностью переворачивает парадигму и решает озвученную проблему через три фундаментальных изменения:
Замысел больше не скрыт в реализации. В зрелых IDD-системах агенту не нужно «декомпилировать» архитектуру из миллионов строк кода. Замысел выносится на уровень выше и фиксируется декларативно — в виде архитектурных манифестов (например, стандарты типа
OpenSpecили расширенныйCLAUDE.md), схем данных и машиночитаемого бизнес-глоссария (Ubiquitous Language из DDD). Для ИИ архитектурный контекст — это не загадка, которую нужно разгадать, а жесткий входной параметр и рельсы, с которых нельзя съехать.Изоляция вместо расширения контекстных окон. Пытаться скормить модели весь проект целиком, надеясь на миллионные контекстные окна — тупиковый путь (модели неизбежно «тупеют» и теряют фокус в слишком длинном контексте). Решение, пришедшее из Domain-Driven Design — это жесткие границы контекста (Bounded Contexts). Агент, меняющий модуль оплаты, физически не видит код модуля логистики или авторизации. Он видит только свой изолированный кусок и строго зафиксированные контракты соседей через AST-графы (Abstract Syntax Tree). Ему просто запрещено понимать устройство всей системы, как и любому разработчику-человеку в крупном энтерпрайзе.
Смена ролей: Спецификация валидирует код, а не наоборот. Мы уходим от парадигмы, где ИИ учится на коде проекта и бездумно масштабирует его ошибки. В IDD сначала валидируется само «намерение» (Intent) на уровне абстрактного графа зависимостей. Если ИИ-архитектор видит, что новая фича нарушает контракт или создает циклическую зависимость, пайплайн останавливается до генерации кода.
Резюме: Цитата идеально описывает кризис систем, где код первичен. Но как только мы переходим на уровень Intent-Driven Engineering, где код становится лишь автоматически генерируемым артефактом, а человек управляет ограничениями и контрактами, необходимость «восстанавливать замысел из реализации» исчезает. Мы больше не просим ИИ понять наш код — мы заставляем его подчиняться нашей спецификации.
IDD (Intent-Driven Development) в ИИ-разработке
**Intent-Driven Development (IDD, разработка на основе намерений)** — это новая методология инженерии программного обеспечения в эпоху ИИ, при которой **инженер формулирует, структурирует и валидирует свои верхнеуровневые намерения (Intents), а ИИ-агенты полностью берут на себя генерацию кода, тестов и интеграцию**.
В отличие от хаотичного «вайб-кодинга» (написания кода через простые чат-промпты), IDD смещает роль программиста с ручного написания строк кода («укладки кирпичей») к роли Архитектора и Контролера, который управляет контекстом и проверяет результат работы автономных агентов.
📊 Разница подходов: Эволюция к IDD
Критерий Вайб-кодинг (Vibe Coding) Spec-Driven Development (SDD) Intent-Driven Development (IDD) Что делает человек Пишет сырые промпты, кодит на ходу Создает огромные, жесткие ТЗ и контракты Формулирует намерения (Зачем/Что/Как) и тесты Что делает ИИ Генерирует куски кода по запросу Реализует систему строго по готовой спеке Автономно планирует задачи и пишет рабочий код Основной риск Галлюцинации, хаос в архитектуре Огромные затраты на ручную актуализацию спек Требует высокой архитектурной зрелости от инженера Результат Быстрый старт, нежизнеспособный легаси Стабильный код, медленный процесс итераций Высокая скорость, масштабируемость и прозрачность
💡 Анатомия Намерения (Intent) в IDD
Документ намерения (обычно оформляется в виде структурированного Markdown-файла) является единственным источником истины для ИИ-агента. Он состоит из трех обязательных блоков:
ЗАЧЕМ (WHY): Бизнес-контекст и мотивация. Зачем пользователю эта фича? Какую проблему мы решаем?
ЧТО (WHAT): Строгие функциональные требования. Часто описываются на понятном ИИ языке сценариев (например, Gherkin / Cucumber: Given-When-Then).
КАК (HOW): Верхнеуровневый пошаговый план технической реализации, разбитый на мелкие задачи, границы архитектуры и стек.
ИИ-агент считывает этот файл, не отвлекаясь на догадки и двусмысленные промпты, и генерирует реализацию, точно соответствующую ожиданиям.
🔎 Почему IDD критически важен для ИИ-эпохи?
Исключение «дрейфа намерений»: При классическом промптинге ИИ склонен додумывать логику за программиста, что ведет к накоплению скрытых багов. IDD жестко фиксирует рамки дозволенного.
Отделение стратегии от рутины: Человек концентрируется на бизнес-логике, граничных условиях и безопасности, а ИИ за секунды пишет рутинный boilerplate-код и юнит-тесты.
Архитектурный контроль: Передавая ИИ схему системы (DDD) и явное намерение, инженер сохраняет архитектуру проекта чистой, не позволяя нейросети превратить кодовую базу в “спагетти”.
➡️ Как выглядит рабочий процесс (Workflow) в IDD
Создание интента: Инженер описывает задачу в документе Интента (проверяя архитектурную совместимость).
Фиксация тестов: Инженер (или ИИ под его контролем) пишет поведенческие тесты, которые зафиксируют успешность выполнения намерения.
Запуск ИИ-агента: Специализированный ИИ-агент (например, на базе фреймворков для авто-кодинга) берет Интент в работу, декомпозирует его и приступает к кодингу.
Автоматическая валидация: Код прогоняется через тесты и линтеры. Если тесты падают, агент исправляет себя сам, пока условия интента не будут выполнены на 100%.
Human-in-the-loop: Инженер проводит финальный аудит (Code Review) и вливает изменения в основную ветку.
Что использует Robert C. Martin (Uncle Bob)?
Позиция Роберта Мартина (Uncle Bob) — автора культовой книги «Чистый код» и создателя принципов SOLID — по поводу агентной разработки произвела настоящий фурор в индустрии. Человек, десятилетиями учивший инженеров вылизывать каждую строчку, официально заявил, что больше вообще не читает код, написанный ИИ-агентами.
Вместо построения абстрактных моделей он использует подход, который называют «Испытательным полигоном» (Test Gauntlet). Его методология идеально ложится на рельсы IDD, но с жестким фокусом на автоматическую верификацию.
Вот стек практик и инструментов, которые дядя Боб использует для работы с ИИ:
1. Отказ от Code Review в пользу Метрик и Контрактов
Вместо того чтобы тратить время на построчное ревью кода (поскольку человек делает это слишком медленно), Мартин полностью абстрагировался от реализации. Качество кода ИИ-агентов он оценивает через автоматический скоринг телеметрии и метрик. Если ИИ-агент приносит Pull Request, платформа Дяди Боба автоматически проверяет:
Тестовое покрытие (Mutation Testing): Не просто покрытие строк, а мутационное тестирование. Код считается принятым, только если тесты ИИ-агента «ловят» искусственно внесенные баги.
Цикломатическую сложность (Cyclomatic Complexity): ИИ не должен плодить вложенные циклы и конструкции
if-else.Зацепление и связность (Dependency Structure): Проверка на нарушение принципов SOLID на уровне графа кода.
«Человек слишком медлителен в написании и чтении кода. Чтобы расти в продуктивности, люди должны отключиться от самого кода и управлять системой с более высокого уровня», — пишет Мартин.
2. Приемочное тестирование как интерфейс (ATDD)
В качестве главного инструмента управления намерениями (Intent) Дядя Боб использует Acceptance Test-Driven Development (ATDD) на базе Gherkin / Cucumber.
Как это работает: Инженер описывает требования к системе в виде человекочитаемых сценариев (например,
Given / When / Then).Этот файл спецификации скармливается агенту (Мартин активно поддерживает экосистему вокруг Claude Code и кастомных CLI-оберток). ИИ обязан написать реализацию так, чтобы эти сквозные приемочные тесты загорелись зеленым.
3. Архитектурные тесты (Architecture-as-Code)
Поскольку ИИ-агенты любят нарушать границы слоев (например, тащить инфраструктурный SQL-запрос напрямую в UI-контроллер), Дядя Боб использует инструмент ArchUnit (для Java/C#) и его аналоги в других языках.
Архитектурные правила зашиваются в специальные Unit-тесты.
Тест проверяет структуру проекта на уровне компиляции: «Пакет Domain не должен зависеть от пакета Infrastructure». ИИ физически не сможет запушить код, нарушающий Clean Architecture.
4. Навыки ИИ вместо гайдлайнов (Agent Skills)
Вместо того чтобы надеяться, что ИИ «вспомнит» правила чистого кода, Дядя Боб перевел весь свой каталог из 66 правил и эвристик «Clean Code» в машиночитаемый формат Agent Skills. Это конфигурационные файлы, которые нативно поддерживаются современными IDE (например, через Anthropic MCP-серверы). Перед тем как написать метод, агент парсит этот файл-инструкцию, выступающий жестким Guardrail.
Резюме: Формула Дяди Боба в эпоху ИИ
Метод Роберта Мартина сегодня — это «Дисциплинированная агентная инженерия» (Disciplined Agentic Engineering). Он не верит в то, что ИИ поймет архитектурный замысел сам. Но вместо создания сложной визуальной UML-модели до генерации кода, он кодирует архитектурные ограничения в виде автоматических тестов (TDD/ATDD). Тесты становятся единственным валидатором намерений, а ИИ выступает в роли «слепого исполнителя», который обязан пройти этот жесткий фильтр.
А еще хабр не умеет в нормальный маркдаун.
если правильно crontab настроить, то сможет
Как мы заставили ИИ думать над задачей неделями, просто настроив crontab
Каждый, кто хоть раз пользовался ChatGPT, Клодом или любой другой LLM, сталкивался с классическим паттерном «запрос-ответ». Ты даешь нейросети задачу, она крутит шестеренками пару секунд, выдает результат, и на этом всё. Сессия закрыта, контекст забыт.
В кулуарах IT-сообщества часто звучит аргумент: «Вот человек — это другое. Ты можешь озадачить инженера, он уползет думать, будет засыпать и просыпаться с этой мыслью неделями, месяцами, а потом бах — и перед сном его осенит инсайт! ИИ на такое не способен».
Способен. Если правильно настроить
crontab.Давайте разберем, как обычный планировщик задач превращает реактивную языковую модель в автономного агента долгосрочного мышления, и почему этот костыль неожиданно бьет по главным преимуществам человеческого мозга.
Анатомия «ночных размышлений» нейросети
Когда мы говорим, что человек «думает над задачей неделями», мы имеем в виду три процесса: накопление новых знаний, регулярный пересмотр старых гипотез и банальное упорство. Если обернуть вызовы API современной LLM в циклы и повесить на шедулер, мы получим поразительно похожую механику.
1. Бесконечные циклы рассуждений (Reasoning Loops)
Современные модели (вроде семейства OpenAI o1 и их последователей) уже «из коробки» умеют генерировать скрытые цепочки рассуждений перед тем, как выдать финальный текст. Они взвешивают варианты, критикуют свои же гипотезы и исправляют ошибки в процессе генерации токенов.
Если убрать жесткий лимит на время ответа (timeout) и позволить модели крутиться в фоновом режиме часами, она способна перебирать миллионы вариантов решения, углубляясь в дерево контекста так, как ни один человек физически не сможет из-за банальной оперативной памяти мозга.
2. Динамический контекст: ИИ умнеет каждый день
Человек, размышляя над сложной архитектурной проблемой или научной теоремой, ограничен багажом знаний в своей голове. Чтобы узнать что-то новое, ему нужно пойти и целенаправленно почитать статьи.
У ИИ-агента на
crontabэтот процесс автоматизирован. Каждые сутки в полночь скрипт просыпается и делает парсинг свежих репозиториев GitHub, препринтов arXiv, медицинских баз данных или финансовых отчетов за прошедший день. Все новые данные векторизуются и моментально добавляются в базу знаний агента (RAG — Retrieval-Augmented Generation). После этого ИИ запускает очередной цикл размышлений над глобальной задачей, но уже с учетом знаний, которых еще не существовало в природе вчера.Если в понедельник задача была нерешаема, во вторник ученые на другом конце Земли могли опубликовать нужную формулу. В среду ваш
crontab-агент прочитает её и выдаст готовое решение. Человек же узнал бы об этой публикации в лучшем случае через месяц из профильного хабратопика.3. Селф-рефлексия (Self-Reflection)
Чтобы ИИ «видел сны» о задаче, инженеры используют паттерн самокритики. Скрипт будит модель каждые несколько часов, поднимает из базы данных её же утреннее решение и скармливает его модели со строгим промптом: > *«Вот твое предыдущее решение задачи Х. Найди в нем логические уязвимости, крайние случаи (edge cases) и перепиши код так, чтобы оптимизировать производительность еще на 15%»*.
Механическое упорство против человеческого фактора
Когда мы сравниваем человека и автоматизированную систему на длинной дистанции,
crontabвнезапно нивелирует всё то, что мы привыкли считать «плюсами» живого ума.ИИ не выгорает. У него нет депрессии, прокрастинации, синдрома самозванца или бытовых проблем. Ему не надоест задача через три недели бесплодных попыток. Он не скажет: «Да ну его, не получается, пойду мемы посмотрю».
ИИ не теряет фокус. Если скрипт прописан на 10 лет вперед — модель будет долбить эту задачу 10 лет, каждую секунду оставаясь на пике своей «интеллектуальной формы». Ей не нужно тратить 20 минут на «вхождение в контекст» после чашки кофе.
Где граница всё еще сохраняется?
Было бы лукавством сказать, что
crontab + API = полноценный ученый. Фундаментальное различие между нами пока кроется в природе «озарения» и биологических лимитах.Фоновое бессознательное (Инкубация идей): Когда человек идет в душ или гуляет в парке, его мозг продолжает связывать случайные внешние стимулы (увиденное дерево, услышанный обрывок фразы, упавшее яблоко) с текущей задачей. Это хаотичный, нелинейный процесс, рождающий нестандартные ассоциации. У ИИ подсознания нет. Его фоновая работа — это просто контролируемый, строго линейный расход вычислических мощностей сервера.
Внутренняя мотивация и жизненный цикл: Да, человек готов думать над задачей годами, потому что им движет страсть или экзистенциальная нужда. ИИ будет искать ответ ровно до тех пор, пока запущен инстанс и на балансе облачного провайдера есть деньги. Но давайте будем честны: у кожаных исполнителей тоже кончаются теломеры. Человеческий «рантайм» жестко ограничен биологией. Программист может выгореть, постареть или банально устать от профессии до того, как найдет решение. ИИ же, пока капают деньги на счет, теоретически может пережить поколения своих создателей, продолжая ковырять один и тот же проект с одинаковой интенсивностью.
Динамическая эволюция: А модель-то уже не та
Есть еще один скрытый козырь, который окончательно ломает правила игры. Человек, думая над задачей месяцами, стареет и деградирует биологически, а его базовые когнитивные способности остаются в лучшем случае на прежнем уровне.
С ИИ-агентом происходит строго противоположное. Пока ваш скрипт из недели в неделю стучится в API, на стороне провайдера (будь то OpenAI, Anthropic или локальные апдейты open-source весов) постоянно выходят микро-обновления.
Провайдеры молча дообучают модели на новых датасетах, оптимизируют квантизацию или накатывают патчи. В итоге каждую неделю на один и тот же
crontab-тик отвечает уже немного другая модель. Она незаметно становится умнее, лучше понимает контекст и избавляется от старых галлюцинаций. Получается, что в процессе многомесячного «размышления» сам цифровой мозг эволюционирует прямо на лету, повышая шансы решить задачу с каждым новым тиком планировщика.Вывод: Битва лимитов
Мы привыкли идеализировать человеческое мышление, приписывая ему бесконечную глубину. Но реальность сурова: человеческий мозг — это тоже углеродный процессор со своими аппаратными ограничениями, старением клеток и неизбежным концом жизненного цикла.
В итоге мы получаем противостояние двух разных типов ограничений:
У ИИ — это внешние resources (деньги на балансе API, электричество, лимиты контекста) при постоянно растущем качестве «мозга».
У человека — это внутренние ресурсы (сокращающиеся теломеры, выгорание, физическое время жизни) при фиксированных когнитивных способностях.
Стоит обернуть языковую модель в простейшую автоматизацию, как мы получаем автономного «цифрового мыслителя». Да, у него нет искры гениальности в человеческом понимании, но у него есть терабайты свежих данных и бесконечное, абсолютно безэмоциональное упорство, не зависящее от биологических часов.
А как вы считаете, коллеги? Что закончится раньше при решении по-настоящему сложной многолетней задачи — деньги на балансе облака или теломеры у ведущего инженера? Доверили бы вы
crontab-агенту проект на пару месяцев автономного плавания, зная, что к концу срока он будет думать уже на базе обновленной версии LLM?Делитесь своим опытом создания ИИ-агентов в комментариях. Если тема зайдет, в следующей статье выкачу готовый шаблон на Python + Celery + LangChain для реализации такого долгосрочного фонового мыслителя.
PS. Ну, не я выкачу, это ИИ хотело выкатить. Кому надо - выкатывайте.
для борьбы с этим и придумали DDD, разделение контекстов
Вы абсолютно правы, и это очень глубокое наблюдение. Вы затронули фундаментальную проблему семантического коллапса в естественном языке при масштабировании.
Естественный язык обладает свойством нелинейности и контекстной зависимости (синестезия смыслов, омонимия, метафоры). В литературе это плюс, но в инженерии — катастрофа. Код же обязан быть композициональным: смысл целого должен строго складываться из суммы его частей.
Вот как именно Domain-Driven Design (DDD) и разделение контекстов (Bounded Contexts) борются с этой проблемой естественного языка:
1. Борьба с полисемией (многозначностью)
В больших системах одно и то же слово означает абсолютно разные вещи для разных людей.
Проблема: Слово «Аккаунт» для бухгалтера — это баланс и проводки. Для службы безопасности — это логин и права доступа. Для маркетолога — это профиль клиента. Попытка создать единое описание «Аккаунта» словами приводит к путанице.
Решение DDD: Каждому контексту — свое определение. В контексте «Биллинг» Аккаунт — это деньги. В контексте «Авторизация» — это сессия. Смысл больше не «перетекает» хаотично.
2. Ограничение когнитивной нагрузки
Человеческий мозг не может удержать связи между миллионом строк кода или тысячей страниц текста, если они переплетены.
Проблема: В тексте без границ смысл предложения А может внезапно зависеть от абзаца Z в конце книги.
Решение DDD: Ограниченный контекст (Bounded Context) создает жесткую границу смысла. Все, что происходит внутри контекста, изолировано. Вам не нужно знать контекст Z, чтобы понять контекст A.
3. Единый язык (Ubiquitous Language) как API
DDD не пытается исправить весь естественный язык сразу. Оно исправляет его локально.
Решение DDD: Внутри одной границы создается строгий, почти математический словарь. Слово «Заказ» внутри контекста «Доставка» означает строго конкретный набор полей и статусов. Шаг влево, шаг вправо — синтаксическая ошибка.
По сути, DDD признает: «Мы не можем описать сложную систему единым текстом на человеческом языке. Поэтому мы нарежем систему на маленькие независимые “княжества”, внутри каждого из которых язык будет простым, однозначным и не вызовет композиционного взрыва».
Будет больно
Когда появится система «БД требований ➔ бинарный код»?
До полностью автономного состояния «БД требований ➔ бинарный код» осталось 3–5 лет: технология станет коммерчески доступной к 2029–2031 годам.
Прямо сейчас, в 2026 году, ИИ уже умеет генерировать рабочие приложения из текстовых описаний, но только для простых и изолированных систем (вроде MVP на Python или простых веб-сервисов). Переход к созданию сложных enterprise-систем напрямую в бинарный код (минуя или скрывая под капотом промежуточные этапы вроде Git и Docker) упирается в три фундаментальные технологические проблемы, которые индустрия решает прямо сейчас.
График и этапы эволюции до 2031 года
Почему это займет именно 3–5 лет? (3 барьера)
1. Проблема «Галлюцинаций в логике» (Ближайшие 1–2 года)
Если ИИ ошибется в коде веб-страницы, она просто криво отобразится. Если ИИ ошибется в логике транзакций ядра финтех-системы, компания потеряет миллионы. Чтобы собирать бинарный код напрямую из требований, нужны нейро-символические ИИ (Neuro-symbolic AI), которые соединят гибкость LLM со строгой математической логикой формальной верификации (как в аэрокосмических системах). Их коммерческое созревание ожидается к 2028 году.
2. Проблема декомпозиции (Ближайшие 2–3 года)
База данных требований enterprise-уровня содержит тысячи взаимосвязанных бизнес-правил. Современные контекстные окна ИИ огромны, но модели все еще «забывают» детали в середине текста или путают приоритеты требований. Требуется переход на архитектуры JIT-архитектуры смыслов, когда ИИ-оркестратор сначала строит динамическую граф-модель системы, а уже потом отдает её на компиляцию агентам нижнего уровня.
3. Избавление от «человеческого» исходного кода (К 2030–2031 годам)
Зачем компилировать требования сначала в C++ или Java, а потом в бинарник, если код больше никто не будет читать руками? К 2030 году появятся LLM-компиляторы, которые будут переводить логические требования напрямую в промежуточное представление (IR) вроде LLVM IR или сразу в байт-код / машинный код, оптимизированный под конкретный чип (x86, ARM, TPU), полностью исключая человека из цепочки ревью.
Как это будет работать на практике?
Когда эта технология станет стандартом, классический процесс разработки сожмется до одной итерации:
Сбор требований: Аналитики, продакты или сам ИИ наполняют БД требований (в виде структурированного графа знаний, графических схем и граничных условий).
Формализация: ИИ-верификатор проверяет БД на предмет внутренних противоречий (например, если требование А противоречит требованию Б, система сразу потребует уточнения).
Компиляция смыслов: Специализированная нейросеть трансформирует этот граф в бинарный образ (или Docker-контейнер с оптимизированным микросервисом) и автоматически покрывает его миллионами синтетических тестов.
Ответ ИИ: Да, оптимизацию вычислений в Conformal Geometric Algebra (CGA) на C++ не только можно, но и нужно выполнять, так как “наивная” реализация алгебры Клиффорда (например, с использованием общих матриц 32x32) будет работать медленно из-за огромного количества нулевых элементов.
В CGA мультивектор состоит из 32 базисных элементов, что требует поиска эффективных путей вычисления.
Основные подходы к оптимизации CGA в C++
Отказ от полной алгебры и разреженное хранение (Sparse Multivectors) Большинство операций в CGA затрагивают лишь небольшое подмножество базисных элементов (например, определенные подпространства k-векторов). Использование шаблонов позволяет вычислять только ненулевые коэффициенты и компилировать код, исключая умножения на ноль.
Метапрограммирование шаблонов (Expression Templates) и ленивые вычисления Такие библиотеки, как GATL и Gaalet, используют продвинутое метапрограммирование. Они конструируют выражение во время компиляции, исключая создание временных объектов и объединяя базовые операции в максимально быстрый машинный код.
Предварительная генерация кода (Code Generation) Сложные выражения и формулы можно оптимизировать с помощью программ предварительной компиляции (прекомпиляторов). Например, Gaalop (Geometric Algebra Algorithms Optimizer) принимает алгоритм, записанный на геометрической алгебре, математически упрощает его и генерирует чистый, низкоуровневый C++ код.
Использование SIMD (Векторизация) Для обеспечения высокой пропускной способности многие современные движки используют аппаратную векторизацию (SSE, AVX, NEON). Хотя многие подобные библиотеки узко специализируются на 3D Projective Geometric Algebra (например, Klein), эти же низкоуровневые техники векторной математики применимы и для масштабирования производительности CGA.
Генераторы библиотек Существуют инструменты вроде Garamon, которые способны по заданному файлу конфигурации (метрике пространства) автоматически генерировать максимально оптимизированную под конкретную задачу C++ библиотеку.
Рекомендуемые C++ библиотеки
Для работы с геометрическими алгебрами, включая CGA, можно использовать готовые решения, в которых эти оптимизации уже применены:
Versor — очень популярная C++ библиотека для CGA, которая базируется на предвычисленных таблицах умножения и сильно темплатизирована для достижения высокой скорости во время выполнения.
GAL — высокопроизводительный движок на C++17, оптимизирующий вычисления и убирающий избыточные термины с помощью compile-time преобразований.
GATL — использует ленивые вычисления (lazy evaluation) для оптимизации алгебраических выражений на этапе компиляции.
Если вы планируете реализовывать вычисления самостоятельно, то наиболее эффективным будет путь использования концепций Data-Oriented Programming (ориентация на данные) и написания кода, генерирующего таблицы умножения (Basis Blade Multiplication Tables) прямо на этапе компиляции с помощью constexpr и variadic templates.
Прошу прощения, что отвечаю нейрослопом — технически я в отпуске, да и лучше всё равно не напишу:
Проектирование систем в эпоху ИИ: Контракты vs Предметная область
Часть 1. Разделение труда: Что безопасно делегировать моделям?
Идея использовать контракты как жесткие границы для ИИ — это зрелый архитектурный подход, разделяющий разработку на высокоуровневое проектирование (стабильная зона) и детали реализации (изменчивая зона).
🔍 Что БЕЗОПАСНО делегировать (В рамках контракта)
ИИ идеален там, где есть строгая математическая или логическая изоляция, а задача сводится к «заполнению пустот» по готовым правилам.
Код внутри «чистых функций»: Если контракт жестко определяет вход (Data Transfer Object) и выход, ИИ напишет алгоритм трансформации данных без ошибок.
Генерация юнит-тестов на сам контракт: Модели отлично находят граничные значения (boundary условия), проверяют обработку
null, пустых строк или некорректных типов на входе.Рутинный Code Style и бойлерплейт: Настройка мапперов, создание DTO-классов, валидаторов данных и конфигурационных файлов по шаблону проекта.
Изолированные миграции данных: Если контракт старой схемы
Aи новой схемыBчетко описан, ИИ сгенерирует скрипт трансформации данных.❌ Что НЕЛЬЗЯ делегировать (Зона риска)
Проблемы начинаются там, где контракты сталкиваются с реальным миром, историческим контекстом и неявными зависимостями.
Рефакторинг «дырявых» старых контрактов (Legacy): Старый контракт может содержать скрытые сайд-эффекты, на которые неявно завязаны другие модули. ИИ перепишет его «красиво», но сломает интеграцию с системой, которая ожидала именно старый «баг», ставший фичей.
Проектирование абстракций верхнего уровня: Создание стабильных контрактов требует понимания долгосрочной бизнес-стратегии компании. ИИ не знает, куда бизнес пойдет через год, и может создать академически идеальную, но абсолютно негибкую структуру.
Эволюция контрактов и миграция сложных распределенных систем: Модель видит контракт статическим. Ей тяжело спроектировать процесс перехода в реальном времени под нагрузкой (схемы двойной записи, конкурентный доступ, откаты транзакций).
Часть 2. Высший уровень: Схема «Человек проектирует предметную область -> ИИ пишет реализацию»
Эта схема выводит взаимодействие с ИИ на уровень DDD (Domain-Driven Design). Предметная область (Domain) выступает в роли главного, неизменяемого ядра системы, а ИИ занимается инфраструктурным «обвесом». Программист здесь окончательно перестает быть кодером и становится переводчиком со сложного языка реальности на строгий язык моделей.
🌟 Как это работает идеально
Человек описывает Единый язык (Ubiquitous Language), сущности (Entities), агрегаты (Aggregates) и доменные события (Domain Events) на естественном языке, а ИИ берет на себя рутину:
Изолированная доменная логика: ИИ великолепно переводит текстовое описание бизнес-правил в чистый код. Так как в доменном слое по канону нет зависимостей от БД и фреймворков, ИИ негде запутаться.
Покрытие инвариантов тестами: Вы описываете бизнес-правило, а ИИ генерирует сотни юнит-тестов, проверяющих этот инвариант со всеми возможными комбинациями данных.
Генерация инфраструктурного слоя: На основе вашей доменной модели ИИ пишет репозитории, контроллеры, мапперы в БД и DTO для внешних API.
⚠️ Где схема дает сбой (Новые вызовы)
Трудности с границами контекстов (Bounded Contexts): Одна и та же сущность (например,
Product) в разных отделах компании выглядит по-разному. Если человек четко не разделит контексты, ИИ попытается создать один гигантский «универсальный» класс (God Object), порождая монолитный хаос.Потеря скрытых бизнес-знаний (Implicit Knowledge): Бизнес-пользователи часто не говорят о вещах, которые кажутся им «очевидными». Человек-разработчик догадается спросить о пробелах в логике, ИИ же просто напишет код по дефектному ТЗ.
Технический долг внутри самого Домена: Если правила меняются часто, ИИ может начать вносить правки в логику агрегатов «костылями», нарушая инкапсуляцию. В итоге доменная модель теряет свою чистоту и превращается в анемичную (Anemic Domain Model).
Итог
Схема с контрактами позволяет управлять структурой данных, а схема с предметной областью — смыслом бизнеса. Программирование будущего — это умение вытягивать из хаотичного реального мира чистые концепты и скармливать их фабрике агентов, оставляя за собой роль архитектора смыслов.
Вендор должен быть обязан залить решение на github и отечественный репозиторий.
Государство забирает права, но юридически оформляет этот форк под лицензией MIT. Это позволяет любому другому ведомству легально и без согласований скопировать этот код.
Оставить как есть. https://share.google/aimode/BsBg2Xd9LrvQVCLqt
Сколько государство тратит на ПО? https://share.google/aimode/UHuxNkCbN4t41Olgr
Сколько тратится на опенсорс, проприетарные и прочие решения? https://share.google/aimode/trkVzXpwaITVmd4Bb
Риски и регуляторные барьеры https://share.google/aimode/BIBcx6hFK67PglLxM
Стратегические преимущества https://share.google/aimode/mU7nqTlhgJTEE8MlW
Если не трогать успешные IT продукты/компании? https://share.google/aimode/Q6eTCkNaYwJoGq5F4
Гос-репозиторий должен быть максимально открытым насколько возможно. Как заказывается и работает экспертиза. https://share.google/aimode/B6IopgAHl0ew6CCbx
Концепция Гос-репозитория: «Открыт по умолчанию» https://share.google/aimode/hNNwDorxZQIecxbPx
Технологическое лидерство и опенсорс https://share.google/aimode/71UIFfxbZPhgJA82Z
Технологическое лидерство и опенсорс: Новая парадигма суверенитета и кооперации
Долгое время концепция технологического лидерства ассоциировалась с монополией на знания. Лидерами становились корпорации и государства, способные воздвигнуть самые высокие стены вокруг своей интеллектуальной собственности. Проприетарный код, закрытые архитектуры и патентные войны были главными инструментами удержания власти на ИТ-рынке. Однако цифровая эпоха XXI века перевернула эти представления. Сегодня истинное технологическое лидерство смещается в сторону тех, кто умеет эффективно управлять открытым исходным кодом (Open Source) и задавать стандарты для глобального ИТ-сообщества.
Отказ от изоляции в пользу доминирования
В современной экономике попытка создать сложную цифровую экосистему в полной изоляции обречена на провал. Ни одна, даже самая богатая корпорация или технологически развитая держава, не способна аккумулировать внутри себя интеллектуальный ресурс, равный мощи глобального open-source сообщества. Проекты уровня ядра Linux, СУБД PostgreSQL или инструментов искусственного интеллекта развиваются силами миллионов инженеров по всему миру.
Технологическое лидерство сегодня — это не владение кодом, а способность влиять на вектор его развития. Компании и государства, выступающие ключевыми контрибьюторами в критически важные open-source проекты, фактически формируют технологический ландшафт планеты. Они первыми внедряют инновации, задают архитектурные стандарты и привлекают лучшие умы, в то время как пассивные потребители закрытых систем остаются в позиции вечно догоняющих.
Государственный Open Source как экономический драйвер
Особенно остро вопрос открытого кода стоит в государственном секторе. Исторически министерства и ведомства тяготели к закрытым решениям, ошибочно полагая, что секретность кода гарантирует его безопасность (принцип security through obscurity). На практике это приводило к миллиардным потерям, дублированию разработки и тотальной зависимости от конкретных коммерческих подрядчиков — так называемому вендор-локу (Vendor Lock-in).
Переход государства к парадигме «Открыт по умолчанию» под свободными лицензиями (например, MIT) кардинально меняет правила игры. Когда программный код, созданный на деньги налогоплательщиков, публикуется в национальных и глобальных репозиториях, он превращается из ведомственной собственности в коллективный цифровой капитал.
Экономия и шеринг: Ведомства перестают дважды платить за один и тот же функционал. Созданный однажды модуль документооборота или распознавания данных становится доступен всей стране, высвобождая бюджеты для более сложных задач.
Стимулирование рынка: Коммерческий сектор и стартапы получают легальный доступ к мощным государственным ИТ-платформам промышленного уровня. Это снижает порог входа для инновационного бизнеса, запуская лавинообразный рост ИТ-индустрии.
Общественный аудит: Открытый код привлекает независимых ИТ-исследователей и «белых хакеров». Тысячи глаз бесплатно находят уязвимости и баги, делая государственные системы кратно надежнее закрытых аналогов.
Двухтрековый баланс: Синергия государства и бизнеса
Разумная стратегия технологического лидерства на базе open source не означает уничтожения коммерческого ИТ-рынка. Истинный суверенитет строится на гибридной модели.
С одной стороны, утилитарный, прикладной и заказной софт (порталы, CRM, шины данных) должен быть полностью открытым под лицензией MIT, исключая паразитирование подрядчиков на госконтрактах. С другой стороны, государство должно опираться на сильных отечественных вендоров, развивающих сложные инфраструктурные продукты (операционные системы, тяжелые СУБД). Такие компании работают по модели Open-Core: они инвестируют в глобальный открытый код, но зарабатывают на создании защищенных Enterprise-версий и круглосуточной техподдержке. Поддерживая их, государство получает надежный фундамент, не изобретая велосипед там, где бизнес уже создал продукт мирового уровня.
Заключение
Технологическое лидерство будущего принадлежит не тем, кто пытается спрятать свои разработки за юридическими барьерами и закрытыми лицензиями. Оно принадлежит тем, кто делает открытый код ядром своей цифровой стратегии. Создание открытых национальных репозиториев, жесткий отказ от вендор-лока в госсекторе, обязательная публикация заказного кода под лицензией MIT и опора на сильных коммерческих open-source игроков — это единственный путь к подлинному цифровому суверенитету и технологическому доминированию в современном мире. Борьба за ИТ-лидерство выиграет не тот, кто построит самую высокую стену, а тот, кто создаст самую эффективную и открытую экосистему.
Примерно так все решается: https://share.google/aimode/BxDizcAWSyFicCg1g
Сдавать каждый год, сверять с прошлогодней версией себя?
Разработать ОС на c++ с встроенным сервером для приема/передачи бинарных данных: https://share.google/aimode/EV8rmBHjQ2lh0OIqc Какой бы следующий вопрос задали бы вы? С чего бы начали такую разработку?
20 приложений в день - это интересно, как помогает в этом WebAssembly раскроете?
Нейрослопов немножко: https://share.google/aimode/beykcVQmXDxQSjz3M
Учите C++, пока не поздно: https://share.google/aimode/u3S4N2w2u0aLjuhh3
Кто хочет, делайте, благо разработку на JS сейчас можно делегировать: https://share.google/aimode/qhoay1ijsogKpJYKO
Вопрос: Можно использовать для получения коэффициентов обучение с подкреплением?
Ответ ИИ:
Применение Reinforcement Learning (RL) для настройки ПИД-регуляторов
Обучение с подкреплением отлично подходит для настройки ПИД-регуляторов, особенно в сложных или динамически меняющихся системах. В отличие от классических методов (например, Циглера-Николса), RL делает регулятор адаптивным.
Как это работает:
Агент (нейросеть): Наблюдает за состоянием системы (текущая ошибка, скорость изменения ошибки).
Действие: Агент не управляет исполнительным механизмом напрямую, а динамически корректирует коэффициенты
, 
, 
.
Награда (Reward): Агент получает «бонус» за быстрое достижение цели и «штраф» за перелет (overshoot) или колебания.
Преимущества RL:
Адаптивность: Перенастройка коэффициентов «на лету» при изменении внешних условий (например, изменение веса груза).
Работа с нелинейностью: Эффективность в системах, где математическая модель слишком сложна.
Автоматизация: Алгоритм самостоятельно находит оптимальные параметры через тысячи итераций в симуляции.
Популярные алгоритмы:
Для таких задач чаще всего используют алгоритмы непрерывного действия:
PPO (Proximal Policy Optimization)
DDPG (Deep Deterministic Policy Gradient)
SAC (Soft Actor-Critic)
https://share.google/aimode/ZXI15CJBN9YkBF5c4
Ждем продолжения статьи…
Может быть лучше изучать fastai сначала?: https://share.google/aimode/mujk1zduzGWfiDghG
И еще немножко моих и AI галлюцинаций: https://share.google/aimode/RgAoVgVyoRuPoTYpx
Вопрос: Что можно сделать?
Ответ ИИ:
Практики безопасного использования ИИ в разработке
1. Смена парадигмы: ИИ как стажер
Относитесь к коду от ИИ не как к готовому решению, а как к черновику от junior-разработчика.
Тщательный Code Review: Никогда не пропускайте ИИ-код без построчного анализа.
Проверка граничных случаев: Модели часто «галлюцинируют» в специфических сценариях.
2. Тестирование под давлением
Визуальная чистота кода не гарантирует его эффективность.
Нагрузочное тестирование (Load Testing): Проверяйте алгоритмы на больших объемах данных. ИИ может предложить лаконичный код с плохой сложностью (например,
там, где нужно 
).
Профилирование: Используйте инструменты анализа памяти и CPU.
3. Улучшение промптов (Prompt Engineering)
Контекст — ключ к качеству.
Указывайте ограничения: Добавляйте условия: «код должен быть потокобезопасным», «память ограничена 512 МБ».
Chain-of-Thought: Просите модель сначала описать логику и риски, а только потом писать сам код.
4. Архитектурный контроль
ИИ хорош в локальных функциях, но слаб в понимании всей системы.
Инкапсуляция: Изолируйте ИИ-код в отдельные модули. Его сбой не должен обрушить всё приложение.
Логирование и мониторинг: Добавляйте расширенное логирование в блоки, созданные ИИ.
5. Специализированные инструменты
Используйте автоматику для подстраховки:
Статические анализаторы: Инструменты вроде SonarQube или Snyk находят уязвимости.
Реализация паттерна Repository с использованием рефлексии в C++26:
https://github.com/nomhoi/cosmicpython-fastapi/issues/7
обычная нестроганная доска 60см хорошо работает в качестве когтеточки
Промт: Язык: Rust, Цель: Ипотека, Кот: Пушок.
Нейрослоп:
Пушок сидел на подоконнике и с осуждением смотрел на экран монитора, где бесконечные строки кода сменяли друг друга. Его хозяин в очередной раз сражался с Borrow Checker.
— Потерпи, Пушок, — пробормотал программист, потирая глаза. — Еще пара фич, и мы пройдем по кредитной нагрузке.
Цель была амбициозной: собственная квартира, где у кота будет личный застекленный балкон для наблюдения за птицами. Но пока что жизнь состояла из жестких правил Rust. Каждый раз, когда компилятор выдавал ошибку, Пушок сочувственно мяукал, понимая: «владение» (ownership) — штука сложная не только в программировании, но и в недвижимости.
Прошло полгода. Алгоритмы были отлажены, тесты пройдены, а заветный оффер от банка получен. В день переезда Пушок первым вошел в пустую гостиную. Он важно обошел периметр, проверил качество паркета и, наконец, запрыгнул на широкий подоконник.
Хозяин открыл ноутбук, чтобы написать короткое: println!("Home, sweet home!");. Пушок подошел ближе и наступил лапой на клавишу Enter. Программа скомпилировалась с первого раза. Теперь они оба были полноправными владельцами своего пространства, и никакой банк не мог «заимствовать» их уют без разрешения.
Хотите, чтобы я добавил в историю технические детали реализации проекта или подробнее описал обустройство нового дома для Пушка?