2135
Канал от Python-разработчиков: — востребованные инструменты — system design — softskills — лучшие практики разработки — подготовка к собеседованиям Увеличим твою ценность на рынке IT Для связи @sa_bul
Я в целом скептически отношусь к курсам. Но так вышло, что как-то время от времени присматривался к курсам Стратоплана – и тут ребята сами предложили пройти у них обучение на курсе CTO.
Сначала подумал: столько в меня не влезет. А потом решил – почему бы и нет. Впихнуть невпихуемое – это мое:)
Хочу структурировать имеющиеся знания, проверить их актуальность и пообщаться с людьми со схожими запросами. Такой осознанный нетворкинг.
Поступление состоит из двух этапов.
Первый – кейс-интервью и эссе о себе. Кейсы я люблю. Это вообще популярный формат собесов на руководящие позиции – и, на мой взгляд, хороший способ понять, как человек думает.
Правда, решать кейсы в вакууме мне сложно. Сложно вжиться в абстрактную ситуацию с безликими героями. И тут для себя выработал лайфхак: отбросить мишуру и перенести суть проблемы на свой проект. Вместо безликих героев назначить своих коллег – и кейс сразу играет новыми красками. Начинают приходить хорошие идеи и решения.
Второй этап – что-то вроде собеседования. Но по сути это просто обсуждение твоего опыта, чтобы подобрать группу, с которой будешь плотно работать в процессе.
В итоге я попал на курс, любопытно, что из этого получится. Буду делиться полезными инсайтами.
Каникулы ещё не закончились – самое время спокойно почитать что-нибудь полезное.
Собрал подборку лучших постов за прошедший год – если пропустили или хотите вернуться к избранному:
– Зачем нужен шаблонный сервис и пример такого сервиса на FastAPI
– Чтобы провести встречу продуктивно, нужно постараться. Мы написали, что сами применяем на практике
– Видео про роли в крупном проекте – аналитики, разработчики, тестировщики и как всё это живёт вместе
– Набор заметок о том, зачем нужны архитектурные схемы, как их составлять и где проходят зоны ответственности
– Пост-стенание на тему код-ревью
– Революционный метод организации рабочих чатов
– Сайт с сериалами на разных языках и бот для изучения иностранного языка методом карточек
– Мой опыт работы с ai-агентами
– Приём, который помогает быстрее принимать решения в команде
– Как не забивать на написание постмитов
– Статья о том, как написать своего первого ai-агента
– Советы и антипаттерны при работе с Postgres
– Очень крутой курс по System Design, который искренне рекомендую
#devfm #backup
Зачем вы проводите код-ревью?
Большая часть команд, с которыми я работал, проводят код-ревью. Код-ревью – как священная корова: “А код поревьюили?”, “Без ревью не пушим” и всякое такое.
И каждый PR дисциплинированно пропускают через код-ревью: назначаются ревьюеры, они что-то пишут, код как-то правится...
Я искренне при любой удобной возможности интересуюсь у лидов или обычных работяг, зачем они его проводят.
Ответы бывают разные.
Мы хотим поддерживать качество кода, соблюдать единый стиль.
Что ж, похвально. Только у меня сразу возникает вопрос: а что вы считаете качественным кодом, что считаете единым стилем? А у вас настроены какие-то автоматизации? Ответы бывают разными, но по моему опыту редко есть уверенные ответы на все из них. А без этого код-ревью очень быстро превращается в вкусовщину и в обсуждение того, что вообще-то должна делать машина – линтеры, форматеры, базовые проверки.
Ревьюеры могут найти баг или проблему.
Вот с этого я искренне всегда недоумеваю. У меня сразу возникает вопрос: а кто у вас пишет код, если ревьюеры, не находясь в глубоком контексте задачи, могут заметить баг? Если баги регулярно ловятся на код-ревью, значит вы используете самый дорогой, самый медленный и самый ненадёжный механизм контроля качества. Ревью не воспроизводимо, не масштабируется и слишком сильно зависит от человеческого фактора.
Код-ревью нам нужно для шаринга знаний – такой ответ дают самые прогрессивные. Честно говоря, какое-то время это был мой любимый аргумент, и я очень им гордился. Но если задуматься: для шаринга знаний предполагается, что разработчик, у которого куча своих задач и контекстов, переключится на чужую задачу, впитает всё, что там написано, разберётся и получит ценные знания. Вопрос – сколько же времени нужно для этого? Как говорят классики: «сомнительно, но окэээээй». Если услышите такой аргумент, спросите у разработчиков, сколько времени они тратят на ревью, и подумайте, можно ли за это время действительно перенять знания. Ответы, которые получал я, говорят: скорее нет, нельзя.
Моё мнение – код-ревью создаёт иллюзию шаринга знаний, но по факту распространяет только очень поверхностный контекст. Если вы реально хотите шарить знания, есть куда более прямые и честные инструменты – дизайн-доки, обсуждения решений до реализации, грумминги задач.
И это я ещё не затронул другие проблемы и крайности: когда в PR появляется миллион комментариев, когда какой-то очень умный разработчик упирается рогом и говорит, что такой PR "только через мой труп", когда PR-ы висят днями, копят строчки, а потом полдня тратится на разруливание конфликтов. В общем – красота.
Так зачем это всё?
Код-ревью – полезная практика
Да, я всё ещё считаю код-ревью полезной практикой. Но чтобы она работала, над этим нужно много работать. Хорошее код-ревью – это работа над инженерной культурой.
Первое – составить гайд, хотя бы выровняться по одной линейке: как в команде проводится ревью, что мы ревьюим, на что обращаем внимание, а что считаем минором, тайминги проведения, выбор ревьюера, правила оформления PR-ов.
Второе – автоматизировать всё, что можно автоматизировать: линтеры, форматеры и вот это всё. Чтобы на ревью об этом даже не думали.
И даже когда есть гайд, тимлид должен чутко следить за его соблюдением и периодически подвергать сомнению его содержимое. У нас на практике в стайлгайдах в шапке была такая графа: актуализировать – "дата". Чтобы целенаправленно и критически посмотреть на эти правила.
Ревью действительно должно быть:
– когда вы залезли в чужой сервис или область знаний и сами просите эксперта посмотреть код
– когда вы мейнтейнер опенсорсного проекта
– когда вы менторите новичков или джунов и осознанно инвестируете время
Если вы прочитали и подумали: "Что это за бред?" – ну что же. Либо вы никогда критически не смотрели на этот процесс, либо вам действительно повезло с командой. Во втором случае искренне за вас рад – держитесь за неё. Так бывает далеко не у всех.
#devfm
СССектор приз на барабане!
Я частенько использую в коммуникации какие-то фразочки и прибаутки.
И к Новому году у нас конкурс: расскажите, что забавного вы сами используете или слышите от коллег.
Автор самого залайканного комментария получит от меня подарок – любую книгу на ваш выбор до 5к. Итоги подведем 31 декабря.
Чтобы задать темп, начну со своих.
– “Этого ребёнка проще выкинуть, чем отмыть”.
Когда-то я так часто собирался что-то выкинуть, что получил на день рождения торт с этой фразой.
– “Когда есть молоток, всё начинает казаться гвоздями”
– "Сколько свинью не крась, олень не получится"
Готов послушать ваши любимые рабочие фразочки и приговорки! Приводите друзей, пусть они тоже поделятся 🙂
⚡️ DevFM
Пятничное развлекательное
Как-то я уже рассказывал о проблеме вагонетки.
А вообще у neal.fun много залипательных и медитативных интерактивностей:
– визуализация денежного потока, обязательно пролистайте до самого конца
– путешествие по маршруту, где направление выбирают голоса пользователей, классно, чтобы пару минут проветрить голову
– подъём на лифте в космос, идеально, позалипать
Присмотритесь к Zed
Недавно общались про агентов (других тем у меня сейчас на повестке не бывает), и разговор внезапно ушёл в сторону Zed. Я за этим редактором кода давно посматриваю: у ребят очень специфичный вижн – всё вокруг идеи совместной работы.
В их статье Zed is our office ребята подробно рассказывают, как используют редактор у себя внутри, превращая его в настоящий виртуальный офис. И вот там становится ясно, что их коллаборативность – это не про «парное программирование на коленочках». Масштаб совсем другой.
Если идея парного программирования меня не очень вдохновляет, то такой подход к внутренним рабочим процессам – прям зашёл. Я даже попробовал провести созвон в Zed, когда обсуждали ТЗ: оказалось удобно, ничего шарить не нужно – все работают в одном документе.
Но смотреть на Zed стоит не только ради совместной работы. Он сам по себе очень приятный в использовании – свежий взгляд на IDE. Плюс ребята активно развивают AI-фичи и уже встроили Claude Code и других агентов.
Пятничное развлекательное
Наткнулся на очень забавный сайт: разные модели генерируют аналоговые часы.
Каждую минуту в модель улетает такой промпт:
Create HTML/CSS of an analog clock showing ${time}. Include numbers (or numerals) if you wish, and have a CSS animated second hand. Make it responsive and use a white background. Return ONLY the HTML/CSS code with no markdown formatting.
You Should Write An Agent
Недавно проводил опрос: по поводу использования агентов и оказалось, что многие используют.
Нашёл отличную статью – в ней автор предлагает самостоятельно разобраться, как базово устроены агенты под капотом, и попробовать реализовать своего.
В первой части – пошагово и с кодом объясняется, как работает агентский цикл: мы храним историю контекста, передаём её языковой модели и получаем ответы.
Дальше – интереснее: как подключать tools к агенту. Автор даёт агенту возможность выполнять команду ping. LLM сама инициирует вызов нужного инструмента. Получается очень прикольно: ты не описывал логики, не писал условий – модель сама решила, какие адреса пинговать, как интерпретировать результаты и как сформировать ответ.
В конце автор затрагивает важный вопрос контекста. Он показывает, что вся магия мультиагентности – это просто несколько массивов контекста и чуть-чуть управляющего кода.
В общем, рекомендую посмотреть и поэкспериментировать самостоятельно.
#ai
Еще один способ организовать рабочие чатики
Я пробовал организовывать рабочие чатики самыми разными способами: иногда просто в отдельную папочку, иногда – в папки по проектам.
Но у такой логичной организации есть проблемы:
– Ты не можешь сходу понять, какие чатики требуют внимания
– Имея большое количество чатов в папке, иногда невольно открываешь посмотреть то, что тебе сейчас вовсе не нужно
И некоторое время назад я придумал (вряд ли я, но в моем мире – именно я), как иначе организовать рабочие чатики – по срочности.
Сделал 4 папки:
🔹Now – то, на что мне нужно реагировать незамедлительно. Таких чатов всего 1–2, но стремиться нужно к нулю
🔹Hourly – то, на что нужно посмотреть в течение часа
🔹Daily – пробежаться раз в день, узнать, что происходило
🔹Later – оно же «никогда», оно же «когда-нибудь». Это чаты, где просто нужно присутствовать :)
В результате стало гораздо легче ориентироваться и не отвлекаться на лишний шум.
#devfm
Прокачать навыки System Design
Периодически коллеги или друзья спрашивают о хороших материалах для подготовки к интервью по System Design или в целом о том, как подтянуть свои навыки по System Design.
И уже достаточно давно я рекомендую небольшой курс (просьба не пугаться слова «курс») по System Design.
– если готовитесь к интервью, вы получите базу о том, как такие интервью проводятся, что важно для интервьюера, и достаточно оперативно получите фундаментальные знания, чтобы проходить такие интервью
– если хотите подтянуть навыки проектирования – этот курс даёт структурированную базу, и вы будете понимать, куда копать дальше, чтобы расширить знания
Начать рекомендую с видео от автора курса на YouTube.
Если никогда не проходили интервью по System Design, обязательно посмотрите мок-интервью от коллег из Тинька. Отличный разбор того, как проходит интервью, как правильно строить ответ, какие вопросы задавать и как углубляться в темы.
#systemdesign
Попробуйте Context7
Когда используешь AI-агентов в разработке, часто сталкиваешься с тем, что они путаются в документации разных библиотек – придумывают функции, которых не существует, или помнят API из устаревших версий.
Для решения этой проблемы есть интересный MCP-сервер – Context7. Этот MCP позволит вашему агенту иметь доступ к актуальной документации огромного количества библиотек. У ребят в ридми подробно описано, как подключить Context7 к вашему любимому агенту.
Расскажите, какие MCPшки у вас в топе?
The Impact of Generative AI in Software Development (DORA)
Продолжаем обзор отчета DORA.
В третьей и четвёртой главах DORA обсуждают доверие к AI и то, как перевести точечные успехи в массовое внедрение.
Сформулируйте понятные правила использования AI
Чётко опишите, что можно и что нельзя: типы задач, работа с данными, допустимые инструменты, требования к проверке и лицензиям. Такая политика снимает страхи, выводит эксперименты из «подполья» и делает применение AI управляемым, а не стихийным.
Ускорьте обратную связь: быстрые ревью и тесты как база доверия
AI – джун на коленках: помогает, но может и прод грохнуть. Таким образом, если проблемы от использования AI будут всплывать только на проде, доверия к инструменту не будет. Но если они ловятся сразу – тестами, линтерами, код-ревью – команда чувствует себя в безопасности. Чем быстрее обратная связь, тем смелее можно использовать AI.
Сделайте обучение с AI частью работы (песочницы, типовые кейсы, наставники)
Опыт рождает доверие. Дайте разработчикам время и формат для практики: внутренние песочницы/репозитории без риска для продакшена, типовые задачи «как мы решаем X с AI», парная работа с наставником, короткие демо‑сессии. Закрепляйте удачные кейсы в мини‑гайдах и общих коллекциях промптов. Чем привычнее инструмент, тем меньше сопротивления и тем выше отдача.
Поощряйте использование, но не навязывайте
Призывайте пробовать AI, делитесь результатами, но оставляйте право выбора. Там, где инструмент убивает удовольствие от любимых задач или не даёт прироста, разрешите работать вручную. Такая гибкость поддерживает мотивацию и снижает сопротивление.
Сформируйте видение новой роли разработчика
Далёкий по горизонту, но важный пункт: по мере внедрения AI часть задач заберут инструменты, и роль разработчика будет смещаться. Задайте траекторию трансформации профессии: что автоматизируем, какие навыки наращиваем (проектирование решений, оркестрация и верификация моделей, данные/безопасность), как это отразится в грейдах, обучении и оценке по end-to-end результатам.
В пятой заключительной главе авторы переходят к самому важному – внедрить внедрили, а зачем мы это делали? Мало просто внедрять AI – нужно ещё понимать, насколько хорошо мы это делаем и какие результаты получаем. Для этого нужны метрики.
Авторы предлагают смотреть на несколько уровней
– На уровне инструментов – кто и как ими реально пользуется
– На уровне команды – скорость ревью, качество документации, ощущение продуктивности
– На уровне сервиса – сложность кода и стабильность релизов
– На уровне компании – бизнес-результаты и довольство пользователей
Смысл в том, чтобы связывать использование AI не только с цифрами вроде "сколько подсказок приняли", а с настоящей ценностью: быстрее ли мы поставляем изменения, лучше ли стал код, комфортнее ли работать команде.
А для интересующихся, есть отличное видео от Александра Поломодова, где он с собеседником разбирает отчет за 24 год, в котором DORA делится методами, как все эти циферки вообще получаются.
#ai
Опыт применения LLM в разработке
Недавно Сальваторе Санфилиппо, создатель Redis, поделился своим опытом использования LLMок в реальной разработке. Он выделил несколько областей, где AI уже сегодня становится незаменимым помощником:
🔹 Поиск багов и ревью кода. На примере реализации Vector Sets для Redis LLM обнаружили множество ошибок ещё до того, как код попал в продакшен. Хотя мой опыт, и опыт разработчиков вокруг меня говорит об обратном, что LLMки так себе справляются с задачами поиска багов
🔹 Тестирование гипотез. Наколеночные прототипы позволяют быстро проверять гипотезы
🔹 Парное проектирование. Комбинация вашего опыта с энциклопедическими знаниями LLM даёт хороший результат: вы вносите контекст и интуицию, AI – широкий набор паттернов и решений
🔹 Изучение новых технологий. В незнакомой области LLM способны быстро ввести в курс дела и предложить первые рабочие заготовки
🔹 Ускорение написания кода. AI пишет код под вашим чутким руководством:)
Для того, чтобы эти сценарии были действительно рабочими необходимо следовать некоторым правилам:
🔹 В большинстве случаев отказываться от вайб-кодинга. LLMки могут самостоятельно сделать что-то небольшое, но в других случаях получаются портянки неподдерживаемого кода
🔹 Давать максимальный контекст – предоставляйте исходники, документацию, требования и примеры плохих и хороших решений
🔹 Использовать передовые модели для кодинга, автор предлагает Gemini 2.5 PRO и Claude Opus 4
🔹 Послдений совет, который дает автор – не использовать агентов. Он обосновывает это необходимостью контролировать весь процесс. Но по своему опыту могу сказать, что агенты уже достигли того уровня, когда их разные фишечки действительно делают жизнь легче и избавляют от многих лишних действий
#ai
Пятничное развлекательное
Недавно вышла забавная заметка. Ребята из Soundslice делают онлайн-сканер нот: загружаешь снимок партитуры, система распознаёт ноты и тут же проигрывает музыку.
В какой-то момент они обратили внимание на ошибки в логах. Вместо обычных снимков нот туда заливали ASCII-табулатуру из ChatGPT. После небольшого расследования выяснилось, что модель советовала пользователям загружать табы в Soundslice для воспроизведения. А самое забавное – то, что такой функции у ребят никогда не было: ChatGPT её просто выдумал.
Команда встала перед дилеммой: разрабатывать ли эту фичу или просто оповещать пользователей о том, что такая функция не поддерживается. В итоге фичу реализовали.
Получилась забавная и немного странная история: фича родилась не из потребностей пользователей, а из-за галлюцинации ChatGPT.
#ai
Советы, как сделать полезный дашборд
На практике часто видел, что в команде есть какие-то дашборды, но кто ими пользуется, что на них можно увидеть – непонятно.
В статье автор делится советами, как превратить набор красивых графиков в полноценный рабочий инструмент команды.
Дашборд должен отвечать на вопросы
Представьте, что человек открывает дашборд, чтобы получить конкретный ответ: Насколько выросло CPU-потребление у сервиса X? Сколько заявок мы обрабатываем за сутки? Какая температура в серверной прямо сейчас? Если панель не помогает ответить – что-то не так.
Относитесь к дашборду, как к продукту
– ЦА. Дежурный SRE, разработчик, топ-менеджер?
– CJM. Куда пользователь пойдёт после просмотра? Лог, alert, соседний дашборд?
– Условия использования. Инцидент на ноутбуке, большой монитор в опен-спейсе, недельный отчёт?
– Что улучшилось после изменений. Например, добавил спарклайн -> дежурный быстрее ловит аномалию
Проверяйте на целевой аудитории
Задайте дежурному реальный вопрос («Почему вырос latency?»). Посмотрите, как он ищет ответ. Соберите обратную связь, доработайте.
Показывать дашборд случайным коллегам бесполезно – у них другие задачи.
Правила восприятия
– Читаем сверху вниз, слева направо – важное размещайте в левом верхнем углу.
– Большая панель = важная метрика. Мелкие блоки – второстепенное.
– Цвет привлекает внимание: используйте принцип светофора (красный – критично, желтый – предупреждение, зелёный – норма, синий – справочная инфа, серый – неактивно / неизвестно)
Не перегружайте
– Панель должна умещаться на экране без прокрутки
– Не больше 30 линий на графике. В остальных случаях – top-10 и детальный дашборд по клику
– Не больше 3 типа визуализации на странице – иначе когнитивная нагрузка растёт
– Толщина линий ≥ 2 px – их будет видно даже на созвоне
– Null-значения не соединяйте – разрывы важны для диагностики
– Стекирование используйте аккуратно и делать максимально непрозрачную заливку
Документируйте панели
– Заполняйте Description (поддерживает Markdown)
– Выводите в названии переменные Grafana – сразу видно контекст
– Добавляйте ссылки в настройки панели на инструкции и релевантные дашборды
– Добавляйте легенду и следите за ее читабельностью
Оптимизируйте данные
Старайтесь отфильтровать максимальное количество данных на стороне источника, чтобы не перегружать клиент
Осторожно с готовыми дашбордами из интернета
Красиво – не значит полезно. Пройдитесь по каждой панели, поймите логику, только потом ставьте в свой контур. Ошибка всплывет в самый неудобный момент – во время аварии.
Еще один способ работать с ai-агентами
Завтра начинаем работать, но никогда не поздно начать то, что давно откладывал.
Сейчас AI-агенты, действительно, умеют многое. И если с большими проектами всё ещё бывает непросто, то для MVP или пет-проекта – это супер классный инструмент.
Общее понимание уже сформировалось: чтобы с агентом получилось что-то толковое, нужно сначала составить план, проверить его, зафиксировать – и только потом просить агента работать по этому плану. Для не очень больших задач это работает. Но все равно несет серьезную ментальную нагрузку – все учесть, ничего не забыть.
Когда стартуешь что-то с нуля или добавляешь большую фичу в существующий проект – хочется чего-то более структурированного. И тут появляются инструменты для автоматизации всего флоу.
Рекомендую попробовать spec-kit.
Суть в том, что он расширяет и формализует классический пайплайн планирования. Общий флоу выглядит так:
– описываешь свои хотелки: что нужно и зачем, без привязки к стеку
– дальше – технический план: архитектура, стек, решения, все это дело ревьюишь, уточняешь
– затем декомпозиция на задачи с учётом зависимостей
– в конце – реализация по этим задачам и разумеется ревью этого добра
Главный плюс такого подхода – он сам подталкивает к определённому флоу, чтобы ничего не забыть. Явно подсказывает следующий шаг. Если прервался – можно продолжить с того же места. Поддерживается разными агентами: Claude Code, Copilot, Cursor и другими.
Мне нравится пробовать на пет-проектах то, что давно откладывал. Делегировать то, в чём скучно разбираться самому.
Например, чтобы подбить статистику по популярным постам, я сделал небольшой сервис tganalytics – собирает информацию из любого публичного канала в Telegram и позволяет сортировать посты по популярности.
Из полезного:
– когда подписываешься на новый канал – удобно посмотреть самые популярные посты
– бэкап собственного канала
– база для RAG и собственной базы знаний
– выгрузка контента – я так делаю для кулинарных каналов
Если интересно – заходите, попробуйте. А если что-то не полетит – приходите, поправлю.
Среди похожих инструментов для работы с агентами стоит посмотреть на SuperClaude, но мне он показался переусложненным.
#ai
Книга "Цель"
Недавно прочитал довольно известную книгу Цель Элияху Голдратта.
Это попытка донести управленческие идеи через художественное повествование – и именно этим книга мне понравилась. Она читается легко, местами даже захватывающе.
Автор ведёт читателя через жизнь реального завода: срывы сроков, простаивающее оборудование, локальные оптимизации, которые почему-то делают только хуже. По ходу сюжета он подталкивает читателя самому подумать над решениями, а не просто принять готовые решения.
Но ключевая смысловая нагрузка книги – не в управлении заводом как таковым.
Голдратт на конкретных примерах показывает, что любая система ограничена несколькими узкими местами – и именно они определяют результат. Пока ты не нашёл это ограничение, любые улучшения в среднем по больнице бесполезны. А когда находишь – внезапно выясняется, что значительная часть привычных управленческих практик (максимальная загрузка ресурсов, KPI на каждое подразделение, фокус на локальную эффективность) работает против общей цели.
Читая книгу, я поймал себя на мысли, что идеи из неё перекликаются с подходами канбана.
И напомню: у нас скоро заканчивается конкурс на самую интересную цитату из практики.
Приходите, голосуйте, приносите свои. Как говорится, от нас пуля вылетела 🙂
Хотел написать небольшой пост – а в итоге получилась целая статья.
Недавно у меня был классный опыт парного программирования с товарищем: он пишет код, а я смотрю за его флоу и предлагаю оптимизации.
Собрал в статье практические советы, которые помогают при работе с агентами:
– как организовать удобный флоу
– почему не стоит просить «сделать всё под ключ» и как стоит
– как формировать рабочие rules
– зачем переключать модели и когда это спасает
– почему экспертиза разработчика всё ещё критично важна
Заходите почитать, если понравилась ставьте лайкосики.
#devfm
How AI is transforming work at Anthropic
Ребята из Anthropic опубликовали исследование – как меняется работа инженеров внутри компании, которая сама делает Claude. И кажется, они прошлись по всем вопросам, которые сегодня беспокоят индустрию.
Вот, что меня заинтересовало.
Решаемые задачи и продуктивность
Это важный блок – особенно чтобы не выращивать ложные ожидания, будто агент будет выполнять всё под ключ.
– Инженеры используют Claude примерно в половине своей работы и оценивают прирост продуктивности до 50%
– Полностью отдать ему получается только до 20% задач – всё остальное выполняется с плотным контролем
– Треть работ, сделанных с Claude, просто не существовало бы без ИИ: nice-to-have тулзы, дополнительные дашборды
И вот здесь у меня возникает вопросик: если часть задач создаётся только потому, что теперь их дешево делать, не ломает ли это приоритизацию? Мы ускоряемся – но ускоряемся ли в нужную сторону?
Про важность делегирования
Когда начинаете работать с агентами, важно уметь давать ему шанс:
– начинать с маленьких и чётко проверяемых задач
– смотреть, с чем он справляется хорошо
– постепенно развивать навык понимать, какие задачи он делает хорошо, а какие лучше оставить себе
Антропик отдельно отмечают: многие негативные кейсы появляются не из-за тупости модели, а из-за неправильного выбора задачи.
На самом деле категорически согласен с этим пунктом.
Все становятся чуть более fullstack-чнее
Авторы пишут, что инженеры стали легче заходить в смежные зоны:
бэкендеры делают фронт, ресёрчеры собирают визуализации, секьюрити разбирают незнакомый код без лишней боли.
Порог входа в новые области сильно падает – можно набросать прототип, показать, отрефакторить и прогнать через Claude.
И важный эффект – меньше пинг-понга между командами: теперь можно не ждать коллег практически по каждому мелкому вопросу.
Что с навыками
– Инженеры отмечают страх потерять экспертизу: когда агент быстро прыгает к решению, ты меньше копаешься в доках и чужом коде – экспертиза формируется медленнее
– Парадокс: чтобы проверять агента, нужны именно те навыки, которые могут атрофироваться
– И вот здесь, как мне кажется, кроется большая проблема: непонятно, как теперь вырасти из джуна. У новичков исчезла часть естественных первых шагов, а спрос на настоящих сеньоров будет только расти. (Но не тех, кто в 25 считают себя сеньорами – извинити, вот такой я дед)
Коммуникации в командах
– 80–90% вопросов, которые раньше шли коллегам, теперь уходят сначала к Claude
– Это влияет на менторство: джуны меньше спрашивают, сеньоры реже передают экспертизу
В общем, очень рекомендую статью к прочтению.
И важно понимать: ребята прямо говорят, что это не истина в последней инстанции. Многое ещё требует прояснения. Да и в целом профессия меняется – и во что это выльется, пока не знает никто.
#ai
Claude учится экономить контекст
Не пришлось долго ждать. Сначала Anthropic рассказали о проблемах – огромный контекст на старте из-за пачки MCP-тулов, частая путаница в выборе инструмента, ошибки в параметрах – а теперь решения уже доступны в бета-версии Claude Development Platform. Подробности – в статье.
Tool Search Tool
Звучит очень многообещающе.
Теперь нет нужды загружать десятки тысяч токенов инструментов в начале сессии. Модель получает только маленький поисковый тул и подгружает нужные MCP-инструменты по запросу – GitHub, Slack, Jira, Drive, что угодно.
Экономия контекста: Anthropic приводят пример, где удалось сократить объём примерно с 70K токенов до 8–9K. И главное – рост точности: модель перестаёт путаться между похожими командами и работает только с тем, что действительно нужно задаче.
Programmatic Tool Calling
Раньше каждое обращение к тулу означало: свалка промежуточных данных в контексте.
Теперь Claude может небольшие скрипты, которые берут на себя вызовы mcp-тулов. Скрипты вызываются, модель получает только конечный результат.
Для длинных цепочек запросов, аналитики, фильтрации, параллельных операций – должно быть удобно: меньше токенов, меньше ошибок, меньше задержек.
Tool Use Examples
Используя JSON-схема декларирует, что можно передавать в параметрах, но не объясняет, как API ожидает это на практике.
Теперь можно приложить примеры корректного вызова инструмента – и Claude начинает следовать этим паттернам. По внутренней статистике Anthropic точность выросла с 72% до 90% для сложных API.
Каждый из этих тулов имеет трейдофы, но это важный шаг к полноценным рабочим агентам, которые управляют большими процессами и сложными наборами инструментов.
Ух, вчера вспомнил давно забытую боль.
Некоторое время назад мы пилили b2b-продукт и интегрировались по HTTP с большим сервисом большой компании.
И вот представьте моё удивление, когда приходит разработчик и говорит, что мы получаем код 200, а в body – что-то типа «произошла ошибка». Мы тогда повозмущались и смирились, потому что альтернатив всё равно не было.
И всё бы ничего, если бы вчера я не рассказал эту историю своему хорошему товарищу. А он, представьте себе, вообще не удивился. Сказал: «Да, всё так и есть. Видел это не раз. И во вполне приличных конторах – тоже».
И вот у меня вопрос – ну как так то, доколе?! Может, у этого есть какая-то логика?
Вы такое встречали?
#devfm
Шаблонный сервис
Я всячески люблю, когда разработка идёт предсказуемо – и многое для этого делаю.
Давно хотел написать пост о важности шаблонного сервиса, но не было хорошего примера под рукой. И тут мой коллега выложил наш шаблонный сервис на FastAPI, который мы долгое время использовали и развивали.
Так зачем же нужен шаблонный сервис?
Легко ориентироваться в других сервисах. Иногда нужно залезть в сервис коллег, или поддерживаешь несколько сервисов. Никаких проблем – структура везде одинаковая, всё знакомо, не нужно тратить время на раскопки.
Быстрый старт. Стартуете новый сервис? Полчаса – и он готов. Никаких лишних приседаний.
Единые практики. Шаблон определяет, не только структуру, но и то, как мы, например, делаем ретраи, какие у нас зависимости. как устроен circuit breaker, обработка ошибок и т.д.
Лучшие практики – в одном месте. Если появляется что-то классное, мы добавляем это в шаблон и новые сервисы сразу это наследуют.
Обсервабилити, логирование, работа с секретами – готово из коробки. И меньше шансов, что кто-то забьёт на логирование до лучших времён»:)
Онбординг на кошечках. Новый человек сначала изучает шаблонный сервис, понимает подходы, а потом уже ныряет в боевые системы.
Просто экспериментировать. Создал веточку от шаблона – и прикручиваешь свою новую махарайку, не тратя время на базовую структуру.
Унификация линтинга. Конфиги линтеров лежат в шаблоне. Ничего настраивать не нужно, а код-ревью идёт быстрее – обо всём уже однажды договорились и зафиксировали.
Базовый CI/CD. Для шаблонного сервиса существует шаблонный ci/cd – и это очень удобно.
Мы активно использовали шаблонный сервис в микросервисной архитектуре, но и для монолитных решений он тоже отлично зашёл – стартовали с ним несколько проектов.
Понимаю, что это нужно не всем. Но если вы занимаетесь продуктовой разработкой и играете вдолгую — на мой взгляд, это мастхев.
В общем – заходите, смотрите, ставьте звездочки. И если с чем-то не согласны – пишите в комменты, автор обязательно ответит 🙂
#devfm #systemdesign
Новый взгляд на MCP
Сложно сейчас представить использование AI-агентов без MCP-серверов.
MCP позволяет агенту подключаться к различным внешним системам, чтобы запрашивать данные, выполнять операции и выстраивать сложные цепочки взаимодействий.
Но текущий способ использования MCP-серверов имеет существенные недостатки.
Ребята из Anthropic выпустили очень любопытную статью, где описывают проблемы текущего подхода и предлагают конкретное альтернативное решение.
Проблемы с MCP:
– Как правило, все MCP-тулы и их описания загружаются в контекст. Если у вас подключено несколько MCP-серверов, у каждого может быть с десяток-другой тулов. В итоге, ещё до того как агент начал работу, у вас съедена большая часть контекста модели. В результате модель работает сильно хуже.
– Когда агент вызывает какой-то MCP-тул (например, запрашивает транскрипт из Google Docs), результат (полный текст) возвращается в контекст. А если нужно передать его дальше – допустим, вставить в запись Confluence – этот же текст снова дублируется в запросе. В итоге в контекст дважды попадает большой артефакт, который на самом деле не нужен агенту повторно, и он переполняется.
– Многие обоснованно переживают, что модель получит лишние данные, которые ей знать не нужно – например, персональные данные пользователей.
Что предлагают делать:
Вместо того, чтобы вызывать инструменты напрямую в контексте, предлагается позволить агенту писать и исполнять код, который сам будет обращаться к MCP-инструментам.
Если подробнее:
1. Информацию о всех тулах MCP-серверов мы храним локально в проекте – каждый тул оформлен как отдельный модуль (например, TypeScript-функция).
2. Агент изучает доступные инструменты через обход файловой системы: сначала смотрит, какие MCP-серверы есть в ./servers/, потом открывает нужные файлы и считывает интерфейсы только тех тулов, которые релевантны текущей задаче. Это позволяет не грузить всё подряд в контекст, а подгружать выборочно – по необходимости.
3. После этого агент пишет код, в котором использует нужные инструменты, вызывая только то, что требуется для выполнения поставленной цели.
4. Сгенерированный агентом код исполняется в отдельной изолированной среде (песочнице). Модель при этом не участвует в каждом шаге исполнения – она получает только итоговый результат (например, через вывод в терминал).
Это категорически снижает нагрузку на контекст: вместо передачи в модель всех промежуточных данных (например, больших таблиц, длинных текстов), результат возвращается в уже отфильтрованном или агрегированном виде.
Дополнительно, используя такой подход, можно:
– фильтровать большие данные (например, из таблицы в 10 000 строк вернуть модели только 5 нужных)
– токенизировать чувствительные данные перед их передачей в модель (модель будет видеть [EMAIL_1], а не сам email)
– строить полноценную логику: циклы, условия, обработку ошибок – без постоянных вызовов модели после каждого шага
На первый взгляд такой подход требует дополнительных приседаний, но, мне кажется, в итоге он перевесит те проблемы, с которыми мы сталкиваемся сейчас при использовании MCP.
#ai
Выбирайте скучные технологии
Принес достаточно старую, но очень жизненную статью.
В ней автор говорит – выбирайте скучные технологии. И я, пожалуй, подпишусь под каждым словом.
Автор приводит классную метафору: у любой компании есть ограниченное число «жетонов на инновации». Хочешь на затащить Airflow? Потратил жетон. Захотел CockroachDB? Ещё жетон. Решил притянуть кастомную систему очередей, которую сам же и написал? Ну, удачи.
Главное преимущество скучных технологий в том, что индустрия уже хорошо понимает их поведение, ограничения – и, что самое важное, знает, где они ломаются.
И проблема не в новых технологиях как таковых. Проблема – в их цене: экспертиза команды, отладка, операционка, поддержка, миграции. Эта цена часто оказывается намного выше, чем кажется в момент выбора.
Когда с тимлидами обсуждаем внедрение новой технологии, мы стараемся смотреть шире, чем просто на технические характеристики. И всегда спрашиваю:
– А точно ли нам это нужно?
– А можем ли решить задачу на текущем стеке, хоть и не идеально?
И чаще всего оказывается – да, можем.
Важно понимать, что это не заскорузлость: давайте не будем использовать новое. Новые технологии нужны, но задача лида, не затащить новое, а выстроить процесс принятия решений. Сделать так, чтобы новинка добавлялась в стек обоснованно, с пониманием зачем, с оценкой последствий и, по возможности, с планом миграции или поддержки.
На эту тему у нас уже были посты:
– Как принимать архитектурные решения
– Для чего мы рисуем архитектурные схемы
Пятничное развлекательное
Я люблю посмотреть что-нибудь на английском. Для этого, разумеется, существует множество ресурсов, но мне особенно нравится Ororo. У ребят действительно неплохая база, а главное – можно не отходя от кассы выделить слово в субтитрах и тут же получить перевод. Еще есть удобная перемотка – не по времени, а по выражениям. То есть если не понял, что только что сказали, можно перемотать только фразу, а не условные 15 секунд, как на YouTube. Для меня это прям две киллер-фичи.
Помимо просмотра, я периодически учу новые слова и выражения. С моей точки зрения, лучший способ для этого – флеш-карточки. И для этого навайбкодил себе бота – @MemAnkiBot. Ну как навайбкодил – начал делать это еще в начале 2024 года, когда даже термина такого не было. В те далекие времена нужно было самому писать код, сейчас какие-то правки уже, конечно, сам не вношу.
Бот позволяет учить слова и выражения методом флеш-карт. Алгоритм подсовывает вам слова, которые знаете хуже. При добавлении слов есть функция автоматического получения перевода и примера – для изучения примеры всегда полезны.
Еще из удобного: встроенный переводчик. Можно перевести слово и тут же добавить его на изучение.
В общем, для кого актуально – заходите, пользуйтесь. А если что-то не работает – знаете, кого пинать:)
#fun
Как работать с ai-агентами
Сейчас, пожалуй, из каждого утюга слышим про вайб-кодинг и использование агентов в разработке. При этом есть достаточно серьезный скепсис: люди пробуют что-то, у них не получается, и их мнение подтверждается – агенты ничего не умеют.
Недавно прочитал интересную статью, где опытный инженер делится своим опытом использования AI-агентов и рассказывает, как у него получается добиваться результата.
Важно понимать, что не стоит ожидать сразу хорошего результата. AI-агенты – это инструмент, которым нужно уметь пользоваться, и он не решит все ваши проблемы за вас. Получить качественный результат – это процесс.
Методика автора: решение задачи в три захода
🔸 Первый заход: как-то формулируешь задачу, агент собирает информацию о проекте, пытается что-то сделать, но 95% получившегося – мусор.
🔸 Второй заход: ты уже начинаешь понимать, где агент споткнулся, где он делал фигню, и более четко формулируешь свои хотелки. В этот раз только половина кода – мусор.
🔸 Третий заход: еще больше конкретики, еще больше деталей. В результате должен получиться код, с которым можно работать. Именно в этот момент можно начинать полноценно ревьюить результат, просить точечно что-то поправить, переделать.
Контекст – ключ к успеху
Каждый ваш разговор с агентом начинается с чистого листа. Чтобы этого избежать, есть свои приемы:
🔹Rules – текстовые файлы с информацией о вашем проекте: архитектурные решения, основные паттерны, любые другие договоренности о правилах разработки
🔹MCP-серверы – очень важно, чтобы агент был интегрирован с вашей инфраструктурой: документация, система ведения тикетов, непродовая БД – со всем, что может дать больше контекста для решения задачи
От себя могу сказать, что при использовании агентов особенно важным становится написание тестов. Я и раньше их очень любил, а теперь в особенности.
Кстати, автор пользуется Claude Code – отличное решение от Anthropic, рекомендую попробовать.
The Impact of Generative AI in Software Development (DORA).
Недавно изучил отчёт (файл) DORA о влиянии AI на разработку. Он большой, поэтому разбиваю выводы на серию постов. Сегодня – первые две главы.
В первой главе авторы приводят цифры и несколько небанальных наблюдений.
Почти все уже в игре: 89% организаций ставят внедрение AI в приоритет, 76% инженеров используют его ежедневно.
Как DORA считает эффект. Они моделируют: если отдельный разработчик увеличивает своё использование AI на 25% (от текущего уровня), как меняются его метрики.
Что выросло: документация +7.5%, качество кода +3.4%, скорость code review +3.1%, скорость аппрува +1.3%, а сложность кода снижается на 1.8%.
А теперь к наблюдениям, которые меня зацепили.
Во‑первых, падает delivery. Throughput уменьшается на 1.5%, Stability – на 7.2%. Логика ожиданий была обратной: раз промежуточные шаги ускорились, значит и поставка должна ускориться. Авторы предполагают, что AI позволяет быстро генерировать большие порции кода, ченджлисты толстеют, и команда нарушает базовый принцип маленьких поставок.
Во‑вторых, просела valuable work. Доля времени, которую разработчики сами относят к valuable work, снижается примерно на 2.6%. При этом на рутинные задачи время почти не меняется, а ощущения flow и продуктивности растут. DORA называет это «вакуумной гипотезой»: AI ускоряет то, что мы считаем ценным, и освободившееся окно забивается тем, что AI пока автоматизирует хуже – митингами, согласованиями, организационным шумом.
Во второй главе авторы пытаются разобраться, что именно разработчики считают valuable work. В итоге получилось пять аспектов. Для каждого описано, как влияет AI и что стоит делать, чтобы влияние было положительным.
Утилитарная ценность – ощущение, что твой труд приносит реальную пользу.
AI обычно помогает: путь от идеи до импакта сокращается. Риск в том, что если ускоряется только написание кода, а не весь поток, импакт всё равно буксует. Делать: разрешать AI на всех этапах SDLC и удерживать маленькие, быстро проверяемые изменения.
Репутационная ценность – признание вклада.
AI увеличивает объём результата, но размывает авторство: «это я сделал или модель?». Чтобы перевести баланс в плюс, нужно явно признавать труд по работе с AI – формулировку промптов, проверку вывода, интеграцию – в грейдах и перфоманс‑ревью.
Экономическая ценность – «мне платят за результат».
Эффективность растёт, но вместе с ней поднимается и «новая норма», что рождает страх заменимости. Ответ – смещать оценку на outcomes (что доставлено пользователю), а не на количество строк или часов, и прозрачно объяснять, как AI учитывается в компенсации.
Внутренняя (intrinsic) ценность – важность самого ремесла.
AI обесценивает часть привычных навыков, но открывает новые. Это не минус, а новые вызовы. Нужны время и ресурсы на обучение, чтобы люди ощущали рост, а не эрозию профпригодности.
Гедонистическая ценность – удовольствие от процесса.
AI снимает рутину, что приятно, но может украсть любимые задачи, если автоматизировать всё подряд. Решение тут простое: оставьте право делать вручную то, что приносит удовольствие, и не навязывайте инструмент там, где он убивает интерес.
#ai
Насколько AI увеличивает продуктивность программистов
Недавно METR опубликовали исследование с интригующими выводами: авторы задаются вопросом, насколько AI‑асисты действительно ускоряют или замедляют работу опытных разработчиков.
Почему привычные метрики не годятся
– Большинство бенчмарков фокусируется на узко поставленных задачах с автоматической проверкой результатов, не требующих контекста больших кодовых баз
– Они не учитывают время на настройку подсказок, исправление неточностей и интеграцию AI‑сгенерированного кода в проект
– В них отсутствует фактор человеческой правки: в реальности мы тратим дополнительное время на доводку и ревью предложений ИИ
Как проходил эксперимент
16 опытных разработчиков из крупных open‑source‑репозиториев (более 22 000 звёзд и 1 млн строк кода) выбрали по 15–20 реальных задач — фиксы багов, новые фичи и рефакторинг. Всего получилось 246 заданий. Каждую задачу случайным образом разрешали выполнять либо с любыми AI‑инструментами, либо без них. Разработчики фиксировали время выполнения каждой задачи.
Ключевой вывод
И вот барабанная дробь: использование AI‑асистов замедляет разработчика на 19%. При этом участники до эксперимента прогнозировали ускорение на 24%, а после всё ещё считали, что AI их реально ускорили.
Размышления авторов
Ребята видимо сами удивились своим выводам, поэтому вторая часть статьи посвещена размышлениям о том, почему их выводы не совпадают с другими бенчмарками и ожиданиями пользователями:
– Ограниченный объём сэмплирования: в бенчмарках модели могут генерировать тысячи вариантов, здесь — лишь несколько
– Крутая кривая обучения: эффект от AI‑инструментов может проявляться после сотен часов практики, а в эксперименте у большинства участников было лишь несколько десятков часов опыта
– Высокие стандарты качества: Open‑source репозитории часто имеют строгие требования к тестам, документации и стилю, что требует дополнительной правки AI‑кода
От себя хочу добавить: AI – не золотая пуля, а набор специализированных инструментов: какие-то классы задач они выполняет хорошо, какие-то хуже. Чтобы получить реальную выгоду, нужно понимать особенность применения этих инструментов. Именно этот момент, на мой взгляд, упущен в исследовании.
Такую же картину я наблюдаю в реальной жизни: некоторые разработчики столкнувшись с тем, что AI не решил задачу под ключ, сразу отказываются от него.
#ai
Cursor изнутри
Недавно вышла немного рекламная, но легкая и интересная статья от The Pragmatic Engineer о том, как устроен Cursor узнутри.
В начале статьи просто любопытные цифры о Cursor. Дальше автор рассказывает нам о технологическом стеке. Из интересного:
- TypeScript – бизнес-логика, критические штуки на Rust
- Turbopuffer – основное KV-хранилище, держит зашифрованные файлы + Merkle-деревья для синка
- Pinecone – векторная БД для семантического поиска по коду
- Datadog, PagerDuty, Sentry, Amplitude для обзервабилити
- Linear – для таск трекинга (рекомендую попробовать для тех, кто не пробовал, интересное решение)
Cursor не хранит наш код на своих серверах. Когда вы отправляете запрос в Chat, происходит следующее:
1. Запрос уходит на сервер
2. Сервер решает, что это – вопрос о коде, и запускает векторный поиск по embedding'ам, которые заранее были созданы на сервере во время “индексации” проекта
3. По результатам векторного поиска сервер понимает, какие файлы могут быть релевантны и запрашивает эти конкретные файлы обратно у клиента
4. Клиент шлёт нужные части кода (зашифрованно) – только те, что реально понадобились
5. Сервер “собирает” полный контекст и запускает inference для ответа
6. Ответ возвращается в чат
Отдельно стоит рассказать, как Cursor узнаёт, какие файлы изменились, и переиндексирует только их. Для используются Merkle-деревья:
1. каждый файл разбивается на чанки, каждый чанк хешируется
2. хеши объединяются попарно и формируют узлы следующего уровня
3. в результате строится дерево, корневой хеш которого отражает состояние всего проекта – аналогичное дерево строится и на клиенте, и на сервере
Каждые ~3 минуты клиент сравнивает свой корневой хеш с серверным:
– если хеши совпадают – индекс остаётся прежним
– если отличаются – обход дерева точно выявляет изменённые чанки, и переиндексирует только их
#ai
Как метрики помогут улучшить доставку фич?
Ребята из Точки поделились интересным кейсом из своей практики.
Команда чувствовала, что в процессе доставки фич что-то идёт не так, но на ощупь определить узкие места не удавалось. Тогда тимлид начал внедрять метрики — и это показало всем объективную картину происходящего.
В статье автор описывает, какие именно метрики Точка стала отслеживать и что удалось благодаря этому выявить:
🔹 Cycle time
Показал, что задачи надолго зависают на этапе ревью. Проблема оказалась не в самом ревью, а в его ожидании. Решили делать ревью до дейли. Это резко ускорило прохождение задач по пайплайну.
🔹 Time to market
Подсветил разрыв между идеей и релизом. Стало видно, как задачи тормозятся ещё до разработки — из-за блокеров и неготовых требований.
🔹 Процент возвратов с тестирования
Вскрыл высокий уровень багбэков. Причина — потеря контекста и отсутствие автотестов. После внедрения автотестов возвратов стало меньше, и задачи стали доходить до продакшена с первого раза.
🔹 Распределение времени по типам задач
Дало понимание, как балансируется работа между багами, фичами и техдолгом. Например, если количество багов растёт, а времени на них почти нет — это сигнал, что воронка вот-вот начнёт захлёбываться.
Метрики не спасут, если процессы разваливаются, но без них ты просто не узнаешь, где именно всё ломается. Ребята из Точки не только поняли это, но и показали на реальных цифрах. Очень годный кейс — стоит почитать.
Реклама «АО Точка», tochka.com, 18+