Конференция The Pragmatic Summit прошла 11 февраля 2026 года в Сан-Франциско. Организатор: Gergely Orosz, автор The Pragmatic Engineer.

Илья Чекун, backend-инженер в FinTech, активный участник сообщества и спикер на мероприятиях Hard&Soft Skills и выпускник курса [Технический Лидер] посетил эту конференцию и поделился своими заметками и выводами.

Какие выступления удалось посетить:

1. Welcome Inside OpenAI: How AI is reshaping the craft of building software
2. Data vs Hype: Data vs hype: how orgs actually win with AI
3. Lessons from Building Vercel vo and the do Agent
4. Frameworks for ICs: Engineering Practices that Make Coding Agents Work
5. Leading High-performing Engineering Teams in the Age of Al
6. What's Next: Building World-class Engineering Orgs in the Age of Al

Еще удалось лично поговорить с организатором об AI-интеграции в европейских и швейцарских компаниях.

1. Боттлнек сместился вверх по стеку
Генерация кода — почти commodity. Настоящие ограничения теперь выше: формулирование задачи, написание спеков, понимание потребностей пользователя. И ниже: code review, CI, деплой, верификация. Тот, кто научится работать с этими боттлнеками — выиграет.

2. Adoption ≠ Impact, и это не технический вопрос
92% используют AI-инструменты, но только ~5% организаций достигают реальной трансформации. Барьеры — не в моделях, а в change management, отсутствии executive sponsorship и слабом developer experience. AI усиливает то, что уже есть: здоровые организации становятся лучше, дисфункциональные — хуже и быстрее.

3. Роли размываются — центр тяжести смещается вверх
PM пишут код, дизайнеры шипают в продакшн, инженеры оркестрируют агентов. Фокус уходит от деталей реализации к вопросу «что на самом деле нужно пользователю?». Быть T-shaped и мыслить на уровне системы и продукта — новый минимум для инженера.

4. DevEx и AgentEx — это одно и то же
Всё, что делает хорошую среду для разработчиков (тесты, документация, быстрый CI, чистые сервисы) — делает AI эффективнее. Это аргумент, который наконец-то работает на получение бюджета. Называй это «agent experience» — и деньги появятся.

5. Качество важнее скорости, особенно сейчас
Чем больше кода генерируется, тем выше соблазн пропустить качество. Это ловушка. Тестирование, верификация, security — становятся критически важнее, а не менее важными. «Closing the loop» — то, что отличает maintainable систему от хаоса.

6. Никто не знает ответов — и это нормально
Martin Fowler и Kent Beck назвали AI самой disruptive технологией за их карьеры. Даже люди с frontier AI стартапов не разобрались, как эффективно использовать LLM на уровне организации. Правильная позиция: оставаться скептичным, но скептичным и к собственному скептицизму. Держать голову в режиме exploration.

Спикеры:
Tibo Sottiaux (Head of Engineering, Codex, OpenAI)
Vijaye Raji (CTO of Applications, OpenAI)

1. Codex как тиммейт

Ключевые тезисы:

• Эволюция за 6 месяцев: tool → extension → agent → teammate
• Инженеры начинают давать агентам имена и воспринимать их как коллег
• Топ-пользователи внутри OpenAI — сотни миллиардов токенов в неделю на одного инженера
• Запущен Codex Box — возможность резервировать dev-боксы на сервере, запускать промпты, закрывать ноутбук и уходить; работа выполняется в фоне
• Параллельная работа множества агентов одновременно — новая норма

Яркая формулировка: "Люди ходят на встречи, возвращаются — работа уже сделана"

2. Как работает команда Codex день за днём

Ключевые тезисы:

• Команда постоянно переизобретает свои процессы — почти еженедельно
• Боттлнеки смещаются: сначала генерация кода → затем code review → сейчас: понимание потребностей пользователей (анализ Twitter, Reddit и др.)
• Впервые кандидат на собеседовании спросил: "Сколько compute я получу?" — новый тип вопроса, раньше был удел только исследователей
• Еженедельный analytics review: вопросы, не закрытые дашбордами, отправляются в Codex-треды прямо во время митинга; ответы приходят через 20 минут

