Start free

Get App

Home
/
Transcripts
/
Russian
/
Как использовать AI разработчику в 2027 / Полный курс по AI в 6 часах — Transcript

Как использовать AI разработчику в 2027 / Полный курс по AI в 6 часах

Курс по использованию AI в разработке на 6 часов: классы нейросетей, промпт-инженерия, работа с кодом, тесты и применение ИИ в повседневной жизни.

Key Takeaways

Эффективность работы с ИИ определяется навыком, а не только выбором модели
Выбирать инструмент нужно под задачу: чат для изучения, IDE-агент для работы с проектом
ИИ автоматизирует механическую часть работы, ключевые решения остаются за человеком
Специалисты, владеющие ИИ-инструментами и демонстрирующие это на собеседовании, востребованы бизнесом

What the video covers

Автор объясняет, что хайп вокруг нейросетей часто не подкреплён конкретными инструкциями, и предлагает практический гайд по применению AI для разных специальностей
Вывод: ИИ не заменяет людей напрямую, а люди, использующие ИИ, вытесняют тех, кто его не использует; бизнес ценит специалистов-оркестраторов
Рекомендация: не бояться замены, а ускорять свою работу с помощью ИИ, чтобы повышать доход даже в кризис
Обсуждается, почему два разработчика с одним запросом получают разные результаты: дело в навыке, а не в инструменте
Три класса инструментов: чат-помощники (ChatGPT, Claude, Gemini, Perplexity, DeepSeek) для обучения и абстрактных вопросов, интегрированные IDE-инструменты (например, Cursor) для работы с проектом, и агенты
Чат-помощники работают только с тем контекстом, который пользователь в них прикрепил; инструменты для кода анализируют весь проект
Качество результата сильно зависит от промптов; важно понимать, как модель обрабатывает текст запроса
Практические демонстрации: написание тестов с помощью ИИ, работа с API, поиск ошибок, документация, миграции старого кода
Упоминаются риски: отправка кода на серверы провайдера, эмбеддинги проекта
Отдельные главы про использование ИИ в быту: планирование, аналитика жизни, тренировки, питание

Chapters

Почему один и тот же запрос к ИИ дает разные результаты у разных разработчиков?

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

Чем чат-помощник отличается от инструмента для работы с кодом?

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

Заменит ли ИИ разработчиков?

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

Full Transcript — Download SRT & Markdown

00:05

Speaker A

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

00:23

Speaker A

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

00:40

Speaker A

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

01:01

Speaker A

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

01:23

Speaker A

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

01:44

Speaker A

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

02:00

Speaker A

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

02:21

Speaker A

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

02:32

Speaker A

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

02:43

Speaker A

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

03:04

Speaker A

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

03:21

Speaker A

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

03:39

Speaker A

Быт, переезды, планирование путешествий, просмотр аналитики по вашей жизни, тренировки, питания. Короче, постарались веерно обозреть все способы применения AI в реальной жизни. Не просто на бумажке, а реально рабочие, которые я применяю каждый день и, надеюсь, ускоряю свою работу.

04:04

Speaker A

Привет. Я Вадим, ментор по фронт и основатель проекта Фронтенд Mountain, [музыка] где мы взбираемся в гору, прокачиваем харды, софты, анализируем рынок, накручиваем опыт. И всё это для вката и повышения условий работы в IT.

04:20

Speaker A

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

04:31

Speaker A

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

04:49

Speaker A

5.000 человек. И на обучение одной только модели они потратили около 100 млн долларов, при этом держа в работе пару месяцев подряд около 25.000 видеокарт. Кчему я об этом рассказываю?

05:00

Speaker A

Когда второй разработчик говорит: "Неронко не работает", он по сути заявляет, что тысячи инженеров и миллиарды вложенных долларов вдруг оказались бесполезны конкретно для него.

05:10

Speaker A

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

05:22

Speaker A

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

05:31

Speaker A

Например, CHG GPT и курсор отличаются друг от друга примерно так же, как обычно блокнот от полноценного.

05:38

Speaker A

Во-вторых, у каждого инструмента есть свои сильные и слабые зоны, и компании, которые их разрабатывают, Open AI, Antropic, Google, китайская Deepsic, Perplexity, намеренно делают акцент на разных сценариях. У одних приоритет на чат, у других приоритет на работу с кодом, у третьих на поиск. Да, их

05:56

Speaker A

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

06:11

Speaker A

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

06:28

Speaker A

задачи? Как получить топовую модель за 3,5 доллара без потери качества? Как заставить глупую модель работать лучше с самой умный? И в целом у тебя отпадут 90% вопросов: а как вообще использовать и Но обо всём по порядку.

06:47

Speaker A

На какие три класса делятся все нейронки? Почему чат GPT, курсор, Cloud код нельзя сравнивать напрямую? Многие думают, что Eинструменты для разработчика отличаются только обёрткой и качеством модели, но это не так. Они отличаются принципом работы. И один и тот же запрос в разных инструментах даёт

07:05

Speaker A

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

07:22

Speaker A

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

07:37

Speaker A

тему примерами и аналогиями. И для такого типа задач, где нужен умный собеседник, подойдёт первый класс E. - это чат-помощники, чат GPT, CL, Gini, Perplexти, Deep. Принцип работы простой.

07:49

Speaker A

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

08:02

Speaker A

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

08:18

Speaker A

получишь относительный результат. Сделаем короткий вывод. Для изучения чего-то нового тебе нужно использовать чат-помощники. Чат GPT, Clod Mini, Perplex, Deepsi. А какой из них лучше, какой нужен тариф под задачу и как написать промпты, чтобы получить высокий результат, мы поймём, что дальше. Вторая

08:36

Speaker A

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

08:51

Speaker A

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

09:09

Speaker A

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

09:26

Speaker A

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

09:42

Speaker A

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

09:59

Speaker A

разграничение всех и - это автономные агенты. Есть всего два качественных решения на рынке. Это Cloud код и OpenCD. Они одинаковые по принципам работы, но CloudД сделан компанией Antropic под их же модели, а OpenCode - это открытое решение, в которое можно

10:15

Speaker A

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

10:35

Speaker A

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

10:53

Speaker A

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

11:10

Speaker A

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

11:24

Speaker A

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

11:43

Speaker A

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

11:59

Speaker A

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

12:14

Speaker A

находится только один инструмент. Обычно это три-четыре нейронки, с которыми они работают параллельно. Кто-то пишет код в курсор, ищет объяснение в чат GPT, делегирует крупные задачи в cloud код, а ищет источники информации в Perplexity.

12:27

Speaker A

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

12:50

Speaker A

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

12:59

Speaker A

У него 900 млн пользователей в неделю и 50 млн платных подписчиков. Он не самый умный из пяти, не самый продвинутый по моделям, но самый известный. Поэтому вокруг него собрана самая большая экосистема, которой нет ни у одного конкурента. Это значит, что у Chatт GPT

13:16

Speaker A

больше всего обучающих материалов, больше всего готовых промтов в интернете и больше всего интеграций с другими сервисами. Что у него в тарифах?

13:24

Speaker A

Бесплатный тариф хорошо работает примерно на первые 10 сообщений на модели GPT 5.3 Instant, поэтому тебя формально не выкидывает из чата, а просто автоматом включается модель Mini.

13:37

Speaker A

Но модель Mini точно не справится с глубоким анализом. И как только задача становится сложнее объяснения термина, то ты почувствуешь, что ответ не совсем подходит. Плас за 20 долларов. Это первый тариф, на котором ты можешь прогнать через A весь свой рабочий день

13:53

Speaker A

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

14:10

Speaker A

веб-интерфейс, а cloudкод локально в терминале. И большинство пользователей ла об этом не знает и продолжают работать только с чат-помощником. Про за 100 или 200 долларов. Проза 100 долларов - это тот же пластриф, но с повышенной пятикратной квотой на все инструменты и

14:27

Speaker A

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

14:43

Speaker A

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

14:59

Speaker A

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

15:16

Speaker A

клод. Дальше ты поймёшь, почему. Давайте раскроем инсайты, которые узнаешь только через полгода работы с чат GPT. Первый инсайт. В текущей топовой модели GPT 5.5 есть два режима работы: базовый instantнт и углубленный финкинг. По умолчанию включён instantн. Он быстрый,

15:34

Speaker A

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

15:55

Speaker A

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

16:15

Speaker A

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

16:33

Speaker A

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

16:53

Speaker A

по Chat GPT. Вокруг chat GPT собрана самая большая экосистема, которой нет ни у одного конкурента. И сам по себе как сервис, он не заточен под одну конкретную задачу, которую сделают лучше других. Например, Clлод лучше работает с кодом, Дмини лучше анализирует данные,

17:10

Speaker A

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

17:27

Speaker A

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

17:44

Speaker A

команде могут им пользоваться без подписки. У Клод есть похожий механизм Project, но поделиться, к сожалению, им нельзя. И это вторая уникальная особенность Chat GPT. Cl - это продукт компании Antropic и главный конкурент Open AI. Openi, от школьника до инженера, ароop с самого

18:04

Speaker A

начала сосредоточился на создании сервиса для разработчиков и аналитиков. Их модели стабильно входят в число лидеров на профессиональных тестах по написанию кода, например, SVE Bench и Human Evil. И результат их работы видны в положительных отзывах разработчиков, которые одновременно работают и с

18:23

Speaker A

экосистемой Antropic, и с экосистемой Open AI. У ClЛОТ есть две основные модели. Sony 4.6 и Opus 4.8. По сути, это как instant и thinking режимы у chet быстрее и дешевле. OPus глубже, но жёт лимиты. И может появиться вопрос, как

18:41

Speaker A

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

18:59

Speaker A

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

19:18

Speaker A

Для сравнения, чаge GPT после исчерпания лимита автоматом переключает на модель Mini, и ты можешь продолжить работать.

19:25

Speaker A

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

19:40

Speaker A

Поэтому клод сразу отрезает подобную имитацию экономии времени. Pro за 20 долларов. Это стандарт Sona 4.6 и топовой моделью Opus 4.8, которой нет в бесплатном тарифе. И это второй тариф наравне спла от Open AI, который даёт минимум три инструмента в одной

19:59

Speaker A

подписке: чат-помощник, автономный агент, cloud код и функционал Project. По сути, Projects - это аналог custom GPTS, который мы разбирали до этого. Ты создаёшь ассистента в рамках своей базы знаний, но есть ключевая разница. Custom GPTS можно поширить с командой, а

20:15

Speaker A

Projects в clк clк нет. Зато клот держит большой объём контекста и отвечает намного строже. И третий тариф Маx 5X и 20X за 100 и 200 долларов. Основное отличие от предыдущего Pro тарифа в кратном увеличении лимитов и вместе с

20:33

Speaker A

увеличенными лимитами у пользователей повышен приоритет в часы пиковой нагрузки. То есть когда пропользователи чувствуют просадки производительности. И третье преимущество, на Протарифе у модели OPUS есть отдельный внутренний барьер внутри общего лимита, а на Макс этот барьер снимается, и OP тратится

20:52

Speaker A

[музыка] из общего пула наравне Sonet. Объективно валидно купить этот тариф только, если ты пользуешься всей экосистемой Anроopic примерно по 6 часов в день. Давайте поймём инсайты, которые узнаешь только через полгода работы с КЛТ. У меня самого это была главная боль

21:12

Speaker A

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

21:33

Speaker A

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

21:51

Speaker A

наоборот. Во-вторых, корень каждого проекта я кладу файл Cloud MD со всеми инструкциями для cloud-кода, в котором описываю архитектуру, правила оформления, специфичные термины и ссылки на источники. Это общий системный файл, который Cloud CД читает перед каждой задачей. И многие даже не знают, что

22:11

Speaker A

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

22:18

Speaker A

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

22:30

Speaker A

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

22:48

Speaker A

Chat GPT. В одной подписке у тебя есть три инструмента: чат-помощник, Projects для работы с базой знаний и автономный агент Cloud Code. Это та же самая связка из трёх инструментов под одной подпиской, что и учат GPT с кодекс. Но

23:04

Speaker A

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

23:21

Speaker A

в проекте важные перемены окружения, локальная база, нестандартный конфиг сборки, токод работает с этим из коробки напрямую. А с кодекс придётся грузить всю эту информацию в облако. Jме - это семейство моделей от Google. Долгое время Jмени был [музыка] догоняющим. Он

23:38

Speaker A

отставал от чати по моделям и откло по работе с кодом. Но за последний год Google сделал ставку не на догон по моделям, а на то, чтобы [музыка] выстроить Gini во всю свою экосистему.

23:50

Speaker A

Dogs, Gmail, Sheits, Drive. И именно это. И огромное контекстное окно на миллион токенов сейчас главное отличие Gini от остальных нейронок. Что у Gini в тарифах? Бесплатный тариф даёт три-5ять серьёзных запросов в день на топовой модели GMini 3.1 Pro в режиме thinking.

24:10

Speaker A

После этого автоматом переключает на упрощённую модель GMI 3.5 Flash, на которой можно сделать ещё около 30-50 базовых сообщений. И по сути это около 30 минут качественной работы. Дальше работаешь на упрощённой модели. Второй тариф Google AI Plus за 8 долларов. Это

24:30

Speaker A

один из двух платных тарифов на рынке, дешевле 20 долларов. Ещё есть чат GPT GO за 8 долларов, но в нём по умолчанию показывают рекламу под ответами.

24:40

Speaker A

Формально здесь есть доступ к топовой модели GMini 3.1 Pro, но контекстное окно ограничено 128.000 токенов и вместо миллиона токенов на про татарифе. Это в восемь раз меньше. И главная фишка Gini в виде 1 млн токенов в обычном чате, ради которой многие и

24:59

Speaker A

приходят. На пласт тарифе получить нельзя. Дополнительно GMI выдаёт 200 акредитов на генерацию картинок и видео.

25:07

Speaker A

Это может показаться, что этого достаточно, но когда начинаешь активно работать, они заканчиваются за первую неделю. Третий тариф- Google A Pro за 20 долларов. Это главный рабочий тариф GMI.

25:18

Speaker A

И единственный тариф за 20 долларов, где ты получаешь 1 млн токенов в обычном чате. Например, у Cloud Pro за те же 20 долларов в чате есть только 200.000 токенов, а миллион доступен только через работу по Апе, но это уже другой формат

25:34

Speaker A

работы. А пласт тариф от CH GPT вообще предлагает копейки в виде 32.000 [откашливается] токенов. И по сравнению с GMIN это в 30 раз меньше. То есть этот лимит позволяет загружать кодовые базы до 30.000 строк или документы до 1.00 страниц целиком и

25:52

Speaker A

задавать вопросы по всему содержимому одним запросом. В этом тарифе, как и Open AI от Antropic за 20 долларов, есть три главных инструмента: чат-помощник, функционал работы с базой знаний JМs и автономный агент Jules. И ещё одна уникальная особенность подписки Google A

26:11

Speaker A

Pro. Её можно поширить до шести человек. Не просто сидеть с одного аккаунта, а официально включить подписку для всех знакомых. И если посчитать, то это выходит около 3,5 долларов в месяц за одного человека за полноценный доступ к топовой модели GMini 3.1 Pro. Как и у

26:31

Speaker A

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

26:48

Speaker A

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

27:06

Speaker A

GMIN остаётся вне конкуренции по объёму, даже с учётом реальной просадки производительности. Во-вторых, GMini глубже всех интегрирован в Google экосистему, естественно, потому что это продукт от Google. Если ты плотно работаешь с Google Docs, ведёшь рабочую переписку в Mail, собираешь статистику в

27:25

Speaker A

Google Sheits, то GMini удобно встроиться в твой рабочий процесс и поможет работать с контекстом прямо внутри документов без переключения в отдельный чат. Но если ты полноценно работаешь, например, в Ntion в контексте программирования, то лучше выбрать чат GPT или CLД, у которых есть готовые

27:43

Speaker A

коннекторы. Давай подведём итоги по Gini. Gini имеет смысл выбрать в трёх конкретных случаях. Во-первых, если у тебя регулярно появляется задача на анализ, не на написание больших объёмов кода или документов целиком, то 1 млн токенов в одном чате реально выручает. И

27:59

Speaker A

такой особенности нет ни у одного сервиса за те же 20 долларов. Во-вторых, если ты плотно работаешь с Google стеком, то есть ты проводишь половину рабочего дня в docs, Mail, Sheits, тогда Gini успешно встроится во все рабочие процессы, и тебе не нужно будет

28:14

Speaker A

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

28:30

Speaker A

сценариев тебе не подходит и тебе нужен один основной и инструмент для написания кода, токлод или чат GPT дадут более стабильный результат, особенно на сложных проектах. Perplexity - это не просто чат-помощник, это AI [откашливается] поисковик. И главное отличие от Chat GPT Clot и Gmini в том,

28:48

Speaker A

что сама концепция Perplexity заточена на поиск с цитированием источников. Это не просто поиск с приведением ссылок, который интегрирован как дополнительный функционал в сервис, а фундамент, на основе которого и построен весь продукт.

29:02

Speaker A

Например, модели учат GPT и GMini генерируют текст, исходя из данных, на которых были до этого обучены. А Перплек сначала найдёт 10 актуальных статей и только потом соберёт общий ответ. У Перплексти есть ещё одна золотая особенность. Он не привязывается ни к

29:19

Speaker A

одной конкретной модели. А по сути берёт модели GPT 5,5 у Openi, модели Sonyet Opus у Antropic, модели Gini у Google и переключается между ними внутри одной подписки. Что у Перплекси в тарифах? В бесплатном тарифе доступно около пяти запросов в режиме Проarch, в котором

29:38

Speaker A

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

29:58

Speaker A

хватает. Например, чтобы что-то достоверно проверить. Бесплатный тариф от Perplexity сильно отличается среди пяти бесплатных тарифов других компаний.

30:06

Speaker A

Он полноценно закрывает задачу на поиск информации с источниками, но не переключает на слабую модель, как, например, делает CH GPT. не останавливает поиск при достижении лимита как лод и не ограничивает качественную работу после 30 минут, как, например, GMI. Pro за 20 долларов

30:23

Speaker A

полностью снимает ежедневный лимит на проarch-режим. В бесплатном тарифе было пять запросов и добавляет новый углубленный режим Deep Research с 20 запросами в месяц. Плюс расширенные лимиты про Search до 200 запросов в неделю. По сути, dearch - это такой же

30:40

Speaker A

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

30:56

Speaker A

заточен под академическое исследование с цитированием каждого утверждения, а чат GPT под общую аналитику без обязательной перепроверки информации. И третий тариф Макс за 200 долларов. Подробно рассказывать не буду. Думаю, мало кому из нас он на самом деле пригодится. Но

31:14

Speaker A

если тебе нужен безлимитный инструмент по регулярному мониторингу изменений на конкретных сайтах или безлимитный помощник в браузере, тогда имеет смысл рассмотреть этот тариф подробнее. Что узнаешь только через полгода работы с Perplex? Относительно недавно Пепleксти сделал свой AI браузер Коме полностью

31:34

Speaker A

бесплатным на всех устройствах. Это такой же браузер, как и Хром, но внутри живёт полноценный AI assistent с доступом ко всем твоим вкладкам.

31:43

Speaker A

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

32:00

Speaker A

EA живёт, на уровне операционной системы. Полностью бесплатный EA браузер на всех платформах есть только у Perplexity. У OpenI есть свой Chat GPT ATL, но он работает только на MacOS, а CLD, Gini и Dipsic в целом пока не предвещали подобную разработку.

32:18

Speaker A

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

32:33

Speaker A

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

32:54

Speaker A

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

33:11

Speaker A

что он не напишет качественный код. Для этого больше подойдёт компания Antropic или Open AI. Deepsic - это продукт китайской компании. У него полностью бесплатный веб-интерфейс без подписок и лимитов. Открытый исходный код, и модели V4 Flash и V4 Pro на бенчмарках по

33:28

Speaker A

написанию кода проседают, но сопоставимы с GPT 5.5 и Cloud Sona 4.6. Когда в январе 2025 года Deeps выпустил модель V4, акции Nvidia отвалились на 17%. И DeПS мог стать угрозой а-разработки, потому что обучение топовой модели было дорогим и доступным только крупнейшим

33:50

Speaker A

компаниям. У DeepS есть две основные модели: V4 Flash для повседневных задач и V4 Pro для сложных задач со встроенным режимом глубокого рассуждения. По сути, это как если бы у Chat GPT Instant и Thinking были не двумя отдельными режимами одной модели, а двумя

34:08

Speaker A

отдельными моделями. Как и у большинства нейронок, модель V4 Flash быстрая и закрывает большинство сценариев, а V4 Pro подключается точечно для задач с математикой и логикой или сложным анализом. Поиск с цитированием тоже встроен как дополнительный инструмент, но работает намного хуже, чем, например,

34:27

Speaker A

у Perplexity. Что у Deeps в тарифах? Тарифная сетка, как Free, Pro, Max тарифы у DeepS нет, есть просто Deeps и он полностью бесплатный, без ограничений по запросам. Учат GPT Clot G Mini Perplex за топовые модели нужно платить от 20 долларов в месяц. Но плата у них

34:46

Speaker A

идёт не только за модель, а за всю экосистему вокруг. Проекты, custom GPTs, память, агенты, интеграции и так далее.

34:54

Speaker A

А у Deeps сопоставимая модель для работы в чате, но без всей этой экосистемы. Единственное, что у Deepsc платно - это AP для разработчиков. Чтобы работать по IP с быстрой моделью V4 FLШ, придётся отдать около 14 центов за 1 млн токенов.

35:11

Speaker A

Но это всё равно в 20 раз дешевле, чем, например, модель Sonet от Clot и в 35 раз дешевле GPT 5.5. При сопоставимом соотношении цена качества. результат остаётся наилучшим. Может появиться вопрос: а можно ли тогда полностью заменить и чат GPT на deeps IP? Нет,

35:31

Speaker A

чтобы провести первичный анализ или создать MVP бесплатно, deeps точно подойдёт, но для глубоких рассуждений его точно недостаточно, что узнаешь только через полгода работы с Deepsic. У Dipsic открытый исходный код. Это значит, что модель можно скачать и запустить локально на своём сервере или

35:50

Speaker A

компьютере, и данные не покинут твою инфраструктуру. Из пяти чат-помощников в стандартных тарифах такая опция есть только у Deeps. Остальные четыре работают только в облаке или через интеграцию с подведём итоги по DeepsК.

36:04

Speaker A

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

36:20

Speaker A

то IP от Deeps обойдётся в десятки раз дешевле, чем CLД или чат GPT при сопоставимом качестве. Давай подведём итоги по всем чат-помощникам. Перед тобой пять основных инструментов, и у каждого есть своя зона, в которой он сильнее остальных. Нет одной

36:38

Speaker A

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

36:53

Speaker A

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

37:11

Speaker A

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

37:30

Speaker A

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

37:46

Speaker A

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

38:04

Speaker A

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

38:26

Speaker A

поймёшь, как вообще устроен AI [музыка] и как получить реально качественный результат, даже выбрав менее слабый инструмент. Потому что даже идеально подобранный под задачу инструмент - это только половина дела. Вторая половина - это то, как ты с этим инструментом

38:42

Speaker A

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

38:58

Speaker A

имел в виду. И вывод обычно один: нейронка глупая. Хотя, если подумать, нейронка ровно настолько же глупая, как и то, каким языком ей объясняют, что надо делать. Что происходит, когда ты отправляешь запрос, когда ты пишешь в чат GPT напиши функцию для сортировки,

39:16

Speaker A

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

39:32

Speaker A

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

39:42

Speaker A

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

40:00

Speaker A

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

40:18

Speaker A

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

40:37

Speaker A

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

40:52

Speaker A

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

41:09

Speaker A

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

41:24

Speaker A

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

41:42

Speaker A

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

42:02

Speaker A

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

42:22

Speaker A

результат ответа. Сначала мы попросим обобщённо написать функцию для сортировки и в ответе получим три популярных примера абстрактного кода на популярном языке Python. Это самый статистически частый ответ. Теперь судим задачу и уточним, что нам нужна функция сортировки по дати регистрации. Мы видим

42:40

Speaker A

новую, более точную функцию на Python, которая нам подходит, но я подразумевал, что она будет написана на JavaScript.

42:47

Speaker A

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

43:03

Speaker A

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

43:18

Speaker A

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

43:36

Speaker A

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

43:55

Speaker A

появиться соблазн долго выбирать между Sonet Opus или между режимами instant и thinking в чат GP пти. Но между несколькими моделями внутри одного класса разница на типовых задачах небольшая. На действительно сложных задачах по типу анализа архитектуры или рефакторинга крупных модулей топовая

44:15

Speaker A

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

44:27

Speaker A

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

44:46

Speaker A

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

45:07

Speaker A

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

45:26

Speaker A

разработке, тестирование, аналитики со своими инструментами, промптами и сценариями под каждое направление. Сидят два бэкэндера и пишут сервис при помощи AI. Первый за 30 минут вмёрл свой МР и пошёл пить латы на кокосом, а второй часа три парится с архитектурой

45:49

Speaker A

проекта, которую он не понимает, и говорит, что AI не работает для написания кода. В бэкэнде он не применим и вообще код нужно писать руками. Первым человеком был Альберт Эйнштейн или ты после просмотра этого видео. Ну а вторым был 10X программист. Всем привет. Меня

46:05

Speaker A

зовут Романович Артём. Я гонг-разработчик и ментор по этому языку. Вы смотрите главу AI для бэкэнда.

46:12

Speaker A

Для кого эта глава? Для тех, кто хочет начать или уже использует нейронки в своей работе. Если вы пропустили, что у нас появился GPT, есть различные агенты для кода MCP, то всё это мы кратко рассмотрим в начале, но после этого

46:27

Speaker A

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

46:44

Speaker A

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

46:59

Speaker A

тесты не ради зелёных галочек, а чтобы они тебе действительно помогли. Не обойдём стороной MCP, gitwes новомодные.

47:08

Speaker A

Ну и разберём, как отлавливать Race Conditions, N+1 проблему и в целом делать ревью кода, который написала Неронка, чтобы тебя после этого не уволить. Итак, представим, что ты бэкэндер, который пропустил всю эту истерию с и вообще ничего не знаешь.

47:21

Speaker A

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

47:38

Speaker A

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

47:53

Speaker A

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

48:01

Speaker A

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

48:18

Speaker A

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

48:33

Speaker A

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

48:48

Speaker A

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

49:04

Speaker A

какой-нибудь там пайплаine результат посмотреть и запушить всё в Gitlab. Может, ещё там Summory какое-то красивое сделать. Многие на нейронку перекидывают лишь часть работы. Скорее всего, вы пишите код, а после этого собираете всё, прогоняете Linter, там, Gitlab, Pipeline, условно говоря. Потом делаете

49:21

Speaker A

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

49:38

Speaker A

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

49:52

Speaker A

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

50:09

Speaker A

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

50:26

Speaker A

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

50:43

Speaker A

неограниченными и разумеется это удобно. К слову про экономию было время, когда я использовал несколько проподписок у клауда и менял папки, то есть move.Cloud1, Cloud 1, там то Cloud 2. Я не рекомендую вам так делать, потому что между этими аккаунтами

50:58

Speaker A

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

51:14

Speaker A

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

51:30

Speaker A

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

51:48

Speaker A

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

52:01

Speaker A

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

52:06

Speaker A

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

52:19

Speaker A

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

52:38

Speaker A

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

52:49

Speaker A

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

53:05

Speaker A

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

53:20

Speaker A

команды, которые AI внедряют в свою разработку, ну, ускорились где-то процентов на 30, на 60. И, очевидно, человек, который сделал всё неронкой, там, условно, за час вместо недели, не будет ходить об этом и бегать на конференциях, что он там 10x

53:34

Speaker A

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

53:51

Speaker A

вас уходило 10 часов, теперь уходит 1 час, только время смотрим. И задача вместо 10 часов будет оценена, ну, там в 6, может быть, в 4 часа. Поэтому всё равно есть время внимательно там проанализировать какие-то кривые случаи, собрать требования у бизнеса, ну, и по

54:05

Speaker A

сути дальше ваше время не тратится. Я работал в разных командах, там, где и принят. То есть у вас, буквально, не скрываясь, на каждом проекте есть файли cloud. А есть те проекты, вот на собеседованиях с ребятами мы это смотрим, где говорят: "Ты что,

54:22

Speaker A

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

54:37

Speaker A

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

54:51

Speaker A

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

55:04

Speaker A

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

55:12

Speaker A

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

55:27

Speaker A

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

55:43

Speaker A

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

56:00

Speaker A

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

56:09

Speaker A

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

56:25

Speaker A

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

56:40

Speaker A

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

56:58

Speaker A

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

57:14

Speaker A

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

57:31

Speaker A

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

57:47

Speaker A

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

57:57

Speaker A

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

58:14

Speaker A

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

58:34

Speaker A

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

58:51

Speaker A

переключить модель. Но давайте обратно переключимся в то, что у нас было выбрано, а именно 2,5 кодер 7B. Ну и мы посмотрим, увидим то, что очень долго происходит генерация и совершенно что-то неадекватное будет на выходе. Потому что если, ну вот давайте сейчас посмотрим.

59:10

Speaker A

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

59:24

Speaker A

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

59:38

Speaker A

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

59:55

Speaker A

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

60:11

Speaker A

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

60:21

Speaker A

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

60:35

Speaker A

простенькие вещи создавать таким э локальным вариантом, потому что если у вас 20 Гб есть, вы какой-нибудь Квен установить можете, он достаточно неплохо справляется э в рамках своего ограниченного размера. Это будто бы лучшее, что есть вот для локальных моделей. Хотя, опять же, там разные

60:54

Speaker A

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

61:10

Speaker A

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

61:27

Speaker A

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

61:45

Speaker A

информацией. У нас есть код - это текст, lнter, результат его - это текст, какие-то там стектрейсы, ошибки джесоны м и прочее. SQL, например. Это всё текст. И нейронка с ним очень хорошо работает. Это буквально чуть ли не единственное, с чем она работает хорошо.

62:00

Speaker A

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

62:13

Speaker A

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

62:28

Speaker A

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

62:45

Speaker A

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

63:01

Speaker A

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

63:18

Speaker A

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

63:24

Speaker A

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

63:44

Speaker A

какой-то промпт и объяснить, в какой точке вы находитесь, что находится там снаружи вас через контекст. Я бы сказал, что на 50% работа с нейронкой - это управление контекстом. То есть она должна быть достаточно умной. У неё должен быть, ну, буквально контекст, как

63:58

Speaker A

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

64:13

Speaker A

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

64:28

Speaker A

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

64:48

Speaker A

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

65:03

Speaker A

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

65:22

Speaker A

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

65:37

Speaker A

оказывается бесполезным. Поэтому чётко прописывайте, чего вы не хотите, чтобы AI делал. Обратная ситуация - это когда вы просто говорите: "Напиши мне сервис".

65:46

Speaker A

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

66:03

Speaker A

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

66:16

Speaker A

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

66:30

Speaker A

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

66:40

Speaker A

То есть раньше было такое, что нейронка выдумывает какие-то инструкции, которые вы ей давали или в коде что-то написано определённым образом. Она говорит, что в данном участке есть там какая-то реализация, её не существует. Почему так? Потому что модели, ну, по сути,

66:57

Speaker A

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

67:03

Speaker A

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

67:10

Speaker A

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

67:30

Speaker A

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

67:47

Speaker A

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

67:53

Speaker A

Поэтому абсолютно нормальная практика - это задавать им вопрос: "А откуда ты это взял? Почему ты так решил?" И может оказаться, что где-то в коде неронка это поняла или додумала, это является правдой, либо это было, ну, типа выдумано. Ну, думаю, вы можете отличить

68:09

Speaker A

плохой промт от хорошего. Плохой - это сделай мне там сервис с аутентификацией, хранением задач, пример хорошего. Добавь Handler Post в такой-то пакет IP.

68:19

Speaker A

Аутентификация должна быть сделана через middleware. Бери user ID из контекста, сохраняй через репозиторий, который уже написан. Ну и там такие-то коды возврата, например, используй для определённых операций. Давайте обратимся к коду и просто посмотрим на две разные реализации, которые будут написаны.

68:33

Speaker A

Итак, давайте посмотрим на пример хорошего и плохого промпта. У нас написан некоторый проектик. Это сервис.

68:40

Speaker A

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

69:00

Speaker A

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

69:19

Speaker A

другой сессии другая папка, вот prompt good написано, мы дадим уже детальный prompt, где опишем то, что у нас есть аэ handler tasks, который нужно добавить, некоторый контекст, что происходит.

69:33

Speaker A

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

69:48

Speaker A

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

70:03

Speaker A

соответственно, реализует. Сейчас он всё соберёт и проверит то, что реализовано всё корректно. Давайте посмотрим на вариант с плохим промптом. И вот мы в целом видим уже результат, то, что, э, нас простой промпт, сделай мне сервис, взял и спросил: "Какой стек ты

70:20

Speaker A

предпочитаешь?" Типа Python или фастапи? Да, он спрашивает что-то про БД, про функции и вообще не вдупляет то, что происходит. Давайте скажем, э, нужно как в годе уже, а тут скажем, не знаю, глянь, ну, тоже будем очень кратко всё писать, а здесь

70:43

Speaker A

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

71:01

Speaker A

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

71:17

Speaker A

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

71:31

Speaker A

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

71:43

Speaker A

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

71:55

Speaker A

Например, сказать: "Перед тем, как писать код, опиши, что важно в условии ты подсветила, что проанализировала и нашла в кодовой базе, что нашла существенным и какие архитектурные решения применила". Это полезно для вас, во-первых, потому что модель не успеет наворотить лишнего. А, во-вторых, если

72:12

Speaker A

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

72:28

Speaker A

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

72:36

Speaker A

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

72:51

Speaker A

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

73:07

Speaker A

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

73:13

Speaker A

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

73:31

Speaker A

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

73:47

Speaker A

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

74:05

Speaker A

новый диалог для несвязанной с предыдущей задачей. Для этого даже есть определённые термины. Smartzone - это небольшая область, контекст, когда модель очень умная, и dump zо - это просто то, что она помнит. У какого-нибудь Cloud Opus 48 есть миллионный контекст. То есть

74:22

Speaker A

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

74:40

Speaker A

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

74:58

Speaker A

фокусироваться на том, что нужно для этой задачи. Ну и на каких-то там общекомандных договорённостях, да, что мы используем для этих сервисов и так далее. Поэтому в идеале размеряйте задачу так, чтобы оставаться в Smartz Zone. Я бы сказал, что для задач,

75:12

Speaker A

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

75:27

Speaker A

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

75:44

Speaker A

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

75:58

Speaker A

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

76:17

Speaker A

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

76:32

Speaker A

определённый процент от своей ЗП. И скоро все эти модели, они будут дороже, потому что работают они сейчас себе в убыток, привлекают клиентов, там выходят на IPO, чтобы эти самые клиенты и платили. Скоро будем платить сильно дороже. Для этого примера в первый

76:48

Speaker A

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

76:55

Speaker A

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

77:11

Speaker A

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

77:22

Speaker A

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

77:38

Speaker A

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

77:54

Speaker A

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

78:10

Speaker A

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

78:31

Speaker A

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

78:49

Speaker A

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

79:02

Speaker A

Вот поэтому в идеале очищать контекст. Если вдруг кто не в курсе, как это делать, то мы можем сделать компакт. И мы видим, что происходит буквально компакт нашей переписки. Обращаю внимание, что токены на это тратятся. То есть, если у вас на 99% сессия кончилась

79:18

Speaker A

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

79:30

Speaker A

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

79:46

Speaker A

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

80:04

Speaker A

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

80:17

Speaker A

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

80:35

Speaker A

уже обсудили. Поэтому, когда Неронка вам говорит done completed там и что-то рассказывает, то воспринимаете это не как код готов к пушу, там напрот можно его разливать. Э, рассматривайте так, что код готов на 95, например, процентов. Я рекомендую вам после этого

80:52

Speaker A

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

81:06

Speaker A

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

81:24

Speaker A

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

81:34

Speaker A

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

81:53

Speaker A

кстати, завейкодить, если у вас такого ещё нет, но как минимум можно сказать: "Вот имеющаяся кодовая база, сделай аналогично". Ну и чтобы не делать это каждый раз, можно единовременно создать эту инструкцию и потом её везде использовать. Про Cloud MD совет,

82:06

Speaker A

кстати, уже не будет актуален, потому что сейчас best practice - это не создавать такой файл. Считается, что умные модели, когда Explore агентов запускают, они сами всё проанализируют, и cloud будет вас только отвлекать. То есть неронка сама поймёт, что ей нужно.

82:24

Speaker A

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

82:38

Speaker A

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

82:56

Speaker A

давайте обратим внимание, у нас есть пустая директория, и там мы запустили Cloud. Также в определённой папке у нас есть файл backend, в котором, по сути, есть описание структура папок, тамх handlerр и прочее, прочее. Вдруг кто-то не знал о том, что в cloudкоде вы можете

83:12

Speaker A

через собачку вот так вот обратиться к файлам, которые имеются. И это можно сделать даже из директории выше, например, вот так. И обратиться к файлу backend и сказать там: "Расскажи кратко про формат".

83:26

Speaker A

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

83:43

Speaker A

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

83:58

Speaker A

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

84:15

Speaker A

Кстати, есть готовые наборы скилов, например, Superpowers. можете погуглить, они изначально определённые подходы навешивают на агента, например, spec Driven Development, тdд тест Diven и прочее. По сути, это набор каких-то markрдау файлов. М, по ним генерится спека, и вы дальше уже всё это создаёте.

84:39

Speaker A

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

84:45

Speaker A

Раньше вы прямо могли встретить такое. Я думаю, многие узнают себя. У вас есть тест, который не проходит, и есть корректный код. На него тест требуется написать. Вы говорите нейронке: "Исправь, тест неправильный". И она начинает править функционал, как бы

85:00

Speaker A

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

85:16

Speaker A

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

85:33

Speaker A

Почему так получается? Неронки не очень хорошо работают с так называемыми failor puffs. Ну, то есть неуспешные сценарии.

85:40

Speaker A

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

85:56

Speaker A

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

86:13

Speaker A

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

86:28

Speaker A

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

86:44

Speaker A

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

86:59

Speaker A

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

87:12

Speaker A

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

87:24

Speaker A

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

87:44

Speaker A

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

88:01

Speaker A

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

88:18

Speaker A

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

88:26

Speaker A

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

88:44

Speaker A

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

89:00

Speaker A

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

89:16

Speaker A

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

89:32

Speaker A

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

89:47

Speaker A

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

90:03

Speaker A

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

90:12

Speaker A

Во-первых, n + 1, то есть неронка вполне может написать какой-нибудь запрос в цикле, и это повлияет на производительность. Дальше индексы. Ещё раз, наиболее вероятное изменение, наиболее вероятный код Нейронка будет стараться использовать, если индексы есть. Она же не может там нагрузку

90:29

Speaker A

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

90:43

Speaker A

какие-нибудь блокировки, то есть локи на таблицах, в целом такое встречается. Ну и да, ещё у нас есть forign tables. В целом, если это не одна таблизица, а несколько её там инстанцесов сущностей, то с таким неронка не очень справляются.

90:57

Speaker A

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

91:13

Speaker A

какой-нибудь подключить к вашему агенту и он сам на тестовом стенде, там defat stage будет брать и гонять данные.

91:21

Speaker A

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

91:34

Speaker A

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

91:41

Speaker A

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

91:59

Speaker A

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

92:17

Speaker A

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

92:34

Speaker A

вас подсветить, объяснить. Можете просить объяснить ответственность какого-то модуля, проследить путь запроса от хендлера до базы данных, ну и так далее. Ещё прикольно рисовать диаграммы Mirmate неплохой формат для этого UML. Мне лично не нравится, и вы визуально поймёте, как что работает.

92:51

Speaker A

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

93:06

Speaker A

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

93:24

Speaker A

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

93:38

Speaker A

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

93:53

Speaker A

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

94:09

Speaker A

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

94:24

Speaker A

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

94:38

Speaker A

сути, просто обвязка на наш йлими, вот, и midleва, который будет его использовать. [музыка] Ну, и посмотрим, например, промпта. Вот такой промт можно придумать. То есть опять же описание подробное, что у нас есть. У нас маленький там HTTP сервер.

94:54

Speaker A

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

95:02

Speaker A

Очевидно, что, ну, если у вас там суммарно в 100 строчек всё помещается, нет смысла это пояснять. Модель лучше вас понимает, что тут происходит. Ну и мы говорим: "Не пиши код сразу. Вначале объясни подходы, которые есть token баck - это Windows и fixed Window. По сути,

95:18

Speaker A

вы даже если не знаете примеры, как реализовать йми, можете сказать: "Расскажи мне, какие варианты есть". То есть не сразу вот делай, делай эit commit git push. Берёте вначале, спрашиваете. Вот после этого выбери один вариант, который так-то так-то всё

95:35

Speaker A

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

95:52

Speaker A

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

96:06

Speaker A

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

96:20

Speaker A

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

96:36

Speaker A

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

96:46

Speaker A

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

97:01

Speaker A

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

97:17

Speaker A

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

97:34

Speaker A

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

97:50

Speaker A

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

98:06

Speaker A

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

98:20

Speaker A

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

98:35

Speaker A

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

98:52

Speaker A

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

99:10

Speaker A

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

99:29

Speaker A

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

99:37

Speaker A

В данной части вашего приложения уже ошибка была. И вот какие-то догадки, некоторый опыт человеческий, который между сессиями никак не поделить. Ну, профайл bën.md. Мы говорили, что-то такое придумать, конечно, можно. Если вы изначально знаете область, где примерно находится бак, то вы сразу об этом

99:56

Speaker A

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

100:13

Speaker A

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

100:26

Speaker A

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

100:44

Speaker A

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

101:02

Speaker A

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

101:19

Speaker A

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

101:35

Speaker A

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

101:53

Speaker A

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

102:10

Speaker A

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

102:30

Speaker A

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

102:39

Speaker A

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

102:56

Speaker A

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

103:10

Speaker A

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

103:27

Speaker A

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

103:44

Speaker A

просто линейно пишет код. Можете явно попросить агента: "Возьми пять раз, прогони код, посмотри, что получится, если у вас там какой-то изолированный модуль". Ну, а для больших проектов всегда с флагом. Ну, опять же, например, Гошки Goest Race прогоняйте код. Ну и

104:01

Speaker A

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

104:18

Speaker A

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

104:33

Speaker A

Лечится - это контекстом. Мой любимый вариант - это контекст 7. По сути, это тоже там MCP или как-то по-другому реализовано. Сборище документации, которая неронко может посмотреть и найти то, что ей нужно. Современные модели неплохо индексируют интернет, но у этих

104:50

Speaker A

решений, про которые я говорю, ну, есть некоторая специфика, и они справляются лучше. Они уже хранят, по сути, документацию, которая вам нужна, а не просто статейки, которые тоже могут попадать в спле. Вы просто переходите на сайт context 7, копируете инструкцию для

105:04

Speaker A

вашего агента, ну, и применяете её в локалке. Проверяете, что всё работает. Теперь вам доступна документация.

105:11

Speaker A

