Мысли про вайбкодинг

0️⃣ Форматирование кода? Спасибо, не надо

В командной работе мы используем prettier / go fmt и прочие «format on save» линтеры, чтобы автоматически форматировать код в едином стиле. Это помогает не спорить про запятые и пробелы в код ревью. Но в агентном кодинге это вредит. Почему? Почти все агенты редактируют код через различные search-replace patch подходы, и если уже «запомненный» моделью код непрозрачно для неё переформатируется, это сбивает якоря, на которые LLM опиралась.

1️⃣ Режим жёсткой дисциплины

Поэтому у нас вместо косметики – жёсткая дисциплина.

Здесь статический анализ именно кода важен как нигде. Автоматический моментальный фидбек для модели, что сгенерированный код не совпадает с нашими ожиданиями. И в отличие от обычной работы в команде, где мы стараемся найти баланс, здесь нужны максимально строгие и упрямые правила. Буквально шаг влево, шаг вправо – и модель отправляется переделывать. Чем строже правила (full strict TS, dependency cruiser, eslint правила на цикломатическую сложность и т.д.) — тем меньше шансов, что спустя пять промптов у вас появится импорт-матрешка или inline-тип, о котором сам агент забудет через минуту.

2️⃣ Однопромптовый маркетинг

Все мы видели истории в духе «эту полноценную CRM систему GPT-5 сгенерировала всего за один промпт!». На практике же вайбкодинг в пустой директории в стиле «привет, создай мне простое приложение для…» оказывается путём в никуда. С каждым запросом растёт экспоненциальный хаос, и очень быстро в коде не можешь ориентироваться не только ты, но и сама модель уже слабо понимает, как код устроен и тем более как вносить в него сложные правки. MVP так и останется MVP навсегда, даже не факт, что рабочим.

3️⃣ Придется поработать

Получается теперь чтобы повайбкодить, еще до самого первого промпта нужно забутстрапить немаленький сетап. Сейчас для меня это
- супер строгая и максимально type-safe конфигурация TypeScript
- большой набор «людоедских» eslint правил (от max-lines-per-function до complexity < 10)
- dependency cruiser что следить за low coupling и high cohesion
- npm-package-json-lint для проверки package.json
- настроенный vitest, чтобы модель сразу понимала какие тесты и как писать
- и всякое другое по мелочи

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

4️⃣ Всё своё ношу с собой

Но только прежде чем кодить, нужно еще не забыть принести свои любимые кастомные правила для Copilot/Cline/Cursor. В каждый проект теперь «инсталлируется» последняя версия проверенных правил, которые позволяют агентам писать код чуть лучше чем из коробки. Интересное наблюдение: эти правила в каждом проекте со временем мутируют и обрастают уникальными дополнениями, релевантными только для конкретного контекста.

• • •

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

Выпуск подкаста со мной уже на ютубе! Бежим смотреть 🏃‍♂️

https://youtu.be/fRqU2JtMlWM

И подписывайтесь на сам канал нашего Lavka Tech подкаста, скоро там будут новые выпуски и новые герои

https://www.youtube.com/@lavkatechteam

Simplicity Is Fucking Hard

Вечерний кинопросмотр 🍿

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

Точно будет интересно для тех, кто интересуется UX и продуктовым дизайном.

Видео o Notion, и то как они потратили 200+ часов на продумывание одной кнопки, очень сильно срезонировало с нашим опытом редизайна в Лавке, где тоже не одна сотня часов была потрачена на решение ряда UX проблем. Те самые мелочи, которые никто не замечает, но именно они делают пользовательский опыт действительно sleeky 💅

А вы придаёте значение таким деталям?

В редакцию поступил вопрос 📬

Так чем же на самом деле занят руководитель разработки, помимо one-to-one и созвонов? 😄 Да, в подкасте мы не успели раскрыть этот вопрос полностью.

Решили, что это отличная тема для совместного эфира. В это воскресенье Дима Бровка и я обсудим её в прямом эфире здесь, в телеграм.

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

Готовьте ваши вопросы и пишите их в комментариях уже сейчас – обязательно разберем их на стриме!

Когда: 20 июля, в 17:00
Где: здесь, в телеграме

Начинаем 🏃‍♂️

https://news.1rj.ru/str/brovkaio?livestream=daf72ba49534c66bdc

1️⃣2️⃣3️⃣4️⃣

Что уже было в канале

Привет! 👋 За последние пару месяцев с момента создания канала накопилось некоторое количество мыслей и постов. Для тех, кто присоединился недавно (и для тех, кто хочет освежить в памяти), собрал небольшой дайджест ключевых постов.


1️⃣ О лидерстве и командах

Почему «Culture eats strategy for breakfast»
Разбирали почему директивы сверху зачастую проваливаются, а настоящие изменения растут снизу.

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

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


2️⃣ Про код и технологии

Реалии «вайбкодинга»
Как же на самом деле выглядит работа с LLM-ассистентами? Спойлер: одного промпта «сделай мне красиво» недостаточно (даже с chatgpt-5).


3️⃣ Про личный бренд и публичность

Зачем Андрей вообще пишет?
Все началось с простого вопроса к ChatGPT о себе и неутешительного ответа. Это стало осознанием что в эпоху AEO личный бренд — уже не опция, а необходимость.

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


4️⃣ Личная рефлексия и находки

Одержимость деталями
Делился видео о том, как команда Notion потратила 200+ часов на одну кнопку. Это очень срезонировало с нашим опытом редизайна в Лавке.

