Агенты стали новой средой разработки, которая фактически заменяет существующие IDE. В ней, имея лишь промпт, вы можете выполнять все те же самые функции, что и в любой другой IDE (написание кода, тестов, рефакторинг, синтаксический анализ и проч.). Просто способ написания кода изменился. Вы на естественном языке пишете, что хотите сделать, и модель это реализует: ищет файлы, правит код, запускает команды.
Андрей Карпатый, 2 февраля 2025 года (перевод с английского):
Есть новый вид программирования, который я называю «вайбкодингом»: ты полностью отдаёшься вайбам, принимаешь экспоненциальный рост и забываешь, что код вообще существует.
Разумеется, это современный, прогрессивный метод, который дает серьезный буст в производительности по сравнению с ручным написанием кода. Однако на серьезных задачах со временем начинают проявляться его минусы, которые особенно видны на слабых моделях. Недостатки эти связаны с глобальным пониманием задачи моделью, отсутствием самоконтроля, ограничением контекста и другими проблемами, которые ведут к понижению качества. Для решения этих проблем приходится тратить больше времени на ревью кода, на общение с моделью по результатам ее реализации, на ручное управление контекстом и т.д. Я не раз ловил себя на мысли, что вот эту задачу я бы точно сделал сам быстрее. Часто модель репортует, что задача сделана, но на поверку выясняется, что решение половинчатое либо вообще нерабочее (хотя все тесты зеленые). Теряется доверие к ее результатам, и вы тратите по итогу больше времени на фиксы, чем потратили бы на самостоятельное решение задачи.
Конечно, это все не критично и лечится путем задания правил поведения, инструкций, скиллов. Со временем у вас будут скапливаться рабочие промпты, скиллы и спеки. Можно поставить плагины для динамического управления контекстом, выгрузки его в офлайн-хранилище и т.д. В целом с этим можно жить, но что делать, если вы хотите большего?
Почти эйфория
Первые месяцы, откровенно говоря, я был впечатлен промпт-инженерингом. Современные IDE с IntelliSense и IntelliCode понижают порог входа, говорите вы? Чепуха! Теперь вам вообще не нужно помнить синтаксис, библиотеку и конкретный API, вам достаточно описать словами на естественном языке, чего хотите, и все подключения сложных библиотек и вызовы их методов, которые раньше нужно было помнить либо искать и вручную кодить, магически сами собой появляются. Вам не нужно забивать голову мелочами: обвязку, конфиги, тесты, замеры производительности модель делает сама, пока вы держите в голове основной замысел.
Вы пишете промпт, агент выдает результат. Вам все нравится, вы сохраняете промпт и начинаете его применять регулярно для подобного класса задач. Со временем получается небольшая библиотечка промптов.
Для однотипных небольших задач вайбкодинг подходит идеально. Прототип, скрипт «на сегодня», демо идеи, проверка незнакомой технологии, написание тестов для готового кода. Однако даже на одинаковых задачах те же самые промпты порой выдают разные результаты. Кроме содержимого контекста на решения модели могут влиять совершенно случайные параметры. Вы даже можете управлять степенью случайности с помощью параметра temperature (обычно значения от 0 до 1). Низкие значения уменьшают случайность ответа, высокие увеличивают ее. Для автоматизации и большей предсказуемости результата промпт можно преобразовать в скилл. Скилл является пакетом инструкций, который состоит из описания и конкретного порядка действий.
При ежедневной практике за пару месяцев я набрал из промптов набор скиллов, которые помогли мне достичь повторяемости и определенного качества. Скиллы задавали паттерны поведения модели, чтобы ход ее мыслей шел в нужном мне направлении.
Порог сложности
Все же я искал что-то более системное, чем вайбкодинг. Для задач определенного объема вайбкодинг очень хорош, но когда задачи требуют большого контекста, состоят из массы требований и затрагивают большой кусок кода, подход буксует. Реализация не влезает в рамки одного промпта, автокомпакция контекста не является спасением, так как в ее процессе теряется информация. Да и лимиты на таких задачах улетают мгновенно, я уже молчу про стоимость вызовов по API.
Кроме повышенных требований к контексту, промпт/скилл не дает проверяемости. Проблема простых промптов и односложных скиллов в том, что они линейны. Большую задачу нужно декомпозировать на более мелкие и решать отдельно. Частично умные модели это умеют, но опять же от случая к случаю. Также нужна цикличность, которую пока могут дать только мультиагентские системы, где среда специально поднимает множество агентов на разных моделях и гоняет их, многократно передавая результаты работы друг другу.
Собственно примерно такую систему я и создал в рамках одного харнеса. За основу я взял управленческий цикл Plan-Do-Check-Act, добавил к нему специфику агентской разработки, наработки по другим моим скиллам, и получился отдельный скилл PDCA.
Скилл жестко задает рамки рассуждения модели и требует проверяемого результата: например, после изменений производительность не должна деградировать или покрытие тестами не должно упасть. Причем этот результат никак не вшит в скилл. Для каждой задачи критерии приемки свои и определяются на этапе планирования. Скилл цикличен, из шагов DO и CHECK мы можем возвращаться, и, по сравнению с линейной реализацией, скилл работает сильно дольше.
При таком подходе уже не побалуешься с простым рефакторингом. Но взамен я получил две важные вещи.
Результат, который стал проверяемым и предсказуемым.
Качество, которое стало заметно выше.
Как работает скилл
Скилл определяет несколько фаз (ролей) и правила перехода между ними. За ролями закрепляется набор функций и прав. У роли есть атрибут: тир, который описывает сложность задач, которые возлагаются на эту роль. Сложность задач определяет модель, которая больше всего подходит для их решения. Я выделил три уровня: cheap / medium / strong. Тир это показатель стоимости и качества модели. Другой атрибут роли: права. Они также зависят от решаемых задач. Сильная модель, как это ни странно, будет иметь меньше прав, чем дешевая. Об этом эффекте будет изложено в разделе экономики. В различных харнесах роли реализуются по-разному, лично я сижу в opencode и там это отлично ложится на сущности субагентов. Скилл ничего не знает про модели и права, он оперирует только ролями. Харнес реализует роль с помощью субагентов, задавая им конкретные модели и права.
На вход скилл получает задачу или цель. Она не может быть изменена или переформулирована внутри скилла (это допускается только пользователем). Если скилл понимает, что она недостижима, цикл останавливается.
После планирования рождается статус-файл, и он же является основным артефактом работы скилла.
Вся работа выполняется субагентами, реализующими определенные роли:
Роль |
Что делает |
Тир |
|---|---|---|
Скаут (GATHER) |
Собирает указатели file:line, URL, числа; без рекомендаций |
cheap |
Аналитик (PLAN) |
Цель, критерии приемки, декомпозиция, риски, способ проверки |
medium |
Исполнитель (DO) |
Правит файлы, запускает команды, ведет статус-файл |
cheap |
Аудитор (CHECK) |
Независимо проверяет каждый критерий по фактическим свидетельствам |
medium |
Эксперт (ESCALATE) |
Инстанция для трудных решений |
strong |
Оркестратор (RUNNER) |
Ведет цикл, ничего не читая и не правя |
cheap |
Далее в скилле задаются правила взаимодействия ролей:
Оркестратор ведет цикл, но ничего не читает и не меняет. Как правило, это первичный агент на дешевой или бесплатной модели. Он диспетчеризует роли через Task (инструмент запуска субагента) и передает им информацию друг от друга. План он не пишет, файлы не читает, команды не запускает; исключение: обновление прогресса выполнения (списка задач).
Скаут: универсальная роль, которая используется всеми недешевыми моделями для перелопачивания сырой информации.
План всегда за аналитиком. Он и составляет начальный план, и пересматривает его, когда приходит соответствующий сигнал.
Писать и запускать может только исполнитель, включая статус-файл.
Аудитор собирает доказательства (с помощью скаута) выполненной работы. Он получает отчет от исполнителя, критерии приемки от аналитика и пытается самостоятельно и независимо оценить достоверность результата.
С помощью механизма разграничения прав в харнесе задаются ограничения для ролей:
писать и запускать (exec) может только исполнитель, иначе источник изменений размножается.
чтение есть только у исполнителя, скаута и эксперта
Средние и сильные тиры не работают с сырой информацией. Прочитанный файл или скачанная из интернета документация попадает в контекст целиком, хотя для принятия решения, возможно, нужна только одна строчка. Поэтому сырые данные читает только скаут и возвращает указатели оркестратору, который дальше диспетчеризует это более сильным ролям.
Технические подробности
Машина состояний скилла выглядит так:
PLAN. Аналитик декомпозирует цель и отвечает на вопрос, какой результат нужен. Декомпозиция идет до атомарных неделимых задач с четкими границами, юнитов. Юнит это один проверяемый кусок работы со своими критериями приемки. Обязательные поля плана:
ожидаемый результат;
ограничения и допущения;
измеримые критерии приемки;
декомпозиция с зависимостями или явное решение не дробить;
средства и доступ;
риски и условия остановки.
DO. Исполнитель делает только то, что сказано в плане; изменения за пределами юнита запрещены. После завершения работы он возвращает оркестратору по сути черновик, корректность которого проверяет аудитор.
CHECK. Аудитор судит каждый ответ по фактическим свидетельствам и проверяет, что они не противоречат друг другу. Аудитор формирует вердикт в терминах критериев приемки и отдает его оркестратору. Дефект реализации возвращается в DO, неверный план в PLAN.
ACT. Завершает цикл: фиксирует выводы, ограничения, статус и передачу дел, финализирует статус-файл.
Если выясняется, что перед текущим юнитом нужно сделать еще один (DO может вернуть работу в PLAN, переведя текущий юнит в блок), то аналитик добавляет новый активный юнит. Когда новый юнит выполнится, исходный разблокируется и продолжает с теми же критериями.
Если исходный юнит больше недостижим, его вытесняет новый, а исходный помечается superseded. Чтобы при вытеснении не потерять требования, новый юнит наследует все критерии исходного, и CHECK проверяет их по прежнему сценарию.
Исполнение не может перейти от одного состояния в другое, пока не пройдет гейт:
План → DO: все обязательные поля на месте, план записан в статус-файл, получено подтверждение от пользователя или работа в автономном режиме.
DO → CHECK: все активные, не вытесненные юниты done со свидетельствами.
CHECK → ACT: все критерии проверены, ни одного несоответствующего или непроверенного.
ACT → EXIT: результат и статус-файл финализированы.
STOP: отдельная финализация, вне ряда переходов выше.
Так как граф допускает возвраты, то необходимо вести счетчик циклов. Оркестратор ведет три счетчика:
N: номер цикла задания в имени файла .pdca/status/<task>-<N>.md; растет только в ACT, когда планируется следующий цикл того же задания.
r: ревизия плана; растет только при действительно другом плане (DO или CHECK могут запросить изменение плана).
n: попытка исполнения текущей ревизии: старт с 1, переход CHECK → DO увеличивает на 1, новая ревизия сбрасывает в 1.
Также ведется история дефектов. Она не стирается ни пересмотром планов, ни новой сессией, она нужна, чтобы не зациклиться на одной и той же ошибке.
Счетчики и история живут в статус-файле.
Оркестратор передает управление Эксперту, когда попытка исполнения n становится равной трем, т.е. Аудитор три раза отклонил реализацию. У Эксперта в таком случае есть два варианта:
Дать новую вводную для перепланирования (вернуть в PLAN). В этом случае r увеличивается, n сбрасывается.
Не найти решения и остановить цикл.
Если Аудитор принял реализацию, он выносит свой вердикт и Оркестратор переходит к шагу ACT, когда цикл завершается.
Пример реальной задачи
В одном большом и сложном проекте была задача, при реализации которой скилл pdca четыре раза возвращался к одной задаче:
Цикл 1
Оркестратор решил остановить работы, так как эскалация не нашла подтверждения от пользователя, что план одобрен.
Цикл 2
Аудитор три раза не принял юнит, произошла эскалация. Эксперт работу принял.
Следующий юнит также провалился три раза и в этот раз Эксперт работу не принял, задача осталась незавершенной.
Цикл 3
Я подключился к решению вопроса и указал, что тот критерий приемки, который провалил предыдущую ревизию, мы исключаем (с записью в статус-файл). Попросил продолжить работу дальше. Следующий юнит, который должен был выполнить другой замер, также был отклонен Аудитором. Опять случилась эскалация, при которой Эксперт вынес решение, что мы завершаем задачу как выполненную, но с записанными ограничениями.
Цикл 4
Задача опять попала ко мне, я опять переформулировал требования и отдал ее на доработку. С новой реализацией Аудитор на первой итерации нашел 6 дефектов и передал исполнителю на переделку. Повторный дефект исполнителя ушел в Эксперта, который принял работу частично и попросил перемерить один аспект. Измерения дали положительный результат, и задача наконец была окончательно закрыта.
Эксперимент
После того, как скилл более-менее устоялся, я захотел его проверить и устроил эксперимент. Взял одну и ту же задачу в проекте (довольно сложный проект, в котором нужно было добавить динамические колонки) и дал ее решить одной и той же модели (DeepSeek V4.1 Flash), в трех разных средах: в чистом виде без скиллов, со скиллом-инструкцией на восемь шагов (один из моих предыдущих очень успешных скиллов) и с новым скиллом pdca. Каждый эксперимент был в отдельном клоне репозитория, без истории и без готового ответа. Отдельно прогнал эталон (рабочие настройки ролей) на рабочей ветке: та же фича, сделанная тем же циклом, но с использованием дорогих моделей: планирование и проверка на средней модели, эскалация на сильной.
среда |
время |
файлов |
своих тестов |
P0-дефектов |
стоимость |
|---|---|---|---|---|---|
без скиллов |
16 мин |
32 |
2 |
5 |
$0.20 |
очень хороший скилл |
30 мин |
37 |
7 |
4 |
$0.33 |
цикл, все роли на дешевой модели |
78 мин |
55 |
19 |
2 |
$1.19 |
цикл с использованием дорогих моделей |
≈40 мин |
48 |
16 |
2 |
$0.76 |
Что мы видим: вайбкодинг безусловный лидер по времени исполнения, стоимости и количеству дефектов. Мой предыдущий скилл, который родился из промптов, несколько лучше сделал работу, но в два раза медленнее. А вот скиллы pdca чемпионы по качеству. Они написали значительно больше тестов и оставили вдвое меньше критичных дефектов. Также можно заметить, что обычный линейный скилл в два раза дешевле, чем скилл pdca, но и в два раза менее качественный.
Экономика тиров
Формализованный скилл дороже по времени, токенам и деньгам. Это верно, пока сравнение идет с одним-двумя промптами. На простых задачах, где контекст никуда не теряется, вайбкодинг дешевле, и цикл не нужен. На сложных цена вайбкодинга складывается из множества перезапущенных сессий, повторных объяснений задачи, ревью кода и часов разработчика на восстановление нити рассуждений. Чем сложнее задача, тем дороже и неэффективнее вайбкодинг. Поэтому, если мы хотим сравнить по деньгам, то сравнивать нужно не «промпт против цикла», а «день вайбкодинга против дня в цикле».
В хорошо декомпозированной задаче почти все токены уходят на механическую работу по чтению/правке файлов, прогону инструментов и т.д. Принятие решений случается редко и выражается в коротких ответах, поэтому сильные модели имеют меньший набор прав, чтобы не забивать контекст и не тратить токены на объемную и механическую работу.
Срез с моего реального использования: 12 часов работы, 159 сессий, 3829 сообщений, $7.34.
Тир |
Сообщений |
Вход, ток. |
Выход, ток. |
Стоимость |
Доля бюджета |
|---|---|---|---|---|---|
cheap |
3485 (91%) |
371.1M |
3.12M |
$4.44 |
60% |
medium |
113 (3%) |
3.36M |
116.5k |
$2.70 |
37% |
strong |
4 (0.1%) |
50.4k |
11.5k |
$0.20 |
3% |
Вход здесь: все входные токены, включая чтение и запись кэша; выход: ответ вместе с reasoning.
За двенадцать часов сильный тир понадобился только четыре раза. Он почти не работает по сравнению с другими ролями, поэтому его относительная дороговизна теряется в общих расходах. Средний тир подключался значительно больше. Это говорит о том, что было много проверок дешевого тира и большое количество раундтрипов и возвратов в DO. Это дорого, но тоже меньше 40% от общих расходов.
У дорогих моделей разница между записью в кэш и чтением из него кратная: в моем сетапе на strong чтение $0.2/M против записи $5/M, в 25 раз. Замер на живом сеансе: теплый повторный ход с полным попаданием в кэш обошелся в $0.0034 против $0.0794 у холодного, в 23 раза дешевле.
Наибольший источник расходов: собственно кодинг. И неудивительно, если посмотреть на количество токенов, которое он перелопатил за это время. Если предположить, что это бы делала средняя модель, то один кодинг за эти двенадцать часов стоил бы около $59 вместо $2.76, а вместе со скаутом около $75 вместо $3.74. На флагманских моделях это было бы уже около $150, и это без учета записи и чтения кэша, которые у дорогих моделей платные.
Выводы
Скилл выполнил большое количество боевых задач и успешно справился с их сложностью и размером. Он не стремится во что бы то ни стало удовлетворить запрос пользователя, просто он не говорит «готово», пока не проверит результат, потому что «готово» и «не готово» для него равнозначные итоги. Скилл пометит задачу incomplete, если определенные при планировании критерии приемки не прошли.
Работа над любой сложной задачей итеративна, вы не можете все сделать за один присест. Модель не исключение, она точно так же намного лучше справляется с задачами, когда их планируют, декомпозируют, проверяют, возвращают на доработку и извлекают уроки.
Скилл потребляет больше токенов. Работают несколько ролей, часть на среднем и дорогом тирах, а независимая проверка требует свежих прогонов. Скилл более сложен в плане устройства и в плане эксплуатации. Нужно поднять роли и тиры, следить за статус-файлом и гейтами. Порог входа выше, чем у одного промпта.
На маленькой разовой задаче цикл pdca не окупится: там проще подсказать модели вручную, что и где поправить. Цикл стоит брать для длинных задач с большим контекстом, где вам важен результат и качество.
Заключение
Результатам моей работы со скиллом я доволен. Конечно, в нем еще есть шероховатости, и почти каждый день я вношу в него изменения, но он уже предоставляет код сильно большего качества и реально экономит ресурсы, позволяя оставаться в лимитах подписок моделей.
Открытый код
Скиллы, о которых шла речь (pdca и прикладные pdca-coder, pdca-dotnet, pdca-collection), открыты: https://github.com/AlexeyShirshov/skills.
Комментарии (127)
ToxaBes
23.10.2026 15:50Эм, вы рассказываете даже не о прошлом, а о поза-позапрошлом подходе. Конечно, скилы еще используются, но не являются ответом на вопрос "что дальше?". Дальше харнесы, мультиагентные системы и имаго-кодинг.
AlexeyShirshov Автор
23.10.2026 15:50В целом да, модели все умнее (и дороже :)). Но пока еще им можно и нужно помогать. На портале https://www.skillsbench.ai/ есть четкая корреляция между качеством и использованием скиллов.
Что касается харнес инженеринг - ну так это он и есть, мы все в нем уже как год почти. ChatGPT мертв, да здравствует Codex.
Что касается мультиагентных систем - описанный скил использует 6 агентов и 3 разные модели от разных вендоров. Так что Вы совершенно правы в определении тренда.
Nikolama
23.10.2026 15:50Что-то не заметно то, что они становятся "умнее", где-то даже наоборот. А за какой-нибудь астрой стоит хайп и просто иной вид обработки операций, где сидит какой-нибудь ральф луп, поэтому теперь и прячут рассуждения. И тот же хайп вокруг математических открытий, которые никто не может проверить и чьё решение случайно совпадает с черновиками решений из вкладок юзеров.
travacry
23.10.2026 15:50Нету там умнее, там нет реального погружения в контекст задачи, приходится пальцем тыкать на проблемные моменты, после чего модель такая : ну да, ты прав ...
arch1lochus
23.10.2026 15:50даже не о прошлом, а о поза-позапрошлом подходе
очень удобная позиция: если собеседник недоволен результатом вайбкодинга, LLM не выдает корректный результат ни с первого, ни со второго раза, значит "у вас не та модель / харнес / whatever". При этом первый результат по запросу "имаго-кодинг" ведет к Вашей статье.
Я как программист с 2019го, в нынешнем стеке с 2021го, так нигде и не нашел ответ, зачем мне уходить от написания кода (тем более, от чтения).
Количество задач осталось тем же. Где нужно сразу много бойлерплейта, я генерирую его - да, через чатик с подпиской 20$. Копи-пейст занимает секунды. Где нужно, даю модели весь необходимый контекст и получаю неплохой такой assistance.
Самое большое преимущество: я знаю что творится в коде. Даже если посреди ночи пьяный в баре я получу сообщение "Hey, we are getting these errors" и далее простыня логов, я пойму хотя бы приблизительно в чем проблема.
Кроме того, я уверен, что мои архитектурные решения имеют смысл. В том числе потому что обсудил их с нейронкой, но я никогда не верю ей на слово, прохожу много раундов проверок. Случаев когда immediate solution был бы неверным, накопил уже множество.
Так вот, на что мне предлагается обменять контроль над своим кодом? Еще и с дополнительной оплатой)ToxaBes
23.10.2026 15:50очень удобная позиция: если собеседник недоволен результатом вайбкодинга, LLM не выдает корректный результат ни с первого, ни со второго раза, значит "у вас не та модель / харнес / whatever".
Имаго-кодинг как раз и решает этот вопрос, вы видимо не прочитали о нем.
При этом первый результат по запросу "имаго-кодинг" ведет к Вашей статье.
И что? Тут, на Хабре, уже писали люди как переходят на него, массово известным этот подход станет скорее всего в следующем году, когда о нем расскажет условный Карпати. Хотя, вон, Thomson Reuters уже перешел, тоже писал об этом недавно. Их отрицать тоже будете?
Я как программист с 2019го, в нынешнем стеке с 2021го, так нигде и не нашел ответ, зачем мне уходить от написания кода (тем более, от чтения).
Я как программист с 21 годами опыта не понял, с чего вы решили, что я такое заявляю. Сами придумали, сами оскорбились. Я пишу код руками каждый день, просто он все больше смещен в RnD.
Количество задач осталось тем же. Где нужно сразу много бойлерплейта, я генерирую его - да, через чатик с подпиской 20$. Копи-пейст занимает секунды. Где нужно, даю модели весь необходимый контекст и получаю неплохой такой assistance.
Так и пишите, что пока находитесь на стадии гусенички.
Самое большое преимущество: я знаю что творится в коде. Даже если посреди ночи пьяный в баре я получу сообщение "Hey, we are getting these errors" и далее простыня логов, я пойму хотя бы приблизительно в чем проблема.
И я знаю. Имаго подход этого не отнимает. Ну и это на стадии гусеничкми приходится баги ыи4сить из бара, с имаго подходом в баре можно просто отдыхать.
Кроме того, я уверен, что мои архитектурные решения имеют смысл. В том числе потому что обсудил их с нейронкой, но я никогда не верю ей на слово, прохожу много раундов проверок. Случаев когда immediate solution был бы неверным, накопил уже множество.
И в имаго все так, только быстрее и качественнее. Потому что модель обучена на вашем проекте, на его специыике реализации, деталях вашей работы и тд. Фактически, она знает проект лучше вас.
Так вот, на что мне предлагается обменять контроль над своим кодом? Еще и с дополнительной оплатой)
Лично вам предлагается выдохнуть, потом прочитать все еще раз на свежую голову и понять какую чушь вы написали, обвиняя меня не пойми в чем. Если не можете понять сами, закиньте это все, включая статьи, в ваш чатик за 20$, ведь вы сами сказали, что копи-пейст занимает секунды. Раз-раз и все поняли.
Kapsa-sa
23.10.2026 15:50Полностью делегировать код нейронкам мечтают обычно те, кто сам никогда не дежурил на онколе. Когда упадет платежка, заказчику будет плевать, насколько модный мультиагентный пайплайн это написал. Отвечать все равно живой головой)
ToxaBes
23.10.2026 15:50О полном делегировании речи и не идет, ощущение, что вы не читали статью. Ответственный всегда человек и имаго подход это еще сильнее подсвечивает.
Dhwtj
23.10.2026 15:50зачем мне уходить от написания кода
Хорошо работает, когда изначальная задача не знает точно особенностей прода/стенда/стека и долбается об стенд, набивая шишки, но не уходит далеко от начальной задумки.
Но это не так чтобы очень частый случай. В остальных не работает
reqvar
23.10.2026 15:50"Hey, we are getting these errors"
То есть, друзья или коллеги к тебе обращаются не по имени, а на "hey" - "эй"?
Просто "эй" или "эй, шнырь", например?arch1lochus
23.10.2026 15:50да, у зарубежных коллег, с которыми давно знаком, обращение "hey" широко используется и синонимично "hi". Стандартное приветствие, обращенное ко мне, это Hey Vladimir, поэтому да, по имени обращаются :) Но и если без, ничего грубого в этом нет, рашн-подъездных интонаций не подразумевается
travacry
23.10.2026 15:50Поддержу полностью, чем больше проект погружается в нерослоп, тем менее он понятен для простых разрабов, ии использует новомодные fn которые обычные разрабы наврятли применили бы, как следствие сложность всей кодовой базы возрастает, ну и постояноое переписывание огромных кусков кода несколько загружает ревьювера, кстати очень часто после переписывания таких кусков подвисшие переменные ии не удаляет.
St_one
23.10.2026 15:50Имаго-кодинг.. даже не знаю от чего больше передергивает - от неблагозвучного названия или от того что вы свой личный подход ставите рядом с общепризнанными и более широкими понятиями. Пожалуйста, хватит форсить этот термин
ToxaBes
23.10.2026 15:50Имаго-кодинг.. даже не знаю от чего больше передергивает - от неблагозвучного названия или от того что вы свой личный подход ставите рядом с общепризнанными и более широкими понятиями.
А меня, бывает, передергивает от чужого невежества. Ну ничего, сейчас будем исправлять.
Этот термин взят из психологии и подходу этому уже больше 40 лет.
Общепризнанных названий этому подходу в программировании до сих пор нет, поэтому я взял ближайшую аналогию. В психологии этот метод позволяет перейти от слепых конфликтов к глубокому контекстному пониманию. Если вы хоть немного в теме машинного обучения, то поймете насколько удачно выбран термин.
Пожалуйста, хватит форсить этот термин
Вы из тех кто не приемлет все новое? Или новые подходы типа вайбкодинга можно изобретать и называть только западным специалистам?
Я понимаю скепсис, ваше право, но затыкать мне рот несколько самонадеяно с вашей стороны. Надеюсь, этой зимой опубликовать результаты своих исследований на arXiv в том числе и для таких как вы.
Tishka17
23.10.2026 15:50Исследование эффективности метода, проведенное в 2017 году, показало, что пары, участвующие в ИТО, повысили удовлетворенность браком во время лечения (и в меньшей степени при последующем наблюдении), но улучшения не были клинически значимыми.
Ok
ToxaBes
23.10.2026 15:50Ok
Давайте проделаем опыт. Возьмите любую фронтир модель на ваш вкус и дайте ей запрос:
Внимательно прочитай статью https://habr.com/ru/articles/1086430/ и проанализируй что общего у этого подхода с имаго-подходом в психологии, который позволяет перейти от слепых конфликтов к глубокому контекстному пониманию?
После чего внимательно прочитайте ответ. Может быть так дойдет о чем я пишу.
Okeu
23.10.2026 15:50Если спросить модель, что общего у пачки сухарей с холодцом и хреном, и новым макбуком на м5, то даже с таким запросом она однозначно наковыряет что-нибудь объединяющее. Вы хотя бы спрашивайте ее так, чтобы в вопросе не содержалось ответа, который вы хотите услышать)
ToxaBes
23.10.2026 15:50Ну спросите сами как можете - вон, выше, вайбкодеры и это осилить не смогли.
aftertherainbow
23.10.2026 15:50
ToxaBes
23.10.2026 15:50Вы криво обрезали сообщения выше поэтому непонятно какой контекст вы там задали. Вот Google Gemini и Claude Opus без всякого контекста:
Claude Opus 
Google Gemini Я подчеркнул ту мысль, которую пытался донести обосновывая почему взял именно такое название.
Пока делал скриншоты понял что я просто зря мечу бисер, если вайбкодеры не принимают это то кто я такой чтобы мешать им вайбкодить. Это ведь не реклама и я не продаю им этот подход, просто поделился тем как работаю сам.
На этом я заканчиваю общение в комментариях к этой статье. т.к. не вижу никакого конструктива, а значит и смысла продолжать.
St_one
23.10.2026 15:50>Этот термин взят из психологии и подходу этому уже больше 40 лет.
так отлично - пусть там и остаётся. В мире много дисциплин, а терминов ещё больше, можно даже выбрать какой-нибудь звучный)
>Вы из тех кто не приемлет все новое? Или новые подходы типа вайбкодинга можно изобретать и называть только западным специалистам?
моя претензия не к новизне. Просто не понимаю смысла форсить свой термин, ставя его на один уровень с общепринятыми
>Я понимаю скепсис, ваше право
не поймите неправильно - я не отношусь скептично конкретно к вашему подходу, просто не считаю его выдающимся настолько, что-бы ему потребовался новый термин да ещё такой который так режет слух, уж простите)ToxaBes
23.10.2026 15:50так отлично - пусть там и остаётся.
Я использую этот подход уже почти год. Мне же как-то надо его называть? У вас же нет претензий когда человек говорит "я использую вайбкодинг" или "я использую харнесс"?
Вы мне предлагаете говорить "я использую контекстно-зависимую LoRA-адаптацию низкоранговых матриц в симбиозе с RAG-системой по конкртеному проекту"? Или как?
В мире много дисциплин, а терминов ещё больше, можно даже выбрать какой-нибудь звучный)
Я выбирал не звучный термин, а наиболее подходящий по логике к самому методу. Уверен, что в следующем году в западных источниках появится собственное название и я просто переду на него. Ну или случится невероятное и термин "имаго" приживется.
моя претензия не к новизне. Просто не понимаю смысла форсить свой термин, ставя его на один уровень с общепринятыми
Давайте ваши предложения, как мне называть коротко, желательно одним словом описывать этот метод? К "упряже/обвязке" (harness) я так понимаю претензий же нет.
не поймите неправильно - я не отношусь скептично конкретно к вашему подходу, просто не считаю его выдающимся настолько, что-бы ему потребовался новый термин да ещё такой который так режет слух, уж простите)
Так он и не выдающийся, это просто дальнейшее развитие работы с моделями, эволюция, а не революция: вайбкодинг -> харнесс -> имаго. Более подробно я описал этот процесс тут.
St_one
23.10.2026 15:50>"я использую контекстно-зависимую LoRA-адаптацию низкоранговых матриц в симбиозе с RAG-системой по конкртеному проекту"? Или как?
"дообучаю модель под проект"
>Я выбирал не звучный термин, а наиболее подходящий по логике к самому методу
напротив - логика из статьи(взрослая бабочка) никак сам подход не характеризует, только ваши амбиции о нём
>Давайте ваши предложения, как мне называть коротко, желательно одним словом описывать этот метод?
не вижу смысла ему вообще иметь отдельное название. Харнесс, к слову, тоже не самый благозвучный термин(хотя и получше), но он уже прижился
>Так он и не выдающийся, это просто дальнейшее развитие работы с моделями, эволюция, а не революция
это не революция и не эволюция - просто вариация на тему. Мы же не называем использование RAG каким-нибудь "мокачино-кодингом"ToxaBes
23.10.2026 15:50"дообучаю модель под проект"
Это полное изменение весов, я его не делаю. А интеграцию с RAG где потеряли? Они ж связаны.
напротив - логика из статьи(взрослая бабочка) никак сам подход не характеризует, только ваши амбиции о нём
Ну, подход действительно "взрослее" чем вайбкодинг, скилы и харнесс. А сам термин я взял из психологии, имаго это не только взрослая особь (из биологии), но и "образ", вернее "бессознательный образ" (из психологии) с одноименным методом.
У меня ощущение, что я веду дискуссию с людьми, которые гуглят и выдают за ответ первую найденную ссылку, ну или не очень удачно задают вопросы модели.
По моему мнению, термин удачно ложиться на метод и имеет прекрасные аналогии как в биологии, так и в психологии. Психологический аспект на стал добавлять в статью чтобы излишне не перегружать.
не вижу смысла ему вообще иметь отдельное название. Харнесс, к слову, тоже не самый благозвучный термин(хотя и получше), но он уже прижился
Когда начнется его распространение, он приживется, либо на западе выдумают другой термин и приживется он, мне лично не принципиально.
это не революция и не эволюция - просто вариация на тему. Мы же не называем использование RAG каким-нибудь "мокачино-кодингом"
Для вас - нет, тк вы его даже не пробовали, а для меня это стало прямо глотком свежего воздуха. Уровень фронтир моделей, локально, на не самом дорогом железе, без зацикливаний в агентской работе и использованием существующих абстракций в проекте. Для меня это эволюция, ведь ни харнес, ни вайбкодинг, ни скилы такого не дадут.
St_one
23.10.2026 15:50>Это полное изменение весов, я его не делаю. А интеграцию с RAG где потеряли? Они ж связаны.
LoRA это именно дообучение. Остальное - технические детали
>По моему мнению, термин удачно ложиться на метод и имеет прекрасные аналогии как в биологии, так и в психологии. Психологический аспект на стал добавлять в статью чтобы излишне не перегружать.
и правильно сделали - "психологический" аспект тоже никак не связан с сутью подхода, читатель бы сразу заподозрил поиск глубинного смысла там, где его нет
>Когда начнется его распространение, он приживется, либо на западе выдумают другой термин и приживется он, мне лично не принципиально.
тут я не спорю - в конце-концов так ли важно, как будет называться пункт в глубине настроек какого-нибудь агентного cli? Хоть Имаго, хоть Гештальт - главное что-бы из описания было понятно что это включает LoRA и RAG
>Для вас - нет, тк вы его даже не пробовали, а для меня это стало прямо глотком свежего воздуха
а для меня глотком свежего воздуха стала какая-нибудь астра. Как назовём новый -кодинг? Астра-кодинг?)
becefi
23.10.2026 15:50Общепризнанных названий этому подходу в программировании до сих пор нет,
Fine-tuning это называется. Дообучение модели.
ToxaBes
23.10.2026 15:50Имаго это скрещивание LoRA с RAG.
И на самом деле, вместо Fine-tuning, тут ближе был бы parameter-efficient fine-tuning (PEFT), но и он описывает всего лишь половину.
RalphMirebs
23.10.2026 15:50Меня же он смешит, ибо имаго по-японски это “взрослое насекомое” в беседе о его развитии. В целом любое насекомое, так-что даже таракана можно так назвать)
ToxaBes
23.10.2026 15:50Меня же он смешит, ибо имаго по-японски это “взрослое насекомое” в беседе о его развитии.
Для знатока "японского": это латынь.
RalphMirebs
23.10.2026 15:50Хм, не знал. А звучит как чистое яп слово. Они могли позаимствовать термин, обычное дело.
Shiaju
23.10.2026 15:50Кто-то опять изобрел айтишечку?
А если серьезно то чем дальше тем сильнее ощущение что мы только тормозим развитие своим наличием в качестве прокладки между слоями агентов.
Груздь.
madevgesha
23.10.2026 15:50А дальше вайбсекс, вайбспорт, вайбжизнь.
farafonoff
23.10.2026 15:50А попробуй спросить у ИИ программу тренировок или вкусные рецепты из курицы на ужин, все уже тут. Я иногда спрашиваю даже про то что кажется очевидным, и узнаю много нового
Wesha
23.10.2026 15:50попробуй спросить у ИИ программу тренировок или вкусные рецепты на ужин,
Скрытая картинка
UplandDivan
23.10.2026 15:50А попробуй спросить у ИИ программу тренировок или вкусные рецепты из курицы на ужин, все уже тут.
А зачем для такой задачи ИИ? Открываешь кингу/сайт с рецептами - и там всё написано. С тренировками аналогично.
Neo28
23.10.2026 15:50Все уже ограничивается только наличием агента тушки, которая сможет с унитазом в руках по лестнице зайти на 3й этаж хрущевки и выкинув старый, поставить новый согнувшись в три погибели на квадратном метре санузла.
oheret
23.10.2026 15:50А зачем его менять (если не ремонт всего санузла)?
Neo28
23.10.2026 15:50ну друзья по пьяни разбили))) У меня вот девушка, моя будущая жена, разбила раковину в санузле, уронила какой то свой пузырек стеклянный с какой то косметикой)) Но я же в общем написал, Хорошо не сантехник, а автослесарь, кто тебе меняет на авто колодки тормозные))))
Arlekcangp
23.10.2026 15:50Не будет оно сгибаться... Выпустит робо-змею со щупальцами.Эта хрень там все распилит и утащит. А новый толкан привинтит. Субагенты же... У роботов тоже будут ))
amazingname
23.10.2026 15:50Автор не рассказал главного: какой моделью он пользуется и насколько большой у него опыт в разработке через консоль. Без этой информации нет смысла ничего обсуждать.
Потому что ситуация "ваш Шаляпин ничего особенного, сам я не был, но Рабинович мне напел" очень распространенная ситуация в публикациях по вайбкодингу.
AlexeyShirshov Автор
23.10.2026 15:50Я попробовал GLM 5.3 flash, DeepSeek 4.1 Flash, Kimi K3, Haiku 5.5, Luna 6.0, Sol 6.1, Sonnet 5.5, Opus 5.5, Astra 6.0, Argon 4
Старые "летние" версии не указываю. Сейчас на этом скилле используется 4: coder - DS 4.1 Flash 1017, plan - Sol 6.1, check - Argon 4, escalate - Sonnet 5.5
В статье есть ссылка на мой конфиг, где можно посмотреть по факту эти настройки. Что касается опыта - очень активно начал работать с лета. Разработка только по данным opencode console около 500 миллионов токенов в день, 4-5 миллиардов в неделю. Остальные подписки не считал. Десятки тысяч строк кода в день.
Yarus23
23.10.2026 15:50у меня 4 млрд в день уходит. количество строк не десятки тысяч но тысячи.
AlexeyShirshov Автор
23.10.2026 15:50Мое почтение, серьезные цифры. Однако видимо это совокупный показатель по всем проектам, так как "в одно лицо" никакая модель сегодня это не затащит. 4B в день, это примерно 46К в секунду. Самые быстрые flash модели на сегодня - это сотни в секунду. Разрыв на порядок.
melodicmsk
23.10.2026 15:50А если без кэша? Вот реально сгенерированных токенов? На локальной модели qwen flash next со скоростью 100-160 т/с реальной генерации за вечер выходит 1 млн. А со всякими кэшами 10-15 млн.
ToxaBes
23.10.2026 15:50За вечер? Хм, у меня в среднем 8 млн токенов в час, на локальной модели.
Ни в коем случае не меряюсь, задачи у всех разные, да и не тот этот параметр чтобы по нему судить. Просто было интересно сравнить.
Yarus23
23.10.2026 15:50Два проекта. Я харнес выращивал наверное месяца три, когда уперся в масштабирование. В итоге схема такая - один проект заказчик ставит issues рой был самописный сейчас на deepseek harness, обычно около 15 агентов одновременно. Все крутится на сервере есть демон тысяч 100 строк кода на go который обеспечивает агентам скажем так коридор + cli утилита. Рой имеет оркестратора - орка, его зама, простые орки и воркеры; каждый в своем worktree, есть общий чат, harness понемногу сами и дорабатывают. Есть память, есть золотой свод правил сами и формируют, наиболее популярные правила перетекают в харнесс в формальную верификацию. то есть
У нас проверка устроена так: агент должен предъявить доказательства, а среда проверяет условия допуска к следующему шагу.
Например, агент исправил баг. По нашим правилам он сначала должен показать, что тест ловит ошибку, затем — что после исправления тот же тест проходит. Сам код проверяет другой агент. Для изменений поведения дополнительно нужен живой сценарий: выполнить действие, сохранить результат, перезагрузить страницу и перечитать данные.
При этом среда контролирует несколько вещей:
Какой код проверяли. У запуска есть номер, версия кода, лог и результат. Старый успешный запуск нельзя просто приписать новой версии.
Кто принял изменения. Вердикт независимого ревью должен соответствовать проверяемой версии.
Где выполняется работа. Тяжёлые команды идут через удалённый харнесс, который управляет очередью, ресурсами и временем выполнения. Локальные ограничения дополнительно поддерживает сторож процессов.
Можно ли сливать изменения. Очередь проверяет необходимые условия и запускает проверки на результате объединения ветки с актуальным
main.Можно ли объявить завершение. В серверном протоколе предусмотрен критерий завершения: одного сообщения агента «готово» недостаточно, обёртка проверяет заданное условие.
Получается, мы ограничиваем не только поведение агента инструкциями, но и возможность провести неподтверждённый результат дальше. Агент может ошибиться в рассуждениях, однако его уверенность сама по себе не заменяет тест, ревью или проверку поставки.
Строго говоря, это формализованная приёмка и машинные проверки; + антидуп и simplify review + спецификации;
Токенов жрется больше но при всем при этом по 10 pr в день иногда льется в прод за 2 месяца еще ни разу не положили. Заказчик нашел новых всего два бага за это время. То есть мы перекладываем муки выбора на обвязку и даем агенту сосредоточиться на задаче. Можно и больше агентов но очередь мержа сериализована чтобы не было конфликтов а каждый мерж гоняется по 10 тыс тестов и более + e2e и хоть все заоптимизировано вусмерть и более менее быстро но больше 15 агентов наичнаются толкаться в очереди мерджа. Можно больше раннеров но тогда я уже не успеваю даже одним взглядом смотреть что они делают, issues они разбирают автоматически, я только потом уже постмортем пробегаю глазами и все.Dhwtj
23.10.2026 15:50Поздравляю!
У вас клиповое мышление и отсутствие единой ментальной модели и понимания что происходит потому что LLM не знает что важно а что нет поэтому закидывает вас мусорной информацией которую вы не читаете. А главное вы не можете ответить на вопрос "почему решено за вас именно так а не иначе?"
P.S. тоже было несколько миллиардов в день пару раз. А толку если задача оказалась не та, выбрана не та ветка и не те способы решения
Yarus23
23.10.2026 15:50Поздравляю, у вас клиповое мышление считать что если у вас ничего не получилось то у других ничего не получится, и заметьте, ничего в моем описании не указывает на отсуствие у меня единой ментальной модели. У нас и задача выбирается та, и ветка та и способы решения те. Просто работа теперь больше сместилась в сторону архитектурных диалогов с продвинутыми моделями. Сначала спокойно и вдумчиво обсуждается спеификация, моки, критикуется. Нередки номера ревизий 11, 12 и тп. Потом режется на beads и уже эпик отдается рою. Просмотр в issues итогов мерджа больше для того чтобы зафиксировать что рой все сделал. сейчас если что то ортогонально их работе они просто ставят новую issue. Прикольно думаешь что счетчик issues плавно должен идти вниз а он иногда плавно увеличивается сам причем по делу.
WWW_cool
23.10.2026 15:50Хорошее описание работы, сам правда немного по другому делаю и проще, но у меня нет страха за прод, а вот скорость и дешевизна важнее. Заметил, что как раз описанный вами процесс сейчас форсят сами нейронки - то есть он спущен "сверху" - видимо надрочили провайдеры. Особенно вот это бросилось в глаза - сделать тест, поймать баг, исправить, проверить что теперь проходит - вот новый грок от курсора сам начал везде это пихать и это прям больно бьёт по расходу, особенно учитывая что он и так думает много.
amazingname
23.10.2026 15:50Разработка сейчас ведётся на опус 5.5 в основном. В среднем коллективе девелопер тратит 1000$ опуса в месяц и имеет опыт работы от пол года до года в таком режиме в энтерпрайз продукте.
Сонет 5.5 фактически непригоден для разработки в текущей практике. Если я случайно на него перехожу, я через два запроса удивляюсь что не так с моим "опусом" и почему его ответы сплошной бред.
Вероятно то с чем вы боретесь не от хорошей жизни в плане доступности моделей и потому устарело на год.
Как то так.
Mr_Makadamia
23.10.2026 15:50Просто, интересно по какой причине, создание и обслуживание новых инструментов не является трудозатратными? А, так же, сколько времени автор, оригинальной статьи, тратит дополнительных ресурсов? На эти вопросы, сознательно, не дают ответы, ибо тогда, это может поменя картину восприятия.
То есть я могу к своему авто прикрутить турбину, поставить другие колёса, поставить другую степень сжатия, чтобы авто ездил на этаноле. Да, авто поедет быстрее, но во-первых, я много часов провёл в гараже для перестройки своего авто, и потратил тучу денег. Во-вторых, теперь мне нужно следить за ним внимательнее, ведь из полностью рабочего агрегата я создал шаткую и требовательную к контролю систему. И теперь вместо концентрации на поездке, я вслушиваюсь в работу мотора, ищу глазами заправки с этанолом, держу в голове расход масла, и сам регулирую отсечку оборотов двигателя... Однако первоначальная моя цель - просто доехать до магазина, осталась прежней.
thekingoftheworld
23.10.2026 15:50Так Вы слона не продадите.
Как правильно сформулировано: можете прикрутить к своему авто турбину, а можете и не прикручивать. Но главное, Вы сможете делать это в 100 раз производительнее. Не сегодня, правда, попозже, когда выйдет следующая модель, она ведь будет почти аги, ведь всё так быстро развивается, буквально со дня на день. Ждем.
Двигателя, кстати, тоже не будет - все будет делать ваш харнесс. Следить тоже ни за чем не придется, вслушиваться и искать заправки будет не обязательно - это будут делать мультиагентные системы, а Вы будете всего-навсего их Аркевстратором!
Авто, правда, как такового сейчас нет. Зато есть тачка спи**енная с соседского
гитхабаогорода. Но т.к. она перекрашена через нейросеть - теперь она ваша. /sNeo28
23.10.2026 15:50У меня есть чувство, именно чувство, что по мере развития ИИ и появления нормального аги, разработка софта, в том виде как она есть сейчас, трансформируется во что то другое. Ибо текущий подход к разработке софта, да и железа, имеет кучу моментов, которые по сути страхуют финальный продукт и его эксплуатацию, от человеческих ошибок, на всех этапах жизни SW/HW. Но ИИ ведет себя по другому, ошибается/галлюцинирует по другому. Поэтому логично предположить что и подход поменяется. Даже уже сейчас видно что применении ИИ "в лоб", просто подменяя/заменяя разработчика...такое себе
kotokot
23.10.2026 15:50Останется ли вообще такое понятие, как "Разработка софта"? Останется ли вообще "софт", как мы его знаем? Зачем вообще слои UI, бизнес логики, данных и кода между человеком и проблемой, если условный AGI сможет сразу транслировать решение в команды процессора?
Но это, конечно, если (или когда) AGI будет. А до этого в индустрию придут агентские системы корпоративного уровня, реализующие весь SDLC с нужным уровнем контроля, гибкими настройками, официальной поддержкой, SLA и разными планами подписки. Наколенные харнесы, конечно останутся, но для бизнеса будут выглядеть, как свой велосипедный сервер для сборки и деплоя, когда есть гитлаб и иже с ними.
Это, разумеется, мое субъективное мнение, и все может оказаться совсем не так.
Arlekcangp
23.10.2026 15:50Не сможет У любого интеллекта будет граница возможного. Все эти слои и архитектура нужны для разбиения на блоки и уменьшения поверхности изменений.Небольшую систему можно написать в стиле "большой навозный шар" Человек в этом запутается сразу.А agi - по мере роста "радиуса" шара. И распутывать потом будет очень сложно. Что касается генерации софта с нуля каждый раз,когда он нужен - это вообще утопия. Так только короткие скрипты одноразовые хорошо генерить. Выполнять все задачи такими скриптами тоже не разумно. Это тупо дольше и малоэффективно. Не говоря уже об отсутствии какой-то повторяемости и стабильности результата.
AlexeyShirshov Автор
23.10.2026 15:50Вы совершенно правы, именно по этому я с оптимизмом смотрю на будущее профессии software engineer. Мы будем управлять средой, которая пишет код. Ну и вопрос ответственности никто не снимал. Работодатель не будет спрашивать с модели за косяки на проде, за них в любом случае будет отвечать наемный сотрудник.
Kapsa-sa
23.10.2026 15:50Настоящий инженер всегда потратит три недели на автоматизацию задачи, которая руками делается за десять минут! :)
oheret
23.10.2026 15:50Однако первоначальная моя цель - просто доехать до магазина, осталась прежней.
Но это справедливо и ко всей айтишке: масса автоматизации нужна только самим автоматизаторам чтобы зарплату получать. Проще говоря для примера, старый добрый пенсионер-вахтёр всё равно эффективнее по всем метрикам новомодной автоматизированной проходной с камерами высокого разрешения и распознованием лиц (базу которых потом ещё и
хацкерыадмины сольют за мелкий прайс).aaoo
23.10.2026 15:50Пенсионера вахтёра тоже можно "хакнуть". И не работает он 27/7, даже посменно.
oheret
23.10.2026 15:50Да без разницы. За исключением совсем уж специфических кейсов, вся эта автоматизация ради автоматизации влетает в копеечку. Просто было модно, чисто ради PR эффекта бабло вливали. А сейчас вот новая "любимая жена" - ИИшка. Суть та же что и айтишка - нахрен особо и не нужно, но для PR эффекта бабло вливать всё равно будем.
Dhwtj
23.10.2026 15:50по какой причине, создание и обслуживание новых инструментов не является трудозатратными
Теоретически, это однократные затраты. На практике это затротство
thekingoftheworld
23.10.2026 15:50В блоке "Пример реальной задачи" ни задачи ни примера.
AlexeyShirshov Автор
23.10.2026 15:50Я хз, пропустят ли модераторы, если я скину ссылку на оригинал статьи. Там есть прям лог рассуждения скила. При желании его можно найти в моем репо в бранче publish. Если не найдете, могу скинуть в личку.
svcoder
23.10.2026 15:50Все эти вайб-кодинги и промт-инжениринги работают ровно до того момента, пока вам не прилется задачу, конечный результат которой сформировадся у вас в голове объяснить модели . Фактически между вами и результатом появляется не очень умный, но очень исполнительный посредник, которому вы раз за разом вынуждены объяснять все ньюансы задачи, чтобы получить ожидаемый вами результат. Возможно со временем, когда в силу естественный причин размер моего контекста уменьшится, а скиллы подзабудутся я начну находить во всем этом смысл, но пока я пас. Для несложных задач есть другие разработчики, которые выдают более предсказуемый результат и несут за него ответственность
Underwold
23.10.2026 15:50Не по теме но буду признателен за ответу. Стоит ли начинать путь в кибербезопасности? и развиваться в ней, плюс конечно изучать программирование, без него будет вообще будет тяжко. Хочу перезапустить себя в 30 лет.(решил узнать про это, так как интересно мнение людей которые уже кодят какое то время и может думают что и их заменят) Надеюсь на адекватный ответ.
AlexeyShirshov Автор
23.10.2026 15:50Я не специалист в кибербезопасности. Насколько я знаю, существующие модели могут взломать все что угодно и вся работа безы на текущий момент может свестись к промпту - просканируй проект на наличие уязвимостей.
В эту отрасль имело смысл входить лет 25 назад (как и вообще в ИТ), щас кажется уже поздно, тем более в зрелом возрасте. У меня большие опасения на счет подростков 16-18 лет. Нужно ли им в это входить...
Даже бесплатные модели сейчас превосходят по скилу джунов.UplandDivan
23.10.2026 15:50тем более в зрелом возрасте
Человек пишет, что ему 30 лет. В этом возрасте ещё ничего не поздно)
Neo28
23.10.2026 15:50кибербез как и разработка никуда не денутся, вопрос только в том, в каком это виде будет, и сколько специалистов нужно будет рынку. Мы приходим в точку равновесия, все специальности это прошли в свое время. Премии в доходах, на рынке труда не будет точно, и конкуренция за нормальное рабочее место будет как и в любой другой профессии
Jajaba
23.10.2026 15:50В большинстве других профессий конкуренции меньше
Neo28
23.10.2026 15:50Да, но в этих профессиях или денег платят совсем не много - типа какие нито кассиры в пятерке или клерк в банке, или работа тяжелая и зачастую вредная для здоровья - типа какой нито сварщик на вахте в тайге где летом сырость и комары, а зимой -30. А так, мест где хотя бы 250к платят, работа дома/офис, +- в нормальные рабочие часы, что то не приходит ничего в голову. Даже набившие оскомину курьеры, что бы 250к заработать должны побегать часов 10-11 в день на 6ти дневке, в любую погоду. И при том у них ГПХ, те пенсия не идет и больничных нет, а в ИТ все же основная часть оформлена на нормальный контракт.
becefi
23.10.2026 15:50Конечно имеет смысл кибербез. Сейчас с внедренем агентных систем, работы еще прибавится - нужно обеспечивать их изоляцию, авторизацию, сандбоксирование, и все такое.
Underwold
23.10.2026 15:50С одной стороны да, с другой риск что это будет напрасно из-за ии. Хотя в рф мне кажется кибербез будет еще какое то время актуален из-за отставания. Я к тому что тратить время на такую проф. хоть и курсы по ним идут в разные строны и начать можно с малого это серьезно. Смотрел видео человека который работает у Касперского, сказал что дефицит есть и не только у нас. При этом, много кто не хочет набирать джунов, им подавай профи сразу, хотя есть исключения конечно. Под себя подстроить человека и расти его в своей компании это неплохо как по мне.
Короче хочется сменить проф. устал на своей по тем или иным причинам. Хотя нравится от части она.
Спасибо за ответ
UplandDivan
23.10.2026 15:50Если это направление вам интересно, если примерно представляете где и как будете искать работу (я не в курсе, что сейчас в РФ с рынком труда в ИТ и ИБ) и готовы начать со стажёрской должности, то, конечно, попробуйте. Что касается ИИ, тут хз куда всё повернётся, и никто не возьмётся предсказать.
Underwold
23.10.2026 15:50Спасибо. Интересного много сейчас решил спонтанно что надо делать и пусть будет что будет. Лучше что-то чем ничего. Готов конечно начать со стажировки. В газпроме видел вакансию без опыта от части, знания о сетях нужны как базовые, так что начну с малого обучения а там посмотрим.
v1st
23.10.2026 15:50тоже отталкивался от PDCA, когда мастерил свою обвязку (harness/каркас/терминального агента). при удачном стечении обстоятельств тисну статью на эту тему в ближайшее время
Kapsa-sa
23.10.2026 15:50Схема красивая, но когда на одну фичу уходит 78 минут и куча субагентов, проще было сесть и набросать код руками за полчаса
v1st
23.10.2026 15:50как вариант - за это время можно сесть и набросать код/архитектуру или сделать ревью чего-то другого - у меня обычно как-то так происходит...
AVAF
23.10.2026 15:50проще было сесть и набросать код руками за полчаса
Абсолютное большинство вайбкодеров программировать не умеет, "под капот" не заглядывает.
becefi
23.10.2026 15:50когда на одну фичу уходит 78 минут и куча субагентов, проще было сесть и набросать код руками за полчаса
Это если одна фича. Если их 10 - самому придется их делать последовательно. А с агентами - можно паралельно, увеличив их количество.
A_M_D_28
23.10.2026 15:50По-моему, правы многие в этой дискуссии. И те, кто строит сложные связки из нескольких моделей, и те, кто ругает их за глупость и неоптимальные пути. Мы сейчас в самом начале пути, сложно делать какие-то серьёзные выводы. Очевидно, что ии будет использоваться всё серьёзнее, но текущие инструменты - это не конечная точка
Кстати, почему все упёрлись в платные подписки? Сейчас локальные модели развиваются с такой скоростью, что часто выдают результаты круче и точнее, просто потому что они не зажаты корпоративными рамками и цензурой на серверах. В дальнейшем можно будет запросто использовать их, вместо серверных моделей.
Насчёт юридичемкой части согласен с тем, кто сказал, что спрашивать за код в любом случае будут с человека. Да, будут, с того, кто писал промпты и проверял результат. Поэтому разработчик будущего обязан понимать архитектуру, структуру проекта и то, что именно ии там понаписал. Профессия точно изменится, и это круто. Огромный пласт унылой рутины просто уйдёт в небытие, и можно будет нормально заниматься RnD и проектированием, а не перекладыванием бойлерплейта.
ToxaBes
23.10.2026 15:50Кстати, почему все упёрлись в платные подписки?
Не все. Использую deepseek-harness с одной локальную моделью и LoRA адаптерами под проекты. Работает на уровне текущих фронтир моделей, некоторых обходит. Пока чуть хуже опуса 5, но тут просто нужно дождаться релиза архитектуры Qwen 4.
Все токены бесплатны. Из минусов, для такого подхода нужно от 48Gb VRAM, лучше 96. У меня с этим проблем нет тк занимался ML еще до того как это стало модным и железо было куплено по адекватным ценам.
Этот подход еще ждет свой пик популярности, когда за текущие облачные модели взвинтят неприличный ценник в подписке, чтобы перестать работать в убыток.
melodicmsk
23.10.2026 15:50Мне кажется обилие архитектур, языков программирования и прочего это жуткий легаси. Сделано, что бы человеку было удобно. По хорошему для эффективного ии кодинга надо создавать новый процессор, новый язык программирования и новые интерфейсы, которые должны быть удобным для ии, и не обязательно удобным для человека. ИИ наверное это все и напишет.
AlexeyShirshov Автор
23.10.2026 15:50Новое железо уже давно есть, новый интерфейс - md или html, язык - я так понимаю все будут переходить на rust.
Так что всё уже сделано.Neo28
23.10.2026 15:50Вообще не факт что RUST. Это просто одна из опций, которая имеет адептов) Я вижу что скорее всего это должен быть компилируемый язык программирования с четкой типизацией (гораздо проще оптимизировать под конкретную платформу), с минимумом языковых конструкций (размер кода и его читаемость не важна, если принять что код написанный ИИ будет в дальнейшем поддерживаться только ИИ и ИИ не делает ошибки за которые мы все так "любим" С))))). Скорее всего С подобное, с сильно урезанным синтаксисом.
Kano
23.10.2026 15:50Создаётся общее впечатление от работы с ллм что им больше подходят языки в которых меньше всего возможностей выстрелить себе в ногу. Rust хороший кандидат где нужна производительность и низкоуровневый доступ
melodicmsk
23.10.2026 15:50Я не имел ввиду вообще человека. У нас все железо, протоколы сделаны для удобства человека. Человек пишет на java, а машина исполняет байт код. Ассемблоер сделан понятным для человека из-за этого внутри cisc появились свои микрокоманды risc. Напрямую такой код человек написать не сможет. Куда не копни, всё сделано для удобства человека, а не для скорости.
AVAF
23.10.2026 15:50Я не раз ловил себя на мысли, что вот эту задачу я бы точно сделал сам быстрее.
Уже сейчас абсолютное большинство вайбкодеров в принципе не знает, что "под капотом". Им надо свою задачу запилить — она пилится. Наверняка в десятки раз менее оптимально, чем возможно, но для опять таки абсолютного большинства это абсолютно не критично, железо который год мощное, дешевое.
melodicmsk
23.10.2026 15:50Ага, а люди прям оптимально пишут. Что не мобильный банк так пару сотен мегабайт.
Kenshouten
23.10.2026 15:50А разве Codex или Claude code не делают это все автоматически? Даже при полном отсутствии каких-то agents.md они вполне себе справляются разгребать Авгиевы конюшни легаси на 100 клок.
Но для самопального харнеса, наверное, актуально.
reqvar
23.10.2026 15:50Почему все думают, что чем современнее модель, тем она, обязательно, лучше? Та, которая вышла, например, вчера, может запросто уступать и быть хуже той, которая вышла полгода назад.
Dhwtj
Так не работает если цель не чёткая, а вариантов достижения "примерно в цель" десятки, противоречивых, с неизвестными вероятностями и стоимостью.
У меня других задач и не бывает.
С ТЗ каждый дурак сможет©
AlexeyShirshov Автор
Есть другой скил, про который тоже думаю написать. pdca-incremental, он как раз для нечетких целей. Типа нужно идти туда-то, но как - хз. Он берет направление, планирует первый шаг в этом направлении, реализует его и передает результат следующему циклу. Дорога длиной в тысячу миль начинается с первого шага...
coldwind
Дорога длиной в тысячу миль начинается с первого шага... и ведёт не туда.
На сложных задачах при большом объёме кода, когда составленный план приходится корректировать на ходу, маленькие шаги могут свернуть весь процесс в никуда или усложнить решение там, где можно было обойтись меньшими изменениями. На входе у тебя задача из четырёх строк и, отвечая на вопросы агента, ты постепенно формируешь ADR, строишь планы и просишь агента пройти один, другой, третий. Через несколько шагов ты сталкиваешься с проблемой, которая при внимательном рассмотрении, связана с ограничениями и условиями, записанными в ADR. Агент воспринимает их как требования, хотя на самом деле ADR лишь один из вариантов реализации требований. Вот только отвечая на вопросы ты же не всегда можешь наперёд сказать, какие архитектурные изменения скрываются за каждым из ответов. А модель не имеет возможности изменить ответ на вопрос, взяв какой-то риск, ведь это же записано в ADR.
Так можно ли отдать целиком весь workflow на реализацию агентом, даже с учётом того, что в некоторых случаях он будет призывать человека на помощь?
AlexeyShirshov Автор
Кажется тут мы путаем понятия. Требования к задаче собирает аналитик. Техлид прорабатывает ADR и проч. это всё вне рамок статьи.
Статья о реализации. Когда речь идёт о планировании агентом planner - имеется в виду составление плана реализации. Т.е. какие классы с какими методами создать, какую библиотеку подключить, залезть в документацию и проч. Скилл не имеет права менять цели или переформулировать задачу, он должен её либо реализовать, либо сказать почему она не реализуема. Если она не реализуема, подключается человек и решает проблему на архитектурном увроне, после чего всё начинается заново.
Что касается отдавать целиком workflow - скил перед реализацией и сразу после составления плана этой самой реализации запрашивает подтверждения у пользователя. Мол вот артефакт, ознакомься пожалуйста, если тебя всё устраивает - подтверди.
Dhwtj
Если реализацию делает человек он может обнаружить противоречия и вернуть требования и ADR с предложением их доработать и описанием противоречий. Причем ложноположительных и ложноотрицательных будет мало
LLM так не умеет
travacry
мне ща больше всего в новом контексе ревью нравятся, у меня джуны и мидлы гоняют клод в хвост и гриву, делая с аналитиками спеку, потом гоняю я и нахожу ошибки, потом тоже происходит с кодом, вообщем натуральный дурдом)
Alkanfel1987
есть у меня одна задумка по поводу наискорейшего улучшения скилов, хуков, плагинов и иных инструментов. Создал модель "семян", которые можно будет скачать с репозитория, задумка следующая: у меня основное ядро на компе, на репозитории ГитХаба шлюз, через который передаются данные об ошибках и глуках их модели Клауда, сбор ошибок происходит посредством Рутины, раз в неделю, но можно и в ручном режиме (сделал так чтобы не нагружать пользователей расходом токенов) , собранные данные анализирую, анализирую нишу и нахожу решение проблемы , которое отдаю обратно через регулярные обновления репозитория , здесь мы убираем , автоматизированный подход наших моделей по поводу решения багов, анализ провожу я и пути решения корректирую сам, проверяем работоспособность обновленных инструментов в полевых условиях. вот в принципе и всё . Я пока не смог родить более быстрого и эффективного способа для улучшения работы в Клауде, свои стеки могу показать, но у меня не все так просто в плане терминологии брал древние тексты и внедрял рабочие по сей день алгоритмы из разных сфер. методология работы следователя, 3 слоя анализа (Я, ИИ модель, среда из которой поступает инфа) , структурирование агентной сети по используемым моделям (сонет, Опус, Фэйбл, хайку не использую показал себя как не эффективный в решении моих задач), навыкам, задачам и сферам деятельности.
Так вот если есть интерес можем сколаборироваться и подумать над некоторыми задачками, а то я крайне не люблю долгий тупеж при работе с ИИ , а она собака такая категорически не хочет внедрять многие мои задумки, ищу различные ходы решения, уже написал что то по типу n8n, думаю гнать ИИшку четко по структуре, чтобы не могла инициативу излишнюю проявлть.