Тот самый пост, в который ChatGPT пытался добавить свой авторский стиль.

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

Серьёзно?

Мы же никогда не писали приложения «сразу».
Сначала изучали предметную область.
Описывали пользовательские сценарии.
Делили задачи на фронт и бек.
Согласовывали API.
Разбирались с ограничениями и корнер-кейсами.
И только потом садились писать код.
Каждый из этих этапов понижал энтропию.

Ну ладно, в пет-проектах — особенно в первых — всё было по-другому. Садишься, сразу пишешь код. Кажется, что и так понятно, чего хочется добиться. (Нет.)

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

Так почему, когда в руки попал AI, мы решили, что теперь можно просто сказать: «сгенери мне приложение» — и удивляемся, почему всё разваливается?

Может, не в AI дело? Может, мы просто решили скипнуть не только написание кода, но и все этапы, которые всегда предшествовали разработке?

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

А потом уже просить AI сгенерить код. Лучше сразу с тестами, чтобы было понятнее где и когда что будет ломаться.

Все описанные шаги LLM'ка, кстати, тоже отлично помогает ускорить.

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

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

Первый раз что-то похожее на системность появилось, когда мне было уже под 30 — я увлёкся теннисом. Занимался 2–3 раза в неделю с тренером, несколько лет подряд. Были тренировки на технику, игровые сессии, даже регулярные внутренние чемпионаты. Естественно, сначала прогресс был очень заметным и радовал меня, но со временем появилось ощущение какого-то стеклянного потолка, и было не очень понятно, что с ним делать.

Летом 2022-го на фоне резко выросшего уровня стресса у меня усилились фоновые боли в спине и шее. После нескольких уколов миорелаксантов, которые возвращали меня в нормальную жизнь, я осознал, что единственный способ системно справиться с этой проблемой — это «закачать» спину. И я занялся фитнесом с тренером. С тех пор я уже почти 3 года регулярно занимаюсь именно фитнесом 2–4 раза в неделю. И это реально изменило очень многое 💪

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

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

А теперь — неожиданный, но закономерный для этого канала переход к AI-разработке 🧠🤖

Когда я смотрю, как люди сегодня начинают делать продукты с помощью AI, я понимаю, что это очень похоже на мои отношения со спортом. Им тоже хочется сразу «играть» — запускать продукты, постить приложения в сторы, радоваться инсталлам. Но как только они сталкиваются с реальным челленджем, выясняется, что без базы — никуда. Сначала LLM всё сделает за тебя, но когда столкнёшься со сложностью, придётся всё равно пойти «жать железо» — разбираться в алгоритмах, читать про архитектуры, понимать (и даже немного писать) код. Просто чтобы не утыкаться постоянно в потолок.

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

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

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

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

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

Что хочу сделать дальше - поднять у себя полноценную систему с RAG (Retrieval-Augmented Generation). Если кто-то уже делал такое упражнение, будет круто, если поделитесь своим опытом в комментах.

⸻

1. Установка движка для моделей — Ollama

Я выбрал Ollama, хотя есть ещё пара альтернатив. Это такая удобная обёртка, которая позволяет запускать LLM’ки локально без плясок с бубном. Скачать можно отсюда: https://ollama.com/download

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

ollama run llama3.2

Ollama сама скачает указанную модель при первом запуске.

Список всех доступных моделей — тут: https://ollama.com/library

Я себе поставил:
- llama3.2
- gemma3
- deepseek-r1

Все 3 модели достаточно бодро работают на MacBook Pro M4 Pro, 24GB. Выбирал скорее интуитивно. Как сравнивать модели по качеству результатов в конкретных задачах — это пока один из самых интересных вопросов для меня 🤷‍♂️


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

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.2",
  "prompt": "Why is the sky blue?",
  "stream": false
}'

Соответственно, в терминале, Postman, VS Code и всём, где вам удобно, уже можно пользоваться моделью. Подробнее про API (оно не OpenAI совместимое!) вот тут https://github.com/ollama/ollama/blob/main/docs/api.md

⸻

2. Добавляем “нормальный” интерфейс

Но я хотел что-то попроще, чем API-запросы, поэтому добавил ещё Open WebUI — веб-интерфейс, похожий на ChatGPT. Тут тоже всё просто, хотя сначала вам нужно будет поставить Docker — если вы не разработчик, то, скорее всего, он у вас не установлен. Так что начнём с него: https://www.docker.com/get-started/

После установки Docker запускаем Open WebUI:

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

Чуть подробнее об этом можно почитать тут: https://docs.openwebui.com/

Но, вообще, уже сейчас можно открыть в браузере http://localhost:3000/ — и всё должно заработать ✨

Бонус: теперь все модели, которые у вас установлены в Ollama, можно использовать не только через её API, но и через OpenAI-совместимый API, который предоставляет Open WebUI.

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

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

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

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

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

Но если уж очень хочется…
В общем, я сейчас ищу тех, кто уже залез во всё это, но чувствует, что что-то пошло не так. Или просто сомневается:
«А я точно всё правильно делаю? Оно правда должно вот так вот через жопу работать?»

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

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

Когда задача — быстро что-то запустить, мы даже в традиционной разработке часто скидываем тесты в техдолг. Типа: «ну потом покроем, когда полетит». Что уж говорить про запуск какого-нибудь микропродукта — когда цель выкатить MVP за вечер, на коленке.

Так вот, вопрос: тесты в этом контексте — это как вообще? 🤔
Они реально помогают или, наоборот, тормозят процесс?

Интересно услышать ваши мысли на этот счёт 👇

Если честно, пост про 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 по Кипру (т.е. по МСК).

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