Как я работаю с AI-агентами: что советую изучать разраб… — Transcript

Кирилл Сачков делится опытом работы с AI-агентами в веб-разработке и советует, какие навыки изучать разработчикам в 2026 году.

Key Takeaways

AI-агенты уже кардинально меняют процесс разработки, снижая необходимость писать код вручную.
Важна не только модель, но и окружение (harness), которое обеспечивает эффективное взаимодействие с агентом.
Освоение терминала и CLI — ключевой навык для работы с современными AI-агентами.
Для разработки лучше использовать проверенные агенты, такие как Codex и Cloud Code, но есть и достойные open source альтернативы.
Разработчикам нужно постоянно обновлять знания и учиться работать с новыми инструментами и пайплайнами.

Summary

Кирилл рассказывает о применении AI-агентов в веб-разработке и их влиянии на процесс создания кода.
Объясняет разницу между LLM, чатботами и агентами, а также что такое harness — рабочая среда вокруг агента.
Делится своим пайплайном и инструментами, которые использует для повышения эффективности разработки.
Подчеркивает важность работы с терминалом и рекомендует освоение CLI для взаимодействия с агентами.
Обсуждает популярные AI-агенты и модели, включая Cloud Code, Codex, OpenCD и китайские open source решения.
Говорит о настройке контекста и правил для повышения качества работы агентов и автоматизации ревью и тестирования.
Рассказывает о личном использовании агентов для разработки и личных задач, включая интеграцию с Telegram.
Отмечает изменения на рынке труда и важность изучения новых знаний и инженерных основ для разработчиков.
Приводит примеры рабочих флоу с агентами и обсуждает экономические и организационные аспекты их использования.
Делится советами по адаптации новичков и опытных разработчиков к новым реалиям с AI-инструментами.

Chapters

Full Transcript — Download SRT & Markdown

Speaker A

Всем привет. Меня зовут Кирилл, и я, как senior разработчик, хочу поделиться с вами своим опытом использования агентов, использования ИИ в разработке, а именно веб-разработке.

Speaker A

Ну и, в принципе, поговорить о том, куда это всё движется, рассказать вам про современные

Speaker A

инструменты, рассказать вам про свои пайплайны, как я это всё использую, а как это влияет на найм, а что сегодня уже востребовано, что делать новичкам, что делать людям уже, которые имеют опыт, как им оставаться актуальным, какие навыки и знания сегодня очень

Speaker A

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

Speaker A

каких агентов использовать. В общем, постоянно тут всё меняется. Поэтому хочу сделать видео и поделиться прямо своим опытом, рассказать про текущую ситуацию.

Speaker A

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

Speaker A

карта, о чём мы поговорим, про инструменты, про понятия, побольше про контекст и какую роль он сегодня занимает, про инженерный цикл разработки, про оркестрацию, ну и чему, в принципе, сегодня нам нужно всем учиться. Давайте сначала поговорим о понятиях. Я думаю, все знают, что такое

Speaker A

LM. Это нейронка, моделька, которая умеет понимать контекст, умеет отвечать на ваши вопросы, но она не умеет взаимодействовать с внешним миром. Это мы все знаем, это понятно. Чатбот тоже уже все используют. Это просто диалог с моделью в браузере. Там Chat, Cloud, не

Speaker A

знаю, DeepStack — это всё база. Дальше уже появились агенты, и это прямо интересно. Сейчас я считаю, что, ну, в принципе, все разработчики должны уметь с ними работать, должны уметь их использовать. Ну и вот всё, о чём я поговорю дальше, они должны уметь это

Speaker A

внедрять в свои проекты, ну и на работе тоже, чтобы быть гораздо эффективней и приносить больше пользы. Значит, что такое агент? Это у вас есть та же моделька, та же моделька, но у вас уже есть дополнительный слой инструментов.

Speaker A

Он умеет читать проект, понимать контекст, изменять файлы. Он умеет работать с терминалом, запускать все команды, есть различные плагины, то есть он может управлять вообще вашим устройством, он может подключаться к серверам по SSH, он может там создавать субагентов, то есть он полностью владеет

Speaker A

буквально компьютером. Ну, как будто это человек. То есть это и правда сейчас мощный инструмент. Но дальше идёт штука поинтереснее. Это harness. Он недавно этот термин появился. Ну и ничего нового, на самом деле, он не обозначает.

Speaker A

Это просто среда, обвязка, рабочая область вокруг вашего агента. То есть это набор промтов, набор скилов, набор правил различных, набор инструкций, набор плагинов, MCP и ваш сам проект.

Speaker A

Какая-то структура хранения, а памяти, это структура там пайплайнов, которые вы используете, workflow, всякие проверки, дополнительные инструменты, там всякие скрипты и управление контекстом. Вот вот это вот всё, что находится вокруг агента. Ну, условно, ваш какой-то там проект репозиторий. Плюс вокруг всего

