Подтемы
Транскрипт
Загрузка транскрипта…
Ничего не найдено.
Уалихан вернулся к своему спору с Максом Горбадюком и понял, что они спорили про слова. Макс говорил, что для спеки нужны знания о базе и проектировании – и это верно. Уалихан же имел в виду не «спеку для LLM», а сам подход: spec-driven development, docs-first. Миша скинул статью Бриджиты Боккелер (на сайте Мартина Фаулера, цикл «Exploring Generative AI», конец 2025 года) – с ремаркой, что это не мнение самого Фаулера, он под своим брендом продвигает других авторов. Вывод: подход не новый, ему уже больше полугода.
Уалихан описал реальный проект: миграцию старого брокера Bestok (двухфазные коммиты, FTP, SQL через DFS, паутина из десятка приложений), от которого надо избавиться, потому что он выйдет из употребления. Где можно, заменяют дорогие гарантии дешевыми: вместо атомарной консистентности – eventual consistency, полумикросервисный подход. Архитектор написал SID сам плюс с помощью LLM (не «сгенерируй мне SID»), с 37+ аппендиксами (секреты, ротация, дата-модель, workflow). Из SID нарезаются слайсы и PRD. Роль LLM тут – упорядочить и централизованно презентовать знания людей, которые по 10+ лет писали под Bestok.
Spec-driven – это про human-in-the-loop: дал LLM написать кусок-слайс, посмотрел, отрефлексировал, поехал дальше; задачи бьются на подзадачи, чтобы контекст не тух. Поверх этого пишут behavior-тесты (BDD). Нынешний development loop идеологически похож, но пытается убрать человека из петли. Он работает там, где вокруг задачи можно выстроить constraints и тесты (harness): если это можно обложить однотипными тестами, запускаешь конвейер задач, который бесконечно лопатит и что-то выдает.
Ключевой тезис Павла: лупы работают в компаниях с широкой автоматизацией и хорошим менеджментом – по тем же причинам, что бизнес-трансформация. Ты не меняешь все сразу, а «выкидываешь кусок бизнеса» и пересобираешь по новым правилам. «Кровь» при этом нормальна: приходит человек, ломает старое, год-два все страдают, потом всем легче. Люди вроде Уалихана видят нарушение локального минимума, но не видят широкую картину, зачем эта неоптимальность выгодна. Отсюда миграция и переписывание становятся понятной бизнес-задачей: переучить людей, построить процессы, описать их спецификацией.
Разобрали публичный кейс переписывания продукта с Zig/Node на Rust (RAAS). Павел делал анализ: плотность покрытия тестами после перехода ухудшилась, интересно посмотреть на стабильность билдов. Много пиара: банк выпустил пост о том, как они переписали, но не назвал дату релиза и назвал не сумму, а бюджет токенов (~$200k) – потому что сумма пугает. С точки зрения бизнеса даже $200k на переписывание дешево. Рабочая схема та же, что у лупов: спеку описал тестами, тесты используешь как приемку; регрессию потом «накручиваешь», а майлстоун считаешь рабочим.
Павел вытащил забытый артефакт: тест-план – это производная спецификация на ПО, которую agile «опопоцал». А зря: тест-план полезно видеть до того, как ты позволишь агенту писать все, что хочет – это скоп видимости на релиз. У Павла был опыт с харденинг-спринтом перед релизом и тест-планом на 300-500 тестов. Отдельно – spec drift: SID это корень, из него ветвятся PRD и слайсы; если не следить за согласованностью, верхнеуровневая спецификация отстает и LLM тащит из контекста старье. Архитектура при этом – решения на 5 лет и ограничения, а не «поддержать все».
Уалихан предпочитает начинать не со спеки, а с маленького рабочего инструмента, который можно ваншотнуть. Придумал консольную утилиту с двумя функциями: разбивает Markdown на шаблон с маркерами и PO-подобный файл для перевода, переводит по параграфам через API (Google Translate / LLM), потом склеивает обратно по маркерам. Дальше это легко «раздувается»: редактор с автопереводом правок, translation memory, личный глоссарий терминов, который же можно подавать в LLM. Каждый шаг тривиальный. Проблема ровно одна – как сделать это долгоживущим: документировать решения и покрыть интеграционными тестами, чтобы LLM потом не напортачила.
Рефлексия Уалихана: он не дописывает спецификацию в начале, потому что рассчитывает, что LLM сама займется процессом – а она не займется, если не заставить. Сначала надо самому руками писать спеку и тесты («ничего не делаем без теста»), чтобы понять, где LLM ломается, и только потом автоматизировать. LLM легко придумывает лишние тесты (из пяти три тестировали пустоту) – название теста надо писать точнее. Павел предложил продавать это заказчику через воспроизводимость: гардрейлы на бюджет ($5-10 за прогон, ~10 экспериментов в $100) и понятные constraints – «получите второго джуна». Обсудили легковесные спек-лупы против «монструозной бюрократии» spec-kit; вывод – каждый потихоньку приходит к своему harness.
| Вопрос | Уалихан | Павел | Миша |
|---|---|---|---|
| «Спека для LLM» – это спецификация? | Это не спека, а подход spec-driven development; спор с Максом был про терминологию | Это spec-driven; тест-план – производная спецификация, забытая agile | «ASAP ≠ Agile»: классический Agile не запрещает потратить спринт на спецификацию |
| Human-in-the-loop или лупы без человека? | Пока держусь human-in-the-loop: сам пишу спеку, чтобы видеть, где LLM ломается | Лупы работают там, где есть широкая автоматизация и тесты-обвязка; это как трансформация бизнеса | – |
| Быстро меняться и переписывать – это хорошо? | Не верю в «всегда быстро меняться»; «кровь» терпима, но осознанно | «Кровь» для бизнеса нормальна, год-полгода приемлемо, зато закрываешь вопрос | – |
| Как сделать one-shot инструмент долгоживущим? | Документировать и покрыть интеграционными тестами, но пока не хватает дисциплины | SDLC-правила («ничего без теста»), тест-план до кода, гардрейлы на бюджет | – |
Спор оказался терминологическим: под «спекой для LLM» имеют в виду подход (docs-first, spec-driven по Фаулеру/spec-kit), а не спецификацию в строгом смысле. Сам подход не новый – это human-in-the-loop цикл: SID → слайсы → PRD, LLM пишет кусок, человек рефлексирует и правит.
Лупы работают там, где задачу можно обложить тестами и constraints (harness) и есть широкая автоматизация. На маленьких задачах это дешево: гардрейлы на бюджет ($5-10 за прогон) дают воспроизводимый результат, который можно показать заказчику как «второго джуна».
Ты «режешь» кусок процесса и пересобираешь по новым правилам; временная «кровь» и неоптимальность нормальны, если бизнес управляем. Люди, которые видят локальный минимум, не всегда видят широкую картину, зачем это выгодно – поэтому миграция становится понятной бизнес-задачей, а не только технической.
Тест-план – производная спецификация, «опопоцанная» agile; полезно видеть его до того, как агент начнет писать, как скоп видимости на релиз. Но LLM легко придумывает лишние тесты, поэтому названия надо писать точнее. SID – корень, PRD ветвятся; без согласованности LLM тащит старье (spec drift). Архитектура – это решения на 5 лет и ограничения, а не «поддержать все».
One-shot утилиту (разбить Markdown → перевести по параграфам → склеить, плюс translation memory и глоссарий) легко раздуть тривиальными шагами до продукта. Но чтобы она жила долго, нужно самому дописывать спецификацию и тесты – LLM не возьмет это на себя, пока не заставишь. Свой легковесный harness – закономерный финал этой эволюции, а не «монструозный» spec-kit.
Хотите обсудить эти темы с практикующими тимлидами?
Обсудить в Telegram