Если честно, пост про GranTurismo я хотел написать очень давно. Когда я только купил GT Sport примерно 4 года назад, я долго просто сидел и с интересом исследовал, с какой любовью восстановлены детали трасс и автомобилей. Потом сравнивал нюансы поведения разных машин и, конечно, учил наизусть все 154 поворота Nordschleife.

Полгода назад я купил руль Fanatec DD Pro — и моё наслаждение от GranTurismo выросло ещё на порядок. Паззл сложился: виртуальное, механическое и эстетическое слились воедино, чтобы полностью погружать меня в атмосферу гонок. Настолько полностью, что жена начала посмеиваться, что я сижу перед телевизором и кручу руль в своих картинговых перчатках. Наверное, со стороны это и правда выглядит забавно 😄

Но сподвигло меня на этот пост в итоге то, что вчера я заговорил про GranTurismo с ChatGPT. Мне захотелось более осознанно подобрать стратегию для почти часовой гонки, которая будет в субботу. Из вариантов настроек машины, которыми можно будет пользоваться, там всего три: Brake Balance, Traction Control и Fuel Map. Немного, но есть, над чем подумать.

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

С Fuel Map для будущей гонки всё просто: должно хватить одного бака на всю дистанцию, так что можно ехать на полную. А вот с настройками стабилизации всё интереснее. Чем больше расслабляешь Traction Control, тем быстрее можно ехать — но тем быстрее умирает резина. А на эту гонку разрешён только мягкий состав. Его хватает примерно от 7 до 15 кругов, а значит пит-стопов может быть от одного до трёх.

Я всё это, конечно, понимал… но мне всегда было лень считать. А ChatGPT отлично справился с ролью стратега моей команды.

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

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

Кстати, чтобы потренировать Grid Start со светофором, мне нужны живые люди. Так что если вдруг кто-то из подписчиков тоже заморачивается по GranTurismo — добавляйтесь в друзья: https://profile.playstation.com/dmgritsan 🚗💨

Вот так курсор обучает меня работе с командной строкой

P.S. Если вы пойдёте и полайкаете эту картинку в моём LinkedIn, вы сделаете мой кодинг на выходных сильно приятнее

Пока ковырялся со своим телеграм-ботом с LLM под капотом, откладывал две технологии, которые очень хочется потыкать на живом примере и, желательно, с локальной развёрткой. Это RAG и MCP.

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

————————————-
На всякий случай, небольшая справка от ChatGPT.

🧠 RAG (Retrieval-Augmented Generation) — это способ обогатить ответы LLM внешними данными. Вместо того чтобы LLM всё "вспоминала" из своих весов, ей дают доступ к базе документов: она сначала ищет нужный фрагмент, а потом генерирует ответ на его основе. Подходит, если хочется, чтобы бот знал что-то конкретное: внутреннюю документацию, справку по продукту или личные заметки.

🔧 MCP (Model Context Protocol) — это концепция "интерактивного сервера" для LLM, где есть tools, state и более сложные диалоги. LLM умеет не просто отвечать, а вызывать инструменты — как функции, API или действия, — и накапливать контекст. Например, можно сделать ассистента, который по ходу разговора заполняет форму, делает запросы к внешним сервисам и учитывает предыдущие шаги.

Вчера, во время поиска тулов для LLM’ок, которые хочется потестить, наткнулся на browser-use. Представил, как буду описывать действия обычным текстом вроде: «зайди на такой-то сайт, найди то-то, вытащи вот это» — и оно всё будет делаться само. Мечта ✨

Потратил несколько часов, чтобы разобраться, как заставить это всё работать. Настроил так, чтобы он использовал локальную LLMку. Убедился, что она действительно работает через GPU. Собрал. Запустил.

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

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

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

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

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

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

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

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

Спросил потом у ChatGPT про это - и он отлично всё рассказал. Про фичетогглы, кстати, это он добавил, у меня на сессии совсем из головы вылетело.

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

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

При этом, конечно, FOMO подтачивает. Все вокруг (спасибо, соцсети) уже запустили свои микропродукты, SaaS’ы и прочие AI-штуки. Мне тоже хочется!

