В свежем материале на Хабре, опубликованном в потоке «Разработка», автор поднимает тему, которая давно назрела в индустрии: что на самом деле представляют собой большие языковые модели и как они соотносятся с разработкой программного обеспечения. Он сразу оговаривается, что не верит в появление сильного ИИ на базе машины Тьюринга или Lisp-машин, а единственным путём к настоящему интеллекту считает биологические эксперименты с мозгами, выращенными вне организма. При этом весь текущий хайп вокруг LLM он называет «снятием сливок рутины» и предлагает договориться: называть LLM просто «Т9 с SSD-шником», а не искусственным интеллектом. Эта радикальная позиция задаёт тон всему дальнейшему рассуждению и сразу отсекает споры о том, является ли LLM шагом к AGI.

Автор описывает рынок через призму того, как разные компании относятся к внедрению LLM. Он перечисляет несколько типов организаций: те, что заставляют разработчиков использовать модели из-за заблуждения о производительности; те, где сотрудники имитируют работу с LLM; те, где LLM применяют тайно, симулируя обычную деятельность; компании, строящие собственные harness-решения; те, что боятся замены; и те, что делают вид, будто справятся без моделей. По его мнению, корень проблемы в том, что большинство разработчиков в хайп-поезде никогда не любили программирование как таковое. Это наблюдение он подкрепляет личным опытом преподавания в ИГХТУ, где читает функциональное программирование, фундаментальную информатику и тестирование ПО. Именно там он объясняет студентам, что современный SDLC — это не про написание программ, а про оптимизацию бизнес-процессов, и что разработчик приходит в индустрию не «программировать», а решать проблемы бизнеса.

Ключевое различие, которое автор проводит на протяжении всего текста, — между программистом и разработчиком. Программист, по его словам, это тот, кто пишет код, фапает на каждую строчку и рефакторит ради процесса. Инженер-программист думает о железе и отказоустойчивости, а software developer решает проблемы бизнеса, используя код как инструмент. Автор подчёркивает, что современный SDLC — это не про написание программ, а про оптимизацию бизнес-процессов: например, автоматизацию ресторана с помощью QR-кодов и вызова официанта, где человек становится консультантом, а не просто исполнителем. Эта мысль важна для понимания того, почему LLM внедряются именно в бизнес-логику, а не в ядро программирования. Более того, автор отмечает, что индивидуалистический капитализм навязал разработчику прямую ассоциацию рабочей деятельности с его личностью, из-за чего тому жизненно необходимо быть связанным с определённым коммьюнити: жабаскриптизёр верит в сверхартефакт, шарпист обмазывается Мартином, а ушедший в гошку натягивает DDD на всё, что видит. Это, по его мнению, не программирование, а разработка ПО, и именно эта подмена ценностей мешает трезво оценивать возможности LLM.

Далее автор вводит понятие harness — инфраструктуры вокруг LLM, которая позволяет агенту работать автономно. Сюда он относит промпты, MCP, skill, agents.md, policies, spec-driven development и другие инструменты, исключающие человека из цикла поставки. По его мнению, компании, которые уже стабилизировали свой стек и свели разработку к работе с CMS или самописными devkit, могут переключиться на feature development и лучше понять потребности стейкхолдеров. Однако тут же возникает первая проблема: существующие LLM не готовы к harness. Автор сравнивает это с AWS, где уже есть DynamoDB, Lambdas и Alpine-ноды, и разработчику остаётся только бизнес-слой. Но для LLM нужен другой подход, поскольку текущие модели не предназначены для автономной работы в таком режиме.

Автор выстраивает лестницу эволюции: chat, API, агент, кластер, эшелоны. Он хочет, чтобы harness имитировал поведение не просто исполнителя-аутсорсера, а целой организации с тимлидами агентов, OKR и key results. Но ключевая мысль в том, что субагентам не нужно общаться текстом, как они общаются с человеком. Форма взаимодействия должна быть иной, и все попытки засунуть LLM в симуляцию разработчика — взять таск с доски, провести код-ревью, задеплоить — обречены, потому что они копируют человеческие процессы, а не машинные. Это техническое наблюдение перекликается с его же тезисом о том, что LLM — это не интеллект, а инструмент, и использовать его надо соответственно. Если продолжать натягивать на модель человеческие ритуалы, ничего кроме имитации бурной деятельности не получится.

Для российского рынка эти рассуждения имеют прямое значение. Многие отечественные компании сейчас активно экспериментируют с LLM, но зачастую без понимания разницы между программистом и разработчиком. Если следовать логике автора, то попытки заменить разработчиков моделями провалятся, потому что бизнес-задачи требуют человеческого суждения и контекста. В то же время harness-подход может стать способом автоматизировать рутину, оставив людям более сложные и творческие задачи. Реакция отрасли на такие тексты обычно полярна: одни видят в них здравый смысл, другие — консерватизм. Но факт остаётся фактом: хайп вокруг LLM продолжает расти, а практика внедрения показывает, что модели пока не готовы к полной автономии. При этом именно в России, где многие компании вынуждены строить собственные решения из-за ограничений на зарубежные сервисы, вопрос о harness встаёт особенно остро.

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