Speaker A

этого оболочка, это уже будет harness. По сути, harness — это просто название. Вот оно это и означает. И на самом деле, вы можете использовать агента, допустим, cloud код, вокруг него настроить всю эту рабочую среду, и у вас получится

Speaker A

harness. Ну и сам по себе, на самом деле, сегодня тот же кодекс, cloud код, не знаю, OpenCD, это уже там RMES, это уже сами по себе harness, но вы вокруг ещё наполняете его контекстом, да, и делаете его максимально полезным для себя, ну

Speaker A

или для работы. Ну и оболочка — это то, через что вы работаете сегодня с агентом. Это через IDE, через терминал.

Speaker A

То есть это CLI-решение, это какое-то десктопное приложение, либо через web можно работать. Я, наверное, 50 на 50 работаю либо через терминал, либо вот последнее время мне очень нравится кодекс App. Там прямо много возможностей, но я уже давно не

Speaker A

использую именно IDE для этого, потому что, ну, не очень удобно, гораздо удобнее работать с этим через терминал.

Speaker A

Можно удобно запускать параллельно много сессий, много агентов. Ну, и в самом терминале куча есть узов дополнительных, а, для irev, и для управления, перемещения между папками. В общем, довольно удобная штука. Вот всем рекомендую осваивать терминал. Это вот совет номер один. Есть отдельные

Speaker A

бенчмарки, которые сравнивают работу агентов. Ну, точнее, уже harness их называют. Это Cloud CDS, там есть ещё Open Cod. В общем, есть сайт Terminal Bench, можно там посмотреть. Ну, я бы не сказал, что они прямо очень много говорят. Там не все агенты есть. Многие

Speaker A

компании делают вообще своих агентов. Ну и в принципе агент — это когда вы, а, LLM-ке даёте возможность использовать инструменты там вызова, там, не знаю, чтения файлов, вызова каких-то там тулзов, скилов и всего остального. Это довольно сложно сделать, поэтому все

Speaker A

используют готовые решения. Тот же Cloud CD, кодекс, это сейчас, конечно, мастодонты, это прямо топ на рынке, все их используют.

Speaker A

В, по крайней мере, своих проектах на работе часто в компаниях используют либо китайские open source какие-то модели, либо своих агентов, либо более open sourceные решения, типа там open-кода того же самого. Ну и вот список решил вывести популярных агентов. Ну это

Speaker A

понятно Cloud код. Вот модели, последняя модель — это Fable OPC 4.8. Недавно был Fable немножко ограничен. У кодекса совсем недавно вышел 5.6 Sol. Мне он очень прямо нравится, на самом деле.

Speaker A

Сильно прямо поумнел. Автономно может работать, ну, прямо много времени. Мне очень нравится. Также есть OpenCD. Его можно использовать со многими моделями, то есть там просто подключается провайдер либо апишка. То есть вы можете использовать либо с GPT 5.6 моделью,

Speaker A

либо с тем же там KI адисиком. То есть их довольно много. Вот ниже они показаны. DeepSik, GLM, Ki, вот недавно вышел K3. Довольно мощная модель GLM 5.2. Скоро там ещё новая выйдет. В общем, они все на самом деле идут прямо

Speaker A

впритык к американским моделям и постоянно как бы на шаг позади, но при этом они open source, при этом они дешевле, поэтому вы тоже можете их использовать. И сегодня, если хорошо настроить пайплайн, если хорошо настроить именно контекст, то это можно

Speaker A

будет довольно всё удобно использовать. И я в Telegram-канале скину скилл, а, который я сделал, чтобы настроить окружение аналогично моему. Дальше мы его разберём, но там будет весь мой стек, то есть я там расскажу, что и как я использую, и, в принципе, вы сможете

Speaker A

аналогично тому, как это сделано у меня, поднять всё это у себя и настроить под свои проекты, да, то есть поэтому заходите в Telegram-канал, подписывайтесь, там ещё будет много чего полезного. Как ещё можно использовать агентов? Как ещё можно использовать ИИ

Speaker A

для разработки, для из своих каких-то нужд? Да, то есть, да, конечно, там 90% случаев, наверное, я использую агента именно для разработки, для своих проектов, для платформы моей, ну, и также использую для личных задач, в том числе использую Хермеса. Он у меня

Speaker A

поднят вообще на отдельном сервере. У него есть интеграция с Телеграмом, поэтому я его использую через мессенджер. Удобно там записывать голосовые, кидать какие-то файлики, там запускать личные задачи. То есть можно кидать туда документы, всякие напоминалки. То есть довольно удобно.

Speaker A

Хермес рекомендую. И для кодинга лучше всё-таки использовать либо кодекс, либо cloud CD. Ну сейчас в последнее время кодекс прямо выходит вперёд, поэтому рекомендую его. Ну либо, если для вас это дорого, то используйте китайскую модельку в сочетании, допустим, с тем же

