Claude ускорил production-код в 2 500 раз

incident.io показали редкий нормальный кейс использования ИИ в разработке: не «сделай мне стартап за вечер», а скучная, больная и дорогая оптимизация реального production-кода.

У них был рендер on-call расписаний. На бумаге звучит просто: кто сегодня дежурит, кого пейджить, когда смена. В реальности там ад из рабочих часов, оверрайдов, разных ротаций, daylight saving time и старых исторических записей.

Старый алгоритм часто просто шёл по времени шаг за шагом от стартовой даты. Иногда это означало сотни тысяч итераций, чтобы понять, кто сейчас on-call.

Команда уже пыталась ускорить это вручную. Были flame graph, бинарный поиск, фиксы в горячих местах, удаление лишних UUID, кеширование timezone. Всё помогало, но не решало главную проблему: алгоритм всё ещё делал слишком много работы.

Потом они дали Claude Opus 4.6 CPU-профили и попросили найти математически более умный способ не перебирать каждую неделю, день или час с начала расписания.

Через 20 минут Claude собрал RenderV2.

Новая версия не ползла по истории, а «перепрыгивала» сразу к нужной точке, восстанавливала правильного дежурного и считала только видимое окно. Плюс Claude сам добавил dry-run режим: старый и новый рендер работали параллельно, а все расхождения логировались.

Самое интересное: в процессе раскатки Claude нашёл баг в старом рендере, связанный с переходом на летнее время. То есть ИИ не просто ускорил код, а помог поймать ошибку, которая годами сидела в логике дат.

После недели без предупреждений incident.io полностью переключились на новый рендер.

Итог: p99 ответа schedule API упал с 2 секунд до 200 мс, а сам render method на сложных расписаниях стал примерно в 2 500 раз быстрее.

Вот это и есть настоящий AI-assisted coding.

Не вайбкодинг, не магия и не «агент всё сделал сам». А инженер с профилями, тестами, feature flag, production-телеметрией и ИИ, который помогает найти ход, до которого команда долго не доходила руками.

https://incident.io/blog/whos-on-call-how-claude-helped-us-calculate-this-2-500-x-faster

M:N concurrency - одна из причин, почему Go так хорошо чувствует себя на сетевых сервисах.

Идея простая: у вас может быть миллион маленьких задач, но это не значит, что под каждую нужен отдельный поток операционной системы. Runtime берёт много лёгких goroutine и сам распределяет их по меньшему числу реальных OS threads.

Получается схема M:N: много пользовательских задач на несколько системных потоков.

Из-за этого goroutine можно создавать тысячами и десятками тысяч без такого же дикого расхода памяти, как у обычных threads. А scheduler сам решает, кто сейчас работает, кого поставить на паузу, кого перенести на другой поток и как не дать одной задаче заблокировать весь процесс.

В статье хорошо объясняется, почему это сложнее, чем кажется. За красивым go func() скрываются work stealing, preemption, blocking syscalls, queues, stacks, parking и постоянная борьба за баланс между latency и throughput.

Для разработчика это полезно не ради теории. Когда понимаешь M:N модель, становится проще объяснить, почему одна программа летает на тысячах соединений, а другая внезапно упирается в scheduler, locks или blocking I/O.

Go выглядит простым снаружи. Но внутри его конкурентность - это очень плотный кусок runtime-инженерии.

0xkiire.com/mn-concurrency-model/

Kubernetes сам по себе ничего не решает. Сила появляется, когда начинаешь правильно его комбинировать

Именно связки инструментов превращают кластер в полноценную платформу

База, без которой никуда
K8s + Docker даёт стандарт оркестрации контейнеров
K8s + Terraform автоматизирует поднятие инфраструктуры
K8s + Helm убирает боль с деплоем и версиями
K8s + ArgoCD закрывает GitOps и делает релизы предсказуемыми

Наблюдаемость и безопасность
K8s + Prometheus + Grafana дают полный контроль над метриками
K8s + Vault решает проблему секретов без костылей
K8s + Cilium добавляет нормальную сетевую безопасность и observability
K8s + OPA позволяет внедрить policy as code и контролировать всё на уровне кластера

Трафик и масштабирование
K8s + NGINX Ingress или Envoy дают контроль над L7 трафиком
K8s + Istio превращает всё это в полноценный service mesh
K8s + KEDA добавляет event-driven scaling, без ручного тюнинга

AI и платформенная инженерия
K8s + Ollama + KServe позволяют гонять LLM-инференс в проде
K8s + Kubeflow закрывает ML пайплайны
K8s + Crossplane делает из Kubernetes основу для platform engineering

По факту Kubernetes это не инструмент, а каркас
И то, во что он превратится, полностью зависит от того, какие связки ты соберёшь

🚀 Удобная сборка с rigx для C, C++, Go и других языков

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

