Как искать баги в коде с помощью нейросети?

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