Продолжаем...

Dialectic проверяет решения. Brainstorm помогает их спроектировать. Оба дают на выходе план. А дальше нужно сесть и написать код.

Задач в плане набралось на 5-6 часов. Контекст Claude деградирует достаточно быстро, ты устаёшь контролировать каждый шаг. Нужен инструмент, который возьмёт готовый план и выполнит задачи сам.

Ralphex - standalone CLI от того же umputun. Не плагин, отдельный тул для тех у кого большие лимиты.

Пишешь план в markdown со списком задач с чекбоксами. Запускаешь ralphex, указываешь файл. Дальше он сам: берёт задачу, запускает Claude Code в свежей сессии, выполняет, коммитит, берёт следующую. Каждая итерация - чистый контекст. На пятидесятой задаче модель работает так же чётко, как на первой.

Тул не простой, есть четыре фазы. Сначала выполнение, ralphex читает план, находит незакрытые чекбоксы, делает по одной задаче за итерацию. Потом ревью, Claude в отдельной сессии смотрит весь код, цикл повторяется пока есть замечания. Дальше внешний ревью через codex или кастомный инструмент. И финализация rebase, squash, тесты.

Запускал на текущем пет-проекте (Пилю аналог литкода для задач по тонкостям Go. Скоро выложу в опенсорс, бесплатно без регистрации и смс), прошел через 8 часов автономной работы.

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

Ставится через brew или go install. Детали в репозитории.

https://github.com/umputun/ralphex 🔗

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

Get Shit Done (GSD) - фреймворк, который превращает это в конвейер. Ставишь как скилл в Claude Code, и вместо "напиши мне фичу" получаешь полный цикл: обсуждение -> планирование -> исполнение -> верификация.

Под капотом 16 специализированных агентов. Один исследует кодовую базу, другой пишет план, третий выполняет задачи параллельными волнами, четвёртый проверяет результат. Каждый запускается с чистым контекстом, а это значит что на сотой задаче модель работает так же, как на первой.

Но меня зацепило другое. GSD учит тебя собой пользоваться прямо через Claude Code. Пишешь /gsd:help - получаешь гайд, дока с которой можно пообщаться. Пишешь /gsd:next - он сам определяет следующий шаг. Не нужно читать доку на 40 страниц, CLI сам ведёт по процессу. Мета-подход: AI-инструмент, который объясняет как им пользоваться через AI.

Про GSD рассказал мой хороший друг - shakhzodme.

https://github.com/gsd-build/get-shit-done 🔗

Теория против практики

Пост пролежал в черновиках с прошлого лета. Все же решился выложить. В тот период у меня случился конфликт с новым коллегой. В команде уже был устоявшийся стиль написания кода, проверенная архитектура и паттерны. Он пришел и решил все сделать по-своему.

На ревью спорил до упора. Ссылался на книги, доклады, рассказывал что это "best practices" и "так принято в командах у больших игроков". Шаг за шагом выводил меня из себя. В какой-то момент я сорвался и повысил тон. Да, проявил слабость, но эмоции прорываются - я ведь не робот.

Его аргументация строилась не на пользе для проекта, а на "так пишут" и "так делают в других компаниях". Но у каждой команды свои вводные: технологии, сроки, опыт инженеров, специфика бизнеса. То, что сработало где-то, может не подойти в конкретной реальности. То что было эффективно в Google или Amazon, у нас может навредить.

Я за изменения, если они несут реальную пользу. Но аргумент должен звучать как "это поможет нам решать задачи лучше, потому что ...", а не как "так написано в книге".

Теория без поправки на практику - красивая, но бесполезная догма.

Разработчиков заменит AI? Нет. Заменят тех, кто отказывается с ним работать.

Перед инженером никогда не стояла задача "написать код". Задача была запустить продукт, который работает быстро, надёжно и решает реальную проблему бизнеса (что бы мы не называли бизнесом). Код - один из инструментов.

Что изменилось: раньше платили за то, что ты держишь в голове тысячи строк контекста и мог с этим уживаться и строить большие системы. Сейчас это дешёвая операция. Дорогая - декомпозировать задачу, прочитать и понять сгенерированный код, критически оценить результат, взять ответственность за решение.

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

Ещё бонус: пока AI берёт на себя рутину, у тебя появляется время копать глубже в технологии, быстрее становясь профессионалом.

