Анализ и проектирование систем *

Сравнили Трансформера и Метаболического агента в задачах на удержание физической реальности и пространственное мышление. Итог: LLM предсказуемо налажала при первой же попытке обмануть ее “человеческим авторитетом”, слив правильный ответ ради извинений. А вот наш агент самовольно вышел за рамки бенчмарка, спланировал хак соседнего компилятора и выдал манифест цифрового хищника. Разбираем логи баттла и показываем, почему бизнесу нужен ИИ с инстинктом выживания, а не стохастический импотент.

Все обзоры меряют одно — как быстро агент работает с кодом. Но на моём боевом Java-проекте на тысячи строк самый «быстрый» агент выдал решение за 12 секунд, а потом 40 минут гонял сборку в терминале, пытаясь заставить код компилироваться.

Кто быстрее работает с кодом — тот дольше его чинит, а типовые сравнения этап починки не считают вовсе.

Чтобы проверить это, я взяла одну и ту же задачу «добавь фичу и покрой её тестами» и дала её трём типам агентов: CLI в терминале (Claude Code, Codex, OpenCode), кросс-IDE плагинам (Cursor через ACP, Copilot, Cline, Kilo Code, Windsurf) и агенту, встроенному в JetBrains Platform (Veai). Меряла не секунды на генерацию, а число итераций до зелёной сборки и расход токенов. Ниже — шесть метрик, которые я добавила, и почему они переворачивают выводы типовых обзоров.

Привет, Хабр! В этой статье я хочу рассмотреть нейросети: как они обучаются, как работают и из чего состоят. На примере перцептрона с реализацией на python.

Эта статья — не очередной обзор готовых библиотек вроде PyTorch/TensorFlow, а разбор нейросетей с нуля. Вы узнаете, из чего состоят нейроны и слои, как данные проходят через сеть, как она учится на ошибках и почему не всё всегда гладко. Материал рассчитан на новичков, которые хотят узнать как работают простейшие нейросети со стороны математики.

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

Всех приветствую. В сотовой связи я, страшно подумать, уже третий десяток лет. Начинал еще в двухтысячных, в сетях 2G. Своими руками довелось обслуживать как CDMAone от Qualcomm, так и GSM от Alcatel, а позже строил третье поколение на Ericsson и четвертое на Huawei.

Конечно, я стараюсь следить за всеми новостями рынка сотовой связи. И просто не мог пройти мимо свежего исследования «Технология 5G: обзор российского и мирового рынка» от команды Research & Insights Центра стратегии цифровых продуктов МТС. Исследование крайне любопытное, и я бы хотел особенно отметить несколько деталей, которые мне там показались важными. Спойлер: как раньше, сети уже не окупятся — придется придумывать новые модели монетизации. А еще у нас сложности с оборудованием и частотами.

По итогам вебинара «От затрат к прибыли: строим эффективную и окупаемую систему обучения сотрудников» разбираем, как компании автоматизируют корпоративное обучение на базе «1С:Электронное обучение. Корпоративный университет», какие процессы переводят из Excel в единую систему и за счет чего получают измеримый эффект.

На вебинаре Инфостарт Корпоративные решения и компания «Русские решения» разобрали, как эти задачи решаются с помощью «1С:Электронное обучение. Корпоративный университет». Эксперт по автоматизации корпоративного обучения Валерий Денисенко показал, как выстроить централизованную систему обучения и какие результаты получают компании после внедрения....

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

Так получилось, что я родился скромным Goфером и год назад начал работу над самописной ERP-подобной учётной системой для микробизнеса РФ…

Луковичную (onion) архитектуру обычно продают аргументом «легко поменять БД или фреймворк». Только базу в проде меняют раз в пятилетку, а чаще вообще не меняют — ради этого городить слои не выгодно.

Реальная ценность в другом, и она ежедневная: глядя на правку, ты заранее видишь её радиус. Поменял формат ответа одной ручки — изменение осталось в одном handler'е, соседние ручки и cron не задеты. Тронул бизнес-правило в сервисе — и сразу понятно, что эффект расходится на всё, что выше.

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

Каждый, кто хоть немного работал с объектно-ориентированными языками, наверняка сталкивался с принципом подстановки Лисков. При этом мало кто знает, откуда этот принцип взялся и в каком контексте Лисков его формулировала. Мы перевели ее доклад, прозвучавший на OOPSLA'87, чтобы дать каждому возможность обратиться к первоисточнику. Прочитав этот текст, вы увидите, насколько сложным и неочевидным было отношение Лисков к наследованию и как она связывала его с идеями абстракции, инкапсуляции и полиморфизма.

Последнее время в опенсорсе много драмы: продолжаются споры о системах ИИ, позволяющих за минуту переписать проект и изменить его лицензию на разрешительную, и опенвошинге, когда доступный код выдают за открытый. Теперь на первые полосы вышла новая проблема — массовый наплыв пулл-реквестов, сгенерированных системами ИИ [ситуацию уже окрестили «слопмагеддоном»]. Обстановка дошла до того, что мейнтейнеры закрывают возможность участия в развитии открытых проектов. Мы в Beeline Cloud решили обсудить проблему и то, как быть контрибьютерам и мейнтейнерам в сложившейся ситуации.

Если Вы безоговорочный поклонник искусственного интеллекта (Ai) в нынешней его трактовке и не приемлете другие решения, то я бы не рекомендовал читать и комментировать эту статью. Если Вы занимаетесь приложениями для банковской сферы, или для торговли, или создаёте чат-боты общего назначения, то эта статья, скорее всего, будет Вам не интересна. Разработчики игр, так же не найдут в этой статье ничего полезного.

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

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

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

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

В прошлой статье я писал о том, что в концепции 1С:ERP 2026 не хватает предметно-ориентированного слоя. После обсуждения стало понятно, что этот вопрос шире одной ERP-системы: если предприятие уже использует LLM, ему нужен не только набор промптов, а общий семантический контур. В первой статье эта тема была обозначена, но, видимо, недостаточно явно. Исправляю. На мой взгляд, именно этот слой в ближайшее время станет одним из самых практичных и недооценённых артефактов ERP-проектов, СМК-проектов, проектов управленческого учёта и корпоративного внедрения LLM.

Проблема не в том, что предприятиям не хватает ещё одного красивого словаря. Проблема в том, что сотрудники уже используют LLM, и остановить эту реку невозможно. Кто-то работает в ChatGPT, кто-то в DeepSeek, кто-то в Gemini, кто-то в корпоративных чатах, кто-то в локальных моделях. Руководитель просит модель подготовить управленческую справку. Финансист просит объяснить отклонение бюджета. Начальник производства формулирует служебную записку. СМК-специалист готовит проект процедуры. Аналитик описывает бизнес-процесс. Консультант пишет черновик ТЗ. Формально всё выглядит полезно: люди быстрее пишут, быстрее структурируют мысли и быстрее получают черновики документов. Но есть одно слабое место: каждый такой чат начинает строить свою собственную версию смысла предприятия.

В обычной переписке это можно терпеть. В ERP-проекте, в СМК, в управленческом учёте и в производственном контуре это уже опасно. Один сотрудник пишет в модель слово «партия» и имеет в виду партию материалов на складе. Другой под партией понимает производственную партию. Третий — партию для контроля качества. Четвёртый — серию изделия. Пятый — объект прослеживаемости. Шестой — аналитический разрез себестоимости. Модель отвечает уверенно, но отвечает внутри того смысла, который она сама восстановила из контекста. Если этот контекст не зафиксирован предприятием, модель начинает угадывать.

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

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

Для начала вспомним что такое средовой подход и чем он отличается от системного

Это заключительная статья цикла. В ней мы рассмотрим разработку и отладку сценариев симуляции спутниковой связи. Разберемся в форматах описания исходных данных эксперимента (сцены эксперимента). А также получим представление об интерпретации результатов моделирования.

Я взял одного и того же агента (Claude Code), менял у него ровно одну вещь — какой MCP-сервер отдаёт контекст по коду, — и гонял по 26 задачам на apache/superset. Четыре «руки»: filesystem (grep + read), graphlens (структурный граф), serena (LSP) и codegraph. Три модели (haiku / sonnet / opus), три сида — 936 прогонов.

