Russian Association of Software Architects

Одна из самых недооцененных возможностей последних полутора лет заключается в создании инструментов для самих инженеров.

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

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

Так же можно автоматизировать и оптимизировать широкий пласт инженерной рутины.

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

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

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

ИИ углубляет разрыв знаний

Разрыв компетенций между инженерами существовал всегда. В одной команде одни знания, в другой – другие, уровни тоже разные. Логично ожидать, что ИИ его сократит. На практике нередко происходит обратное.

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

Сейчас обучение становится индивидуальным. Человек спросил – модель ответила, он уточнил – она ответила снова. И отвечает она так, что все очень гладко укладывается в голове. Если где-то она ошиблась и увела не туда, сомнения может даже не возникнуть. А потребность обсудить тему с кем-то снижается, – вы ведь уже не просто прочитали, вы прочитанное еще и «обсудили».

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

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

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

🦖

Choose agent patterns from failures, not from a catalog.

“Selecting and Composing Agent Design Patterns” separates two questions: what responsibility is missing, and what execution structure enforces it?

A valid ID can point to the wrong record. A successful API call can return an unusable map. A retried event can apply the same effect twice.

In three local reference systems, combining contracts with execution controls completed or safely refused 11 of 12 scenario families per system. These are constructed fault tests, not production success rates; the new experiments made no LLM calls.

The sharpest result: recovery without consumer-side verification increased false success in the map surrogate. Retrying made an inadequate acceptance rule more dangerous.

Start with the required outcome, reproduce a failure, add the smallest justified control, and verify the resulting artifact. All three compositions still failed when trusted evidence was wrong.