В предыдущей статье я поднял вопрос о кризисе технических собеседований. Мы обсуждали, почему проверка знания синтаксиса на бумажке в 2026 году — это абсурд, и почему индустрия упорно игнорирует существование ИИ.
Читая комментарии, я поймал себя на мысли: мы ругаем HR за вопросы по синтаксису, но ведь вся наша карьерная лестница десятилетиями строилась именно вокруг знания синтаксиса и особенностей конкретных инструментов.
Команда AI for Devs подготовила перевод статьи, в которой по полочкам разбирается агентная экосистема. Skills, Prompts, Projects, MCP и сабагенты — что из этого отвечает за знания, что за действия, а что за подключение к данным. Материал помогает понять, какой инструмент когда использовать и как собирать из них сложные, но управляемые AI-воркфлоу.
Дисклеймер: большая часть советов из этой статьи подходит не только для Claude, но и для любых других AI-инструментов.
В одном из прошлых проектов случился «кошмар техлида»: в суматохе хотфикса было забыто добавление фильтра WHERE tenant_id = ? в одну из ручек API. В итоге один клиент увидел отчеты другого. Все быстро откатили, но я навсегда запомнил то холодное чувство в животе.
Когда начали проектировать архитектуру следующего проекта, я понял, что полагаться на внимательность разработчиков на код-ревью - это тупик. Рано или поздно кто-то устанет, ошибется, и данные снова протекут.
Искал способ гарантировать изоляцию данных так, чтобы ее физически нельзя было забыть.
Почему стандартные решения не подошли?
4000 строк в одном MR. Три часа на ревью, 12 замечаний, исправления - ещё 800 строк. На четвёртом заходе я закрыл вкладку и понял: проблема не в коде, а в том, что никто не знал, что именно нужно было написать.
Если ты работаешь с большими кодовыми базами, ситуация знакомая. Большие MR - симптом. Когда непонятно, что именно нужно сделать, разработчик пишет больше кода, чем требуется. Добавляет на всякий случай. Покрывает сценарии, которые никто не просил. MR растёт не потому что задача большая, а потому что границы размыты.
В этой статье я хотел бы рассмотреть микросервисные паттерны под другим углом. Когда я начинал изучение микросервисных паттернов, у меня постоянно был вопрос: Так это же было в другом паттерне. Я решил немного структурировать их: объединить по похожим элементам. Кластеризировать микросервисные паттерны достаточно тяжело так как каждый паттерн по‑своему уникален, однако для запоминания на собеседованиях или для себя это сделать можно. Основной контент статьи — картинка, далее идёт описание, чтобы всё было в одном месте.
Мультиагентные системы - главный тренд в AI-разработке. AutoGPT, CrewAI, LangGraph, Microsoft AutoGen обещают армию специализированных агентов, которые вместе решат любую задачу.
Сделал систему на 5 агентов, а потом передумал и сделал на одного.
История о том, что иногда с ИИ надо упрощать, а не усложнять.
Сервис для автоматической генерации дашбордов из данных. Пользователь загружает файл (CSV, Excel, JSON, PDF), AI анализирует данные и создаёт интерактивный дашборд с графиками. Бесплатный, без регистрации.
За пару недель работы:
153 дашборда сгенерировано
93 уникальных пользователя
Среди них крупные FMCG-сетиЧитать полностью »
Woven City — это экспериментальный город в Японии, построенный Читать полностью »
Всем привет! Меня зовут Анатолий, я представляю команду Front-End разработки компании DD Planet.
В этой статье расскажу о том, как наш проект завершил этап разработки и трансформировался в стабильный рабочий продукт.
Сталкивались ли вы с болью при управлении порядком запуска и остановки зависимостей в вашем Go-сервисе?
Разработка больших сервисов неизбежно приводит к необходимости управлять множеством зависимостей. В этом контексте мы говорим о долгоживущих компонентах, чья работа обеспечивается отдельными горутинами: как правило, это блокирующий метод (например, Start), внутри которого крутится цикл обработки.
Примерный сценарий жизненного цикла сервиса выглядит так:
При запускеЧитать полностью »
