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

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

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

И на этом уроке вы поймёте, как давать ИИ задачи так, чтобы он писал код точнее. Почему большой контекст не всегда помогает и часто сжигает токены? Какие документы нужны, чтобы ИИ не переписывал весь проект каждый раз? Как разделять проект на маленькие контексты, задачи, спринты, документы? Как работать с существующим проектом через контекст d change request, legacy warning? И как этот подход используется в реальной AI Driven разработке? Как поработать со мной, если у вас вдруг появилось желание, чтобы я вам это рассказал как-то там более индивидуально в процессе совместной какой-то работы.

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

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

Меня зовут Миша, мне 40 лет и 26. Да, звучит странно, но вот прямо буквально из них я в программировании, и я большую часть жизни, можно сказать, уделил этому ремеслу. Я сейчас работаю принципом впуста к инженером. Я буквально с любым форентендом, бэкэндом, практически с любым языком программирования могу работать и работал. Я занимаюсь инфраструктурой на текущем проекте, немножко архитектурой занимаюсь. И я был этим лидом нескольких команд за свою карьеру. Сейчас я зарабатываю много денег. И если говорить, например, про менторство, то уже было два потока. Я помог более 100 студентам внедрить ИИ в работу на инженерном уровне и понять архитектуру. Это помогло. Вот смотрите, вот ошибка. Архитектуру. Архитектуру. Это помогло ученикам получать новые оферы и вырасти внутри компании.

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

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

И давайте начнём, собственно, с полезной части прежде всего и немного контекста добавить сюда. Сегодня у нас июль или сейчас июль 2026, конкретно даже девятого сегодня. И разработка очень сильно поменялась. Если раньше разработчик писал код руками, буквально совсем недавно, ещё 4 года назад условно, или там даже три, и, э-э, как бы это было его основной ценностью, то сегодня сильный, ценный разработчик — он управляет искусственным интеллектом, он знает, как настроить контекст, как работает архитектура, и он отвечает за качество результата. И выигрывают не те, кто просто пользуется LLM, да, потому что даже те, кто до сих пор особо LLM не любит, так или иначе ими где-то пользуются. Он даже Сторвальс сделал первый пулреквест с помощью нейрокода, да, с помощью вайп-кодинга сделанный. А выигрывают те, кто встроил процесс, встроил искусственный интеллект в процесс, в инженерный процесс разработки программного обеспечения. Произошёл такой своеобразный сдвиг рынка. Если раньше достаточно было хорошо знать свой стек, то сегодня этого абсолютно мало. Рынку нужны другие инженеры, да, мы вообще не говорим о программистах, которые умеют работать с искусственным интеллектом, понимают архитектуру, видят продукт целиком, потому что надо смотреть не только с инженерной точки зрения, могут работать в команде, потому что всё-таки разработка программного обеспечения — это всё ещё пока командная работа, и могут автоматизировать часть разработки, потому что сегодня есть инструменты, чтобы делать разработку быстрее. И, естественно, хорошие разработчики должны уметь этим пользоваться.

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

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

И принцип сегодняшнего урока — это то, что искусственному интеллекту не нужен весь проект для того, чтобы сделать всё правильно, да? Потому что первая идея — это как бы: «Сейчас я туда всю информацию закину, весь проект пускай он меня прочитает и красиво сделает, как в проекте». Нет, надо правильный контекст выделять под конкретную задачу. И спецификация проекта, она нужна не для красоты. Она нужна, чтобы искусственный интеллект понимал, что делать, где делать, как делать, что нельзя трогать, какие ограничения учитывать, какой результат считать правильным. И чем точнее контекст, тем меньше токенов уходит на лишние попытки.

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

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

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

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

Начнём с того, надо всегда создать ясность или принять во внимание или учесть или понять, что мы, собственно, будем делать. Перед тем, как дать какую-то задачу, нам надо разобраться, что мы делаем, для кого или для чего эта функция. Потому что, если мы пишем условный endpoint какой-то или даже функцию, она где-то должна кем-то и зачем-то вызываться. Какой результат нам надо получить? Какие ограничения у нас есть? Да, это могут быть абсолютно разные, например, архитектурные ограничения. Какой стек используется, потому что всегда нужен конкретный стек, мы ещё об этом поговорим. Какой уровень качества нужен, это тоже важно, потому что мы можем буквально разрешать создавать технический долг. И что, естественно, нельзя трогать, потому что ИИ может захотеть начать править где-то. Она там будет какой-нибудь файл сканировать по непонятной причине, увидит что-то, что ей не понравится, такая: «И вот здесь давай улучшим тоже». Нет, нам надо, чтобы ИИ решил задачу так, как она определена, а сам он этого делать, к сожалению, не может.

