Больше года я исследовал то, как LLM'ки могут писать код и как они могут выступать частью продукта. В основном, я делал это в рамках пет-проектов или даже совсем искусственных упражнений, но удавалось поэкспериментировать с ними и для работы в корпорации. Главный вывод, который я сделал за это время — для того, чтобы применение AI-инструментов действительно значимо влияло на результаты или, хотя бы, на скорость их достижения, должны поменяться практически все R&D-процессы. И из-за этого осознания меня мучило дикое FOMO — AI-революция происходит, но я в ней не участвую.

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

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

И я ответил на этот вопрос "Да!"

В этом "Да" сошлось столько разных аспектов, что, кажется, у меня не было другого выбора:
— Я давно хотел стать CTO, но даже когда меня собеседовали на позицию Engineering Manager, я всё равно оказывался продактом;
— Я давно хотел жить в Альпах или рядом с ними, но последние пару лет живу на Кипре, а получить Шенген тут это целая история;
— Со времён работы со стартапами в Microsoft (привет мой 2017й) я мечтал сгонять на WebSummit в роли фаундера;
— За много лет работы в разных компаниях, есть меньше десятка людей, с которыми мне очень хотелось бы снова поработать вместе, и мой нынешний кофаундер один из них;
— Ну и, конечно, я больше года хотел, чтобы AI стал основой моей ежедневной работы, а в этом проекте он и код пишет, и требования, и непосредственно в бизнес-логике принимает активное участие.

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

Stay Tuned!

Самое сложное с активным внедрением AI-агентов — признаться самому себе, что все привычные паттерны нужно пересматривать на адекватность практически каждый день. Новые тулы, новые возможности = новые вопросы: "А как теперь правильно?"

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

А как это выглядит в Cursor? Я сказал ему, сколько будет шагов, и дальше выделяю в Фигме один за другим экраны, прошу реализовать. А уже потом, когда он наверстал всё отдельно, говорю: а теперь отрефактори так, чтобы общие элементы были переиспользуемыми.

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

В общем, чувствую себя первокурсником, которому первого сентября говорят: "Забудь всё, чему тебя учили в школе". Только говорю это я себе сам и практически каждый день. Если честно, очень утомляет 😅

Кто угадает, не раскрывая спойлер, как накосячил Cursor?

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

Созваниваемся вчера с дизайнером посмотреть на то, что у нас получается в проекте. Я показываю, у меня всё красиво, а у него не грузится ни одна картинка. Странно — у меня-то всё работает стабильно в разных браузерах, на разных страницах, и с локальными серверами, и опубликованное в AWS. Значит, у всех всё должно работать нормально? Не мог же Cursor указать адреса файлов на компьютере?

Не мог. Но смог поставить ссылки на localhost. Но почему же этот localhost работал всегда, сколько бы раз я ни перезапускал dev-сервера на разных портах? А потому что это был порт, на котором крутится Figma MCP!

Перед WebSummit вся моя соцактивность перекочевала в LinkedIn.
Мы там уже представили команду, рассказали, с кем хотим встретиться, а я даже успел написать короткий и не очень серьёзный пост про GitHub spec-kit.

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

Так что если вы ещё не подписаны на мой LinkedIn — самое время это сделать и сразу полайкать пост конечно же.
А если знаете кого-то, кто оценит шутку — тегните его там в комментах 🍷💚🇵🇹

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

По факту же выяснилось (в очередной раз), что я вообще не блогер. 😅

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

В пятницу вечером, когда русские фаундеры и инвесторы отходили от WS на тусовке s16, мы с женой тоже поехали выдохнуть — но по-своему: на винодельню Луиша Пату.

Нам повезло не только попасть на дегустацию, но и встретиться и пообщаться с самим виноделом. А ещё мы оказались на еженедельном Happy Hour винодельни, где все сотрудники (их всего около десяти) собираются в пятницу вечером.

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

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

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

