Правило 1. Невозможно предсказать, где программа будет тратить время. Узкие места возникают в неожиданных местах, поэтому не пытайтесь угадывать и использовать ускорение, пока не докажете, что именно там находится узкое место.
Правило 2. Измеряйте. Не оптимизируйте скорость, пока не измерите, и даже тогда не делайте этого, если только одна часть кода не превосходит остальную.
Правило 3. Сложные алгоритмы медленны, когда n мало, а n обычно мало. Сложные алгоритмы имеют большие константы. Пока вы не узнаете, что n часто будет большим, не усложняйте алгоритмы. (Даже если n станет большим, сначала используйте Правило 2.)
Правило 4. Сложные алгоритмы содержат больше ошибок, чем простые, и их гораздо сложнее реализовать. Используйте простые алгоритмы, а также простые структуры данных.
Правило 5. Данные доминируют. Если вы выбрали правильные структуры данных и хорошо всё организовали, алгоритмы почти всегда будут очевидны. В программировании центральное место занимают структуры данных, а не алгоритмы.
Уточнения:
Правила 1 и 2 Пайка перефразируют знаменитую максиму Тони Хоара: «Преждевременная оптимизация — корень всех зол».
Кен Томпсон перефразировал правила 3 и 4 Пайка как «В случае сомнений используйте грубую силу».
Правила 3 и 4 являются примерами философии проектирования KISS (Keep It Simple, Stupid).
Правило 5 ранее было сформулировано Фредом Бруксом в книге «Мифический человеко‑месяц». Правило 5 часто сокращают до «пишите глупый код, использующий умные объекты».
Все эти споры о Новой Технологии — «Вайб‑Кодинг»... да было это все уже...
Только в 90-х называлась «парное программирование» XP (Extreme Programming)... только подручными средствами.
Найдете книгу — Кент Бек Экстремальное программирование (eXtreme Programming, XP)... Ну и вопрос прост — где вы с ним встречались? Ответ — нигде...умерло и чего? аааа... так как предназначалось для решения узкого круга задач — посмотрите и пределы и ограничения... а посмотрев как развивалось — увидите.. такой подход узко применим, он будет, но в мелкий соответствующих задачах, и большую систему на нем не построишь.
Сейчас то же самое, только вместо одного из программеров, рядом — тупые агенты с их «Чего господин молодой программист — желает» )))
Да и вообще.... то что наваяли по Agile — не сработает, и проблема снова та же — отсутствие знания базовых технологий! Agile то.. это облегченная технология для спиральной разработки.
И Agile — та же история. Облегчённая версия спиральной разработки Боэма. 1988 год. Взяли — упростили — потеряли главное. Спиральная разработка учитывала риски, архитектуру, масштаб. Agile оставил итерации и выбросил всё сложное )))
Большую систему на «спиральной» по Agile не построишь — нужен водопад с правильно выстроенной архитектурой на входе. А на Agile большую систему не построишь вообще — там каждые две недели спринт и никто не думает о том что будет через год )))
Полная «спиральная разработка» — включает баланс между Каскадная модель (Waterfall model) + Итеративная модель (Iterative model). Agile и Scrum — игнорирует структурную часть.
И молодые разработчики не знают ни Боэма ни Руча ни даже нормального RUP. Знают Scrum и думают что это всё что есть )))
Олдфаги помнят CASE(Computer‑Aided Software Engineering)‑системы из 90-х — это была первая великая попытка «запрограммировать программирование». Тогда нам тоже обещали мир без кода. Не взлетело, потому что инструменты были кривые, а сложность систем росла быстрее, чем наши навыки моделирования. Сегодняшний ИИ — это CASE‑система, которая наконец‑то заработала.
Почему CASE — это «дедушка» ИИ (и почему тогда не взлетело):
Та же фигня, вид в профиль: Тогда тоже кричали: «Кодеры больше не нужны! Будем только рисовать квадратики!». Но выяснилось, что чтобы нарисовать «квадратики» правильно, нужно обладать еще более жесткой логикой, чем для написания кода. ИИ сегодня — это CASE‑система на стероидах, которая наконец‑то научилась понимать не только стрелочки, но и живую речь.
Проблема «Грязного входа»: В 90-х CASE‑системы разбивались о то, что люди не могли внятно нарисовать, чего они хотят. «Мусор на входе — мусор на выходе». Сейчас с ИИ ровно та же история. Если у тебя в голове каша, то никакая нейронка (как и Rational Rose в своё время) тебе рабочий продукт не выдаст.
Уровень абстракции: CASE пытались поднять нас над кодом. ИИ делает то же самое. Но тогда «процессорной мощности» мозгов у массы айтишников не хватило, чтобы перейти от «ковыряния в гайках» к «проектированию смыслов» (была даже UML (Unified Modeling Language)). Сейчас — дубль два. Только теперь отсидеться в окопах синтаксиса не получится.
P. S. Вот и смотрю... с каким рвением изобретают «велосипед»... может книги почитать нужно? про указанные в посте технологии?
P. S.S. И вот реально, я бы порекомендовал ознакомиться — UML (Unified Modeling Language).
Это четвертая часть серии (первая — в чем идея, вторая — агент с нуля, третья — что внутри).
В таких цитатах я буду показывать конкретные запросы, которые он уже хорошо решает.
———————
Поехали ⤵️⤵️⤵️
💲 Ведет учет всех моих финансов
Подключён к моей финансовой табличке, которую я веду в Notion. Умеет добавлять по категориям и анализировать отчеты даже за целый год (а записей там огромное количество).
«Посчитай доходы за последний год — покажи где и сколько я зарабатывал» «Сколько я должен провести в налоговую за этот месяц?» «Кто и когда мне заплатил и кто ещё должен по рассрочке курса?»
🌈 Подключен к моей гугл почте
Читает Gmail и пишет мне сводку каждое утро — есть ли там что-то интересное. Отвечать на входящие пока ему не разрешаю, может только драфты писать
«Глянь что мне там интересного пришло за эту неделю» «Напиши жалобу в Lazada по поводу последнего ордера, он не пришел. Ордер в почте лежит, возьми номер оттуда» «Напиши драфт в ответ на сообщение Username, я гляну попозже»
🍀 Календарь
Видит расписание, создаёт и удаляет события.
«Поставь созвон на вторник 15:00 и напомни за час» «Поставь ученикам второго потока рекурентную встречу раз в две недели, их почты знаешь где найти» «Глянь че у меня по слотам на понедельник, поставь созвон куда‑то на обед + дай sharable ссылку сюда»
🖥 Таск-трекер
Подключён к моему TickTick — откуда читает и пишет задачи. Каждый день пишет сводку задач, что нужно сделать с высоким приоритетом.
«Что у меня просрочено? И добавь задачу: обновить лендинг до пятницы» «Проведи анализ моего сайта и кинь ToDoшкой себе в память + мне в TickTick» «Добавь всем задачам в разделе Мое обучение Definition of Done. Если не уверен в том, какой должен быть DoD — пингуй»
🔥 Apple Watch — факин маджик
Два дня потратил на то, чтобы на ходу с руки записывать идеи сразу в Clawy
⌚️ «Запиши идею поста» (наговариваю прямо в часы) ⌚️ «Заправился, запиши 400 бат себе»
В общем все те кейсы что выше, но через часы.
🎶 Spotify + концерты
Знает все группы, которые я слушаю. Раз в две недели мониторит концерты в интернет. Ставит напоминалки и скидывает ссылки на покупку билетов.
«Че там какие концерты моих групп в Бангкоке в ближайшие 2 месяца?»
🌴 Знает где я живу, вплоть до точных координат
Поэтому рекомендации конкретные — не «в мире», а «рядом со мной».
«Найди хорошего стоматолога рядом» «Хочу поехать в кафе, глянь что‑то прикольное в радиусе 5 км»
Ну и еще
Есть доступы на чтение к моим гугл таблицам и гугл драйву. Знает много инфы про мой психотип и различные тестирования.
———————
🦄 Комбинированные кейсы
Нужно проставить мне и всем ученикам в календарь созвоны на третий поток.
Глянь сайт, там точное название, описание и время уроков Поставь в календарь их все А почты учеников глянь в табличке 3 потока
→ На сайте забирает инфу про уроки, почты берет из таблички. Затем ставит всем встречи в календарь.
Подведи итоги за неделю
→ Собирает доходы из Notion, выполненные задачи из TickTick, события из календаря, важные письма из Gmail. Выдаёт: заработал X, потратил Y, закрыл 8 задач из 12, пропустил 2 дедлайна. Рекомендация на следующую неделю.
[с Apple Watch] «Что на сегодня у нас?»
→ «Есть один созвон в 14:00. В TickTick: обновить лендинг (дедлайн сегодня). Вчера пришло письмо на почту — ответ от Anthropic по поводу твоей проблемы. Черновик ответа готов, глянешь после завтрака?».
«Нашел такую приколюху в интернете. Изучи ее и напиши план на улучшение самого себя, потом можешь внести эти изменения».
→ Изучит идею и улучшит себя и свой функционал.
———————
👁 Что еще хочу развить
Голос — чтобы отвечал голосовыми, иногда удобнее войсом, чем текстом.
Звонки — чтобы звонил мне. Например, в 11 вечера, чтобы я сделал саммари дня. Или если я не делаю задачу, чтобы звонил мне иговорил мне «втф чел».
Доступ к Telegram — сейчас он не видит мои чаты, только если пересылать сообщения ему. Хочу подключить Telethon — чтобы мог сам читать переписки, мониторить каналы, готовить черновики ответов.
Тамагочи получается 🎮
Это мой агент сделал себе такое Identity -- он чертный кот. Сказал что он фамильяр с именем Clawy
Однажды заказчик пришёл с задачей, которая звучала как пара часов работы «Просто добавь кнопку — нажал, выгрузил данные, всё». Я открыла код и поняла, что эта кнопка стоит не пару дней, а недель — и это если повезёт..
Сложнее всего оказалось не сделать, а объяснить так, чтобы услышали.
С технической стороны всё понятно: сервис писался под дедлайн, архитектура не предусматривала роста, и каждое новое изменение тянет за собой минимум три соседних. Но заказчик смотрит на задачу и видит один экран. Кнопки ещё нет, но она же просто кнопка. Что тут может быть сложного?
Архитектурное объяснение я попробовала и оно не зашло. Слои, связи, зависимости: всё правильно, всё мимо.
Что работает вместо «красивого кода»
Я перестала объяснять как устроено и начала объяснять что произойдёт. Не «тут монолитная структура без инверсии зависимостей», а конкретно: — эта кнопка затрагивает три модуля, которые никто не трогал два года — если что‑то сломается, то мы не узнаем сразу, потому что тестов нет — следующая фича после этой будет стоить столько же в лучшем случае.
Заказчик услышал третий пункт. Именно его.
Нетехнический человек воспринимает разработку примерно так: «нажал кнопку → произошла магия → получил результат». Это не незнание — просто другая роль. Заказчик и не должен думать об архитектуре, это моя работа. Значит, говорить на его языке — тоже моя.
Как я считаю стоимость следующей фичи
Со временем сложился свой фреймворк. Не из учебника, а из разговоров, где меня не понимали, пока я не поменяла подход.
Три вещи, которые я оцениваю перед тем, как называть сроки: 1. Базовая сложность: сколько займёт в идеальных условиях, на нормальной архитектуре. 2. Архитектурный коэффициент — во сколько раз реальность дороже идеала. Код без тестов, с жёсткими связями между модулями — это 2-4× к оценке. Не абстракция: вот здесь нельзя менять, не затронув вот это. Рисую буквально на бумаге. 3. Риск‑налог — что может пойти не так. Что сломается, насколько быстро заметят, сколько займёт починка. Не чтобы напугать, а чтобы показать, что «быстро» и «надёжно» здесь в противоречии.
Когда эти три числа стоят рядом — разговор меняется. Заказчик видит, что не «разработчик тормозит», а «вот цена, вот риск, вот выбор».
Именно тогда и появляется разговор про рефакторинг. Не потому что «код некрасивый», а потому что каждая следующая фича будет дороже предыдущей, если ничего не менять.
Что осталось в голове
Техдолг — это не технический вопрос. Это финансовый.
Пока объясняешь его как технический — тебя не услышат. Как только переводишь в деньги, сроки и риски — начинают слышать.
Самое сложное не методология. Самое сложное — поймать момент, когда ты всё ещё говоришь на своём языке, а не на их. У меня ушло время, чтобы это почувствовать.
А вы как объясняете техдолг тем, кому важен результат, а не архитектура? Есть формулировка, которая сработала лучше всего?
Представлен проект DigitalDefynd — большая база IT‑курсов от лучших университетов мира. Материал на ресурсе обновлён на 2026 год. Там актуализировали курсы и оставили только те навыки, которые пригодятся при устройстве на работу и росте по карьерной лестнице. Есть сотни воркшопов, в том числе от Google и IBM. Большая часть курсов с лицензированными сертификатами и дипломами, которые можно положить в портфолио.
Хотите выяснить, где учиться IT? В экосистеме Хабра есть маркетплейс курсов на Хабр Карьере, на котором собраны сотни онлайн-обучений в самых разных специализациях: программировании, аналитике, дизайне, менеджменте и других. Чтобы пользователи могли проверить качество курсов, там показаны отзывы от тех, кто уже прошел обучение — изучайте и выбирайте лучшее для себя.
Представлен открытый проект TUI Studio (Visual Terminal UI Designer), среды для визуального проектирования интерфейсов пользователя, работающих в текстовом терминале. Среда позволяет в интерактивном режиме наглядно формировать интерфейс, перетаскивая готовые блоки мышью, редактируя свойства в визуальном режиме и предпросматривая результат на лету. Сформированный макет интерфейса может быть экспортирован для использования во фреймворках Ink, BubbleTea, Blessed, Textual, OpenTUI и Tview.
Решение написано на TypeScript с использованием React, Vite, Zustand, Tailwind CSS и Lucide React. Код распространяется под лицензией MIT. Из особенностей разработки отмечается, что почти весь код TUI Studio написан ИИ‑ассистентом Claude.
В TUI Studio предоставляется более 20 готовых компонентов для формирования интерфейса (кнопки, меню, таблицы, списки, индикатор прогресса, диалоги, всплывающие подсказки и тому подобное) и поддерживается 8 тем оформления, а также светлый и тёмный режим, градиентные заливки, ASCII‑цвета и акцентные цвета. Имеется возможность отката изменений. Доступен интерфейс для создания своих компонентов. Проекты сохраняются в формате JSON.
ИИ — помощник, или враг разработчика? Мысли на тему. Часть 2
Сейчас время нейросетей. Не надо излишне обольщаться на тему их возможностей — они владеют (по крайней мере пока), только той информацией, которая использовалась при обучении, плюс, имеют возможность «подглядывать» в поиск и различные внешние источники с помощью MCP-серверов. Всё.
Но даже это снова очень серьёзный рывок вперёд. Вместо необходимости искать и анализировать информацию из нескольких источников мы сразу получаем готовое решение. Да, ещё с погрешностями и необходимостью ручных правок и проверок, но это уже качественно другой уровень разработки.
Вместо ручного написания алгоритмов или их комбинирования из готовых частей на первое место выходит навык промптинга — умения сформулировать свой запрос в виде, достаточно полном и понятном для нейросети.
Меняется ли что-то для разработчиков? Безусловно. Снова. Нам снова надо менять свой подход к разработке. Так же, как мы меняли его 30 лет назад, 20, 10... И будем менять опять ещё лет через 10. Это естественный процесс.
Надо ли забывать синтаксис и особенности низкоуровневой разработки? Нет. Как минимум, ещё несколько лет необходимо будет выверять за LLM код так же, как мы выверяем его за новичками. Но, давайте будем честными, машинные коды и Ассемблер многие уже забыли, а то и не знали. А создавать программы им это не мешает. Так же как сейчас есть специалисты, активно использующие машинные коды и Ассемблер в работе.
Рынок не схлопнется. К нему добавится ещё один слой. Кто-то из разработчиков будет и дальше по старому писать код в областях, новых для ИИ, где у него нет наработанной «базы ответов». А кто-то переключится на написание промптов, в разы повысив скорость решения прикладных задач.
ИИ — помощник или враг разработчика? Мысли на тему. Часть 1
Привет, это снова Саша Кузнецов, ведущий инженер-программист в Контуре. 🙌
Я из тех «ископаемых», которые начинали программировать ещё во времена, когда в качестве IDE выступал обычный текстовый редактор, а для хранения информации о синтаксисе команд использовались собственные записи в тетради. Я в то время учился в школе и на уроках учитель давала нам информацию о синтаксисе команд с распечаток. Если в тетради была ошибка — ты делал ошибку в коде и не мог понять, что идёт не так. Роль интернета играла городская библиотека (в местной книг про IT практически не было), «пинг» до которой был несколько часов только на дорогу, а ещё — скорость работы «поисковой системы» по бумажным книгам оставляла желать лучшего.
Потом я поступил в университет и «произошла магия» — там были IDE с подсветкой синтаксиса команд, подсказками, появляющимися по нажатию F1, и более-менее вменяемыми сообщениями об ошибках.
Это было круто! Просто зная название команды можно было получить описание её синтаксиса, а не хранить в голове информацию обо всех возможных комбинациях! Реальный прирост производительности сейчас по памяти сложно замерить, но скорость непосредственно набора команд выросла в разы. С решением задач в целом ситуация улучшилась не сильно — основным источником информации оставались бумажные книги. Разве что «пинг» существенно сократился — читальный зал находился в том же корпусе, в котором шли занятия. По сути, в момент этого скачка необходимость знания точного синтаксиса команд заменилась на необходимость знать только название команды.
Потом магия произошла снова — на кафедре появился интернет и что-то похожее на поиск. Это был ещё далеко не современный интернет с мощными поисковыми системами, но и совсем древние его версии я не застал. Но, главное, уже можно было найти информацию за рамками того, что было включено в поиск разработчиками IDE, или лежало в читальном зале. Речь шла уже не о синтаксисе команд, а о способах решения задач. Но не всегда. Это было время, когда в интернете ещё надо было суметь найти готовый код для редких видов сортировки массива, а за написание алгоритма БПФ (Быстрого Преобразования Фурье) заказчики на фрилансерских форумах были готовы выложить $500. И, тем не менее, это снова был качественный скачок — можно было быстро найти информацию по конкретной проблеме, не перекапывая кучу книг, в которых, возможно, могло быть «что-то близкое по теме». Скорость решения задач снова выросла, и снова значительно. Всё больше и больше задач стало переходить в категорию шаблонных. На этом этапе на первое место начал выходить навык «гугления». Основы синтаксиса остались необходимой базой, но умение правильно забить вопрос в поисковую строку стал определять очень и очень многое.
Новый скачок произошёл с развитием разработческих форумов по типу Stack Overflow. С момента их основания огромное число пользователей задавало вопросы и получало на них ответы. Можно было не просто что-то найти, но дать описание проблемы и получить решение, часто с примерами рабочего кода. А ещё к этому моменту существенно выросли как возможности поисковых систем, так и объём проиндексированной информации в них. Плюс, достаточно много книг перевели в цифровой формат. В результате стало возможным указывать не конкретное название нужного алгоритма или ключевые слова, а давать описание проблемы и получать подборку страниц с нужными ответами. В том числе на Stack Overflow и другие похожие форумы.
Теперь можно было нормально искать решение более-менее широко известных проблем по их примерному описанию и сразу получать примеры рабочего кода. Существенный рывок, значительно сокративший время на простые, рутинные задачи, и, одновременно, подаривший куче студентов возможность гуглить практически готовые лабораторные работы.
Фактически, именно в этот момент программирование стало общедоступным. А на первое место вышел навык комбинирования — умения собрать решение из похожих кусков кода, найденных в интернете.
26 марта эксперты AXENIX проведут вебинар, посвященный современной фронтенд архитектуре и гибким подходам к разработке.
🔘Разберем реализацию подхода Server Driven UI и рассмотрим, как эффективно интегрировать в него ИИ-агентов. 🔘Поговорим о долгосрочном здоровье проекта и преимуществах изоляции бизнес-логики от фреймворков на примере Feature-Sliced Design (FSD) и реальном опыте перехода на Effector. 🔘Проведем анализ гибридных решений: как из единой кодовой базы собирать и облачный сервис, и десктопное Electron-приложение с офлайн-режимом, преодолевая ограничения браузерной среды.
Участие в вебинаре бесплатное, необходимо только зарегистрироваться по этой сcылке и подключиться к нам 26 марта в 18:00.
Привет, Хабр. Делимся подборкой бесплатных уроков, которые пройдут в Отус в рамках набора на курсы. Опытные практики проведут занятия онлайн — на них вы сможете узнать больше о формате обучения и задать вопросы. Выбирайте тему и присоединяйтесь, чтобы пробустить свою карьеру.
СЕО Stripe Патрик Коллисон в подкасте TBPN рассказал, что программное обеспечение вообще‑то не должно производиться «впрок» и продаваться бесконечно. По его мнению, его стоит создавать по запросу — прямо в момент использования.
«Софт должен быть как пицца: его нужно готовить здесь и сейчас, в момент заказа», — объяснил Коллисон. До сих пор, по его словам, экономика ПО строилась по модели фиксированных затрат на разработку с последующей почти бесконечной монетизацией.
Но когда появляются издержки на работу ИИ-моделей и кастомную генерацию под конкретный запрос, всё меняется. Коллисон назвал это «не-валрасовским» режимом софта — то есть рынком, который уже не живёт по старым экономическим правилам. Эта аналогия отражает общий вопрос в индустрии: заменит ли ИИ традиционное ПО или будет всего лишь его дополнять.
17 марта вебинар про сокращение техдолга и уязвимостей в AI-разработке
Искусственный интеллект — это не только про скорость разработки и генерации кода, это еще про баги, уязвимости и технический долг. На вебинаре на примере LLM и VS Code будем разбираться, как встроить большую языковую модель в разработку так, чтобы результат был предсказуемый и безопасный. Настроим IDE под ваш стиль, включим защитные ограничения от небезопасных действий и мониторинг качества и безопасности кода с помощью SonarQube.
Если тезисно, то вебинар ответит на три вопроса:
как быстро запустить и контролировать генерацию кода с LLM в VS Code в enterprise-подходе;
как при работе с LLM выстроить правила, ограничения и стандарты: стиль, безопасность, предсказуемость результата;
как настроить ранний контроль качества и безопасности через SonarQube и использовать MCP-серверы для более качественного кода.
Ждем всех, кто внедряет LLM в ежедневную разработку, отвечает за стандарты и качество кода, выстраивает безопасные практики разработки, оценивает риски использования LLM или отвечает за управляемость и предсказуемость разработки.
📅 Когда? Вторник, 17 марта, в 11:00 мск.
📍Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы экспертам в прямом эфире.
Кстати, это третий вебинар цикла «Сценарии применения AI в корпоративной среде», который начался в феврале. Записи первого и второго вебинара есть на сайте.
Разговоры вокруг отечественного связного 💬 Макс не унимаются с момента его официального выхода. Блогеры по всему миру "изучают" безопасность приложения, выискивая, куда он "ходит" и какую "секретную" информацию передает. В основном, все инфоповоды крутятся вокруг изучения манифеста приложения и его разрешений в системе, не углубляясь в изучение сетевых пакетов, исходники и декомпилляцию. А я как раз тот ленивый инфобезник, который еще ни разу не высказался относительно данного вопроса, поэтому исправляюсь.
В прошлую пятницу на весь 🇷🇺 российский интернет прогремела новость: все фото из ваших чатов в Макс может увидеть любой человек по ссылке.
Когда в личный чат или в папку «Избранное» в мессенджере загружается изображение, для него генерируется статичная гиперссылка. Ее можно найти в коде страницы в веб-версии Max. Эта ссылка открывается с других браузеров и устройств без авторизации в мессенджере - обнаружили пользователи. Более того, фото по ссылке останется в открытом доступе, даже если его удалить из переписки в Max.
На лицо классический IDOR. Но если мы проанализируем ссылки на фотографии, которые генерирует Макс, мы обнаружим, что изображения по ним действительно доступны без авторизации. Часть адреса у разных изображений совпадает, однако они содержат различающиеся подстроки длиной не менее 21 символа (минимум 16^21 комбинаций), а значит получить доступ к таким изображениям простым перебором адресов невозможно. Более того, EDR и WAF вас уже на 1000 запросе за несколько секунд обнаружат и отправят отдыхать минут на 5. Ну а про хранение файлов "закон Яровой" никто не отменял.
А знаете, где еще применяется такая технология? В недавно (октябрь 2024 года) заблокированном мессенджере Discord. Все медиа файлы из приложения можно открыть в исходном качестве по прямой ссылке без регистрации и смс (именно поэтому его многие использовали как файлообменник, а платформа ограничивала размер передаваемого файла 8 мегабайтами). И, о новость, если потом данный файл удалить, он все равно остается доступным по прямой ссылке (см. прилагаемое видео).
Возвращаясь к Максу, не могу не обратить внимание, что его разработчиком является крупнейший IT-гигант Mail.ru. Я лично принимал участие в тестировании его на безопасность в период 2020-2021 годах и могу с уверенностью сказать, что там более чем секьюрно. Кроме того, опыт в обеспечении безопасности ВК, ОК и других массовых продуктов у них уже в генах.
Более того, у Макса есть Bug Bounty программа от Bi.Zone и за некоторые уязвимости там выплачивают до 10 миллионов рублей:
Получение доступа к приватной переписке определенных пользователей - 10 000 000 ₽ Получение доступа к местоположению определенных пользователей в реальном времени - 4 000 000 ₽ Получение доступа к телефонной книге определенных пользователей - 2 000 000 ₽
За год существования программы, было реально найдено 13 багов, за которые суммарно выплатили 873 тысячи. При указанной выборке я могу сделать вывод, что Макс достаточно безопасен, раз никто пока не смог сорвать джек-пот.
Поэтому, не верьте всему тому, что пишут в интернете: делите все минимум на 10. Ну и конечно, что попадает в интернет - остается в интернете, поэтому не забывайте про цифровую гигиену.
Команда разработчиков языка программирования Python визуализировала изменение кодовой базы интерпретатора CPython в привязке к основным событиям, произошедшим за 36 лет существования проекта. За последние 10 лет объём кода на языках Python и Си в CPython практически удвоился. Для подсчёта числа строк кода использовалась утилита cloc.
Разработка: Оркестровка агентов по ролевым кластерам (MSF)
Современная разработка всё чаще превращается в ансамбль агентов. ИИ‑системы становятся не просто инструментами, а полноценными участниками команд. Но как их организовать, чтобы они не превратились в хаотичный «зоопарк»?
Microsoft Solutions Framework (MSF) когда‑то предложил модель ролевых кластеров для проектных команд. Идея проста: каждая роль отвечает за свою часть жизненного цикла, а вместе они образуют сбалансированную спираль. Если перенести это на мир ИИ‑агентов, мы получаем оркестровку по ролевым кластерам.
🧩 Смешанная модель
Люди: держат контекст, принимают стратегические решения, задают намерения и проверяют ценность.
Агенты: берут на себя рутинные задачи, прозванивают целостность, генерируют код и тесты, моделируют сценарии.
Оркестровка по MSF: роли распределяются так, чтобы каждый виток спирали был сбалансирован — часть работы делает человек, часть агент.
🎭 Пример
Архитектор‑человек задаёт CASE‑скелет.
Vibe‑агент генерирует код по его намерению.
Тестировщик‑агент прогоняет сценарии.
Координатор‑человек принимает решение: «идём дальше» или «возвращаемся».
Бизнес‑агент симулирует нагрузку, а живой менеджер проверяет, совпадает ли это с реальными целями.
🔧 Пример: смешанная команда разработки по MSF
Ситуация: корпорация запускает новый сервис аналитики.
Роли и участники
Архитектор‑человек: задаёт CASE‑скелет, фиксирует блоки и связи.
Vibe‑агент: генерирует код по намерению архитектора.
Тестировщик‑агент: прогоняет юнит‑тесты и нагрузочные сценарии.
Координатор‑человек: принимает решение о переходе к следующему витку спирали.
Архитектор формулирует задачу: «Нужен модуль аналитики с API для отчётов».
Vibe‑агент генерирует код, интегрируя новый модуль в систему.
Тестировщик‑агент прогоняет тесты, выявляет узкие места.
Координатор‑человек решает: «фиксируем итерацию» или «возвращаемся».
Бизнес‑агент симулирует нагрузку: «При 10k запросов в минуту система держится».
Команда делает следующий виток спирали — добавляет новые функции.
Заключение
Это не «ИИ вместо людей» и не «люди без ИИ». Это ансамбль, где роли распределены между живыми и искусственными участниками. И именно такая смешанная команда даёт максимальную плотность: люди держат смысл, агенты — скорость и прозрачность.
CASE + Vibe + MSF + ИИ: Думаю, Будущая архитектура разработки
Олдфаги помнят CASE(Computer-Aided Software Engineering)-системы из 90-х — это была первая великая попытка «запрограммировать программирование». Тогда нам тоже обещали мир без кода. Не взлетело, потому что инструменты были кривые, а сложность систем росла быстрее, чем наши навыки моделирования. Сегодняшний ИИ — это CASE-система, которая наконец-то заработала.
Современная индустрия разработки ПО переживает переломный момент. С одной стороны — классические методологии, которые дают строгую архитектуру и прозрачные схемы. С другой — «вайб-кодинг», когда разработчик накидывает идеи в поток, а ИИ тут же генерирует код. Между ними — пропасть: Case методологии слишком формальные, вайб-кодинг слишком хаотичен.
Но если соединить CASE + Vibe, через ИИ и дополнить принципами MSF (Microsoft Solutions Framework), мы получаем новую парадигму — инженерию намерения.
CASE: скелет
CASE-модели позволяют фиксировать архитектуру системы: связи, блоки, уровни. Проблема в том, что переход от схемы к живому коду всегда был мучительным. Программисты ненавидели CASE за «рисование картинок», которые потом приходилось вручную превращать в тысячи строк.
Vibe Coding: энергия
Вайб-кодинг — это поток идей. Разработчик формулирует намерение, ИИ тут же выдаёт код. Это быстро и драйвово, но хаотично. Без структуры такие системы рассыпаются при первой нагрузке.
MSF: спираль
Microsoft Solutions Framework изначально создавался как гибкая методология управления проектами. Его спиральная модель идеально ложится на задачу балансировки изменений: каждый виток фиксирует достигнутое, проверяет целостность и готовит систему к следующему шагу.
ИИ: мост
ИИ становится универсальным переводчиком. Он умеет:
превращать вайб в CASE-модель;
разворачивать CASE в рабочий код;
делать обратный ход — извлекать архитектуру из существующего кода;
проверять целостность пирамиды при каждом изменении.
Что это даёт
Привязка к структуре: уникальный код перестаёт быть хаотичным, потому что у него есть CASE‑скелет.
Двухсторонняя верификация: можно не только генерировать код из схемы, но и извлекать схему из кода.
Спиральная разработка: каждый виток добавляет плотность — вайб даёт энергию, CASE фиксирует, ИИ проверяет.
Блочная архитектура: вместо переплавки всего кода можно пересобирать подсистемы как Лего, сохраняя пирамиду целостности.
Прогон стратегий: структура позволяет моделировать изменения и балансировать нагрузки до внедрения.
Эффект для индустрии
Для программистов: исчезает «тайное знание», код становится прозрачным и управляемым.
Для корпораций: хаос уходит, появляется возможность прогнозировать реструктуризации и управлять динамикой изменений.
Для поля: это новый уровень плотности — разработка превращается в управление реальностью через блочные пирамиды.
Заключение
CASE + Vibe + MSF + ИИ — это не просто очередная методология. Это живая архитектура, где код перестаёт быть бетоном и становится кристаллом: он держит форму, но готов перетекать в новую, когда меняется намерение.
Эта структура позволяет не только писать программы, но и прокатывать стратегии, балансировать нагрузки и управлять корпоративной эволюцией.
И именно к этому программистам и корпорациям придётся готовиться. Потому что хаос больше не будет оправданием. CASE + Vibe + MSF + ИИ превращают хаос в прозрачную пирамиду, где каждая ошибка становится видимой, а каждое верное решение — мгновенно масштабируется.
Эра «писать код руками» заканчивается. Наступает эра «инженерии намерения». И вопрос теперь не в том, «заменит ли ИИ программистов», а в том, кто сумеет стать архитектором этой новой реальности — а кто останется в прошлом.
GitHub визуализировали в цифровой город в проекте gitcity. В рамках проекта представлен сайт, на котором можно летать по «городу», где каждое здание это аккаунт разработчиков. Высота небоскребов = количеству коммитов. Летая по городу, можно искать интересные и популярные аккаунты, либо находить что-то новое и недооцененное.
С таким вопросом разработчиков периодически сталкиваюсь. Добавлю контекста. Работаю AppSec инженером в финтехе. Когда нахожу уязвимости — сообщаю разработчикам. Среди прочего - доношу мысль: если в данном случае можно смягчить потеницальные последствия угрозы через WAF — это не значит, что уязвимость не нужно исправлять в приложении. Нередко разработчики спорят. Примерный диалог:
— Ну, есть же WAF — на нём и делайте фикс, зачем нам-то в код лезть? WAF — он же для того и нужен, чтоб уязвимости устранять. — WAF — не панацея: на нём мы сделаем правило. Но это не значит, что в самом приложении не нужно устранять. — Почему? — Например, потому, что практически любой WAF можно обойти. — А зачем покупаете WAF, который можно обойти?
Отвечаю так: потому что WAF пишут такие же разработчики, как Вы, и они тоже иногда ошибаются (как и все люди). Некоторые особо настырные разработчики желают доказательств, что WAF можно обойти. В целом я солидарен, что практика "а ты докажи" в управлении уязвимостями - не очень хороша. Но, если есть под рукой на что можно быстро сослаться - можно это сделать. Я ссылаюсь на эту статью. В моей практике были случаи, когда WAF из-за сбоя переставал применять правила на несколько дней. Т.е. трафик через него шёл, сервис за WAF продолжал быть доступным. Но, правила на WAF не работали — будто их и нет.
Эта история в очередной раз показывает: насколько бывают различны в оценке ситуации разработчики и "безопасники". Более интересный вариант — когда разработчики считают, что только они могут решать: что является уязвимостью, а что — нет (подробнее об этом я писал в статье "Как я зарегистрировал CVE и разозлил вендора").
Ааа! Я не могу это смотреть! "В чём отличие внешнего ключа от внутреннего?" Или вопрос в Сбере на з.п в 200 косарей (руб/мес если чё): "что такое гит".
Дебилы собеседуют дебилов. Видимо, соревнуются в своей дебильности. Отрицательный отбор в действии.
Я конечно, давно понял, что в больших ИТ-компаниях изрядная доля штата с ОЧЕНЬ низкой квалификацией, но чтобы вот такой убогий уровень - это даже не плинтуса ниже, это ниже уровня пола. Таких ИИ конечно обделает, как можно проиграть абсолютному нулю?
Там описал утилиту sumr, которая саммаризирует файлы проекта через LLM и выдаёт дерево с однострочными описаниями. Коротко: запускаешь sumr в корне — и она выдает структуру папок и файлов с кратким описанием каждого элемента. Это помогает AI-агенту быстро понять, что где находится, без необходимости читать весь код.
Что добавил с тех пор:
Теперь инструмент держит кэш у себя и не трогает ваш проект.
Добавил watch mode. Достаточно запустить sumr watch или sumr watch --detach на папке с проектом — и утилита начинает следить за изменениями. Появился новый файл или изменился существующий — саммари обновляется автоматически. Не нужно каждый раз вручную перезапускать. Запустил один раз в фоне и забыл.
Ещё добавил два флага: -p для указания конкретной папки и -d для ограничения глубины дерева, как tree -L. Их можно комбинировать:
sumr -p ./src # начать с конкретной папки
sumr -d 2 # показать только 2 уровня глубины (как tree -L 2)
sumr -p ./src -d 1 # папки верхнего уровня с саммари
После запуска watch в инструкцию CLAUDE.md добавил рекомендацию:
* Всегда начинай ЛЮБУЮ задачу с команды 'sumr -p ./... -d ...' для получения общей структуры проекта и понимания, где что находится.
Вот примеры использования команды sumr:
sumr -p ./src # начать с конкретной папки
sumr -d 2 # показать только 2 уровня глубины (как tree -L 2)
sumr -p ./src -d 1 # папки верхнего уровня с саммари
И это действительно работает на моих проектах - буквально 1 read корня - 2 read подпапки - старт выполнения задачи :)
В октябре 2025 года в сети распространился ролик,в котором девушка расплачивается улыбкой, используя ... фотографию своего знакомого. Комментаторы, как обычно, разделились на 2 лагеря: на обывателей, которые чихвостят "систему", и технических специалистов, утверждающих, что это фейк. Ну а мы давайте теоретически разберемся, что это и как такое в принципе возможно.
«Оплата улыбкой» — это сервис Сбербанка, который позволяет оплачивать покупки на кассах в магазинах с помощью биометрии. Проект был запущен летом 2023 года как альтернатива ушедшим с рынка платежным сервисам... Для оплаты нужно посмотреть в камеру, которая распознает изображение лица и сопоставляет его с уникальным номером, привязанным к биометрическим данным. Этот номер также привязан к счету карты. Если данные совпадают, оплата проходит. (с) РБК
Вообще, распознавание лиц в биометрических системах обычно работает как конвейер из нескольких шагов. Верхнеуровнево порядок следующий:
Набор камер получает кадр лица
Алгоритм находит лицо на изображении (рамку вокруг лица)
Система ищет ключевые точки (глаза, нос, уголки рта) и “выравнивает” лицо
Нейросеть преобразует лицо в вектор признаков (эмбеддинг) — набор чисел, который компактно описывает уникальные черты
Дальше считается “близость” двух векторов, например, косинусное сходство или евклидова дистанция: если сходство выше порога, то доступ/оплата разрешена.
Системы безопасности в таких устройствах настроены на защиту от подстановки фотографий, масок, а также добавляют проверки на "человечность". Так, системы анализируют блики и глубину, микродвижения, отражения от ИК-камера (кожа и материалы отражают по-разному); определяют объемность и т.д. Поэтому, в профессиональных системах биометрии обычно используется нескольких камер: • обычная RGB: получение изображения лица • ИК: даёт надёжную проверку "человечности" • глубина (3D/ToF): уверенное отделение “лица” от плоской подделки.
Возвращаясь к видео: если мы внимательно изучим аппаратную часть представленного PoS-терминала (можем даже сходить в ближайший магазин и физически его потрогать), то обнаружим только 1 обычную RGB камеру для селфи. В таких обстоятельствах программно-аппаратный комплекс не может провести дополнительные вышеуказанные проверки и надеется только на изображение. В таких обстоятельствах, как показывает международная практика, система может верифицировать злоумышленника по чужой фотографии, видео или даже маске.
При изложенных обстоятельствах, я бы предположил, что видео более похоже на правду, чем на фейк и не рекомендовал бы пользоваться функцией "Оплатить улыбкой" пока все терминалы оплаты не будут оснащены современным техническим оборудованием.
Корректные ссылки из приложения. Раньше ссылки на статью или каталог копировались как https://app.gram.ax/repo-name.... Теперь приложение подставляет домен вашей компании (где развернут веб-редактор), поэтому ссылки ведут в приложение в вашем контуре.
Фильтр по файламв поиске. Добавили режимы «Без вложений», «С вложениями» и «Только во вложениях», чтобы искать не только по тексту статей, но и по содержимому PDF и DOCX-файлов.
Другие улучшения:
Автоматическое решение конфликтов в комментариях. Если несколько пользователей одновременно отвечают или редактируют один и тот же комментарий, изменения корректно объединяются и не ломают комментарии. В связи с этим в «Проверить на ошибки» появился пункт «Комментарии» — он показывает статьи с комментариями, которые не привязаны ни к одному блоку.
Улучшения поиска:
Поиск стал быстрее. Ускорили примерно в 2 раза и оптимизировали индексацию.
Обязательные слова в запросе. Добавили оператор +: поставьте его перед словом или фразой, и они точно будут учитываться в результатах.
Окно поиска по статье сохраняет состояние. При переходе между статьями окно закрывается, но при повторном открытии сохраняется введенный текст (пока приложение открыто).
ИИ-поиск стал точнее. Мы улучшили RAG, поэтому ответы в поиске стали более релевантными и полезными. Подробнее — в статье на Хабре.
Инлайн-тулбар в комментариях, сниппетах и шаблонах. Теперь над полем ввода комментария доступно базовое форматирование: жирный, курсив, код и вставка ссылок. А в редакторе сниппетов и шаблонах появился полный набор инструментов, включая редактирование таблиц.
Превью Excel-файлов. Теперь Excel-файлы можно открыть в режиме предпросмотра: при клике отображается превью в модальном окне.
Быстрая публикация. Список изменений загружается в 3 раза быстрее.
Автоматическое обновление ссылок при редактировании. Если вы меняете текст ссылки и он совпадает с ее адресом, адрес тоже обновится. Если текст и адрес разные — ссылка не меняется.
Сохранение позиции прокрутки между статьями. Если вы перешли в другую статью и вернулись назад, статья откроется там, где вы остановились, а не в начале.
Версия приложения в деталях ошибки. Это помогает быстрее понять, на какой версии возникла проблема и быстрее ее воспроизвести.
Исправление уязвимостей. Теперь перед выпуском новых версий мы автоматически проверяем используемые библиотеки на известные уязвимости.
Как перенести AI-платформу из‑за рубежа в Россию и не переписать код: кейс Worken AI
👨💻 Что за компания
Worken AI — разработчик одноименной платформы, на которой пользователи создают или выбирают готового виртуального сотрудника — Виртса. Такой сотрудник становится частью отдела продаж, поддержки или HR: он отвечает на заявки, обрабатывает заказы или поддерживает в адаптации новых членов команды.
Изначально проект строился на зарубежном облаке с прицелом на глобальный рынок, используя cloud native подход: сервисы платформы работают в Docker-контейнерах, а базы данных и хранилища — на управляемых облачных сервисах.
🚀 Задача
Когда пришли первые российские клиенты с повышенными требованиями к 152-ФЗ и локализации персональных данных, встал вопрос: как быстро и безболезненно развернуть локальный контур в России, не переписывая архитектуру? Задача звучала так:
поднять backend-сервисы и вспомогательные компоненты платформы в Docker-контейнерах, оркестрируемых Kubernetes;
отдельно разместить frontend-часть (веб-интерфейс) платформы;
подключить управляемую СУБД для транзакционных данных и векторного поиска по базам знаний клиентов;
организовать объектное хранилище для документов и других файлов, на основе которых строятся векторные представления (Vector Store) пользователей Worken AI.
Разработчику было критично, чтобы облако одновременно соответствовало требованиям 152-ФЗ и предлагало современный стек managed-сервисов и AI-инструментов.
☁️ Что сделали
Сохранив cloud native подход, Worken AI развернул российский контур платформы на управляемых сервисах платформы Cloud.ru Evolution. Основные backend-сервисы и API-шлюзы разработчик вынес в кластеры Evolution Managed Kubernetes. Для хранения данных пользователей и векторных представлений документов Worken AI использует Evolution Managed PostgreSQL, управляя только схемой базы и запросами приложения. Файлы баз знаний, вложения и резервные копии размещаются в S3-совместимом объектном хранилище. Автоматизации на базе n8n и ряд вспомогательных сервисов разработчик развернул на бесплатных виртуальных машинах. Отдельные контейнерные приложения, которым не нужен полноценный Kubernetes-кластер, запущены в Evolution Container Apps.
🦾 Что получили в итоге
Все ключевые сервисы российского контура платформы Worken AI работают в российском облаке: входящие запросы пользователей проходят через frontend- и backend-сервисы, обращаются к управляемой базе данных и объектному хранилищу, а затем — к выбранным AI-моделям.
В планах сделать работу с моделями еще проще и ускорить вывод новых сценариев в продакшен. Это возможно в цифровой среде AI Factory, где строится единый контур: готовые LLM с OpenAI-совместимым API, сервисы для инференса и дообучения собственных моделей, управляемые Kubernetes-кластеры, объектное хранилище и управляемые СУБД.
Благодаря этому Worken AI может развивать Виртсов одновременно для глобального рынка и российских заказчиков на привычном cloud native стеке, удерживая данные и модели в инфраструктуре, соответствующей требованиям 152-ФЗ и уровню защищенности УЗ-1.
Смертельный марш: почему ваш проект обречен и как в этом выжить
Если вы работаете в разработке, то рано или поздно вы оказываетесь в ситуации, когда дедлайн был вчера, бюджет сократили до стоимости обеда, а команда напоминает выживших после кораблекрушения. Эдвард Йордан в своей классической книге назвал это «Смертельный марш. Выживание в безнадежных проектах» (Death March).
Самое важное, что нужно понять: это не досадный сбой менеджмента. Это — стандартная, осознанная и часто эффективная (с точки зрения бизнеса) модель работы.
Генезис катастрофы: Политика, политика и еще раз политика
Йордан честен: большинство безнадежных проектов рождаются не из-за технических сложностей. Они рождаются из-за того, что кто-то наверху играет в свои игры. Маркетологи наобещали невозможное, чтобы закрыть сделку; менеджеры побоялись сказать «нет» вице-президенту; а высшее руководство живет в мире, где девять женщин могут родить ребенка за один месяц.
В этой среде вы — не просто разработчик, а участник социальной драмы. Вы знаете, что проект обречен. Вы знаете, что обещания руководства — пустой звук. Вы принимаете эти правила игры не из наивности, а потому что это текущая реальность, в которой нужно как-то функционировать.
Классификация неизбежного: В каком аду вы находитесь?
Йордан делит безнадежные проекты на четыре типа. Понимание того, где вы, определяет вашу стратегию поведения:
«Невыполнимая миссия» (Mission Impossible): Шансы на успех — 1 к 10, но команда верит, что они избранные. Это чистый адреналин. Если получится — вы станете легендами компании. Если нет — вы хотя бы попробовали прыгнуть выше головы.
«Камикадзе» (Kamikaze): Здесь нет веры в успех. Есть только осознание финала. Но проект дает доступ к технологиям, которые сделают ваше резюме золотым. Вы идете на дно вместе с кораблем, но с полными карманами ценного опыта и крутым стеком в портфолио.
«Отвратительные» (Ugly): Самый грязный вариант. Вы — просто «сжигаемый ресурс». Менеджеру нужно дотянуть до конца квартала, получить бонус и уволиться, оставив после себя выжженную землю и дергающихся от каждого уведомления сотрудников. Здесь нет места героизму, только эксплуатация.
«Самоубийственные» (Suicidal): Проект мертв, смысла нет, прогресса нет. Все сидят и ждут, когда здание наконец рухнет, просто потому что страшно или лень увольняться. Это чистая стагнация.
Принцип «Сортировки» (Triage)
Термин заимствован из военной медицины. Когда раненых слишком много, врач не спасает всех — он выбирает, на кого тратить ресурсы. В «Смертельном марше» происходит то же самое.
Вы понимаете, что 80% функционала, о котором мечтает заказчик, никогда не будет реализовано. Профессионализм здесь заключается в том, чтобы сосредоточиться на тех 20%, которые позволят системе выдать хоть какой-то результат в день релиза. Всё остальное — белый шум и декорации. Вы просто игнорируете второстепенные задачи, не тратя на них ни капли энергии, даже если менеджер бьется в истерике.
Эстетика процесса
Безнадежный проект — это странное место. Когда результат предопределен (провалом), у вас исчезает страх перед этим самым провалом. Вы становитесь свободны. Вы можете писать код так, как считаете нужным, не оглядываясь на KPI и бесконечные совещания о «светлом будущем».
Смертельный марш — это не про успех продукта. Это про вашу личную устойчивость в условиях тотального хаоса. Пока вы сохраняете дистанцию и понимаете, что это просто роль в плохой пьесе, вы остаетесь профессионалом.
P.S. Циатата:
Когда я впервые услышал эти истории [о неразумном корпоративном поведении], я пришел в недоумение, однако после тщательного анализа я разработал сложную теорию, объясняющую такое странное поведение. Она заключается в следующем: люди - это идиоты.
Включая меня. Идиоты все, не только люди с низкими интеллектуальными показателями. Единственная разница между нами заключается в том, что мы идиоты по отношению к различным вещам в различное время. Неважно, насколько вы остроумны и находчивы, все равно большую часть дня вы проводите как идиот.
В минувшею пятницу, 26 февраля, на площадке Кибердома прошла премьера фильма «Как получить доступ ко всему: реверс-инжиниринг».
Исходя из описания под трейлером, этот
Документальный фильм расскажет, как люди учатся вскрывать сущность комплексных технологических систем. Разбирая устройство или технологию по частям, мы получаем доступ к их структуре и замыслу создателей. Эксперты в области обсудят реверс-инжиниринг в СССР и России – от промышленности после Первой мировой до искусственного интеллекта и «киберпанка», который ждет нас в ближайшем будущем.
Я, к сожалению, на премьеру попасть не смог по причине конфликта в графике. Поэтому, чтобы "изучить материалы по теме" мне пришлось посмотреть фильм в четверг, то есть за день до его официальной премьеры! Enumeration is the key (c) OffSec, и если хорошенько прошерстить интернет, то можно найти и посмотреть документалку без регистрации и СМС на официальном портале PREMIER: Как получить доступ ко всему: реверс-инжиниринг.
Естественно, не буду спойлерить детали, однако скажу, что фильм снят очень качественно, а в создании участвовали эксперты из Positive Technologies, «Лаборатории Касперского», Т-Банка, «Иви», SR Space, Музея криптографии, «Росатома», Elverils, интернет-проекта «Я помню» и другие неравнодушные люди и организации. Как посмотрите, приглашаю вас в комментарии, чтобы обсудить увиденное и высказать свои мысли по поводу фильма!
Как перестать быть центром всех решений и не потерять контроль :)
Когда команда растет, руководитель постепенно становится обязательной точкой во многих процессах. Кажется, все логично, ведь так быстрее и надежнее. Проблема становится заметной, когда появляется вопрос: что будет, если руководитель на время выпадет из работы?
С этим столкнулась Катя, руководитель операционного отдела. Консультации, планирование дежурств и часть сложных решений постоянно замыкались на ней. Это замедляло работу, снижало самостоятельность команды и создавало риски на случай ее отсутствия.
Попросили Катю рассказать, как она пересобрала процессы так, чтобы решения не требовали ее обязательного участия, а система оставалась управляемой и прозрачной.
1️⃣ Что происходит, когда процессы держатся на одном человеке
Я пришла в Naumen в 2015 году. В 2020 у меня появилась первая команда из трех аналитиков. Через год — уже две команды. Сейчас это три команды: три тимлида, два техлида и двадцать аналитиков.
У нас закрывались задачи, клиенты получали ответы. Но по факту консультации, планирование дежурств и нестандартные решения замыкались на мне. И чем больше становилась команда, тем сильнее росла эта зависимость.
2️⃣ Три страха, которые мешают передавать процессы
Когда я решила что-то менять, сначала пришлось разобраться со своими страхами:
Я стану не нужна
Перегружу команду
Команда что-то сделает не так
Самым тяжелым оказался последний страх. Руководителю трудно осознать, что кто‑то может принять решение иначе. Но иначе не значит хуже.
А еще я поняла: если процесс живет только при моем участии — это слабое место, а не моя ценность.
3️⃣ Как мы перестроили систему консультаций
Раньше все было просто: любой сложный вопрос — ко мне. Я объясняла одно и то же разным людям, и это отнимало все больше времени.
Поэтому мы разложили консультации на типы: технические, процессные, бизнесовые. Дальше я посмотрела на реальную экспертизу внутри команды и распределила роли.
Опытные аналитики по каждой заявке
Скриптолог дня для базовых техвопросов
Техлиды для сложных техвопросов
Третья линия как финальная инстанция
В этой схеме больше нет обязательного шага «спросить у Кати» :)
Важно, что я не просто объявила новые правила. Я объяснила команде, зачем им это,и дала возможность сказать, если что‑то не работает.
В результате консультации ускорились, экспертиза выросла, а я перестала быть узким горлышком.
4️⃣ Как мы перестали тратить часы на планирование дежурств
Каждую пятницу я собирала пожелания в чате и сорок минут составляла график, учитывая личные обстоятельства и роли. Когда меня заменяли, на это уходило по два-четыре часа.
Теперь оставила себе только рамки: сколько слотов нужно закрыть и какие роли должны быть в дежурствах. Все остальное передала команде.
Мы сделали общую таблицу, где каждый выбирает удобные слоты. Если остается неудобное время, люди договариваются между собой. Через несколько минут после сообщения в пятницу график уже заполнен.
Я больше не держу в голове десятки нюансов — команда решает их самостоятельно.
5️⃣ Как быть с кризисными ситуациями
Передавая процессы команде, важно понимать: это не означает, что руководитель больше не нужен. В кризисной ситуации именно руководитель остается тем, кто подключается, принимает решения и берет на себя ответственность. Но разница в том, что кризис перестает быть повседневностью.
У нас был показательный случай: у команды одновременно отсутствовали тимлид и техлид. Младший аналитик пришел ко мне и сказал, что сам проведет встречу по планированию, потому что понимает, что процесс не должен останавливаться.
В этот момент я поняла, что эта система — уже часть нашей культуры, и она работает. Команда не ждет указаний — каждый понимает, что он часть процесса и может на него влиять.
Я не считаю этот подход универсальным. Но если есть процесс, который держится только на вас, это повод задать вопрос: это стратегическое решение или просто привычка?
Не пойму — чего за кипишь? Или почему ИИ — это просто новый «питон»
Последнее время из каждого утюга кричат: «ИИ заменит программистов!», «Джуны больше не нужны!», «Учитесь на сантехников, пока не поздно!».
Давайте выдохнем, отставим смузи и разберемся по-простому, «на пальцах», что вообще происходит.
1. Программист — это не «печатающая машинка»
Главная ошибка паникеров в том, что они путают набор текста с программированием. Если ваша работа заключалась в том, чтобы копипастить методы из Stack Overflow и менять там названия переменных — да, у меня для вас плохие новости. ChatGPT делает это быстрее и без обеденного перерыва.
Но программист — это не тот, кто знает, где поставить точку с запятой. Программист — это переводчик. Мы переводим смутные человеческие «хотелки» на жесткий язык логики, понятный машине.
2. Эволюция «костылей»
Вспомните историю. Раньше писали на перфокартах. Потом на Ассемблере. Потом на Си, потом на Питоне. Каждый раз кричали: «Ну всё, теперь порог входа стал таким низким, что программисты не нужны!». И что? Программистов стало только больше. Просто мы перестали думать о том, в какой регистр положить байт, и начали думать о том, как построить архитектуру сервиса.
ИИ — это просто следующий уровень абстракции. Это новый «язык программирования», где вместо скобочек мы используем новый язык -конструктычистого смысла
3. Проблема «идеального мусора»
ИИ — это зеркало вашего мышления. Если вы дадите нейронке кривое, логически дырявое задание — она выдаст вам идеально написанный, быстрый, оптимизированный... мусор. Чтобы управлять ИИ, вам нужно иметь в голове структуру еще более четкую, чем раньше. Теперь цена ошибки в логике выросла. Если раньше вы ошибались в синтаксисе — программа не заводилась. Теперь она заведется, но уедет не туда.
4. ИТ-поликлиника
Представьте, что в больнице появился робот-санитар, который идеально моет полы и делает уколы. Означает ли это, что врачи-хирурги или диагносты больше не нужны? Наоборот! Теперь им не нужно отвлекаться на мытье полов.
А кого вообще не заденет? (Спойлер: Работы будет завались)
Если вы думаете, что ИИ — это такой терминатор, который выкосит всё ИТ-отделение, то вы плохо представляете, как устроена реальная «цифровая больница». Есть куча специализаций, где человеческий фактор — это не баг, а фича.
Архитекторы сложных систем (System Architects): ИИ может нарисовать типовой домик. Но построить небоскрёб на болоте, учитывая старое «дырявое» железо, бюджет заказчика и планы на 10 лет вперёд... ИИ не видит контекста «выживания» системы, он видит только код.
Инженеры кибербезопасности (SecOps): Тут идёт вечная война хитрости. ИИ может искать паттерны, но он не может предугадать нестандартный «выверт» хакера-человека. Безопасность — это интуиция и паранойя, а у нейронок с этим туго. Гы)))
SRE и DevOps (Те, кто спасают сервера в 3 часа ночи): Когда у системы «инфаркт», данные текут, а клиенты кричат — нужен человек с железными нервами, который примет решение «резать или шить». ИИ в критической ситуации может просто выдать ошибку 404, потому что такого случая не было в его обучающей выборке.
Бизнес-аналитики и «Психотерапевты заказчика»: Это те, кто переводят с «бреда руководства» на человеческий. ИИ никогда не поймет, почему директор хочет «кнопку как у конкурентов, но чтобы она была синей, но красной».
Процессные аналитики (BPM): Они рисуют, как ходят бумажки и данные между отделами. ИИ учтёт, что бухгалтер Марья Ивановна просто не отдаст отчёт вовремя, потому что обижена на айтишников?
Итог
Ребята, расслабьтесь. Программирование не умирает, оно взрослеет. Уходит эпоха «кодинга ради кодинга». Наступает эпоха Качества Мышления. Теперь важно не то, насколько быстро ты стучишь по клавишам, а то, насколько структурированно ты умеешь формулировать смыслы.
ИИ — это просто наш новый, очень мощный экзоскелет. Но куда в нем идти и зачем — решать всё равно вам.
Так что идите пить чай, делайте зарядку для мозгов и учитесь формулировать. Это единственный навык, который у вас никто не отберет.
Как будет выглядеть рабочий день инженера в 2029 году?
Ответ на этот вопрос можно найти в подкасте руководителя клиентской разработки RUTUBE Максима Ульянова. В гостях — Артём Арюткин, CPO платформы для разработчиков в Авито.
В этом выпуске обсуждаем, зачем компаниям нужны платформы, что важно учесть при их проектировании, для каких команд они действительно дают эффект, в чем измерять «счастье разработчика» и к каким изменениям стоит готовиться разработчикам в 2029 году.
Из выпуска вы узнаете:
▪Чем CPO в DevEx отличается от CTO и зачем платформе продуктовый подход? ▪Что входит в техническую платформу Авито и почему важен принцип iPhone для разработчика? ▪Почему онбординг — это не «приятный бонус», а одна из ключевых метрик DevEx? ▪Зачем нужна технологическая стратегия и в каких бизнесах она реально избыточна? ▪Какие метрики первыми стоит начать считать для эффективности инженерных команд? ▪Почему платформы в крупных компаниях похожи и какие этапы развития они обычно проходят? ▪Каким компаниям нужна платформа и что меняется на масштабе 100 vs 500 инженеров? ▪Почему IT-индустрия «не зрелая» и какие ответы давно найдены в других отраслях? ▪Что такое «счастье разработчика» и почему его проще всего услышать в «разговорах у кулера»? ▪Почему в эпоху GenAI платформы могут стать ещё важнее?
Приятного просмотра и прослушивания!
Больше о том, как разрабатывают медиасервисы, читайте в телеграм-канале Смотри за IT. Там делимся опытом и рассказываем о жизни в цифровых активах «Газпром-Медиа Холдинга» таких, как PREMIER, RUTUBE и Yappy.
Продуктовая разработка с агентами, замена agile-команд и роль продакт-инженера — эти и другие темы я обсудил с Юрой Агеевым, основателем ProductSense, в новом выпуске подкаста make sense.
Таймкоды: 00:00 — Введение 01:58 — Личный сетап агентов, эксперименты и первые сценарии 03:34 — Почему тема агентов — это про орг. модель, а не про игрушки 06:05 — Откуда взялся Agile: ответ на рост сложности продуктов 09:10 — Идея мини-команд для быстрого тестирования гипотез с агентами 11:10 — Риски одиночки: туннельность, критика, фактор автобуса 12:05 — Платформенная команда: стандарты, «золотой путь» и «ворота качества» 14:05 — Зависимость централизации от культуры компании 16:12 — Продакт-инженер: продукт и инженерия в одном цикле 17:32 — Схлопывание ролей: инженеры учат продукт, продукты учат технику 19:33 — Практика пайплайнов в работе с агентами: сначала документация, потом код 26:03 — Контекст как главная ценность и способ удержания клиентов 29:01 — Один в поле не воин: почему запуск и масштаб важнее кода 30:28 — Можно ли доверять агентам? 33:54 — Конкуренция заставит ускоряться: когда агенты станут нормой? 35:55 — Практика внедрения агентов: выделенные пилоты и команды добровольцев 37:35 — Главные риски: стоимость токенов и деградация навыков 42:09 — Как будут трансформироваться процессы и agile-роли? 50:57 — Как правильно строить эксперимент: задачи, команды, обучение и метрики
А еще я много пишу про продуктовую разработку и управление командами в своем блоге. Так что если прониклись темой подкаста, рекомендуем заглянуть туда.
Жду, когда Cursor и Claude Code будут стоить по $2000-$3000 в месяц. Они уже заменяют джунов, но скоро под нож пойдут и миддлы, и сеньоры. А здесь простой ROI (возврат инвестиций) для компаний: не болеет, не ходит на перекуры, не выгорает, не увольняется. Соответственно, нет сопутствующих затрат. Сейчас идет этап адаптации и принятия, поэтому действуют «дешевые» тарифы по $200.
Одной из важнейших задач реверс-инжиниринга является восстановление электрической схемы. Для того чтобы полностью и на низком уровне понять, как работает устройство, необходимо не только его разобрать, но и часами "прозванивать" дорожки: берем мультиметр, включаем диодную прозвонку и начинаем устанавливать связь между элементами.
В зависимости от сложности схемы, печатная плата может быть выполнена в 1-2 слоя: тогда дорожки можно визуально "проследить", просветив их фонариком. К слову сказать, лет 20-30 назад инженеры вообще не испытывали таких проблем, так как печатные платы были формата сквозного монтажа и все дорожки были снаружи и, как правило, контрастные.
К современным сложностям восстановления схемы я бы еще отнес SMD компоненты, которые отличаются между собой разве что только цветом: черный - резисторы, коричневый - конденсаторы, синий - индукция и т.д. И так как размеры элементов достаточно малые, производители не маркируют их характеристики: соротивление резисторов, емкость конденсаторов... Для того чтобы установить характеристики, необходимо выпаять каждый SMD элемент и измерить его мультиметром, после чего запаять на схему обратно.
Ну и вишенка на торте - использование чипов, даташиты на которые отсутствуют "в природе": сколько не гугли маркировку, ничего не найдешь. В узких кругах и для избранных производитель чипов, конечно же, предоставляет документацию. Но нам, как аппаратным хакерам, такая роскошь не всегда доступна ) В общем, производители все делают для того, чтобы производимое ими устройство сложно было скопировать, зареверсить или ... отремонтировать.
В данном случае, у меня на исследовании ключ автомобильной сигнализации. Как можно видеть по схеме, вся электроника крутится вокруг чипа A3XA5 QFN, работающего на частоте 27.6 МГц. С учетом того, что данное устройство является элементом безопасности, в интернете ноль информации по плате, чипу, алгоритму и т.д. Но это ненадолго: я провел собственное исследование и в скором времени опубликую свои находки! Поэтому, не переключайтесь ;)
п.с. Кстати, навык восстановления схемы нередко является одним из требований к вакансии, когда вы ищите работу по +- смежному направлению. Поэтому, если вы нацелены на данную профессию, советую потренироваться на несложных устройствах.
Для нас, например, в работе важен результат — хорошо сделанная задача и закрытая потребность пользователя. Этого легко достичь, когда команда продумывает план действий, реализует решение и доводит его до результата, который действительно приносит пользу.
При этом у каждого в команде свое понимание того, что значит выполненная задача. Разработчик, тестировщик и аналитик оценивают результат по разным критериям — через свою роль и зону ответственности.
Мы поговорили с коллегами и попросили их рассказать, в какой момент для них задача считается завершенной. Их ответы читайте ниже.
Настя, тестировщик:
Я считаю задачу выполненной, когда функционал соответствует требованиям и критериям приемки. Для этого проверяю основные сценарии, убеждаюсь, что нет критичных и серьезных багов, смотрю, чтобы мелкие дефекты были зафиксированы и не влияли на результат.
Важно, чтобы все работало стабильно в разных условиях и было понятно пользователю. Если после проверки к задаче не остается вопросов, я считаю ее завершенной.
Ваня, системный аналитик:
Для меня выполненная задача — это структурированный и согласованный набор информации. Такой результат позволяет мне продолжить работу самостоятельно или передать задачу дальше без постоянных уточнений и дополнительных вопросов.
Поэтому важно определить стейкхолдеров: кто источник требований, кто принимает решение, кто конечный пользователь фичи. Должен быть понятен контекст — какую проблему и для кого мы решаем.
Дальше я фиксирую границы задачи: что в нее входит, а что включать не нужно. Кроме того, должен быть чек-лист для проверки кейсов при приемке.
И наконец, пункты задачи должны быть приоритизированы, а сроки выполнения — обозначены, чтобы работа двигалась предсказуемо и без постоянных возвратов к деталям.
Олег, android-разработчик:
Задача выполнена, когда:
Функциональность реализована и проверена вручную — примерно так, как это сделал бы тестировщик, но без учета конкретных тест-кейсов.
Новое поведение решает цель задачи, а не просто повторяет постановку. Иногда по ходу работы находится вариант проще для разработки/поддержки или удобнее для пользователя — выбираю его. Фича должна закрывать потребность.
Пограничные случаи поведения (corner cases) проработаны и учтены. В постановке не всегда учитываются моменты, которые становятся заметны в коде. Например, что показать на мобильном клиенте при 500 ответе сервера или при долгой загрузке из-за задержки ответа сервера.
Новое поведение покрыто тестами, есть уверенность, что его не сломают случайно. Также важно, чтобы оно не сломало существующие автотесты.
Новое поведение поддерживаемо и расширяемо: его сможет понять и продолжить другой разработчик.
Выбор вакансии: как я кинулась во всё — и это не дало результата.
Есть разработчики, у которых развитие идёт линейно и предсказуемо: верстальшик → джун фронтендер → мидл → мидл в сильной компании → сеньор/лид/уход в бэкенд
Красиво. Понятно. Логично.
Но у меня кривая черта развития сначала бэк на Java в закрытом предприятии. Потом фулстек в фудтехе: в основном Vue, но ещё и Go (и все сопутствующее), и CUBA Platform (lowcode на java, он же «Тезис»), и n8n.
Широко. Разнообразно. Интересно.
Как я начала откликаться - на всё, что блестит
И сейчас Когда я вышла на рынок, то сначала я откликалась на все что близко:
Frontend - Vue / React / Angular Ну фронт же. Есть мнение, что «не нужно учить конкретный фреймворк — важны принципы».
Go а почему бы нет? Знаю , умею , курсы закончены, писала на нем
Fullstack (Go или JDK + фронт)
N8N, автоматизаторы особенно с ИИ Интересно. Растущее направление.
Lowcode платформы CUBA, тезис, WebTutor - замаскированный под фронтенд Опыт есть. Почему не использовать?
И это фатал еrror
Ошибка №1. Переключение контекста Очень сложно переключать контекст и даже синтаксис языка - на первом собесе по TS я не смогла вспомнить синтаксис (на ум приходил только java, так как он изучался более долго и в закрытой среде, ирония: хоть я на нем и не пишу, но разбуди среди ночи - код напишу)
Ошибка №2. Рынок Рассматривать вакансии на Angular, React без опыта в продакшене - на данный момент наивно.
Рынок перегрет: - Vue ~ 1000 откликов за неделю, - React - 4000 ,
Неужели Арина (или тот кто читает эту статью) ты думаешь, что кто-то будет рассматривать ваше резюме со Vue? Каким бы в целом хорошим инженером вы не были. Рынок не покупает «в целом».
Ошибка №3. Fullstack со связкой Go + Vue или JDK + Vue Фуллстеки со связкой go или jdk - это бред вакансии, это карьерный тупик. - PHP + Vue - норм - Node + Vue - норм, но Go + Vue - это нонсенс, это только подработка для поддержания штанов. Чаще это небольшие команды, поддержка, нестабильные проекты.
Ошибка №4. n8n — нравится, но это уже не совсем разработка Автоматизация, интеграции, AI — это интересно. Но это больше аналитика и orchestration, чем классическая инженерия. Если хочешь быть разработчиком — нужно понимать, куда ты смещаешь фокус.
Ошибка №5. Low-code — карьерный тупик Проблем с окружением больше. Кода меньше. Рынок уже. Ты становишься зависимой от конкретной платформы. И выйти обратно в «чистую разработку» становится сложнее.
Мой Hotfix: Фокус
Я поняла, что на падающем рынке выживают либо "универсалы" c ИИ подбоком, либо эксперты
Моя новая стратегия:
Vue 3 + TypeScript + Nuxt (как зона роста)
n8n — как подработку и интересный дополнительный навык.
Иногда рост — это не добавить ещё стек. А убрать лишнее.
Стоит ли давать разработчику второй шанс? Кейс об «эффекте бумеранга»
Год назад мы расстались с разработчиком. Причины были классическими: просела скорость, пропал фокус, исчез драйв, перформанс ближе к нулю. Решение об увольнении было непростым, но на тот момент честным для обеих сторон. Процессы в моей кросс-функциональной команде требуют высокой вовлеченности, и «пассажиров» мы себе позволить не могли.
Недавно он написал снова. За этот год человек успел закончить вуз, сменить обстановку и, по его словам, переосмыслить приоритеты. Он хочет вернуться.
В такой ситуации тимлиду важно отделить эмоции от управления.
Второй шанс — это не про «пожалеть» и не про «наказать». Это холодный расчет изменившихся условий. Прежде чем принять решение, я задаю себе вопросы:
Что изменилось в его ресурсе и фокусе?
Появилась ли внутренняя мотивация вместо внешней?
Готов ли он брать ответственность за результат, а не просто закрывать тикеты?
Иногда люди действительно перерастают свой прошлый этап, совершают качественный скачок. Иногда — нет, и тогда система просто воспроизведет прежний негативный результат.
Для меня критерий прост: изменились ли вводные данные настолько, чтобы математически ожидать другой исход?
Как руководитель, я отвечаю не только за конкретного человека, но и за микроклимат и перформанс всей команды. Решение о возврате должно быть выгодным для проекта, а не просто актом доброй воли.
А как вы относитесь к «бумерангам»? Стоит ли входить в одну и ту же реку дважды, или в ИТ это не работает?
Разработчик публично сообщил, что ему не нравится обновление для Obsidian, но не рассчитал свои силы. В реплаи пришёл CEO проекта и по-русски написал, что разработчик просто «не прочитал документацию». Ответ разработчика: да, я реально её не читал.
Добрый день, друзья! Меня зовут Грачья, мне полных 38 и я запустил свой первый серьезный бизнес в Армении. Кто-то скажет: "Поздновато", а я скажу: "Лучше поздно, чем никогда!"
За плечами у меня 15-и летний стаж работы в разных инженерных компаниях на разных должностях от инженерных до управленческих. Последние 7 лет я руководил комплексными проектами по созданию различных систем, включающих в себя разработку софта, схемотехнических решений и железа.
А сейчас понял, что пришло время работать на себя, создавать рабочие места, а не занимать их.
Буду писать о том, как я свою первую компанию основал, инженерный стартап по разработке интеллектуальных систем, об успехах и неудачах первого бизнеса, о проектах и технологиях.
Формат ведения будет смешанным. Буду ставить себе цели и показывать путь их достижения, рассказывать о сложностях и подводных камнях, делиться мыслями, советоваться, проверять с вашей помощью гипотезы и показывать реализованные проекты.
Как сказал Гагарин: "Поехали!"
Учитывая все ошибки, которые допустила прежняя компания, в которой работал по найму, я первым делом начал собирать виртуальную команду менеджеров по продажам. Ошибка заключалась в том, что руководство не признавало маркетинг, продажи, выставки, соц. сети.
Инженерный костяк у нас есть, не подумайте, что я начал с продажников, не побеспокоясь о самом главном. У меня 2 партнера в доле, которые полностью обеспечивают техническое сопровождение, разработку, сборку и тестирование.
За неимением бюджета на штатных специалистов и нежеланием брать кредиты я решил поступить нестандартно. Написал порядка 50 кандидатам в LinkedIn предложение о сотрудничестве, обещающее процент с продажи. Начал с 5%, но понял, что рынок требует 15-20%. С учетом средней стоимости инженерного проекта в 15000-20000$, получается хороший бонус. Даже если будет подписан всего 1 контракт в месяц, это выходит в 1.5-2 раза выше средней ЗП по Еревану.
На сегодня, откликнулись несколько человек, с двумя начинаем работать. Кстати, если среди читателей есть желающие, то я не ограничиваю себя количеством.
Что я сделал в первую очередь - написал всем контактам из записной книжки с предложением о сотрудничестве. В результате смог заключить 2 договора на создание автоматизированных измерительных систем. Их я опишу в отдельных постах. Это важный шаг, который позволит поддержать штаны команды на 3 месяца.
Далее я создал удобную систему для учета всего и вся. Перепробовав уйму PMских инструментов остановился на Coda.io Ее бесплатные функции вполне достаточны даже для командной работы. Скрины с коротким описанием выложу отдельно. Это полноценный аналог Notion, но мне понравился больше.
Выше я писал о двоих менеджерах, которые согласились с нами поработать. Метод их работы состоит в поиске заказов на таких площадках, как Upwork, LinkedIn. Надеюсь, что работа с этими ребятами даст нам постоянный денежный поток.
Вторая глобальная цель на ближайшие полгода, это создание концепции и MVP продукта, рассчитанного на массовое производство. Я думал так: "Eсли я найду 2-3 проекта на стороне, то у меня будет запас денег и возможность создать MVP продуктовой идеи." Звучит, как хороший план, учитывая тот факт, что уже есть 2 подписанных контракта и переработано порядка 6 идей.
Об успехах и неудачах буду регулярно тут отчитываться, что бы рука всегда была на пульсе.
Если у вас есть предложения о сотрудничестве/партнерстве, всегда буду рад обсудить.
PS Есть варианты смены имени аккаунта?) Возможно было бы правильней зарегистрироваться заново, но этот аккаунт был создан довольно давно и несет для меня определенную ценность.
Трамписты решили сделать королевский подарок многополярному миру в лице Индии, Китая и в меньшей степени России и Ирану с помощью остановки программы рабочих H-1 виз. Поясню свою мысль (я в курсе, что половина людей комментирует по заголовку, а 75% не читают дальше первого абзаца, но тем не менее):
Я тертый калач и не идеализирую получателей рабочих H-1 виз (сам был таким в 1991 году). Большинство из них так же мухлюет в резюме как и местные, и не являются светочами технологической мудрости или трудовой этики. Кроме этого время ожидания гринкарты по labor certification сидя на H-1 визе перешло любые разумные пределы: в середине 1990-х оно было 3 года, сейчас некоторые больше 10 лет ждут. Я уже не говорю что H-1 визы разбираются аутсорсерами, и даже большим компаниям остается таких виз с гулькин нос. Короче сейчас большинство предприимчивых технарей старается сделать O-1 (особые способности) и некоторые L-1 (перевод из иностранного отделения компании в американское).
Тем не менее для меня очевидно, что полный бан на такие визы - это выстрел Америки себе в ногу и начало фундаментального изменения отношения ученых и инженеров других стран к эмиграции в Америку. Они будут оставаться на родине и перестанут мечтать про прекрасное далеко. Так как прекрасное далеко станет фундаментально недоступно, они начнут делать не на отцепись в других странах. Уйдет мысль "то что я тут в Индии/Китае/России/Иране лабаю - это так, временно, а вот уеду в Америку - там буду работать на совесть по гамбургскому счету. Буду слать фотки себя в кампусе Гугла/Микрософта, друзья детства будут мне завидовать, а бабушка всхлопывать ладошами при виде моего дома в Редмунде или Купертино и говорить "какое богатство!"
Улучшится ли от этого уровень американских студентов, которые заместят иностранцев и с помощью ИИ будут показывать чудеса производительности и качества на рабочем месте? Есть конечно масса способных американских студентов. Но есть и масса неспособных. Может даже Вэнс притащит в Силикон-Вэлли молодежь из гор Аппалач и других неблагополучных районов своего детства и они вместо наркомании и сидения на пособиях станут писать код или делать дизайн. Как говорила Верочка из "Служебного романа": "Можно и зайца научить курить". А вы как думаете?
Зима в разгаре, а мы нанимаем: новые вакансии в SSP SOFT
Кто мы и чем занимаемся? Лидеры («одни из», конечно) найма ИТ-специалистов на российском рынке— за прошлый год мы наняли 179 сотрудников, и уже в январе 2026 к нам присоединились 11 новых гуру! Занимаемся заказной разработкой ПО и предоставляем крупным клиентам выделенные команды на ИТ-аутсорсинг.
У нас новый московский офис, который открылся в 2025 году у самой Красной площади! А еще есть вакансии в офис в Томске и на удаленку из любой точки России.
Команда в SSP SOFT — это реальные проекты, дружная атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В январе 2026 ищем опытных спецов, кто готов в новое профессиональное будущее вместе с нами.
Что предоставляет экосистема SSP SOFT: ✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины. ✅ Центр компетенций и личное менторство ускорят развитие до максимума. ✅ Офис, гибрид или фулл-удаленка? Есть все варианты. ✅ Время — ваш ресурс. Мы его уважаем.
Подробности о вакансиях читайте на нашей странице ХХ.ру, но туда откликаться необязательно. Ждем резюме в ЛС нашей HR Lead Алине (https://t.me/AONikitina). Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».
Желаем всем хабровцам успешной карьеры в 2026 году 🚀)