И ошибка, когда вы работаете с ИИ — это хотеть сделать быстро фичу, да? Это вот простой запрос. Да, вы поняли, что вам надо, и вы такие: «Сделай мне красиво, сделай мне endpoint». И надеяться, что всё будет работать. Да. Так может работать с маленькими задачами на маленьких проектах, но в реальном проекте и в большом, серьёзном, особенно в Enterprise, быстрый промт часто создаёт проблемы: не те файлы, не тот стиль, поломанная архитектура или неправильная или новая, не учитывается какая-то существующая логика, потому что мы не сообщили. И создаётся технический долг. Повторюсь, он и всё равно создаётся, даже без разрешения, но мы можем ему разрешить и сказать, что с этим делать. Так вот, мы должны его фиксировать. И в итоге быстрое решение превращается в какую-то переделку и как бы то, что нам надо будет вносить много исправлений, когда наши коллеги, например, посмотрят код-ревью.

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

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

И вы обязательно фиксируете стек. Причём стек вы фиксируете вместе с версиями. Плохо писать, например, что у вас просто Python и FastAPI. Можно написать там конкретно Python 3.13 и там FastAPI, не знаю, 2.1. Или у вас Node.js, не просто Node.js React, а у вас Node.js 20, хотя он там скоро истекает, но там условно Node.js 22 и какой-нибудь девятнадцатый React. Потому что, как я уже сказал, ИИ может использовать устаревшие знания, и точные версии снижают риск несовместимости, уязвимости и случайных решений.

А затем вы, конечно же, фиксируете архитектуру. В каких файлах что должно лежать, я вам ещё расскажу, но затем вы фиксируете архитектуру и, э-э, обязательно надо указывать, что вы и как делаете. Не только на основании там условного названия, да, вы можете написать просто MVC или MVVM или там FSD или DDD или Clean Architecture, в общем, что вы используете. Это, конечно, замечательно и уже поможет, но желательно также указать и конкретное название папок, в какой папке, что у вас лежит, где сервисы, где там представления и так далее, потому что без архитектуры ИИ напишет рабочий код, но этот код будет встроен в систему так, что он будет или отличаться, или неправильно в целом встроен, и вам будет трудно тестировать и поддерживать в будущем.

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

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

Документы для маленького проекта, то есть какие вам документы нужны. И на самом деле можно было отделаться только двумя. Первый документ — это README.md, да? Это вот этот документ, собственно. И в нём вы описываете проект, что он делает, зачем он есть. Описываете архитектуру, описываете все подходы и паттерны, которые у вас есть, структуру папок и технический стек. Всё, этот файл условно будет читаться. И затем у вас может быть какой-нибудь agent.md, условно, где вы укажете, что вот в этом файле информация о проекте, и вам нужен план. Это то, с чем вы будете работать. Проект у нас небольшой, повторюсь. И в плане надо, чтобы была задача. У неё всегда должен быть какой-то идентификатор. Вы сами придумываете, какой. Должно быть описание, статус, что сделано и что осталось. Я обычно использую CLI, да, клиент в терминале, который называется dene для заметок и там храню планы для того, что делаю с помощью ИИ. Обычно я разбиваю план на задачи. И получается, что у меня всегда есть задача, которая выполнена, и задачи, которые надо выполнить. Соответственно, ИИ всегда может брать следующую задачу, которую надо выполнить, выполнять, помечать, что она готова. И таким образом он может в цикле одну за одной задачу достаточно быстро выполнить.

Почему это экономит токены в маленьком проекте? Э-э, двух этих файлов хватает для того, чтобы ИИ не сразу понимал, в чём заключается суть проекта, то есть что он должен делать, да? Потому что если логика понятна, общее, это уже хорошо, какой стек используется, то есть какие библиотеки есть, какие, как с ними работать, да, какие их версии, какая структура уже есть. То есть не надо думать, а есть ли сервисы, а есть ли уже API-запросы или ещё что-то. Мы уже указываем, что у нас есть. Мы указываем, какие задачи активны и конкретно какие надо брать, и показываем, что сделано для того, чтобы ИИ понимал, да, он всегда может обратиться в файл, где хранится то, что уже сделано, хотя бы общими описаниями. И он может глянуть и понять: «А вот это уже было сделано, значит, наверное, где-то в проекте это есть, надо найти такую-то функцию». Это убирает лишнее объяснение в каждом новом запросе. То есть, если у вас буквально маленький какой-то Hobby Project, там, не знаю, на 30 файлов и там 300 Кб без зависимостей, то вы можете смело использовать такой подход.

