Как переписывание промта повысило эффективность GPT-5-mini на 22%

Мы представляем результаты тестирования модели GPT-5-mini в рамках бенчмарка Tau², предназначенного для оценки языковых моделей. Оказалось, что простое переписывание промта повысило успешность небольшой модели более чем на 20%.

Тестирование LLM с Tau²

На летнем обновлении OpenAI заявили, что GPT-5 значительно улучшила агентские задачи. Для проверки использовали бенчмарк Tau², симулирующий реальные взаимодействия в телекоме, ритейле и авиалиниях. Однако улучшения GPT-5 были заметны только в телекоме, поэтому мы сосредоточились на этой области.

GPT-5-mini предлагает преимущества: вдвое меньше задержка, выше пропускная способность и в пять раз дешевле при 85–95% производительности полной GPT-5. Мы провели эксперимент, чтобы оценить, насколько хорошо GPT-5-mini справляется с бенчмарком и можно ли улучшить её результаты, изменяя политики агентов или описания задач.

Базовые результаты: 45% провалов

Мы запустили подмножество из 20 тестовых сценариев телекома. Результаты показали успешность всего 55%. GPT-5-mini с её ограниченными возможностями reasoning не приблизилась к флагманской GPT-5.

Бенчмарк также ввёл метрику pass^k, измеряющую надёжность агента при k попытках выполнения задачи, и выделил задачи, с которыми агент не справляется совсем.

Решение: переписывание промтов с помощью Claude

Мы поставили три цели: повысить общую успешность, "разблокировать" больше задач и улучшить надёжность агента. Используя генеративный ИИ, мы поручили Claude проанализировать политики агентов в телекоме и переписать их для упрощения понимания моделью GPT-5-mini.

Ключевые улучшения включали:

• Чёткие деревья решений и последовательные шаги
• Ясные условия и обработку ошибок
• Снижение когнитивной нагрузки через таблицы и шаблоны
• Действенные команды вместо описаний

После переписывания промтов успешность GPT-5-mini выросла до 77%, что на 22% выше исходного показателя. Это демонстрирует, что тонкая настройка промтов может значительно повысить эффективность небольших моделей без изменения их архитектуры.

• Оптимизация структуры промптов (деревья решений, нумерованные шаги, проверки зависимостей) значительно улучшает работу ИИ-агентов.
• Использование Claude для перезаписи промпта повысило эффективность GPT-5-mini в телеком-бенчмарке, но методология вызывает вопросы о возможной утечке данных.
• Подход перезаписи промптов затратен по времени и ресурсам, не универсален для разных доменов и может нивелировать преимущества небольших моделей.
• Сообщество выражает скептицизм относительно долгосрочной стабильности и воспроизводимости результатов, полученных с помощью подобных техник.
• Многие отмечают, что описанные практики уже представлены в более продвинутых фреймворках, таких как DSPy.
• Обсуждается этический аспект: оптимизация промпта под конкретный бенчмарк может искажать оценку истинных агентских способностей модели.
• Отсутствие исходных промптов и деталей перезаписи затрудняет независимую верификацию и воспроизведение результатов.

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

Такой прогресс открывает перспективы широкого использования инструментов вроде Lean без необходимости глубоких экспертных знаний, что может ускорить верификацию критических систем, криптографии и компиляторов. Практический совет: попробуйте сами инструменты вроде Claude Code или Gemini CLI на знакомых задачах — это обойдётся примерно в $20–100 в месяц.

• Участники обсуждают потенциал LLM (особенно Claude Code) в генерации формальных доказательств и кода с использованием инструментов вроде Lean, отмечая, что ИИ часто успешно справляется с первой частью задачи, но испытывает трудности с завершающими, самыми сложными этапами.
• Подчеркивается фундаментальная проблема: сложность не в написании кода, а в создании точных и корректных спецификаций и требований, что является ключевым для формальной верификации и доказательства правильности программ.
• Высказывается мнение, что сочетание генеративных ML-моделей с формальными методами — многообещающий путь вперед, так как LLM снижают усилия на реализацию, а формальные методы — на проверку, компенсируя слабые стороны друг друга.
• Обсуждаются практические сложности: необходимость жесткого контроля за выводом ИИ, риск получения ложных доказательств, которые лишь выглядят корректно, и важность эмпирической валидации результатов, сгенерированных ИИ.
• Отмечается, что архитектурные решения и изменяющиеся требования часто делают формальные доказательства непрактичными для большинства реальных проектов, где код не статичен, а правильное абстрагирование и разделение ответственности важнее тотальной корректности.