Speaker A

Он-кодом. Либо я знаю, что даже с клауд-кодом можно, так как Cloudкод — это именно агент, а LLM модель вы можете использовать любую. Можно настроить в сочетании с клауд-кодом тот же DeepSik, я знаю V4 Pro, ну, тоже неплохая комбинация, но для кодинга

Speaker A

довольно слабоват. Кто-то использует агент.

Speaker A

Может, там лимиты нормальные, но опять же, э, если вам нужно именно дебажить, делать там ревью каждой строчки, да, и вы и там вы хотите прямо безопасно писать код и только учитесь, например, писать код. Вот больше даже это подходит

Speaker A

для тех, кто только учится писать код. Вы, конечно, используете либо курсор, либо какую-то айдешку, но в целом тренды сейчас такие, что мы уже даже и не делаем ревью каждого кусочка кода, да, об этом мы поговорим дальше. То есть там

Speaker A

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

Speaker A

промт разработай какое-то большое приложение, которое будет вам зарабатывать деньги, которое будет хорошо работать. Нет, ну так не бывает.

Speaker A

До сих пор они плохо с этим справляются. Ну и, в принципе, в большом каком-то бизнесе, где у нас большие, сложные бизнес-процессы, это, в принципе, невозможно. Очень сейчас важно это какой контекст находится вокруг вашего агента.

Speaker A

То есть мы видим, что агент без контекста. У нас результат непредсказуемый. Но если мы настроим правила для проекта или для проектов, если мы настроим тесты, если мы настроим автоматическое ревью, настроим, как у нас будет храниться память, контекст нашего проекта, контекст наших задач,

Speaker A

очередь задачек, то есть заведение эпиков, и вот это вот всё, настроим MCP, выберем правильную архитектуру, настроим целый, не знаю, список огромных скилов, у них есть тоже вложенности, будем поддерживать документацию, настроим пайплайны, то тогда мы уже будем чаще намного получать предсказуемый

Speaker A

результат. И вот опять же вот эта вот схемка, это по сути называется их харнес, то есть правила, скилы, пайплайны, тесты, архитектура проекта.

Speaker A

Это можно назвать единым словом harness ваш личный, который будет на вас работать и выполнять ваши задачи. Тут стоит сказать пару слов о том, как я это использую. У меня есть мой репозиторий SCOS, он приватный. Там у меня хранится

Speaker A

вся информация обо мне, вся информация о моих проектах. Там я использую такой паттерн, то есть такой инструмент, как lm Wiки - это специальный формат хранения MD-файлов, так чтобы ваш агент удобно с ними работал. То есть это моя база знаний, там у меня хранится память

Speaker A

о том, какие у меня есть проекты, какие решения я принимаю, различные заметки. Там у меня есть список задач, тамменеджер, есть очередь этих задач и огромное количество скилов, пайплайнов, инструкций. Ну, в принципе, это не обязательно, если вы делаете какие-то

Speaker A

там личные проекты либо на работе используете. Это больше интересно и полезно для личного использования, либо если вы работаете над несколькими проектами. Ну, а так, в принципе, каждый какой-то проект может содержать свою LMвиvки, свой набор там инструментов, пайплайнов там, а, и всего остального,

Speaker A

да, и использовать это изолированно. Но так как я работаю над несколькими проектами, и, в принципе, каждый человек сейчас может настроить такое хранилище, настроить, прикрутить к этому Хермес, а, развернуть его, допустим, на сервере, чтобы он постоянно работал, подключить Telegram, и вот у вас получается

Speaker A

отличный агент, с которым можно проводить реarchнг, можно что-то обсуждать, делать там напоминания, управлять задачами, проводить ресерчинг.

Speaker A

Ну и плюс Хирмес имеет прикольную систему скилов. Он их постоянно улучшает, чистит, добавляет новые.

Speaker A

Поэтому я его часто использую, даже когда я просто, ну, работаю с компьютера в моей основной рабочей сессии. А, ну и для кодинга, для ведения проектов, даже для генерации вот визуала, который вы сейчас видите, для всего этого используются именно агенты. То есть я не

Speaker A

делаю это вручную. Это основная работа с кодом, основное ведение задач, это какой-то, может, тоже ресерчинг. То есть это, ну, основная работа, где я параллельно запускаю много разных сессий и работаю и с клодом, и с кодексом. При этом я работаю со всем этим

Speaker A

одновременно. Из-за того, что у меня несколько агентов с разных устройств могут работать с одним и тем же репозиторием. У меня настроена эта полная синхронизация. То есть с помощью гитхуков, с помощью комитов, пушев, всего этого, да, у меня поддерживается

Speaker A

синхронизация. То есть какой-то агент на сервере внёс какое-то изменение, он сразу всё это пушит. Значит, локально у меня все эти агенты сразу это всё подтягивают. Также я в Telegram-канале скину, а то, как я оплачиваю все сегодня вот эти вот сервисы, э, чем я пользуюсь