Чисто менеджерски хочется сделать из этого вывод про универсальность некоторых управленческих практик. Не важно, чем ты занимаешься, как часто ты выпускаешь новый продукт и когда будет возможность внедрить изменения, для совершенствования тебе нужна площадка, где мнение каждого участника процесса о том, что можно сделать по-другому, будет услышано. Да, конечно, это хорошо работает тогда, когда у тебя достаточно небольшая команда. Но с учётом нынешнего уровня развития технологий, я всё больше верю в силу небольших команд! Мы, например, верим, что в Aivaly не должно быть больше 10 FTE.

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

P.S. Про винную часть этой истории можно почитать здесь.

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

Конечно да! Понимать, как AI-driven IDE ускоряет именно твою работу, — это уже базовый навык. А самое главное: эффективность твоей работы растёт пропорционально времени, которое ты проводишь в конкретном туле. Чем больше ты в нём живёшь, тем лучше понимаешь его сильные стороны, ограничения и моменты, когда ему точно доверять не стоит. Так что начинать нужно было ещё вчера.

Плюс, такие вещи как Cursor или Claude Code уже становятся важными ключевыми словами в резюме. Сейчас все хотят, чтобы сотрудники были AI-first: продакты, аналитики, разработчики, тимлиды. Добавить что-то AI-ное в резюме и уметь уверенно рассказать, как тебе помогают новые инструменты — это прям must. Немного скепсиса тоже не помешает: если нанимающий менеджер не видит ограничений AI, которые видишь ты, — возможно, это тревожный звоночек 🚩


Но хватит прелюдий. Теперь по делу. Фронтендер, если ты ещё не пробовал AI-driven разработку — вот топ-5 вещей, с которых стоит начать прямо сейчас:

💻 Поставить AI-driven IDE. Это может быть триалка Cursor или Windsurf, а может быть Google Antigravity (он пока полностью бесплатный) .

✨ Открыть свой старый проект и попросить IDE отрефакторить компонент. Причём в трёх вариантах: Ask, Agent и Plan. Сравнить поведение и уровень контроля над изменениями.

⚙️ Разобраться, где задаются глобальные правила IDE, а где — проектные. Вписать туда свои принципы разработки и конкретные версии инструментов. Посмотреть, когда агенты следуют им, а когда отступают.

🧪 Подключить Figma MCP и попросить IDE заимплементить выделенную область. И обязательно проверить, что картинки не тянутся с фигмовского локалхоста, а то будешь как я вот тут.

🙃 Подключить Chrome DevTools MCP и заставить агента самому проверить в браузере то, что он только что реализовал. Рассказать мне в комментах, что из этого вышло

Уверен, после этих пяти пунктов вопрос «а оно мне надо?» сменится на азартное: «нет, я заставлю тебя понять, чего я от тебя добиваюсь!» Ну а со временем вы точно сработаетесь и станете классной командой 🤖🧑

А вы бы что добавили в этот список для фронтендера?
И стоит ли собрать такие же списки для других ролей?

У меня в гостях сейчас один из главных AI-инженеров recraft и, естественно, каждый вечер мы с ним обсуждаем подходы к работе с LLM’ками, промт-инжиниринг, вайбкодинг и другие подобные вещи.

Вчера он поделился со мной методикой вайбкодинга проектов, которая прошла мимо меня.

Суть простая:
— никакой IDE, только чат с LLM 🤖
— весь репозиторий кидается в контекст одним файлом собранным через gitingest
— в ответ тоже получается один большой файл со всем кодом

Дальше начинается самое интересное:
— этот файл можно отнести в другой чат и попросить найти уязвимости или ошибки 🔍
— можно в разных LLM получить несколько таких файлов и уже третьей LLM’кой попросить их сравнить
— потом «победивший» файл просто загружаешь в свой проект и надеешься, что LLM-ки тебя не обманули 😅

Интуитивно мне этот подход не очень нравится — я в нём теряю последнюю иллюзию контроля над результатом. А вы как думаете — уже можно доверять LLM’кам целые репозитории? 🧑‍💻💭

Если вы пользовались таким подходом, расскажите, как оно!

