Прокачать навыки System Design
Периодически коллеги или друзья спрашивают о хороших материалах для подготовки к интервью по System Design или в целом о том, как подтянуть свои навыки по System Design.
И уже достаточно давно я рекомендую небольшой курс (просьба не пугаться слова «курс») по System Design.
– если готовитесь к интервью, вы получите базу о том, как такие интервью проводятся, что важно для интервьюера, и достаточно оперативно получите фундаментальные знания, чтобы проходить такие интервью
– если хотите подтянуть навыки проектирования – этот курс даёт структурированную базу, и вы будете понимать, куда копать дальше, чтобы расширить знания
Начать рекомендую с видео от автора курса на YouTube.
Если никогда не проходили интервью по System Design, обязательно посмотрите мок-интервью от коллег из Тинька. Отличный разбор того, как проходит интервью, как правильно строить ответ, какие вопросы задавать и как углубляться в темы.
#systemdesign
Периодически коллеги или друзья спрашивают о хороших материалах для подготовки к интервью по System Design или в целом о том, как подтянуть свои навыки по System Design.
И уже достаточно давно я рекомендую небольшой курс (просьба не пугаться слова «курс») по System Design.
– если готовитесь к интервью, вы получите базу о том, как такие интервью проводятся, что важно для интервьюера, и достаточно оперативно получите фундаментальные знания, чтобы проходить такие интервью
– если хотите подтянуть навыки проектирования – этот курс даёт структурированную базу, и вы будете понимать, куда копать дальше, чтобы расширить знания
Начать рекомендую с видео от автора курса на YouTube.
Если никогда не проходили интервью по System Design, обязательно посмотрите мок-интервью от коллег из Тинька. Отличный разбор того, как проходит интервью, как правильно строить ответ, какие вопросы задавать и как углубляться в темы.
#systemdesign
Leetcode
Explore - LeetCode
LeetCode Explore is the best place for everyone to start practicing and learning on LeetCode. No matter if you are a beginner or a master, there are always new topics waiting for you to explore.
2👍9❤5🔥5
Друзья, хотел спросить: какие агенты вы используете в работе? Если не используете, то расскажите в комментах почему.
Anonymous Poll
30%
Cursor
16%
Claude Code
4%
Roo Code
14%
Другой инструмент – напишу в коммантах
43%
Не использую
❤6🔥3👎1
Выбирайте скучные технологии
Принес достаточно старую, но очень жизненную статью.
В ней автор говорит – выбирайте скучные технологии. И я, пожалуй, подпишусь под каждым словом.
Автор приводит классную метафору: у любой компании есть ограниченное число «жетонов на инновации». Хочешь на затащить Airflow? Потратил жетон. Захотел CockroachDB? Ещё жетон. Решил притянуть кастомную систему очередей, которую сам же и написал? Ну, удачи.
Главное преимущество скучных технологий в том, что индустрия уже хорошо понимает их поведение, ограничения – и, что самое важное, знает, где они ломаются.
И проблема не в новых технологиях как таковых. Проблема – в их цене: экспертиза команды, отладка, операционка, поддержка, миграции. Эта цена часто оказывается намного выше, чем кажется в момент выбора.
Когда с тимлидами обсуждаем внедрение новой технологии, мы стараемся смотреть шире, чем просто на технические характеристики. И всегда спрашиваю:
– А точно ли нам это нужно?
– А можем ли решить задачу на текущем стеке, хоть и не идеально?
И чаще всего оказывается – да, можем.
Важно понимать, что это не заскорузлость: давайте не будем использовать новое. Новые технологии нужны, но задача лида, не затащить новое, а выстроить процесс принятия решений. Сделать так, чтобы новинка добавлялась в стек обоснованно, с пониманием зачем, с оценкой последствий и, по возможности, с планом миграции или поддержки.
На эту тему у нас уже были посты:
– Как принимать архитектурные решения
– Для чего мы рисуем архитектурные схемы
Принес достаточно старую, но очень жизненную статью.
В ней автор говорит – выбирайте скучные технологии. И я, пожалуй, подпишусь под каждым словом.
Автор приводит классную метафору: у любой компании есть ограниченное число «жетонов на инновации». Хочешь на затащить Airflow? Потратил жетон. Захотел CockroachDB? Ещё жетон. Решил притянуть кастомную систему очередей, которую сам же и написал? Ну, удачи.
Главное преимущество скучных технологий в том, что индустрия уже хорошо понимает их поведение, ограничения – и, что самое важное, знает, где они ломаются.
И проблема не в новых технологиях как таковых. Проблема – в их цене: экспертиза команды, отладка, операционка, поддержка, миграции. Эта цена часто оказывается намного выше, чем кажется в момент выбора.
Когда с тимлидами обсуждаем внедрение новой технологии, мы стараемся смотреть шире, чем просто на технические характеристики. И всегда спрашиваю:
– А точно ли нам это нужно?
– А можем ли решить задачу на текущем стеке, хоть и не идеально?
И чаще всего оказывается – да, можем.
Важно понимать, что это не заскорузлость: давайте не будем использовать новое. Новые технологии нужны, но задача лида, не затащить новое, а выстроить процесс принятия решений. Сделать так, чтобы новинка добавлялась в стек обоснованно, с пониманием зачем, с оценкой последствий и, по возможности, с планом миграции или поддержки.
На эту тему у нас уже были посты:
– Как принимать архитектурные решения
– Для чего мы рисуем архитектурные схемы
Dan McKinley :: Math, Programming, and Minority Reports
Dan McKinley :: Choose Boring Technology
🔥15❤8👍7
Еще один способ организовать рабочие чатики
Я пробовал организовывать рабочие чатики самыми разными способами: иногда просто в отдельную папочку, иногда – в папки по проектам.
Но у такой логичной организации есть проблемы:
– Ты не можешь сходу понять, какие чатики требуют внимания
– Имея большое количество чатов в папке, иногда невольно открываешь посмотреть то, что тебе сейчас вовсе не нужно
И некоторое время назад я придумал (вряд ли я, но в моем мире – именно я), как иначе организовать рабочие чатики – по срочности.
Сделал 4 папки:
🔹Now – то, на что мне нужно реагировать незамедлительно. Таких чатов всего 1–2, но стремиться нужно к нулю
🔹Hourly – то, на что нужно посмотреть в течение часа
🔹Daily – пробежаться раз в день, узнать, что происходило
🔹Later – оно же «никогда», оно же «когда-нибудь». Это чаты, где просто нужно присутствовать :)
В результате стало гораздо легче ориентироваться и не отвлекаться на лишний шум.
#devfm
Я пробовал организовывать рабочие чатики самыми разными способами: иногда просто в отдельную папочку, иногда – в папки по проектам.
Но у такой логичной организации есть проблемы:
– Ты не можешь сходу понять, какие чатики требуют внимания
– Имея большое количество чатов в папке, иногда невольно открываешь посмотреть то, что тебе сейчас вовсе не нужно
И некоторое время назад я придумал (вряд ли я, но в моем мире – именно я), как иначе организовать рабочие чатики – по срочности.
Сделал 4 папки:
🔹Now – то, на что мне нужно реагировать незамедлительно. Таких чатов всего 1–2, но стремиться нужно к нулю
🔹Hourly – то, на что нужно посмотреть в течение часа
🔹Daily – пробежаться раз в день, узнать, что происходило
🔹Later – оно же «никогда», оно же «когда-нибудь». Это чаты, где просто нужно присутствовать :)
В результате стало гораздо легче ориентироваться и не отвлекаться на лишний шум.
#devfm
4👍19🔥10⚡5🌭1
Новый взгляд на 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
Сложно сейчас представить использование 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
Anthropic
Code execution with MCP: building more efficient AI agents
Learn how code execution with the Model Context Protocol enables agents to handle more tools while using fewer tokens, reducing context overhead by up to 98.7%.
👍10🔥6⚡4😁1
You Should Write An Agent
Недавно проводил опрос: по поводу использования агентов и оказалось, что многие используют.
Нашёл отличную статью – в ней автор предлагает самостоятельно разобраться, как базово устроены агенты под капотом, и попробовать реализовать своего.
В первой части – пошагово и с кодом объясняется, как работает агентский цикл: мы храним историю контекста, передаём её языковой модели и получаем ответы.
Дальше – интереснее: как подключать tools к агенту. Автор даёт агенту возможность выполнять команду ping. LLM сама инициирует вызов нужного инструмента. Получается очень прикольно: ты не описывал логики, не писал условий – модель сама решила, какие адреса пинговать, как интерпретировать результаты и как сформировать ответ.
В конце автор затрагивает важный вопрос контекста. Он показывает, что вся магия мультиагентности – это просто несколько массивов контекста и чуть-чуть управляющего кода.
В общем, рекомендую посмотреть и поэкспериментировать самостоятельно.
#ai
Недавно проводил опрос: по поводу использования агентов и оказалось, что многие используют.
Нашёл отличную статью – в ней автор предлагает самостоятельно разобраться, как базово устроены агенты под капотом, и попробовать реализовать своего.
В первой части – пошагово и с кодом объясняется, как работает агентский цикл: мы храним историю контекста, передаём её языковой модели и получаем ответы.
Дальше – интереснее: как подключать tools к агенту. Автор даёт агенту возможность выполнять команду ping. LLM сама инициирует вызов нужного инструмента. Получается очень прикольно: ты не описывал логики, не писал условий – модель сама решила, какие адреса пинговать, как интерпретировать результаты и как сформировать ответ.
В конце автор затрагивает важный вопрос контекста. Он показывает, что вся магия мультиагентности – это просто несколько массивов контекста и чуть-чуть управляющего кода.
В общем, рекомендую посмотреть и поэкспериментировать самостоятельно.
#ai
Telegram
DevFM
Друзья, хотел спросить: какие агенты вы используете в работе? Если не используете, то расскажите в комментах почему.
Cursor / Claude Code / Roo Code / Другой инструмент – напишу в коммантах / Не использую
Cursor / Claude Code / Roo Code / Другой инструмент – напишу в коммантах / Не использую
👍10🔥8⚡4👎1
Шаблонный сервис
Я всячески люблю, когда разработка идёт предсказуемо – и многое для этого делаю.
Давно хотел написать пост о важности шаблонного сервиса, но не было хорошего примера под рукой. И тут мой коллега выложил наш шаблонный сервис на FastAPI, который мы долгое время использовали и развивали.
Так зачем же нужен шаблонный сервис?
Легко ориентироваться в других сервисах. Иногда нужно залезть в сервис коллег, или поддерживаешь несколько сервисов. Никаких проблем – структура везде одинаковая, всё знакомо, не нужно тратить время на раскопки.
Быстрый старт. Стартуете новый сервис? Полчаса – и он готов. Никаких лишних приседаний.
Единые практики. Шаблон определяет, не только структуру, но и то, как мы, например, делаем ретраи, какие у нас зависимости. как устроен circuit breaker, обработка ошибок и т.д.
Лучшие практики – в одном месте. Если появляется что-то классное, мы добавляем это в шаблон и новые сервисы сразу это наследуют.
Обсервабилити, логирование, работа с секретами – готово из коробки. И меньше шансов, что кто-то забьёт на логирование до лучших времён»:)
Онбординг на кошечках. Новый человек сначала изучает шаблонный сервис, понимает подходы, а потом уже ныряет в боевые системы.
Просто экспериментировать. Создал веточку от шаблона – и прикручиваешь свою новую махарайку, не тратя время на базовую структуру.
Унификация линтинга. Конфиги линтеров лежат в шаблоне. Ничего настраивать не нужно, а код-ревью идёт быстрее – обо всём уже однажды договорились и зафиксировали.
Базовый CI/CD. Для шаблонного сервиса существует шаблонный ci/cd – и это очень удобно.
Мы активно использовали шаблонный сервис в микросервисной архитектуре, но и для монолитных решений он тоже отлично зашёл – стартовали с ним несколько проектов.
Понимаю, что это нужно не всем. Но если вы занимаетесь продуктовой разработкой и играете вдолгую — на мой взгляд, это мастхев.
В общем – заходите, смотрите, ставьте звездочки. И если с чем-то не согласны – пишите в комменты, автор обязательно ответит 🙂
#devfm #systemdesign
Я всячески люблю, когда разработка идёт предсказуемо – и многое для этого делаю.
Давно хотел написать пост о важности шаблонного сервиса, но не было хорошего примера под рукой. И тут мой коллега выложил наш шаблонный сервис на FastAPI, который мы долгое время использовали и развивали.
Так зачем же нужен шаблонный сервис?
Легко ориентироваться в других сервисах. Иногда нужно залезть в сервис коллег, или поддерживаешь несколько сервисов. Никаких проблем – структура везде одинаковая, всё знакомо, не нужно тратить время на раскопки.
Быстрый старт. Стартуете новый сервис? Полчаса – и он готов. Никаких лишних приседаний.
Единые практики. Шаблон определяет, не только структуру, но и то, как мы, например, делаем ретраи, какие у нас зависимости. как устроен circuit breaker, обработка ошибок и т.д.
Лучшие практики – в одном месте. Если появляется что-то классное, мы добавляем это в шаблон и новые сервисы сразу это наследуют.
Обсервабилити, логирование, работа с секретами – готово из коробки. И меньше шансов, что кто-то забьёт на логирование до лучших времён»:)
Онбординг на кошечках. Новый человек сначала изучает шаблонный сервис, понимает подходы, а потом уже ныряет в боевые системы.
Просто экспериментировать. Создал веточку от шаблона – и прикручиваешь свою новую махарайку, не тратя время на базовую структуру.
Унификация линтинга. Конфиги линтеров лежат в шаблоне. Ничего настраивать не нужно, а код-ревью идёт быстрее – обо всём уже однажды договорились и зафиксировали.
Базовый CI/CD. Для шаблонного сервиса существует шаблонный ci/cd – и это очень удобно.
Мы активно использовали шаблонный сервис в микросервисной архитектуре, но и для монолитных решений он тоже отлично зашёл – стартовали с ним несколько проектов.
Понимаю, что это нужно не всем. Но если вы занимаетесь продуктовой разработкой и играете вдолгую — на мой взгляд, это мастхев.
В общем – заходите, смотрите, ставьте звездочки. И если с чем-то не согласны – пишите в комменты, автор обязательно ответит 🙂
#devfm #systemdesign
GitHub
GitHub - ydjin0602/fastapi-template
Contribute to ydjin0602/fastapi-template development by creating an account on GitHub.
👍17🔥12❤6👎5⚡3
This media is not supported in your browser
VIEW IN TELEGRAM
Пятничное развлекательное
Наткнулся на очень забавный сайт: разные модели генерируют аналоговые часы.
Каждую минуту в модель улетает такой промпт:
А дальше ai начинает творить чудеса.
В общем заходите посмотреть :)
#fun
Наткнулся на очень забавный сайт: разные модели генерируют аналоговые часы.
Каждую минуту в модель улетает такой промпт:
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.
А дальше ai начинает творить чудеса.
В общем заходите посмотреть :)
#fun
🔥8👍6⚡4
Ух, вчера вспомнил давно забытую боль.
Некоторое время назад мы пилили b2b-продукт и интегрировались по HTTP с большим сервисом большой компании.
И вот представьте моё удивление, когда приходит разработчик и говорит, что мы получаем код 200, а в body – что-то типа «произошла ошибка». Мы тогда повозмущались и смирились, потому что альтернатив всё равно не было.
И всё бы ничего, если бы вчера я не рассказал эту историю своему хорошему товарищу. А он, представьте себе, вообще не удивился. Сказал: «Да, всё так и есть. Видел это не раз. И во вполне приличных конторах – тоже».
И вот у меня вопрос – ну как так то, доколе?! Может, у этого есть какая-то логика?
Вы такое встречали?
#devfm
Некоторое время назад мы пилили b2b-продукт и интегрировались по HTTP с большим сервисом большой компании.
И вот представьте моё удивление, когда приходит разработчик и говорит, что мы получаем код 200, а в body – что-то типа «произошла ошибка». Мы тогда повозмущались и смирились, потому что альтернатив всё равно не было.
И всё бы ничего, если бы вчера я не рассказал эту историю своему хорошему товарищу. А он, представьте себе, вообще не удивился. Сказал: «Да, всё так и есть. Видел это не раз. И во вполне приличных конторах – тоже».
И вот у меня вопрос – ну как так то, доколе?! Может, у этого есть какая-то логика?
Вы такое встречали?
#devfm
😁12⚡7❤4🌭2
Присмотритесь к Zed
Недавно общались про агентов (других тем у меня сейчас на повестке не бывает), и разговор внезапно ушёл в сторону Zed. Я за этим редактором кода давно посматриваю: у ребят очень специфичный вижн – всё вокруг идеи совместной работы.
В их статье Zed is our office ребята подробно рассказывают, как используют редактор у себя внутри, превращая его в настоящий виртуальный офис. И вот там становится ясно, что их коллаборативность – это не про «парное программирование на коленочках». Масштаб совсем другой.
Если идея парного программирования меня не очень вдохновляет, то такой подход к внутренним рабочим процессам – прям зашёл. Я даже попробовал провести созвон в Zed, когда обсуждали ТЗ: оказалось удобно, ничего шарить не нужно – все работают в одном документе.
Но смотреть на Zed стоит не только ради совместной работы. Он сам по себе очень приятный в использовании – свежий взгляд на IDE. Плюс ребята активно развивают AI-фичи и уже встроили Claude Code и других агентов.
Недавно общались про агентов (других тем у меня сейчас на повестке не бывает), и разговор внезапно ушёл в сторону Zed. Я за этим редактором кода давно посматриваю: у ребят очень специфичный вижн – всё вокруг идеи совместной работы.
В их статье Zed is our office ребята подробно рассказывают, как используют редактор у себя внутри, превращая его в настоящий виртуальный офис. И вот там становится ясно, что их коллаборативность – это не про «парное программирование на коленочках». Масштаб совсем другой.
Если идея парного программирования меня не очень вдохновляет, то такой подход к внутренним рабочим процессам – прям зашёл. Я даже попробовал провести созвон в Zed, когда обсуждали ТЗ: оказалось удобно, ничего шарить не нужно – все работают в одном документе.
Но смотреть на Zed стоит не только ради совместной работы. Он сам по себе очень приятный в использовании – свежий взгляд на IDE. Плюс ребята активно развивают AI-фичи и уже встроили Claude Code и других агентов.
zed.dev
Zed Is Our Office
From the Zed Blog: A look at how we use Zed's native collaboration features to run our entire company.
👍7🔥5⚡3😁1
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.
Каждый из этих тулов имеет трейдофы, но это важный шаг к полноценным рабочим агентам, которые управляют большими процессами и сложными наборами инструментов.
Не пришлось долго ждать. Сначала 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.
Каждый из этих тулов имеет трейдофы, но это важный шаг к полноценным рабочим агентам, которые управляют большими процессами и сложными наборами инструментов.
Telegram
DevFM
Новый взгляд на MCP
Сложно сейчас представить использование AI-агентов без MCP-серверов.
MCP позволяет агенту подключаться к различным внешним системам, чтобы запрашивать данные, выполнять операции и выстраивать сложные цепочки взаимодействий.
Но текущий…
Сложно сейчас представить использование AI-агентов без MCP-серверов.
MCP позволяет агенту подключаться к различным внешним системам, чтобы запрашивать данные, выполнять операции и выстраивать сложные цепочки взаимодействий.
Но текущий…
🔥11❤5⚡4👎2🌭2
Media is too big
VIEW IN TELEGRAM
Пятничное развлекательное
Как-то я уже рассказывал о проблеме вагонетки.
А вообще у neal.fun много залипательных и медитативных интерактивностей:
– визуализация денежного потока, обязательно пролистайте до самого конца
– путешествие по маршруту, где направление выбирают голоса пользователей, классно, чтобы пару минут проветрить голову
– подъём на лифте в космос, идеально, позалипать
Как-то я уже рассказывал о проблеме вагонетки.
А вообще у neal.fun много залипательных и медитативных интерактивностей:
– визуализация денежного потока, обязательно пролистайте до самого конца
– путешествие по маршруту, где направление выбирают голоса пользователей, классно, чтобы пару минут проветрить голову
– подъём на лифте в космос, идеально, позалипать
👍8🔥8❤4
How AI is transforming work at Anthropic
Ребята из Anthropic опубликовали исследование – как меняется работа инженеров внутри компании, которая сама делает Claude. И кажется, они прошлись по всем вопросам, которые сегодня беспокоят индустрию.
Вот, что меня заинтересовало.
Решаемые задачи и продуктивность
Это важный блок – особенно чтобы не выращивать ложные ожидания, будто агент будет выполнять всё под ключ.
– Инженеры используют Claude примерно в половине своей работы и оценивают прирост продуктивности до 50%
– Полностью отдать ему получается только до 20% задач – всё остальное выполняется с плотным контролем
– Треть работ, сделанных с Claude, просто не существовало бы без ИИ: nice-to-have тулзы, дополнительные дашборды
И вот здесь у меня возникает вопросик: если часть задач создаётся только потому, что теперь их дешево делать, не ломает ли это приоритизацию? Мы ускоряемся – но ускоряемся ли в нужную сторону?
Про важность делегирования
Когда начинаете работать с агентами, важно уметь давать ему шанс:
– начинать с маленьких и чётко проверяемых задач
– смотреть, с чем он справляется хорошо
– постепенно развивать навык понимать, какие задачи он делает хорошо, а какие лучше оставить себе
Антропик отдельно отмечают: многие негативные кейсы появляются не из-за тупости модели, а из-за неправильного выбора задачи.
На самом деле категорически согласен с этим пунктом.
Все становятся чуть более fullstack-чнее
Авторы пишут, что инженеры стали легче заходить в смежные зоны:
бэкендеры делают фронт, ресёрчеры собирают визуализации, секьюрити разбирают незнакомый код без лишней боли.
Порог входа в новые области сильно падает – можно набросать прототип, показать, отрефакторить и прогнать через Claude.
И важный эффект – меньше пинг-понга между командами: теперь можно не ждать коллег практически по каждому мелкому вопросу.
Что с навыками
– Инженеры отмечают страх потерять экспертизу: когда агент быстро прыгает к решению, ты меньше копаешься в доках и чужом коде – экспертиза формируется медленнее
– Парадокс: чтобы проверять агента, нужны именно те навыки, которые могут атрофироваться
– И вот здесь, как мне кажется, кроется большая проблема: непонятно, как теперь вырасти из джуна. У новичков исчезла часть естественных первых шагов, а спрос на настоящих сеньоров будет только расти. (Но не тех, кто в 25 считают себя сеньорами – извинити, вот такой я дед)
Коммуникации в командах
– 80–90% вопросов, которые раньше шли коллегам, теперь уходят сначала к Claude
– Это влияет на менторство: джуны меньше спрашивают, сеньоры реже передают экспертизу
В общем, очень рекомендую статью к прочтению.
И важно понимать: ребята прямо говорят, что это не истина в последней инстанции. Многое ещё требует прояснения. Да и в целом профессия меняется – и во что это выльется, пока не знает никто.
#ai
Ребята из Anthropic опубликовали исследование – как меняется работа инженеров внутри компании, которая сама делает Claude. И кажется, они прошлись по всем вопросам, которые сегодня беспокоят индустрию.
Вот, что меня заинтересовало.
Решаемые задачи и продуктивность
Это важный блок – особенно чтобы не выращивать ложные ожидания, будто агент будет выполнять всё под ключ.
– Инженеры используют Claude примерно в половине своей работы и оценивают прирост продуктивности до 50%
– Полностью отдать ему получается только до 20% задач – всё остальное выполняется с плотным контролем
– Треть работ, сделанных с Claude, просто не существовало бы без ИИ: nice-to-have тулзы, дополнительные дашборды
И вот здесь у меня возникает вопросик: если часть задач создаётся только потому, что теперь их дешево делать, не ломает ли это приоритизацию? Мы ускоряемся – но ускоряемся ли в нужную сторону?
Про важность делегирования
Когда начинаете работать с агентами, важно уметь давать ему шанс:
– начинать с маленьких и чётко проверяемых задач
– смотреть, с чем он справляется хорошо
– постепенно развивать навык понимать, какие задачи он делает хорошо, а какие лучше оставить себе
Антропик отдельно отмечают: многие негативные кейсы появляются не из-за тупости модели, а из-за неправильного выбора задачи.
На самом деле категорически согласен с этим пунктом.
Все становятся чуть более fullstack-чнее
Авторы пишут, что инженеры стали легче заходить в смежные зоны:
бэкендеры делают фронт, ресёрчеры собирают визуализации, секьюрити разбирают незнакомый код без лишней боли.
Порог входа в новые области сильно падает – можно набросать прототип, показать, отрефакторить и прогнать через Claude.
И важный эффект – меньше пинг-понга между командами: теперь можно не ждать коллег практически по каждому мелкому вопросу.
Что с навыками
– Инженеры отмечают страх потерять экспертизу: когда агент быстро прыгает к решению, ты меньше копаешься в доках и чужом коде – экспертиза формируется медленнее
– Парадокс: чтобы проверять агента, нужны именно те навыки, которые могут атрофироваться
– И вот здесь, как мне кажется, кроется большая проблема: непонятно, как теперь вырасти из джуна. У новичков исчезла часть естественных первых шагов, а спрос на настоящих сеньоров будет только расти. (Но не тех, кто в 25 считают себя сеньорами – извинити, вот такой я дед)
Коммуникации в командах
– 80–90% вопросов, которые раньше шли коллегам, теперь уходят сначала к Claude
– Это влияет на менторство: джуны меньше спрашивают, сеньоры реже передают экспертизу
В общем, очень рекомендую статью к прочтению.
И важно понимать: ребята прямо говорят, что это не истина в последней инстанции. Многое ещё требует прояснения. Да и в целом профессия меняется – и во что это выльется, пока не знает никто.
#ai
👍19❤6🔥4⚡2
СССектор приз на барабане!
Я частенько использую в коммуникации какие-то фразочки и прибаутки.
И к Новому году у нас конкурс: расскажите, что забавного вы сами используете или слышите от коллег.
Автор самого залайканного комментария получит от меня подарок– любую книгу на ваш выбор до 5к . Итоги подведем 31 декабря.
Чтобы задать темп, начну со своих.
– “Этого ребёнка проще выкинуть, чем отмыть”.
Когда-то я так часто собирался что-то выкинуть, что получил на день рождения торт с этой фразой.
– “Когда есть молоток, всё начинает казаться гвоздями”
– "Сколько свинью не крась, олень не получится"
Готов послушать ваши любимые рабочие фразочки и приговорки! Приводите друзей, пусть они тоже поделятся 🙂
⚡️ DevFM
Я частенько использую в коммуникации какие-то фразочки и прибаутки.
И к Новому году у нас конкурс: расскажите, что забавного вы сами используете или слышите от коллег.
Автор самого залайканного комментария получит от меня подарок
Чтобы задать темп, начну со своих.
– “Этого ребёнка проще выкинуть, чем отмыть”.
Когда-то я так часто собирался что-то выкинуть, что получил на день рождения торт с этой фразой.
– “Когда есть молоток, всё начинает казаться гвоздями”
– "Сколько свинью не крась, олень не получится"
Готов послушать ваши любимые рабочие фразочки и приговорки! Приводите друзей, пусть они тоже поделятся 🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10❤5⚡3🌭1
Хотел написать небольшой пост – а в итоге получилась целая статья.
Недавно у меня был классный опыт парного программирования с товарищем: он пишет код, а я смотрю за его флоу и предлагаю оптимизации.
Собрал в статье практические советы, которые помогают при работе с агентами:
– как организовать удобный флоу
– почему не стоит просить «сделать всё под ключ» и как стоит
– как формировать рабочие rules
– зачем переключать модели и когда это спасает
– почему экспертиза разработчика всё ещё критично важна
Заходите почитать, если понравилась ставьте лайкосики.
#devfm
Недавно у меня был классный опыт парного программирования с товарищем: он пишет код, а я смотрю за его флоу и предлагаю оптимизации.
Собрал в статье практические советы, которые помогают при работе с агентами:
– как организовать удобный флоу
– почему не стоит просить «сделать всё под ключ» и как стоит
– как формировать рабочие rules
– зачем переключать модели и когда это спасает
– почему экспертиза разработчика всё ещё критично важна
Заходите почитать, если понравилась ставьте лайкосики.
#devfm
Хабр
Мой опыт разработки с агентами: советы
Недавно у меня была сессия парного программирования с хорошим товарищем. Получилась классная коллаборация: он пишет код, а я наблюдаю за его флоу и предлагаю оптимизации по части использования...
👍14🔥12❤8
Зачем вы проводите код-ревью?
Большая часть команд, с которыми я работал, проводят код-ревью. Код-ревью – как священная корова: “А код поревьюили?”, “Без ревью не пушим” и всякое такое.
И каждый PR дисциплинированно пропускают через код-ревью: назначаются ревьюеры, они что-то пишут, код как-то правится...
Я искренне при любой удобной возможности интересуюсь у лидов или обычных работяг, зачем они его проводят.
Ответы бывают разные.
Мы хотим поддерживать качество кода, соблюдать единый стиль.
Что ж, похвально. Только у меня сразу возникает вопрос: а что вы считаете качественным кодом, что считаете единым стилем? А у вас настроены какие-то автоматизации? Ответы бывают разными, но по моему опыту редко есть уверенные ответы на все из них. А без этого код-ревью очень быстро превращается в вкусовщину и в обсуждение того, что вообще-то должна делать машина – линтеры, форматеры, базовые проверки.
Ревьюеры могут найти баг или проблему.
Вот с этого я искренне всегда недоумеваю. У меня сразу возникает вопрос: а кто у вас пишет код, если ревьюеры, не находясь в глубоком контексте задачи, могут заметить баг? Если баги регулярно ловятся на код-ревью, значит вы используете самый дорогой, самый медленный и самый ненадёжный механизм контроля качества. Ревью не воспроизводимо, не масштабируется и слишком сильно зависит от человеческого фактора.
Код-ревью нам нужно для шаринга знаний – такой ответ дают самые прогрессивные. Честно говоря, какое-то время это был мой любимый аргумент, и я очень им гордился. Но если задуматься: для шаринга знаний предполагается, что разработчик, у которого куча своих задач и контекстов, переключится на чужую задачу, впитает всё, что там написано, разберётся и получит ценные знания. Вопрос – сколько же времени нужно для этого? Как говорят классики: «сомнительно, но окэээээй». Если услышите такой аргумент, спросите у разработчиков, сколько времени они тратят на ревью, и подумайте, можно ли за это время действительно перенять знания. Ответы, которые получал я, говорят: скорее нет, нельзя.
Моё мнение – код-ревью создаёт иллюзию шаринга знаний, но по факту распространяет только очень поверхностный контекст. Если вы реально хотите шарить знания, есть куда более прямые и честные инструменты – дизайн-доки, обсуждения решений до реализации, грумминги задач.
И это я ещё не затронул другие проблемы и крайности: когда в PR появляется миллион комментариев, когда какой-то очень умный разработчик упирается рогом и говорит, что такой PR "только через мой труп", когда PR-ы висят днями, копят строчки, а потом полдня тратится на разруливание конфликтов. В общем – красота.
Так зачем это всё?
Код-ревью – полезная практика
Да, я всё ещё считаю код-ревью полезной практикой. Но чтобы она работала, над этим нужно много работать. Хорошее код-ревью – это работа над инженерной культурой.
Первое – составить гайд, хотя бы выровняться по одной линейке: как в команде проводится ревью, что мы ревьюим, на что обращаем внимание, а что считаем минором, тайминги проведения, выбор ревьюера, правила оформления PR-ов.
Второе – автоматизировать всё, что можно автоматизировать: линтеры, форматеры и вот это всё. Чтобы на ревью об этом даже не думали.
И даже когда есть гайд, тимлид должен чутко следить за его соблюдением и периодически подвергать сомнению его содержимое. У нас на практике в стайлгайдах в шапке была такая графа: актуализировать – "дата". Чтобы целенаправленно и критически посмотреть на эти правила.
Ревью действительно должно быть:
– когда вы залезли в чужой сервис или область знаний и сами просите эксперта посмотреть код
– когда вы мейнтейнер опенсорсного проекта
– когда вы менторите новичков или джунов и осознанно инвестируете время
Если вы прочитали и подумали: "Что это за бред?" – ну что же. Либо вы никогда критически не смотрели на этот процесс, либо вам действительно повезло с командой. Во втором случае искренне за вас рад – держитесь за неё. Так бывает далеко не у всех.
#devfm
Большая часть команд, с которыми я работал, проводят код-ревью. Код-ревью – как священная корова: “А код поревьюили?”, “Без ревью не пушим” и всякое такое.
И каждый PR дисциплинированно пропускают через код-ревью: назначаются ревьюеры, они что-то пишут, код как-то правится...
Я искренне при любой удобной возможности интересуюсь у лидов или обычных работяг, зачем они его проводят.
Ответы бывают разные.
Мы хотим поддерживать качество кода, соблюдать единый стиль.
Что ж, похвально. Только у меня сразу возникает вопрос: а что вы считаете качественным кодом, что считаете единым стилем? А у вас настроены какие-то автоматизации? Ответы бывают разными, но по моему опыту редко есть уверенные ответы на все из них. А без этого код-ревью очень быстро превращается в вкусовщину и в обсуждение того, что вообще-то должна делать машина – линтеры, форматеры, базовые проверки.
Ревьюеры могут найти баг или проблему.
Вот с этого я искренне всегда недоумеваю. У меня сразу возникает вопрос: а кто у вас пишет код, если ревьюеры, не находясь в глубоком контексте задачи, могут заметить баг? Если баги регулярно ловятся на код-ревью, значит вы используете самый дорогой, самый медленный и самый ненадёжный механизм контроля качества. Ревью не воспроизводимо, не масштабируется и слишком сильно зависит от человеческого фактора.
Код-ревью нам нужно для шаринга знаний – такой ответ дают самые прогрессивные. Честно говоря, какое-то время это был мой любимый аргумент, и я очень им гордился. Но если задуматься: для шаринга знаний предполагается, что разработчик, у которого куча своих задач и контекстов, переключится на чужую задачу, впитает всё, что там написано, разберётся и получит ценные знания. Вопрос – сколько же времени нужно для этого? Как говорят классики: «сомнительно, но окэээээй». Если услышите такой аргумент, спросите у разработчиков, сколько времени они тратят на ревью, и подумайте, можно ли за это время действительно перенять знания. Ответы, которые получал я, говорят: скорее нет, нельзя.
Моё мнение – код-ревью создаёт иллюзию шаринга знаний, но по факту распространяет только очень поверхностный контекст. Если вы реально хотите шарить знания, есть куда более прямые и честные инструменты – дизайн-доки, обсуждения решений до реализации, грумминги задач.
И это я ещё не затронул другие проблемы и крайности: когда в PR появляется миллион комментариев, когда какой-то очень умный разработчик упирается рогом и говорит, что такой PR "только через мой труп", когда PR-ы висят днями, копят строчки, а потом полдня тратится на разруливание конфликтов. В общем – красота.
Так зачем это всё?
Код-ревью – полезная практика
Да, я всё ещё считаю код-ревью полезной практикой. Но чтобы она работала, над этим нужно много работать. Хорошее код-ревью – это работа над инженерной культурой.
Первое – составить гайд, хотя бы выровняться по одной линейке: как в команде проводится ревью, что мы ревьюим, на что обращаем внимание, а что считаем минором, тайминги проведения, выбор ревьюера, правила оформления PR-ов.
Второе – автоматизировать всё, что можно автоматизировать: линтеры, форматеры и вот это всё. Чтобы на ревью об этом даже не думали.
И даже когда есть гайд, тимлид должен чутко следить за его соблюдением и периодически подвергать сомнению его содержимое. У нас на практике в стайлгайдах в шапке была такая графа: актуализировать – "дата". Чтобы целенаправленно и критически посмотреть на эти правила.
Ревью действительно должно быть:
– когда вы залезли в чужой сервис или область знаний и сами просите эксперта посмотреть код
– когда вы мейнтейнер опенсорсного проекта
– когда вы менторите новичков или джунов и осознанно инвестируете время
Если вы прочитали и подумали: "Что это за бред?" – ну что же. Либо вы никогда критически не смотрели на этот процесс, либо вам действительно повезло с командой. Во втором случае искренне за вас рад – держитесь за неё. Так бывает далеко не у всех.
#devfm
👍19🔥10🌭7❤4😁1