🚀 Основные моменты:
- Поддержка множества языков: C, C++, Go, Rust, Zig, Nim, Python.
- Сборки и тесты выполняются в песочнице, не загрязняя систему.
- Легкая конфигурация с помощью простого TOML-файла.
- Возможность параллельного выполнения тестов и интеграционных тестов.
- Кэширование выходных данных для повышения производительности.

📌 GitHub: https://github.com/unofficialtools/rigx

# MCP становится новым API-слоем для агентов

Если продуктом можно управлять через UI, REST и Terraform, то у агента тоже должен быть нормальный официальный вход. Не парсинг страниц, не хаки, а tools со схемами, типами и понятными описаниями.

Главная мысль статьи - MCP-интерфейс нужно проектировать не для человека, а для модели.

Для агента описание tool и input schema - это почти как документация и типы для разработчика. Плохое название поля, мутный enum или устаревший комментарий сразу превращаются в ошибки вызова.

Что делает Oblique:

- берёт gRPC/Protobuf как источник правды
- генерирует MCP tools
- подтягивает комментарии из proto-файлов
- помечает read-only и destructive tools
- чистит ответы от лишних полей
- прогоняет сценарии через evals

Обычный API часто возвращает много служебного шума: timestamps, metadata, внутренние поля. Для агента это лишние токены и больше шанс ошибиться. Поэтому MCP-ответы делают компактнее и ближе к задаче.

MCP - это отдельный слой продукта, где важны названия, схемы, права, компактность ответа и тесты на поведение агента.

Если продукт должен нормально работать с Claude Code, Codex и другими агентными средами, MCP постепенно становится базовой инфраструктурой.

https://oblique.security/blog/mcp/

🚀 Golang Roadmap 2026 — продвинутый курс на русском

📌 О курсе
Это бесплатный open-source roadmap на русском языке. Внутри — 19 модулей, каждый со своей теорией, практикой, бесплатными ресурсами и финальным проектом. Программа собрана так, чтобы провести вас от полного нуля до уровня Senior/Staff Go Engineer за 12–18 месяцев при темпе 10–15 часов в неделю.

Главный принцип курса — практика > видосы. Каждую тему вы закрываете кодом: пишете, ломаете, чините, рефакторите. Любой модуль завершается мини-проектом, который можно положить в портфолио.

🎯 Кому подойдёт
🐹 Новичкам в Go — даже если до этого писали только на Python/JS/PHP
🛠 Backend-разработчикам с другого стека — хотите перейти на Go
📈 Junior Go-разработчикам — нужен путь до Middle/Senior
🚀 Middle-инженерам — закрыть пробелы в архитектуре, observability, distributed
🤖 Тем, кто хочет писать AI-инфраструктуру — модуль 18 специально про это

https://github.com/Develp10/golangroadmap2026

O(1) не значит «быстро»

Одна из самых частых ошибок в алгоритмах: считать, что O(1) всегда быстрее O(n).

На практике это не так.

O(1) означает только одно: время работы не растёт вместе с размером входных данных.

Но сама операция может быть дорогой.

Например, хеш-таблица формально даёт O(1) для поиска, но если данные не в кэше CPU, один cache miss может сделать её медленнее, чем простой линейный проход по маленькому массиву.

Именно поэтому в Go, Python и даже C-библиотеках для маленьких map/таблиц иногда используют обычный linear search.

Парадоксально, но:

O(n) при n = 16 и тёплом кэше может быть быстрее, чем O(1) с холодным cache miss.

Big O описывает асимптотический рост, а не реальную скорость на маленьких данных.

📌 HyperLogLog на Go простыми словами

Redis может примерно считать уникальные значения, почти не храня сами значения.

Идея такая:

- берём строку
- считаем от неё хеш
- первые биты выбирают ячейку
- остальные биты проверяем на количество нулей подряд
- чем длиннее серия нулей, тем более редкое событие мы увидели
- редкие события намекают, что элементов прошло много

Минимальный пример на Go:

package main

import (
 "fmt"
 "hash/fnv"
 "math/bits"
)

const registersCount = 16

type HyperLogLog struct {
 registers [registersCount]uint8
}

func hash64(s string) uint64 {
 h := fnv.New64a()
 _, _ = h.Write([]byte(s))
 return h.Sum64()
}

func (hll *HyperLogLog) Add(value string) {
 hash := hash64(value)

 // первые 4 бита выбирают регистр: 2^4 = 16
 index := hash >> 60

 // остальные биты используем для поиска серии нулей
 rest := hash << 4

 // сколько нулей подряд в начале
 zeros := uint8(bits.LeadingZeros64(rest) + 1)

 if zeros > hll.registers[index] {
  hll.registers[index] = zeros
 }
}

func main() {
 hll := HyperLogLog{}

 values := []string{
  "user_1",
  "user_2",
  "user_3",
  "user_1",
  "user_2",
  "user_4",
  "user_5",
 }

 for _, v := range values {
  hll.Add(v)
 }

 fmt.Println(hll.registers)
}