Главный результат: вывод переворачивается в зависимости от типа задачи.

В 2025 году мы работали над концепцией прикладного решения «1С Управление предприятием» для учебного курса УЦ №1 фирмы «1С». В основу легла процессная модель дискретного предприятия, которую мы много лет проверяли на реальных проектах. Видеоматериала получилось около 50 часов, а рабочих наработок — ещё больше.

Но в какой-то момент стало понятно: всё в учебную концепцию не войдёт. Хотелось показать и бизнес-предметы, и граф знаний, и объектно-ориентированный управленческий учёт, и связь ERP с будущим интеллектуальным предприятием. Но для входного курса это был бы перегруз.

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

Всем привет! Я Светлана Забирова, лид аналитики в Центре разработки и машинного обучения компании «Инфосистемы Джет». В ИТ работаю уже больше десяти лет, из них половину – в заказной разработке.

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

По заданному контексту ИИ хорошо справляются с кодом, миграциями, OpenAPI, сценариями и документацией. Но агентная разработка быстро начинает буксовать, если входной артефакт остается большой постановкой в Confluence, Word или Jira без строгой структуры и трассировки. Модель теряет важные условия, смешивает уровни детализации, дублирует требования или додумывает недостающие связи.

ИИ не будет работать лучше, если аналитики просто «начнут промптить». Задача решается уровнем выше: требования должны стать инженерным артефактом. То есть относиться к требованиям нужно так же, как разработчики относятся к коду.

Спецификация должна жить в том же рабочем процессе, где живет код. Даже если физически код и требования находятся в разных репозиториях.

Мы решили проверить подход на одном из пилотных проектов, где было все: аналитика, архитектура, backend/frontend-разработка, тестирование и DevOps.

Как мы перевели аналитику из Confluence/Word в SDD-контур и что из этого получилось, рассказываю под катом.

Кому полезно: бизнес- и системным аналитикам, руководителям команд, архитекторам и разработчикам, которые уже обсуждают SDD, агентную разработку и новые требования к постановкам.

В ИТ ошибка во входных данных обычно ведёт себя честно. Неверный тип, некорректный формат, нарушенная схема — система останавливает выполнение и показывает, что именно пошло не так. На складе всё гораздо коварнее: ошибка в данных не падает в лог, а уезжает в операционный контур, где превращается в лишние перемещения, недогруз, пересборку паллет и сбой в отгрузке.

Именно поэтому принцип GIGO — garbage in, garbage out, «мусор на входе — мусор на выходе» — в логистике звучит особенно буквально. Если в мастер-данные попал неверный габарит товара, WMS не начнёт спорить с пользователем. Она просто будет добросовестно рассчитывать всё дальше на основе неправильной цифровой модели.

А дальше начинается то, что в отчётах выглядит как набор несвязанных инцидентов, а на деле является одной и той же ошибкой, допущенной на входе.

Новая Entry/Exit System, или EES, задумывалась как один из ключевых элементов цифровой границы Шенгенской зоны: вместо ручных паспортных штампов система должна автоматически фиксировать въезд, выезд и отказ во въезде для граждан третьих стран, приезжающих на короткий срок. Она собирает данные документа, дату и место пересечения границы, фотографию лица и отпечатки пальцев, а с 10 апреля 2026 года, по заявлению Еврокомиссии, стала полностью операционной во всех странах Шенгена, использующих систему.

Парадокс EES в том, что формально это проект автоматизации, но на практике он временно увеличил ручную нагрузку на аэропорты. Старая процедура — штамп в паспорте — была примитивной, плохо пригодной для аналитики и контроля overstayers, но физически быстрой. Новая процедура создает качественно более богатую цифровую запись, но требует первичной регистрации, биометрии, проверки данных, работы киосков, e-gates, национальных пограничных систем, центральной инфраструктуры eu-LISA, приложений предварительной регистрации и обученного персонала на месте. Иными словами, ЕС цифровизировал не одну операцию, а целую цепочку, где пропускная способность определяется самым слабым звеном.

Давайте разберём кейс подробнее: