Джеремі Фрімен, співзасновник і технічний директор Allstacks – Серія інтерв’ю

Джеремі Фрімен, співзасновник і технічний директор Allstacks, є програмістом, технологічним архітектором і підприємцем з кар’єрою, що охоплює розробку програмного забезпечення, інженерію апаратного забезпечення, машинне навчання та інновації продукту. З моменту заснування Allstacks у 2017 році він очолював архітектуру та розвиток основної платформи компанії, допомагаючи трансформувати управління доставкою програмного забезпечення за допомогою передбачувальної аналітики та прогнозування, керованого штучним інтелектом. До Allstacks Фрімен займав керівні посади в Ravioli Labs і CertiRx, де працював над інженерією програмного забезпечення, дослідженнями, технологіями боротьби з підробками та розробкою продукту. На початку своєї кар’єри він набув досвіду в стартапах, підприємствах з технологій та академії, включаючи викладання веб-розробки в коледжі Wake Technical Community. Його технічний досвід охоплює вбудовані системи, проектування апаратного забезпечення, великомасштабні платформи програмного забезпечення, машинне навчання та лідерство в інженерії, що дає йому унікальну перспективу на будівництво даних продуктів, які допомагають організаціям покращити результати доставки програмного забезпечення.

Allstacks є платформою інтелекту програмної інженерії та управління потоками вартості, яка допомагає організаціям покращити передбачуваність та ефективність розробки програмного забезпечення. Платформа інтегрує дані з інструментів, що використовуються на всіх етапах життєвого циклу розробки програмного забезпечення, включаючи системи управління проєктами, системи контролю джерельного коду та системи розгортання, а потім застосовує штучний інтелект та машинне навчання для визначення ризиків, прогнозування результатів доставки та надання дієвої інформації. Надавши керівникам інженерії та продукту видимість проекту, продуктивності команди та тенденцій розробки, Allstacks дозволяє організаціям приймати більш обґрунтовані рішення, зменшувати невизначеність доставки та краще узгоджувати зусилля інженерії з бізнес-цілями. Її технологія розроблена для того, щоб допомогти компаніям вийти за межі інтуїтивного планування, використовуючи реальні оперативні дані для покращення виконання доставки програмного забезпечення та стратегічного виконання.

У вас унікальна подорож від керівництва командами досліджень та інженерії, що застосовують машинне навчання до даних розробки програмного забезпечення, до співзаснування Allstacks у 2017 році. Які конкретні пробіли чи повторювані проблеми ви спостерігали, що в кінцевому підсумку спонукали вас створити компанію?

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

Що стало ясним досить швидко, це те, що це не проблема звітування або проблема інтеграції. Це була проблема відносин. Щоб знати, чи щось знаходиться під загрозою, вам потрібно знати, як робота пов’язана з гілкою, гілка пов’язана з запитом на отримання, запит на отримання пов’язаний з цілями спринту та цілі спринту пов’язані з бізнес-ініціативами. Цей граф не існує за замовчуванням ніде в стандартному інструментарії. Вам потрібно його побудувати. І побудувати його добре – це фундаментально проблема висновку, яка ставить в пригоді досвід машинного навчання.

Наша мета з самого початку не полягала в тому, щоб зробити окремого розробника швидшим над функцією Х. Це було зробити всю організацію кращою. Як ви вирівнюєте зусилля інженерії з бізнес-результатами? Як ви робите інженерію справжнім слугою бізнесу, а не просто існуючої поруч з ним? Вам потрібно краще розуміння даних відносин, щоб відповісти на ці питання. Це ті питання, які керували майже кожним продуктовим рішенням, яке ми прийняли.

Allstacks зосереджується на аналізі даних по всьому життєвому циклу розробки програмного забезпечення. Які типи сигналів або моделей найбільш передбачувані при визначенні ризику доставки на ранній стадії?

Я не думаю, що існує єдиний набір метрик, який передбачає добро та зло, а радше моделі для різних фаз та типів організацій. Що я знайшов більш корисним, це те, що інженерні організації проходять через сезони покращення. Цього місяця це продуктивність бази даних. Наступного місяця це міжкомандна комунікація. Потім це “чому ми не можемо закрити жодного запиту на отримання?” Потім спостережуваність. Як лідер інженерії, ви плаваєте в сигналах: деякі діагностичні, деякі моніторингові та багато з них просто шум.

