Пока одни пророчат скорую замену всех программистов искусственным интеллектом, а другие скептически качают головой, Дмитрий Смирнов, основатель «Код Смирнов» и технический лидер, ежедневно работает с LLM в реальных проектах. В этом интервью он рассказал, почему мы находимся в «1994-м году развития интернета», как на самом деле использовать ИИ-инструменты безопасно, и почему обещания Сэма Альтмана — это «рекламные пугалки».
Полную версию обсуждения можно посмотреть на канале Ai4Dev на Youtube. А еще у нас появился Telegram-канал для разработчиков, которые используют ИИ. В нем уже около 4 тысяч разработчиков, с которыми можно обмениваться мнениями и реальными кейсами.
Сейчас в стало модно озвучивать: «Мы внедрили LLM, мы уже пишем с LLM, мы сократили часть команды и отдали задачи LLM». Хочется понять, что на инженерном уровне происходит и к чему это в реальности уже привело?
Процесс внедрения технологии идет полным ходом. Это очень перспективная технология, все об этом знают. Насколько она перспективна, можно сопоставить с интернетом, когда он только зарождался. Тогда тоже было понятно издалека, что все будет использоваться через интернет, через мобильную связь. Но надо понимать: в 80-х и 90-х интернет активно внедряли на корпоративном уровне, везде об этом говорили, надували знаменитые пузыри dotcom. От момента, когда это все началось, до момента, когда вы смогли спокойно заказать пиццу через «Яндекс.Еду», прошло значительное количество времени.
С LLM происходит примерно то же самое. Сейчас на уровне ранних продуктов, MVP, внедряется эта технология, и она всем нравится. Это хороший маркетинговый ход и стратегическая инициатива, чтобы занять рынок, занять нишу. Но практическая отдача не всегда такая, как заявляется. Это абсолютно нормальный процесс, потому что для максимально эффективной работы LLM должно пройти значительное количество времени, итераций разработки, продуктового анализа. Сейчас на бумаге все звучит классно, но на практике встречается миллион нюансов с этой технологией. Хотя сама технология невероятная и очень мощная — LLM как слепок от всех знаний мира, истории человечества. Но это не значит, что можно сразу же извлекать из этого практическую пользу.
В IT-командах разработчики используют это в основном как инструмент, который помогает решать не очень любимые задачи: написать тесты, разобраться с документацией по API, сделать сортировку, группировку — задачи, которые часто приходится отлаживать. Но даже с этими задачами LLM не всегда сразу справляется. Когда работаешь с Cursor, например, все разработчики сталкиваются с тем, что с первого раза не всегда все работает. Бывает, что работает, но шансов не так много, чтобы все получалось с первого раза. Когда тратишь время на отладку, по сути занимаешься тем же, чем занимаешься, когда пишешь код сам. Разработчики сталкиваются с тем, что иногда проще самому написать с нуля, используя минимально подсказки как ассистента.
Что касается анализа данных, то здесь LLM вполне успешно показывает себя в задачах, которые всегда были очень специфичными. Например, понять контекст, понять смысл — отобрать пять перспективных новостей из тысяч по определенным критериям. LLM с этой задачей справляется. Трансформировать текст из одного формата в другой — LLM великолепно справляется. С переводом, с пониманием смысла, который может быть не суперинтеллектуальный, но все равно сложно извлекается из лингвистики, — LLM тоже справляется отлично. В сочетании с традиционными алгоритмами и метриками это может показывать хороший результат.
Почему крупные инвестиционные компании вкладывают миллиарды долларов в гонку развития LLM, заточенных именно на программировании?
Во-первых, инвестиционные фонды всегда во что-то вкладывают — у них такая работа. Это не всегда показатель того, что на выходе получится что-то невероятное. Технология перспективная, это понятно всем. Через 20-50 лет мир изменится абсолютно невообразимым для нас сейчас образом. Если сделать ставку на то, что мир изменится под влиянием искусственного интеллекта, наверняка не ошибемся.
Но говорить о том, что разработчиков полностью заменит ИИ, очень преждевременно. Любой специалист-разработчик, который занимается этим на серьезном уровне, прекрасно это понимает, когда видит, как эти системы работают. Последние опросы МТС на российском рынке показали: очень небольшой процент разработчиков — всего 4% — верит в то, что ИИ сможет заменить их работу.
А вот в то, что их работа претерпит изменения под влиянием ИИ, верят 58%. Это разумно, потому что рутинных операций станет меньше. Сокращение в разрезе повышения эффективности для корпораций — очень важный процесс. А вот сокращение ради сокращения абсолютно бессмысленно для любой компании, потому что люди — это производственная мощность. Люди — это льготы, рабочие места, налоги. Экономики устроены по принципу найма большого количества людей, чтобы все работало. Избавиться от людей, которые не производят ценности, — разумно. Избавиться от людей, которые производят ценности и делают это хорошо, — неразумно. А усилить их — очень даже разумно, чтобы они создавали еще больше ценности, могли повысить качество, безопасность.
Как вы оцениваете эффект от использования LLM в программной разработке? В чем выражается экономия времени, снижение количества багов? Как измерить усиление разработчика?
В первую очередь — это увеличение удовлетворенности разработчиков от работы за счет уменьшения времени на рутинных задачах, которые не представляют интеллектуального вызова. Это очень важно для продукта в целом, чтобы разработчик был вовлечен в написание кода и показывал свой интеллектуальный максимум. Лучше, чтобы он меньше занимался рутинными задачами, когда в одном окне документация, в другом ты вставляешь код без какого-либо отступления от парадигмы. С этой задачей LLM справляется неплохо, а разработчик контролирует процесс. В итоге у разработчиков будут расти управленческие навыки.
Скорость работы тоже важна. То, что раньше требовало два неприятных часа, может превратиться в 15-30 минут «легкого» времени. Новая технология — у тебя чат генерирует, агент сам делает, подменяет, коды определяет. Это интересно пытливому уму. Пока, конечно, через два года это всем не наскучит. Скорость реализации должна повышаться, и объемы кода вырастут тоже.
Вместе с тем традиционные метрики могут быть завышенными. Например, количество активности, пулл-реквестов, коммитов, контрибуций. За счет LLM эти метрики могут вырасти, и оценка их вне контекста может вводить в заблуждение.
Вы сказали, что вырастет объем кода. Не боитесь, что пока разработчик радуется генерации кода агентом, тот создает большой объем мусорного кода? Раньше, нанимая специалиста, можно было оценить качество его кода, был определенный стандарт. Не размоется ли это? Не уничтожит ли культуру качественного кода?
Code review никто не отменял. Давайте поговорим про код как таковой в больших технологических компаниях. Есть мобильные приложения, которые представляют примерно 100 тысяч строк кода. Над таким приложением работают 20 разработчиков прямо сейчас, а до этого уже сотни поработали. У каждого был свой почерк, школа, бэкграунд, путь — он обязательно привносит в код что-то свое.
Чтобы унифицировать код, разработчики больших команд работают в рамках определенных парадигм, архитектур и покрывают код линтерами, которые следят за код-стилем, единообразием и важнейшими подходами — например, SOLID Principles. Они принципиально важны, чтобы даже разнообразный код был унифицирован и поддерживаем в будущем, чтобы не превратился в Legacy.
Когда парадигма и архитектура не соблюдаются, даже код, написанный людьми, быстро превращается в Legacy, в котором никто ничего не понимает. Когда перекрасить кнопку из красного в зеленый цвет требует 40 часов работы — это проблема.
Поэтому и без LLM существуют подходы для контроля и унификации кода. LLM прекрасно умеет работать по документации. Если точно объяснить, что мы хотим в плане классовой структуры, определенных подходов и принципов, он справляется — LLM знает эти принципы лучше людей иногда, может пройти любое интервью по этим вопросам. Он умеет заполнять спецификацию, документацию по промтам.
В плане архитектуры, когда я работаю с LLM, мне проще попросить его придумать модули, разбитые по определенным принципам классы. Он сам создаст файлы, опишет их, предварительно создаст документацию, абстракцию. При итерационном подходе, как у разработчика, результат будет качественным и с выигрышем по времени.
Какими ИИ-инструментами не должен пользоваться разработчик?
Прежде всего бесплатными или инструментами у которых нет защиты от попадания отправленной информации в аналитические базы данных. Эти данные могут не только использоваться для обучения — они могут попадать в определенные базы данных, сливаться третьим компаниям, которые тоже будут использовать их для обучения. Это все продается, ведь эта информация представляет ценность. Потом можно обнаружить эти данные в даркнете. Если в данных будут токены, endpoints, специфика — это потенциальная уязвимость.
Огромное количество людей уже работает над тем, чтобы майнить эту информацию — хакеры, спецслужбы. Поэтому взять и скопировать свой код с токенами и секретными ключами в ChatGPT — все равно что опубликовать эти данные на своей странице ВКонтакте. Это серьезное нарушение безопасности.
Например, Cursor на платном тарифе имеет галочку Privacy Mode. Если ее включить, Cursor гарантирует, что он и вендоры не используют данные в аналитике, не хранят их, не накапливают. Если что-то временно хранится в кеше, то безлично или зашифровано. Можно почитать эту политику — это относительно безопасный способ работы с кодом.
Но надо понимать: в Cursor нужно настраивать выделение всех токенов в отдельный файл и прописывать правила, чтобы он этот файл не трогал, не сливал, не смотрел, чтобы агенты его не трогали. Тогда это безопасный подход.
Достаточно ли компаниям-заказчикам гарантий политики безопасности того же Cursor? Принимают ли клиенты использование облачных LLM при разработке и считают ли это безопасным?
Если говорить про предприятия где нужно проходить через шесть пунктов охраны по бейджикам, где даже флешку вынести нельзя, то безопасность разработки - это критично. Если пишете софт для подводных лодок — использовать Cursor не стоит, это точно.
Для стратегически важных сервисов надо понимать: это потенциально интересно государственным структурам других стран. Они майнят эту информацию на всякий случай, и никакие политики приватности для них не преграда. На коммерческом уровне все будет нормально, но на уровне спецслужб это легко обходится. Там сидят специалисты, которые занимаются внедрением и отслеживанием определенных типов информации.
Поэтому примерно 9% компаний принципиально говорят, что никаких ассистентов использовать нельзя. Еще для 18% — разрешено для всех проектов. Клиентам по умолчанию неважно, кто или что пишет код — они хотят получить качественный результат. Конечно, они не захотят увидеть исходный код своего проекта где-то еще. Надо понимать: если выкладываете исходный код в GitLab, вы также компрометируете его во внешний сервис.
Как вы обучаете программистов работать с LLM? В Cursor много настроек — можете поделиться опытом?
Это стандартный онбординг. Собираемся, созваниваемся, показываем, смотрим, обмениваемся опытом. Не всегда я обучаю — иногда мне показывают новые возможности. «Памятка бойца» включает: обязательно включить Privacy Mode, использовать рекомендуемую модель ChatGPT 5 Pro, Claude Sonnet 4 — самые удачные из тех, что мы пробовали. Настройки для проекта — в ignore поставить файлы с токенами, чтобы они не улетали. Этот файл не должен попадать в репозиторий, должен быть в .gitignore и ни в коем случае не храниться в облачных сервисах.
Если это все сделано, дальше — творчество. Иногда интереснее самому что-то найти и понять, как работает. Промпт-инжиниринг естественный. Предпочитаю, чтобы разработчики сами проходили свой путь — так они учатся думать. Чуть-чуть подтолкнуть, подсказать, но ничего не навязывать.
Может ли ваш текущий продукт целиком написать LLM? Можете оценить трудозатраты и рассказать, как бы проектировали под LLM?
Проектирование под LLM практически ничем не отличается от проектирования для человека. Единственная разница — вместо инструкций, понятных человеку, больше будут инструкции, специализированные для LLM.
LLM — это как достаточно начитанный, очень прилежный человек, но немного наивный, все воспринимает в лоб и не любит что-то добавлять от себя. Но если в промпт добавить достаточное количество различных требований, он прекрасно понимает требования безопасности — знает OWASP Top-10, требования PCI DSS, даже российские федеральные законы. То, что многие разработчики не знают. Если насытить промпт различными требованиями, код будет генерироваться хороший.
Требования нужно насытить и архитектурными принципами. LLM помогает разрабатывать архитектуру — нужно сказать «разрабатывай Clean Architecture или VIPER, соблюдай SOLID принципы, продумай структуру файлов, напиши абстракцию для классов, реализуй их, задокументируй, напиши документацию для архитектуры, уточни эту документацию для LLM, чтобы LLM сам написал необходимые базовые системные промпты».
Но когда вы все запустите, работать ничего не будет. Вы будете кидать информацию из отладочной консоли, сами все протыкивать, по сути станете продвинутым QA. Не всегда LLM будет правильно мыслить о том, где находится баг и в чем проблема — такая проблема есть и у разработчиков.
Проблема в том, что ИИ может очень сильно уводить при отладке в сторону, переписывая целые классы, не понимая, что уходит далеко от изначальной архитектуры. Он может закопаться в баг и сильно менять код. Это нужно контролировать.
Когда пишу с Cursor, не полагаюсь на него полностью. Пишу с помощью, сам пишу код, пользуюсь автокомплитом — Copilot делает это прекрасно, сокращает рутину. А ассистентами стараюсь не злоупотреблять, чтобы не превращаться в AI-кодера.
LLM не способна исправить ваш код или быстро найти ошибку, которую вы не видите?
Многие проекты реализовать не способна. Например, делаете проект, связанный со звонками — условно пишете Skype. Как LLM проверит, правильно идет звук или нет, прошел звонок или нет? Огромное количество вещей LLM может реализовать разве что на заглушках, но когда снимете заглушки, работать не будет абсолютно точно. Это касается и человека.
Огромное количество взаимодействий с интерфейсом, анимациями, физическими ограничениями, звонками, картами, токенизацией. А еще взаимодействие с коллегами — когда пишешь им «у вас не работает», а они отвечают «у нас все работает», и начинается два дня выяснений, в чем проблема. Это LLM тоже не сможет.
Командная разработка — точно ничего не сможет сделать самостоятельно и полностью. Но под руководством, если взял на себя роль ментора, это возможно, но очень трудоемко.
Какие задачи LLM решает хорошо? Есть зоны, где LLM вне конкуренции в разработке?
Хорошо справляется с шаблонизированными задачами, которые абсолютно рутинные. Создать файлы, следуя определенной архитектуре, описать абстрактные классы, решить задачи сортировки, группировки. Кстати, это очень нелюбимые задачи для разработчиков — нужно обязательно проверять процесс, писать, и обязательно что-то напутаешь.
Задачи с датами — если говоришь «мне нужно отформатировать дату в таком ключе» — LLM прекрасно справится. Регулярные выражения написать, документацию для метода, Swagger сгенерировать. Кинуть документацию, описание API метода, объяснить, что хочешь сделать — справится прекрасно.
Это рутинные неприятные задачи. При этом можно сфокусироваться на более творческих моментах — сделать красивую анимацию, обсудить с продуктом детали верхнего уровня, повысить скорость работы, подумать о базе данных, логах, масштабируемости, отказоустойчивости. У разработчиков ограничен фокус внимания — если думаешь про рутину, вытесняется остальное. Освобождаешь ресурс и с помощью LLM можешь решать эти задачи.
Код-ревью можно отдать LLM?
Под контролем — если используешь LLM для экономии времени, это поможет. Мы создали продукт Codes Git AI, который отработали в больших технологических компаниях на множестве команд. LLM может отслеживать активность разработчиков через GitLab API — в реальном времени подтягивать количество коммитов команды, contribution, комментарии, merge requests, diff кода.
Все это подгружается с контекстными данными в LLM, и он оценивает базово с определенным системным промптом. Например, в случае с комментариями LLM оценивает: есть ли токсичность, выглядят ли комментарии полезными или формальными.
LLM очень помогает — можно проверить, как проводится код-ревью в командах на десятках продуктов за 10 минут. Фокусируешься на местах, где LLM говорит «здесь комментарии токсичные и неполезные, формальные, лишенные контекста». Смотришь и видишь — действительно есть. Можно обусдить с разработчиком почему так происходит.
Докопаться до этого самостоятельно через интерфейс GitLab — часы работы руководителя. LLM превращает это в 10-30 минут. Это масштабируемое решение. Главное — может работать в режиме алертинга, сообщать только по необходимости.
Если у тебя 10 продуктовых команд и пытаешься понять, что происходит, это сложно. Даже если посещаешь все демо, лично смотришь — фокус ограничен вниманием, и что-то может уплывать.
LLM может делать первичный код-ревью, проверять, как проводится код-ревью в команде, проверять merge requests — что происходило, что менялось, какого объема работа, насколько сложная, затрагивались ли архитектурные моменты. Более того, это можно уточнять в режиме чата — не обязательно доверять системному промпту, можно задавать уточняющие вопросы. Через GitLab API управляется по временным диапазонам — по месяцам, неделям, можно посмотреть за прошлую неделю, прошлый месяц. Это действительно экономит время, особенно если знаешь, что в команде результаты не очень, и можно узнать, что происходило некоторое время назад.
Вы рассматриваете LLM как надстройку над разработкой — скорее алертинг-систему, чем часть цикла разработки. Можно ли глубже погрузить LLM в код-ревью, чтобы ускорить разработку и повлиять на качество?
Механизм, который я описал, прямо влияет на качество и скорость разработки, если окажется в руках тимлида продуктовой команды. За счет того, что тимлид может сократить свое время, он может больше внимания уделять продуктовым вопросам, общению по бизнес-моментам и эффективно справляться с контролем качества кода.
Понимая, что разработчики не всегда все говорят, не всегда все получается, все работают в нагрузке — это происходит не из-за того, что кто-то плохой, а потому что все работают в авральном режиме. Это нормально. Иногда продукт на финальной стадии, вдруг меняются требования — мало никому не покажется.
Не нужен LLM, чтобы вычислить плохого разработчика. Человека, который потерял мотивацию, не работает, будет видно сразу. А на ближайшем демо станет окончательно заметно, что разработчик выгорел или у него проблемы.
А вот выделить человека, который действительно активный, вкладывается — такого пропустить не хочется, иначе он подумает, что никто его не заметил. LLM очень может помочь в этом. Выделив вовремя такого человека — это достижение, которое повлияет на скорость команды, дух и качество продукта в целом. LLM насыщает информацией, избавляет от рутины и фокусирует на том, на чем хочешь. У хорошего человека он обострит и усилит способности.
LLM поменяла роль тимлида в команде? Возникает ли размывание ответственности, когда часть контроля и управленческих решений принимает LLM?
Нет, ни в коем случае. В индустрии LLM воспринимается не так, как на публику. Когда вы слышите, что Сэм Альтман говорит «завтра всех заменят», он говорит это не потому, что так считает. Очень может быть, что он говорит так, чтобы напугать вас, и вы побежали использовать GPT как можно скорее, потому что «ИИ завтра всех заменит». Это полезно с точки зрения маркетинга и рекламы, это хорошо работает.
Доверять экспертному мнению «завтра всех заменит» не стоит — это рекламное обещание, маркетинговый трюк. Маркетинг прекрасно работает на угрозах. Вспомните Илона Маска, который обещает что-то там про Тесла, астероиды, что нужно срочно лететь на Марс. Это прекрасно работает — люди готовы нести миллиарды на основе определенных эмоций, акции растут.
Нам, инженерам, легко проверить рекламные обещания и посмотреть на практике, как это работает. Руководители тем более прекрасно знают, что LLM ошибается очень часто — 10-20%. Если бы LLM был сотрудником, его уволили бы через неделю по ошибкам, которые он допускает.
Когда сидим в эхокамере, разговариваем с LLM и думаем «он такой умный» — это не LLM умный, это ты умный. Ты смотришься как в зеркало. Сам по себе без инструкций, промптов, направления каждую минуту он не особенно эффективен. Это угадывающая система, которая угадывает последующее слово. Очень важно, какие слова ты скажешь ему, чтобы он угадал то, что ты хочешь услышать. В этом плане он блестяще работает. Но сам по себе без человека — это не то.
Руководить компанией с помощью LLM? Такая компания долго не продержится. Сколько данных ни скорми, LLM не сможет понять без тебя, какие данные важны, какие нет. В лингвистике содержатся подсказки в речи — LLM поймет, что важно, что нет, смысл поймет. Но в конкретных ситуациях, в конкретной компании в конкретный момент времени у него будут большие проблемы.
Мы далеки от момента, когда можно будет загрузить в LLM пожелание «разработай программу» и получить готовый работающий результат?
Вы хотите, чтобы компания-производитель LLM сказал что-то другое? Они сильно заинтересованы продавать, и будь все отлично, продавали бы роли разработчиков не по 20 долларов в месяц, а значительно дороже.
LLM — невероятная технология, перспективный потенциал которой понятен всем: топ-менеджерам, государственным лидерам, обычным разработчикам, домохозяйкам. Это технология, которая изменит наше представление о продуктах, не говоря о разработке. Изменит общественные устои, экономику, государство — много чего. Но не прямо сейчас, это точно.
Мы, условно, находимся где-то в 1994-95 году развития интернета. Вроде все уже было — вы могли в 1995-м позвонить, email отправить в пиццерию, и вам привезли бы пиццу. Но полноценно это сделать смогли, наверное, только в 2015 году. То есть, 20 лет — нормальный цикл для любой технологии.
Огромное количество людей будет адаптировать эту технологию. Огромное количество экономических принципов могут быть нарушены, если внедрять LLM бездумно. Увольнять сотрудников — нехорошая практика для государства. Любой сотрудник — платежеспособный потенциал на рынке. Люди с зарплатами сами покупают то, что производят. Также они налогоплательщики. На налоги существует все хорошее в государстве — армия, здравоохранение, образование. Корпорации тоже налогоплательщики. Им важно, чтобы на рынке были платежеспособные люди.
Поэтому мы очень далеки от того, чтобы кто-то что-то внедрил и всех уволил. А те 20-30% которые мы видим - это оптимизация расходов, абсолютно нормальная практика. Это случилось бы в любом случае, потому что компаниям нужен резерв. В определенный момент они перенасыщают рынок предложением и набирают много разработчиков. После этого выпускают их на рынок, особенно, если разработчики плохо зарекомендовали себя. Это нормальный процесс. LLM немного на это влияет, безусловно. Может, где-то эмоционально кто-то распустил команды, но через два года снова наберет.
С появлением LLM меняется ли подготовка программистов? Как бы вы советовали начинать с нуля в программировании с учетом AI-кодинга?
Cursor обязательно можно поставить — это первое, что ставишь. Неплохо прочитать какую-нибудь классическую книгу по программированию —Можно и без книжек, но современные инструменты молодым людям обязательно нужно осваивать, потому что через 20 лет, когда они будут на пике формы, все эти навыки будут очень востребованы. Отслеживать эти технологии критически важно для молодых специалистов. Для 40-летнего разработчика это не так важно уже — когда это все будет, там уже будет другая ситуация, другая ветка профессионального развития.
Молодым специалистам обязательно нужно осваивать эти инструменты.
Учиться на программиста имеет смысл сейчас? В классическом виде, в котором происходит обучение в вузе? Или это все потеряно?
Казалось бы, образование потеряло смысл еще когда появился Google с Wikipedia в определенном плане получения знаний — это не проводник в библиотеку, где тебе карточку выдали и ты пошел умных книжек начитался. Тем не менее образование сохранило другие смыслы — как именно тебя выпустили в общество, насколько подготовленный ты, где крутился.
Смысл в образовании пока еще есть. Даже если это кажется нефункциональным — ты понимаешь, что тебя там учат ерунде, — но если заканчиваешь престижный университет, скорее всего, это поможет в будущем. Но при этом знания можно получить дома за компьютером, совершенно спокойно обучить себя без профессоров и учителей, если есть способности и таланты. Это абсолютно точно. Для этого есть все инструменты.
Что сейчас в свете развития LLM становится наиболее важным качеством для разработчика? Предполагаете ли, что появятся тесты на применение LLM в разработке? Ты приходишь на работу, тебе говорят: «Покажи, как умеешь работать с Cursor, составь промпт».
Я к собеседованиям всегда относился очень скептично. Дело в том, что собеседование проводит человек, которого самого было неплохо прособеседовать. Появляются интересные практики, которые очень сомнительны.
Скорее всего, да, на LLM будут проверять — как настроить в Cursor такую-то функцию, знаешь ли что такое безопасность. Такой кандидат скажет: «Блин, я не задумывался, я курсовые работы до этого писал». Понятно, хорошо, до свидания.
Но я не задаю таких вопросов на собеседовании. Все, что гуглится за три секунды, я не спрашиваю. Это каверзные вопросы. Я и так пойму, когда общаюсь с человеком про опыт — где работал, что делал, какую роль занимал. Мне не надо, я достаточно проницательный для этого, чтобы использовать какую-то механику подлога.
Если человек этого не знает, значит, скорее всего, не было опыта вообще. Не факт, что он действительно мог работать и не уделять внимание безопасности. Если его за пять минут этому научить, он будет блестящим разработчиком и принесет огромную пользу компании.
Поэтому незнание чего-то для меня лично не означает, что разработчик плохой. Может быть обратный эффект — если он знает, как работать с LLM и готов вас научить, это позитив. Если он умный, талантливый — это неплохо. Главное, чтобы был умный и талантливый, а уж как распорядиться этим — тоже не важно.
Что с LLM будет дальше в разработке?
Он будет внедряться так, как и внедряется. Кто-то будет использовать на свой страх и риск, кто-то будет выводить в общие командные процессы. Смотря какие инструменты LLM — есть облачные, есть бесплатные, есть облачные платные, есть сервисы США, России, Китая. В зависимости от этих конфигураций будет сильно влиять на процесс.
Есть локальные, разные модели локальные, разные инструменты локальные. Кто-то будет их использовать. Я в основном использую для критически важных проектов локальные сервисы — есть аналог Cursor, например, называется Void, и много других появилось, которые прекрасно работают с локальными моделями, не тратят токены и абсолютно безопасны с точки зрения утечки данных в облако. .
Развиваться все это будет, активно внедряться. На перспективу 20 лет это, конечно, очень сильно изменит наше представление о продуктах, процессах и всем остальном. Но на ближайшее время экономическая и политическая ситуация будет влиять значительно сильнее, чем LLM.
Не стоит сильно обращать внимание на рекламные пугалки. Не нужно терять сон из-за того, что Альтман что-то сказал. Спокойно — это просто реклама.