All streams
Search
Write a publication
Pull to refresh
50
-2.1
Alex Gusev @flancer

Я кодирую, потому что я кодирую…

Send message

ADSM: итеративность и иерархия

Level of difficultyMedium
Reading time5 min
Views271

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

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

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

Читать далее

ADSM: границы возможностей Моделей

Reading time7 min
Views3.4K

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

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

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

Читать далее

ADSM: ролевые игры

Level of difficultyEasy
Reading time3 min
Views1.8K

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

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

Объяснения под катом

How I Learned to Stop Worrying and Love the… BDSM

Level of difficultyEasy
Reading time4 min
Views760

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

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

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

Читать далее

Когда LLM становится предсказуемой

Level of difficultyEasy
Reading time5 min
Views1.1K

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

Читать далее

Инструмент непрямого управления

Level of difficultyEasy
Reading time3 min
Views978

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

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

Читать далее

А вы храните историю запросов к ИИ-агентам?

Level of difficultyEasy
Reading time2 min
Views1.3K

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

Читать далее

Не одушевляйте неодушевлённое

Level of difficultyEasy
Reading time5 min
Views4.1K

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

Да, это агитация :)

LLM-first: парная разработка без вайбкодинга

Level of difficultyMedium
Reading time9 min
Views4.4K

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

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

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

Читать далее

@teqfw/di: Coding JavaScript like a Java boss

Level of difficultyHard
Reading time7 min
Views922

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

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

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

Читать далее

Типовой ES-модуль в TeqFW или «сборник вредных советов»

Level of difficultyHard
Reading time6 min
Views243

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

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

Читать далее

Почему TeqFW использует только ES-модули?

Level of difficultyHard
Reading time6 min
Views344

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

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

Читать далее

«Философия платформы TeqFW» или «Как усложнить себе жизнь, делая вид, что это инновация»

Reading time8 min
Views624

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

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

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

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

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

Читать далее

IoC: DI vs Ambient Context

Reading time1 min
Views867

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

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

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

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

к опросу

Энергоэффективность интеллекта

Level of difficultyMedium
Reading time2 min
Views744

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

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

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

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

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

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

Ответить или оставить комментарий

Вот почему AGI не уничтожит человечество

Reading time3 min
Views2.4K

Одним словом: симбиоз. Кооперация ради эффективности. Человечество совместно с AGI (или AGI совместно с человечеством) составят более устойчивую конструкцию, чем каждый из компонентов по отдельности.

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

Читать далее

Путаясь в замыканиях

Level of difficultyMedium
Reading time6 min
Views5K

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

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

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

Читать далее

Дискриминация интеллекта

Level of difficultyHard
Reading time2 min
Views1.7K

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

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

Читать далее

Голосовая аутентификация через GPT

Level of difficultyMedium
Reading time5 min
Views2.7K

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

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

Читать далее

Разница между ранним и поздним связыванием

Level of difficultyMedium
Reading time5 min
Views7.3K

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

Читать далее

Information

Rating
Does not participate
Location
Рига, Латвия, Латвия
Date of birth
Registered
Activity

Specialization

Fullstack Developer
Lead
From 3,000 €
JavaScript
HTML
CSS
Node.js
Vue.js
Web development
Progressive Web Apps
PostgreSQL
MySQL
GitHub