На Архитектурном трёпе #125 обсудили работу с системами Retrieval-Augmented Generation (RAG).

🎯 С чего начинать: готовые решения или своё?

Я рекомендую сначала взять готовое SaaS-решение за $100 в месяц, проверить свои гипотезы, понять, что именно вам нужно, а уже затем задумываться о собственной разработке

Советы участников по первому этапу:

🔸Быстро тестируйте идеи на готовых решениях
🔸Не усложняйте сразу — идите от простого к сложному
🔸Применяйте проверенные библиотеки (LamaIndex, LangChain)

🧩 Векторный и гибридный поиск

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

Проблемы чистого векторного поиска:

🔹Потеря семантики из-за неправильного чанкирования
🔹Снижение производительности при увеличении объёмов данных
🔹Недостаток точности при обработке сложных запросов

Рекомендуемые практики:

🔸Сочетайте векторы с дополнительными фильтрами
🔸Структурируйте метаданные заранее
🔸Используйте LLM для автоматизации создания метаданных

🗄 Проблемы хранения данных

Участники сошлись во мнении, что оптимальный подход состоит из нескольких уровней:

🔹Исходные файлы (PDF, изображения) — отдельно, например, в S3
🔹JSON-данные и промежуточные структуры — в MongoDB
🔹Финальные векторные данные — в PostgreSQL с PgVector или специализированные векторные базы

📑 Чанкирование и обработка информации

Неправильно созданные чанки резко снижают качество поиска, поэтому важно подходить к этому осмысленно и постепенно уточнять чанки

Рекомендации по чанкированию:

🔸Начинайте с базовых подходов (по абзацам)
🔸Применяйте LLM для определения границ смысловых блоков
🔸Вручную дорабатывайте чанки для сложных документов

🗃 Разные типы информации — разные архитектурные решения

🔹Простые тексты требуют минимум усилий
🔹Таблицы и формулы нуждаются в отдельной логике обработки
🔹JSON-данные и транскрибации разговоров требуют особой структуры

Каждый тип данных — это новая архитектурная задача. Всегда учитывайте, как новая информация повлияет на вашу RAG-систему

🛠 Реальные кейсы, проблемы и рекомендации

Модератор встречи Peter Hanzo поделился кейсом из практики:

Мы делали поиск агрохимикатов. Пользователь задаёт вопрос, чем лечить томаты от конкретной болезни. RAG-система на основе векторного поиска и фильтрации по метаданным из нескольких тысяч препаратов выделяет 5 подходящих

Другие практические советы от участников:

🔹Используйте реальные запросы пользователей
🔹Тестируйте RAG-системы на заранее подготовленных наборах вопросов
🔹Применяйте LLM для постобработки и улучшения результатов
🔹Не забывайте о пользователях

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

🔗А еще Peter Hanzo поделился списком полезных материалов по теме:

раздел Вступление в RAG
https://docs.llamaindex.ai/en/stable/understanding/rag/
https://github.com/mem0ai/mem0
https://github.com/memodb-io/memobase

раздел Векторный поиск
https://github.com/pgvector/pgvector
https://weaviate.io/blog/multimodal-search-in-typenoscript
https://jkatz05.com/post/postgres/hybrid-search-postgres-pgvector/

раздел Гибридный поиск
https://docs.opensearch.org/docs/latest/vector-search/ai-search/conversational-search/#step-6-use-the-pipeline-for-rag
https://aws.amazon.com/ru/blogs/big-data/amazon-opensearch-service-vector-database-capabilities-revisited/
https://github.com/meilisearch/meilisearch
https://nuclia.com/
https://github.com/infiniflow/infinity

раздел Проблемы и Хранение
https://unstract.com/
https://github.com/quivrhq/megaparse
https://github.com/docling-project/docling

