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