Що допомагає, це починати з проблеми, яку ви фактично бачите, а не метрики, яку ви хочете покращити. Якщо ви питаєте “чому здається, що ми доставляємо менше, ніж у минулому році”, це правильна початкова точка. Відтоді я думаю, що вам потрібно три типи метрик: перша, як ви знаєте, що проблема реальна (можливо, кількість запитів на отримання на розробника за час); друга, які зміни ви робите та як ви відстежуєте їх на своєму шляху (наприклад, прийняття оглядача запиту на отримання штучного інтелекту, якщо це ваше втручання); і третя, наскільки важлива ця проблема для бізнесу. Ваша інтуїція може бути правильною, що ви доставляєте на 20 відсотків менше коду, але справжня історія може полягати в тому, що тестування тепер займає в три рази більше часу. Вам потрібно всі три лінзи, щоб знати, чи ви розв’язуєте правильну річ.

Ви працювали в галузях, таких як охорона здоров’я, енергетика та технології. Як проблеми з доставки програмного забезпечення відрізняються в цих секторах, і як це вплинуло на платформу Allstacks?

Я дуже ціную свій досвід у секторах, що не є чисто технологічними. У компаніях SaaS легко загубитися в ідеї, що саме програмне забезпечення є метою. Коли ви перебуваєте в бізнесі, де ви не продаєте програмне забезпечення безпосередньо, ваша роль стає набагато яснішою: технологія існує для підтримки бізнесу. Я часто жартую, що якщо бізнес міг досягти всього з тією ж швидкістю без необхідності мати справу зі мною, вони вибрали б цю опцію без коливань.

Ця перспектива насправді корисна. Вона контекстуалізує все, що ми робимо в цій галузі, і повертає багато технологічних дебатів до їхнього місця. Бізнес не турбується, чи ви використовуєте Python чи Go. Витрачання циклів на цю переробку, ймовірно, не там, де справжня віддача.

Що залишається постійним у всіх галузях, це проблема фрагментації. Незалежно від сектора, кожна інженерна організація має дані, розкидані по десятку інструментів з обмеженою сполучною тканиною між ними. Деталі відрізняються: регульовані галузі мають довші плани та нижчу толерантність до неоднозначності у вимогах, оскільки вартість будівництва неправильної речі вища. Високошвидкісні технологічні майстерні накопичують приховані борги швидше. Але основний режим відмови однаковий. Команди можуть сказати вам, що було доставлено. Вони не можуть простежити, чому щось зсунулося, скільки це коштувало чи де ризик був видимим до того, як став проблемою. Це те, що сформувало, як ми побудували платформу.

Є зростаюча розповідь про те, що штучний інтелект прискорює сам кодування, одночасно викриваючи слабкості в інших місцях. Чому вимоги, планування та готовність специфікацій стають справжніми瓶頸ами?

Ми бачимо це щодня. З хорошим агентом та солідним харнесом навколо нього ви можете перейти від ідеї, іноді безпосередньо з уст клієнта, до виробництва за буквальні години.

Частина того, що робить цей зсув таким значним, є зміна зворотного зв’язку. З інструментами типу копілота людина знаходиться в циклі на кожній пропозиції. Штучний інтелект пропонує завершення; ви приймаєте або відхиляєте його відразу. Коли це неправильно, ви ловите це швидко. Радіус ураження поганої пропозиції становить одну рядок коду. Агентське кодування працює інакше: ви даєте агенту мету, він розбиває роботу, виконує багатокроковий план та доставляє робочий модуль. Людина переглядає вивід, а не кожен крок. Коли специфікація неправильна, агент будує весь модуль реалізації до неправильної специфікації, і ви дізнаєтеся про це під час огляду.

Це звучить як чистий верх, поки ви не визнаєте, що попередня затримка часу насправді служила справжній меті. Затримка служила справжній меті. Були кілька раундів розумних людей, які переглядали, планували, тестували та працювали над ідеями, щоб створити кращу систему.

Тепер спокуса полягає в тому, щоб вибити щось і обійти все це. Але агенти та харнеси ще не готові до повного життєвого циклу розробки програмного забезпечення. Швидкість реальна. Якість контролю, яка раніше відбувалася під час усіх тих повільних кроків, не була замінена. Це пробіл.

Багато організацій все ще вимірюють продуктивність за допомогою застарілих метрик. Що лідери фундаментально неправильно розуміють про продуктивність у середовищі розробки, керованому штучним інтелектом?

Люди досить сильно доросли щодо цього питання з моменту, коли ми створили Allstacks. Вимірювання перейшло до речей, які насправді мають значення, і рамки стали більш складними. Штучний інтелект перевертає все це.

Традиційна розробка програмного забезпечення була фундаментально обмежена тим, як швидко розробник міг написати код, який відповідає вимогам бізнесу та основної технології. Ця вартість наближається до нуля. До того, чого ми рухаємось, є щось ближче до індивідуального розробника як менеджера агентів. Ця модель вимагає зовсім іншого підходу до вимірювання продуктивності, який ґрунтується на чомусь іншому, ніж токени, згенеровані або витрачені години розробника.

Частина небезпеки поточних метрик полягає в тому, що вони ховають, що насправді відбувається на рівні команди. Старші інженери з інструментами штучного інтелекту компенсують свою перевагу: вони мають контекст кодової бази та судження, щоб керувати виводом агента та ловити його невдачі. Ранні інженери часто генерують той же обсяг коду, але витрачають більше часу на аудит виводу, який вони не можуть повністю оцінити. Агрегатна швидкість виглядає добре, можливо, навіть покращилася. Пропуск між цими двома групами не з’являється ніде в стандартному панелі управління. Правильне питання, з якого потрібно почати, не “як швидко ми рухаємось”, а “як багато з того, що ми доставили, було правильним з першого разу”.

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

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

Allstacks був успішним у цьому просторі, оскільки ми будували графи контексту з тих пір, як це стало терміном. Ми визнали на початку, що з’єднання всіх даних разом було необхідним для відповіді на питання, які фактично запитували клієнти.

Коли таке з’єднання не існує, штучний інтелект, що працює з інженерними даними, може бачити лише частину картини. Він може проаналізувати те, що знаходиться в вашій системі управління проєктами. Він може проаналізувати те, що знаходиться в вашому репозиторії коду. Що він не може зробити, це простежити затримку доставки назад до заблокованої залежності через три інструменти, оскільки відносини між цими сигналами не існує в шарі даних. Ви отримуєте мілку аналіз на рівні найкращого, і впевнені, неправильні рекомендації в гіршому випадку. Якість моделі не вирішує це. Ви можете поставити найбільш здатну модель, доступну на ринку, на верхівку сурових API-інтеграцій, і все одно пропустити справжню причину проблеми, оскільки дані не кодують відносини між сигналами. Сміття вхідних даних, сміття виводу, незалежно від того, наскільки розумна модель.

Це з’єднання є основою. Це те, що дозволило нам бути першими на ринку з можливостями, які все ще не були повторені.

Як агенти штучного інтелекту стають більш вбудованими в робочі процеси розробки, що виглядає добре підготовлена інженерна організація порівняно з тією, яка не готова?

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

Що також важливо, і люди схильні недооцінювати це, це повернення до основ: ваших правил агентів, ваших файлів AGENTS.MD. Ви можете зробити солідний перший прохід, але легко потрапити в ритм доставки в новий спосіб і забути, що ви можете фактично витренувати багато поганих умовних положень. Речі, такі як навчання агента запускати тести перед кожним коммітом, не повинні вимагати людської пам’яті кожен раз.

Одне діагностичне питання, яке я б поставив будь-якому лідеру інженерії: можете ви мені сказати, що ваші агенти виробили за останній спринт, яке з цього виводу було прийнято без змін, а яке було переглянуте, і де зосереджено зусилля з перегляду? Якщо ви можете відповісти на це, у вас є інструментування для покращення. Якщо ви не можете, ви летите наосліп.

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

Я бачив два основні режими відмов. Перший – компанії, які не спарюють інженерні команди з продуктами. Багато структур команд є спадковими і існують уже давно. Одна команда може володіти частиною трьох різних продуктів, тоді як інша володіє чотирма зовсім іншими. Інвестиції в інженерію в основному залежать від кількості працівників, і коли команди не вирівнюються з продуктами, стає дуже важко побачити, де очікування бізнесу розходяться з реальністю.

Другий режим відмов – не врахування всієї роботи, яка йде на будівництво та підтримку програмного забезпечення. Є величезна категорія інженерної роботи, невидимої для бізнесу. Мій улюблений приклад – оновлення пакетів. Нетехнічні лідери бізнесу часто борються з тим, щоб зрозуміти вартість або чому це постійно й непередбачувано. Але вони можуть зрозуміти категорії інвестицій. Якщо ви сформулюєте це як “критичні оновлення безпеки” і покажете в середньому, скільки місткості воно споживає, ви говорите мовою, з якою вони можуть працювати.