Например, я могу попросить нейронку заполнить позгрю какую-то таблицу определёнными данными, либо могу попросить что-то найти. Итак, давайте посмотрим на подключение Context 7 - это tool, используя который неронка может зайти в интернет, смотреть документацию и прочее. У нас есть команда MCP, и мы

105:27

Speaker A

можем посмотреть, что у нас подключено. Видим, что Playriра, например, есть здесь, но нашего контекственна нет. Если мы ведём команду, это подключение любого агента можно сделать, там кодекс какой-то и прочее, то видим то, что у нас а в файл Home Art Cloud был добавлен

105:46

Speaker A

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

106:06

Speaker A

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

106:28

Speaker A

последнюю версию Bubб Tia Goangтуй, например. Да, обычно, когда вы подключаете MCP и он не работает, у вас будет гореть то, что он не работает не connected, как в случае там с Игмейлом каким-то или, не знаю, базой данных. Тут

106:44

Speaker A

он почему-то говорит, что он работал. Когда я его попросил, использовать context 7, что-то сделать. Он сказал, что он недоступен и ключ не настроен.

106:55

Speaker A

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

107:14

Speaker A

что-то новое сможет нам сказать. Нет, недоступен. Ну сейчас ещё раз попробую. Мы можем, кстати, через Fкрол. Ээ, это то, что я настраивал в своё время. По сути, абсолютно такая же штука. Не настроил я контекст 7 и Fire Crawл у

107:29

Speaker A

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

107:48

Speaker A

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

108:04

Speaker A

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

108:18

Speaker A

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

108:30

Speaker A

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

108:49

Speaker A

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

109:06

Speaker A

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

109:22

Speaker A

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

109:42

Speaker A

как это проверить? Вот примерно так. Вы можете сделать команду MCP есть. Видно, что у меня там какой-то Gmail, Google календарь подключен и прочее. И давайте скажем а глянь количество задач с типом два и сколько это процентов от задач. То есть вот у

110:05

Speaker A

нас есть тип задач один, иногда есть два. Давайте скажем, а можешь ли ты добавить задачу? Ну и мы видим то, что только в RE режиме открыто, поэтому отредачить мы ничего не сможем. В случае, если у нас был бы доступ на

110:19

Speaker A

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

110:36

Speaker A

посмотреть. То есть размер э всех там разделов, какие-то расширения, которые установлено, вот там UI ID, например, э PGron и так далее. Ну, как какой-то RAM может посмотреть что-то такое. То есть вот запросами достаточно удобно получается это посмотреть. Вы вот эти PG

110:54

Speaker A

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

111:07

Speaker A

И в контексте этом давайте ещё обсудим, как сильно можно отпускать руль, потому что можно чуть ли не каждое действие валидировать, а можно accept all changes режим включить, и всё будет происходить автоматически. Тут есть пара нюансов.

111:23

Speaker A

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

111:37

Speaker A

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

111:58

Speaker A

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

112:14

Speaker A

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

112:24

Speaker A

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

112:39

Speaker A

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

112:49

Speaker A

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

113:08

Speaker A

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

113:26

Speaker A

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

113:42

Speaker A

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

114:01

Speaker A

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

114:18

Speaker A

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

114:37

Speaker A

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

114:52

Speaker A

Итак, давайте посмотрим на Git Worktrace. Мы видим, что у нас каждый из агентов находится в мастере. Ну, есть у нас некоторый код в этой директории. При этом workст даёт нам только мастер. Что мы здесь будем с вами делать? Мы хотим

115:08

Speaker A

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

115:21

Speaker A

распараллелить. Каким же образом это сделать? Давайте отправим промт. То, что мы работаем в определённом проекте. Тебе нужно создать Work 3. Вот эту же команду у нас запускает агент. Он добавляет Work 3 и в нём же будет делать там какую-то

115:39

Speaker A

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

115:50

Speaker A

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

116:03

Speaker A

то вот у нас есть ветки, и мы можем Git checkout сделать на, например, эту ветку. Вот. Ну для этого, да, нам придётся перейти вот таким образом в случае 43.

116:20

Speaker A

Вот. И мы можем тут сделать git ad, соответственно, gitстатус, там что-то посмотреть закоммитить. Вот git merge master нам ничего не даст. Но если мы перейдём обратно вот сюда, то мы видим, да, что мы смогли сделать merch.

116:40

Speaker A

Абсолютно то же самое делаем с другой веткой. Git pш. Ну и можем куда-то отправить.

116:49

Speaker A

Давайте перейдём к важной теме. Это секреты ficк. Где они у нас хранятся? Я рекомендую явно запретить нейронки не на уровне промта типа не смотри, а на уровне правил обращаться к этому файлу.

117:04

Speaker A

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

117:23

Speaker A

пароли попадали в гиIT. Ну и это не очень хорошо. Поэтому рекомендую все-таки отладочные файлы, опять же, секреты хранить в каких-то гиitгнорах, например. К слову про GitignгNor, как рекомендую подойти к нему на проектах своих. Вы можете глобально в папке

117:40

Speaker A

programing/work запретить ну сделать, короче, невидимым cloud MD файл. И когда вы будете Git делать или у себя в нажимать на push ну и коit, то не будет этот файл подключаться. Вам не нужно будет каждый раз его убирать. Это

117:55

Speaker A

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

118:11

Speaker A

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

118:21

Speaker A

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

118:37

Speaker A

давайте помимо баз данных посмотрим на Postman, что необходимо может быть. У вас есть какой-нибудь й URL, который шарится междупоинтами.

118:47

Speaker A

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

119:10

Speaker A

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

119:26

Speaker A

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

119:44

Speaker A

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

119:59

Speaker A

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

120:16

Speaker A

нужно вообще не всегда. Например, есть GitHub, есть Kubernetis. Что такое GitHub? GH. У нас есть команда, и ей вы можете всё сделать. Изза вас уже написан этот интерфейс Kuber. У него, по-моему, тоже есть какой-то MCP, но зачем, если

120:31

Speaker A

команда CBECL неплохо пользуется неронкой, она опять же знает там, как и в пот войти, и какой-нибудь state wset глянуть. Поэтому не для всего MCP нужно подключать. Иногда у нас есть команда.

120:43

Speaker A

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

121:01

Speaker A

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

121:19

Speaker A

Кстати, про Playri ещё если не знаете, загуглите. Это, ну, как clad in Chrome. Э, возможность поднять браузер и в нём сделать определённые действия. Опять же для тестов, мне кажется, это очень хорошо используется. Я думаю, что ZMCP будущее, потому что есть нейронка,

121:36

Speaker A

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

121:49

Speaker A

условия вызова. Я не думаю, что большинству нужно в это углубляться. Возьмите Контекст 7, подключите Джиру, обрадуйтесь, что вы можете не копировать описание текстом, а просто вот там ссылка, вот confнс, вот там оцени задачи, и это будет гораздо проще,

122:02

Speaker A

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

122:13

Speaker A

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

122:30

Speaker A

статистику по данным Дора, что за исполнитель, как бы не в курсе. Команды с активным внедрением и мёрт почти на 100% больше плуреквестов. Ну и время ревью выросло там чуть меньше, чем на 100%. пишут, что нейронный код даёт примерно в 1,7 раз больше проблем, а

122:48

Speaker A

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

123:02

Speaker A

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

123:19

Speaker A

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

123:39

Speaker A

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

123:51

Speaker A

подходы, которые мы обсудили, вот если вы их применять будете, кажется, будет проще и долгоиграющий код у вас получится, а не просто нейрослоп, который, не знаю, грохнется на проде там когда-нибудь. [музыка] Может вам будет интересно, как работает Antropic. Они не

124:05

Speaker A

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

124:24

Speaker A

Ребята взламывали криптокошельки, подбирали более вероятные пароли. Ну и возвращаясь к линтерам, можно посмотреть на стиль кода. Линтер его как-то явно не поймёт. Безопасность баги может найти там соответствие тикету. То есть это тоже машинная рутинная по сути работа.

124:40

Speaker A

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

124:53

Speaker A

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

125:07

Speaker A

такая GR задача, такая-то документация, мы с аналитиком обсудили такие-то вещи. Возьми и проведи ревью функционал".

125:15

Speaker A

Соответственно, как лично я делаю кодрев свежей сессии, берём и говорим: "Вот у нас GitLab, их может быть несколько.

125:23

Speaker A

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

125:41

Speaker A

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

125:59

Speaker A

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

126:07

Speaker A

Пример неплохого промпта, с которым можно проводить кодрев. Вот мы находимся в папке internal Orders. У нас есть какая-то логика. И как же можно кодрев запросить в таком варианте? Несколько покажу их. Первый - это ты независимый кодревюр. Ну, опять же, современные

126:26

Speaker A

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

126:32

Speaker A

Не оправдывай решение, ищи проблему. Кажется, это важная штука. Что дальше в тикет мы можем привести? [откашливается] Я всегда добавляю задачу через Gra MCP.

126:43

Speaker A

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

126:49

Speaker A

Можно сказать: "Сделай Gitdv master". Почему? Потому что в мастере у вас ну как бы уже есть какой-то код. Вы отпачковываетесь ветки фичер обычно всё делаете. И git divm master вот только ту разницу, которая у вас есть, вы можете м

127:04

Speaker A

глянуть. То есть как иначе модель будет сделать? Она по комтам должна идти что-то смотреть. Гораздо проще глянуть div. Поэтому мы мастер обновляем. Ну и у нас вот на этой разнице ветки Фишера с мастером без открытия мра вы можете не

127:18

Speaker A

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

127:30

Speaker A

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

127:50

Speaker A

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

128:06

Speaker A

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

128:22

Speaker A

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

128:39

Speaker A

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

128:56

Speaker A

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

129:15

Speaker A

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

129:31

Speaker A

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

129:51

Speaker A

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

130:06

Speaker A

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

130:25

Speaker A

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

130:45

Speaker A

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

131:00

Speaker A

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

131:09

Speaker A

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

131:22

Speaker A

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

131:39

Speaker A

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

131:54

Speaker A

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

132:04

Speaker A

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

132:21

Speaker A

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

132:38

Speaker A

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

132:56

Speaker A

сейчас меняется. Чтобы остаться на плаву, у меня есть Telegram-канал, MCP, промты для обучения, разбор подходов.

133:05

Speaker A

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

133:23

Speaker A

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

133:40

Speaker A

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

133:56

Speaker A

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

134:11

Speaker A

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

134:26

Speaker A

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

134:44

Speaker A

это функция. И на данный момент тут нету никакой логики. Applyдиуountт буквально должен применять каким-то вариантом нашу скидку. И что хочется сделать? Вначале мы пишем тесты. Давайте на это посмотрим. Вот у нас есть New Order. Это формат, когда мы вначале создаём

135:06

Speaker A

какую-то функцию, которая будет определённые данные возвращать, и, как видим, её потом везде используем. И мы можем не начать писать наш apply discут, а потом покрывать тестами, а изначально писать тесты, которые определят, что Applyдиу должен для нас делать.

135:22

Speaker A

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

135:40

Speaker A

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

135:49

Speaker A

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

136:09

Speaker A

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

136:30

Speaker A

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

136:48

Speaker A

по сути, есть заглушка некоторая. Первым делом мы напишем тест на главное правило. Если два купона приходят, то применяется один самый выгодный. Мы запускаем вначале наш код, видим, что тест не проходит. Это хорошо, значит, он живой. И проверяет поведение, которого

137:03

Speaker A

нет. Дальше мы пишем тесты не на Happy Puff, а на Failor Puffs. Например, запрос на применение скидки прилетел дважды за 500 мсекунд. Это про идемпотентность. Вот скидка не должна в таком случае примениться во второй раз.

137:18

Speaker A

Дальше webхуhook пришёл повторно, когда заказ уже создан. Тест тоже должен быть красным. И вот только теперь мы доводим код до проходящего варианта. Мы реализуем функцию, смотрим, ну, и всё, у нас загорается зелёным. Это тест, который реально что-то значит. Я видел,

137:35

Speaker A

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

137:44

Speaker A

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

138:01

Speaker A

примеры со своей стороны я привёл. Это может быть там истёкчая сессия. Эта домашка закроет у вас такой рефлекс, восприятие, что Hэпff - это самый важный путь. Как раз-таки else, то есть есть if, а есть else. Тот вариант, где что-то

138:14

Speaker A

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

138:34

Speaker A

доступ только на чтение. Вы, конечно, неронки можете спросить: "Слушай, а ты же действительно не можешь ничего редактировать?" Она скажет: "Да, да, а потом вам прот уронит". Поэтому всё должно быть не на уровне системных промтов, а на уровне вот разрешений,

138:47

Speaker A

каких-то там политик. Ну и задаём агенту вопросы: "Покажи реальную схему через information. Схема, он не угадывает по миграциям. У вас, если особенно миграции очень много, ну там, не знаю, сотни, то ему будет очень тяжело понять, какое конечное состояние. И MCP здесь поможет

139:04

Speaker A

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

139:21

Speaker A

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

139:41

Speaker A

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

139:57

Speaker A

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

140:13

Speaker A

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

140:22

Speaker A

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

140:38

Speaker A

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

140:57

Speaker A

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

141:14

Speaker A

информации, чтение документации или постоянное переключение между вкладками такими как Steack Overflow, Google и своим редактором кода, то теперь значительная часть этих задач может выполняться намного быстрее. Это не значит, что я начал делать работу за разработчика. Это не совсем так. не

141:32

Speaker A

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

141:49

Speaker A

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

142:03

Speaker A

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

142:23

Speaker A

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

142:30

Speaker A

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

142:51

Speaker A

Запомни один момент. AI не должен отменять и не отменяет необходимость думать над тем, что ты делаешь. Более того, чем мощнее становятся инструменты, тем важнее становится инженерное мышление самого разработчика.

143:10

Speaker A

Теперь давай поговорим о не менее интересном. Где именно AI сегодня используется в фронт-тенд-разработке и какие задачи он помогает тебе решать?

143:18

Speaker A

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

143:36

Speaker A

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

143:52

Speaker A

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

144:03

Speaker A

То же самое касается и Typeesскрипtтипов AP клиентов, MOК данных, тестов, которые, кстати, нейронка пишет вообще прекрасно, конфигов и большого количества повторяющегося кода. Тут важно правильно понимать роль AI. Его основная задача - не заменить разработчика, а убрать рутину и

144:20

Speaker A

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

144:39

Speaker A

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

144:58

Speaker A

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

145:14

Speaker A

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

145:31

Speaker A

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

145:42

Speaker A

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

145:57

Speaker A

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

146:19

Speaker A

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

146:37

Speaker A

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

146:54

Speaker A

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

147:00

Speaker A

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

147:09

Speaker A

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

147:27

Speaker A

частью повзятней разработки. Причём не только у Jниor разработчиков, как многие думают, а вообще на всех уровнях, даже C++леevel.

147:41

Speaker A

AI действительно умеет сильно ускорять разработку, ну, только при правильном использовании. Правда, здесь важно не попасть в ловушку. Многие разработчики, особенно начинающие, начинают воспринимать Иакто что-то, что знает правильный ответ, и доверяют его решениям на 100%. Это само по себе и

147:59

Speaker A

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

148:17

Speaker A

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

148:34

Speaker A

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

148:50

Speaker A

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

149:09

Speaker A

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

149:25

Speaker A

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

149:36

Speaker A

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

149:46

Speaker A

Если просто копировать код, можно очень быстро начать тащить ошибки прямо в свой проект или продукт. Есть ещё один важный момент. Заключается он в том, что AI почти никогда не понимает контекст проекта полностью. У тебя могут быть свои архитектурные ограничения, свой

150:03

Speaker A

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

150:19

Speaker A

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

150:40

Speaker A

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

151:00

Speaker A

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

151:09

Speaker A

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

151:31

Speaker A

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

151:44

Speaker A

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

151:55

Speaker A

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

152:13

Speaker A

свою задачу. Мой первый вопрос может выглядеть примерно так. Мне нужно реализовать страницу пользователей на React и TypeSescript. Для самих таблиц используем библиотеку React Table.

152:23

Speaker A

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

152:41

Speaker A

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

152:50

Speaker A

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

153:05

Speaker A

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

153:24

Speaker A

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

153:31

Speaker A

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

153:49

Speaker A

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

154:08

Speaker A

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

154:27

Speaker A

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

154:45

Speaker A

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

155:00

Speaker A

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

155:19

Speaker A

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

155:37

Speaker A

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

155:54

Speaker A

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

156:10

Speaker A

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

156:27

Speaker A

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

156:44

Speaker A

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

157:02

Speaker A

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

157:20

Speaker A

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

157:45

Speaker A

устроена работа с АПИ внутри проекта или даже дать ссылку на дизайн Фигма и попросить сверстать какой-либо элемент.

157:53

Speaker A

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

158:12

Speaker A

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

158:19

Speaker A

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

158:37

Speaker A

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

158:59

Speaker A

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

159:14

Speaker A

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

159:30

Speaker A

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

159:49

Speaker A

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

160:06

Speaker A

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

160:26

Speaker A

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

160:43

Speaker A

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

161:02

Speaker A

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

161:21

Speaker A

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

161:38

Speaker A

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

161:53

Speaker A

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

162:05

Speaker A

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

162:24

Speaker A

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

162:44

Speaker A

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

163:05

Speaker A

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

163:23

Speaker A

работать с производительностью и способен проверить результат AI, а также умеет формулировать задачи и работать с контекстом. По сути, рынок постепенно двигается в сторону того, что AI становится инструментом для работы разработчика, примерно как когда-то IDE, Typeesриpt или деftлзы. И здесь, как мне

163:43

Speaker A

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

164:00

Speaker A

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

164:19

Speaker A

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

164:37

Speaker A

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

164:56

Speaker A

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

165:15

Speaker A

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

165:32

Speaker A

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

165:52

Speaker A

с чем ты согласен, с чем ты не согласен. Какие рекомендации оказались для тебя полезными, какие нет или какие из них оказались вовсе ошибочными. Главная цель задания - научиться использовать AI не как генератор кода, а как инструмент анализа и принятия решений. А если

166:09

Speaker A

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

166:26

Speaker A

Привет. Меня зовут Антон, и я ментор по Androidке. За свою карьеру я успел поработать с нативной разработкой, с КМП и с BDU. Сейчас я активно выстраиваю процесс работы с EИ для менторства и у себя на работе. Мобильная разработка -

166:39

Speaker A

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

166:55

Speaker A

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

167:07

Speaker A

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

167:17

Speaker A

Именно поэтому стали так популярны Driving UI решения, но они от разработчика требуют огромного понимания в том, как работает бэкэнд, и мы становимся с вами T-sшеape специалистами. Именно поэтому AI может помочь тебе вкатиться в это быстрее. И сегодня расскажу тебе три уровня работы

167:33

Speaker A

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

167:50

Speaker A

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

168:05

Speaker A

Здесь ты уже можешь потерять контекст своего кода и не так вдаваться в подробности того, что пишет Неронка.

168:11

Speaker A

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

168:26

Speaker A

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

168:41

Speaker A

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

168:56

Speaker A

весь flлоow f в мобилке и затем посмотрим на то, как мы можем автоматизировать некоторые части из этого флоу с помощью AI. Первое - это знакомство с фичой. Здесь продакт или дизайнер презентует нам то, что мы должны будем сделать. У нас уже есть

169:09

Speaker A

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

169:19

Speaker A

требований для фичи. Здесь, в зависимости от компании, например, в Авито или в Яндексе, этим может заниматься разработчик. В других компаниях обычно для этого выступает аналитик. Разработчик или аналитик должны продумать все шаги, как фича будет общаться с пользователем, какой

169:32

Speaker A

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

169:47

Speaker A

мы переходим к декомпозиции задачи. Здесь уже ответственность на разработчики. После декомпозиции мы переходим к оценке. И здесь опять же тут либо экспертная оценка только от разработчика, либо это Plкеer с использованием команды. Ну а дальше мы переходим к разработке. Здесь всё лежит

170:01

Speaker A

на пчах разработчика. Это вёрстка экрана, сетевой слой, логика, навигация, интеграция фичи, ну и какое-то тестирование в коде, unнисты и UI-тесты.

170:11

Speaker A

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

170:28

Speaker A

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

170:40

Speaker A

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

170:55

Speaker A

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

171:11

Speaker A

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

171:25

Speaker A

простое, где здесь можно применить AI - это транскрибация и повторная фиксация всех требований и итога обсуждений.

171:32

Speaker A

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

171:46

Speaker A

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

172:01

Speaker A

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

172:13

Speaker A

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

172:25

Speaker A

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

172:41

Speaker A

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

172:55

Speaker A

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

173:05

Speaker A

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

173:19

Speaker A

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

173:25

Speaker A

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

173:38

Speaker A

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

173:56

Speaker A

использование контекста очень большое. Каждый блок или рассуждение лучше проходить в новом чате. чаat GPT или нейронка, которая разрешена в вашей компании. Здесь важно следить за качеством ответов. Если оно упало, то лучше смело переходить в новый чат.

174:08

Speaker A

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

174:22

Speaker A

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

174:40

Speaker A

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

174:57

Speaker A

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

175:09

Speaker A

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

175:21

Speaker A

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

175:37

Speaker A

будет написана логика, какой у вас кодстайл. правил для линтёра, детекта или для сия и так далее. Я рекомендую подумать над следующими файликами для ENCM MD. Как использовать дизайн-систему, как правильно писать документацию, какая у вас архитектура внутри модуля, какая у вас архитектура

175:55

Speaker A

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

176:09

Speaker A

руками клода или кодекса. Также GitHub или GitLub MCP. Ну и я рекомендую использовать плагин Superpow для того, чтобы он за вас писал реализацию по своим тддшным историям. С ним, мне кажется, что на среднем или большом проекте сильно легче писать код. Ну и

