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