Содержание
Коротко
На Dev.to предлагают заменить классическую «инженерию инструкций модели» на инженерию постановки задачи: формальное описание проблемы до генерации кода. Провалы в проде почти никогда не из‑за «модель недостаточно умна» — из‑за дыр в спецификации. Рамка из пяти слоёв: инварианты системы, контракты данных, мутации состояния, топология отказов и точки наблюдаемости.
Что произошло
Автор показывает типичный сценарий 2026 года: в модель льют сотни строк репозитория и наследие трюков («думай по шагам», «ты ведущий инженер»). На выходе — синтаксически идеальный TypeScript, зелёный билд… и через дни в проде исчерпан пул Redis, гонки и двойные списания. Модель не «не умела кодить» — ей дали неинженерную задачу.
Контраст на промежуточном слое идемпотентности для платежей: размытая инструкция даёт гонку «проверил — потом записал» и вечный кэш без срока жизни; полная спецификация (ключ Redis, атомарный SET NX, статусы PROCESSING/COMPLETED, контрольная сумма тела, открытый отказ при таймауте) превращает модель в «компилятор синтаксиса» с устойчивым кодом с первого прохода.
Почему это важно
Длинный контекст и рассуждение во время ответа не спасают от двусмысленности. Пока границы не зафиксированы, модель заполняет дыры статистическим путём наименьшего сопротивления — уровнем учебного туториала без гонок и деградации. Для продакшена навык сеньора — не «говорить с ИИ», а ограничивать пространство поиска.
На практике
- Перед генерацией пройдите контрольный список: инварианты, схемы входа/выхода, атомарность, поведение при таймауте зависимостей, телеметрия.
- Пишите контракты данных явно (типы, допустимость
null, формат) — не «как модель сама догадается». - Для денег и побочных эффектов требуйте идемпотентность и контрольную сумму полезной нагрузки.
- Задайте «открытый» или «закрытый» отказ до кода, а не после первого инцидента.
- Вложите ожидания журналов и трасс в техническое задание: иначе «рабочий» код слеп в проде.
Итог
Трюки инструкций были мостом для хрупких моделей. Зрелые движки рассуждений выигрывают от жёсткой архитектуры задачи. Сначала инженерия проблемы — потом генерация.