TGViewer
(java || kotlin) && devOps (java || kotlin) && devOps @javakotlindevops · 341 subscribers
Post #643 75
Блеск и нищета AI разработки.

Мне легко понять эйфорию менеджеров по поводу AI. Без разработчиков, в диалоге с AI можно создать работающее приложение. Только за токены плати. Ну да, конечно, надо выбрать workflow для разработки, evals настроить, контекст проекта. И, вуаля, роботы работают, отдыхает человек)
И сроки ускоряются.

Но ещё я использую AI для реальной разработки. Сделал свой workflow из двух фреймворков - OpenSpec и Superpowers. Написал свои evals скилы под каждый проект и универсальные. Настроил контексты - проектные и глобальный. Провожу ревью создаваемых спецификаций, смотрю код периодически. Разработка идёт конечно же быстрее. Но при этом я чётко понимаю, что качество кода ниже, чем если бы я его писал полностью руками.

Почему так?

Если свести все причины в одну, то может сформулировать так - очень сложно построить полноценный контекст проекта.

Сильная модель с 100% настроенными правилами работы в проекте с большой вероятностью написала бы код, близкий к моему. Но есть нюанс - 80+% правил находится в головах разработчиков. Некоторые из них разработчики не осознают как правила работы в проекте) И это как раз становится заметно, когда модель делает что-то не так. Конечно, чем больше работаешь над проектом с ИИ - тем больше эти правила будут формализаться. Но это не дни, скорее месяцы. К правилам относятся и ADR - когда-то принятые в проекте решения, которых надо придерживаться. И архитектурные и инфраструктурные требования компании. И многое другое.

Можно на эту проблему посмотреть с другой стороны. Воспомним количество принимаемых во время разработки решений.
Это могут быть десятки на простой фиче. При разработке с ИИ очевидно часть этих решений будет принимать агент. Иначе человек будет блокером в процессе. А чтобы агент принял правильное решение - под каждый кейс должно быть настроено правило. Рецепт если хотите. Если рецепта нет - модель примет решение сама. Может хорошее, а может увеличивающее техдолг и превращающее сервис в legacy.

Очевидно, что при разработке с ИИ не техническим специалистом эффект может нарастать лавинообразно.

Вывод - на данном этапе развития разработки с ИИ мы
1) либо жертвуем скоростью работы и тогда возникает вопрос - зачем нам вообще ИИ
2) либо что более вероятно - жертвуем качеством кода. И хорошо если сервис маленький - тогда его можно просто переписать. Или прототип - тут конечно ИИ идеален.А если нет?

Может возникнуть вопрос - не забыл ли я про третью переменную - деньги?
И да, и нет.
Дорогая модель не гарантирует качественный код. Хотя может его улучшить, особенно при применении на этапе проектирования.

Речь про выбор точек на трех осях - качество, скорость, деньги. А harness - его нужно постоянно настраивать.

#ai
  • 👍 6
More from @javakotlindevops
  1. Sep 29, 2026Ещё про небезопасный AI) Задача - запустить трафик в k8s с Istio через egress для 2 интегр…
  2. Sep 21, 2026Забавный факт, цитата: AI context windows have grown from 512 tokens in 2017 to 2,000,000…
  3. Sep 15, 2026Сколько стоит AI агент? Для кого-то - бесплатно. Платит работодатель. Кому-то хватает мини…
  4. Sep 11, 2026Post #640
  5. Sep 4, 2026PostgreSQL наносит ответный удар) Я думаю все слышали про NoSQL, предлагающие альтернативн…
  6. Aug 31, 2026Еще один пост о вреде Boolean флагов) Почему еще один - я за последние пару лет точно виде…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →