Говна кусок можно получить :) Но пахнуть начнёт не сразу, а через какое-то время, когда уже поздно будет исправлять

На конфиге, распараллелить?

Что параллелить то? Без нормальной спеки у тебя недетерменированный инструмент (читай, нейронка) намешает в одну тарелку кучу архитектур и подходов, позатыкает это костылями и будет уверенно рапортовать о том, что молодец и всё выполнила.

При разработке нейронкой описывать границы нужно настолько жёстко, насколько это возможно

PDR грузите и тех тз , + ограничения по ключевым местам

Елизавета Гнетнева про это и писала

«тех тз» это, типа, техзадание?)

А грузим всё-таки pdr или prd?

На самом деле не очень важно. Продуктовая документация не несёт такую большую ценность. Она может меняться и в нейронку зачастую отдаёшь не всю доку, а описание конкретной фичи или стори.

Куда важнее спека, описывающая архитектуру и принципы разработки. Причём adr тут не нужна. Нейронке пофиг, почему мы решили делать именно так, а не иначе. Важно объяснить, как делаем, а не почему так

Да я тупой ()) очень

Я этого не говорил и даже не подразумевал

Тут истина зарыта посередине. Нужно учитывать как продуктовое виденье, так и чисто инженерную часть, о которой рассказал Юрий

А кэш во фронте существует, или эти ошибки чисто ux логикой покрываются

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

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

Для примера: если мы строим фронт по цсловному FSD, у нас появляются сотни потенциальных конфигураций системы, которые с ± равным успехом достигают результата. При длительной разработке в таких условиях от случая к случаю решения будут приниматься неконсистентные и кодовая база расползётся.

Если же мы изначально возьмём архитектуру с набором строгих и непреложных правил организации кодовой базы и декомпозиции сущностей, то у агента при работе над задачей просто не будет опций и он будет всегжа идти одним путём реализации. При смене бизнес требований агент просто пройдёт тот же путь реализации, что и всегда и выполнит задачу в предсказуемый бюджет и предсказуемым методом.