В выходные решил изучить повнимательнее один такой модный продукт — Cal AI. Это приложение обещает лёгкий и точный подсчёт калорий: фоткаешь еду — и вуаля, всё посчитано. На сайте заявляют, что нутрициологи в среднем точны на 60%, а приложение — аж на 90%. Ну, думаю, звучит интересно, надо попробовать.

Скачиваю. Устанавливаю. Запускаю. Жму на большую кнопку с плюсом, чтобы добавить первое фото еды. В ответ мне предлагают согласиться на триал, который через две недели станет подпиской. Ну, понятно, все так делают. И я бы даже согласился, если бы на фоне не проигрывалась красивая анимация (это она, кстати, в посте).

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

Ну, камон! Ребята, я даже когда съем этот сендвич, не факт, что пойму, с чем он был. А от типа мяса (если это вообще мясо) калорийность может различаться очень даже существенно. Вряд ли речь о пределах тех самых “±10%”.

Короче, кнопку “старт триала” я так и не нажал. FOMO слегка подуспокоилось. А я пошёл искать пример AI-продукта, который бы вдохновил не только идеей, но и качеством исполнения.

Может, у вас есть что-то на примете? 👀

Так как я не только Fullstack Manager, вооружившийся курсором, но и симгонщег с GranTurismo и Fanatec'ом, хочу поделиться с вами сегодняшним открытием. Помимо цветов British Racing Green и French Racing Blue кажется существует ещё и Польский Гоночный Красный

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

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

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

Для начала: вайб-кодинг, о котором я говорю — это такой вайб-кодинг, который научились нормально применять в продакшне. «Нормально» — это не просто «нажал кнопку, получил код», а полноценный TDD-процесс:
1. Объясняем AI, что нужно сделать — в продуктовом смысле.
2. Вместе с ним описываем сущности, генерим объявления: без логики, только структура.
3. Пишем тест-кейсы, валидируем их, просим написать тесты, принимаем.
4. Запускаем агента, который пишет код, проходящий эти тесты.

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

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

— Никаких рефакторингов.
— Никаких разборов старого кода.
— Никаких «ой, а как тут всё устроено?».

Больше не нужен читаемый код!

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

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

Пару недель назад созванивался с тремя разными людьми, которым интересны ТГ-боты. Это было что-то типа кастдева — чтобы ответить на вопрос: кому и зачем нужен курс по AI-driven разработке для Telegram. И вот к концу третьего звонка, спасибо моему собеседнику, я внезапно понял, что курс делать я вообще не хочу 😅 А на самом деле хочу поделиться одной идеей, которая кажется мне реально полезной. В связке AI + Telegram-бот (а ещё Slack, WhatsApp, Facebook Messenger и прочие чат-боты) отлично ложится третий элемент — serverless.

Если коротко, вот почему я так думаю:
– Serverless задаёт архитектурную рамку — если не вам, то хотя бы LLM’ке, которая будет проектировать решение.
– В получившийся проект LLM’ке будет проще вносить изменения. Структура получается понятной, и когда прилетают новые требования — сразу видно, куда копать.
– Железо — не ваша забота. Нет трафика — всё бесплатно. Появился трафик? Заливаешь деньгами, и всё масштабируется (ну, теоретически 😈).

Но и подводные камни тоже есть:
– Нужно понимать, что такое serverless и как работает микросервисная архитектура.
– Трудно тестировать всё локально — понадобится эмуляция облачных сервисов.
– Вендорлок. Если захотите мигрировать с одного облачного провайдера на другой — будьте готовы немного пострадать 🥲

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

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

Хочешь такой воркшоп — поставь под постом 👾 А ещё лучше — напиши в комментариях, что хотелось бы обсудить.

Соберётся 10 👾 — сделаю!

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

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