Но для среднего и большого проекта документов надо намного больше, потому что задачи там будут не такие общие, они будут часто разделяться. Предположим, что у нас проект, где есть и фронт, и бэкэнд, и какая-то база данных, и там надо работать по-другому. Вам понадобится Dockerfile, да, там отдельный файл, будут описаны все, как бы, зависимости, возможно, для каждого сервиса. Архитектура, она может быть или для каждого сервиса отдельно, или одним файлом для всех сервисов. И там мы описываем, как у нас устроен тот или иной сервис. Use cases — это ситуации, которые надо предусмотреть при разработке, да, нестандартные, различные. Мы должны понимать, что мы делаем. Поэтому просто вайп-кодером быть не подойдёт, на самом деле, чтобы, ну, как бы нормально работать. И надо буквально понимать, что делаешь и почему. Это схема базы данных. Конечно же, когда мы будем работать с данными или ИИ будет какую-то логику делать или менять базу данных, ей надо где-то брать об этом информацию. Если мы это не скажем, она начнёт вызывать команды запроса к структуре базы данных напрямую, чтобы разобраться, что там. В общем, лишние потраченные токены. Ссылки, вот видите, написано Links, а должно быть Links SKS. А это ссылки на документацию. Просто положите их туда, и ИИ будет редко туда ходить. Скорее всего, он будет думать, что у него уже всё есть, что надо. Но для того, чтобы он не просто искал в интернете что-то из того, что надо сделать, и нарывался на неправильные ответы, у него будет конкретная информация, куда пойти. Он всегда сможет воспользоваться поиском по определённой странице и найти то, что ему надо. UI Kit. Если у вас есть фронтенд и вы используете какой-то UI kit, то полезно было бы о нём информацию дать, и ИИ прочитает и поймёт, и какие компоненты есть, и как их использовать. И текущий спринт — это такой абстрактный файл. Вы можете не спринтами работать, любыми другими итерациями, но назовём спринт, так как это для IT более привычно. Текущий спринт — это то, над чем мы работаем сейчас.

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

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

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

Архитектура MD - это для того, чтобы не позволить и писать код отдельно от системы, мы описываем файл с нашей архитектурой. И там внутри архитектурный подход, который используется, основные слои, структура папок, правила создания файлов, взаимодействие модулей, то есть как что где вызывается и какой модуль за что отвечает. Важные ограничения, они тоже всегда есть. Например, мы не хотели бы прямых обращений к базе данных, а через какой-нибудь драйвер только. И граница ответственности, то самое разделение ответственности, чтобы как можно меньше возлагать на один какой-то модуль. Тем самым у нас упрощалось и тестирование, и дальнейшая поддержка с помощью и Edgecase SND - это файл с нестандартными сценариями. И если мы его не сделаем, то и всегда будет тестировать только так называемый Happy Flow, да, или Happy Pass, и не будет проверять ошибки. Поэтому внутри надо описать, какие ошибки могут быть, какие могут быть пустые состояния. Валидация. Это, кстати, важно для создания тестов, да, если вы пишете тесты с ней нейросетями. Также нетипичные пользовательские действия, если у нас есть UI, сетевые сбои, что делать с ними, ошибки авторизации, ошибки базы данных и ограничения безопасности. Всё это чкейсы, мы их описываем, что они могут быть, и будет их предусматривать во время разработки.

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

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

И опять-таки UI kit, про который я уже говорил, если в проекте он есть готовый и должен об этом знать заранее, иначе он сделает интерфейс сам, он будет рабочий, но не соответствовать вашим стандартам, где лежит, что уже есть, где находится документация, есть истории бука, как его открыть, да, он откроет Playрай и посмотрит, если вы playрай подключили, какие компоненты использовать, какие компоненты запрещено писать с нуля или даже менять. И пример юакита, да, или проблемы с юакитом. Это мой личный, у меня была задача. У нас там, в общем, достаточно сложная история. Я на менторстве у себя её достаточно подробно рассказываю, но в целом мне надо было сделать две страницы в UI. И мне, я не знал, что есть UI Kit, и я как бы и не просил даже искать. Я ему говорю: "Проанализируй". Там вот есть, я посмотрел на таких страницах похожие того, что мне надо компоненты по дизайну, и сказал: "Проанализируй эти компоненты и сделай мне вот страницу. Вот тебе дизайн, там вот тебе подключись к фигме, посмотри, всё классно". Да, MCP есть. Он посмотрел, изучил и сделал рабочий результат. Две страницы классных. Я сделал Request Merge Request в нашем случае у нас Gitlab и получил огромное количество одинаковых комментариев. И все были: "Это у нас есть UI kit, это у нас уже есть, можешь переиспользовать" и так далее. И всё, потому что я не сам не знал и не сказал. Теперь я, естественно, более ответственно подхожу к тому, чтобы изучать, что уже есть. Но в целом, как бы вывод такой, да, и пишет код неплохо, но в рамках того контекста, который вы дали. Если дали вы дали ему контекст океите, он практически идеально им воспользуется подробный контекст. Если не дали или будут отступления, если он сам поймёт, что какой-то UI Kit есть или будет всё по-своему.

