Проектирование API *

На GitHub лежат сотни AI-скиллов. Скилл для code review, скилл для дебага, скилл для обработки PDF, скилл для анализа безопасности. Установил в Cursor или Claude Code — и твой AI-ассистент стал умнее. Звучит как npm install: поставил пакет, он работает.

Но скилл — не пакет. Это текстовый файл с инструкциями, который читает языковая модель. А модели читают по-разному.

Представьте: вы написали подробное ТЗ и отдали его четырём специалистам. Все четверо — профессионалы, все мотивированы, все прочитали ТЗ целиком. Результат будет разный. Каждый делает как его учили, как привык, какой опыт накопил. И всегда есть шанс, что кто-то начнёт не с того конца или вообще решит ответить устно вместо того, чтобы сделать.

Модель = работник. Скилл = ТЗ. Я взял одно ТЗ, отдал четырём работникам, и каждый выполнял его 120 раз. Вот что получилось.

Забегая вперёд: скиллы работают. Но не так, как обещают. И самый интересный результат оказался не там, где я ожидал.

С завидным постоянством в тематических каналах возникают вопросы про 429 и 50x HTTP ошибки при получении данных из API WB или OZ. Коллеги интересуются, нет ли особого параметра, секретного метода или «золотого» часа, когда гарантированно можно получить данные без ошибок.

Увы, нет. Поэтому надо искать пути решения. Самый очевидный из них — относиться к 429 и 50x как к штатной ситуация и соответственно ее обрабатывать программной логикой.

Пример функции опроса API может выглядеть как‑то так:

Есть такой момент, знакомый каждому, кто долго работает в паре с AI. Сидишь в терминале, Claude генерит код, ты ревьюишь, правишь курс, снова запускаешь. Проходит пара часов, и ты понимаешь: никто не записал, что вообще произошло.

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

Меня это достало. Заканчиваю марафон-сессию с Claude или Codex, ощущение, что гора работы сделана, а доска проекта все так же показывает Not Started. Тайм-трекинг? Какой тайм-трекинг. Разрыв между реальной работой и тем, как выглядит проект, стал просто нелепым.

Недавно я обнаружил, что далеко не все знают об одной простой вещи — и это меня удивило.

Многие думают примерно так: «я описал интерфейс, указал что GET /users возвращает User[], TypeScript подсвечивает все поля, автодополнение работает — значит всё под контролем». Звучит разумно. Но есть одна проблема.

TypeScript работает только во время компиляции. В рантайме его нет.

Когда реальный ответ прилетает с сервера — никакой проверки не происходит. TypeScript просто верит вашей аннотации и молчит. Что реально вернул сервер — string вместо number, переименованное поле, отсутствующий объект — он не знает и знать не будет.

Вы узнаете об этом позже. Обычно от пользователей.

Я всю жизнь писал только бэк и подкапотщину - будь это классический КРУД, хайлоад, CLI, [вставьте свое]... И для любых сетевых взаимодействий чаще всего люди думают именно прикладными вещами - GRPC, REST, Kafka, не задумываясь об этом глубже - супер удобные инструменты с защитами от дураков и прочими радостями

Но тут спохватился я писать фронт - подключать свое же к себе же. И в этот момент я понял, насколько же это сложно, муторно и, главное, НЕУДОБНО взаимодействовать REST'ом

ЗАЧЕМ ОН НУЖЕН?? - У нас нет удобного контракта общения (eg Proto, Avro) кроме Swagger, который нужно поддерживать с обеих сторон. Да и к тому-же, сложность взаимодействия с JSONом с ОБЕИХ СТОРОН - одна постоянно маршаллит, защищается, ищет поля, в то время другая боится резких обновлений, что строчка получения поля может превратиться в что-то в роде

Во второй части мы сделали консольный чат с циклом и system prompt. Но у него был пробел: каждый запрос шёл к модели независимо, без контекста предыдущих реплик. В третьей части добавляем историю сообщений — и чат наконец начинает помнить разговор.

Когда в FastAPI-проекте появляется нормальная авторизация, код быстро начинает расползаться в стороны.

Сначала все выглядит терпимо: один Depends(get_current_user), один Depends(get_enforcer), одна ручная проверка. Потом роутов становится больше, правил доступа становится больше, и внезапно половина endpoint’ов начинает содержать не бизнес-логику, а обвязку вокруг нее.

В какой-то момент меня перестал устраивать и классический подход через dependency injection в каждом роуте, и вариант с middleware. Хотелось, чтобы правило доступа было видно прямо рядом с маршрутом, но при этом не приходилось таскать авторизацию в сигнатуры всех функций.

В итоге я собрал casbin-fastapi-decorator — тонкий слой над Casbin для FastAPI, который позволяет описывать authorization через декораторы.

Идея простая:

Всем привет!

Если вы хоть раз пытались нормально вкатиться в разработку Telegram-ботов, то почти наверняка сталкивались с одной проблемой: информации в интернете много, но она какая-то рваная. То есть где-то вам сразу дают библиотеку, заставляя писать код и даже не объяснив, как бот вообще работает.

В особых сценариях (например разработка userbot) смешивают воедино Telegram Bot API, Telegram API (да, это разные вещи!), api_id, api_hash, token, chat_id, webhook и еще десяток терминов.

А где-то вообще показывают “hello world”, который фактически-то работает, но только ты ступишь на шаг вперед, так всё начинает разваливаться, ведь понимания практически 0.

