Research Insights Made Simple #31: AI4SDLC — что бы я делал по-другому (Рубрика #AI4SDLC)

С чего начинать свой AI-стек: с выбора модели, покупки GPU, написания собственной обвязки? На Deep Tech Night 5 сентября в рамках lighting talk я предложил начать с границы владения: что арендовать, что дорабатывать под свою среду и что обязательно держать под своим контролем.

22 сентября в 13:00 МСК в прямом эфире расскажу режиссёрскую версию этого выступления, за которое набролось 100+ голосов в одном из прошлых постов.

В центре выпуска — несколько вполне практических вопросов:
- Зачем писать собственный цикл агента, если рынок уже развивает готовые? И где своя обвязка всё-таки оправданна?
- Почему одна и та же модель даёт разный результат с разными инструментами, контекстом и правами?
- Как отличить красивый трейс от выполненной задачи — и проверить, что очередная доработка действительно помогла?
- Какие задачи можно передать меньшей модели, а где пока стоит оставить большую?

Cлайды выступления уже на сайте. Сам выпуск — 22 сентября на YouTube. Приходите, особенно если сейчас решаете, какую часть AI-стека действительно стоит делать своей.

#AI4SDLC #AI #Agents #Architecture #PlatformEngineering #Evals

Когда код стал дешёвым: материалы дискуссии Deep Tech Night (Рубрика #AI4SDLC)

Собрал запись и конспект дискуссии «Когда код стал дешёвым: где теперь ценность, ответственность и экспертиза?». Участвовал в ней 5 сентября 2026 года на Deep Tech Night Яндекса вместе с Александром Лукьянченко из Авито, Александром Мазько из Сбера и Олегом Смоляковым из Яндекса. Если агент пишет код быстрее, почему полезные изменения не доходят до пользователя с той же скоростью? С этого вопроса перешли к тому, как устроена работа вокруг кода.

Обсудили
- Ценность ускорения. Постановок, требований и кода становится больше, а согласования и передача контекста могут тормозить всю цепочку.
- Права и ответственность. Какие действия можно доверить агенту, где нужны изоляция и проверки — и кто будет разбираться с инцидентом после зелёных тестов.
- Обучение джунов. Ограничивать агентов в учебных задачах или сразу учить работать с ними? Здесь мнения разошлись. Я предложил проверять, понимает ли человек архитектуру и причины решений.
- Цену внимания. Несколько параллельных агентов требуют переключений и контроля. Обсудили, как оценивать результат с учётом нагрузки на инженера.

Материалы дискуссии:
📌 Страница дискуссии
📖 Мои позиции до дискуссии — лонгрид подготовки.
🎬 Запись на YouTube — 1 час 6 минут.
📝 Текстовый конспект

А у вас что стало главным ограничением после ускорения написания кода?

#AI4SDLC #AI #Agents #Engineering #Management

Заходите на очередной эфир 3 AImigo, где мы будем обсуждать как не утонуть в потоке AI-изменений и сохранить силы.

Homa: почему GPU ждут сеть (Рубрика #AI)

Посмотрел свежий доклад Джона Оустерхаута из Stanford про Homa (Джон - соавтор протокола консенсуса Raft, а также автор крутой книги "A Philosophy of Software Design", о которой я уже рассказывал). В заголовке доклада заявлен тизис «конец TCP для AI-кластеров», а внутри интересный инженерный вопрос: сколько времени дорогие GPU простаивают, пока маленькое сообщение ждёт за большой передачей? По мысли Оустерхаута, в инференсе и агентных системах растёт роль коротких обменов: проверить запись в распределённом KV-кэше, согласовать следующий шаг вычислений. Здесь важна хвостовая задержка: один запоздавший ответ может задержать всех участников синхронизации.

Проблема хорошо известна распределённым системам (она буквально продолжает историю "The Tail at Scale", что я разбирал вчера). Когда несколько серверов одновременно отправляют данные одному получателю, перед его сетевым портом растёт очередь — incast. Короткому сообщению тоже приходится ждать.

Homa предлагает перестроить транспорт вокруг сообщений:
— Знать длину сообщения и давать преимущество тем, которым осталось передать меньше байтов.
— Управлять потоком со стороны получателя: отправитель передаёт начальную порцию, а дальше получает разрешения — grants.
— Использовать приоритетные очереди коммутаторов, чтобы короткие сообщения обходили большие передачи.

В показанном бенчмарке, по данным автора, p99 задержки коротких сообщений у Homa примерно в 13 раз ниже, чем у TCP. Большие сообщения при этом тоже выигрывают. Уже есть Linux-модуль, тесты и утилиты измерений. Но с заголовком и широтой выводов я бы поспорил.

1️⃣ На слайде презентации сетевой бенчмарк, который демонстрирует эффект использования протокола
Ускорения LLM в 13 раз из него не следует: нужно измерять время ответа приложения, tokens/s и загрузку GPU. Выигрыш зависит от того, какая доля ожидания действительно приходится на транспорт.
2️⃣ Отрасль давно работает над этой проблемой
Google описал промышленное применение Swift, а SIRD исследует, как согласовывать решения получателей, когда узким местом становится общий канал. Сравнение с TCP ещё не закрывает спор о лучшем транспорте.
3️⃣ Границы применимости существенны: Homa рассчитан на сеть внутри дата-центра. Нужны интеграция с приложением и настройка сети; разработка grpc_homa приостановлена. Для внедрения работы хватает.

Почитать подробнее — научные статьи и техническое обоснование:
— Homa, SIGCOMM 2018 — устройство протокола.
— Linux-реализация, USENIX ATC 2021 — измерения на 40 узлах; на странице есть PDF.
— It’s Time to Replace TCP in the Datacenter — аргументы Оустерхаута против архитектуры TCP в ЦОД.

Кстати, в конце доклада автор приглашает экспериментировать с Homa и обещает помощь: ouster@cs.stanford.edu. Хорошая задача для входа — проверить, сколько сетевого выигрыша сохраняется в реальной AI-нагрузке. Вот такой результат мне было бы интересно увидеть.

#AI #Architecture #Engineering #Research #PlatformEngineering

IT как Лего: почему эта ложная метафора приносит больше вреда, чем пользы, и что использовать вместо неё (Рубрика #Architecture)

На ArchDays 2024 в докладе про эволюцию архитектуры в Т-Банке у меня был слайд «IT as a Lego». Так выглядела концепция повторного использования решений: выделяем блоки, собираем системы из кирпичиков, всё взаимозаменяемо и красиво. Тогда я сказал коротко, что метафора не работает. Сейчас хочу разобрать, почему именно, тем более что Чад Фаулер пишет для O'Reilly книгу "Regenerative Software" ровно про это (книга топовая и я про нее расскажу сразу, как дочитаю)

Чем Лего подкупает
У кубика один интерфейс — стандартные выпуклости, и любой кубик стыкуется с любым. У кубика нет состояния, и он не меняется, пока его не трогают. Заменить кубик стоит ноль. Отсюда получается очень удобная логика для планирования: система равна списку блоков, блок равен строке в бюджете, переиспользование бесплатно, а замена системы — проект с датой окончания. По сути это та же строительная метафора, что и «сервис — это здание», только с инструкцией по сборке.

Звучит круто, но что не так с этой метафорой?
Сервис — не кубик. У него есть данные и история, неявные контракты и потребители, которые давно опираются на недокументированное поведение. В докладе я формулировал так: с точки зрения Лего замена элемента — это просто кубик, с точки зрения живой системы — трансплантация важного органа. Решения, принятые в логике Лего, узнаются по характерным фразам:
- «Возьмём коробку, потом заменим» — а исходная коробка живёт рядом с двумя волнами своих замен;
- «Назовём это платформой, и все будут переиспользовать» — а блок, вынутый из своей среды, тащит за собой её допущения и в другую среду не встаёт;
- «Это маленький сервис, заменим за спринт» — а маленьким он был только по числу строк.

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

Книга "Regenerative Software" развивает эту метафору дальше. Ее пишет сейчас Чад Фаулер— соавтор RubyGems, автор The Passionate Programmer и бывший CTO Wunderlist. Книга выходит у O'Reilly в Early Release, финальная версия ожидается в апреле 2027 года, а выросла она из серии эссе "The Phoenix Architecture", которую Фаулер публикует с декабря 2025 года. Тезис: код больше не актив, актив — система. Когда генерация кода почти бесплатна, а проверка нет, главным свойством становится replaceability — возможность безопасно заменить компонент целиком. А сохранять надо то, без чего его не воссоздать: поведение, границы, evaluations, evidence и provenance, то есть историю, почему решение именно такое. Мне понравился его deletion test: «Если удалить эту кодовую базу и сгенерировать заново, на что я буду опираться, чтобы решить, что результат правильный?» Страх при этом вопросе означает, что знание живёт только в коде.

Вторую главу Фаулер начинает с истории из Wunderlist: на замену «простого» сервиса членства в группах отвели вечер, а споткнулись о собственную систему уникальных ID, через которую всё остальное находило данные и которую уже никто целиком не понимал. Та самая трансплантация органа, только описанная изнутри.

Если продолжать биологическую аналогию (это уже моя, а не Фаулера), он предлагает не пересаживать органы, а отращивать их заново из «генома» системы: спецификаций, тестов и истории решений. Организм остаётся собой, хотя клетки в нём сменились. Насколько это заработает за пределами задач со строгими evaluations, пока неясно, и сам Фаулер оговаривает, что replaceability бывает неправильной целью. Но как рамка для решений это точно лучше кубиков.

Так что когда в следующий раз услышите «это просто кубик, заменим», спросите: какой это орган, что вокруг него выросло и на что вы будете опираться, чтобы проверить замену.

#Architecture #Software #Engineering #AI #Books #Management #SystemDesign

Материалы 3 AImigo S1E5: джун без простых задач (Рубрика #AI4SDLC)

Готовы материалы пятого выпуска 3 AImigo, который вышел 11 сентября 2026 года. Вместе с Евгением Сергеевым и Алексеем Литвиновым продолжили разговор о найме со стороны начинающего инженера: если небольшие исправления и доработки можно отдать агенту, на чём теперь учиться человеку, которому ещё только предстоит получить первую работу?

В разговоре разделили две вещи: начать делать продукты и начать получать за это деньги. AI помогает быстрее собрать и запустить свой проект. Но работающий продукт сам по себе ещё не гарантирует ни заработка, ни того, что его автор понимает, как всё устроено.

Обсудили:
- Кто будет растить следующих инженеров. Отрасли нужны будущие опытные специалисты, а отдельной компании может быть выгоднее усилить тех, кто уже умеет работать. Обсудили этот конфликт интересов; при этом успешные стажировки для сильных олимпиадников нельзя автоматически считать моделью для всех новичков.
- Собственный проект как входной билет. Пройти путь от проблемы пользователя до запуска и поддержки. Особенно интересно, что происходит после первой работающей версии: ошибки, новые требования и необходимость разобраться в том, что собрал агент.
- Что показывать работодателю. Алексей предлагает разбирать историю проекта: как организована работа агентов, какие есть инструкции и автоматические проверки, что делали при сбоях. По такому разговору видно, какие решения человек принимал сам и чем проверял результат.
- Как учиться с AI. Инженерные основы и работу с агентами можно осваивать параллельно. Оглавления технических книг помогают обнаружить пробелы, а дальше — вопросы, примеры и проверка понимания. Скопировать незнакомый термин в AGENTS.md ещё не значит в нём разобраться :)
- Как устроить стажировку. Новичок объясняет задачу и критерии приёмки, защищает решение агента перед наставником, понимает выпуск изменений и откат. Я предложил начинать с процесса конкретной компании: знать сразу все методологии для этого не требуется.

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

Материалы выпуска
- Страница выпуска с содержанием и таймкодами
- Видео: YouTube, VK Видео
- Аудио: Podster, Яндекс Музыка, Apple Podcasts
- Текст: конспект разговора

Если вы сейчас начинаете карьеру или растите джунов, расскажите: какие задачи помогают учиться рядом с агентом и как вы проверяете, что человек действительно разобрался?

#AI #AI4SDLC #Engineering #Career #Education #Podcast

Regenerative Software — Чад Фаулер (Рубрика #Books)

Книга ещё не дописана, а рекомендовать её уже хочется. "Regenerative Software" Чада Фаулера выходит у O’Reilly в Early Release, и текущие главы, на мой взгляд, очень хорошо объясняют, куда движется разработка софта и почему. Финальный релиз издательство пока планирует на апрель 2027 года, но предмет для разговора уже есть.

Фаулер начинает с экономики. Десятилетиями работающий код было дорого создавать, поэтому вокруг его сохранения выросла вся культура разработки. При этом в коде оседало знание о системе: странные исключения, последствия инцидентов, особенности клиентов. Когда всё это существует только внутри реализации, переписывание превращается в археологическую работу. Новую версию написать можно. Вспомнить всё, что было зашито в старой версии, гораздо сложнее (и никто это без острой нужды не делал). Кстати, эти размышления напоминают те, что были в whitepaper "What Happens When Technical Debt Vanishes?", что я уже разбирал.

AI, в логике автора, резко удешевляет получение правдоподобной реализации. И вот слово «правдоподобной» здесь очень важное. Проверка того, что она действительно выполняет обещания системы, автоматически дешевле не становится. Поэтому ценность смещается к пониманию поведения, границам компонентов и способности обоснованно сказать: эту замену можно выпускать.

Отсюда и regenerative software: систему проектируют так, чтобы её части можно было заново создавать, сохраняя накопленное знание. Реализация может смениться, а контракты, ограничения, проверки и причины решений должны пережить эту смену. У Фаулера есть хорошая аналогия с инфраструктурой: мы уже ушли от pets к catlle и научились пересоздавать сервера из yaml файлов. Теперь он предлагает продумать, что потребуется для такой же заменяемости самого софта (видимо много md файлов).

Причём маленький сервис ещё ничего не гарантирует. Если соседи читают его таблицы или зависят от недокументированного порядка событий, замена затронет и их. Автор предлагает оценивать архитектуру через очень конкретный вопрос: можем ли мы заменить этот компонент, не переделывая остальные, и чем проверим, что всё сохранилось?

Особенно показательна глава про evaluations. Фаулер рассказывает, как участвовал в переписывании системы для школ: современная архитектура, TDD, стопроцентное покрытие unit-тестами. Пользователи новую систему не приняли, и её пришлось откатить. Нужное им поведение жило в привычках и неявных правилах работы, которые команда не перенесла в требования. Все тесты были зелёными. Проверяли просто не всё, что имело значение.

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

Ещё один важный слой — provenance или история происхождения решений. Почему здесь ограничено число повторных попыток? Почему валидация продублирована? Какие варианты уже пробовали и отвергли? Для следующего инженера или агента эти причины должны быть доступны вместе с подтверждающими данными. Иначе очередное «упрощение» легко удалит защиту от старой аварии.

Мне кажется, именно здесь книга хорошо объясняет происходящий сдвиг: удешевление кода повышает ценность инженерного суждения. Нужно понимать, что система обязана сохранять, как это проверить и каким свидетельствам можно доверять. При этом Фаулер оговаривает цену подхода: качественные evaluations дорого создавать, а превращать каждую часть стабильного внутреннего инструмента в заменяемый компонент может быть бессмысленно. Эту оговорку полезно держать рядом с идеей регенерации.

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

#Books #AI4SDLC #Architecture #Engineering #Software

Материалы 3 AImigo S1E6: как не утонуть в потоке AI-изменений и сохранить силы (Рубрика #AI)

Готовы материалы шестого выпуска 3 AImigo, который вышел 18 сентября 2026 года. Вместе с Евгением Сергеевым и Алексеем Литвиновым обсудили, как оставаться в контексте AI, когда на чтение всех новостей, проверку новых моделей и собственно жизнь претендуют одни и те же часы.

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

Обсудили
- Как выбирать, за чем следить. Евгений начинает с личных целей и планирования недели. Я использую технологический радар: читать сейчас, наблюдать или перестать отслеживать. И прошу подбирать материалы, которые расширяют картину мира, а не только подтверждают то, что уже думаю.
- Когда подборку полезнее отключить. Алексей перестал читать автоматическую ленту и отказался от неё. Темы для изучения ему дают задачи компаний, профессиональное окружение и собственные эксперименты. Это его способ отбора; общего рецепта для всех здесь нет.
- Где заканчивается помощь агента-тьютора. На моём примере разобрали программу от инфраструктуры дата-центров до моделей и платформ. Подготовить теорию и упражнения можно быстро, а дальше приходится задавать вопросы, пробовать руками и подстраивать нагрузку под свои силы.
- Зачем оставлять время без входящей информации. Схема от руки, заметка своими словами, подготовка выступления — способы переработать материал. В опыте ведущих прогулка или бег без подкаста тоже помогают освободить голову. Не каждую свободную минуту обязательно заполнять ещё одной лекцией :)
- Как отличать прогресс от занятости. Евгений ведёт вечерний дневник: приблизил ли день к выбранной цели? При этом он признаёт, что агенты позволяют запустить больше параллельных процессов, чем хватает сил сопровождать. Уметь запускать ещё одну задачу и иметь на неё внимание — разные вещи.

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

Материалы выпуска:

- Страница выпуска с содержанием и таймкодами
- Видео: YouTube, VK Видео
- Аудио: Podster, Яндекс Музыка, Apple Podcasts
- Текст: конспект разговора

Как вы выбираете, что изучать, а что пропускать? И как понимаете, что действительно чему-то научились, а не просто разгребли очередную подборку?

#AI #AI4SDLC #Agents #Education #Engineering #Podcast

Диогу Алмейда: AI, за которым можно не присматривать (Рубрика #AI4SDLC)

Почему AI впечатляет решением сложных задач, а обычный возврат денег клиенту всё ещё страшно поручить ему без проверки? В 18-минутном июльском выступлении на AI Engineer Диогу Алмейда предлагает искать ответ в цели обучения. По его мнению, индустрия научилась делать отличных помощников, а надёжная автоматизация требует другого набора свойств. Алмейда — один из основных авторов InstructGPT, работы 2022 года, которая помогла превратить языковую модель в исполнителя инструкций. Теперь он разбирает ограничения этого подхода. Получается интересная исследовательская петля: сначала научить AI работать с человеком, затем понять, что мешает убрать постоянный присмотр.

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

Представим ответ службы поддержки. Он вежливый, подробный, выглядит убедительно. А возврат оформлен по неверному правилу. Если результат проверяет человек, он ещё может заметить ошибку. Если ответ стал условием в программе, дальше уже поехали деньги. Здесь качество формулировки и качество решения приходится измерять отдельно.

Отсюда провокация Алмейды: ChatGPT и Claude Code принадлежат одной эпохе — эпохе ассистентов. По его логике, агент может выполнять всё больше действий, но это ещё не означает, что ему можно доверить процесс целиком. В идеале автоматизация должна стать настолько обыденной, что о ней вспоминают примерно как о фоновом задании на сервере.

У этой критики есть предметная опора. В отчёте GPT-4 показано, что после постобучения модель хуже оценивала вероятность правильности своих ответов на подмножестве MMLU. При этом результаты на TruthfulQA улучшились. То есть можно чаще отвечать правильно, но хуже соотносить уверенность с реальной точностью. Два разных свойства, которые легко склеить в одно слово «качество».

Для автоматизации Алмейда предлагает отдельную цель — калиброванные решения. Если система выдаёт вероятность 90%, то на большой группе таких прогнозов доля верных должна быть около 90%. Тогда можно настраивать границы: где программа действует сама, где запрашивает дополнительные данные, где передаёт случай человеку. Эти границы всё равно придётся проверять на своих задачах, так как ваше распределение решений может отличаться.

Сильная часть аргумента — требование сделать неопределённость пригодной для программирования. А вот необходимость человека при каждом запуске из RLHF автоматически не следует. Человек участвует в обучении; сколько проверки потребуется при эксплуатации, зависит от реальных ошибок и цены их последствий. Поэтому объяснять все проблемы автоматизации одним методом обучения было бы слишком удобно.

Ещё у Алмейды есть хороший поворот про программное обеспечение. AI уже помогает быстрее писать код, а он хочет изменить сами возможности готовой программы: добавить в неё смысловые суждения, которые можно проверять и соединять с обычной логикой. Условие «клиент действительно просит возврат» гораздо труднее выразить кодом, чем проверку суммы или даты.

На момент выступления его TypeSafe ещё готовилась к релизу, который состоялся 15 сентября. Собственно, у этой идеи появился API и модель Jev, про которую мы поговорим в следующем посте.

#AI #AI4SDLC #Engineering #Automation #Research

Jev: интеллект для обычного if (Рубрика #AI4SDLC)

В предыдущем посте Диогу Алмейда предлагал учить AI принимать решения, которые можно встроить в обычную программу. У этой идеи уже появилось вполне осязаемое продолжение: модель Jev от его компании TypeSafe. Любопытно здесь то, сколько возможностей разработчики согласились отдать ради одного полезного свойства — быстро отвечать на маленькие вопросы.

15 сентября 2026 года TypeSafe открыла ранний доступ к Jev и объявила о раунде на $40 млн под руководством DCVC. Модель вообще не пишет свободный текст. Ей передают состояние — например, обращение клиента и сведения о заказе — и набор вопросов с заранее заданной формой ответа:
- Choice выбирает вариант из списка: в какую очередь отправить обращение;
- Score оценивает по описанной шкале: насколько срочно нужна помощь;
- Noul возвращает вероятность ответа «да»: просит ли клиент вернуть деньги.

Вопросы обрабатываются параллельно; Choice и Score тоже возвращают вероятности возможных ответов. Дальше обычный код решает, что делать: направить заявку нужной команде, запросить недостающие данные, передать человеку. Модель можно поставить внутрь знакомого if, а правила перехода между шагами оставить в программе. Именно из таких деталей и собирается автоматизация.

Метод обучения TypeSafe назвала RLCD — Reinforcement Learning for Calibrated Decisions. Его заявленная цель — согласовать вероятности с реальной частотой событий. Если модель много раз говорит «вероятность 80%», примерно в 80% этих случаев событие должно происходить. Тогда можно подобрать порог для автоматического действия, а сомнительные случаи отправлять на разбор. Разумеется, такую калибровку еще нужно проверить на своих данных.

За отказ от генерации обещают щедро заплатить скоростью. В собственных тестах рабочих процессов TypeSafe получила ускорение до 193,6 раза и снижение стоимости до 444,6 раза относительно сравниваемых LLM. Сама компания считает такой выигрыш оптимистичным ориентиром для реальных задач. Есть и методическая тонкость: эталоном служило усреднение ответов сильных моделей, так что тест измерял согласие с ними, а не независимо установленную правильность.

Появились и внешние эксперименты. 20 сентября LangChain опубликовала проверку, в которой Jev оценивал пять ответов погодного агента, каждый по 100 раз. Все 500 бинарных оценок совпали с разметкой человека, средний вызов занимал 0,44 секунды. Звучит бодро, но пять разных примеров остаются пятью: повторы хорошо показывают устойчивость, а широту возможностей придется проверять отдельно.

Самая скользкая фраза в анонсе — «не может галлюцинировать». Здесь гарантируется форма ответа: Jev не придумает шестую категорию, если разработчик разрешил пять. Ошибочно выбрать одну из пяти он вполне может. И документация довольно прямо перечисляет проблемы: арифметика, сравнение дат, длинные цепочки рассуждений, лишний контекст. Содержащиеся в данных вредоносные инструкции тоже могут влиять на решение.

Поэтому интересный эксперимент с Jev — выделить небольшой участок существующего процесса, где постоянно нужен смысловой выбор. Например, проверять, подтверждает ли источник вывод агента, или выбирать маршрут обработки заявки. Посчитать ошибки, подобрать порог, оставить возможность передать задачу человеку. Если такая деталь работает дешево и предсказуемо, ее можно вызывать на каждом шаге — и вокруг нее уже строить более сложную систему.

Попробовать можно через OpenRouter: модель typesafe/jev-1.13, на 20 сентября — $0,042 за миллион входных токенов, выход бесплатный. Хороший повод взять одну повторяющуюся развилку в своем коде и проверить, как изменятся задержка и число ошибок.

#AI4SDLC #AI #Architecture #Evals #Engineering

Y Combinator: железо, агенты и основатели (Рубрика #AI)

В свежем выпуске The Lightcone «The State of Startups in 2026» команда YC связывает несколько изменений одной идеей: AI позволяет маленьким командам браться за более сложные задачи. В этой картине меня интересуют две вещи: откуда берётся экономика новых производств и зачем каждому софтверному продукту заводить собственного агента. Со вторым тезисом я бы поспорил.

По данным, которые ведущие приводят в выпуске от 17 сентября 2026 года:
- Доля hard tech среди принятых в YC компаний выросла с 8% до 20%;
- Робототехники — примерно с 1% до 6–7%;
- Компаний с одним основателем — примерно с 5% до 18–19%.

Это статистика отбора YC. На неё влияют и предложения основателей, и предпочтения инвесторов; переносить проценты на весь рынок я бы не стал.

1️⃣ Железо и спрос на производство
Под hard tech здесь понимают роботов, чипы, энергетику, космос и оборонные системы. Аргумент YC: генерация кода позволяет меньшей команде справляться с программной частью сложного физического продукта. Звучит разумно, хотя расчёта экономии на всём цикле разработки в выпуске нет. Ребята еще приводят в пример Nox Metals, который интересен другим. По словам ведущих, новые оборонные стартапы в США нуждаются в металле, а существующие поставщики не успевают за их темпом. Nox развивает автоматизированную обработку и поставку металла. Здесь локальное производство создаёт рынок для следующего звена цепочки. Автоматизация помогает обслужить этот спрос. Объяснять весь рост удешевлением разработки благодаря AI было бы слишком смело.

2️⃣ Свой харнесс в каждом продукте
Дальше YC предлагает системам, где хранятся рабочие данные, становиться средой исполнения задач агентов — харнессом. Иначе работу с их данными организует внешний агент, к которому может перейти и взаимодействие с пользователем. В пример они приводят успехи Salesforce и их обвязку для Slack.

Вот в массовый успех такого подхода я не верю. Разработка собственного харнесса может съесть много денег, а пользователь продолжит работать в привычном Claude или Codex. Через MCP и API внешний агент потенциально охватит больше систем: одна задача легко проходит через CRM, почту, документы и финансы. Я бы скорее вкладывался в понятные агенту действия продукта: проверить условия договора, согласовать скидку, оформить заказ. С правами доступа, проверками и возможностью разобраться в ошибке. Собственному агенту ещё придётся доказать, что внутри продукта он даёт заметно лучший результат.

3️⃣ Опытные основатели снова в центре внимания
Ведущие отдельно отмечают сильных основателей, которым под 40, за 40 и даже за 50. Их объяснение: AI помогает быстрее реализовывать идеи, а опыт подсказывает, что вообще стоит строить. Они также предполагают, что управление инженерами помогает ставить задачи агентам и оценивать их работу. Здесь я вижу правдоподобный механизм: знание отрасли и её проблем становится полезнее, когда можно быстрее проверить решение. Но в выпуске это наблюдения и примеры; статистики успешности по возрастам там нет.

4️⃣ Стартовать одному стало проще
Рост с 5% до 18–19% относится к solo founders — основателям, которые приходят в YC без сооснователя. Численность сотрудников эта цифра не описывает. Сами ведущие ожидают, что многие успешные одиночки добавят сооснователей позже. По их логике, AI позволяет одному человеку закрыть больше задач на старте. Мне здесь интересна возможность сначала проверить идею и спрос, а уже затем собирать команду под понятную работу. Для человека с отраслевым опытом это вполне конкретное расширение возможностей: до первого эксперимента теперь потенциально меньше организационных препятствий.

#AI #Robotics #Agents #Product #Management #Software #Engineering

Research Insights Made Simple #30: Developer Productivity for Humans (Рубрика #Management)

21 сентября в 17:00 МСК в сольном выпуске соберу серию исследований Google и мои разборы о продуктивности разработки в одну картину.

Представим, что сборки ускорили, AI пишет больше кода, а графики активности растут. Как понять, что команде стало легче доводить работу до полезного результата? И не переехала ли сэкономленная работа к тому, кто теперь всё это проверяет?

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

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

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

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

#Management #Engineering #Metrics #DevEx #AI #Research