А curent Sprintmd - это файл текущей итерации. Повторюсь, вы можете работать не с принтами, просто чтобы вам было понятнее. И один спринт, один агент, один контекст, а и субагенты. Естественно, я думаю, что не надо сейчас создавать много агентов. Сейчас новая модная тема - это субагенты. Вот этот цикл. Поэтому один спринт, один агент с субагентами, один контекст. И так работает точнее, быстрее, дешевле. Внутри описываются задачи текущего спринта, приоритеты, статусы. Практически всё то же самое, что вы обычно в Джире делаете. Можно, в принципе, и в Джире, но тогда надо предусмотреть выгрузку этой информации из жиры в контекст и делать это желательно до того, как использовать и как экономить токены на контексте. Ээ, и это не тащим старую историю диалога в новую задачу. Бывает, что многие заходят, старый диалог, копируют и что-то там вставляют. Не делаем этого. Не даём агенту весь проект, потому что весь проект - это много токенов, это много контекста, это много денег и вра и заканчивающиеся наши ограничения, да, количество токенов, которые нам работодатель дал. Под каждый спринт создаём отдельный контекст. Это тоже очень важно. Вот эти ирации вы можете отдельными контекстами, потому что в программировании принято, что один спринт реализует какую-то одну или несколько фич, и они сразу после этого идут в продакшн, да, по окончанию спринта идеально, чтобы их можно было задеплоить. Поэтому для, если вы делаете одну фичу или несколько, для них нужен какой-то ограниченный контекст. Под каждый спринт отдельный контекст. И в контекст попадают только те нужные документы, которые связанные файлы, которые как бы подходят конкретно для текущих задач. Так, агент меньше путается, быстрее отвечает и не сжигает токены на лишнюю информацию.

А что же делать, если у вас уже есть проект и вы хотели бы начать там работать с помощью искусственного интеллекта, и он не готов для работы с и там всего этого нет. Тогда вам нужны, ну, тут, видите, три файла. На самом деле вам нужны три скила, которые создадут нужные файлы. Первое - это контекстбиilder или контекст dump. Он изучит проект, он обычно стоит много токенов, он изучит проект и сделает вам файлы, которые будут вот нужные вам и с архитектурой, с какими-то ограничениями и так далее, и библиотеками. Второе - это change request. Это такой промт, который или это такая задача или функция, которая вернёт вам промт. Вот там тоже может использоваться. Что надо изменить? То есть у вас есть какая-то задача, с которой вы хотите начать работать. У вас вот вы использовали вот этот скилл или функцию контекст дампа. У вас есть уже контекст, у вас есть задачи, которую вы хотите начать работать. И это Legacy Waring. Legacy Вординing - это тоже специфический контекст. Там и должен вам найти всё, что устарело или проблемы, или зависимости, которые надо обновить. И вы должны тоже о них знать, чтобы как бы, во-первых, использовать только этот функционал, те, которые есть в этом в этих устаревших файлах, коде и так далее, и чтобы знать, что их надо будет изменить и улучшить.

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

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

Ну и вот пример практического задания, которое, например, мы делаем у себя на на менторстве, да, и вы можете тоже попробовать, на самом деле, с каким-нибудь кодом, да, например, у меня есть там репозиторий с рагом в гитхабе или найти любой другой репозиторий или старый проект, который у вас есть. Вы можете его форкнуть, сделать отдельную ветку, удалить RIDMI и сделать контекст dump. RIDMI будет мешать, на самом деле. Он может быть не обновлённый, устаревший, не такой подробный. В общем, лучше удалите, он создастся новый. Контекст Dump или Котек Builder. Скилы вы можете найти в интернете и получить этот контекст дам. Затем посмотреть, что там с помощью и, например, проанализировать, посмотреть, что можно улучшить, создать вот эти улучшения, внести изменения и проверить результат. А технический долг можно или сразу зафиксировать, занести, или попробовать его исправить и оставши часть него, но всё, что останется, занести в LEGY Warnings. И вот, например, какие задачи у нас выполнялись. повторить пример из того, что у нас э было есть в менторстве. У нас получается есть какой-то MCP, там один вид поиска надо сделать гибридный векторный киворд и сделать как бы ранжирование, чтобы хорошо при этом проходило. И умное перефразирование запросов, потому что там пользователь может написать некрасиво, может написать лишнее, может аббревиатуры, которые они нужны. Поэтому как бы вот такие вот штуки надо было сделать в репозитории, который не готов для разработки с помощью ей.

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

