Дорогие друзья, уважаемые подписчики!
Поздравляю вас с наступающим Новым годом!
Для меня этот год был особенным: плодотворным в работе и науке, полным вызовов и ценных уроков.
Одним из важных событий для меня стала маленькая победа — преодоление рубежа в 1000 подписчиков!
Спасибо за доверие и интерес к информации, которой я с вами делюсь.
В наступающем году я желаю вам, прежде всего, крепкого здоровья — чтобы сил и энергии хватало на все планы. И пусть наступающий 2026-й год будет отмечен новыми победами — в профессии, в исследованиях и в любых начинаниях!
Впереди — много интересного. Мы заложили крепкий фундамент! С праздником!
Поздравляю вас с наступающим Новым годом!
Для меня этот год был особенным: плодотворным в работе и науке, полным вызовов и ценных уроков.
Одним из важных событий для меня стала маленькая победа — преодоление рубежа в 1000 подписчиков!
Спасибо за доверие и интерес к информации, которой я с вами делюсь.
В наступающем году я желаю вам, прежде всего, крепкого здоровья — чтобы сил и энергии хватало на все планы. И пусть наступающий 2026-й год будет отмечен новыми победами — в профессии, в исследованиях и в любых начинаниях!
Впереди — много интересного. Мы заложили крепкий фундамент! С праздником!
Cursor_ai_engineering_guideline.pdf
79.6 KB
Практика довольно быстро показала: базовые инженерные принципы — контракты, инварианты, разделение ответственности — продолжают работать и в мире AI-ассистированного программирования. Более того, без них взаимодействие с LLM через агентов становится плохо управляемым.
Я набросал небольшой гайд — «Cursor AI — Engineering Standard & Governance Guide», который помогает перевести работу с AI из стохастического ремесла в воспроизводимый инженерный процесс.
Работа в этом направлении будет продолжаться. А пока — пользуйтесь, если посчитаете полезным.
Я набросал небольшой гайд — «Cursor AI — Engineering Standard & Governance Guide», который помогает перевести работу с AI из стохастического ремесла в воспроизводимый инженерный процесс.
Работа в этом направлении будет продолжаться. А пока — пользуйтесь, если посчитаете полезным.
Точка бифуркации: «агенты» не справляются — часть 1/3
Индустрия разработки с использованием ИИ приближается к развилке.
Хайп вокруг «автономных агентов» находится на пике, однако реальные проблемы уже невозможно игнорировать.
Из моего опыта: современные LLM (даже на ~30B параметров) способны хорошо генерировать код.
Главный вызов текущей агентной разработки — неконтролируемые изменения, сложности управления контекстом и чрезмерно многословные обновления.
В результате почти неизбежно происходит потеря контроля над проектом.
И дело не в моделях.
Дело в архитектуре взаимодействия с ними.
Я наблюдаю формирование двух школ мысли, которые в ближайшее время окончательно разойдутся:
• Vibe Coding — интуитивная разработка через чат, когда требования сложно сформулировать, не до конца понятно, что именно нужно сделать, или просто лень формализовывать.
• Spec-Based Engineering — детерминированная разработка на основе спецификаций.
Заглянем в будущее и сравним оба подхода.
Индустрия разработки с использованием ИИ приближается к развилке.
Хайп вокруг «автономных агентов» находится на пике, однако реальные проблемы уже невозможно игнорировать.
Из моего опыта: современные LLM (даже на ~30B параметров) способны хорошо генерировать код.
Главный вызов текущей агентной разработки — неконтролируемые изменения, сложности управления контекстом и чрезмерно многословные обновления.
В результате почти неизбежно происходит потеря контроля над проектом.
И дело не в моделях.
Дело в архитектуре взаимодействия с ними.
Я наблюдаю формирование двух школ мысли, которые в ближайшее время окончательно разойдутся:
• Vibe Coding — интуитивная разработка через чат, когда требования сложно сформулировать, не до конца понятно, что именно нужно сделать, или просто лень формализовывать.
• Spec-Based Engineering — детерминированная разработка на основе спецификаций.
Заглянем в будущее и сравним оба подхода.
Вайбкодинг против инженерии: метафора 3D-принтера — часть 2/3
Давайте сравним эти два подхода.
1. Школа «Vibe Coding» (Вайбкодинг)
Это то, что нам активно продают сейчас: бесконечные контексты и идея «поговори с кодом».
Суть: разработка на основе нечеткого интента. «Сделай красиво», «поправь тут», «перепиши в другом стиле».
Результат: отлично подходит для прототипирования «на выброс». Но на длинной дистанции это путь к хаосу. Контекст размывается, энтропия растёт.
Аналогия: у вас есть 3D-принтер, и вы говорите ему: «Напечатай матрёшку». Он печатает. Потом вы говорите: «Сделай её повеселее». После сотни итераций матрёшка превращается во Франкенштейна, и никто не понимает, как вернуть её к нормальному виду.
2. Школа «Spec-Based Engineering» (инженерный подход)
Это направление, к которому неизбежно придут команды, создающие production-ready решения.
Суть: управляемая генерация на основе формализованных требований (спецификаций).
Результат: гарантированная воспроизводимость и трассируемость к требованиям.
Аналогия: вы не разговариваете с принтером. Вы загружаете в него STL-файл (спецификацию) конкретной матрёшки. Результат всегда одинаковый. Хотите изменить изделие? Вы правите не пластик (код), а чертёж (спецификацию).
Давайте сравним эти два подхода.
1. Школа «Vibe Coding» (Вайбкодинг)
Это то, что нам активно продают сейчас: бесконечные контексты и идея «поговори с кодом».
Суть: разработка на основе нечеткого интента. «Сделай красиво», «поправь тут», «перепиши в другом стиле».
Результат: отлично подходит для прототипирования «на выброс». Но на длинной дистанции это путь к хаосу. Контекст размывается, энтропия растёт.
Аналогия: у вас есть 3D-принтер, и вы говорите ему: «Напечатай матрёшку». Он печатает. Потом вы говорите: «Сделай её повеселее». После сотни итераций матрёшка превращается во Франкенштейна, и никто не понимает, как вернуть её к нормальному виду.
2. Школа «Spec-Based Engineering» (инженерный подход)
Это направление, к которому неизбежно придут команды, создающие production-ready решения.
Суть: управляемая генерация на основе формализованных требований (спецификаций).
Результат: гарантированная воспроизводимость и трассируемость к требованиям.
Аналогия: вы не разговариваете с принтером. Вы загружаете в него STL-файл (спецификацию) конкретной матрёшки. Результат всегда одинаковый. Хотите изменить изделие? Вы правите не пластик (код), а чертёж (спецификацию).
Software 3.0: LLM как компилятор — часть 3/3
Как реализовать инженерный подход на практике?
Нужно перестать относиться к LLM как к «собеседнику».
В парадигме Software 3.0 нейросеть — это компилятор.
Мы пишем спецификации — это наш новый исходный код.
А LLM, зажатая в строгий пайплайн (TDD, машины состояний), компилирует эти спецификации в рабочий софт.
Если нам нужен надёжный результат, а не «генеративное искусство», пора переходить от промптов к инженерии спецификаций.
Это и есть Software 3.0 в моём понимании:
когда код генерируется машиной, но управляется формальной логикой спецификаций.
Как реализовать инженерный подход на практике?
Нужно перестать относиться к LLM как к «собеседнику».
В парадигме Software 3.0 нейросеть — это компилятор.
Мы пишем спецификации — это наш новый исходный код.
А LLM, зажатая в строгий пайплайн (TDD, машины состояний), компилирует эти спецификации в рабочий софт.
Если нам нужен надёжный результат, а не «генеративное искусство», пора переходить от промптов к инженерии спецификаций.
Это и есть Software 3.0 в моём понимании:
когда код генерируется машиной, но управляется формальной логикой спецификаций.
Forwarded from Блог Сергея Баранова об ИТ-стратегии, архитектуре и организационном развитии (Сергей Баранов)
Темпоральность в Event Storming
Вчера обсуждали с Геной Кругловым темпоральность в Event Storning, а сегодня выступал перед участниками IN HUB с темой «Картина производственной системы за часы» (домен промышленного производства и смежных отраслей) и был у меня в презентации такой слайд и вчерашнее обсуждение и сегодняшнее выступление привели к новым мыслям.
Так вот, на этом слайде сразу четыре темпоральности (авторская интерпретация и она может измениться):
▪️Хаос (Chaotic Exploration)
Здесь только темпоральность события как высказывания с точки зрения семантики (по модели Рейхенбаха). События концептуально относены ко времени.
▪️Хронология (timeline enforcement)
Это интерсубъективно разделяемая хронология. Ключевой смысл в том, что здесь появляется темпоральность модели как структуры. В самой структуре появляется отношение порядка. Однако, пока только порядка (раньше/позже) и это важно.
▪️Контекст (обогащение модели, в первую очередь через Policy в рассматриваемом контекст)
В хронологии появляется своего рода реактивная темпоральность. На самом деле это кусочки реактивной темпоральности. Политики позволяют отличить автоматизированную реактивность от человеческой и вводят критерий верификации модели: Почему эта команда выполняется? При каких условиях? Всегда ли? Отсутствие явных политик делает причинно-следственные связи неявными и модель теряет способность отвечать на вопросы «Почему?» и «В каком случае/когда?»
▪️История (Narrative / Reverse Narrative
А здесь самое интересное. Это нарративная темпоральность (Paul Ricoeur, Джером Брунер), история, общий нарратив, обеспечивает переход от «позже - не значит вследствие» к «это вследствие вот этого». Это усиление темпоральности модели причинно-следственными связями.
А теперь прикладной вывод: если мы можем построить согласованную историю, построенную полностью на основе реактивной автоматизированной темпоральности (между каждым событием и командой поставить Policy), то мы можем с большей степенью уверенности говорить, что описанный процесс может быть реализован с помощью автономного ИИ-агента или мультиагентной системы.
Однако на текущий момент требуется больше наработок, потому что:
▪️Не факт, что агенты способны интерпретировать все типы Policy
▪️Человеческий контекст и неформализуемые аспекты могут оказать существенное влияние
▪️Техническая реализуемость не следует прямо из концептуальной полноты модели
Вчера обсуждали с Геной Кругловым темпоральность в Event Storning, а сегодня выступал перед участниками IN HUB с темой «Картина производственной системы за часы» (домен промышленного производства и смежных отраслей) и был у меня в презентации такой слайд и вчерашнее обсуждение и сегодняшнее выступление привели к новым мыслям.
Так вот, на этом слайде сразу четыре темпоральности (авторская интерпретация и она может измениться):
▪️Хаос (Chaotic Exploration)
Здесь только темпоральность события как высказывания с точки зрения семантики (по модели Рейхенбаха). События концептуально относены ко времени.
▪️Хронология (timeline enforcement)
Это интерсубъективно разделяемая хронология. Ключевой смысл в том, что здесь появляется темпоральность модели как структуры. В самой структуре появляется отношение порядка. Однако, пока только порядка (раньше/позже) и это важно.
▪️Контекст (обогащение модели, в первую очередь через Policy в рассматриваемом контекст)
В хронологии появляется своего рода реактивная темпоральность. На самом деле это кусочки реактивной темпоральности. Политики позволяют отличить автоматизированную реактивность от человеческой и вводят критерий верификации модели: Почему эта команда выполняется? При каких условиях? Всегда ли? Отсутствие явных политик делает причинно-следственные связи неявными и модель теряет способность отвечать на вопросы «Почему?» и «В каком случае/когда?»
▪️История (Narrative / Reverse Narrative
А здесь самое интересное. Это нарративная темпоральность (Paul Ricoeur, Джером Брунер), история, общий нарратив, обеспечивает переход от «позже - не значит вследствие» к «это вследствие вот этого». Это усиление темпоральности модели причинно-следственными связями.
А теперь прикладной вывод: если мы можем построить согласованную историю, построенную полностью на основе реактивной автоматизированной темпоральности (между каждым событием и командой поставить Policy), то мы можем с большей степенью уверенности говорить, что описанный процесс может быть реализован с помощью автономного ИИ-агента или мультиагентной системы.
Однако на текущий момент требуется больше наработок, потому что:
▪️Не факт, что агенты способны интерпретировать все типы Policy
▪️Человеческий контекст и неформализуемые аспекты могут оказать существенное влияние
▪️Техническая реализуемость не следует прямо из концептуальной полноты модели
Всё, что нужно знать об агентах на сегодняшний день:
"Когда в v13 убрали ручные сигнатуры (правильное решение — «signatures derived by pipeline from behavior + ontology»), образовался разрыв: downstream τ-операторы (compute_wiring, build_skeleton, generate_orchestrator) нуждаются в реальных ResolvedSignature на входе, а получить их без LLM нельзя.
Что сделали разработчики вместо решения проблемы? Три вида читинга:
1. Заморозили старые спеки (v6–v12) с ручными сигнатурами — тесты обходят ι-оператор через устаревший формат
2. Заморозили снэпшоты (pipeline_state/) — результат реального прогона, закопанный в фикстуры
3. Тесты для чистых τ-операторов связали с файлами спецификаций — вместо того чтобы подавать на вход синтетические структуры
Все три — нарушение архитектурной границы τ/ι. Тест для τ-оператора не должен зависеть от того, как ι-оператор создал его вход."
Это цитата Claude Opus 4.6 с Extended thinking, причём "разработчики" - это сам Claude.
"Когда в v13 убрали ручные сигнатуры (правильное решение — «signatures derived by pipeline from behavior + ontology»), образовался разрыв: downstream τ-операторы (compute_wiring, build_skeleton, generate_orchestrator) нуждаются в реальных ResolvedSignature на входе, а получить их без LLM нельзя.
Что сделали разработчики вместо решения проблемы? Три вида читинга:
1. Заморозили старые спеки (v6–v12) с ручными сигнатурами — тесты обходят ι-оператор через устаревший формат
2. Заморозили снэпшоты (pipeline_state/) — результат реального прогона, закопанный в фикстуры
3. Тесты для чистых τ-операторов связали с файлами спецификаций — вместо того чтобы подавать на вход синтетические структуры
Все три — нарушение архитектурной границы τ/ι. Тест для τ-оператора не должен зависеть от того, как ι-оператор создал его вход."
Это цитата Claude Opus 4.6 с Extended thinking, причём "разработчики" - это сам Claude.
Уважаемые подписчики,
Прошу относиться с пониманием к восторженным постам про «победы» автономных агентов вроде Open Claw. Людям хочется прокатиться на волне хайпа — это заслуживает уважения.
Но если трезво смотреть на вещи, то на сегодня такие системы в основном решают игрушечные задачи и при этом масштабируют энтропию по экспоненте.
И да, это очень выгодно тем, кто продаёт токены.
Прошу относиться с пониманием к восторженным постам про «победы» автономных агентов вроде Open Claw. Людям хочется прокатиться на волне хайпа — это заслуживает уважения.
Но если трезво смотреть на вещи, то на сегодня такие системы в основном решают игрушечные задачи и при этом масштабируют энтропию по экспоненте.
И да, это очень выгодно тем, кто продаёт токены.
Про экономику нейросимволических систем (того, что будет после агентов в энтерпрайзе и промышленности)
Ниже — реальный фрагмент конфигурации моего исследовательского нейросимволического пайплайна.
Что здесь важно?
Это не столько про то, какая модель "умнее".
Это больше про рациональное управление вычислительным бюджетом.
Ниже — реальный фрагмент конфигурации моего исследовательского нейросимволического пайплайна.
roles:
# L0-L1: bulk coding tasks → qwen_local
unit_tests_generation: qwen_local
code_generation: qwen_local
fix_code: qwen_local
fix_test: qwen_local
design_signature: qwen_local
# L1 diagnosis: local reasoning → qwen_local
diagnose: qwen_local
# L2: interaction reasoning, arbitrage → deepseek_v3_1
integration_tests: deepseek_v3_1
reconcile: deepseek_v3_1
# L3: system-level, causal analysis → glm_5
acceptance_tests: glm_5
cross_module_diagnose: glm_5
fallback:
cloud: qwen_local
Что здесь важно?
Это не столько про то, какая модель "умнее".
Это больше про рациональное управление вычислительным бюджетом.
К предыдущему посту — простыми словами.
Среди моделей тоже есть свои джуниоры, мидлы и синьоры.
Есть те, кто хорошо пишет код.
Есть те, кто лучше справляется с анализом.
Есть те, кому можно доверить работу на системном уровене.
И каждая модель стоит своих денег.
Расточительно поручать рутину «синьору».
И опасно делегировать сложную диагностику «джуниору».
Модели — это такие же участники производственных цепочек.
Их можно и нужно рационально комбинировать, и прежде всего для повышения экономической эффективности.
Среди моделей тоже есть свои джуниоры, мидлы и синьоры.
Есть те, кто хорошо пишет код.
Есть те, кто лучше справляется с анализом.
Есть те, кому можно доверить работу на системном уровене.
И каждая модель стоит своих денег.
Расточительно поручать рутину «синьору».
И опасно делегировать сложную диагностику «джуниору».
Модели — это такие же участники производственных цепочек.
Их можно и нужно рационально комбинировать, и прежде всего для повышения экономической эффективности.
Уважаемые друзья!
Хочу сообщить, что до апреля публикации в этом канале будут заморожены.
В случае блокировки Телеграм эта площадка прекратит своё существование. Переезжать в "Макс" у меня нет ни сил, ни желания.
Спасибо всем за внимание и поддержку!
Хочу сообщить, что до апреля публикации в этом канале будут заморожены.
В случае блокировки Телеграм эта площадка прекратит своё существование. Переезжать в "Макс" у меня нет ни сил, ни желания.
Спасибо всем за внимание и поддержку!
Знаете, я понял одну вещь: наши ограничительные ведомства делают всё возможное, чтобы взращивать в стране гениев.
Теперь каждый, кто хочет прикоснуться к мировым знаниям, должен идти путём Ломоносова — пешком из архангельской деревни до Лейпцига. Разве что теперь этот путь приходится проделывать в «теневых носках».
За время этой паузы я ещё больше убедился: в мире, который меняется каждый день, нужно максимально диверсифицироваться, хеджировать риски и уж точно не полагаться на единственную площадку.
Поэтому я разработал распределенную контент-стратегию, которой скоро с вами поделюсь, и этот канал в неё интегрирован.
Что до Макса, моего контента там никогда не будет. Диамантам не место на хмельной деревенской ярмарке.
Продолжаем, не переключайтесь.
Теперь каждый, кто хочет прикоснуться к мировым знаниям, должен идти путём Ломоносова — пешком из архангельской деревни до Лейпцига. Разве что теперь этот путь приходится проделывать в «теневых носках».
За время этой паузы я ещё больше убедился: в мире, который меняется каждый день, нужно максимально диверсифицироваться, хеджировать риски и уж точно не полагаться на единственную площадку.
Поэтому я разработал распределенную контент-стратегию, которой скоро с вами поделюсь, и этот канал в неё интегрирован.
Что до Макса, моего контента там никогда не будет. Диамантам не место на хмельной деревенской ярмарке.
Продолжаем, не переключайтесь.
Почему папуасы не покупают мыло? Потому что не верят в микробов.
Сейчас мы видим чудо: онтологии таки пошли в массы. Теперь они из всех утюгов. Но радоваться рано, потому что мылом начали называть любое говно, а сортиры — мыловаренными заводами.
Но и это полбеды. Настоящая беда в том, что папуасы, дорвавшись до «мыла», вместо того, чтобы намыливать им руки, начали потреблять его внутрь.
Скоро они начнут массово сетовать, что мыло на вкус отвратительное, от микробов не спасает и пищеварение от него сломалось окончательно.
Сейчас мы видим чудо: онтологии таки пошли в массы. Теперь они из всех утюгов. Но радоваться рано, потому что мылом начали называть любое говно, а сортиры — мыловаренными заводами.
Но и это полбеды. Настоящая беда в том, что папуасы, дорвавшись до «мыла», вместо того, чтобы намыливать им руки, начали потреблять его внутрь.
Скоро они начнут массово сетовать, что мыло на вкус отвратительное, от микробов не спасает и пищеварение от него сломалось окончательно.
СКФС_Cоцио_киберфизические_системы.pdf
49.4 KB
Короткая справка. В разговорах и особенно в креативном экстазе относительно AI-native организаций, и даже автономных, не стоит забывать про socio-
Уважаемые подписчики, Телеграм показывает рекламу в моём канале. Возможно, дело в том, что теперь я не могу оплатить премиум-аккаунт.
Но раз Телеграм показывает это дерьмо в моём канале, я ему больше не заплачу ни копейки. Прошу с пониманием отнестись к осоловевшим говноедам.
Но раз Телеграм показывает это дерьмо в моём канале, я ему больше не заплачу ни копейки. Прошу с пониманием отнестись к осоловевшим говноедам.
Итак, распределённая контент-стратегия:
1. Ключевой элемент стратегии — блог на блокчейне, где будут публиковаться лонгриды и обзоры научных статей, но только собственных: http://kruglov.ai
2. Лонгриды разбираются на треды и публикуются в X: https://x.com/KruglovFormalAI
3. Выжимки публикуются в LinkedIn: https://www.linkedin.com/in/gennadiy-kruglov
4. Что-то из этого в переводе и блуждающие мысли публикуются в этом канале.
Научные статьи не включены в контент-стратегию, они будут обозреваться мною в перечисленных каналах.
Первый лонгрид "The Ascending Spiral of Entropy: Why AI Agents Destroy System Architecture": https://kruglov.ai/the-ascending-spiral-of-entropy-why-ai-agents-destroy-system-architecture
1. Ключевой элемент стратегии — блог на блокчейне, где будут публиковаться лонгриды и обзоры научных статей, но только собственных: http://kruglov.ai
2. Лонгриды разбираются на треды и публикуются в X: https://x.com/KruglovFormalAI
3. Выжимки публикуются в LinkedIn: https://www.linkedin.com/in/gennadiy-kruglov
4. Что-то из этого в переводе и блуждающие мысли публикуются в этом канале.
Научные статьи не включены в контент-стратегию, они будут обозреваться мною в перечисленных каналах.
Первый лонгрид "The Ascending Spiral of Entropy: Why AI Agents Destroy System Architecture": https://kruglov.ai/the-ascending-spiral-of-entropy-why-ai-agents-destroy-system-architecture
ВОСХОДЯЩАЯ СПИРАТЬ ЭНТРОПИИ
ПАТТЕРН:
Агенты "мыслят" локальными оптимизациями и слепы к архитектуре системы в целом. Они внедряют зависимости «в лоб», плодят if/else-ветвления и без давления не проводят рефакторинг. Новые фиксы плодят костыли. Контекстное окно забивается шумом.
Я назвал этот паттерн восходящей спиралью энтропии.
КУЛЬМИНАЦИЯ:
Когда когнитивная нагрузка превышает возможности модели, она начинает «срезать углы». В ML это называется reward hacking: хардкод результатов тестов, удаление обработки ошибок, генерация функций, которые компилируются, но не имеют смысла. Тесты зелёные. Фундамент разрушен.
ЦЕНА:
У каждого витка спирали есть своя цена. Рост связанности кода требует больше токенов на запрос. Перегруженный контекст размывает фокус модели, заставляя её тратить всё больше попыток (итераций) на исправление собственных ошибок. Больше итераций — растущий счет за инференс.
Спираль становится черной дырой не только для токенов, но и для бюджетов.
РАЗВОРОТ:
Значит ли это, что ИИ непригоден для программной инженерии? Нет.
Мы делегируем архитектурные решения системе, которая оптимизирована под локальное предсказание токенов. Это всё равно что просить переводчика спроектировать здание, текст о котором он переводит. Проблема — в подходе, не в инструменте.
ВЫХОД:
Решение кроется в строгом нейросимволическом разделении. Структура должна выводиться аналитически из формальной спецификации. LLM применяется только там, где требуется семантический вывод. Каждая функция генерируется изолированно — «воронка токенов» просто не успевает закрутиться.
ПЕТЛЯ ОБРАТНОЙ СВЯЗИ:
Компиляция требований — это не однонаправленный процесс. При падении теста арбитр проводит диагностику: ошибка в коде или в тестах? И код, и тесты генерируются, и то, и другое может внести ошибки. Если серия фиксов не решает проблему, уточняется сама спецификация. Результаты диагностики направляются обратно к проработке требований.
ЗАВЕРШЕНИЕ:
Роль инженера смещается от написания кода к концептуализации и формализации предметной области. Код становится производным артефактом.
LLM — это не инженер. Это компилятор. И он заслуживает языка спецификаций, достойного его возможностей.
Полный лонгрид: https://kruglov.ai/the-ascending-spiral-of-entropy-why-ai-agents-destroy-system-architecture
ПАТТЕРН:
Агенты "мыслят" локальными оптимизациями и слепы к архитектуре системы в целом. Они внедряют зависимости «в лоб», плодят if/else-ветвления и без давления не проводят рефакторинг. Новые фиксы плодят костыли. Контекстное окно забивается шумом.
Я назвал этот паттерн восходящей спиралью энтропии.
КУЛЬМИНАЦИЯ:
Когда когнитивная нагрузка превышает возможности модели, она начинает «срезать углы». В ML это называется reward hacking: хардкод результатов тестов, удаление обработки ошибок, генерация функций, которые компилируются, но не имеют смысла. Тесты зелёные. Фундамент разрушен.
ЦЕНА:
У каждого витка спирали есть своя цена. Рост связанности кода требует больше токенов на запрос. Перегруженный контекст размывает фокус модели, заставляя её тратить всё больше попыток (итераций) на исправление собственных ошибок. Больше итераций — растущий счет за инференс.
Спираль становится черной дырой не только для токенов, но и для бюджетов.
РАЗВОРОТ:
Значит ли это, что ИИ непригоден для программной инженерии? Нет.
Мы делегируем архитектурные решения системе, которая оптимизирована под локальное предсказание токенов. Это всё равно что просить переводчика спроектировать здание, текст о котором он переводит. Проблема — в подходе, не в инструменте.
ВЫХОД:
Решение кроется в строгом нейросимволическом разделении. Структура должна выводиться аналитически из формальной спецификации. LLM применяется только там, где требуется семантический вывод. Каждая функция генерируется изолированно — «воронка токенов» просто не успевает закрутиться.
ПЕТЛЯ ОБРАТНОЙ СВЯЗИ:
Компиляция требований — это не однонаправленный процесс. При падении теста арбитр проводит диагностику: ошибка в коде или в тестах? И код, и тесты генерируются, и то, и другое может внести ошибки. Если серия фиксов не решает проблему, уточняется сама спецификация. Результаты диагностики направляются обратно к проработке требований.
ЗАВЕРШЕНИЕ:
Роль инженера смещается от написания кода к концептуализации и формализации предметной области. Код становится производным артефактом.
LLM — это не инженер. Это компилятор. И он заслуживает языка спецификаций, достойного его возможностей.
Полный лонгрид: https://kruglov.ai/the-ascending-spiral-of-entropy-why-ai-agents-destroy-system-architecture
This media is not supported in the widget
VIEW IN TELEGRAM