Джереми Фриман, сооснователь и технический директор Allstacks – Интервью

Джереми Фриман, сооснователь и технический директор Allstacks, является软件-инженером, технологическим архитектором и предпринимателем с карьерой, охватывающей разработку программного обеспечения, аппаратную инженерию, машинное обучение и инновации в области продуктов. С момента основания Allstacks в 2017 году он возглавлял архитектуру и разработку основной платформы компании, помогая трансформировать управление доставкой программного обеспечения с помощью прогностической аналитики и прогнозирования, основанного на ИИ. До Allstacks Фриман занимал руководящие должности в Ravioli Labs и CertiRx, где он работал над разработкой программного обеспечения, исследованиями, технологиями противодействия подделкам и разработкой продуктов. Ранее в своей карьере он получил опыт работы в стартапах, фирмах по разработке программного обеспечения и в академии, включая преподавание веб-разработки в колледже Уэйк Тех. Его технический опыт охватывает встроенные системы, проектирование аппаратуры, крупномасштабные программные платформы, машинное обучение и лидерство в области инженерии, что дает ему уникальную точку зрения на создание данных-ориентированных продуктов, помогающих организациям улучшить результаты доставки программного обеспечения.

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

У вас была уникальная карьера – от руководства исследовательскими и инженерными командами, применяющими машинное обучение к данным разработки программного обеспечения, до сооснования Allstacks в 2017 году. Какие конкретные пробелы или повторяющиеся проблемы вы наблюдали, что в конечном итоге заставило вас создать компанию?

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

Очень быстро стало ясно, что это не проблема отчетности или интеграции. Это была проблема отношений. Чтобы знать, находится ли что-то под угрозой, вам нужно знать, как элемент работы связан с веткой, ветка связана с запросом на вытягивание, запрос на вытягивание связан с целью спринта, а цель спринта связана с бизнес-инициативой. Этот граф не существует по умолчанию в стандартном инструментарии. Вам нужно его построить. И построить его хорошо – это фундаментально проблема вывода, где полезен опыт работы с машинным обучением.

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

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

Я не думаю, что существует единственный набор метрик, который предсказывает хорошее и плохое, а скорее закономерности для разных фаз и типов организаций. То, что я нашел более полезным, – это признание того, что инженерные организации проходят через сезоны улучшения. В этом месяце это производительность базы данных. В следующем месяце – межкомандная связь. Затем – “почему мы не можем закрыть ни один запрос на вытягивание?” Затем – наблюдаемость. Как лидер инженерии, вы плаваете в сигналах: некоторые диагностические, некоторые мониторинговые, и многое из того, что просто шум.

Что помогает, так это начало с проблемы, которую вы фактически видите, а не с метрики, которую вы хотите улучшить. Если вы спрашиваете “почему кажется, что мы доставляем меньше, чем в прошлом году”, это правильная отправная точка. Оттуда, я думаю, вам нужно три типа метрик: первое, как вы знаете, что проблема реальна (может быть, количество запросов на вытягивание на разработчика за время); второе, какие изменения вы делаете и как вы отслеживаете их на пути (скажем, принятие обзора запросов на вытягивание с помощью ИИ, если это ваше вмешательство); и третье, насколько значима эта проблема для бизнеса. Ваша интуиция может быть правильной, что вы доставляете на 20 процентов меньше кода, но реальная история может быть в том, что теперь тестирование занимает в три раза больше времени. Вам нужно все три линзы, чтобы знать, решаете ли вы правильную проблему.

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

Я очень ценю свой опыт в секторах, не связанных напрямую с технологиями. В компаниях SaaS легко потеряться в идее, что программное обеспечение само по себе является целью. Когда вы находитесь в бизнесе, где вы не直接 продаете программное обеспечение, ваша роль становится намного яснее: технология существует для поддержки бизнеса. Я часто шучу, что если бизнес мог бы достичь всего с той же скоростью, не имея дела со мной, они бы выбрали этот вариант без колебаний.

