Transcription
Всем привет. Меня зовут Кирилл, и я, как синьор разработчик, хочу поделиться с вами своим опытом использования агентов, использования ИИ в разработке, а именно веб-разработке. Ну и, в принципе, поговорить о том, куда это всё движется, рассказать вам про современные инструменты, рассказать вам про свои пайплайны, как я это всё использую, а как это влияет на найм, а что сегодня уже востребовано, что делать новичкам, что делать людям уже, которые имеют опыт, как им оставаться актуальным, какие навыки и знания сегодня очень важны для всех, ну и как будет выглядеть в будущем, в принципе, разработка.
Уже сейчас она очень сильно поменялась. Уже сейчас почти везде код никто не пишет руками. Поэтому здесь возникает вопрос, что делать и новичкам, какие сегодня инструменты использовать актуально, каких агентов использовать. В общем, постоянно тут всё меняется. Поэтому хочу сделать видео и поделиться прямо своим опытом, рассказать про текущую ситуацию. Потому что, если вы до сих пор не используете агентов на максимум, вы, наверное, много упускаете, потому что я знаю, что многие люди не используют их там даже на половину, постоянно задают вопросы, ответы на которые, мне кажутся уже очевидными.
Вот примерно дорожная карта, о чём мы поговорим, про инструменты, про понятия, по побольше про контекст и какую роль он сегодня занимает, про инженерный цикл разработки, про оркестрацию, ну, и чему, в принципе, сегодня нам нужно всем учиться.
Давайте сначала поговорим о понятиях. Я думаю, все знают, что такое LLM. Это нейронка, моделька, которая умеет понимать контекст, умеет отвечать на ваши вопросы, но она не умеет взаимодействовать с внешним миром. Это мы все знаем, это понятно. Чатбот тоже уже все используют. Это просто диалог с моделью в браузере. Там ChatGPT, Claude, не знаю, DeepSeek - это всё база.
Дальше уже появились агенты, и это прямо интересно. Сейчас я считаю, что, ну, в принципе, все разработчики должны уметь с ними работать, должны уметь их использовать. Ну и вот всё, о чём я поговорю дальше, они должны уметь это внедрять в свои проекты, ну и на работе тоже, чтобы быть гораздо эффективней и приносить больше пользы.
Значит, что такое агент? Это у вас есть та же моделька, та же моделька, но у вас уже есть дополнительный слой инструментов. Он умеет читать проект, понимать контекст, изменять файлы. Он умеет работать с терминалом, запускать все команды, есть различные плагины, то есть он может управлять вообще вашим устройством, он может подключаться к серверам по SSH, он может там создавать субагентов, то есть он полностью владеет буквально компьютером. Ну, как будто это человек. То есть это и правда сейчас мощный инструмент.
Но дальше идёт штука поинтереснее. Это harness. Он недавно этот термин появился. Ну и ничего нового, на самом деле, он не обозначает. Это просто среда, обвязка, рабочая область вокруг вашего агента. То есть это набор промтов, набор скиллов, набор правил различных, набор инструкций, набор плагинов, MCP и ваш сам проект. Какая-то структура хранения, а памяти, это структура там пайплайнов, которые вы используете, workflow, всякие проверки, дополнительные инструменты, там всякие скрипты и управление контекстом. Вот вот это вот всё, что находится вокруг агента. Ну, условно, ваш какой-то там проект репозиторий. Плюс вокруг всего этого оболочка, это уже будет harness.
По сути, harness - это просто название. Вот оно это и означает. И на самом деле, вы можете использовать агента, допустим, Claude Code, вокруг него настроить всю эту рабочую среду, и у вас получится harness. Ну и сам по себе, на самом деле, сегодня тот же Code Llama, Code Llama, не знаю, OpenCode, это уже там harness, это уже сами по себе harness, но вы вокруг ещё наполняете его контекстом, да, и делаете его максимально полезным для себя, ну или для работы.
Ну и оболочка - это то, через что вы работаете сегодня с агентом. Это через IDE, через терминал. То есть это CLI решение, это какое-то десктопное приложение, либо через web можно работать. Я, наверное, 50 на 50 работаю либо через терминал, либо вот последнее время мне очень нравится Code App. Там прямо много возможностей, но я уже давно не использую именно IDE для этого, потому что, ну, не очень удобно, гораздо удобнее работать с этим через терминал. Можно удобно запускать параллельно много сессий, много агентов. Ну, и в самом терминале куча есть юзкейсов дополнительных, а, для IDE, и для управления, перемещения между папками. В общем, довольно удобная штука. Вот всем рекомендую осваивать терминал. Это вот совет номер один.
Есть отдельные бенчмарки, которые сравнивают работу агентов. Ну, точнее, уже harness их называют. Это Claude Code, там есть ещё Open Code. В общем, есть сайт Terminal Bench, можно там посмотреть. Ну, я бы не сказал, что они прямо очень много говорят. Там не все агенты есть. Многие компании делают вообще своих агентов. Ну, и в принципе агент - это когда вы, а, LLM даёте возможность использовать инструменты там вызова, там, не знаю, чтения файлов, вызова каких-то там тулов, скиллов и всего остального. Это довольно сложно сделать, поэтому все используют готовые решения. Тот же Claude Code, Code Llama, это сейчас, конечно, мастодонты, это прямо топ на рынке, все их используют. В, по крайней мере, своих проектах на работе часто в компаниях используют либо китайские open source какие-то модели, либо своих агентов, либо более open sourceные решения, типа там open-code того же самого.
Ну, и вот список решил вывести популярных агентов. Ну, это понятно Claude Code. Вот модели, последняя модель - это Fable Opus 4.8. Недавно был Fable немножко ограничен. У Code Llama совсем недавно вышел 5.6 Sol. Мне он очень прямо нравится, на самом деле. Сильно прямо поумнел. Автономно может работать, ну, прямо много времени. Мне очень нравится. Также есть OpenCode. Его можно использовать со многими моделями, то есть там просто подключается провайдер либо APIшка. То есть вы можете использовать либо с GPT 5.6 моделью, либо с тем же там Kai AI. То есть их довольно много. Вот ниже они показаны. DeepSeek, GLM, Kai, вот недавно вышел K3. Довольно мощная модель GLM 5.2. Скоро там ещё новая выйдет. В общем, они все на самом деле идут прямо впритык к американским моделям и постоянно как бы на шаг позади, но при этом они open sourceные, при этом они дешевле, поэтому вы тоже можете их использовать. И сегодня, если хорошо настроить пайплайн, если хорошо настроить именно контекст, то это можно будет довольно всё удобно использовать.
И я в Telegram-канале скину скилл, а, который я сделал, чтобы настроить окружение аналогично моему. Дальше мы его разберём, но там будет весь мой стек, то есть я там расскажу, что и как я использую, и, в принципе, вы сможете аналогично тому, как это сделано у меня, поднять всё это у себя и настроить под свои проекты, да, то есть поэтому заходите в Telegram-канал, подписывайтесь, там ещё будет много чего полезного.
Как ещё можно использовать агентов? Как ещё можно использовать AI для разработки, для из своих каких-то нужд? Да, то есть, да, конечно, там 90% случаев, наверное, я использую агента именно для разработки, для своих проектов, для платформы моей, ну, и также использую для личных задач, в том числе использую Hermes. Он у меня поднят вообще на отдельном сервере. У него есть интеграция с Telegram, поэтому я его использую через мессенджер. Удобно там записывать голосовые, кидать какие-то файлики, там запускать личные задачи. То есть можно кидать туда документы, всякие напоминалки. То есть довольно удобно. Hermes рекомендую.
И для кодинга лучше всё-таки использовать либо Code Llama, либо Claude Code. Ну, сейчас в последнее время Code Llama прямо выходит вперёд, поэтому рекомендую его. Ну, либо, если для вас это дорого, то используйте китайскую модельку в сочетании, допустим, с тем же OpenCode. Либо я знаю, что даже с Claude Code можно, так как Claude Code - это именно агент, а LLM модель вы можете использовать любую. Можно настроить в сочетании с Claude Code тот же DeepSeek, я знаю V4 Pro, ну, тоже неплохая комбинация, но для кодинга довольно слабоват.
Кто-то использует агентов через IDE, Cursor, понятное дело, VS Code GitHub Copilot, есть ещё такая штука через Getpins, а, какие-то редакторы, аддоны, но мне не нравится такой подход. Они менее гибкие, чем через терминал, либо чем использование голых вот этих агентов. Да, Cursor вроде неплох, но я его использовал довольно давно ещё, и он очень сильно поедал лимиты. Сейчас вроде как там выходит Grok, и он интегрируется с Cursor. Может, там лимиты нормальные, но опять же, э, если вам нужно именно дебажить, делать там ревью каждой строчки, да, и вы и там вы хотите прямо безопасно писать код и только учитесь, например, писать код. Вот больше даже это подходит для тех, кто только учится писать код. Вы, конечно, используете либо Cursor, либо какую-то IDEшку, но в целом тренды сейчас такие, что мы уже даже и не делаем ревью каждого кусочка кода, да, об этом мы поговорим дальше. То есть там уже тренды меняются, конечно, подход разработки меняется.
И вот на что я хочу сделать акцент, так это то, что магических промтов не бывает, магических скиллов не бывает, как это раньше, знаете, вот какой-то промт, набор промтов, там, используй их и, а, в один промт разработай какое-то большое приложение, которое будет вам зарабатывать деньги, которое будет хорошо работать. Нет, ну так не бывает. До сих пор они плохо с этим справляются. Ну, и в принципе, в большом каком-то бизнесе, где у нас большие, сложные бизнес-процессы, это, в принципе, невозможно.
Очень сейчас важно это какой контекст находится вокруг вашего агента. То есть мы видим, что агент без контекста. У нас результат непредсказуемый. Но если мы настроим правила для проекта или для проектов, если мы настроим тесты, если мы настроим автоматическое ревью, настроим, как у нас будет храниться память, контекст нашего проекта, контекст наших задач, очередь задачек, то есть заведение эпиков, и вот это вот всё, настроим MCP, выберем правильную архитектуру, настроим целый, не знаю, список огромных скиллов, у них есть тоже вложенности, будем поддерживать документацию, настроим пайплайны, то тогда мы уже будем чаще намного получать предсказуемый результат. И вот опять же вот эта вот схемка, это по сути называется их harness, то есть правила, скиллы, пайплайны, тесты, архитектура проекта. Это можно назвать единым словом harness ваш личный, который будет на вас работать и выполнять ваши задачи.
Тут стоит сказать пару слов о том, как я это использую. У меня есть мой репозиторий SCOS, он приватный. Там у меня хранится вся информация обо мне, вся информация о моих проектах. Там я использую такой паттерн, то есть такой инструмент, как LLM Wiki - это специальный формат хранения MD-файлов, так чтобы ваш агент удобно с ними работал. То есть это моя база знаний, там у меня хранится память о том, какие у меня есть проекты, какие решения я принимаю, различные заметки. Там у меня есть список задач, там менеджер, есть очередь этих задач и огромное количество скиллов, пайплайнов, инструкций. Ну, в принципе, это не обязательно, если вы делаете какие-то там личные проекты либо на работе используете. Это больше интересно и полезно для личного использования, либо если вы работаете над несколькими проектами. Ну, а так, в принципе, каждый какой-то проект может содержать свою LLM Wiki, свой набор там инструментов, пайплайнов там, а, и всего остального, да, и использовать это изолированно.
Но так как я работаю над несколькими проектами, и, в принципе, каждый человек сейчас может настроить такое хранилище, настроить, прикрутить к этому Hermes, а, развернуть его, допустим, на сервере, чтобы он постоянно работал, подключить Telegram, и вот у вас получается отличный агент, с которым можно проводить ресерчинг, можно что-то обсуждать, делать там напоминания, управлять задачами, проводить ресерчинг. Ну, и плюс Hermes имеет прикольную систему скиллов. Он их постоянно улучшает, чистит, добавляет новые. Поэтому я его часто использую, даже когда я просто, ну, работаю с компьютера в моей основной рабочей сессии.
А, ну, и для кодинга, для ведения проектов, даже для генерации вот визуала, который вы сейчас видите, для всего этого используются именно агенты. То есть я не делаю это вручную. Это основная работа с кодом, основное ведение задач, это какой-то, может, тоже ресерчинг. То есть это, ну, основная работа, где я параллельно запускаю много разных сессий и работаю и с Claude, и с Code Llama. При этом я работаю со всем этим одновременно. Из-за того, что у меня несколько агентов с разных устройств могут работать с одним и тем же репозиторием. У меня настроена эта полная синхронизация. То есть с помощью GitHub hooks, с помощью коммитов, пушей, всего этого, да, у меня поддерживается синхронизация. То есть какой-то агент на сервере внёс какое-то изменение, он сразу всё это пушит. Значит, локально у меня все эти агенты сразу это всё подтягивают.
Также я в Telegram-канале скину, а, то, как я оплачиваю все сегодня вот эти вот сервисы, э, чем я пользуюсь вообще и как я оплачиваю всех, все эти подписки, все многочисленные подписки, которые, к сожалению, надо оплачивать. Короче, заходите в Telegram-канал.
Давайте вот пример моего Task пайплайна. То есть это пайплайн по выполнению одной какой-то задачки. На самом деле дальше вот мы говорим подробнее, как это всё делается, но сначала формируется задача в GitLab. То есть у меня есть тоже на отдельном сервере у меня развёрнут GitLab, где для моих проектов всех хранятся задачки. То есть они хранятся в их ремесе в LLM Wiki, но для конкретных проектов, допустим, для моей платформы у меня там отдельный список именно GitHub задач, чтобы это вот как в Kanban доске у меня всё управлялось, да, чтобы у меня открывались pull requests, они все были присоединены к задачкам. В общем, довольно удобно, это полезно настроить. Ну, и ближе именно к коммерческой разработке.
Сначала я с помощью агента провожу ресерчинг. Я обсуждаю все требования. Я формирую контракт именно задачи, как он связан с другими задачами. Я формирую именно его какой-то контекст этой задачи. А что должно происходить? Как она должна решаться? Я её полностью проектирую, как она должна, не знаю, в систему вливаться, провожу ресерчинг, а обсуждаю всё это с агентом, выстраиваю план с шагами подробными. У меня уже к этому времени, конечно, настроена архитектура в моём проекте. Уже настроена там куча скиллов, как с этим всем работать. Потом агент создаёт отдельную ветку Work 3, то есть отдельную изолированную копию по сути репозитория и начинает там полную реализацию. Потом он там на каждом шагу проводит именно свою self-review, то есть свою проверку. Естественно, он постоянно пишет тест, всё это тестирует. Потом, когда он завершает, уже начинается ручная проверка, но сначала проводится изолированная проверка, как бы независимая другим агентам. Плюс ещё проверяется именно сам функционал автоматический агентом, то есть с помощью плагина либо Computer Vision, либо в браузере он может это всё запустить с помощью Playwright, а либо могут прогнаться end-to-тесты. В общем, полное тестирование проводится этой фичи.
Дальше уже агент формирует отчёт, он говорит, что он сделал, какие важные там изменения он внёс. А можно также настроить всё это систему сделать hooks, систему ограничений, чтобы он не влезал в вашу систему, не там залезал за рамки вашего проекта. Плюс можно настроить, чтобы он, ну, понятно, генерировал отчёты. И если он влезает в какую-то, допустим, важную бизнес-логику, то он останавливался и как-то с вами это обсуждал. Либо отдельно в отчёте прямо писал, допустим, вот изменена такая бизнес-логика, сам обновлял документацию, сам закрывал задачу, всё это открывает Merge Request и дальше уже всё это проверяю я, чтобы понять, как это работает. Он локально у меня запускает всё, что он сделал, то есть проект. А, и я всё это проверяю, да, я потом смотрю код, смотрю, всё ли хорошо. Ну, и задача выполнена. Отлично. В принципе, что мне ещё нужно от него?
И вот сейчас, на самом деле, работа современного разработчика, она сместилась немножко с написания кода. Немножко в другие стороны. Во-первых, а вот как у нас раньше было, мы просто пишем код, и в основном это занимает у нас большую часть времени. Ну, хотя нет, у нас очень много времени занимало именно придумывание, как мы будем решать эту задачу. Мы вникали в проект, мы разбирались, что как там работает, как это связано, и потом только вот написание, реализация, когда мы уже поняли, как это всё сделать, реализация, вот чисто написание кода, оно занимало какое-то время. И вот сейчас всё это время у нас, получается, делает агент, а мы вместе с ним мы начинаем с ним обсуждать задачу. Мы начинаем с ним понимать, как эта задача решается. Мы вникаем в бизнес, мы проводим реарчинг, делаем анализ, мы с ним составляем весь план. То есть видим, что работа, она на самом деле сместилась немножко на так сказать другой вектор приняла. А мы именно до того, как происходит выполнение, проводим на самом деле значительную работу потому, а, чтобы настроить агента и сказать, как всё это будет выполняться, да, чтобы он не наплодил ошибок, чтобы у нас все тесты прошли, чтобы все бизнес-требования были соблюдены. И это, на самом деле, большая, достаточно тяжёлая работа. И чем больше проект, тем больше у вас времени будет она занимать.
Ну, и, конечно, работа после, то есть, так как мы уже код почти не пишем, а мы делаем его ревью, мы смотрим тесты, мы проводим сами ручное тестирование, мы читаем отчёт, мы проводим какую-то независимую верификацию либо с помощью других агентов, конечно же, сами мы всё это проводим. Ну, и задача считается завершённой, когда все проверки пройдены, ну, и человек сам лично подтверждает результат, тем самым берёт на себя ответственность за выполненную задачу. То есть мы видим, что роль современного разработчика, она сместилась от написания кода до вот этих всех вещей, которые я сейчас вам проговариваю.
И что показывают современные исследования? То есть мы видим, что использование агентов, во-первых, удвоилось за год. То есть люди уже всё чаще используют именно агентов, да, до сих пор очень много людей пользуются просто либо чатиком, либо какими-то там подсказками в IDE, но прямо полноценно агентов использует очень мало человек. Мне от этого реально грустно, потому что, ну, ну, потенциал прямо очень большой, на самом деле, у этого всего. Мы видим всё большее количество именно AI навыков, требования к AI навыкам в вакансиях, то есть компании ищут уже умеющих сотрудников работать с агентами. Поэтому сегодня это довольно важно. Но при этом, да, мы можем посмотреть, что метрики в компаниях пока что эффекта какого-то не возвели, да, процессы они перестраиваются довольно медленно. То есть мы видим, что pull requests больше, кода больше. Но фичи они быстрее не выходят, на самом деле. А потому что код пишется быстрее, но никогда код не был узким горлышком. То есть сейчас гораздо больше разработчики делают ревью, но на самом деле это всё потому, что процессы перестраиваются довольно медленно. Плюс бизнес может нести должен, то есть и несёт ответственность за то, что если что-то пойдёт не так, он потом расплатится за это деньгами. Поэтому мы должны быть уверены, что критические секции работают правильно, что ошибок меньше.
Но а тут многие скажут типа вот это и пузырь, на самом деле, и неэффективно, на самом деле нет. Да, можно лишь посмотреть на то, что, ну, сейчас все используют, в вакансиях требуются. От разработчика всё меньше уже требует знания какого-то конкретного языка. Да, вакансии всё ещё очень много, большинство вакансий. это там C# .NET разработчик, Java разработчик, Go разработчик, но всё больше тебя спрашивают уже о, в принципе, инженерной базе. Всё больше тебя спрашивают о том, а как работают там всякие механизмы, инструменты какие-то, там брокеры, знаешь, как работают микросервисы, как выстраиваете архитектуру. А всё больше спрашиваю тебя про в целом понимание, а, разработки бизнес-процессов, там, структуры данных. Да, понятно. Всё ещё часто тебя будут спрашивать на а собеседованиях там, а как устроен лист, как, не знаю, работает многопоточка, как работает garbage collector, там как работает асинхронность, всё это понятно, но есть будет, скорее всего, ещё довольно долгое время, но тренд мы видим уже сегодня. Но это означает, что нам нужно перестраиваться и постоянно изучать какие-то новые знания. Инженерная база стала ещё важнее. Без неё не удержать контекст проекта.
Ну, и, в принципе, без навыков. Вот мой основной ещё тейк такой. Многие думают, там, я схожу с ума по агентам, нейронкам, но мой тейк такой, что на самом деле навык программирования, вот эта инженерная база, она очень нужна. И как будто она становится всё ещё более востребованней, потому что она как бы умножает ваш потенциал. То есть, если у вас он плохой изначально, если ваши навыки плохие, но она эти навыки и умножит в минус, как бы, да. Если у вас навыки крутые, у вас хорошая есть база, у вас хорошие знания есть, то вы сможете сделать прямо, не знаю, x10 от того, что вы бы могли делать вручную. Поэтому очень важно сегодня понимать процесс целиком, от как реализуется какая-то фича, начиная от идеи до продакшена. И поэтому, кстати говоря, сегодня разработчики там узконаправленные, допустим, просто backend-разработчик там либо frontend-разработчик уже становятся менее востребованными. Всё больше ценятся именно full-stack разработчики, которые знают и backend, и frontend, и devops, да, они умеют, в принципе, взять фичу какую-то, проанализировать проект, проанализировать бизнес и реализовать её, внедрив систему. То есть написать пайплайны, написать код, всё это проверить, настроить агентов, всё это дело автоматизировать и влить в продакшн, настроить деплой и поддерживать инфраструктуру, принять там правильные решения об архитектуре, принять решение там какую базу данных использовать, какую очередь использовать, асинхронно, не асинхронно, там какие микросервисы, как домен правильно построить. Всё это как раз-таки и будут теперь ваша задача. Вы не сможете просто взять какую-то маленькую таску, написать для неё код, ну, и всё, типа закрыть задачу, всё отлично, я там написал код. Всё, такого больше не будет. Поэтому не время расслабляться. Ну, разработчику, в принципе, некогда расслабляться, когда настолько быстро всё изменяется. Вам постоянно сейчас нужно изучать новые знания и расширять свой стек.
Хочу вам привести один рабочий пример рабочего flow, который я тоже использую. Допустим, смотрите, вот поступают, вот у вас есть там какая-то доска, там Jira, RocketLab, неважно. Туда поступают различные тикеты, задачки, допустим, какой-то баг, либо задачка небольшая. То есть уровень задачки он не слишком большой, и, в принципе, его можно сделать автоматически. Она не требует там какого-то проектирования, принятия каких-то бизнес-решений. И агенты, они же могут автоматически перехватить эти задачки. Они могут автоматически создать изолированные ветки. Они могут автоматически применить все нужные скиллы. Они могут автоматически сделать всё ревью, провести тесты и полностью либо пофиксить, либо реализовать эти небольшие фичи. Дальше всё создаётся merge request, создаются отчёты, и человек это всё проверяет. То есть тот человек, который настроил всю эту систему, он, ну, получит огромный плюс, потому что он уже будет не брать каждую задачку отдельно и вручную с ней работать, да? Ну, понятно, что над серьёзными задачами, которые требуют именно человеческих решений, мы так и работаем. Мы запускаем локально агентов, но мы можем настроить систему, когда, допустим, в поддержку кто-то что-то пишет, да, в поддержку там человек пишет, а, какую-то проблему описывает, мы понимаем, что агент может сам взять и обработать эту проблему. То есть мы можем и сторону поддержки закрыть, и сторону именно если это какой-то баг системы закрыть. И то, и то агент может взять автоматически, а человек просто это потом проверит, примет решение, если нужно, возьмёт локально на себя работу, ну, и доведёт всё это до результата. То есть такие вот решения сегодня реально работают, и их можно выстраивать и применять даже в своих проектах.
Давайте поговорим немножко про оркестрацию. А сегодня модное слово, там AI Engineering, там циклы, оркестрации. На самом деле какая-то оркестрация уже встроена в модных, крутых современных агентов типа Claude Code, Code Llama, потому что они сами умеют создавать уже субагентов, они сами умеют параллелить задачи, они сами умеют уже прогонять циклы. И, в принципе, для этого отдельный оркестратор не нужен. Они сами хорошо проверяют, ну, справляются с этими задачами. Но почему нужно осторожно относиться к всяким там кастомным ручным оркестраторам либо каким-то скиллам, методологиям, оркестрации, где у вас там 100 агентов запускаются, они полноценно выполняют весь там рабочий цикл и автоматизация вообще там полноценная, все задачи сами закрываются, человек не нужен. Во-первых, это очень дорого, потому что параллельные агенты, они съедают очень много токенов. То есть, если вы сделаете такую систему, которая у вас будет работать там 24х7 и там решать постоянно всякие задачки, во-первых, ну как вы это проверять будете? Во-вторых, какие задачки решаться будут, да, как вы вообще уследите за тем, что происходит, и плюс у вас ещё 1000 млрд токенов сожрётся. В общем, это сейчас так не работает. Это всё довольно сложно контролировать. Ну, и в целом агентов сегодня нужно уметь правильно контролировать. То есть нужно делать ревью, следить за отчётами, следить, что они вообще делают. Да, конечно, есть сейчас какие-то отдельные, э, параллельные системы, которые работают в отдельных командах. Но, во-первых, они, ну, там большие должны быть команды, а чаще большие корпорации там в том же Anthropic Open, понятно, да, почему они это делают, но на них всё ещё рано делать ставку, потому что, а, сначала мы делаем обычный цикл в проверке с одним агентом. То есть мы сначала человек должен, вот human in the loop, человек должен выстраиваться эту систему, чтобы контролировать пока что, ну, может быть, не каждый шаг, но, по крайней мере, вот до и после он должен контролировать обязательно. Если у вас уже этот процесс хорошо налажен, то, конечно, его можно масштабировать. Но пока что таких систем именно полноценных, автоматизированных, я не видел и особо о них не слышал.
Ну, и если смотреть на сегодняшнюю реальность, то 100% кода в Anthropic уже пишет Claude Code, а 75% нового кода в Google генерирует AI, а 74-92% pull requests от агентов принимают в рутинных правках, а в новых фичах лишь 35-65%. То есть мы видим, что много pull requests принимаются прямо автоматически, а если это какая-то новая фича, то принимается от 30 до 60%. То есть мы видим, что тут разброс большой. Всё, на самом деле, зависит от контекста реальных задач. То есть в продакшене мы видим, что агенты, они работают под присмотром инженера. Агент сам может доводить рутинную задачу до готового pull request. Параллельные агенты, они уже существуют, они работают. В принципе, это не так сложно, да, это когда просто, а, разные задачки, которые вместе не составляются, разделяются на параллельных агентов. Но мы обязательно проводим ревью. Пока ранняя стадия, это полностью автономные фичи. То есть они могут реализовываться, но обязательно большая работа до подготовительная, так сказать, и обязательно большая работа после тестирования всего этого. Полноценной какой-то, опять же, автоматизированной регистрации пока не существует. Обязательно в какие-то точки вставляется человек, который за всем следит и всем этим управляет.
Ну, и, естественно, никакие агенты инженеров не заменяют. Наоборот, есть новости в Telegram-канале даже публиковал, что те там сокращения, про которые мы слышим, в основном сокращается поддержка, в основном сокращаются там, не знаю, менеджеры, дизайнеры, но именно люди, которые управляют разработкой, которые развивают продукт, которые управляют всеми этими агентами, добавляют новые фичи, которые как раз-таки приносят деньги, они наоборот, их найм повышается.
Поэтому что мы можем сказать? То, что вам нужно всему этому учиться. Вам нужно сегодня работать, уметь с агентами. Вам нужно в своих реальных проектах, независимо от того, пишете ли вы код на TypeScript, GO, C# .NET, Java, Python, вообще неважно, вы должны уметь внедрять агентов. Вы должны уметь разбираться и в бэкэнде, и в фронтенде, и в девопсе, и в инфраструктуре. Вы должны полноценно доводить все эти фичи от нуля и до конца. У вас должна быть реально хорошая инженерная база. Плюс опыт. Вот опыт. Как же сегодня будет цениться опыт? Вам очень нужен опыт, чтобы вы могли с этим всем работать. Поэтому делайте pet-проекты как можно больше. Какие-то свои SaaS решения, какие-то, не знаю, системы, просто инструменты для личных задач, которые можно автоматизировать. Попробуйте решить эту проблему. Сегодня реально огромное количество есть для этого возможностей.
Уже сегодня 68% разработчиков ждут, что навыки работы с AI станут требованием профессии. Я могу сказать, что они уже сегодня становятся требованием профессии. От региона к региону немножко разные, от работы к работе, там компании от компании немножко разные требования. Где-то у нас там закрыто контра, где-то вообще ничего не используется. Но все всё понимают. Все всё понимают. Поэтому это сегодня очень сильно востребовано. 80% вообще новых разработчиков, которые работают на GitHub, используют Copilot с первой, а, Copilot с первой недели. То есть, да, вот такая тоже тенденция есть. То есть мы видим, большинство разработчиков уже всё это используют. Вместо код, ну, хотя тут можно поспорить с тейком. Это тейк мне предложил агент сам, что на собеседованиях уже больше дают ревью там дефектного какого-то кода, проектирование системы, понимание инженерных основ. Это я согласен. Но всё равно те же самые алгоритмы, те же самые вопросы, там про язык с подковырками там, да, про асинхронность, там garbage collector, про перемены value объекты, не value объекты, всё это остаётся до сих пор и является очень важной частью любого собеседования пока что. Ну, к сожалению, я считаю, почему к сожалению, потому что вопросы они повторяются из года в год одни и те же. Мы просто заучиваем теорию, идём на эти собеседования, проговариваем одно и то же, да, вместо того, чтобы подумать над какой-то, возможно, интересной задачкой, либо спроектировать систему, либо, ну, просто на собеседовании решить конкретную задачу со всеми инструментами, которые у вас есть. Допустим, там вы можете использовать и агентов, и нейронку, и вы просто показываете, как вы работаете, и в итоге решаете какую-то задачу. Мне кажется, вот такой формат был бы лучше всего.
Вот. А что думаете вы? Напишите в комментариях, ну, или переходите в мой Telegram-канал, где планируется ещё много интересных анонсов. Также это мне агент сам тут написал, что TypeScript - это язык номер один. Я могу с этим согласиться только, ну, вот, что он в топе популярности - это язык номер один, потому что агентам нужна type-безопасность как быстрая обратная связь. Но на самом деле type-безопасность у нас есть там и в C# .NET, и в других языках, там и в Java, и так далее, но >> [фыркает] >> не в этом суть. Он, да, популярный, потому что огромное сегодня количество есть каких-то там SaaS решений, а личных проектов. Ну, и, конечно, на TypeScript всё это сделать очень быстро. Какой-нибудь React framework используйте, там Next, Nest, вы можете и backend, и frontend, и Fullstack, любое приложение на нём сделать. Это всё понятно. Но тут надо смотреть именно на то, какой стек используется в больших компаниях, то, что сегодня востребовано. И мы видим, что, в принципе, ничего не поменялось. Там где-то много где используют GO, много где используют C# .NET, много где используют Java, Python, то есть всё то же самое осталось. Но вот что мне кажется, так это то, что акцент на том, какой конкретный язык программирования вы знаете и вы используете, он будет всё меньше, потому что уже существовали такие вакансии там на Software Engineer уже достаточно давно, когда вы приходите на собеседование, а вы, допустим, решаете какие-то алгоритмические задачки на языке, которым вы знаете, вас потом нанимают, то есть вы проходите там собеседование по system design, по архитектуре, по решению каких-то других задачек, по какой-то базе. Да, вас не будут там спрашивать в этих компаниях на такую позицию, как там работает, не знаю, list в таком-то языке программирования, либо как работает garbage collector в там в C# .NET либо в Java. Да нет, вас о таком не будут спрашивать. И когда вас нанимают на работу, вас уже просто распределяют в команду, где может быть совсем другой стек, который вы не знаете. То есть вы знаете GO, а там, допустим, C# .NET, да? Ну, и вам дают просто месяц на адаптацию, и вы уже пишете на C# .NET. Потому что на самом деле, если вы знаете какой-то хотя бы, ну, хорошо, если вы знаете один язык программирования, то влиться в новый вообще не составит труда. Тем более, когда вам даже не нужно сегодня писать код на этом языке программирования. Поэтому моя позиция такая: какой вы язык бы не знали, вам нужно качать инженерные навыки и смотреть в сторону вакансий Software Engineer. То есть, что там требуется, вот это будет скоро везде, да? Ну, нигде не будет то, что там junior, C# .NET разработчик. Нет, будет какой-то там Software Engineer, либо там AI Product Engineer, либо что-то такое, да, который человек умеет решать, доводить задачки до конца.
Итак, как я это сегодня вижу? Вам нужно тренировать и изучать инженерную базу, да, доводить её до идеала. Это уметь работать с продакшеном, уметь закрывать архитектуру, инфраструктуру, доводить, в общем-то, фичи результата. Вам нужно уметь выстраивать среду для агентов. Это формировать правила MCP, контекст задачи, контекст проекта. Потому что, опять же, каких-то волшебных промтов не существует. Это формировать скилы, это следить за трендами, постоянно изучать какие-то новые инструменты сегодня очень часто появляются. Я там в свои проекты регулярно постоянно что-то новое внедряю тот или иной там формат документации, тот или иной формат там пайплайнов каких-то всё это внедряю. Тестирую и использую, да, это тоже обязательно. И уметь правильно проводить инженерный цикл, ну, то есть применять его. Это ресёрчить, составлять план, продумывать требования к задаче, продумывать вообще, что должно получиться в итоге, видеть вот эту целую картину целиком, а потом реализация с помощью агентов, ну, и, соответственно, всё это проверять грамотно. Ну, и дальше идёт оркестрация. Может быть, сейчас это ещё не так актуально, да, потому что всё ещё это очень дорого, но всё дальше дальше, да, это всё будет становиться дешевле. И работа с параллельными агентами, управление там большими досками, большим объёмом задач, работа с субагентами. Но это больше уже конкретно будет заниматься этим всем какой-то инструмент. А в принципе ваша задача - это работа до, работа после, как я уже говорил, и, в принципе, понимание вот этих всех тонкостей какого-то вашего проекта конкретного, вашего продукта.
Как итог, я могу сказать, что искусственный интеллект, он усиливает сильного инженера, и понимание системы он ни в коем случае не заменяет. Работы меньше, к сожалению, её не стало. Решение, ревью, сложные задачи, контроль процессов, они остаются, все эти задачи на инженере. И поэтому я скоро буду запускать AI First направление. То есть это будет AI First курс, где я буду делиться всем своим опытом. Короче, следите за анонсами в Telegram-канале. Будет реально очень жёстко. У меня много всего запланировано, много ещё видосов, контента, идей. И вот эта область, она сейчас каждый день развивается, и она очень интересная. Можно делать реально очень прикольные штуки. Не забывайте подписываться на канал, оставлять комментарии, ставить лайки, подписывайтесь на Telegram, обязательно канал. Спасибо за просмотр этого видео.