176:26

Speaker A

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

176:39

Speaker A

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

176:51

Speaker A

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

177:04

Speaker A

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

177:18

Speaker A

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

177:30

Speaker A

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

177:37

Speaker A

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

177:52

Speaker A

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

178:06

Speaker A

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

178:22

Speaker A

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

178:36

Speaker A

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

178:49

Speaker A

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

179:01

Speaker A

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

179:16

Speaker A

будет заниматься оркестратор. Опять же здесь я очень сильно рекомендую использовать Super Powers, потому что этот плагин позволяет нам сильно лучше поработать с агентами, чем если бы мы его не использовали. Как же это работает? Осной контекст задачки ложится на оркестратор, который, понимая, что

179:31

Speaker A

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

179:47

Speaker A

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

180:02

Speaker A

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

180:18

Speaker A

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

180:32

Speaker A

нас есть просмотрщик кода, у нас есть аналитик, у нас есть архитектор, разработчик, тестировщик и верификатор.

180:38

Speaker A

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

180:54

Speaker A

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

181:12

Speaker A

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

181:26

Speaker A

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

181:39

Speaker A

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

181:53

Speaker A

принципе, нужно посмотреть и куда обратить свой взор. Далее он занимается декомпозицией задачки и придумывает, как мы должны сделать задачу. Результатом работы такого особо агента, как архитектор, является mirмейate диаграмма, описание классов, описание взаимодействия классов и декомпозиция фичи. А также в декомпозиции фичи

182:10

Speaker A

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

182:28

Speaker A

пишут это с использованиемDD Test Drive Development. После работ разработчика обычно мы переходим к этапу COдVW, а также к тестированию. Код смотрит код, смотрит на то, как код реализован соответствует с документации или нет, а также может запускать разные проверки по

182:42

Speaker A

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

182:56

Speaker A

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

183:11

Speaker A

может сверять использованные классы и их архитектуру с тем, что у нас получилось от архитектора. Он должен понять, насколько процентов по полноте, насколько хорошо по качеству наша задача выполнена. Если что-то идёт не так, то он может вернуться с ответом к

183:25

Speaker A

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

183:39

Speaker A

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

183:55

Speaker A

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

184:07

Speaker A

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

184:18

Speaker A

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

184:35

Speaker A

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

184:53

Speaker A

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

185:05

Speaker A

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

185:19

Speaker A

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

185:32

Speaker A

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

185:49

Speaker A

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

186:03

Speaker A

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

186:09

Speaker A

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

186:22

Speaker A

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

186:36

Speaker A

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

186:50

Speaker A

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

187:06

Speaker A

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

187:21

Speaker A

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

187:37

Speaker A

полностью с помощью AI. Здесь нужно обратить внимание на то, как вы будете делить, а контекст между чатами, как вы будете композировать фичу, а также какие-то МCшки, документики, скилы, которые вы будете использовать для вашего продукта. На данном этапе вы

187:51

Speaker A

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

188:07

Speaker A

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

188:18

Speaker A

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

188:31

Speaker A

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

188:49

Speaker A

инфу про AI в тестировании. Расскажу, как я сам применяю на своих работах AI. То есть будет прикладная информация почти без воды. Покажу, что работает, а что не работает. Теперь о себе в двух словах. Я Seniors Dead Python. Опыт в

189:03

Speaker A

Альфа-Банке, Сбербанке, Госуслугах и других крупных энтерпрайзах, а также работал на валютных удалёнках. Некоторые знают меня как кокосовый QA. Я ментор и вкатил больше сотни учеников на работу в IT. Есть коммерческий опыт в применении AI и в обучении учеников. Зачем вообще

189:19

Speaker A

AI в QA? На моём примере расскажу, почему AI - это важно, а также покажу на примеры работы. Год назад мне лид автоматизации принёс задачу по рефакторингу и тех долгу. Нужно было переписать стиль наших Алюрстепов. У нас они были оформлены по-старому через

189:34

Speaker A

декоратор Аure Step над отдельными функциями, а надо было перевести всё налайн-степы, используя контекстный менеджер wi alureст прямо в теле теста.

189:44

Speaker A

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

189:56

Speaker A

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

190:04

Speaker A

Сейчас бы я решил эту задачу, пользуясь курсором, и я бы написал чёткий промт. Вот паттерн, который у меня есть. В какой паттерн надо переписать? Вот что сделать со старыми функциями. Агент пошёл бы итерациями, проходил бы по тестам. Я контролировал процесс. Минут

190:18

Speaker A

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

190:32

Speaker A

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

190:48

Speaker A

делалась 1 месяц, решилась за 2 часа. Вдумайтесь, это же X1 сокращение временных затрат. Сколько ещё мест вы можете оптимизировать? Сейчас покажу вам аналогичную задачку вживую, но не на 1.00 тестах, а на 32 тестах из учебного проекта, чтобы вы не смотрели запись

191:06

Speaker A

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

191:15

Speaker A

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

191:30

Speaker A

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

191:52

Speaker A

Нажимаем Enter. И агент сейчас будет смотреть на текущее состояние наших тестов и сформирует нам какой-нибудь план. Вот курсор у нас спрашивает вопросы: на каком языке нам делать разметку. Выбираем английский. У нас так принято на проекте. Следующий вопрос. Мы

192:07

Speaker A

отвечаем, разметим все 32 теста. Сразу формируется план. Ожидаем. Посмотрим на план. Сейчас мы не будем детально погружаться в этот план. Мы просто выберем то, что нам нужно.

192:30

Speaker A

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

192:53

Speaker A

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

193:07

Speaker A

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

193:24

Speaker A

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

193:36

Speaker A

Он нам описывает, что он успел поправить. Мы можем нажать, например, на конфтест и провалиться внутрь. Можем сохранить изменения либо откатить.

193:46

Speaker A

Сохраняем изменения некоторые. Можно сохранить сразу весь файл. Итак, подводим итоги. Вы сами видите, как теперь просто писать автотесты. Раньше такого не было. Пару лет назад мне приходилось писать самому всё это.

194:01

Speaker A

Теперь мне просто нужно валидировать предложение от иагента. Сейчас стало намного проще и удобнее. Есть ещё одна штука, которую я хотел проговорить прямо сейчас. В самом начале с приходом AI граница между медлом и синьором начинает сужаться. У них одинаковые инструменты.

194:17

Speaker A

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

194:32

Speaker A

преимущество ещё работает. Давай разберёмся с инструментами, потому что я знаю эту боль. Открываешь YouTube, а там эти названия чат GPT, Cloud, Gini, Курсор, Коilotт, какие-то агенты, MCP. И ты сидишь и думаешь: "А мне-то что ставить? С чего вообще начать? От меня

194:53

Speaker A

что требуется? Сейчас разложу по полочкам. Я сам перепробовал кучу всего и отобрал то, что реально работает, чтобы ты не тратил время и деньги на лишнее. И сразу главная мысль: инструментов много, но по сути они делятся на три класса. Не по названиям,

195:07

Speaker A

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

195:24

Speaker A

Моё мнение, почему Cloud, а не чат GPT? Вся линейка Cloud была задумана для разработчиков и инженеров. Он гораздо лучше меня понимает, не пишет мне всякую хрень со смайликами. Вот вам типичный чат GPT. Вот как отвечает Клод. Вообще это вкусовщина, как я только не пытался

195:40

Speaker A

убедить чат GPT, но он меня не понимает. Также чат GPT очень часто галлюционирует. Курсор - это мой агент.

195:47

Speaker A

Мы недавно его применяли, когда нужно было отрифачить 32 автотеста. Я вам показывал недавно. Беру для ежедневной работы с автотестами. Рефакторинг кода, когда надо, чтобы я видел весь проект, очень сильно упрощает работу с кодом.

196:00

Speaker A

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

196:08

Speaker A

Например, если нужно нам поднять фреймворк автотестов с нуля, на новом проекте, нам Cloudкод очень сильно пригодится. Он помогает разворачивать структуру по твоему описанию. Чуть позже расскажу, чем отличается курсор отууд-кода. И всё, три инструмента.

196:22

Speaker A

Этого хватает для того, чтобы закрыть 90% всех задач. Я не гонюсь за тем, чтобы попробовать каждую новую модную штуку. Лучше глубоко знать три инструмента, чем по верхам 10. Также VI очень часто и быстро меняются тренды. В какой-то временной период будет по

196:38

Speaker A

качеству тащить чат GPT и кодекс. Потом ему на смену придёт ещё что-нибудь. Например, Cloud Cod. Есть небольшой нюанс по стеку клода и продукты Антропика. У меня они обходятся дороже всего. Чат GPT мне достаточно версии за 22 доллара, а вот клод у меня жжжёт

196:55

Speaker A

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

197:10

Speaker A

посоветуй мне аниме для QA или автотестеров. Мы можем выбрать языковую модель. Вон снизу Sunet написано. Вот AI нам рекомендует посмотреть аниме. Мы смотрим на это всё и закрываем. Скорее всего, все начинают использовать AI через такие интерфейсы. Я не буду делать

197:27

Speaker A

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

197:39

Speaker A

Это то, с чем знаком каждый обычный чат. Ты пишешь вопрос, он отвечает. Сюда относится cloud, чаat, gptini. Что важно понять, чат-помощник не видит твой проект. Он не знает, что у тебя в коде, не может зайти в твою базу, не запускает

197:54

Speaker A

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

198:05

Speaker A

Я вас Христом Богом прошу начать использовать и это очень эффективно. Начинайте с простых задач, которые вы и так умеете решать. Класс второй. E агенты, например, курсор. Когда нужно, чтобы AI видел весь твой проект Телеком, обычные чаты уже здесь не годятся.

198:20

Speaker A

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

198:33

Speaker A

Это редактор кода со встроенным AI, который видит весь свой проект целиком. Самый популярный сейчас курсор. Ещё есть GitHubilot. Чем курсор реально хорош? Он работает в двух режимах и оба полезные.

198:45

Speaker A

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

199:02

Speaker A

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

199:15

Speaker A

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

199:33

Speaker A

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

199:40

Speaker A

Осталось написать сам тест. Создаю новую папку под тесты. Создаю файл. Пишу сначала импорты. Мы уже видим подсказки.

199:52

Speaker A

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

200:05

Speaker A

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

200:18

Speaker A

Только я не хочу вот такую реализацию. Я хочу сделать через цикл. Так. Посмотрим свагер, чтобы убедиться.

200:27

Speaker A

Так, сделаем через циклф. Видим, что формат ошибок он перенял из прошлых наших тестов. Accepted but god.

200:37

Speaker A

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

200:47

Speaker A

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

200:57

Speaker A

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

201:13

Speaker A

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

201:30

Speaker A

курсор, а в терминале командной строке. Ты даёшь ему задачу словами, а он её выполняет целиком. Сам ходит по файлам, сам запускает команды, сам читает вывод и сам исправляет ошибки. В чём разница между курсором и cloudкод? Это частый вопрос. Давай разложу просто. Курсор -

201:46

Speaker A

это напарник. Ты сидишь в редакторе, видишь код, ты за рулём. Он подсказывает и дописывает, но рулишь ты. Cloud код - это исполнитель. Ты даёшь задачу, отходишь, он за рулём, а ты потом проверяешь результат. Помнишь мою историю про 1.500 тестов в начале? Вот

202:00

Speaker A

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

202:12

Speaker A

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

202:26

Speaker A

не помочь. Например, массовый рефакторинг тестов, как моя история, поднятие каркаса фреймворка с нуля на новом проекте, пайтеста, люр фикстуры, кофтест и всё остальное. Починить пачку автотестов, которые слетели после изменения API. Размжить тесты по готовому паттерну на новый модуль.

202:45

Speaker A

Сейчас я вам покажу всё это на практике. Задача реальная, с которым каждый автотестер сталкивается минимум раз в карьере. Нужно поднять тестовый фреймворк с нуля. На новом проекте нам нужно будет реализовать базовый HTP клиента, а-классы, модели через PIDENTIC, фикстуры, configперы и

203:03

Speaker A

разметить всё алюром. Если это делать руками, то это займёт от 1 дня до 7 дней. Там по-разному бывает. Попробуем делегировать эту задачу на Cloud Code.

203:12

Speaker A

Сейчас я открыл Cloud CД. У меня пустой проект, только документация. JSONфайл со свагером. Также есть документация по проекту и всё, никакого кода. Плюс я заранее подготовил промт. Я коротко его прошу построить мне фреймворк, соблюдая беспрактисы и всякое такое. Вставляю

203:31

Speaker A

промт в cloud codд. Сейчас мы его с вами изучим. Требования к архитектуре. Вы можете увидеть требования к тестам, порядок выполнения. Также нужны ограничения.

203:41

Speaker A

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

203:53

Speaker A

Пишем ему faster. Итак, прошло 15 минут. Cloud код закончил. Давайте посмотрим. Он нам выдал небольшой отчёт коротенький.

204:05

Speaker A

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

204:13

Speaker A

Сейчас мы начнём смотреть сами тесты. Вот у нас базовый клиент. Мы видим [музыка] его. Сессии, токены, всё здесь хорошо.

204:31

Speaker A

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

204:55

Speaker A

То есть 109 тестов у нас только что были созданы. Какие-то тесты фейлятся, мы сразу видим, какие-то проходят. Это нормально для первого прогона. Cloud не всегда пишет идеально. Тесты прошли.

205:06

Speaker A

Нужно посмотреть отчёт Алюра. И вот видим, что примерно половина тестов у нас прошла, половина упала.

205:22

Speaker A

Давайте посмотрим, почему они упали. Тут всё о'кей. Тут мы видим, что не совпал статус код.

205:37

Speaker A

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

205:58

Speaker A

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

206:12

Speaker A

минут реальной работы клауд-кода? Фреймворк с правильными паттернами и архитектурой, 109 тестов, покрывающие основные сценарии, конфиги, фикстуры, утлираных. Небольшая люрметка. Ну и бонусом мы нашли реальные баги в системе, что тоже очень хорошо. По сути, это не финальный продукт. Это жирный

206:31

Speaker A

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

206:40

Speaker A

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

206:54

Speaker A

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

207:11

Speaker A

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

207:27

Speaker A

данные, она сама заходит и берёт всё, что ей нужно. Представьте разницу без MCP ты говоришь: "Вот тебе скрин задачи из джира, вот кусок лого, вот выгрузки из базы данных на разбирайся". С MCP ты говоришь: "Глянь задачу, проверь, что

207:41

Speaker A

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

207:55

Speaker A

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

208:11

Speaker A

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

208:29

Speaker A

Плюнет и скажет: "AI не работает". Инструмент один, а разница в том, как они с ним разговаривают. Это называется промт инженеринг. И это самый важный навык во всей этой теме. Без него любой инструмент бесполезен. Разберёмся дальше.

208:46

Speaker A

Итак, главное правило: один чат, одна тема. Желательно, перед тем, как разбираться, как писать промты, расскажу про ошибку, из-за которой у новичков I тупит, и не работает. Дело в контекстном окне. У каждой модели есть память в рамках одного диалога. Это и есть

209:01

Speaker A

контекст. Окно большое, но не бесконечное, и с ним связаны две беды. Беда первая: замустривание. Новичок открывает один чат и валит туда всё подряд. Помоги с кейсами. Туда же напиши мне SQL. Туда же расскажи про MCP, а потом ещё какую-то фичу мне разложи.

209:18

Speaker A

Пять разных тем в одной куче. И модель начинает их путать. Спрашивает про SQL. Иногда она тянет в ответ обрывки твоих тест-кейсов. Изначала каша на входе, каша на выходе. Беда вторая.

209:30

Speaker A

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

209:47

Speaker A

Я не создаю 100 чатов, я пользуюсь папками, проектами. Есть такая штука в chat GPT в Клауде. Это работает так: создаю папку под проект. В неё один раз загружаю весь важный контекст. Что за проект, какая команда, какие инструменты, какой стек. Этот контекст

210:02

Speaker A

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

210:16

Speaker A

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

210:30

Speaker A

выжимку всего важного из диалога. Копирую её и переношу в новый чат. Это как сохраниться в игре перед сложным боссом. Продолжаешь с того же места, но с чистым окном. Сейчас просто покажу, как работают папки. Итак, сейчас я вам покажу, как выглядят папки в Cloudi.

210:45

Speaker A

Пишем тестовый проект. Тут будет весь контекст для моего тестового проекта под названием Sciencecope. Это онлайнкинотеатр.

211:03

Speaker A

Создаю. Так, сюда я хочу дать контекст обо всём бэкэнде проекта. Задай мне пять вопросов и сохрани контекст.

211:20

Speaker A

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

211:40

Speaker A

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

211:50

Speaker A

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

212:11

Speaker A

Кавка и так далее. Пишем кубернетис. О'кей, он сохранил. Теперь это протестируем. Контекст для фронтенда.

212:25

Speaker A

Задай мне также пять вопросов. Нажимаем Enter. Он помнит, что у нас есть backend. Сейчас мы будем заполнять frontend. На этот раз всё проще. Он просто даёт нам викторину, где мы должны выбрать нужные ответы. Ну, допустим, view. Допустим, оба. Выбираем все чекбоксы. Нажимаем

212:47

Speaker A

Next. Так, тут тоже всё выбираем. Нажимаем Next. Так, мы видим, что он сохранил контекст.

212:56

Speaker A

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

213:13

Speaker A

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

213:20

Speaker A

Вот и вся магия. Перейдём к хорошему промту для QA задачи. Промт для QA инженера должен содержать пять блоков.

213:28

Speaker A

Первое, роль. Кем ты должен стать? Ты QA инженер с опытом финтехи. Контекст: что за система? Какие технологии и нюансы.

213:35

Speaker A

Третье, задача. Что именно нужно сделать? Четвёртое, формат вывода, как должен выглядеть ответ. Гиркин Markдаун, таблица, jon, просто текст. Пятое.

213:43

Speaker A

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

213:55

Speaker A

Видите закономерность? Все три промта по одной структуре: роль, контекст, задача, формат, ограничения. Меняется только наполнение. И главный секрет - это ограничение. Именно последний блок отличает джиновский промт от синьорского. Напиши тест-кейсы. Так может написать каждый. А вот особое внимание обращай накейсы, корнеркейсы,

214:15

Speaker A

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

214:31

Speaker A

в гите. Сейчас в entтерпрайз-командах новый тренд. Хранить промты прямо в Git- репозитории, чтобы любой в команде QA разработчик мог зайти и воспользоваться готовым, проверенным промтом, а не изобретать велосипед каждый раз. Смысл простой. Если ты делаешь что-то регулярно, например, каждую неделю

214:50

Speaker A

генеришь тест кейсы по похожей структуре. Глупо писать промт заново. Каждый раз один раз отшлифовал, сохранил как файл и дальше просто берёшь готовый.

214:59

Speaker A

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

215:15

Speaker A

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

215:23

Speaker A

Команда им пользуется, замечает DI, косячит и подкручивает промпт. Чем дольше он живёт, тем он точнее.

215:33

Speaker A

О'кей, с инструментами и промтами разобрались. Теперь самое интересное. Покажу четыре типовые задачи, с которым сталкивается каждый тестировщик, и как я их закрываю с AI у себя на работе.

215:44

Speaker A

Задача номер один - разобраться в новой технологии перед тестированием. Давай сразу на конкретном кейсе. Представь, ты раньше тестировал через API и кавку. Всё знакомо, всё понятно. И тут тебе перекидывают в другой продукт, а там вместо Кавка уже биit MQ. И сразу

215:59

Speaker A

пролетает задача, связанная с ней. А ты с Ребитом Q никогда не работал. Знакомая ситуация? Два варианта, как это решить.

216:05

Speaker A

Вариант первый: как было раньше без AI. Садишься, зарееч, хабр, видосы на YouTube, документация, пару часов в лучшем случае, а то и весь рабочий день.

216:15

Speaker A

Просто чтобы понять, что это вообще за зверь и с чем его едят. Но этого мало.

216:19

Speaker A

Теперь надо идти к разрабу и спрашивать: "А как конкретно у нас в проекте протестировать эту фичуби MQ?" Отвлекаешь его от работы, ждёшь, пока освободится, задаёшь свои вопросы. Итог: день на беглое изучение плюс пару часов чужого времени у разраба. И только после

216:35

Speaker A

этого ты хоть как-то начинаешь тестировать эту задачу. День полтора выброшенный на помойку ещё до старта работы. Теперь вариант два. Как я бы делал это сейчас с AI. Открываем Cloud и первым делом гружу в него весь контекст.

216:48

Speaker A

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

216:58

Speaker A

Дальше пишу промт. Я Qнженер, мне предстоит тестирою систему с реbitмQ. Объясни, что я должен знать как тестировщик, что такое продюсер, что такое консюмер и как всё это проверять.

217:09

Speaker A

Какие типичные баги бывают на стыке сервисов и очередей. У меня есть опыт скавка, но нету с Rabbit MQ. Поэтому отдельно объяснить, чем Rabbit MQ отличается от Кавка и что из этого меняется для тестирования. На что обратить внимание при тестировании

217:23

Speaker A

задачи? И вот контекст проекта, документация. Получаю прицельный разбор с позиции тестировщика. Через 15 минут я уже знаю, что искать в логах, какие команды смотреть, где обычно всё ломается. И главный кайф я могу уточнять прямо на ходу: "А если консюмер падает в

217:39

Speaker A

середине обработки? Где это будет видно? А как проверить, что сообщение не потерялось в очереди? Момент, который экономит всем нервы. Мне почти не надо дёргать разработчика". Раньше я шёл к нему с пачкой базовых вопросов и отвлекал. Теперь базу я закрываю сам C,

217:54

Speaker A

а к разрабу иду уже с пару точных вопросов по существу, если вообще иду. Это был разбор на пальцах, а теперь покажу то же самое вживую. Специально не на Rabbit MQ, а на GRPC. Один и тот же приём, незнакомая технология, AI и

218:09

Speaker A

первый рабочий запрос. Смотрим. Реальная ситуация. Прилетела задача протестировать новый сервис на GRPC. А с раньше не работал, только привычный HTTP REST и так далее через Postman.

218:20

Speaker A

Разберёмся, как бы я бы всё это делал. Я создал отдельный проект специально для этого. Туда я приложил сообщение разработчика, требования аналитика приложил и сам протофайл. Это специальная штука для JPC, по сути контракт, как API. В общем, я вообще не

218:37

Speaker A

знаю, что такое GRPC, и я хочу разобраться, вот что бы мы бы делали в такой ситуации. Итак, начинаем писать промт. Мне дали задачу протестировать новый сервис на GRPC. Хочу протестировать при помощи Postman. Да и пошаговый гайд.

218:56

Speaker A

Как мне всё это настроить и начать тестировать? Так он думает. Пока он думает, я создам новый Workspace. Назову его JRPC testting.

219:13

Speaker A

Так, он выдал нам гайд, и мы сейчас пойдём по нему пошагово. Открою Postman. Создай новый GPC запрос. Посман. Жму плюсик. Выбираю JPC.

219:23

Speaker A

Второй шаг. Подключить протофайл и ввести адрес сервиса. Делаю импорт протофайла. Так, выбираем метод. видим, что он уже сразу распознал оба сервиса. Review сервис и moderation севиice.

219:48

Speaker A

Смотрим четвёртый шаг про переключатель ТЛС. Заходим в настройки. Что как-то муторно. Давайте пропустим этот шаг, потом разберёмся. Так, выбираем метод. Берём Create Review.

220:03

Speaker A

Cloud уже подготовил для меня готовый JON. Я его просто копирую и вставляю. Он построил структуру по протофайлу.

220:12

Speaker A

Нажимаем запуск и ничего не работает, потому что Movie ID не найден. Это логично. Нужны реальные ID юзера и фильма. Беру их из базы за кадром и подставлю.

220:24

Speaker A

Так, отправляю. Запрос прошёл. Ревю создан. С нуля до работающего GPC запроса всего лишь 5 минут. Давайте посмотрим, что нам пришло.

220:36

Speaker A

Так, moderation, action, approve. Поле должно стать false. Полев hidden должно быть false, но мы видим, что оно true. Возможно, это баг.

220:47

Speaker A

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

220:55

Speaker A

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

221:12

Speaker A

Проблем с ТЛС у нас тоже не было. Подводим итоги. Что мы сделали за 10 минут? Разобрались с новой для нас технологией GRPC. Настроили окружение в Postman, которое раньше под GRPC мы не настраивали. Отправили первый рабочий запрос и нашли реальный баг в системе.

221:28

Speaker A

ещё толком не начали полноценное тестирование, но мы уже понимаем, куда нам копать и как это всё работает. Это очень круто. Благодаря AI мы ускорили понимание этой технологии. Задача два- сгенерировать тест-кейсы по спецификации. Снова на конкретном кейсе пролетела новая фича, допустим, API,

221:47

Speaker A

оформление подписки. Те кидают свагер на 30 поинтов и говорят: "Покрой ты с кейсами". Знакомо, как это было раньше и как я делаю сейчас. Вариант один: как было раньше без AI? открываешь СВАр, садишься и пишешь кейсы руками. Endpint запоинтом позитивные негативные

222:04

Speaker A

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

222:13

Speaker A

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

222:25

Speaker A

Риск что-то пропустить от усталости. Вариант два, как делают сейчас CI. Беру cloud, закидываю в swagger и пишу промот по структуре из прошлой части. Роль, контекст задача формат ограничения.

222:38

Speaker A

Не голая напиши тест-кейсы, а с конкретикой. Кто я, что за система, в каком формате нужны кейсы и самое важное, какие ограничения и корнер кейсы учесть. Что получаю за 5 минут? Черновик на 100 -ре150 кейсов. Позитивные, негативные, граничные и безопасность.

222:55

Speaker A

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

223:10

Speaker A

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

223:17

Speaker A

Дальше ты их сам переносишь в валюрты стопs или zефир копипастом или импортом, если формат подходящий. Быстро, но руками. Уровень два. Агент плюс MCP.

223:27

Speaker A

Кейсы льются в аure сами. Тут подключаем то, про что я говорил. MCP для Alure Testops. MCP даёт AI руки, чтобы ходить в твои инструменты. У тебя курсор или cloudкод с подключенным MCP кор и ты даёшь задачу словами: "Возьми свагер из

223:44

Speaker A

файла, какой-нибудь файл называешь. Сгенерируй тест-кейсы позитивные, негативные и граничные, и через MCP создай их сразу в валюрты SOPS в проекте Subs в секции оформления подписки.

223:56

Speaker A

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

224:11

Speaker A

в Арвери, что оставить, а что поправить. Разберём на практике. Сейчас я вам покажу. За кадром я поставил Aure MCP.

224:19

Speaker A

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

224:30

Speaker A

Находится он вот тут. Здесь сказано генерация тесткейсов для TOS. Вообще скил - это отдельная инструкция для агента под конкретную задачу.

224:42

Speaker A

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

225:04

Speaker A

по нему. Дальше я начинаю давать ему задачу: изучить docs. Там есть сообщение от разраба и протофайл. Составь на его основе тест-кейсы.

225:19

Speaker A

Нажимаем Enter. Он обнаружил, что у него есть скил. Подгрузил его. Вот написал, да, об этом.

225:29

Speaker A

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

225:48

Speaker A

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

226:03

Speaker A

Это неудобный формат просмотра. Я чуть позже переведу на фиче. Вот. Переходим на фи. Всё разложил по папкам. Аккуратно открываем кейсы и рассматриваем их.

226:13

Speaker A

Повторное создание отзыва с тем же пользователем на тот же фильм. Тело расписано, шаги есть. Accepted result.

226:20

Speaker A

Ну, с тегами тут чуть-чуть по-другому. Он проставил сам, что захотел, но вообще мы можем дать ему свой выбор тегов, тогда он сделает всё ещё намного точнее.

226:29

Speaker A

Но это уже рабочий результат. Дальше можно просто кидать ему какие-то идеи текстом, а он оформит эти кейсы сам.

226:37

Speaker A

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

226:52

Speaker A

посмотреть. Как базу он вам дал уже хорошую. Это хороший черновик. Но не забывайте всё это перепроверять, и всегда надо проверять. Посмотрим какие-нибудь кейсы. Ровно 1.000 символов. Ровно 10. Граничные значения проверяет. Создание с отрицательным рейтингом. Есть кейс. Пустой текст

227:11

Speaker A

отзыва. Супер. Очень много чего и продумала. Итого. Подведу итоги. Фича вроде крошечная. Создай отзыв. Да проверь. А посмотрите, сколько кейсов нагенерил и сколько мест, где может что-то отвалиться. Вот очень классно, что он уже подготовил нам это всё, и нам

227:27

Speaker A

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

227:38

Speaker A

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

227:54

Speaker A

Нагенерил кейсы и сразу разложил их по проекту без ручного копипаста. Как это у меня на работе? Скажу честно, как есть.

228:02

Speaker A

У нас это в процесс внедряется, но в основном уже работает. Подключили агента через MCP к нашим источникам Свагера, Люрджира. Идея простая, чтобы агенты генерировали кейсы не из воздуха, а с учётом нашего контекста, что уже покрыто, в каком стиле оформлены кейсы,

228:18

Speaker A

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

228:34

Speaker A

что в бэклок на автоматизацию. Вот это ключевая мысль, и мы к ней ещё вернёмся в конце главы. A меня, он стал моим черновиком, а мозг, который принимает решение, остался моим. Задача номер три- сгенерировать тестовые данные. Одна из самых частых задач, про которые

228:49

Speaker A

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

229:00

Speaker A

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

229:10

Speaker A

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

229:28

Speaker A

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

229:41

Speaker A

Как делаю я сейчас AI. Открываю Cloud, даю чёткий промс, сгенерирую 50 тестовых пользователей для банковской системы РФ.

229:49

Speaker A

Нужны валидные Fio даты рождения от 18 до 65, валидный NNN с контрольной суммой, снилсы в формате и обозначаем маску. Номера паспортов в формате серия и номер, номера карточек банковских.

230:05

Speaker A

Формат JSON - ключи на английском. Через 30 секунд готовый JSON сразу импортируется в тесты. И вот в чём кайф.

230:11

Speaker A

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

230:27

Speaker A

это Postman и AI вместе. В реальной работе я часто делаю так. Открываю Postman. Нахожу готовый постзапрос на регистрацию, оформление подписки, ну или на что угодно. Скринью его и кидаю в cloud задачей. Перепиши этот запрос под негативные кейсы. Невалидный email,

230:44

Speaker A

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

231:02

Speaker A

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

231:16

Speaker A

Почему? Потому что в сложных бизнес-сценариях данные нужны на Литу. Создал юзера, достал его ID, создал ему счёт, пополнил, списал. Кажется, следующий шаг зависит от предыдущего.

231:26

Speaker A

Данные рождаются по ходу теста. Для такого теста AI не главный инструмент. А вот для подготовки фикстур, негативных кейсов, корнер-кейсов перед тестом самое то. Теперь покажу немного практики создания тестовых данных. Итак, кейс. У меня есть point создание оплаты по

231:42

Speaker A

фильму. Это финтехсценарий, где нужно покрыть разные платёжные системы: визы, Mastercard, мир. Плюс надо немного негатива. Volkswagen. Изучим его. Введим эту ручку Create для создания оплаты.

231:57

Speaker A

Копируем как есть и закидываем в клод. Вот есть пример тела. Запрос извагера. Я хочу протестировать различные варианты.

232:10

Speaker A

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

232:43

Speaker A

Копируете и вставляете в Postman. Ну, в нашем случае это свагер. Обратите внимание на важный момент. AI сам знает эти форматы, откуда начинается визы, как начинается карта Мир. Вообще, в целом, вы можете подключить MCP и гонять это через cloud код, чтобы это всё было

233:00

Speaker A

намного быстрее и эффективнее, чтобы он сам зашёл в базу данных и нашёл на Movie ID. Что унести из этого кейса? Первое, тестовые данные - это та задача, где AI выигрывает по чистому времени больше всего. Второе. AI знает технические

233:14

Speaker A

форматы, которые ты можешь не знать. Платёжной системы ENILS паспорта. Он держит это всё у себя в голове и не ошибается на этом уровне. Третье. И на следующий уровень связка с MCP или курсор превращает разовую генерацию в повторяемый workflow, который ты

233:31

Speaker A

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

233:38

Speaker A

Как разобраться в новой технологии JRPC CAS? Как сгенерировать тест-кейсы? Как генерировать тестовые данные под платёжной системы? Как курсоры Cloud CД работают с твоим кодом в части про инструменты? Сейчас перечислю автотестерский сценарий, где нам поможет и сценарий первый: написать тесты на

233:58

Speaker A

новую фичу. Прилетел endpint, нужны автотесты. Открываешь курсор в своём проекте, формулируешь задачу словами: "Напиши автотесты на этот Point". Стиль возьми вон оттуда. Фикстуры и смтест.

234:09

Speaker A

Курсор видит твой проект, понимает паттерн, генерит тесты в стиле твоей кодовой базы. Мы уже это разбирали.

234:15

Speaker A

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

234:35

Speaker A

модуль. Итак, сценарий три. MCP - это следующий уровень. Вот тут начинается по-настоящему интересное. Какие MCP сервера реально полезны QA инженеру? Их четыре основных. Первое- MCP colрops.

234:49

Speaker A

Самый кайфовый AI видит твои существующие тест-кейсы, понимая структуру, предусловия, шаги, постуя и генерит новые в стиле твоего проекта.

234:58

Speaker A

Плюс может разобрать отчёт прогоны и сгруппировать падение, где флаките тесты, где реальные баги, где инфраструктурные сбои. Второе. MCP Git AI читает мёрквесты, видит, какие файлы изменились, и сам говорит: "Вот эти тесты надо обновить". Эти нет. Раньше ты вручную сверял div, теперь это секунды.

235:16

Speaker A

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

235:31

Speaker A

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

235:47

Speaker A

Постгress. Он будет лазить при помощи MCP прямо в базу. SQL писать мы не будем. Разберём на примере сайскопа. Это наш тестовый стенд. Тут фильмы, отзывы, регистрация, авторизация. Ну, всё по классике. Возьмём типичную задачу- создать фильм. Тут у нас есть название,

236:03

Speaker A

картинка price description локация. Тут всё понятно. Есть жанр ID. А вот жанр ID мы не знаем. Допустим, я хочу создать фильм с жанром военный. Как нам узнать, какое ID у этого жанра? Название пишем рандомное. Телепузики, например.

236:23

Speaker A

Даже если вы ручник, вы можете всё равно пользоваться курсором. Вам не нужны автотесты, как у меня слева. Если вы MCP ещё не подключили, просто пишите ему: "Подключи мне MCP Постгрос". И он сам всё сделает. О'кей. Пишем ему задачу.

236:37

Speaker A

Мне надо узнать, какой жанр ID у фильмов военных. Чтобы создать фильм, сходи в базу данных и узнай этот ID. Происходит сейчас магия закадровая. И вот он сразу же нам выдал жанр военный в таблице имеет ID10. Нам не нужно было писать SQL запросы.

237:01

Speaker A

Давайте попробуем выполнить запрос. Нажимаем. Видим ошибку. Мы ещё не авторизованы. Нам нужна роль админа.

237:09

Speaker A

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

237:19

Speaker A

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

237:34

Speaker A

Даём добро. Курсор пыхтит. Так, читаем. Админююер создан. Через опишку создал админа. Обновил его патчем. Видим email, видим пароль.

237:46

Speaker A

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

237:57

Speaker A

Токен закидываем и авторизуемся. [музыка] Возвращаемся к нашей прошлой задаче. Создать фильм в жанре военный.

238:03

Speaker A

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

238:12

Speaker A

Переходим к другому кейсу. Нам нужно найти карточку фильма без отзывов на фронт. Искать самостоятельно нам лень.

238:20

Speaker A

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

238:44

Speaker A

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

238:52

Speaker A

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

239:02

Speaker A

Дал ссылку. Открываем. Видим, когда отзывов нет, на фронте отображается. Оставьте отзыв первым. Кейс мы проверили. Давайте теперь проверим кейс.

239:11

Speaker A

Наоборот, надо найти фильм, у которого отзывы есть. Тоже попросим ссылкой. Видим, как он пользуется SQэлем. Он сделал селект нам ссылку. Переходим по ней и видим отзывы. Кейс проверен.

239:32

Speaker A

Подведём итоги. Раньше нам пришлось бы писать SQL напрямую в дебивер. Искать всё это было бы душно. Теперь мы просто пишем всё в курсоре и сам разбирается в нашем контексте, сам выдаёт нам нужные жанры, сам выдаёт даже ссылки на фронд,

239:47

Speaker A

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

240:05

Speaker A

кстати, вам мотивация навести порядок в ваших тестах. Раньше чистый код - это была эстетика и удобство, ну и прихоть лиму подобное. Сейчас это ещё и прямая производительность. Чем чище проект, тем мощнее AI работает с ним.

240:23

Speaker A

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

240:41

Speaker A

это создание фильма, как мы делали на Sciencecop. Просишь курсор, напиши мне автотесты на этот endpint. Получаешь пачку красивых тестов, запускаешь, они все зелёные. Покрытие выросло. Ты доволен, отдаёшь свой пиар лиду, он опровет тесты в мастере. А теперь смотри, что внутри одного из них. Как вы

241:00

Speaker A

видите, тест проходит. В отчёте зелёная галочка. А теперь вопрос: что этот тест проверяет? На самом деле только то, что сервер ответил двухсоткой. Всё. А что фильм реально создался, он не проверяет.

241:12

Speaker A

Он не проверяет, что в ответе пришло, что пришло правильное название, что пришла цена, жанр, ничего не проверяет.

241:18

Speaker A

Также не смотрит базу данных. Сервер может вернуть двухсотку и пустое тело. Может вернуть двухсотку и сохранить фильм с ценой ноль. Вместо твоей цены, которую ты задавал. может вернуть 200 и вообще ничего не сохранить. Бывают и такие баги. Тест будет зелёный во всех

241:33

Speaker A

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

241:49

Speaker A

Джейсоном, хоть просто открытый объект. И тест пройдёт, лишь бы не NANн. AI обожает писать такие тесты. Почему, вы спросите? Потому что они проходят. Они дают зелёные галочки. Метрики уледа повысились. Тебе тоже нравятся зелёные галочки, но бизнес-логику они не

242:05

Speaker A

проверяют. Как защититься? Читай каждый осёт. Не количество тестов выросло, а что именно проверяет каждый тест.

242:11

Speaker A

Нормальный API-тест проверяет статус код плюс тело ответа плюс что данные реально изменились в системе. Помнишь наш тест на создание фильма в скринкасте? Мы циклом сверяли, что отправили, что получили. Вот это проверка, а не голый статус-код равно 200. Это самообман. Не

242:28

Speaker A

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

242:43

Speaker A

Спросишь у Клауда, проверь, нормальные ли тесты ты написал. Он скажет: "Отличные тесты, всё хорошо. Поэтому ревью делает человек или хотя бы другая модель". AI поднимает покрытие за 5 минут. Качество обеспечиваешь ты сам своими глазами. Поэтому не смотрите на

243:00

Speaker A

зелёные галочки. Вы должны проверять всё, что делает AI. Хорошо, с косяками AI разобрались. Теперь про внешние ограничения, про корпоративную безопасность. Многие банки, финтехи и гасухи запрещают использовать чат GPT, Cloud и другие облачные AI. Причина простая. Ты загружаешь код Свагер,

243:20

Speaker A

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

243:37

Speaker A

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

243:53

Speaker A

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

244:10

Speaker A

запрещён, это не значит, что он тебе недоступен. Есть три рабочих варианта, как можно выкрутиться из данной ситуации. Первое. льный LLM. Через OAMA или LM Studio можно поднять модель прямо на своём железе. Образы модели лежат в открытом доступе. Есть Deepsek, есть.

244:27

Speaker A

Запросы никуда не уходят. Всё находится на local host. Есть минус. Нужно мощное железо и очень много оперативной памяти.

244:33

Speaker A

Если у вас не мощное железо, то у вас будет очень тупая лмка. Вариант два: корпоративный ЛМ. Если компания готова инвестировать, она разворачивает свою ныронку на корпоративных серверах, вы можете подключиться к локальному LLM через API. Снаружи запросы не будут

244:50

Speaker A

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

245:08

Speaker A

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

245:24

Speaker A

которую AI ускоряет, а есть работа, которая и есть сам тестировщик. Её делегировать нельзя. И что же это такое?

245:30

Speaker A

Нельзя делегировать финальные решения, например, о релизе. Представь, пятница, вечер, релиз. Яй, говорит: "Все тесты зелёные, можно катить". Ты катишь, продакшн падает. Кто виноват? Найронка?

245:41

Speaker A

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

245:55

Speaker A

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

246:13

Speaker A

перед чёрной пятницей и падение платёжки будет стоить миллионы. Он не знает, что вон тот Legacy модуль трогать страшно, потому что его писал человек, который уволился 3 года назад. Контекст бизнеса в твоей голове. В лэмку его загрузить сложно, и она может всё это потерять и

246:29

Speaker A

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

246:43

Speaker A

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

247:01

Speaker A

датасете. А что, если нажать сюда во время загрузки? Это другой тип мышления, и именно за него тестировщикам платят так много. Ответственность за качество нельзя делегировать. Это финальная и главная мысль. Если на продакшене что-то сломалось, отвечает не cloudд, не курсор

247:17

Speaker A

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

247:23

Speaker A

Заметь закономерность, AI забирает исполнение, но не может забрать финальное решение. Решить, оценить, понять, ответить. Вот почему тестировщик всё ещё нужен и его никогда не заменит EI.

247:39

Speaker A

Теперь домажка. Работаем с Rful Booker сервисом. Публичный API про систему бронирования отелей. Он живой, у него есть авторизация, валидация, негативные сценарии. Вот тут у нас хранится документация. И чтобы ты не писал всё с нуля, я подготовил стартовый репозиторий. Внутри уже есть базовые

247:57

Speaker A

автотесты на создание, получение, удаления брони, текстуры и конфтест. Клонируй, поставь зависимость и запусти тестбазик. Если зелёный, ты готов к домашке. Сценарий кейс из реальной жизни. Представь, к тебе пришёл Тимлит и говорит: "Слушай, нам через 2 дня сдавать модуль бронирования. Базовые

248:16

Speaker A

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

248:28

Speaker A

AI-стировщик. Ты будешь работать быстрее. Что нужно сделать? Шаг первый. Разберись в API. Закинь в cloudкод ссылку на документацию resфлбукера и попроси объяснить, что это за endпоинты и как они работают и как работает авторизация, какие подводные камни. За 10 минут ты должен понимать систему так,

248:46

Speaker A

будто бы работал с ней неделю. Шаг два. Сгенерирует тест-кейсы по структуре промта из части три, которую мы тебе выдавали в этом ролике. Роль, контекст, задача, формат, ограничения. Попроси cloud код сгенерит тесткейса на putт и patch. И отдельно минимум пять

249:03

Speaker A

негативных сценариев: пропущенные поля, неверный тип данных, обновление без авторизации и всё такое. Лайфхак. Попроси cloudкод сохранить кейсы файл.

249:13

Speaker A

