#рецепт
Манифест вайбинжиниринга: продолжение (часть 2)

Вот продолжение списка, который пригодится не только как напоминалка, но и как манифест того на кой черт все эти пригоршни практик без которых не работает энтерпрайз и agile:

1️⃣7️⃣ Забить агрегат на все эти прикольные механики из разряда prompt engineering, context engineering, потому что в большинстве случаев это полный bullshit, и они никак не помогают. А prompt-схемы вида COSTAR или CLEAR вообще вредны, потому что добавляют слишком много онтологической дрожи и вообще противоречат друг другу. Слишком дохрена противоречивых инструкций;

1️⃣8️⃣ Можно использовать шотган-механики для больших проектов, но в большинстве случаев они совершенно не нужны, абсолютно достаточно как раз-таки той вменяемой документации, которую ты ведёшь, и твоих правил, overview проекта, архитектуры и так далее;

1️⃣9️⃣ Перед тем как решать какую-то задачу — поискать на гитхабе её решение, хотя бы агента с вебсерчем. В 95% случаев то, как вы решаете задачу — это недостаток вашего кругозора, и это уже делали;

2️⃣0️⃣ Во все промпты инъектить команду ограничивать изменения решением задачи и не менять сопутствующие файлы, лишь бы было хорошо. Все LLM крайне плохо воспринимают принцип бойскаута и часто специально настроены, чтобы жечь больше токенов;

2️⃣1️⃣ Естественно хранить документацию в том же репозитории хотя бы в .md, и всегда её проверять на непротиворечие другой документации;

2️⃣2️⃣ Не использовать для полностью автономной работы агентов. Пока они сырые. Максимум доверять бойлерплейты и простые вещи в бекграунде;

2️⃣3️⃣ Все сервисы писать максимально автономные. Пока что модели, к сожалению, плохо справляются с учетом того, что не вся картина у них под носом

На будущее
присмотром. Но в будущем лучше делать ставку именно на небольшие автономные сервисы в рамках большой системы и микро-репы
2️⃣4️⃣ Сделать какую-то кастомную настройку, чтобы в каждом забросе ограничивать количество коллов и проходов, чтобы сервис не уходил в death loop. Скажем, делать максимум 20 правок и максимум вызовов 10 апишки. Не ходить в слишком большое количество файлов и ни в коем случае не ходить в файлы за пределами запроса и не менять всё подряд. Провайдеры LLM и API крайне любят, когда твой запрос сожрал крайне много токенов и выставит тебе большой счет. Как-то это инъектировать в каждый промпт, в каждую задачу, каждый запрос, чтобы не было избыточного количества изменений, которые не сдались;

2️⃣5️⃣ Настроить какую-то интеграцию для того, чтобы если после промота появились ошибки и сервис не перезапускается, он автоматически, делал повторный запуск и автоматически исправлял. Естественно с критериями death loop-а и не оптимального решения задачи

P.S. Если на половину пунктов не понял, не беда, у тебя есть множество инструментов для обучения