Купил чайник — и обнаружил, что у него нет шкалы уровня воды. — 3 сентября 2026 г. в 11:58:35.013
Купил чайник — и обнаружил, что у него нет шкалы уровня воды. Той самой прозрачной штуки сбоку, которая позволяет сразу понять, сколько воды внутри. Интересно, в какой момент инженеры решили, что эта функция больше не нужна? И как теперь определять уровень — каждый раз открывать крышку и заглядывать внутрь? Забавно, но сейчас в разработке ПО происходит нечто похожее. Раньше главной задачей разработчика было не потерять знания о системе: зафиксировать архитектурные решения, описать правила, передать контекст коллегам. Мы документировали не только то, как устроен продукт, но и то, как с ним правильно работать. С появлением ИИ этого уже недостаточно. Теперь после каждой выполненной задачи важно смотреть не только на результат, но и на систему, которая этот результат произвела. Допустим, я ставлю ИИ задачу и получаю решение с ошибками. Самый очевидный путь — открыть код и всё исправить вручную. Но если делать так каждый раз, никакого реального ускорения не произойдет. Я просто превращусь в редактора очень быстрого, но не всегда внимательного исполнителя. Поэтому мой главный вопрос теперь звучит иначе: «Что нужно изменить в обвязке, чтобы в следующий раз ИИ справился лучше сам?» Может быть, уточнить инструкции. Добавить пример. Зафиксировать архитектурное ограничение. Настроить проверку. Дать модели доступ к нужному контексту. Изменить сам процесс постановки и приемки задачи. То есть исправлять нужно не только конкретный результат — нужно перенастраивать станок, который этот результат производит. Каждая ошибка становится обратной связью для надсистемы. Каждая ручная правка — повод спросить себя: можно ли превратить её в правило, тест, инструкцию или автоматическую проверку? Именно здесь разработчик переходит на уровень выше. Он уже не просто пишет код. Он проектирует среду, в которой код создается: собирает контекст, формулирует ограничения, настраивает инструменты и строит контур обратной связи. Можно назвать эту роль ИИ-архитектором. Можно — инженером производственной системы. Название пока не так важно. Важен сам сдвиг: единицей улучшения становится не очередной фрагмент кода, а весь процесс его создания. Если остаться в прежней парадигме и продолжать молча исправлять всё руками, ускорения не будет. Более того, мы начнем регулярно терять полезные функции, знания и ограничения — просто потому, что они нигде не закреплены. И продолжим производить чайники без шкалы уровня воды.