Якщо ви попросите лідера продажів вибрати між деякими оновленнями пакетів npm та функцією, яку вони потребують для закриття угоди, функція виграє кожен раз. Але якщо ви сформулюєте це як “ми виходимо з режиму відповідності SOC або доставляємо цю функцію”, тепер ви показуєте їм два компроміси, які вони можуть фактично оцінити. Це переформулювання – вся гра. Ми бачили клієнтів, які скоротили час звітності про капіталізацію досліджень і розробок більш ніж на дві третини, просто зробивши цю роботу класифікації автоматичною, а не ручною. Механізм той же, незалежно від того, чи є метою звітність про капіталізацію, виправдання кількості працівників чи доведення ROI штучного інтелекту: підключені дані замінюють корельовані таблиці.

Враховуючи ваш досвід у ручній інженерії та викладанні веб-розробки, як ви бачите еволюцію ролі розробників, коли штучний інтелект бере на себе більше кодування?

Відкрито кажучи, я трохи турбуюсь, хоча я довіряю, що розумні люди все вирішать.

Мої турботи реальні. Свіжі випускники скоро вступлять на робочий ринок, ніколи не кодуючи у світі без агентів кодування. Залишилася освіта позаду? Інструменти рухаються швидко; вища освіта не завжди рухається поряд з ними. Інша зміна, яку я спостерігаю, – це розмиття старших інженерів і старших людей продукту. Найбільш успішні практики в новій моделі – інженери, які глибоко інвестовані в продуктова думки.

Що стає більш цінним, це судження: здатність визначити проблему досить точно, щоб агент міг її вирішити, оцінити, чи рішення правильне, і ловити тонкі невдачі, які проходять CI, але створюють архітектурні проблеми пізніше. Старші інженери компенсують свою перевагу, оскільки вони можуть керувати виводом агента та знати, яким виводом можна довіряти. Турбота полягає в ранньому етапі кар’єри. Традиційний спосіб побудови цього судження полягав у тому, щоб написати багато коду та вивчити на помилках. Цей зворотний зв’язок змінюється способами, які галузь ще не повністю проробила.

Тим сказано, історія пропонує деяку впевненість. Був значний контингент людей, які вважали, що компілятори виведуть розробників з асемблера з роботи. Технологічний зсув відбувся так, як вони передбачали. Що відбулося з розробниками, які не слідували тому ж сценарію? За наступне десятиліття загальна кількість розробників виросла. Багато з тих програмістів асемблера вивчили нову мову та excelled, оскільки мали фундаментальні знання. Я думаю, що версія цього шаблону грається знову.

Оглядаючи вперед, як ви бачите штучний інтелект, який змінює життєвий цикл розробки програмного забезпечення протягом наступних трьох-п’яти років, і де компанії здобудуть найбільшу конкурентну перевагу?

Ми бачитимемо гонку озброєння функцій, подібну до жодної іншої. Коли вартість будівництва наближається до нуля, компанії, навіть великі, стикаються з новим обмеженням: збором та перевіркою достатньої кількості клієнтського зворотного зв’язку для того, щоб продовжувати будівництво якісних речей у масштабі.

Зміна, яка повинна відбутися, полягає в тому, що планка того, що будується, повинна піднятися. Поточне обмеження в більшості інженерних організацій просте: п’ять верхніх пріоритетів, можливо, два доставлені. З агентами співвідношення перевертається. У вас може бути п’ять верхніх, десять наступних і двадцять можливо на списку, і ви можете доставити сотню. Питання, яке ніхто ще не повністю відповів, полягає в тому, як ви утримуєте останні шістдесят п’ять від того, щоб бути погано спланованими та погано виконаними.

Дві речі, у яких я досить впевнений для три-п’ятирічного вікна. Перше, конкурентна перевага в інженерії штучного інтелекту буде походити від глибини та ширини контексту, а не якості моделі. Моделі стають таблицями ставок; кожний інструмент матиме здатні. Що відрізнить провідні платформи, це те, наскільки глибоко вони розуміють вашу конкретну організацію: ваші репозиторії, вашу командну структуру, вашу історію доставки, ваші моделі розгортання. Інструменти, які знають вашу систему, будуть виробляти фундаментально різні відповіді, ніж ті, які не знають. Друге, зсув від реактивного до проактивного. Сьогодні інструменти відповідають на питання, коли їх запитують. За кілька років провідні інструменти будуть спостерігати безперервно та поверхнево ризик до того, як ви запитаєте. Організації, які побудують цей контекстний шар зараз, компенсують свою перевагу. Наступне покоління інструментів повинно вирішити проблему якості у масштабі, і організації, які це вирішать першими, матимуть справжню перевагу.

Дякую за велике інтерв’ю, читачам, які бажають дізнатися більше, слід відвідати Allstacks.