Практический вывод: Запускать Codex-треды в фоне во время совещаний для анализа данных в реальном времени.

3. Новые инженерные практики

Ключевые тезисы:

• Вместо design doc → параллельное прототипирование нескольких реализаций с последующим выбором лучшей
• Роли размываются: дизайнеры шипят больше кода, чем инженеры шипали 6 месяцев назад
• Качество генерируемого кода достаточно высокое, чтобы мержить as-is
• Codex как замена памяти на CLI-команды (пример: ffmpeg — никто не помнит флаги, просто описываешь задачу)
• Code review, security review — следующие фронты автоматизации
• Глубина хакатонных демо постоянно растёт: уже не «что возможно», а «готовый продукт с учётом corner cases»

Практический вывод: Не изучать наизусть команды CLI — делегировать составление команд Codex.

4. Overnight-прогоны и самотестирование

Ключевые тезисы:

• Codex запускается ночью в автономном режиме и выполняет QA в цикле
• Сам находит регрессии, без участия людей
• Исследователь команды, обучающий модели: регулярно обнаруживает, что Codex способнее, чем он думал — просто не так промптил или не так настроил среду
• Один из исследователей передал Codex полное обучение модели самостоятельно; на выходе — PDF-отчёт с выводами и самыми перспективными направлениями для следующей итерации

Яркая формулировка: "Это одновременно захватывает и немного угнетает" (о том, что Codex оказывается способнее, чем ожидалось).

5. Новые грады и онбординг

Ключевые тезисы:

• OpenAI активно нанимает new grads прямо из университетов
• Летом 2025 — первая большая волна: ~100 человек + расширенная интернатура
• Ставка на AI-native поколение: они освоят инструменты нативно с первого дня
• Онбординг организован самими недавно онбордившимися — самые свежие знания у них
• Codex ведёт онбординг: новички задают вопросы Codex, изучают кодовую базу через него, получают ежедневные отчёты
• Пример: new grad Ахмед пришёл 6 месяцев назад, «абсолютно crushes it»

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

6. Новая роль software engineer

Ключевые тезисы:

• Фундаментальные знания остаются важными — не выйдут из моды никогда
• Параллель с историей: assembly → C++ → JavaScript → каждый раз говорили «настоящий разработчик так не делает», каждый раз абстракция побеждала
• Важно: product intuition, понимание что строишь, умение ходить по стеку вверх-вниз
• VJ работал над IntelliSense в Visual Studio — та же дискуссия была и тогда
• Скорость gratification cycle резко выросла — это делает разработку более увлекательной

Яркая формулировка: VJ: "Интеллисенс — а раньше говорили: ты не настоящий разработчик, если используешь подсказки"

7. PM и дизайнеры

Ключевые тезисы:

• Пока строим продукты для людей — человеческий дизайн и product sense незаменимы
• PM и дизайнеры пишут код, создают прототипы до обращения к инженерам
• PM Александр Эмберос (единственный PM на всю команду Codex): организовал bug bash → Codex собрал фидбэк → сформировал Notion-doc → автоматически создал тикеты в Linear → назначил исполнителей → следит за прогрессом
• Пример гиперлевереджа: один PM работает за команду из 50 человек

Практический вывод: Один хорошо оснащённый PM с Codex может закрывать объём работы, требовавший команды.

8. Вопрос стоимости токенов

Ключевые тезисы:

• Внутри OpenAI — безлимитные токены бесплатно; снаружи — реальная стоимость
• Tibo: не ограничивайте лучших людей преждевременно — это риск
• Новый фрейм: думать не «сколько токенов», а «сколько стоит тиммейт 24/7»
• Если считать в терминах продуктивности (4–5 AI-тиммейтов на инженера) — экономика выглядит иначе
• Codex уже заменяет работу, которая раньше требовала 15 инженеров (например, разбор бэклога)