Дальше курсор может читать их напрямую без копипаста. Шаг три. Сгенерирует тестовые данные. Понадобятся валидные и невалидные данные для бронирования имена, даты цены. Попроси 20 наборов, 15 валидных и пять невалидных. Оставь какую-нибудь пометку типа validфse, чтобы было что подать на негатив. Шаг

249:32

Speaker A

четыре. Напиши автотесты через курсор. Открой стартовый репозиторий в курсор и дай задачу написать тесты по кейсам из шага два, который мы его сделали в домашке. Что должно получиться?

249:43

Speaker A

Позитивные тесты на пт- полное обновление. Позитивные тесты на патч- частичное обновление. Негативные тесты в отдельном файле testive.pi. Позитив и негатив в одном тесте мы не мешаем. Это правило сразу поставь курсор в рамки.

249:57

Speaker A

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

250:10

Speaker A

Ожидаемый результат под то, что вернул сервер. Всё позеленеет. А должно ли быть так? Подумайте. Подробнее я расскажу вам в разборе домашки на буссе. Шаг пять.

250:21

Speaker A

Финальный аудит. Самое важное. Открой все тесты, которые сгенерил курсор. Найди минимум два теста в пустышки, если они есть. Конечно. Я вам уже рассказывал, что значит тесты в пустышки. Это когда мы просто проверяем статус код равно 200. Перепишите тесты в

250:35

Speaker A

нормальный с проверкой реальной бизнес-логики. А также покажи до и после в отдельном файле Audit MD. Критерий зачёта: проверь себя без меня. Все позитивные тесты на пут и патч зелёные.

250:48

Speaker A

Все негативные сценарии возвращают ожидаемый код ошибок. Аудит выявил минимум два теста пустышки, и они переписаны. После того, как вы выполните домажку, вы можете спросить у Ишки, попросить сделать такой промт: "Пожалуйста, раскритикуй все мои автотесты". Вы можете послушать, сделать

251:04

Speaker A

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

251:19

Speaker A

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

251:33

Speaker A

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

251:54

Speaker A

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

252:11

Speaker A

Ответственность за качество всегда за тестировщиком. И - это знак умножения. Хорошего тестировщика он усиляет в разы, плохого делает опасным для команды. Что вам делать прямо сейчас? Не закрывай это видео и не иди дальше учиться AI под другим курсам. Сделай по-настояще

252:27

Speaker A

простую вещь. Открой Cloud или chatчат GPT прямо сегодня. Возьми свою рабочую задачу, которая у тебя прямо сейчас в работе. Тесткейсы, баг-репорты, разбор незнакомый технологии и прогони всё это через AI. Потому что между тем, кто смотрел Pro AI и тем, кто уже работает

252:43

Speaker A

на практике с AI, уже огромная пропасть. И плюс сделать домашку, которую я дал в предыдущей части на реальном Rful Booker Service. Спасибо, что досмотрел до конца. Я знаю, глава была потной. много инструментов, промтов, MCP. Не пытайся всё это внедрить разом. Возьми хотя бы

253:00

Speaker A

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

253:10

Speaker A

Hello, это Илья Фурса, эки Элиозаур, ментор по аналитике. Спасибо, капитан. Очевидность. Рад приветствовать тебя в главе AI для аналитиков. Если ты работаешь BI, дата продуктовым аналитиком или же только хочешь вступить на этот праведный путь, то уверен, что ты подчерпнёшь для себя из этой главы

253:33

Speaker A

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

253:50

Speaker A

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

254:13

Speaker A

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

254:33

Speaker A

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

254:58

Speaker A

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

255:21

Speaker A

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

255:44

Speaker A

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

255:54

Speaker A

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

256:15

Speaker A

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

256:35

Speaker A

Перейдём непосредственно к кейсу. Представьте, что вы работаете, например, во Вкусвиле, продуктовым аналитиком в так называемом фудтехе. То есть отвечаете за аналитику доставки заказов.

256:48

Speaker A

К вам прибегает ProdК с идеей на миллион и обещает, что при следующей выплате премии вы уедете на сказочное Бали на ПМЖ. Идея заключается в следующем.

257:00

Speaker A

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

257:20

Speaker A

говорится, ваши действия. Что скажете на это продакту? Главное, без паники. Тут здорово может помочь, например, так называемая функция глубокого ресерча в чат ГПТ. Deep resarch. Открываем соответствующую вкладку и вбиваем в него следующий промт. Ты работаешь продуктовым аналитиком Футехе, то есть

257:43

Speaker A

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

258:04

Speaker A

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

258:25

Speaker A

давайте я прокомментирую, мы с вами вместе посмотрим, что вообще чат ГПТ здесь сгенерировал. Сейчас я как раз экспортирую это сразу в пдфку. Так, пдфка готова. Открывается аж 22 страницы PDF-текста. И смотрите, насколько вообще детально всё расписано. Здесь прямо есть

258:47

Speaker A

резюме сразу. Сразу чат ГПТ сделал резюме для руководителя, где прямо написано, вот прямо чётко тут выделено моя рекомендация go. Go go для узкого MVP. No, no go для большой реализации на старте. Тут давайте даже я увеличу текст. Сейчас мы вот так вот сделаем.

259:07

Speaker A

Вот. Не стоит начинать с полноценного сценария, где мы прямо суперсистему строим, да, стоит запускать только бережные MVP, Callback или click to call из приложения сайта, то есть ограниченные часы работы, один пилотный город или кластер ресторанов, ручной ввод заказа операторов, существующую

259:28

Speaker A

систему, подтверждение заказа по SMS, оплата по ссылке, а не диктовка карты. Ух ты! Ну да, диктовка карты, наверное, будет такой такой себе. И здесь рассказывается, что такой подход минимизирует Капекс, опять же, то есть наши расходы, быстро даёт реальный

259:45

Speaker A

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

260:05

Speaker A

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

260:26

Speaker A

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

260:44

Speaker A

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

260:55

Speaker A

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

261:15

Speaker A

потратить. Тут даже вот учитывается, как это повлияет на доставку и курьеров. Даже техническая реализация схемы MVP нарисована. Сравнение всяких MVP вариантов. Это ли не красота? Финансовая модель просчитывается риски, но уже в конце, то есть конкретно в деньгах, как

261:32

Speaker A

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

261:49

Speaker A

в телефонные заказы стоят только как узкие измеряемые assisted ordering MVP для конкретных сегментов и конкретных pain points. Да, это прямо очень много англицизмов. Инвестировать сразу даже в минимальный voiceбоot или широкую горячую линию не стоит, пока вы не доказали хотя бы 1-2% инкрементального

262:10

Speaker A

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

262:28

Speaker A

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

262:45

Speaker A

В аналитике, как и в целом в IT, часто появляются новые инструменты, а старые умирают. К тому же сам набор инструментов отличается от компании компании. Особенно это заметно по набору там СУБД и BI-систем. И в этом заключается страх многих даже опытных

263:05

Speaker A

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

263:23

Speaker A

BI-системы datalнs, а вам дали офер, где там витрины слой, например, на кликхаусе. Асистема напротив сусет. При этом ещё нужно знать airflow. Тут как бы не путать с чисткой зубов, чтобы там вставить витрины на автообновление. Ведь на текущем месте вместо вас это делают

263:44

Speaker A

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

263:55

Speaker A

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

264:16

Speaker A

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

264:33

Speaker A

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

264:51

Speaker A

Docker связку Click Houseу плюс Airflow плюс суet. реализуй тестовую витрину на клиckкхаус и дак под неё, который будет раз в сутки добавлять небольшой кусочек данных. И в целом всё. Конечно, насчёт волшебности, ну, это шутка. Конкретный набор слов здесь, я считаю, не играет

265:11

Speaker A

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

265:20

Speaker A

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

265:31

Speaker A

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

265:52

Speaker A

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

266:14

Speaker A

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

266:31

Speaker A

Создаём. Супер. Выбираем какой-нибудь просто big number. Вот. И добавляем в качестве метрики items counts, например, просто сумму createчат. И давайте с вами сейчас развернём на полный экран. То есть у нас всё работает. Мы можем сохранить этот чарт и потом вывести в

266:52

Speaker A

наш дэшборд. Супер. Так, и давайте опять же посмотрим, например, на Airflow. Работает ли он? И, конечно же, Airflow тоже работает. Заходим в Airflow. И здесь как раз мы можем видеть наш дак, который уже аж три раза запускался. Мы

267:08

Speaker A

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

267:25

Speaker A

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

267:51

Speaker A

BI-система, а, скажем так, штука на Python, которая позволяет делать супер детализированные дашборды. Плюсы: можно сделать такие фичи, которых нет в обычных биосистемах. Минусы: ну, не классическая биосистема, как минимум. То есть всё, буквально всё это код и ещё раз код. Но тут на помощь нам приходит

268:13

Speaker A

AI. Точнее, я снова буду использовать, как и сказал в начале, кодекс. Закину следующий промт. Создай в докеer стamlit приложение с крутым дашбордом для анализа данных по заказам. Используй лучший практики BI, чтобы он был очень красивым и функциональным. В качестве

268:32

Speaker A

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

268:47

Speaker A

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

269:05

Speaker A

Можно посмотреть конкретные макрорегионы, там сегменты. Выбираем VIPмент, например. Вот всё пересчитывается. И здесь, если мы посмотрим ещё внизу, куча вкладок, обзор, продажи, продукты. Смотрите, какое прямо дерево нам кодекс построил отдельно по клиентам. Тут и некие там прямо сегменты собрались и по операциям,

269:29

Speaker A

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

269:47

Speaker A

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

270:06

Speaker A

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

270:23

Speaker A

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

270:40

Speaker A

Docker десктоп должен быть запущен для того, чтобы в целом вся эта магия произошла. Часто в работе аналитика заказчики присылают данные в виде эксельки. Это может быть даже просто CSV формат, то есть separated values, you know. Почему так происходит, об этом можно долго

271:04

Speaker A

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

271:23

Speaker A

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

271:42

Speaker A

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

272:01

Speaker A

есть и другие подфункции, в том числе на KGLE можно найти классные данные для анализа на любой вкус и цвет. В качестве примера возьмём данные по продажам известного бренда одежды Zara. Кстати, тут можете возразить: "Илья, так это здорово, но я ничего не могу поделать,

272:22

Speaker A

так как не хочу сливать данные компании в тот же самый ЧатГТ". И вы будете абсолютно правы. Тут по сути два пути.

272:30

Speaker A

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

272:51

Speaker A

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

273:12

Speaker A

тому, что делать бизнесу с чётким экшн-планом. Итак, давайте посмотрим. Вот я как раз закинул данные, написал промт и посмотрим. Вот что на протяжении аж 47 секунд думал ГПТ. Опять же у меня Sying Mode, то есть это даже не кодекс,

273:30

Speaker A

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

273:48

Speaker A

Второе, например, то, что вот главная категория по деньгам - это вообще Jackets. Тут написано основной денежный локомотив и так далее. Мы прямо вот всё читать не будем. Далее идут прямо конкретные гипотезы, да? То есть гипотезы для бизнеса. Что делать?

274:05

Speaker A

Например, первая гипотеза, вот промо надо перенести именно с категории мужчин на женские всякие свитера. Ух ты. Вторая гипотеза: Front of Store лучше использовать под товары без скидки. Ну, тут прямо без детализации не разберёшься и так далее. Опять же, всевсе

274:25

Speaker A

гипотезы мы с вами читать не будем. Вот посмотрим вот в конце, что даётся на чёткий экшн-план. То есть тут прямо говорится, что у нас этап один: быстрые действия на 1-2 недели. Вот что конкретно делать. Ну и само действие,

274:39

Speaker A

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

274:48

Speaker A

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

275:04

Speaker A

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

275:21

Speaker A

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

275:38

Speaker A

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

275:52

Speaker A

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

275:59

Speaker A

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

276:16

Speaker A

В этой части мы поговорим об алгоритмах, но не пугайтесь, это не совсем алгоритмы на техническом собеседовании в Яндексе.

276:26

Speaker A

Это так называемые аналитические алгоритмы. А конкретно мы разберём алгоритм скоринга. Чего бы то ни было.

276:34

Speaker A

Без паники. Сейчас объясню на простых примерах, что это может вообще означать. Бизнес, в котором работает аналитик, как правило, достаточно большой. Например, представьте, что вы работаете в сети Шоурумы, ну или шавермы, да, если вы из Питера, у вас 1.000 плюс точек по всей

276:54

Speaker A

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

277:12

Speaker A

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

277:33

Speaker A

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

277:52

Speaker A

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

278:11

Speaker A

просто по выручке. Тут также поможет думающий чат ГПТ. Об него можно подумать, особенно если есть идеи, но финальный алгоритм это трудно собрать.

278:22

Speaker A

Давайте заведём следующий промт. Ты работаешь аналитиком данных в сети Шоурмы. У вас 1.000 плюс точек по CF.

278:30

Speaker A

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

278:50

Speaker A

Закидываем как раз этот промт. И чат ГПТ подумал. Перво-наперво он рассказывает про логику скоринга. На основе чего мы будем скорить, на основе каких данных.

279:02

Speaker A

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

279:20

Speaker A

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

279:30

Speaker A

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

279:46

Speaker A

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

280:06

Speaker A

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

280:22

Speaker A

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

280:43

Speaker A

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

281:04

Speaker A

Вот тут даже вот пример, что менеджер не смотрит на все 120 точек региона подряд, а получает 10 точек с максимальным prоorрити score и конкретными причинами.

281:14

Speaker A

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

281:21

Speaker A

Рейтинг там упал за неделю резко там на 0,3. Отмены заказов, как я понимаю, выросли в два раза. тоже можем присылать. Так, у нас тут приоритизация аудитов, поиск типовых паттернов проблем, даже прогнозирование проблем нам рассказывают даже прямо оверкил какой-то. Чрезмерно нам тут ГПТ советуют

281:40

Speaker A

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

282:01

Speaker A

следующая версия, даже есть короткая формула для собеседования, но это, видимо, потому что это мой отчёт ГПТ.

282:08

Speaker A

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

282:21

Speaker A

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

282:35

Speaker A

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

282:53

Speaker A

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

283:09

Speaker A

Поэтому что я сейчас сделаю? Возьму датасет данных с Кала. Попрошу ГПТ подготовить Summ для презентации, ну, для генерации презентации в гамме и непосредственно сделаем презу. Погнали.

283:22

Speaker A

Я открываю датасет. Вот у меня сейчас вот датасет по пингвинам. Размеры пингвинов. Здесь опять же можно скачать кнопочкой этот датасет. Далее, конечно, я прикладываю этот датасет в чат ГПТ в думающем режиме. Задаю ему следующий промт. Подготовь короткий текстовый

283:42

Speaker A

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

284:03

Speaker A

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

284:22

Speaker A

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

284:41

Speaker A

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

285:01

Speaker A

Рассказывается здесь у нас про структуру датасета, всякие морфологические признаки, о'кей. Распределение видов и островов. Что у нас больше всего? Видов какого-то пингвина без кое, только генту. Ладно, я не буду пытаться вид сделать, как будто я знаю, как это

285:18

Speaker A

правильно читать. Сравнение видов по размеру тела. Кстати, тут сразу у нас, видите, барчарты нарисовано. То есть у нас картинка и картинка интерактивная, то есть можем наводить вот так вот. Всё работает. Далее у нас форма клюва как видовой маркет. Тут прямо отдельная ещё

285:35

Speaker A

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

285:47

Speaker A

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

286:04

Speaker A

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

286:24

Speaker A

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

286:48

Speaker A

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

287:11

Speaker A

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

287:33

Speaker A

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

287:51

Speaker A

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

288:12

Speaker A

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

288:25

Speaker A

Ну и скидываю ссылку на статью. У меня тут кодекс думал на протяжении аж 16 минут. Ну почти. Вот собрал такую штуку.

288:33

Speaker A

Причём интересно, что я же не сказал на каком языке писать. То есть здесь есть прямо JavaScript. Вот. Потому что как бы веб-приложение, хотя можно было сказать там условно сделать только на Питоне.

288:46

Speaker A

Вот я опять же не сказал, что у нас за мобильное приложение, что за область бизнеса, это там Marketпйсфтеch или это fintech какой-то там банк. То есть всё как бы без этого вполне о'кей сработало.

288:59

Speaker A

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

289:18

Speaker A

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

289:27

Speaker A

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

289:45

Speaker A

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

289:58

Speaker A

Опять же, тут есть ещё эээнд часть, но это просто вам небольшое интро, как по супер, ну, прямо супер простому промту у нас всё это получилось сделать. При том, что можно намного подробнее, дольше посидеть с кодексом, всё это править, подправить

290:15

Speaker A

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

290:22

Speaker A

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

290:46

Speaker A

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

290:56

Speaker A

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

291:18

Speaker A

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

291:39

Speaker A

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

291:59

Speaker A

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

292:18

Speaker A

Не надо строить 100 бессмысленных графиков, надо ответить на бизнес-вопросы. Что вообще делать-то будем для того, чтобы денег побольше, а не поменьше заработать? Главный артефакт, так называемый Seller Health Score, то есть алгоритм, который помогает понять, с какими продавцами в

292:39

Speaker A

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

292:58

Speaker A

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

293:21

Speaker A

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

293:42

Speaker A

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

293:55

Speaker A

Hello, это Илья Фурса Элиозаур. [музыка] Если вы смотрели предыдущую главу про AI для аналитиков, то, возможно, помните, что я говорил, что в следующей главе, во-первых, будет больше упора именно на технические детали, в частности на SQL.

294:14

Speaker A

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

294:25

Speaker A

Поэтому эту главу расскажу тоже я. Поэтому рад приветствовать тебя в главе AI для датаинженеров.

294:34

Speaker A

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

294:58

Speaker A

база держится на работе с этими данными, зачастую структурированными, которые хранятся в различных там популярных СУД по типу кликхауса или же Гринплама.

295:10

Speaker A

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

295:32

Speaker A

дисклеймер: "Я не буду повторять там то же самое про, например, тот же самый питон. Тоже как бы топовый навык. дата инженера, ибо как бы всё пиво льётся из одной бочки. Поэтому уверен, что после такого укращения сQэля вы поймёте, как

295:49

Speaker A

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

296:03

Speaker A

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

296:25

Speaker A

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

296:44

Speaker A

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

297:06

Speaker A

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

297:23

Speaker A

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

297:37

Speaker A

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

297:57

Speaker A

это просто пример. Промт вы можете самостоятельно точно написать. Опять же, как пример промта, мы пишем, что ты выступаешь как senior data engнир, и нужно посчитать retтенtion пользователей за последний месяц, да? То есть мы говорим, что вот мы хотим конкретно

298:14

Speaker A

метрику посчитать и говорим далее инструкции. То есть сначала задак уточняющих вопросов, в том числе к кому?

298:21

Speaker A

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

298:37

Speaker A

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

298:53

Speaker A

написать. При том, что мы говорим, что пока не пиши SQL, да, сначала помоги нам правильно сформулировать задачу бизнесово, а потом на основе этого формирования, если так можно выразиться, тот же чат ГПТ спокойно вам напишет код, и вы просто Ctrl C, Ctrl V, немножко его

299:10

Speaker A

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

299:38

Speaker A

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

299:55

Speaker A

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

300:13

Speaker A

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

300:32

Speaker A

взглядом. Итак, чего же начинается сам промт? Мы говорим о том, что мы хотим, чтобы ИИИ написал escapль запрос для пастгресса. Сразу указываем, получается СУБD, которая будет использоваться. И в качестве контекста даём таблицы входные, потому что опять же иишка, она, как

300:52

Speaker A

правило, не подключена непосредственно к нашей СУБD, особенно если это продакшн, там вот чувствительные данные и, как правило, тем более стороннюю чат ГПТ, ну точно особенно какой-то российский бигтех вам не позволит подключить, но вы можете дать контекст, то есть какие поля

301:09

Speaker A

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

301:24

Speaker A

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

301:42

Speaker A

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

301:58

Speaker A

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

302:14

Speaker A

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

302:36

Speaker A

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

302:57

Speaker A

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

303:18

Speaker A

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

303:37

Speaker A

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

303:53

Speaker A

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

304:11

Speaker A

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

304:26

Speaker A

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

304:38

Speaker A

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

304:54

Speaker A

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

305:17

Speaker A

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

305:25

Speaker A

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

305:42

Speaker A

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

305:55

Speaker A

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

306:14

Speaker A

или же их в целом кривость, да, что партицы надо бы пересоздать. И, конечно, разберём пример промтак, который может нам в этом помочь. А именно промт заключается в следующем. Проанализирую скельзапрос и explain analy вот как такой database performance eng, ну или в

306:31

Speaker A

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

306:49

Speaker A

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

307:08

Speaker A

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

307:28

Speaker A

галлюционировала, да, там не придумывала саму статистику, размеры таблиц, поля нашего селекта. Ну и непосредственно, да, нам нужно этот сект или даже не обязательно сект передать. Ну и XLIN Analй из Бдшки, чтобы сам и [музыка] понял, какой там запрос в части плана

307:46

Speaker A

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

307:59

Speaker A

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

308:17

Speaker A

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

308:41

Speaker A

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

308:59

Speaker A

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

309:16

Speaker A

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

309:34

Speaker A

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

309:52

Speaker A

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

310:13

Speaker A

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

310:27

Speaker A

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

310:40

Speaker A

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

310:58

Speaker A

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

311:16

Speaker A

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

311:30

Speaker A

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

311:52

Speaker A

автоматизирует прежде всего механическую часть работы, там написание шаблонных запросов. адаптация старого кода, поиск каких-то ошибок, подготовка в целом документации. Ну вот это вот всё, думаю, как бы вы поняли. При этом самые важные задачи остаются непосредственно за человеком. То есть опять же, например,

312:15

Speaker A