Основная ошибка, которую многие допускают - это делать не то, что и не то, что приближает их к реальной разработке, наделать этих переиспользуемых промтов, потом копировать и вставлять. А на это как бы одна из проблем, да, и потом вы эти пронты пытаетесь везде применять и пару слов дописывать. Оно так не работает. Тогда вы думаете, что у вас плохой, и вы начинаете покупать более дорогие модели или использовать, и токены заканчиваются ещё быстрее, а деньги уходят ещё ра ещё в больших объёмах. Тоже так делать не надо. любой и сегодня, ну, практически любой, многие, большинство и большинство моделей с хорошим контекстом работают хорошо. А просить код писать без спецификации - это ошибка. Делать проект по одном одному, когда не хватает командного опыта. Не стоит никогда делать что-то, если у вас не хватает опыта во всём. Не надо браться за бэкэнд, если вы про него ничего не знаете. И углубляться только в один стек, да, это вот как раз проблема тех, кто хочет или остаться на рынке, или делать свой продукт. Вы можете знать один стек и быть в нём экспертом, но этого сегодня мало. Надо иметь фуштестк мышления, где у вас ломается и процесс. Вот, чтобы вы понимали, вы можете взять, если у вас такие проблемы есть, и пробежаться. Если и сжигает токены и пишет не то, то, скорее всего, у вас нет спецификации. Если перечитывает весь проект, да, чтобы понять, где и что, то вы не разделяете. У вас, во-первых, нет нужной документации разделённой, да, потому что он хочет знать всё. Или она есть, но плохо описана. Если путается в архитектуре или вводит новые какие-то методы или, э, как это называется? паттерны архитектуры, то, скорее всего, она у вас нигде не описана существующая. Если используют не те библиотеки или ставят новые, хотя уже есть как бы аналоги, то у вас нигде не описано, где это посмотреть, да, и там условно JS про там в TypescriptриP приложениях хотя бы pack jon иногда читает, а в языках программирования, где нет э менеджера зависимости, где вы копируете что-то из гитхаба, то было бы неплохо обо всём этом рассказывать. условно не понимает задачу. Это значит, что вы её неправильно описали, у вас нет того, что надо сделать. Change request слово теряет историю проекта, потому что у вас нет информа, во-первых, у вас спринт неправильно оформлен или у вас вообще нет, и вы работаете слишком большим контекстом. Ну, если тяжело работать с Legacy, то, скорее всего, вам надо объяснить, что это Legacy, и использовать условный контекст дам.

Для этого навык пользования LLM не равно навык и разработки, да? То есть то, что вы умеете -э промты правильные делать, красивые, это не значит, что вы умеете использовать и в разработки правильно, потому что сегодня надо уметь намного больше. Сегодня надо уметь полный цикл от задачи до деплоя. И не надо, чтобы контролировать всё на каждом шаге. Да, всё ещё большинство компаний, конечно, заставляют вас там проверять merg квесты и вот это вот всё, но в какой-то момент мы перестанем смотреть на код, и нам надо будет как бы больше внимания уделять или совсем финальному результату, финальному финальному коду, или же всё-таки прямо готовому результату где-нибудь на def и acceptance envirйменте. Вам надо всё равно понимать архитектуру и иметь понимание о том, что такое качественно разработки, чтобы всё это как бы учитывать, понимая, что код написали не вы и вы, например, не хотите смотреть код. У вас должны быть другие метрики, по которым вы поймёте, что всё правильно. Решать, где и помогает, где нарёт, и всё сломает. Не всё сегодня, к сожалению, ещё пока можно автоматизировать. Вы должны знать, как, чем и где лучше это делать. Может быть, что-то надо делать руками. И вы должны не просто уметь предложить архитектуру, а объяснить. И эта архитектура не только там условного приложения или архитектура всей системы. Это и архитектура от скилов контекста и всего того, что вы используете в и должны уметь объяснить, какие требования вы закрываете, где риски, почему выбран этот вариант, что пришло, чем пришлось пожертвовать или там технический долг, который пришлось оставить, и как это всё будет вести себя в продакшене, да, и какие ошибки вы ожидаете, и как бы это нормально.