P.S. Бояться стоит другого - инженера, который копирует ответы из ChatGPT не читая. Вот это деградация. Но такие были и во времена Stack Overflow.

Я часто пишу про то, что за AI-агентом нужно проверять. Кто закоммитил - тот и отвечает...

Окей, а как именно проверять?

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

Второй: дать агенту закончить задачу целиком, а потом сесть и провалидировать результат. Это эффективнее. Но тут возникает вопрос: через что смотреть?

IDE покажет diff. Но я работаю в консоли. Claude Code, терминал, клавиатура. Переключаться в IDE ради ревью - это разрыв потока.

Нашёл revdiff. TUI-тулза на Go, открываешь прямо в терминале. Показывает diff с подсветкой синтаксиса, word-level изменения внутри строк, навигация по хункам. Главное можно аннотировать любую строку прямо в процессе. Нажал a на подозрительной строке, написал комментарий, пошёл дальше.

На выходе структурированный список замечаний в stdout. Его можно скормить обратно агенту как инструкцию на доработку.

revdiff HEAD~1

Одна команда и ты в ревью. Без IDE, без переключения контекста.

https://github.com/umputun/revdiff

В прошлом году я писал, что больше не читаю книги по программированию. Пока книгу пишут, технология успевает устареть. Учусь иначе: исходники, подкасты, документация.

С какихто пор практикую ещё один способ - Claude собирает мне полноценный курс с примерами кода на Go, которые можно запустить и потрогать.

Сейчас мы внедряем в проект кафку, собрал для команды такой курс. Давно ничего не писал, по этому решил выложить в опенсорс и написать об этом пост.

https://github.com/dsbasko/kafka-cookbook

Внутри основные темы: продьюсеры, консьюмеры, группы, партиции, оффсеты, идемпотентность, exactly-once, транзакции, retry, dead letter queue. Каждая тема это отдельная папка с рабочим Go-кодом, README и docker-compose.

Запускаешь, открываешь нужную папку, читаешь код, гоняешь сценарии. За пару вечеров проходишь то, на что в книге уйдёт месяц.

Главное, что материал получается под твой уровень и твой стек. Книга пишется для всех, AI пишет для тебя.

Поварская книга по Кафке... Несколько подписчиков написали, что папки на github читать неудобно, попросили сделать сайт.

Как тут отказать. В век AI это вечер-два работы и пара долларов на токены.

https://dsbasko.github.io/kafka-cookbook

Внутри всё то же: продьюсеры, консьюмеры, группы, партиции, идемпотентность, exactly-once, транзакции, retry, DLQ. Просто открыл, выбрал тему, читаешь.

Пользуйтесь :-)

В прошлом году я был на Испае. Этой весной решил повторить. Только в этот раз я со своей командой.

В общем и целом было также сложно, может даже сложнее. Но в этот раз я уже не плакал.

Наверное это прогресс…

Читаемость UUID, миф или реальность?

Смотрю на UUID в URL и морщусь: 36 символов с дефисами, красота и уродство.

/orders/550e8400-e29b-41d4-a716-446655440000

В феврале услышал в подкасте про Base32 и залип на пару вечеров. Думал, дело на пять минут: перекодировал те же 128 бит в другой алфавит, и вот тебе короткий id. Те же 16 байт, ничего не сжимается, коллизии те же. Просто другое представление.

И правда красиво выходит, 26 символов вместо 36:

/orders/AM788072KD0X99RP8HK5AH0000

Берешь Crockford-алфавит (автор который придумал JSON), а он выкинул I L O U, чтобы не путать с единицей и нулем и не собирать случайные матерные слова. Такой ID не стыдно продиктовать по телефону.

А дальше я наступил на грабли. Думал, Base32 он и есть Base32. Ага... Конечно...

Взял стандартный RFC4648 (A-Z2-7) и сломал сортировку. Значение 25 это Z, 26 это 2, а в ASCII 2 идет раньше Z. Для UUIDv7, где время в старших битах, это больно: вроде сортируешь по времени, а строки разъезжаются как попало.

Лечится сменой алфавита: Crockford или base32hex (0-9A-V), и порядок строк снова совпадает с хронологией.
Собственно, в ULID ровно так и сделано: 128 бит, 26 символов, Crockford, сортировка по времени из коробки.

