Меня зовут Алекс Гусев. Я продолжаю публикацию заметок о своём персональном опыте использования агента Codex от OpenAI для разработки веб-приложений. В этой статье я расскажу о своих выводах относительно организации каталогов верхнего уровня в проектах, разрабатываемых в паре с ИИ-агентами.

Посмотреть результат применения излагаемого подхода можно в проекте "flancer64/pwa-home-call".

В эпоху, когда новое знание рождается быстрее, чем человек способен его осмыслить, привычная модель познания перестаёт работать. Мы уже просто не успеваем изучать новое последовательно, шаг за шагом. Каждый день приходится принимать решения, не имея времени на проверку фактов и их взаимосвязей. Понимание сместилось: вместо анализа - согласие, вместо доказательств - внутренняя сонастройка.

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

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

В рамках развития собственного понимания тонкостей парной разработки программ с участием LLM‑агентов я решил создать PWA для видеочата на базе WebRTC при помощи Codex-агента.

Я не злопамятный. Просто то, что 7-го января этого года на Хабре сняли мою публикацию, текст которой был полностью создан языковой моделью, очень сильно деформировало мою душевную организацию своей, на мой взгляд, несправедливостью. Нет, я понимаю, что никто не хочет читать генерированные моделями "портянки" текста, но... а какая, по-большому счёту, разница, кто написал эту "портянку" - человек или алгоритм?

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

В этой публикации я предлагаю взглянуть на языковую модель (LLM) как на вероятностный вычислитель, который при определённой организации контекста способен давать детерминированный результат.

При таком подходе ADSM (Agent-Driven Software Management) становится архитектурой вычислений, где человек задаёт смысловую базу, агент выполняет циклы, а предсказуемость возникает из внутренней согласованности контекста.

В прошлой публикации я кратко описал своё представление о наиболее важных ограничениях Моделей (LLM):

- работа только с текстом: вход и выход - текстовые файлы; - ограниченность контекстного окна; - все входные данные и все результаты одного диалога размещаются в рамках одного контекстного окна; - расширяющийся контекст (вход меньше выхода) - признак "творческой" работы Модели, сужающийся - признак "инженерной" работы (повторяемой); - противоречивые (или просто лишние) данные приводят к размыванию контекста и снижению повторяемости;

В этой публикации я обозначаю базовые выводы, которые я сделал, исходя из вышеописанных ограничений.

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

Я пробовал разные Модели (GPT, Gemini, Deepseek, Grok) — все они, на мой взгляд, работают примерно одинаково. На один и тот же запрос они дают очень похожие, а иногда и идентичные ответы. Это ожидаемо, ведь все современные LLM построены на одной и той же архитектуре — трансформерах.

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

Четыре дня назад я запостил на Хабре опрос: как лучше назвать пакет документов, описывающих мой опыт разработки программного продукта при помощи LLM‑агентов/ботов — ADSM или BDSM. С небольшим перевесом в один голос (6 к 5) победил вариант ADSM — Agent Driven Software Management. Ну, пусть будет ADSM.

Так вот, при формализации своих отношений с агентами в первую очередь передо мной встал вопрос, а кто в этих отношениях какую роль играет? Пока что я склоняюсь, что наиболее точным описанием являются отношения «Заказчик — Исполнитель».

Это публикация‑опрос. Поэтому и такой заголовок :-) Отсылку поймут не только лишь все, но главная цель — привлечь внимание народа к опросу.

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

Буду благодарен всем, кто поучаствует в голосовании.

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

Прочитал с утра очередной пост на Хабре, как можно неправильно использовать LLM. Я отношусь к Моделям достаточно утилитарно — как к инструменту. Я не пытаюсь найти в них сознание, так как довольно хорошо представляю устройство вычислительной техники и то, как она выполняет программы. Поэтому каждая публикация с посылом «смотрите, Модель делает чушь» для меня сродни откровениям человека, попытавшегося вырезать ровный круг из оконного стекла при помощи молотка и получившего груду осколков в результате.