Duolingo мотивирует тебя качать streak — количество дней подряд, когда ты сделал хотя бы одно задание. За 5, 10, 100 дней, год — тебя хвалят, награждают и напоминают, какой ты молодец. Если пропустил — можно «прикрыть» пробел за счёт внутриигровой валюты. Но если сова тебя в чём-то заподозрит — начинается жара. Она начинает спамить пушами и письмами.
То нежно говорит, что верит в тебя и надеется, что у пропусков есть уважительная причина.
То с укором напоминает, как ты её подвёл.
То просто начинает давить: ну что, серьёзно? После всего, что между нами было?

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

А вот другой пример геймификации — Gran Turismo — работает со мной намного лучше в долгосрочной перспективе.

Там есть штука под названием Daily Marathon. Её суть максимально простая: если ты проехал 42,2 километра за день — получаешь лотерейный билетик. Билетик бывает разного достоинства — от 3 до 6 звёздочек. И, честно говоря, я так до конца и не понял, от чего эта величина зависит.

Но основная разница с Duolingo в том, что с одной стороны, нужно не просто зайти и хоть что-то сделать, а реально проехать минимальный объём (42,2 км — это примерно полчаса гонок). А с другой — за то, что пропустишь день, тебя никто не накажет. Никакого непрерывного streak тут нет (хотя, кажется, в Gran Turismo Sport что-то выдавали за 150 дней подряд, но это была совсем необязательная ачивка).

В итоге месяцы, когда я не пропускаю ни одного Daily Marathon, могут соседствовать с месяцами, когда я и половину дней не захожу в игру. А вот после того как я сорвался с этого несчастного streak’а в Duolingo, к сове я так и не вернулся.

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

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

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

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

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

Всем блины и никаких комочков! 💛

Нет сил больше терпеть — анонс! 😤

Воркшоп «TG-боты с AI и Serverless»

📅 Когда: один из дней уикенда 27–29 июня (точный слот выберем вместе в чате)

🧠 Что будет: за 2 часа разберёмся, как с нуля поднять Telegram-бота с помощью AI-инструментов и serverless-инфраструктуры. AI будет не только в промтах, но и в бэкенде 🤖

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

⸻

Как всё будет устроено

1. Теория (≈ 30 мин):
• Конструкты, no-code и «настоящая» разработка — когда что удобнее;
• Telegram Bot API: pull vs push;
• Микросервисная и serverless-архитектура — что это и зачем она тут;
• Чего ждать помимо кода: деплой, тесты, отладка, CI/CD и прочее веселье.

2. Практика (≈ 75–90 мин):
⚡️ Промтим Cursor
• Сгенерим основу: λ-функции, очередь, API Gateway и CDK-скрипт. Документацию тоже не забудем;
• Деплой в AWS + разбор пайплайна;
• Апгрейд: логируем сообщения;
• Апгрейд 2: обрабатываем голосовые;
• Апгрейд 3: чат-бот с контекстом и чуть-чуть AI магии;
⚡️ Что-то из этого сделаем в Codex. Заодно покажу, в чём его принципиальные отличия.

3. Q&A — сколько понадобится. Ну и продолжим в чате 💬

⸻

Уровень участников

Если когда-то писал(а) код и примерно понимаешь, что происходит в редакторе — погнали. У нас будет простой и логичный проект. Подойдёт любой язык: Java, Go, PowerShell, Node.js, C#, Python, Ruby — всё, что работает в AWS Lambda. Моё демо будет на Python.

⸻

Что подготовить

• Точно нужен Cursor и поддержка выбранного языка;
• Пригодится GitHub (но не критично);
• AWS-аккаунт (можно заменить на GCP или Яндекс Облако, но будет сложнее — так как демо будет на AWS);
• Инструкции по настройке будут в чате. Если что-то непонятно — обсудим подробнее.

⸻

Условия участия

📣 Сделай репост этого анонса в любую из своих соцсетей
🔗 Пришли ссылку на репост в комментарии к этому посту
✅ Я добавлю тебя в отдельный чат для подготовки и публикации материалов после воркшопа

⸻

Жду всех, кому интересно изучать AI-инструменты разработки и применять их в реальных задачах 🛠✨

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

