GitHub CEO predicts the future of programming (AI)

Посмотрел на выходных интервью Thomas Dohmk, CEO GitHub, которое у него брал Matthew Berman, известный AI-блогер. Само общение состоялось уже после MS Build, где GitHub анонсировал open source для своего чата внутри VSCode "GitHub Copilot Chat". Основные мысли интервью ниже

1. Влияние GPT и начало Copilot
Генеральный директор GitHub признаёт, что изначально сомневался в работоспособности GPT, но был впечатлён результатами: GPT изменил подход к разработке ПО навсегда. Copilot стал первым массовым инструментом, который завершает код за пользователя, и это оказалось крайне востребованным
2. Статистика и пользовательский опыт
Copilot пишет 25% кода в файлах, где он включён, а уровень удовлетворённости пользователей очень высок (NPS — 72). Интеграция с редакторами (VS Code) и code completion стали точкой входа AI в ежедневную работу разработчика
3. Образование и значимость программирования
Программирование остаётся важным навыком для понимания современного мира, его нужно преподавать детям и взрослым. Основы информатики и умение читать код — это универсальная грамотность будущего.
4. Роль и ответственность разработчика
Даже с появлением copilot агентов инженер должен проверять и подтверждать изменения, чтобы избежать ошибок и проблем с безопасностью. Важно понимать, что делает ИИ-агент, и не терять контроль над кодом
5. Эволюция индустрии и открытый исходный код
Открытый исходный код стал стандартом индустрии, а Copilot теперь доступен как open source для интеграции и доработки сообществом (речь идет про расширение для чата). GitHub и Microsoft делают ставку на использование нескольких моделей ИИ для разных задач, а не на одну универсальную (одну для code completion из-за требований к latency, другую для агентских workflow, где latency не так важно и можно использовать модель поумнее и помедленнее)
6. Будущее разработки: агенты и микро-приложения
Интересная идея о том, что в будущем персональные агенты могут создавать мини-приложения "на лету" для конкретных задач, а операционная система будет скрыта за ИИ-интерфейсом. Пример: автоматизация семейных задач (управление карманными деньгами детей) с помощью Copilot и персонализированных приложений
7. Vibe Coding и ограничения ИИ
Vibe Coding — подход, при котором ИИ помогает быстро воплощать идеи в прототипы, но для серьёзных задач нужны ревью, безопасность и стандарты. ИИ-агенты пока ограничены по объёму обрабатываемого кода, но в будущем смогут работать с большими проектами и тогда вайбкодить станет еще проще.
8. Интеграция и экосистема ИИ-агентов
Ожидается появление экосистемы персональных ИИ-агентов, интегрированных с работой и личной жизнью пользователя. Знания, связанные с работой, будут принадлежать компании, а личные — останутся у пользователя. Чем-то этот концепт напоминает сериал "Разделение", который я не смотрел, но про который слышал.
9. Влияние на рынок труда и новые профессии
ИИ автоматизирует рутинные задачи, но открывает новые профессии и возможности, даже для тех, кто не владеет английским языком. Как и в прошлые технологические революции, часть профессий исчезнет, но появятся новые роли и специализации.
10. Оптимизм в отношении ИИ
Томас выражает оптимизм: ИИ не заменит людей, а поможет решать больше задач, повысит продуктивность и создаст новые возможности для разработчиков

В общем, интервью неплохо показывает как быстро развивается сфера AI-assisted programming и какую роль в этом играет GitHub как лидер индустрии. Основной посыл: AI не заменяет программистов, а делает их более продуктивными, позволяя сосредоточиться на креативных и стратегических аспектах разработки.

#AI #Software #Engineering #Architecture #Agents #Math #Software #ML #Leadership

