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

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

Решил поискать что-нибудь готовое. Спросил у Perplexity, какие тулы есть для промт-инженеров. Ведь если уже появилась целая отдельная профессия, то наверняка есть и специальные сервисы. Оказалось, что действительно есть много инструментов: кто-то умеет версионировать промты и проксировать запросы к LLM’ке, кто-то предлагает Prompt IDE или CMS (так и не понял, это одно и то же или нет), кто-то пытается улучшать промты с помощью AI.

Из того, что нашлось, больше всего по описанию мне понравилась Agenta. В ней есть всё, что мне хотелось получить:
🛠 Инструменты для тестирования промтов, включая Chain of Prompts и RAG.
🤖 Автоматическая оценка результатов, в том числе на смысловую схожесть, плюс разметка вручную через удобный интерфейс.
🌐 Проксирование запросов в LLM для использования актуальных версий промтов.
⚙️ API-доступ к последним версиям промтов для использования в своих запросах.

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

━━━━━━━━━━━━━━━━
P.S. Кстати, в том проекте, с которого начались мои поиски инструмента, надо было оценивать результат обработки не текста, а картинки. И вот под эту задачу я так ничего готового и не нашёл. 🤷‍♂️

Летел сегодня в командировку и по дороге столкнулся с двумя вещами, которыми хочу поделиться.

Первая - маленькая, но очень порадовавшая фича то ли последнего Андроида, то ли конкретно последнего Пикселя. Когда после включения авиарежима включаешь WiFi или Bluetooth, появляется уведомление, что при следующем включении авиарежима, он запомнит текущее состояние. Неужели, наконец-то включение авиарежима не будет обрывать прослушивание контена? Меня это очень сильно раздражало, особенно, когда я летал с короткими пересадками. Кстати, это я просто слишком долго на древнем Хуавее с неактуальным Андроидом сидел, или это всё-таки Гугл красавчики?

А вот кто точно не красавчики в IT сервисах, так это Cyprus Airways или их подрядчики. Как это сейчас бывает почти у всех авиакомпаний, они запустили свою Inflight Entertainment System, к которой можно подключиться по WiFi. Всё бы хорошо, но когда подключаешься к бортовой сети с телефона, перебросить открывшуюся страницу в Chrome не получается. Ну, ничего, для таких случаев они сделали QR-код на флаерах, вложенных во впереди стоящее кресло. Правда, зачем-то сделали его через сокращатель ссылок bit.ly. И, сюрприз-сюрприз, без Интернета ссылка не открывается 😂 Причем, я вот прям отлично представляю, откуда взялся именно такой QR-код, как тз на него поставили, как сгенерили и как протестили.

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

А вас кто и какими фичами порадовал за последнее время?

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

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

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

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

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

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

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

Я несколько месяцев помогал другу найти CTO для нового high-load сервиса. Этот проект оказался, пожалуй, самым интересным, что я делал за год, потому что включал в себя совершенно разные задачи:
✅ Декомпозиция продукта
✅ Определение стека технологий
✅ Выбор архитектурных подходов
✅ Написание вакансий
✅ Ну и, конечно, много-много интервью

Так как мой друг хотел нанять действительно крутого CTO, я проводил интервью не один. Мне повезло работать в паре с Сашей Кирилловым (CTO Evrone, член программного комитета HighLoad++), который знает всё о разработке сложных IT-проектов — от системного дизайна до управления командами. Особенно меня впечаталяли его комментарии к архитектурам сервисов пользовательских балансов, которые предлагали кандидаты.

После 10+ интервью я разобрался в разных архитектурных решениях, их плюсах и минусах. И знаете, что грумит сейчас моя команда в Tabby? Да, мы проектируем Ledger-сервис! То есть что-то очень близкое по смыслу. Все обсуждения про event sourcing и кэширование, которые мы вели осенью, теперь выходят для меня на совершенно новый уровень. Потому что теперь это не просто теория — это реальный сервис, с которым мы будем жить годами.

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

Поэтому я возвращаюсь к этой практике! Пиши мне, если ты:
🔹 Хочешь честный разбор своей IT-продуктовой идеи — покажу подводные камни, которые ты не замечаешь, и короткие пути, о которых не знаешь
🔹 Планируешь запустить IT-бизнес в одиночку (особенно без опыта в коде) и хочешь эффективно использовать LLM — помогу сэкономить часы (а может и дни!), объяснив тебе, что на самом деле ты делаешь и как правильно формулировать свой запрос к AI-ассистенту про это