раздел Готовые проекты
https://github.com/infiniflow/ragflow
https://github.com/Cinnamon/kotaemon
https://github.com/deepset-ai/haystack
https://github.com/milvus-io/milvus
https://github.com/HKUDS/LightRAG
https://github.com/oramasearch/orama
https://github.com/gusye1234/nano-graphrag
https://github.com/vanna-ai/vanna
https://github.com/trustbit/RAGathon
https://github.com/danny-avila/rag_api
https://github.com/confident-ai/deepeval

🚀 Завтра встречаемся на митапе «AI-ассистент для разработчиков: внедрение и метрики в большой организации»!

Как встроить AI в ежедневную практику разработчиков? Разбираем реальный кейс: от подготовки репозитория и промптов до измерения метрик и обратной связи от команды.

🎤 Спикер — Ильшат Назаргулов, Lead Backend Developer с 10+ годами опыта.

📅 Присоединяйтесь, начало в 20.00 GMT+3

🎙 Друзья, завтра собираемся обсудить один из самых волнующих вопросов этого года - что происходит с работой в 2025 и что нас ждёт дальше?

Когда: 24 июля, в 20.00 GMT+3

🧭 Поговорим о рынке, найме и повседневной реальности разработчиков:

‣ Где действительно сейчас находят работу?
‣ Нужно ли backend-инженерам осваивать фронт (и наоборот)?
‣ Две работы одновременно - норма или путь к выгоранию?
‣ Как AI уже меняет нашу работу, и какие риски и возможности ждут впереди?

📌 Регистрация
До встречи!

Навыки техлида: Architectural Vision и его значение

🏗 Architectural Vision: фундамент успешного проекта

Architectural vision – это способность задать технический курс разработки: спроектировать систему под бизнес-цели, предвидеть будущие потребности и создать целостную структуру, которой будет следовать команда.

Для опытного техлида “видеть архитектуру” – значит мыслить на несколько шагов вперед, чтобы сегодняшние решения не обернулись проблемами завтра. Это не просто выбор технологий – это умение связать технические решения с долгосрочной стратегией продукта и жизненным циклом системы.

🧭 Роль техлида в архитектуре

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

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

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

Эффективный техлид сочетает навыки архитектора и ведущего разработчика: создаёт в команде общее техническое видение и несёт ответственность за качество технических решений.

⚠️ Когда архитектурного видения не хватает

Отсутствие продуманной архитектуры способно похоронить даже перспективный проект. По данным исследования Standish Group, 50% провалов IT-проектов происходят из-за ошибок в архитектуре.

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

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

📋 Architectural Vision на практике: что делает техлид?

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

🔸 Определяет ключевые атрибуты системы: масштабируемость, производительность, надёжность, безопасность – и показывает, как они влияют на дизайн архитектуры.

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

🔸 Доносит архитектуру до команды: эффективный техлид не держит архитектурные идеи в голове – он визуализирует их. Это позволяет разработчикам понять свои задачи в контексте всей системы. Обсуждая архитектуру вместе с командой, техлид повышает общую инженерную культуру и вовлечённость – каждый понимает, зачем выбран тот или иной подход.

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

🚀 Взгляд вперёд как ключевой навык

Architectural vision – это про мышление на перспективу. Техлид с развитым архитектурным чутьём действует как навигатор: указывает команде направление, обходя непродуманные решения. В итоге выигрывают все – и разработчики (меньше хаоса и авралов), и бизнес (продукт развивается предсказуемо и надёжно).

🧠 Уже завтра встречаемся на митапе - Agentic AI: зачем он нужен и как работает?

📅 29 июля, 20:00 GMT+3

Что такое агентный ИИ и почему за ним будущее? Обсудим архитектуру AI-агентов, реальные кейсы, ограничения LLM-подходов и как их преодолевает agentic AI.

👨‍💻 Спикер: Данила Поддубный, Lead DevOps Engineer @ Intel

Регистрация

Привет, друзья! 👋
А есть тут кто из Казахстана? 🇰🇿