Глобально у вас есть два пути, чтобы со всем этим разобраться. Здесь уже чуть больше рекламная часть стороны моего менторства начинается. Вы можете выбрать двигаться самостоятельно, да, потому что это тоже возможно. В интернете есть всё совершенно бесплатно. Вы можете всё пробовать самостоятельно и ошибаться на своих проектах, пробовать самостоятельно разные инструменты и тратить какое-то большое количество времени на бессистемные попытки, потому что надо понимать, что где смотреть или вообще стоит ли. И это будет приближать к вас росту, да, но очень медленно, потому что вы не понимаете, опять-таки, нет этой структуры. И в итоге вы можете что-то упустить, что-то не допонять. И если вы выйдете напрот с недопониманием, то большая стоимость ошибки в итоге. Или же путь два - это двигаться с ментором и командой. Это перейти от разрозненного использования, как получится или как умею, к системной разработке, чтобы всё работало практически само. Да, всё ещё Humor and the Loop у нас есть. Всё ещё где-то надо быть самому вовлечённым, но в целом переложить больше всего на и уж тем более не писать код руками, потому что сегодня это, ну, практически уже устаревшее. Больше делегировать агентам, больше им доверять и понимать, как получать результат, которому можно доверять. Естественно, экономить токены и делать больше в тех ограничениях, которые у вас есть. Быстрее выполнять рабочие задачи, потому что чем больше и знает, тем быстрее он это делает. Например, мне не нравится, что клод медленный, но с хорошим контекстом он хотя бы не совсем слово погда снилом антигравити. И вы научитесь, э, как бы работая вместе, объясняясь, согласовываясь, если у вас есть какой-то ментор, то вы поймёте, как упаковать всё то, что вы поняли, узнали и разобрались для того, чтобы, например, или расти внутри компании, или сменить работу, если есть желание.

Часто запросы, с которыми ко мне приходят, да, эти люди, которые участвуют в тренингах, им обычно надо опыт работы в команде, потому что их может не быть, они могут быть или фрилансерами, или сами себе команда, или там два человека в команде. Им надоело работать и как справочникам, да, они не хотят там копипастись от GPT или там копипасти откуда-то в плод. Они не понимают, как оставаться востребованными, потому что все боятся сокращений и боятся потерять работу. Они долго не могут устроиться на работу и не понимают, в чём проблема. Кто-то хочет просто понять, что и как в мире поменялось, да? Он чувствует себя хорошо, у него есть работа, но он понимает, что надо не отставать от рынка. Кто-то застрял просто в одном месте условном, даже если это большая зарплата, у тебя большая должность, ты, возможно, хочешь двигаться дальше, и тебе хотелось бы понять, как быть лучшей для компании или там для себя или whatever. И, конечно же, кто-то хочет просто автоматизировать процессы, как бы условный фрилансер, который просто хочет больше выполнять за короткий промежуток времени. Именно поэтому у меня появилось менторство, да, потому что я понял, что я, в принципе, много из этого понимаю, умею, хотел бы рассказать. И, э, как бы я решил, что делать там по одному, это, во-первых, неудобно, во-вторых, трудно, если бы я был ментором для отдельного человека, да, быть там помощником ему в командной работе, потому что я не хотел бы как бы выполнять много ролей. Если человек хочет быть разработчиком в большой команде, есть только я, то это надо роль Тихлида и Тимлида и Qэя выполнять какое-то много ролей каждому из нас. И я решил, что как бы многие разработчики должны понимать и уметь то, что они до сих пор не разобрались, да, потому что есть буквально люди опытные, классные, умные, но им буквально не хватает знаний в какой-то одной области или в какой-то сфере или в той же. И некоторые люди, например, хотят повысить стоимость своего часа с помощью инструментов. Это, конечно же, больше относится к фрилансерам, но в целом кто-то хочет меньше писать коды руками, а это и вовсе не писать. Кто-то хочет делегировать агентам рутинные задачи, потому что я, например, и почту проявляю с помощью агента, а кто-то хочет просто там свой стартап быстрее запустить или много проектов пробовать или в НТИ работать в компании, хочет тоже там всё делать быстрее. И в моём менторстве вы сможете встроить или с помощью моего менторства, я называю это менторство, но это такое групповое менторство, я даже не знаю, но это тренинг. Я обычно называю тренинг, будем пока называть менторство. Так вот, он, ну, как мне кажется, помогает строи идти в работу и научиться делегировать агентам кода рутинные задачи, выйти за рамки одного стека, потому что там надо быть фулстеком и думать фулстеком и думать продуктом, собрать сильный проект и опыт для портфолио. Да, вы всегда можете зайти на GitHub и посмотреть, какие проекты делали, какие проекты были у предыдущих потоков. Вы научитесь реализовывать свои идеи с помощью агентов. Я расскажу, мы обсудим и локальную модель и раги, и MCP. Вы, может быть, что-то для себя даже сделаете. вы сможете видеть процессы разработки с разных сторон и как бизнес, и за счё и как разработчика, как QA, потому что у нас на тренинге есть ротация ролей на каждый спринт, и вы сможете повысить свой доход или внутри компании, да, или, может быть, даже найти себе новую работу или автоматизировать коммерческие проекты и делать их больше за короткий промежуток времени.