Это не полноценный Redis HyperLogLog, а понятная учебная версия.

Что тут важно:

• дубликаты дают тот же хеш
• один и тот же хеш попадает в тот же регистр
• регистр хранит только максимум найденных нулей
• сами user_1, user_2, user_3 не сохраняются
• память остаётся почти постоянной

В Redis всё серьёзнее: там 16 384 регистра, аккуратная математика для оценки cardinality и поправки на маленькие и большие значения.

Morph - генератор мапперов для Go, который закрывает одну из самых скучных частей backend-разработки: перекладывание данных между похожими типами.

Типичный кейс: у вас есть protobuf-модели, доменные структуры, DTO, database-типы и API-ответы. Поля почти одинаковые, но код всё равно приходится писать руками:

func MapFromRecipeToToRecipe(source *from.Recipe) to.Recipe {
    if source == nil {
        return to.Recipe{}
    }

    var target to.Recipe
    target.ID = to.RecipeID(source.RecipeId)
    target.Name = source.Name
    target.Servings = int(source.Servings)

    return target
}

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

Morph генерирует такой код автоматически и умеет работать не только с простыми структурами.

Что поддерживает:

* structs и enums
* basic types, pointers, slices, arrays, maps
* nested structs
* concrete generic containers
* safe и настроенные type conversions
* вложенные сгенерированные мапперы
* пользовательские callables для сложной логики
* discovery готовых mapping-функций из указанных пакетов
* presets, чтобы не дублировать конфиг для типовых сценариев

Самый полезный случай - protobuf → idiomatic Go model. protoc часто генерирует не тот код, который хочется таскать по доменному слою: другие имена, другие типы, timestamp-обёртки, enum-формат, optional-поля. Morph позволяет описать правила один раз и дальше генерировать нормальные мапперы.

Запуск простой:

go install github.com/seeruk/morph/cmd/morph@latest
morph

Конфигурация живёт в morph.yaml, а сам инструмент можно использовать и как CLI, и как библиотеку внутри более сложных codegen-пайплайнов.

Хороший вариант для Go-проектов, где ручной mapping уже стал отдельным источником багов и мусорного кода.

GitHub:
https://github.com/seeruk/morph

#golang

Gortex индексирует репозитории в виде графа кода и открывает доступ к нему через CLI, MCP Server и веб-интерфейс. Это позволяет AI coding agents сокращать расход токенов до 50 раз.

* До 50 раз меньше токенов на ответ благодаря graph-native поиску.
* Заранее рассчитанный depth-3 reach index для impact analysis за доли миллисекунды.
* Одна установка автоматически настраивает все найденные AI coding agents на вашей машине.
* Доступен на macOS, Linux и Windows, релизы подписаны через Sigstore.

https://github.com/zzet/gortex

Open-source мониторинг без SaaS-привязки

CheckCle выглядит как интересная self-hosted альтернатива для мониторинга инфраструктуры, сервисов и приложений.

Проект даёт uptime-мониторинг, проверки HTTP, DNS, Ping и TCP-сервисов, распределённые региональные проверки, историю инцидентов, SSL и domain monitoring, public status pages, отчёты и алерты в Telegram, Slack, Discord, Matrix и email.

Главный плюс в том, что всё можно поднять у себя через Docker. Не нужен внешний SaaS, не нужно отдавать данные третьей стороне, не нужно платить за каждый монитор или сидеть в чужой панели.

По стеку тоже интересно: основа на Go, фронт на TypeScript, лицензия MIT. На GitHub у проекта уже около 2.7k звёзд, так что это не просто заброшенная утилита на вечер.

Подойдёт тем, кто хочет свой мини-UptimeRobot/Better Stack для VPS, pet-проектов, внутренних сервисов или небольшой команды.

Репозиторий: https://github.com/operacle/checkcle

GoPost - нативный API-клиент на Go + React через Wails, без Electron, аккаунтов и лишнего облака.

Главное:

1. около 15 МБ
2. работает офлайн
3. хранит всё plain JSON-файлами
4. можно версионировать коллекции в Git
5. есть GraphQL, WebSocket, SSE
6. импорт/экспорт .http
7. CLI-runner с JUnit для CI
8. response diff и extract переменных через JSONPath

По сути, это Postman для тех, кому нужен быстрый локальный инструмент без блоата и телеметрии.

GitHub: github.com/berksunduri/GOPost

Limen — модульная auth-библиотека для Go с подходом plugin-first.

Ядро даёт базовые интерфейсы, сессии и security primitives, а каждый способ аутентификации поставляется как отдельный Go-модуль.

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

Хороший подход для Go-сервисов, где auth хочется собирать как конструктор: минимальное ядро, отдельные провайдеры и меньше зависимостей в проде.

GitHub: https://github.com/thecodearcher/limen

#golang