Speaker A

вообще и как я оплачиваю всех, все эти подписки, все многочисленные подписки, которые, к сожалению, надо оплачивать.

Speaker A

Короче, заходите в Telegram-канал. Давайте вот пример моего Task пайплайна. То есть это пайплайн по выполнению одной какой-то задачки. На самом деле дальше вот мы говорим подробнее, как это всё делается, но сначала формируется задача в Гитлабе. То есть у меня есть тоже на

Speaker A

отдельном сервере у меня развёрнут GitLab, где для моих проектов всех хранятся задачки. То есть они хранятся в их ремесе в LM вике, но для конкретных проектов, допустим, для моей платформы у меня там отдельный список именно Gitub задач, чтобы это вот как в

Speaker A

конбандаке у меня всё управлялось, да, чтобы у меня открывались пулреквесты, они все были присоединены к задачкам. В общем, довольно удобно, это полезно настроить.

Speaker A

Ну и ближе именно к коммерческой разработке. Сначала я с помощью агента провожу речинг. Я обсуждаю все требования. Я формирую контракт именно задачи, как он связан с другими задача.

Speaker A

Я формирую именно его какой-то контекст этой задачи. А что должно происходить? Как она должна решаться? Я её полностью проектирую, как она должна, не знаю, в систему вливаться, провожу ресерчинг, а обсуждаю всё это с агентом, выстраиваю план с шагами подробными. У меня уже к

Speaker A

этому времени, конечно, настроена архитектура в моём проекте. уже настроена там куча скилов, как с этим всем работать. Потом агент создаёт отдельную ветку Work 3, то есть отдельную изолированную копию по сути репозитория и начинает там полную реализацию. Потом он там на каждом шагу

Speaker A

проводит именно свою self-реev, то есть свою проверку. Естественно, он постоянно пишет тест, всё это тестирует. Потом, когда он завершает, уже начинается ручная проверка, но сначала проводится изолированная проверка, как бы независимая другим агентам. Плюс ещё проверяется именно сам функционал

Speaker A

автоматический агентом, то есть с помощью плагина либо компьютер use, либо в браузере он может это всё запустить с помощью Playwright, а либо могут прогнаться end тесты. В общем, полное тестирование проводится этой фичи.

Speaker A

Дальше уже агент формирует отчёт, он говорит, что он сделал, какие важные там изменения он внёс. А можно также настроить всё это систему сделать хуков, систему ограничений, чтобы он не влезал в вашу систему, не там залезал за рамки вашего проекта. Плюс можно настроить,

Speaker A

чтобы он, ну, понятно, генерировал отчёты. И если он влезает в какую-то, допустим, важную бизнес-логику, то он останавливался и как-то с вами это обсуждал. Либо отдельно в отчёте прямо писал, допустим, вот изменена такая бизнес бизнес-логика, сам обновлял документацию, сам закрывал задачу, всё

Speaker A

это открывает Merch Request и дальше уже всё это проверяю я, чтобы понять, как это работает. Он локально у меня запускает всё, что он сделал, то есть проект. А, и я всё это проверяю, да, я потом смотрю код, смотрю, всё ли хорошо.

Speaker A

Ну и задача выполнена. Отлично. В принципе, что мне ещё нужно от него? И вот сейчас, на самом деле, работа современного разработчика, она сместилась немножко с написания кода.

Speaker A

немножко в другие стороны. Во-первых, а вот как у нас раньше было, мы просто пишем код, и в основном это занимает у нас большую часть времени. Ну, хотя нет, у нас очень много времени занимало именно придумывание, как мы будем решать

Speaker A

эту задачу. Мы вникали в проект, мы разбирались, что как там работает, как это связано, и потом только вот написание, реализация, когда мы уже поняли, как это всё сделать, реализация, вот чисто написание кода, оно занимало какое-то время. И вот сейчас всё это

Speaker A

время у нас, получается, делает агент, а мы вместе с ним мы начинаем с ним обсуждать задачу. Мы начинаем с ним понимать, как эта задача решается. Мы вникаем в бизнес, мы проводим реarчинг, делаем анализ, мы с ним составляем весь

Speaker A

план. То есть видим, что работа, она на самом деле сместилась немножко на так сказать другой вектор приняла. А мы именно до того, как происходит выполнение, проводим на самом деле значительную работу потому, а, чтобы настроить агента и сказать, как всё это

Speaker A

будет выполняться, да, чтобы он не наплодил ошибок, чтобы у нас все тесты прошли, чтобы все бизнес-требования были соблюдены. И это, на самом деле, большая, достаточно тяжёлая работа. И чем больше проект, тем больше у вас времени будет она занимать. Ну и,

Speaker A

