Со всей ажиотажем вокруг ИИ может быть трудно понять, какие аспекты технологии ИИ на самом деле реализуются на предприятиях. Чтобы выяснить это, я поговорил с Брайаном Уолдом, который возглавляет команду Gitlab’s Field CTO и находится в регулярном контакте с ИТ -отделами Enterprise.
Уолд назвал роль полевого техника в Gitlab, которая предоставляет стратегическую, высокоуровневую консультативную поддержку предприятиям, подвергающимся цифровым преобразованиям. Они склонны сосредоточиться на DevOps, облачной инфраструктуре и (теперь, конечно,) технологии ИИ. Кроме того, его команда из девяти полевых CTOS подает в отрасли тенденции отрасли и понимание клиентов групп продуктов и инженеров Gitlab.
Что касается ИИ, в частности, Уолд объяснил, что Гитлаб начал инвестировать в ИИ и машинное обучение около трех лет назад — с первоначальным акцентом на использовании своей большой кодовой базы для поддержки процессов разработки. Но со временем он переключился на этапы «пост-коммитации».
«Мы видим, что пост-коммита [are] Ряд шагов, которые занимают очень много времени, чтобы попасть в производство. И мы смотрим на то, как мы можем минимизировать этот промежуток времени [using AI]- сказал Уолд.
Gitlab использует ИИ для автоматизации трудоемких задач, таких как обзоры кодов, аудиты безопасности и устранение неполадок CI.
Именно здесь пришла его команда полевых директоров. Основываясь на отзывах клиентов, пояснил Уолд, Gitlab изменил свои усилия по ИИ для автоматизации трудоемких задач, таких как обзоры кодов, аудиты безопасности и устранение неполадок CI. Этот подход был особенно полезен для команд в регулируемых средах с высоким содействием, которая является одной из областей, на которой сосредоточена компания.
От кодирования до архитекции
Одна из тенденций, которые Уолд и его команда полевых компьютеров определили в эпоху ИИ, — это сдвиг в типе работы, необходимой для команд развития предприятий. Поскольку ИИ становится более способным генерировать код, особенно когда дается надлежащая структура, подсказки и контекст, разработчики смещают свое внимание на обязанности более высокого уровня, отметил Вальд. В крупных организациях, особенно в регулируемых отраслях, таких как финансы, разработчики в настоящее время действуют больше как архитекторы: тратить больше времени на предварительный дизайн, определение бизнес-логики и создавая среды с высоким контекстом для руководства кодом, сгенерированного AI.
«Ваши старшие инженеры или ваши ведущие команды разработчиков, они тратят больше времени, говоря:« Хорошо, вот как это соединяется с нашими подсистемами. Вот бизнес -логика, которая связана [with] это’. И создание высоких контекстных окон, так что когда разработчики идут и строят эти задачи, они используют этот контекст как способ создания лучшего кода ».
Уолд добавил, что организации также опасаются качества кода, генерируемого программным обеспечением Ais Assistant. Это означает, что разработчики предприятия все чаще берут на себя роли обеспечения качества и рассмотрения кода, гарантируя, что AI-написанный код соответствует организационным стандартам, использует утвержденные библиотеки и поддерживает безопасность и эффективность.
«… Вы становитесь своего рода оркестровками кода, по сравнению с авторами кода».
— Брайан Уолд, Глобал Глава, полевой технический директор в Gitlab
«Таким образом, вы становитесь вроде оркестраторов кода, по сравнению с авторами кода», — сказал Уолд. «[On] Передняя часть, вы делаете гораздо больше анализа и создаете планы. [On] Задняя часть, вы делаете много «давайте рассмотрим это и убедитесь, что это действительно имеет смысл» и [that] Мы не создаем больше технического долга ».
Я спросил, выполняют ли разработчики программного обеспечения эти новые задачи «кодового оркестратора», или это выполняются существующими ИТ -архитекторами?
В некоторых случаях, ответил Уолд, разработчики, естественно, превращаются в эти роли без формального признания — они просто тратят меньше времени на написание кода и больше времени на архитектурные или планирующие задачи. Но в более зрелых организациях этот сдвиг официально признается и действует. Эти компании реструктурируют свои команды, четко определяя роли архитекторов, которые тесно сотрудничают с менеджерами продуктов для проектирования систем, а не кода записи.
«Таким образом, у вас есть премьер -министр и архитектор, которые сидят вместе, выполняющие большую часть этой разработки», — объяснил он, добавив, что их работа заключается в создании «плана» для поколения кода.
Принадлежит ли Vibe кодирование на предприятии?
Таким образом, с меньшим количеством написания кода, которое сейчас происходит на предприятиях, возникает вопрос: принимают ли организации «кодирование вибрации», практику побуждения системы ИИ для создания программного обеспечения?
Продолжить с осторожностью, кажется, является девизом в корпоративных средах. Уолд отметил, что некоторые организации даже запретили использование кодирования Vibe для приложений «коричневого поля» (где существует сложность программного обеспечения) из -за риска непредвиденных последствий. Другие организации принимают кодирование атмосфера, но более контролируемыми способами.
«Где я это вижу [vibe coding] Быть очень ценным находится на быстром прототипировании, макетах с высокой точностью и обрамлением проводов,-сказал Уолд.-Это очень хорошая работа, выполняя этот тип вещей. И новые приложения — я хочу раскрутить новое приложение, и вот архитектура, вот инструменты, которые я хочу, чтобы вы использовали, идите, идите в основу этого. Использование кодирования Vibe для этого может привести к 90% пути туда в 10% времени ».
«… Не делай этого и пытайся выполнить какую -то большую, огромную задачу — она с треском пройдет с треском».
— Wald на кодировании Vibe на предприятии
Но с существующими приложениями в корпоративных средах гораздо больше осторожны.
«Когда дело доходит до решения вещей в наших существующих бизнес -приложениях, вы можете использовать [vibe coding] Чтобы помочь перепроектировать функцию, но не заставляйте ее пойти и попытаться выполнить какую -то большую, огромную задачу — она с треском пройдет с треском ».
Агентские системы: первые дни
Другой большой броской фразой в этом году была «агентские системы». Я спросил Уолд, как предприятия практически развертывают технологии агента ИИ.
Опять же, он подчеркнул, что предприятия сосредоточены на структурированных реализациях, а не на открытых экспериментах. Предприятия не позволяют каждому разработчику свободно использовать агенты ИИ, сказал он. Вместо этого они формируют централизованные команды «AI -eablement», которые часто совпадают с командами по проектированию платформы или DevOps.
Команды по обеспечению эффективности ИИ создают предопределенные, контекстуальные рабочие процессы и агенты, адаптированные к потребностям компании — он упомянул ботов по исправлению положения в качестве повторяющегося примера на предприятиях. Эти боты идентифицируют проблемы в журналах или трубопроводах наблюдения, и назначают ответственность за исправление.
Команды по обеспечению эффективности ИИ создают предопределенные, контекстуальные рабочие процессы и агенты, адаптированные к потребностям компании.
Он добавил, что Enterprise IT -команды обычно имеют строгие политики в отношении конфиденциальности данных, защиты от IP и модельного хостинга. Таким образом, есть различные вопросы, которые необходимо решить.
«Можем ли мы использовать эту модель AI LLM? Где она размещена? Что она делает? Это правильная модель с правой Rag или MCP -сервером, чтобы дать контекст [of] Наша организация там, не подвергая риска IP? И поэтому они все еще находятся на этом этапе вещей, но позволяют своим командам […] Делайте вещи внутри этих ограждений ».
Другими словами, это еще первые дни для агентских систем.
Консультации для разработчиков
Наконец, я спросил Уолда, есть ли у него советы для разработчиков в Enterprise. Должны ли они разобраться в том, чтобы стать этим архитекторами? Или есть и другие способы, которыми они могут повысить в качестве инженеров -программистов?
Уолд подчеркнул, что понимание основы разработки программного обеспечения все еще имеет решающее значение, наряду с тем, что ваша голова вокруг LLMS.
«Лучшие инженеры, которые используют AI сегодня, имеют действительно, действительно сильное основное фундаментальное понимание кода, который они пишут, и что они делают до этого. [AI is] собираюсь позволить нетехническим людям иметь возможность писать код; И хотя это верно с кодированием атмосфера, и они могут стать довольно далеко, они всегда попадают в стену. И это потому, что они не совсем понимают, что происходит в коде, и они не могут этого проанализировать, и они не могут сказать: «Да, я не думаю, что это правильное решение здесь, позвольте мне дать вам еще немного контекста».
Разработчики теперь должны глубоко понимать бизнес -логику.
С точки зрения адаптации к переходу от кодирования к оркестрованию, Уолд сказал, что разработчики теперь должны глубоко понимать бизнес -логику — что исторически не всегда имело место, потому что часто это было обязанностью менеджера по продукту.
«Теперь вы должны быть не просто архитектором для инженерии, но вы также должны понимать это и деловую сторону, чтобы вы принимали правильное решение, чтобы вы могли рассказать ИИ, что ему нужно сделать, чтобы он работал с результатом продукта более эффективно».
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Ричард Макманус — старший редактор нового стека и пишет о тенденциях разработки веб -и приложений. Ранее он основал ReadWriteWeb в 2003 году и встроил его в один из самых влиятельных технологических новостей в мире. С самого раннего … Подробнее от Ричарда Макмануса
