С Новым Годом и добро пожаловать в Gas Town!

Gas Town - это новый взгляд на IDE для 2026 года. Gas Town помогает вам справиться с рутиной запуска множества экземпляров Claude Code. Вещи теряются, трудно отследить, кто чем занимается, и так далее. Gas Town помогает со всей этой рутиной и позволяет вам сосредоточиться на том, над чем работают ваши Claude Code.

В этом посте "Claude Code" означает "Claude Code и все его идентичные конкуренты", то есть Codex, Gemini CLI, Amp, Amazon Q-developer CLI, бла-бла-бла, потому что именно этим они и являются. Клоны. Индустрия - это постыдная детская футбольная команда, гоняющаяся за форм-фактором CLI Claude Code образца 2025 года, вместо того чтобы создавать то, что будет дальше.

Я пошел вперед и создал то, что будет дальше. Сначала я предсказал это еще в марте в статье Месть начинающего разработчика. Я предсказал, что кто-то свяжет верблюдов Claude Code вместе в колесницы, и это именно то, что я сделал с Gas Town. Я приручил их настолько, что вы можете продуктивно использовать 20–30 штук одновременно на постоянной основе.

Gas Town имеет свое мнение - во многом как Kubernetes или Temporal, на которые Gas Town похож, по крайней мере, если прищуриться так сильно, что глаза почти полностью закроются. Я включу сравнения как с k8s, так и с Temporal в конце этого поста. Немного удивительно, насколько они похожи, несмотря на радикально разные основы.

Но сравнение должно служить предупреждением: Gas Town сложен. Не потому, что я этого хотел, а потому, что мне приходилось добавлять компоненты до тех пор, пока он не стал самодостаточной машиной. И те части, которые у него теперь есть, ну, они выглядят так, как будто Kubernetes спарился с Temporal, и у них родился очень уродливый ребенок.

Но это работает! Gas Town решает проблему MAKER (Ханойская башня из 20 дисков) вообще элементарно. Просто генерируешь по формуле "цепочку" на миллион шагов - и готово. Вчера ради интереса прогнал 10 дисков за несколько минут: доказал, что тысяча шагов для нас - это не проблема, хотя в статье MAKER говорится, что нейронки ломаются уже через несколько сотен. На 20 дисков закладываю часов 30. На этом мой импровизированный TED Talk окончен.

Все это обретет полный смысл, если вы дочитаете до конца следующих 23 страниц.

Beads продолжает набирать обороты. Когда мои старые друзья начинают натыкаться на него независимо друг от друга, я понимаю, что проект становится вирусным.

Beads занимает совершенно уникальную нишу. Все сосредоточены на создании инструментов планирования, в то время как Beads - это инструмент исполнения. Это всё равно что поставить вашего ИИ-агента на отлично смазанные лыжи. Возможно, лучшим названием было бы Agents on Rails («Агенты на рельсах»). Но название «Beads» (Бусины) хорошо передает идею того, что инструмент сфокусирован исключительно на отслеживании (трекинге) и ни на чем другом: маленькое имя для маленькой системы.

Сейчас, спустя почти 6 недель своего пути, Beads стал намного, намного стабильнее. Это была безумная гонка, порой менялось по 50 тысяч строк кода в день. И никто из нас, контрибьюторов, даже не просматривает этот код. Он на 100% написан ИИ («vibe coded»), сейчас в нем 130 тысяч строк на Go, и примерно половина - это тесты. Десятки тысяч людей используют его в своих повседневных рабочих процессах. Люди говорят мне, что им это так нравится, что они используют его даже для личных списков дел (TODO). А другие направо и налево встраивают его в более крупные оркестраторы. Это также потрясающий строительный блок.

Мы сохранили небольшой объем функционала. Прислушиваясь к мнению сообщества, я отвергаю всё, что не должно быть частью ядра Beads. Поэтому у Beads нет пользовательского интерфейса (UI), но есть множество примеров UI, которые люди создали как проекты «для души» (passion projects). У нас их уже как минимум четыре или пять. Мой приятель и соавтор Джин Ким даже создал свой собственный UI для Beads на Java Swing! Он был так взволнован, когда показывал мне его. И это действительно было очень круто.

Итак, никакого UI, и у Beads также нет системы планирования. Он не для этого. Но он отлично интегрируется с любой системой планирования - просто составьте план, а затем попросите агента создать в Beads эпики и задачи (issues) для этой работы. После того как эпики будут готовы, вы можете натравить на них любое количество агентов, чтобы они их «разгребли».

Последняя большая категория, которую люди постоянно пытаются втиснуть в Beads, - это оркестрация. Мы знаем, что оркестрация неизбежна. И есть соблазн сделать Beads более активным; сегодня он довольно пассивен и ожидает, что Агент будет использовать его как инструмент. Но люди хотят большего. И я их понимаю. Однако этому не место в Beads.

