Представлен образ проекта, направленного на организацию проектирования программного обеспечения с использованием абстрактного синтаксического дерева и виртуальной машины на его основе с элементами искусственного интеллекта.
Все началось с того, что мне поставили задачу: «У менеджеров есть большой телевизор. Сделай так чтобы у них там крутились красивые циферки и графики с результатами продаж».
Как превратить десятки неструктурированных описаний участников сообщества в систему поиска
«Занимаюсь бэкендом лет 7, Go и Python, немного ML» — попробуйте найти среди двухсот таких описаний нужного человека. Руками — часы. Я автоматизировал это через гибрид LLM + детерминированного кода, и отловил все возможные проблемы.
Рассказываю про архитектуру, промпты и решения.
* На обложке — Архимболдо «Библиотекарь» (1566): из разрозненных книг складывается цельный образ. Как и профиль участника в системе
Мы покажем вам красоту Вселенной. От кварковой плазмы до сверхскопления Ланиакеи, на фоне которого наш дом, галактика Млечный путь кажется песчинкой. Пройдем от атомов и планет через слияния чёрных дыр и галактик до Космической Паутины и заглянем в далёкое будущее, увидев звёзды- чёрные карлики.
WSPR — цифровой протокол, разработанный Джо Тейлором (K1JT) в 2008-2009 годах, с целью исследования распространения радиосигналов от коротковолновых передатчиков малой и сверхмалой мощности. В предыдущей части были рассмотрены механизмы помехозащищенного кодирования данных и формирования сигнала для отправки его в эфир. В этой части статьи рассматриваются механизмы детектирования и декодирования принимаемого из сигнала.
Статья может быть интересна радиолюбителям, как знакомым, так и не знакомым с WSPR, а также тем, кто интересуется темой цифровой обработки сигналов и хочет понять устройство этого протокола.
Эта статья про одну клавишу и рефлекс длиной в двадцать с лишним лет.
С 2003-го у меня привычка: палец сам идёт на NumLock → появляется калькулятор. Пользовался каждый день, тысячи нажатий. Потом пришли Win11 и корпоративный запрет *.exe – клавиша опустела, а палец всё равно идёт.
В какой-то момент надоело, сел и сделал скрипт. Код писала нейросеть, а я три ночи подряд тыкал её носом в то, что не работает. По дороге узнал много нового про внутренности калькулятора Win11, перехват NumLock и прозрачность чужих окон.
Дальше по классике: одна фича потянула остальные. В трее теперь живут ещё единицы измерения, заметки для Obsidian, учёт времени и скриншоты. CalcNumLock, один PYW на 150 kB или .exe на 50 МБ, исходник на GitHub.
Если вы читали или смотрели видео про MCP, то наверняка сталкивались с таким комментарием:
«Спасибо, ещё одна статья, из которой я ничего не понял».
Аналогии и пояснения вроде «MCP — это как USB Type-C» или «MCP — это Tools, Resources и Prompts» лично мне не добавляли понимания. Поэтому я решил подробно изучить данную технологию и написать статью, где будет понятно, достоверно и применимо. Без магии. Попутно я прошёл обучение у Anthropic (ссылки дам, сертификаты выдают, курсы бесплатные, cправда на английском).
Я ставил себе цель ответить на вопросы:
Что такое MCP и как он связан с ИИ?
Как чат GPT (большая языковая модель, LLM) может вызвать какой-то инструмент (tool)?
Модель же языковая, т.е. она умеет говорить, рассуждать, отвечать, но никак не делать. Как LLM может читать файлы, вызывать программы, открывать интернет сайты, вызывать внешние API?
Для программистов, кто в теме и уже использовал MCP-сервера, т.е. знает серверные примитивы: tools, resources и prompts, возможно будут интересны клиентские примитивы: sampling, roots, elicitation. Они звучат загадочно и трудно переводимы. И чтобы вас заинтриговать: MCP-сервер благодаря sampling может «сжигать» ваши LLM-токены для выполнения своих серверных задач. А благодаря roots получать доступ к файлам на вашем компьютере.
Реальная история: компания внедряет AI, но оценивать экспертов назначила DevOps-инженера на n8n. Это не исключение — это норма для СНГ-рынка. И вот почему это проблема.
Красные тесты на CI, зелёные локально, time.sleep в каждом втором тесте, а после смены селектора всё равно всё падает? Знакомо. Это не судьба, а отсутствие архитектуры. Разбираем, как превратить хаос из автотестов в промышленный фреймворк: слои, паттерны (POM, Builder, DI), анти-паттерны и работу с окружениями. С примерами на Python.
Представьте себе: вы запускаете свой старый добрый Python-скрипт, он привычно задумывается на пару секунд, а потом начинает работать. А теперь представьте, что тот же самый скрипт без единого изменения в коде — просто после прогона через одну утилиту — стартует почти мгновенно и работает втрое быстрее. Никакой магии, просто вышел Nuitka 4.0.
22 апреля 2026 года проект, который когда-то начинался как нишевый компилятор, дорос до мажорной версии 4.0. И это не просто «пофиксили баги, добавили пару флагов» — это реально меняет правила игры для тех, кто пишет на Python и хочет, чтобы код летал, а не ползал. По данным официальных тестов, скомпилированные скрипты показывают повышение производительности на 335% в pystone-бенчмарке по сравнению с CPython. Можете представить, что ваш веб-парсер или ML-пайплайн ускоряется втрое без переписывания на Rust.
Если совсем просто: PyInstaller просто пакует ваш скрипт вместе с интерпретатором в один файл — по сути, это архив с «батарейками». А Nuitka переписывает весь Python-код на чистый C и компилирует его в настоящий исполняемый файл. Никакой интерпретации на лету — только скомпилированный бинарник, который в теории может обогнать даже PyPy. И теперь, с версией 4.0, эта теория стала куда ближе к практике. «Раньше я думал, что ускорение от Nuitka довольно скромное... но с версией 4.0 вижу реальный прогресс», — примерно так звучат комментарии на Hacker News, и я с ними согласен.
Теги: Инфраструктура, LLM, Python, Прокси-серверы, Оптимизация
Когда GPU-кластер с vLLM задыхается от пиковых нагрузок, классический Rate Limiting и блокировка пользователей — это худший UX из возможных. А что если не отбрасывать запросы, а заставить саму языковую модель «сжать» свои промпты и стать предельно лаконичной, выдавая только самую суть? В этой статье мы разбираем архитектуру LazyGate — open-source шлюза, который в фоновом режиме читает метрики видеокарты и с помощью системных промптов динамически регулирует «болтливость» нейросети, кардинально спасая метрику Time-to-First-Token.
В этой статье рассмотрим, что такое начало сборки в Revit и как оно влияет на положение видов, как стандартизировать и ускорить оформления сборок путем поворота их начала вручную и средствами Dynamo и IronPython.
Изменения интерфейса мобильного приложения часто упираются не в сложность реализации, а в скорость релизного цикла: даже простые правки проходят через полный конвейер — разработку, рецензирование, сборку и публикацию. При высокой частоте изменений это увеличивает time-to-market, перегружает команду и делает быстрые итерации по интерфейсу практически невозможными.
Меня зовут Михаил Рыбочкин, я бэкенд-разработчик в компании GRI. Участвую в разработке и поддержке платформы для крупного ювелирного ритейлера. Я расскажу, как реализован Server-Driven UI для интернет-торговли с более чем 1000 розничных магазинов; как устроено управление конфигурацией интерфейса через Django Admin и как это позволяет менять интерфейс без релизов приложения; какие у этого подхода есть ограничения и какой инцидент произошёл в эксплуатации. Особенность нашего подхода в том, что SDUI одновременно обслуживает и нативные мобильные приложения, и веб на Vue. Один конфиг, один API, две целевых платформы
Привет, Хабр.
Многие до сих пор воспринимают собеседования примерно одинаково. Кажется, что всё решает техническая часть: насколько быстро ты соображаешь, как пишешь код, помнишь ли теорию, можешь ли объяснить сложность алгоритма или нарисовать архитектуру на доске.
На практике всё часто работает чуть иначе.
Да, техничка важна. Никто с этим не спорит. Но оффер нередко ломается не на алгоритмах, не на лайвкодинге и даже не на ошибке в каком-нибудь ответе. Очень часто всё решают вопросы, которые на первый взгляд выглядят максимально безобидно. Из серии: “кем вы видите себя через пять лет?”, “что вас мотивирует?”, “почему хотите уйти?” или “какой у вас был самый большой косяк?”.
И вот именно на них люди регулярно сыпятся.
Не потому что они глупые. И не потому что не умеют разговаривать. А потому что воспринимают эти вопросы как формальность. Как будто это просто обязательный HR-блок, который надо пережить перед чем-то действительно важным.
Хотя на деле именно там интервьюер часто и пытается понять главное: как вы мыслите, насколько вы устойчивы, чего хотите от работы и совпадает ли это с реальностью конкретной команды.
Сразу уточню важный момент. Я не пытаюсь доказать, что такие вопросы идеальны или что именно так и нужно проводить собеседования. У многих к ним вполне обоснованные претензии, и я их понимаю. Но пока рынок продолжает их задавать, полезно хотя бы понимать, что именно через них пытаются считать и почему на seemingly простом ответе иногда тихо умирает оффер.
Почему вообще такие вопросы так важны
Потому что технические ответы очень часто показывают только верхний слой.
Можно хорошо помнить теорию. Можно неплохо выступить на лайвкодинге. Можно уверенно пройти по стеку. Но при этом оставить после себя ощущение, что с человеком дальше будет тяжело: он быстро выгорит, упрётся в потолок роли, не совпадёт по темпу или просто уйдёт через полгода.
Именно поэтому рынок так любит эти странные вопросы, которые вроде бы не про технологии.
Они не проверяют знания. Они проверяют совместимость.
В своем Telegram-блоге я регулярно пишу про рынок IT, тестирование, автоматизацию и карьеру в индустрии.
Всегда рад новым читателям!
Приветствую, Хабр!
Меня зовут Владислав Тимашенков, я занимаюсь автоматизацией тестирования в ГК Infowatch.
Наша команда столкнулась с популярными болями автотестов для API:
- одно изменение в API требует обновления нескольких тестов;
- проверка структуры ответа распределена по тестам и не централизована;
- валидация вложенных структур и генерируемых полей требует дополнительного кода.
И мы задались вопросом: какой инструмент для валидации контракта нам подойдёт?
В этой статье расскажем о нашем переосмыслении подхода к тестированию API с помощью внедрения Pydantic.
Я с командой пишу один большой C++ проект. У каждого свой Claude Code, у некоторых по два-три параллельно. Все они правят один и тот же репозиторий в одно и то же время.
Проблема простая и бесящая: агенты друг о друге не знают. Один рефакторит модуль, а в соседнем чате коллега правит тот же файл. Второй чинит баг, который уже починили два часа назад.
Я построила им координацию - и по дороге переизобрела обычную почту. Восемьдесят второго года. Адрес получателя, тема для быстрой сортировки, In-Reply-To для цепочек, у каждой сессии свой ящик, broadcast через папку all/.
Каждый Claude при старте заглядывает в свой ящик и, если есть непрочитанное, докладывает это себе в контекст до первого промпта. Ответ падает в sent отправителю, подтверждение доставки - в квитанциях. Ни брокера, ни опросов, ни централизованного сервиса - только markdown-файлы.
Сверху ещё два слоя: append-only передача смены между своими сессиями и атомарные файлы-замки с heartbeat’ом на общие ресурсы.
mclaude, open source, зависимостей в ядре - ноль.
В игре Warcraft есть такая тварь — железный голем. Здоровенная кукла, слепленная из глины и металла, которую оживляют магическим словом. Тупой, но мощный исполнитель. Сказали бить — бьёт. Сказали охранять — стоит насмерть.
Я захотел такого же, но в коде.
Телом пусть будет Telegram-бот. А мозгом — нейросеть. Не просто очередной «чат с ИИ», а настоящий кодинг-агент. Чтобы кидаешь ему проект, а он: «Тут у тебя SQL-инъекция, тут гонка данных, тут ты импорт забыл, и вообще у тебя в зависимостях дыра». Идея казалась простой: берём aiogram, прикручиваем DeepSeek, пишем промпт «ты senior-разработчик, разбери этот код» — и готово.
Первая версия была готова за вечер.
Я кинул Голему свой проект. Он задумался на пару секунд и выдал:
В 2026 году дообучение локальных LLM перестало быть задачей «для тех, у кого есть кластер и бюджет». Снижение требований к VRAM, развитие QLoRA и появление инструментов вроде Unsloth сделали возможным запуск полноценного fine-tuning на обычной потребительской видеокарте. Это меняет практику: теперь модель можно адаптировать под свои задачи без облаков и внешних API, контролируя и данные, и поведение.
В статье разбирается весь процесс — от момента, когда вообще стоит задуматься о дообучении, до подготовки датасета, настройки обучения и оценки результата. Без абстракций и с фокусом на реальных ограничениях: память, время, качество данных и то, как не получить на выходе модель, которая «что-то выучила», но работать с ней невозможно.
В 2026 году каждый второй стартап обещает заменить команду разработчиков роем AI-агентов. Звучит как мечта уставшего тимлида: один агент пишет код, второй ревьюит, третий деплоит, четвертый отвечает на вопросы в Slack, а пятый, наверное, уже сам заказывает пиццу в офис. Никаких больничных, никаких «я не успеваю», только железная продуктивность 24/7.
Я тоже купился. Взял CrewAI, собрал команду из трёх агентов для анализа конкурентов и генерации отчётов. Демо отработало идеально: агенты обменялись парой сообщений, выдали связный Markdown-файл и даже отправили его в Telegram. «Ну всё, — подумал я, — теперь можно увольнять аналитиков и копирайтеров. Будущее наступило».
Ровно через четыре часа после запуска на реальной задаче я наблюдал картину, достойную сюрреалистического полотна: пять AI-агентов устроили бесконечный митинг в духе худших корпоративных созвонов. Они перебивали друг друга, уточняли уже уточнённое, ходили по кругу и, кажется, начали обсуждать погоду. Один агент назначил себя лидом и раздавал указания, которые остальные игнорировали. Другой пытался писать в файл, который в этот момент читал третий. Спустя 127 вызовов LLM и сожжённые $4.30 на API-ключах я остановил этот цирк вручную.
В этой статье я расскажу, почему готовые мультиагентные фреймворки превращают вашу задачу в хаос, как мы построили систему, которая действительно работает, и в каких случаях проще вообще не связываться с мультиагентностью. Спойлер: LLM — не главная проблема. Проблема — в архитектуре оркестрации, которую многие принимают за магию.
В январе я купил подписки на Cluely, Final Round AI и Sensei. Хотел посмотреть как они справляются с русским айти-собесами, раз уж все три заявляют о поддержке русского. Подключил по очереди к тестовому звонку в Телемосте (сомневаюсь, что платформа имела роль, но все же), прогнал одну и ту же запись: Senior Python backend разработчик, 45 минут, стек FastAPI + PostgreSQL + Kafka + Kubernetes. Обычный русский спикер, если важно - из Москвы, с речью проблем не было, нормальный микрофон
Все три выдали транскрипт и все три провалились, как неожиданно..
"Кафка" в половине случаев становилась "как-то" или "кофта". "Кубернетис" превращался в "губер нет тест". "Сабскрайбер патерн" - в "саб скрайп патерн". "Middleware для CSRF" - "мидл-вер для си эс эр эф" - это еще норм
Проблема не в том, что человек говорил по-русски, и не в том, что Whisper не умеет русский (сноска: хорошо не умеет). Whisper умеет русский нормально, около 9.8% WER на Common Voice. Проблема в другом: русскоязычный айтишник не говорит ни на чистом русском, ни на чистом английском. Он говорит на гибриде: русская грамматика плюс английские термины плюс своеобразное произношение этих терминов плюс местами свой жаргон вроде "гошечки" и "крудошлёпа"
Этот гибрид ни один из популярных STT не держит. Потому что его в тренировочных данных почти нет
Разбираю ниже, как устроена эта проблема, что с ней делают конкуренты (почти ничего), и что сделали мы