📅 Консультации — по утрам в рабочие дни с 8 до 9 (по Кипрскому времени), начиная со следующей недели. Позже сделаю лендинг и Calendly, а пока просто пиши в личку 👉 @dmgritsan!

Давайте делать крутые вещи вместе! 🚀

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

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

А потом случилась командировка в Дубай.

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

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

А потом я вернулся домой. Спокойствие, 80+% рекавери, всё на своих местах и в своём ритме. Но и от пары новых идей, и от уже объявленного возвращения к консультациям никуда не деться.

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

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

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

Что общего у сырников и медитации?

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

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

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

Из этих троих сырники — мой фаворит. Потому что это:
💪 Полезный завтрак (качковская еда, по версии моего тренера)
🍽️ Сытный завтрак (не хочется есть уже через пару часов)
🎨 Гибкий завтрак (топпинги под настроение)
😊 Завтрак, который радует меня
❤️ Завтрак, за который я получаю благодарность от жены
🏡 Скрепа по версии очень большого числа понауехавших

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

А на таком топливе уже можно и горы сворачивать 🚀

P.S. Если кто-то хочет напроситься на сырники в выходные, считайте это знаком.

Сегодня, наводя порядок в своих AWS-аккаунтах, удаляя лишние Lambda-функции и очереди, вспомнил, как несколько лет назад хакал cron-таски в AWS.

Летом 2022 года, когда записаться на шенген в Москве стало практически невозможно, но привычка ездить в Европу у жителей столицы ещё не пропала, появились всевозможные “помогаторы”. Они за деньги записывали людей в консульства на редкие свободные слоты.

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

Небольшой ресёрч показал: проще всего пробиться к итальянцам. Я быстро разобрался, как мониторить свободные окошки, и для начала решил просто слать себе уведомления, когда они появлялись. Парсер был простым Python-скриптом, так что я развернул его в AWS Lambda и настроил запуск раз в секунду через EventBridge (читай: cron-таски, но для Lambda).

На следующий день стало ясно: окна появляются регулярно, но живут меньше секунды. Явно идёт война ботов 🤖💥.

Из чего я сделал два вывода:
1️⃣ Записывать меня тоже должен бот.
2️⃣ Мониторить слоты раз в секунду — слишком медленно.

Но как запускаться чаще, если в cron минимальная размерность — секунда?

Вспомнил, что AWS Lambda умеет триггериться при появлении сообщений в SQS, и немного доработал скрипт. Теперь перед началом парсинга он проверял, в какой доле секунды находится. Если это было до 0.75, то он слал в очередь новое сообщение с таймаутом видимости 250 мс.

В результате, если первый вызов приходился на начало секунды, скрипт отрабатывал до 4 раз в секунду. Чаще всего — действительно 4, иногда 3.

📈 Количество найденных окон увеличилось примерно вдвое. Но ненадолго.

Сначала подтянулись конкуренты. Потом и само консульство поставило защиту против таких вот “мамкиных хакеров” 😅. Но к тому моменту я уже успел податься на визу и запланировать отпуск, из которого, кстати, в Москву так и не вернулся.

А вам приходилось запускать что-то чаще, чем раз в секунду? Как решали такие задачи? 🤔

Интересно, кстати, почему ChatGPT при редактировании текстов на русском ставит пробелы вокруг длинного тире, а на английском нет 🤔

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

Поэтому бесконечный поток AI-тулов вызывает у меня смешанные чувства. С одной стороны, хочется сравнивать новинки с тем, что я уже использую. Вот появился DeepSeek, а я так его и не потестил. Вот новая модель Claude — тоже интересно. Да и Llama самому развернуть давно хочется. Но с другой стороны, у меня уже есть простой и рабочий алгоритм: поискать — в Perplexity, порассуждать — с ChatGPT. Так зачем менять то, что уже работает? 🤷‍♂️

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

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

И вот, для регистрации бизнеса в банке мне нужно было срочно собрать простой лендинг и захостить его на своём домене. Я решил не мучить Cursor, а поискать специализированные решения. Мне посоветовали три сервиса: carrd, v0 и lovable. Я сразу выбрал lovable, потому что увидел, что в нём есть интеграция с GitHub, а значит, не будет вендор-лока. Решил попробовать и, честно говоря, остался доволен.