конечно, работа после, то есть, так как мы уже код почти не пишем, а мы делаем его ревью, мы смотрим тесты, мы проводим сами ручное тестирование, мы читаем отчёт, мы проводим какую-то независимую верификацию либо с помощью других агентов, конечно же, сами мы всё это

Speaker A

проводим. Ну и задача считается завершённой, когда все проверки пройдены, ну и человек сам лично подтверждает результат, тем самым берёт на себя ответственность за выполненную задачу. То есть мы видим, что роль современного разработчика, она сместилась от написания кода до вот этих

Speaker A

всех вещей, которые я сейчас вам проговариваю. И что показывают современные исследования? То есть мы видим, что использование агентов, во-первых, удвоилось за год. То есть люди уже всё чаще используют именно агентов, да, до сих пор очень много людей пользуются просто либо чатиком,

Speaker A

либо какими-то там подсказками в ADE, но прямо полноценно агентов использует очень мало человек. Мне от этого реально грустно, потому что, ну, ну, потенциал прямо очень большой, на самом деле, у этого всего. Мы видим всё большее количество именно АИ навыков, требования

Speaker A

к АИ навыкам в вакансиях, то есть компании ищут уже умеющих сотрудников работать с агентами. Поэтому сегодня это довольно важно. Но при этом, да, мы можем посмотреть, что метрики в компаниях пока что эффекта какого-то не возвели, да, процессы они

Speaker A

перестраиваются довольно медленно. То есть мы видим, что пулреквестов больше, кода больше. Но фичи они быстрее не выходят, на самом деле. А потому что код пишется быстрее, но никогда код не был узким горлышком. То есть сейчас гораздо больше разработчики делают ревью, но на

Speaker A

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

Speaker A

секции работают правильно, что ошибок меньше. Но а тут многие скажут типа вот это и пузырь, на самом деле, и неэффективно, на самом деле нет. Да, можно лишь посмотреть на то, что, ну, сейчас все используют, в вакансиях требуются. От разработчика всё меньше

Speaker A

уже требует знания какого-то конкретного языка. Да, вакансии всё ещё очень много, большинство вакансий. это там C#P разработчик, Java разработчик, Go-разработчик, но всё больше тебя спрашивают уже о, в принципе, инженерной базе. Всё больше тебя спрашивают о том, а как работают там всякие механизмы,

Speaker A

инструменты какие-то, там брокеры, знаешь, как работают микросервисы, как выстраиваете архитектуру. А всё больше спрашиваю тебя про в целом понимание, а, разработки бизнес-процессов, там, структуры данных. Да, понятно. Всё ещё часто тебя будут спрашивать на а собеседованиях там, а как устроен лист,

Speaker A

как, не знаю, работает многопоточка, как работает коллектор, там как работает асинхронность, всё это понятно, но есть будет, скорее всего, ещё довольно долгое время, но тренд мы видим уже сегодня. Но это означает, что нам нужно перестраиваться и постоянно изучать

Speaker A

какие-то новые знания. Инженерная база стала ещё важнее. Без неё не удержать контекст проекта. Ну и, в принципе, без навыков. Вот мой основной ещё тейк такой. Многие думают, там, я схожу с ума по агентам, неронкам, но мой тек такой,

Speaker A

что на самом деле навык программирования, вот эта инженерная база, она очень нужна. И как будто она становится всё ещё более востребованей, потому что она как бы умножает ваш потенциал. То есть, если у вас он плохой изначально, если ваши навыки плохие, но

Speaker A

она эти навыки и умножит в минус, как бы, да. Если у вас навыки крутые, у вас хорошая есть база, у вас хорошие знания есть, то вы сможете сделать прямо, не знаю, x10 от того, что вы бы могли делать вручную. Поэтому очень важно

Speaker A

сегодня понимать процесс целиком, от как реализуется какая-то фича, начиная от идеи до продакшена. И поэтому, кстати говоря, сегодня разработчики там узконаправленные допустим просто ээнд-разработчик там либо фронт-разработчик уже становятся менее востребованными.

Speaker A

Всё больше ценятся именно фуек разработчики, которые знают и backend, и frontend, и devops, да, они умеют, в принципе, взять фичу какую-то, проанализировать проект, проанализировать бизнес и реализовать её, внедрив систему. То есть написать пайплайны, написать код, всё это проверить, настроить агентов, всё это

Speaker A

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

Speaker A

раз-таки и будут теперь ваша задача. Вы не сможете просто взять какую-то маленькую таску, написать для неё код, ну и всё, типа закрыть задачу, всё отлично, я там написал код. Всё, такого больше не будет. Поэтому не время расслабляться. Ну, разработчику, в

Speaker A

принципе, некогда расслабляться, когда настолько быстро всё изменяется. Вам постоянно сейчас нужно изучать новые знания и расширять свой стек. Хочу вам привести один рабочий пример рабочего флоу, который я тоже использую.

Speaker A

