Transcription
Последние 20 лет самым дефицитным ресурсом в IT были разработчики, которые умели превращать бизнес-требования в код. Но на текущий момент времени мы живём в переломный момент в IT, когда этот дефицит меняется, потому что появились модели искусственного интеллекта, которые за один или несколько промтов могут составить целые приложения, написать модули интеграции, вызвать по опишке, сделать функции или покрыть тестами, и с этим приходится считаться.
Проблема заключается в том, что реальная скорость вывода рабочих проектов и приложений на рынок, она не увеличилась. И зачастую даже в команды, где внедряется искусственный интеллект, э, скорость, она падает либо возникает больше хаоса. И тоже не очень понятно, как с этим работать. Поэтому мы живём в момент времени, когда дефицит на самом деле никуда не исчез. Он просто переехал от момента, когда мы пишем код к моменту, когда мы должны понимать контекст, архитектуру, взаимосвязь, продуктовую линейку, roadmap и то, как строить приложение. И именно этим переходом сейчас и знаменуется текущий этап в IT.
Дамы и господа, сегодняшнее видео не будет про то, как сейчас всех программистов заменят нейросети или что вышло топ-10 новых нейросетей и моделей, которые сейчас точно всё поменяют. Нет, ролик будет немножечко о другом. То, что сейчас я вам расскажу, это не было взято из какой-то отдельной статьи или курса, а это было прожито мною на протяжении последних 2 лет из опыта построения реальных приложений на искусственном интеллекте в бизнесе, поездок на бесконечные конференции или общения с тим-лидами, фаундерами, продуктами, CTO, разработчиками, которые взаимодействуют с искусственным интеллектом, которые понимают, что происходит трансформация и новый качественный слом и бесконечного прочтения статей, тоже прохождения различных курсов, анализа, практики, построения workкфлоу, всех этих процессов.
В общем, вот эта вот огромная каша, которая происходила с искусственным интеллектом на протяжении последних дву лет, я постарался систематизировать и собрать воедино для того, чтобы ответить на такие вопросы, как: "А что, собственно, происходит с IT? Где сейчас реальная ценность для программиста, если код теперь пишут машины?" И также мы должны понимать, почему вот умение написания кода нейронкой - это лишь только самое начало. Почему, например, использовать клод-код, кодекс, курсор? Этого недостаточно для того, чтобы поддерживать большие проекты на долгой перспективе. Какой архитектурный слой сейчас появляется вокруг модели искусственного интеллекта? В чём вообще заключается суть профессии AI-инженера? И почему команды, которые до сих пор пропагандируют старый подход и не адаптируются на новые рельсы в среднесрочной и долгосрочной перспективе проиграют?
Я не буду доказывать о том, что сейчас всех программистов заменят или что существуют какие-то автономные фабрики искусственного интеллекта, которые будут полностью автоматизированы писать код. Нет, наоборот. Я хочу показать, почему инженерия сейчас наоборот будет ещё более важной. Просто объект её работы меняется с кода на нечто иное.
Так, давайте начнём разбираться с самого начала для понимания вообще повествования. Сейчас середина 2026 года, и по факту мы имеем технологию, которая умеет писать код. Искусственный интеллект, он прекрасно пишет отдельные функции, он создаёт модули. А если работают агентские системы, то они могут генерировать целые проекты с нуля, создавать действительно полноценный функционал, интерфейсы, логику работать с разными языками программирования. И мы здесь имеем, на самом деле, очень важный прецедент, потому что раньше написание кода - это всегда была привилегия профессии программиста или софтуердевелопера или разработчика. А теперь у нас есть технология, которая умеет за нас это делать.
Как происходил этот процесс раньше? У нас был какой-нибудь продукт или бизнес-онер, который такой: "Хочу сделать вот такую-то фишку в моём приложении". Он это всё оформлял в список требований и передавал программисту. И по сути вот, ну, концептуально, если оценить, то профессия программиста была в том, что он умел переводить с человеческих требований на язык машины, то есть, что ему нужно сделать путём написания кода. Он писал код. И вот эти вот желания и фичи, которые хотел видеть бизнес owner или Prodct owner, они появлялись уже в приложении. То есть машина понимает код, который написан.
А сейчас мы имеем следующий переход. Ведь по сути вот эта вот привилегия написания кода от программистов перешла в новый уровень абстракции. Что я имею в виду? В общем, раньше тебе нужно было знать, например, какой-нибудь язык программирования, Python, Java, C#P, TypeScript для того, чтобы написать программу. Это тоже уже были высокоуровневые языки программирования, но теперь, чтобы писать код, тебе, по сути, нужно просто уметь говорить словами. Ты диктуешь голосовушку, пишешь текстом в обычной человеческой речи. Это может быть и английский язык, и русский язык, не принципиально. И код за тебя уже пишет искусственный интеллект. То есть, по сути, мы имеем качественный вот такой вот перелом, когда мы можем создавать программное обеспечение с помощью естественного языка. Это и называется новый уровень абстракции.
Но мы уже живём в рамках таких реалий достаточно долго, уже года полтора существуют действительно мощные агентские системы. Но почему-то продукты они не стали дешевле. Цельно готовый продукт, он повысился в стоимость, но мы уже довольно-таки давно живём в таких реалиях, когда искусственный интеллект прекрасно пишет код, но почему-то продукты готовые, они не стали дешевле. Как это работает? Казалось бы, да, противоречие, ведь у нас есть технология, которая пишет этот код. Мы, по идее, должны быстрее создавать эти продукты. Они должны быть дешевле, но этого не происходит.
На самом деле концептуально, если рассматривать нейронки как вероятностные модели, таковыми они на самом деле и являются, то когда нейронка, она предлагает тебе готовый код, а делает она это очень быстро и качественно, то это не уже готовое решение, это всего лишь вероятностый кандидат на решение какой-то проблемы, которую мы хотим решить. То есть вот агент, допустим, написал тебе какую-то функцию, и это не значит, что эта функция решает все твои проблемы. Это означает, что есть вероятность, что эта функция, она может подойти под решение бизнес-трелебования.
Есть очень интересная статистика. А ссылочку на сайт я выложу в описании. Здесь она показывает следующее, значит, измерение, что а берут 500 реальных проблем Isс из Гитхаба с реальных репозиториев и пропускают их через разные модели. А так вот здесь мы видим уже то, что запрувлено реальными людьми. Насколько модели действительно делают качественное решение, да? Если мы посмотрим, то, скажем, моделька Клода Опуса 4,5, она решила 76,8%, ну, реальных задач, которые были на гитхабе. Причём, что интересно, справа вы ещё видите стоимость этого решения 0,75 доллара, да? И дальше вот мы видим, что и Gemini Flash неплохо разбиралась, и Cloud OPUS 4,6 тут присутствует, и кодекс 5,2, и у них у всех статистика решения вот этих вот проблем больше 70%. То есть мы имеем прецедент, что действительно многие инженерные задачи уже действительно решаются с помощью нейронок, но это показатель не доходит до 100%, да, то есть тем самым мы получаем некоторую вот вероятность нашего решения. И дальше это будет очень важно в всём цикле повествования.
Раньше, по сути, вот разработка выглядела следующим образом. У у нас была какая-то идея, например, у фаундера, он эту идею передавал программисту. Программист писал код и, собственно говоря, получал в итоге продукт. Но узким местом вот являлось тогда написание кода, потому что программист должен оценить задачу, он должен понять, как её реализовать, написать код, оттестировать. Но что мы имеем сейчас? Нейронка действительно пишет код. И по факту мы сейчас получили узкое горлышко уже в других местах.
Как это работает? У нас есть некоторые идеи, так же как и раньше. А дальше это всё передаётся программисту с Иишкой, который пишет этот код. Но по факту мы получаем много вероятностного кода, вероятностных решений, которые подойдут, ну, для решения данной задачи. И когда очень много кода, его же нужно кому-то проверять, здесь как раз-таки мы и попадаем в новое узкое горлышко, потому что а ревю, процесс проверки и интеграции этого решения занимает теперь большое количество места, большое количество времени, да? То есть человеку нужно обладать экспертизой для того, чтобы посмотреть, что на генерирова нейронка и понять вообще, подходит это решение или нет. Именно здесь как раз-таки сейчас основное количество времени тратят программисты для того, чтобы решать, пустить это решение в продакшн или нет. Ну а потом это уже всё идёт уже в продукт.
Резюмируем. Код в данном случае он действительно становится дешёвым, потому что нероночка прекрасно и дёшево это и быстро пишет. Но вот контекст, архитектура и проверка данного кода является теперь современным дефицитом, в том числе и компетенции инженеров, которые нужны для того, чтобы это реализовать. И это и есть, на мой взгляд, такой один из ключевых парадоксов, потому что если мы можем получить код довольно-таки быстро, то почему мы на текущем этапе не получаем продукты и классные сервисы кратно быстрее и дешевле? Давайте поэтом и разберёмся.
Я думаю, что в сети с появлением вайп-кодинга было очень много вот таких вот хайповых и шумных идей про то, что смотрите, мы с одного промта пишем целый сервис, целое приложение, и сейчас все будут программистами, а якобы программисты будут не нужны. Давайте разберёмся в действительности. Так это и работает, потому что есть два разных понятия. Первое - это демка или MVP, а второе - это действительно рабочий продукт. Я не буду отрицать тот факт, что с одного, с двух, с трёх промтов ты можешь сделать прямо качественное, классное приложение, которое будет выглядеть красиво, здорово, будет даже работать. И, в принципе, там на уровне Telegramботика или продающей страницы, например, это будет работать. либо, может быть, даже маленького СА-сервиса. Но демка или маленькая MVP - это не настоящий продукт.
Потому что когда мы говорим про действительно настоящую инженерную дисциплину, когда мы создаём продукты, это подразумевает намного больше слоёв, чем есть вот в визуальном его представлении. Когда мы говорим про мбипишку, например, то, по сути, это можно представить как маленький проект, у которого маленькая кодовая база, нет истории того, какие решения принимались на протяжении создания этого приложения. Всегда можно его сделать заново. И знаете, вот когда мы работаем с новым контекстным окном, то есть запускаем новый диалог, неронки, в принципе, довольно-таки просто уместить вот базовые требования, которые требуются для MVP, и реализовать их. А критерии успеха для МВПшки это выглядит так, что вот если всё красиво, то это работает. Значит, и люди, которые далеки от настоящей разработки, они могут на это повестись, обмануться и не понимая о том, что будет ждать их дальше при реальной разработке.
Когда мы говорим про построение настоящего продукта, который не просто живёт в рамках одной или там двух сессий работы чатика, а на протяжении нескольких месяцев или, может быть, даже лет, то там начинает возникать уже более глубокие причины. и формирование инженерной архитектуры, например, такие как миграция, исторические решения, интеграция различных сервисов, решение вопросов с ролями или, например, с доступами, с безопасностью, обратной совместимостью или, например, реализация специфических бизнес-требований, которые есть в каждом продукте. Зачастую в сервисах есть исторические решения, которые, например, пришли так называемые э-кейсы от клиентов, которые попросили, например, сделать такую задачу. И это всё учитывается вот в рамках этого продукта, что невозможно уместить в контекст одной сессии нейронки.
Причём, если вы в реальной разработки, вы знаете, как в действительности хранится вся эта база данных. То есть зачастую вот какие-то решения специфические, которые есть по проекту, они находятся только в голове у Тимлида, который уже 3 года работает проектом и просто помнит, что там вот такие решения принимались. какие-то решения хранятся там в Telegram или в слагчатиках, где просто быстро оперативно решали эту задачу. Какие-то из них лежат в жира Ишюс или в Конфлюенсе, либо в другой Вике. И то есть есть огромная база данных такая децентрализованная, которую зачастую вот нормальные разработчики понимают просто потому, что они знают про это. Но ведь сессия агента, и мы про это дальше поговорим, она это всё не воспринимает. И когда стоит задача поддерживать такой продукт, то она не может освоить вот сразу вот все вот эти вот нюансы. Она может в них запутаться и, конечно же, начнёт решать задачу не так, как нам нужно. Поэтому мы и видим вот такой прецедент, что многие там, а, показывают, что вот, мо, у меня готов целый сервис, э- который я написал за два промта. Но по сути MVP - это просто презентация этого продукта, да. Когда мы говорим про настоящий продукт с большой кодовой базой, с нормальными архитектурными решениями и с бизнес-логикой, то это уже должна быть отдельная история.
Если наглядно продемонстрировать, как это выглядит на диаграмме, то вот по сути я вижу это следующим образом, что MVP - это верхушка айсберга, то есть там есть какой-то интерфейс, есть код, и оно как бы вот на демке работает, то есть можно показать и выглядеть это будет довольно-таки здраво. Но по факту, когда мы говорим про реальную разработку и реальный продукт, нужно учитывать ещё бизнес-правила, исторические решения, данные, безопасность, интеграция, как всё это эксплуатировать, обратную совместимость, различные инциденты, которые происходили за время формирования данного продукта. И так как мы все не идеальные и очень сложно соблюдать постоянную консистентную базу знаний, то значительная часть знаний и нюансов, которые лежат на дне этого айсберга, они вообще находятся ни в коде, ни в комментариях, они где-то вот разрознены. И получается следующий вот факт, то, что если, например, какой-то программист долго строит продукт, то вот он носит знания об этом продукте у себя в голове. Это о'кей. Это очень долго работало в ITмире. А теперь давайте подумаем. Кто-то хочет, например, сделать так, чтобы теперь агент писал код, да? Вот агент приходит к вам на проект, но он же как будто бы вот заново рождается. И что происходит в этот момент с нормальными требованиями и со старыми репозиториями?
Когда агент приходит к вам на проект, на самом деле он имеет огромное количество ограничений, которые нужно учитывать. И самое главное ограничение - это контекстное окно. Потому что вот разные модельки декларируют разное контекстное окно. Тот же самый, например, Opus П. Он есть для кодинга в размере миллионного контекстного окна. То есть миллион токенов можно забить, и он будет с ними оперировать. У кого-то это там 374.000 токенов, у кого-то это 256.000 токенов. Но проблема заключается в том, что это всё равно ограничение, в рамках которого вот мы не можем выйти. Более того, последние исследования говорят, что всё равно на текущий момент там миллионный контекст, он не так уж и классно работает. То есть, условно, если залить миллион токенов туда, то всё равно он не будет показывать там стопроцентную эффективность. А когда мы говорим про реальную разработку, то мы должны понимать, что у нас есть огромная база данных, которой может путаться модель. Могут быть противоречивые бизнес-требования, которые она тоже будет умещать в контекст и не понимать, что с ними делать. Часть информации в этих документах вообще может оказаться нерелевантной. И поэтому вот агенту, который пришёл, он будет выдавать какое-то решение, но непонятно, как с этим работать.
Компания Anтроopic она выпустила даже специальную статью по этому поводу про то, что построение контекста по сути является сейчас одной из важнейших дисциплин, потому что это влияет на эффективность работы я и агентов. И здесь они говорят про то, что действительно нужно как-то конструировать это а контекстное окно. Нужно помещать туда только необходимую информацию, узконаправленную, точечную, которая позволит действительно работать с нужной задачей. Они даже выставляют целую вот анатомию эффективного контекстного окна. про то, как в принципе это строить, про то, в какой момент модель начинает гаволюционировать с примерами. На самом деле, довольно полезная статья. Вы должны с ней ознакомиться, чтобы понимать просто про то, что это вот первый необходимый шаг, который нужен, а для того, чтобы как-то приблизить вашего агента к решению данной задачи.
Второе очень важное ограничение у моделек - это то, что по сути, как и любая LLM - это всего лишь вероятностный ответ. То есть наши нейронки, они работают по очень простому принципу. у нас есть какой-то импут. Мы даём данные на вход, дальше через алгоритм это всё переваривается и выдаётся на самом деле вероятностный ответ. То есть это никогда не стопроцентная истина. Просто вот согласно текущему алгоритму вероятностный ответ на такую задачу будет следующий. И любой код, любая функция, любое решение, по факту это является некоторой вероятностью. Например, модель может неправильно понять бизнес-требования, неправильно оценить вообще задачу, потому что мы, например, неправильно ей донесли, не со всеми вводными, и она выдаст решение, но оно не будет соответствовать тому, что нам нужно. Она может выбрать не тот архитектурный подход. Она может взять, например, и выдумать какое-то решение, например, а запросы, какие-то удалённые URL или там, а, контракты взаимодействия с другими приложениями. Ну, потому что она вероятностная, и она такая, ну, кажется, это решение более-менее подходит. Она может, например, взять и пропустить какие-то или просто проигнорировать наши бизнес-требования. И знаете, что она в итоге скажет? Она скажет вам: "Ой, извините, да, вы правы, вы нашли ошибку, я не так себя повела". То есть она не несёт ответственности, потому что это алгоритм. Это очевидно. Поэтому каждый ответ модели - это просто некоторый кандидат на решение, но не истина. И здесь нам обязательно нужно это всё проверять.
Третье ограничение - это то, что у модели отсутствует какая-то постоянная память. Вот представьте очень талантливого, классного ребёнка, который вот рождается в каждой новой сессии, и он не знает, что мы до этого строили, какие решения мы принимали, почему тут выбран такой-то подход, такие-то инструменты. Он не понимает, какие были проблемы или с чем связаны разные участки кода. Он просто такой: "Я родился, я ничего не знаю про проект, но я готов вот работать". Да. И для того, чтобы вот, ну, эффективное решение было в итоге, конечно же, нужно всё это понимать. Это как раз проблематика памяти.
Четвёртое - это на самом деле то, что у модели отсутствуют какие-либо дополнительные инструменты, потому что в своей основе это просто алгоритм работы с текстом. Он принимает на вход данные и выдаёт какой-то текст. У него отсутствуют инструменты для того, чтобы расширить свои полномочия. То есть в своей базе оно не может, например, создавать по реквесты, смотреть на то, какой текущий C есть, ходить в Git или править конфиги, загладить по SSH, проверять то, а как это выглядит на самом деле, например, запускать это в браузере и оценивать глазами клиентов интерфейса.
Пятое - это то, что модель на самом деле может рандомно просто брать и завершать задачу, то есть, условно говоря, игнорировать вообще те требования, которые мы ей давали. Те же самые, они выпустили другое исследование, которое вот называется effective hardness for long running agents. И смысл в том, что вот когда давали объёмную задачу очень мощно классным моделям антропика, то по сути в какой-то момент они брали и переставали работать. Да, они как раз-таки это и описывают. И по факту они пришли к тому, что для того, чтобы агент грамотно выполнял задачу, в первую очередь нужно идти итеративно, то есть в буквальном смысле составлять прямо чек-лист и план, по которому она должна идти и не переступать шаги. Обязательно должен быть инициалайзер, обязательно должны присутствовать различные последовательности для того, чтобы реализовывать эти вещи. И очень важно, чтобы была грамотно продуманная инфраструктура, а которая позволяет модели вот, ну, не сбиваться своей логики вот работы. То есть сюда включаются и, безусловно, тестирование, и работа с гетом для того, чтобы фиксировать различные этапы. То есть некоторая инфраструктура, которая нынче называется харness, которая позволяет как раз вот модели доводить всё это до конца. Также ссылочку на статью оставлю в описании.
То есть, что нам нужно понимать в данном случае, это то, что когда агент приходит к нам на проект, по сути, он не понимает его полностью, он просто берёт и вот в новой сессии, да, которая абсолютно свежие, он как из чёрного ящика появился, он начинает реконструировать вообще из доступных артефактов, а что в принципе есть в проекте. Это вон файлы какие-то анализирует, там данные, которые мы им прикрепили. И мы не можем гарантировать, что этих данных будет достаточно. Опять же, вот эти ограничения, которые мы только что проговорили. И мы, как разработчики, мы не можем ждать, когда магическим образом появится новая суперклассная модель, которая возьмёт и исправит все вот эти вот проблемы. По факту мы должны сконструировать инфраструктуру, которая позволит агенту более чётко понимать взаимосвязь между различными элементами, долгосрочную память, добавить ему вот эти вот различные инструменты, которые позволят ему лучше ориентироваться, лучше строить контекст и тем самым повысить результативность решения каких-либо задач.
На схеме это выглядит следующим образом. То есть вот это текущий наш контекст фиолетовым цветом. И он, видите, он достаточно ограниченный, да, потому что, э, для реализации вот реальной системы и реальной задачи ему нужно понимать и репозитории, и документацию, и базу данных, и анализировать задачи в трекере, анализировать логи, метрики, там переписки в чатах, различные принятые до этого исторические решения, доступы и роли пользователей, вообще наличие другой инфраструктуры, которая есть. Это всё должно уместиться в контекст. Это неправильно. Неронка будет галлюцинировать. глючить, и мы должны ей подсказать, как правильно оперировать с этими данными для того, чтобы у неё всё получилось.
То есть на текущем этапе мы должны понимать, что да, мы получили инструмент, который классно пишет код, но при этом то, что он быстро создаётся, это не означает, что теперь продукты также быстро будут создаваться. Новым узким местом становятся не сами изменения, как это было раньше, а теперь узким местом становится наше понимание, какие изменения нам реально нужны, которые предлагает агент, а какие нам нужно отклонить.
Итак, искусственный интеллект способен генерировать код быстрее, чем любая организация, процессы или программисты могут принять эти изменения и оцифровать, насколько они валидные. Именно на этом этапе и возникает такой термин, который называется verification tax. Это терминология, которая описывает, что есть некоторый долг по проверке того кода, который нагенерирован. И действительно, существуют целые исследования, которые показывают, что интуитивно, и вот примерно программисты считают, что с появлением Иишки они пишут код намного быстрее, релизят больше фичей, и всё у них классно, быстро получается. Но фактологические исследования показывают, что на самом деле количество фищей не выросло, потому что код-то написал быстро, но потом уходит огромное количество времени на то, чтобы проверить, а что там вообще происходит. И в конце двадцать пятого года этот показатель был порядка 19%, то есть прирост к производительности программистов. В некоторых случаях там вообще говорилось о том, что прироста не было и был отрицательный рост, так сказать. То есть код шипился быстрее, но его нужно было проверять.
Хотя есть и другая организация, которая называется Метр. Она вообще исследует, сколько искусственный интеллект может автономно работать без участия человека и не делать ошибки. И она утверждает, что, конечно же, на момент двадцать шестого года всё-таки прирост производительности сильно вырос. Плюс он будет также категоризироваться из-за роста интеллекта у моделей. То есть чем умнее они становятся, тем, в принципе, быстрее будет проходить данный процесс. Но мы имеем одну простую истину на текущий момент, что наличие умных и классных новых моделей, которые становятся всё мощнее и мощнее, не гарантирует, что у вас будет лучше производиться кодовая база, потому что это очень сильно зависит именно от специфики проекта, от репозитория, от инфраструктуры и доступных инструментов.
Существует и другой термин, он называется verification dep. То есть, по сути, это долг по ревью, да, и он возникает, когда мы быстро производим какой-либо функционал, но у нас есть проблема в том, чтобы верифицировать, насколько он подходит для нашего проекта. И здесь действительно ценностью становится не само решение, а факт того, что вы его проверили, вы поняли, что он подходит под те задачи, которые мы ставили в проекте. И вот именно здесь сейчас происходит основная такая вот битва и решение проблемы по внедрению яишки.
Для наглядности давайте покажу ещё некоторую схему, потому что раньше процесс строился очень просто. Были требования, был разработчик, который анализирует это эти требования. После он пишет какой-то код, происходит ревью и происходит релиз. Очевидно, что код, который написал программист, намного проще отревьюшить. А если говорить про процесс, который был до этого времени, и во многом он сейчас в компаниях устраивается, называется такой наивный AI process, то есть есть требования, они попадают через разработчиков в искусственный интеллект, он вываливает просто огромное количество изменений файлов, называется огромный div. И по факту программист теперь смотрит вообще, а нужен этот код, не нужен, как его проверить. Именно вот на этом этапе и формируется такое понятие, как verification TX. Ну и дальше всё это отправляется уже на переделки, ошибки, новые промты. В общем, до тех пор, пока это не заработает.
Для того, чтобы вся эта система работала, существует новый процесс. Он выглядит примерно следующим образом. То есть у нас есть некоторые требования, которые потом формируются уже в спецификацию. Спецификация, она переводится в контекст, который понимает агент. Вот на этом этапе как раз-таки и возникает роль контекст инженеринга. Далее агент, он выбирает инструменты, которые ему потребуются для того, чтобы реализовать конкретно эту задачу из контекста. После этого у нас происходит автоматическая проверка всех этих изменений. И дальше
у нас присутствует блок trace, когда мы отслеживаем вообще по объективным параметрам, насколько это решение далось нам хорошо или не очень. После этого, когда вот это вот всё автоматическая цепочка прошла, дальше это всё переходит уже на решение человека и на эксперта. То есть насколько оно действительно подходит под контекст данного проекта. Ну и после этого, если человек это всё запрывил, то это попадает в релиз.
Поэтому сейчас основная задача, которая происходит в мире IT и искусственного интеллекта - это то, как построить среду для того, чтобы дать агенту понять, как работать в проекте. То есть не просто подключить умную модель и надеяться, что она решит все ваши проблемы, а как сделать так, чтобы она чётко понимала, какую задачу решить, её верифицировала и уже передала на э проверку. И вот на этом этапе возникает такое понятие, как харnness. Мне очень нравится определение, что РNС - это управляющая инженерная среда вокруг модели, которая превращает вероятностный искусственный интеллект в повторяемую программного исполнителя. То есть мы наращиваем некоторый архитектурный инженерный слой вокруг лэмки, где лэмка является просто некоторым процессором или вычислительной вот мощностью. И дальше в зависимости от архитектуры, которые мы выстроим, она решает соответствующие задачи.
Есть очень классный кейс прямо вот именно с конференции, то, что вначале ребята писали проект на топовых моделях, там GPT 5,5 на тот момент, OPUS 4,8, но потом, когда у них возрастал харнес вокруг их проекта, то они могли делать те же самые задачи, только уже на более дешёвых моделях, таких как Kimia 2.5 на тот момент и GLM 5.2. И на самом деле для компании это огромное преимущество, потому что у тебя те же самые фишки делаются, но при этом ты платишь за токены там в три, в пять, в 10 раз меньше. И как раз-таки это и есть заслуга Харнеса.
Многие на самом деле думают о том, что Харnessс - это какая-то сразу сложная терминология или сложная архитектура, которую там вот нужно комплексно внедрять. В действительности самый простой харness - это базовые инструкции для агента, для Clodда - это CLДМ. Для других агентских систем - это AGM MD. И, может быть, несколько макдаун файлов, которые просто позволяют лучше сконструировать контекст и объяснить, как устроен ваш проект. Это уже в простом представлении и является харнесом.
Однако, когда ваш проект становится более взрослым, а больше наращивает инфраструктуры и экосистемы, то там, конечно, уже возникают и более продвинутые механики по тому, как процессить весь проект, то есть искать нужные файлы, нужные модули, нужные компоненты. К этому подключается и векторные базы данных. К этому подключается, конечно же, система Рага, которая позволяет поэтапно доставать определённые элементы по смыслу из базы, чтобы не загружать контекст. К этому добавляются и внутренние MCP, и внешние MCP, тулы, скилы, добавляются различные сэндбоксы для того, чтобы изолированно тестировать разные фишки. Добавляются истории с observability, с трейсингом для того, чтобы проверять работу искусственного интеллекта. Появляются целые пайплайны и workflow. Возможно, они будут связаны с различными правами доступа, оркестрацию различных исполнителей и субагентов. Ну то есть вот это всё становится уже таким огромным инфраструктурным слоем.
Вы должны понимать, что вот объём и сложность Харнеса, она напрямую зависит от сложности проекта. Чем больше проект, чем больше в нём функционала, чем больше в нём бизнес-логики, тем очевиднее и больше должен становиться ваш харнес для того, чтобы лучше поддерживать данную инфраструктуру. В текущих реалиях самая даже умная и топовая модель, которую вы сможете найти без харнеса - это, по сути, очень классный, проактивный и умный сотрудник, который не обладает доступом к базе данных, к правам, к пониманию проекта, к пониманию взаимосвязи и бизнес-логики, к инструментам. То есть он что-то хочет делать, но просто не может. Харнс решает данную задачу.
Давайте покажу на диаграмме, чтобы просто лучше было понятно. В центре у нас присутствует модель искусственного интеллекта. И в нормальных проектах она может меняться. То есть, допустим, сегодня вы работаете там на опусе, завтра на Fable, потом вы работаете там на GPT Soul 5,6, другая модель выйдет, да, вы не должны привязываться к конкретной модели, она просто является некоторым процессором. Чтобы это обеспечить, нужен слой провайдера такого, да, когда у вас, у этого провайдера будет единый IP для вашего проекта, и к нему вы уже подключаете нужную модель. Там хотите тестируете на дипсике в продакшене, работаете там с, например, с Кими третьим, который вот недавно вышел. И вот Харнес, да, его основная задача заключается в том, чтобы подключить к нему контекст, который отвечает на вопрос: а что модель должна знать? Подключить необходимые инструменты. чтобы дать понять ему, что она вообще может, например, работу с внешними MCP, получение базы данных и так далее. К этому мы должны подключить и память, а что она знает вообще про проект, какие были приняты исторические решения, почему мы выбираем именно такой путь. Обязательно для разработчиков необходимо добавить слой наблюдаемости. Это вообще один из ключевых вот этапов, потому что как мы можем объективно судить о эффективности работы искусственного интеллекта, если мы не знаем вообще, что произошло, и не можем отследить результаты. Может быть, на одной модели это будет работать хорошо, а на другой там хуже, например. Да, и для этого как раз-таки нам и нужно понимать, а что происходит именно с ней. Ну и, безусловно, должны быть определённые ограничения, дать понять, куда, например, лазить нельзя, какие файлы нельзя трогать, какие функции нельзя менять. Ну и, безусловно, также, а, должны быть проверки того, что вообще, например, твой функционал, он сохранён. То есть вот в этом концептуально и заключается роль как такового харнеса. Ещё раз, это инфраструктурный слой, который позволяет сделать модель обширней с точки зрения функционала в вашем проекте.
И на этом этапе я как раз-таки хочу в детали погрузиться того, чем является Харness, чтобы это не просто были абстрактные там квадратики на экране, а вы чётко понимали, из чего состоит вот современный обвяз вокруг модели, который позволяет искусственному интеллекту грамотно работать в вашем проекте. Смотрите, говоря про харнес, в первую очередь очень важна концепция контекст инженеринга, поскольку она позволяет поместить только необходимые данные внутрь контекста, который мы уже с вами поняли, что ограничен, и тем самым а дать возможность модели правильно работать. Как модель получает знания, как вообще формируется данный контекст. Существует, на самом деле, довольно-таки много различных вариантов. То есть, если вы работали с кодинговыми агентами, то они зачастую используют функцию grab или просто поиск для того, чтобы по определённым паттернам находить соответствующие файлы, например, в вашем проекте. Ну либо обычный поиск. Зачастую это происходит по символам либо по так называемому dependency graph, когда ты понимаешь иерархию компонентов или, например, различных модулей и структур и можешь понять, что с чем связано по гистории, по взаимосвязи с трекерами или по семантическому поиску. И по факту, то есть у нас есть несколько вариантов того, как мы можем эти знания получить. И дальше это всё вот происходит через так называемый процесс либо rock. Многие путают, говоря про то, что рак - это только бединги, например. А когда мы переводим наш датасет в числовую последовательность, я оставлю ссылкой, в общем, полный гайд по рагу плю 11 стратегий. Я записываю его у себя на Ютубе. Там вы подробнее с этим ознакомитесь. Вот. Смысл в том, что это не только про эмбединги, да, соответственно, это вот про различные возможности получения этих знаний. И получается, что когда мы вот начинаем внедрять а данные инструменты, то мы перестаём пытаться положить целый проект в один промт в контекст. Нет, мы контекст именно формируем через а очень узконаправленные источники информации, в том числе эмбединги, если это потребуется. Дальше мы передаём это в контекст запроса. По сути, вот контекст запроса - это, грубо говоря, системный промп, да, который вот у нас есть. И дальше уже это всё передаётся к модели. И очень хорошее замечание про то, что хороший контекст - это не то, что мы запихали туда как можно больше информации. Нет, это наоборот про то, чтобы собрать в этом контексте как можно меньше информации, которой будет достаточно для того, чтобы модель сделала правильное решение. Вот об этом и идёт речь здесь про контекст engнириing и конкретно про рак.
И данная система, она отвечает на вопрос, что агент должен знать. Но дальше мы должны ответить на вопрос: а что агент может делать? Потому что, как мы уже с вами говорили, а сам по себе агент или LLM - это всего лишь текстовый алгоритм. Он взаимодействует только с текстом. Он не умеет работать там ни с файлами, ни с терминалом и так далее. И поэтому есть очень важные два понятия, которые называются Tools and MCP. А давайте начнём начнём с MCP. То есть MCP - это некоторый протокол, который позволяет подключать модель к какой-то внешней базе данных. к внешнему датасету. То есть это просто некоторый, грубо говоря, контракт, который позволяет лмке, этому агенту, да, взаимодействовать с нашими данными. Есть очень классная аналогия, да, что по сути MCP - это даже не память, это как просто разъём, да, это USBC там для искусственного интеллекта, кто работал с агентами типа GMES Agent или Open Claw, вот вы понимаете, что в принципе они тоже являются вот таким разъёмом, который соединяет, например, базу данных и лэмку. Так вот, для этого мы внедряем MCP, чтобы агент имел возможность получить доступ, например, к файлам или к файловой системе, к терминалу, там, к GitHubбу, к браузеру, к базе данных, к внутренним опишкам в нашем проекте, к стейджингу, к environment переменным, тастрекерам, к логам, к continuous integration или к билдам. Это всё, что позволяет, э, агенту принимать решение более корректно, с учётом того, что он понимает лучше наш проект непосредственно. И также здесь вы видите, что у нас всё-таки перечислен в заголовке to NMCP. А расскажу, а в чём заключается здесь идея. То есть, очевидно, это конкретные инструменты, которые мы можем давать агенту для использования. И тогда спрашивается разумный вопрос: "А зачем нам нужен какой-либо MCP?" И это действительно резонный вопрос. он нужен для некоторой стандартизации и для обобщения, так как это является некоторым протоколом. С учётом того, что агент на самом деле напрямую может подсоединять себе конкретные инструменты, которые будут уже действовать во внешней среде, то MCP нужен для того, чтобы, например, мм сделать интерфейс доступным для других клиентов. Давайте приведу простой пример. Скажем, с Gmailлом там или с какой-нибудь почтой или с инвестициями. когда присутствует MCP, который позволяет множеству клиентов работать с ресурсами сервиса, там того же Gmail, например. Вот если мы говорим в рамках одного проекта, а где только наша логика, мы не намерены, например, там добавлять какой-то внешний функционал и клиентов, то здесь, в принципе, MCP нам может быть не нужен. Мы просто в тулы оборачиваем функционал как бы конкретных этих элементов и, э, запускаем в работу. Но смысл остаётся, если в общем говорить простой, что уровень в Харнесе, который отвечает за тулы, за MCP, он отвечает на вопрос и расширяет отвечает на вопрос, что агент может делать, и расширяет полномочия агента с точки зрения того, что он может реализовать.
Следующий слой, он называется Memory and State. Очевидно, чтобы агент работал более корректно, причём он учитывал предыдущий опыт, какие-то ошибки, исторические решения, мм, какие-то важные пометки, которые нам необходимо внести в проект или специфику непосредственно этого проекта, то мы должны иметь некоторую долгосрочную память или состояние, в котором это всё дело сохраняется. А опять же, если берём консервативный путь, то как бы вот эти сессии, они просто появляются, исчезают, и они никак не взаимодействуют с внешней памятью. А при этом, когда мы добавляем харнес, то, например, в одной сессии мы приняли решение, что мы там пишем код вот по одному алгоритму, мы сохраняем этот, а, эту информацию в нашем стейте, в памяти. Потом, допустим, вторую сессию запустили, которая абсолютно изолированная от первой сессии, да, и мы можем сразу же из памяти прочитать, какие решения были приняты ранее, да, и тем самым он уже будет учитывать то, что было сохранено. Это как бы тоже формируется контекстом, но тем не менее это другой архитектурный слой. Ну и что-то он записывает. Ну и так далее, и так далее. То есть каждая новая сессия будет более общей и полной. Память сама по себе может быть репрезентирована в, на самом деле, в разных состояниях. То есть это может быть какой-нибудь просто обычный MD-файл, который обновляется. Это может быть гиit история, это может быть Jonй, это могут быть логи или какие-то сари, это может быть и векторная база данных с сложными там иерархиями. И, честно говоря, чем шире ваш проект, чем больше он становится, то очевидно, что нужно выносить, да, какие-то вот решения больше в базу, нежели в файлы, поскольку работа с файлами - это достаточно долгий процесс. Но тем не менее там суть остаётся в том, что мы просто сохраняем это где-то на диске и всё. И тут возникают ещё другие архитектурные, на самом деле, задачи, да, потому что если мы абсолютно всё будем хранить, то, опять же, мы столкнёмся с ситуацией, переполнением контекста, переполнением информации. Это будет абсолютно бесконечный склад, и ничего хорошего в этом нет. То есть нам определённо нужен отбор плюс структура того, какие решения сохраняются, как это работает. И, честно говоря, это всё тоже попадает в архитектурный слой.
Переходя к четвёртому пункту, это тесты и ваус, так называемые, то есть это проверка того, что агент правильно работает, да? Смотрите, в опять же консервативном IT у нас присутствуют софтуер-тесты, которые проверяют продукт, да, что в это может входить. Это и unit-тесты, integration тесты, nendтесты, какие-то тесты на performance, на безопасность, контракты проверяемые. Это достаточно, ну, классическая структура. Но когда у нас есть новый архитектурный слой, который отвечает за агента и где агент работает, мы добавляем ещё один слой тестов, который называется EvaS. Они проверяют именно агента. По сути, это некоторые смоук-тесты, которые должны гарантировать, что вот при таких условиях аэ агент выдаст нам соответствующий результат. Мы проверяем там, что он понял задачу, там нашёл документ, он вызвал определённый, например, MCP или пошёл в базу данных там по а рагу. Он сделал определённый порядок шагов, не пропустил шаг и то, что смена модели, например, не повлияла на это. Э ну простой пример, что мы, скажем, в девелопменте работали с диптиком, перешли на prodдакш, там, допустим, какой-нибудь кими третий, например, работает. Вот. И наша задача - понять, что агент при смене модели всё равно выполняет все необходимые операции, которые обеспечивают жизнеспособность и работоспособность нашей системы. А, да, то есть Иваус он как раз-таки проверяет ту систему, которая создаёт код. Это очень важный архитектурный слой, который относится к харнесу.
При этом, а, пятый слой харнеса, он называется observability. Давайте приведу пример с консервативным IT. То есть, например, когда у нас мы пишем какую-нибудь функцию и она выдаёт ошибку, то у неё всегда есть некоторый там стекрейс, по которому мы можем отследить, что с ней случилось, где произошла ошибка, и сделать соответствующую поправку или дебаг. Но для того, чтобы контролировать архитектурные слои, связанные с агентом, то нам также нужно отслеживать как минимум шесть слоёв вот этих, которые перечислены, чтобы понять, где произошла ошибка. Например, неправильно сформированный контекст. Ошибка произошла при вызове лэмки, да, что-то не сработало в вызове инструментов, провалились сивалы или там тесты, да, либо там произошёл какой-нибудь ретрай. А это то, что позволяет нам отследить работу агента, опять же, без привязки, там, например, к модели, а просто именно в нашем Харнесе, чтобы поправить нужное место. Вот зачастую бывает так, что так как опять же лэмки - это вероятностные модели, то они не стопроцентно гарантированно вызывают, например, нужные MCP или нужные инструменты. И очень часто, как раз-таки, observability позволяет, а помочь отследить такие моменты. Но это как один из самых примитивных примеров.
И шестой очень важный слой - это Guardrails и Approvals. По сути, что такое Guardrails - это м система, в которой мы ограничиваем функционал моделью. Короче говоря, что мы ему запрещаем? Вот смотрите, у нас, если схематично посмотреть на архитектурный слой здесь, то у нас, по сути, есть некоторый агент. И по-хорошему вначале мы запускаем всё это дело в СНБ. Sandbox - это изолированная среда. Это, если угодно, всякие там докерконтейнеры, как аналогию, да, привожу здесь. И вот это всё находится ещё внутри гардрейся, то есть определённых структурных ограничений, которые позволяют, а, лимитировать возможности данной агенты. Мы можем, допустим, свободно гарантировать модели, читать тестовую базу данных, там, работать в своей изолированной гитветке, работать с по-реквестами внутри неё и так далее. Но при этом, когда мы приходим к реальному продакшу, то возникает слой approval, то есть человек, он должен оценить, какие изменения произошли, а что агент нам предлагает, и только после его одобрения он уже запускает это всё дело в prodдакшн там, а, ну, либо удаление данных, миграции. Это просто некоторые примеры, которые вот в этой схеме логичны. Guardrails, очевидно, не гарантирует полную безопасность, но при этом он жёстко структурирует работу агента. Например, там опять же чтение всяких разных в переменных или анализ определённых папок и так далее.
В итоге, если суммарно оценить то, как работает Харнес и в чём заключается его ключевая идея, ну, а точнее и общая архитектура, то смотрите, у нас есть определённые действия алгоритмические, да, когда всё начинается с намерения, дальше это намерение перетекает в спецификацию. Дальше мы от этой спецификации формируем необходимый контекст, который уже передаётся в действие. То есть модель начинает с ним работать. После этого а мы проверяем результат. И после этого, если что-то нужно, мы заносим это в память для того, чтобы прошёл а цикл, ну, такой вот итеративная часть. При этом всём мы наблюдаем каждый из этих слоёв с помощью слоя observability. И при этом мы всё это запрещаем как бы и ограничиваем именно гардреусами, которые, ну, не позволяют там хотя бы часть ошибок допустить. Вот так вот именно и строится харнес. И вот на самом деле очень многие технологии, которые сейчас есть в а И мире, это всякие SDK и так далее, они вот построены на то, чтобы вот все эти этапы более корректно и правильно работали. Вот в этом и заключается архитектурная часть. Каждая технология этого стака, она действительно существует, потому что просто об модельки ей чего-то не хватает. И это наша задача сформировать данные, э, архитектуру, чтобы она вела себя предсказуемо. И когда это всё реализовано, то, в принципе, мы можем называть наш проект, а что он более-менее готов к AI рельсам.
Здесь я хочу сделать небольшую паузу, потому что вот, знаете, всё, что я сейчас перечислил, оно, конечно, вот выглядит так встроенно и классно, разная терминология, куча теории, но, честно говоря, можно вообще бесконечно смотреть разные обзоры на фреймворке, как это всё красиво строится и даже понимая, что такое там условный рак или MCP, так и не понимать, а как это всё воедино вообще соединить. Вот эта вот вся структура, которая только что проговорена была, да, как на практике её пощупать. Я не буду скрывать, что я и сам довольно-таки долго собирал это всё вот воедино, всю эту картину в целостности, чтобы понять, как что зачем следует. И поэтому весь этот опыт я соединил в одну большую практическую программу. Программа называется "Я инженер". Собери свою собственную entнticк систему. И вы должны понимать, что это не какой-то там курс по промтам или по очередным инструментам. Это исключительно на практикум, который позволяет пошагово, а, понять вообще вот эти все концепции, которые только что перечислил из мира AI, инженерия, и соединить это всё воедино в последовательную структуру, чтобы было понятно вообще, о чём идёт речь.
Как это работает, спросите вы. А первый модуль, он немного обособленный от общего курса, потому что там есть полный интродакшн того, как работает вайпкодинг и вообще современная разработка с агентскими системами. То есть для тех, кто вообще ни разу не пробовал там себя в агентских системах и разработку с Иишкой, этот модуль позволит закрыть вообще все вопросы, то есть где купить подписки, как это работает, базовый hardness, код MD, agents MD, best practice, различные базовые концепции, чтобы просто можно было нормально вайпкодить. И это маленький идакшн. Дальше, что мы делаем? То есть для того, чтобы пошагово понять вот эти вот все соединения, которые есть в профессии я, инженеры, мы начинаем прямо с простого Typeesрипт файла. Там буквально будет там строчек 50. И дальше вот мы за 10 шагов начинаем наслаивать на этот файл постепенную пошаговую инфраструктуру без переусложнения технологий, чтобы вы понимали вообще, какую суть несёт в себя каждый из них, каждый из этих шагов. Причём, что очень важно, мы не просто подключаем какой-либо там фреймворк готовый, который делает Magic работу. Нет, сознательно идёт упрощение здесь, чтобы мы вот прямо самостоятельно писали многие блоки без продакшн-фреймворков. Для того, чтобы вы понимали, причина этому тому, что, э, с агентами подключить какой-то готовый инструмент очень легко. То есть тут очень важно именно архитектурное понимание, как это выстроено, чтобы потом уже наслаивать какие-то prodдакшн-фреймворки.
Смотрите, что получается по итогу практикума. Вы создаёте свою полноценную adentic систему. То есть это по факту у вас будет своё собственное приложение современное, которое вы заливаете на GitHub. и можете переиспользовать. Что имеется в виду? Самаксистема именно в практикуме, она построена на основе такого хелф-кодча, то есть коуч по вашему личному здоровью, там питанию, нутрициологии и так далее. Но кодовая база и архитектура, они остаются вот антихрупкими. То есть по сути вы можете перенести данный фреймворк на любую доменную область, будь то программирование, маркетинг, продажи, разработка, тестирование. Там просто меняются некоторые промты, чтобы он более профильно понимал, что нужно. То есть кодовая база остаётся на 80% той же самой. Данная программа рассчитана на тех инженеров, которые уже владеют JavaScript и TypeSescript. Ну и хотя бы это уровень Junior Plus, потому что здесь не будет рассказов про программирование, про базовые его основы. Это больше про архитектуру и про новую профессию Я инженера. То есть база программирования вам потребуется для того, чтобы понимать, что там происходит. Ссылку на программу я оставлю в описании. Ознакомьтесь с ней, и также там можно узнать будет актуальные условия.
А теперь давайте вернёмся к индустрии и поговорим, почему вот уже многие команды на самом деле перестраивают свои собственные системы и проекты под AI Native разработку. И уже даже есть целые спецификации и классификации, которые говорят про уровни зрелости проекта киндустрии. >> Говоря про уровень зрелости проекта к искусственному интеллекту, хочется показать исследование от Стнфорда, которое называется Stanford I Enggering Practices Benchmark. По сути, что делает это исследование? Они не просто выкидывают в компании формочки, где спрашивают, насколько у вас внедрён искусственный интеллект. Нет, они, грубо говоря, берут, запускают своих собственных агентов в проекты или репозитория, а, которые им дают для того, чтобы они вообще посмотрели эти агенты, какие там есть промты, какие есть версии этих промтов, какие есть агенты, субагенты, workflow и различные процессы. И только после этого назначается уже классификация данному репозиторию. Если на сайте посмотрим, значит, уровни этих классификаций, то они описали их вот здесь. Да, существует пять типов. Первый тип называется L0, то есть no observable AI. Это когда, по сути, у тебя вообще нет никакого искусственного интеллекта в проекте и ты пишешь всё старыми добрыми руками. А уровень один - это opportunistic prompting. Это когда, по сути, мы видим в проекте наличие каких-либо промтов, которые уже складируются, и, в принципе, разные члены команды берут и используют их. А уровень второй systemized prompting - это когда уже присутствует определённая версионность этих промтов. То есть есть разные версии, которые позволяют тестировать один и тот же функционал, когда есть определённые правила, которые грамотно храниются в репозитории. И опять же другие члены команды могут их переиспользовать. Третий уровень - это Agent Backend Development. По сути, он описывает этап, когда команды могут создавать переиспользуемые процессы или агенты и запускать их под нужные задачи. То есть есть, например, какая-то типовая задача, ты вызываешь нужного агента, и он тебе её реализовывает. И уровень четыре - это orchestrated genentic workflows. Это когда у тебя, по сути, присутствует уже множество агентов, которые объединены общим оркестратором, и ты берёшь и управляешь ими, опять же, выбирая подзадачу, выбираешь нужных агентов для того, чтобы они оптимально решили, а, ну, ту или иную задачу, которая ставит бизнес. И по сути вот на этом этапе уже возникает новая роль, новая профессия человека, который способен выстраивать все эти системы для того, чтобы твой проект был готов к внедрению искусственного интеллекта, к определённой роли автоматизации и чтобы всё это прекрасно работало, а не галлюцинировало и выдавало непонятный результат. Ну и плюс, чтобы со временем оно не разваливалось.
И на этом этапе нам необходимо поговорить про то, а кто же такой AI инженер. По сути, это специалист, который превращает вероятностную модель в управляемого участника внутри системы. То есть он оперирует вот на уровне между, а, рабочим кодом, который есть в репозитории, и архитектурой, которая строится для того, чтобы модель функционировала. Он выстраивает вот эти вот взаимосвязи для того, чтобы моделька могла чётко залезть куда нужно и сделать, что от неё просят. По сути, он проектирует следующие вещи: какой контекст модель должна получить и откуда эти знания ей идут. Он оперирует тем, что сохраняется в памяти и какие инструменты доступные модели. Он определяет, как устроен рак в платформе, как вообще происходит, в принципе, процесс ретривола, то есть получения информации для модели. Он настраивает agent loop и выбирает момент, когда нужно сделать повторный запрос, например, для того, чтобы лучше реализовать функционал. Также он определяет, когда модель должна остановиться, в какой момент времени нужно позвать реального человека для того, чтобы он верифицировал решения, которые предоставляет модель. Как считаются различные трейсы, когда нужно остановить модель, как ограничить её для того, чтобы она не лезла туда, куда ей не нужно. То есть вот это вот всё как раз-таки и проектирует, и я, инженер. Этот человек, он должен, безусловно, обладать компетенциями в программировании и понимать как минимум кодовую базу, потому что ему нужно будет грамотно настроить вот эту вот взаимосвязь консервативного кода с новой архитектурой, который нужен для нейросетей. В данном случае это не просто какой-то промт- инженер. Нет, это настоящий инженер, да, который обладает всеми этими знаниями. Но дело в том, что это просто практик. То есть не обязательно знать машин лерning или обучать модели там на высоких весах для того, чтобы уметь строить этот продукт. Нет, если у тебя есть консервативные компетенции в мире программирования, то ты плавно перетекаешь как раз-таки в эту роль, где ты уже занимаешься большей части архитектурой и пониманием того, как правильно настроить процессы внутри твоего проекта, чтобы теперь код писал не человек, а всё это делало более-менее автоматически модель там, где это возможно. В данном случае компетенции классические, которые получены в таком, давайте назовём это старый мир IT, они никуда не уходят, потому что наоборот сильнее начинают быть востребованы навыки архитектуры, понимания баз данных, того, как работают опишки, как работает безопасность CCD, devOBS, тестирование. То есть вот эти вот все навыки, они необходимы для человека, чтобы выстроить правильный харнес и вот эти вот уровни для нейрона. Раньше разработчик, он в основном писал саму логику, а, приложения, в котором он работает. Сейчас же он создаёт среду и инфраструктуру, внутри которой модель сама может выполнять эту логику. В этом и заключается как раз вот этот процесс автоматизации и революции, который происходит в IT.
И здесь вы должны понимать, что какой бы сильный инженер не был с классными компетенциями, если проект не подготовлен для того, чтобы там работалаишка, ну, ничего у него не получится со своими компетенциями. То есть всё равно должна быть определённая зрелость проекта и готовность всей этой инфраструктуры для того, чтобы мм вот эта вся связка и автоматизация нынешнее работала.
Здесь же также хочется ответить на ещё один очень важный вопрос: а что будет, если финансовый пузырь вокруг искусственного интеллекта лопнет? Что если вот все инвестиции, субсидирования, которые сейчас есть, они вдруг не вылятся ни во что и компании там разорятся? Очень частое возражение присутствует в обществе, и с этим тоже нужно иметь понимание, как работать, потому что, скорее всего, действительно финансовый пузырь лопнет. Такое уже мы наблюдали неоднократно за XXI век. И с Иишкой, скорее всего, будет то же самое. И многие на этом этапе говорят про то, что, ну, если это лопнет, значит, вот это сейчас вся инфраструктура, она уйдёт. Никакие яинженеры, харнесы, они вообще не потребуются. И в принципе мы вернёмся в старый добрый IT, где будем писать свои собственные функции. Но давайте подождём немножечко и подумаем вот о чём. У нас был такой же вот разрыв пузыря финансового с доткомами. Исчез ли из-за этого интернет? Хороший вопрос. Лопнул пузырь с криптовалютами, но сама технология блокчейна и stable коины, да, и а какие-то более фундаментальные монетки, они тоже ведь остались. Рынок живёт, инфраструктура вырастает. И с Иишкой вот ровно то же самое. Сейчас выкладывают просто невероятные модели в открытый доступ. Это называется открытые веса. И вы можете, в принципе, ими пользоваться. Если у вас есть просто какой-нибудь стационарный компьютер. Вы можете скачать, например, какой-нибудь Квен 32 млрд параметров или у вас там помощнее железа 72 млрд параметров и уже писать код. при наличии хорошего харнеса это будет прекрасно работать, даже если все open AI, антропики и другие компании, они вот просто умрут в момент, технология-то уже остаётся. Вот буквально сегодня, когда я записываю видео, в открытые веса вышел Kми. Он по уровню э своих размышлений, ну, там что-то похожие на OPUS 4,8, то есть очень мощный и сопоставим с флаговскими моделями того же самого Антропика. И это уже есть в сети. Ты уже можешь это скачать, поставить на свой локальный компьютер и использовать. Ну, для справки KI3 ты не поставишь на компьютер. Для этого нужна будет целая студия или там кластер вычислительных процессоров. Но тем не менее технология будет, и поэтому IT уже никогда не вернётся в прошлое русло. Технология уже здесь. И вот все те вещи, которые я рассказываю в этом видео, они останутся актуальными, потому что люди получили доступ к алгоритму, который может писать код. И этот алгоритм уже лежит в интернете, и вы можете его скачать, как делают это многие компании. Многие вообще компании переходят именно на локальные модели, выстраивают вокруг него харness и спокойно решают свои бизнес-задачи, постепенно наращивая уровни автономности для того, чтобы проект был готов к искусственному интеллекту. Поэтому аргумент про то, что сейчас финансовый пузырь лопнет, он имеет место быть с точки зрения финансов, но он абсолютно невалиден с точки зрения того, что технология уйдёт и мы теперь вернёмся к старому ручному написанию кода. Нет, мы дальше будем продолжать наращивать инфраструктуру и мощности выишки, поэтому это прямое будущее, которое гарантировано в данной сфере.
А теперь давайте соединим всё воедино того, что было в данном видео. Искусственный интеллект научился писать код, но производительность в рынке она моментально не увеличилась, потому что программный продукт - это не количество строк кода, которые теперь можно быстро и дёшево нагенерить. Программный продукт - это большая экосистема и инфраструктура, которую нужно поддерживать на долгой дистанции с большим количеством людей, нюансов, знаний, ограничений, взаимосвязей и обязательств. Поэтому узкое место в текущем IT теперь- это не в написании кода, как это было раньше, а в том, чтобы в первую очередь проверить то, что вероятностная модель нам генерирует. И для того, чтобы правильно это проверять, потому что человеческих ресурсов здесь будет недостаточно, просто нужно выстраивать определённый дополнительный инженерный слой вокруг вашего проекта для того, чтобы грамотно уметь отфильтровать вероятностные решения и понять, какие из них применить вы проект, а какие нет. Именно поэтому вокруг консервативного классического кода появляется новый архитектурный слой, который включает в себя большое количество понятий и термин из мира искусственного интеллекта, такие как и MCP. и RCK, и harness, и Observability, evolation, Tracing, Guard Trails, Memory, Vector Database, Embedings и Context Engжениing, разумеется. Для того, чтобы обеспечивать работу всей этой инфраструктуры, роль обычного разработчика, она переходит от написания кода и классических функций, там, бэкэнда, фронт-тенда, там, девопса в сторону AI инженерии. как вот эти вот все термины взять и соединить воедино для того, чтобы моделька, которая работает у вас на проекте, могла прийти, понять, что ей нужно, и сделать действительно качественное решение. И это реально инженерная работа. Это вопрос про архитектуру, это вопрос про понимание продукта, про понимание кода, про понимание модулей. В данном контексте инженерия, она вообще никуда не уходит, она, наоборот, становится сильнее, просто слегка в другом русле. Раньше мы, как программисты просто брали и писали программы. Теперь мы начинаем проектировать системы, которые могут сами себя писать, проверять, доставлять, поддерживать программы, только уже под нашим контролем. Выигрывает уже давно не тот, кто генерирует больше коды. Выигрывать будет тот, кто научился превращать человеческие и бизнес-запросы в реальные рабочие системы. Надеюсь, вам понравился этот ролик, и вы поняли, что искусственный интеллект, он не отменяет инженерию классическую, а он наоборот её развивает, просто поднимая её на следующий уровень абстракции. Если вы не хотите просто наблюдать со стороны, как меняется индустрия, а всё-таки понять, что здесь происходит и освоить новую профессию, то в описании напомню, что есть ссылочка на мою актуальную практическую программу, в рамках которой вы соберёте свою собственную adentticos систему и поймёте, как вообще всё это работает, и сможете классно взаимодействовать с яишкой. Кстати, если вы заценили антураж и понравилась локация в данном видео, то это я не съездил в Японию в данном случае. Это под Петербургом есть классные отель, называется Шинrрин. Йоку. Вот они предоставили мне локацию для того, чтобы поснимать. Очень классно. Ссылочку на них я также оставлю в описании. Если вы будете под Питером, обязательно скатайтесь. Это очень уютное место. Там очень комфортно и классно. Можно перезагрузиться. Благодарю вам всем счастливым.