Мое экранное время
Проверил свою интуицию и выяснил, что Telegram занимает у меня не 80%, а «всего» 40% времени.

Челенджат первым законом Паркинсона?

Работа заполняет всё время, отпущенное на неё

На самом деле Паркинсон писал сатиру на бюрократию, а не учебник по менеджменту – на этом, в целом, можно и закончить 😅 Но боюсь, ваши оппоненты скажут: «Звучит же здраво! Режем буфер и втискиваем ещё один проект».

Этот аргумент подменяет управление рисками иллюзией эффективности.

Давайте соберём линию защиты 👇


Риск-менеджмент, а не «жир»

1️⃣ Во-первых, «закон» Паркинсона, если и работает, то на уровне отдельных задач, провоцируя «студенческий синдром». Проект — это система, и ему нужен проектный буфер для управления неопределённостью. Идея критической цепи учит нас забирать скрытые буферы из каждой задачи и объединять их в один общий, управляемый «щит».

2️⃣ Во-вторых, надо перестать называть сроки одной цифрой. Лучше диапазонная оценка: оптимистично, реалистично, пессимистично. Я обычно это оформляю как soft/hard-дедлайны. Soft — цель команды. Hard — обязательство перед стейкхолдерами. Зазор между ними — наш управляемый буфер.


Математика рисков

План «под завязку» не ускоряет команду, он переносит весь риск в конец квартала. Почему?

🟥Факт = базовая оценка + сумма неотрицательных задержек
🃏Базовая оценка – время, которое нужно при идеальных условиях.
🃏Сумма задержек – сумма рисков, которые «срабатывают» с некоторой вероятностью.

Сокращая буфер, мы не трогаем физику рисков, но сдвигаем линию обреза влево, ближе к «телу» распределения — и тем самым захватываем больше вероятности в «зоне провала».

Вероятность
↑
│▓
│▓▓
│▓▓▓
│▓▓▓▓│░░░
│▓▓▓▓│░░░░░░░░
│▓▓▓▓│░░░░░░░░░░░░░░░░░░░░░░
└────┼────────────────────────► Дни
│ ◄─ [ зона провала ] ─►
дедлайн

Здесь по вертикали – вероятность завершить проект за n дней, а по горизонтали – длительность проекта в днях.

Площадь справа от дедлайна — это «зона провала» (вероятность не уложиться).

Если дедлайн поставить на уровне идеала (ноль рисков реализовалось), то зона провала шире – риск срыва выше.
Сдвигая дедлайн правее (добавляя буфер), зона провала сужается – риск ниже.


Делаем буфер прозрачным

Чтобы развеять подозрения в «просиживании штанов», сделайте буфер частью регулярного процесса:

🔴Еженедельно показывайте график «сгорания» буфера. Быстрое сгорание — сигнал тревоги для всех. Медленное — повод для оптимизма.

🔴Договоритесь, что если к середине проекта потрачено меньше трети буфера, мы анонсируем целевую дату раннего старта следующего проекта. Это показывает, что буфер — инструмент ускорения всего портфеля проектов.

🔴Введите привычку любое изменение требований проводить через явный размен – чем платим? Сокращением буфера, вырезанием другой фичи или сдвигом hard-дедлайна.


Но разве это амбициозно?

– Да кто вообще захочет работать в команде где нет челенджей!

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

Отказываться от риск-менеджмента, чтобы влез ещё один проект — это просто перенос риска на конец квартала и на соседние команды, а не демонстрация big balls.

• • •

А как вы защищаете проектный буфер? Удается убеждать, что это не роскошь?

Руководители тоже уходят

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

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

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

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

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


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

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

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

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


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

The /llms.txt file

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

Уже на автомате я быстро дописываю в начало URL префикс pure.md/, жму Enter и получаю чистый markdown-текст страницы без рекламы, сайдбаров и прочего текстового шума. Простая и тем самым гениальная идея: делать сервисы-прокси, которые парсят страницы и выдают только нужный контент. Уверен, что таких сейчас уже десятки, если не сотни.

До этого какое-то время я пользовался r.jina.ai/ — примерно то же самое, но, сами понимаете, разница между 8 и 10 символами решает многое =) Если знаете сервисы с ещё более короткими URL — делитесь в комментариях. Это, конечно, ирония – про разницу в 2 символа; скорее, в какой-то момент качество преобразования в чистый текст у https://pure.md было получше, на мой взгляд.

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

С появлением ChatGPT и других LLM-моделей, а в частности функций web search в них, появился пропозал по стандартизации специального .txt-файла в корне сайта — /llms.txt. По аналогии с robots.txt. Идея в том, что если на сайте есть такой файл, то он содержит структурированный контент, который могут использовать LLM-модели без необходимости парсить HTML-страницы.

Так как в последнее время я довольно много ковыряюсь с Claude Code и Anthropic SDK в целом, то уже и представить не могу, что бы я делал без возможности просто зайти на https://modelcontextprotocol.io/llms-full.txt и «прикопать» к себе целиком 1,2 МБ чистого текста документации. Очень удобно. И теперь всё чаще я на удачу проверяю наличие /llms.txt на других сайтах и расстраиваюсь, когда не нахожу их.

Неудивительно, что в процессе популяризации этой идеи появляются и сервисы-каталоги, которые собирают сайты, уже поддерживающие такие файлы — https://directory.llmstxt.cloud/

*️⃣Ну и, конечно же, я тоже иду в ногу со временем, поэтому добавил поддержку /llms.txt и к себе на сайт:

https://vavilov.dev/llms.txt 😄