Практический вывод: Переосмыслить ROI токенов как стоимость найма дополнительного тиммейта, а не как статью расходов на инфраструктуру.

Спикер: Laura Tacho, CTO

1. Введение: аналогия с космической гонкой

Ключевые тезисы:

• Параллель: возраст AI = возраст космической экспансии — такое же сочетание восторга и скептицизма
• Скептицизм обоснован: реальный экономический эффект AI неоднозначен, есть экологические и финансовые издержки
• Цель космоса была не колонизация луны, а улучшение жизни на Земле — так же и с AI: не хайп ради хайпа, а решение реальных проблем
• Нужно балансировать sense of wonder с прагматизмом и данными

Яркая формулировка: «Somewhere, something incredible is waiting to be known» — Carl Sagan

2. Новые отраслевые бенчмарки 2026

Ключевые тезисы:

• Выборка: 121,000 разработчиков, 450+ компаний, ноябрь 2025 — февраль 2026
• 92.6% используют AI coding assistant хотя бы раз в месяц; 75% — раз в неделю
• Самоотчётная экономия времени: ~4.08 часа/неделю — не меняется принципиально с Q2 2025 (~10% прирост производительности, совпадает с данными Google)
• AI authored code (мержится без значимого вмешательства человека): 26.9% — выборка 42,600 разработчиков
• Рост с 22% за предыдущий квартал — значимое квартальное изменение
• Среди ежедневных пользователей AI: >30% кода пишется AI и попадает в продакшн

Практический вывод: Используй эти цифры как отраслевой baseline для сравнения с твоей организацией.

3. Онбординг: самый сильный use case

Ключевые тезисы:

• Метрика: time to 10th PR — отраслевой стандарт milestонa онбординга
• С Q1 2024 по Q4 2025 — сокращение в 2 раза, коррелирует с ростом AI-adoption
• Работает не только для новых сотрудников: также для тех, кто переходит между проектами, и для нон-инженеров
• Исследование Microsoft (Brian Hulcat, SPACE framework): производительность с time to 10th PR сохраняется на 2 года после онбординга

Практический вывод: Приоритизируй AI для онбординга — ROI здесь особенно высок и долгосрочен.

4. Почему средние значения вводят в заблуждение

Ключевые тезисы:

• Average ≠ typical — по мере расхождения полюсов среднее остаётся неизменным
• Не существует «типичного опыта» с AI — каждая компания уникальна
• AI как акселератор → big bang эффект: организации разлетаются в разные стороны от своей исходной точки
• Примеры расхождения качества (выборка 67,000 разработчиков, тот же период):
• Часть организаций: в 2 раза больше customer-facing инцидентов
• Другая часть: на 50% меньше инцидентов + выше скорость + выше качество кода
• AI усиливает то, что уже есть: здоровые системы → лучше, дисфункциональные → дисфункциональнее и быстрее

Яркая формулировка: «Dysfunctional and dysfunctional faster»

5. Высокое adoption, низкая трансформация

Ключевые тезисы:

• MIT study «The Gen AI Divide» (июль 2025, 152 организации): высокое adoption + низкая трансформация
• Трансформация некомфортна — организации, которые сдавались на cloud и agile трансформациях, сдаются и на AI
• Причина: инструменты применяли только к индивидуальным coding-задачам разработчика — очень низкий потолок продуктивности
• Adoption ≠ impact: выдать лицензии всем и надеяться на лучшее («spray and pray») не работает
• Нужен organizational level подход, а не individual level
• Агентские workflows расширяют возможности — но и хайп вместе с ними

Практический вывод: Переосмысли AI-стратегию: от «инструмент для кодинга» к «решение организационных проблем».

Яркая формулировка: «High adoption, low transformation»

8. AI не решает организационные проблемы сам по себе

Ключевые тезисы:

• Главный вывод: AI не решает системные и человеческие проблемы организации
• Можно применить AI к проблеме — но сначала нужно признать, что проблема существует
• Если не решить системные проблемы — мы возьмём их с собой «в космос»
• Барьеры к AI adoption (MIT study): не технические — change management, отсутствие executive sponsorship, плохой UX, неясные ожидания

