Про покрытие тестами
В интернетах удивительно мало информации о том, как технически устроить повышение уровня покрытия тестами на проектах, где по историческим причинам их писать было не принято. Обычно тесты пишут большие и крутые ребята, которые как-то раз это завели у себя и не видят смысла зачем об этом рассказывать. А если и рассказывают, то это непросто на себя переложить.
Вот вы решили писать тесты. Предположим, что вы придумали весь стек на котором будете это делать. Хотя это тоже ещё та задача. Там и фреймворков много, и подходов в них, и даже каких-нибудь ассёрт-библиотек не одна и не две. Основная сложность не в том, что тесты писать нельзя, а в том, чтобы люди их реально писали.
Единственная понятная мне метрика – процент покрытия тестами строк кода. Для его сбора есть JaCoCo, и есть Kover. Первый – индустриальный стандарт, но не очень работает с котлином. Второй – хоть ещё не вышел в стабильной версии, но от JetBrains, с котлином в уме, и как будто сильно проще. Поэтому делаем ставку на него. Списать с документации просто не получится. Добавить сбор покрытия в каждый из ~200 модулей проекта – просто, но чтобы это собрать в один итоговый отчёт приходится повозиться. Сэмплы где-то на дне гитхаба и по знакомым ищешь.
Kover делает отчёты в JaCoCo формате, который довольно популярен, поэтому с какими-то дальнейшими интеграциями всё должно быть одинаково просто. И правда, в GitLab CI разбор этого отчёта добавить довольно легко, например. И вот уже на код ревью в гитлабе начинают подсвечиваться какие-то непокрытые строчки красным и в мёрж реквесте гордо красуется число – 2% покрытия по проекту.😔
И в этом кроется следующая проблема. Что делать-то с этим? Нельзя так просто взять и сказать, что с завтрашнего дня без покрытия 80% мы ваши реквесты не смёржим. Разраб в своём мёрж реквесте вообще не причём, что проект не покрыт. Он должен отвечать только за свой конкретный реквест. Покрытие проекта хоть и интересная, но бесполезная штука, т.к. ты с этим числом ничего не сделаешь. Ладно бы это был новый проект, на котором можно было бы сразу требуемый процент зафиксировать. Но у нас-то старый.
Так я и пришёл к мысли, что ключевая метрика – процент покрытых строк именно на уровне конкретного мёрж реквеста. Мы должны требовать от разработчиков, чтобы они свои новые/изменённые строки покрывали на целевые 80%. А как это сделать, если у нас отчёт на весь проект и GitLab это сам считать не умеет?
Задача, казалось бы, алгоритмически простая – взять дифф, взять JaCoCo отчёт, посчитать количество покрытых строк из диффа относительно всех строк из диффа – вернуть процент покрытия. Наверняка кто-то делал, рискну даже предположить, что есть готовые GitHub Actions или какой-нибудь SonarQube умеет такое делать из коробки. Но что если у тебя их нет?
Поверхностный поиск показывает, что делали. Но решений становится ещё меньше и меньше, для тебя уже сотня звёзд на гитхабе в радость. Есть вот что-то типа такого или такого. Я уж даже не помню что с ними не так, но у меня никто из них не завёлся за несколько часов так как я хотел. Возможно я мало старался, но как будто возня несоразмерна задаче.
Если вы думали, что этот пост без AI агентов обойдётся, то вы ошибались. Я в результате пошёл и за несколько часов сгенерил себе Gradle-таску, которая принимает отчёт по покрытию, хэш коммита, по которому git diff запускает, и матчит строки с отчётом. На выходе одно число – процент покрытия на уровне диффа. И тесты нагенерил. И документацию. И CI конфиги поправил, чтобы запускалось. И это всё работает.
Ну а потом уже дело техники. Можем в danger, например, посмотреть на результат этой таски, похвалить разраба, если всё хорошо / сказать, что можно было бы лучше / сказать, чтобы он шёл и дописывал тесты, иначе не сольётся.
Велосипед – да. Решает задачу – да. Кайфанул ли я пока это писал – да.🤟
А дальше развилка. Или вы мне говорите, что я неправ и надо было сделать так или эдак, накидываете материалов. Или я это простейшее решение собираю в репу на гитхабе, чтобы можно было подключить одной строчкой.
В интернетах удивительно мало информации о том, как технически устроить повышение уровня покрытия тестами на проектах, где по историческим причинам их писать было не принято. Обычно тесты пишут большие и крутые ребята, которые как-то раз это завели у себя и не видят смысла зачем об этом рассказывать. А если и рассказывают, то это непросто на себя переложить.
Вот вы решили писать тесты. Предположим, что вы придумали весь стек на котором будете это делать. Хотя это тоже ещё та задача. Там и фреймворков много, и подходов в них, и даже каких-нибудь ассёрт-библиотек не одна и не две. Основная сложность не в том, что тесты писать нельзя, а в том, чтобы люди их реально писали.
Единственная понятная мне метрика – процент покрытия тестами строк кода. Для его сбора есть JaCoCo, и есть Kover. Первый – индустриальный стандарт, но не очень работает с котлином. Второй – хоть ещё не вышел в стабильной версии, но от JetBrains, с котлином в уме, и как будто сильно проще. Поэтому делаем ставку на него. Списать с документации просто не получится. Добавить сбор покрытия в каждый из ~200 модулей проекта – просто, но чтобы это собрать в один итоговый отчёт приходится повозиться. Сэмплы где-то на дне гитхаба и по знакомым ищешь.
Kover делает отчёты в JaCoCo формате, который довольно популярен, поэтому с какими-то дальнейшими интеграциями всё должно быть одинаково просто. И правда, в GitLab CI разбор этого отчёта добавить довольно легко, например. И вот уже на код ревью в гитлабе начинают подсвечиваться какие-то непокрытые строчки красным и в мёрж реквесте гордо красуется число – 2% покрытия по проекту.
И в этом кроется следующая проблема. Что делать-то с этим? Нельзя так просто взять и сказать, что с завтрашнего дня без покрытия 80% мы ваши реквесты не смёржим. Разраб в своём мёрж реквесте вообще не причём, что проект не покрыт. Он должен отвечать только за свой конкретный реквест. Покрытие проекта хоть и интересная, но бесполезная штука, т.к. ты с этим числом ничего не сделаешь. Ладно бы это был новый проект, на котором можно было бы сразу требуемый процент зафиксировать. Но у нас-то старый.
Так я и пришёл к мысли, что ключевая метрика – процент покрытых строк именно на уровне конкретного мёрж реквеста. Мы должны требовать от разработчиков, чтобы они свои новые/изменённые строки покрывали на целевые 80%. А как это сделать, если у нас отчёт на весь проект и GitLab это сам считать не умеет?
Задача, казалось бы, алгоритмически простая – взять дифф, взять JaCoCo отчёт, посчитать количество покрытых строк из диффа относительно всех строк из диффа – вернуть процент покрытия. Наверняка кто-то делал, рискну даже предположить, что есть готовые GitHub Actions или какой-нибудь SonarQube умеет такое делать из коробки. Но что если у тебя их нет?
Поверхностный поиск показывает, что делали. Но решений становится ещё меньше и меньше, для тебя уже сотня звёзд на гитхабе в радость. Есть вот что-то типа такого или такого. Я уж даже не помню что с ними не так, но у меня никто из них не завёлся за несколько часов так как я хотел. Возможно я мало старался, но как будто возня несоразмерна задаче.
Если вы думали, что этот пост без AI агентов обойдётся, то вы ошибались. Я в результате пошёл и за несколько часов сгенерил себе Gradle-таску, которая принимает отчёт по покрытию, хэш коммита, по которому git diff запускает, и матчит строки с отчётом. На выходе одно число – процент покрытия на уровне диффа. И тесты нагенерил. И документацию. И CI конфиги поправил, чтобы запускалось. И это всё работает.
Ну а потом уже дело техники. Можем в danger, например, посмотреть на результат этой таски, похвалить разраба, если всё хорошо / сказать, что можно было бы лучше / сказать, чтобы он шёл и дописывал тесты, иначе не сольётся.
Велосипед – да. Решает задачу – да. Кайфанул ли я пока это писал – да.
А дальше развилка. Или вы мне говорите, что я неправ и надо было сделать так или эдак, накидываете материалов. Или я это простейшее решение собираю в репу на гитхабе, чтобы можно было подключить одной строчкой.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12
Pavel Korolev. Потяжелее
Про покрытие тестами В интернетах удивительно мало информации о том, как технически устроить повышение уровня покрытия тестами на проектах, где по историческим причинам их писать было не принято. Обычно тесты пишут большие и крутые ребята, которые как-то…
https://github.com/pavelkorolevxyz/diff-coverage-report
Всего 4 дня пинг понга с Gradle Plugin Portal, чтобы они апрувнули мой паблиш, плюс несколько свободных часов с клодкодом, чтобы это всё дело причесать и не так стыдно было выкладывать.
Это просто Gradle-плагин, который тащит одну таску, запускать так:
или так:
Результат сразу видно в консоли
И в файле, чтобы попарсить для своих проверок
Предусловий не должно быть никаких. Ест XML файл отчёта и ссылку на ветку/коммит с которым сравнивать, всё.
PS. Пока сути в том, что это Gradle-плагин нет никакой, могло бы быть просто скриптом (может даже и будет скриптом в альтернативном варианте). Но, думаю, неплохая идея туда конфигурацию вынести.
Всего 4 дня пинг понга с Gradle Plugin Portal, чтобы они апрувнули мой паблиш, плюс несколько свободных часов с клодкодом, чтобы это всё дело причесать и не так стыдно было выкладывать.
Это просто Gradle-плагин, который тащит одну таску, запускать так:
./gradlew reportDiffCoverage --branch=main --report=build/reports/kover/report.xmlили так:
./gradlew reportDiffCoverage --diffSha=abc123 --report=build/reports/jacoco/test/jacocoTestReport.xmlРезультат сразу видно в консоли
> Task :reportDiffCoverage
17/20 - src/main/kotlin/Feature.kt
10/15 - src/main/kotlin/Service.kt
Total: 27/35 (77.14%)
Report saved to: /path/to/build/reports/coverage/report.txt
И в файле, чтобы попарсить для своих проверок
analyzedLines: 35
coveredLines: 27
uncoveredLines: 8
coveragePercentage: 77.14
Предусловий не должно быть никаких. Ест XML файл отчёта и ссылку на ветку/коммит с которым сравнивать, всё.
PS. Пока сути в том, что это Gradle-плагин нет никакой, могло бы быть просто скриптом (может даже и будет скриптом в альтернативном варианте). Но, думаю, неплохая идея туда конфигурацию вынести.
🔥7
Кулстори про обновление coil
У нас не так давно дошли руки до того, чтобы пообновлять часть зависимостей в проекте из соображений гигиены. И вот очередь coil. Версия 3.0 вышла в прошлом ноябре. Выждали паузу, так сказать, обновляемся.
В проекте есть вьюшное легаси, пусть и немного. Так вот, там тоже coil используется, и много где был такой синтаксис примерно:
И на регрессе в рантайме увидели краши. Начали копать. Оказалось ребята из койла там в рамках поддержки KMP (вроде бы) вытащили функцию
-- тут пауза на подумать --
Когда вы вызываете функцию у билдера, то импорт её в файле писать не надо.
Когда вы используете экстеншн функцию – её импорт писать надо.
Т.к. импорта там не было, то функция error должна бы после этого не компилироваться, да ведь?) Ага, если бы не было функции
Короче, простыми словами, для компилятора это выглядело так, как будто мы сами написали
Этот урок нас учит, что меняя функции классов на экстеншн функции нужно лишний раз перепроверить, что её название не клэшится с какой-нибудь функцией из стандартной библиотеки. Ну и принимать Any в функциях стандартной библиотеки – тоже подход, который оставляет вопросики. Это с точки зрения разработчика функции/класса. Что делать с точки зрения пользователя библиотеки не представляю даже)
Настолько тупая ситуация, но такая логичная и от этого забавная.
У нас не так давно дошли руки до того, чтобы пообновлять часть зависимостей в проекте из соображений гигиены. И вот очередь coil. Версия 3.0 вышла в прошлом ноябре. Выждали паузу, так сказать, обновляемся.
В проекте есть вьюшное легаси, пусть и немного. Так вот, там тоже coil используется, и много где был такой синтаксис примерно:
imageView.load(url) { // Тут мы заходим в лямбду, где this - это ImageLoader.Builder
placeholder(drawable1) // Задаёт плейсхолдер пока картинка грузится
error(drawable2) // Задаёт плейсхлодер, если вдруг загрузить не получилось
}И на регрессе в рантайме увидели краши. Начали копать. Оказалось ребята из койла там в рамках поддержки KMP (вроде бы) вытащили функцию
error(drawableRes) из самого класса ImageLoader.Builder в экстеншн функцию. Угадайте что могло пойти не так?-- тут пауза на подумать --
Когда вы вызываете функцию у билдера, то импорт её в файле писать не надо.
Когда вы используете экстеншн функцию – её импорт писать надо.
Т.к. импорта там не было, то функция error должна бы после этого не компилироваться, да ведь?) Ага, если бы не было функции
kotlin.error(Any), которая кидает исключение и которую явно импортировать не надо.Короче, простыми словами, для компилятора это выглядело так, как будто мы сами написали
throw IllegalStateException(). И удивляемся почему оно крашится.Этот урок нас учит, что меняя функции классов на экстеншн функции нужно лишний раз перепроверить, что её название не клэшится с какой-нибудь функцией из стандартной библиотеки. Ну и принимать Any в функциях стандартной библиотеки – тоже подход, который оставляет вопросики. Это с точки зрения разработчика функции/класса. Что делать с точки зрения пользователя библиотеки не представляю даже)
Настолько тупая ситуация, но такая логичная и от этого забавная.
👍12😁5
Решаем задачу сами vs Делегируем агенту
Где-то неделю назад Дима из Дринкит написал у себя пост о том, что они экспериментируют с алгоритмической генерацией сетевого слоя по OpenAPI спеке с модельками, ретрофит интерфейсами и всем таким. Тема интересная. Понятная, красивая программистская задача. Но пост меня триггернул подумать.🤔
Он там пишет, что у спеки есть особенности. Например, упоминается, что названия классов получаются слишком длинные, если всё точно по спеке делать. А ещё в спеке что-то лишнее есть, что хотелось бы из вида убрать.
Когда идёт речь о подобной автоматизации, в теории она всегда звучит хорошо, но на практике появляются какие-то компромиссы и нюансы, которые надо иметь в виду. Спеку ещё кто-то поддерживать должен. Актуализировать её, не придумывая новые концепции и правила. Всегда должны придерживаться оговоренного, иначе автоматизация будет всё более комплексной и ненадёжной.
Причём, смею предположить, задача перенести спеку в код – плюс-минус одноразовая, когда фичу кто-то пишет. Как минимум – редкая, когда она кардинально меняется.
И вот с такими вводными я уже перестаю понимать, зачем её в 2к25, как говорится, решать алгоритмически. Вот бы у нас был инструмент, который может "подумать" вместо нас, да? Которому можно было бы объяснить, что тебе хотелось бы видеть на выходе.
Claude Code, буквально, молоток в моих руках, всё остальное вокруг – гвозди.🔨
Так вот, я могу дать ему ту же самую спеку, показать, где лежит верхнеуровневая документация типа "как мы пишем сетевой слой", с пояснениями "как использовать OpenAPI спеку", и он сделает good enough. Он сам примет какие-то решения, над которыми тебе бы пришлось думать во время написания своего.
Более того, собственным решением своих разрабов тоже потом нужно учить пользоваться, даже если оно простое. А сформулировать агенту "по openapi.yml допиши в feature:name сетевой слой" как будто уже базовый скилл любого, кто трогал агентов хоть раз. И чем дальше, тем таких людей будет больше. Нехитрыми уточнениями можно и конкретный метод из этой спеки добавить/изменить в уже существующем коде. Ну да, поработает агент минут десять, но напишет же. Всё быстрее живого разраба. А в своей автоматизации это ещё и нужно было бы изначально закладывать.
На всякий случай замечу, что агента можно научить и своими велосипедами пользоваться, если они есть. У нас, например, агент на слова типа "сделай фича-модуль X" вызовет нашу собственную таску, а не нейронкой будет нагенеривать как видит.
Но мой посыл это не меняет. Похоже, некоторые вещи не имеет смысла писать вообще.
А вы как думаете, где собственно эта грань? Если у вас есть задача, то когда для её решения стоит писать свою автоматизацию, а когда достаточно её отдать агенту? Дело в частоте использования, в желании надёжности, в трудозатратах?
Где-то неделю назад Дима из Дринкит написал у себя пост о том, что они экспериментируют с алгоритмической генерацией сетевого слоя по OpenAPI спеке с модельками, ретрофит интерфейсами и всем таким. Тема интересная. Понятная, красивая программистская задача. Но пост меня триггернул подумать.
Он там пишет, что у спеки есть особенности. Например, упоминается, что названия классов получаются слишком длинные, если всё точно по спеке делать. А ещё в спеке что-то лишнее есть, что хотелось бы из вида убрать.
Когда идёт речь о подобной автоматизации, в теории она всегда звучит хорошо, но на практике появляются какие-то компромиссы и нюансы, которые надо иметь в виду. Спеку ещё кто-то поддерживать должен. Актуализировать её, не придумывая новые концепции и правила. Всегда должны придерживаться оговоренного, иначе автоматизация будет всё более комплексной и ненадёжной.
Причём, смею предположить, задача перенести спеку в код – плюс-минус одноразовая, когда фичу кто-то пишет. Как минимум – редкая, когда она кардинально меняется.
И вот с такими вводными я уже перестаю понимать, зачем её в 2к25, как говорится, решать алгоритмически. Вот бы у нас был инструмент, который может "подумать" вместо нас, да? Которому можно было бы объяснить, что тебе хотелось бы видеть на выходе.
Claude Code, буквально, молоток в моих руках, всё остальное вокруг – гвозди.
Так вот, я могу дать ему ту же самую спеку, показать, где лежит верхнеуровневая документация типа "как мы пишем сетевой слой", с пояснениями "как использовать OpenAPI спеку", и он сделает good enough. Он сам примет какие-то решения, над которыми тебе бы пришлось думать во время написания своего.
Более того, собственным решением своих разрабов тоже потом нужно учить пользоваться, даже если оно простое. А сформулировать агенту "по openapi.yml допиши в feature:name сетевой слой" как будто уже базовый скилл любого, кто трогал агентов хоть раз. И чем дальше, тем таких людей будет больше. Нехитрыми уточнениями можно и конкретный метод из этой спеки добавить/изменить в уже существующем коде. Ну да, поработает агент минут десять, но напишет же. Всё быстрее живого разраба. А в своей автоматизации это ещё и нужно было бы изначально закладывать.
На всякий случай замечу, что агента можно научить и своими велосипедами пользоваться, если они есть. У нас, например, агент на слова типа "сделай фича-модуль X" вызовет нашу собственную таску, а не нейронкой будет нагенеривать как видит.
Но мой посыл это не меняет. Похоже, некоторые вещи не имеет смысла писать вообще.
А вы как думаете, где собственно эта грань? Если у вас есть задача, то когда для её решения стоит писать свою автоматизацию, а когда достаточно её отдать агенту? Дело в частоте использования, в желании надёжности, в трудозатратах?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5❤2
Про заметки и команду сабагентов
Раньше ведение системы заметок скатывалось в прокрастинацию под видом настройки обсидиана. Теперь я уже на далёком следующем уровне, где играюсь с системным промптом для AI агентов, которые мне помогают с ней работать. Благо эти умения потом уже в отработанном виде переносятся на работу, поэтому у меня есть лишнее оправдание почему я занимаюсь системой и процессами, а не полезными делами. Я это сам осознаю, поэтому не расценивайте как рекомендацию, мне это нравится и просто кажется прикольной идеей.
В предыдущем посте на эту тему я писал, о том, что клодкод – мой помощник по заполнению регулярных заметок – daily, в первую очередь, куда я оперативную память выгружаю. В меньшей степени weekly и monthly с ретроспективой недели и месяца, соответственно. Ну и отдельные заметки по шаблонам написать милое дело. А вообще-то задач сильно больше. Принципы ведения этой системы заметок подразумевают, что она мне как-то помогает документировать жизнь, отвечать мне на какие-то вопросы по ней, и в конечном счёте добиваться целей в разных областях. И так я итерационно пришёл к текущему концепту, который уже куда-то в сторону чёрного зеркала смотрит.
Я подумал, что команды из двух "человек" мне недостаточно. Что если мне собрать прям полноценную команду с разнообразными экспертами?
Представьте:
– Клинер🧹 , который предлагает упорядочить заметки в системе по моим правилам или делает это сам, т.к. мне лень разбирать готовые заметки из инбокса
– Контент-мейкер📰 , который мог бы мне предлагать идеи для постов, основываясь на том, что со мной происходило в последнее время и пачке недописанных черновиков
– Ментор😎 , который мог бы подсвечивать насколько мои действия соотносятся с долгосрочными карьерными целями
– Врач-консультант👨⚕️ , который мог бы глядя на информацию о здоровье аргументированно рекомендовать мне конкретные действия для его улучшения
– Психотерапевт🧠 , он же специалист по рефлексии, суть которого глядя на это всё подсветить какие-то общие паттерны и заставить меня углубиться в их суть
..и может ещё другие.
Понятными словами: каждый из них кастомный агент в клодкоде, со своим промптом, ссылающимся на заметки, дающие больший контекст на конкретную тему. А агент по умолчанию остаётся таким помощником-стрелочником, который перенаправляет запрос к конкретному специалисту. То есть, если я спрошу сколько мне ещё пить какие-то витамины или когда мне сдать анализ, то вопрос уйдёт к врачу. Если я попрошу придумать план подготовки к собесам, то это будет делать ментор, т.к. у него просто больше знания по теме.
Не то, чтобы я америку этим открыл. Заводить каких-то кастомных сабагентов для каждой роли в команде типа продакта, аналитика, архитектора, кодера – это уже база от вайбкодеров. Но мне доставляет удовольствие думать об этом именно за пределами программирования и рабочих проектов.
Следующий шаг, от которого у меня прям аха-момент случился – заставить их синковаться, как настоящую скрам команду. Понятными словами: кастомная команда
По итогу получаю много всего конструктивного. Они задают вопросы, которые помогают мне дополнить информацию по своему направлению. Почти без моей помощи фиксируют отчётный период, чтобы я лишний раз вспомнил и зафиксировал у себя в голове события. Триггерят у меня много мыслей. Напомнают, что я что-то хотел. Предлагают действия. И базированно унижают меня за то, что я не сделал, что должен был.
Минусы этой системы – время работы, потребление токенов, и отсутствие проактивности. Много думаю в последнее время о том, как так выстроить процесс, чтобы запускать агентов автоматически.
Раньше ведение системы заметок скатывалось в прокрастинацию под видом настройки обсидиана. Теперь я уже на далёком следующем уровне, где играюсь с системным промптом для AI агентов, которые мне помогают с ней работать. Благо эти умения потом уже в отработанном виде переносятся на работу, поэтому у меня есть лишнее оправдание почему я занимаюсь системой и процессами, а не полезными делами. Я это сам осознаю, поэтому не расценивайте как рекомендацию, мне это нравится и просто кажется прикольной идеей.
В предыдущем посте на эту тему я писал, о том, что клодкод – мой помощник по заполнению регулярных заметок – daily, в первую очередь, куда я оперативную память выгружаю. В меньшей степени weekly и monthly с ретроспективой недели и месяца, соответственно. Ну и отдельные заметки по шаблонам написать милое дело. А вообще-то задач сильно больше. Принципы ведения этой системы заметок подразумевают, что она мне как-то помогает документировать жизнь, отвечать мне на какие-то вопросы по ней, и в конечном счёте добиваться целей в разных областях. И так я итерационно пришёл к текущему концепту, который уже куда-то в сторону чёрного зеркала смотрит.
Я подумал, что команды из двух "человек" мне недостаточно. Что если мне собрать прям полноценную команду с разнообразными экспертами?
Представьте:
– Клинер
– Контент-мейкер
– Ментор
– Врач-консультант
– Психотерапевт
..и может ещё другие.
Понятными словами: каждый из них кастомный агент в клодкоде, со своим промптом, ссылающимся на заметки, дающие больший контекст на конкретную тему. А агент по умолчанию остаётся таким помощником-стрелочником, который перенаправляет запрос к конкретному специалисту. То есть, если я спрошу сколько мне ещё пить какие-то витамины или когда мне сдать анализ, то вопрос уйдёт к врачу. Если я попрошу придумать план подготовки к собесам, то это будет делать ментор, т.к. у него просто больше знания по теме.
Не то, чтобы я америку этим открыл. Заводить каких-то кастомных сабагентов для каждой роли в команде типа продакта, аналитика, архитектора, кодера – это уже база от вайбкодеров. Но мне доставляет удовольствие думать об этом именно за пределами программирования и рабочих проектов.
Следующий шаг, от которого у меня прям аха-момент случился – заставить их синковаться, как настоящую скрам команду. Понятными словами: кастомная команда
/sync, на которую собирается консилиум всех этих сабагентов, чтобы они поделились своими мыслями по последним событиям, а главный собрал это в отчёт по стандартному формату. Ну и weekly/monthly-ретро теперь, естественно, проходит точно таким же образом.По итогу получаю много всего конструктивного. Они задают вопросы, которые помогают мне дополнить информацию по своему направлению. Почти без моей помощи фиксируют отчётный период, чтобы я лишний раз вспомнил и зафиксировал у себя в голове события. Триггерят у меня много мыслей. Напомнают, что я что-то хотел. Предлагают действия. И базированно унижают меня за то, что я не сделал, что должен был.
Минусы этой системы – время работы, потребление токенов, и отсутствие проактивности. Много думаю в последнее время о том, как так выстроить процесс, чтобы запускать агентов автоматически.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Про свалку отчётов от агента
Маленький лайфах по работе с агентом, к которому я уже очень привык. Добавить в gitignore какую-нибудь папку типа
Теперь каждый раз, когда просишь его какой-нибудь отчёт сгенерить, он это делает в папку
Типа такого получается:
К примеру, последний был сделан по промпту "проанализируй как сейчас в проекте используется модуль game, какие у него зависимости, кажется его можно удалить".
Эти отчёты и сами по себе хороши, чтобы разобраться в каком-то вопросе по проекту. И ещё великолепно работают как промпт для следующего чистого чата с агентом. Типа, вот тебе подробные отчёты A, B и C – делай. Они не настолько важны, чтобы их в репу пушить, конечно, но при этом локально в истории остаются, чтобы ты мог память освежить. Это приятно.
Я почти уверен, что это не самый правильный подход с точки зрения процессов. Наверняка правильно завести тикет в джире, потом под это сделать отдельную ветку и там уже создавать всё что нужно только в рамках этого тикета. Но я часто совершенно не так работаю. Я параллельно генерю кучу идей и мне важно убрать все препятствия для этого. Агент может в нескольких вкладках терминала параллельно анализировать разные вопросы. И по каждому такому вопросу у меня в итоге есть артефакты, которые как минимум не мешают, а скорее помогают.
Но, кстати, хот тейк: конвеерные процессы через джиру убивают инициативность и выключают техническую фантазию. Т.е. часто чтобы кто-то сформулировал тебе полезный технический тикет в джире – нужно самому или в рамках брейншторма с командой что-то поанализировать. Вместо этого разрабы учатся действовать только в рамках тикета. А нужно оставлять в конвеере место на подумать.
Маленький лайфах по работе с агентом, к которому я уже очень привык. Добавить в gitignore какую-нибудь папку типа
ai/ и в AGENTS.md оставить какие-то такие правила:
- `ai/` - директория для временных файлов агента.
- Создавай здесь Markdown файлы для больших ответов (временная документация, анализ, отчеты).
- Файлы называй с текущей датой и временем в начале: `YYYYMMDD_HHMM_file_name.md`
- Перепроверяй дату с помощью `date` перед созданием файла
Теперь каждый раз, когда просишь его какой-нибудь отчёт сгенерить, он это делает в папку
ai/ с упорядоченными названиями, чтобы не запутаться. Не в аутпут выплёвывает, и не с рандомными именами в корень проекта, откуда этот "мусор" потом нужно вычищать перед коммитами.Типа такого получается:
- ai/
- 20251104_1820_illustrations_migration.md
- 20251106_1132_sdk_integration_analysis.md
- 20251107_1605_identification_dependencies.md
- 20251108_2245_webview_hooks_implementation.md
- 20251110_1027_game_module_analysis.md
К примеру, последний был сделан по промпту "проанализируй как сейчас в проекте используется модуль game, какие у него зависимости, кажется его можно удалить".
Эти отчёты и сами по себе хороши, чтобы разобраться в каком-то вопросе по проекту. И ещё великолепно работают как промпт для следующего чистого чата с агентом. Типа, вот тебе подробные отчёты A, B и C – делай. Они не настолько важны, чтобы их в репу пушить, конечно, но при этом локально в истории остаются, чтобы ты мог память освежить. Это приятно.
Я почти уверен, что это не самый правильный подход с точки зрения процессов. Наверняка правильно завести тикет в джире, потом под это сделать отдельную ветку и там уже создавать всё что нужно только в рамках этого тикета. Но я часто совершенно не так работаю. Я параллельно генерю кучу идей и мне важно убрать все препятствия для этого. Агент может в нескольких вкладках терминала параллельно анализировать разные вопросы. И по каждому такому вопросу у меня в итоге есть артефакты, которые как минимум не мешают, а скорее помогают.
Но, кстати, хот тейк: конвеерные процессы через джиру убивают инициативность и выключают техническую фантазию. Т.е. часто чтобы кто-то сформулировал тебе полезный технический тикет в джире – нужно самому или в рамках брейншторма с командой что-то поанализировать. Вместо этого разрабы учатся действовать только в рамках тикета. А нужно оставлять в конвеере место на подумать.
👍4
Про память нейронок и команды
В продолжение заметочной темы ещё раз хочется закрепить, что оно стало для меня основной точкой входа в нейронки. В первую очередь потому что я вообще всегда теперь разговор начинаю не с чистого листа, а с базовым контекстом обо мне, которым я ещё и управляю.
Всякие веб версии ChatGPT и Claude все в курсе проблемы отсутствия знаний о юзере, поэтому пытаются сделать себе "память", куда пишут рандомные тяп ляп мысли взятые из переписок с ними же. А тут этой проблемы нет прямо сразу. И пусть даже они тоже сгенерированные нейронкой – командой
А на днях я ещё пришёл к очевидной мысли, что это именно то место, где идеально организовывать свои GPTs, Projects, или библиотеки кастомных промптов, как хотите называйте. Не в контексте какого-то проекта, а опять же в широком смысле любой твоей активности.
Вот захотел я например упростить себе суммаризацию статей в интернетах – завёл кастомную команду
Короче, если у вас есть какая-то база промптов или идей для чего использовать нейронку – это всё может просто лежать кастомными командами в этом проекте. Это не обязательно команды связанные с заметками, это что угодно. Вот это для меня был неочевидный инсайт.
Если даже заметок никаких нет, то всё равно завести проект для агента и складывать туда все ништяки – это отличная идея.
А если вас парит идея переносимости этих команд между агентами, то пишите всё в агент-агностик файлах, а из команд ссылайтесь на них. Это и без фичи команд вообще нормально работает, если в системном промпте есть инфа в духе
Сейчас обкатываю идею запускать терминал с этим агентом в quake моде по хоткею. Кажется, богатая идея – поднимать этого агента-секретаря из любого места, по аналогии с каким нибудь рейкастом. Пока нравится.
В продолжение заметочной темы ещё раз хочется закрепить, что оно стало для меня основной точкой входа в нейронки. В первую очередь потому что я вообще всегда теперь разговор начинаю не с чистого листа, а с базовым контекстом обо мне, которым я ещё и управляю.
Всякие веб версии ChatGPT и Claude все в курсе проблемы отсутствия знаний о юзере, поэтому пытаются сделать себе "память", куда пишут рандомные тяп ляп мысли взятые из переписок с ними же. А тут этой проблемы нет прямо сразу. И пусть даже они тоже сгенерированные нейронкой – командой
/init, это уже лучше обрывков из мемори чатгпт.А на днях я ещё пришёл к очевидной мысли, что это именно то место, где идеально организовывать свои GPTs, Projects, или библиотеки кастомных промптов, как хотите называйте. Не в контексте какого-то проекта, а опять же в широком смысле любой твоей активности.
Вот захотел я например упростить себе суммаризацию статей в интернетах – завёл кастомную команду
/tldr в которой написано в каком виде я хочу получить саммари контента по переданной ссылке. Вот захотел я себе автоматизировать анализ данных со смарт браслета – завёл команду /healthcheck, которая знает что именно из базы HealthKit достать, на что смотреть, и как мне отчёт предоставить. Вот решаю я литкод задачки, допустим – завёл команду /leetcode, куда передаю ссылку/текст/номер задачки, и она мне не код в лицо кидает, а учит думать, потому что так у неё в промпте написано. Или захочу свои диктофонные записи сразу фиксировать в регулярных заметках – тоже скорее сделаю команду, а не полноценный скрипт. Ну вы поняли.Короче, если у вас есть какая-то база промптов или идей для чего использовать нейронку – это всё может просто лежать кастомными командами в этом проекте. Это не обязательно команды связанные с заметками, это что угодно. Вот это для меня был неочевидный инсайт.
Если даже заметок никаких нет, то всё равно завести проект для агента и складывать туда все ништяки – это отличная идея.
А если вас парит идея переносимости этих команд между агентами, то пишите всё в агент-агностик файлах, а из команд ссылайтесь на них. Это и без фичи команд вообще нормально работает, если в системном промпте есть инфа в духе
docs/Tldr.md - описание команды /tldr. С веб инструментами ни о какой переносимости речи вообще нет.Сейчас обкатываю идею запускать терминал с этим агентом в quake моде по хоткею. Кажется, богатая идея – поднимать этого агента-секретаря из любого места, по аналогии с каким нибудь рейкастом. Пока нравится.
👍5🔥1
Про чужой стек и агентов
Я пару недель как загорелся небольшой идеей пет проекта. Это веб приложение, и это первый мой опыт, где я хочу преодолеть ощущение "это непонятный стек, я туда не хочу даже лезть". Ещё это первый мой долгострой (две недели в свободное время – это уже долго), который я исключительно вайбкодю. Не написал пока ни одной строчки кода руками, исключительно менеджерский надзор. Причём менеджер из меня такой – типичный, который делает вид, что понимает все эти технические слова, которые ему разраб говорит.👥
Какие-то мысли по поводу вайбкодинга пока формируются, возможно даже в какой-то митапный докладик в будущем, поэтому сейчас не об этом. Пока просто представьте, что я набросал какой-то MVP, не зная почти ничего про фронтенд с практической точки зрения. То есть там и стек уже сформировался, и какая-то хай левел архитектура нарисовалась. Что-то есть уже, короче.
Но одним глазком посмотреть что он там делает, всё равно, хочется. И получить опыт хочется, и чуйка подсказывает, что скоро начнутся проблемы. Надо будет чуть глубже понимать. Пока проблемы всё не начинаются и не начинаются, к слову, жду. На своём родном стеке я бы уже немножко исплевался, глядя на результаты.
Один из главных блокеров, который меня всегда останавливал от похода в чужие стеки – то что я вообще не представляю даже с какой стороны подступиться. Даже как Visual Studio Code настроить, чтобы он перестал быть блокнотом – я не знаю. Я такого никогда не делал. Приоткрыл форточку в ожидании комментов про WebStorm🪟
Это прям очень понятный показатель опыта для меня. Написать код на любом языке – много ума не надо. Настроить себе окружение, чтобы избавиться от ощущения, что тебе вообще всё в этом процессе неудобно – это непросто.
Мне пришла в голову абсолютно гениальная идея. Называется "Claude Code, настрой мне VS Code для этого проекта".
Он что-то там где-то там подшаманил, заставил меня поставить пачку экстеншнов, которые идеально заходят под выбранный стек. Сделал какие-то таски, наделал хоткеев, по которым их можно запускать. И, вишенка на торте, ещё и доку мне написал как этим всем добром пользоваться. А то глаза-то всё равно разбегаются. Линтеры, тесты, автодополнения всякие, подсказки, всё необходимое, короче.
Это офигенное чувство, когда он просто разрулил за тебя блокер на недели, объяснил, и ты теперь стал чуточку умнее.🧞♀️
Я пару недель как загорелся небольшой идеей пет проекта. Это веб приложение, и это первый мой опыт, где я хочу преодолеть ощущение "это непонятный стек, я туда не хочу даже лезть". Ещё это первый мой долгострой (две недели в свободное время – это уже долго), который я исключительно вайбкодю. Не написал пока ни одной строчки кода руками, исключительно менеджерский надзор. Причём менеджер из меня такой – типичный, который делает вид, что понимает все эти технические слова, которые ему разраб говорит.
Какие-то мысли по поводу вайбкодинга пока формируются, возможно даже в какой-то митапный докладик в будущем, поэтому сейчас не об этом. Пока просто представьте, что я набросал какой-то MVP, не зная почти ничего про фронтенд с практической точки зрения. То есть там и стек уже сформировался, и какая-то хай левел архитектура нарисовалась. Что-то есть уже, короче.
Но одним глазком посмотреть что он там делает, всё равно, хочется. И получить опыт хочется, и чуйка подсказывает, что скоро начнутся проблемы. Надо будет чуть глубже понимать. Пока проблемы всё не начинаются и не начинаются, к слову, жду. На своём родном стеке я бы уже немножко исплевался, глядя на результаты.
Один из главных блокеров, который меня всегда останавливал от похода в чужие стеки – то что я вообще не представляю даже с какой стороны подступиться. Даже как Visual Studio Code настроить, чтобы он перестал быть блокнотом – я не знаю. Я такого никогда не делал. Приоткрыл форточку в ожидании комментов про WebStorm
Это прям очень понятный показатель опыта для меня. Написать код на любом языке – много ума не надо. Настроить себе окружение, чтобы избавиться от ощущения, что тебе вообще всё в этом процессе неудобно – это непросто.
Мне пришла в голову абсолютно гениальная идея. Называется "Claude Code, настрой мне VS Code для этого проекта".
Он что-то там где-то там подшаманил, заставил меня поставить пачку экстеншнов, которые идеально заходят под выбранный стек. Сделал какие-то таски, наделал хоткеев, по которым их можно запускать. И, вишенка на торте, ещё и доку мне написал как этим всем добром пользоваться. А то глаза-то всё равно разбегаются. Линтеры, тесты, автодополнения всякие, подсказки, всё необходимое, короче.
Это офигенное чувство, когда он просто разрулил за тебя блокер на недели, объяснил, и ты теперь стал чуточку умнее.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9
Про Spec-Driven Development
Если вы думаете, что ваши подходы в агентской разработке какие-то немного самозванские и где-то там кто-то делает настоящую красоту, то это отчасти так, конечно, но не полностью. Они там тоже абсолютно случайные вещи делают и надеются, что станет получше.
В двух словах: Spec-Driven Development – это когда вы сначала делаете (генерите) спеку с требованиями, а потом уже по ней агент пишет код. Конец.
Вы же наверняка так уже давным давно делаете, да? Даже вот этот мой пост про рабочую папку для агента этот кейс покрывал. Вот у нас SDD с вами. Ни больше ни меньше.
Дальше – есть несколько opinionated реализаций этой идеи. Github Spec Kit например, или тот который в Kiro от Amazon встроен. Или, такой же кит ещё есть примерно у каждого второго, кто с агентом уже на ты. Может быть уже формализован, или концепциями в голове. Вот я как раз и дошёл до того, чтобы своё формализовать, смотрю по сторонам.
Причём когда я говорю про то, что Spec Kit это реализация этой идеи – я имею ввиду буквально то, что она тебе в Claude Code просто несколько кастомных команд кладёт. Это не софт какой-то особенный, не фреймворк, а просто несколько промптов, которые команда гитхаба сама походу сгенерила. Причём содержимое там такое, на любителя.
Оно очень сильно подразумевает, что у вас такого ничего вообще не было. Он и папки за вас вполне конкретные там описывает, и правила нейминга свои, и какие-то новые концепции добавляет, которые пересекаются с существующим всем на проекте. Ещё там в концепцию заложена удивительно странная идея – что спека теперь может лежать у тебя в репе и это якобы полезно.
Я на это всё дело посмотрел, позаимствовал идеи, а содержимое Claude Code переписал под меня, посмотрев на текущий контекст проекта. В итоге, кастомные команды:
-
-
-
-
Ну и генерится всё связанное с фичей теперь с более понятной структурой:
Идея в том, что у нас есть фиксированный пайплайн из нескольких последовательных команд, каждая генерит артефакт, который мы вычитываем, правим, и идём к следующей.
И на мой вкус, артефакты после выполнения задачи можно сносить без сожаления, они никому больше не нужны. Мне кажется невероятно наивной идея, что эти сгенеренные спеки тебе когда-то будут нужны и они будут на тот момент так же актуальны. Автор приводит в пример типа "а что если я захочу через 5 лет переписать это с технологии X на технологию Y". Ну наивность же.
И да, это всё выглядит как бюрократия разведённая на пустом месте и хорошо работает (правда хорошо) только для средне-сложных задач, которые ты хочешь ваншотнуть. Эту машинерию разворачивать вообще не имеет смысла в остальных случаях. Можно
Если задача достаточно понятная целиком или вообще не про написание кода, то забить и промптить как обычно.
Короче, идея хорошая, но готовый кит вам почти наверняка не нужен. Сгенерьте свой, дело пяти минут. Важно помнить, что это просто попытка упростить сбор требований и написание промпта, чтобы к выполнению задачи всё это уже было готово.
Если вы думаете, что ваши подходы в агентской разработке какие-то немного самозванские и где-то там кто-то делает настоящую красоту, то это отчасти так, конечно, но не полностью. Они там тоже абсолютно случайные вещи делают и надеются, что станет получше.
В двух словах: Spec-Driven Development – это когда вы сначала делаете (генерите) спеку с требованиями, а потом уже по ней агент пишет код. Конец.
Вы же наверняка так уже давным давно делаете, да? Даже вот этот мой пост про рабочую папку для агента этот кейс покрывал. Вот у нас SDD с вами. Ни больше ни меньше.
Дальше – есть несколько opinionated реализаций этой идеи. Github Spec Kit например, или тот который в Kiro от Amazon встроен. Или, такой же кит ещё есть примерно у каждого второго, кто с агентом уже на ты. Может быть уже формализован, или концепциями в голове. Вот я как раз и дошёл до того, чтобы своё формализовать, смотрю по сторонам.
Причём когда я говорю про то, что Spec Kit это реализация этой идеи – я имею ввиду буквально то, что она тебе в Claude Code просто несколько кастомных команд кладёт. Это не софт какой-то особенный, не фреймворк, а просто несколько промптов, которые команда гитхаба сама походу сгенерила. Причём содержимое там такое, на любителя.
Оно очень сильно подразумевает, что у вас такого ничего вообще не было. Он и папки за вас вполне конкретные там описывает, и правила нейминга свои, и какие-то новые концепции добавляет, которые пересекаются с существующим всем на проекте. Ещё там в концепцию заложена удивительно странная идея – что спека теперь может лежать у тебя в репе и это якобы полезно.
Я на это всё дело посмотрел, позаимствовал идеи, а содержимое Claude Code переписал под меня, посмотрев на текущий контекст проекта. В итоге, кастомные команды:
-
/spec:specify – мета-промптинг, который переводит твой промпт в спеку с бизнесовыми юзкейсами, задаёт уточняющие вопросы;-
/spec:plan – переводит бизнес юзкейсы на технический язык;-
/spec:tasks – декомпозирует технические требования и говорит как подзадачи зависят друг от друга. Можно объединить с предыдущими двумя, если очень хочется;-
/spec:implement – берёт эти подзадачи и делает как посчитает нужным.Ну и генерится всё связанное с фичей теперь с более понятной структурой:
- ai/
- feature/
- 20251201_1146_webview_permissions/
- spec.md
- plan.md
- tasks.md
Идея в том, что у нас есть фиксированный пайплайн из нескольких последовательных команд, каждая генерит артефакт, который мы вычитываем, правим, и идём к следующей.
И на мой вкус, артефакты после выполнения задачи можно сносить без сожаления, они никому больше не нужны. Мне кажется невероятно наивной идея, что эти сгенеренные спеки тебе когда-то будут нужны и они будут на тот момент так же актуальны. Автор приводит в пример типа "а что если я захочу через 5 лет переписать это с технологии X на технологию Y". Ну наивность же.
И да, это всё выглядит как бюрократия разведённая на пустом месте и хорошо работает (правда хорошо) только для средне-сложных задач, которые ты хочешь ваншотнуть. Эту машинерию разворачивать вообще не имеет смысла в остальных случаях. Можно
specify и implement без остальных запустить, если уж очень хочется этим китом воспользоваться.Если задача достаточно понятная целиком или вообще не про написание кода, то забить и промптить как обычно.
Короче, идея хорошая, но готовый кит вам почти наверняка не нужен. Сгенерьте свой, дело пяти минут. Важно помнить, что это просто попытка упростить сбор требований и написание промпта, чтобы к выполнению задачи всё это уже было готово.
👍6
Pavel Korolev. Потяжелее
Про Spec-Driven Development Если вы думаете, что ваши подходы в агентской разработке какие-то немного самозванские и где-то там кто-то делает настоящую красоту, то это отчасти так, конечно, но не полностью. Они там тоже абсолютно случайные вещи делают и надеются…
Пример команд для спеки
Под прошлым постом Георгий меня попросил пошарить команды. Мне несложно, держите - https://github.com/pavelkorolevxyz/spec-driven-prompts
Но я там специально ещё несколько контрольных раз написал, что рекомендую это использовать разве что как пищу для размышлений. А потом сгенерить всё под свои нужды самому. Эти команды тоже сгенерированы.
Claude Code команды на русском, чтобы было удобно читать. У меня они так и лежат в домашней директории, потому что мне для себя, плюс токены я не экономлю. И пример их работы, чтобы вы понимали что там примерно сгенерится. Пример супер простой, поэтому может показаться, что это не настолько вообще нужная история, но это так кажется.
Например, я с этим подходом практически ваншотнул клоны всех своих постов из этого канала в блог на сайте для истории. А это не самая простая задача. С одной стороны zip архив от телеги, с другой hugo. Там и заголовки как-то из текста надо придумать (не всегда они есть), и английскую короткую версию для урла, и ссылки на другие посты переоформить так чтобы они вели на посты из блога, а не в телегу, и теги расставать. В общем довольно комплексная такая история. До использования спеки останавливался с агентом на этой задаче где-то посередине, всегда что-то не нравилось.
И так уже далеко не одна какая-то житейская и рабочая задача решены.
Под прошлым постом Георгий меня попросил пошарить команды. Мне несложно, держите - https://github.com/pavelkorolevxyz/spec-driven-prompts
Но я там специально ещё несколько контрольных раз написал, что рекомендую это использовать разве что как пищу для размышлений. А потом сгенерить всё под свои нужды самому. Эти команды тоже сгенерированы.
Claude Code команды на русском, чтобы было удобно читать. У меня они так и лежат в домашней директории, потому что мне для себя, плюс токены я не экономлю. И пример их работы, чтобы вы понимали что там примерно сгенерится. Пример супер простой, поэтому может показаться, что это не настолько вообще нужная история, но это так кажется.
Например, я с этим подходом практически ваншотнул клоны всех своих постов из этого канала в блог на сайте для истории. А это не самая простая задача. С одной стороны zip архив от телеги, с другой hugo. Там и заголовки как-то из текста надо придумать (не всегда они есть), и английскую короткую версию для урла, и ссылки на другие посты переоформить так чтобы они вели на посты из блога, а не в телегу, и теги расставать. В общем довольно комплексная такая история. До использования спеки останавливался с агентом на этой задаче где-то посередине, всегда что-то не нравилось.
И так уже далеко не одна какая-то житейская и рабочая задача решены.
🔥6
Wrapped, который мы заслужили
В Claude Code теперь можно запустить команду
Информативность графика, конечно, зашкаливает, явно сам клод это и накодил.
Иначе как объяснить, что 9 ноября, с которого он показывает мне статистику – ровно между словами Nov и Dec, а декабрь как будто весь уже закончился. Недель то там 52 (я сидел считал), как и должно быть, просто месяцы вообще не там😳
Да и зачем показывать год, когда у всех статистика есть максимум за месяц – тоже непонятно.
Но цифры интересные. Я восстание машин точно не переживу. А вы как?
В Claude Code теперь можно запустить команду
/stats и посмотреть как сильно ты его мучал в последнее время.Информативность графика, конечно, зашкаливает, явно сам клод это и накодил.
Иначе как объяснить, что 9 ноября, с которого он показывает мне статистику – ровно между словами Nov и Dec, а декабрь как будто весь уже закончился. Недель то там 52 (я сидел считал), как и должно быть, просто месяцы вообще не там
Да и зачем показывать год, когда у всех статистика есть максимум за месяц – тоже непонятно.
Но цифры интересные. Я восстание машин точно не переживу. А вы как?
Please open Telegram to view this post
VIEW IN TELEGRAM
🥰1
Алматы завтра тут, приходите. У ребят в этот раз получился мобильный митап вообще без AI. Ну или почти мобильный и почти без AI, посмотрим 🙂
❤1
Forwarded from nullptr.party
🔥 nullptr.talks[1] от nullptr.party в MOST IT Hub 🔥
У тебя есть два варианта: продолжать верить в методички про «чистую архитектуру» или прийти на nullptr.talks[1] и послушать, как на самом деле живут боевые мобильные продукты — с кривыми практиками, странными интеграциями, хардкорным железом и чёрной магией Flutter.
Wake the fuck up samurai. We have a meetup to visit!
В программе:
Иван Луценко — Android Tech Lead, Bereke Bank
Тема: CI/CD: история любви
Говорят, любовь живёт три года — но с CI/CD всё сложнее. Ваня расскажет, как за три года отношения с пайплайном в Bereke Bank прошли путь от полного хаоса (ноль политик мерджа, ни одного quality gate’а и 11 разрозненных тестовых сред) до внятной системы с дебаг-меню, линтерами, pre-commit/pre-push хуками, SonarQube и переездом в GitLab. Поговорим о том, с каких болей команды начинать, как не превратить CI/CD в карающий меч разработчикам и почему страдания разработчиков окупаются любовью пользователей.
Алексей Орехов — Android Engineer, izi
Тема: Лебедь, рак и щука (современная интерпретация)
Как взять существующее приложение и аккуратно встроить его в другой продукт, не превратив всё в монстра? Лёха из izi поделится реальным кейсом интеграции «приложения внутри приложения»: архитектура, боли, неожиданные ловушки и выводы, которые стоит учесть всем.
Амин Бенариеб — iOS Engineer, Welltory
Тема: Как мы превратили iPhone в лабораторный микроскоп
Доклад про проект на стыке мобильной разработки и медицины. Амин покажет, как команда превращала iPhone в лабораторный микроскоп: съёмка крови через оптику, связь по BLE с устройством и AI, работающий прямо на телефоне. Поговорим о том, чем такой продукт отличается от привычного «приложения из стора» и какие уроки они извлекли.
Алихан Байшоланов — Android Engineer, BCC HUB
Тема: Запуск Dart кода через нативку
Представьте: у вас Flutter-приложение, внутрь него встраивают нативный SDK, который имеет в себе нативный экран и поверх него снова нужно показать Flutter-экран. Алихан расскажет, как запускал Dart-код из нативного SDK, строил мосты между Kotlin и Flutter и почему простая «шторка оплаты» оказалась чуть сложнее чем кажется на первый взгляд.
🗓 12 декабря | 19:00
📍 MOST IT Hub, г. Алматы, ул. Ходжанова 2/2, БЦ Fortis
https://go.2gis.com/aPpbN
⏱️ Длительность: 2–2,5 часа
📝 Регистрация: https://forms.gle/6HD8yDUEWLNU2iZr6
⚠️ Количество мест ограничено — лучше занять место заранее!
Наш канал: https://t.me/+NwP6cY9dVfgyMDVi
Наш уютный чатик: https://t.me/+60NkAf4EsJ8xYWJi
У тебя есть два варианта: продолжать верить в методички про «чистую архитектуру» или прийти на nullptr.talks[1] и послушать, как на самом деле живут боевые мобильные продукты — с кривыми практиками, странными интеграциями, хардкорным железом и чёрной магией Flutter.
Wake the fuck up samurai. We have a meetup to visit!
В программе:
Иван Луценко — Android Tech Lead, Bereke Bank
Тема: CI/CD: история любви
Говорят, любовь живёт три года — но с CI/CD всё сложнее. Ваня расскажет, как за три года отношения с пайплайном в Bereke Bank прошли путь от полного хаоса (ноль политик мерджа, ни одного quality gate’а и 11 разрозненных тестовых сред) до внятной системы с дебаг-меню, линтерами, pre-commit/pre-push хуками, SonarQube и переездом в GitLab. Поговорим о том, с каких болей команды начинать, как не превратить CI/CD в карающий меч разработчикам и почему страдания разработчиков окупаются любовью пользователей.
Алексей Орехов — Android Engineer, izi
Тема: Лебедь, рак и щука (современная интерпретация)
Как взять существующее приложение и аккуратно встроить его в другой продукт, не превратив всё в монстра? Лёха из izi поделится реальным кейсом интеграции «приложения внутри приложения»: архитектура, боли, неожиданные ловушки и выводы, которые стоит учесть всем.
Амин Бенариеб — iOS Engineer, Welltory
Тема: Как мы превратили iPhone в лабораторный микроскоп
Доклад про проект на стыке мобильной разработки и медицины. Амин покажет, как команда превращала iPhone в лабораторный микроскоп: съёмка крови через оптику, связь по BLE с устройством и AI, работающий прямо на телефоне. Поговорим о том, чем такой продукт отличается от привычного «приложения из стора» и какие уроки они извлекли.
Алихан Байшоланов — Android Engineer, BCC HUB
Тема: Запуск Dart кода через нативку
Представьте: у вас Flutter-приложение, внутрь него встраивают нативный SDK, который имеет в себе нативный экран и поверх него снова нужно показать Flutter-экран. Алихан расскажет, как запускал Dart-код из нативного SDK, строил мосты между Kotlin и Flutter и почему простая «шторка оплаты» оказалась чуть сложнее чем кажется на первый взгляд.
🗓 12 декабря | 19:00
📍 MOST IT Hub, г. Алматы, ул. Ходжанова 2/2, БЦ Fortis
https://go.2gis.com/aPpbN
⏱️ Длительность: 2–2,5 часа
📝 Регистрация: https://forms.gle/6HD8yDUEWLNU2iZr6
⚠️ Количество мест ограничено — лучше занять место заранее!
Наш канал: https://t.me/+NwP6cY9dVfgyMDVi
Наш уютный чатик: https://t.me/+60NkAf4EsJ8xYWJi
❤1🔥1
Про ботлнеки в разработке
OpenAI вчера сделали довольно интересный пост про то, как они разрабатывали андроид-приложение Sora с помощью своего Codex. Не хочу всё пересказывать, вот тут это уже хорошо сделали, и вообще тезисы удивительно близко повторяют контент моего канала и моих докладов 🙂
Я хочу за одну цитату зацепиться:
Always has been, как говорится. Они, очевидно, очень лукавят, ведь эта идея в рекламных целях красиво смотрится.
Непосредственно кодинг – почти никогда не ботлнек. За 80% ресурсов, потраченными на разработку, идут по 80% ресурсов, потраченные на аналитику, QA, деплой и всякие маркетинговые штуки. Ну или, по крайней мере, так должно было быть. Если не было, то это в консерватории что-то не так.
Просто если у вас на проекте хоть как-то зафиксировались подходы к разработке и все понимают что делать, то вы начинаете работать сильно быстрее, чем это успевают ревьювить, тестировать и потом регрессить. И если на разработке не задумываться о том, как бы чего лишнего не задеть и как сложно будет тестировать, то ботлнек будет на шаг дальше.
AI особо ничего не поменял, просто чуть ярче показал. Как без AI мы начинали наворачивать автоматические проверки и тесты поверх разработки, так и тут придётся. Но если без AI мы можем без всего этого жить довольно долго, то с ним просто иначе работать вообще не получается — он будет делать какую-то ерунду и очень быстро. Дальше будет уже не ботлнек, а ботлнечище.
OpenAI вчера сделали довольно интересный пост про то, как они разрабатывали андроид-приложение Sora с помощью своего Codex. Не хочу всё пересказывать, вот тут это уже хорошо сделали, и вообще тезисы удивительно близко повторяют контент моего канала и моих докладов 🙂
Я хочу за одну цитату зацепиться:
Our bottleneck in development shifted from writing code to making decisions, giving feedback, and integrating changes.
Always has been, как говорится. Они, очевидно, очень лукавят, ведь эта идея в рекламных целях красиво смотрится.
Непосредственно кодинг – почти никогда не ботлнек. За 80% ресурсов, потраченными на разработку, идут по 80% ресурсов, потраченные на аналитику, QA, деплой и всякие маркетинговые штуки. Ну или, по крайней мере, так должно было быть. Если не было, то это в консерватории что-то не так.
Просто если у вас на проекте хоть как-то зафиксировались подходы к разработке и все понимают что делать, то вы начинаете работать сильно быстрее, чем это успевают ревьювить, тестировать и потом регрессить. И если на разработке не задумываться о том, как бы чего лишнего не задеть и как сложно будет тестировать, то ботлнек будет на шаг дальше.
AI особо ничего не поменял, просто чуть ярче показал. Как без AI мы начинали наворачивать автоматические проверки и тесты поверх разработки, так и тут придётся. Но если без AI мы можем без всего этого жить довольно долго, то с ним просто иначе работать вообще не получается — он будет делать какую-то ерунду и очень быстро. Дальше будет уже не ботлнек, а ботлнечище.
👍3🔥1
Про проактивность AI
Все люди относятся к определённой части спектра. С одной стороны есть те, кто просто делает ровно то, что им сказали. И с другой те, кто сверху этого проявляют какое-то количество инициативы – и в рамках конкретной задачи, и в рамках процессов и проекта в целом. Первых большинство, первые надёжные и понятные. Вторые – не самые предсказуемые, но они двигатель прогресса, они наводят суету. Все остальные начинают этой суетой подпитываться, и мы все вместе движемся в какую-то правильную (или не очень) сторону. В команде всегда нужны и те и другие. Даже если и те и другие живут в рамках одного человека, ведь каждый человек между этими полярными состояниями должен балансировать.
Мы все тут уже прекрасно понимаем, что нейроночки классные и могут порешать плюс-минус любую задачу с должным уровнем декомпозиции. Но прямо сейчас у них есть фундаментальная проблема – они находятся в той части спектра, которая пальцем (или что у них там) не пошевелит, если их не пнуть. Агенты – потрясающие как исполнители, но они вообще ничего не делают проактивно.
Мне кажется это какой-то следующий этап, который перевернёт игру опять, ещё сильнее прежнего. И уже даже на самом попсовом уровне движение в эту сторону прослеживается. ChatGPT Pulse, например, который анализируя список чатов тебе проактивно присылает сообщения в духе "спишь?" и "ты интересовался римской империей, а вот интересный факт".
Но, как я и говорил, я пока не очень верю в то, что чат интерфейсы вообще способны насобирать в свою память достаточно полезного, поэтому агенты наше всё. Наш следующий шаг – сделать агентов проактивными. Давайте помечтаем и подумаем.
Нам как будто нужно ответить на четыре вопроса:
1. Когда запускать агента?
2. Что ему делать?
3. Как ему это делать?
4. Что сделать с результатом его работы?
Ну например:
- При создании мёрж реквеста в гитлабе сделать код-ревью как описано в документации и запостить результат обратно.
- Или раз в сутки по крону проанализировать интернеты на предмет интересных постов об андроиде и принести тебе саммари в виде поста в телеграм бота/канал.
- Или каждые два часа запускать агента, что делать он сам определяет по заранее определённому техническому бэклогу проекта, анализирует это, предлагает решения в виде маркдаун спеки/плана (см. sdd).
Последний вариант я у себя локально на компе поднимал с помощью
Сильно не хватает какого-то приятного интерфейса-конструктора такой системы пока. По сути надо просто научиться спавнить агентов по определённым триггерам, а всё остальное у нас уже есть. Ну и чтобы вопросы задавал, перед погружением в тему, которая вообще не нужна. Навайбкодить что ли.🤔
Все люди относятся к определённой части спектра. С одной стороны есть те, кто просто делает ровно то, что им сказали. И с другой те, кто сверху этого проявляют какое-то количество инициативы – и в рамках конкретной задачи, и в рамках процессов и проекта в целом. Первых большинство, первые надёжные и понятные. Вторые – не самые предсказуемые, но они двигатель прогресса, они наводят суету. Все остальные начинают этой суетой подпитываться, и мы все вместе движемся в какую-то правильную (или не очень) сторону. В команде всегда нужны и те и другие. Даже если и те и другие живут в рамках одного человека, ведь каждый человек между этими полярными состояниями должен балансировать.
Мы все тут уже прекрасно понимаем, что нейроночки классные и могут порешать плюс-минус любую задачу с должным уровнем декомпозиции. Но прямо сейчас у них есть фундаментальная проблема – они находятся в той части спектра, которая пальцем (или что у них там) не пошевелит, если их не пнуть. Агенты – потрясающие как исполнители, но они вообще ничего не делают проактивно.
Мне кажется это какой-то следующий этап, который перевернёт игру опять, ещё сильнее прежнего. И уже даже на самом попсовом уровне движение в эту сторону прослеживается. ChatGPT Pulse, например, который анализируя список чатов тебе проактивно присылает сообщения в духе "спишь?" и "ты интересовался римской империей, а вот интересный факт".
Но, как я и говорил, я пока не очень верю в то, что чат интерфейсы вообще способны насобирать в свою память достаточно полезного, поэтому агенты наше всё. Наш следующий шаг – сделать агентов проактивными. Давайте помечтаем и подумаем.
Нам как будто нужно ответить на четыре вопроса:
1. Когда запускать агента?
2. Что ему делать?
3. Как ему это делать?
4. Что сделать с результатом его работы?
Ну например:
- При создании мёрж реквеста в гитлабе сделать код-ревью как описано в документации и запостить результат обратно.
- Или раз в сутки по крону проанализировать интернеты на предмет интересных постов об андроиде и принести тебе саммари в виде поста в телеграм бота/канал.
- Или каждые два часа запускать агента, что делать он сам определяет по заранее определённому техническому бэклогу проекта, анализирует это, предлагает решения в виде маркдаун спеки/плана (см. sdd).
Последний вариант я у себя локально на компе поднимал с помощью
launchd + backlog.md + sh скрипт для запуска claude с соответствующим промптом. Он вполне даже работает, но этим просто как-то очень неуклюже пользоваться.Сильно не хватает какого-то приятного интерфейса-конструктора такой системы пока. По сути надо просто научиться спавнить агентов по определённым триггерам, а всё остальное у нас уже есть. Ну и чтобы вопросы задавал, перед погружением в тему, которая вообще не нужна. Навайбкодить что ли.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6
Про лидерское внимание
Сегодня немного менеджерских размышлений. В прошлом посте я зафиксировал, что в командах всегда есть сильные (high) и слабые (low) перформеры. В разных смыслах. И в смысле вкладываемой в работу инициативы, и в смысле качества, и в смысле количества работы в единицу времени. Короче, это такой собирательный образ, и лидер/менеджер/руководитель на чуйке и по определённым метрикам понимает место каждого коллеги на этом спектре. От грейда это даже не настолько сильно зависит как кажется, это сумма факторов.
И вот дилемма, с которой я уже довольно давно борюсь – кому уделять своё время и внимание? Тому, кто тащит? Или тому, кто отстаёт? Любые совпадения случайны, это чисто мысленный эксперимент. Понятное дело, что я упрощаю.🤭
Интуитивный ответ – слабым, ведь им больше нужна помощь. Ты заинтересован в том, чтобы никто в твоей команде не проседал. Но с другой стороны, мне очевидно, что вместе с сильными ты за то же время сделаешь намного больше, плюс они ещё и благодаря этому растут гораздо быстрее.
В этой итерации я заинтересовался настолько, что пошёл заказывать исследования нескольким нейронкам, чтобы они мне рассказали как надо. Что человечество вообще на эту тему думает и пишет? Выжимка такая:
- Время с сильным перформером множит его продуктивность, это больше влияет на общий выхлоп
- Сильные должны работать там, где максимальный потенциал
- По сильному понятен его план развития, по слабому – нет
- Время со слабым перформером часто даёт ноль или минус
- Слабые демотивируют остальную команду и сигнализируют ей, что уровень не важен
- Слабых надо или ротировать туда, где их слабости станут нерелевантны, или расставаться
Правда сказать, это всё хорошо работает, если у тебя есть одновременно и ответственность, и полномочия. Иначе ты скорее не в глобальных интересах бизнеса действуешь, а в своих. Когда и не вредишь активно, но и не инвестируешь время туда, где тебе лично пользы нет. Если уж совсем прагматично на жизнь смотреть, то слабые из неё пропадут как только ваши пути разойдутся. А сильные так или иначе останутся.
Сегодня немного менеджерских размышлений. В прошлом посте я зафиксировал, что в командах всегда есть сильные (high) и слабые (low) перформеры. В разных смыслах. И в смысле вкладываемой в работу инициативы, и в смысле качества, и в смысле количества работы в единицу времени. Короче, это такой собирательный образ, и лидер/менеджер/руководитель на чуйке и по определённым метрикам понимает место каждого коллеги на этом спектре. От грейда это даже не настолько сильно зависит как кажется, это сумма факторов.
И вот дилемма, с которой я уже довольно давно борюсь – кому уделять своё время и внимание? Тому, кто тащит? Или тому, кто отстаёт? Любые совпадения случайны, это чисто мысленный эксперимент. Понятное дело, что я упрощаю.
Интуитивный ответ – слабым, ведь им больше нужна помощь. Ты заинтересован в том, чтобы никто в твоей команде не проседал. Но с другой стороны, мне очевидно, что вместе с сильными ты за то же время сделаешь намного больше, плюс они ещё и благодаря этому растут гораздо быстрее.
В этой итерации я заинтересовался настолько, что пошёл заказывать исследования нескольким нейронкам, чтобы они мне рассказали как надо. Что человечество вообще на эту тему думает и пишет? Выжимка такая:
- Время с сильным перформером множит его продуктивность, это больше влияет на общий выхлоп
- Сильные должны работать там, где максимальный потенциал
- По сильному понятен его план развития, по слабому – нет
- Время со слабым перформером часто даёт ноль или минус
- Слабые демотивируют остальную команду и сигнализируют ей, что уровень не важен
- Слабых надо или ротировать туда, где их слабости станут нерелевантны, или расставаться
Правда сказать, это всё хорошо работает, если у тебя есть одновременно и ответственность, и полномочия. Иначе ты скорее не в глобальных интересах бизнеса действуешь, а в своих. Когда и не вредишь активно, но и не инвестируешь время туда, где тебе лично пользы нет. Если уж совсем прагматично на жизнь смотреть, то слабые из неё пропадут как только ваши пути разойдутся. А сильные так или иначе останутся.
Please open Telegram to view this post
VIEW IN TELEGRAM
☃2❤1😢1💯1
С новым годом!
Традиционное поздравление из уже наступившего нового года всем тем, у кого он уже наступил и тем, кто только готовится встречать.
Год был нормальный, лучше чем предыдущие. Надеемся что этот продолжит в том же духе хотя бы. О многом не просим.
Ну а сами настраиваемся крепко поработать в этом году, чтобы ещё лучше стало.
Традиционное поздравление из уже наступившего нового года всем тем, у кого он уже наступил и тем, кто только готовится встречать.
Год был нормальный, лучше чем предыдущие. Надеемся что этот продолжит в том же духе хотя бы. О многом не просим.
Ну а сами настраиваемся крепко поработать в этом году, чтобы ещё лучше стало.
❤5👍3🔥1
Про одноразовые AI интерфейсы
Новый год, а посты всё ещё про AI. Обнаружен ещё один прикольный юзкейс для агента.
Я несколько раз за последнее время оказывался в такой ситуации, когда понимал, что нейронке принятие финального решения по некоторым задачам давать не стоит и мне нужно её работу перепроверить. Я понимаю, что у неё нет достаточного контекста для этого, а у меня есть. Причём перепроверить нужно не что-то одно, а прям по списку много разных пунктов.
Давайте ближе к конкретным примерам.
- Предположим, у меня в проекте есть какая-то рандомная иконка и я хочу выбрать ближайший аналог из дизайн-системы.
- Или я хочу проставить массиву данных какие-то коэффициенты – например приоритет задач, чтобы потом с ними было удобнее работать.
- Или я подготавливаю данные для какого-нибудь пет проекта, попросил агента насытить базу информацией и картинками из интернета, хочу это провалидировать и отбросить косячное.
- А может, я в своём пет проекте выбираю иконки и мне хочется посмотреть на предложенные варианты, вместо того чтобы он вставил первый попавшийся.
И вот это всё иногда нужно сделать в цикле много раз. Например, для кучи строк в базе.
Мне для этих кейсов хочется что-то типа опросника. Для принятия решения часто нужно что-то пооткрывать рядом, посравнивать. Одна картинка, другая, сходу разницу не видно, нужно их как-то друг на друга накладывать. Запутаешься, пока будешь это делать. Или, если про другой пример, цифры печатать в простой эксель-табличке не очень весело, да и ты не можешь всё в голове удержать. Тоже наошибаешься.
И вот я подумал, почему бы этот опросник не делать динамически под задачу. Микроприложение, где ты проходишь по каждому пункту отдельно и принимаешь решения – выбираешь ответы из предложенных агентом. Варианты не обязательно ограничиваются двумя, где-то может быть даже множественный выбор. Он даже может подсветить, что, по его мнению, правильно, чтобы ты от этого отталкивался. Он может тебе помочь это всё отрисовать, чтобы удобнее было смотреть. Он тебе показывает прогресс. В результате он сам же может сгенерить отчёт с ответами, по которому сам же потом и отработает.
По сути это такой же визард, как встроенный в Claude Code с вариантами ответов, но на стероидах. С любой кастомизацией, которая необходима.🕶
Вот этот симбиоз, где он может на ровном месте сделать одноразовую автоматизацию, а я могу подумать – самый кайф. Я бы в жизни такую автоматизацию не писал, он бы в жизни без меня нормально задачу не решил. Но стоит ему дать тебе в помощь специальный интерфейс под задачу – тебе сразу проще и ему от тебя понятный фидбек прилетает.
Вообще очень нравится абьюзить html для любой визуализации с помощью агентов. От какой-нибудь презентации для команды, до утилиты для решения моей конкретной маленькой задачки.
Всё описанное в виде промпта тут. Я себе кастомную команду даже сделал, чтобы наиграться в этот инструмент вдоволь. В комменты прикрепил видеопример того, что она генерит.
Новый год, а посты всё ещё про AI. Обнаружен ещё один прикольный юзкейс для агента.
Я несколько раз за последнее время оказывался в такой ситуации, когда понимал, что нейронке принятие финального решения по некоторым задачам давать не стоит и мне нужно её работу перепроверить. Я понимаю, что у неё нет достаточного контекста для этого, а у меня есть. Причём перепроверить нужно не что-то одно, а прям по списку много разных пунктов.
Давайте ближе к конкретным примерам.
- Предположим, у меня в проекте есть какая-то рандомная иконка и я хочу выбрать ближайший аналог из дизайн-системы.
- Или я хочу проставить массиву данных какие-то коэффициенты – например приоритет задач, чтобы потом с ними было удобнее работать.
- Или я подготавливаю данные для какого-нибудь пет проекта, попросил агента насытить базу информацией и картинками из интернета, хочу это провалидировать и отбросить косячное.
- А может, я в своём пет проекте выбираю иконки и мне хочется посмотреть на предложенные варианты, вместо того чтобы он вставил первый попавшийся.
И вот это всё иногда нужно сделать в цикле много раз. Например, для кучи строк в базе.
Мне для этих кейсов хочется что-то типа опросника. Для принятия решения часто нужно что-то пооткрывать рядом, посравнивать. Одна картинка, другая, сходу разницу не видно, нужно их как-то друг на друга накладывать. Запутаешься, пока будешь это делать. Или, если про другой пример, цифры печатать в простой эксель-табличке не очень весело, да и ты не можешь всё в голове удержать. Тоже наошибаешься.
И вот я подумал, почему бы этот опросник не делать динамически под задачу. Микроприложение, где ты проходишь по каждому пункту отдельно и принимаешь решения – выбираешь ответы из предложенных агентом. Варианты не обязательно ограничиваются двумя, где-то может быть даже множественный выбор. Он даже может подсветить, что, по его мнению, правильно, чтобы ты от этого отталкивался. Он может тебе помочь это всё отрисовать, чтобы удобнее было смотреть. Он тебе показывает прогресс. В результате он сам же может сгенерить отчёт с ответами, по которому сам же потом и отработает.
По сути это такой же визард, как встроенный в Claude Code с вариантами ответов, но на стероидах. С любой кастомизацией, которая необходима.
Вот этот симбиоз, где он может на ровном месте сделать одноразовую автоматизацию, а я могу подумать – самый кайф. Я бы в жизни такую автоматизацию не писал, он бы в жизни без меня нормально задачу не решил. Но стоит ему дать тебе в помощь специальный интерфейс под задачу – тебе сразу проще и ему от тебя понятный фидбек прилетает.
Вообще очень нравится абьюзить html для любой визуализации с помощью агентов. От какой-нибудь презентации для команды, до утилиты для решения моей конкретной маленькой задачки.
Всё описанное в виде промпта тут. Я себе кастомную команду даже сделал, чтобы наиграться в этот инструмент вдоволь. В комменты прикрепил видеопример того, что она генерит.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4
Про вайб-продакт менеджмент
В рамках дисклеймера: мы кажется уже на том этапе, где словосочетание вайб-кодинг почти перестало быть ругательным и описывать бездумный аппрув всех агентских правок. Это теперь всё ближе к продуманному процессу с теми же спеками, нормальными инженерными практиками и всем таким. Просто с минимальным ручным кодингом. И неважно, что там автор термина вообще имел ввиду. Я уже тоже даже подстроился, перестал душнить об этом и сам часто использую.
Этот пост — по следам моего опыта вайбкодинга и контента от Бориса Чёрного (который Claude Code) в твиттере. Он там говорит, что деливерит примерно 65 пулл реквестов в неделю и каждую строчку в них написал Claude Code. Это очень много. Нам бы командой столько деливерить.
Мысль какая. По моим ощущениям такое возможно только, если сходятся 3 фактора:
Во-первых, очевидное: если у тебя есть автоматизированные quality гейты и ты им доверяешь. Тесты, стат анализ и всё такое. Людей в этой схеме надо бы вообще исключить, они медленные.
Во-вторых, этот пайплайн не должен занимать минуты. Иначе ты всё равно потеряешь контекст, даже несмотря на постоянное жонглирование инстансами агентов и попытку из него не выпасть. А если ты выпадаешь из контекста, то ты чисто физически в день не успеешь по 10+ PR делать. Ну разве что по одной строчке.
В-третьих, это для меня всё равно не очень реалистично звучит, если у тебя фиксированные требования. Вайб-кодинг офигенно быстро и хорошо двигает продукт, если у тебя вайб-продакт мышление. Да, я придумал новый термин для стартаперского срезания углов.
Что делает человек, если упёрся в какую-то проблему и не может решить задачу в обозримые сроки? В худшем случае — будет долбиться и дальше, периодически принося тебе неработающие решения. Вот агенты на это тоже падки. Понятное дело, skill issue, но согласитесь, что такое бывает. Ты раз-два-три его пнул, у него не очень хорошо получилось, и тебе теперь нужно принимать какое-то решение что делать. Если мы условились не лезть в код руками, то у нас есть один быстрый вариант – поменять требования под реализацию. Остальные варианты долгие и неприятные.
У тебя есть какое-то стратегическое видение твоего продукта, но ты допускаешь тактическое отклонение (даже довольно сильное) от поставленных требований или вообще отсутствие формализованных требований в пользу скорости движения. Ты можешь на ходу с агентом понять, что другое решение тебе достаточно и его делать гораздо проще. И это норм.
AI здесь тоже концептуально ничего не меняет, но множит важность того, что было актуально и раньше.
В рамках дисклеймера: мы кажется уже на том этапе, где словосочетание вайб-кодинг почти перестало быть ругательным и описывать бездумный аппрув всех агентских правок. Это теперь всё ближе к продуманному процессу с теми же спеками, нормальными инженерными практиками и всем таким. Просто с минимальным ручным кодингом. И неважно, что там автор термина вообще имел ввиду. Я уже тоже даже подстроился, перестал душнить об этом и сам часто использую.
Этот пост — по следам моего опыта вайбкодинга и контента от Бориса Чёрного (который Claude Code) в твиттере. Он там говорит, что деливерит примерно 65 пулл реквестов в неделю и каждую строчку в них написал Claude Code. Это очень много. Нам бы командой столько деливерить.
Мысль какая. По моим ощущениям такое возможно только, если сходятся 3 фактора:
Во-первых, очевидное: если у тебя есть автоматизированные quality гейты и ты им доверяешь. Тесты, стат анализ и всё такое. Людей в этой схеме надо бы вообще исключить, они медленные.
Во-вторых, этот пайплайн не должен занимать минуты. Иначе ты всё равно потеряешь контекст, даже несмотря на постоянное жонглирование инстансами агентов и попытку из него не выпасть. А если ты выпадаешь из контекста, то ты чисто физически в день не успеешь по 10+ PR делать. Ну разве что по одной строчке.
В-третьих, это для меня всё равно не очень реалистично звучит, если у тебя фиксированные требования. Вайб-кодинг офигенно быстро и хорошо двигает продукт, если у тебя вайб-продакт мышление. Да, я придумал новый термин для стартаперского срезания углов.
Что делает человек, если упёрся в какую-то проблему и не может решить задачу в обозримые сроки? В худшем случае — будет долбиться и дальше, периодически принося тебе неработающие решения. Вот агенты на это тоже падки. Понятное дело, skill issue, но согласитесь, что такое бывает. Ты раз-два-три его пнул, у него не очень хорошо получилось, и тебе теперь нужно принимать какое-то решение что делать. Если мы условились не лезть в код руками, то у нас есть один быстрый вариант – поменять требования под реализацию. Остальные варианты долгие и неприятные.
У тебя есть какое-то стратегическое видение твоего продукта, но ты допускаешь тактическое отклонение (даже довольно сильное) от поставленных требований или вообще отсутствие формализованных требований в пользу скорости движения. Ты можешь на ходу с агентом понять, что другое решение тебе достаточно и его делать гораздо проще. И это норм.
AI здесь тоже концептуально ничего не меняет, но множит важность того, что было актуально и раньше.
👍5
Pavel Korolev. Потяжелее
Про вайб-продакт менеджмент В рамках дисклеймера: мы кажется уже на том этапе, где словосочетание вайб-кодинг почти перестало быть ругательным и описывать бездумный аппрув всех агентских правок. Это теперь всё ближе к продуманному процессу с теми же спеками…
Про парадоксальность AI разработки
К предыдущему посту хочется ещё вот какой вывод зафиксировать. Раньше на разных сторонах спектра были стартапы и кровавые энтерпрайзы. И с ними ассоциировались конкретные процессы. Например, покрывают проект тестами и утопают в бюрократии — энтерпрайзы, а стартапы — действуют быстро, забивая на всё, что не несёт понятный инкремент для бизнеса.
И забавно, что с AI для эффективной работы нужно схлопнуть эти два мира. Стартапы обязаны делать quality гейты и работать с документацией на раннем этапе, а энтерпрайзы обязаны научиться гибко и спокойно относиться к тому, что агенты тебе нагенерят. Иначе и те, и другие будут медленнее, чем их же альтернативные версии, которые это делают.
К предыдущему посту хочется ещё вот какой вывод зафиксировать. Раньше на разных сторонах спектра были стартапы и кровавые энтерпрайзы. И с ними ассоциировались конкретные процессы. Например, покрывают проект тестами и утопают в бюрократии — энтерпрайзы, а стартапы — действуют быстро, забивая на всё, что не несёт понятный инкремент для бизнеса.
И забавно, что с AI для эффективной работы нужно схлопнуть эти два мира. Стартапы обязаны делать quality гейты и работать с документацией на раннем этапе, а энтерпрайзы обязаны научиться гибко и спокойно относиться к тому, что агенты тебе нагенерят. Иначе и те, и другие будут медленнее, чем их же альтернативные версии, которые это делают.
👍4
Про команды, скиллы, агентов и плагины
В последние дни мне слишком часто попадается контент, где кто-то сделал какой-то плагин для Claude Code, какие-то скиллы, агенты и всё в таком духе. Кажется, не все понимают, что эти слова вообще значат. Поэтому какой-то хайп и фомо на пустом месте разводится.
В двух словах:
- Команда — это просто промпт, который можно отправить с автокомплитом.
- Скилл — это команда, которую агент может вызвать сам, поняв по косвенным признакам.
- Агент — это отдельный процесс с промптом, отправленным в новое контекстное окно
- Плагин — это Claude Code специфичный способ загружать всё вышеперечисленное + хуки + mcp пачками. Или из локальной папки, или из какой-то репы.
Хот тейк: вам ничего чужого из этого не надо почти никогда, вам нужны только идеи. Единственное важное здесь — промпты.
И если вы где-то видите, что кто-то опубликовал плагин для Claude Code с агентом для упрощения кода, или со скиллами для работы с андроидом, то в голове это надо переводить примерно так: "я тут клодкодом нагенерил текст промпта, возможно вычитал, и поправил, чтобы он делал как я хочу".
Просто нагенерьте свой таким же образом, но на основе текущего состояния проекта или своего видения. Это несложно. В лучшем случае используйте чужие промпты как референс. А то потом окажется, что агент для упрощения кода подразумевает, что вы вообще-то на реакте пишете CLI приложение, а скилл для написания андроид фичи говорит о каких-то библиотеках, которых у вас в проекте нет и никогда не было. Мусор и противоречия вам в контексте нужны в последнюю очередь.
Чем больше в промпте специфики, тем меньше вероятность, что им нужно делиться. Чем меньше в промпте специфики, тем меньше вероятность, что это вообще нужно писать, т.к. модель и сама это скорее всего знает.
В последние дни мне слишком часто попадается контент, где кто-то сделал какой-то плагин для Claude Code, какие-то скиллы, агенты и всё в таком духе. Кажется, не все понимают, что эти слова вообще значат. Поэтому какой-то хайп и фомо на пустом месте разводится.
В двух словах:
- Команда — это просто промпт, который можно отправить с автокомплитом.
- Скилл — это команда, которую агент может вызвать сам, поняв по косвенным признакам.
- Агент — это отдельный процесс с промптом, отправленным в новое контекстное окно
- Плагин — это Claude Code специфичный способ загружать всё вышеперечисленное + хуки + mcp пачками. Или из локальной папки, или из какой-то репы.
Хот тейк: вам ничего чужого из этого не надо почти никогда, вам нужны только идеи. Единственное важное здесь — промпты.
И если вы где-то видите, что кто-то опубликовал плагин для Claude Code с агентом для упрощения кода, или со скиллами для работы с андроидом, то в голове это надо переводить примерно так: "я тут клодкодом нагенерил текст промпта, возможно вычитал, и поправил, чтобы он делал как я хочу".
Просто нагенерьте свой таким же образом, но на основе текущего состояния проекта или своего видения. Это несложно. В лучшем случае используйте чужие промпты как референс. А то потом окажется, что агент для упрощения кода подразумевает, что вы вообще-то на реакте пишете CLI приложение, а скилл для написания андроид фичи говорит о каких-то библиотеках, которых у вас в проекте нет и никогда не было. Мусор и противоречия вам в контексте нужны в последнюю очередь.
Чем больше в промпте специфики, тем меньше вероятность, что им нужно делиться. Чем меньше в промпте специфики, тем меньше вероятность, что это вообще нужно писать, т.к. модель и сама это скорее всего знает.
🔥5