Допустим, смотрите, вот поступают, вот у вас есть там какая-то доска, там G, RocketLab, неважно. Туда поступают различные тикеты, задачки, допустим, какой-то баг, либо задачка небольшая. То есть уровень задачки он не слишком большой, и, в принципе, его можно сделать автоматически. Она не требует

Speaker A

там какого-то проектирования, принятия каких-то бизнес-решений. И агенты, они же могут автоматически перехватить эти задачки. Они могут автоматически создать изолированные ветки. Они могут автоматически применить все нужные скилы. Они могут автоматически сделать всё ревью, провести тесты и полностью либо пофиксить, либо реализовать эти

Speaker A

небольшие фичи. Дальше всё создаётся merch request, создаются отчёты, и человек это всё проверяет. То есть тот человек, который настроил всю эту систему, он, ну, получит огромный плюс, потому что он уже будет не а брать каждую задачку отдельно и вручную с ней

Speaker A

работать, да? Ну, понятно, что над серьёзными задачами, которые требуют именно человеческих решений, мы так и работаем. Мы запускаем локальны агентов, но мы можем настроить систему, когда, допустим, в поддержку кто-то что-то пишет, да, в поддержку там человек пишет, а, какую-то проблему описывает,

Speaker A

мы понимаем, что агент может сам взять и обработать эту проблему. То есть мы можем и сторону поддержки закрыть, и сторону именно если это какой-то баг системы закрыть. И то, и то агент может взять автоматически, а человек просто это потом проверит, примет решение, если

Speaker A

нужно, возьмёт локально на себя работу, ну и доведёт всё это до результата. То есть такие вот решения сегодня реально работают, и их можно выстраивать и применять даже в своих проектах. Давайте поговорим немножко про оркестрацию. А сегодня модное слово, там Иненеринг

Speaker A

клуб, там циклы, оркестрации. На самом деле какая-то оргистрация уже встроена в модных, крутых современных агентов типа клаудкода, кодекса, потому что они сами умеют создавать уже субагентов, они сами умеют параллелить задачи, они сами умеют уже прогонять циклы. И, в принципе, для

Speaker A

этого отдельный оркестратор не нужен. Они сами хорошо проверяют, ну, справляются с этими задачами. Но почему нужно осторожно относиться к всяким там кастомным ручным оркестраторам либо каким-то скилам, методологиям, оркестрации, где у вас там 100 агентов запускаются, они полноценно выполняют

Speaker A

весь там рабочий цикл и автоматизация вообще там полноценная, все задачи сами закрываются, человек не нужен.

Speaker A

Во-первых, это очень дорого, потому что параллельные агенты, они съедают очень много токенов. То есть, если вы сделаете такую систему, которая у вас будет работать там 24х7 и там решать постоянно всякие задачки, во-первых, ну как вы это проверять будете? Во-вторых, какие задачки

Speaker A

решаться будут, да, как вы вообще уследите за тем, что происходит, и плюс у вас ещё 1.000 млрд токенов сожётся. В общем, это сейчас так не работает. Это всё довольно сложно контролировать. Ну и в целом агентов сегодня нужно уметь

Speaker A

правильно контролировать. То есть нужно делать ревью, следить за отчётами, следить, что они вообще делают. Да, конечно, есть сейчас какие-то отдельные, э, параллельные системы, которые работают в отдельных командах. Но, во-первых, они, ну, там большие должны быть команды, а чаще большие корпорации

Speaker A

там в том же Ароopic Open, понятно, да, почему они это делают, но на них всё ещё рано делать ставку, потому что, а, сначала мы делаем обычный цикл в проверке с одним агентом. То есть мы сначала человек должен, вот human in the

Speaker A

loop, человек должен выстраиваться эту систему, чтобы контролировать пока что, ну, может быть, не каждый шаг, но, по крайней мере, вот до и после он должен контролировать обязательно. Если у вас уже этот процесс хорошо налажен, то, конечно, его можно масштабировать. Но

Speaker A

пока что таких систем именно полноценных, автоматизированных, я не видел и особо о них не слышал. Ну и если смотреть на сегодняшнюю реальность, то 100% кода в Antropic уже пишет Cloud код, а 75% нового кода в Google генерирует АI, а 74 -ре92%

Speaker A

пулреквестов от агентов принимают в рутинных правках, а в новых фичах лишь 3565. То есть мы видим, что много преквестов принимаются прямо автоматически, а если это какая-то новая фиша, то принимается от 30 до 60%. То есть мы видим, что тут разброс большой.

Speaker A

Всё, на самом деле зависит от контекста реальных задач. То есть в продакшене мы видим, что агенты, они работают под присмотром инженера. Агент сам может доводить рутинную задачу до готового плуреквеста. Параллельные агенты, они уже существуют, они работают. В принципе, это не так сложно, да, это

Speaker A

