Vercel купил Better Auth.

Авторизация/аутентификация для меня всегда была интересной темой. Которую если делать правильно и безопасно - нужно упороться. Даже имплементировать все основные подстандарты oauth/oidc и рекомендации owasp - вообще ни разу не просто.

Better Auth лучшая и можно сказать единственная универсальная open source библиотека которой очень много лет не хватало для реализации многих бестпрактикс. Единственную альтернативу в виде nextauth он поглотил очень быстро.

Сейчас авторизацию во многих приложениях сразу строят на нем, и покупка vercel это некоторый знак качества и уверенности в темпе развития.

А нужно ли потреблять контент и сигналы с рынка с такой скоростью?)

Готов поспорить что - "да" и мы вынуждены это делать чтобы не ошибаться в инженерных, архитектурных и организационных вопросах.
Нет универсально правильных, выверенных годами способов решения совершенно новых для отрасли задач и вызовов в области построения ai sdlc процессов.

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

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

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

2. Для другой конференции мы начали отбирать доклады за 3+ месяца. И часть докладов которые казались актуальными в марте, в июне уже сильно менее актуальны.
То что казалось революцией 3 месяца назад, сейчас уже данность.

> Выпасть на 1-2 месяца из этого зверского информационного потока - значит принимать неправильные решения в трансформации производства за которую ты отвечаешь.

Как бы не звучало смешно - но практика которая прожила год или хотя бы 6 месяцев с результатами - это прям штука за которую стоит хвататься)
Каждую практику ты еще вынашиваешь применительно к своим процессам, анализируешь относительно трендов и рынка, 10 раз взвешиваешь прежде чем кинуться ее внедрять.

Тут стоит отдельно похвалить коллег из сбера которые не побоялись выпустить AI Disrupt PDLC как набор устоявшихся практик, трендов и веяний который они взяли смелость зафиксировать в документ. Коллеги утверждают что таких аналогов нет в мире, и в целом из моего наблюдения - кажется столь всеобъемлющего действительно нет.

Да, может быть что какая то доля трендов отражена с ошибкой, где-то с перегибом, но с моей точки зрения они действительно выразили и консолидировали многие СТАБИЛЬНЫЕ тренды на которые сейчас все ставят.

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

Отдельный кайф получил от встреч c-level клуба, когда технические и бизнес директора разных компаний разных уровней и совершенно разного бизнеса (от заказной до продуктового) в форматах брейншторма обсуждали свой вижен. И здесь прям супер приятно что вижен во многом матчится. Это дает больше уверенности в тех изменениях что мы опять же внедряем у себя.

Глеб Михеев (кстати руководитель AI Native комитета в онтико) запустил опрос — исследование адаптации агентной разработки в компаниях.

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

Сам опрос тут, его пустили по разным каналам в попытке больше собрать информации по состоянию в отрасли.

https://github.com/obra/superpowers/releases/tag/v5.0.6

Значимое событие в области харнеса отыгрывает за лагерь сокращения старых обвесов мультиагентности.
Автор superpowers выпилил мультиагентное ревью, со словами что чеклист самопроверки справляет лучше и быстрее.

# Масленников разобрал лагери обвесов харенса
https://habr.com/ru/articles/1058676/

Причем мои наблюдения подтверждают что "минималисты" которых он выделил зачастую приверженцы SDD. Я у многих приверженцев готовых SDD фреймворков, на которых они строят слой харнеса поверх базовой шины контекста узнавал что они не упарываются в мультиагентность.

# Мой взгляд на мультиагентность:
1. Многие сабагенты которые мы делали в 2025ом - стали не нужны. Часто мы их делали т.к. не влезали в контекстное окно, да и в эпоху когда скилов не было. Бездумное следование старым привычкам - зло.
2. Мои наблюдения (eval еще не выкатили чтобы сказать замеры), показывают достаточно неплохое качество замыкание на чеклисте самопроверки из SDD при работе в 1 поток.

Конечно это не значит что нужно всегда и везде юзать 1 агента в монопоток.
Но это призыв к тому чтобы не считать что мультиагентность - серебрянная пуля и точно является некоторой уверенной стадией зрелости харнеса. Необходимо все эвалами тестить, не устарело ли на актуальных моделях конкретные старые приемы в т.ч. конкретное использование сабагентов.

Собственно есть разные поинты когда нужно идти в мультиагентов, когда нет.
Например базовые правила что мелкие подзадачи с большим выводом и малым вводом можно делегировать чтобы экономить окно. И в недавних патчах агенты вроде claude code / codex даже начали САМИ это делать без ручных оптимизаций.

Один из поинтов когда стоит нарезать мультиагентов вручную выразил Николай Сенин на AgenticDevConf и который я тоже нахожу весьма неплохим (скрин ниже).
Еще поинт из того же доклада про то что иногда делегирование подзадач дает просто лишнюю потерю токенов т.к. нужно многим подагентам объяснять один и тот же контекст.

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

Немного про измерение эффективности от внедрения AI в SDLC