Генерация процедурных островов (часть III)

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

Карта высот (повтор)

Исходная карта высот из части I задаёт базовое распределение суши и воды:

Для визуализации используется палитра magma из matplotlib с искусственным затемнением океанских областей. Карта семплируется по центроидам треугольников Делоне.

Многоуровневые шумовые слои

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

Используется шесть слоёв с частотами: 1x, 2x, 4x, 16x, 32x, 64x. Отсутствует слой 8x (n₃).

Усиление прибрежного шума

Применяем высокочастотный шум specifically вдоль береговой линии:

\[e_{coast} = e + \alpha \cdot (1 - e^4) \cdot \left(n_4 + \frac{n_5}{2} + \frac{n_6}{4}\right)\]

Множитель \((1 - e^4)\) создает колоколообразную кривую, пикующуюся на береговой линии (e=0).

Поле расстояний до гор

Для горных пиков предварительно вычисляем поле расстояний через топологию триангуляции Делоне с использованием BFS:

1. Начинаем от треугольников с горными точками (расстояние = 0)
2. Посещаем соседние треугольники, увеличивая расстояние на рандомизированную величину
3. Рандомизация создает естественные формы вместо идеальных конусов

Формула приращения расстояния: \[\Delta = s \cdot (1 + j \cdot r)\] где r использует треугольное распределение для естественного вида.

Порядок обработки соседей случайно перемешивается алгоритмом Фишера-Йейтса для избежания направленных смещений.

Смешивание высот

Финальная высота комбинирует все компоненты через взвешенное смешивание.

• Автор выбрал подход на основе графа (Voronoi) и сетки (mesh), а не шума или фракталов, для большей структурной целостности и контроля над формами рельефа.
• Основная критика существующих методов (шум, фракталы) — их недостаточный реализм и неестественность, поскольку они не моделируют геологические процессы.
• Уникальность подхода в статье — комбинация Voronoi-диаграмм с добавлением шума к расстояниям и последующим моделированием эрозии.
• Обсуждается ценность альтернативных, телеологических (основанных на моделировании процессов) методов: тектоники, эрозии, климата для достижения максимального реализма.
• Отмечается, что физически-обусловленное моделирование — это сложно и вычислительно дорого, но используется в высокоточных профессиональных инструментах.
• Упомянуто разделение алгоритмов на онтогенетические (создающие конечную форму) и телеологические (симулирующие процесс формирования).
• Подчёркивается, что выбор метода отражает то, как автор концептуализирует процесс генерации, а не подход, основанный на данных.

Приложение Apple Photos иногда повреждает изображения при импорте с камеры. Я хотел поделиться этим, так как другие пользователи тоже сталкивались с проблемой, но большинство сдались, не разобравшись так глубоко, как я.

Я снимаю на камеру OM System OM-1 в формате RAW + JPEG и раньше использовал опцию «Удалить после импорта», чтобы очистить карту памяти. Это оказалось ошибкой. Проблема стала очевидной после съёмки на свадьбе: около 30% фотографий были безвозвратно испорчены — иногда JPEG, иногда RAW, иногда оба файла.

Чтобы исключить аппаратные причины, я последовательно менял всё оборудование: кабели, карту памяти, перешёл только на RAW, купил новый ноутбук и даже новую камеру OM-1 MKII. Но проблема не исчезла. Позже я обнаружил, что файлы на карте были целыми до импорта, а corruption происходил случайным образом в самом приложении Photos.

Сравнение повреждённого и исходного файлов показало одинаковый размер, но разные контрольные суммы:

md5sum P7110136-from-camera.ORF Exports/P7110136.ORF 
17ce895fd809a43bad1fe8832c811848  P7110136-from-camera.ORF
828a33005f6b71aea16d9c2f2991a997  Exports/P7110136.ORF

