ИИ не будет думать об одной задаче днями, вечерами, неделями, пока однажды перед сном ему эта идея в голову не придет. Ты ему дал задачу, он покрутил, что-то выдал. А человеку ты можешь дать задачу, и он может думать над ней годами и найти решение. Либо не найти. Вот это очень большая разница между человеком и ИИ, которую, мне кажется, еще не все учитывают.
если правильно 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. Программа скомпилировалась с первого раза. Теперь они оба были полноправными владельцами своего пространства, и никакой банк не мог «заимствовать» их уют без разрешения.
Хотите, чтобы я добавил в историю технические детали реализации проекта или подробнее описал обустройство нового дома для Пушка?
Искусственный интеллект сгенерировал рабочий вариант за 4 часа вместо недели работы. Звучит как успех, но когда передали код команде продуктовой разработки, выяснилось: около 60% пришлось переписывать. Нейросеть продублировала методы, которые уже существовали в других частях системы, проигнорировала архитектурные паттерны проекта и запихнула всю логику в один файл на 800 строк.
Вопрос: Почему так случилось, что можно сделать?
Ответ ИИ:
🤖 Почему ИИ подвёл команду (и как это исправить)
Ситуация классическая: ИИ отлично справляется с написанием кода в вакууме, но совершенно не чувствует контекст и архитектуру конкретного проекта. Для него ваша кодовая база — это «черный ящик», если вы не дали к нему доступ.
🚩 Почему это произошло?
Отсутствие контекста: Нейросеть видела только вашу задачу, но не знала о существовании готовых методов в других файлах. Она «изобрела велосипед», потому что не знала, что он уже стоит в гараже.
Проблема «длинного контекста»: ИИ проще выдать результат в одном файле, чем проектировать связи между десятью модулями. Разрезание логики на части требует понимания структуры папок и правил импорта, которые вы, скорее всего, не описывали в промпте.
Отсутствие Linter-ов и правил: ИИ не знаком с вашим стайл-гайдом или архитектурными паттернами (например, SOLID или Clean Architecture), если они не прописаны в системных инструкциях.
🛠 Что можно сделать?
Контекстная подача (RAG для кода): Используйте инструменты вроде Cursor или плагины (например, GitHub Copilot с индексацией репозитория). Они позволяют ИИ «читать» весь проект перед генерацией, что резко снижает дублирование функций.
Метод «Сначала архитектура»: Не просите ИИ сразу писать код. Сначала попросите его составить план реализации: какие файлы создать, какие методы использовать. Команда должна утвердить этот план, и только потом давать команду на генерацию по частям.
Модульные промпты: Разбивайте задачу. Вместо «напиши фичу» говорите: «Используй метод X из файла Y, создай новый класс в папке Z и вынеси бизнес-логику в отдельный сервис».
Спецификации (Rules): Создайте файл .cursorrules или аналогичный, где жестко прописаны правила:
«Не писать файлы длиннее 200 строк»
«Использовать только Dependency Injection»
«Всегда проверять папку /utils на наличие дублей»
Хотите подберем конкретные инструменты или настроим шаблон системного промпта, чтобы ИИ соблюдал ваши архитектурные правила?
если правильно 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. Программа скомпилировалась с первого раза. Теперь они оба были полноправными владельцами своего пространства, и никакой банк не мог «заимствовать» их уют без разрешения.
Хотите, чтобы я добавил в историю технические детали реализации проекта или подробнее описал обустройство нового дома для Пушка?
Вопрос:
Почему так случилось, что можно сделать?
Ответ ИИ:
🤖 Почему ИИ подвёл команду (и как это исправить)
Ситуация классическая: ИИ отлично справляется с написанием кода в вакууме, но совершенно не чувствует контекст и архитектуру конкретного проекта. Для него ваша кодовая база — это «черный ящик», если вы не дали к нему доступ.
🚩 Почему это произошло?
Отсутствие контекста: Нейросеть видела только вашу задачу, но не знала о существовании готовых методов в других файлах. Она «изобрела велосипед», потому что не знала, что он уже стоит в гараже.
Проблема «длинного контекста»: ИИ проще выдать результат в одном файле, чем проектировать связи между десятью модулями. Разрезание логики на части требует понимания структуры папок и правил импорта, которые вы, скорее всего, не описывали в промпте.
Отсутствие Linter-ов и правил: ИИ не знаком с вашим стайл-гайдом или архитектурными паттернами (например, SOLID или Clean Architecture), если они не прописаны в системных инструкциях.
🛠 Что можно сделать?
Контекстная подача (RAG для кода): Используйте инструменты вроде Cursor или плагины (например, GitHub Copilot с индексацией репозитория). Они позволяют ИИ «читать» весь проект перед генерацией, что резко снижает дублирование функций.
Метод «Сначала архитектура»: Не просите ИИ сразу писать код. Сначала попросите его составить план реализации: какие файлы создать, какие методы использовать. Команда должна утвердить этот план, и только потом давать команду на генерацию по частям.
Модульные промпты: Разбивайте задачу. Вместо «напиши фичу» говорите: «Используй метод X из файла Y, создай новый класс в папке Z и вынеси бизнес-логику в отдельный сервис».
Спецификации (Rules): Создайте файл
.cursorrulesили аналогичный, где жестко прописаны правила:«Не писать файлы длиннее 200 строк»
«Использовать только Dependency Injection»
«Всегда проверять папку /utils на наличие дублей»