Стать программистом в 2026 легче чем когда либо! ChatGPT, Claude и Cursor не заменяют программистов, а делают их жизнь легче. В этом видео рассказываю всю необходимую базу, чтобы начать программировать с нейронками.
*https://www.youtube.com/watch?v=dO6PL5ZYMcQ
пересказ видео
Разница между вайб-кодером и вайб-инженером
- Вайб-кодинг — это случайный подход, где задачи решаются с помощью одного промта.
- Вайб-инжиниринг — это системный подход, где задачи декомпозируются и решаются с помощью атомарных итераций.
- Вайб-кодеры опираются на глазомер, вайб-инженеры — на тесты и линтеры.
Что такое LLM
- LLM — это большая языковая модель, обученная на огромном массиве текста.
- LLM генерирует текст, используя таблицу с весами слов.
- LLM не понимает буквы, а видит токены.
Что такое токены
- Токены — это смысловые единицы внутри текста.
- Токены могут быть не только словами, но и частями слов.
- Токены используются как валюта при работе с LLM.
Что такое контекст
- Контекст — это история взаимодействия с LLM.
- LLM не помнит предыдущий контекст, поэтому каждый запрос должен включать предыдущий контекст.
- Много контекста может привести к ошибкам и увеличению стоимости.
Пример хорошего контекста
- Хороший контекст должен содержать роль, контекст, задачу и определения успеха.
- Это помогает модели понять, какого поведения от неё ожидают.
- Недостаток контекста может привести к общему и дефолтному результату.
Описание задачи и контекст
- Важно чётко определить цель и задачи для модели.
- Системная инструкция часто включает роль, что позволяет её игнорировать в промтах.
- Хороший контекст включает описание цели, стека технологий, ограничений, дизайна и входных данных.
Tools и их роль
- Tools помогают модели выполнять задачи, которые она не может решить самостоятельно.
- Они представляют собой код, который модель может вызывать для получения нужной информации.
- Примеры использования: получение данных из базы, выполнение команд в терминале, запросы к серверам.
MCP и его преимущества
- MCP (Model Protocol) — это API, содержащий набор инструментов.
- MCP сервер предоставляет модели список доступных инструментов.
- Использование MCP позволяет экономить контекст и улучшать выполнение задач.
Проблемы и решения с MCP
- Большое количество MCP может создавать шум в контексте.
- Для решения этой проблемы используются скилы — маленькие Markdown файлы с инструкциями для модели.
Инструменты для программистов
- Инструменты можно разделить на CLI, IDE и плагины.
- Плагины встраиваются в существующие редакторы кода и делают их умнее.
- Примеры плагинов: GitHub Copilot, AmazonQ Developer, Clean, Killcode.
Редакторы кода с LLM
- IDE с агентами предлагают новый инструмент с интеграцией LLM.
- Примеры редакторов кода с LLM: Cursor, китайские редакторы, Kira.
Инструменты для работы с LLM
- Большинство инструментов переделывают VS-код до неузнаваемости.
- Введены возможности скрывать код и общаться с нейросетью в формате чата.
- Консольные LLM агенты позволяют общаться с нейросетями через терминал.
Выбор инструментов
- Рекомендуется иметь по одному инструменту из каждой категории.
- Инструменты имеют бесплатные тарифные планы, что позволяет экономить деньги.
Использование Git
- Git помогает сохранять версии кода и откатываться к рабочим прототипам.
- Частые комиты обеспечивают больше точек сохранения и упрощают просмотр кода.
- Ветви и рабочие деревья позволяют работать над несколькими задачами одновременно без конфликтов.
Важность проверки кода
- Нельзя доверять нейросети полностью, необходимо проверять сгенерированный код.
- Обсуждение кода с нейросетью помогает понять его и принять решение о его использовании.
Фреймворк работы с LLM
- Планирование, декомпозиция, делегирование и проверка — ключевые этапы работы с LLM.
- Автор планирует выпустить видео с подробным описанием фреймворка.
В этом видео
Эпизоды
Расшифровка видео
Что нужно чтобы стать программистом в 2026?
0:00
Если ты до сих пор копируешь код в
0:01
чатбота и веришь, что можно одним
0:03
промтом за вечер собрать клон Нетфликса,
0:05
то присаживайся поудобнее. Сейчас я
0:08
простыми словами разложу всю базу. Что
0:10
такое токены и контекст? Что за
0:12
магическая MCP? Чем отличается агентский
0:15
плагин от редактора кода и CLI? Почему
0:18
гит твой лучший друг? И как, наконец,
0:20
эволюционировать из viб-кодера в VIPй-
В чем разница между вайб-кодером и вайб-инженером
0:23
инженера? И для начала было бы неплохо
0:25
понять вообще, в чём разница между
0:27
вай-кодером и VIPй-нженером. И здесь
0:29
есть отличная метафора, которую я люблю
0:31
приводить в пример. Представьте, что
0:33
кодинг — это такая игра в однорукого
0:35
бандита, где вы дёргаете эту ручку, как
0:38
бы нажимаете на кнопочку и ждёте, что у
0:40
вас что-то там получится. [музыка]
0:42
Надейтесь на судьбу. Vйbe инжиниринг же,
0:45
с другой стороны — это когда мы строим
0:47
целую систему вокруг LLM, вокруг наших
0:50
нейронок. Ключевое отличие между ними —
0:52
это то, что вайп-кодинг — это больше про
0:53
случайность, тогда как инженеры
0:55
стремятся к повторяемости. в тех местах,
0:57
где viпкоodдер будет писать из prive
0:59
please или, «Пожалуйста, без ошибок»,
1:01
Vipнеer будет опираться на чёткие
1:03
definition of. По факту это список
1:04
критериев, по которым мы, люди, ну и,
1:07
собственно, lm будет понимать, что
1:08
задача действительно решена. Кроме того,
1:10
обычно вайп-кодеры пытаются ваншотнуть,
1:13
то есть с одного промта сделать сразу
1:15
всё. При этом вайп-инженеры всё-таки
1:17
декомпозируют задачу и пытаются решить
1:20
её с помощью атомарных итераций. Ну и
1:22
самое главное — это то, что вайпкодеры
1:23
опираются на свой глазомер. То есть
1:25
после того, как они пообщались с чатом,
1:27
они идут и прокликивают свой Happy Pass,
1:29
то есть только так, как они задумали.
1:32
При этом же Vipe-инженеры опираются на
1:34
те инструменты, которыми мы и так
1:36
пользовались до появления LLM. Это
1:38
разные тесты и линтеры. То есть, ещё
1:40
раз, вайPe-кодинг — это больше про
1:42
случайность и рулетку, а вайpнжиниринг —
1:44
это больше про систему и управление. Но
Что такое LLM
1:46
чтобы чем-то управлять, нужно понимать,
1:49
чем ты управляешь. И здесь мы переходим
1:51
к трём столбам Vйbнжиниринга. Это LLM,
1:55
токены и контекст. И начнём с ядра всей
1:57
этой системы, собственно, с LLM или
2:01
Large Language Model. Большая языковая
2:03
модель. Это такой тип нейросети, который
2:05
натренировали на огромном массиве
2:08
текста, на огромном массиве данных и
2:10
которая теперь может этот текст
2:12
генерировать. И очень важно понять, как
2:14
именно происходит генерация этого
2:16
текста. По сути, LLM — это такой Т9 на
2:18
стероидах. У неё, у модели, есть
2:20
огромная такая таблица, ну, типа
2:22
Excelтаблица, в которой расположены
2:25
разные слова и есть веса. То есть какое
2:27
слово после какого с какой вероятностью
2:30
идёт. И таким образом, когда модель
2:32
видит фразу London is the capital, то с
2:35
большей вероятностью эта фраза должна
2:37
закончиться of grade Britton, чем,
2:39
например, какой-нибудь the table. Ну
2:41
или, например, если будет написано
2:43
где-то дважды два, то мы, люди,
2:46
автоматически продолжим. Хороший был
2:47
когда-то канал. Но моделька продолжит
2:50
его равночеты, потому что такое
2:53
расположение символов очень часто
2:56
встречается в тех данных, на которых
2:58
обучалась модель. Здесь очень важно
Что такое токены
3:01
понимать вот такой нюанс. LM не понимает
3:04
буквы, она видит токены. И на экране вы
3:07
можете увидеть, что такое примерно
3:10
токены. Токены — это смысловые единицы
3:13
внутри нашего текста. Это не обязательно
3:15
целые слова. Например, вот эта фраза LLM
3:17
не понимает буквы, она видит токены, как
3:20
видите, не совсем по словам разбито.
3:23
Само слово, точнее акроним LLM — это уже
3:26
два токена. Для того, чтобы чуть лучше
3:28
понимать, как же LLM воспринимает наш
3:31
текст, есть разного рода такинайзеры,
3:33
сайты такинайзера, например, от Open AI,
3:35
где мы можем ввести какой-то текст, ну,
3:37
например, подпишись и поставь лайк. И
3:41
увидеть, сколько токенов у нас занимает
3:43
эта фраза. Например, эта заняла у нас
3:45
целых девять токенов, хотя по факту у
3:47
нас всего четыре слова. Токены — это не
3:49
только то, как модель видит текст,
3:51
который она воспринимает, но также это и
3:53
валюта. Когда мы используем модель, мы
3:56
платим как за входящие токены, которые
3:59
мы передали модели, так и за исходящие,
4:01
которые она сгенерировала. Обычно
4:03
входящие токены стоят дешевле, чем
4:05
исходящие. и нам это на руку, потому что
4:08
мы, как инженеры, будем много токенов
4:10
передавать на вход, потому что нам нужно
4:13
строить тот самый контекст. Когда мы
Что такое контекст
4:15
взаимодействуем с лэмкой, мы пишем ей
4:18
свой запрос, который улетает на сервер.
4:21
Собственно, lm пасит его на токены,
4:23
понимает, какие токены нужно
4:24
сгенерировать, и в ответ даёт нам ответ.
4:27
После этого мы прочитали ответ и пишем
4:30
дополнительный запрос. И вот здесь есть
4:33
небольшой нюанс. Мы как люди, общаясь с
4:36
другими людьми, привыкли, что у нас вся
4:38
коммуникация происходит в формате
4:39
запрос-ответ. Запрос-ответ. Даже веб в
4:42
целом построен именно на этом формате.
4:44
Прикол в том, что LLM, сама моделька,
4:46
она не помнит предыдущий контекст. Для
4:48
неё каждый запрос — это новый диалог.
4:51
Поэтому, когда вы пишете второй ваш
4:53
запрос, вместе с ним вы также
4:55
отправляете ваш первый запрос и ответ
4:57
LLM для того, чтобы ваш диалог
4:59
продолжился. Обычно, правда, перед этим,
5:02
на самом деле, существует ещё один
5:04
запрос, скрытый, который называется
5:06
системный промт. Там прописывается
5:08
поведение модели, описывается, для чего
5:10
она нужна, что именно должна делать и
5:12
так далее. Без этого системного промта
5:14
модель будет очень сильнориic, то есть
5:16
как бы очень сильно обо всём и про всё.
5:19
И вот вы отправили ещё один запрос,
5:21
получили ещё один ответ и дальше
5:23
продолжаете диалог со своей моделькой.
5:25
Через определённое время ваш контекст
5:28
становится просто огромным. неимоверно
5:31
огромным. И какие здесь могут быть
5:34
минусы? Ну, во-первых, это становится
5:36
сильно дороже, потому что модели
5:38
всё-таки приходится обрабатывать весь
5:39
контекст, и чем дольше вы с ней
5:41
общаетесь, тем больше тот самый контекст
5:44
становится, тем дороже для вас это
5:45
становится. Благо, конечно, компании
5:47
изобрели такую штуку, как кэшированные
5:50
токены. То есть все те данные, которые
5:52
были до, если они не изменились, то они
5:54
будут вытаскиваться из кэша и будут
5:55
стоить чуть-чуть дешевле, но всё равно
5:58
будут чего-то стоить. Но самая большая
5:59
опасность заключается именно в самом
6:02
контексте. Много контекста не есть
6:04
хорошо. Представим ситуацию. Вы
6:06
отправили какой-то запрос, модель вам
6:08
ответила и ответила, ну, не так, как вы
6:11
хотели бы. После этого вы просите её
6:13
что-то переделать, и она всё равно
6:15
отвечает ещё хуже. И вот здесь
6:18
критическая ошибка — это пытаться как-то
6:21
исправить модель, пытаться вывернуть из
6:23
этой ситуации. Почему это не получается?
6:25
Потому что вы находитесь всё ещё в том
6:28
же самом контексте. Ответы модели,
6:30
которые вас не устроили, каждый раз
6:33
будут также влиять на те токены, которые
6:36
будут генерироваться в новом ответе. Все
6:38
эти инструкции, типа «Забудь, что я тебе
6:40
говорил дальше, не делай так», они не
6:43
особо работают, просто потому что та
6:45
плохая, назовём её так, информация уже
6:48
находится в контексте. Ваш контекст уже
6:50
засорён. И самая выгодная ситуация в
6:53
данном случае — это попросить новым
6:56
запросам, например, сжать контекст,
6:58
какие-то указать ключевые точки, которые
7:00
вы обсуждали, и начать новый диалог с
7:04
этим уже очищенным контекстом. Часто
7:07
наблюдаю, когда в одном диалоге с ЛLM
7:09
люди обсуждают вообще всё подряд. Они
7:11
обсудили что-то по одному проекту,
7:13
спросили какие-то свои приколы по
7:15
другому проекту, про новую технологию
7:17
поузнавали, и всё это в одном окне.
7:19
Представьте, какая каша получается в
7:22
нашем контексте. И когда мы попросим
7:24
что-то сделать нужное, вероятность того,
7:27
что модель сделает то, что мы её
7:28
попросили, крайне мала. Потому что,
7:30
опять же, контекста очень много, и он
7:32
очень разнообразный. Поэтому много
7:34
контекста не всегда есть хорошо. При
Пример хорошего контекста
7:37
этом есть и другая крайность. Мало
7:39
контекста тоже плохо. Давайте посмотрим
7:42
на вот такой пример. Промпт формата
7:44
сделай сайт для моей компании. В целом,
7:46
ничего сверхкритичного здесь нет. и
7:48
неронка даже что-то сделает вам по этому
7:50
промту, но помним, что она опирается
7:53
именно на все данные, на которых она
7:55
обучалась, и у неё нет никаких
7:57
ограничений. Есть просто общая фраза:
8:00
«Сделай сайт для моей компании». В итоге
8:02
вы получите супер общий, супер дефолтный
8:06
результат. Как же в этом случае выглядел
8:07
бы хороший промт, как бы его собирал VIP
8:10
инженер? Вообще глобально есть очень
8:12
обобщённое правило, что любой пром
8:15
должен содержать в себе такие части, как
8:17
роль, контекст, задачу и definitions of
8:20
done, либо пример того, как вы хотите
8:23
видеть эту задачу выполненной. Это супер
8:25
усреднённо и работает как в чатботе, так
8:27
и в разных агентах, которые мы
8:29
используем для кодинга. Суть этого
8:31
подхода в том, чтобы мы как раз-таки
8:33
дали достаточное количество контекста
8:35
для того, чтобы мы описали модели,
8:37
какого поведения мы от неё ожидаем,
8:39
сказав ей её роль. для того, чтобы мы
8:41
дали подробный контекст, то есть типа
8:43
зачем вообще нам нужна эта задача.
8:46
Собственно, чтобы мы описали саму задачу
8:48
и чтобы мы сказали, какой результат мы
8:51
ждём. Те самые definition of done. Но
8:53
сегодня роль часто можно опускать, если
8:55
мы не общаемся в чатботе, потому что
8:57
помним из предыдущего слайда, что
9:00
существует такая штука, как системная
9:02
инструкция. Обычно там и зашита та самая
9:05
роль, поэтому мы можем её игнорировать в
9:07
наших промтах и фокусироваться на
9:09
контексте, задаче и definitions of done.
9:11
Давайте попробуем пересобрать вот этот
9:13
вот плохой пример и сделать реально
9:15
хороший контекст для нашей модельки. И
9:17
выглядело бы это примерно так. Цель
9:20
сделать лендинг для компании рога и
9:23
копыта Digital. И описываем, что именно.
9:26
Ну, например, пять секций плюс форма
9:29
заявки. Дальше мы описываем стек. Хотим,
9:31
чтобы backend был на Larovel, frontend
9:35
был на View. Ну и делоться будем на VPS
9:38
с Убунту. Обязательно нужно дать
9:40
ограничение. В нашем случае, ну,
9:42
например, без сложной админки. Укажем,
9:44
что SEO важно, потому что это же
9:46
всё-таки лендинг. Дизайн
9:48
минималистичный. Форму слать на email и
9:52
в Telegram. Текста пока рыба, потому что
9:54
маркетолог потом заменит его всё равно
9:56
на то, что ему нужно. Дальше нам
9:57
обязательно нужно дать входные данные. В
10:00
нашем случае здесь я сейчас опишу их
10:02
текстом, но большинство из них — это
10:03
обычно мы прикладываем какие-то примеры.
10:05
Ну, например, мы прикладываем наш
10:07
логотип, чтобы модель понимала вообще в
10:08
какой мы стилистике. Указываем цвета
10:11
нашего бренда, даём два-три референса
10:15
тех лендингов, которые нам нравятся, и
10:17
мы хотим, чтобы они выглядели так же. Ну
10:19
и можем дать какие-нибудь типа контакты
10:21
и дополнительную информацию, которая
10:23
должна быть на этом сайте. И в конце,
10:25
естественно, мы даём definitions of
10:27
done. Мы говорим, что нам нужен
10:29
адаптивная вёрстка, три экрана,
10:31
мобильный, планшет и компьютер.
10:34
Lighthouse больше 90. Это обозначает,
10:36
что у нас сайт грузится быстро и
10:38
подходит по всем правилам, которые нужны
10:40
Гуглу для того, чтобы он их хорошо
10:42
индексировал. Форма работает. Ну и самое
10:45
главное, в Redmi есть инструкция по
10:48
установке. Вот это пример хорошего
10:50
контекста. Я думаю, разница очевидна.
10:52
Вот плохой пример, который, ну,
10:54
буквально там пять слов и хороший
10:56
контекст, где у нас описано по максимуму
10:59
всё, что мы хотим от этого сайта. Вы
11:01
можете сами попробовать и взять прямо
11:03
эти два промта, прогнать первый,
11:04
прогнать второй, и вы увидите, насколько
11:07
результаты будут сильно-сильно
11:09
отличаться. О’кей. Теперь от контекста
Tools — это руки для LLM
11:11
мы можем плавно двигаться к следующей
11:13
теме. Это кллингу.
11:15
И если LM можно считать как бы мозгом,
11:18
то tools — это руки. Основная проблема в
11:21
том, что она не понимает, что он там
11:23
генерирует. Каждый раз нейронка пытается
11:25
угадать, какие же токены должны идти
11:28
дальше. И в некоторых задачах нам этого
11:30
достаточно, но есть задачи, когда это
11:32
просто непозволительно. Например, у вас
11:35
есть сервис, и вы хотите, чтобы чатбот
11:38
мог отвечать вашим клиентам, какие,
11:40
например, у вас есть ивенты ближайшие.
11:42
Можно пойти путём, когда мы просто берём
11:44
и список всех ивентов скармливаем
11:46
нейронки где-то там в контексте в наших
11:48
промтах. И надеемся, молимся, что она не
11:52
сгллюцинирует и выдаст информацию
11:55
правильно. Но, естественно, это не
11:56
стопроцентная вероятность, и,
11:57
согласитесь, будет грустно, когда
11:59
пользователь запросит какой-то там
12:01
следующий ивент, а Неронка ему просто
12:03
максимально наврёт. Человек воспримет
12:05
это как правду, будет надеяться, а
12:07
такого ивента не существует. Собственно,
12:08
tools призваны решать эту проблему.
12:10
Tools на практике — это буквально код.
12:13
Только мы говорим нейронки, что смотри,
12:15
у нас есть в коде вот такие функции, и
12:18
ты можешь их вызывать. Например, в
12:20
примере с ивентами мы можем описать
12:22
функцию, которая пойдёт в базу данных,
12:24
посмотрит реальные ивенты и выдаст их
12:27
обратно. А неронки мы описываем, что
12:29
смотри, у нас есть такая функция,
12:31
которая называется get events. И,
12:33
например, ей нужно передать параметрами
12:36
дату, потому что в самом коде у нас так
12:38
и написано get events, которая ожидает
12:40
дату. Нейронка же, когда поймёт, что ей
12:42
нужно достать информацию об ивентах,
12:44
посмотрит, что у неё есть такой Туolс, и
12:46
вместо того, чтобы галлюционировать, она
12:47
просто отдаст инструкцию нашему коду,
12:50
что нужно выполнить вот этот вот метод с
12:52
вот такими вот параметрами. В итоге наш
12:54
обычный тупой код исполнит, собственно,
12:57
этот метод с нужными параметрами и
12:59
отдаст нейронке уже готовый результат,
13:01
который она отдаст уже пользователю.
13:03
Поэтому на слайде я и называю Tools
13:05
руками. То есть как бы неронка думает и
13:07
говорит, что когда ей нужно что-то
13:09
вызвать, она буквально вызывает наш код.
13:12
Причём не только код. Современные агенты
13:13
могут запускать команды в терминале для
13:15
того, чтобы прочитать файл или создать
13:18
этот файл. Может сделать запрос на
13:20
какой-то сервер, используя тот же там
13:21
кул, например, из терминала. Но это я
Что такое MCP
13:24
уже глубоко технически закапываюсь.
13:26
Здесь я бы хотел остановиться на таком
13:27
магическом слове, как MCP. MCP — это
13:30
акроним от model протокол. По факту это
13:33
просто модное название для API, причём
13:36
для такого API, который внутри себя
13:39
содержит просто набор tools. Скорее
13:41
всего, вы слышали такое сочетание, как
13:43
MCP сервер. И по сути, что он делает,
13:46
это он отдаёт нашей неронке список
13:48
инструментов, которые доступны на этом
13:50
сервисе. Ну, например, представим
13:52
какой-нибудь MCP-сервис почты, и он
13:54
может сказать, что есть инструменты
13:56
отправить письмо, есть инструмент
13:58
прочитать письмо, есть инструмент
14:00
удалить письмо. И в зависимости от того,
14:02
что именно нужно сделать с нейронке, она
14:03
будет вызывать тот или иной инструмент.
14:05
И вот благодаря этим механизмам, что
14:07
Tools, что MCP, мы можем не скармливать
14:11
огромное количество контекста нейронки,
14:13
а давать ей самой загружать порционно
14:16
только тот контекст, который ей
14:17
действительно нужен для выполнения
14:19
задачи. Мы так и денежки экономим,
14:21
потому что контекст, собственно, меньше.
14:23
Ну и задача выполняется лучше, потому
14:25
что остальной ненужный контекст не
14:27
создаёт шум. Но хочу вас предупредить,
14:29
уже есть исследование, что большое
14:32
количество MCP, подключённых вредит
14:34
вашему контексту, потому что сами по
14:36
себе MCP и список инструментов, которые
14:38
есть внутри MCP, подгружаются в
14:41
системную инструкцию к каждому запросу.
14:43
Соответственно, появляется тот самый
14:45
шум, даже если он вам не нужен. Для
14:47
решения этой проблемы можно использовать
Что такое Skills
14:49
скилы. Это такие маленькие Markдаун
14:51
файлы, где мы описываем какие-то
14:54
инструкции для модельки. То есть, что
14:56
конкретно она может делать. Прелесть
14:57
скилов в том, что они не подгружаются
14:59
все разом. Модель сканирует директорию
15:01
со скилами и выбирает нужный, опять же,
15:04
в тот момент, когда ей что-то конкретно
15:06
надо. Это позволяет прямо очень сильно
15:08
очистить наш контекст, сократить его,
15:10
сэкономить, ну, и в итоге получить
15:12
лучшее поведение от модели. О’кей,
Плагины с LLM для программирования
15:14
надеюсь, с этим понятно, потому что мы
15:15
переходим к следующим инструментам.
15:17
Собственно, к тем инструментам, которыми
15:19
мы, как программисты будем пользоваться.
15:21
Их можно разделить на три категории. это
15:24
CLI, IDE и Plugins. Хоть я их и
15:26
расположил здесь в порядке плагин IDE и
15:28
CLI, и в таком порядке они у нас как бы
15:31
появлялись в инструментарии, не значит,
15:33
что это эволюция. Все три типа до сих
15:36
пор развиваются и процветают. Нужно
15:38
просто выбирать тот инструмент, который
15:40
вам удобен и который решит вашу
15:42
конкретную задачу. Например, плагин
15:44
стоит выбирать, когда ты уже привык к
15:46
какому-то своему редактору кода, не
15:49
хочешь его менять, но просто хочешь его
15:51
прокачать и сделать его немножечко
15:53
умнее. Наверное, самый популярный и один
15:55
из первых примеров таких плагинов — это
15:56
GitHub Cilot. И поначалу, когда он был,
16:00
он, ну, по факту имитировал просто чат с
16:02
нейронкой, но внутри нашего редактора
16:04
кода. Сегодня же его прокачали
16:07
настолько, что он уже прямо умеет и
16:09
файлы создавать, и редактировать, и сам
16:11
идти их искать, читать. Однозначный
16:14
лайк. При этом не только один GitHub
16:15
Cilot существует. Есть и AmazonQ
16:17
Developer, и Clean, и Killкоodд. Они
16:19
есть как платные, так и бесплатные. и их
16:22
огромный,огромный зоопарк. Но самое
16:24
главное то, что они встраиваются в ваш
16:27
редактор кода, и окружение, к которому
16:29
вы привыкли, остаётся точно таким же, в
Редакторы кода с LLM
16:32
отличие от IDE с агентами, потому что
16:35
это прямо будет, ну, совершенно новый
16:37
инструмент, и вы можете его выбирать,
16:39
если вы не боитесь просто пересесть с
16:41
того инструмента, на котором вы привыкли
16:43
работать, на что-то новое ради вот как
16:46
раз-таки вот этих агентских интеграций с
16:48
Lлm. Хотя, если вы работали и так
16:50
вскоде, то вы сможете спокойно на них
16:52
переключиться, потому что большинство
16:54
редакторов кода, которые прокачаны
16:56
нейронками, это, по сути, форки, то есть
16:59
как бы копии VS-кода, на которые сверху
17:01
накрутили дополнительного функционала.
17:03
Самый популярный, самый наделавший хайп
17:05
это, естественно, курсор, но кроме
17:07
него есть китайские, есть Kira от
17:10
Amazon, есть антигравити от Google.
17:13
Большинство из них переделывают VS-код
17:14
прямо до неузнаваемости. Например,
17:16
курсор недавно ввели возможность прямо
17:19
скрыть полностью вот это дерево кода и
17:21
сам код и общаться с нейронгой просто в
17:24
формате чата. Ну, если вы, например,
17:26
делаете кучу работы параллельно и вам,
17:28
ну, неважно видеть сам код. При этом,
17:30
если вдруг вы захотели, вы можете
17:32
переключиться обратно, увидеть это
17:33
дерево, увидеть код и работать, как
Консольные LLM агенты
17:35
привыкли. Ну и финальная категория — это
17:36
CLI, то есть консоль line интерфейс.
17:39
Буквально мы внутри консольки общаемся с
17:41
нашими нейронками. И это нужно выбирать,
17:44
во-первых, если вы уверенный
17:46
пользователь терминала и знаете, что
17:47
такое консоль, не боитесь её. Во-вторых,
17:50
если вам нужно прямо много-много
17:53
одновременно запускать агентов. Если вы
17:55
хотите запускать агентов не только
17:57
внутри вашего проекта, а вообще
17:59
где-нибудь в любом месте на своём
18:01
компьютере и так далее, их уже тоже
18:03
сегодня огромное множество. Есть кодекс
18:05
от chpt, естькод отроopic, есть OpenCД,
18:08
есть Gemini CLI от Google, есть куча
18:11
китайских CLI. Собственно, почти любой
18:13
провайдер модели имеет свою CLI Tolzu.
18:16
Как же выбрать, что именно подойдёт вам?
18:18
И я, если честно, советую иметь всё из
18:21
этого арсенала. Я имею в виду не весь
18:23
набор, что здесь написан, а хотя бы по
18:25
одному из каждой категории. Лично я
18:27
ежедневно использую кодекс CLI, точнее,
18:30
недавно они выпустили кодекс App. Это,
18:32
по сути, интерфейс для CLI, который
18:34
делает работу с ним сильно-сильно
18:36
удобнее, но суть остаётся та же. При
18:38
этом у меня на компьютере установлены и
18:41
курсор, и Try, и Open CodeД, и Cloud
18:44
CodeД, и GitHub Cilot. Кстати, GitHub
18:46
Copilot я тоже использую чуть ли не на
18:48
ежедневной основе, но его я использую,
18:50
когда мне нужно сделать что-то
18:52
небольшое, когда я просто пишу в коде
18:54
комментарий и
18:55
Капайла буквально как автодополнение
18:57
пишет мне то, что я написал там в
18:59
комментарии. Вам же советую поставить,
19:01
по крайней мере, по одному инструменту
19:03
из каждой категории, поиграться,
19:05
посмотреть, что вам удобнее, что лучше
19:07
встраивается в ваш рабочий инструмент, и
19:10
на том и остановиться. Другой плюс иметь
19:13
множество из них — это то, что всё, что
19:15
здесь описано — это так или иначе
19:17
инструмент, который использует модель
19:19
для того, чтобы генерировать вам код. А
19:22
модели стоят денег. И обычно у каждого
19:25
из этого инструмента есть подписочная
19:27
система. И если иметь их все, то это
19:29
нужно тратить огромное количество
19:31
долларов просто для того, чтобы они у
19:33
вас были все. При этом почти каждый из
19:35
них имеет какой-то бесплатный тарифный
19:37
план. Да, с лимитами, да, сильно
19:39
ограниченный, но всё же имеет. Поэтому
19:43
есть смысл иметь весь зоопарк у себя на
19:45
рабочей машине. Просто для того, чтобы,
19:48
если вы хотите поиграться с каким-то
19:49
новым проектом, хотите попробовать новую
19:51
технологию, вы берёте и на бесплатных
19:54
токенах генерируете, играетесь,
19:57
смотрите, не тратите ни свои деньги, ни
20:00
лимиты своих подписок. Другой очень
GIT — твой лучший друг
20:02
важный инструмент, которым нам нужно
20:04
пользоваться как инженером — это Git.
20:06
Если вы не знаете, что такое гит, у меня
20:08
есть ролик на канале, он отличный.
20:10
Посмотрите там. Не только объясняю, что
20:12
такое Git, но и показываю основные
20:13
команды, как с ним работать. Но для нас
20:15
гит — это прямо страховка вайба. Суть в
20:19
том, что нейронка, когда мы с ней
20:21
работаем, она генерирует много кода и
20:23
много где правит. И может случиться так,
20:26
что во время долгой какой-то сессии
20:28
нейронка может несколько раз править
20:30
один и тот же файл. И, например,
20:33
ситуация, когда вы поработали первые
20:36
полчаса и получили какой-то готовый
20:38
рабочий прототип, а потом через час у
20:41
вас всё сломалось, она вполне возможна.
20:43
Поэтому основное правило — это делать
20:45
частые комиты. Комиты — это такие точки
20:48
сохранения, где мы сохраняем конкретную
20:50
вот версию нашего кода. В чём плюс? В
20:53
том, что если мы всё сломали и нас не
20:55
устраивает результат, мы всегда можем
20:57
откатиться назад. В текущее время, когда
21:00
код в большинстве своём пишут именно
21:02
неронки, сам код перестал что-либо
21:04
стоить. Поэтому откатываться можно
21:07
вообще не боясь. Если нейронка
21:09
нагенерировала там кучу всего, что не
21:11
работает, вы просто берёте и отменяете
21:13
все эти изменения, восстанавливаетесь к
21:15
точке, когда всё работала, и пробуете
21:17
заново. При этом, если вы работаете над
21:19
несколькими задачами одновременно внутри
21:21
одного проекта, очень полезно
21:24
использовать функционалния в гиIT. Это
21:26
когда у нас создаётся такая виртуальная
21:28
копия нашего проекта, где мы что-то там
21:31
изменяем, и при этом мы никак не влияем
21:34
на основную копию, то есть на основную
21:36
версию нашего проекта. Потом, когда мы
21:38
доделали какие-то фишки в нашей ветке,
21:40
мы можем их слить в основную, а можем
21:43
просто забить и удалить эту ветку и
21:45
забыть это как страшный сон. А для тех,
21:47
кто любит прямо натравить нескольких
21:49
агентов на один и тот же репозиторий и
21:51
на одну и ту же ветку, есть такая штука,
21:53
как рабочие деревья или workктрис. Суть
21:55
в том, что если несколько агентов будут
21:56
работать внутри одной папки, велика
21:58
вероятность, что они будут просто
22:00
перетирать изменения друг друга. Worктс
22:03
призваны как раз-таки эту проблему
22:05
решить. У нас буквально создаются копии
22:08
наших папок, внутри которых агенты и
22:10
работают. А потом, когда они закончат
22:12
свою работу, эти папки просто
22:14
схлопываются, и мы получаем одну точку
22:16
правды. Но самое главное правило это
22:19
делать частые комиты, потому что чем
22:21
чаще вы комитите, тем больше точек
22:22
сохранения у вас остаётся, но и тем
22:24
меньше кода вам нужно просматривать,
Как стать вайб-инженером
22:27
потому что путь vibe инженеринга — это
22:29
планируй, декомпозируй, делегируй и
22:33
проверяй. Нам жизненно необходимо просто
22:37
читать, а что же там нейронка
22:39
сгенерировала. Никогда нельзя доверяться
22:41
просто тому, что Неронка написала: «Всё
22:43
готово, я всё сделала». Нет, это не
22:46
финальная точка. Вам нужно прочитать,
22:48
что же там получилось, понять, а
22:51
правильно ли всё написано, а нужно ли
22:53
это, то, что написано, и принять это,
22:56
потому что ответственность всё равно на
22:58
нас, на людях. Мы принимаем решение
23:01
залить этот код и пустить его дальше в
23:03
продакшн. Сразу для тех, кто скажет:
23:05
«Так, я не понимаю код, о чём мне, как
23:07
мне его проверять?» Вы тут же с
23:09
нейронкой можете его обсудить, можете
23:11
обсудить с другой нейронкой, как
23:12
раз-таки внутри чатбота. Но суть в том,
23:15
что вам нужно разобраться в том коде,
23:17
который был сгенерирован, понять, зачем
23:19
он был сгенерирован, и принять решение,
23:21
вы его пропускаете дальше или нет. Про
23:24
каждый из пунктов на этом слайде, если
23:26
честно, можно снять отдельное видео, но
23:28
я для вас постарался и собрал это всё в
23:30
одном видео, где рассказал фреймворк
23:33
работы над кодом вместе с LLM. Там я
23:36
рассказываю, как правильно планировать,
23:38
как декомпозировать, как потом
23:40
делегировать эти задачи и самое главное,
23:42
как их проверять. К сожалению, в это
23:44
видео фреймворк не поместился, но совсем
23:46
скоро он выйдет у меня на канале.
23:48
Поэтому подписывайтесь, чтобы не
23:50
пропустить это видео. Ставьте лайки,
23:52
если было вам полезно. Пишите в
23:53
комментариях, если вдруг что-то осталось
23:55
непонятное, я обязательно отвечу и
23:58
объясню. Ну и увидимся с вами совсем
24:00
скоро. Пока. Yeah.