55 записей с тегом "developer-productivity"

Один AI-агент — Cursor Composer, Claude Code, GPT-4 с тулами — решает примерно 38% задач SWE-Bench Verified. Поставьте рядом critic-агента, и число вырастает до 62%. Swarm из трёх (planner + coder + critic) бьёт 71%. Swarm из семи падает обратно до 54%. Форма кривой воспроизводится по пяти публичным бенчмаркам, которые мы просмотрели: больше агентов помогает, пока не перестаёт.

Этот пост — взгляд на реальные данные о мульти-агентных workflow для разработки: что работает, что разваливается и что это значит для того, как разработчики должны использовать агент-swarms в 2026. Наша позиция уже хайпа: swarms реальны, прирост реален, failure mode тоже реален и предсказуем.

Внутреннее исследование GitHub 2024 по Copilot Chat показало: разработчики принимают LLM-сгенерированный фикс примерно в 31% сессий отладки — но только 11% из этих фиксов реально закрыли исходный баг. Остальные 20% пропатчили симптом, ввели регрессию или уверенно указали не на ту подсистему. Исследование Shi et al. в ACM 2024 по LLM-assisted debugging на 2500 сессиях показывает тот же паттерн: ускорение случается на неглубоких багах; глубокие часто становятся хуже, когда разработчик отдаёт генерацию гипотез LLM.

Вывод не "не используйте LLM для отладки". Вывод: используйте там, где они измеримо лучше; не используйте там, где они системно врут; постройте воркфлоу вокруг разницы. Этот пост проходит пять воркфлоу, которые реально экономят время — собраны с инструментации нашей команды и пяти команд-клиентов PanDev Metrics.

Fintech-команда, с которой мы работаем, отгрузила одну 400-строчную фичу четыре раза. Figma-файл обновился во вторник. Разработчик взял в среду. Дизайн переоткрыл файл в четверг утром, чтобы «уточнить spacing», и ещё раз в пятницу вечером ради «ещё одной микро-интеракции». Фича уехала в понедельник. Потом инженер два дня чинил visual regressions, пойманные PM-ом после релиза. Итого 7 инженерных дней. Чистого нового кода — 400 строк. Handoff убил больше, чем сама работа.

Разговор про «Figma → код» обычно про инструменты: Zeplin, Figma Dev Mode, Locofy, Visual Copilot. Ни один из них не чинит реальную проблему: handoff дизайн→разработка — это пробел в измерении, прячущийся в пробеле процесса. Определим метрики, которые реально предсказывают хороший handoff, как их мерить без оверхеда, и где выбор инструмента важен (иногда), а где нет (обычно).

Платформенная команда в компании на 600 инженеров потратила $340 000 за 9 месяцев, дообучая 13B-параметровую модель на своей внутренней документации. Launch day: модель отвечала правильно примерно на 72% частых вопросов и уже на 3 недели устарела в день запуска. После этого за 2.5 недели и $18 000 они построили RAG-пайплайн поверх того же корпуса. Он отвечал на 88% частых вопросов и всегда был актуален. Fine-tuned-модель тихо отправили на пенсию через полгода параллельной эксплуатации.

Это доминирующий паттерн 2025-2026: для внутренней документации разработчика RAG выиграл по экономике и свежести. Fine-tuning всё ещё побеждает в отдельных кейсах — специфика домена, выравнивание стиля, жёсткие требования по латенси. Но "дообучить LLM на нашей вики" — уже неправильный дефолт. Бенчмарки OpenAI DevDay 2024 показали, что RAG обгоняет fine-tuning в 14 из 16 сценариев QA по документации по точности и свежести, при стоимости в 8-40 раз ниже. Разберём, когда что реально имеет смысл.

Notion проходит невидимый порог отказа где-то в районе 300 страниц на инженерный воркспейс. До этой точки инструмент любят. После — поиск разваливается, накапливаются дубликаты, команда делится на два лагеря: тех, кто продолжает писать, и тех, кто перестал читать. Stack Overflow Developer Survey 2024 поставил Notion в топ-3 не-IDE инструментов у инженеров — и одновременно отметил его как #1 инструмент, от которого инженеры уходят в 18 месяцев, обычно именно из-за этого коллапса.

Коллапс — не вина Notion. Это проблема структуры. Вот playbook воркспейса из 7 баз, который остаётся навигируемым от 5 до 50 инженеров, и конкретные правила, которые предотвращают «проблему 300 страниц».