Так вот, вчера пошёл писать первый пост в чат воркшопа про установку Cursor, Python и Node.js. И пока писал, совершенно случайно выяснил, что историческое деление в моём проекте на два языка — Python и TypeScript — это всё происки LLM’ок. На самом деле можно было всё написать на Python. Просто когда я просил Cursor или, возможно, ещё ChatGPT написать код для lambda-функций в AWS, я явно говорил, что он должен быть написан на Python. А вот про описание стека в CDK я такого не говорил. Просто сказал ему: «Сделай мне автоматичекий деплой этого всего в AWS», ну он и написал всё на TypeScript. Скорее всего, потому что TypeScript был популярнее для решения этой задачи.

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

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

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

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

Вот так я узнал, что даже то, что ты делаешь всю жизнь, можно делать неправильно 😅

Я поверил — и в себя, и в тренера. В Москве мы занимались стабильно по 3 раза в неделю. Потом был переезд в Белград и месяц паузы, пока Эд тоже не переехал туда. Потом мы переехали на Кипр, тренер остался в Белграде, и я попросил составить мне программу для дома. Программа менялась - то на 4, то на 3, то на 2 раза в неделю. В домашних занятиях я полюбил TRX, степы и резинки. И даже проникся к йога-растяжкам. 🧘‍♂️
Сейчас я снова вернулся в зал, сначала на 2 раза в неделю, потом на 3, сейчас опять на 2. Причём хожу эти два раза в неделю даже в командировках, как прямо сейчас!

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

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

Время воркшопа выбрали — он будет в ближайшую субботу в 11:00 по Кипру (т.е. по МСК).

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

Готовлю тут материалы к завтрашнему воркшопу. И могу вам ответственно заявить: Gemini умеет в русский язык 🤣

Спасибо всем, кто пришёл на воркшоп! 🙌 Особый респект тем, кто не просто слушал, а задавал вопросы, делился мыслями, шарил экран Курсора с успехами и не терял концентрацию три с лишним часа подряд. Вы — супер 💪

Ещё один важный повод сказать спасибо — это репосты. Благодаря им канал наконец пробил 300 подписчиков 🚀
Раз этот коварный план сработал, продолжу гнуть свою линию: запись воркшопа будет доступна в той же группе — со входом за репост. А здесь я буду постепенно делиться разными тизерами и хайлайтами. Начну прямо сейчас!

💡 Мысль, которая родилась как введение к практической части воркшопа.

Всем менеджерам хорошо знакома аббревиатура S.M.A.R.T. — мы по ней ставим цели себе, команде и вообще кому угодно. Но что если поразмышлять, как SMART применим к AI-driven разработке?

Начну с конца, потому что там самое понятное, а потом вернусь в начало.

🧾 T — это больше никакой не Time-Bound. Теперь это Token-Bound.
Причём в двух смыслах сразу: и в плане длины промта, и в том, что задача должна укладываться в лимит по ресурсам.
Агент не должен думать бесконечно — нужно дать ему возможность остановиться, пока он не сожрал все токены с твоей кредитки и ничего дельного не выдал.

🎯 S — Specific
Тут всё как раньше, если не хуже. Дать человеку немного свободы в постановке задачи — можно. Дать её LLMке — чаще всего значит получить непредсказуемый результат.
Если ты не понимаешь, чего хочешь от LLM’ки, — она уж точно не поймёт. И сделает совсем не то, что ты хотел бы увидеть.

📏 M — Measurable
Вот это уже интереснее. Вопрос-то простой: как ты поймёшь, что результат — именно тот, который был нужен? А вот найти ответ на него…
Попросишь написать тесты? Окей. А тесты кто проверять будет?
В общем, с LLM’ками буква M — одна из самых непростых.
Нужна такая форма постановки, при которой и ты, и модель можете убедиться в том, что именного этого результата вы и добивались.

✅ A — Achievable
Здесь попроще. Не хочешь, чтобы Cursor нафантазировал — сначала проверь, достижима ли цель.
Обсуди её с ChatGPT, Gemini, DeepSeek — или с тем же Claude, который у тебя внутри Cursor сидит.
Главное — убедиться, что ты не просишь невозможного. Человека это демотивирует, а LLM’ку отправляет в галлюцинагенный трип.
Она тебе скажет, что всё сделала, а ты такой: я же M не забыл, правда?

📚 R — Relevant
Несмотря на то же английское слово, смысл этой буквы сильно поменялся.
Relevant — больше не «актуальная», а вот прям релевантная: коду, документации, содержимому .cursor/rules.
Agentic-AI не будет спорить, если ты попросишь странного — он просто начнёт переписывать всё, что под руку попадётся. Да так, что ты не будешь рад ни потраченному количеству токенов, ни незапланированному рефакторингу, ни тому, что ты полностью потерял M из всех предыдущих целей и задач.

Короче, кажется, SMART живее всех живых, хоть и заиграл немного новыми красками в контексте AI.
А ты что думаешь про их сочетание? 👀

На воркшопе практическая часть сразу пошла не по плану 🙈

Я попросил Курсор последовательно выполнить три разные задачи:
📌 Написать код функций для AWS Lambda
📌 Описать CDK-стек для деплоя
📌 Собственно, провести деплой

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

Одна из самых частых проблем, возникающих при работе над многослойными проектами в Курсоре, — это управление зависимостями. Он постоянно прописывает конкретные версии библиотек, не проверяя их актуальность. Как результат — устаревшие либы, которые тянут за собой устаревшие рантаймы. Версия AWS CDK, которую он указал, была на 900 😱😱😱 релизов старше последней стабильной! Отсюда и всплыл Python 3.6

В общем, после воркшопа родилось новое правило для Cursor Rules, которое сразу же показало свою эффективность в воскресенье, пока я работал над очередным проектом:
✅ Перед тем как прописывать любые зависимости, узнай, какая последняя стабильная версия, и проверь, не установлена ли уже нужная библиотека локально.

В .cursor/rules, конечно, это выглядит иначе. Вот во что Курсор транслировал моё короткое требование 👇

## Python Runtime Version Alignment
- ALWAYS align Python runtime versions between local development and AWS Lambda
- Required Python version: 3.13.x
- Required Lambda runtime: PYTHON_3_13
- AWS Lambda supported Python runtimes: PYTHON_3_8, PYTHON_3_9, PYTHON_3_10, PYTHON_3_11, PYTHON_3_12, PYTHON_3_13
- Ensure all development environments (local, venv, CI/CD) use Python 3.13.x
- Test Lambda functions locally with target Python version before deployment

## Python Dependencies (requirements.txt)
- ALWAYS check for the latest version of any external library before adding it to requirements.txt
- Use exact version pinning (==) for all dependencies to ensure reproducibility
- Before adding a new dependency, verify its latest version using:
  - PyPI: https://pypi.org/project/[package-name]/
  - pip index versions [package-name]
  - Or use tools like pip-check-updates or pip-review

## Node.js Dependencies (package.json)
- ALWAYS check for the latest version of any external library before adding it to package.json
- Use exact version pinning (no ^ or ~) for production dependencies to ensure reproducibility
- Before adding a new dependency, verify its latest version using:
  - npm view [package-name] version
  - npm outdated
  - Or use tools like npm-check-updates or npm-check

## Version Update Process
1. Before adding any new dependency, research the latest stable version
2. Check for breaking changes in major version updates
3. Test compatibility with existing codebase
4. Update all related files (requirements.txt, package.json, package-lock.json)
5. Document any breaking changes or migration steps

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

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

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

🔸 Скучные задачи имеет смысл дробить, чтобы они не висели мертвым грузом до последнего. Ведь чтобы сесть за нудную большую задачу нужно либо много времени и сил, либо дедлайн завтра. А небольшие не особо интересные задачки намного легче «рассасываются» в течение недели. К тому же чувство выполненного долга после закрытия скучной задачи бесценно! 

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

В общем, как бы мне ни хотелось меньше быть менеджером в нерабочее время, ничего не получается. 🤷‍♂️ Но тут по крайней мере мне не надо ни с кем кроме себя бороться, чтобы сначала думать, а потом делать 😅