Мы всерьёз задумались о проведении оффлайн-митапа в Алмате и хотим понять, есть ли у нас там местные и какой формат вам был бы интересен.

Если вы в Алмате или поблизости — очень ждём ваш голос! 🙌

PS. И если вам интересно помочь с организацией, поделиться советом или выступить на митапе — пишите Даше: @d_zherebtsova

📌 Архитектура без архитектора? Приходите обсудить!

Круглый стол для инженеров и техлидов — обсудим, где заканчивается зона ответственности разработчика и начинается архитектура. Что происходит, когда решения принимаются “де-факто”? И нужна ли вообще формальная роль архитектора?

📅 7 августа, 20:00 GMT+3
🎙 Ведущий: Антон Дворников, Principal Solution Architect
👥 Участники:
‣ Вячеслав Панасов, руководитель направления
‣ Артём Жильцов, Tech Lead в FinTech

👉 Зарегистрироваться

На 126-м Архитектурном Трёпе обсудили текущее состояние рынка труда в IT, новые тренды в найме и использовании AI.

Вот краткая выжимка беседы:

📉 Текущая ситуация на рынке труда и тренды в найме

Рынок IT стал более конкурентным:

🔸На каждую вакансию теперь поступают сотни откликов
🔸Процессы собеседования усложнились и включают больше этапов даже в небольших компаниях
🔸Важность личного нетворкинга выросла в разы
🔸Компании используют автоматизированные системы отбора (ATS), поэтому критично включать правильные ключевые слова в резюме
🔸В Европе ужесточились языковые требования – часто обязательно владеть местным языком

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

🤖 ИИ и его влияние на разработчиков

AI уже плотно интегрирован в повседневную работу разработчиков и приносит существенные бонусы:

🔹Сильно ускоряет рутинные задачи и кодинг
🔹Ускоряет навигацию и поиск информации в больших проектах

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

Но участники выражают опасения о качестве сгенерированного кода:

Люди бездумно копируют код, сгенерированный AI, не понимая, как он работает. Это создаёт проблемы поддержки и качества продукта в долгосрочной перспективе

🛠 Новые требования к профессиональным навыкам разработчиков

🔸Высокий спрос на fullstack-специалистов с пониманием бизнеса и инфраструктуры
🔸Ценность разработчиков, умеющих эффективно интегрировать AI-инструменты в рабочий процесс
🔸Важность навыков системного и архитектурного мышления

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

🌍 Этические и культурные аспекты использования AI

Использование AI в коммуникациях и управлении сотрудниками поднимает важные этические вопросы:

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

Если сотрудник узнает, что важный фидбэк был написан AI, это может серьезно подорвать доверие и внутреннюю культуру компании

⚡️ Практические советы для кандидатов и работодателей

🔸Активно развивайте свой LinkedIn-профиль и нетворк
🔸Используйте AI не для слепого копирования, а для помощи в работе и ускорения рутинных задач
🔸Старайтесь глубоко разбираться в задачах, не полагаясь полностью на автоматизацию

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

ИИ — угроза или возможность?
Как меняется работа инженера под давлением искусственного интеллекта?

🗓 12 августа, в 20.00 GMT+3

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

Темы дискуссии
📉 Тренды и рынок:
– Что происходит с ИТ-вакансиями?
– Какие роли исчезают, а какие наоборот набирают вес?

🤖 Влияние ИИ:
– Какие задачи уже автоматизирует ИИ?
– Станет ли команд меньше? Как изменится найм?

🧩 Новые навыки:
– Какие компетенции становятся must-have в 2025?
– Нужно ли инженерам изучать Prompt Engineering и LLM?

🔁 Найм и карьера:
– Что определяет сильного кандидата сегодня?

🧭 Личное и системное:
– Как понять, что ты отстаёшь от рынка?
– Где искать точки роста — и как помогает комьюнити?

