Transcription
А, хорошо. А, всем привет. Меня зовут Горковенко Александр. Я ээкэнд-разработчик и бизнес-аналитик в компании Warmsoft.
Собственно, чем мы занимаемся? Заказная веб-разработка от каких-то простых лендингов до сложных корпоративных систем, которые так или иначе помогают оптимизировать бизнес-процессы. И в каком-то контексте жить бизнесу становится гораздо легче после этих оптимизаций.
А пару слов о себе. Мой путь в IT-индустрии начинался достаточно таким нетривиальным путём. Начинал я с разработки смарт-контрактов на языке солидитики в сети, в эфире потобных сетях. Затем перешёл в классическую бк-разработку в основном на ноди, и потом уже начал техдить какие-то проекты. И на данный момент я уже такую примеряю на себя другую роль. Я иду как бизнес-аналитик компании, но иногда включаюсь как разработчик. То есть на новых проектах уже приходится переводить именно какие-то идеи бизнеса в технические решения.
Сегодня хотел бы рассказать, как мы внедряем свои процессы в контексте разработки искусственный интеллект, как мы работали раньше. То есть садишься писать код, видишь какую-то проблему, начинаешь гуглить, начинаешь там Overflow, документация, ещё к Overflow, ещё документация, и в итоге там минут через 20 открыто 15-20 вкладок, и в итоге вообще забываешь, с чего ты начинал. Иногда решение находилось с таким подходом, иногда оно находилось, но оно там актуально было 4-5 лет назад.
А, рассмотрим жизненный цикл продукта от идеи до его реализации. То есть мы собираем требования, ищем решение, документируем, выстраиваем структуру проекта, пишем код, покрываем тестами, делаем ревью, фиксим баги и затем релиз. Всё правильно, всё. Ну, то есть весь процесс описан достаточно верно, но в нём скрывается много технической рутины, которую так или иначе хотелось бы кому-то делегировать. Этом немножко в сторону.
И ээ был и есть такой термин Overflow туризм. Что он из себя представляет? Это когда ты открываешь один к Overflow, потом проваливаешь в документацию, потом в репозиторий, потом опять куда-то уходишь и вот так взрываешься в дебре. То есть, и не факт, что найдёшь решение, как я уже сказал об этом ранее.
А-а, рассмотрим, э, в часах сколько раньше занимала, например, такая операция, как написать, э, сущность, ручки к ней, описать модули, сервисы, там, например, сущность, транспортные средства. А, пишем сущность, пишем миграцию, пишем ДТО, пишем валидацию, контроллерсервисы покрываем тестовыми, добавляем в Свагер и передаём на ревью. Ну, то есть, если в контексте рабочего дня, это практически весь рабочий день уходит на достаточно базовую операцию, которая будет нужна, но по факту, наверное, никакого разработческого кайфа такого не приносит. То есть это такая сплошная типовая рутина.
И где мы теряли время? Теряли время мы не только при написании кода, но и про где нужно разобраться с задачей, ревью полреквестов, пофиксить баги, разобрать нетипичную ситуацию. И одно из самых любимых - это когда спустя два-три спринта к тебе приходит, говорит: "Пофикси баг в коде сотрудника, который там сейчас в отпуске". Ты открываешь его код, начинаешь смотреть вообще, что там имелось в виду, начинаешь вникать. И в, ну, в итоге, если взять вот так вот, ээ, узко, по факту ты там фиксишь три строчки кода, но тратишь на это там час, полтора-два. Ну, то есть тоже удовольствия от этого как такового мало.
А перейдём к блоку, который касается нашего первого опыта работы с искусственным интеллектом. Первое впечатление: быстро генерит, делает красиво. А, но появились и проблемы, которые мы достаточно быстро увидели, иногда врёт и не понимает архитектуру проекта в целом. Мы начали размышлять, может быть, модель не такая, может быть, ещё что-то не так, но как итог, дело не в модели. Дело в том, что модели даётся очень узкий контекст и у неё отсутствие полностью всего контекста проекта. В какой-то момент у нас был хаос, то есть разработчики некоторые обленились и просто Ctrl C, Ctrl V, Ctrl C, Ctrl V. Работает, не работает, работает, не работает. Такой пин-понг начинался между, а, браузерным решением. То есть там чат GPT просто скопировал и отправил в чат. Он тебе ответил, ты вставил такой: "Ага, не работает". Но лично себе, например, я так попытался один раз, и там я сидел полтора часа ему объяснял, что нужно сделать. И у него есть такая особенность, он вам никогда не скажет, что и, ну, я не знаю этого, он будет врать до талова просто. И вот я полтора часа сидел, и в какой-то момент я себя поймал на мысли, что если бы я не делегировал эту задачу ему, я бы, наверное, сам её сделал минут за 30-40. Но в каких-то моментах он был прекрасен.
Аа и используя предыдущий опыт, который я описал ранее, мы подсветили для себя три основные проблемы. У иишки нет контекста проекта именно вот в таком формате общения. Она часто галюционирует, то есть может придумать библиотеки, паттерны, просто от себя кутют лепить. Но чем, ну, понятно сейчас, а, модель усовершенствуется, этого становится меньше гораздо, но это всё равно остаётся и может иногда повторяться. И ломает архитектуру. То есть она не знает ограничения, не знает вашу архитектуру, не знает там стиль кода ваш и так далее.
Сейчас, прежде чем перейти к следующему блоку, кто-то знает, что такое MCP? Поднимите руку. Угу. Не так много. Если дословно, это переводится model context протокол. То есть это способ подключать ишку к внешним инструментам, сервисам, там, не знаю, базе данных, там, чтобы она ходила и распаршивала разные файлы ваши и смотрела ваш код, куда ей нужно. Угу.
А как выглядит наша инфраструктура именно касаемая и в компании на данный момент? А из облачных решений мы используем кодекс в связке с GPT 5.2 и локальная модель, которая работает на физическом сервере в офисе - это GPT OSS на 120 млрд параметров. И из инструментов, что мы используем, это килокод, э, расширение, плагин для IDE, а MCP контек седьмой. Ээ, кто-то знает, что такое MCP Контекст седьмой? А, о, один человек вижу. Точно. Аа, собственно, эта тула, которая держит в себе всегда актуальную документацию по библиотекам, расширениям, фреймворкам и помогает модели актуализировать знания по тем или иным вещам в разработке. А глобальная такая тула webarch, то есть если контекст - это работа с документацией фреймворков, библиотек и зависимости, то webarch - это глобальный поиск. То есть там, не знаю, вам написал агент написал, что вот так и так. Ты говоришь: "Не, давай мы сейчас подрубим тулувысёрч. Ты сходишь, посмотришь первые пять страниц, пришлёшь информацию и скормишь их нейронки. А Chrome def Tools это тоже MCшка, которая подрубается к локальному браузеру, где вы там пишете фронт, забирает оттуда логи и скармливает их иишки и какие-то свои самописные MCP. Но тут, скорее всего, аа, насколько я помню, это не в разработку, это там заполнение каких-то документов в формате опроса. То есть у нейронки есть образец документа, ей нужно собрать определённый перечень информации, и затем она выплёвывает вам готовый документ, заполненный вами. То есть там номер телефона, имя, фамилия, ещё какие-то вещи. То есть мы так нашим там бухгалтерам упростили работу в каких-то моментах.
А, поговорим немножко приближено про килокод. Что такое килокод? Как я уже сказал ранее, это расширение для IDE, которое как раз-таки занимается управлением э навыков MCP тулов. Мы ставим какие-то ограничения на уровне его. И у Killлокода достаточно классная документация, которая, а, дефолтно описывает, как с ним работать можно. Но опять же, там всё плавно, и я далее расскажу уже, как конкретно, какой workflow у нас с килокодом.
А вот, собственно, наш workflow. В контексте разработки у нас есть, э, три роли у агентов. Первый - это архитектор, второй код и третий тест. А архитектор как ээ работает вкратце, я далее более подробно расскажу. То есть, э, разработчик пишет задачу, архитектор его опрашивает, какие директории затрогают, ну, правильно ли, а, агент понял задачу. То есть как таковой архитектор с кодом не работает. Он формулирует Markдаdown файл и складывает его в указанную директорию как ТЗ конкретной задачи. Когда разработчик опровывает, что действие архитектора, мы переходим в следующую итерацию к агенту с ролью код. Он смотрит это ТЗ и реализует код строго по этому ТЗ, затрагивая только те директории, которые там описаны. И после того, как разработчик там запустил этот код, посмотрел, работает, то есть сделал какое-то ревью минимальное, либо там сам руками поправил, либо также с помощью агента. А, переходим дальше и пишем там уже по сгенерированному модулю тесты. То есть и такая небольшая оговорка, то есть это по большей части, я рассказываю сейчас про разработку вот в контексте на моего понимания, ээ, именно бэкэнд часть, то есть, ну, на фронте там немножко иначе и сложнее. Там вот именно в плане тестов гораздо больше человеческого внимания нужно.
А вот из чего состоит структура проекта, то есть классически у нас там frontend, backend и добавляется три новые директории. ТЗ - это куда модель с ролью архитектор складывает технические задания по каждой задаче. А директория AI в каждом проекте она своя, где описывается стек проекта, архитектура проекта, ограничения, какие-то особенности, особенности бизнес-логики и так далее. и дефолтная директория килокод, в которой, а, описываются уже конфиги, какие эмсипишки мы подрубаем глобально, какие эмсипишки мы подрубаем только на этот проект, э, тоже какие есть ограничения. Файл killкод игнор, то есть в какие директории и в какие файлы ходить нельзя и смотреть их и скармливать их глобальный нейрон, где AI даёт реальный буст - это достаточно типовые задачи, которые много раз повторялись. Ну, срези знаний ишки. Это крут операции, тесты, SQL, revюw документации.
Давайте поговорим немножко про промт. Это очень важно. То есть, что вы на вход дадите яишки изначально, то тем ближе будет тот ответ, который вы хотите получить. То есть промт сделаем мне ДТО для авторизации пользователя на NJS будет примерно выглядеть так. Сказать, что он неверный, ну, это будет неправильно. Он верный, но он более абстрактный. И, то есть, как сказано уже на слайде, это неплохой код. Это код без контекста. Идеально. То есть мы на вход даём стек, ээ, даём, какая валидация нам нужна. Вот. И формализуем, то есть говорим, какой ответ на выходе нам нужен. То есть, что мы видим здесь уже? Мы видим, что нейронка добавила нам декораторов, что это только email, что это обязательный параметр для пароля, что это тоже обязательный параметр и минимальная длина восемь символов. Со временем у нас сформировался такой чек-лист промта, что должно при разработке уходить э на вход всегда. Это контекст проекта, стек, архитектура, ограничения, затрагиваемой директории и формат ответа. Это вот, собственно, та тесная работа тех директории AI, ТZ и Kocд, которые дают нам а вот такой идеальный промт. И тоже небольшая оговорка, то есть я сейчас рассказываю, но буквально там 3 дня назад мы какие-то процессы переварили и немножко что-то делаем по-другому. То есть это не такая какая-то священная грали и золотая середина. Мы продолжаем совершенствовать, что-то убираем, что-то удаляем, но что-то достаточно плотно закрепилось в нашей работе.
Аа генерация тестов, отдельный момент. Ээ ну тесты, наверное, это не самое приятное вообще, кто что любит делать на проекте и про них либо забывается, либо откладывается на потом. Но в контексте разработки очень круто справляется с вот мы написали сервис и дальше идёт у нас роль агента с точнее агент с ролью тест. И он покрывает этот модуль там toend для pнпоинтов, интеграционными тестами для модулей или там юнит-тестами для различных сервисов. Но не всё так радужно. А есть и подводные камни свои, есть и нюансы, что слепо доверять нейронки не стоит. То есть там скопировать, вставить, проверить, запустил, запустилась и ушёл и отправил там в прот или куда-то на эмрку отправил на ревью. Ну это достаточно такой плохой стиль работы. И, наверное, кто так делает, его не задержит той компании, где он работает.
Давайте поговорим про опасности. Опасность номер один - это устаревшие решения. Что это значит? Если взять достаточно свежую модель, я знаю, что уже вышло там 5,4 GPT, но такая достаточно непрожорливая, но эффективная GPT 5.2, у неё срез знаний - это август двадцать пятого года. Если мы у нас сейчас март двадцать шестого года, уже прошло да больше полугода, по идее. И так как ничего не стоит на месте, знания могли уже какие-то устареть, какие-то вещи быть неактуальными. И для этого как раз-таки мы используем различные MCP тулы, такие вот, как я уже сказал ранее, Websearch и контекст седьмой, что помогает нам актуализировать знания и подпитывать контекст в нашей разработке. Вторая опасность - это галлюцинации. часто придумывают библиотеки, которых нету, функции, паттерны, которые давно признаны антипаттернами и так далее. Поэтому, то есть, валидация разработчиков всегда на первом месте в этом плане. И отсутствие бизнес-логики. И AI никогда не понимает бизнеса и заказчика, аа полутонов созвонов с заказчиком, что заказчику вообще нужно. А, то есть, как уже сказано, да, вот SQL запрос, он будет, может быть, красивый, вы отдадите его аналитику там или напишете ручку для кого-то, но по факту данные будут красивые, но не верные. Поэтому тут тоже требуется дополнительная валидация всегда. И если предыдущие два кейса ещё как-то можно было обойти, но вот с бизнес-логикой и пониманием бизнеса, ну, наверное, тут человек пока точно незаменимый на ближайшее время останется. И главное правило: я не равно архитектор. Под архитектором я понимаю, не подразумевая не то, что я сказал ранее, что у нас есть модель с роль архитектора в глобальном понимании. Человек, который выстраивает систему, человек, который затрагивает инфраструктуру всего проекта, выстраивает работу. И человек всегда остаётся таким надзорным органом. Он стоит сверху по иерархии на DI и только опровывает его решение у себя.
Как изменился наш пайплайн? До этого он выглядел так. То есть тут такие шесть различных вариаций. Сами пишем тесты, сами дебажем, сами пишем код. Это выглядело до. То есть как изменился наш пайплайн более подробно, мы сейчас рассмотрим. А этап один, э, архитектор, агент в режиме архитектор, разработчик описывает задачу, а, агент описывает ТЗ, задаёт уточняющие вопросы. описывает затрагиваемые директории и сохраняет Markдаун файл в директорию ТЗ. Разработчик подтверждает, либо тут свобода воли, как бы разработчик может либо сам пойти по этому ТЗ, написать код, либо отправить его дальше агенту. А после того, как опрувнули ТЗ, начинаем реализовать строго ПТЗ задачу, создаём, редактируем файлы, формируем список затронутых файлов и главное соблюдаем правила проекта, которые у нас сохраняются на уровне директории AI. Разработчик проверяет, запускает, возможно, делает какую-то отладку, что-то добавляет от себя и передаёт на следующую стадию. тестирование. То есть после того, как прошли второй аprв, начинаем писать тесты, и разработчик тоже остаётся итоговым звеном в этой цепи и опровывает тест.
Почему это важно и почему вообще мы так сильно заморочились вокруг и инфраструктуры и работа с этим? То есть время идёт, время не стоит на месте. И разработка это, наверное, уже становится не только про написание кода, а про скорость принятия решения, про скорость самой разработки и про скорость доставки э идей бизнеса уже реализованных. И то есть ээ поэтому здесь этот инструмент уже будет незаменим, и это реально даёт в каких-то вещах очень хороший буст. И такой момент, что AI не делает разработчика умнее, но помогает ускорить многопроцессы прям, ну, ощутимо на часы. И когда таких задач там тут час сэкономили, тут час и их становится там десятки, а то и сотни, а результат становится ощутимый. И про цифры хотел бы поговорить в следующем слайде. На примере нашей компании я открыл прямо там трекер часов разрабов и посмотрел, то есть там как было условно, не знаю, когда мы, ну, пускай в мае, то есть мы вот заморочились, наверное, только за последние там 4 месяца с осени, начиная а над всей вот этой инфраструктурой. То есть написание крут базовое - это минимум 3 часа. Сейчас улучшение практически больше, чем в два раза. На тестирование минимум 50% времени сократилось. И написание документации, когда ты движешься в контексте и тебе модель всегда подпитывает там техническое задание, ещё какими-то новыми затрагиваемыми файлами, документацию составить гораздо легко, потому что весь этот контекст впитывается в формате переписки.
Такой достаточно насущный вопрос. Заменит ли и разработчиков? Нет, не заменит. в каких-то в каких-то кейсах уже реально заменяет, то есть там документация, написать сервис, написать контроллер, написать вот базовый крут вообще в целом, да, но архитектуру и бизнес-логику не заменит никогда. Э, ну, это опять же моё такое личное мнение, да, может быть, кто кто-то скажет: "Нет, ты не прав". И он заменит вас всех. И так, достаточно такой чуть с юмором вывод. I вас не заменит. Заменит вас разработчик, который умеет пользоваться AI. Всё. Так. И также, да, хотелось сказать спасибо организаторам за предоставленную возможность. И если было интересно, подписывайтесь на канал моего руководителя Антон Морев, канал Галера Морев. Там очень много он рассказывает как раз по как подрубить аа различные нейронки и также на мой канал. Буду рад. Спасибо большое. >> Ещё раз спасибо. Ну что, переходим к вопросам. Есть желающие? Отлично. >> Раз. Раз. Так, ещё раз привет. Меня Слава зовут. А я сейчас скажу, о чём все стесняются сказать. Вот там был слайд фронтend, backend. У нас всё в одном проекте. Зачем тогда системные аналитики? Допустим, мы их увольняем. А кого ещё можно тогда уволить? Кажется, что вот, допустим, аналитика не нужна уже, получается. Это первый вопрос. Кого ещё? А второй вопрос вот не все в компании всегда принимают вот эту игру. то, что появился искусственный интеллект. Кто-то говорит, типа, его нельзя на сложные задачи, а как нам заставить их изменить свою точку зрения, потому что мы видим буст по времени, они всё ещё не хотят перейти. Что мы с ними делаем? >> Ну, так, давайте начнём с первого. А как такового там системного аналитика в контексте нашей компании нет. Есть бизнес-аналитик - это я. Я редко влезаю именно в системную аналитику. А со стороны заказчика у них явно есть. То есть мы там делаем проект, мы его саппортим, но передаём им. То есть если им нужна какая-то у них с их стороны есть системный аналитик, мы ему помогаем там реализовать какие-то запросы или открываем просмотровый доступ к базе данных и даём ему доступ к какой-то аналитике изолированной. Это отвечая на первый вопрос, да? А отвечая на второй вопрос, ну я думаю, тут время само расставит на места. Просто в какой-то момент востребованность ээ людей, которые будут очень сильно ершиться от технологии, но, скорее всего, будут менее востребованы. >> Угу. Спасибо. >> Меня зовут Артём, всё ещё, кажется, лид фронтенда в компании Русский Экспресс. Несколько вопросов. Вопрос первый. Предположим, мы, значит, натравили ишку на какую-нибудь Фигму через MCP. Всё классно. Она такая давай всё реализовывать. Мы ограничили контекст, архитектуру, там ТЗ, туда-сюда. И где-то в части каких-то блоков она вместо того, чтобы реализовать какой-то блок, она его придумала, а потом тесты, которые мы туда же натравили, она считает, что пройдены замечательно. Вот эти тесты яичные. И отсюда первый вопрос: как или ограничить, или помочь Иишке, чтобы она не гавалюционировала? >> Ну, смотрите, если мы, если у нас огромный проект и мы дадим, э, на весь дизайн фигмы, то, конечно же, она где-то споткнётся. Это, вероятно. Ну, поэтому возможно идти небольшими итерациями, то есть и всегда валидировать её результат, как я сказал вот ранее, что, да, о'кей, она пошла, ну вот даже если взять этот кейс, где она по туле пошла в Фигму, забрала оттуда дизайн и начинает его верстать, быстро накидывать везде, но может быть там, не знаю, пойти с одной страницы, что давай вот мы сейчас опишем вот эту страницу, и ты накидаешь дизайн - и уже там разработчик отсмотрел И потом он уже передал на следующий шаг, например. Но тут такой момент тоже с Фигмой. Вот что именно мы подрубали, да? Ну, с фигмой пока неоднозначно работает. То есть есть момент. И где мы это используем? Мы используем это, когда нам нужно быстро накидать что-то. Верстальщик у нас там занят девушка или фронты заняты, но у нас показ и нам нужно не с линейкой бегать по интерфейсу и мерить, где у нас какие отступы, а просто показать функционал и сказать: "Ребята, ну вначале, что мы сейчас покажем функционал, не смотрите на визуал. Визуал мы в течение дву-трёх дней подправим". Вот в этом плане вообще идеально работает. Но на у нас на любом этапе врубается фронт и вёрстка, то есть и который это всё доводит до идеала. О'кей, спасибо. И второй вопрос. Вот есть читай последняя миля. Написание функционала и написание тестов. Предположим, мы ограничили контекст. Вот. Вот всё по красоте сделали, всё классно. >> И вот, значит, эта штука магическая написала, значит, нам код, который должен решать задачу. Он как будто её решает. А потом другая часть этой магической штуки пишет тесты. >> Тесты такие: "Ага, вот тут проблемы". Они говорят: "Первый штуки перепиши". Первая штука идёт переписывать. Потом идут тесты. Тесты говорят: "Нет, что-то не получилось". Снова возвращаемся на предыдущий шаг. Снова тесты провалились. Снова возвращаемся на предыдущий шаг. И получается, мы зациклились. А Ишка может уйти вообще куда-то не туда, а может туда, потому что она там своим яичным мозгом что-то там у неё пошёл цинкин на несколько листов. И как сделать процесс управляемым и атомарным для того, чтобы минимизировать или совсем предотвратить вот такие круги? >> Мм, иногда, наверное, стоит влезать руками, какие-то вещи делать. И для этого как раз-таки нужен разраб тестировщик с реальной насмотренностью и опытом. Ну, то есть, если ты видишь, ощущаешь, что он начинает взрываться, например, в каком-то контексте или там сильно уже раздутый контекст, ты сам влезаешь и просто руками правишь. Вот тут такой момент тонкий, что вот как я описывал, у нас были там достаточно такие ленивые разрабы, которые, надеюсь, они не услышат меня, а, которые Ctrl C, Ctrl V, блин, не работает, типа опять Ctrl C скопировал ошибки, не работает. И, ну, вот так. И в какой-то момент нужно понимать, что такой, блин, ну что-то она начинает буксовать. А давай-ка я сам подключусь в этот момент. И вот это будет тоже один из нужных скилов, как минимум. >> А не будет ли вариантом, если мы совсем до каких-то маленьких конструкций будем ограничивать контекст, что вот на этой странице вот этим блоком мы сейчас занимаемся, ты его реализуй, а ты его проверь. Может ли это нам помочь >> повысить вот вот эту >> добавляется ещё одна роль. То есть вы имеете виду, >> добавляется ещё одна роль. А, объём итераций сокращается, >> объём контекста сокращается и для инкрементации, и для тестирования. Таким образом, кажется то, что там негде запутаться. Как ты думаешь, могло ли бы это? >> Ну, сокращение контекста и задача, конечно, чем точнее, чем меньше и точнее контекст будет, тем лучше будет реализация. Ну, то есть даже все бенчмарки, они говорят об этом. Угу. >> Что? >> Хорошо. Спасибо. Спасибо за вопрос. >> Раз, раз. А, Ярослав, бкэнд разработчик. А, у меня такой вопрос первый. Это, а-а, я просто немножко не уловил контекст по презентации. Получается, вы натравливали это только на фронтовые задачи? >> Не, наоборот, только на в основном только ээкэнд. То, только ээкэнд. Отлично. Тогда такой вопрос. А как хорошо вот агент и Ишка в целом держат контекст при задаче межсервисного взаимодействия? Ну то есть когда Фича внутри себя реализует какие-то там поинты похода куда-то ещё в другие сервисы и реализацию логики этих поинтов в других сервисах. >> Ну то есть одно дело в одном проекте натравить сделай мне там вот такой там классик накидает, чтобы он реализовывал то-то. А когда нужно именно взаимодействие между разными сервисами, которые в одном зоопарке вертятся. Но тут зависит много ещё от модели. То есть у нас есть модель вот GPT OSS 120B. Она достаточно скудновата с большим ко у неё и контекст достаточно урезан в силу там наших мощностей. Мы пока в качестве эксперимента подрубили вот RTX 3090 и обкатываем локальную модель эту на каких-то достаточно узкоконтекстных задачах, где вот ты дал и всё дальше. То есть она уже тулами не будет входить. А вот как вы описали там 5,2, ну в 80% случаев достаточно отлично справляется. Тем более, когда идёт такая связка плагин килокод, она такая: "О'кей, мне надо реализовать это". А, подожди, а вот тут почему-то, э, там этот модуль ещё подрубает тот модуль. А давай мы туда сходим, посмотрим, что там есть. Они такие: "Ага, от этого у нас зависит". И она, ну, она может реально минут пять ээ открывать файлы, впитывать контекст. И, ну, в 80% случаев будет достаточно валидный результат, но который, возможно, нужно будет руками чуть-чуть подправить. >> О'кей. Тогда вот следующий вопрос. касаемо этой же темы. Мм, есть ли какая-то корреляция о размерности фичи галлюцинации? Ну, то есть над над маленькой фичи, да, она, скорее всего, легко справиться, но вот если фича там достаточно обширная, да, затрагивает там много сервисов, вот вообще вот насколько она справляется с таким? Я сейчас вспомнил, у нас один из раз из разработчиков, когда мы внедрили килокод массово, скажем так, и рассказали, как его подрубать, а один из разработчиков сказал: "Блин, а что мы работать будем? А давай вот нам ТЗ дали, мы сейчас туда скинем и всё, я кушать пойду". И ну ну к сожалению, так это не работает. Тут тоже нужен контроль и нужно всегда декомпозировать ту или иную фичу, хотя бы, ну, разбивать на небольшие подфичи и скармливать. Но опять же, чтобы, знаете, эта декомпозиция не уходила для работы СИ ради работы СИ, а чтобы это, ну, реальный такой улучшай оптимизация была именно во времени. >> Ну да, понятно. >> Ну то есть, как я описал там вот плохой хороший промт, я взял такой достаточно абстрактный, лёгкий пример. Конечно же бы руками это написалось бы всё быстрее, чем объяснять яишки, что вот мне нужно так, так, так, так, там из двух полей сделать, написать дтошку какую-то. >> Ну, я понял, опыт был как бы этот такой бе Bad PR. А тогда вот следующий вопрос больше процессный. Э-э были цифры касаемо сокращения, да, на времени на задачи какие-то. Вот. Но при этом говорилось, что в любом случае нужна валидация живого человека, каких-то фич, которые реализуются. >> А вот были ли кейсы, когда вот валидация живым человеком, она как бы отнимала достаточно большое количество времени? То есть, ну, понятное дело, что, скорее всего, большая часть процент фич они протекают как бы с сокращением времени, но по-любому есть какие-то узкие места, вот когда, допустим, валидация занимала очень много времени, что человеку нужно было разобраться во многом количестве кода, как бы понять вообще, что там нагенерил. >> Ну, лично у меня был такой опыт, я просто написал агенту, я посмотрел, что он там, ну, не знаю, 400 строк кода сделал и в разных сервисах всё это как-то запутано. Я такой: "Так, чувак, давай этот, ну, я тут же в кодерской модели остался". Я говорю: "Положи мне в корень проекта MD файл, где ты чётко расписываешь, где что-ты сделал построчно там практически". Ну, не построчно, а вот именно по логике. И он меня, ну, прямо этим MD-файлом вводил такой: "Я сделал вот это здесь, потому что это". И я уже в контексте работы делал отсылки, говорю: "Слушай, вот здесь вот то, что ты написал там в в этом описании, давай мы переделаем, мне это не нравится". Но и тогда провалидируй последующую логику, чтобы она нигде не сломалась в твоей реализации. То есть, да, такой кейс был, когда там 500 срок, я такой: "Да, ё-моё". Ну и, конечно, ну, то есть тут ещё настолько гибкий процесс, что к нему нужно будет подстраиваться. >> Всё, спасибо большое. >> Спасибо вам за вопрос. >> Здравствуйте. Тимур Даянов, менеджер айтека по сейчас как раз очень много занимаюсь и вопрос такой, не ловили ли вы у себя эффект того, что специалист, который занимается искусственным интеллектом, выгорает за счёт того, что очень много делает операций, много работает и не успевает фактически за работой Иакуственный интеллекта? >> Мм, не понял. Ещё раз не успевает. >> Смотрите, а приходит очень много задач, да, на человека, который управляет этим искусственным интеллектом. Угу. >> И фактически вот я на себе ловил. Сидишь до по:30, до полго, очень много интересных задач, очень интересно, и понимаешь, что ты больше исправляешь с искусственным интеллектом, направляешь его на уки на свой путь и ловишь такой эффект, что не понимаешь, что происходишь. И просто вот за счёт того, что тебе это очень интересно, получается, что произвольность твоя собственная становится хуже. >> М, может быть. Я, если правильно понял вопрос, как раз-таки вот внедрением, обкатыванием, э, под счётом, сколько это вообще будет стоить на практике, занимаюсь я и вот мой руководитель. И в какой-то момент я словил себя на мысли, что я не успеваю за статьями на Хабре: "Вышло это, вышло это, вышло это". И то есть я такой: "Да ё-моё, ну мы мы это ещё не протестировали, там уже что там пишет: "Openc там вышло, давайте open clow". И я такой: "Ну и что делать?" Ну мы сейчас как-то остепенились с этим, да, выстроили архитектуру. Я говорю: "Так, Антон, давай, говорю, мы стопорнёмся, нас устраивает вот ээ такой workкфлоу сейчас". Он говорит: "Да, я говорю: "Да, мы его будем допиливать и не будем кидаться на всё подряд". И как бы мы пришли к такому пониманию, если я правильно понял вопрос ваш. >> Неправильно поняли, но второй вопрос был как раз про эту тему. А-а >> как успевать за обновлениями моделей? >> Модели >> моделей разных. Open cl, cloud cд, опус 46 сейчас вышел уже месяц. как он настолько большие результаты даёт, что вообще непонятно, как этим управлять. >> Ну мы в этом плане, то есть вот мы обкатали 5,2, вышло 5,4. Да, мы попробуем 5,4 без упреч, но дорогой, типа он достаточно прожорливый в плане токенов. Э, но 5,2 закрывает, например, 5,4 наших потребностей, а 5,2 80, но э ном 5,2 дешевле в 10 раз. Мы останемся на 5,2, пока, да, 5,4 не подешевеет. >> И последний вопрос. Локальное оборудование какое использовать? Э-э, ну вот в плане видюхи, я скажу, это RTX 3090, а в остальной, я для там 30 человек компании, которые этим пользуются достаточно не в одно время, скажем так, более чем. >> Спасибо. >> Спасибо большое, Саш. Ну, ещё на один вопросик тебе хватит? >> Конечно, конечно. >> Отлично. >> А, небольшой быстренький вопрос. Что вы делаете в плане безопасности? А очень часто в России, ну, очень часто стали происходить такие случаи, когда разработчики заливают, ну, видимо, по ошибке, по зорке какую-нибудь персональную информацию в ии и потом, а, хакеры какие-то могут эту персуху утащить. >> Это стало происходить последнее время достаточно часто. То есть, что вы делаете для защиты персональной информации? Апишники, открытые порты. >> Угу. А, ну для этого я уже там, да, когда описывал инфраструктуру, у нас есть локальная модель, которая дальше нашего железного сервера в офисе не уйдёт. То есть и какие-то особо конфиденциальные вещи мы прогоняем через неё. Да, она глупее, да, она тяжелее, да, с ней более до того, что нужно работать, но именно вот для такого мы её и подрубали. >> Ну, при обновлении, опять того же, >> при обновлении А, ну она работает в закрытом контуре, она даже в сеть может не выходить. Она работает вот в рамках железной коробки и всё. Ну, то есть, если мы мы только захотим стащить что-нибуд, но пока такого вроде не было желания. Всё о'кей.