Теперь я отказался от автоматического удаления и вручную проверяю все фото после импорта, прежде чем форматировать карту. Это трудоёмко, но надёжно. Возможно, проблема связана с конкретными камерами OM System, но я не планирую дальше её исследовать.

• Обнаружена редкая ошибка в Apple Photos, приводящая к недетерминированному повреждению файлов при импорте, вероятно, из-за проблем с параллелизмом в конвейере обработки.
• Пользователи сообщают о различных случаях коррупции изображений: от зеленых пикселей до полной порчи файлов и потери целых архивов, в том числе в iCloud.
• Многие критикуют рабочий процесс с автоматическим удалением файлов после импорта и рекомендуют всегда сохранять оригиналы на картах памяти или делать резервные копии перед импортом.
• В качестве альтернативы предлагается использовать другие инструменты для импорта (например, Image Capture, Digikam, Olympus Workspace) или полностью отказаться от экосистемных решений в пользу локального хранения и самохостинга.
• Высказывается общая обеспокоенность снижением качества программного обеспечения Apple и недостаточным вниманием к тестированию и сохранности данных пользователей.
• Некоторые пользователи предполагают, что проблема может быть связана с конкретными камерами (OM System) или SD-картами, а не только с ПО Apple.
• Рекомендуется документировать версии ПО с ошибкой и избегать хранения критически важных данных исключительно в проприетарных системах без независимых бэкапов.

Определение пятого значения функции занятого бобра

Авторы: Коллаборация bbchallenge (Джастин Бланшар и др.)

Аннотация: Мы доказываем, что $S(5) = 47,176,870$ с использованием системы проверки доказательств Coq. Значение занятого бобра $S(n)$ — максимальное число шагов, которое машина Тьюринга с $n$ состояниями и 2 символами может выполнить с нулевой ленты до остановки. Функция $S$ была введена Тибором Радо в 1962 году как один из простейших примеров невычислимой функции. Доказательство включает перебор $181,385,789$ машин Тьюринга с 5 состояниями и определение для каждой из них, останавливается ли она. Наш результат — первое определение нового значения занятого бобра за более чем 40 лет и первое формально верифицированное значение, что демонстрирует эффективность массовых онлайн-исследований (bbchallenge$.$org).

Комментарии: 48 страниц, 17 рисунков

Предметные области: Логика в информатике (cs.LO); Формальные языки и теория автоматов (cs.FL); Логика (math.LO)

Цитирование: arXiv:2509.12337 [cs.LO]

• Результат BB(5) был подтверждён с использованием комбинации исчерпывающего перебора и продвинутых методов анализа (десидеров) для проверки остановки машин Тьюринга.
• Процесс проверки был значительно оптимизирован: большинство машин было отсеяно на ранних этапах, и лишь 183 машины потребовали глубокого моделирования (до 47 млн шагов).
• Исследование является крупным collaborative-проектом с открытым исходным кодом, аналогичным другим сообществам, изучающим клеточные автоматы и гугологию.
• Значение BB(5) само по себе не имеет прямого практического применения и считается чисто академическим достижением, однако разработанные методы могут быть полезны для статического анализа программ и решения проблем остановки.
• Некоторые машины Тьюринга, включая кандидата для BB(6), выполняют вычисления, аналогичные последовательности Коллатца, что представляет отдельный математический интерес.
• Проверка доказательства с помощью Coq требует нескольких часов на обычном компьютере, что несопоставимо с вычислительными затратами на его получение.
• Для машин с большим числом состояний (начиная с BB(6)) прямое вычисление значения считается невозможным из-за его колоссального размера и неразрешимости проблемы остановки в общем случае.

Утечка IPv6 в PureVPN

В конце августа 2025 года я отправил два отчёта о безопасности в PureVPN. Через три недели ответа не последовало, поэтому публикую результаты для информирования пользователей.

Проблемы затрагивают как GUI (v2.10.0), так и CLI (v2.0.1) клиенты на Linux (тестировалось на Ubuntu 24.04.3 LTS). Вот что обнаружено.

1. Утечка IPv6

