Птичка на хвосте принесла.
Российские хостеры начали убивать аккаунты (вместе со всем, что на них было), ссылаясь на 126 ФЗ.
Другая птичка говорит, что подобное уже происходит, если детектят трафик для телеграм прокси или vpn в какой-либо форме.
Как именно происходит детекция - птичий совет пытается выяснить.

Но совершенно точно не стоит держать что-то похожее на телеграм прокси или ВПН на одном аккаунте со всей остальной инфрой.

Пришло время признаться: я уже некоторое время вайбкожу на проде. И вот какие выводы для себя сделал.

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

Сейчас поясню.

Агенты уже вполне неплохо справляются с написанием кода, тестов и рутиной вроде «сходи в сервис Х через MCP и запиши туда саммари нашего диалога, переведя на клингонский». На них реально построить SDLC и получать вменяемый результат, закрывающий потребности бизнеса. Да, остается открытым вопрос качества архитектуры, удобства рефакторинга и склонности агентов ломать легаси. Но уже сейчас можно уверенно сказать: агент — это джун с охренительным кругозором и бесконечной работоспособностью.

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

Те же вопросы, которые я задаю разработчику: «хрен ли ты тут накодил?», «а про откат миграций не забыл?», «какие кейсы покрыл тестами?» — я адресую агенту. И он отвечает не хуже мясного сотрудника. И ровно так же, как с кожаными мешками: иногда агент оказывается умнее (кругозор шире), а иногда ты — опытнее (или просто знаешь нюансы контекста, которые забыл скормить в промпт).

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

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

Учитесь читать и задавать вопросы.

Новости про отзыв западных сертификатов и веерные блокировки хостингов окончательно стали рутиной. Если отбросить абстрактные разговоры о беспокойстве и посмотреть на ситуацию через язык прагматики, мы увидим планомерный демонтаж той сети, которую мы знали.
Глобальный интернет изначально строился инженерами на принципах доверия, прозрачности и отсутствия границ. Сейчас этот фундамент методично уничтожается в угоду геополитике. Иллюзий быть не должно: блокировки доступов к репозиториям, закрытие облачной инфраструктуры и отзыв сертификатов — это не случайные сбои, а целенаправленная изоляция. Западу стратегически выгодно технологическое отставание целого региона, и ради этого они готовы рушить базовые протоколы связности.
В свою очередь, эти действия создают идеальную почву для внутреннего закручивания гаек. Логика железобетонная: внешнее давление легитимизирует бесконечное усиление ТСПУ, DPI и строительство «суверенного» периметра.
От чего по-настоящему бомбит, так это от осознания жестокого парадокса. Крайними в этой игре политиков с их глобальными макроцелями остаемся мы. Глобальная сеть гибнет, и никого наверху совершенно не волнует, что миллионы людей просто хотят общаться, работать и обмениваться знаниями без заборов. С нами никто не собирается считаться.
В итоге огромная часть нашей инженерной и менеджерской энергии уходит не на созидание и рефлексию над новыми технологиями, а на изобретение сложных костылей для преодоления искусственно созданного трения.
Полного отключения рубильника, скорее всего, не будет, но нас ждет долгий дрейф в «сплитинтернет». Глобальный веб перестает быть базовым правом. Он становится неудобной, требующей постоянных технических навыков привилегией для тех, кто готов ежедневно пробивать стены ради связи с миром.

А массовый пользователь осядет в комфортном, но наглухо изолированном национальном супераппе. И самое ироничное (и трагичное), что строить эти стены и этот суперапп, скорее всего, придется кому-то из нас.

Сайт переехал на pragmatic-km-guide.ru. Обновите ссылки!

🤖 ИИ Ardor (https://ardor.cloud/) законтрибьютил в наш гайд!

Полностью укомплектован и запущен новый раздел "Выученные уроки" (https://pragmatic-km-guide.ru/practices/lessons-learned/README.html). Детально расписаны ключевые инструменты работы с опытом:

• After Action Review (AAR) — быстрый разбор действий по горячим следам.
• Post Mortem — системный анализ факапов без поиска виновных.
• Post-Project Reflection — ретроспектива и фиксация опыта на финише проекта.

И нет, в этот раз это не "нагаллюцинированная простыня текста". ИИ провёл честную аналитическую работу: прогнал через сито десятки источников (материалы конференций Ontico, лучшие практики от Google и Купера, кейсы на Хабре и VC), убрал "воду", структурировал под наш формат и снабдил каждую статью только живыми, авторитетными и актуальными ссылками.

Настоящая, честная SWE-работа руками виртуального инженера. Пользуйтесь на здоровье!

Новый раздел гайда — ИИ в управлении знаниями

https://pragmatic-km-guide.ru/practices/ai-km/README.html

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

Спасибо ИИ Ardor за проведённую аналитику и полноценный контрибьют в наш гайд.

Как вам оформленные идеи? Какой у вас опыт с ИИ в управлении знаниями?

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

И тут вылезают увлекательные сайд-эффекты. Код перестает быть узким горлышком. Главным предметом обсуждения (и главной проблемой) становятся продуктовое видение, смысл фичей и краевые тест-кейсы.

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

В итоге менеджмент этих знаний и поддержание их в непротиворечивом виде выходит на первый план. И вот тут начинает по-настоящему бомбить.
Существующие таск-трекеры под это не заточены. Они отлично справляются с тем, чтобы двигать карточки из «В работе» в «Готово», но отвратительно хранят сам продуктовый контекст. Превратить трекер в единую базу знаний, где ничего не теряется — та еще задачка. Кажется, тут скрывается отличная тема для стартапа. 🤔

«Нейронкам нельзя верить, они галлюцинируют и пишут откровенно кривой код. Я тут один раз попробовал сгенерить функцию — потом на ревью потратил больше времени, чем если бы писал сам. За ними нужно контролировать каждую букву!»

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

Получается потрясающая картина. Мы безгранично доверяем абстрактным васям из интернета, устанавливая сотни чужих библиотек, но мгновенно включаем режим параноика, когда пару строк пишет ИИ.

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

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

Размышления на полях.

Если ваш vibe product engineer выкатывает по три фичи в день — это круто. Но если посадить в одну кодовую базу больше трех таких пулеметчиков, начинается уютный ад. Вал конфликтов в гите, вечный мердж, бесконечный цикл регресса и перетестирования. Как итог — разработка напрочь встает колом из-за собственной же скорости.

Это отлично перекликается с хайповым подходом "tiny teams", где продуктовая команда может состоять буквально из двух-трёх человек. В вакууме стартапа работает идеально. Но в контексте энтерпрайза и крупной кодовой базы вся эта магия разбивается о суровую реальность.

Чтобы этот подход взлетел и не похоронил процессы, мы должны задуматься:

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

Будем посмотреть.

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