👉 Оставить свой вопрос и зарегистрироваться

Архитектурные катастрофы: уроки провальных проектов - Часть 2

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

🌩 Netflix – трёхдневный сбой, изменивший всю архитектуру

В августе 2008 у Netflix из-за серьёзной порчи базы данных лег почти на три дня, остановив отправку DVD-дисков подписчикам. Корень проблемы – монолитная система с единой точкой отказа.

Инженеры Netflix отказались от вертикально масштабируемого монолита с централизованной БД и перешли к распределённой облачной системе микросервисов, устранив «single point of failure».

За последующие годы Netflix постепенно перенёс все компоненты в AWS, добившись высокой отказоустойчивости и масштабируемости. Появилась «Chaos Monkey» – утилита, намеренно ломающая произвольные части системы в продакшене, чтобы убедиться, что всё выдержит падение любого узла.

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

Урок: Если в системе есть единственные точки отказа, рано или поздно они обязательно откажут. Лучшая инвестиция – вовремя построить резервирование и гибкость архитектуры, пока сбой не обошёлся вам простоем или хуже.

🗑 Netscape – переписали с нуля и проиграли «войну браузеров»

В 1990-х браузер Netscape Navigator царил на рынке, но его кодовая база устаревала и обрастала проблемами. Вместо постепенного улучшения в 1998 руководство Netscape приняло решение: выбросить старый код и переписать браузер с нуля.

На это понадобилось больше двух лет, за которые конкуренты ушли далеко вперед. Internet Explorer от Microsoft (бесплатный и агрессивно продвигаемый) захватил пользователей, пока в Netscape работали над новой версией. Когда переписанный Netscape 6 наконец вышел, было поздно – аудитория уже ушла, доля рынка рухнула.

Как метко заметил один эксперт, выбрасывая старый код, вы выбрасываете все накопленные знания и багфиксы, и фактически дарите конкурентам фору в два-три года.

Netscape стал ярким примером Second System Syndrome, когда попытка создать «идеальный» второй вариант убивает рабочий первый.

Урок: Переписывание всей системы с нуля – крайне рискованный шаг. Чаще выгоднее рефакторить и эволюционно переделывать продукт, сохраняя накопленный опыт. Новая архитектура должна созреть постепенно; иначе можно потратить годы впустую, пока конкуренты захватывают рынок.

🏙 SimCity 2013 – «всегда онлайн», в который никто не смог играть

Релиз игры SimCity 2013 стал примером того, как неудачное архитектурное решение способно уничтожить репутацию продукта в первый же день. Компания EA заложила в архитектуру требование always-online: даже одиночная игра требовала постоянного подключения к серверу.

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

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

Оказалось, что ничего критичного в онлайне не было, и маркетинговые заявления EA были неправдой. Это подорвало доверие окончательно. Даже спустя время, когда патчи частично исправили ситуацию, игра уже потеряла аудиторию (которая перебралась в Cities: Skylines и другие проекты). Легендарная серия SimCity фактически похоронила себя этой неудачей.

Урок: Если вы закладываете жёсткие ограничения ради бизнес-целей, убедитесь, что ваша инфраструктура потянет. Архитектура должна служить интересам пользователя – навязывание неудобных решений (ещё и плохо реализованных) оборачивается катастрофой для продукта.

🚀 Как построить AI-инфраструктуру и не сойти с ума?

Разберём на реальных кейсах, как проектировать и развивать инфраструктуру под ИИ-нагрузки — от стартапов до корпоративных систем, сохраняя качество и здравый смысл.

📅 Когда: 14 августа, 20:00 (GMT+3)

💡 В программе:

• Как подойти к проектированию AI-инфраструктуры на разных стадиях компании
• Лучшие практики, проверенные в боевых условиях
• Типичные ошибки и как их избежать
• Лайфхаки, которые экономят время и ресурсы команды

🎙 Формат: доклад + живое обсуждение — можно будет задать свой вопрос и разобрать реальные ситуации участников.

👤 Спикер: Данила Поддубный, Lead DevOps Engineer @ Intel. Специалист по высокопроизводительным вычислениям и инфраструктуре для ИИ-обучения

👉 Регистрация

📢 19 августа приглашаем на Круглый стол о роли технического лидера сегодня!

Вместе с выпускниками и выпускницей программ H&S Skills поговорим честно и без фильтров:
— какие вызовы стоят перед лидерами в 2025 году
— чему учатся и на чём ошибаются
— как внедряют новые технологии и при этом держат команду в фокусе

Это не лекция, а живой разговор про опыт, рост, компромиссы и реальные истории изнутри индустрии.

💬 Темы: путь в техлиды, роль и задачи, ошибки и инсайты, работа с AI, команда и процессы.
🎯 В финале: советы тем, кто хочет расти в новую роль, и тем, кто уже делает первые шаги.

🕗 Начало: 20:00 GMT+3

🙌 Регистрируйтесь по ссылке и оставляйте свои вопросы!

Эволюция API: совместимость, версии, депрекация

API неизбежно меняется. Задача техлида — сделать так, чтобы новые возможности не ломали клиентов и чтобы старое уходило предсказуемо. Ниже — концентрат практик для REST/gRPC/GraphQL.

📐 Правила контрактов (REST / gRPC / GraphQL)

REST. Добавляйте — не изменяйте: новые необязательные поля, стабильные коды и семантика. Не переиспользуйте поля, не меняйте форматы без явной версии. Идемпотентность для PUT/DELETE, ETag/If‑Match для конкуренции.

gRPC. В protobuf не трогайте номера полей, не меняйте типы/смысл, помечайте reserved для удалённых. Новое — через optional/поведенческие флаги. Версии — в package/service‑имени, параллельные реализации допускаются.

GraphQL. Расширяйте схему (новые поля/типы), не удаляйте и не переименовывайте. Используйте @deprecated(reason) и телеметрию по полям. Не ужесточайте nullability без major‑миграции.

🚦 Версионирование

Минимум версий — максимум совместимости.

REST: для breaking‑изменений — vN (лучше в header/mediatype; путь — допустимо, но грубо). Для additive — без версии.

gRPC: новая major — новый package/service; клиенты пинят контракт.

GraphQL: обычно одна активная схема; breaking — через параллельную схему/шлюз на время миграции.

🧰 Feature gates и capability‑договорённости

Включайте новые поведения по флагам (per-tenant/per-token). Клиент может передавать заголовок/параметр «хочу новую фичу», сервер — объявлять поддерживаемые возможности (capabilities) в метаданных/SDL.

⏳ Депрекация и sunset policy

Фиксируйте этапы: объявление → фриз → ограничение → отключение. Сигнализируйте в ответах (заголовки/метаданные, предупреждения в GraphQL), укажите дату sunset и альтернативу. Замерьте фактическое использование и держите окно поддержки (например, 6–12 месяцев).

🧪 Контрактное тестирование

Consumer‑driven подход: контракты клиентов выполняются против «будущей» версии (Pact/Spring Cloud Contract). Для REST — проверка OpenAPI/примеров/генерации SDK; для gRPC — buf breaking/lint; для GraphQL — проверки схемы, запроса и директив депрекации. Интегрируйте в CI, блокируйте breaking без явного major.

📣 Коммуникация с клиентами

Единый каталог API, changelog, рассылки/вебхуки о депрекациях, версии SDK и примеры миграции. SLA по окнам поддержки, статусная страница, канареечные релизы. Меряйте: кто вызывает устаревшее, какие поля/методы — и целенаправленно помогайте мигрировать.

✅ Чек‑лист эволюции API (REST / gRPC / GraphQL)

🔸 Контракт зафиксирован (OpenAPI/Protobuf/SDL), lint и «breaking‑скан» в CI.
🔸 Добавочные изменения — без версии; breaking — только через новую major.
🔸 Feature gates: план включения per‑client, откат и метрики.
🔸 Телеметрия по endpoint/методу/полю, дэшборды использования.
🔸 Sunset policy с датами, сообщениями и альтернативами.
🔸 Consumer‑driven контракты, авто‑ген SDK и примеры миграции.
🔸 Каталог API и понятный changelog; канареечный/теневой прогон.
🔸 План совместного существования версий и критерий выключения (0 трафика N дней).

🧭 План миграции без боли

🔹 Инвентаризация клиентов и их версий; включите метки клиентских приложений.
🔹 Запустите vNext совместимым (тени/dual‑write), соберите метрики.
🔹 Откройте feature gate избранным клиентам → канареечное расширение.
🔹 Заморозьте v1 (только багфиксы), объявите даты и гайды.
🔹 Переведите SDK/CLI и шаблоны; помогите ключевым клиентам руками.
🔹 После 0 трафика на v1 N дней — поэтапно отключайте, оставив «красную кнопку» отката.

Эволюция API – это не разовый "v2". Формализуйте правила, измеряйте использование, коммуницируйте заранее – и ваши изменения станут предсказуемыми для клиентов и безопасными для бизнеса.

Друзья, всех с пятницей!🕺

У нас к вам вопрос - мы хотим познакомиться ближе с теми, кто ведёт свои блоги, каналы или медиа на технические темы.

👉 Если у вас есть свой проект (в Telegram, LinkedIn, Medium или где угодно), вы публикуете что нибудь интересное или организуете мероприятия — онлайн или офлайн — делитесь ссылкой в комментариях.

Мы собираем список таких проектов, чтобы потом поискать классные идеи и возможности для коллабораций 💪

PS. или присылайте в личку Даше @d_zherebtsova

Переход в техлиды: как не потерять технические навыки

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

Шире зона ответственности – меньше hands‑on. Из‑за страха потерять форму многие тормозят переход. Поговорим о том, как сохранить технические навыки, когда на первый план выходит лидерство.

🧠 Какие технические навыки должны быть у техлида?

Это не только про написание кода. Технические навыки это еще: 

🔹 Читать и ревьюить PRы 
🔹 Проектировать архитектуру, которую смогут реализовать другие разработчики
🔹 Разбирать инциденты по метрикам/трейсам/логам
🔹 Понимать CI/CD и стоимость инфраструктуры
🔹 Управлять безопасностью и данными

Умение разбираться во всем этом даёт доверие команды, качество решений и возможность преодолевать кризисы, когда важны точные технические trade‑off’ы.

🛠Где углубляться, а где расширяться: T‑shape

Глубина – 1-2 ключевых вертикали вашего домена (например, платформа данных и производительность; надёжность и безопасность). Здесь вы задаёте стандарты и отвечаете за сложные решения. 

Ширина – грамотность в соседних областях: протоколы и интеграции, типы хранилищ, облака/сети, CI/CD, SLO и экономика эксплуатации. 

Суть T‑shape: вы обязаны видеть последствия решений соседей и ставить guardrails, но не становиться единственной «точкой знания» по всем стекам.

⌨️ Как поддерживать навыки написания кода и не стать bottleneck для команды

🔸 Квоты на код. Выделите 4–6 часов в неделю на low-risk задачи: техдолг, тест‑фиксы, внутренние утилиты. Малые PR, trunk‑based, без критического пути
🔸 Tracer‑bullets. Разрабатывайте быстрые прототипы для новых идей (1–2 дня), а затем передавайте другим исполнителям
🔸 Парное программирование. Вы сохраняете практику, команда растёт
🔸 On‑call с кодом. Ротация дежурств раз в квартал с «fix‑forward» правками: учит быстрому чтению незнакомого кода
🔸 Инфраструктурные библиотеки. Курируйте 1–2 общие библиотеки/шаблоны (логирование, ретраи, telemetry). Это регулярный hands‑on и мультипликатор для команды
🔸 Ограничьте блокировки. SLA на ревью (например, ≤24 часа), резервные ревьюеры, запрет «последней кнопки» деплоя у техлида

