В наше время известное изречение Линуса Торвальдса "Talk is cheap. Show me the code." можно переиначить в виде "Code is cheap. Show me the spec." Меня зовут Алекс Гусев и в этой публикации я постараюсь показать, почему я так считаю.

У меня есть несколько статей на Хабре, объединённых общей темой - ADSM (Agent Driven Software Management). По сути, это моя попытка формализовать свой персональная опыт в Spec-Driven Development (SDD) в какое-то подобие методологии. Под катом я поделюсь результатами применения SDD-подхода (в его ADSM виде) к разработке простого приложения - помощника в создании плейлистов в Spotify. И покажу, что будет, если на базе одного и того же контекста (спецификации) сгенерировать код одним и тем же агентом (Codex, GPT-5.4) с разным уровнем reasoning'а (high, medium, low).

Меня зовут Алекс Гусев и сегодня я расскажу о том, как ChatGPT убедил меня переписать библиотеку @teqfw/di, которую я бережно "выращиваю" с 2019-го года, и почему я всё-таки убедился.

Эта JS-библиотека позволяет мне использовать в своих веб-приложениях позднее связывание и даёт возможность писать изоморфный код, который без изменений работает и в браузере, и на бэке. Без транспиляции исходников, без ручной регистрации зависимостей - так, как я привык делать в Java и PHP. Я почти 7 лет вручную выверял каждую строку этой библиотеки, а на прошлой неделе я отдал её на откуп Codex-агенту и вот что он с ней сделал.

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

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

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

Я не собирался ничего писать на Хабр, как-то не до этого сейчас, но комменты под постом "День после появления AGI" меня, можно сказать, вынудили к этому. Как участник дебатов в комментах, я вдруг осознал, как, возможно, достаточно (не)гуманным способом будет решаться проблема перенаселения в не очень далёком будущем и какое место займёт ИИ в решении этой проблемы.

Сразу предупреждаю, что пост несерьёзный только наполовину. И серьёзную половину будет трудно понять как гуманитариям, так и технарям. Так что, можно просто считать, что это, ну... озорство такое, публичное.

Представь, что мир — это огромная комната, заваленная игрушками. Игрушек так много, что ты не знаешь, во что играть. Раньше игрушек было мало, и взрослые показывали, какие из них важные. А теперь игрушек слишком много, и все кричат: «Возьми меня!».

У человека в голове есть своя картина мира — как личная карта того, что он уже видел и понял. Новые знания — это как новые игрушки. Но чтобы взять новую игрушку и понять, как с ней играть, нужно внимание. А внимание — как батарейка: оно быстро садится.

Когда мы читаем или слушаем, мы платим вниманием. Если устали, слова превращаются в шум. Поэтому важно, чтобы знания подавались маленькими кусочками: сначала название, потом короткий рассказ, а уже потом — длинное объяснение.

Умные машины умеют сжимать большие тексты и помогать находить похожие идеи. Так люди могут находить друг друга, делиться мыслями и вместе понимать мир, не уставая слишком сильно.

P.S.

Меня зовут Алекс Гусев. Я попросил LLM пересказать текст своей публикации на уровне 5-летнего. Получилось вот это :-) Но там, дальше, всё не так просто. Там всё сложно. Там даже мне сложно.

Меня зовут Алекс Гусев. В этой публикации я очень кратко раскрываю, почему переход с IntelliJ IDEA (PhpStorm) на VSCode ломает привычную работу с JSDoc в JavaScript-проектах.

Всем привет, меня зовут Алекс Гусев. В этой публикации я продолжаю формализовать свой личный опыт взаимодействия с агентом OpenAI Codex при разработке программного обеспечения. Речь пойдёт о практическом использовании файлов AGENTS.md как инструмента организации контекста проекта в долгоживущих и структурно сложных системах.

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

Прочитал с утра очередной пост на Хабре, как можно неправильно использовать 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, но для выработки энергии для этого процесса придётся сжечь всё ископаемое топливо или выпарить Средиземное Море для охлаждения реакторов АЭС?

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

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

В общем-то, это основная мысль, которую я хотел донести до читателя. Лично мне кажется, что идея кристально ясная и дальнейшего уточнения не требует. Кто-то с этим согласен или, наоборот, несогласен. Если есть желание высказаться - вам в комменты. Под катом же немного рассуждений для тех, кому "сомнительно".

В комментах к статье "Синглтон - корень всех зол", который вообще-то про паттерн проектирования, я высказал мысль, что в функциональном программировании "все функции - синглтоны" (это уже в смысле lifestyle - больше одной функции на приложение не нужно). Тут же мне более опытные коллеги насовали в панамку, что "функции не синглтоны, потому что существуют замыкания". Я, конечно, "сварщик не настоящий" - в ФП серьёзно никогда не игрался, но основные идеи вроде как у всех на слуху: неизменяемость данных, чистота функций, функция как аргумент / результат другой функции.

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

Тем не менее, мысль про замыкания надо было как-то подумать - не, ну а вдруг?! Под катом я привожу результаты своих изысканий на примере очень простого функционала на JS, написанного в трёх разных стилях.

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

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

Около трёх месяцев назад я задумался о том, что в ближайшем будущем взаимодействие человека с техносферой (программно-аппаратно-сетевой инфраструктурой) будет происходить скорее через мессенджеры, такие как Telegram, чем через привычный браузер. Частое использование чатов на смартфоне быстро подтолкнуло меня к попытке снова попробовать голосовой ввод вместо привычных тапов по виртуальной клавиатуре или набора слов жестами. К моему приятному удивлению, распознавание голоса сейчас достигло очень высокого уровня как на Android, так и на iPhone. Причём настолько высокого, что STT (speech-to-text) стал для меня основным способом ввода текста в чатах, включая браузер.

Поскольку искусственный интеллект в целом, и технологии OpenAI в частности, уже практически стали повседневной нормой (по крайней мере, для меня), я, естественно, начал использовать голосовое общение и в GPT-чатах. А узнав о действиях (actions) в настраиваемых GPT-чатах, я сразу загорелся идеей соединить GPT-чат с каким-нибудь внешним приложением. Однако на этом этапе встал вопрос: как аутентифицировать пользователей чата во внешнем приложении? Несмотря на то что OpenAI предлагает использовать OAuth 2.0 для интеграции, в этой статье я рассмотрю альтернативный вариант — парольную аутентификацию, которая, на мой взгляд, лучше подходит для голосового взаимодействия.

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

В этой статье я продолжаю делиться результатами изучения создания телеграм-ботов в nodejs, начатой в предыдущих публикациях (раз, два). На этот раз я покажу, как организовать интерактивные диалоги с пользователями, используя модуль conversations библиотеки grammY. Мы рассмотрим, как настроить библиотеку для работы с диалогами, управлять их завершением, а также реализовать ветвления и циклы. Этот подход станет основой для более сложных проектов, где важно взаимодействие с пользователем.

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

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

Для тех же, кто хочет более детально ознакомиться с процессом взаимодействия человека и ChatGPT при создании JavaScript-проекта - добро пожаловать под кат.

Я продолжаю описывать собственное погружение в мир телеграм-ботов, начатое в предыдущей публикации. Тогда я создал простого бота на Node.js с тремя стандартными командами (/start, /help, /settings) с использованием библиотеки grammY, который мог работать в режимах long polling и webhook. В этот раз я разработал бота, который манипулирует данными в базе по шаблону CRUD + List (CRUDL) с помощью аргументов команд. Из-за своей простоты, граничащей с примитивностью, это решение не подходит для коммерческих проектов, но может быть полезным в персональных проектах.

Время от времени я встречаю на страницах Хабра мысль, что современные браузеры не соответствуют современным требованиям, стали слишком сложными, делают всё не так и не туда, и вообще - ниша “забронзовела”, поделилась между игроками (Blink, WebKit, Gecko) и новичкам с новыми движками в неё стало невозможно попасть в принципе. В своей прошлой статье я коснулся основ работы с телеграм-ботами и в какой-то момент мне показалось, что я увидел прообраз “браузера будущего” - приложения, через которое люди будут подключаться к Сети совсем скоро (а некоторые подключаются уже сейчас).

Под катом я попытался формализовать словами свои субъективные ощущения (КДПВ не моя, это всё DALL-E).

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

Так как я предпочитаю использовать JavaScript и на фронте, и на бэке, то среда существования для бота была определена сразу же - nodejs. Осталось определиться с библиотекой - Telegraf или grammY? Так как у второй в примере использовался кошерный import, а у первой - старомодный require, я выбрал grammY.

Под катом - пример телеграм-бота в виде nodejs-приложения с использованием библиотеки grammY, который запускается как в режиме long pooling, так и в режиме webhook, созданный с применением моей любимой технологии - внедрения зависимостей через конструктор (TL;DR).

Когда я писал свою статью про интерфейсы в JS на примере фильма "Перевозчик" с Джейсоном Стейтемом, я решил использовать ChatGPT, чтобы он мне помог с фактологией. Например, выяснить, сколько весила сумка с девушкой-китаянкой и откуда-куда её должен был перевезти Фрэнк Мартин (герой Стэйтема). Хотя я пересмотрел фильм перед написанием статьи, поиск нужных сцен казался мне утомительным, и я решил срезать путь, обратившись к ChatGPT. Ведь всем известно, что ИИ скоро выкинет старый добрый поиск через Гугл на обочину истории.

Однако, результат меня разочаровал. Если коротко, то ChatGPT (как и любая LLM) работает с вероятностями и ей очень сложно, на грани невозможного, признать, что она чего-то там не знает. Она будет выдавать всякий мусор с очень низким правдоподобием, но так не скажет "извини, чувак, я не в курсе". Ну а если с деталями, то добро пожаловать под кат.

На эту статью меня сподвигла переписка в комментах с коллегой @iliazeus и его вопрос, как в @teqfw/di код может зависеть от интерфейса, а не от его имплементации. В своём ответе я попытался провести параллели с героем Джейсона Стэйтэма из фильма "Перевозчик" - с Фрэнком Мартином. У Фрэнка было три правила (условия контракта) и любой, кто удовлетворял этим правилам (и имел достаточно денег), мог нанять Фрэнка в качестве первозчика.

Ниже я продемонстрирую на примере Фрэнка Мартина, каким образом могут работать интерфейсы в обычном JS (не TS).