Идеальный склероз в сером ящике — мой опыт в ИИ-программировании

[ramil_trinion]

ИИ все прочнее входит в работу программиста

Нейросети пока не могут работать с большими проектами. 

Ни пруфов. Ни аналитики. Просто очередной пиар ИИ.

Дальше читать не стал.

[Ra2007]

Гранулярность на уровне модулей: именно к этому пришёл сам после 200к строк с AI. Только у нас дополнительный слой: CLAUDE.md описывает границы каждого модуля явно, чтобы агент не «видел» соседей без необходимости. Получился примерно тот же принцип, каждый модуль самодостаточен и не требует контекста других. Интересно, у вас это получилось эволюционно или изначально закладывали?

[fathergorry]

Я этими идеями грезил еще когда никаких LLM не было, а были индусы, которые ведут себя примерно также:)

Эволюционно получилась своего рода дрейфующая гранулярность - когда код сначала варится в одном котле, а потом естественно вырисовываются разделения и интерфейсы. Прям как в неравновесной термодинамике. А это значит, в перспективе задачу по разделению можно будет тоже повесить на ИИ.

[Ra2007]

«Дрейфующая гранулярность» точное название. Наблюдаем то же самое: код сначала монолит, потом сам вырисовывает границы через боль. У нас сигнал что граница проведена не там, когда CLAUDE.md одного модуля начинает ссылаться на детали соседнего. Про перекладывание разделения на ИИ интересно, пробовали? Мы пару раз просили Claude предложить разбивку, результат неплохой но требует ревью.

[fathergorry]

Несколько запросов в одним и тем же промптом, и в какой-то момент получается хороший вариант. В общем, человек должен проверять.

[Ra2007]

Да, итерации работают. У нас похожий паттерн: первый вариант разбивки Claude делает неплохо, но обычно режет по техническим границам, а не по бизнес-логике. Второй-третий запрос с уточнением «модуль должен иметь одну бизнес-причину для изменения» даёт результат который можно взять за основу. Финальное слово всё равно у меня.

[Ariless]

Интересно, что принцип "короткой памяти" здесь фактически заменяет историю диалога текущим состоянием системы. История чата накапливает не только полезный контекст, но и шум. Код в этом смысле выступает как источник истины о том, что система представляет собой сейчас.

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

Для автономных модулей такой подход выглядит очень практичным. Для долгоживущих систем это наверное открытый вопрос - где хранить не только текущее состояние, но и reasoning, который к нему привёл.

[fathergorry]

Рассуждения и есть тот самый лишний шум.
В проекте храню shittrace.txt - резюме диалогов, которые регулярно приводили к ошибкам, вот он в принципе помогает. Т.е. не всю историю решений, а только краткую историю плохих решений.
Это логично: нам нужна максимальная свобода, но не нужно повторять ошибки.