С первого коммита моего Python-проекта одно правило важнее всех остальных: агент-программист никогда не должен видеть критерии приёмки. Поэтому я создал двух агентов, которые никогда не обмениваются заметками. Один пишет тесты по полной спецификации, а отдельный агент-программист пишет код по той же спецификации, но с вырезанными критериями. В большинстве сред разработки оба пишет один и тот же агент, что ставит под сомнение валидность результатов тестов.
Я обеспечил вырезание в коде через сборку контекста, то есть на этапе, где формируется промпт агента-программиста: раздел критериев из файла задачи удаляется до того, как промпт собирается. Какое-то время я считал, что это вырезание абсолютно надёжно. Потом выяснилось, что одна строка комментария его ломала: вырезание останавливалось на ней, и все критерии после комментария попадали к агенту-программисту. Через неделю та же ошибка случилась с критерием, перенесённым на вторую строку. Оба бага были моими. На этот раз, исправив их, я добавил тесты, чтобы любая будущая сборка падала, если вырезание применено не так, как задумано.
Skill и MCP-серверы часто сравнивают друг с другом, но для правила, на котором держится мой проект, ответом оказался ни один из них. Я хотел, чтобы пользователи могли обращаться к qikly, моей утилите командной строки, из ИИ-ассистента, например Claude Code или Cursor. Значит, в процессе участвуют две языковые модели, и ни одна из них не должна видеть критерии приёмки. Ассистент уже умел запускать qikly, но не знал, когда это нужно делать, поэтому я написал Skill: папку с инструкциями в формате Markdown, которую ассистент загружает, когда запрос совпадает с её описанием.
Написание Skill разделило две задачи. Задача Skill — давать советы о том, что должно входить в требования, а что в критерии приёмки. Этому можно только научить, но не гарантировать. Задача сборки контекста — вырезать критерии каждый раз, независимо от того, установлен ли Skill. Совет при этом всё равно важен, потому что критерий, продублированный в требованиях, всё равно попадёт к агенту-программисту, поэтому я добавил в qikly --validate проверку, которая предупреждает о таких повторах.
Часто задаваемый вопрос
Вопрос: Почему нельзя полагаться на лучшую модель или нулевую температуру, чтобы LLM не видела критерии?
Ответ: Лучшая модель чаще следует советам, но не всегда, а нулевая температура делает ответы более повторяемыми, а не более послушными. Правила, которые должны соблюдаться всегда, нужно обеспечивать в коде, например через сборку контекста, а рекомендательные указания могут жить в Skill.
Источник: Towards Data Science · Сводку подготовил HeadlinesBriefing