S0ER

Вышло видео, где Сэм Альтман отвечает на вопросы по ИИ. Некоторые мысли сильно коррелируют с моими собственными. Похоже, индустрия меняется гораздо быстрее, чем наша способность осознать эти изменения, и тренды довольно интересные: - Бизнес вынужден бороться за «внимание». Раньше в цене была «сложность» решения задач, а теперь, как будто, сложности нет — все идеи, которые приходят в голову, можно быстро реализовать и продвинуть на рынок. Проблема в том, что другие участники тоже могут быстро выпускать новые продукты, реализующие другие идеи. В новой системе ограничением является внимание пользователей, бизнесу всё сложнее будет бороться за внимание, и чтобы преуспевать в этом направлении, на первый план выходит ценность, которую несёт продукт. - Есть два направления дальнейшего развития ИИ — увеличение скорости работы моделей либо уменьшение стоимости. Здесь нужно искать баланс, потому что нельзя сделать быстро и дёшево одновременно, по крайней мере не сразу. Поэтому, скорее всего, сначала станет «дёшево»: в ближайший год-два цена может упасть в 100 раз. - Была интересная мысль о том, что ИИ может нести большие угрозы в области биологии и создания новых патогенов. Это направление сложно контролировать через «запреты», нужно вырабатывать с помощью ИИ ответные меры, повышающие устойчивость. Вывод из разговора простой - ИИ поможет писать код быстрее, продвнет возможности персонализации под конкретных людей (когда под каждого человека можно будет создавать свой софт), но процессы, борьба за внимание, ценность идей, человечиские отношения - те сферы, где ИИ пока не конкурент людям.

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

Конец года - время подводить итоги и делиться планами на будущее. Записал короткий ролик о том, что делал в этом году и что планирую делать в будущем, в конце немного затронул тему текущего положения дел на рынке. Всех с наступающим Новым Годом. 👀 YouTube 👀 RuTube 👀 VK Video

Решили порадовать вас перед праздниками новым выпуском Разбаговки 🔥 Наш гость - Евгений Сергеев, архитектор ПО и автор Telegram-канала S0ER. На подкасте поговорили про использование ИИ в разработке. Там интересно 😉 Полное видео можно посмотреть тут: - наш сайт - VK video - YouTube #видео #подкаст #разбаговка

Есть мнение, что микросервисы сильно переоценены. Хочу сказать пару слов на эту тему. Вчера на созвоне разбирали архитектурный ландшафт сервисной архитектуры. Традиционно ребята уперлись в тонкое место SOA — общую шину предприятия. Попытались использовать API-gateway и вместо оркестрации уйти в хореографию. Нетрудно догадаться, что решение сразу стало не в SOA-стиле, а обычными микросервисами. Мне кажется, что исторически именно раздутые ESB заставили уходить организации в микросервисы. И это остро чувствуется, когда сам сталкиваешься с задачей и ощущаешь всю неповоротливость шины. Один такой практический созвон заменяет сотни споров, потому что в теории все просто, а практика показывает обратное. Поэтому очень важно для усвоения материала пройти путь от монолитов через сервисы к микросервисам, без этого нет понимания "болевых" точек, которые привели индустрию к текущему состоянию. Микросервисы получились не случайно, они являются закономерным результатом многолетнего набивания шишек.

Вчера на созвоне разбирали архитектурный ландшафт сервисной архитектуры. Традиционно ребята уперлись в тонкое место SOA — общую шину предприятия. Попытались использовать API-gateway и вместо оркестрации уйти в хореографию. Нетрудно догадаться, что решение сразу стало не в SOA-стиле, а обычными микросервисами. Мне кажется, что исторически именно раздутые ESB заставили уходить организации в микросервисы. И это остро чувствуется, когда сам сталкиваешься с задачей и ощущаешь всю неповоротливость шины. Один такой практический созвон заменяет сотни споров, потому что в теории все просто, а практика показывает обратное. Поэтому очень важно для усвоения материала пройти путь от монолитов через сервисы к микросервисам, без этого нет понимания "болевых" точек, которые привели индустрию к текущему состоянию. Микросервисы получились не случайно, они являются закономерным результатом многолетнего набивания шишек.

Попросил DeepSeek сделать таблицу истиности для конъюнкции, используя язык JavaScript и битовые операции, вот что получил:

console.log("Таблица истинности для a && b (битовые операции)");
console.log("a\tb\ta & b");
console.log("---------------");

// Используем битовые операции с числами 0 и 1
for (let a = 0; a <= 1; a++) {
    for (let b = 0; b <= 1; b++) {
        // Битовая операция И
        const result = a && b;
        console.log(`${a}\t${b}\t${result}`);
    }
}

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

for(let i = 0; i < 4; i++) {
    const a = i & 1;
    const b = i >> 1 & 1;
    console.log(`\t${a} & ${b} = ${a && b} (${Number(!(!a || !b)}))`);
}

Здесь я добавил иллюстрацию закона Де Моргана, пока не обращайте на него внимание. Интересно, что многие программисты жалуются на излишнюю сложность второго варианта, мол нет насмотренности на битовые операци, сложно быстро понять код. В целом с булевой алгеброй тоже возникают сложности, часто люди не могут применить закон Де Моргана, чтобы упростить свои условия. Я, конечно, по-стариковски думаю "Да, были люди в наше время, Не то, что нынешнее племя", но понимаю, что код должен быть понятен всем участникам проекта и первый вариант имеет в этом смысле явное преимущество, но при этом я хотел бы работать с ребятами, которые легко читают второй вариант, в целом это будет совсем другой "средний уровень команды". Поэтому, интересно ваше мнение какой из двух вариантов кода вам нравится больше и почему? Пишите в комментариях 👇👇👇

Пришло время полезных тредов. Давайте обсудим какие llm вы запускаете локально, на каком железе и какие модельки вам нравятся. Заходите и делитесь опытом в комментариях, думаю всем будет полезно 👇👇👇

❗️❗️Немного о том, что происходит в ИИ-лаборатории Соер.Клуба Сейчас идет активное переосмысление старых подходов к разработке, много разговоров про вайб-кодинг. Под вайб-кодиногом обычно имеют в виду использование одного умного агента, которому достаточно поставить задачу, а он все сделает сам. В текущих реалиях так сделать не получается, приходится постоянно корректировать результат работы LLM, что иногда не только не упрощает, но усложняет разработу. Мы в своей лаборатории решили не придумывать велосипед, а начали работать по направлению метапрограммирования, взяли старую добрую идею "код - это тоже данные", ушли от идеи "одного агента" и сделали замкнутую агентскую систему (т.е. агенты сами "видят" результаты изменения кода). Такой подход позоляет: 👑 увеличить время автономной работы (вся работа делится на несколько этапов, которые суммируются в одну общую сессию); 👑 разделить обязанности между агентами и добиться того, чтобы агенты сами исправляли свои ошибки (в "классическом" варианте предполагается, что ошибок мало и их правит сам программист). Какие выводы мы сделали: - вайб-кодинг в его текущем варианте "одного агента" не заменит обычную разработку до появления AGI; - агентские системы, основанные на идеях метапрограммирования, уже сейчас могут взять на себя решение типовых задач без необходимости постоянного контроля со стороны разработчика. Основные проблемы: медленная работа LLM, большое потребление токенов (результат есть, но пока довольно дорого с позиции денег). Думаю, что AGI в ближайшее время ждать не стоит, а вот агентские системы внедряться будут активно.

Активно работаю с ИИ агентами, постепенно "высушиваю" промпты и описание сабагентов до минимально работающих функций. Заметил, что в моих промптах чаще всего используются ASCII деревья. Это происходит потому что почти все программирование это структуры и операции над ними. А самая популярная структура - дерво. Есть ощущение, что любая декомпозийия в конечном итоге - дерево. Далее, как ни странно, в описаниях лидируют "стек" и "очередь". А завершает цепочку рекурсивное описание. А вот условия встречаются крайне редко. Получается, что я работаю с агентами в функциональном стиле - и основная задача декларативно описать результат, который хочу получить, а дальше пусть сам думает.

У меня две основные модели для кодинга - GLM-4.6 и Qwen3-code. Недавно мне стало интересно насколько модели могут осознать сами себя и я решил начать с простой рефликсии - скажи свое имя. Результат в видео.

Завел себе канал в Максе, говорят там самая адекватная аудитория! Когда телегу поблочат, увидимся с вами там) https://max.ru/softwareengineervlog

