TGViewer
Тимур Хахалев про AI Coding Тимур Хахалев про AI Coding @the_ai_architect · 9.23K subscribers
Post #415 4.76K
Про типичные проблемы AI Coding

На этой неделе я упомянул несколько проблем AI Coding, которые, как мне казалось, уже решены (как минимум подписчиками моего канала), но судя по комментам - нет. Спасибо вам, что подсветили.

Как и обещал, я сел разбирать проблемы, но понял, что я пока не понимаю, какие из них приоритетнее. А может быть какие-то я вообще пропустил?

Так вот, я создал опросник для такого случая.

Пройти опрос

Пожалуйста, пройдите опрос и помогите мне понять о каких проблемах мне стоит писать и разбирать их.

А пока, я решил разобрать парочку проблем, за которые я зацепился в комментах к прошлому посту.

1) Неконтролируемый техдолг – AI позволяет генерировать код быстрее, чем команда успевает его осмысливать. То, что раньше занимало 100 инженеров 5 лет, теперь 5 инженеров делают за 6 месяцев — но это legacy-код сразу.

2) Команда теряет знание проекта – при 99% AI-generated changes команда коллективно теряет понимание кодовой базы. Любая проблема, с которой AI не справляется, занимает значительно дольше — работают как с чужим кодом.

Давайте для начала разберёмся, как вообще у разработчиков и команд появляется знание о проекте?

Очень просто – человек, обычно, знает код, который пишет сам. Если он его сам не пишет, но ему нужно его понять, то необходимо погружаться в этот код и тратить немногим меньше времени, чем если бы он сам его писал.

В умных книжках это называется ownership проекта.

Что происходит сейчас?

Люди, привыкшие к чувству ownership, пытаются угнаться за AI и вычитывать весь код, который генерится.

С непривычки начинает появляться сильная усталость и к концу дня голова становится ватной.

Одни продолжают насиловать свой мозг и пытаться поспеть за AI, а другие забивают болт и доверяют AI и не читают ничего.

И вот в чём проблема заключается.

Большинство разработчиков не делают работу тех. менеджмента (техлиды), что логично.
И при вайбкодинге они не делают планирование задачи или делают это недостаточно хорошо.

Если перед написанием кода определить, что именно мы делаем, зачем, почему, какие у нас критерии приёмки и как именно мы их будем проверять, то после того, как агент напишет код, нам не придётся читать все строки, что он написал.

Да, примерно с осени 2025 года llm доросли достаточно для того чтобы писать код очень хорошо по предоставленному ТЗ.

Как только вы получили готовый PR от агента, ваша задача заключается в том, чтобы определить и проверить критичные места, которые были затронуты – data model, db миграции, биллинг и прочее.

Тут ещё помогает оценка и понимание в деньгах, сколько будет стоить ошибка в каждой из частей системы.

Почему это работает?

Потому что на этапе планирования:
- вы уже определили архитектуру и скелет вашего решения, по которому будет написан код
- вы уже определили, какие тесты будут написаны

Что может пойти не так?

Конечно, не так может пойти много чего :) на этапе планирования нельзя на 100% закрыть все пограничные кейсы, где-то что-нибудь сломается. Но и на этапе чтения кода вы не найдёте все эти кейсы.

У вас упадёт прод?

Да, как и до внедрения AI Coding. Если у вас нет отлаженных процессов мониторинга, алертинга, восстановления продакшена, то это проблема не AI Coding, а ваших процессов.

Что ещё можно внедрить для обработки техдолга?

Мне нравится подход с ревью проекта по крону.
Суть – вы настраиваете skill, в котором описываете, что агент должен изучить задачи (по git) за последнюю неделю, срастить их с тасками в jira и найти различные code smells и прочую фигню, которую можно оптимизировать. Насоздавать issues и либо самому их закрыть, либо вызвонить человека.

1. Ставите codex на vps и настраиваете обычный cron, который запускается раз в неделю и в промпте указываете этот skill.

2. Готово, у вас есть работяга, который будет находить проблемы в вашем репозитории и уменьшать техдолг.

Да, на начальном этапе вам необходимо будет самому раз в недельку ходить по репозиторию (с агентами в т. ч.) и обогощать skill различными инструкциями как должно быть и как быть не должно.

Вывод

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

Не забудьте пройти опрос и рассказать про ваши актуальные проблемы с AI Coding

Лайк, репост,
Тимур Хахалев про AI Coding, подписывайтесь!
  • 🔥 18
  • ❤ 11
  • 👍 11
  • 😁 1
More from @the_ai_architect
  1. Sep 21, 2026Зачем SDLC нужен рядовому разработчику? Проблема того, что немногие знают SDLC, в том, что…
  2. Sep 19, 2026AI Agentic SDLC Roadmap Я уже рассказал зачем нужен agentic SDLC, как он может выглядеть и…
  3. Sep 16, 2026Post #432
  4. Sep 13, 2026Meeting Summary В конце поста попрошу у вас предложить хороший open source meeting summary…
  5. Sep 11, 2026К концу рабочего дня у вас появляется ощущение что вы ничего серьёзного не сделали за день…
  6. Sep 11, 2026В чем залог успеха при работе с ai агентами? ответ на фото – это feedback loop. Нарочно не…
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 →