Блеск и нищета AI разработки.
Мне легко понять эйфорию менеджеров по поводу AI. Без разработчиков, в диалоге с AI можно создать работающее приложение. Только за токены плати. Ну да, конечно, надо выбрать workflow для разработки, evals настроить, контекст проекта. И, вуаля, роботы работают, отдыхает человек)
И сроки ускоряются.
Но ещё я использую AI для реальной разработки. Сделал свой workflow из двух фреймворков - OpenSpec и Superpowers. Написал свои evals скилы под каждый проект и универсальные. Настроил контексты - проектные и глобальный. Провожу ревью создаваемых спецификаций, смотрю код периодически. Разработка идёт конечно же быстрее. Но при этом я чётко понимаю, что качество кода ниже, чем если бы я его писал полностью руками.
Почему так?
Если свести все причины в одну, то может сформулировать так - очень сложно построить полноценный контекст проекта.
Сильная модель с 100% настроенными правилами работы в проекте с большой вероятностью написала бы код, близкий к моему. Но есть нюанс - 80+% правил находится в головах разработчиков. Некоторые из них разработчики не осознают как правила работы в проекте) И это как раз становится заметно, когда модель делает что-то не так. Конечно, чем больше работаешь над проектом с ИИ - тем больше эти правила будут формализаться. Но это не дни, скорее месяцы. К правилам относятся и ADR - когда-то принятые в проекте решения, которых надо придерживаться. И архитектурные и инфраструктурные требования компании. И многое другое.
Можно на эту проблему посмотреть с другой стороны. Воспомним количество принимаемых во время разработки решений.
Это могут быть десятки на простой фиче. При разработке с ИИ очевидно часть этих решений будет принимать агент. Иначе человек будет блокером в процессе. А чтобы агент принял правильное решение - под каждый кейс должно быть настроено правило. Рецепт если хотите. Если рецепта нет - модель примет решение сама. Может хорошее, а может увеличивающее техдолг и превращающее сервис в legacy.
Очевидно, что при разработке с ИИ не техническим специалистом эффект может нарастать лавинообразно.
Вывод - на данном этапе развития разработки с ИИ мы
1) либо жертвуем скоростью работы и тогда возникает вопрос - зачем нам вообще ИИ
2) либо что более вероятно - жертвуем качеством кода. И хорошо если сервис маленький - тогда его можно просто переписать. Или прототип - тут конечно ИИ идеален.А если нет?
Может возникнуть вопрос - не забыл ли я про третью переменную - деньги?
И да, и нет.
Дорогая модель не гарантирует качественный код. Хотя может его улучшить, особенно при применении на этапе проектирования.
Речь про выбор точек на трех осях - качество, скорость, деньги. А harness - его нужно постоянно настраивать.
#ai
Мне легко понять эйфорию менеджеров по поводу AI. Без разработчиков, в диалоге с AI можно создать работающее приложение. Только за токены плати. Ну да, конечно, надо выбрать workflow для разработки, evals настроить, контекст проекта. И, вуаля, роботы работают, отдыхает человек)
И сроки ускоряются.
Но ещё я использую AI для реальной разработки. Сделал свой workflow из двух фреймворков - OpenSpec и Superpowers. Написал свои evals скилы под каждый проект и универсальные. Настроил контексты - проектные и глобальный. Провожу ревью создаваемых спецификаций, смотрю код периодически. Разработка идёт конечно же быстрее. Но при этом я чётко понимаю, что качество кода ниже, чем если бы я его писал полностью руками.
Почему так?
Если свести все причины в одну, то может сформулировать так - очень сложно построить полноценный контекст проекта.
Сильная модель с 100% настроенными правилами работы в проекте с большой вероятностью написала бы код, близкий к моему. Но есть нюанс - 80+% правил находится в головах разработчиков. Некоторые из них разработчики не осознают как правила работы в проекте) И это как раз становится заметно, когда модель делает что-то не так. Конечно, чем больше работаешь над проектом с ИИ - тем больше эти правила будут формализаться. Но это не дни, скорее месяцы. К правилам относятся и ADR - когда-то принятые в проекте решения, которых надо придерживаться. И архитектурные и инфраструктурные требования компании. И многое другое.
Можно на эту проблему посмотреть с другой стороны. Воспомним количество принимаемых во время разработки решений.
Это могут быть десятки на простой фиче. При разработке с ИИ очевидно часть этих решений будет принимать агент. Иначе человек будет блокером в процессе. А чтобы агент принял правильное решение - под каждый кейс должно быть настроено правило. Рецепт если хотите. Если рецепта нет - модель примет решение сама. Может хорошее, а может увеличивающее техдолг и превращающее сервис в legacy.
Очевидно, что при разработке с ИИ не техническим специалистом эффект может нарастать лавинообразно.
Вывод - на данном этапе развития разработки с ИИ мы
1) либо жертвуем скоростью работы и тогда возникает вопрос - зачем нам вообще ИИ
2) либо что более вероятно - жертвуем качеством кода. И хорошо если сервис маленький - тогда его можно просто переписать. Или прототип - тут конечно ИИ идеален.А если нет?
Может возникнуть вопрос - не забыл ли я про третью переменную - деньги?
И да, и нет.
Дорогая модель не гарантирует качественный код. Хотя может его улучшить, особенно при применении на этапе проектирования.
Речь про выбор точек на трех осях - качество, скорость, деньги. А harness - его нужно постоянно настраивать.
#ai