Купил чайник — и обнаружил, что у него нет шкалы уровня воды

3 сентября 2026 г.

Той самой прозрачной штуки сбоку, которая позволяет сразу понять, сколько воды внутри. Интересно, в какой момент инженеры решили, что эта функция больше не нужна? И как теперь определять уровень — каждый раз открывать крышку и заглядывать внутрь?

Забавно, но сейчас в разработке ПО происходит нечто похожее.

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

С появлением ИИ этого уже недостаточно.

Теперь после каждой выполненной задачи важно смотреть не только на результат, но и на систему, которая этот результат произвела.

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

Поэтому мой главный вопрос теперь звучит иначе:

«Что нужно изменить в обвязке, чтобы в следующий раз ИИ справился лучше сам?»

Может быть, уточнить инструкции. Добавить пример. Зафиксировать архитектурное ограничение. Настроить проверку. Дать модели доступ к нужному контексту. Изменить сам процесс постановки и приемки задачи.

То есть исправлять нужно не только конкретный результат — нужно перенастраивать станок, который этот результат производит.

Каждая ошибка становится обратной связью для надсистемы. Каждая ручная правка — повод спросить себя: можно ли превратить её в правило, тест, инструкцию или автоматическую проверку?

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

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

Если остаться в прежней парадигме и продолжать молча исправлять всё руками, ускорения не будет. Более того, мы начнем регулярно терять полезные функции, знания и ограничения — просто потому, что они нигде не закреплены.

И продолжим производить чайники без шкалы уровня воды.

Комментариев нет:

Отправить комментарий