Про типичные проблемы 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, подписывайтесь!
На этой неделе я упомянул несколько проблем 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
Лайк, репост,