Что в итоге: в стандартной либе Go этого нет, нужен свой кодек, и БД такой ID за UUID не примет. Так что либо берешь готовый ULID, либо пишешь Encode/Decode сам и не путаешь алфавиты, как я :-)

Ответ на заданный в заголовке вопрос: Скорее миф, чем реальность...

Сегодня в команде была дискуссия про конфиги.

У нас несколько сервисов, и rate limit на каждом настраивается отдельно. Сейчас их немного, но через год будет в разы больше, и крутить лимиты руками в десяти местах это боль. Проблема настоящая.

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

Главная причина вот в чём. С rate limit ещё понятно, он у всех плюс-минус одинаковый. Но у каждого сервиса свой набор конфигурации, и в общую админку всё не перенесёшь. А раз так, то половина настроек живёт в админке, половина в самом сервисе. Размазать конфигурацию одного сервиса по двум платформам это настоящий ужас. Конфиг сервиса должен лежать в одном месте, а не делиться по принципу «это успели вынести, а это нет».

Сверху ещё пара рисков. Кривой конфиг, разосланный из центра, кладёт все сервисы разом: так положили 8.5 млн машин в CrowdStrike в 2024, не баг в коде, а плохой конфиг из одной точки. Плюс единая панель стирает границы доступа: кто крутит настройки одного сервиса, технически дотянется до всех.

С самой целью всё в порядке. Проблема в реализации.

Решение: централизуй не рантайм, а управление. Конфиг лежит как код в гите рядом со своим сервисом, меняется через PR с ревью и валидацией схемы, катится пайплайном. Одно место правок на сервис, полный аудит, откат одним revert. Enforcement остаётся локально с fallback. Упал "центр", сервис живёт на последнем валидном конфиге.

Хочешь спокойно дорасти до десяти сервисов? Дай им общий стандарт конфигурации, а не общее хранилище. Стандарт масштабируется, общая база только копит проблемы.

Рубрика «Гикуем».

Немного доработал прошивку сплита. Теперь радуюсь кастомной анимацией :-)

Нет лучше озвучки…

Поварская книга, теперь по PostgreSQL.

После kafka-cookbook собрал такой же курс по PostgreSQL 18. 11 модулей, под 60 уроков: от первого коннекта из Go до транзакций и MVCC, индексов с EXPLAIN, JSONB, оконных функций и transactional outbox.

Курс для тех, кто пишет запросы, а не администрирует сервер. Бэкапов, репликации и тюнинга нет... Только то, что нужно разработчику приложений. SQL пишешь руками, типизируешь через sqlc, гоняешь на локальной песочнице: postgres:18 + Adminer в одном docker-compose.

Через все уроки проходит история выдуманной сети кофеен Brew. Модель данных та же, что и в kafka-cookbook. В финале откроешь из postgres CDC-поток, который подхватит кафка-курс. Два курса сшиты в одну киновселенную.

Сайт в этот раз поднял сразу, не дожидаясь жалоб на папки в github :-)

https://dsbasko.github.io/postgres-cookbook

Репозиторий: https://github.com/dsbasko/postgres-cookbook

Модули открываются по мере прохождения (при необходимости, из настроен можно открыть доступ ко всем модулям сразу).

Саму подачу возможно буду еще дорабатывать. Как мне показалось - чуть рваное и сухое повествование.

Пользуйтесь :-)

С этого отрезка больше всего в восторге. Другой мир…

UUID в stdlib Go, дефолтом сделали v4

Go наконец затаскивает uuid в stdlib. И сразу ставит дефолтом v4, тот самый рандомный, который размазывает вставку по индексу :-)

В апреле приняли proposal #62026. Парсер, конструкторы, всё как у google/uuid, который годами стоит почти в каждом сервисе и при этом полузаброшен. Казалось бы, радуйся.

Но uuid.New() отдаёт v4. Чистый рандом. А сортируемый v7 надо звать руками через NewV7().

Для приложения, которое пишет в Postgres, это не мелочь. Первичный ключ на v4 ложится в B-tree как попало: каждая вставка прыгает в случайную страницу, растут page split, индекс пухнет. v7 кладёт время в старшие биты, вставка идёт в хвост, локальность сохраняется. Разница на больших таблицах видна и в размере индекса, и в скорости вставки.

stdlib поставил дефолтом то, что безопаснее «вообще», а не то, что лучше для базы. Дефолты надо читать, а не доверять им :-)