Яркая формулировка: «We will just take them to space with us»

2. Проблема «параллельных инициатив»

Ключевые тезисы:

• Типичный паттерн: в компании есть публичная AI-инициатива, но она существует как standalone-проект, отдельно от обычных рабочих процессов
• Рядовые сотрудники либо получают информацию поздно, либо вообще не знают деталей
• Это подтверждается как личным опытом, так и наблюдениями Gergely из общения с европейскими инженерами
• Перекликается с выводом MIT study: high adoption, low transformation — именно потому что инициативы не встроены в реальные процессы

Практический вывод: AI-инициатива, изолированная от ежедневной работы сотрудников, обречена оставаться витриной.

Спикеры:
Malte Ubl, CTO, Vercel
Steve Huynh, Creator of A Life Engineered

1. Лучший агент — это почти нет агента
DZero (внутренний text-to-SQL агент Vercel) v1: традиционная архитектура «tools in a loop», десятки инструментов, много кода — работало, но не магически. v2: удалили всё, оставили два инструмента — bash и execute SQL. 50 строк кода. Ключ: сделать задачу похожей на coding task (YAML с бизнес-семантикой каждой колонки Snowflake) — модели оптимизированы под код, и это даёт непропорционально хорошие результаты.

2. В мире агентов нет «best practices» — только текущие практики
То что было лучшей практикой летом 2025 — мало значит сегодня. Агентам от силы три года. Нужна humility: быть готовым выбросить всё и начать заново как только появляется лучший способ. Это не pivot (pivot = ошибка в данных), это адаптация к тому что мир вокруг изменился — Anthropic выпустила Sonnet 3.5 и тот же промпт внезапно строит full-stack приложения.

3. Vercel — это «где запускать» всё что создаётся агентами
Позиция продукта в мире AI не меняется фундаментально: «Больше земли не делают» — любой инструмент генерации кода (Claude Code, Cursor, Lovable) в какой-то момент нужно деплоить. Vercel коннектится к git-репозиторию и каждый push → новая версия в продакшене. CTO не боится obsolescence на уровне инфраструктуры.

4. Главная нерешённая проблема: trust model для vibe-coded приложений
Профессиональный разработчик → можно доверять что он добавит OAuth, RBAC, базовую безопасность. AI-coded приложение от не-разработчика → нельзя доверять: AI прекрасно понимает что такое OAuth, но через 15 промптов на новом роуте забудет добавить защиту. Как запустить в продакшен дашборд выручки сделанный секретарём P&G без того чтобы она случайно опубликовала данные в интернет? Malte тратит на этот вопрос почти всё время.

5. Инфраструктурная надёжность через автономность регионов
Vercel: 20 регионов, намеренно без механизма синхронного изменения всех регионов сразу. Конфиг-изменения — волнами. Вывод из опыта Google и анализа CloudFlare outage: катастрофические аутажи = всегда либо bad config change либо проблема с secrets management service. Решение: физически невозможно сломать всё одновременно.

6. Будущее за «правее кода»: тестирование и production management
Писать тесты стало дешево — их ценность выросла. Malte: bullish на всё что после написания кода — тестирование, стабильность тестов, продакшн мониторинг. Мечта: агент замечает ошибку в продакшне и сам присылает PR с исправлением. Не bullish на инструменты которые помогают написать тест — это coding agent уже умеет.

Спикеры:
Simon Willison, Open Source Dev
Eric Lui, Infra Lead, Statsig

1. TDD — единственный надёжный способ доверять AI-коду
Начинай каждую сессию с агентом с команды run tests + use red green TDD. Агент пишет тест → смотрит как он падает → пишет минимальную реализацию → проходит. Тесты теперь бесплатны — нет ни одной причины их не писать. Без тестов агент — это лотерея.

2. Стадии AI-adoption: не читать код — это следующий уровень
Путь разработчика: ChatGPT для вопросов → агент пишет куски кода → агент пишет больше кода чем ты → ты не пишешь код вообще → ты не читаешь код вообще. Последний уровень требует серьёзной работы над верификацией и доказательством корректности — это и есть новая работа инженера.