Эта точка зрения на самом деле полезна. Она контекстуализирует то, что мы все делаем в этой отрасли, и она возвращает многие технологические дебаты на их место. Бизнес не заботится, используете ли вы Python или Go. Тратя циклы на этот рефакторинг, вероятно, не там, где реальная отдача.

Что остается постоянным во всех отраслях, так это проблема фрагментации. Независимо от сектора, каждая инженерная организация имеет данные, разбросанные по десятку инструментов с ограниченной связью между ними. Конкретные детали варьируются: регулируемые отрасли имеют более длинные циклы планирования и более низкую толерантность к неопределенности в требованиях, потому что стоимость построения неправильной вещи выше. Высокоскоростные технологические компании накапливают скрытый долг быстрее. Но основной режим отказа один и тот же. Команды могут рассказать вам, что было доставлено. Они не могут отследить, почему что-то сдвинулось, что это стоило или где риск был виден до того, как он стал проблемой. Это то, что сформировало, как мы построили платформу.

Существует растущий нарратив, что ИИ ускоряет сам процесс кодирования, одновременно раскрывая слабости в других местах. Почему требования, планирование и готовность спецификаций становятся реальными бутылками?

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

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

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

Соблазн сейчас – обойти все это. Но агенты и харнессы еще не готовы к полному SDLC. Скорость реальна. Качество шлюзов, которое ранее происходило на всех этих более медленных шагах, не было заменено. Это пробел.

Многие организации все еще измеряют производительность, используя устаревшие метрики. Что лидеры фундаментально неправильно понимают о производительности в среде разработки, управляемой ИИ?

Люди достаточно созрели на эту тему с момента, когда мы начали Allstacks. Измерение сместилось в сторону вещей, которые действительно имеют значение, и рамки стали более сложными. ИИ переворачивает все это.

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

Часть опасности с текущими метриками заключается в том, что они скрывают то, что на самом деле происходит на уровне команды. Старшие инженеры с инструментами ИИ усиливают свое преимущество: у них есть контекст кодовой базы и суждение, чтобы направлять вывод агента и ловить его неудачи. Ранее карьерные инженеры генерируют один и тот же объем кода, но тратят больше времени на аудит вывода, который они не могут полностью оценить. Суммарная скорость выглядит хорошо, может быть, даже улучшена. Пробел между этими двумя группами не появляется нигде на стандартном панеле управления. Правильный вопрос, с которого следует начать, – не “насколько быстрее мы движемся”, а “сколько из того, что мы доставили, было правильным с первого раза”.

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

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

Allstacks была успешной в этом пространстве, потому что мы строили графы контекста до того, как это стало термином. Мы признали рано, что соединение всех данных вместе было необходимо для ответа на вопросы, которые на самом деле задавали клиенты.

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

Это соединение – основа. Это то, что позволило нам быть первыми на рынке с возможностями, которые до сих пор не были воспроизведены.

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

Иронично, но это не так уж и отличается от того, чтобы быть готовым принять класс летних стажеров. Вам нужно сильные автоматические тестовые наборы, солидную документацию, зрелую CI/CD-пipeline и ограничители, которые вы бы поставили, когда добавляете доверенного, но неопытного разработчика в команду.

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

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

Вы подчеркивали важность выравнивания инженерной работы с бизнес-результатами. Как организации могут мостить этот пробел в практическом и измеримом смысле?

Я видел два основных режима отказа. Первый – компании, которые не соединяют инженерные команды с продуктами. Многие командные структуры являются наследием и существуют уже давно. Одна команда может владеть частью трех разных продуктов, в то время как другая команда владеет четырьмя совершенно другими. Инженерные инвестиции в основном сводятся к количеству сотрудников, и когда команды не выровнены с продуктами, становится очень трудно увидеть, где бизнес-ожидания расходятся с реальностью.

