Спира да подканваш. Започни да строиш цикли.

Миналия месец Питър Щайнбергер пусна туит, който събра осем милиона гледания: "Вече не трябва да подканваш кодови агенти. Трябва да проектираш цикли, които подканват твоите агенти." По същото време Борис Черни — създател на Claude Code — каза нещо подобно в Acquired Unplugged: "Вече не подканям Клод. Имам цикли, които работят. Те подканват Клод."

И после интернет направи това, което винаги прави: всички започнаха да спорят, никой не видя конкретен цикъл, и дискусията се превърна в каша от абстракции.

Аз пускам реални цикли от няколко месеца. Не защото съм пред модерните тенденции — просто ми писна от ръчната триажна работа и я автоматизирах. Това, което открих, ме изненада: начинът на мислене с цикли не е напреднала техника за AI гурута. Това е естествена еволюция, която настъпва, когато спреш да третираш AI агентите като сложни машини за копи-пейст и започнеш да ги третираш като системи, способни да наблюдават, вземат решения и действат от твое име.

Трите вида "цикъл", за които никой не е съгласен

Ето защо този разговор се обърква: когато хората казват "цикъл", те може да имат предвид едно от три неща, и разликите са важни.

Първо има автономен цикъл за задачи — по същество "продължавай, докато приключи". Мисли за Джеофри Хънтли скрипта Ралф (while :; do cat PROMPT.md | claude-code; done), или командата /goal, която Codex и Claude Code вече предлагат нативно. Това е режимът "настрои и забрави".

Второ има цикъл по график или събитие — работа, която тече, докато теб те няма. Примерът на Питър Щайнбергер — HEARTEBEAT.md в OpenClaw — е каноничният: чеклист, който агентът преразглежда на всеки 30 минути. Наследници на този модел включват Codex автоматизации и планираните рутини на Claude Code.

Трето има оркестрация fan-out — динамични работни потоци с множество агенти, работещи едновременно. Операциите от тип map/reduce на Claude Code влизат тук. Това е по-близо до актьорски модел, отколкото до обикновен цикъл.

Моето мнение? Щайнбергер и Черни описват втория тип, свързан с първия. Циклите, които аз пускам, са планирани и събитийни отвън, а някои от тях изпълняват експериментални вътрешни цикли, когато се задействат. Тази комбинация е там, където се крие реалната полза.

PR Бавачката: Моето въведение в дизайна на цикли

Вече имах AI код ревю за всяко pull request. Клод преглеждаше пръв, после Codex със собствения си review, после персонализиран GitHub Action, където контролирах точно какво вижда модела — пълния контекст на разговора плюс patch diff-а.

Реалната ми работна последователност беше абсурдна: пращах PR, чаках review-и да се върнат, после copy-paste-вах коментарите в агента. Понякога снимах екрани. Ръчна, повтаряща се, изтощителна работа.

Един ден попитах агента си: "Не можеш ли просто да използваш gh клиента и да провериш статуса на review-а?" Можеше. Естествено, последва: "Не можеш ли просто да продължаваш да проверяваш и да ми кажеш, когато приключи?"

Този единствен въпрос трансформира работния ми процес. Сега агентът наблюдава за промени в статуса на review-а, изтегля нов контекст, анализира обратната връзка и върши действителната работа по адресирането ѝ. Цикълът приключва, когато стигне до решение за триаж: приеми обратната връзка, противопостави се, или ескалирай към мен.

Моделът се обобщава перфектно: наблюдавай за промени в състоянието на външни системи, събуждай се когато настъпят, тегли нов контекст, анализирай, действай и триажирай. Щом видиш тази форма, започваш да я забелязваш навсякъде. Екипът на Codex доставя свой собствен babysit-pr skill, а документацията на Claude Code вече сочи PR babysitting като водещ use case за тяхната команда /loop.

Вътрешни цикли: Да накараш агента да си пуска собствени експерименти

Има още един модел на цикъл, който ми отне повече време да оценя: експерименталният цикъл. Концепцията за автоматизирано проучване на Андрей Карпати ме насочи към това — пускаш много итерации, измерваш резултати, запазваш това, което работи. Насочих го към бавен Python път и пуснах 49 експеримента за един час, свалих p95 латентността от 339ms до 34ms за около $24.

Същият модел важи за по-сложни проблеми: дебъгване на поведението на агента в production. Когато нещо се обърка — странна траса в Braintrust, обратна връзка от потребител в Slack, или нещо, което аз самият забележа — пускам worktree, поставям трасата и извиквам тестовия цикъл.

Ето какво прави този цикъл различен: той налага дисциплина, срещу която наивното интуитивно поведение на модела се бори. Оставен сам, моделът ще хардкодне "никога не прави X, Y, Z" в system prompt-а и ще overfit-не към една-единствена траса. References-ите на skill-а дестилират изследванията защо този подход се проваля, а договорът на цикъла изисква хипотеза и тестова матрица.

Нуждая се от три случая: оригиналният провален случай, съседен положителен случай, който трябва да поеме същия път, и контрапример, който трябва да поеме различен. Три-четири проби се пускат едновременно срещу локалния dev, възстановявайки точния потребителски контекст от трасата. Всяко изпълнение се оценява по tool calls, латентност, input-token delta и коректност. Моделът не може да мами чрез запаметяване — трябва действително да разбере.

Какво всъщност се променя, когато строиш цикли

Най-голямата промяна не е техническа — тя е концептуална. Когато подканваш агент, ти все още си този, който управлява. Ти си газта, навигаторът, проверяващият качеството. Циклите обръщат това. Ти ставаш архитект на системи, които се управляват сами.

Това не означава, че пълната автономия е целта. Аз все още съм на портала за триаж при всичко важно. Циклите се грижат за досадните неща, мониторинга, повторението. Аз се грижа за преценките, които наистина имат значение.

Втората промяна е, че циклите те принуждават да си ясен относно критериите за успех. Един добър цикъл има ясни условия за изход, ясни точки на решение, ясни пътища за ескалация. Не можеш да строиш цикъл, без да си дефинирал как изглежда "готово". Тази дисциплина се прелива във всичко останало.

Трето, циклите са композируеми. PR бавачката работи заедно с експерименталния цикъл. Планирани проверки задействат on-call отговори. Започваш да строиш библиотека от поведения, които работят заедно, вместо куп еднократни подканяния.

Практическа отправна точка

Ако искаш да експериментираш с цикли, започни с нещо, което вече си автоматизирал зле. Вероятно имаш GitHub Action, който прави нещо по график, или сесия на Claude Code, която ръчно рестартираш, или процес на review, който включва copy-paste на резултати между инструменти.

Избери най-досадното. Попитай се: каква промяна в състоянието чакам? Какъв контекст е нужен на агента, когато тази промяна настъпи? Какво решение трябва да вземе?

После построи цикъла. Не трябва да е елегантен. Трябва да работи и да те върне в контрол върху собственото ти време.

Пълните конфигурации, skills-и и CI workflow-ът зад циклите, които пускам, са в публичен snapshot repo: camwest/agent-skills. Това не е полиран продукт — това е работеща система, която се развива, докато уча. В това е смисълът. Циклите не са дестинация; те са практика.

Дискурсът около AI агентите се дави в абстракции. Ето конкретната версия: спри да подканваш, започни да строиш цикли, и виж какво става, когато оставиш машината да се грижи за мониторинга, а ти се грижиш за смисъла.