После переподключения Wi-Fi или возобновления работы из спящего режима клиент PureVPN не восстанавливает защиту IPv6:

• CLI: Клиент автоматически переподключается и сообщает о статусе "подключено", но система получает маршрут IPv6 через Router Advertisements. Egress-трафик идёт вне туннеля.
• GUI: При обнаружении отключения GUI блокирует IPv4, но IPv6 остаётся рабочим до явного переподключения.

Результат: можно использовать IPv6-сайты и почту с реальным IPv6-адресом провайдера, хотя клиент утверждает о защите.

2. Сброс файрвола

При подключении PureVPN сбрасывает конфигурацию iptables пользователя:

• INPUT устанавливается в ACCEPT
• Все правила -A сбрасываются (включая UFW, Docker)
• После отключения изменения не восстанавливаются

Результат: система остаётся более уязвимой после использования VPN, чем до него. Это противоречит ожиданиям пользователя.

Пример:

# Базовая защита
$ sudo iptables -P INPUT DROP
$ sudo iptables -I INPUT -p icmp -j DROP

# После подключения VPN
$ sudo iptables -S | head -3
-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
# Правила удалены

Итог

PureVPN:

• Неправильно реализует kill-switch для IPv6
• Оставляет IPv6 открытым после переподключений
• Сбрасывает состояние файрвола и не восстанавливает его
• Применяет политики ACCEPT для работоспособности

Обе проблемы имеют практическое влияние. Заявления о конфиденциальности подрываются, когда реальный IPv6 утекает, а состояние файрвола теряется.

Полные технические отчёты отправлены на security@purevpn.com. Ответа нет. Используйте с осторожностью.

• Автор поста благодарит за обсуждение и согласен с рисками использования проприетарных VPN-клиентов, отмечая полезность сетевых пространств (network namespaces) для изоляции трафика.
• Многие участники критикуют VPN-провайдеров за плохую реализацию поддержки IPv6, выделяя Mullvad как исключение, но и ему предъявляют претензии.
• Несколько комментаторов настоятельно не рекомендуют использовать PureVPN из-за доказанных в суде случаев логирования трафика, вопреки их заявлениям.
• Высказываются серьёзные сомнения в надёжности закрытого исходного кода клиентов и серверов VPN, предлагается использовать решения с открытым кодом и изоляцией трафика (например, через Vopono или Gluetun).
• Участники обсуждают ненадёжность популярных провайдеров (NordVPN, ExpressVPN) из-за агрессивного маркетинга, моделей ценообразования и возможных связей с определёнными юрисдикциями.
• Предлагаются технические решения для предотвращения утечек: отключение IPv6, использование kill-switch и настройка сетевых пространств через systemd-nspawn или другие инструменты.
• Отмечается, что основная функция VPN — подключение к удалённой сети, а конфиденциальность и безопасность являются вторичными и зависят от доверия к провайдеру.

Борьба против Chat Control: "Позиция Германии вернулась к статусу НЕОПРЕДЕЛЕННОСТЬ..."

Для использования веб-приложения Mastodon необходимо включить JavaScript. Также можно воспользоваться нативными приложениями для вашей платформы.

• Исключение для государственных аккаунтов ставит под сомнение заявления о безопасности и точности системы, указывая на вероятность ложных срабатываний.
• Предложение воспринимается как антидемократичное и нелегитимное, подрывающее доверие к ЕС и ведущее к росту поддержки крайних политических сил.
• Реализация подобного контроля технически неfeasible, так как злоумышленники могут легко обойти его с помощью альтернативных зашифрованных каналов.
• Критики проводят параллели с историей тотальной слежки (Стази, Третий рейх) и предупреждают о создании дистопического инструмента массового наблюдения.
• Обсуждение выявляет циничный мотив лоббирования со стороны компаний-поставщиков surveillance-решений (Thorn, Palantir) и заинтересованных госструктур (Europol).
• Исключение для политиков трактуется как способ избежать бумажного следа и подотчетности, а безопасность служит лишь прикрытием.
• Многие пользователи выражают готовность полностью отказаться от сервисов, которые подчинятся таким требованиям, и поддерживают принцип сквозного шифрования.

О нет, снова... Размышления об атаках на цепочку поставок NPM

Я долго откладывал эту статью — более года — но, как мы видим на этой неделе, пришло время снять покровы и сказать вслух:

В 2025 году Microsoft следует считать «плохим игроком» и угрозой для всех компаний, разрабатывающих программное обеспечение.

Конечно, если вы достаточно взрослые, чтобы помнить — это не первый раз...

Время — плоский круг

Мы снова здесь — в 2025 году Microsoft настолько всё испортили, что создали ещё больший риск, чем в 2000-х с их браузером, просто ничего не делая.

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

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

Опять же... это ничего нового в мире NPM.

Но так быть не должно было...

Мы прошли долгий путь, но никуда не ушли

У меня долгая история с NodeJS — примерно в 2010 году я начал работать над стартапом, и это было до того, как npm вообще появился.

В туманные дни 1990-х большинство проблем безопасности JavaScript не сильно касались бэкенда: это в основном была область Perl, PHP, Python и Java.

Однако веб был совсем другой историей.

В самые ранние дни Всемирной паутины был только один основной браузер, который все использовали: Netscape Navigator. Выпущенный в 1994 году, он был не просто браузером: на протяжении своей жизни он имел различные воплощения встроенного почтового клиента, календаря, HTML-редактора с FTP-браузером, а с плагинами мог воспроизводить медиафайлы, такие как Realplayer и MP3 (что я помню при его запуске), а также флеш-фильмы и игры. Именно здесь родился JavaScript.

Многие ранние сайты того времени были статичными — популярные инструменты для создания сайтов включали HotDog или Блокнот. Никаких навороченных IDE или фреймворков, только текстовый редактор, браузер и alert() для отладки.

Microsoft также вошла в игру с Internet Explorer — включённым в раннее DLC для Windows под названием «Plus! For Windows 95». В конечном итоге он стал программным обеспечением, на которое Microsoft поставила всю свою корпоративную стратегию (во многом как сегодня с ИИ).

Internet Explorer был встроен в каждый аспект Windows — сначала в 1995 году с Active Desktop, что продолжалось вплоть до Windows XP. С ним можно было встраивать фрейм на рабочий стол, а также документы Rich Text или электронные таблицы Excel. Он также был раздутым и багнутым — и с этим представлял две проблемы: огромный риск безопасности и обвинения в монополизации рынка браузеров.

Закон жёстко настиг Microsoft, и в 2001 году она проиграла — Microsoft было приказано разбить компанию, но апелляция отменила это решение.

• Участники критикуют экосистему npm за уязвимости в цепочке поставок и отсутствие безопасности по умолчанию, сравнивая её с другими менеджерами пакетов.
• Обсуждается роль крупных компаний (в частности, Microsoft как владельца npm) в решении проблем безопасности и их ответственность за состояние экосистемы.
• Предлагаются конкретные меры: обязательная 2FA, подписывание кода, политика задержки обновлений (cooldown), переход на альтернативы (pnpm), сканирование пакетов.
• Поднимается проблема эксплуатации труда добровольцев в open-source и недостаточного вклада коммерческих организаций в проекты, которые они используют.
• Отмечается, что культура JavaScript-разработки чрезмерно зависит от большого количества зависимостей, что увеличивает поверхность атаки.
• Указывается на необходимость более строгого контроля зависимостей, включая проверку кода и фиксирование версий (pinning).
• Некоторые участники считают, что фундаментальные изменения в экосистеме маловероятны, и рекомендуют индивидуальные меры защиты.

Алибаба представила новый ИИ-чип с характеристиками, сопоставимыми с H20.

• Китай запретил закупки чипов NVIDIA и стимулирует развитие собственных AI-чипов, чтобы сократить технологический разрыв
• Китайские чипы (например, от Alibaba) пока уступают флагманским GPU NVIDIA (Blackwell, H100) и сравнимы с более старыми моделями (A100, H20)
• Ключевым барьером NVIDIA считается не столько hardware, сколько программная экосистема (CUDA), создающая сильную привязку клиентов
• Экспортные ограничения США вынуждают Китай развивать собственное производство, но возникают проблемы с качеством, совместимостью и производительностью
• Вопросы вызывают возможности Китая в передовой литографии (EUV) без доступа к оборудованию ASML
• Часть комментаторов расценивает новости как пропаганду или считает, что успехи Китая основаны на краже IP и господдержке без оглядки на прибыль
• Сокращение доступа к NVIDIA может замедлить развитие AI в Китае, но также стимулирует глобальную конкуренцию и снижение цен на GPU

Почему мы создаём Stategraph: состояние Terraform как проблема распределённых систем

Экосистема Terraform десятилетиями обходила фундаментальное архитектурное проблему: использование файловой семантики для решения задач распределённых систем. Результат предсказуем и болезнен.

При масштабировании автоматизации инфраструктуры мы обнаружили, что управление состоянием в Terraform демонстрирует классические симптомы несоответствия между представлением данных и шаблонами доступа. Команды создают сложные обходные решения: разделение файлов состояния, оркестрация обёрток, внешние механизмы блокировок. Это не решения, а доказательство, что мы решаем не ту проблему.

Stategraph подходит к состоянию как к тому, чем оно является на самом деле: направленному ациклическому графу ресурсов с семантикой частичных обновлений, а не монолитному документу.

Патология файлового состояния

Состояние Terraform — это проблема координации. Множество акторов (инженеры, CI-системы) должны одновременно читать и изменять перекрывающиеся подмножества состояния инфраструктуры. Вместо решений с тонкими блокировками и управлением параллелизмом Terraform использует глобальный мьютекс для JSON-файла.

Наблюдение: Вероятность конфликта блокировок растёт сверхлинейно с увеличением команды и количества ресурсов.

Несоответствие гранулярности:

• Текущая модель: чтение 100%, блокировка 100%, изменение 0.5%
• Фактическая потребность: чтение 3%, блокировка 3%, изменение 3%

Разделение файлов состояния не решает проблему, а перераспределяет её, добавляя сложность управления зависимостями между состояниями.

Состояние как граф: естественное представление

Состояние инфраструктуры по своей природе является направленным графом. Ресурсы имеют зависимости, образующие рёбра. Изменения распространяются по этим рёбрам. Terraform внутренне представляет состояние как граф, но на уровне хранения уплощает эту структуру в blob.

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

• Изоляция подграфов: операции над несвязанными подграфами параллелизуемы
• Точные блокировки: блокировка на уровне ресурсов и зависимостей
• Инкрементальное обновление: вычисление минимального набора изменений через обход графа

Управление параллелизмом через правильные абстракции

Stategraph реализует проверенные паттерны распределённых систем:

• MVCC для неблокирующего чтения
• Write-ahead logging для сохранности данных
• Уровни изоляции транзакций

Традиционный подход:

Acquiring global lock… waiting

Stategraph:

Locking subgraph (3 resources)… ready

Каждая операция блокирует только свой подграф. Менеджер блокировок использует граф зависимостей для предотвращения взаимных блокировок. Читатели получают согласованные снимки без блокировки писателей.

Результат: значительное улучшение пропускной способности при параллельной работе. Три команды могут одновременно применять изменения к независимым ресурсам.

• Предлагается заменить файловую систему Terraform на графовую базу данных для улучшения масштабируемости и устранения глобальных блокировок.
• Текущий файл состояния Terraform ценится за простоту и предсказуемость, но становится узким местом при работе с тысячами ресурсов и большими командами.
• Ключевая проблема — разделение состояния (splitting state) создаёт новые сложности, такие как зависимости между состояниями и необходимость оркестрации.
• Новое решение должно обеспечивать детализированное блокирование ресурсов, а не глобальную блокировку, и предоставлять возможности для запросов и отчётности.
• Обсуждаются вопросы управления доступом (RBAC) и миграции существующих крупных setup'ов в новую модель.
• Подход сравнивается с другими инструментами (Pulumi, Crossplane, Terraform Cloud), но фокус — на оптимизации именно модели Terraform/OpenTofu.
• Мнения разделены: одни видят в этом фундаментальный сдвиг, другие считают, что проблема вызвана антипаттернами в организации инфраструктуры.