Почему JSON Schema не делает ответ LLM надёжным
После того как LLM начинает возвращать structured output, интеграция внезапно становится очень похожей на обычный backend.Больше не нужно вырезать JSON из Markdown, надеяться, что модель не добавит перед ним «Конечно, вот результат», чинить потерянные кавычки и повторять запрос из-за случайной запятой.Мы описываем схему, модель возвращает объект, десериализуем его в Go-структуру — и кажется, что самая неприятная часть интеграции закончилась.Например:type Invoice struct { Number string `json:"number"` Currency string `json:"currency"` Total int64 `json:"total"` }На выходе получаем:{ "number": "INV-2026-1842", "currency": "USD", "total": 148000 }JSON валиден.
Почему fallback между LLM может сломать семантику ответа
Когда проектируешь обычный backend, fallback обычно воспринимается как довольно понятный механизм.Есть основной upstream. Если он недоступен, переключаемся на резервный. Если один pod умер, запрос обслужит другой. Если один PostgreSQL read replica недоступен, читаем с другой. Если основной endpoint партнёра отвечает ошибкой, можно попробовать резервный.В большинстве таких случаев мы предполагаем, что резервный исполнитель реализует тот же контракт.С LLM это предположение начинает ломаться.Две модели могут принимать один и тот же JSON, возвращать JSON по одной и той же схеме и при этом фактически выполнять задачу по-разному.
xk6-sip: SIP-телефония как код
Парадокс 2026 годаНа дворе 2026 год. Веб-сервисы тестируют облачные оркестраторы: тысячи виртуальных пользователей поднимаются из пайплайна, метрики падают в Prometheus, деградации ловит алерт до того, как их заметит клиент. А в телефонии, которая до сих пор держит колл-центры, банки, скорую помощь и диспетчерские, релиз АТС часто проверяют так же, как двадцать лет назад: тестировщик берёт два телефона и звонит сам себе. Нагрузку дают SIPp со сценариями в XML, которые проверяют сигнализацию, но не слышат, прошёл ли голос.xk6-sip — моя попытка закрыть этот разрыв. Это расширение k6/x/sip для Grafana k6
Go сделали скучным — и после нейросетей это выстрелило
Go двадцать лет дразнили языком для дураков. Без дженериков, без перегрузок, без нормальных перечислений, без магии. Синтаксис учится за выходные, выразительность — на уровне табуретки.А теперь смотрим на 2026 год. Индустрия побежала писать AI-агентов и гейтвеи — и пишет их на Go или Rust. Нейронки генерируют код на Go лучше, чем почти на любом другом языке, потому что Go читается. Можно сказать, что язык оказался настолько тупым, чтобы снять пороги входа для LLM. И это, возможно, оказалось самой дальновидной ставкой в истории языков программирования.
Почему LLMProvider недостаточно: проектируем AI Gateway для SaaS на Go
Когда начинаешь делать AI-фичу в backend-приложении, первая архитектурная идея обычно выглядит очень здраво: спрятать конкретного провайдера за интерфейсом.Что-то вроде:type LLMProvider interface { Generate(ctx context.Context, req Request) (Response, error) }Сегодня за ним OpenAI-compatible API, завтра другой провайдер, послезавтра локальная модель. Код бизнес-логики от конкретного SDK не зависит, значит архитектурная задача вроде бы решена.
Почему юридический AI‑сервис нельзя строить как обычный чат: проектируем case‑first SaaS на Go
Несколько месяцев назад мне понадобилось заключить договор с водоканалом. Казалось бы, обычная бюрократическая задача: отправил документы, дождался ответа, подписал договор. На практике всё оказалось значительно веселее — ответа долго не было, сроки шли, а что делать дальше, было не совсем понятно.Юриста у меня не было, зато был AI. Я загрузил документы, описал ситуацию и начал разбираться, какие вообще есть варианты дальнейших действий. В итоге с помощью AI подготовил несколько обращений и жалоб, после чего ситуация сдвинулась с места и договор со мной всё‑таки заключили.
Компилятор как первый ревьюер: петля верификации Go‑кода, который написал агент
Год назад мой типичный пулл‑реквест писался руками часа три и ревьюился минут двадцать. Сейчас четыреста строк агент выдаёт за минуту, а ревью того же дифа занимает час: приходится вычитывать уверенно написанный чужой код, в котором ошибка выглядит ровно так же убедительно, как правильное решение. Узкое место переехало с набора кода на его проверку, и усилием воли оно не расширяется.В августе у Google вышел текст о том, почему Go хорошо подходит для разработки с агентами
gitTalk: когда лень вспоминать команды для гита
Всем привет, в этой статье я хочу написать про инструмент, который может быть полезным многим новичкам и людям которым не нравится синтаксис гита.Суть проекта:Проект был создан ради того чтобы вопервых заполнить моё портфолио и во вторых - исправить мою забывчивость в синтаксисе гита, т.к я иногда забываю команды для него, что замедляет мой прогрессЦели проекта: Сделать лёгким и удобным для использованияСделать лёгким для правки его кодаПостараться не облажаться
Как я делал текстовую игру для веба
Привет, Хабр! Меня зовут Костя, я десять лет занимаюсь коммерческой Android-разработкой. Давно хотелось попробовать себя в вебе, а эксперименты с LLM давали некоторую уверенность в том, что по крайней мере есть шанс написать агентами поддерживаемый код и задеплоить.Что же можно сделать? Конечно тамагочи! Текстовая браузерная игра: герой живёт в мире мрачного будущего. Непрямое управление, возможность предлагать миссии, а также тюнинг предпочтений героя. Эдакий Годвилль, но на новый лад.ОглавлениеКак это создавалось Что может делать игрок
