HTTP-запрос закончился, а LLM ещё работает: как проектировать AI-задачи на Go
Когда пишешь обычный HTTP API на Go, использование context.Context быстро становится привычкой.Пришёл запрос, получили r.Context(), передали его в сервис, затем в репозиторий и во все внешние вызовы. Если клиент отключился или истёк таймаут, связанные операции отменяются.Для большинства backend-задач это именно то поведение, которого мы хотим.Зачем продолжать выполнять SQL-запрос, если результат уже некому возвращать? Зачем держать соединение с внешним API, если пользователь закрыл страницу?Но когда в систему добавляется LLM, эта привычная логика начинает работать не всегда так, как ожидается.
DSL позволяют надежно использовать LLM
LLM генерируют код невероятно быстро, но чтобы гарантировать, что они создают именно то, что задумано, им нужны четкие границы. Абстракции и предметно-ориентированные языки (DSL) создают надежную оболочку, которая направляет LLM с самого начала. Пример Tickloom — предметной модели и DSL для иллюстрации поведения распределенных систем — показывает, как мы можем использовать LLM в качестве партнера для итеративного создания DSL и как естественно-языковой интерфейс для его использования. Такой DSL может выступать в качестве единственного источника истины для программных систем в мире LLM.
Несколько Клодов над одним проектом: locks, handoffs и email 1982 года
Я работаю с Claude Code параллельно на трёх подписках Pro. Плюс коллеги на своих мульти-аккаунтах, часто в тех же файлах, часто в один и тот же день.Когда мне надоело каждый новый чат заново пересказывать Claude’у курс дел - я придумала handoff’ы: короткую сводку, которую сессия пишет в конце и которую следующая читает при старте.Когда на долгих проектах handoff’ов накопилось по восемьдесят штук и новая сессия тратила полчаса на «как мы сюда вообще пришли» - я придумала rollup’ы: один handoff, который сворачивает двадцать предыдущих. Цепочка rollup’ов на длинной дистанции становится летописью проекта.
Разница между параллельными и распределёнными вычислениями
Параллельные и распределённые вычисления часто ставят рядом, но это далеко не одно и то же. В новом переводе от команды Spring АйО разберем, как устроены обе модели, чем отличаются их архитектура, способы обмена данными, масштабируемость и отказоустойчивость. Статья подойдет тем, кто хочет понять, когда достаточно ресурсов одной машины, а когда без сети из нескольких узлов уже не обойтись.Введение