За 5 минут у меня получился чистый, аккуратный лендинг. Правда, сначала AI сгенерировал его на Node.js, и я уже даже начал мучительно вспоминать, как это деплоить. Но потом понял, что мне же достаточно тупого HTML-файла, попросил его переделать — и вуаля! Он даже favicon сделал в формате SVG и вставил прямо в код. 🔥

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

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

💡 А без каких AI-инструментов вы уже не представляете свою жизнь? Поделитесь в комментах! 👇

Буду последовательным. Раз уж я тут хвалил Apple TV за удобную UX-фишку с субтитрами при перемотке назад, то теперь пришло время Netflix. Но это будет пост возмущения. 😤

📺 Недавно вышел новый сезон Formula 1: Drive to Survive. Я слежу за Формулой без фанатизма, поэтому после окончания сезона, даже зная результаты, с удовольствием смотрю этот сериал. Отличный, атмосферный, ненапряжный.

Вчера за обедом решил включить первую серию нового сезона. Открываю Netflix на Google TV, нахожу превьюшку с плашкой “new season”, жму… и получаю первую серию, но не нового сезона, а вообще всего сериала. 🤦‍♂️

Ладно, захожу в меню Episodes and More. Список сезонов идёт в обратном порядке – от последнего к первому. Думаю: значит, мне нужна самая нижняя серия – она должна быть первой в новом сезоне. Запускаю. Смотрю. Рассказывают, что сезон 2024 был невероятно крутым, интрига сохранялась до последней гонки! Ну, нормальный такой тизер для старта сезона. А через 5 минут вижу 21-ю гонку сезона и понимаю, что что-то не так. 😳

🕵️‍♂️ Пытаюсь выяснить, какая это серия, но Netflix упрямо не показывает её номер, только название – “End Game”. Возвращаюсь в Episodes and More, сверяюсь с предыдущими сезонами, которые смотрел… и осознаю: сезоны идут в обратном порядке, а серии в них – в прямом! В итоге “нижняя” серия – это не первый эпизод сезона, а последний.

К счастью, шутки с предсезонной пресс-конференции Mercedes F1 быстро подняли настроение. 😄 Но осадочек остался.

Короче, будьте как Apple TV, не будьте как Netflix. Хотя, если честно, у Apple тоже есть проблемы с навигацией по сериалам. Но там хотя бы номера серий есть.

Провел на этой неделе первую за долгое время менторскую сессию для менеджера из IT. Самая любимая часть таких встреч для меня — это момент, когда я задаю в конце вопрос: “Что ты уносишь с собой?” Каждый раз этот вопрос немного страшно задавать — а вдруг человек скажет, что ничего? Но чаще всего ответ оказывается гораздо глубже и интереснее, чем я сам предполагал.

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

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

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

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

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

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

"I identify myself as non-binary. Non product, nor engineering manager."

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

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

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

Так, ну, почему non product разобрались, а теперь почему nor engineer?

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

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

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

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

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

Начнём с вина. Пару дней назад мы с женой были на экскурсии и дегустации у одного из старейших производителей игристого вина в Пьемонте — Contratto. Их винные подвалы входят в список всемирного наследия ЮНЕСКО. И технология производства максимально соответствует этим подвалам.

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

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

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

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

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

⸻

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

Мне бы очень хотелось найти что-то такое и в IT. Чтобы можно было сказать: “Да, мы знаем, что это не самое эффективное решение, но именно так мы хотим это делать. Потому что можем. Потому что нравится. Потому что в этом наша суть”.

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

Хотел, как обычно, написать пост при помощи ChatGPT — закинуть в него не очень структурированный поток мыслей и попросить причесать. В общем, содержательного поста сегодня не будет, потому что я не могу перестать смеяться (или, как написал бы ChatGPT — ржать).

Просто полюбуйтесь, как он структурировал. Моя версия абзаца:

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

Версия чатажпт:

Да, в пет-проектах часто было иначе.
Можно было сразу херачить фичу,
ведь ты же “и так всё понимаешь” (нет).

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

Тот самый пост, в который 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 за вечер, на коленке.

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

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