когда просто, а, разные задачки, которые вместе не состакуются, разделяются на параллельных агентов. Но мы обязательно проводим ревью. Пока ранняя стадия, это полностью автономные фичи. То есть они могут реализовываться, но обязательно большая работа до подготовительная, так сказать, и обязательно большая работа

Speaker A

после тестирования всего этого. Полноценной какой-то, опять же, автоматизированной регистрации пока не существует. Обязательно в какие-то точки вставляется человек, который за всем следит и всем этим управляет. Ну и, естественно, никакие агенты инженеров не заменяют. наоборот, есть новости в Telegram-канале даже публиковал, что те

Speaker A

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

Speaker A

повышается. Поэтому что мы можем сказать? То, что вам нужно всему этому учиться. Вам нужно сегодня работать, умегентами. Вам нужно в своих реальных проектах, независимо от того, пишете ли вы код на тайpesскрипте, GO, C#P, Java, Python, вообще неважно, вы должны уметь

Speaker A

внедрять агентов. Вы должны уметь разбираться и в бэкэнде, и в фронт-нде, и в девопсе, и в инфраструктуре. Вы должны полноценно доводить все эти фичи от нуля и до конца. У вас должна быть реально хорошая инженерная база. Плюс опыт. Вот опыт. Как же сегодня будет

Speaker A

цениться опыт? Вам очень нужен опыт, чтобы вы могли с этим всем работать. Поэтому делайте ПД-проекты как можно больше. Какие-то свои САС решения, какие-то, не знаю, системы, просто инструменты для личных задач, которые можно автоматизировать. Попробуйте решить эту проблему. Сегодня реально

Speaker A

огромное количество есть для этого возможностей. Уже сегодня 68% разработчиков ждут, что навыки работы с АИ станут требованием профессии. Я могу сказать, что они уже сегодня становятся требованием профессии. От региона к региону немножко разные, от работы к работе, там компании от компании

Speaker A

немножко разные требования. Где-то у нас там закрыто контра, где-то вообще ничего не используется. Но все всё понимают.

Speaker A

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

Speaker A

всё это используют. Вместо код, ну, хотя тут можно поспорить с тейком. Это тейк мне предложил агент сам, что на собеседованиях уже больше дают ревью там дефектного какого-то кода, проектирование системы, понимание инженерных основ. Это я согласен. Но всё равно те же самые алгоритмы, те же самые

Speaker A

вопросы, там про язык с подковырками там, да, про асинхронность, там garbage коллектор, про перемены value обжекты, не value обжекты, всё это остаётся до сих пор и является очень важной частью любого собеседования пока что. Ну, к сожалению, я считаю, почему к сожалению,

Speaker A

потому что вопросы они повторяются из года в год одни и те же. Мы просто заучиваем теорию, идём на эти собеседования, проговариваем одно и то же, да, вместо того, чтобы подумать над какой-то, возможно, интересной задачкой, либо спроектировать систему, либо, ну,

Speaker A

просто на собеседовании решить конкретную задачу со всеми инструментами, которые у вас есть. Допустим, там вы можете использовать и агентов, и нейронку, и вы просто показываете, как вы работаете, и в итоге решаете какую-то задачу. Мне кажется, вот такой формат был бы лучше всего.

Speaker A

Вот. А что думаете вы? Напишите в комментариях, ну или переходите в мой Telegram-канал, где планируется ещё много интересных анонсов. Также это мне агент сам тут написал, что Typeesриpt - это язык номер один. Я могу с этим согласиться только, ну вот, что он в

Speaker A

топе популярности - это язык номер один, потому что агентам нужна типа безопасность как быстрыя обратная связь.

Speaker A

Но на самом деле типа безопасности у нас есть там и в C-#P, и в других языках, там и в Джаве, и так далее, но [фыркает] не в этом суть. Он, да, популярный, потому что огромное сегодня количество есть каких-то там САС решений, а личных

Speaker A

проектов. Ну и, конечно, на Тайпскрипте всё это сделать очень быстро. какой-нибудь Reactфorк используйте, там Next, Nest, вы можете и backend, и фронтend, и Fstaк, любое приложение на нём сделать. Это всё понятно. Но тут надо смотреть именно на то, какой стек

Speaker A

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

Speaker A

Там где-то много где используют GO, много где используют C-#P, много где используют Java, Pyon, то есть всё то же самое осталось. Но вот что мне кажется, так это то, что акцент на том, какой конкретный язык программирования вы знаете и вы используете, он будет всё

Speaker A

меньше, потому что уже существовали такие вакансии там на софтуер инженера уже достаточно давно, когда вы приходите на собеседование, а вы, допустим, решаете какие-то алгоритмические задачки на языке, котором вы знаете, вас потом нанимают, то есть вы проходите там собеседование по систем-дизайну, по

Speaker A

архитектуре, по решению каких-то других задачек, по какой-то базе. Да, вас не будут там спрашивать в этих компаниях на такую позицию, как там работает, не знаю, лист в таком-то языке программирования, либо как работает garbage колектор в там в C#P либо в

