Комментарии 23
... С появлением ИИ мы как-то резко стали забывать, что между работает и можно людям показать - огромная разница. Работает - это 10%. До людям показать можно ещё девять раз по столько же и эти девять раз ещё и длиннее самих себя.
Люди как-то поверили, будто бы можно сразу написать хорошо. Нет. Нельзя.
Сначала вы объясняете агенту ТЗ. Это занимает час. Потом ИИ пишет код, который сразу работает. Это занимает 10 минут. Вам не нравится. Вы говорите, что гипотеза не удалась, всё удаляете и пишите ещё раз. Это занимает ещё 10 минут. Теперь вам нравится.
И вот тут вы садитесь и вместе с ИИ следующую неделю перекладываете архитектуру, пока не станет действительно хорошо. Так это работает.
Представьте команду разработки, которая внедрила ИИ-генерацию кода. Первые недели — эйфория. Velocity вырос на 40%. Задачи закрываются быстро, бизнес доволен, менеджеры смотрят на дашборд и улыбаются.
ИИ код без ревью и в прод, улыбающийся менеджмент, явно планирующие брать новые горизонты.
я представил и у меня задёргался глаз.
Не потому что сложно, а потому что непонятно вообще, что там происходит.
Как правило боты делают очень качественную (не дословную) документацию в коде. Просите объяснять вплоть до каждой строки, максимально подробно. Обычно этого более чем достаточно.
А ещё будет очень хорошо продумать ему способы сохранения решений в долговременной памяти хотя бы по кодовой базе, чтобы начиная новый диалог не писать агенту всё с 0
Вот только понятность каждой строки не всегда означает, что:
код понятен в целом
код делает то, что хочет заказчик
в коде нет багов
не зря же есть выражение "за деревьями леса не видно"
https://github.com/Ldiga174/AIL-Assistant-Instruction-Layer
Я себе написал вот такую структуру управления проектом. Там ведётся лог успешных реализаций, ошибок , память проекта , ход ведения проекта , успешные реализации выделяются как можно использовать. Думаю с этим проще решить вашу проблему .
Расскажу как это делаю я.
1. Этап проектирования. Я обсуждаю с ИИ что мне нужно, мы разбиваем проект на логичные части. Описываем каждую часть, если в какой-то части получается слишком много, разбиваем еще мельче. В результате должен появится очень подробный план, каждая часть которого легко реализуема и может быть протестирована отдельно.
2. Этап программирования. Начитаю с первой части проекта, проверяю работоспособность и чистоту кода, чтобы все было просто и понятно, с комментариями. Работает первая часть, приступаю ко второй. Тот код, что пишет ИИ, переношу в проект руками, слежу чтобы ничего из работающего кода не пропало и не было переписано.
Да, это не быстро. Да, это непросто. Да, разработчик должен быть программистом и хорошо знать что он делает. Зато код хорошо задокументирован, понятен и гарантированно работает.
Это рассказ про разработку первой версии приложения.
А основной вопрос в данной статье - о развитии и последующих версиях.
Как Вы делаете следующую версию? В которой что-то надо расширишь, что-то сделать по-другому, обеспечив совместимость и миграцию с предыдущего решения...
Когда изначальный код понятен, то что-то расширить или переделать не трудно. Совершенно аналогичным образом - проектирование, написание кода, ручной перенос в проект.
То есть Вы расширяете или переделываете модуль, расширяя или переделывая его описание для ИИ. То описание, которое было создано для предыдущей версии.
А потом ИИ разрабатывает новый код на основе этого описания опять с нуля?!
Ну почему с нуля, код где нужно внести изменения так же прилагается к промпту. Нет смысла передавать весь код, но где вносятся изменения, это сделать необходимо. После этого собственно новый код сравнивается со старым и, если все нормально, вносятся необходимые изменения. Если изменений много, то это тоже делается не сразу все, а по частям.
Если ИИ пишет код не с нуля, то ему надо рассказать не только то, как должно быть, но и то, чем отличается переданный ему кусок кода от того, что нужно сделать.
И надо позаботиться не только о том, чтобы изменения кода соответствовали новой версии описания, но ещё и продумать переход от старого к новому.
То есть второй шаг, о котором мы сейчас с Вами говорим - это далеко не то же самое, что повторение первого шага :-)
Я описал общий случай, Вы полезли в детали. Детали зависят от конкретной задачи, но в любом случае не вижу смысла в указанных Вами действиях.
Спасибо, понял. Подход, который я описал - это классика, которую десятилетиями продвигают компании, разрабатывающие инструменты разработки (автоматической генерации...) на основе концептуальных описаний...
Обычные разработчики никаких концептуальных описаний/моделей не поддерживают, а просто "пишут код" :-)
Проблема, которую описывает автор статьи, в том, что в данном случае написанный код непонятен человеку. И при отсутствии высокоуровневого описания, понятного человеку, остаётся полагаться на способности ИИ... и выбрасывать сделанное им, если он справиться не может?!
Интересно, спасибо за статью.
Пожалуй, я попробую начать активно использовать ИИ похожим образом:
Мы пришли к третьему варианту с элементами первого. ИИ помогает нам разбираться в документации и думать над сложными кейсами.
Да, ИИ определённо хорош в качестве "продвинутого поиска" ответов на вопросы (вариантов решений) как внутри кодовой базы, так и в Сети, в том числе, в документации.
Очевидно, полезность ИИ падает с увеличением размера кода, составляющего разрабатываемую Систему, плюс, до некоторой степени, - кода (АПИ) интегрируемых с нашей Системой других систем... Но если он сможет быть более полезен, чем полнотекстовый поиск - уже хорошо.
Интересно упоминание MCP-серверов и необходимости искать ответы по свежей информации, а не только по тому, чему ИИ мог научиться раньше.
Техдолг появляется, когда команда гонится за результатом и не вкладывает время в то, чтобы сделать нормальное решение. Всё понятно, все виноватые известны.
С ИИ-долгом история формально та же: торопимся, выпускаем, не думаем. Только виноватый другой. Точнее — его нет
Есть. Тот же, что в первом абзаце. Менеджер. Лицо, принимающее решение о выпуске такого кода в продакшен. Не надо прятаться за абстрактной "командой".
У каждого коммита есть имя и должность. И обычно это не ИИ. Тот кто использует средства разработки сам отвечает за результат. То есть - виноватые всё те же.
Интересно, слово legacy так же будет пугать, когда первый раз столкнётесь? 🤔
ИИ написал. Никто не понимает. Трогать страшно