Количество часов разговоров с коллегами в отрасли на эту тему за последний год я бы мог исчислить десятками)
Например пол года назад тут с коллегами из Т-Банк, Яндекс и WB (FunSun) или пару недель назад в круглом столе про ФОТ. Или под новый год на митапе smallTech.
Также много разговоров с коллегами в кулуарах Saint Haighload++, TeamLeadConf, Sber Arch.Meethup и еще многих других.
Кстати так сложилось что практически не обсуждали на Agentic Dev Conf, там как будто бы у людей другой вайб, сильно больше тех кто уже обосновал для бизнеса эффективность.

Я бы разделил следующие фазы этого дискуссии.

# ФАЗА 1:
А ТОЧНО ЛИ УСКОРЯЕТСЯ САМ ПРОЦЕСС РАЗРАБОТКИ?

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

Второй их основной довод: у нас в компании сеньеры тратят 10% на код, а львиная часть на решение блокеров и других вопросов. И правильное следствие (которое происходит не у всех) - анализировать узкие места и решать, то что 10% пишется код порой может быть следствием неэффективности построения команд или межкомандного взаиможействия, процессов внутри.

На мой взгляд в таких случаях правильный вопрос: а стоит ли параллелить решение вопросов. Иногда можно на AI рельсах пересобрать новомодные tiny team это как раз способ и перезагрузить проржавевшие старые процессы.
А с AI флагом сейчас можно как раньше с agile флагом ломать многие преграды внутри корпоративных укладов.

Третий довод: что упираемся в когнитивные возможности человека на валидацию (многие об в т.ч. Никита в канале SE Materials подсвечивает риск).
Я бы тут прокомментировал что большую часть когнитивных возможностей должен решать harness. Предел конечно же есть, однако на мой взгляд этот предел точно х2-х3 выше чем работа в старых парадигмах. Запуская harness в 2-3 потока с высоким уровнем автономности (работа часами с самопроверкой до результата), ты можешь поочередно решить 2-3 задачи тогда когда решал за это время условно 0.5.
Но тема большая в т.ч. если раскрывать мультипоточность работы разработчика в новых реалиях.

## Лагерь адоптеров

Можно поделить на тех кто нашел способ доказать ускорение на пилотах в определенных командах. Я видел разные пилоты в корпорациях за последние пол года

1. Внедрение в greenfield проект. Берут greenfield проект, оцениваются конвенциональными способами разработки в год (верифицируют оценку другими старыми командами). И потом эффективно делают его за пару месяцев.
Примеров видел много, вот публичный кейс x5, доклады Александра Поломодова (Тбанк) в т.ч. на последнем Highload++ рассказывает об успехе таких команд, много данных в кулуарах конференций. Да и в целом кажется про успехи в greenfield не рассказывал только ленивый.

2. Внедрение в brownField проекты
Это уже интереснее т.к. было много споров что вот на старых то проектах внедрить нельзя. Но пилоты многих показали что и тут можно добиваться значимых результатов.
На Agentic Dev Conf и грядущем TeamLead Conf Siberia коллеги из райфа показывают такие пилоты и их успех в разных не связанных вертикалях.
Есть и много других проектов, и в т.ч. мы в в Вебпрактик видим ускорение в т.ч. в brownfield проектах, если правильно работать с контекстом и правильно затачивать под это harness.
Причем как про микросервисную (могу говорить про десятки/сотни) так про монолитную brownfield архитектурой.

Т.е. в лагере адоптеров есть много кейсов когда они доказали эффективность бизнесу через прирост производительности разработка в конкретных метриках.

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

# ФАЗА 2:
ТРАССИРОВКА ЭФФЕКТОВ ОТ УСКОРЕНИЯ НА БИЗНЕС

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

И один из ключевых вопросов который задают: а точно ли ускорение разработки дает эффект в бизнесе.
Измеримый сквозной throuthput. В идеале в финансах.

И тут ловушка в которую попадает этот вопрос: что даже в мире без ai в большинстве команд не могут однозначно сказать на сколько те или иные гипотезы беклога определенного продукта повлияли на сквозную пользу для бизнеса который выразился в финансовом результате. Могут быть какие нибудь промежуточные метрики, но на сколько они точно влияют на конечный бизнес результат сложно.

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

И тогда 2 сценария
а) У вас есть возможность доказать бизнесу что беклог действительно конвертируется в ценность и ускорение переработки беклога = польза.
б) У вас идут сценарии доказания через сохранение скорости беклога, но сокращение ресурсов.

===
В целом в правильном споре стоит разделять уровени, и спорить на каждой конкретно: разработчик / команда / поток доставки / бизнес
Часто в спорах идет перепрыгивания с уровня на уровень, причем не осознанное.

На мой взгляд эффективность разработки доказана давно. Лето 2026 славится тем что уже к этому моменту за весну многие корпорации откатали свои пилоты и пришли с публичными результатами о которых могут заявлять. Сейчас все начинают думать как масштабировать этот опыт и решать те боли с которыми столкнулись в процессе.

Нельзя не уважить лагерь тех кто говорит подходить аккуратнее и утверждают что можно получить ускорение больше классическими методами поиска узких мест без AI, особенно если у вас накопился большой ворох проблем и те самые 10% написания кода происходяи в результате огромного количества блокеров. Но имхо эти процессы нужно параллелить. Чтобы к тому моменту когда вы разошьете старые проблемы, не оказалось что вы с самом начале перевода производства на новые рельсы.