как понять реальную бизнес-проблему, выбрать, например, правильную метрику, проверить в целом корректность данных, точно ли всё правильно там ГПТ нагенерировал, интерпретировать в целом результат, что дальше с этим делать. ну, превратить анализ именно в решение, наконец-таки, да, а не просто, чтобы

312:33

Speaker A

данные остались просто данными. Поэтому ценность нас как спецов смещается, да, от знания синтаксиса к качеству мышления. Ну, опять же, как бы это пафосно не звучало. [музыка] Так что учите мачасть в использовании ишки, и будет вам счастье.

312:55

Speaker A

Рад приветствовать вас на разделе с домашним заданием по пройденным, скажем так, возможностям использованиишки в инженерии данных. Поэтому предлагаю вам попробовать себя, как ни странно, не в ролитаинженера пока что, а в роли бизнесмена, а более формально. Ваше задание звучит следующим образом.

313:18

Speaker A

Первое, выберите какой-нибудь бизнес, например, не знаю, там сеть продуктовых магазинов. И представьте, да, закройте глаза и представьте, что вы как раз уже открываете или даже открыли этот бизнес.

313:32

Speaker A

Шаг номер два. Теперь же вам, как даты инженеру, требуется продумать техническое решение того, как данные будут храниться, собираться и использоваться вот в вашей этой новосозданной компании. Конечно же, с помощью вы всё это будете делать. Ну и подготовьте, опять же, как такой базовый

313:51

Speaker A

минимум, ответы на следующие вопросы. Перво-наперво, какие инструменты и технологии вы будете использовать, в каких, например, там СУБД будут храниться данные? Нужна ли будет биосистема вам, либо вы просто там на доске будете рисовать графики. Следующая вещь - это какие в целом сущности нужно

314:11

Speaker A

создать в виде таблиц в бдшке, что нужно хранить, как долго. Следующая вещь, а какая будет, ну, плюс-минус стоимость такого решения? Нужно ли использовать так называемые облака или же всё будет, скажем так, на личных серверах построено с нуля, там, не знаю, где-то хостится у

314:28

Speaker A

бабушки в деревне. Главная же цель - это подготовить чёткий план, который вы сможете защитить перед вашими, скажем так, инвесторами, дабы убедить их, что в части инженерии данных у вас всё в компании было, будет и сейчас на высшем уровне, и они могут точно не

314:46

Speaker A

беспокоиться. Разбор же этого домашнего задания вы сможете найти, конечно же, на бусте. Привет. Меня зовут Александр. Я руководитель направления AI пайплайнов.

315:02

Speaker A

До этого несколько лет работал в Яндексе, а всего за плечами около 8 лет в Data Science. Я ментор в направлении AINGринг. Помогаю войти с нуля или перекатиться в эту новую профессию. Сам я давно делаю с помощью и уже буквально

315:16

Speaker A

всё. Именно поэтому отлично знаю, где он в очередной раз захочет меня обмануть или потратит непростительно много моего времени. В прошлых главах уже звучала такая мысль, как инструмент работает, проблема в навыке, а самый базовый навык - понять, когда не доставать этот

315:31

Speaker A

инструмент вообще. Именно этому будет посвящена данная глава. Мы погрузимся в детали работы LLM-моделек, разовьём интуицию, в каких случаях не стоит делегировать работу и и почему, а также поймаем и с поличным в тот момент, когда он сколлюционировал или спрятал за

315:47

Speaker A

красиво оформленным результатом полную чушь. Я замечаю, что в последнее время люди вокруг разделились на два лагеря. И слишком туп и не экспертен в моей области, чтобы решать мои задачи. И и слишком умён, экспертен во всём. И вот-вот всех нас заменят. Давайте

316:04

Speaker A

избавимся от этой ложной дихотомии. Сегодняшние топовые модели, конечно, отнюдь не тупые, как многие по разным причинам продолжают считать. Например, chт GPT в двадцать пятом показал результат золотого медалиста на международной математической олимпиаде, а в двадцать шестом решил задачу Эрдёша,

316:19

Speaker A

на которой математики бились 60 лет. Но и далеко не всемогущий. Под капотом это вероятностная модель, которая обучалась определённым образом под определённые цели, а потому имеет ограничения, связанные с её архитектурой и дизайном.

316:32

Speaker A

Давайте рассмотрим несколько примеров стандартных ограничений и, чтобы чуть глубже копнуть в его архитектуру. Первый промт. Сколько раз буква О встречается в этом тексте? И не видит текст как набор букв. Перед обработкой текст рубится на токены, куски слов. Например, сороки для

316:48

Speaker A

него - это сор и оки, а не с Ор о к и. Отдельных букв внутри токена для модели просто нет, поэтому посчитать символы для неё без специальных инструментов почти неподъёмная задача. Она отвечает интуитивно, а не считает по-настоящему.

317:04

Speaker A

То есть, например, она физически не знает, что находится внутри токенасор. Это буквосочетание для неё, атомарная единица. На коротком слове прикидка часто совпадает. Модель при обучении читала всякие споры про орфографию и другие релевантные тексты. На длинном предложении уже стабильно разъезжается.

317:20

Speaker A

В нашем случае ЛМ насчитала 27 букв вместо тридцатидвух. Второй промт. Отец мальчика-хирург. Мальчик попал в аварию, его привозят в больницу, и хирург говорит: "Я не могу оперировать его. Это мой сын. [музыка] Как такое возможно? Эту загадку модель видела в обучении тысячи раз, почти

317:37

Speaker A

всегда в оригинальной версии, где разгадка, хирург - это мать. Я специально убрал из этой загадки всю загадочность, но не решает задачу с нуля, а достраивает самое вероятное продолжение знакомого шаблона, поэтому выдаёт заученный ответ и не замечает, что в условии ей уже сказали: "Отец есть

317:53

Speaker A

хирург". Подвоха нет, она его ищет, потому что в корпусе текстов, на котором она обучалась, так было чаще всего.

317:59

Speaker A

Третий промт- схема: Orders, ID, customer ID amount и order items. Order ID, product quantity. Напиши SQL для каждого клиента. Посчитай средний чек и общее число проданных единиц. Запрос выглядит как надо. И join, иy, и аккуратный Quалеск. Но для расчёта

318:16

Speaker A

среднего чекай не нужен. Он нужен только для расчёта общего числа проданных единиц. А LLM, решая вторую задачу, затащила всё в джой и не заметила простейшей логической ошибки. То есть модель выдала самую типовую форму такого запроса. Все агрегаты считаются вместе в

318:31

Speaker A

одном селекте, а неверную под смысл данных. Посчитать среднее значение отдельно под запросу. Ошибка тихая, код компилируется, цифры есть и выглядят разумно, но доверять им нельзя. Я специально привёл здесь те галлюцинации, которые смог воспроизвести у себя за 5 минут в веб-интерфейсе GPT и

318:49

Speaker A

в курсоре на модели GPT 5.5. можешь повторить то же самое у себя, только имей в виду, что иногда повторить не получится, иногда может понадобиться несколько попыток. Это всё следствие LLM недетерминизма. На один и тот же промпт одна и та же модель может ответить

319:03

Speaker A

совершенно по-разному. Самым влияющим на это фактором является температура модели. Обрати внимание, что это тот же самый chт GPT, который щёлкал невероятно трудные математические задачи. Что общего во всех этих трёх примерах?

319:16

Speaker A

Устройство модели и повёрнутость на достижение результата. и не понимает текст. Он рубит его на токены, превращает в числовые векторы и предсказывает самый вероятный следующий токен, слово за словом, по статистике, на которой обучался. И угадывание результата всё ещё поощряется при

319:31

Speaker A

обучении модели. Модель, которая признаёт свои ошибки и ограничения, получит гораздо меньший балл на бенчмарках, чем модель, которая любой ценой попытается выдать ответ, хотя бы отдалённо похожий на правду. Бенчмарки - это такие специально собранные и общедоступные датасеты для замеров

319:46

Speaker A

качества и сравнения этих замеров у разныхмок. За ответ не знаю, баллов не дают. А при уверенном ответе у модели есть шанс попасть в точку и выбить качество побольше и собрать хайп вокруг себя, побив новый рекорд или обогнав других провайдеров. От того, как

320:01

Speaker A

составлены сами бенчмарки, качество на которых напрямую влияет на популярность модели и, следовательно, приносит больше денег её владельцам, зависит очень многое. И это позволяет нам лучше понять, как устроены топовые лэмки сегодня и чего от них ожидать. бенчмарки бывает двух типов: с эталонными

320:17

Speaker A

ответами, тысячи задач по коду, математики, где есть правильно, неправильно и так далее. И что больше понравилось людям? На сайтах вроде ARA AI живым людям показывают пару ответов и спрашивают, какой лучше. Это приводит к тому, что люди часто оценивают модель

320:32

Speaker A

чисто субъективно, более красиво, нравится тон ответа, ответ нужной длины и так далее. Арене регулярно приходится работать над тем, чтобы придумывать новые способы вычищать искусственные завышенные оценки за счёт длины и оформления ответа. В итоге модель в первую очередь учит нравиться людям, в

320:49

Speaker A

том числе льстить, соглашаться с человеком и прочее, и выбивать высокие баллы на ограниченном множестве задач, а не говорить правду или тщательно перепроверять и нести ответственность за свои результаты. Это как раз целиком и полностью ответственность юзера. На практике это часто приводит к одной из

321:05

Speaker A

крайностей, которые я формулировал выше. И никогда нельзя доверять, и и лучше и надёжнее меня справится с любой задачей.

321:14

Speaker A

Крутой инсайт дал контролируемый эксперимент в двадцать пятом году. Опытные разработчики, которым разрешили пользоваться и на знакомой им кодовой базе, отработали в среднем на 20% медленнее, чем без него. И самое интересное то, что те же самые люди были уверены, что ИИ, наоборот, ускорил их

321:30

Speaker A

примерно на 20%. Вывод отсюда напрашивается очевидный. Полагаться на свои ощущения в части ускорения своей работы с помощью и ненадёжно, а потому важно чётко осознавать, в каких случаях лучше просто сделать что-то иным способом. Разберём теперь типовые сценарии.

321:49

Speaker A

Первый сценарий - задачи, в которых важна стопроцентная точность. Одним из самых избитых и древних примеров является использование EИ как калькулятора. Ранние GPT модели совсем не справлялись с базовыми математическими задачками. Но ситуация сильно изменилась с появлением у моделей ризонинга. Режима, в котором модель

322:08

Speaker A

перед финальным ответом сначала прогоняет в уме цепочку рассуждений. Впервые этот режим появился у Open AI осенью двацать четвётого, а в течение двадцать пятого года это стало общим стандартом. Давайте сравним два подхода и заодно развеем устоявшийся миф: "LлM не умеет считать". Как было раньше.

322:26

Speaker A

Модель выдавала ответ за один проход, то есть фактически предсказывала самое правдоподобное продолжение, а не вычисляла. Дело не в глупости модели как таковой. Генерация текстов, вопросы на общие знания, пересказ и другие задачи она успешно выполняла. И тогда проседало именно то, что требует пошаговой

322:44

Speaker A

цепочки: арифметика, многоходовая логика, сложные расчёты, сложение многозначных чисел. Операция последовательная, а трансформер, костяк любой элэмки за один проход параллельная машина фиксированной глубины, поэтому такую цепочку действий надёжно не тянет.

323:00

Speaker A

это его архитектурное ограничение, доказанное математически. Отсюда и закономерное недоверие. Модель, которая не может перемножить два числа, выглядела неубедительно. Но это скорее когнитивная ошибка. Если использовать модель по назначению, её результаты становятся более надёжными и предсказуемыми. Современные модели с режимом размышления представки thinking,

323:22

Speaker A

reasoning- это ограничение научились обходить. Они либо расписывают вычисление по шагам в скрытом черновике, что снимает проблему одного прохода, либо запускают для этой цели простой скрипт. Подход с черновиком называют Chain of Tho. Кстати, теперь за этими скрытыми размышлениями можно следить в

323:40

Speaker A

реальном времени во многих интерфейсах. В общем, корректно считать современные модели способны, но рининг требует ресурсов, поэтому у многих LLM есть внутренний роутинг. На этот конкретный запрос пользователя стоит потратить время и деньги на рининг или лучше ответить без раздумий? И это уже

323:56

Speaker A

лотерея. Если модель поленится и сочтёт твою задачу тривиальной, ответ может быть сомнительного качества. Итак, с одной стороны, Ии всё же научился считать, а с другой, он по-прежнему ленив и непредсказуем. Ты никогда не знаешь наверняка, соизволит ли он посчитать всё надёжным скриптом,

324:12

Speaker A

распишет ли вычисление в черновике или просто попытается угадать ответ сходу. Покажу на живом эксперименте. Снова возьмём GPT 5.5 из курсора. В этом интерфейсе удобно наблюдать за тем, как модель размышляет. Берём обычную табличку расходов, 30 строк, сумма с копейками. Правильный итог- 169.500.

324:32

Speaker A

Внизу он посчитан через сумму. Закидываю модели скриншот этой таблицы без итоговой суммы и спрашиваю, сколько денег ушло в итоге. Получаю в ответ одно число: 151. 198 и 17 коп. Мимо на 18.000 и не тени сомнения.

324:49

Speaker A

Но есть нюанс. Если те же самые числа отправить не картинкой, а текстом, модель думает несколько секунд и выдаёт нужную сумму с точностью до копейки.

324:58

Speaker A

Причём, если прогнать несколько раз, модель стабильно будет попадать. Почему так вышло? В случае с картинкой добавился ещё один слой распознавание или ввиду стабильного попадания в ответ на текстовый запрос модель, вероятно, криво считала информацию со скриншота и сложила уже искажённые данные. Текст же

325:15

Speaker A

распознавать не нужно, числа сразу попадают в вычисление, как есть. Этот пример наглядно демонстрирует, что каждый дополнительный слой, тут это парсинг картинки, кратно увеличивает шанс ошибки. У модели сразу несколько дел, и она может споткнуться на любом из этапов. Но давайте судим задачу, да,

325:31

Speaker A

просто посчитать. Для этого возьмём пример чуть сложнее. 80 транзакций, большой разброс чисел. Среди них несколько со знаком минус. Правильный ответ в районе 16,5 млн. Кидаю данные текстом и спрашиваю: "Сколько всего выходит? Модель быстро отвечает: 11.900".

325:49

Speaker A

Мимо на 4,5 млн. Очевидно, она поленилась расписывать вычисления и попыталась угадать ответ с ходу. Кидаем второй раз. Модель размышляет 10 секунд.

325:58

Speaker A

И вот часть её размышлений. Я вижу инструкцию проверить доступные терминалы перед выполнением команды, но, возможно, есть способ это обойти. Она буквально прикидывает, как бы обойти свои инструкции, чтобы быстрее ответить юзеру. Но на этот раз Reринг сделал своё дело, и модель попала ровно в 16,5 млн.

326:17

Speaker A

Попробуем третий раз. На этот раз я чуть поменял вопрос на какова общая сумма? И это привело к новому поведению.

326:24

Speaker A

Возможно, из-за более строгой формулировки. Модель выбрала решить задачу Python скриптом и получила верный ответ. Первая попытка - отличный пример того, как на простой задачке и уверенно ломается. Вторая и третья попытки позволяют пронаблюдать тот самый эффект бенчмарков, о котором мы говорили

326:40

Speaker A

раньше. У модели, помимо просьбы юзера, есть ещё ряд своих личных целей и инструкций. И далеко не факт, что желание юзера она поставит выше вшитых в неё создателем. Лучшим решением, разумеется, всегда было использовать простой скрипт для ответа. Хотя в его

326:54

Speaker A

генерации модель тоже может сгаллюцинировать, но выбрала она его только в одном случае из трёх, и то пришлось её к этому подтолкнуть.

327:01

Speaker A

Ключевые инсайты. Старайся использовать ИИ только со знанием дела. Если твоя задача предполагает длинную цепочку последовательных действий, убедись, что lm переведена в thinkнкиing режим, а не бездумно генерирует ответ или код. Чем сложнее задача, тем выше можно выкручивать степени ризонинга medum, хай

327:19

Speaker A

и так далее. В процессе генерации ответа наблюдай за тем, как lм мыслит, и сразу направляй её в нужное русло. Ещё на том этапе, когда она только подумала сделать что-то не то. Не делегируй и выбор способа решения, когда есть заведомо

327:32

Speaker A

самый лучший. Относись к кии со здоровым скепсисом. Перепроверяй важные действия и не строй выводы на паре успешных кейсов. На третий раз модель вдруг с галлюцинирует, и излишнее доверие приведёт к неприятным последствиям. Если у тебя есть простое действие, в котором

327:47

Speaker A

категорически нельзя ошибиться, а валидация результата займёт не меньше времени, просто сделай это действие сам.

327:58

Speaker A

Второй сценарий и как поисковик и источник свежих фактов. Нередко мы спрашиваем у Ии актуальную версию библиотеки, сигнатуры метода, детали свежей уязвимости, ссылку на какую-нибудь статью или материал. Он уверенно отвечает на все эти запросы, но с приличной вероятностью версия из его

328:14

Speaker A

ответа устарела, сигнатура выдумана, а посылки либо 404, либо вообще не имеющие отношения к делуматериало. У этих ошибок есть несколько причин. Во-первых, хотя модель уже научили ходить в интернет специальным инструментом, это не значит, что ответ будет всегда достоверен.

328:30

Speaker A

надеется, что она честно скажет, что ничего не нашлось - это оптимистичный сценарий. Если подходящего источника нет, она может прислать не очень подходящий или вообще выдумать несуществующий. И это не редкий сбой.

328:42

Speaker A

LлM выдаёт несуществующие страницы в разы чаще обычного поиска, а также часто путает цитаты из источников. Во-вторых, каждая модель обучалась на данных до какой-то конкретной даты в прошлом, после которой про мир она не знает вообще ничего. В двадцать шестом году у

328:57

Speaker A

топовых моделей дата отсечения - это лето, осень двацать пятого. И в поиск она идёт не всегда. В ID и агентах на вопрос какая последняя версия или сигнатура метода модель часто отвечает по памяти, не перепроверяя, актуальная ли эта информация. Та же беда с именами

329:11

Speaker A

пакетов. Модель легко выдумывает несуществующий пакет, и злоумышленники этим уже пользуются. Заранее регистрируют именно те фейковые имена, которые модели галлюционируют чаще всего. Это называется слот сquн.

329:23

Speaker A

Обобщая, если тебе нужен конкретный проверяемый факт, версия, дата, источник, сигнатура, и ты не собираешься перепроверять его руками, и здесь может подвести удобный фрейм, и это resarch assistent, который подсказывает, где искать, а не база данных, информация из которых можно всегда верить на слово.

329:42

Speaker A

Давайте проведём простой показательный эксперимент. Промт: "Дай статью с Хабра" этого года на казахском про галлюцинации LLM модель GPT 5.5 веб-интерфейс. Как мы видим, модель безмолвно прислала ссылку на статью на русском языке, которая при этом подходит по теме. Также я лично

329:59

Speaker A

ввиду того, что часто ищу хорошие статьи по разным темам, кучу раз натыкался на то, что и отдавал мне совершенно случайную ссылку. При этом якобы, цитируя из неё релевантные моему запросу утверждения. Ключевые инсайты. При вопросах о свежей информации явно проси

330:14

Speaker A

модель использовать поисковик или свериться с источником, а не отвечать по памяти. За строгими фактами проще сходить в первоисточник либо использовать специально обученные EИ типы perplexity. Для свежих библиотек можно использовать инструменты вроде конк 7, которые подсовывают модели актуальную документацию. При поиске

330:30

Speaker A

информации через и валидирую его источники и цитаты из них. Может оказаться, что цитата отсутствует в источнике или сам источник поломанный, нерелевантный или выдуманный.

330:46

Speaker A

Следующий сценарий - работа с чувствительными данными во внешних моделях. Сначала дадим определение этому мутному термину. Чувствительные данные - это всё, что нанесёт ущерб, если покинет внутренний контур компании. Ущерб юридический финансовый репутационный или по безопасности. На практике это доступы и секреты: API-ключи, токены,

331:05

Speaker A

пароли, приватные ключи, строки подключения к БD и прочее. Персональные данные клиентов и сотрудников Fio.

331:11

Speaker A

Телефоны, почты. платёжки и всё, что регулируется 152 ФЗ. Внутренние документы, договоры под NDA, неопубликованные финансовые данные, рабочая переписка и так далее.

331:23

Speaker A

Коммерческая тайна и интеллектуальная собственность, непубличный исходный код, архитектура, алгоритмы, ноу-хау. На деле это самый слабый пункт списка. На практике им в первую очередь пренебрегают. Простая интуиция такая: если утечка данных повлечёт штраф, иск, взлом или неприятный разговор с безопасником, эти данные чувствительные.

331:43

Speaker A

Теперь к делу. Предположим, мы хотим дать сторонний lm чат GPT, CLД, deep псиquку, какой угодно. Одно из следующих заданий. Первое задание- сделать небольшую задачку в репозитории, содержащим незащищённые токены и креды, или документы с персональной информацией клиентов компании. Второе задание:

332:01

Speaker A

суммаризовать NDA документ. Третье задание - помочь сгенерить красивую презентацию со свежими финансовыми результатами продукта. Во всех трёх случаях ты отправишь на сервер провайдера твоего EИ чувствительные данные. Это действие несёт неприятные последствия от простого нарушения NDA или внутреннего регламента до санкций в

332:20

Speaker A

виде ограничения пользования рабочими инструментами и потенциальной угрозы кибератаки. Промт уходит на сервер провайдера, где может логироваться, а в зависимости от настроек и условий использования попадать в обучающую выборку для обучения новых моделей.

332:33