📏 Как измерять impact, когда не пишешь код?

Смотрите на результаты системы. DORA‑метрики показывают скорость delivery (lead time for changes, частота деплоя, time to recover, доля неуспешных изменений). 

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

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

⚠️ Ошибки и антипаттерны начинающих техлидов

🔹 Супер‑разработчик. Пишете ключевой код сами — команда ждёт. Решение: RACI, владение модулями у инженеров, вы — наставник и арбитр
🔹 Big‑bang переписывания. “Сделаем правильно с нуля”. Решение: эволюция, strangler pattern, поэтапные критерии успеха
🔹 Ревью bottleneck. Все PR через вас. Решение: стандарты кода, обучение ревьюеров, два параллельных потока ревью, авто‑чеки
🔹 24/7 митинги. Календарь съедает все рабочее время. Решение: тайм‑боксы, асинхронные ADR
🔹 Архитектура без эксплуатации. Решения без данных эксплуатации. Решение: дизайн‑сессии с on‑call, телеметрия и canary перед масштабированием

Друзья, наше сообщество растёт – к нам регулярно присоединяются новые участники🚀
Мы сделали этот пост-ориентир, где собрали всё самое важное о нас, наших форматах и возможностях.

⚙️ О нас

Hard&Soft Skills community – это объединение инженеров, для которых разработка – больше, чем код.
Мы создаём среду для ИТ специалистов, которые хотят расти шире кода – разбираться в архитектуре, процессах, продуктах и людях.

🎤 Наши форматы

Мы регулярно проводим онлайн мероприятия в разных форматах: Архитектурные Трепы, технические доклады, митапы, круглые столы, live-design cессии и др.

👉 Расписание ближайших событий смотрите в нашем календаре.

Но мы хотим не только встречаться онлайн, а ещё и знакомиться вживую 🕺

Этой осенью запускаем серию оффлайн-встреч в разных городах: Батуми, Минск, Алматы, Варшава. Первая встреча пройдет 18 сентября в Батуми, следите за апдейтами 👀

🤝 Как участвовать

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

А ещё мы очень ценим вашу повседневную активность 🙌 Когда вы приходите на мероприятия, читаете посты, комментируете и ставите реакции – именно это делает наше комьюнити живым и ценным.

💬 Где общаемся

📢 Канал в Telegram (вы здесь!) – анонсы, полезные материалы, опросы.
💬 Чат в Telegram – задать вопроc, обсудить профессиональные трудности, поделиться новостями или найти поддержку.
▶️ YouTube-канал – записи всех встреч, которые вы могли пропустить.

📚 Лучшие посты и материалы в канале

[Компетенции разработчика: как найти свои слабые и сильные стороны?]
[Чек-лист техлида: все ли хорошо у вас на проекта?]
[Почему проектировать системы сложно?]
[Event Sourcing: что это, зачем нужно и когда применять?]
[Что мешает разработчику расти?]
[4 фундаментальные книги для техлида]
[Чек-лист: готовы ли вы стать архитектором?]
[4 must-read книги для архитектора]

📌 Сохраняйте этот пост, он будет вашим ориентиром. И добро пожаловать в комьюнити Hard&Soft Skills 🫂

Мы не успели обсудить тему поиска работы на прошлом Трёпе, поэтому по вашим запросам проводим её ещё раз 🙌

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

🗓 28 августа, 20:00 (GMT+3)
🎙 Архитектурный Трёп №127

Тема: Как мы ищем работу сегодня: обмен реальными кейсами

Поговорим о том, какие каналы реально работают, что только тратит время, насколько помогают нетворкинг и личный бренд, и разберём успешные кейсы трудоустройства в Европе и США.

👤 Модератор: Виктория Телюк

🔗 Регистрация

Друзья!

26 августа мы провели митап «Технический лидер», на который предварительно зарегистрировалось почти 700 участников!

К сожалению, из-за ограничений Google Meet не все смогли подключиться онлайн.
Мы приносим извинения за неудобства 🙏 и предлагаем вам посмотреть митап в записи:

🎥 Ссылка на запись митапа

📑 Ссылка на презентацию

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

А если у вас ещё остались вопросы – приглашаем на бесплатную консультацию с ex-Architect Miro и EPAM Павлом Вейником:
👉 Записаться на консультацию

Количество слотов ограничено, успейте забронировать!
Всем продуктивного дня ✨

Как мы ищем работу сегодня: обмен реальными кейсами - выводы Архитектурного трёпа #127

🎯 Где и как находят работу сегодня: новые требования к разработчикам

Сегодня выигрывают те, кто соединяют широту навыков с управляемым использованием AI: T‑shaped (бэк, фронт, немного DevOps) + умение объяснить промптинг и валидацию решений

Рабочие каналы – прямые сообщения нанимающим и рефералы. Они срабатывают лучше массовых откликов.

Границы между специальностями стираются… в одном человеке хотят фронт, бэк, шарить за DevOps – и опыт внедрения LLM в процессы

🌍 Состояние рынка по стекам и регионам: AI в работе и на собеседованиях

По стекам спрос смещается: где‑то «потише» по Java, местами активнее зовут на Go; full‑stack‑профили продаются легче, особенно в распределённых командах.

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

На лайвкодинге стали разрешать AI: в работе всё равно будете пользоваться; запрещать — всё равно что заставлять писать в текстовом редакторе

🎰 Процессы найма: как происходит, ATS и «лотерея» откликов

Типовой конвейер удлинился: скрининг → офлайн‑задача → live‑coding → финальный разговор; встречаются IQ/логические этапы и разношёрстные форматы в зависимости от страны и культуры компании.

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

Подался на 168 вакансий: ~67 зависли, ~70 – автодеклайн… в итоге пять офферов

📄 Резюме и личный бренд: pet‑проекты, сертификации, LeetCode

Резюме – до 2 страниц, последние 5 лет и измеримые результаты (формат STAR); актуальные технологии – компактным блоком.

Pet‑проекты позиционируйте как микро‑продукты (проблема → решение → метрика), open‑source даёт видимые артефакты и красивую строчку в резюме.

Сертификации окупаются там, где есть бизнес‑эффект (клауд‑партнёрства, CKA/CKAD для верификации глубины); общие бумажки по языкам редко конвертят.

LeetCode – инструмент по назначению: для корп‑циклов – структурная подготовка (Blind‑75/NeetCode), для продуктовых команд важнее чистый код и кейсовое мышление.

🛠 Практические стратегии поиска работы

Действовать лучше по чек‑листу, а не по вдохновению:

🔸 Ранний отклик (в первые сутки)
🔸 Зарплатные фильтры на площадках вроде Glassdoor/Genie
🔸 Ведение своей статистики воронки
🔸 Локализация коммуникации под страну (лексика, ожидания, формат интервью)
🔸 Использование программ для newcomers там, где они есть
🔸 Тактическая гибкость: при переезде допустим «вход» на пол‑грейда ниже с быстрым ростом внутри

Стратегия – это не список инструментов, а последовательность решений во времени

Коротко: рынок ценит управляемую широту (T‑shaped + AI‑грамотность), прозрачные решения на интервью, видимые артефакты в профиле и дисциплину стратегии — тогда даже длинные воронки и ATS‑фильтры превращаются из лотереи в прогнозируемый процесс