Завтра выходит первый за несколько лет существенный апдейт седьмой Gran Turismo, и я уже знаю, на что уйдут мои выходные. Буду экспериментировать с телеметрией! Жаль, что её, скорее всего, не получится просто выгрузить, поэтому протестируем, как LLM-ки справятся с фотками экранов с этой телеметрией. Интересно, что из этого получится!

PS: Ну и да, ребята, как всегда, молодцы — умудряются продавать одно и то же несколько раз. Вместо шин Michelin теперь везде будут шины Dunlop. А на управление это как-то повлияет, как думаете?

Вы когда-нибудь задумывались о том, что AI‑assisted IDE — это не только инструменты вайб-кодинга, но и очень мощные тулы для работы с требованиями и для решения операционных задач? 🤔

Я долго смотрел на Cursor исключительно как на инструмент разработки. И даже когда кто-то говорил, что в нём можно собрать классного бизнес-ассистента, мой мозг сопротивлялся и говорил — ну это же вообще для другого!

А потом я наткнулся на GitHub spec-kit — и всё внезапно сложилось. Использовать такие IDE (или даже CLI-утилиты Gemini и Claude Code) для ведения документации оказалось удивительно удобным. Мне давно хотелось иметь интерфейс, в котором LLM задаёт уточняющие вопросы, а затем аккуратно интегрирует ответы в существующую базу знаний в репозитории. И это прям оно! ✨

Я разобрался, как устроен spec-kit, и — спойлер — там нет никакого rocket science 🚀. Просто набор шаблонов, промтов для разных этапов discovery и скриптов, которые запускаются в нужные моменты: что-то копируют, что-то обновляют, что-то коммитят.

Когда у нас появилась задача сопоставлять вакансии с матрицей компетенций — небольшая операционная задача, на которой было не страшно экспериментировать — я понял, что пора собрать свой маленький репозиторий и начать онбордить коллег в GitHub и AI‑IDE. Сейчас там всего два воркфлоу:
- проанализировать вакансию по URL;
- предложить обновления для матрицы компетенций.

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

Да, продактам придётся освоить пару новых инструментов. Ладно IDE, с ней всё просто, а вот Git… коммиты, ветки, пулл-пуш, вот это всё — удовольствие ниже среднего, особенно на старте 😅. Но для регулярных задач этот подход настолько эффективен, что окупается мгновенно. А сколько у продактов нерегулярных задач? Вот, да. Так что берите пару повторяющихся сценариев и прям садитесь собирать под них воркфлоу!

А главное, сейчас идеальное время попробовать. Если пока не понимаете, зачем платить за Cursor, ставьте Antigravity от Google. Он пока бесплатный, а Gemini 3 Pro, который там под капотом по умолчанию, рвёт большинство других LLM во многих задачах. 🔥

Есть желание, но не понимаете как начать? Пишите вопросы в комментах!

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

И на первый взгляд всё выглядит прям прикольно:
- продакт написал требования, сделал Pull-Request;
- LLM'ка его обработала, проверила консистентность с другими требованиями и текущей реализацией, предложила варианты, как именно это запилить;
- я уточнил план реализации и запустил агентов его имплементить.

🤖 На практике первый же вопрос, который вводит меня в лёгкий ступор: а какой флоу выбрать в этом случае для работы с гитом?

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

Пока у меня в голове есть два варианта:

🔧 Костыльный:
- каждый член команды работает в своей ветке;
- не реже, чем раз в неделю, коммитит изменения в GitHub;
- я (ну не прям ручками, а, например, локальным курсором и скриптами) раз в неделю собираю всё в Pull-Request в основную ветку и на нём уже гоняю агентов.

⚙️ Системный:
- объяснить команде концепции веток, push/pull, ревью и CI/CD;
- настроить автоматизацию в GitHub.

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

Собственно, у меня к вам два вопроса:
1. Какой бы путь выбрали вы? Или, если уже выбрали, — поделитесь с чем столкнулись
2. Как вы решаете, сколько времени тратить на автоматизацию и настройку процессов, а сколько — на текущие задачи? ⚖️

Тут на днях подъехало ещё одно подтверждение, что Gemini круче всех. Какие вам ещё пруфы нужны?

В начале этого года у меня довольно спонтанно случился горнолыжный отпуск (🏂 на самом деле ) — и он в очередной раз продемонстрировал разницу между hard skills и soft skills.

Я всю жизнь занимался каким‑нибудь спортом: плаванием, стрельбой, баскетболом, теннисом, картингом, сноубордом, велосипедом. С разной степенью серьёзности и регулярности, но почти все время как-то тренировался. При этом я несколько раз начинал ходить в тренажёрный зал — и каждый раз быстро забрасывал. Потому что скучно. Не скучно стало ровно в тот момент (3,5 года назад), когда стало понятно, что это нужно для здоровья:
— не сходил в зал две недели — болит спина;
— ходишь регулярно — чувствуешь себя заметно лучше.

В этот момент мотивации ходить в зал стало больше, а времени на остальные виды спорта — меньше. Но я сделал интересное наблюдение.

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

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

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

С AI сейчас ровно та же история 🤖

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

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

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

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

Мой главный лозунг прошлого года - забудь то, как ты работал раньше!

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

Первая моя поделка совместно с AI — serverless бекенд для телеграм-бота. Мне казалось это очень прикольной идеей — у тебя нет крутящегося где-то сервера. Нет клиентов — нет оплаты. Придёт много клиентов — оно отмасштабируется полностью само. И поэтому первый бекенд для aivaly я собирал по той же схеме: DynamoDB в качестве базы данных, lambda — в качестве обработчиков, API Gateway в роли маршрутизации. 🛠

Работает стабильно, управляемо и даже курсору довольно несложно разобраться, где что лежит и как это правильно развивать. Но есть проблема — без поллитра годов опыта в AWS ни в чём не разберешься. Если хотя бы месяц не залезал в проект, то погрязнешь в логах и т.д. А главное — когда кофаундеры приходят с радостной новостью, что они что-то навайбкодили в lovable и уже можно показывать клиенту, то ты с кислым лицом отвечаешь, что их вот этот модный supabase нам не подходит для прода. 😐

На Новый Год у меня было время немного остановиться и подумать — а что я делаю не так? Что нужно поменять, чтобы не лишать коллег возможности вайбкодить? Как сделать нашу инфраструктуру более дружелюбной и прозрачной для всех? Ну и заодно — как сделать так, чтобы мы безболезненно могли быстро поднимать какие-то региональные сервисы, где будут учтены особенности местного законодательства?

В общем, я пошёл смотреть на supabase и понял, что он офигенный! В нём есть всё, что нужно для простого CRUD-бекенда из коробки. Остаётся только аккуратно управлять схемой данных и правами через миграции. Заводишь таблички — и к ним уже можно делать фронт хоть через REST, хоть через GraphQL.

Но у нас всё-таки не просто CRUD-бекенд. Есть ещё асинхронная логика обработки всякого разного. Значит, нужен оркестратор процессов. И тут на сцену выходит n8n. Его можно поселить на той же машине на тот же Postgres. А запускать workflow можно либо через webhook к нему, либо через дополнительную табличку, в которую Supabase будет по разным триггерам класть задачи на обработку.

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

А вы как в своих проектах выстраиваете инфраструктуру? 👀

Давно вы сталкивались с продуманным UX в мире обычных вещей вне девайсов и приложений? 🤔

Вещь, которая заставила меня написать этот пост — маленькая наклейка. Мне, правда, не удалось сделать фото — в фокусе оказался 🐶 (положу его в комменты). Да, это рулон пакетов для прогулок с пёселями, а в конце рулона — наклейка с предупреждением: "осталось 3 пакета!". И, блин, это офигенно удобно. Все, у кого есть собака, знают, как бывает сложно понять перед прогулкой, сколько там осталось пакетиков — один, два, а может, ещё четыре?

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

А у вас как? Делитесь, что вас приятно удивляло в последнее время👇

На прошлой неделе созвонился с товарищем поделиться своими вайб-кодерскими подходами, лайфхаками и находками. И первый раз услышал персональный и очень положительный отзыв на то, что называется skills 🤔

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

А в выходные у меня обновился Cursor и тоже что-то написал про skills. Ну, тут я уже не выдержал и пошёл смотреть, что же это такое и как это работает 👀

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

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

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

Реально, как в Матрице: "Я знаю кунг-фу" 🥋✨

P.S. Ссылки на документацию про скиллы в разных инструментах в комментарии.

У меня всегда была странная привычка: когда я набирал «ok», я обязательно переключался на английскую раскладку. Это не очень удобно и тормозит процесс, но мне было важно, чтобы это было именно «ok», а не куцый русский «ок». 🤷‍♂️

Рационального в этом было немного. Но благодаря таким людям как я, теперь примерно в половине случаев, когда я прошу gemini на русском поставить таймер, то в ответ слышу не "ока", потому что кто-то писал ОК заглавными буквами в русской раскладке, а полноценное "окей". 😄

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

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

Поэтому я довольно давно перенёс TDD-подход в работу с Codex, Claude Code и Cursor (если ваша вайб-кодинг-тула не начинается на C — даже не предлагайте мне её 😄) — и вижу, насколько стабильнее получается результат, если система нормально покрыта тестами на разных уровнях (а не просто “написали миллион юнит-тестов”).

Но я также понимаю, что выше написано что-то на эльфийском для большинства вайб-кодеров 🙂

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

Хочу понять, как вы с этим справляетесь

Вот здесь можно забронировать слот на 20-минутный созвон: https://calendar.app.google/eueW7N9Sn2YDLu8XA

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

С конца января я почти перестал сюда писать, но не потому что ничего не происходило, а наоборот, потому что происходило слишком много всего.

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

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

И первые месяцы это действительно было драйвово.

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

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

Один из первых вопросов, на которые Игорь Рябенький просил честно себе ответить, звучал очень просто: "Готов ли ты заниматься этим 10 лет?" Я честно ответил "нет". Но попытался себя убедить, что, возможно, достаточно того, что другие ребята из команды готовы.

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

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

И здесь самая ироничная часть. Я много лет сам говорил знакомым стартаперам, что на ранней стадии им не нужен CTO. Им нужен сильный hands-on инженер и иногда кто-то со стороны, с кем можно обсудить сложные решения — fractional CTO или technical advisor. Но фуллтайм нужен тот, кто в первую очередь деливерит, а не объясняет как и что должно быть сделано. Да, сейчас с LLM'ками трансформация ролей происходит очень быстро. Но как показала практика, на этапе поиска своего места на рынке, крутые продакты становятся гораздо более эффективными вайбкодерами, чем технический менеджер. По крайней мере, если для этого менеджера это просто прикольный проект, а не задача, на решение которой он готов потратить ближайшие 10 лет своей жизни.

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

Желаю ребятам успехов, а сам двигаюсь дальше.

Куда? Скоро расскажу (но спойлеры уже можно найти в LinkedIn)

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

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

А возвращаясь к мысли из прошлого поста про unfair advantage, я понял, что моя ценность в финтехе сильно выше, чем вне его, так что это точно должен быть финтех. Но не совсем же отказываться от своих мечт? Так что это должен быть финтех, который готов строить агентские процессы разработки, переосмыслять привычные штуки и не тащить за собой тонны legacy.

А такое точно бывает? Вот и я думал, что нет и собесился в разные большие компании с релокацией в Лондон.

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

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

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

Но самое кайфовое — это команда. Все максимально AI-driven, постоянно что-то пробуют, экспериментируют, обсуждают. Мне кажется, за последние недели я попробовал больше нового, чем за многие предыдущие месяцы. Ну, знаете ли, unlimited token policy этому очень способствует.

> Эй, клод, закрой таску про пост в ТГ в Linear, и сформулируй темы для следующих постов!

Я постараюсь рассказывать про всё это регулярно и подробно. Но пока времени катастрофически не хватает, потому что помимо погружения в новую для себя сферу я параллельно готовлюсь к переезду в Барселону 🇪🇸

Такой visa sponsorship мне очень по душе!