Подтемы
Транскрипт
Загрузка транскрипта…
Ничего не найдено.
Разговор начали с терминологии спек-флоу. Уалихан развернул структуру рабочей единицы – «слайса»: PRD (in scope, out of scope, риски, constraints), ADL/ADR (Architecture Decision Log с маркированными решениями вроде «не используем поле image в SQL Server»), clarifications, data model, task index с зависимостями задач и планами, которые потом выполняет «какой-нибудь сонет». Его вывод: это не спецификация, а детальный план работ – и называть это «спекой» значит подменять понятие. Настоящая спецификация ловит грубую логическую ошибку до реализации, потому что требует цельного понимания системы, а не патчинга.
Ключевая ось. Для Уалихана система – цельное собрание живых взаимосвязанных процессов, и «патчинг» (проектирование модулями по кусочкам) ведет к «каше и лапше». Контраргумент: патчинг – рабочая схема, многие системы так дорастали до объема, а хай-левел-подход (SID сверху вниз до endpoint) тоже рабочий. Отдельный тезис: LLM не умеет абстракцию – спека для нее слишком абстрактна, ей нужно предметное и суженный контекст. Отсюда вопрос, держать ли в разработке людей, которые видят систему целиком, или разводить роли на «архитекторов» и «исполнителей».
Уалихан описал свою модель: маленькие команды, где каждый «съел собаку» на своем компоненте и отвечает за него; планирование скидывается на внешний мир (реагирование на заказчика), на себе – только polisy-making. Тезис «незаменимых нет»: если бизнес экономил на процессах и экспертизе, он заплатит 3x за болезнь или уход человека – но это риски заказчика, а не исполнителя. Вывод для карьеры: если тянет к сложной технической работе, не иди в аутсорс и бизнес-разработку, где люди «на расход» – иди сразу в компании, которые делают инструменты.
Прагматичный взгляд Вадима и других: даже если ты все знаешь сам, LLM полезна как аудитор – проходит по чек-листу, задает вопросы по темам, гоняет дип-ресерч по конкурентам и готовым решениям (по публичке, быстро, с табличками) и работает как критик, вскрывая подводные камни. Бонус для бизнеса – артефакт с эвиденсами: работа видима и прозрачна, feasibility, частые мелкие PR-ы, каждая таска двигается по борде «в реальном времени». Уалихан признал ценность видимости, но назвал это не аргументом: скорость сама по себе вредна, у человека фиксированное число качественных решений в день.
Самая радикальная идея. По аналогии с переходом на компиляторы и ООП (никто не смотрит на машинный код) – приемку описывают интеграционными тестами, а как оно реализовано, отдают на откуп LLM. Раз LLM вероятностна, надо сузить контекст так, чтобы она почти детерминированно проходила тесты, которые не пропускают неправильное. Ценность смещается от написания кода к бизнес-экспертизе и экспертизе тестирования; программиста в пределе убирают. Оговорки: работает для несложных, непроцессных систем и поверх готовой платформы; на greenfield и многопроцессных системах все равно нужны архитекторы-программисты.
Практика работы с агентами. Главное «заблуждение»: субагенты не жрут токены, а экономят – каждое новое сообщение в большом контексте тащит весь миллион токенов и дорожает, а изолированный субагент работает на 30 тысячах; кэш дешевле, но изоляция все равно выгоднее и повышает качество. Практик выходил в 80% «паровоза» на 30–40 параллельных субагентах, отдавая основному контексту Opus 4.8 (1M), а субагентам – модель попроще. Дальше: план-мод плюс документация на каждый merge request, скиллы как накопленная экспертиза проекта, которую агент переписывает сам, эволюционные алгоритмы для улучшения промптов по тестам, граф кодовой базы для поиска. Fable дал на ~30% больше edge-кейсов, чем Opus 4.8, но «жрет дохрена».
Переход ко второй теме. Уалихан вернулся к переводам после паузы – и ChatGPT стал переводить заметно хуже: вольничает, дописывает фразы, разбивает на лишние параграфы. Его процесс ручной: переводит по 2–3 параграфа, черновик, отлежка на день-два, потом внимательная вычитка с оригиналом перед глазами – и именно вычитка, а не перевод, самое ценное и неавтоматизируемое, особенно в технических и исторических текстах. Консенсус по моделям: для казахского/украинского/русского лучше всего GPT (fine-tuned под эти языки), Google Translate выше DeepL, а «свежие» модели деградируют. Fine-tuning решил бы, но дорого (~$3k за итерацию) и уже не везде доступен.
Уалихан развернул больную тему: перевод через Google Translate в ресурсные файлы – это не локализация, а «compliance-галочка», болезнь индустрии, под которую заточено много фреймворков. Настоящая локализация – процесс: контекст для переводчика (на каком экране какой ключ), консолидация названий, синхронизация переводчиков и разработчиков, отдельные тестировщики-носители языка. Инструменты: Crowdin как лучшая платформа процесса, JetBrains-бандлы с параллельным показом нескольких переводов, идея связки бандлов с Figma, чтобы переводчик «как в тиндере» вычитывал варианты прямо на макете. Рекомендация: делать мультиязычность в «день 0», иначе перевод превращается во второй проект.
| Вопрос | Уалихан | Андрей | Вадим | Павел |
|---|---|---|---|---|
| «Спека для LLM» – это спецификация? | Детальный план работ, а не спецификация – подмена понятий | LLM – это harness; настоящую спеку пишешь с экспертом, а не «LLM, напиши спеку» | Не важен термин – LLM как чек-лист и evidence-артефакт для бизнеса | «Спека для LLM» ≠ спека; это ближе к Rational Unified Process, чем к Agile |
| Отказаться от программиста, оставив бизнес + тесты? | Только для несложных, непроцессных систем; иначе нужны архитекторы | Сузить контекст и обложить интеграционными тестами – приемка детерминирована | Да, если все покрыть тестами – ценность в бизнес- и тест-экспертизе | – |
| Субагенты – это дорого по токенам? | – | Наоборот дешевле: изоляция контекста экономит против гонки миллиона токенов | 30–40 субагентов параллельно, минимум общения между ними – дешево и качественнее | – |
| LLM заменит ручной перевод? | Нет – вычитку, нюансы, тональность не автоматизировать; руками надежнее | – | Дробить по параграфам, логировать правки, векторная база – можно приблизить | Дело в fine-tuning под язык: GPT силен там, где его дообучали |
Слайс из PRD, ADR, data model и task index – рабочая и удобная штука, но это детальный план работ, а не спецификация в строгом смысле. Настоящая спецификация ловит грубую логическую ошибку до реализации, потому что требует цельного понимания системы. Называть план спекой – удобная, но подмена понятий.
Спека для модели слишком абстрактна; она работает на предметном материале и коротком контексте. Отсюда практический вывод: и в разработке, и в переводе задачу дробят на мелкие единицы, а контекст изолируют – так меньше шанс ошибки.
Если приемку описать интеграционными тестами и сузить контекст, реализацию можно отдать LLM, а ценность уходит в бизнес-экспертизу и экспертизу тестирования. Но это работает для несложных, непроцессных систем и поверх готовой платформы – на greenfield и многопроцессных системах архитектор-программист никуда не девается.
Большой контекст дорожает с каждым сообщением, потому что тащит весь объем; изолированный субагент на 30 тысячах токенов дешевле кэша и точнее. Правило – минимизировать общение между агентами и отдавать им итоговый результат, а не переписку.
Вычитка с оригиналом перед глазами не автоматизируется, особенно в технических и исторических текстах; лучшая модель – та, что была fine-tuned под целевой язык. А локализация приложения – процесс с контекстом ключей, консолидацией и носителями-тестировщиками, который надо закладывать в «день 0», иначе получаешь «compliance-галочку» вместо перевода.
Хотите обсудить эти темы с практикующими тимлидами?
Обсудить в Telegram