На дворе февраль 2026 года, и я пишу это с четким осознанием того, что через полгода этот пост может стать музейным экспонатом. Область AI-assisted разработки меняется настолько стремительно, что любые наблюдения устаревают быстрее, чем молоко в холодильнике. Тем не менее, зафиксировать текущее состояние дел мне кажется полезным — хотя бы для того, чтобы потом самому посмеяться над своими заблуждениями.
Я прошел весь путь, который, полагаю, проходят большинство разработчиков в наши дни: от автодополнения кода в редакторе (Copilot и подобные), через чат-интерфейсы с копипастом кода туда-сюда, потом агентский подход (Claude Code), и наконец до полной автоматизации с Ralphex. Каждый этап казался прорывом, а предыдущий — наивностью. Подозреваю, что через полгода и текущий подход будет выглядеть так же.
копайлот
Мой путь в AI-assisted разработке начался, как и у большинства, с Copilot. Автодополнение кода прямо в редакторе казалось магией — иногда оно совершенно удивительно угадывало, что именно ты хочешь написать, и дописывало за тебя целые блоки. На практике, конечно, оно далеко не всегда попадало в точку, но ощущение будущего уже было. Подход этот весьма локальный и тактический, однако надо отдать должное — и в современной реальности Copilot остается очень полезной штукой. По сути, он стал современным автокомплитом с определенным умом, и в этом качестве отлично работает.
чат-интерфейсы
После того как Copilot перестал быть новинкой, появились модели, достаточно хорошие для программирования. Если не ошибаюсь, первой такой по-настоящему пригодной моделью был Sonnet 3.5, хотя я могу путать. Так или иначе, они стали настолько хороши, что их стало возможно использовать как помощника в программировании — но в режиме, прямо скажем, жестоком.
Выглядело это у меня так: копируешь кусок кода в чат, в надежде, что контекста будет достаточно для модели, чтобы понять, о чем речь. Целиком проект туда не вставишь — не влезет. Пытаешься с ним беседовать по поводу этого кода, решать те или иные проблемы. Результат потом копируешь обратно в свой редактор, смотришь, насколько все корректно. Если что-то не так — копируешь обратно в чат, и так до тех пор, пока не добьешься полной любви и взаимопонимания.
Еще в те времена, когда я делился опытом использования этих чат-интерфейсов, я выражал определенные сомнения в общем радостном хоре о двукратном улучшении скорости программирования. Я осторожно утверждал, что прирост скорее в районе 10-20%, и, забегая вперед, считаю что был недалек от истины. Реальные проблемы оно решало, но имело массу сложностей, и подход этот с высоты нашей сегодняшней реальности выглядит, мягко говоря, не самым оптимальным.
первые попытки агентского подхода
Между чат-интерфейсами и полноценными агентами была еще короткая серия экспериментов с программами, которые пытались реализовать нечто подобное агентскому подходу. Cursor, Aider, Cody и прочие в разной степени пытались дать AI доступ к проекту целиком и позволить ему самостоятельно вносить изменения. Какое-то время я ими пользовался, но на практике ни одна из этих штук мне по-настоящему не зашла, потому что чего-то всегда не хватало: то контекст терялся, то результат был слишком непредсказуемым, то workflow был неудобным. Тем не менее, направление было правильным, и именно эти инструменты подготовили почву для того, что появилось дальше.
агенты
Следующий этап, опять же как у всех, моя история тут ничем не отличается от прочих, начался в феврале-марте 2025 года с выходом Claude Code, т.е. полностью агентский подход к программистским задачам. И это сразу было “вау”. Причем “вау” такого уровня, как в свое время от появления Copilot. Было совершенно очевидно, что это путь вперед, хотя вся дорога была не без ухабов. Со временем и модели стали лучше, и я, как и вы, научился их правильнее использовать.
Разница по эффективности тут, конечно, уже не те 10-20%, с которых мы начинали. Но я бы сильно поспорил по поводу чрезвычайно оптимистичных заявлений о десятикратных приростах и прочих чудесах. Что есть, то есть — этот подход несомненно меняет весь процесс и переносит акцент с написания кода на его подготовку и планирование. Но при этом он не отменяет необходимость в человеческом участии, и я бы сказал, что в реальной жизни мы все-таки говорим о 2-3 кратном приросте, а не о десятикратном. Тем не менее, это уже совсем другой уровень, и он действительно стоит того, чтобы к нему привыкать и учиться его использовать.
агентский подход и ручной режим
Мой типичный рабочий процесс с Claude Code выглядел примерно так: сначала создается детальный план на всю задачу — с разбиением на подзадачи, с описанием ожидаемого результата и с описанием тестов. После того, как план завершен и одобрен мною, гордым человеком, железка радостно начинала по нему шуршать.
В ручном режиме это выглядело следующим образом: я говорил Claude Code “план вот такой-то, давай сделаем задачу номер один”. Оно включалось в режим планирования, делало локальный план на конкретную задачу, я подтверждал, оно выполняло. После этого я прогонял тесты, иногда спрашивал мнение другого AI — в моем случае Codex — и повторял весь процесс. Естественно, не всегда все шло гладко. Если Codex, например, находил ошибки, я копировал его ответы обратно в Claude Code, и таким образом мы добивались относительно пристойного результата. Иногда процесс повторялся несколько раз, и в итоге получалось довольно неплохо.
Весь процесс довольно механистический, и смысла использовать человека посередине, нет никакого. Я пробовал подходить к автоматизации разными способами. Например, настроил в Kitty горячие клавиши, которые автоматически переносят результат ревью от Codex в соседнее окно с Claude Code и даже Enter за меня нажимают. Ну, такие минимальные попытки автоматизации, которые помогали — меньше надо было копировать руками — но все равно это полумеры.
Кроме того, в этом подходе была еще одна заковыка. Когда я этим занимался, у Claude Code еще не было автоматической очистки контекста при переходе между задачами. Надо было постоянно помнить, в каком месте контекста ты находишься. Если забыл очистить контекст перед началом новой задачи, можно было попасть на автоматическое сжатие (compaction), которое и времени много занимает, и качество результата не улучшает. Ну и в целом, когда работаешь с раздутым контекстом, все и хуже, и медленнее.
Сейчас, в феврале 2026, с этим попроще — Claude Code сам предлагает переключиться с режима плана на режим выполнения и очистить контекст, и это часть проблемы снимает. Однако механистичность всего хозяйства вызывает удивление в эпоху, когда корабли бороздят просторы вселенной, а судный день уже на носу.
идея ralph loop и рождение ralphеx
Как раз к этому моменту появился Ralph Loop. Не буду утверждать что это моя идея, но она у меня тоже крутилась в голове. Я не помню точно, кто его автор — погуглите или у любимого AI спросите. Идея проста: запускаешь агента не в одном цикле на выполнение всех задач, а на каждую задачу запускаешь свежего, отдельного агента. И запускаешь до тех пор, пока все задачи не выполнены. Во всяком случае, это мое упрощенное понимание, хотя и в оригинале идея звучит примерно так же просто.
Вооруженный этой идеей плюс опытом ручного механистического труда, я решил наконец за эту проблему взяться. К этому моменту я уже понимал, какого вида нужен план и какая интерактивность мне интересна, а интересна мне очень низкая интерактивность и даже наоборот, полная автоматизация. В идеале хочется создать подробный, проверенный план, скормить его железке и через какое-то время получить результат. Мало того — результат, многократно осмотренный разными AI и соответственно скорректированный. Особенно интересен режим, когда один агент смотрит, отдает другому, другой чинит и отдает обратно первому. В моем случае Codex посматривает сбоку и отдает замечания обратно Claude, но и Claude сам по себе тоже проверяет, запуская ревью отдельными субагентами. И все это — часть одного полностью автоматического процесса.
Первая реализация этого продвинутого Ralph Loop была написана на Python — коротенький скриптик строчек на 70-80. Довольно быстро стало очевидно, что все несколько сложнее, чем казалось вначале. Хочется вести логи, хочется при запуске новой итерации со свежим контекстом внедрять знания о прошлом выполнении, хочется внести ограничения, чтобы оно не молотило вечно и не съедало все драгоценные токены, и многое прочее. В общем, скрипт этот быстро разросся до 300-400 строк, и стало понятно, что с таким кодом будет сложно работать и поддерживать его.
Я пришел к выводу, что оставаться на Python — это не наш путь для проекта, который обещает вырасти, и посему переписал его на Go. И с этого началась активная жизнь Ralphex.
Надо сказать, что на Go я его переписывал при помощи его же самого. Та старая Python-версия служила для переписывания самой себя на Go. Есть в этом какая-то самоирония, и даже какая-то философская нотка. Процесс этот у меня постоянно повторялся: все задачи для Ralphex я решал при помощи его же. Типа, как компилятор, который умеет компилировать сам себя, так и Ralphex умеет сам для себя создавать и выполнять планы.
как это работает на практике
Одна из моих целей была в том, чтобы все было совсем просто. Если я напишу очередную утилиту, покрывающую все случаи жизни и требующую тонкого конфигурирования, то, во-первых, кроме меня ей никто пользоваться не будет, а во-вторых, в эпоху активного переключения контекста я и сам через неделю не вспомню, как эту штуку правильно запускать.
создание плана
Создать план для Ralphex не просто, а очень просто и для этого есть несколько способов. Во-первых, к нему прилагается скилл для Claude Code, который позволяет создавать планы прямо из него. Объясняешь задачу, он задает уточняющие вопросы, просит подтверждения, и так шаг за шагом план доводится до готовности. Во-вторых, у Ralphex есть собственный встроенный режим планирования — я им пользуюсь нечасто и предпочитаю все-таки работать через Claude Code, но он делает примерно то же самое.
Впрочем, никаких особых требований к тому, как именно план создается, нет. Формат предельно простой — обычный Markdown, где задачи размечены чекбоксами: невыполненные [ ], выполненные [x]. Создать такой план можно в чем угодно. На GitHub есть масса готовых скиллов для этого — любой brainstorm-агент, plan-агент и прочие подобные штуки. В общем, ничего сложного. Прямой, простой и понятный план.
выполнение
На практике работа выглядит так: есть план, разбитый на задачи. Запускаешь Ralphex, указываешь план и вперед. Он начинает выполнять задачу за задачей последовательно. Тут начинается самое сложное, и сложное оно в двух моментах. Во-первых, если задача большая, надо ждать — это займет время. А во-вторых, надо сдерживать себя, потому что ничего уже сделать нельзя. План написан, одобрен, и надо отдаться на волю течения. Запустил — и можно идти курить или готовить другой план и запускать его в параллель.
Строго говоря, есть способы немного подвинуть процесс в одну или другую сторону по ходу выполнения. Но основная идея, которую я пытался реализовать: создал план, запустил, отошел в сторону.
Что касается моих сетований на то, что “долго и займет время”: причина ожидания в том, что задачи действительно сложные. Моя типичная задача занимает в среднем час-полтора и содержит от 10 до 15 подзадач, в каждой из которых от 5 до 7 конкретных пунктов. Делая это руками, в механистическом режиме, я наверняка потратил бы в три, а то и в четыре раза больше времени. Раньше, когда я это делал вручную, за день я мог осилить одну-две такие задачи, не больше. Сейчас никакой проблемы запустить несколько в параллель, а даже если делать последовательно — спокойно укладывается пять-десять задач за день. Самое долгое время автономной работы ralphex у меня было около 7 часов, но это была реально сложная проблема, затрагивающая фундаментальные изменения в проекте.
git, коммиты и финализатор
Все это дело привязано к git: в процессе выполнения каждая задача оформляется отдельным коммитом, а при ревью починки тоже логически коммитятся.
Кроме того, есть финальный этап, который я добавил буквально на днях, такой финализатор. Я заметил, что после завершения всех задач, когда я осматриваю коммиты и оцениваю результат, я часто делаю rebase всех этих коммитов до какой-то логической последовательности. Иметь пять коммитов вида “починил то-то, починил это-то” просто смешно для PR, поэтому последний этап я тоже автоматизировал: можно разрешить финализатор (по умолчанию он отключен), который сделает за вас красивый rebase.
не только код
Как оказалось, Ralphex можно использовать не только для программистских проблем. Не далее как вчера у меня была задача, связанная с этим самым блогом, а именно улучшить, расширить и углубить его, что по сути не столько программирование, сколько работа с текстом и контентом. В виде эксперимента я попробовал описать эту задачу планом и отдать Ralphex на выполнение, и на удивление результат получился более чем пристойным. Видимо, сам подход с декомпозицией на задачи и последовательным выполнением с ревью достаточно универсален и не ограничен написанием кода.
выводы
Подход этот мне сильно зашел и мне он кажется весьма разумным, прагматичным и производительным. Единственное, что реально иногда напрягает — ошибка в плане может дорого стоить. Ошибка в плане способна привести к цепной реакции, когда последующие этапы работают уже на основании немного испорченных предыдущих. Поэтому вес предварительного планирования сильно повышается.
Но по сути тут ничего нового нет. В нашу новую эпоху AI-исполнителей и джуниоров, человеческая роль как синьоров только вырастает. А синьоры как раз этим и занимаются — думают головой и рассказывают джуниору, что и как надо делать, и какого результата добиваться.
Все написанное — исключительно мой личный опыт, актуальный на февраль 2026 года. Через полгода наверняка все будет по-другому, и этот пост превратится в очередной артефакт из прошлого.