Linear катит новую фичу почти каждую неделю и стал дефолтным трекером для "мы современный стартап". У Jira — 20 лет институциональной мускульной памяти, 3000+ Marketplace-апп и одинаково сильная репутация "медленной" и "настраиваемой под что угодно". Между ними сидят 200 000+ инженерных команд, делающих неверный выбор на шестизначные суммы в год.

Это сравнение уходит за поверхность feature-matrix. Оно смотрит, что ломается, когда команда переключается, какова реальная цена миграции и где дизайн-решения каждого инструмента тихо исключают его из определённых форм команд.

Платформенная команда, управляющая 11 production K8s-кластерами, собирает 94 000 метрик каждые 15 секунд, 2.4 ТБ логов в день в Loki и держит Grafana с 340 дашбордами. Когда VP of Engineering спросил "шипим ли мы на K8s надёжно?", никто не смог ответить быстрее чем за час. У них есть cluster observability. Нет engineering observability.

Это две разные задачи. Cluster observability отвечает, здоровы ли поды. Engineering observability отвечает, здорова ли инженерка поверх этих кластеров — быстро ли идут деплои, редки ли откаты, ждут ли разработчики инфры или воюют с ней. Большинство K8s-шопов решили первую задачу и забыли про вторую. Ежегодный отчёт CNCF 2024 сообщил: 68% корпоративных пользователей K8s борются с тем, чтобы "сделать observability actionable" — вежливая формулировка для "метрики есть, решения из них не выходят".

Инженер с 3,5-летним стажем в 120-человеческом скейлапе, с которым я работал в прошлом году, был «очевидно сеньор» — по интуиции всех. Её данные Git и IDE говорили другое: она шипила больше фич, чем любой сеньор команды, но не ревьюила PR за пределами своего сквада, никогда не вела system-design-proposal от начала до конца, а её коммиты кучковались в узкой области из 2 компонентов. Гут её менеджера говорил «сеньор». Поведенческие данные говорили: готова через 6-9 месяцев, не сегодня. Ревизит через 6 месяцев подтвердил: она дошла, и промоушен зашёл сильнее, чем зашёл бы интуитивный.

Решения о промоушене ошибаются в двух направлениях. Promote-too-early производит недоподдержанных сеньоров, тихо недорабатывающих и иногда уходящих. Promote-too-late теряет ваших лучших инженеров в пользу конкурентов, первыми увидевших готовность. Исследование First Round Review 2023 по инженерным карьерам обнаружило: крупнейший драйвер сожаления senior-инженеров — «повысили до того, как был готов», отмечено 41% респондентов. Критерии на данных снижают обе ошибки.

Инженерная команда delivery-платформы работает с нагрузкой принципиально другой формы, чем B2B SaaS. Мобильное приложение курьера пингует локацию каждые 3–5 секунд. Консоль диспетчера ждёт sub-200ms на назначение заказа. Route-optimization крутит комбинаторику ночью и обязан закончить до утренней смены. Отчёт McKinsey по last-mile 2024 оценил час простоя диспетчерской в $12,000–$35,000 для среднего регионального перевозчика.

Эта форма работы меняет то, какие инженерные метрики реально важны. DORA Four Keys всё ещё применимы, но картина delivery performance и team health смещается. Вот метрик-стек, который ложится на логистические команды — и места, где «скопируй SaaS-DORA-дашборд» вводит в заблуждение.

Крупный автопоставщик, с которым я консультировал в 2024, получил production-баг во вторник в 03:15. Фикс написали за 8 минут и выкатывали 19 дней — потому что требовался софт-апдейт PLC на 14 производственных ячейках, каждую из которых можно было обновить только в 4-минутное окно между сменами. Средний lead time инженерной команды на офисной IT-стороне — 31 час. На shop-floor-стороне — 14 дней. Та же команда, тот же репозиторий, две разные вселенные constraint'ов delivery.

Manufacturing software engineering — это Agile, столкнувшийся с железом. Практики, работающие в SaaS-стартапе — deploy-whenever, feature flags, canary-релизы — сталкиваются с регулируемой реальностью plant floor: цели OEE, стоимость changeover, разделение OT/IT и production-линии, которые нельзя остановить ради деплоя. Исследование Deloitte Smart Factory 2023 обнаружило, что 73% производителей называют «интеграцию IT/OT» главным барьером цифровизации. Дело не в технологии — дело в том, что метрики и ритуалы, придуманные для чистого софта, ломаются, когда софт касается физического процесса.