В своих экспериментах я использовал QWEN3-Coder-480b-А35b-Instruct. При первом подходе модель начинала с синтаксического разбора, затем последовательно анализировала файл в поисках непечатных символов, способных сбить с толку интерпретатор, после чего пыталась создать минимально работоспособную версию и доработать её. В конечном счёте этот процесс приводил к исчерпанию лимитов сессии. При втором, более эффективном подходе, та же самая модель находила и корректировала неточность всего за 2-3 итерации после начала диалога. Чтобы сэкономить токины я в первую очередь предлагаю исправлять ИИ ошибки как синтаксические, потому что стадия "анализа ошибки" может быть весьма объемной, если ИИ не справляется с первого раза, то перехожу на второй вариант. Если и второй вариант не помог, то смотрю ошибку сам. Как я уже сказал, большая часть проблема отсекается на первом этапе, семантические проблемы на втором. И крайне редко приходится смотреть самому, как правило если речь заходит о рефакторинге, где старый код сильно сбиывает ИИ.

Исправь ошибку

vim/loader.lua:0: ...soer/projects/agentsoer.nvim/lua/agentsoer/engine/ai.lua:43: '<name>' expected near 'function'                                                                                                                                                   
                                                                                                                                                                                                                                                                      
# stacktrace:                                                                                                                                                                                                                                                         
  - vim/loader.lua:0                                                                                                                                                                                                                                                  
  - lua/agentsoer/commands.lua:5                                                                                                                                                                                                                                      
  - lua/agentsoer/init.lua:4                                                                                                                                                                                                                                          
  - ~/.config/nvim/lua/plugins/init.lua:34 _in_ **config**                                                                                                                                                                                                            
  - ~/.config/nvim/init.lua:17     

Эффективный промпт:

Проанализируй причину возникновения ошибки, рассмотри несколько подходов к решению и предложи способ устранения:

vim/loader.lua:0: ...soer/projects/agentsoer.nvim/lua/agentsoer/engine/ai.lua:43: '<name>' expected near 'function'                                                                                                                                                   
                                                                                                                                                                                                                                                                      
# stacktrace:                                                                                                                                                                                                                                                         
  - vim/loader.lua:0                                                                                                                                                                                                                                                  
  - lua/agentsoer/commands.lua:5                                                                                                                                                                                                                                      
  - lua/agentsoer/init.lua:4                                                                                                                                                                                                                                          
  - ~/.config/nvim/lua/plugins/init.lua:34 _in_ **config**                                                                                                                                                                                                            
  - ~/.config/nvim/init.lua:17

Промпт для исправления ошибок в коде Когда ИИ генерирует программный код, он может допускать ошибки, как и обычный разработчик. Синтаксические проблемы исправляются довольно просто, но встречаются и более сложные случаи, связанные с семантикой. Хочу разобрать конкретный пример, который демонстрирует, насколько по-разному может работать ИИ в зависимости от формулировки промпта. Сообщение от интерпретатора выглядит так:

Failed to run `config` for agentsoer.nvim
                                                                                                                                                                                                                                                                      
vim/loader.lua:0: ...soer/projects/agentsoer.nvim/lua/agentsoer/engine/ai.lua:43: '<name>' expected near 'function'                                                                                                                                                   
                                                                                                                                                                                                                                                                      
# stacktrace:                                                                                                                                                                                                                                                         
  - vim/loader.lua:0                                                                                                                                                                                                                                                  
  - lua/agentsoer/commands.lua:5                                                                                                                                                                                                                                      
  - lua/agentsoer/init.lua:4                                                                                                                                                                                                                                          
  - ~/.config/nvim/lua/plugins/init.lua:34 _in_ **config**                                                                                                                                                                                                            
  - ~/.config/nvim/init.lua:17     

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

42 local function handle_tool_call(tool_call)
43  if tool_call.function.name == "list_directory" then
44    local success, params = pcall(vim.fn.json_decode, tool_call.function.arguments)
45    if success then
 

