Из реддитового коммента, про AI vs reviewer

[amarao]

Interesting part of review, is when you learn something from wiser man code, or teach someone how to do it right.

AI slop is the most horrible for review.

It works, passed CI, everyone are (presumably) happy.

It subtly broke abstractions or introduce new requirements or assumptions on environment which were not here before.

Normally, if someone spend a week writing +5000 -2000 PR, you can respect this person time and spend a day or two, trying to understand deeper reasoning. If you find a flaw in the reasoning, you explain this to the person, and that's another week of work of it.

But with AI you spend a day reading +5000 -2000, find a flow, and your carefully crafted review send to AI which says 'Nicely spotted' and rewrite another +4800 -1800 PR, which someone need to read again, and it can be in complete disregard of what was said in review (if it's too abstract).

The main problem with +5000 -2000, is that if I spend 20 minutes writing an explanation for the problem (even with mvp to highlight the issue), I expect that person to learn something from it.

With LLM it's all wasted time, you get slop back, and next PR will not learn it. Partially it can be alleviated by updating AGENTS.md, but it can't be too large, so long explanation just waste tokens.

So, it's a pipe of slop and you need to review it.

What happens in reality? You skim across codebase, looking for random bits which looks odd, degrading to pattern matching machine. It's impossible to understand +5000 -2000 lines of code in 20 minutes. But they get merged. You accept them, other accept them, but codebase is slowly drifting, so you need code janitor to come and restore original semantic at the end.

Yes, we all do this, and it's terrible. Yes, it's real-politic productivity gains, but there is some kind of horrible built-in negligence in all of this.

Comments

[ufm]

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

И, опять таки, если код обложен тестами, которые пишет автор ТЗ/специально обученный QA, и он их проходит, то мне, по большому счёту, всё равно что и как там внутри тИкает. Задачу решает? Решает. Неоптимально? Да и пофиг, я уже привык к калькуляторам, которые жрут 100М памяти.

[ichthuss]

Так ведь тестьі-то тоже теперь пишет ИИ, сам себе. С понятньім результатом.

[ufm]

Для клиента, с приходом ИИ, в этой картинке ничего не поменялось.

[amarao]

Одна из причин, почему AI так лидирует в программировании по сравнению с другими областями, что в программировании очень легко проверить результат. Сначала "компилируется, значит работает". Потом тесты (какие-никакие, а кучу вещей даже фиговые тесты проверяют). Потом объективный фидбэк по результирующим сайд-эффектам.

Я смотрел умнючую презенташку от Topos Institute, там говорили, что ключевой прорыв в математике возникнет в тот момент, когда формализмы AI можно будет автоматически верифицировать. Они говорили про разрыв между формализмом и математическим текстом.

[dedekha]

И еще один момент. Когда кожанный мешок пишет свои 5000 строк кода он делает десятки микро-ревью написанного.

[amarao]

Ох, да.

[sab123]

Не делать такое в один заход, а поделить на мелкие части?

[amarao]

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

Видимо, надо адоптить идеи из линукса. Написал? работает? Молодец. Теперь готовь patch queue так, чтобы каждый коммит был произведением искусства и мог быть прочитан независимо.

Надо перестать воспринимать стадию написания как существенную и сфокусироваться на pre/post части.

[yurikhan]

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

У меня получалось заставить агента прочитать коммит и семантически сребейсить его через крупный рефакторинг меняемых файлов. Ну, то есть, в оригинальном патче файл foo правится, а в апстриме делится на bar и baz; ожидаемое — изменения по foo, применимые к общей части bar и baz, применяются к обеим; применимые только к одному — к нему.

Если я как кожаный мешок сделал кусок работы +5000 −2000, то это могло произойти в результате двух воркфлоу:

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

Агентам, в принципе, тоже подходит. В первом случае нужно, чтоб был генеральный план и чтоб коммитилось после каждого пункта. Во втором — таки причёсывание ветки.

[amarao]

Почему ты игнорируешь банальные рефакторинги? Если я какую-то базовую штуку переименовал, иметь +2000/-2000 можно после первого же find-n-replace.

[yurikhan]

Я не очень верю в сущности с 2000 использований в кодовой базе. Обычно — три. Исключение — базовые штуки: логирование, профилирование, конфигурация, файловый ввод-вывод, сеть, dependency injection.

Я не очень верю в переименование сущности с 2000 использований. Обычно — «работает, не трогай».

Я в принципе верю в замену сущности с 2000 использований на новую, с более чистой реализацией. Но она выглядит не как ±2000 в одном коммите, а как построение новой реализации рядом, использование в трёх новых местах, потом постепенный переезд, потом deprecation, потом obsoletion, потом задача на выпиливание трёх оставшихся мест и старой реализации.

Ну, в конце концов, если это реально механическое переименование без риска поломки, то да, имеет право на жизнь. Но это будет отдельный коммит, с пояснением, что тут только механическое переименование, объяснением, почему мы решили это переименовать, и счётчики «+» и «−» будут строго совпадать.

(Если новое имя длиннее старого, то оно в принципе может вести к переформатированию кода. В худшем случае, при использовании конвенций как в black — «либо все аргументы функции вмещаются на одну строку, либо мы их взрываем каждый на отдельную строчку, да ещё и свешиваем закрывающую скобку» — коэффициент не ограничен разумными пределами; но это и коррелирует с тем, что я, как ревьюер, буду сопротивляться такому рефакторингу.)

[amarao]

Поменялся каталог с инвентори.

[sab123]

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

[amarao]

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

[sab123]

Баз микроменеджмента оно косячит как я не знаю что. Или у вас какие-то задачи очень простые.

[amarao]

У меня последняя plan session длилась 9 часов. Код писался минут 15, плюс мелкие исправления (ещё час).

Последствия plan session - больше десятка issue.

[sab123]

Так а вы поделите свою plan session на части по полчаса.

[amarao]

Ты передёргиваешь "поделить plan на части" и саму plan session.

Plan session - это обсуждение как делать задачу и какие там проблемы. "Поделить на части по пол-часика" - это просто делать перерывы (вещь полезная), но само планирование надо делать целиком. Либо отказываться, изменять требования, сокращать scope - это всё на самом деле и есть plan session.

Бывают и failed plan sessions. Начал планировать, понял, что не надо это делать от слова совсем. И не всегда оно понятно в начале, часто это результат попытки разрешить противоречия в конце.

[sab123]

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

[amarao]

Ты про время работы клода (код пишется дольше)? Или про время на всё вместе, включая планирование и review?

[juan_gandhi]

+5000 -2000 changes in one PR don't have the right to exist. And first of all, how the fuck does it decide to delete 2000 lines of code written probably by respected humans? It's an abomination.

[amarao]

Что за экстримизм? Ну вот разделился какой-то там State на два. Использовался в 2000 мест. Теперь 1300 мест получила первый стейт, 700 - второй. Нормальный правильный рефакторинг.

Или, вообще, переименование. Или переход с одной либы на другую. Вполне себе разумное решение, если новая либа решает проблему, а старая нет.

[juan_gandhi]

Ха, это два специальных случая. Но не одновременно же переименование и разбиение на две части. Насчёт же перехода, если API другой, то нужен адаптер сначала.

[amarao]

Ну вот не надо мне про "нужен адаптер сначала". Разные продукты, разные требования и процессы. В куче мест, где важным является только now, вполне нормально переходить целиком и сразу.

[juan_gandhi]

А, ну если пациента не жалко, то да.

[amarao]

А что жалко? Я не понимаю тебя. У тебя в голове какой-то специфичный продакшен, с специфичными требованиями. Я вот совсем не чувствую какую проблему ты решаешь.

[juan_gandhi]

Ну как; если мы делаем питоний софт в компании Квора, то и пох, они там сначала деплоят, а потом тестируют. А вот если есть риск потерять данные банковских клиентов, или просто богатых влиятельных клиентов, то там уже на цырлах. Ну или если речь идёт об авионике, о медицинском софтвере...

[amarao]

Я ж говорю, "конкретный продакшен". Я вот с инфрой работаю, там совсем другой набор требований. Переключиться по библиотеке - как нефиг делать. Переключить коммит для ipxe бинаря на следующий - два месяца тестирования (ipxe - зависимость, и надо конкретный коммит, а не версию).

[juan_gandhi]

Ну это как повезёт с инфрой. Если вы используете Апачи Спарк, то хрен вы переключитесь со Скалы 2.12 на Скалу 2.13 (которой, небось, уже десять лет).

[amarao]

Наверное. не работал ни с одной, ни с другой.