Модная дискуссия последних недель: должен ли оператор кодового агента вообще читать код? Или достаточно проверить, что результат соответствует функциональным и нефункциональным требованиям?

Вопрос не новый, просто раньше он звучал в других отраслях.

Английское engine изначально означало не мотор, а «хитроумное устройство» от латинского ingenium, изобретательность. Софт это такой же engine в этом смысле. И если устройство работает и попадает в требования, так ли важно, насколько уродливо оно устроено внутри?

Иногда нет. Иногда критично. Решает не вкус, а три вещи.

Риск. Что произойдёт, если оно сломается? Сколько это стоит в деньгах и сколько людей при этом пострадает.

Скрытые качества. Насколько важно то, что вы не наблюдаете снаружи: производительность под нагрузкой, поведение на границах, утечки, безопасность.

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

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

С софтом ровно так же. Небольшое веб-приложение поверх готовых API, выглядит прилично, проходит вменяемый набор тестов и читать каждую строчку сгенерированного кода, скорее всего просто пустая трата времени. Может быть, вообще не надо этот код и вовсе читать. Но если сервис держит важные данные, сложную бизнес-логику, безопасность или просто должен прожить пять лет... тогда ключевые места смотреть придётся. И тут есть подвох.

Для нового продукта тесты - это его сертификация Единственное свидетельство того, что ваше AI поделие делает то, что заявлено - это качественный и однозначный TDD поверх SDD. А значит, при LLM-генерации вы обязаны убедиться, что тесты не фиктивные, не бессмысленные, не проверяют “не то” и самое неприятное - не повторяют ту же ошибку, что и реализация. То есть модель, которая неправильно поняла требование, напишет под это неправильное понимание идеально зелёный тест!

Так что, возможно, вы не читаете весь код приложения. Возможно, вы читаете код тестов. Но что-то вы читаете всё равно :)

Репутация Теперь про репутацию и здесь я возвращаюсь к предыдущему посту.

В наше мире репутация вендора способна зачастую закрывать часть вопросов: я могу купить условный iPhone просто потому, что Apple обычно делают нормально, и не вскрывать корпус. Я уверен в девайсе. Репутация - это накопленная информация о процессе, которого я не вижу.

С софтом, который сгенерирован агентами в рамках LLM модели(ей) каждый новый продукт - это новый вендор с нулевой репутацией. Вы не знаете, кто и как собрал это продукт.

И вот тут тема предыдущего поста смыкается с сегодняшней проблемой. Я писал про skills, hooks и агентов, которые живут в чьей-то домашней папке и не оставляют следов: reviewer смотрит на артефакт и не видит функцию, которая его произвела. Сложите два тезиса и получите систему, где процесс не наблюдаем, потому что не закоммичен, а артефакт не читается, потому что «работает же! Нууууу!».

А по факту наблюдаемость с тремится к нулю с обеих сторон. Проверить нечего.

Итог и выводы Репутацию сгенерированного кода нельзя купить. Но её можно построить ровно тем способом, о котором я говорил ранее.

1. Skill, правило, hook и промпт под git, на review, с историей изменений - это и есть описанный техпроцесс вендора 2. Тесты в репозитории - это сертификат вашего AI продукта.

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

Не читать код это нормальная инженерная стратегия. Но она работает только там, где вместо чтения кода есть что-то другое. и осознанное.

Если ни того, ни другого нет то у вас нет стратегии и вы просто бредите грезите :)

#разработка #ai #нейросети #it #codereview #тестирование #инженернаякультура