Я занимался вайб-кодингом (vibe coding) как одержимый сорок дней и сорок ночей. Это долгая история, поэтому я резюмирую её в этих трех картинках.

Слева, 3 недели назад: я вайб-кожу на пляже за ужином в Кабо-Сан-Лукас, Мексика, с неподражаемым Торстеном Боллом, нашим приятелем Мэттом Манелой и другими коллегами из Sourcegraph на корпоративном выезде. Кто-то сделал это фото, потому что я отказывался убрать компьютер.

В центре, 2 недели назад: фотография, на которой я фотографирую сам себя, пока еду на скорости 100 км/ч (60 миль/ч) по шоссе в Беллингем, чтобы забрать гитары, занимаясь голосовым вайб-кодингом всю дорогу туда и обратно. Глупо и чертовски опасно. Мне было плевать. Застрял в пробке на несколько часов. Всё равно плевать. Я упоминал, что это вызывает привыкание? Вайб-кодинг вызывает привыкание.

На последнем кадре: мы с женой в торговом центре на прошлой неделе, наслаждаемся приятным днем с кофе, наблюдаем за людьми и вайб-кодим вместе с Моцартом (на фото он в своей любимой сумке). Лин прячется за компьютером - так я получил разрешение руководства на публикацию снимка.

Я никуда не хожу и не делаю ничего, даже не сплю, без своего ноутбука. Ну, разве что когда бегаю - там я ещё не совсем раскусил, как вайб-кодить. Но я близок. Это тема для отдельного поста, но у меня наконец-то работают агенты на GCP с Terraform и Tailscale. Так что скоро я смогу вайб-кодить и с телефона.

Агенты никогда не должны отдыхать.

Разработка с ИИ-ассистентами часто напоминает поездку с талантливым, но забывчивым штурманом. Он отлично знает карту (код), но постоянно забывает пункт назначения (бизнес-задачу) и пройденный маршрут (контекст).

Мы привыкли работать в режиме "Prompt & Pray": написали длинный промпт, получили код, внесли правки. Но на дистанции сложной фичи контекст размывается. Агент начинает галлюцинировать, терять детали или переписывать одно и то же. Проблема не в модели, а в отсутствии долгосрочной памяти и четкого контракта.

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

OpenSpec - чтобы зафиксировать "что и зачем мы делаем" (Spec-Driven Development).

Beads - чтобы управлять тем, "как и в каком порядке" это выполнять (граф задач).

Cursor - как среду, которая связывает их воедино.

Если вы устали от того, что ИИ теряет нить повествования на середине рефакторинга, этот подход для вас.

Вы тоже устали? Устали объяснять ChatGPT структуру вашего проекта в десятый раз? Устали от того, что Cursor "съедает" ваши лимиты? Платные подписки нужны ради их мощных моделей, но обидно тратить драгоценные токены на бесконечные уточнения контекста.

Встречайте OpenSpec - конец vibe-кодинга. Это инструмент, который не просто "еще одна обертка над GPT", а смена парадигмы. Мы переходим от AI-чатов к Spec-Driven Development.

Spec Kit - это один из самых амбициозных фреймворков для наведения порядка в разработке с использованием ИИ. В нашем предыдущем посте о spec driven development мы обсуждали его потенциал для закрытия давних пробелов в рабочих процессах с ИИ-ассистентами за счет обеспечения соблюдения стандартов проекта, контекста на уровне функций, принудительной декомпозиции для управляемого объема работ и контрольных этапов (review gates) для контроля качества.

Но исполнение - это то, где теория сталкивается с сопротивлением. Документация Spec Kit - это сильная отправная точка, с понятными видео, подробными руководствами и предписывающими шагами, которые позволяют развернуть его за считанные часы. Сложности начинаются, когда вы покидаете «песочницу». Подобно примерам Animal → Dog → Labrador в учебниках по ООП, примеры учат синтаксису, а не промышленной разработке программного обеспечения.

Пробел заключается не в документации, а в контексте и реальной экспертизе. Чистые примеры прекрасно работают для greenfield-проектов (проектов с нуля), но большинство команд работают с существующими (brownfield) кодовыми базами, сформированными месяцами эволюционирующих решений, компромиссами разработчиков, конкурирующими паттернами и не подлежащими обсуждению стандартами качества.

Этот пост отражает наш путь через эти испытания. Это не отполированная история успеха, а честный рассказ о том, что сработало, что нет, и как мы заставили Spec Kit работать в живой производственной системе, где компромиссы в качестве были недопустимы.

Почему команды отказываются от подхода «сначала код, потом исправления», когда ИИ ускоряет поставку сверх всякого контроля? Spec-Driven Development (разработка на основе спецификаций) представляет шестиэтапную модель, которая переносит архитектурные решения, ограничения и ясность на более ранние стадии (upstream). Узнайте, как это улучшает качество выходного результата, сокращает циклы очистки кода и позволяет AI-агентам работать согласованно в рамках мультисервисных систем.

Поставка программного обеспечения была ориентирована на реализацию большую часть своего существования: команды открывали редактор, пробегали глазами бриф спринта и начинали писать код. Этот рабочий процесс имел смысл, когда основными создателями были люди, репозитории развивались медленно, а конвейеры релизов были линейными и предсказуемыми. Теперь AI-агенты, такие как Copilot, Cursor и Windsurf, генерируют код быстрее, чем успевают реагировать архитектура, управление (governance) и интеграция. Код перескакивает от бэкенд-логики к конфигурациям инфраструктуры и CI/CD за часы, на что раньше уходили месяцы.

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

Модель, ориентированная на спецификации (spec-first), обращает этот коллапс вспять с помощью живых, исполняемых артефактов. Вместо того чтобы код вел процесс, спецификации становятся якорем (и источником), на основе которого действуют ИИ и люди. Они содержат решения о структуре, библиотеках, паттернах, соответствии требованиям и интеграции еще до того, как будет сгенерирована хоть одна функция.

Когда поведение меняется, команды обновляют спецификацию, и все последующие выходные данные следуют за ней. Поломки также устраняются путем обновления исходной спецификации, а не латанием симптомов в разных файлах. Чтобы увидеть, как Spec-Driven Development меняет темп и качество разработки с использованием ИИ, давайте разберем, что это такое на самом деле.

Все уже слышали, что в Go 1.25 завезли новый экспериментальный сборщик мусора - Green Tea GC. Теории о том, как он работает, много (и в том числе на Хабре).

Но когда мы с коллегой попытались просто включить GOEXPERIMENT=greenteagc на наших обычных бенчмарках, нас ждало разочарование: результаты были то чуть лучше, то чуть хуже, то вообще одинаковые. Сплошная лотерея.

Мы задались целью: найти условия, в которых Green Tea GC побеждает безоговорочно. Не на 1-2% в пределах погрешности, а так, чтобы график "пробил потолок". И у нас получилось добиться стабильного ускорения пауз GC на 40-50%.

Хотя экосистема LLM в основном ориентирована на Python, мы нашли Go исключительно подходящим для производственных развертываний. Наша инфраструктура на базе Go обрабатывает миллионы ежемесячных запросов LLM с минимальной настройкой производительности. Помимо хорошо документированных преимуществ Go (см. отличное изложение Роба Пайка о преимуществах Go), три возможности оказались особенно ценными для нагрузок LLM: статическая проверка типов для обработки выходных данных модели, горутины для управления параллельными вызовами API и интерфейсы для построения составных конвейеров ответов. Вот как мы реализовали каждую из них в нашем производственном стеке.

После просмотра подкаста (Коняев - чума!) я вроде понял, в чём минус «ИИ», и провёл небольшое исследование этого вопроса. Ниже - обзорная статья, которая охватывает фундаментальные ограничения современных LLM через призму интерполяции и энтропии, технологические прорывы 2025 года, рыночную динамику ключевых игроков (Google, Broadcom, Intel), экономику вычислений и революционные перспективы развития ИИ.

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

Чтобы понять, что решает synctest, мы должны сначала рассмотреть основную проблему: недетерминизм в конкурентных тестах.

func TestSharedValue(t *testing.T) {
    var shared atomic.Int64
    go func() {
        shared.Store(1)
        time.Sleep(1 * time.Microsecond)
        shared.Store(2)
    }()

    // Проверяем общее значение через 5 микросекунд
    time.Sleep(5 * time.Microsecond)
    if shared.Load() != 2 {
        t.Errorf("shared = %d, want 2", shared.Load())
    }
}

Этот тест запускает горутину, которая изменяет общую переменную. Она устанавливает shared в 1, спит 1 микросекунду, а затем устанавливает её в 2.

Тем временем основная функция теста ждёт 5 микросекунд перед проверкой того, достигло ли shared значения 2. На первый взгляд кажется, что этот тест должен всегда проходить. В конце концов, 5 микросекунд должно быть достаточно времени для завершения выполнения горутины.

Однако...

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

И если вы сталкивались на больших legacy-проектах с хаосом в обработке и логировании ошибок — когда одна и та же ошибка дублируется в логах на каждом уровне, когда непонятно где обрабатывать ошибку, а где передавать дальше, когда тесты превращаются в кромешный ад из-за необходимости мокать каждый возможный путь ошибки — тогда возможно пригодится то, что я хочу предложить.

В эпоху становления асинхронного программирования JavaScript-разработчики столкнулись с явлением, получившим название "callback-hell" — бесконечной вложенностью функций обратного вызова. Хотя с точки зрения функционального программирования функции являются полноправными гражданами первого класса, принцип "всё хорошо в меру" никто не отменял. Появление Promise и механизма async/await стало спасительным решением этой проблемы.

В мире Go у нас есть более элегантные инструменты — каналы и горутины. Однако совершенству нет предела, и здесь нас поджидает другая ловушка — "error-hell". Новички в Golang часто приходят в недоумение от того, что идиомы языка требуют обработки ошибок буквально на каждом шагу.

Федеративный GraphQL бесценен для предприятий, потому что он создает единый, логический уровень API - федеративный граф, - который соединяет разрозненные источники данных, служа единым представлением о ландшафте данных организации.

Сервисы могут обеспечивать взаимодействие, но при этом оставаться независимыми и использовать технологии, с которыми они знакомы, благодаря общей и стандартизированной схеме GraphQL, и новые функции/сервисы могут быть легко интегрированы в этот объединенный граф без нарушения существующих систем. В двух словах: надежная, адаптивная архитектура предприятия, которая может развиваться для удовлетворения потребностей.

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

С роутером, совместимым с Federation V1/V2, который изначально поддерживает подписки, как WunderGraph Cosmo Router, это становится намного проще. Что более важно, с Cosmo вы можете делать это с использованием открытого программного обеспечения, совместимого с OSI, которое позволяет вам самостоятельно размещать и сохранять полную автономию над вашими данными.

Мы рассмотрим, что нового предлагает Cosmo Router в отношении подписок на федеративном GraphQL; но сначала мы расскажем о подписках на GraphQL.

Предприятия имеют разнообразные зависимости от данных — внутренние микросервисы со специализированными доменами данных, устаревшие системы с собственными форматами данных, а также сторонние API и приложения SaaS со своими уникальными моделями данных и конечными точками.

TL;DR: разные (и часто устаревшие) технологии, которые нужно как-то объединить.

Federated GraphQL выделился как главное решение для такого объединения в сфере предприятий, и Router (или Gateway) в Federation действует как ключевой элемент, который связывает все эти разрозненные источники данных вместе, делая их доступными через единственный, согласованный API, сохраняя при этом адаптивность. Это, на самом деле, ключ к тому, как Federated GraphQL позволяет создавать масштабируемые и модульные архитектуры.

Сегодня мы рассмотрим высокопроизводительный, открытый, совместимый с Federation V1/V2 Router от WunderGraph Cosmo. Мы расскажем, что он делает, почему он так важен для стека Cosmo, как вы можете разместить его самостоятельно, а также настроить и расширить его с помощью своего собственного кода на Go.

Мы недавно объявили, что WunderGraph теперь полностью открыт в исходном коде. Сегодня мы хотели бы объяснить, как вы можете использовать нашу платформу для разработчиков API, чтобы добавить кэширование на уровне Edge в ваши GraphQL API, не привязывая себя к конкретному поставщику.

WunderGraph предоставляет подписки GraphQL через SSE (Server-Sent Events) или Fetch (в качестве резервного варианта). В этом посте объясняется, почему мы решили выбрать этот подход и считаем его лучше, чем использование WebSockets.

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

Мы покажем вам, как интегрировать 8 сервисов: SpaceX GraphQL, 4x GraphQL с использованием Apollo Federation, REST API с использованием OpenAPI Specification, API на основе PostgreSQL и API на основе Planetscale-Vitess (MySQL) всего несколькими строками кода, полностью автоматически, без каких-либо конфликтов.

При реализации Cosmo Router, open-source замена Apollo Router, мы столкнулись с проблемой поддержания нашего кода для решения проблемы N+1. Реализация маршрутизатора для федеративных служб GraphQL в значительной степени зависит от возможности группировать вложенные запросы GraphQL для сокращения числа запросов к подграфам.

Чтобы решить эту проблему, мы разработали новый алгоритм, который решает проблему N+1 более эффективно и проще для поддержания, чем наше предыдущее решение, которое было основано на шаблоне DataLoader, обычно используемом в сообществе GraphQL. Вместо разрешения сначала по глубине, мы загружаем данные сначала по ширине, что позволяет нам сократить параллелизм с O(N^2) до O(1) и улучшить производительность до 5 раз, сокращая сложность кода.

Если вы заинтересованы в проверке кода, вы можете найти его на GitHub.

Я также провел лекцию на эту тему на GraphQL Conf 2023, которую вы можете посмотреть здесь.