Не секрет, что про написание кода AI-агентами в автономном режиме (я буду пользоваться термином vibe coding, хотя он не вполне точен) сейчас прям нам вещают из каждого динамика.
С другой стороны, я довольно много использую AI для написания кода, и мои ощущения - «иногда работает неплохо, но надо проверять и высок риск, что в код пролезет какая-то дичь». Т.е. это сильно расходится с историями из интернета. Я внезапно смог четко сформулировать для себя, почему так и когда это работает, а когда нет.
Есть два типа программистов. Первые усиленно пользуются отладчиком, пишут и запускают 100500 тестов и все равно их код часто сбоит, когда что-то идет не по happy path сценарию. Вторые думают, идут гулять с собакой, возвращаются и пишут в разы меньше кода, который работает намного надежнее. На самом деле я, конечно же, идеализирую, и все мы находимся между типом 1 и типом 2, просто кто-то чуть ближе к одному, а кто-то к другому полюсу.
Но в чем принципиальная разница между этими типами? У типа 1 есть какое-то, часто очень локальное предположение о том, как должен работать код, он действует по принципу monkey see, monkey do. Второй пытается построить в голове модель того модуля, который он реализует, и дальше уже, имея модель, овеществляет ее в коде. Второе, как правило, быстрее и надежнее, но на порядок сложнее и требует глубокого понимания всех вовлеченных в процесс элементов.
При этом в IT есть масса задач, которые решаются первым способом, не сильно подготовленными инженерами. Будем честны, последние лет 15-20 первый подход изрядно доминирует в commodity IT, и этому есть объективные причины. Это накладывает отпечаток на инструментарий, культуру, построение SDLC процессов и т.п. (некоторые менеджеры просто не верят, что есть инженеры, которые без тестов и плясок с бубном могут посмотреть на проблему и сказать «вот так делайте»).
Возвращаясь к vibe coding - AI-агент это чистый тип 1. Модель системы и процессов в ней у него не глубже, чем память у золотой рыбки, потому что он оптимизируется под внешний feedback, а не под внутренние инварианты. Он, конечно, пытается что-то документировать, и ему пытаются писать требования, но все это работает довольно тяжело. Одна из причин в том, что инженер (хороший) не только машина для нажимания кнопок, но и источник множества мельчайших, но критически важных функциональных и нефункциональных требований, многие из которых ни бизнес аналитик, ни product owner прописать не могут (тут я в очередной раз сошлюсь на Polanyi's paradox - https://en.wikipedia.org/wiki/Polanyi%27s_paradox).
Это обстоятельство далеко не всегда имеет смысл и не всегда важно. Если вы делаете сайт для записи в барбершоп и вам надо показать список барберов, потом список слотов и потом сделать кнопку book, то строить глубокую модель системы смысла не имеет. Если вы делаете софт для электронной педали газа в автомобиле, то помимо тестов, хорошо бы точно понимать, как что работает и для чего каждая строчка кода и каждая из переменных. Между этими двумя примерами, разумеется, есть широкое поле для обсуждения.
Возвращаясь к AI-агентам - по идее искусство работы с ними заключается в понимании того, где ваша задача находится относительно этой системы координат, и в выдаче агенту задания нужного размера и нужной сложности. Где-то можно доверить делать большой кусок, где-то не более одного небольшого метода, а где-то вообще надо руками написать код. Неожиданное следствие для меня как динозавра, больше полагающегося на понимание кода, чем на тесты - даже если тесты не важны мне, все равно стоит их завести в какой-то мере для AI-агентов, если я хочу ими пользоваться для ускорения разработки.
Надо только правильно их таргетировать - для каких-то кусков они имеют смысл, а для каких-то просто трата времени.