Второй режим отказа – неучет всей работы, которая входит в создание и поддержание программного обеспечения. Существует огромная категория бизнес-невидимой инженерной работы. Мой любимый пример – поддержание пакетов в актуальном состоянии. Нехудожественные бизнес-лидеры часто борются с пониманием ценности или того, почему это постоянная и непредсказуемая работа. Но они могут понять категории инвестиций. Если вы формулируете это как “критические обновления безопасности” и показываете в среднем, сколько емкости оно потребляет, вы говорите на языке, с которым они могут работать.

Если вы спросите лидера продаж, чтобы он выбрал между некоторыми обновлениями пакетов npm и функцией, которую он нуждается, чтобы закрыть сделку, функция выигрывает каждый раз. Но если вы формулируете это как “мы выходим из соответствия SOC или доставляем эту функцию”, теперь вы показываете им два компромисса, которые они могут фактически оценить. Это переформулирование – это вся игра. Мы видели, как клиенты сократили время отчетности о капитализации исследований и разработок более чем на две трети, просто сделав эту классификацию работы автоматической, а не ручной. Механизм один и тот же, будь то целью отчетность о капитализации, оправдание количества сотрудников или доказательство ROI ИИ: связанные данные заменяют коррелированные электронные таблицы.

Учитывая ваш опыт в области как практической инженерии, так и преподавания веб-разработки, как вы видите эволюцию роли разработчиков, когда ИИ берет на себя больше кодирования?

Честно говоря, я немного обеспокоен, хотя я доверяю, что умные люди все выяснят.

Мои опасения реальны. Свежие выпускники скоро войдут в рабочую силу, никогда не кодируя в мире без агентов кодирования. Следует ли образованию за ними? Инструменты движутся быстро; высшее образование не всегда движется вместе с ними. Другой сдвиг, который я наблюдаю, – это размытие границ между старшими инженерами и старшими продуктовыми людьми. Самые успешные практики в новой модели – это инженеры, которые глубоко инвестируют в продуктовое мышление.

Что становится более ценным, так это суждение: способность определить проблему достаточно точно, чтобы агент мог ее решить, оценить, правильное ли решение, и поймать тонкие неудачи, которые проходят CI, но создают архитектурные проблемы позже. Старшие инженеры усиливают свое преимущество: они имеют контекст кодовой базы и суждение, чтобы направлять вывод агента и знать, какие выводы можно доверять. Опасение заключается в ранней карьере. Традиционный способ построения этого суждения заключался в том, чтобы написать много кода и учиться на ошибках. Этот цикл обратной связи меняется способами, которые отрасль еще не полностью проработала.

Однако история предлагает некоторое успокоение. Было значительное количество людей, которые считали, что компиляторы вытеснят разработчиков ассемблера из работы. Технологический сдвиг произошел так, как они предсказали. Что произошло с разработчиками, которые не следовали одному и тому же сценарию? За следующие десять лет общее количество разработчиков выросло. Многие из этих программистов на ассемблере научились новому языку и преуспели благодаря своему основному знанию. Я думаю, что подобный шаблон повторится снова.

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

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

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

Две вещи, в которые я довольно уверен для трех-пятилетнего окна. Первое: конкурентное преимущество в инженерном ИИ будет来自 глубины и ширины контекста, а не качества модели. Модели становятся стандартными; каждый инструмент будет иметь способные. То, что будет отличать ведущие платформы, – это как глубоко они понимают вашу конкретную организацию: ваши репозитории, структуру команд, историю доставки, модели развертывания. Инструменты, которые знают вашу систему, будут производить фундаментально разные ответы, чем те, которые не знают. Второе: сдвиг от реактивного к проактивному. Сегодня инструменты отвечают на вопросы, когда их спрашивают. Через несколько лет ведущие инструменты будут наблюдать непрерывно и выявлять риск до того, как вы спросите. Организации, которые строят этот контекстный слой сейчас, усиливают свое преимущество. Следующее поколение инструментов должно решить проблему качества в масштабе, и организации, которые это первые выяснят, будут иметь реальное преимущество.

Спасибо за отличное интервью, читатели, которые хотят узнать больше, должны посетить Allstacks.