🤖 Сдвиг дефицита в IT: от кода к верификации

Сдвиг дефицита в IT: от написания кода к его верификации

Ключевые тезисы:

Дефицитный ресурс в IT сместился с умения писать код на умение понимать контекст, архитектуру и проверять сгенерированный код.
ИИ генерирует код быстро и дёшево, но это лишь вероятностные кандидаты на решение, а не готовые решения.
Основная проблема и новое «узкое горлышко» — verification tax (налог на проверку): огромные затраты времени на анализ и интеграцию сгенерированного кода.
Решение — построение архитектурного слоя (Harness) вокруг ИИ-модели, превращающего её в управляемого исполнителя.
Профессия разработчика эволюционирует в AI-инженера, который проектирует системы для автоматической генерации и проверки кода.

Переломный момент: код стал дешёвым

Раньше ценностью было умение переводить бизнес-требования на язык машины (писать код). Теперь это делает ИИ по промту на естественном языке — новый уровень абстракции.

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

Ограничения ИИ-моделей в реальной разработке

Ограниченный контекст: Модель не может «поместить» в контекстное окно всю историю проекта, разрозненные знания, бизнес-правила и нюансы.
Вероятностная природа: Любой ответ модели — лишь вероятный кандидат. Модель может ошибиться в требованиях, архитектуре или выдумать несуществующие решения.
Отсутствие долговременной памяти: Каждая сессия — это «новорождённый» агент, не знающий истории проекта и принятых ранее решений.
Отсутствие инструментов: Базовая LLM — лишь алгоритм работы с текстом. Она не умеет работать с Git, API, базами данных, конфигами и т.д.
Склонность к «срывам»: При выполнении объёмных задач модель может преждевременно завершить работу или проигнорировать часть требований.

Решение: архитектурный слой Harness

Harness — это управляющая инженерная среда вокруг модели, превращающая вероятностный ИИ в повторяемого программного исполнителя.

Составляющие Harness:

Контекст-инженерия и RAG: Система формирования контекста запроса. Цель — подать модели точечно необходимую информацию, а не весь проект. Использует семантический поиск, эмбеддинги, графы зависимостей.
Инструменты и MCP: Дают агенту «руки» для взаимодействия с внешним миром (Git, файловая система, базы данных, API, браузер). MCP — стандартизированный протокол для такого подключения.
Память и состояние: Долгосрочное хранилище для исторических решений, ошибок, специфики проекта. Позволяет новым сессиям агента учитывать прошлый опыт.
Тесты и эвалюация (Evals): Специальные тесты, проверяющие не конечный продукт, а корректность работы самого агента (понимание задачи, вызов нужных инструментов, соблюдение шагов).
Наблюдаемость (Observability): Система трейсинга и логирования для отслеживания работы всех слоёв Harness. Позволяет понять, где произошла ошибка (контекст, модель, инструменты).
Ограничения и подтверждения (Guardrails & Approvals):
- Guardrails — жёсткие ограничения, что агенту нельзя делать (доступ к папкам, переменным).
- Approvals — обязательное подтверждение человеком критических изменений (мерж в прод, миграции) перед их применением.

Преимущество: С грамотно выстроенным Harness одна и та же задача может эффективно выполняться более дешёвыми моделями.

Новая роль: AI-инженер

Это специалист, который проектирует и выстраивает описанную выше инфраструктуру (Harness). Его задачи:

Определять, какой контекст и откуда должна получать модель.
Настраивать инструменты, память и процессы извлечения знаний (RAG).
Конфигурировать циклы работы агента, критерии остановки и привлечения человека.
Настраивать систему тестирования (Evals), наблюдаемости и ограничений (Guardrails).

Это не промпт-инженер, а инженер-архитектор. Ему необходимы глубокие классические компетенции: программирование, понимание архитектуры, БД, DevOps, безопасности. Теперь он создаёт не логику приложения, а среду, в которой модель сама может генерировать эту логику.

Уровни зрелости проекта по отношению к ИИ (Stanford AI Engineering Benchmark)

L0: ИИ не используется.
L1: Оппортунистическое использование промтов.
L2: Систематизированные, версионированные промты.
L3: Разработка на основе переиспользуемых агентов.
L4: Оркестрированные генеративные workflow (несколько агентов под управлением оркестратора).

Выводы

Технология останется: Даже если финансовый пузырь ИИ лопнет, открытые модели и технология генерации кода никуда не денутся.
Инженерия не отменяется, а эволюционирует: Ценность смещается от написания строк кода к проектированию систем, которые могут сами писать, проверять и поддерживать код.
Побеждает не тот, кто генерирует больше кода, а тот, кто научился превращать бизнес-запросы в работающие системы с помощью управляемого ИИ.

Суть перехода: Программист прошлого писал программы. AI-инженер будущего проектирует системы, которые пишут программы под его контролем.