Спасибо всем, кто пришёл на воркшоп! 🙌 Особый респект тем, кто не просто слушал, а задавал вопросы, делился мыслями, шарил экран Курсора с успехами и не терял концентрацию три с лишним часа подряд. Вы — супер 💪
Ещё один важный повод сказать спасибо — это репосты. Благодаря им канал наконец пробил 300 подписчиков 🚀
Раз этот коварный план сработал, продолжу гнуть свою линию: запись воркшопа будет доступна в той же группе — со входом за репост. А здесь я буду постепенно делиться разными тизерами и хайлайтами. Начну прямо сейчас!
💡 Мысль, которая родилась как введение к практической части воркшопа.
Всем менеджерам хорошо знакома аббревиатура S.M.A.R.T. — мы по ней ставим цели себе, команде и вообще кому угодно. Но что если поразмышлять, как SMART применим к AI-driven разработке?
Начну с конца, потому что там самое понятное, а потом вернусь в начало.
🧾 T — это больше никакой не Time-Bound. Теперь это Token-Bound.
Причём в двух смыслах сразу: и в плане длины промта, и в том, что задача должна укладываться в лимит по ресурсам.
Агент не должен думать бесконечно — нужно дать ему возможность остановиться, пока он не сожрал все токены с твоей кредитки и ничего дельного не выдал.
🎯 S — Specific
Тут всё как раньше, если не хуже. Дать человеку немного свободы в постановке задачи — можно. Дать её LLMке — чаще всего значит получить непредсказуемый результат.
Если ты не понимаешь, чего хочешь от LLM’ки, — она уж точно не поймёт. И сделает совсем не то, что ты хотел бы увидеть.
📏 M — Measurable
Вот это уже интереснее. Вопрос-то простой: как ты поймёшь, что результат — именно тот, который был нужен? А вот найти ответ на него…
Попросишь написать тесты? Окей. А тесты кто проверять будет?
В общем, с LLM’ками буква M — одна из самых непростых.
Нужна такая форма постановки, при которой и ты, и модель можете убедиться в том, что именного этого результата вы и добивались.
✅ A — Achievable
Здесь попроще. Не хочешь, чтобы Cursor нафантазировал — сначала проверь, достижима ли цель.
Обсуди её с ChatGPT, Gemini, DeepSeek — или с тем же Claude, который у тебя внутри Cursor сидит.
Главное — убедиться, что ты не просишь невозможного. Человека это демотивирует, а LLM’ку отправляет в галлюцинагенный трип.
Она тебе скажет, что всё сделала, а ты такой: я же M не забыл, правда?
📚 R — Relevant
Несмотря на то же английское слово, смысл этой буквы сильно поменялся.
Relevant — больше не «актуальная», а вот прям релевантная: коду, документации, содержимому .cursor/rules.
Agentic-AI не будет спорить, если ты попросишь странного — он просто начнёт переписывать всё, что под руку попадётся. Да так, что ты не будешь рад ни потраченному количеству токенов, ни незапланированному рефакторингу, ни тому, что ты полностью потерял M из всех предыдущих целей и задач.
Короче, кажется, SMART живее всех живых, хоть и заиграл немного новыми красками в контексте AI.
А ты что думаешь про их сочетание? 👀
Ещё один важный повод сказать спасибо — это репосты. Благодаря им канал наконец пробил 300 подписчиков 🚀
Раз этот коварный план сработал, продолжу гнуть свою линию: запись воркшопа будет доступна в той же группе — со входом за репост. А здесь я буду постепенно делиться разными тизерами и хайлайтами. Начну прямо сейчас!
💡 Мысль, которая родилась как введение к практической части воркшопа.
Всем менеджерам хорошо знакома аббревиатура S.M.A.R.T. — мы по ней ставим цели себе, команде и вообще кому угодно. Но что если поразмышлять, как SMART применим к AI-driven разработке?
Начну с конца, потому что там самое понятное, а потом вернусь в начало.
🧾 T — это больше никакой не Time-Bound. Теперь это Token-Bound.
Причём в двух смыслах сразу: и в плане длины промта, и в том, что задача должна укладываться в лимит по ресурсам.
Агент не должен думать бесконечно — нужно дать ему возможность остановиться, пока он не сожрал все токены с твоей кредитки и ничего дельного не выдал.
🎯 S — Specific
Тут всё как раньше, если не хуже. Дать человеку немного свободы в постановке задачи — можно. Дать её LLMке — чаще всего значит получить непредсказуемый результат.
Если ты не понимаешь, чего хочешь от LLM’ки, — она уж точно не поймёт. И сделает совсем не то, что ты хотел бы увидеть.
📏 M — Measurable
Вот это уже интереснее. Вопрос-то простой: как ты поймёшь, что результат — именно тот, который был нужен? А вот найти ответ на него…
Попросишь написать тесты? Окей. А тесты кто проверять будет?
В общем, с LLM’ками буква M — одна из самых непростых.
Нужна такая форма постановки, при которой и ты, и модель можете убедиться в том, что именного этого результата вы и добивались.
✅ A — Achievable
Здесь попроще. Не хочешь, чтобы Cursor нафантазировал — сначала проверь, достижима ли цель.
Обсуди её с ChatGPT, Gemini, DeepSeek — или с тем же Claude, который у тебя внутри Cursor сидит.
Главное — убедиться, что ты не просишь невозможного. Человека это демотивирует, а LLM’ку отправляет в галлюцинагенный трип.
Она тебе скажет, что всё сделала, а ты такой: я же M не забыл, правда?
📚 R — Relevant
Несмотря на то же английское слово, смысл этой буквы сильно поменялся.
Relevant — больше не «актуальная», а вот прям релевантная: коду, документации, содержимому .cursor/rules.
Agentic-AI не будет спорить, если ты попросишь странного — он просто начнёт переписывать всё, что под руку попадётся. Да так, что ты не будешь рад ни потраченному количеству токенов, ни незапланированному рефакторингу, ни тому, что ты полностью потерял M из всех предыдущих целей и задач.
Короче, кажется, SMART живее всех живых, хоть и заиграл немного новыми красками в контексте AI.
А ты что думаешь про их сочетание? 👀
❤8👍3👏2🦄1👾1
На воркшопе практическая часть сразу пошла не по плану 🙈
Я попросил Курсор последовательно выполнить три разные задачи:
📌 Написать код функций для AWS Lambda
📌 Описать CDK-стек для деплоя
📌 Собственно, провести деплой
И когда деплой не завёлся, а Курсор начал искать варианты решения проблемы, он предложил мне понизить версию Python в лямбдах до 3.6. Я сначала не понял, а потом как понял…
Одна из самых частых проблем, возникающих при работе над многослойными проектами в Курсоре, — это управление зависимостями. Он постоянно прописывает конкретные версии библиотек, не проверяя их актуальность. Как результат — устаревшие либы, которые тянут за собой устаревшие рантаймы. Версия AWS CDK, которую он указал, была на 900 😱😱😱 релизов старше последней стабильной! Отсюда и всплыл Python 3.6
В общем, после воркшопа родилось новое правило для Cursor Rules, которое сразу же показало свою эффективность в воскресенье, пока я работал над очередным проектом:
✅ Перед тем как прописывать любые зависимости, узнай, какая последняя стабильная версия, и проверь, не установлена ли уже нужная библиотека локально.
В .cursor/rules, конечно, это выглядит иначе. Вот во что Курсор транслировал моё короткое требование 👇
Я попросил Курсор последовательно выполнить три разные задачи:
📌 Написать код функций для AWS Lambda
📌 Описать CDK-стек для деплоя
📌 Собственно, провести деплой
И когда деплой не завёлся, а Курсор начал искать варианты решения проблемы, он предложил мне понизить версию Python в лямбдах до 3.6. Я сначала не понял, а потом как понял…
Одна из самых частых проблем, возникающих при работе над многослойными проектами в Курсоре, — это управление зависимостями. Он постоянно прописывает конкретные версии библиотек, не проверяя их актуальность. Как результат — устаревшие либы, которые тянут за собой устаревшие рантаймы. Версия AWS CDK, которую он указал, была на 900 😱😱😱 релизов старше последней стабильной! Отсюда и всплыл Python 3.6
В общем, после воркшопа родилось новое правило для Cursor Rules, которое сразу же показало свою эффективность в воскресенье, пока я работал над очередным проектом:
✅ Перед тем как прописывать любые зависимости, узнай, какая последняя стабильная версия, и проверь, не установлена ли уже нужная библиотека локально.
В .cursor/rules, конечно, это выглядит иначе. Вот во что Курсор транслировал моё короткое требование 👇
## Python Runtime Version Alignment
- ALWAYS align Python runtime versions between local development and AWS Lambda
- Required Python version: 3.13.x
- Required Lambda runtime: PYTHON_3_13
- AWS Lambda supported Python runtimes: PYTHON_3_8, PYTHON_3_9, PYTHON_3_10, PYTHON_3_11, PYTHON_3_12, PYTHON_3_13
- Ensure all development environments (local, venv, CI/CD) use Python 3.13.x
- Test Lambda functions locally with target Python version before deployment
## Python Dependencies (requirements.txt)
- ALWAYS check for the latest version of any external library before adding it to requirements.txt
- Use exact version pinning (==) for all dependencies to ensure reproducibility
- Before adding a new dependency, verify its latest version using:
- PyPI: https://pypi.org/project/[package-name]/
- pip index versions [package-name]
- Or use tools like pip-check-updates or pip-review
## Node.js Dependencies (package.json)
- ALWAYS check for the latest version of any external library before adding it to package.json
- Use exact version pinning (no ^ or ~) for production dependencies to ensure reproducibility
- Before adding a new dependency, verify its latest version using:
- npm view [package-name] version
- npm outdated
- Or use tools like npm-check-updates or npm-check
## Version Update Process
1. Before adding any new dependency, research the latest stable version
2. Check for breaking changes in major version updates
3. Test compatibility with existing codebase
4. Update all related files (requirements.txt, package.json, package-lock.json)
5. Document any breaking changes or migration steps
❤11👾4🐳3👀2
Не знаю, многие ли из вас планируют персональные задачи спринтами, но я вот уже месяц практикую такой подход.
Когда у тебя утром и вечером есть всего по полчаса-часу на свои пет-проекты, важно иметь заранее подготовленный список конкретных небольших задач. Но бывает лень тратить время на дробление одной большой задачи на несколько мелких. Думаешь: «Ну, это же моя задача, я буду её делать, я понимаю, что тут нужно сделать, зачем тратить время и дробить» 🤔
И вот вчера я нашел ответ на этот вопрос. Задачи бывают двух типов — интересные и скучные. И важно декомпозировать и те, и другие, но причины для этого совершенно разные.
🔸 Скучные задачи имеет смысл дробить, чтобы они не висели мертвым грузом до последнего. Ведь чтобы сесть за нудную большую задачу нужно либо много времени и сил, либо дедлайн завтра. А небольшие не особо интересные задачки намного легче «рассасываются» в течение недели. К тому же чувство выполненного долга после закрытия скучной задачи бесценно!
🔸 Интересные задачи надо разбивать по другой причине: они слишком легко увлекают и уводят в сторону. Можно неожиданно обнаружить себя где-то в области, которая очень увлекательна, но совсем не обязательна для конечной цели. Маленькие, заранее подготовленные кусочки помогут сохранить фокус и не потеряться в увлекательных, но ненужных деталях ✨
В общем, как бы мне ни хотелось меньше быть менеджером в нерабочее время, ничего не получается. 🤷♂️ Но тут по крайней мере мне не надо ни с кем кроме себя бороться, чтобы сначала думать, а потом делать 😅
Когда у тебя утром и вечером есть всего по полчаса-часу на свои пет-проекты, важно иметь заранее подготовленный список конкретных небольших задач. Но бывает лень тратить время на дробление одной большой задачи на несколько мелких. Думаешь: «Ну, это же моя задача, я буду её делать, я понимаю, что тут нужно сделать, зачем тратить время и дробить» 🤔
И вот вчера я нашел ответ на этот вопрос. Задачи бывают двух типов — интересные и скучные. И важно декомпозировать и те, и другие, но причины для этого совершенно разные.
🔸 Скучные задачи имеет смысл дробить, чтобы они не висели мертвым грузом до последнего. Ведь чтобы сесть за нудную большую задачу нужно либо много времени и сил, либо дедлайн завтра. А небольшие не особо интересные задачки намного легче «рассасываются» в течение недели. К тому же чувство выполненного долга после закрытия скучной задачи бесценно!
🔸 Интересные задачи надо разбивать по другой причине: они слишком легко увлекают и уводят в сторону. Можно неожиданно обнаружить себя где-то в области, которая очень увлекательна, но совсем не обязательна для конечной цели. Маленькие, заранее подготовленные кусочки помогут сохранить фокус и не потеряться в увлекательных, но ненужных деталях ✨
В общем, как бы мне ни хотелось меньше быть менеджером в нерабочее время, ничего не получается. 🤷♂️ Но тут по крайней мере мне не надо ни с кем кроме себя бороться, чтобы сначала думать, а потом делать 😅
❤10🔥6🤓3👾2
Media is too big
VIEW IN TELEGRAM
С момента моего воркшопа прошло уже больше месяца, но со временем такая беда, что только вчера я, наконец, добрался до того, чтобы быстро промотать 3-часовое видео с него. Понял, что единственная часть, которой можно поделиться без монтажа на более широкую аудиторию — это 30-минутное теоретическое вступление. Оно про то как вообще устроены ТГ-боты, что такое серверлесс и почему они подходят друг для друга. Правда, мне до сих пор сложно сказать для какого уровня подготовки эта вводная часть, так что очень хочется услышать ваши мнения.
❤7🔥4👾4
А мои эксперименты с серверлесс подходами продолжаются. Я тут собрал аппки под Android и iOS, которые умеют транскрибировать аудио-сообщения. И весь бекенд транскрибации полностью Serverless. Ставьте 👾, если интересно, чтобы я подробнее об этом рассказал.
👾14❤2🦄2🤔1
Недавно услышал где-то версию, что английское выражение biased происходит от теоремы Байеса (хоть и пишется совсем не так). А вчера, после того, как поделился этим "знанием" с женой, решил проверить эту теорию в ChatGPT и он выдал совсем другую этимологию — от французского слова biais.
Мне, конечно, теория про теорему Байеса нравится больше. А вам?
Мне, конечно, теория про теорему Байеса нравится больше. А вам?
❤3🔥2🤔1👀1
Если про машины я тут писал не так давно (было же что-то про гран-туризмо), то ещё одного своего важного увлечения давно не касался. Вина!
А всё потому, что лучше моей жены о наших дегустациях я точно не расскажу. Но иногда она цитирует меня в своих постах, и мне это доставляет особое удовольствие.
Поводом поделиться её каналом сегодня стало шедевральное описание (и такая же фотография) выдающегося вина. Точнее, двух вин — нашего “дежурного особенного” и выдающегося.
В посте можно наблюдать всё наше винное задротство сразу — сравнительные дегустации, ассортимент бокалов и, конечно, внимательный анализ обонятельных и вкусовых ощущений. И, да, каждое из этих вин было продегустировано минимум из трёх бокалов, а на фото — именно те, что подходят лучше всего. Для Rose de Xinomavro — этоGrassl Liberte Josephine N°2, а для Blanc de Rose — Grassl Cru.
Ладно, на этом остановлюсь — если вам про вина интересно, лучше подпишитесь на Валю. Особенно, если вы на Кипре. Выбор вин тут не такой большой, как на континенте, а без проводника очень легко решить, что ничего интересного тут не найти.
https://t.me/winesails/461
А всё потому, что лучше моей жены о наших дегустациях я точно не расскажу. Но иногда она цитирует меня в своих постах, и мне это доставляет особое удовольствие.
Поводом поделиться её каналом сегодня стало шедевральное описание (и такая же фотография) выдающегося вина. Точнее, двух вин — нашего “дежурного особенного” и выдающегося.
В посте можно наблюдать всё наше винное задротство сразу — сравнительные дегустации, ассортимент бокалов и, конечно, внимательный анализ обонятельных и вкусовых ощущений. И, да, каждое из этих вин было продегустировано минимум из трёх бокалов, а на фото — именно те, что подходят лучше всего. Для Rose de Xinomavro — это
Ладно, на этом остановлюсь — если вам про вина интересно, лучше подпишитесь на Валю. Особенно, если вы на Кипре. Выбор вин тут не такой большой, как на континенте, а без проводника очень легко решить, что ничего интересного тут не найти.
https://t.me/winesails/461
Telegram
Культ вина🥂 [на Кипре]
Ксиномавро во всей красе — две версии от Apostolos Thymiopoulos.
Про Rose de Xinomavro я уже писала. В сегодняшнем сравнительном тесте с блан-де-розе оно кажется очень юным и свежим. Звонкое вино с ароматом вяленого томата, зеленого чая и абрикоса.
Версия…
Про Rose de Xinomavro я уже писала. В сегодняшнем сравнительном тесте с блан-де-розе оно кажется очень юным и свежим. Звонкое вино с ароматом вяленого томата, зеленого чая и абрикоса.
Версия…
❤7🔥5🍾2👍1😁1🙈1
Чем дальше, тем больше хочу сделать сервис по AI-сбору требований. Сегодня понял, что основной метрикой для людей, с которых собираются эти требования, в нём будет доля релевантных ответов на поставленные вопросы.
И, хоть я и не верю в универсальные метрики, но если бы мне нужно было выбрать одну метрику для перформанс-ревью сотрудников, исходя из которой можно было бы решать увольнять человека или повышать, я бы выбрал именно её. Ничего не отнимает у меня столько ментальных сил и, как следствие, не тормозит проекты, сколько неумение людей отвечать на поставленные вопросы.
И, хоть я и не верю в универсальные метрики, но если бы мне нужно было выбрать одну метрику для перформанс-ревью сотрудников, исходя из которой можно было бы решать увольнять человека или повышать, я бы выбрал именно её. Ничего не отнимает у меня столько ментальных сил и, как следствие, не тормозит проекты, сколько неумение людей отвечать на поставленные вопросы.
❤7👍2
Больше года я исследовал то, как LLM'ки могут писать код и как они могут выступать частью продукта. В основном, я делал это в рамках пет-проектов или даже совсем искусственных упражнений, но удавалось поэкспериментировать с ними и для работы в корпорации. Главный вывод, который я сделал за это время — для того, чтобы применение AI-инструментов действительно значимо влияло на результаты или, хотя бы, на скорость их достижения, должны поменяться практически все R&D-процессы. И из-за этого осознания меня мучило дикое FOMO — AI-революция происходит, но я в ней не участвую.
Несколько месяцев назад мой старый друг и коллега обратился ко мне за советом на тему LLM'ок в его проекте. Мы созвонились с ним и его партнером по бизнесу, обменялись идеями и разошлись. Через некоторое время я понял, что тема, которую ребята подняли, мне очень интересна, и я предложил им более тесно сотрудничать. Так у меня появился настоящий бизнесовый пет-проект с AI, в котором мой голос стал решающим при принятии технических решений.
Ещё через некоторое время, у нас появилось ощущение, что под проект пора искать инвестиции, подаваться с ним на стартап-визу и ехать на WebSummit, чтобы заявить о себе широкой общественности. А в моей голове встал вопрос — готов ли я сделать прыжок веры, отказаться от стабильного корпоративного дохода и прочих плюшек, чтобы попытаться стать частью движущей силы AI-трансформации всего вокруг.
И я ответил на этот вопрос "Да!"
В этом "Да" сошлось столько разных аспектов, что, кажется, у меня не было другого выбора:
— Я давно хотел стать CTO, но даже когда меня собеседовали на позицию Engineering Manager, я всё равно оказывался продактом;
— Я давно хотел жить в Альпах или рядом с ними, но последние пару лет живу на Кипре, а получить Шенген тут это целая история;
— Со времён работы со стартапами в Microsoft (привет мой 2017й) я мечтал сгонять на WebSummit в роли фаундера;
— За много лет работы в разных компаниях, есть меньше десятка людей, с которыми мне очень хотелось бы снова поработать вместе, и мой нынешний кофаундер один из них;
— Ну и, конечно, я больше года хотел, чтобы AI стал основой моей ежедневной работы, а в этом проекте он и код пишет, и требования, и непосредственно в бизнес-логике принимает активное участие.
В общем, не знаю пока, куда вся эта история меня приведёт, но всё это очень волнительно и вдохновляюще. Так что пожелайте мне удачи! А я постараюсь тут почаще рассказывать и о нашем проекте, и о своих AI-находках, обнаруженных по мере его реализации.
Stay Tuned!
Несколько месяцев назад мой старый друг и коллега обратился ко мне за советом на тему LLM'ок в его проекте. Мы созвонились с ним и его партнером по бизнесу, обменялись идеями и разошлись. Через некоторое время я понял, что тема, которую ребята подняли, мне очень интересна, и я предложил им более тесно сотрудничать. Так у меня появился настоящий бизнесовый пет-проект с AI, в котором мой голос стал решающим при принятии технических решений.
Ещё через некоторое время, у нас появилось ощущение, что под проект пора искать инвестиции, подаваться с ним на стартап-визу и ехать на WebSummit, чтобы заявить о себе широкой общественности. А в моей голове встал вопрос — готов ли я сделать прыжок веры, отказаться от стабильного корпоративного дохода и прочих плюшек, чтобы попытаться стать частью движущей силы AI-трансформации всего вокруг.
И я ответил на этот вопрос "Да!"
В этом "Да" сошлось столько разных аспектов, что, кажется, у меня не было другого выбора:
— Я давно хотел стать CTO, но даже когда меня собеседовали на позицию Engineering Manager, я всё равно оказывался продактом;
— Я давно хотел жить в Альпах или рядом с ними, но последние пару лет живу на Кипре, а получить Шенген тут это целая история;
— Со времён работы со стартапами в Microsoft (привет мой 2017й) я мечтал сгонять на WebSummit в роли фаундера;
— За много лет работы в разных компаниях, есть меньше десятка людей, с которыми мне очень хотелось бы снова поработать вместе, и мой нынешний кофаундер один из них;
— Ну и, конечно, я больше года хотел, чтобы AI стал основой моей ежедневной работы, а в этом проекте он и код пишет, и требования, и непосредственно в бизнес-логике принимает активное участие.
В общем, не знаю пока, куда вся эта история меня приведёт, но всё это очень волнительно и вдохновляюще. Так что пожелайте мне удачи! А я постараюсь тут почаще рассказывать и о нашем проекте, и о своих AI-находках, обнаруженных по мере его реализации.
Stay Tuned!
1❤30🔥10👏7🦄2
Channel name was changed to «CTO & Co-founder with AI tools»
Самое сложное с активным внедрением AI-агентов — признаться самому себе, что все привычные паттерны нужно пересматривать на адекватность практически каждый день. Новые тулы, новые возможности = новые вопросы: "А как теперь правильно?"
Наглядный пример с прошлой недели. Верстаю в Cursor странички онбординга. Должно получиться что-то типа визарда — несколько экранов с повторяющимися элементами и разным контентом. Как бы я делал это раньше сам или декомпозировал на задачи человеку? Сначала проанализировал бы, что в этих страницах общего, сверстал переиспользуемые компоненты, а потом уже набивал бы их контентом.
А как это выглядит в Cursor? Я сказал ему, сколько будет шагов, и дальше выделяю в Фигме один за другим экраны, прошу реализовать. А уже потом, когда он наверстал всё отдельно, говорю: а теперь отрефактори так, чтобы общие элементы были переиспользуемыми.
Раньше это было бы жёстким антипаттерном. Моей задачей как менеджера было дать разработчику как можно больше контекста, чтобы он мог заранее предусмотреть возможности для расширения функциональности в будущем. Сейчас, возможно, именно так и правильно. Если дать AI-агенту лишнего контекста, он с гораздо большей вероятностью поймёт что-то не так и налажает. Зато задача рефакторинга как раз отлично подходит для агентов — особенно если функциональность хорошо покрыта тестами.
В общем, чувствую себя первокурсником, которому первого сентября говорят: "Забудь всё, чему тебя учили в школе". Только говорю это я себе сам и практически каждый день. Если честно, очень утомляет 😅
Наглядный пример с прошлой недели. Верстаю в Cursor странички онбординга. Должно получиться что-то типа визарда — несколько экранов с повторяющимися элементами и разным контентом. Как бы я делал это раньше сам или декомпозировал на задачи человеку? Сначала проанализировал бы, что в этих страницах общего, сверстал переиспользуемые компоненты, а потом уже набивал бы их контентом.
А как это выглядит в Cursor? Я сказал ему, сколько будет шагов, и дальше выделяю в Фигме один за другим экраны, прошу реализовать. А уже потом, когда он наверстал всё отдельно, говорю: а теперь отрефактори так, чтобы общие элементы были переиспользуемыми.
Раньше это было бы жёстким антипаттерном. Моей задачей как менеджера было дать разработчику как можно больше контекста, чтобы он мог заранее предусмотреть возможности для расширения функциональности в будущем. Сейчас, возможно, именно так и правильно. Если дать AI-агенту лишнего контекста, он с гораздо большей вероятностью поймёт что-то не так и налажает. Зато задача рефакторинга как раз отлично подходит для агентов — особенно если функциональность хорошо покрыта тестами.
В общем, чувствую себя первокурсником, которому первого сентября говорят: "Забудь всё, чему тебя учили в школе". Только говорю это я себе сам и практически каждый день. Если честно, очень утомляет 😅
1❤13👍2🤯2👾1
Кто угадает, не раскрывая спойлер, как накосячил Cursor?
Не так сложно что-то разработать с помощью вайбкодинга, как потом это всё задеплоить в продакшн. Но мне казалось, что я со своей насмотренностью на самые разные косяки при миграции из дева в прод избегу детских ошибок.
Созваниваемся вчера с дизайнером посмотреть на то, что у нас получается в проекте. Я показываю, у меня всё красиво, а у него не грузится ни одна картинка. Странно — у меня-то всё работает стабильно в разных браузерах, на разных страницах, и с локальными серверами, и опубликованное в AWS. Значит, у всех всё должно работать нормально? Не мог же Cursor указать адреса файлов на компьютере?
Не мог. Но смог поставить ссылки на localhost. Но почему же этот localhost работал всегда, сколько бы раз я ни перезапускал dev-сервера на разных портах?А потому что это был порт, на котором крутится Figma MCP!
Не так сложно что-то разработать с помощью вайбкодинга, как потом это всё задеплоить в продакшн. Но мне казалось, что я со своей насмотренностью на самые разные косяки при миграции из дева в прод избегу детских ошибок.
Созваниваемся вчера с дизайнером посмотреть на то, что у нас получается в проекте. Я показываю, у меня всё красиво, а у него не грузится ни одна картинка. Странно — у меня-то всё работает стабильно в разных браузерах, на разных страницах, и с локальными серверами, и опубликованное в AWS. Значит, у всех всё должно работать нормально? Не мог же Cursor указать адреса файлов на компьютере?
Не мог. Но смог поставить ссылки на localhost. Но почему же этот localhost работал всегда, сколько бы раз я ни перезапускал dev-сервера на разных портах?
😁4👍2👻1👨💻1👀1
Перед WebSummit вся моя соцактивность перекочевала в LinkedIn.
Мы там уже представили команду, рассказали, с кем хотим встретиться, а я даже успел написать короткий и не очень серьёзный пост про GitHub spec-kit.
А сегодня пробую новый тип контента.
Запостил самодельный мем с довольно провокационной подписью и теперь проверяю, получится ли его немного завирусить.
Так что если вы ещё не подписаны на мой LinkedIn — самое время это сделать и сразу полайкать пост конечно же.
А если знаете кого-то, кто оценит шутку — тегните его там в комментах 🍷💚🇵🇹
Мы там уже представили команду, рассказали, с кем хотим встретиться, а я даже успел написать короткий и не очень серьёзный пост про GitHub spec-kit.
А сегодня пробую новый тип контента.
Запостил самодельный мем с довольно провокационной подписью и теперь проверяю, получится ли его немного завирусить.
Так что если вы ещё не подписаны на мой LinkedIn — самое время это сделать и сразу полайкать пост конечно же.
А если знаете кого-то, кто оценит шутку — тегните его там в комментах 🍷💚🇵🇹
❤6🍾2🦄2
Перед началом Web Summit я всерьёз думал, что буду вести здесь дневник — каждый день постить мысли, инсайты, истории или просто фотографии с места событий. Казалось, что столько поводов писать, что всё это случится само собой. Ещё и на следующую неделю хватит, чтобы всё это отрефлексировать.
По факту же выяснилось (в очередной раз), что я вообще не блогер. 😅
Каждый вечер я просто падал без сил в номере, а утром бежал на новые встречи не вспоминая про свои "социальные обязательства". А когда мы вернулись домой, я ещё и приболел, так что всю прошлую неделю не было ни сил, ни концентрации, ни желания что-то формулировать. И тем забавнее, что менеджерский вывод из всей этой поездки, который хочется сделать первым, вообще не о том, что я видел на Web Summit. Нет, конечно, про него я тоже напишу, но потом, а сегодня будет о вечном. 🍷
В пятницу вечером, когда русские фаундеры и инвесторы отходили от WS на тусовке s16, мы с женой тоже поехали выдохнуть — но по-своему: на винодельню Луиша Пату.
Нам повезло не только попасть на дегустацию, но и встретиться и пообщаться с самим виноделом. А ещё мы оказались на еженедельном Happy Hour винодельни, где все сотрудники (их всего около десяти) собираются в пятницу вечером.
Так вот. Почти 50 лет Луиш Пато делает вина из одного и того же винограда. У него одна итерация в год — урожай чаще не соберёшь. И каждый раз он делает что-то по-новому: меняет подход к сбору, к выдержке, к купажированию. Но при этом годовом «релизном цикле» каждую пятницу на винодельне проходит что-то вроде спринт-ревью, демо и ретро в одном лице.
Раз в неделю вся команда собирается за столом с закусками, открывает экспериментальные бутылки, пробует, обсуждает, спорит и находит новые идеи. В том числе такие, которые можно попробовать внедрить только через год.
Сам Луиш Пато постоянно говорит — я не энолог, всё, что я знаю — это то, что я узнал сам за годы экспериментов. И теперь, когда мы оттуда уже уехали, мне стало очень интересно узнать, как же у Луиша Пато выглядят записи. Невозможно столько экспериментов держать в голове. Невозможно за год не забыть классные идеи, если аккуратно их не фиксировать. Я в проекте длинной несколько недель регулярно путаюсь в гипотезах, выводах и целеполагании следующих итераций. А он экспериментирует 50 лет и добивается фантастических результатов.
Чисто менеджерски хочется сделать из этого вывод про универсальность некоторых управленческих практик. Не важно, чем ты занимаешься, как часто ты выпускаешь новый продукт и когда будет возможность внедрить изменения, для совершенствования тебе нужна площадка, где мнение каждого участника процесса о том, что можно сделать по-другому, будет услышано. Да, конечно, это хорошо работает тогда, когда у тебя достаточно небольшая команда. Но с учётом нынешнего уровня развития технологий, я всё больше верю в силу небольших команд! Мы, например, верим, что в Aivaly не должно быть больше 10 FTE.
Ну и, конечно, пусть у нас у всех будет занятие, в котором нам будет в кайф стремиться к совершенству каждый день в течение 50 лет. ✨
P.S. Про винную часть этой истории можно почитать здесь.
По факту же выяснилось (в очередной раз), что я вообще не блогер. 😅
Каждый вечер я просто падал без сил в номере, а утром бежал на новые встречи не вспоминая про свои "социальные обязательства". А когда мы вернулись домой, я ещё и приболел, так что всю прошлую неделю не было ни сил, ни концентрации, ни желания что-то формулировать. И тем забавнее, что менеджерский вывод из всей этой поездки, который хочется сделать первым, вообще не о том, что я видел на Web Summit. Нет, конечно, про него я тоже напишу, но потом, а сегодня будет о вечном. 🍷
В пятницу вечером, когда русские фаундеры и инвесторы отходили от WS на тусовке s16, мы с женой тоже поехали выдохнуть — но по-своему: на винодельню Луиша Пату.
Нам повезло не только попасть на дегустацию, но и встретиться и пообщаться с самим виноделом. А ещё мы оказались на еженедельном Happy Hour винодельни, где все сотрудники (их всего около десяти) собираются в пятницу вечером.
Так вот. Почти 50 лет Луиш Пато делает вина из одного и того же винограда. У него одна итерация в год — урожай чаще не соберёшь. И каждый раз он делает что-то по-новому: меняет подход к сбору, к выдержке, к купажированию. Но при этом годовом «релизном цикле» каждую пятницу на винодельне проходит что-то вроде спринт-ревью, демо и ретро в одном лице.
Раз в неделю вся команда собирается за столом с закусками, открывает экспериментальные бутылки, пробует, обсуждает, спорит и находит новые идеи. В том числе такие, которые можно попробовать внедрить только через год.
Сам Луиш Пато постоянно говорит — я не энолог, всё, что я знаю — это то, что я узнал сам за годы экспериментов. И теперь, когда мы оттуда уже уехали, мне стало очень интересно узнать, как же у Луиша Пато выглядят записи. Невозможно столько экспериментов держать в голове. Невозможно за год не забыть классные идеи, если аккуратно их не фиксировать. Я в проекте длинной несколько недель регулярно путаюсь в гипотезах, выводах и целеполагании следующих итераций. А он экспериментирует 50 лет и добивается фантастических результатов.
Чисто менеджерски хочется сделать из этого вывод про универсальность некоторых управленческих практик. Не важно, чем ты занимаешься, как часто ты выпускаешь новый продукт и когда будет возможность внедрить изменения, для совершенствования тебе нужна площадка, где мнение каждого участника процесса о том, что можно сделать по-другому, будет услышано. Да, конечно, это хорошо работает тогда, когда у тебя достаточно небольшая команда. Но с учётом нынешнего уровня развития технологий, я всё больше верю в силу небольших команд! Мы, например, верим, что в Aivaly не должно быть больше 10 FTE.
Ну и, конечно, пусть у нас у всех будет занятие, в котором нам будет в кайф стремиться к совершенству каждый день в течение 50 лет. ✨
P.S. Про винную часть этой истории можно почитать здесь.
❤9🍾3🦄3
Вчера созванивались с коллегой-фронтендером, которая сейчас в поиске работы. Почти весь разговор был довольно стандартным — где искать вакансии, кому писать, какие компании подходят. Но в конце Настя задала важный вопрос про AI-тулы: насколько долго в них погружаться и нужно ли начинать прямо сейчас, если ещё не начал? 🤔
Конечно да! Понимать, как AI-driven IDE ускоряет именно твою работу, — это уже базовый навык. А самое главное: эффективность твоей работы растёт пропорционально времени, которое ты проводишь в конкретном туле. Чем больше ты в нём живёшь, тем лучше понимаешь его сильные стороны, ограничения и моменты, когда ему точно доверять не стоит. Так что начинать нужно было ещё вчера.
Плюс, такие вещи как Cursor или Claude Code уже становятся важными ключевыми словами в резюме. Сейчас все хотят, чтобы сотрудники были AI-first: продакты, аналитики, разработчики, тимлиды. Добавить что-то AI-ное в резюме и уметь уверенно рассказать, как тебе помогают новые инструменты — это прям must. Немного скепсиса тоже не помешает: если нанимающий менеджер не видит ограничений AI, которые видишь ты, — возможно, это тревожный звоночек 🚩
Но хватит прелюдий. Теперь по делу. Фронтендер, если ты ещё не пробовал AI-driven разработку — вот топ-5 вещей, с которых стоит начать прямо сейчас:
💻 Поставить AI-driven IDE. Это может быть триалка Cursor или Windsurf, а может быть Google Antigravity (он пока полностью бесплатный) .
✨ Открыть свой старый проект и попросить IDE отрефакторить компонент. Причём в трёх вариантах: Ask, Agent и Plan. Сравнить поведение и уровень контроля над изменениями.
⚙️ Разобраться, где задаются глобальные правила IDE, а где — проектные. Вписать туда свои принципы разработки и конкретные версии инструментов. Посмотреть, когда агенты следуют им, а когда отступают.
🧪 Подключить Figma MCP и попросить IDE заимплементить выделенную область. И обязательно проверить, что картинки не тянутся с фигмовского локалхоста, а то будешь как я вот тут.
🙃 Подключить Chrome DevTools MCP и заставить агента самому проверить в браузере то, что он только что реализовал. Рассказать мне в комментах, что из этого вышло
Уверен, после этих пяти пунктов вопрос «а оно мне надо?» сменится на азартное: «нет, я заставлю тебя понять, чего я от тебя добиваюсь!» Ну а со временем вы точно сработаетесь и станете классной командой 🤖🧑
А вы бы что добавили в этот список для фронтендера?
И стоит ли собрать такие же списки для других ролей?
Конечно да! Понимать, как AI-driven IDE ускоряет именно твою работу, — это уже базовый навык. А самое главное: эффективность твоей работы растёт пропорционально времени, которое ты проводишь в конкретном туле. Чем больше ты в нём живёшь, тем лучше понимаешь его сильные стороны, ограничения и моменты, когда ему точно доверять не стоит. Так что начинать нужно было ещё вчера.
Плюс, такие вещи как Cursor или Claude Code уже становятся важными ключевыми словами в резюме. Сейчас все хотят, чтобы сотрудники были AI-first: продакты, аналитики, разработчики, тимлиды. Добавить что-то AI-ное в резюме и уметь уверенно рассказать, как тебе помогают новые инструменты — это прям must. Немного скепсиса тоже не помешает: если нанимающий менеджер не видит ограничений AI, которые видишь ты, — возможно, это тревожный звоночек 🚩
Но хватит прелюдий. Теперь по делу. Фронтендер, если ты ещё не пробовал AI-driven разработку — вот топ-5 вещей, с которых стоит начать прямо сейчас:
💻 Поставить AI-driven IDE. Это может быть триалка Cursor или Windsurf, а может быть Google Antigravity (он пока полностью бесплатный) .
✨ Открыть свой старый проект и попросить IDE отрефакторить компонент. Причём в трёх вариантах: Ask, Agent и Plan. Сравнить поведение и уровень контроля над изменениями.
⚙️ Разобраться, где задаются глобальные правила IDE, а где — проектные. Вписать туда свои принципы разработки и конкретные версии инструментов. Посмотреть, когда агенты следуют им, а когда отступают.
🧪 Подключить Figma MCP и попросить IDE заимплементить выделенную область. И обязательно проверить, что картинки не тянутся с фигмовского локалхоста, а то будешь как я вот тут.
🙃 Подключить Chrome DevTools MCP и заставить агента самому проверить в браузере то, что он только что реализовал. Рассказать мне в комментах, что из этого вышло
Уверен, после этих пяти пунктов вопрос «а оно мне надо?» сменится на азартное: «нет, я заставлю тебя понять, чего я от тебя добиваюсь!» Ну а со временем вы точно сработаетесь и станете классной командой 🤖🧑
А вы бы что добавили в этот список для фронтендера?
И стоит ли собрать такие же списки для других ролей?
❤4👨💻4🔥3👾2
У меня в гостях сейчас один из главных AI-инженеров recraft и, естественно, каждый вечер мы с ним обсуждаем подходы к работе с LLM’ками, промт-инжиниринг, вайбкодинг и другие подобные вещи.
Вчера он поделился со мной методикой вайбкодинга проектов, которая прошла мимо меня.
Суть простая:
— никакой IDE, только чат с LLM 🤖
— весь репозиторий кидается в контекст одним файлом собранным через gitingest
— в ответ тоже получается один большой файл со всем кодом
Дальше начинается самое интересное:
— этот файл можно отнести в другой чат и попросить найти уязвимости или ошибки 🔍
— можно в разных LLM получить несколько таких файлов и уже третьей LLM’кой попросить их сравнить
— потом «победивший» файл просто загружаешь в свой проект и надеешься, что LLM-ки тебя не обманули 😅
Интуитивно мне этот подход не очень нравится — я в нём теряю последнюю иллюзию контроля над результатом. А вы как думаете — уже можно доверять LLM’кам целые репозитории? 🧑💻💭
Если вы пользовались таким подходом, расскажите, как оно!
Вчера он поделился со мной методикой вайбкодинга проектов, которая прошла мимо меня.
Суть простая:
— никакой IDE, только чат с LLM 🤖
— весь репозиторий кидается в контекст одним файлом собранным через gitingest
— в ответ тоже получается один большой файл со всем кодом
Дальше начинается самое интересное:
— этот файл можно отнести в другой чат и попросить найти уязвимости или ошибки 🔍
— можно в разных LLM получить несколько таких файлов и уже третьей LLM’кой попросить их сравнить
— потом «победивший» файл просто загружаешь в свой проект и надеешься, что LLM-ки тебя не обманули 😅
Интуитивно мне этот подход не очень нравится — я в нём теряю последнюю иллюзию контроля над результатом. А вы как думаете — уже можно доверять LLM’кам целые репозитории? 🧑💻💭
Если вы пользовались таким подходом, расскажите, как оно!
🔥6❤4😁3🤡1
Завтра выходит первый за несколько лет существенный апдейт седьмой Gran Turismo, и я уже знаю, на что уйдут мои выходные. Буду экспериментировать с телеметрией! Жаль, что её, скорее всего, не получится просто выгрузить, поэтому протестируем, как LLM-ки справятся с фотками экранов с этой телеметрией. Интересно, что из этого получится!
PS: Ну и да, ребята, как всегда, молодцы — умудряются продавать одно и то же несколько раз. Вместо шин Michelin теперь везде будут шины Dunlop. А на управление это как-то повлияет, как думаете?
PS: Ну и да, ребята, как всегда, молодцы — умудряются продавать одно и то же несколько раз. Вместо шин Michelin теперь везде будут шины Dunlop. А на управление это как-то повлияет, как думаете?
🔥5👀2😁1🏆1
Вы когда-нибудь задумывались о том, что AI‑assisted IDE — это не только инструменты вайб-кодинга, но и очень мощные тулы для работы с требованиями и для решения операционных задач? 🤔
Я долго смотрел на Cursor исключительно как на инструмент разработки. И даже когда кто-то говорил, что в нём можно собрать классного бизнес-ассистента, мой мозг сопротивлялся и говорил — ну это же вообще для другого!
А потом я наткнулся на GitHub spec-kit — и всё внезапно сложилось. Использовать такие IDE (или даже CLI-утилиты Gemini и Claude Code) для ведения документации оказалось удивительно удобным. Мне давно хотелось иметь интерфейс, в котором LLM задаёт уточняющие вопросы, а затем аккуратно интегрирует ответы в существующую базу знаний в репозитории. И это прям оно! ✨
Я разобрался, как устроен spec-kit, и — спойлер — там нет никакого rocket science 🚀. Просто набор шаблонов, промтов для разных этапов discovery и скриптов, которые запускаются в нужные моменты: что-то копируют, что-то обновляют, что-то коммитят.
Когда у нас появилась задача сопоставлять вакансии с матрицей компетенций — небольшая операционная задача, на которой было не страшно экспериментировать — я понял, что пора собрать свой маленький репозиторий и начать онбордить коллег в GitHub и AI‑IDE. Сейчас там всего два воркфлоу:
- проанализировать вакансию по URL;
- предложить обновления для матрицы компетенций.
Даже этого уже хватает, чтобы экономить массу времени:
- Не нужно вручную копировать промты, матрицы и тексты вакансий — просто запускаешь команду с адресом вакансии.
- Не нужно думать, куда сохранять результаты — воркфлоу делает это сам.
- Не нужно бояться сломать что-то коллегам — всё работает локально, а Git всегда позволит откатиться. 🙌
Да, продактам придётся освоить пару новых инструментов. Ладно IDE, с ней всё просто, а вот Git… коммиты, ветки, пулл-пуш, вот это всё — удовольствие ниже среднего, особенно на старте 😅. Но для регулярных задач этот подход настолько эффективен, что окупается мгновенно. А сколько у продактов нерегулярных задач? Вот, да. Так что берите пару повторяющихся сценариев и прям садитесь собирать под них воркфлоу!
А главное, сейчас идеальное время попробовать. Если пока не понимаете, зачем платить за Cursor, ставьте Antigravity от Google. Он пока бесплатный, а Gemini 3 Pro, который там под капотом по умолчанию, рвёт большинство других LLM во многих задачах. 🔥
Есть желание, но не понимаете как начать? Пишите вопросы в комментах!
Я долго смотрел на Cursor исключительно как на инструмент разработки. И даже когда кто-то говорил, что в нём можно собрать классного бизнес-ассистента, мой мозг сопротивлялся и говорил — ну это же вообще для другого!
А потом я наткнулся на GitHub spec-kit — и всё внезапно сложилось. Использовать такие IDE (или даже CLI-утилиты Gemini и Claude Code) для ведения документации оказалось удивительно удобным. Мне давно хотелось иметь интерфейс, в котором LLM задаёт уточняющие вопросы, а затем аккуратно интегрирует ответы в существующую базу знаний в репозитории. И это прям оно! ✨
Я разобрался, как устроен spec-kit, и — спойлер — там нет никакого rocket science 🚀. Просто набор шаблонов, промтов для разных этапов discovery и скриптов, которые запускаются в нужные моменты: что-то копируют, что-то обновляют, что-то коммитят.
Когда у нас появилась задача сопоставлять вакансии с матрицей компетенций — небольшая операционная задача, на которой было не страшно экспериментировать — я понял, что пора собрать свой маленький репозиторий и начать онбордить коллег в GitHub и AI‑IDE. Сейчас там всего два воркфлоу:
- проанализировать вакансию по URL;
- предложить обновления для матрицы компетенций.
Даже этого уже хватает, чтобы экономить массу времени:
- Не нужно вручную копировать промты, матрицы и тексты вакансий — просто запускаешь команду с адресом вакансии.
- Не нужно думать, куда сохранять результаты — воркфлоу делает это сам.
- Не нужно бояться сломать что-то коллегам — всё работает локально, а Git всегда позволит откатиться. 🙌
Да, продактам придётся освоить пару новых инструментов. Ладно IDE, с ней всё просто, а вот Git… коммиты, ветки, пулл-пуш, вот это всё — удовольствие ниже среднего, особенно на старте 😅. Но для регулярных задач этот подход настолько эффективен, что окупается мгновенно. А сколько у продактов нерегулярных задач? Вот, да. Так что берите пару повторяющихся сценариев и прям садитесь собирать под них воркфлоу!
А главное, сейчас идеальное время попробовать. Если пока не понимаете, зачем платить за Cursor, ставьте Antigravity от Google. Он пока бесплатный, а Gemini 3 Pro, который там под капотом по умолчанию, рвёт большинство других LLM во многих задачах. 🔥
Есть желание, но не понимаете как начать? Пишите вопросы в комментах!
🔥5❤3👨💻2👀1
Если развивать дальше мысль о том, что можно управлять требованиями непосредственно в репозитории проекта, то слово "монорепозиторий" начинает играть новыми красками.
И на первый взгляд всё выглядит прям прикольно:
- продакт написал требования, сделал Pull-Request;
- LLM'ка его обработала, проверила консистентность с другими требованиями и текущей реализацией, предложила варианты, как именно это запилить;
- я уточнил план реализации и запустил агентов его имплементить.
🤖 На практике первый же вопрос, который вводит меня в лёгкий ступор: а какой флоу выбрать в этом случае для работы с гитом?
Второй вопрос связан с первым, но ещё более практический: а где гонять и как управлять теми агентами, которые должны обрабатывать пулл-реквесты?
Пока у меня в голове есть два варианта:
🔧 Костыльный:
- каждый член команды работает в своей ветке;
- не реже, чем раз в неделю, коммитит изменения в GitHub;
- я (ну не прям ручками, а, например, локальным курсором и скриптами) раз в неделю собираю всё в Pull-Request в основную ветку и на нём уже гоняю агентов.
⚙️ Системный:
- объяснить команде концепции веток, push/pull, ревью и CI/CD;
- настроить автоматизацию в GitHub.
С технической точки зрения мне второй путь ближе. С практической — выглядит как два отдельных больших проекта (обучение коллег и реализация всей этой системы) вместо того, чтобы заниматься непосредственно развитием продукта.
Собственно, у меня к вам два вопроса:
1. Какой бы путь выбрали вы? Или, если уже выбрали, — поделитесь с чем столкнулись
2. Как вы решаете, сколько времени тратить на автоматизацию и настройку процессов, а сколько — на текущие задачи? ⚖️
И на первый взгляд всё выглядит прям прикольно:
- продакт написал требования, сделал Pull-Request;
- LLM'ка его обработала, проверила консистентность с другими требованиями и текущей реализацией, предложила варианты, как именно это запилить;
- я уточнил план реализации и запустил агентов его имплементить.
🤖 На практике первый же вопрос, который вводит меня в лёгкий ступор: а какой флоу выбрать в этом случае для работы с гитом?
Второй вопрос связан с первым, но ещё более практический: а где гонять и как управлять теми агентами, которые должны обрабатывать пулл-реквесты?
Пока у меня в голове есть два варианта:
🔧 Костыльный:
- каждый член команды работает в своей ветке;
- не реже, чем раз в неделю, коммитит изменения в GitHub;
- я (ну не прям ручками, а, например, локальным курсором и скриптами) раз в неделю собираю всё в Pull-Request в основную ветку и на нём уже гоняю агентов.
⚙️ Системный:
- объяснить команде концепции веток, push/pull, ревью и CI/CD;
- настроить автоматизацию в GitHub.
С технической точки зрения мне второй путь ближе. С практической — выглядит как два отдельных больших проекта (обучение коллег и реализация всей этой системы) вместо того, чтобы заниматься непосредственно развитием продукта.
Собственно, у меня к вам два вопроса:
1. Какой бы путь выбрали вы? Или, если уже выбрали, — поделитесь с чем столкнулись
2. Как вы решаете, сколько времени тратить на автоматизацию и настройку процессов, а сколько — на текущие задачи? ⚖️
👨💻4⚡3👾2❤1