Measuring Productivity: All Models are Wrong But Some are Useful (Рубрика #Management)

Этот whitepaper от исследователей Google Сьеры Джаспан и Коллина Грина, представляет собой текстовую версию их выступления на DPE Summit (Developer Productivity Engineering). В заглавие статьи они вынесли знаменитую цитату Джорджа Бокса "В сущности, все модели неправильны, но некоторые полезны", которая отлично применима и к вопросам измерения продуктивности инженеров тут к месту. Они рассказывают про принципы и методики, что выработали в Google для преодоления ограничений моделей и получения ценных инсайтов. Эта статья продолжает серию "Developer Productivity for Humans" в журнале IEEE, все статьи из которой рассмотрены в отдельном посте, а дальше поговорим про этот whitepaper.

1. Измерение продуктивности разработчиков — это построение моделей, где необходимо принять, что ни один подход к измерению не способен идеально охватить всю сложность разработки софта. Авторы утверждают, что модели продуктивности часто «опасно избирательны», поскольку опускают важные аспекты работы разработчиков, что приводит к неполным или искажающим оценкам. Важно понимать, что эффективное измерение продуктивности требует комплексного подхода, который охватывает несколько аспектов работы, а не опирается на примитивные метрики вроде количества строк кода или частоты коммитов.
2. Часто такой комплексный подход связан с компромиссами между разными сторонами разработки софта, например, легко ускорить velocity, если выкинуть этап код ревью и тестирования. Для нас это означает, что продуктивность следует рассматривать как баланс между несколькими факторами, в первую очередь скоростью, удобством и качеством, а не как единичный измеряемый результат. Интересно, что в Google этот компромисс представляется в виде треугольника: speed, ease, quality.
3. Исследователи в Google также смотрят и на социологические аспекты, учитывая их совместно с технологическими. Именно этот подход дал название всей серии статей, где измерение продуктивности должно учитывать сложную, творческую природу работы разработчика, а не рассматривать её как чисто механический процесс.
4. В этом исследовании лежит структурированная модель построения систем измерения продуктивности, которая избегает распространённых ошибок. Кажется, авторы используют подход Goals/Signals/Metrics (GSM), про который я уже писал, когда разбирал книгу "Software Engineering at Google", но они прямо об этом не говорят:)
5. Авторы учитывают два противоположных фактора: стремление к простоте (parsymony) и избегание опасной избирательности (worrying selectivity). Парсимония подталкивает к включению меньшего числа компонентов ради простоты, а worrying selectivity требует включения большего числа аспектов для охвата всех важных сторон продуктивности. Исследование советует склоняться к более полному охвату, а не к чрезмерной простоте.
6. Авторы комбинируют в своей методологии качественные и количественные методы, используя данные из инструментальных логов и опросов. Такой смешанный подход отражает их понимание того, что продуктивность разработчиков нельзя полностью охватить только количественными метриками или исключительно субъективными оценками. Вместо этого они предлагают комбинировать разные типы данных для более полного понимания картины. Интересно, что структура их модели учитывает влияние самих измерений на поведение: то, что измеряется, зачастую начинает влиять на поведение сотрудников, иногда вопреки изначальным целям.

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

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