Называется всё это Back to the Future. Не знаю, так получилось, так вышло, потому что команда на предыдущем тренинге называлась DMC1. Это типа я так назвал Deloran из первой части Back to the Future было решено так тренинг обозвать. И это такой fullstaк driven development тренинг или менторство для разработчиков, которые хотят повысить, как я уже сказал, стоимость своего часа и стать специалистами, которые не просто пишут код быстрее, а доводят идеи от начала и до конца до рабочего продукта через иагентов, через знания архитектуры и системную разработку с помощью иагентов. На выходе у вас будет fullstack проект, который можно показать в портфолио или коммерциализировать. Коммерциализировать, наверное, с двумя им пишется, потому что, э, ну, как бы он ваш, там MIT лицензия, и вы делаете, что хотите. У вас будет опыт командной разработки, близкий к формату сильных IT-команд, потому что будет такая сильная команда. У вас будет нетворкинг, потому что вы узнаете других разработчиков. Может быть, у вас, вы там рядом живёте, пиво попьёте. Может быть, у вас какие-то общие интересы найдутся или вы проект вместе сделаете. У вас будет навык делегировать агентам рутинные задачи и меньше писать куда-то руками. Я бы сказал, вообще не писать понимание, как экономить токены за счёт контекста спецификации, сжатия и что и как использовать. Там на самом деле много всего прои как упаковать резюме и LinkedIn, чтобы они были актуальны на рынке сегодняшнем. Э как делать техтолки и готовить документы о том, чтобы вы работали с архитектурой. И пока это всё покажет ваш инженерный уровень, потому что у нас и разговоры тоже есть там, и даже демо. И карьерный план роста лично от меня, потому что каждый из вас получит индивидуальный, каждый из тех, кто на не вас, а тех, кто придёт на менторство, на тренинг, получит дальнейший план, куда двигаться и как развиваться. Ну и главная трансформация до ты пишешь код и закрываешь задачу, но упираешься в потолок, работаешь в своём участке, на

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

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

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

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

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

И простая формула программы - это понять ей как рабочую систему, а не как справочник. Это применить её искусственный интеллект, не растите в фустек разработки. Там фронт-end, backend, IP, вот это вот всё. База данных, инфраструктура. собрать MVP в команде с ролями, спринтами, ревью, демо, документацией и упаковать в карьеренный результат, потому что там есть целый трек, посвящённый карьере там и как себя продавать и что делать. И этот результат ценен для рынка, потому что вы всё это будете уметь на практике. Вы можете это показать в гитхабе, в котором вы всё будете делать и хранить. Там всё это будет видно. Можно зайти, посмотреть, если кто-то решит вас проверить.

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

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

Второй месяц, повторюсь, командный FullStк проект, мини-команда, восемь человек, спринты, ревью, технические решения надо будет объяснять и описывать. Команда хочет знать, что вы делаете везде и везде, на всех этапах. React Typeescript на фронт-эндде, Python fast IP на бэкэнде, Postc Radies, Mongo DB. Я расскажу, зачем вы сами решаете. На самом деле команда принимает и архитектурное решение тоже. Авторизация разная. Команда решает какая, но будет предусмотрена одна. Docker, CICD, Engine X. С этим всем будем разбираться. Будет плой, будет Production и Dev environment, базовая инфраструктура и мониторинг, естественно, связи. В общем, всё то, что я уже перечислял.

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

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

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

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

Антон, он 20 лет в IT, архитектор, потому что такие люди тоже приходили на тренинг, и он получил уверенность себе в как в разработчики, потому что как бы рекомендации, моё мнение о нём и как бы улучшило его мнение о себе. И до того, до того, как прийти на это менторство, он был в профессии достаточно давно. Вот. Но когда ты долго в профессии, многие вещи ты уже за ними не успеваешь. Всё часто и быстро меняется, и всё надо как будто бы учить. и придя на тренинг, просто быстро, за короткое время освоил стек, на который у него не хватало времени всегда, да, из-за работы там каких-то семьи и всего остального. И при этом он стал более актуальным на рынке, потому что он и выучил то, что популярно в целом, там docker GitHub Actions, ещё de Pls, но и понял, как её использовать, и стал более актуален, да, и может расширить те задачи, которые он на себя берёт.

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

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

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

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