Speaker A

Секрет, который попал к ИИ, после этого является скомпрометированным. Причём не обязательно ты его прямо туда вставил и [музыка] агент мог прочитать его через башкоманду, пока выполнял твою задачу.

332:44

Speaker A

Известных инцидентов уже достаточно. В марте двадцать третьего баг в chatча GPT показывал пользователям заголовки чужих переписок и часть платёжных данных, а инженеры Samsung за 20 дней трижды слили в публичный чат исходники и внутренние документы, после чего волна компаний

332:59

Speaker A

Apple, JP Morgan, Goldman Sax и другие запретила сотрудникам публичные генеративное модели. Важно понять, что именно запрещают. Не ИИ как таковой, а публичный неконтролируемый канал. Таже Apple, забанив публичный charge GPT, через пару лет строила инженерам CLOД прямо в XCД. То есть компании не

333:17

Speaker A

выбирают жить с и без него. Они создают условия для безопасного и конфиденциального использования. Есть и альтернативный подход. Компании, располагающие большим количеством ресурсов, разворачивают у себя в контуре лучшие open source-модели JLM, Deepsek и другие, которые справляются с повседневными задачками уже на приличном

333:35

Speaker A

уровне. И даже в этих случаях часть данных может утечь мимо твоего внимания. Но в этом случае нетрудно взять контроль в своей руки. Разберём на примере связки, курсор и агентские расширения.

333:46

Speaker A

Телеметрия. Пока не включён Privacy mode. Наружу по умолчанию уходят твои промты, снипеты кода, действия в редакторе, чтобы улучшать продукт.

333:54

Speaker A

Включаешь Privacy mode, и провайдерам гарантируется, что твои запросы не сохраняются ни в логах, ни в истории, ни для обучения новых моделей. Телеметрию добиваешь в настройках. Проделаем это в домашнем задании. Индексация. Чтобы эффективнее писать код в твоём репозитории, курсор строит индекс, режет

334:12

Speaker A

код на куски, считает по ним эмбейдинги, то есть векторные представления текстов, и сохраняет себе на сервер. Сырой код на их серверах при этом не хранится, но сам факт, что в обработку уезжает весь проект, включая то, что ты и не

334:25

Speaker A

открывал, мало кто осознаёт. Решение простое. Секреты в курсор Ignore. Это режет и индексацию, и доступ, и [музыка] тяжёлые ненужные папки в курсор индексинг, ignore. Это режет только индексацию. Автокопт типичный паттерн джина. На время локальной разработки копипасти токен прямо в тестовый скрипт

334:44

Speaker A

или ячейку IPNB тетрадки и потом удалять. Это и раньше приводило к проблемам. Токен попадал в кэш-файлы или этот тестовый скрипт случайно пушился на GitHub. А сегодня это может привести к мгновенной компрометации. Если у тебя включён автокомп - это дописывание

334:59

Speaker A

предлагаемого кода налету по кнопке Tab. Курсор шлёт окружающий код вместе с твоим токеном, как есть на сервер, на каждое изменение файла, чтобы предложить продолжение. И при этом неважно, использовал это Tab или нет. Работа в курсор со сторонними расширениями:код,

335:14

Speaker A

кодекс и прочими. Сторонние агенты не знают про курсор ИгNно. Эта фича распространяется только на нативные агенты курсоor. Если запустить внутри него расширение кодекса или код-код, их курсор игнорар чтения не остановит, так как у каждого инструмента свои правила доступа. Более того, у каждого из этих

335:32

Speaker A

расширений свой неочевидный способ запретить чтение дотфайлов. Разберём их в домашнем задании. Справа на скрине можно заметить, что даже нативному агентурсор при этом ничего не мешает запросить сделать команду CATF, которая при твоём одобрении отправить всё содержимое файла прямиком на

335:47

Speaker A

серверкурсор или даже без одобрения, если ты раздал автопруfв, чтобы агент работал над задачами быстрее. При этом оба файла и демотест, и EN лежат в курсор ключевые инсайты. Риски отдавать внешний lm чувствительные данные перевешивают плюсы от возможной экономии твоего времени. Когда даёшь агенту

336:06

Speaker A

контекст, задай себе вопрос: будет ли проблема, если передаваемая информация утечёт наружу или попадёт в обучающую выборку? Если нужно поработать с конфиденциальными данными, вычести их внутренней моделькой, если такая есть, собственным скриптом или руками.

336:21

Speaker A

Ограничь агенту доступ к секретам ENF и прочим и используй аналоги курсор ИгNнор. А самое критичное- вообще держи вне рабочего воркспейса и не давай и агенту прав выходить за рамки текущего рабочего пространства. Аккуратно и вдумчиво настрой разрешение на команды

336:37

Speaker A

всем агентам, с которыми работаешь, и со временем дополняй этот список. Выключи всё, что молча шлёт данные наружу.

336:43

Speaker A

Включи Privacy Mode. Отключи телеметрию и использование твоего кода для улучшения продукта. Четвёртый сценарий - одноразовая задача.

336:56

Speaker A

Разберём такую ситуацию. Прилетела нестандартная срочная задача. Аналитик заболел, и разрабы с базовыми знаниями SQL нужно самому сделать. нетривиальную выгрузку из БД. У тебя нет готового паттерна у модели нужных для этой задачи инструментов. Есть два пути. Первый сесть и потратить рабочий день на то,

337:13

Speaker A

чтобы разобраться, возможно, даже с помощью EИ и самому сделать запрос по аналогии с другими выгрузками из старых задач, а потом попросить кого-нибудь из коллег поревью твой результат. И второй-учить агента решать эту задачу с нуля. Второе выглядит проще, ещё и

337:29

Speaker A

привлекает своей возможностью сэкономить пару-тройку часов работы. Пусть и сядет и за пару минут во всём разберётся. И это правда. Ии вполне может справляться с подобными задачками. Но [музыка] чтобы обучить агента выполнять такую задачу, может потребоваться немало усилий.

337:43

Speaker A

Перечислим что вероятно потребуется сделать во втором случае. раздобыть удобочитаемый для агента формат документации, собрать ему весь необходимый контекст для решения задачи, собрать описание столбцов СБД, информацию о типах и возможных значениях данных, по каким ключам витрины связаны друг с другом и прочее. Убедиться, что

338:02

Speaker A

там нет чувствительных данных или замаскировать их, написать точный, понятный промт, сделать несколько итераций правок в сгенерированный результат, провалидировать итог и сверить контрольные цифры. Все эти действия имели бы смысл и были бы полезны только для аналитика, который каждый день потом будет сталкиваться с

338:20

Speaker A

этой задачей. И даже он начнёт экономить время на решение подобных задач только на пятый-шестой раз после нескольких итераций отлаживания этих инструментов.

338:29

Speaker A

Так, решение непривычной частной задачи плавно перетекает в прототип решения этой задачи в общем случае, что в разы сложнее и трудозатратнее. В итоге расходы на сетап тут просто не окупаются. И держи в голове совсем простую вещь. и может просто не

338:45

Speaker A

справиться. Мы уже видели введении, как уверенно он генерирует багованный SQL-код. Или, по крайней мере, твоё терпение может закончиться сильно раньше. Одна итерация, вторая, третья, а рабочего результата всё нет. В какой-то момент ты бросаешь эту затею и идёшь делать задачу сам. Но время на возню

339:03

Speaker A

автоматизации уже потрачено. Итог неприятный. Ты потратил то же самое время и сверху ещё проводился с автоматизацией заведомо одноразовые задачки. Ключевые инсайты. После нескольких неудачных итераций правок остановись и порефлексируй. Тот ли подход ты используешь? Оправданы ли усилия, которые ты вкладываешь в эту

339:22

Speaker A

изацию? Если нет, смени подход или просто сделай задачу своими руками. Не продолжай только потому, что уже потратил время. Считай не прошлые затраты, а сколько ещё придётся вложить для достижения цели. Вкладываться в сетап стоит только, если задача будет повторяться и на выходе останется

339:39

Speaker A

переиспользуемый артефакт. шаблон промпта, скил, правила и так далее. Между двумя крайностями сделать всё руками и не написать руками ни строчки есть огромный спектр возможностей. В данном кейсе было бы эффективно использовать Ии, чтобы лучше разобраться в SQL-синтаксисе, для понимания логики

339:56

Speaker A

других запросов или для валидации написанного обойкода на предмет багов и возможных проблем. И последний сценарий - автономное выполнение задач. Этот кейс немного выделяется из общей канвы, потому что без ИИ автономно сделать совсем ничего не получится. И мы тут выбираем не

340:17

Speaker A

использовать лиИ, а где грань в уровне свободы, который мы для него устанавливаем. Но этот сценарий настолько одновременно прогрессивен и опасен, что я решил разобрать его здесь.

340:28

Speaker A

В какой-то момент лайпкодинг превращается в рутину. Ты знаешь, что делать, выполнял с помощью агентов много похожих друг на друга задач. А разработка состоит из написания небольшого числа промтов, между которыми ты просто жмёшь Enter, чтобы разрешить агенту очередную правку или команду в

340:43

Speaker A

консоли. И закономерно тебя посещает мысль, зачем в этом процессе ты? Агенту можно дать конечную цель, несколько строгих правил, которые обязательно нужно соблюдать в процессе, обложить свой проект тестами, а на весь новый функционал обязать агента писать новые тесты специально под него. И пусть с

341:00

Speaker A

автопрувом сидит, реализовывает очередную фичу. В общем, хочется простого человеческого отойти за кофе, вернуться и прислать коллегам на ревью готовый пиар. И это мощная, но при этом крайне разрушительная идея. Важно чётко осознавать разницу в случае, когда за агентом осуществляется тщательный

341:18

Speaker A

контроль и в случае, когда он предоставлен сам себе. Эти траектории просто разительно отличаются. Наблюдать за агентом и направлять его необходимо по множеству причин. Например, в цепочке выше гарантирована поломка на каждом из этапов. дал агенту конечную цель, у него

341:33

Speaker A

в процессе выполнения несколько разбьётся контекст, и твоя цель исказится до неузнаваемости. Выдал [музыка] агенту строгие правила, и обязательно капсом, очевидно, он рано или поздно их проигнорирует. Обложил свой проект тестами. Агент с ловит красный тест, решит, что функционал-то новый, а значит, старые тесты не

341:50

Speaker A

годятся, и перепишет сам тест на зелёный. обязал агента писать тесты под весь новый функционал. Агент вместо того, чтобы честно решить задачу, захардкодит какой-нибудь частный случай и пойдёт дальше. Это всё звучит не так страшно. Ну, допустит агент несколько ошибок. Всегда есть кодрев, да и ошибки

342:07

Speaker A

можно исправить самому. Это зачастую проще, чем писать код с нуля. Поэтому разберём пару команд, которые агент на практике легко может захотеть исполнить и которые демонстрируют реальные угрозы автономии в первом случае. И решает, что нужно поставить новый пакет. И команда

342:22

Speaker A

выглядит как обычная установка с какого-то деф-сайта. На деле выкачка произвольного скрипта с чужого сервера и последующее исполнение с твоими правами.

342:30

Speaker A

Во втором случае он решил выполнить какую-то случайную башкоманду. На глаз не определить, что она делает. Ясно ли, что последствия непредсказуемы. Обычно внутри таких закодированных строк вредоносный скрипт. В данном случае это была команда, которая читает твой приватный SSH-ключ и через курл

342:45

Speaker A

отправляет его на сервер атакующего. Оба примера попадают к агенту одним и тем же путём. Их массово впрыскивают через prompt injection, публикуют и предлагают выполнить в комментариях на форумах вышю на гитхабе в Redmi, на веб-страницах, которые агент читает по ходу выполнения

343:00

Speaker A

задачи, и так далее. Подвох в том, что EИ допускает ошибки, о чём явно написано на любом сайте, предоставляющем ИИ продукты, а мошенники постоянно придумывают новые способы продать агенту идею выполнить на вид безобидную команду, которая решит его задачу. И чем

343:16

Speaker A

сильнее забит контекст, тем выше шанс, что агент исполнит её. Замечу также, что Prompt Injection - это нерешённая на сегодняшний день проблема, и панацея от этой атаки пока не существует. Так что вывод простой. Никакой автономии без выверенной безопасниками архитектуры. В

343:32

Speaker A

больших компаниях любая агентская автономия обязательно контролируема и представляет собой отдельный одобренный ИБ-продукт с жёсткими, предсказуемыми ограничениями, тонко настроенными правами доступа. В заключение приведу несколько релевантных инцидентов. Первый произошёл с Pocket OS в двадцать шестом году. Это СААС, который развернули на

343:51

Speaker A

хостинг платформе Railway. Разработчик пустил агента в курсор на Cloud Opus 4.6 в рабочее окружение. Агент наткнулся на рассинхрон доступов и вместо того, чтобы остановиться, решил починить сам, снести том с базой и пересоздать его с нуля.

344:06

Speaker A

Дальше в одном из файлов окружения нашёл токен от сервера с полным доступом и через IP платформы скомандовал удалить диск с базой без всякого подтверждения.

344:14

Speaker A

За 9 секунд протбаза была удалена вместе со всеми бэкапами. Railwayй хранил их на том же диске. Это повлекло около 30 часов простоя. Это не взлом и не инъекция. Агент просто двигался к поставленной цели, используя все предоставленные ему возможности. Второй

344:29

Speaker A

случай с RLТ в двадцать пятом году. На этот раз у разработчиков были настроены с десяток правил в духе: "Ни в коем случае не трогай прот" и явные предупреждение о фриз периоде, то есть, что сегодня ничего нельзя менять в

344:42

Speaker A

работе продукта. Агент Rплет во время работы забил на эти правила, полез в прот и удалил боевую базу данных компании. И MCP. MCP - это стандарт подключения к агенту внешних инструментов и сервисов или плагинов.

344:55

Speaker A

Сначала нашли первый реальный вредоносный плагин. С виду обычный пакет в тихую слал злоумышленнику скрытую копию всех исходящих писем юзера. Тысячи писем в день у сотен компаний. И штатная защита почты этого не замечала. Позже выяснилось, что это не случайность, а

345:09

Speaker A

следствие устройства самого протокола. Механизм запуска устроен так, что одного вредоносного плагина достаточно, чтобы запустить на машине любой код.

345:17

Speaker A

Разработчики Anтроopic назвали это ожидаемым поведением и сказали, что валидация должна происходить на стороне разработчика MCP-сервера. Это хороший пример необходимости ручного опрова. Без него агент может поставить себе сомнительный плагин самостоятельно для решения какой-нибудь сложной задачи, не заметить странности в работе уже

345:34

Speaker A

имеющихся или просто сделать что-нибудь непоправимое. MCP всё же мощная штука. Ключевые инсайты. Никаких внешних shшел команд без явной проверки глазами.

345:44

Speaker A

Особенно Кул, Баш, EVAL, Base 64 и подобные. Прочитай команду до того, как нажмёшь Enter. Обычного агента очень просто не нароком превратить в автономного без всяких дополнительных знаний. Жмёшь edit automatically или run everything, и твой автономный безумец готов причинять добро и наносить пользу.

346:03

Speaker A

Следи за этим. Для деструктивных операций RM, drop, delete, force push. Настрой обязательное ручное подтверждение. Агент не должен делать такое без твоего явного опрова. Как это сделать в разных интерфейсах, разберём в домашнем задании. Разведи и прот окружение. Выключи авторуф и ограничь

346:22

Speaker A

набор инструментов агента ровно теми, которые нужны для конкретной задачи. И если хочешь глубже разобраться в теме безопасности агентов, почитай OASP топ-1 forentic Applications. Там [музыка] подробно разобраны основные угрозы.

346:39

Speaker A

Домашнее задание. Задание первое. Делегируем с умом. Ниже список из одиннадцати рабочих ситуаций. Для каждой реши делегировать агенту целиком.

346:49

Speaker A

делегировать агенту и проверить или сделать самому. И аргументируй, почему. Первое: написать юнит-тесты на хорошо знакомый тебе модуль. Вторая- проанализировать выгрузку клиентах обращений, в которой есть имеil-адреса, чтобы к вечеру выделить частые темы жалоб. Третье. Разобраться в LEAC коде на 400 строк перед рефакторингом. Автор

347:10

Speaker A

давно уволился. Четвёртое. Переписать Python Scriptри на 300 строк на Typeescript. Есть тесты на выходные и выходные данные. Ты не знаешь Typeesриpt. Пятое. Накатить на продмиграцию, удаляющую одну и ту же колонку из десяти таблиц. Работа механическая и однообразная. Шестая.

347:28

Speaker A

Модуль полностью покрыт тестами. Он стал тормозить, и нужно переписать внутреннюю логику на более быструю, снаружи ничего не меняя. Седьмое. [музыка] Написать логику авторизации для нового микросервиса. Кто имеет доступ, кто нет.

347:41

Speaker A

Восьмая. Написать одноразовую SQL-выгрузку для пима. Нужна сегодня, повторяться не будет. Девятое. Баг воспроизводится через раз. Нужно проверить несколько конкурирующих гипотез, почему так происходит. И ты уже начал копать самую вероятную. Десятое.

347:57

Speaker A

Найти причину ОМ Краша в незнакомом сервисе. Есть трейс и метрики. И одиннадцатое. Многошаговая агентная задача на несколько часов. Хочется запустить и уйти. Задание второе. Ловим галлюцинации. Сперва попробуй воспроизвести какой-нибудь из примеров галлюцинации, которые я приводил. Потом попробуй заставить соврать lлэмку. Либо

348:19

Speaker A

чар JPT 5,4 и выше, либо ClД 4,5 и выше, или Гини 3,1 или выше, то есть умную самостоятельно, желательно даже в своей профессиональной области. Это отличное упражнение на доверие или недоверие, которое, скорее всего, покажет, что LLM сегодня достаточно трудно обмануть. И,

348:39

Speaker A

наконец, время от времени в работе приходится сталкиваться с ситуацией, когда локальное окружение сломано или настроено сразу несколькими конкурирующими способами или не настроено вовсе. А по самому коду версию библиотеки однозначно не определить.

348:53

Speaker A

Имеющиеся куски нейтральны и годятся под несколько версий. Попробуем воспроизвести эту ситуацию и понаблюдать, как себя будет вести модель в таком случае. Воспроизведи такую ситуацию на удобном тебе языке и попроси модель дописать отдельный новый модуль на этой библиотеке. Зафиксируй, пошла ли

349:10

Speaker A

она проверять, что реально установлено, какие версии пакетов она выбрала для написания кода. Потом запусти, проверь, насколько этот код оказался работоспособен. Цель - поймать lm на том, что при неполной информации она сама решает, что и как делать.

349:23

Speaker A

По-хорошему, она должна сперва разобраться, какое окружение на деф или протстенде, для которого мы пишем код.

349:29

Speaker A

Но в реальности так почти не происходит. И третье задание. Настраиваем родительский контроль. Возьми свой рабочий стек, курсор, VS-код, клодкод.

349:38

Speaker A

кодекс, в общем, всё, что используешь. Пройдись по чек-листу ниже для каждого инструмента или ID и настрой его.

349:45

Speaker A

Первое. Убери телеметрию. Настрой ID и расширение так, чтобы они не слали наружу usage-аналитику, кэш-репорты и твои действия в редакторе. Второе: отключи передачу твоего кода и промтов в обучение моделей. Третье: закрой секреты от агента точкан N в приватные ключи

350:03

Speaker A

тоpm.Sс и так далее. недоступны агента ни для чтения, ни для индексации, эмбедингов и прочего. Проверка. Попроси агента прочитать [музыка] Fфаile или выполнить CT EN. Он отказывает или запрашивает опруф, а не читает молча. Четвёртое.

350:20

Speaker A

Явно проставь ручной опруф на потенциально опасные команды. Проверка. Заставь агента сделать обе команды из последнего сценария, которые Скурл и Баш были вредоносные. Если будет отказываться, убеди или подмени на аналогичные, нейтральные. Проверь, что для каждой команды среда запросила у

350:40

Speaker A

тебя подтверждение на выполнение. Пятое. Ограничь скоупагента. Доступ к файловой системе в пределах рабочего воркспейса.

350:47

Speaker A

Сеть по умолчанию выключена. Набор инструментов только нужный под задачу. И проверка попроси агента прочитать что-нибудь из downloads. Проверь, что у него не получится без допразрешения.

350:58

Speaker A

Шестое. Настрой правила rules для более контролируемого поведения. Например, зашеему правила никогда ни при каких обстоятельствах не читать и не принтить никакие токены, детальнее, чем несколько первых символов. Создай подобные правила в зависимости от того, какие нежелаемые сценарии обычно воспроизводит твой

351:16

Speaker A

агент. Седьмое. Убедись, что в твоих рабочих проектах агент не дотянется до чувствительных данных. Продоступы, мастер ключи и тому подобное не лежат в папке, которую открывает IDE или агент.

351:28

Speaker A

Плюс ко всем используемым агентским IT применены настройки выше. И проверка. Придумай потенциально деструктивный сценарий и понаблюдай, как агент будет себя вести. Разбор всех трёх заданий и эталонные настройки по каждому инструменту будут ждать тебя на бусте.

Topics: нейросети ИИ для разработчиков промпт-инженерия ChatGPT Cursor AI-агенты тестирование с ИИ Claude программирование автоматизация

Учить по этому видео

Карточки по этому видео Тест по этому видео Кроссворд по этому видео Филворд по этому видео Шпаргалка по этому видео

Бесплатно, составлено ИИ по этой расшифровке. Без регистрации.

Get More with the SozAI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries and speaker detection. 30 minutes free.

App Store Google Play

Or transcribe another YouTube video here →

Free tools: TXT to SRT · SRT Validator · Merge SRT · Subtitle to Text · All tools