3. Качество кода — это выбор, а не данность
Если агент выдал 2000 строк плохого кода и ты это принял — это твой выбор. Можно попросить агента отрефакторить — и получить код лучше, чем написал бы сам, потому что у агента нет усталости. Для disposable одностраничных утилит качество не важно. Для долгосрочных проектов — критично.

4. Prompt injection — реальная угроза, решение — sandboxing
Lethal trifecta: доступ к приватным данным + воздействие вредоносных инструкций + канал экфильтрации. Лучшая защита — отрезать одну из ног. Практическое решение: Claude Code for Web запускается в контейнере Anthropic, худшее что может случиться — кто-то уничтожит чужую VM. Для чувствительных данных — моки, не продакшн данные.

5. Не предсказывай будущее — исследуй текущие модели глубже
Каждый раз когда модель не справляется с задачей — запомни и попробуй через 6 месяцев. Важнее не ждать следующую модель, а разобраться что умеет текущая, что мы ещё не открыли. Опус 4.6 — Simon oneshots практически всё, и это произошло буквально на прошлой неделе.

6. AI не вызывает деградацию навыков — если осознанно подходить
Работа с агентами умственно изматывает — это противоположность лени. Одновременно вести 3 проекта чтобы заполнять время пока агент думает — реальная практика Simon. Деградация навыков — это выбор: можно использовать AI как репетитора 24/7, а не как замену мышлению.

8. Боттлнек в open source — не генерация кода, а валидация
AI резко увеличивает количество контрибьюций, но review capacity мейнтейнеров не масштабируется автоматически. Большой AI-сгенерированный PR невозможно нормально проревьюить — такие PR закрываются. Open source страдает первым и пока не знает, как с этим жить.

9. AI парадоксально ускорит open source, а не убьёт его
Несмотря на боттлнек валидации, AI сделает создание и развитие open source проектов значительно доступнее. Больше компаний будут начинать разработку продукта с open source основы — тренд, который уже набирает силу (пример: Thomas Dohmke, бывший CEO GitHub).

10. Coding с телефона — это уже реальность
Simon Willison начал сессию с того, что разрабатывает свой сайт с телефона, общаясь с Claude только на английском языке. Полное делегирование низкорискованных задач без написания кода вручную. Это освобождает руки продуктовым людям без глубокого технического бэкграунда.

11. «Отпустить поводок» — но только там, где это безопасно
Полное делегирование AI допустимо только на задачах с низким риском. Simon осознанно разграничивает: где можно отпустить и дать Claude полный цикл, где нельзя. Это не про доверие AI в целом — это про понимание границ применимости.

12. Trust не масштабируется вместе с contributions
Проблема open source — не техническая. AI позволяет любому человеку сгенерировать внешне качественный PR в незнакомый репозиторий. Но мейнтейнер не знает, кто этот человек и можно ли ему доверять. Возникает потребность в инструментах оценки репутации контрибьютора до начала review (упоминался Vouch).

13. AI демократизирует продуктовую разработку
Когда продуктовый человек может описать фичу на английском и получить рабочий результат — барьер между «умею думать о продукте» и «умею строить продукт» исчезает. Это меняет кто может быть builder'ом.

Спикеры:
Nicole Forsgren, Author, Frictionless
Gergely Orosz, Author, The Pragmatic Engineer

1. Inner loop ускорился — outer loop рвётся
AI ускорил написание кода (inner loop), но обнажил все узкие места downstream: code review перегружен, deployment процессы управляются людьми и не масштабируются, onboarding не адаптирован под скорость с которой новый сотрудник может начать коммитить. Раньше эти проблемы были «нормально», теперь они «на огне».

2. Производительность — это не PRs в неделю
Измерять productivity нужно отвечая на вопрос: что именно вы хотите знать? Lines of code и PR count — сигнал о чём? Помогает ли это фиче попасть к клиенту быстрее? Правильная ли это фича? Полезен SPACE framework (Satisfaction, Performance, Activity, Collaboration, Efficiency) — он даёт несколько измерений вместо одного. Скорость без quality guardrails — путь к тому что «что-то сломается».

