Из реддитового коммента, про 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

[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?