Это очень короткая статья про то, чем отличаются молотки от LLM.

Лично мне нравится LLM как инструмент, усиливающий мои интеллектуальные возможности. Я использую его ежедневно — для поиска информации, для создания и перевода текстов, в качестве ассистента по подсчёту калорий и, само собой, для разработки приложений. Немного попрактиковавшись с генерацией pull request'ов через OpenAI Codex для модулей своего проекта TeqCMS, я пришёл к выводу, что в "грядущую эпоху вытеснения разработчиков моделями" настоящую ценность представляет вовсе не код и даже не проектная документация. Главный артефакт — это инструкции, настраивающие контекст для Агента, и история запросов, с помощью которых генерируется код.

Всем привет, меня зовут Алекс Гусев. Поводом для этой публикации стали интересные и вдумчивые посты коллег @Siberianice, @SergioPrieto и @Kamil_GR — спасибо им за пищу для размышлений. Я задался вопросом: есть ли у нас вообще основания наделять современные большие языковые модели (LLM) субъектностью? Где проходит грань между инструментом и носителем воли? Это не просто изложение моей позиции, а попытка повлиять на восприятие темы.

Этот пост — мой личный разбор по итогам двух недель разработки простой файловой CMS для одного из моих пет-проектов. Мне нужен был SSR-сайт с мультиязычным контентом — около десятка страниц на двух языках. Всё под Git-контролем, переводы я делал вручную через DeepSeek API и выкладывал на продакшн через GitHub Actions.

В какой-то момент стало понятно: отслеживать и переводить все мелкие изменения вручную — неудобно и утомительно. Тогда я решил автоматизировать этот процесс и взял в напарники ИИ. Не для вайбкодинга и генерации «по настроению», а для настоящего парного программирования.

Результат — рабочий open-source проект, который можно развернуть, изучить и использовать. Но главное — это опыт. Это была не просто реализация CMS, а переосмысление роли ИИ в разработке. Под катом — мои подходы, наблюдения и выводы.

Эта статья для тех, кто, как и я, хочет программировать на JavaScript в Java-стиле. Для тех, кто находит вдохновение в балансе между строгой архитектурной дисциплиной Java и творческой свободой JavaScript. Ранее я уже публиковал "философию" своей платформы TeqFW, а также инструкции для LLM (раз, два) по оформлению es-модулей в приложениях, написанных в стиле TeqFW. На этот раз я делюсь инструкцией для LLM по использованию внедрения зависимостей в таких приложениях.

Для тех, кто не совсем понимает, что значит "программировать на JavaScript в Java-стиле", приведу рабочий пример — это Node.js-утилита @flancer64/smtp-logger. Она сохраняет в базу данных все email'ы, которые Postfix отправляет наружу. Мне как раз понадобился такой функционал — и я реализовал его в стиле TeqFW: с явным управлением зависимостями и строгой модульной структурой.

Под катом - пример JS-кода в Java-стиле.

Я ранее описал принципы, которыми руководствуюсь при разработке веб-приложений, а также требования, предъявляемые со стороны платформы TeqFW к JS-коду. В этой публикации я покажу, как выглядит код типового модуля платформы, где не используется статический импорт. Хочу сразу отметить, что кажущаяся сложность материалов обусловлена непривычностью представленных концепций. Наработанный опыт и инерция мышления — сильные вещи! Тем, кто имеет ограниченный опыт в JS-разработке, этот материал будет проще для восприятия, в то время как опытным разработчикам предстоит преодолеть барьер устоявшихся привычек. На мой взгляд, несмотря на то что "TypeScript — это суперсет JavaScript", самыми сложными концепции платформы станут именно для TS-разработчиков.

Ну, вот - я предупредил, дальнейшее чтение - на ваш страх и риск.

