На днях провел эксперимент с LLM.
Занимался реализацией задачи в проекте, где генерировать код LLM-кой запрещено. Сам проект абсолютно не готов для работы с ИИ, хотя глобально там есть общие универсальные скиллы по тестам, качеству кода, архитектуре и т.д. Они общие, но индивидуального контекста под проект нет.
Суть эксперимента была в том, что я со своими знаниями и экспертностью попробую дать на вход максимум контекста и в итоге оценю результат.
Контекст я готовил половину рабочего дня: делал референсы из ТЗ, собирал контекст из переписок, саммари из созвонов. Было подготовлено много артефактов.
Дальше я запустил генерацию и через 30 минут получил готовый код: покрытый тестами, полностью рабочий. Если отправить его в прод, никто даже не заметит подвоха. QA отчитается, что все кейсы выполнены и все гуд.
Но код LLM-кой писать запрещено, значит, прежде чем отправлять его на ревью, мне нужно было поревьювить его самому.
Что в итоге? Как вы думаете?
Я полностью его переписал. Начиная от структуры таблиц и заканчивая кодом.
Это был рабочий мусор.
Думаете, вывод такой: «ха-ха, LLM делает мусор»?
Нет.
Эксперимент на самом деле завершился так, как я и предполагал. ИИ — это просто инструмент. Качественный контекст по задаче даст рабочее решение, но он не выполнит все ваши внутренние соглашения сам по себе.
А вот чтобы все было так, как вы хотите, хотя бы приближенно, нужно потратить кучу времени на подготовку проекта к работе с LLM: выстроить harness, дать примеры того, как нужно писать, и постоянно их поддерживать.
Причем это нужно внедрять не только на уровне разработки. Аналитики тоже должны сразу готовить контекст по задаче в едином стиле, желательно в кооперации с LLM, чтобы на вход уже попадал нормальный сформированный инпут, а не набор разрозненных сообщений, созвонов и догадок.
То есть задача должна приходить не в формате «ну там в переписке все есть», а в виде готового артефакта: что делаем, зачем, какие ограничения, какие кейсы, какие спорные места, какие примеры, какие связи с текущей системой.
А дополнительную информацию модель уже должна получать через внутренний MCP: документацию, схемы, соглашения, примеры кода, контракты, историю решений и все остальное, что нужно для нормального погружения в проект.
В моей ситуации нужно было бы вложить очень много времени именно в подготовку контекста по кодовой части. И этот процесс был бы бесконечным: столкнулись с непредсказуемым поведением — дополняем инструкции, улучшаем слой валидации, добавляем новые проверки.
Все это невозможно без смены мышления у всей команды.
Каждый должен держать систему в тонусе, чтобы через какое-то время получить буст и постоянно его наращивать.
Разработчикам в найме заниматься этим в свободное время, скорее всего, не особо захочется. А бизнес в большинстве случаев вряд ли выделит под это отдельные ресурсы.
Пока как-то так.
P.s. Манифест "AI Native - Новая культура мышления" уже доступен -
https://ai-native.cutcode.dev
ОД 