В этой статье моя цель - разобрать всё это нормально и по-человечески, объяснив как использовать Telegram Bot API для создания ботов.

Сейчас многие компании внедряют ИИ-агентов в свои процессы. И сталкиваются с проблемами. Классический пример: ИИ-агент по продажам самостоятельно пообещал клиенту скидку 50% на которую ему никто не давал разрешения. Явный провал разработчиков ИИ-агентов, хотя на прошлой неделе в демо всё работало идеально.

Мир явно разделился: одни говорят, что агенты готовы к продакшену, другие кричат что это не работает и работать не будет. Энтузиасты показывают впечатляющие демо. Чистые данные, правильные API, никаких сюрпризов. Но продакшен это другой зверь. Отчёт MIT показал, что 95% пилотов генеративного ИИ не достигают ожидаемых результатов. Модели не тупые. Инфраструктура вокруг них не готова.

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

Два месяца назад я выложил первую версию MCP для КОМПАС-3D. Реакция была предсказуемая: “круто для демо, но в реальной работе не взлетит”. Тогда они были правы.

Сейчас агент получает задачу, строит 3D-деталь, добавляет отверстия, проверяет дерево построения, сохраняет документ и возвращает скриншот. Сам.

Более того, теперь ИИ забирает на себя не только объемную геометрию, но и плоскую документальную рутину. Ему можно делегировать создание чертежа, автоматическое заполнение штампа и экспорт результата в DXF одним запросом.

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

Например:

Можно взять уже открытую деталь, спросить у неё текущее состояние через get_3d_context и узнать, что базовое тело уже создано, а в дереве висит 11 элементов. Агенту не нужно угадывать или строить всё с нуля - он понимает, на каком этапе находится модель, и сразу переходит к следующим шагам.

Можно не высчитывать координаты плоскостей вручную. Инструмент resolve_selection_3d по описанию сам находит нужную грань (например, «верхняя плоская») и возвращает её системный идентификатор. Агент просто берёт эту ссылку, ставит на неё новый эскиз и делает вырез точно там, где нужно.

Можно убедиться, что команды не просто улетели в пустоту, а реально сработали. Тул list_feature_tree_3d отдаёт агенту список шагов: базовый эскиз, выдавливание, вырез, отверстие, фаска. То есть ИИ доводит деталь до конкретной истории построения, которую вы потом можете открыть руками и проверить.

Недавно ходил в кино и, пока стоял в очереди на вход, поймал себя на мысли, что проектирую систему, которой пользуется контролер. На первый взгляд задача примитивная: есть база билетов, контролер сканирует QR, система должна проверить билет и пустить человека. Главное условие - один билет используется ровно один раз.

Я прикинул, и понял, что проблем там гораздо больше, чем кажется ..

Новая сертификация партнеров-разработчиков на Claude от Anthropic (Claude Certified Architect) не просто корпоративная бюрократия, а задокументированный чеклист современного вайб-кодера.

12 марта 2026 года Anthropic запустила свою первую техническую сертификацию — Claude Certified Architect, Foundations. Формально - это часть партнёрской программы на $100 млн. Фактически — публичный чеклист того, что теперь считается базовой грамотностью в работе с ИИ.

Когда команда пишет API, но документация живёт своей жизнью, а интеграторы часами гадают, что значит ошибка 500, — проект неизбежно тонет в хаосе. В этой описан подход, который является лучшим решением: Design‑First на основе OpenAPI.

Мы пройдём полный цикл: от проектирования спецификации до работающего Spring‑приложения с автоматической генерацией кода и централизованной обработкой ошибок.

Вы узнаете, как одна команда ./gradlew clean build может создать модели и интерфейсы, избавив вас от рутины.

Я периодически провожу технические интервью и смотрю pet-проекты кандидатов.

И почти всегда вижу одну и ту же картину:

Используется localStorage или заглушки вроде jsonplaceholder.

Я прекрасно понимаю, почему так происходит:

Открыл Postman, потыкал эндпоинты, всё ответило 200 — вряд-ли хорошее тестирование Разбираю что на самом деле нужно проверять в API, показываю примеры на Postman и Jest, и даю чеклист который можно взять и использовать прямо сейчас.

40 000+ записей без пагинации, 200 OK вместо 400 Bad Request, SQL-запросы в ответах клиенту. Собрал 10 ошибок API из реальных проектов: монолитов, микросервисов, стартапах и энтерпрайза.

Классические шины — это блокер цифровой трансформации, а не её энейблер. Рост числа сервисов, переход к микросервисной архитектуре и необходимость быстрой адаптации требуют большей гибкости и новых подходов к интеграции. Теперь связывать цифровые системы между собой необходимо в условиях постоянного роста объёма данных.

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

Привет Хабр!

Меня зовут Дмитрий Гаврин, я заместитель директора департамента «Цифровые решения» компании «Диасофт». Есть тип совещаний, которые я узнаю с первой секунды по интонации приглашения. Когда директор проекта пишет «зайди, поговорим по цифрам» - это не про то, что кто-то перевыполнил план. Это про интеграцию. Почти всегда про нее.

Делаем из простого скрипта настоящий консольный чат: цикл общения, system prompt, обработка ошибок и первые шаги к “живому” AI-приложению на Python с Ollama и LiteLLM.

Простой старт в LLM-разработке без API-ключей и облака: ставим Ollama, скачиваем модель и делаем первый вызов из Python через LiteLLM.