Speaker A

Java. Да нет, вас о таком не буду спрашивать. И когда вас нанимают на работу, вас уже просто распределяют в команду, где может быть совсем другой стек, который вы не знаете. То есть вы знаете GO, а там, допустим, C#P, да? Ну

Speaker A

и вам дают просто месяц на адаптацию, и вы уже пишете на C#пе. Потому что на самом деле, если вы знаете какой-то хотя бы, ну, хорошо, если вы знаете один язык программирования, то влиться в новый вообще не составит труда. Тем более,

Speaker A

когда вам даже не нужно сегодня писать код на этом языке программирования. Поэтому моя позиция такая: какой вы язык бы не знали, вам нужно качать инженерные навыки и смотреть в сторону вакансий Software Engнеer. То есть, что там требуется, вот это будет скоро везде,

Speaker A

да? Ну, нигде не будет то, что там juniниor, C#P разработчик. Нет, будет какой-то там софtare инженер, либо там AI productду инженер, либо что-то такое, да, который челик умеет решать, доводить задачки до конца. Итак, как я это сегодня вижу? Вам нужно тренировать и

Speaker A

изучать инженерную базу, да, доводить её до идеала. Это уметь работать с продакшеном, уметь закрывать архитектуру инфраструктуру доводить в общем-то, фичи результата. Вам нужно уметь выстраивать среду для агентов. Это формировать правила MCP, контекст задачи, контекст проекта. Потому что, опять же, каких-то волшебных промтов не

Speaker A

существует. Это формировать скилы, это следить за трендами, постоянно изучать какие-то новые инструменты сегодня очень часто появляются. Я там в свои проекты регулярно постоянно что-то новое внедряю тот или иной там формат документации, тот или иной формат там пайплайнов каких-то всё это внедряют. тестирую и

Speaker A

использую, да, это тоже обязательно. И уметь правильно проводить инженерный цикл, ну, то есть применять его. Это ресёрчить, составлять план, продумывать требования к задаче, продумывать вообще, что должно получиться в итоге, видеть вот эту целую картину целиком, а потом реализация с помощью агентов, ну, и,

Speaker A

соответственно, всё это проверять грамотно. Ну и дальше идёт оркестрация. Может быть, сейчас это ещё не так актуально, да, потому что всё ещё это очень дорого, но всё дальше дальше, да, это всё будет становиться дешевле. и работа с параллельными агентами,

Speaker A

управление там большими досками, большим объёмом задач, работа с субагентами. Но это больше уже конкретно будет заниматься этим всем какой-то инструмент. А в принципе ваша задача - это работа до, работа после, как я уже говорил, и, в принципе, понимание вот

Speaker A

этих всех тонкостей какого-то вашего проекта конкретного, вашего продукта. Как итог, я могу сказать, что искусственный интеллект, он усиливает сильного инженера, и понимание системы он ни в коем случае не заменяет. Работы меньше, к сожалению, её не стало.

Speaker A

Решение, ревью, сложные задачи, контроль процессов, они остаются, все эти задачи на инженере. И поэтому я скоро буду запускать A First направление. То есть это будет AI First курс, где я буду делиться всем своим опытом. Короче, следите за анонсами в Telegram-канале.

Speaker A

будет реально очень жёстко. У меня много всего запланировано, много ещё видосов, контента, идей. И вот эта область, она сейчас каждый день развивается, и она очень интересная. Можно делать реально очень прикольные штуки. Не забывайте подписываться на канал, оставлять комментарии, ставить лайки,

Speaker A

подписывайтесь на Telegram, обязательно канал. Спасибо за просмотр этого видео. y

Topics:AI-агентывеб-разработкамашинное обучениеLLMCodexCloud Codeharnessтерминалавтоматизация коданавыки разработчика 2026

Frequently Asked Questions

Что такое AI-агент и чем он отличается от обычной LLM?

AI-агент — это LLM с дополнительным слоем инструментов, который может взаимодействовать с проектом, изменять файлы, запускать команды и управлять устройством, в отличие от простой модели, которая только отвечает на вопросы.

Какие инструменты и модели Кирилл рекомендует для разработки с AI-агентами?

Кирилл рекомендует использовать Codex и Cloud Code как основные агенты для кодинга, а также упоминает open source решения и китайские модели как более доступные альтернативы.

Почему важно изучать терминал и CLI для работы с AI-агентами?

Работа через терминал позволяет удобно запускать множество сессий и агентов параллельно, управлять ими и использовать дополнительные инструменты, что повышает эффективность и комфорт работы с AI-агентами.

Get More with the Söz AI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries, speaker detection, and unlimited transcriptions.

App Store Google Play

Or transcribe another YouTube video here →

Free tools: TXT to SRT · SRT Validator · Merge SRT · Subtitle to Text · All tools