Comments 12
Получается ты или проверяешь и вникаешь в код ИИ или сам продумываешь реализацию, а ИИ лишь помогает реализовать. Как будто сам подход неправильный сложился у общества, что ИИ это замена, в то время когда это лишь еще один инструмент.
Есть такое...
Но вы же понимаете, что люди ищут простых путей.
Пишут: хочу чтобы мне написали готовый проект с нуля по одному моему желанию...
При этом тут все как в жизни. Без четкого ТЗ, результат ХЗ) Он и с четким ТЗ все равно ХЗ, но без него совсем плохо.
Проблема в том, что мало “проверять и понимать код ИИ”, нужно знать “а какие были альтернативные варианты” и “почему был выбран именно этот вариант”.
Тут даже “сам продумываешь реализацию, а ИИ лишь помогает реализовать” не поможет - подводные камни встречается в реализации даже относительно простых вещей.
На мой взгляд, статья бестолковая. Попробую объяснить почему.
С моей точки зрения, процесс ИИ-разработки выглядит следующим образом:
Перед реализацией фичи как правило нужно попросить ИИ написать план, что и как оно собирается реализовывать, проревьюить этот план, а потом уже подтверждать его реализацию. Борис из Антропика как раз недавно говорил что он ревьюит только планы, а в саму окончательную реализацию практически не заглядывает, т.к. там проблем практически не бывает.
После реализации фичи нужно в этом же сеансе сказать ИИ что бы оно актуализировало файл claude.md. (или если не хочется его раздувать, то тогда наверно актуализировать какую-то отдельную базу знаний с описаниями функционала и его реализации)
Соответственно, было бы интересно почитать что в итоге получается у людей которые действуют по этой схеме. А если "разработчики" режимом/шагом планирования не пользуются, базу знаний продукта не актуализируют, то очевидно они заранее обречены в итоге вляпаться в полное гуано. Про таких можно бесконечно статьи писать как у них все плохо.
Напомнило анекдот:
Ночь, темно. Горит фонарь. Под фонарем на четвереньках ползает подвыпивший мужчина и что-то ищет. Прохожий спрашивает у него «Что потерял? – Ключи. - Здесь? - Нет, там, в стороне. - А чего же здесь ищешь? - Так здесь светло…»
Ревью планов - практически единственное, что может сделать человек с адекватными трудозатратами и с сохранением высокой скорости разработки. Но это не потому что “этого достаточно”, а потому что “иначе будет больно”.
Я пользуюсь такой методикой. Если фича или фикс не тривиальный, то всегда прошу план. План просматриваю сам и еще прошу просмотреть поан агента оркестратора (иногда он находит то, что я пропустил). После реализации агент должен предьявить доказательства, что он все действительно реализовал по плану (бывают разные). Если фича затоагивает логику работы, то третий этап это документирование изменений. Такие фичи всегда оформляются в beads как эпик. В комите фиксируется id задачи. Если решений несколько, то прошу реализовать вне кода оба решения и протестировать качественные метрики - я называю это экспериментом и это отдельная задача. Потом реализация наиболее удачного решения с планом, реализацией, документированием.
Ожидание: нейронка пишет код по требованиям, освобождая программиста от шлёпанья по клавишам.
Реальность: надо не только шлёпать по клавишам, но ещё и проверять бредни искусственного идиота на завихрения, которые в долгой перспективе больно стукнут по заднице.
Пока с моего дивана видно, что эта штука пока хорошо работает в фантазиях топ-менеджеров, а на деле безопасно можно использовать только в роли генератора прототипов, чтобы самому все типовые обвязки не писать.
Ну или может на небольших проектах, где можно охватить весь код и не поехать крышей от взаимосвязей в нём. 😁
Как-то так.
Надо было быстро сделать прототип парсинга строки на SQL . Подключил ИИ, без плана, строка ведь маленькая, но оказалась удаленькая, с пропусками, совпадениями и еще множеством тонкостей. В конечном итоге после полдня общения строка была готова. Начал тестировать, еще полдня ушло на правки конечного запроса. Особо не вникал в код так как прототип. В результате пришлось разбираться в коде, так как на реальных данных начали возникать проблемы. Код запроса сильно переусложнен ( тут сам виноват, не просил отсекать заведомо ненужные комбинации). Сейчас упростил логику парсинга в самом начале, стало намного проще править код SQL. Резюме: даже на прототипе небольшой задачи нельзя пускать код на самотек. Всегда нужно ревьюировать самому и с концептуальной точни зрения для упрощения результирующего кода. Сам бы тоже сделал, без ИИ, но решил поэксперементировать.
Долг понимания — скрытая цена кода, сгенерированного искусственным интеллектом