Почему API‑First уже недостаточно и что меняется, когда SDD строится на.md‑файлах и обязательном участии агентов?
В агентном SDD спецификация становится не пояснением к коду, а рабочим контекстом, из которого агент строит план, тесты и реализацию. Это ускоряет разработку — и одновременно увеличивает цену неоднозначности. Разбираем, как превратить.md из документации в управляемый контракт.
Есть особый жанр боли, знакомый всем гоферам, которые хоть раз отдавали свою HTTP‑ручку наружу: документация. Не та, что «напишите README», а честная машиночитаемая спека, по которой фронтенд сгенерирует клиент, QA — коллекцию, а API Gateway — валидацию.
// CreateUser godoc
// @Summary Create user
// @Accept json
// @Produce json
// @Param request body CreateUserRequest true "user"
// @Success 201 {object} models.User
// @Failure 400 {object} ErrorResponse
// @Router /api/v1/users [post]
func (h *UserHandler) Create(c fiber.Ctx) error { ... }
Я уже давно думал об одной вроде небольшой, но на самом деле изрядно, по крайней мере меня, доставшей backend‑проблеме.
На прошлой неделе я снова потратил полдня на то, чтобы понять, почему фронт падает после обновления бэка. Локально работало, а на стейдже ошибка. Оказалось, бэкендер переименовал поле в ответе, но не обновил документацию и не предупредил команду. Я узнал об этом только когда код упал на стейдже - вручную править ручку пришлось уже постфактум, разбираясь с ошибкой.
С этим надо было что-то делать.
Я начал использовать генерируемый API-клиент. По сути, это набор ручек (функций для запросов) и типов к ним, которые генерируются на основе открытого API - yaml-файла сваггера.
Это личный инженерный эксперимент. Не релиз, не продуктовая статья и не попытка кого-то убедить. Мне просто захотелось проверить руками, насколько российские модели на примере GigaChat готовы к агентной работе в современной среде разработки.
Мне давно интересна разработка при помощи агентов. Обычный чат с моделью — это уже понятный сценарий: спросил, получил ответ, пошёл дальше. Агентный режим — следующий шаг. Модель там не просто пишет текст: она получает историю, вызывает инструменты, читает результаты, продолжает диалог, стримит ответ, иногда работает с картинками и живёт внутри реального проекта.
Короткая суть. Некоторые команды до сих пор хранят «правду» об API в трёх несовместимых местах: в голове бэкендера, в страничке Confluence, которая устарела ещё прошлой весной, и в реальном JSON, который прилетает с прода. Эти три источника постоянно расходятся, и расплачиваются за это все — особенно клиентские разработчики. OpenAPI — это способ свести правду к одному файлу-контракту, понятному и человеку, и машине. В статье я разбираю, зачем это нужно, почему кодогенерация — далеко не главная причина, но при этом проговариваю, во что внедрение обойдётся бэкенду, и где у подхода реальные слабые места.
За последние несколько лет для вызова внешних API в каждом втором (если не первом) проекте я видел одну и ту же картину:
RestTemplate
или FeignClient
Причём Feign почти всегда шёл в связке с OpenAPI: сгенерировали клиент, получили интерфейсы и не думаем о реализации. Удобно, красиво, привычно.
Но потом в Spring появился нативный декларативный HttpClient, который работает поверх RestClient / WebClient
И у меня возник вопрос: а можно ли им заменить Feign, не потеряв удобство?
Спойлер: да, можно и будет даже удобнее.
Идея, на самом деле, очень простая.
Читать полностью »Привет!
Представим ситуацию: идет тяжёлый спринт, вы выполнили кучу задач, написали тонну нового функционала, готовитесь к релизу и вдруг обнаруживайте, что часть фич перестала работать! Идёте разбираться и обнаруживайте, что оказывается бэкендер Вася в последний момент решил переименовать поля в json-е, а вам об этом не сказал!
Ситуация образная, но позволяет быстро обрисовать одну из болей во время разработки. В этой статье я бы хотел рассказать об одном из вариантов её решения в коде с помощью подхода Единого источника истины(Single source of truth).
Команда AI for Devs подготовила перевод статьи о том, как меняется программирование с приходом ИИ. Автор делится опытом: в его проекте уже 90% кода пишется агентами, но вся ответственность за архитектуру и продакшен остаётся на нём. По мнению автора, это не далёкий прогноз — это уже реальность, просто распределённая неравномерно.
«Я думаю, что через три-шесть месяцев мы придём к тому, что ИИ будет писать 90% кода. А ещё через год — к миру, где ИИ пишет фактически весь код».