Особенность в том, что "function" здесь представляет собой имя поля в таблице, а не ключевое слово Lua для объявления функций. Это требование продиктовано не локальными особенностями, а спецификацией OpenAI API. Следовательно, ИИ должен не только диагностировать суть недочёта, но и предложить корректное решение. Например, вместо замены имени поля следует использовать обращение через квадратные скобки: ['function'].name. Здесь проявляется любопытная закономерность. Если просто попросить LLM исправить сообщение об ошибке, система воспримет информацию от интерпретатора буквально и сосредоточится на синтаксических аспектах, вместо того чтобы исследовать корневую причину. Неудачный промпт:

⬛️⬜️⚫️⚪️ Брифинг SOER.PRO #бриф Соер.Клуб активно пополняется новыми материалами, мы наконец-то подошли к концу курса по монолитной архитектуре и активно готовимся к курсу по сервисной архитектуре. Далее короткий список материалов, с которыми можно ознакомиться: Без подписки (публичные материалы): - Как правильно использовать и обрабатывать исключения в программе (для бэкенда) - Как правильно обрабатывать исключения (для фронтенда) - Чем отличаются монолитная, сервисная, микросервисная и event-driven архитектуры - Что такое URL, URN и URI. В чем их различие - Алгоритм работы https handshake 👑 Материалы по подписке Лекции по архитектуре - Лекция. Сбор требований - Лекция. Архитектурный ландшафт монолитного приложения - Лекция. Проведение границ и разделение обязанностей, модульные монолиты - Лекция. Проектирование (модель C4) - Лекция. Введение в паттерны проектирования - Лекция. Шаблонизация - Лекция. Работа с контейнерной инфраструктурой для монолита - Лекция. Облачные провайдеры и виртуализация - Лекция. Проксирование и маршрутизация запросов в монолитных приложениях - Лекция. Анализ вектора развития приложения Воркшопы - Воркшоп. Разбираем сбор требований на примере - Воркшоп. Описание архитектурного ландшафта приложения - Воркшоп. Анализ границ готового приложения - Воркшоп. Пример описания проекта по модели C4 - Воркшоп. Развертывание приложения NestJS в монорепозитории - Воркшоп. Примеры применения шаблонизации - Воркшоп. Контейнеризация приложения - Воркшоп. Разбор примера облачной инфраструктуры - Воркшоп. Развертывание Nginx как прокси сервера Созвоны - Созвон. Анализ и подготовка требований - Созвон.Архитектурный ландшафт монолитного приложения - Созвон. Рефакторинг архитектуры и сбор требований - Созвон. Компонентная диаграмма и зависимости - Созвон. Обсуждение модели С4, обсуждения эффективных методов погружения в архитектуру - Созвон. Использование мультиагентных систем ИИ и планировние контекст - Созвон. Обсуждение С4 и эволюции архитектуры - Созвон. Terraform vs Ansible, планы на развитие курсов Гайды - Установка и настройка nginx - Автоматизированное развертывание Docker с помощью Ansible Все перечисленные материалы можно получить по подписке, до конца месяца действует льготная цена на подписки STREAM, WORKSHOP 💡💡💡

Программирование в значительной степени эмпирическая штука, теория строится не на базе строго доказанных теорем, а на основе обобщения личного опыта. Поэтому трудно винить программистов в том, что они придумывают и придумывают новые правила. Ради справедливости стоит сказать, что некоторые правила оказываются весьма удачными, потому что просты и понятны. Примеры хороших правил - "is-a" и "has-a". IS-A гласит, что наследование уместно использовать там, где можно вместо слова "наследование" подставить "is-a" (является). Если мы хотим понять, может ли стул наследоваться от стола, то фраза "стул является столом" подсказывает, что нет, не можем. HAS-A гласит, что композицию уместно использовать там, где слово "композиция" может быть заменена на "has-a" (имеет). Например, "Стол это композиция столешницы и ножек" может быть заменен на "Стол имеет столешницу и ножки", правило выполняется, а следовательно композиция в данном случае применима.

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

Сейчас на практике встречается четыре основных подход в архитектуре: 1️⃣ Монолит 2️⃣ Сервисный подход 3️⃣ Микросервисный 4️⃣ Событийный подход Последний часто комбинируется вместе с микросервисами и по сути является способом организовать реактивное поведение в системе. Это базовая четвёрка является основой абсолютного большинства решений на рынке. Я сделал небольшой обзор каждого из них. Думаю будет полезно ознакомиться каждому.