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

Илья Чекун, backend-инженер, участник сообщества 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 prey») не работает
• Нужен 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»

В средних командах (11–50 человек) данные показали меньше значимых эффектов.

Причины две — и обе связаны с математикой, а не с “отсутствием связей”:

1. Дисперсия метрик (разброс оценок) там ниже.
Команды среднего размера уже стабилизировались: процессы выровнены, оценки становятся более однородными — “всё работает нормально”.

А значит разница между “есть практика” и “нет практики” становится менее выраженной — эффекты сглаживаются.

2. Статистическая мощность меньше при слабых сигналах.

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

Это не значит, что связи отсутствуют — просто они не превышают порог статистического обнаружения.

Некоторые практики заметно влияют сразу на несколько ключевых метрик:

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

Для анализа использовали модель Random Forest Regressor (500 деревьев, min_samples_leaf=2, OOB-оценка включена).

Модель обучалась предсказывать общий индекс зрелости (Overall Maturity) по степени внедрения практик в каждом блоке.

После обучения получено:

• R² (train) = 0.94,
• OOB = 0.76,

Это говорит о высокой объясняющей способности модели — она описывает около 76% вариации зрелости между командами.

Главный источник роста зрелости — тестирование.

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

Безопасность и CI/CD следуют сразу за тестированием. Там, где защищены секреты и стандартизованы пайплайны, стабильность релизов и качество инцидент-менеджмента выше.

Документация и ADR — удивительно сильный фактор. Даже при умеренных значениях ΔR² ≈ 0.1 они стабильно поднимают общий индекс.

Эти четыре блока объясняют более 80 % вариации зрелости. Поэтому их можно считать основными точками приложения усилий.

Ниже всех свой проект оценивают разработчики. Средний балл 5.32

СТО смотрят более радужно. Средняя оценка 5.9

Тимлиды — самые оптимисты. Они оценивают свои проекты на 6.06

Максимальное отклонение:

• Качество алертинга: разработчик -0.73, СТО +0.69. Видимо, СТО не знает того, что знает разработчик.
• Готовность вкладываться в улучшения: разработчик -0.9, Тимлид +0.86. Вероятно, потому что отдуваться придется разработчику.
• Качество ревью: разработчик -0.67, тимлид 0.89. Если бы разработчики ревьювали тимлидов — оценки бы может и изменились :)
• Только тестам разработчики доверяют чуть больше, +0.1, против -0.17 у лидов.
• И ко внешним специалистам у разработчиков немного больше доверия — +0.17, против -0.43 у СТО

Ниже — практики с наибольшим практическим эффектом по данным опроса.

Столбец ROI отражает соотношение ожидаемого прироста зрелости к усилиям на внедрение (сколько пунктов зрелости потенциально может принести 1 затраченный час).

В краткосрочной перспективе выигрывают организационные шаги (паспорт PR, DRI, онбординг). В долгосрочной — инфраструктурные (SLO, централизованные секреты, CI/CD-стандарты).

ROI больше 1 — выдающийся результат. Мгновенная отдача. Практика даёт кратный эффект при минимальных усилиях.

Больше 0.3 — заметный прирост при умеренных усилиях. Стоит внедрять в первую очередь.

Больше 0.1 — полезно, но эффект проявляется позже или требует инфраструктуры.

Меньше 0.1 — эффект есть, но не мгновенный. Такие практики дают отдачу в долгую.

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

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

Поэтому зрелость растёт не линейно, а распространяется волнами через культуру и инфраструктуру.

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

Отсюда следует закономерное выравнивание процессов: чем крупнее команда, тем меньше разброс оценок и больше предсказуемости.

Зрелая инженерная команда — это не та, где всё автоматизировано, а та, где процессы предсказуемы, прозрачны и воспроизводимы. Где каждый понимает, почему система работает именно так, и может объяснить это другому.

Главная цель не “сделать CI/CD” или “внедрить SLO”, а построить экосистему, где улучшения масштабируются сами.

Когда система устойчиво растёт без героизма — это и есть настоящий уровень инженерной зрелости.

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