TGViewer
Channel Public Channel
Книжный куб

Книжный куб

@book_cube

Канал Александра Поломодова (@apolomodov), cto & technical fellow.

https://polomodov.tech - сайт со всеми материалами
youtube.com/@tellmeabouttech - канал со всеми видео
Subscribers
15.7K
Photos
3K
Videos
6
Links
2.5K

Showing posts older than #4803 · Back to latest

Older Posts 20 shown
Post #4802 2.99K
Материалы по второй AMA сессии про AI-assisted Engineering с Алексеем Литвиновым про то, как внедрять AI в разработку (Рубрика #AI4SDLC)

Готовы материалы с прямого эфира подкаста Code of Leadership с Алексеем (@tip_podcast):
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка

#AI #Management #Processes #Engineering #Software #Architecture
polomodov.tech AMA #2 про AI-Assisted Engineering — Code of Leadership Вторая AMA с Алексеем Литвиновым: локальные модели, мультиагентность, brownfield, ИБ, evals и экономика AI-Assisted Engineering.
  • ❤ 5
  • 👍 2
  • 🔥 1
  • 🍌 1
Post #4801 3.09K
AI4SDLC 2026: как AI меняет разработку ПО в России (Рубрика #AI4SDLC)

Сегодня на «ИТ-Пикнике» я расскажу о нашем исследовании AI4SDLC 2026 и об общем состоянии AI в разработке софта. Мы уже прошли этап с ассистентами и теперь интересно взглянуть на то, как а помогает ли разработка с агентами не просто ускорять кодинг, но и преводить к более быстрой и устойчивой поставке продуктов. Или агенты просто переносят узкое место в постановку задач, review, тестирование, переделки и эксплуатацию?

Для этого мы проводим исследование из двух основных частей
1️⃣ Обновляемое мета-исследование публикаций 2026 года. Мы собираем мировые опросы, телеметрию, продольные наблюдения, квазиэксперименты, бенчмарки агентов и индустриальные отчёты. И не складываем все цифры в одну корзину: самооценка, рабочие логи и контролируемый эксперимент дают разные доказательства.
2️⃣ Собственный русскоязычный опрос инженеров, участвующих в создании, поставке или эксплуатации ПО в командах России и СНГ. В основе лежит подход DORA с каузальным инференсом и стандартными конструктами, но мы пересобрали вопросы под тему агентной разработки, которая нас интересовала.

Мы не смешиваем автодополнение, чат и фоновых агентов в один показатель «использует AI». Отдельно смотрим на задачи, частоту, глубину делегирования, автономность, права агента и параллельные потоки. Связываем это с надзором, стоимостью проверки, переделками, DevEx, обучением и пониманием кодовой базы. На уровне команды - со скоростью поставки, стабильностью, надёжностью и качеством продукта. Для руководителей есть ветка про цели организации, затраты и ROI.

Почему мы верим, что это поможет увидеть состояние дел в России?

Не потому, что добровольный опрос автоматически становится переписью индустрии. Мы прямо фиксируем это ограничение. Но такой дизайн позволяет собрать не истории «мы стали в десять раз быстрее», а карту практик и связей между ними. Участников набираем через несколько каналов; учитываем роль, опыт, страну работы команды, отрасль и размер организации. Сравниваем руководителей и специалистов, пользователей разных режимов AI и тех, кто почти им не пользуется. Гипотезы, правила очистки и план анализа фиксируются до просмотра результатов, а в отчёте будут видны размеры сегментов, пропуски и ограничения.

Для меня важно избежать двух крайностей: не объявлять AI бесполезным по одному неудачному эксперименту и не принимать ощущение ускорения за эффективность всей инженерной системы.

Если вы участвуете в разработке ПО - пройдите опрос. Нам нужны ответы не только AI-энтузиастов: опыт скептиков, редких пользователей и команд, которые ещё не перешли к агентной разработке, не менее важен. Буду благодарен, если вы отправите ссылку коллегам - инженерам, архитекторам, тимлидам и руководителям разработки.

#AI4SDLC #AI #Engineering #Research #Management #Metrics
  • 👍 6
  • ❤ 4
  • 🔥 3
  • ⚡ 1
  • 👌 1
  • 💊 1
Post #4800 3.07K
Понимание - новое узкое место в работе с AI (Рубрика #Learning)

Посмотрел 20-минутное выступление Geoffrey Litt, design engineer в Notion. Его главный тезис: AI ускоряет производство изменений, но не формирование модели системы в голове. Поэтому узким местом становится уже не написание кода, а человеческое понимание. И важно оно не только для проверки результата. Агенты тоже учатся тестировать и рецензировать себя. Понимание нужно, чтобы участвовать: замечать связи, предлагать следующий ход и отвечать за развитие системы. Когда код работает, но команда уже не может объяснить, как и почему, накапливается когнитивный долг.

Litt предлагает превращать AI из генератора результата в преподавателя. Кстати, я многими из этих способов пользуюсь, но не в применении к ревью PR, а изучая какую-то новую тему. Эти подходы действительно работают и помогают лучше уложить картинку у себя в голове
1️⃣ После большого изменения просить не пересказ diff, а объяснение: контекст системы → интуитивная модель → логика решения → код в осмысленном порядке;
2️⃣ Завершать разбор коротким тестом из пяти вопросов. Его правило: не отдавать код на ревью, пока сам не ответил. Такой тест - ограничитель скорости понимания;
3️⃣ Для сложной логики поручать агенту сделать «микромир»: временный отладчик, симуляцию или пошаговый интерфейс, где видно изменение состояния;
4️⃣ Обсуждать планы и объяснения в общем пространстве команды, а не в личных чатах с агентами. Иначе каждый быстро движется со своей версией реальности.

В итоге, я бы свел рекомендации Джеффри к простому ритуалу: после каждой существенной AI-сессии зафиксировать, что изменилось, почему выбран этот путь, какие инварианты нельзя нарушать и что теперь умеет объяснить человек без помощи модели. Суть в том, что делегировать можно исполнение, но не владение системой. Хороший AI-процесс измеряется не только скоростью выпуска, но и тем, сохраняет ли команда способность придумать следующий шаг.

#AI #AI4SDLC #Agents #Engineering #Management
YouTube Understanding is the new bottleneck — Geoffrey Litt, Notion Autonomous loops are hot, but the reality is that most agentic tasks still require human judgement. And to guide your agents well, it's not enough to just verify correctness -- you actually need to understand the work they're doing. In this talk, I'll share…
  • 🔥 17
  • 👍 5
  • ❤ 4
  • 👌 1
  • 🥴 1
Post #4799 2.84K
Через пять минут стартует прямой эфир выпуска "Research Insights Made Simple" про AI-разработку как эволюционирующий стек.

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

#AI4SDLC #AI #Agents #Architecture #PlatformEngineering #Evals #Engineering
YouTube AI-разработка как совместно эволюционирующий стек Почему одна и та же модель в двух кодинговых агентах даёт настолько разный результат? И что компании действительно стоит считать своим AI-стеком: модель, обвязку, инструменты, данные или право агента менять внутренние системы? В пятницу, 7 августа, в 27…
  • 🔥 9
  • ❤ 2
  • 👍 1
Post #4798 3.08K
Post #4797 2.8K
Дженсен Хуанг: от трех учебников до универсального аппроксиматора (Рубрика #AI)

Посмотрел разговор Гарри Тана с Дженсеном Хуангом на Startup School 2026, опубликованный 26 июля 2026 года. Обычно такие интервью быстро превращаются в набор историй успеха, но здесь через весь разговор проходит одна инженерная привычка: вовремя признать, что прежняя модель не работает, разобраться в новой области и увидеть за отдельной технологией смену всей вычислительной системы.

1️⃣ Первая история - про ошибку, с которой началась NVIDIA. Компания хотела превратить персональный компьютер в игровую консоль и выбрала собственный алгоритм трехмерной графики. В 1995 году команда поняла, что технология фундаментально неверна, а правильного подхода внутри компании никто не знает. По рассказу Хуанга, он поехал во Fry’s, купил три учебника по OpenGL и устройству графического конвейера и отдал их инженерам. Компания, которая позже стала лидером компьютерной графики, буквально доучивалась уже после запуска и привлечения инвестиций.

2️⃣ Вторая история - про Sega. NVIDIA должна была участвовать в создании консоли после Saturn, будущей Dreamcast, но с выбранной архитектурой выполнить контракт не могла. Хуанг поехал к руководителю Sega Сёитиро Иримадзири, честно объяснил, почему проект нужно отдать другому подрядчику, и одновременно попросил деньги, без которых NVIDIA закрылась бы. По словам Хуанга, Sega выплатила $5 млн: не за готовую технологию, а потому что доверяла команде. Эти деньги дали NVIDIA время на разворот.

3️⃣ Третья история - про AlexNet. В 2012 году многие увидели в ней очень хороший классификатор изображений. Хуанг утверждает, что NVIDIA увидела другое: AlexNet была не отдельным решением для computer vision, а примером нового способа создавать программное обеспечение. Вместо того чтобы вручную описывать функцию, мы задаем глубокой нейронной сети примеры входов и выходов, а обучение подбирает внутренние параметры.

Здесь стоит отдельно разобрать формулировку Хуанга про «универсальный аппроксиматор функций».

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

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

Поэтому прорыв AlexNet был не в открытии самой теоремы. В 2012 году Алекс Крижевский, Илья Суцкевер и Джеффри Хинтон показали, что большую глубокую сверточную сеть можно обучить на ImageNet с помощью GPU и получить на тесте ILSVRC-2012 top-5 error 15,3% против 26,2% у лучшего конкурирующего результата. Разрыв был достаточно большим, чтобы deep learning перестал выглядеть как интересная теория и стал рабочей вычислительной платформой.

Именно эту смену масштаба, кажется, и заметил Хуанг. Если сеть может учить не одну заранее запрограммированную процедуру, а разные отображения из данных, менять придется не только приложение. Меняются процессор, библиотеки, инструменты обучения, инфраструктура и затем целые прикладные отрасли. Для NVIDIA это был не новый рынок для GPU, а повод перестраивать весь стек.

Остальные темы разговора я бы отметил короче:

- Компанию Хуанг предлагает строить как гоночную машину под стиль ее основателя, а следующему руководителю - перенастроить ее под себя;
- Главным навыком эпохи агентов он считает системное мышление, а ключевой нерешенной задачей - точное управление действиями агентов;
- AI, по его мнению, автоматизирует отдельные задачи, но не обязательно уничтожает профессию целиком; приведенные в разговоре цифры занятости требуют отдельной проверки;
- «ChatGPT-момент» робототехники, по его оценке, уже произошел, а следующий этап зависит от симуляции, evals и переноса навыков из симулятора в физический мир;
- Фундаментальные дисциплины, способность учиться и ежедневная устойчивость для него важнее знания конкретного инструмента.

Для меня главный вывод из этих историй не в том, что нужно «верить в себя». Сильная сторона Хуанга - классификация сдвига. Он увидел в учебниках не признание поражения, в деньгах Sega - время на смену технологии, а в AlexNet - не победителя соревнования, а новый способ программировать компьютеры. Инженерно это редкий навык: отличить хороший результат внутри старой категории от события, которое меняет саму категорию.

#AI #Engineering #Architecture #Leadership #Robotics #Research
YouTube Jensen Huang: The Mindset That Built NVIDIA NVIDIA started with the wrong technology, learned the right one from three textbooks bought at Fry’s, and went on to invent most of the major breakthroughs in modern computing. At Startup School 2026 at Chase Center, Garry Tan sits down with Founder and…
  • 👍 9
  • 🔥 6
  • ❤ 2
Post #4796 2.79K
SonarQube Cloud: зачем агентному коду детерминированный внешний контроль (Рубрика #AI4SDLC)

После поста "Sonar и звёздный час верификаторов" решил разобраться, а что именно SonarQube Cloud проверяет в коде, написанном агентами, а также почему это не еще один линтер, а что-то большее, например, гейт между тем, что «агент закончил» и «изменение можно влить».

Sonar не определяет, понял ли агент задачу. Он проверяет более узкую вещь: не нарушает ли код правила безопасности, надежности и сопровождаемости. Продуктовая линейка сейчас выглядит так:

- SonarQube - анализ и quality gates: Cloud работает в CI/CD, Server - в своем контуре, бесплатный SonarQube for IDE - во время написания кода.
- Gitar - AI-ревьюер pull request: разбирает сбои CI, предлагает и применяет исправления. Практически это экономия внимания на рутинном PR-ревью.
- Sonar Vortex - подает агенту контекст и правила через plugin, CLI или MCP и проверяет код во время генерации. Ошибки можно поймать до CI.
- Remediation Agent - исправляет issues из PR или backlog и открывает проверенный PR. Это автоматизация технического долга.
- Advanced Security - SCA: CVE, вредоносные зависимости, SBOM и лицензии. Это слой безопасности цепочки поставки.

Почему проверки в основном детерминированные? Проверяющий слой должен работать как турникет, а не как второй собеседник. При одинаковых исходниках, версии анализатора, профиле правил и отчетах результат повторяется. Это дает контракт для человека и coding agent, короткий цикл исправления и аудит: видно правило, строку и причину отказа.

Детерминированность не означает примитивность или точность. Анализатор строит модели потоков данных и путей исполнения, но они остаются приближением. Возможны ложные срабатывания и пропуски. Security Hotspots Sonar оставляет человеку: инструмент показывает чувствительное место, инженер оценивает контекст.

Зеленый Quality Gate не доказывает правильность бизнес-логики или архитектуры. Я бы разделял роли так: тесты проверяют ожидаемое поведение, Sonar - известные дефектные конструкции, человек - намерение и инженерные компромиссы.

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

P.S.
Изучу еще CodeScene и дальше для своих пет проектов выберу один из этих продуктов и попробую на практике, потом поделюсь своими мыслями о том, а как они работают (благо сейчас я кода с агентами много пишу).

#AI4SDLC #AI #Agents #Engineering #DevSecOps #Evals
Telegram Книжный куб Sonar и звёздный час верификаторов (Рубрика #AI4SDLC) Sonar как продукт существует уже почти двадцать лет и всё это время пользовался популярностью в своей нише: статический анализ, quality gates, поиск багов, уязвимостей и code smells. Но теперь у компании…
  • 🔥 7
  • 👍 5
  • ❤ 3
Post #4795 2.9K
Приходите мы стартуем прямой эфир, где Иван Гель расскажет про продукт UpCore, цифрового тимлида, а я буду задавать интересные вопросы

В плане обсудить:
- Что именно UpCore считает эффективностью и как нормализует разные проекты, стеки и типы задач;
- Можно ли автоматически определить грейд и трудоёмкость только по коду;
- Как в текущих условиях, когда код пишется с помощью ИИ, можно измерить эффективность программиста.
- Как отличить слабую работу от легаси, техдолга, сложного ядра системы и длительной отладки;
- На каких данных проверялись заявленные 85% точности и рост на 12%;
- Повышает ли полная прозрачность осознанность разработчика или разрушает доверие в команде;
- Как защитить такую систему от накрутки и саму команду - от ошибочных управленческих выводов;
- Где проходит граница между полезной инженерной телеметрией и цифровой слежкой.

#AI4SDLC #Engineering #Management #Leadership #Metrics #DevTools
YouTube Code of Leadership S2E9: Цифровой тимлид или можно ли измерить эффективность разработчика по коду? Работают ли ваши разработчики на 100%? И можно ли вообще ответить на этот вопрос по коду - без табелей, дополнительных отчётов и субъективной оценки руководителя? А если в работе случился спад - отличить недозагрузку от сложного легаси, техдолга, незнакомой…
  • 👍 6
  • ❤ 4
  • 🔥 3
  • 👎 1
Post #4794 2.76K
Таненбаум, PagedAttention и фундамент, который не устаревает (Рубрика #Books)

Разбирался с интересным paper "Efficient Memory Management for Large Language Model Serving with PagedAttention" от создателей vLLM. В 2023 году авторы посмотрели, как современные на тот момент движки инференса LLM работают с памятью, и нашли почти криминальную по нынешним временам картину (убийцей эффективности был KV-cache).

Системы заранее резервировали под запрос непрерывный участок памяти исходя из максимально возможной длины последовательности. Но реальные ответы обычно короче, запросы растут динамически, память фрагментируется. По измерениям авторов, полезными данными было занято лишь 20,4–38,2% памяти KV-cache.

Авторы предложили PagedAttention: разделить KV-cache на логические блоки и отображать их на физические блоки памяти, которые не обязаны лежать подряд и выделяются по мере необходимости. По сути, они перенесли в LLM serving давно знакомые операционным системам идеи виртуальной памяти и страничной организации.

И тут я вспомнил, как с большим интересом читал "Современные операционные системы" Эндрю Таненбаума и Херберта Боса. Это был примерно 2017 год. Я уже год работал техническим менеджером в Тинькофф, но очень не хотел терять технические компетенции. Поэтому по выходным приезжал в офис: сначала позаниматься в фитнесе, потом - поботать технические темы. Одной из таких тем и стали операционные системы.

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

Книга последовательно разбирает:
- Процессы и потоки, планирование, межпроцессное взаимодействие и синхронизацию;
- Адресные пространства, виртуальную память, страничную организацию и алгоритмы замещения страниц;
- Файловые системы, хранение данных и ввод-вывод;
- Взаимоблокировки и способы их предотвращать, обнаруживать или переживать;
- Виртуализацию и облака, многопроцессорные системы и безопасность;
- Устройство UNIX, Linux, Android и Windows 8.1 как реальные примеры этих принципов.

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

Конечно, четвёртое издание - уже капсула времени. Windows 8.1 давно не современная система, а конкретные детали Linux, Android, безопасности и железа нужно дополнять актуальной документацией. И это точно не быстрый практикум по администрированию Linux. Но фундаментальные главы про процессы, память, файловые системы, конкуренцию за ресурсы и виртуализацию стареют гораздо медленнее конкретных API.

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

#Books #Engineering #Software #Architecture #OS #AI #DistributedSystems
  • 🔥 19
  • 👍 10
  • ❤ 4
  • 💯 2
Post #4793 3.27K
Запускаем подкаст 3 AImigo: три взгляда на AI и разработку (Рубрика #AI)

Мы запускам еженедельный подкаст про AI в разработке и не только. Вести его будем втроем: Евгений Сергеев, Алексей Литвинов и я, Александр Поломодов. У нас разный опыт и разная точка зрения, но общий интерес: понять, как AI на самом деле меняет инженерную работу, продукты и управление. Не на уровне рейтинга моделей и магических промптов, а там, где начинаются реальные кодовые базы, ограничения, ответственность и внедрение в команды.

Состав для этого подобрался подходящий:
🤖Женя - Engineering Director во Flo. Женя смотрит на вопрос с позиции управления большой инженерной организацией и думает о том, как AI влияет не на отдельного разработчика, а на всю систему разработки.
🤖 Лёша - Principal Engineer и консультант по внедрению AI в разработку, ex-Lyft и ex-EPAM. Его фокус - AI-Assisted Engineering: как превратить эксперименты с coding agents в воспроизводимый процесс с контекстом, спецификациями и проверками.
🤖 Я - Technical Director & Fellow. Моя страсть - архитектура, платформенная разработка, AI4SDLC и технологические изменения на мастшабе корпорации.

С каждым из нас в канале уже выходили отдельные подкасты. С Женей обсуждали, почему coding agents не отменяют экспертизу и как строить production-grade evals. С Лёшей разбирали AI-Assisted Engineering и работу агента в многоходовом диалоге. А я вообще постоянно о чем то рассказываю:)

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

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

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

#AI #AI4SDLC #Engineering #Architecture #Management #Podcast
  • 🔥 26
  • ❤ 4
  • 💅 4
  • 🎉 1
Post #4792 2.84K
Джефф Дин покидает Google после 27 лет работы (Рубрика #Legend)

Буквально пару-тройку дней назад я рассказывал про лекцию Джеффа для стартаперов из Y Combinator. Ближе к концу там была такая фраза
Наконец, Дин ожидает, что в 2027 году заметно вырастет автоматизация самого ML: система будет раскладывать задачу, запускать множество экспериментов, оценивать результаты и собирать улучшенную версию. AlphaEvolve уже показывает форму такого цикла.

А сегодня появляется эта новость, где Джефф и его друзья стартуют лабу "Discovery Loop!" в формате
Public Benefit Corporation whose mission is to automate machine learning, science, and engineering to accelerate discoveries and progress

Теперь понятно за счет чего вырастет эта автоматизация:)
Ну а если серьезно, то с большим интересом буду следить за анонсами из этой новой корпорации, которую как объявил Сундар Пичай поддержит Google

#AI #Agents #Engineering #Architecture #Infrastructure #Product
X (formerly Twitter) Jeff Dean (@JeffDean) on X Announcing Discovery Loop! I am very excited to announce that, along with my longtime friends and collaborators @Sanjay_Ghemawat, @OriolVinyalsML and @quocleix, we are founding Discovery Loop (@…
  • 🔥 8
  • ❤ 5
  • 👀 1
Post #4791 3.01K
Post #4790 2.98K
Материалы по прямому эфиру с Артемом Бондарем про то, как внедрять AI в операционную работу (Рубрика #AI)

Готовы материалы с прямого эфира подкаста Code of Leadership с Артемом (@artemonml):
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка

#AI #Management #Processes #Engineering #Software #Architecture
polomodov.tech GenAI в операционной работе — Code of Leadership Как внедрять GenAI в поддержку, бухгалтерию, маркетинг и проектирование: качество, сквозная экономика, перепроектирование процессов и ответственность.
  • 🔥 4
  • ❤ 2
  • 👍 1
Post #4789 2.98K
Гарри Тан про AI-native компанию: память важнее модели (Рубрика #AI4SDLC)

Посмотрел доклад Гарри Тана, президента и CEO Y Combinator, «Every company should have a Brain» с AI Engineer World’s Fair 2026. Главный тезис: преимущество даёт не особая модель, а организация работы вокруг агентов и накопленного контекста. По собственной оценке Тана, его производительность в программировании выросла до 400 раз, а со строгими поправками — в 8–80 раз. Это не benchmark, а личная оценка. Важнее другое: условные «2x» и «100x» разработчики используют те же модели. Разница - в обвязке.

Тан предлагает смотреть на агентную систему как на организацию:
- Skill-файл - сотрудник с одной обязанностью;
- Resolver - оргструктура, направляющая задачу;
- Правила хранения - внутренние процессы;
- Evals - проверка их работы (аля performance review)

Неоднозначные задачи Тан предлагает отдавать модели и сейчас это это понять намерение и сделать выбор. А состояние, расчёты, ограничения и проверки можно поручить детерминированному коду. Многие сбои начинаются там, где одно пытаются заменить другим. Но даже хороший агент ограничен контекстным окном, а компания - это библиотека из переписки, встреч, решений и postmortem. Поэтому «мозг компании» у Тана - не просто поиск, а библиотека плюс библиотекарь, выбирающий нужный контекст для задачи.

Свой вариант Тан развивает в открытом проекте GBrain - слое памяти и поиска для агентов с синтезом ответов, ссылками на источники и графом связей: Без источников, проверки противоречий и удаления устаревшего знания такой «мозг» превратится в свалку с хорошим поиском. Память здесь - production-инфраструктура, а не папка для всего подряд.

Практический совет от Гарри - не делать одноразовую работу. Удачный результат нужно превратить в повторяемый skill и проверить через eval. Тогда организация накапливает способность, а не каждое утро начинает с амнезии.

#AI #AI4SDLC #Agents #Engineering #Architecture #Management
YouTube Every company should have a Brain — Garry Tan, Y Combinator Garry Tan, President of Y Combinator, discusses how the rise of AI-native companies is revolutionizing organizational productivity, allowing lean teams to operate at a scale previously requiring hundreds or thousands of employees (0:52-1:07). Key Takeaways:…
  • ❤ 5
  • 👍 2
  • 🔥 1
Post #4788 2.74K
Research Insights Made Simple #27: AI-разработка как эволюционирующий стек (Рубрика #AI4SDLC)

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

В пятницу, 7 августа, в 27-м выпуске "Research Insights Made Simple" в прямом эфире разберу AI-разработку как совместно эволюционирующую производственную систему. В этот раз без гостя: хочу собрать в одну картину выводы из последних исследований и инженерных разборов — от hardware-software co-design до agent harness, MCP, evals и production traces.

Главная идея выпуска: преимущество всё реже живёт в одном компоненте. Сильная модель становится продуктом только внутри конкретной среды - с контекстом, примитивами действий, identity, policy и доказательствами результата. А сбой превращается в улучшение, только если команда умеет воспроизвести его, изменить нужный слой и заново пройти проверку.

Поговорим о том:

- Почему не каждый сбой требует новой модели и чем быстрый цикл настройки tools и harness отличается от медленного цикла model и hardware;
- Почему API-совместимость и MCP ещё не дают поведенческой совместимости, корректных полномочий и безопасного эффекта;
- Чем telemetry отличается от evals и training data — и почему production traces не улучшают модель автоматически;
- Где провести границу между арендой, адаптацией и созданием своего: что разумно арендовать у провайдера, что адаптировать, а чем компания должна владеть сама;
- Когда собственная обвязка действительно оправдана, а когда она превращается в дорогую попытку повторить общий агентный цикл.

Для меня главный вывод такой: возможности компании не в модели и не количество MCP-серверов, а скорость доказанного изменения. Увидеть реальный сбой, сохранить эпизод, воспроизвести его, поправить один слой, пройти release gate и безопасно вернуть улучшение в production.

#AI4SDLC #AI #Agents #Architecture #PlatformEngineering #Evals #Engineering
YouTube AI-разработка как совместно эволюционирующий стек Почему одна и та же модель в двух кодинговых агентах даёт настолько разный результат? И что компании действительно стоит считать своим AI-стеком: модель, обвязку, инструменты, данные или право агента менять внутренние системы? В пятницу, 7 августа, в 27…
  • ❤ 4
  • 🔥 2
  • 👎 1
  • 🤔 1
Post #4787 2.96K

This post (sticker, poll or similar) has no web preview. Open in Telegram

  • ❤ 6
  • 👍 5
  • 🔥 3
Post #4786 2.89K
FDE: инженер, которому нужен собственный агент (Рубрика #AI4SDLC)

Посмотрел доклад Vasuman Moza, основателя Varick Agents, с "AI Engineer World's Fair". Обычно Forward Deployed Engineering обсуждают как новую модель AI-внедрения. Здесь интереснее другое: что такой инженер делает руками и какие инструменты нужны уже ему самому.

А воообще FDE (forward deployed engineer) в этом докладе - это инженер, встроенный в команду клиента. Он превращает размытую бизнес-проблему в работающую систему: интервьюирует владельцев процессов и восстанавливает реальную схему работы. Кто сверяет счет с заказом, куда уходит исключение, где дни теряются в ожидании и что вообще нигде не записано. Дальше FDE перепроектирует процесс под AI: этот шаг агент выполняет сам, здесь нужен human-in-the-loop, а здесь решение остается за человеком из-за риска. Затем встраивает агентов поверх NetSuite, Salesforce, Dynamics или SAP, не затевая новую миграцию.

Самая сильная часть доклада - инструменты Varick для собственных FDE:
🤖 Engagement agent собирает заметки Granola, письма, Slack и документы в спецификацию процесса;
🤖 Workflow agent работает рядом с Claude или Codex и напоминает про исключения, владельцев и зависимости;
🎯 Development agent будет разбирать мелкие запросы клиента и обновлять процесс.

Основа - это единый источник правды: граф зависимостей, который, по словам команды, можно хранить даже в Postgres. Поверх нужны поиск контекста, разрешение сущностей, выявление дублей и циклов; ниже - API или computer use для старых систем. В эксплуатации добавляются evals, мониторинг, права, аудит и человеческий контроль.

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

Для меня главный вывод: FDE - это многорукий шива 🤩: системный аналитик, архитектор, продуктовый инженер и консультант в одном лице, отвечающий за production. Его главный инструмент - не модель, а управляемая корпоративная память. Без нее даже сильный агент будет уверенно автоматизировать выдуманный процесс.

#AI #AI4SDLC #Engineering #Agents #Architecture #Management
YouTube AI tools for Forward Deployed Engineering — Vasuman Moza, Varick Agents A customer spent five million dollars and five years migrating to SAP, and has zero appetite to rip anything out again. That constraint is the whole design at Varick Agents: instead of asking an enterprise to migrate, you drop forward deployed agents on top…
  • 👍 7
  • ❤ 3
  • 🔥 1
Post #4785 2.88K
Post #4784 2.79K
Материалы по прямому эфиру с Евгением Сергеевым про то, как строить работающие evals (Рубрика #AI)

Готовы материалы с прямого эфира подкаста Research Insights Made Simple с Евгением Сергеевым:
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка

#AI #Management #Processes #Engineering #Software #Architecture #Evals
polomodov.tech Разбираем построение работающих… — Research Insights Made Simple #26 Интерактивные слайды выпуска Research Insights Made Simple #26: Как превратить evals для AI-агентов из разовой проверки ответа в воспроизводимую инженерную систему…
  • ❤ 7
  • 🔥 3
  • 👍 1
  • 👎 1
Post #4783 2.9K

This post (sticker, poll or similar) has no web preview. Open in Telegram

  • 🔥 20
  • 👍 8
  • ❤ 4
Older posts →
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →