🧩 ИИ-агенты — новое слово в работе с нейросетями

Если нейросеть просто выдаёт ответ по параметрам, то ИИ-агент способен решать комплексные задачи до заданного пользователем результата.

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

А с помощью нескольких ИИ-агентов вы сможете настроить целую цифровую команду, которая будет решать значительную часть ежедневных задач.

На курсе «ИИ-агенты для маркетинга» вы сможете собрать и внедрить своих ИИ-агентов, даже если никогда не работали с ИИ и языками программирования, и автоматизировать процессы в компании: от создания креативов до аналитики.

Сосредоточьтесь на стратегии и поручите рутину цифровой команде.

До 31 марта на курс «ИИ-агент» действует скидка 10%, а так же на все курсы кроме программ ВО и Медицины, по промокоду NETONEW10.

➡️ Записаться

Реклама. ООО "Нетология" ОГРН 1207700135884 erid:2VSb5xstda1

Скилл для подготовки к интервью

Наткнулся на рекомендацию скилла для отработки всех этапов по поиску работы:

👉Поиск слабых мест в резюме и его адаптация под конкретную вакансию.
👉Анализ расшифровок прошедших интервью с выделением слабых точек.
👉Симулятор прохождения разных типов собеседования.
👉Помощь с оформлением вашего опыта в STAR кейсы.

MWS Cloud запускает MWS GPT Model Hub: теперь подключение LLM — это не проект на несколько месяцев.

Облачный сервис дает доступ к 10 большим языковым моделям (от таких компаний как DeepSeek, Google, Alibaba, Zhipu AI) внутри публичной облачной платформы MWS Cloud Platform. До конца года добавят модели TTS и ASR, а также реранкеры.

Развертывание — за секунды через OpenAI‑совместимый API. Ключевое преимущество — сокращение time‑to‑market новых решений до двух раз.

Стоит затестить, если нужно:
• добавить AI‑ассистента в продукт;
• настроить интеллектуальный поиск;
• создать внутренние AI‑сервисы для сотрудников.

Сервис запущен на базе платформы MWS GPT.

Когда менеджер должен вмешиваться

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

👉Команда должна иметь возможность совершать ошибки и учиться на них. Выбрать такие ошибки поможет эвристика "Below/above the waterline" – если какая-то ошибка может сильно навредить и потопить ваш корабль, стоит вмешаться, иначе – нет.
👉Нужно различать ошибки и вкусовщину. В случае вкусовщины не нужно сильно давить своим мнением, оно не важнее других людей в команде.
👉Вмешиваться стоит в следующих случаях – команда столкнулась с большой неопределенностью, которую вы можете уменьшить; или они вошли в дедлок по вопросу, который не имеет одного верного ответа, например, по выбору архитектуры.
👉При оценке необходимости вмешательства всегда учитывайте сеньорность человека в контексте конкретной задачи. Иногда в одной и той же задаче джуну помощь может быть не нужна, а вот сеньору – вполне.
👉Хорошее вмешательство организовано таким образом, чтобы в будущем команда чему-то от него научилась, и в похожей ситуации справилась бы сама.

🛠 Тимлид и бизнес: как начать говорить на одном языке

«Сделали хорошо, но бизнес не оценил» — знакомая ситуация? Часто дело не в качестве решений, а в том, что они слабо связаны с реальными целями компании.
Или — хуже того — их просто не поняли.

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

👀 В программе:

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

🛠 Формат конференции такой: 5 дней, 10+ спикеров, утренние и вечерние сессии в Zoom и активное общение в закрытом Telegram-сообществе.

👉 Если хочется услышать опыт от крутых инженеров-руководителей и сразу применить знания на практике — держите ссылку.

До 30 марта действует early-bird цена.

Присоединиться!

Оптимизировать надо не скорость написания кода

Держите отличную статью, которую можете аккуратно закинуть своему СТО, когда он предложит внедрять метрики оценки количества AI-generated PR, или еще каким-то образом будет пушить ускорение разработки фичей.

Вообще, Голдратт уже все объяснил десятки лет назад, но эффективные менеджеры либо его не читают, либо думают, что именно их случай – особенный.

Как Cursor влияет на скорость и качество разработки

Исследователи взяли все репозитории с GitHub, в которых файл .cursorrules появился уже после создания проекта, и сравнили их состояние до и после его появления. Вот какие выводы получились:

👉После адопшна Cursor количество новых строк кода выросло в 3-5 раз, но уже спустя два месяца этот эффект проходит.
👉Одновременно с этим растет устойчивое накопление техдолга: статанализ находит на 30% больше проблем, а когнитивная сложность выросла на 40%.

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

Приглашаем вас на бесплатный вебинар, где расскажем о преимуществах управления инфраструктурой через код, обсудим типичные ошибки при внедрении IaC и покажем подход на практике.

Каждому участнику вебинара мы пришлём пошаговый план перехода к IaC.

📅 1 апреля, 11:00 по МСК
💻 Онлайн

РЕГИСТРАЦИЯ И ПРОГРАММА

Советы по техническим интервью в эпоху LLM

👉Углубляйтесь в личный опыт собеседуемого – LLM будет довольно сложно уйти в глубину и при этом поддерживать когерентность рассказа. Например, когда вы расспрашиваете кандидата про то, чем в своем опыте он оордится, закапывайтесь в конкретные решения по архитектуре, трейд-оффы, и встреченные сложности. Но главное – просите больше деталей в каждом из ответов, и смотрите на глубину понимания темы, критическое мышление и присутствие каких-то личных инсайтов, а не только общих выводов.
👉Так как огромную часть работы инженера составляет чтение кода, можно попробовать дать задачу именно на это, и разрешить использовать LLM. Важно смотреть, насколько хорошо он оперирует моделью, может ли найти проблемы в кодовой базе с ее помощью, насколько доверяет ее выводам, задает ли дополнительные вопросы вам, или целиком полагается на машину.
👉Похожая история с ревью кода – тут можно дать довольно запутанный PR и посмотреть, в какой мере кандидат полагается на свой вкус и размышления, а в какой – на выводы LLM.
👉Хороший кандидат не доверяет модели слепо, а кросс-валидирует ее выводы и дополняет личным мнением. Он умеет декомпозировать сложные проблемы на оораздо более локальные, и отдает LLM уже их. У него есть сильное доменное знание, и он его использует для подсказок и валидации модели.

Как Intercom использует Claude Code

Гипер-интересный тред про то, как в Intercom используют агентов для автоматизации разных процессов. Вот несколько идей:

👉Агентам дали доступ к продакшн админке, в которой есть штуки вроде контроля фичефлагов – но только на чтение.
👉Транскрипты всех сессий работы с агентом автоматически отправляются в LLM, чтобы собирать стату по частым ошибкам, недостающим скиллам и прочему. По итогу сразу же в бэклоге создаются таски на их решение.
👉Автоматически чинятся флаки тесты по заданной таксономии.
👉Автоматически обновляет список разрешенных пермишнов для агента на основе предыдущей истории их аппрува.

Два важных вопроса для собеседования

1️⃣Кто отвечает за задачу?

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

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

2️⃣Пишете ли вы unit тесты?

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

Если задать такой вопрос тимлиду, то он может вывести на разговор про понимание инженерной реальности системы – ограничения, риски, последствия решений, долгосрочную устойчивость.