Скрытый хардкод в ИИ-автоматизации

Коротко для руководителя. За эффектной ИИ-автоматизацией часто стоит хрупкий хардкод: зашитые правила, длинные промпт-цепочки, подогнанные под конкретные примеры. Это будущая стоимость изменений, которую видно на аудите, а не на демонстрации. Для бизнеса важно одно: система, которую дорого менять, перестаёт давать эффект ровно тогда, когда процесс меняется, — то есть всегда.

«Смотрите, ИИ сам всё делает» на демо часто означает «мы зашили все нужные случаи в промпты и правила». Это работает на показанных примерах и ломается на новых. Назовём это скрытым хардкодом: автоматизация выглядит интеллектуальной, а держится на жёстко подогнанной логике.

Гипотеза: за «магией ИИ» часто стоит подгонка под примеры

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

Проблема: хрупкость и стоимость изменений

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

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

Почему обычные подходы не работают

«Допишем ещё правило под этот случай» не масштабируется: число частных правил растёт быстрее, чем покрытие, а взаимодействие правил становится неотлаживаемым.

«Удлиним промпт, добавим примеров» превращает промпт в нечитаемую конфигурацию без версий и тестов — тот же хардкод, только в тексте.

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

Инженерная модель: контракты, конфигурация, тестируемость

Контракты вместо подгонки. Поведение задаётся типизированными входами и выходами с явной обработкой «не уверен», а не набором частных «если» в промпте.

Конфигурация вместо зашитого. То, что меняется (правила маршрутизации, пороги, форматы), выносится в конфигурацию с версиями — а не живёт внутри промпта или кода.

Тестируемость. Есть набор кейсов (включая исключения), на которых система прогоняется при каждом изменении. Регрессия видна до прода, а не по жалобе.

Разделение модели и логики. Логика, ветвления, работа с данными — это инженерные слои; модель вызывается там, где нужна, а не «решает всё промптом». Это же снижает и стоимость токенов.

Наблюдаемость решений. Видно, почему система приняла решение, — иначе хардкод невозможно даже найти.

Практический вывод для бизнеса

Хрупкость — это будущий счёт, и его видно на аудите. Перед масштабированием спросите: что произойдёт при новом типе входа, которого не было на демо; где правила — в конфигурации, а где зашиты; есть ли тесты на исключениях. Уклончивые ответы — это и есть скрытый хардкод.

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

Оценивайте стоимость изменения, а не только запуска. Система, которую дорого менять, не переживёт первого же изменения процесса — а процессы меняются всегда.

Приложить это к вашим процессам — обсудить с инженером → .

Открытые вопросы

Где граница между разумной конфигурацией и чрезмерной гибкостью — компромисс, решаемый под процесс. Сколько тестовых кейсов достаточно — зависит от цены ошибки. Как быстро обнаруживать «подгонку под примеры» на аудите чужой системы — мы смотрим на поведение вне показанных случаев, но зрелого стандарта нет.

Если вам показали впечатляющее демо — стоит проверить поведение на том, что в демо не входило. Обсудить аудит → — посмотрим, где система обобщает, а где подогнана.