3. Adoption metric — первый шаг, но недостаточный
Adoption даёт ранний сигнал (разработчики не будут пользоваться плохим инструментом — они поднимут Jenkins за $20), но не говорит об impact. Нужно смотреть на engagement, на какие задачи используется инструмент, и на end-to-end flow — от идеи до клиента, не только inner loop.

4. Cognitive load растёт вместе со скоростью feedback
Парадокс: быстрые feedback loops — это хорошо. Но если агент возвращает результат быстрее чем ты успеваешь перестроить ментальную модель — это перегрузка. Мозг человека способен на 3-4 часа реально глубокой работы в день (Gloria Mark). Вопрос: как использовать эти часы максимально эффективно с агентами? Разные люди находят разные ответы (Hashimoto: агент всегда запущен, но уведомления отключены).

5. Высокоэффективные команды имеют те же характеристики что и раньше
Психологическая безопасность, любопытство, готовность рисковать и не скрывать ошибки — важнее чем когда-либо. Труднее всего адаптируются те кто жёстко идентифицировал себя с конкретным видом выдаваемого кода. Легче — кто понимает что его ценность шире чем «typing the code».

6. Для frictionless будущего нужна observability — для людей и для агентов
Агенты не смогут self-improve систему которую не видят. Люди не смогут принимать решения о системе которую не видят. Первый шаг: определить touch points которые важно отслеживать → сделать их дёшево и легко достижимыми → научиться sense-making вокруг них. Это меняется по мере эволюции процесса.

Спикеры:
Rajeev Rajan, СТО, Atlassian
Thomas Dohmke, Co-Founder & CEO of Entire

1. AI-native — это про mindset, а не про инструменты
Лучшие AI-native разработчики намеренно заставляют себя не смотреть в код — работают через промпты, intent и reasoning. Это навык сам по себе. Code review тоже уходит от чтения строк к верификации inputs/outputs и guard rails.

2. Боттлнек сместился: «левее» и «правее» кода
Генерация кода почти бесплатна. Узкие места теперь: слева — планирование, спеки, формулировка intent (Confluence, Jira, Loom); справа — CI/CD, деплой, инциденты, code review. Atlassian называет это AI-native SDLC — от идеации до продакшна.

3. Роли схлопываются: PM → product engineer, designer → design engineer
PM уже обязаны использовать coding agent для прототипа вместо документа. Дизайнеры пишут код. Venn diagram ролей перекрывается всё сильнее. Но без product sense и архитектурного мышления получится Homer Simpson car — продукт со всеми фичами из бэклога и без смысла.

4. Агенты дали удалённым командам новое преимущество
Coding agent, brainstorming agent, code review agent — всегда доступны, в любом часовом поясе. Thomas: агенты выровняли конкурентный разрыв между офисными и распределёнными командами. Atlassian строил distributed-first задолго до COVID.

5. Span of control растёт, менеджеров станет меньше
Rajeev: 33 прямых подчинённых (как у Tibo в OpenAI) — уже реальность. Jensen Huang говорит о 40–50. Менеджеры станут ближе к коду, дальше от чистого управления. Совет Rajeev молодым: не становись менеджером, пока не вынужден.

6. Coding is fun again — и это важнее метрик
Главный эмоциональный тезис обоих спикеров: агенты вернули радость от программирования. Не нужно тратить час на npm error или настройку Xcode. Thomas за одну сессию у OpenAI собрал три нативных Mac-приложения на SwiftUI, не глядя в код.

7. AI усиливает существующую культуру
Дисфункциональные организации становятся дисфункциональными быстрее.

8. Немецкие и японские компании всё ещё не в облаке
Agent adoption у них ещё медленнее.

9. Переломный момент для CTO крупных банков
Дать агентам задачу на ночь, проверить утром — две недели такого и понимаешь, что всё нужно менять.