S0ER - architecture and coding

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

Завел себе канал в Максе, говорят там самая адекватная аудитория! Когда телегу поблочат, увидимся с вами там) Ссылка скрыта

Промпт для исправления ошибок в коде Некоторое время использую QWEN3-Coder-480b-А35b-Instruct и QWEN Coder. Модель в чем-то хороша, в чем-то не очень. Хочу рассказать о своем опыте борьбы с неверным поведением модели. Когда ИИ генерирует программный код, он может допускать ошибки, как и обычный разработчик. Синтаксические проблемы исправляются довольно просто, но встречаются и более сложные случаи, связанные с семантикой. Хочу разобрать конкретный пример, который демонстрирует, насколько по-разному может работать ИИ в зависимости от формулировки промпта. Сообщение от интерпретатора выглядит так: Failed to run `config` for agentsoer.nvim vim/loader.lua:0: ...soer/projects/agentsoer.nvim/lua/agentsoer/engine/ai.lua:43: '' 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 исправить сообщение об ошибке, система воспримет информацию от интерпретатора буквально и сосредоточится на синтаксических аспектах, вместо того чтобы исследовать корневую причину. Неудачный промпт: Исправь ошибку vim/loader.lua:0: ...soer/projects/agentsoer.nvim/lua/agentsoer/engine/ai.lua:43: '' expected near 'function' # stacktrace: ... Эффективный промпт: Проанализируй причину возникновения ошибки, рассмотри несколько подходов к решению и предложи способ устранения: vim/loader.lua:0: ...soer/projects/agentsoer.nvim/lua/agentsoer/engine/ai.lua:43: '' expected near 'function' # stacktrace: ...

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

⬛️⬜️⚫️⚪️ Брифинг 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 отметок 💡, выполняю свое обещание и публикую новую заметку на тему исключений - Как правильно обрабатывать исключения (для фронтенда). На этот раз я больше задумался об архитектурных вопросах обработки ошибок, и в итоге получил более полный и глубокий разбор, надеюсь вам понравится. SOER | PRO | Boosty

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