Кому не подойдёт? Тем, кто не не знаком с программированием, да, с синтаксисом, да и в целом с логикой в программировании. Тех, кто хочет насмотреться просто лекции, потому что можно сказать: "Да, мне только про и надо и желательно лекциями". Нет, так не работает. Я даю комплекс. Комплект. Комплекс, да. Комплект. Потому что сработать и тоже надо в команде, и это тоже надо делать правильно. Поэтому эта часть тоже очень важна для того, чтобы буквально понимать, как е работает. И были люди, которые буквально, скажу, как я уже говорил, хотели один месяц и только лекции про и никакого проекта, потому что нет времени, работы и так далее. Классно. Про это можно купить какой-нибуд курсе или какие-нибудь записанные лекции и посмотреть. Я даю и как бы чуть больше, чем даёт просто запись. Тем, кто не готов работать в команде, это тоже не подойдёт. К сожалению, совсем-совсем интроверты не готовые делиться или не готовые делегировать или недоверяющие нам не подойдут. У нас командная работа. И тем, кто ждёт волшебную таблетку вместо системной работы, да, если вы не хотите самостоятельно разбираться и думаете, что вот послушайте пару лекций и сразу вам зарплата прилетит и ещё что-то, нет. Это труд. Вам надо будет понять, разобраться, использовать, упаковать и продать. Я не найду вам работу. Я не перевезу за границу. Я не приду к вашему боссу и не скажу повышаю ему зарплату. Я вам дам знания, которыми вы можете воспользоваться, чтобы всё это произошло.

Собственно, поэтому есть отбор, да, потому что есть все вот эти вопросы, на которые надо ответить. Аа то есть это менторство про командную работу, как я уже сказал. Есть и ограничения, и есть проект, есть разборы, но моё внимание будет ограничено, потому что людей будет не только вы, но как бы у вас будут другие люди, и я всё равно буду давать вам нужную информацию, и я буду всё равно комментировать ваш проект. Вы будете работать вместе, и вам придётся с вашими коллегами какие-то решения совместно принимать или в чате, или у нас в командах в командах люди созванивались, устраивали себе такие раз в неделю созвоны. В общем, вам всё равно придётся это делать. И это не работа для одного. И вам нужно понимать, что вам придётся работать. Вам нельзя будет: "Ой, на этой неделе не буду ничего делать, сделаю на следующей или следующем спринте". Вы должны работать в одном темпе. Это не будет занимать у вас много времени, да, он рассчитан там, условно, там 6 тире 10 часов в неделю вместе с обязательными звонками, которые с моим участием. Но вам всё равно придётся как бы э делать то, что вам надо будет делать. А если мы увидим в процессе отбора, что мы можем вам помочь, то есть нам надо понять, может быть, вы уже для нас оверquвалифайд, дайте, как бы, знаете, как бывает с работой, может быть, вы для этого тренинга уже оверквалифайд, мы должны тоже понять, что мы вам подходим. Вы должны понять, что мы вы подходим. И для этого, собственно, мы будем всё это проводить. И это не массовый набор, это отбор людей, которым реально поможет наш тренинг. То есть я не хочу просто заработать денег, да, я могу брать всех подряд, рассказывать и будет, что будет. Я хочу помочь людям. И я роликами своими в интернете не особо обычно людям помогаю. Я рассказываю что-то там энтертейнмент в рамках там новостной повестки условной. А здесь я хочу помочь людям. И эти люди заплатят много денег. Я хочу, чтобы у них был какой-то результат. Поэтому, если мы можем вам помочь, мы вас пригласим. Если мы с вами не подходим друг к другу, и мы должны решать это в обе стороны, да, потому что деньги не самое важное здесь, то, к сожалению, мы с вами не подходим друг к другу.

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

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

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

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

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

А, и парочка ответов на вопросы, которые могут возникнуть. Я, возможно, на них уже ответил, наверное повториться. Сколько времени нужно будет уделять обучению? 6 или 10 часов. Можно ли совмещать с работой? Обязательно можно, потому что, ну, если вы уже работаете, вы молодец, значит, вам просто надо стать лучше. Подойдёт ли мне программа, если я не умею в код? Не подойдёт. Вы должны уметь в код. И можно ли научиться всему самостоятельно? Вы можете научиться всему самостоятельно, просто у вас зайдёт займёт больше времени, и вы допустите больше ошибок на пути.

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

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