Дисциплина ИИ-программирования — почему важны структурированные prompt и контракты

Правильная настройка ИИ

Программирование с помощью ИИ порождает реальные, часто остающиеся без ответа вопросы: как настроить ИИ и его отдельных агентов, чтобы всё работало корректно и не ломало уже существующий код и логику? Рефакторинг никогда не должен нарушать структуру, которая уже есть в кодовой базе.

Что важнее всего для ИИ

• Точный, подробный prompt — чем яснее описано требование, тем лучше оно выполняется.
• Разбиение работы на более мелкие, гранулярные шаги с проверкой после каждого даёт лучшие результаты, чем один большой prompt.
• Снижение галлюцинаций — ИИ склонен выбирать наиболее созвучный вариант по совпадению ключевых слов, даже если он не соответствует реальному требованию.
• Встраивание бизнес-логики и явных ограничений "что нельзя ломать" в prompt даёт лучшие результаты, чем один prompt и модульные тесты.
• Модульные, интеграционные и сквозные тесты существуют, чтобы подтвердить, что данное изменение не нарушило функциональность за пределами собственной области Task.

Что AITM добавляет к стандартному ИИ-агенту

• Контракты, элементы DOM, цепочки поведения и описания бизнес-логики, к которым обычный ИИ-агент не имеет доступа.
• Task, сформированные из Chat или Brainstorm, используют контракты, документацию и поведенческую бизнес-логику, чтобы быстро находить части кода, которые не должны меняться, и подставлять соответствующую бизнес-логику в prompt до того, как ИИ к чему-либо прикоснётся, — получается prompt, подогнанный под ИИ, с минимумом галлюцинаций и наилучшей возможной реализацией.
• Prompt также получают Skills и конкретные контракты, что позволяет точно направлять Task на существующие шаблоны кодирования и существующую бизнес-логику, улучшая соответствие изменения текущему коду.
• Каждая Task Pipeline формируется в соответствии с типом запроса — Bug, Enhancement или Feature — и для каждого типа выполняется и проверяется в Pipeline по-разному, что поддерживает стабильно высокое качество кода.
• Крупные требования разбиваются на более мелкие зависимые Task, опирающиеся друг на друга; последняя Task в цепочке проверяет, что все они созданы корректно и точно.
• Крупные или нелогичные изменения приводят к остановке Task, требуя, чтобы человек (или более сильная модель) подтвердил, что изменение действительно верно, прежде чем она продолжит.
• Шаг Architect собирает сведения о том, что и где изменится, просматривает метрики покрытия кода и точно записывает происходящее — ничего лишнего и ничего умозрительного.