¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
S0ER
Ir al canal en Telegram
Архитектура | Программирование | Профессиональное развитие Соер.Клуб - https://t.me/soer_live По всем вопросам писать на @soerdev
Mostrar más📈 Análisis del canal de Telegram S0ER
El canal S0ER (@softwareengineervlog) en el segmento lingüístico de Ruso es un actor destacado. Actualmente la comunidad reúne a 10 511 suscriptores, ocupando la posición 11 614 en la categoría Tecnologías y Aplicaciones y el puesto 61 742 en la región Rusia.
📊 Métricas de audiencia y dinámica
Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 10 511 suscriptores.
Según los últimos datos del 29 junio, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de -52, y en las últimas 24 horas de 0, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 25.18%. Durante las primeras 24 horas tras publicar, el contenido suele obtener N/A% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 2 647 visualizaciones. En el primer día suele acumular 0 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 56.
- Intereses temáticos: El contenido se centra en temas clave como rbp, архитектура, callme, mov, указатель.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“Архитектура | Программирование | Профессиональное развитие
Соер.Клуб - https://t.me/soer_live
По всем вопросам писать на @soerdev”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 30 junio, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Tecnologías y Aplicaciones.
10 511
Suscriptores
Sin datos24 horas
-137 días
-5230 días
Carga de datos en curso...
Canales Similares
Nube de Etiquetas
Menciones Entrantes y Salientes
---
---
---
---
---
---
Atraer Suscriptores
junio '26
junio '26
+23
en 0 canales
mayo '26
+77
en 0 canales
Get PRO
abril '26
+41
en 0 canales
Get PRO
marzo '26
+127
en 0 canales
Get PRO
febrero '26
+159
en 2 canales
Get PRO
enero '26
+42
en 0 canales
Get PRO
diciembre '25
+37
en 2 canales
Get PRO
noviembre '25
+27
en 0 canales
Get PRO
octubre '25
+31
en 0 canales
Get PRO
septiembre '25
+37
en 0 canales
Get PRO
agosto '25
+53
en 3 canales
Get PRO
julio '25
+51
en 3 canales
Get PRO
junio '25
+48
en 0 canales
Get PRO
mayo '25
+41
en 2 canales
Get PRO
abril '25
+54
en 0 canales
Get PRO
marzo '25
+108
en 1 canales
Get PRO
febrero '25
+110
en 0 canales
Get PRO
enero '25
+56
en 1 canales
Get PRO
diciembre '24
+151
en 5 canales
Get PRO
noviembre '24
+203
en 4 canales
Get PRO
octubre '24
+81
en 0 canales
Get PRO
septiembre '24
+125
en 2 canales
Get PRO
agosto '24
+171
en 2 canales
Get PRO
julio '24
+244
en 5 canales
Get PRO
junio '24
+164
en 5 canales
Get PRO
mayo '24
+245
en 4 canales
Get PRO
abril '24
+198
en 5 canales
Get PRO
marzo '24
+211
en 5 canales
Get PRO
febrero '24
+307
en 2 canales
Get PRO
enero '24
+323
en 4 canales
Get PRO
diciembre '23
+907
en 4 canales
Get PRO
noviembre '23
+190
en 3 canales
Get PRO
octubre '23
+218
en 2 canales
Get PRO
septiembre '23
+173
en 0 canales
Get PRO
agosto '23
+247
en 0 canales
Get PRO
julio '23
+273
en 0 canales
Get PRO
junio '23
+195
en 0 canales
Get PRO
mayo '23
+2 925
en 0 canales
Get PRO
abril '23
+397
en 0 canales
Get PRO
marzo '23
+321
en 0 canales
Get PRO
febrero '23
+221
en 0 canales
Get PRO
enero '23
+798
en 0 canales
Get PRO
diciembre '22
+385
en 0 canales
Get PRO
noviembre '22
+229
en 0 canales
Get PRO
octubre '22
+645
en 0 canales
Get PRO
septiembre '22
+208
en 0 canales
Get PRO
agosto '22
+153
en 0 canales
Get PRO
julio '22
+186
en 0 canales
Get PRO
junio '22
+241
en 0 canales
Get PRO
mayo '22
+402
en 0 canales
Get PRO
abril '22
+1 176
en 0 canales
Get PRO
marzo '22
+2 018
en 0 canales
Get PRO
febrero '22
+25
en 0 canales
Get PRO
enero '22
+41
en 0 canales
Get PRO
diciembre '21
+60
en 0 canales
Get PRO
noviembre '21
+26
en 0 canales
Get PRO
octubre '21
+63
en 0 canales
Get PRO
septiembre '21
+375
en 0 canales
Get PRO
agosto '21
+185
en 0 canales
Get PRO
julio '21
+122
en 0 canales
Get PRO
junio '21
+20
en 0 canales
Get PRO
mayo '21
+35
en 0 canales
Get PRO
abril '21
+61
en 0 canales
Get PRO
marzo '21
+40
en 0 canales
Get PRO
febrero '21
+39
en 0 canales
Get PRO
enero '21
+41
en 0 canales
Get PRO
diciembre '20
+1 613
en 0 canales
| Fecha | Crecimiento de Suscriptores | Menciones | Canales | |
| 30 junio | 0 | |||
| 29 junio | +1 | |||
| 28 junio | 0 | |||
| 27 junio | 0 | |||
| 26 junio | 0 | |||
| 25 junio | +1 | |||
| 24 junio | 0 | |||
| 23 junio | 0 | |||
| 22 junio | +2 | |||
| 21 junio | 0 | |||
| 20 junio | +2 | |||
| 19 junio | +1 | |||
| 18 junio | +2 | |||
| 17 junio | +1 | |||
| 16 junio | +1 | |||
| 15 junio | 0 | |||
| 14 junio | +1 | |||
| 13 junio | +1 | |||
| 12 junio | +1 | |||
| 11 junio | +2 | |||
| 10 junio | +1 | |||
| 09 junio | 0 | |||
| 08 junio | 0 | |||
| 07 junio | 0 | |||
| 06 junio | +1 | |||
| 05 junio | +3 | |||
| 04 junio | +2 | |||
| 03 junio | 0 | |||
| 02 junio | 0 | |||
| 01 junio | 0 |
Publicaciones del Canal
await this.progressRepository.create({ userId, lessonId, status: "started", startedAt: new Date() })
this.analyticsService.track("lesson_started", { userId, lessonId })
.catch(err => this.logger.error("Analytics failed", err))
}
`
Стал ли код лучше? И да, и нет. Первый вариант по-прежнему остается самым читаемым, понятным и простым. Но на перспективу иметь разделение обязанностей и четкие границы между слоями - это очевидный плюс.
Получается три разных варианта, все рабочие. Но какой из них подойдет в конкретной ситуации - это решение, которое должен принять разработчик. Реальное программирование - это всегда компромисс между надёжностью, универсальностью и простотой.
Важно помнить, что как программисты, мы всегда можем объяснить, какие проблемы есть в коде, какие опасности они создают. Но насколько эти "проблемы" реальны - сказать сложно. И никто не знает, какой выбор нужно сделать. Знаю только, что через год-два открою этот код и не вспомню, почему выбрал именно так. И, скорее всего, нужно будет объяснять проблемы и переписывать... Опять.| 2 | Три варианта. Один выбор.
Допустим, у нас есть задача реализовать user story:
Как пользователь платформы, я хочу начать урок, чтобы продолжить обучение и потратить накопленные токены.
Наивная реализация на TypeScript + NestJS могла бы выглядеть как-то так:
async startLesson(userId: string, lessonId: string) {
const user = await this.userRepository.findById(userId)
const lesson = await this.lessonRepository.findById(lessonId)
const subscription = await this.subscriptionRepository.findActiveByUser(userId)
if (!subscription || subscription.expiresAt < new Date()) {
throw new Error("No active subscription")
}
if (user.tokens < lesson.tokensCost) {
throw new Error("Not enough tokens")
}
await this.userRepository.update(userId, { tokens: user.tokens - lesson.tokensCost })
await this.progressRepository.create({ userId, lessonId, status: "started", startedAt: new Date() })
await this.analyticsService.track("lesson_started", { userId, lessonId })
}
Код рабочий и простой. Но насколько он хорош? Остановитесь на секунду и назовите 2-3 потенциальные проблемы этого кода. Я нашел сразу пять:
- Проверка подписки здесь, хотя должна быть в отдельном слое доступа.
- Списание токенов не атомарное - между проверкой и обновлением токены может списать другой запрос.
- Нет транзакции - если сервер упал между update и create, токены списались, а прогресс не создался.
- Аналитика блокирует основной поток.
- Нет уникального индекса на прогресс.
Учитывая эти моменты, можно сделать более надёжную реализацию:
async startLesson(userId: string, lessonId: string) {
return this.unitOfWork.execute(async (uow) => {
const user = await uow.users.findById(userId)
const lesson = await uow.lessons.findById(lessonId)
if (!user || !lesson) {
throw new Error("User or lesson not found")
}
const accessResult = await this.accessService.checkAccess(user, lesson)
if (!accessResult.allowed) {
throw new Error(accessResult.reason)
}
const updateResult = await uow.users.updateOne(
{ _id: userId, tokens: { $gte: lesson.tokensCost } },
{ $inc: { tokens: -lesson.tokensCost } }
)
if (updateResult.modifiedCount === 0) {
throw new Error("Not enough tokens")
}
return await uow.progress.create({
userId,
lessonId,
status: "started",
startedAt: new Date()
})
})
}
Код стал сложнее и надёжнее: транзакция, атомарность, разделение ответственности.
Но суть в том, что для небольшого проекта с десятком активных пользователей эта сложность чаще всего не нужна. Вероятность race condition стремится к нулю. Если транзакция зависнет - техподдержка поправит токены за пять минут, а вы потратили кучу времени на Unit of Work.
Поэтому из перечисленных проблем, наверное, единственное, что достаточно универсально - это разделение обязанностей. Всё остальное - преждевременная оптимизация.
Итоговый вариант кода с разделением обязанностей выглядел бы так:
`typescript
async startLesson(userId: string, lessonId: string) {
const user = await this.userRepository.findById(userId)
const lesson = await this.lessonRepository.findById(lessonId)
if (!user || !lesson) {
throw new Error("User or lesson not found")
}
const accessResult = await this.accessService.checkAccess(user, lesson)
if (!accessResult.allowed) {
throw new Error(accessResult.reason)
}
if (user.tokens < lesson.tokensCost) {
throw new Error("Not enough tokens")
}
await this.userRepository.update(userId, { tokens: user.tokens - lesson.tokensCost }) | 2 681 |
| 3 | ИИ база
Ну что, дожили до того светлого будущего, когда все больше работодателей интересуются, умеет ли соискатель работать с ИИ. Сразу успокою, пока — это далеко ни каждый первый и даже ни каждый второй, поэтому есть время подготовиться и понять, что вообще могут спросить и как отвечать.
Почему стали проверять знания ИИ?
Тут все просто — строили, строили и наконец построили процессы, которые включают работу агентов как дополнительный инструмент для решения рабочих задач. Раньше джун мог выехать на одном языке и фреймворке, а теперь даже на старте ждут, что ты не просто пишешь код, а понимаешь, как подключить к этому делу LLM.
Лично мне положение дел скорее радует, чем огорчает. Для инженеров (соеров) — это дополнительная возможность карьерного роста, да, снова надо учиться новому и уходить в сторону M-shape, но так было всегда — учись лавировать или уходи из профессии.
Для джунов ситуация стала сложнее — кроме обязательного System Design, появляется "покажи, как ты умеешь с агентами работать". И если по системному дизайну еще можно измерить нагрузку городами и как-то проскочить со словами "ну что вы от меня хотите, я ж только учусь", то по ИИ нужно показать хотя бы базовые практические навыки, и здесь все зависит от желания развиваться, так что шансы есть, особенно если подкачать базу.
Сейчас в приоритете агенты (с постепенным переходом к командам агентов и оркестрации), нужно уметь:
Теория:
- промпт-инжениринг — нужно рассказать про принципы, подходы, техники рассуждений и т.д.
- контекст-инжениринг — нужно объяснить, что такое контекстные окна, «загнивание» контекста, управление вниманием, RAG и т.д.
- обосновать выбор модели под задачу (например, тебя просят разработать небольшую фичу за разумное время и потребление токенов — тут главное не гонять дорогую модельку на задачах, а показать, что ты понимаешь, где проходят «границы возможностей»);
- архитектура агентов (включая команды агентов)
Практика
Например, задача на 20–30 минут, где нужно показать основные моменты разработки с агентами. На собеседовании дается живой кейс с уже настроенным агентом (либо можно взять свой привычный инструмент) и нужно:
- построить структуру проекта c учетом spec-driven development, ADR и т.д.;
- подобрать набор инструментов (в том числе MCP) и скиллов;
- разбить задачу на этапы (планирование, проектирование, реализация, контроль);
- решить проблемы галлюцинаций и в завершение сделать качественное ревью результата (т.е. показать, что именно «вы» будете делать и почему human in the loop так важен).
И для общей статистики предлагаю поставить 💡 если в твоей компании уже просят использовать ИИ или на собесах задают вопросы по ИИ. | 4 690 |
| 4 | Курс по микросервисам стартует 20.04.2026.
Продолжаю создание курсов по теме архитектуры. Ранее в сообществе были созданы коллекции материалов по сервисам и монолитам, и вот настала очередь микросервисов.
О курсе:
❗️ приоритет на проектирование, документирование и анализ (будем разбираться, как проводить границы, формировать требования, распределять обязанности и т.д.)
❗️ изучать можно индивидуально или общаясь в группе
❗️ еженедельные семинары с разбором проблем и консультациями (только для Подписки №3)
❗️ часть созвонов предполагает интерактивный формат круглого стола (например, общая Event Storming сессия)
Важно! Это не формат обучения. Нет никаких обязательных лабораторных работ, программы обучения и прочих вещей. Вместо этого — набор материалов, доступных по подписке, и обмен реальным опытом.
Можно просто смотреть лекции (для этого нужна Подписка №1), можно дополнительно смотреть мастер-классы (подписка №2), а для обратной связи приходить на семинары (подписка №3).
Наибольшая польза достигается за счет участия в семинарах: у нас собрана команда из 10 человек — это специалисты разного уровня, от архитекторов до новичков.
Мы обсуждаем не только информацию из курсов, но и практические вопросы, которые есть у ребят. Поэтому встречи — это отличный способ обменяться опытом, задать вопросы, получить информацию, которая выходит за пределы курса.
Количество участников на семинарах ограничено, сейчас есть 4 места, которые доступны, если вы приобрели подписку №3.
Важный момент! Подписка предусматривает доступ ко всем имеющимся материалам, встречам, созвонам и т.д., в общем, всему тому, что входит в подписку. Поэтому не надо думать, что подписка идет на курс: курс — лишь часть того, что есть в подписке.
Мы реализуем идею поэтапного развития (движения к цели короткими шагами), постоянно шлифуем свои навыки, собираем актуальную информацию, которую можно применять на практике, обмениваемся опытом и т.д., а подписка определяет уровень доступа.
Например, после курса по микросервисам планирую курс по архитектуре агентных систем, дополнительные созвоны, публикацию материалов в ИИ-лаборатории и т.д.
В общем, приобретая подписку, вы получаете не только курс, а участие в нашем сообществе и его активностях. | 0 |
| 5 | Последнее видео по промпт-инженерии далось с особой болью, раньше я бездумно использовал советы из интернета, которые определяли, что нормальный промпт - это когда ты задаешь роль, контекст, задачу, пример (строго в таком порядке) и добавляешь конкретные измеряемые критрии качества.
Я использовал и мне казалось, что "Вау! Это работает". А потом я решил сделать ролик в котором показать "плохие" и "хорошие" промпты.
Оказалось, что "плохие" промпты работают ничуть не хуже чем "хорошие", т.е. все это время я делал промпты не понимая, что делаю "шляпу". В итоге я собрал те моменты, которые реально дают изменения, перестал писать портянки текста, больше фокуса на примеры и техники размышления и вот здесь уже удалось показать разницу.
А знаменитое "представь что ты программист" оказалась не такой полезной штукой, как я думал. | 0 |
| 6 | Сделал видео по созданию промптов, идея была в том, чтобы рассмотреть разные варианты текстов и выделить общие правила, которые опубликовать на soerdev.space в картах знаний.
В итоге получилось очень плотное информативное видео, смотреть можно тут:
YouTube | Vk | RuTube | 0 |