The 4 Patterns of AI Native Development — Patrick Debois (Рубрика #AI)

Вчера посмотрел короткое, но интересное выступление от Патрика Дюбуа, эксперта по DevOps, соавтора "DevOps Handbook", эксперта по интеграции AI в разработку. Это выступление состоялось 4 июня 2025 года на AI Engineer World's Fair 2025 в Сан-Франциско — крупнейшем отраслевом событии, посвященном практическому применению AI в инженерии. Конференция собрала около 1000 основателей, вице-президентов и ведущих инженеров со всего мира (я с большим интересом следил за этой конференцией в прямом эфире, что был доступен на Youtuve).

Ключевые идеи Патрика о том, что мы сейчас в состоянии перехода от обычной разработки к AI Native. По его мнению это похоже на то, как мы все двигались в сторону cloud native, но теперь у нас новая волна изменений. А это приводит к тому, что инженеры меняются в 4 направлениях

1. От производителя к менеджеру.
Разработчики все меньше пишут код сами, вместо этого управляют AI-агентами, которые генерируют код. Время написания кода сокращается, но время на ревью увеличивается — когнитивная нагрузка растет.
2. От реализации к намерениям
Фокус смещается с "как делать" на "что делать". Мы описываем цель и требования, позволяя AI самостоятельно найти решение. Появляются specification-центричные инструменты.
3. От delivery к discovery
Стоимость экспериментов резко снизилась. Теперь можно быстро создавать прототипы, тестировать множественные варианты и исследовать новые идеи, прежде чем принимать решения.
4. От контента к знаниям
AI дает мотивацию систематизировать и сохранять знания команды. Накопленная экспертиза становится конкурентным преимуществом компании, поскольку создание продуктов становится все более автоматизированным.

Если подводить итог, то AI не заменяет разработчиков, а изменяет области, где мы создаем ценность. Понимание этих паттернов поможет инженерам эффективно позиционировать себя и свои команды в меняющемся ландшафте разработки.

#AI #Software #Engineering #Architecture #Agents #Leadership

Надежность на масштабе 50 млн клиентов: опыт Т-Банка для инженеров (Рубрика #SRE)

Сегодня на Хабре вышла статья Алексея Мерсона, бывшего dev advocate нашей платформы Sage. Леша рассказывал про то, как у нас выстроены процессы обеспечения надежности и как они инструментализированы. Ниже я кратко описал основные мысли статьи

- Леша начал с базы, рассказав определение надежности по SRE Book от Google, пирамиду качества (надежность -> UX -> Enjoyment), отметив, что без надежной основы нет смысла говорить об удобстве интерфейсов.
- Дальше пришла пора тройки: SLI/SLO/SLA, а также бюджета ошибок и его связи с каноническими MTTR и MTBF
- Потом Леша рассказал про святую троицу инструментов
-- Sage — единая платформа наблюдаемости, заменившая зоопарк инструментов мониторинга
-- FineDog — система инцидент-менеджмента для учета SLA и здоровья услуг
-- Колобок — инструмент управления релизами с календарем и светофором
- Но инструменты обычно поддерживают процессы, поэтому Леша рассказал про работу с инцидентами: от алертинга с принципом "stateless-инженера" до кризис-менеджмент-планов, а также объяснил как мы разгружаем контакт-центр во время инцидентов
- Вопросы надежности курирует наш центр надежности, который работает над методологией, процессами, делает deep dive по крупным инцидентам и делится со всеми статистикой и интересными инсайтами

Если подводить итог и как-то суммировать то, что полезно сделать в компании почти любого размера и прямо сейчас, то получится следующее
- Стоит заниматься наблюдаемостью независимо от размера сервисов
- Важно наладить работу с инцидентами и научиться писать постмортемы
- Если компания большая, то может потребоваться гибридная схема с центром надежности и ролями chief reliability officers по отдельным бизнес-вертикалям
- Важно держать фокус на клиентском опыте — технологии делаются ради решения задач клиентов
Если же накинуть масштаб Т, то видно, что
- Важна автоматизация всех процессов - нельзя лично поговорить с миллионами клиентов
- Важно собирать и анализировать большие объемы данных
- Важно проектировать отказоустойчиво свои системы и использовать платформенные сервисы (XaaS)

Если говорить про ценность статьи, то она не только разбирает кейс Т в плане надежности, но и демонстрирует комплексный подход к надежности: от технических инструментов до организационных процессов. Это не просто рассказ о том, "как мы мониторим метрики", а системное видение того, как обеспечить работоспособность критически важного сервиса.

P.S.
Интересно, что я недавно выступал с докладом "Надежность и безопасность — это дополнительные опции или фундамент для современных ИТ-систем?" на PHDays и упоминал процессы и инструменты, которые подробно разбирает Леша в этой статье.

#SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering

Code of Leadership #40 - Interview with Vladimir Lazarev about media platforms and SDLC (Рубрика #Management)

В очередном выпуске подкаста ко мне пришел интересный гость, Владимир Лазарев, бывший технический руководитель Т-Ж. Вова живет сейчас в Белграде и мы с ним обсудили его путь в ИТ, работу в Т, а потом отъезд зарубеж и работу в качестве engineering manager и консультанта по инженерным процессам.

За полтора часа мы обсудили много интересных тем
- Введение и знакомство с гостем
- Влияние семьи и самообразование
- Выбор профессии и поступление в вуз
- Опыт в менеджменте и работа в диджитал-агентстве
- Приход в Т-Банк и работа над проектами
- Развитие и модернизация медиа-проектов
- Переезд в Белград и опыт работы в TravelTech
- Обсуждение ухода из ETG
- Советы по саморазвитию и рекомендации по книгам

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

Статьи и контакты Вовы есть на его сайте: https://laidrivm.com/. Пишите Вове, если ищите engineering management/director, или хотите проконсультироваться о менеджменте команд или веб-разработке.
Рекомендации Вовы:
- Книга "Designing Data-Intensive Applications", про которую я уже рассказывал
- Книга "Теоретический минимум по Computer Science", про которую я уже рассказывал
- Книга "Пиши, Сокращай", про которую я уже рассказывал
- Школа Менеджеров Бюро Горбунова
- Сайт о local-first разработке

#Software #Engineering #SRE #Management #Architecture #Processes #Devops #DevEx

Cursor CEO: Going Beyond Code, Superintelligent AI Agents, And Why Teste Still Matters (Рубрика #AI)

Посмотрел интересное интервью Michael Truell с Garry Tan. Они говорили про будущее разработки и это действительно интересно, ведь Майкл — соучредитель и генеральный директор Anysphere, компании, создавшей Cursor, один из самых быстрорастущих AI-инструментов для кодирования. А Гарри — президент и генеральный директор Y Combinator, известного стартап-акселератора. Это интервью было 11 июня и оно проходило во время Demo Day Y Combinator Summer 2025, где представляются новые компании из текущего набора Y Combinator. Ниже представлены ключевые идеи интервью в моей интерпретации

1. Революционное видение будущего программирования
Основная цель Cursor — изобрести новый тип программирования, где разработчики смогут просто описывать желаемый результат, а не писать сложный код. Майкл предвидит, что программисты будут становиться "дизайнерами логики", фокусируясь на высокоуровневом проектировании, а не на написании низкоуровневого кода. Интересно, что раньше часто говорили про языки программирования новых поколений, например, третьим поколением были стандартные C, C++, C#, Java и JavaScript, но люди говорили про четвертое поколение. Но оно особо не полетело:) А теперь новым поколением языков программирования похоже будет plain english/russian/whatever text (но лучше с правильными промптами). Интересно, что Майкл считает, что за следующие 5-10 лет произойдет значительное изменение в способах создания софта.

2. Текущее состояние AI в программировании
Наибольшие изменения уже заметны в небольших кодовых базах, где разработчики могут работать на более высоком уровне абстракции. В среднем разработчики используют AI для написания 40-50% кода в Cursor, но все еще требуется человеческий контроль и понимание. Майкл говорит о том, что vibe coding пишется без глубокого понимания и не рекомендуется для долгосрочных проектов (а для прототипов он отлично подходит)

3. Технические вызовы и ограничения
Ограниченный размер контекстного окна AI затрудняет работу с большими кодовыми базами, содержащими миллионы строк кода (что типично для больших компаний). Существующие модели испытывают трудности с непрерывным обучением и сохранением контекста организации и предыдущих решений. AI-модели пока не имеют четкого представления об эстетике, что требует участия человека-дизайнера.

4. История и эволюция Cursor
Команда основателей из MIT первоначально работала над AI для автоматизированного проектирования (CAD), но позже переключилась на программирование. GitHub Copilot и исследования OpenAI о масштабируемости моделей стали ключевыми источниками вдохновения для создания Cursor. Вместо создания расширения для условного VSCode команда решила разработать собственный редактор, что оказалось важным преимуществом.

5. Рост и успех компании
Anysphere достигла оценки в 9,9 миллиардов долларов после привлечения 900 миллионов долларов инвестиций. Компания достигла 100 миллионов долларов годового дохода всего за 20 месяцев после запуска, а затем выросла до 300 миллионов за два года и более 500 миллионов к середине 2025 года. Cursor используется в крупных технологических компаниях, включая OpenAI, Stripe, Spotify и других.

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

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

#AI #ML #Software #DevEx #Engineering #Development

[1/3] Enabling the Study of Software Development Behavior With Cross-Tool Logs (Рубрика #Management)

Прочитал наконец-то исследование, вышедшее в 2020 году, где авторы из Google рассказали про создание своей системы InSession, которая позволяет проводить комплексный анализ поведения инженеров путем интеграции логов от множества инструментов разработки. Ценность исследования в том, что разработчики - это одна из самых затратных частей разработки софта, поэтому даже небольшие улучшения продуктивности могут принести значительные результаты. InSession отличалось от других подобных инструментов тем, что собирало не только данные из IDE, но и не требовало установки на рабочие машинки инженеров (данные собирались из существующих облачных инструментов).

Если говорить про саму систему, то она состояла из следующих ключевых частей
1. События (Events)
Событие - это отдельное использование инструмента или системы разработчиком или от имени разработчика. Для каждого типа логов был свой импортер, который трансформировал данные в общий формат событий. Сами события были разных типов
- Фронтенд-события: инициируемые разработчиком активно (например, нажатие кнопки интерфейса)
- Бэкенд-события: происходящие асинхронно от имени разработчика (например, cron-задания)
- Мгновенные события: с неопределенной конечной точкой
- Длительные события: с установленным временем начала и окончания
2. Артефакты
Для большинства событий собиралась еще дополнительная метаинформация, которую авторы называли артефактами. Они были двух типов
Идентифицирующие задачу артефакты: идентифицируют конкретную задачу разработки для группировки связанных событий
Информационные артефакты: предоставляют контекстную информацию о событии
3. Сессии
Собственно события объединялись в сессии при помощи группировок, которые
- Происходят в один день
- В течение временного интервала (10 минут)
- Имеют одинаковые идентифицирующие задачу артефакты (или не имеют никакую)
4. Метрики
Система выводит семь ключевых метрик поведения разработчиков:
- Время кодирования - время написания или maintaining кода
- Время рецензирования - время на ревью кода
- Время сопровождения (shepherding) - время на доработки кода по результатам обратной связи с code review
- Время исследования - время на изучение документации
- Время разработки - время на разработческие активности любого типа (что не покрыты другими категориями)
- Время работы с электронной почтой
- Время, проведенное на встречах

Если говорить про источники данных для InSession, то это множество инструментов, включающих
- Buganizer - система отслеживания ошибок
- Code Search - инструмент поиска и просмотра кода
- Cider - веб-IDE
- Blaze - распределенная система сборки
- Critique - инструмент рецензирования кода
- Gmail и Calendar - здесь тянулись ограниченные метаданные
- Еще более 90 инструментов командной строки

Продолжение обзора этой интересной статьи в следующем посте.

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes