GitHub разложила новый словарь AI-разработки: loops, squads, harnesses и hill climbing

Loop engineering вместо бесконечного чата

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

Loop engineering — проектирование повторяемой системы вокруг агента вместо ручного одноразового prompt. Например, scheduled loop получает новые issues, передаёт их агенту, валидирует output и эскалирует тупик. В простейшем виде это AI-native cron job, но зрелая петля добавляет routing, checkpoints, observability и skills. Важен не сам повтор, а управляемость: каждую итерацию можно наблюдать, ограничить и проверить.

Ralph loop — более прямолинейный вариант: агент получает подробную задачу или product requirements document и продолжает цикл plan, act, check до завершения. Он полезен для длинных работ, но может бесконтрольно расходовать tokens, context и compute. Loop engineering пытается заменить просьбу «попробуй ещё раз» явными primitives и условиями остановки, чтобы настойчивость не была единственным механизмом надёжности.

Squad, fleet и разделение труда

Squad обозначает группу агентов с разными ролями, похожую на человеческую команду. Один планирует, другой проверяет план, третий реализует, четвёртый тестирует, пятый проводит review. Fleet описывает параллельное исполнение нескольких задач. Эти понятия можно совмещать: роли squad идут последовательным конвейером внутри каждой задачи, а несколько таких задач обрабатываются fleet одновременно.

Преимущество подхода — специализация и параллельность. Agent с узкими tools и правилами может быстрее выполнить конкретный этап, чем универсальный исполнитель, который держит все обязанности в одном context. Но количество ролей не является показателем качества. Без общего определения done, передачи артефактов и разрешения конфликтов squad легко превращается в дорогой обмен противоречивыми текстами.

Практический критерий здесь тот же, что у обычной архитектуры: разделение должно уменьшать связанность и делать ошибки заметнее. Отдельный reviewer полезен, если он действительно проверяет diff по независимому набору критериев. Параллельная fleet полезна, если задачи не конкурируют за один mutable state. Иначе модное название лишь скрывает orchestration problem.

Harness — всё, что делает модель рабочим инструментом

Harness — окружающая модель система: tools, permissions, memory, context и orchestration. Сама модель может предложить текст или действие, но именно harness подключает её к repository, terminal, pull request и политикам доступа. GitHub приводит Copilot как пример такого окружения. Harness engineering означает проектирование и улучшение этого слоя, а не настройку одного идеального prompt.

Это понятие помогает точнее обсуждать сбои. Если агент не увидел нужный файл, проблема может быть в retrieval или permissions; если опасная команда выполнилась без проверки — в policy и checkpoints; если результат невозможно оценить — в telemetry и evals. Обвинение модели во всех случаях стирает различие между генерацией и инфраструктурой, которая решила, что генерации можно доверять.

Hill climbing — постепенное улучшение агента и harness через обратную связь. Команда задаёт eval, измеряет полезность результата, меняет tools или правила и смотрит, выросла ли метрика. Для агента review это может быть доля найденных содержательных bugs и качество рекомендаций. Название подчёркивает итеративность, но не гарантирует глобальный optimum: плохой eval способен уверенно вести систему не туда.

Open weights — ещё не обязательно open source

GitHub различает closed models, open weight models и open source models. Closed model доступна через API или hosted product, но пользователь не получает weights, training data и полный training process. Open weights можно скачать и запускать в собственной инфраструктуре, однако данные и метод обучения могут остаться закрытыми. В наиболее строгом изложении open source требует доступности модели, кода, данных и процесса для изучения, повторного использования и изменений.

Эти категории важны при выборе контроля, а не только лицензии. Доступные weights позволяют локальное исполнение и тонкую настройку, но сами по себе не дают полного ответа о происхождении данных или воспроизводимости. Hosted API снимает часть операционной нагрузки, но оставляет меньше возможностей для аудита и независимого запуска. Поэтому слово open без уточнения объекта — weights, code, data или recipe — сообщает слишком мало.

Forward-deployed engineer завершает словарь примером старой роли с новым AI-акцентом. Это customer-facing engineer, который адаптирует технологии к реальной среде клиента, соединяя продукт, workflows и существующие systems. Новизна не в близости к заказчику, а в том, что теперь значительная часть интеграции касается agents, моделей и harnesses.

Главная рекомендация GitHub — не бояться отстать от словаря. Термины будут исчезать и уточняться, тогда как инженерные вопросы сохранятся: насколько надёжно повторяется workflow, как валидируется действие, когда вмешивается человек, откуда берётся доверие и измеряется ли улучшение. Если на них нет ответа, новое название не сделает систему зрелой.