Ни у кого не получится показать другому то, что тот не хочет или не может увидеть. Объяснять и показывать нужно только тем, кто а) может понять, б) хочет понять. В этой публикации я демонстрирую пару своих документов для LLM, которые предписывают "силиконовым", какими правилами им следует руководствоваться при создании кода для моей платформы. "Силиконовым" можно впаривать любую дичь - они всеядные (могут понять) и покладистые (согласны понять). За это мы их и любим!

Кому интересно, что за инструкции - прошу под кат. Кто хочет сразу получить ответ на вопрос в заголовке - могут задать его (и множество других) соответствующему преднастроенному GPT-чату. Кто не хочет ни того, ни другого - в вашей ленте есть ещё куча других, более интересных публикаций.

Аудитория Хабра, в силу своей айтишности и любознательности, отлично подходит для различного рода экспериментов . Этот документ - эксперимент. Создан мной в соавторстве с LLM и предназначен как для людей, так и для LLM. Хочу увидеть реакцию людей. Реакцию LLM я уже видел.

Всё изложенное касается только разработчиков на JavaScript (JS !== TS).

Философия Tequila Framework (TeqFW) — это мой личный взгляд на организацию разработки веб-приложений. Я, Алекс Гусев, сформировал этот подход, исходя из собственного опыта, который сосредоточен на модульных монолитах с одной базой данных. Этот документ отражает именно такой контекст и не претендует на универсальность.

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

Документ предназначен для формирования когнитивного контекста как у естественных интеллектов, так и у искусственных. В нём затрагиваются как специфические аспекты веб-разработки, так и более общие вопросы архитектуры ПО, с упором на снижение избыточной сложности, улучшение структурированности и адаптируемости к изменениям.

На днях с коллегой @nin-jin возник небольшой спор в комментариях к статье "ООП: худшее, что случалось с программированием". Мы обсуждали, что является истинным IoC: "контекст окружения" (Ambient Context) или же "внедрение зависимостей" (Dependency Injection).

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

Другие наши коллеги могут посчитать этот опрос бессмысленным, типа популярные практики не могут быть хорошими априори. Я же считаю, что более популярные практики прошли более тщательную проверку жизнеспособности, чем их менее популярные аналоги. Популярность практики прямо пропорциональна вероятности того, что твою текущую проблему уже кто-то когда-то решил с её помощью. А зачастую решены и те проблемы, о которых ты пока даже и не подозреваешь.

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

Мысль моя простая и на целую статью её не хватает, но на Хабре под постом комменты хуже создаются, а мне интересна обратная связь. Поэтому вот. Извиняюсь, если кого задело:)

Некоторые говорят, что ИИ скоро заменят программистов. Типа, LLM «мыслит» точно так же, как и человек, только шире и быстрее. Достаточно увеличить контекст до каких‑нибудь внушительных размеров и LLM спокойно начнёт писать портянки кода и связывать их воедино. Вот только мой личный опыт меня убеждает, что с размера текста в 4–5К токенов LLM начинает дико лажать с его модификацией. Он начинает его регенерировать заново. Не исправлять, а именно регенерировать — так ему проще.

Думаю, что проблему можно решить через закольцовывание рассуждений (Reasoning, Chain of Thought) — разбиение контекста на части, анализ, кластеризация и иерархическая структуризация об общего к частному и обратно.

Скорее всего, «кожаные», включая меня, примерно так и решают задачи. Вот только вопрос, будет ли это выгодно чисто экономически с точки зрения расхода энергии? Не окажется ли на уровне современных технологий, что LLM может написать программу уровня самой LLM, но для выработки энергии для этого процесса придётся сжечь всё ископаемое топливо или выпарить Средиземное Море для охлаждения реакторов АЭС?

«Кожаные», между тем, справились с задачей лишь слегка подтаяв ледники Гренландии. При этом написав ещё кучу разных программ, ненужных и устаревших по большей части.

Вот и вопрос: а будет ли экономически эффективно заменять «кожаных» программистов «силиконовыми» чисто с точки зрения энергопотребления?