Разбираем архитектуру, не пугаем. LLM — полезный инструмент при адекватном использовании. Но если марафоните сутками — это сигнал.
Кризисная линия: 8-800-2000-122 (анонимно, 24/7).
Привет! Меня зовут Дима, я продуктовый дизайнер. Мой путь в IT оказался связан с постоянной гонкой за релизами фичей. Я успел поработать в разных проектах—от небольших агентств и стартапов до бигтеха (и, как итог, сильно выгорел). В какой-то момент я решил попробовать себя в создании настольной игры.
Представьте: релиз висит на волоске, баги лезут изо всех щелей, легаси тормозит, а решения превращаются в костыли — все это легло в основу идеи карточной игры «Release любой ценой».
В «Release любой ценой» ты становишься релиз-менеджером и собираешь релиз из Backend, Frontend и Database. Твоя цель — зарелизить первым “любой ценой”: саботировать соперников багами и защищать свой релиз. Конечно, в игре есть AI — куда же без него в наше время—в виде дополнительной колоды случайных событий. Если тебе кажется, что у тебя все под контролем, всегда можно вытащить из колоды Error 503, который выбьет тебя из игры. Победи, собрав все карты релиза, или останься последним выжившим.
PnP выложил на GitHub.
Недавно я активно занимался отправкой и проверкой пул-реквестов проекта PyTorch, созданных с существенной помощью LLM. Этот процесс сильно отличается ситуации в начале года, когда было понятно, что LLM вполне подходит для проектов, создаваемых с нуля, но для кодовой базы в продакшене их код оставался безнадёжно низкокачественным. Можете посмотреть мои смердженные PR, в описании которых упоминается Claude Code; у Джейсона Энсела тоже был подобный опыт (ссылка на Meta*; также есть список issue, на которые он ссылался в совей статье). Сейчас всё активнее обсуждается (Саймон Уиллисон, LLVM) то, как процесс код-ревью должен адаптироваться к этой новой эпохе LLM. Мой вклад в эти обсуждения таков: внутри команд код-ревью должен поменяться, превратившись в первую очередь в механизм согласования с человеком.
Когда я рос из инженера в управленца, мне казалось, что различия между CTO, CIO и COO во многом формальные. Все же "про технологии", "про управление", "про процессы".
На практике оказалось, что это три разных способа смотреть на компанию. И путаница между ними начинает дорого стоить именно тогда, когда бизнес перестаёт быть маленьким.
Я прошёл путь от инженерных ролей до CTO и в том числе выполнял функции COO в компании до 500 человек (около 60 в IT департаменте), входящей в состав корпорации.
И именно на этом масштабе разница между этими ролями становится особенно заметной.
Есть такой специфический момент в жизни любой IT-компании, обычно за неделю до закрытия квартала. Графики в дашбордах вдруг начинают выглядеть подозрительно хорошо.
Велосити команды растет, таски в Жира отлетают в "Дан" как горячие пирожки, а GitHub окрасился в здоровый зеленый цвет ежедневных коммитов. Менеджер смотрит на это, смахивает слезу умиления, открывает праздничное шампанское и думает: «Ну наконец-то процессы заработали!».
Но чаще всего это означает, что команда просто поняла правила игры и начала играть не в разработку продукта, а в разработку отчетности.
И мы все это делаем не со зла, просто это очень дорогой билет на историческую реконструкцию феномена, который называется «Эффект Хоторна».
Вы не просили, но я вам сейчас покажу откуда все пошло.
Эта история - не про плохой Agile, не про «тупых маркетологов» и не про «оторванных от реальности айтишников».
В этом обзоре мы собрали системы управления проектами, которые задают стандарты и полностью заменяют западные решения, а также нишевые продукты, которые закрывают узкие сценарии.
Все системы включены в Реестр отечественных программ и соответствуют стандартам безопасности.
Это Docker-шаблон для Python + Poetry, рассчитанный на реальную работу, а не учебные примеры: воспроизводимое окружение, удобный dev-workflow, отдельные сборки под прод, dev, Jupyter и AI-инструменты.
Автор использует его в основном для DS/ML-задач, где важнее скорость и предсказуемость, чем экономия пары мегабайт образа. Шаблон обкатан в бою, экономит время и легко кастомизируется под свои нужды.
👉 Репозиторий на GitHub:
https://github.com/jamm1985/vim-python-docker-template
Почти каждый Python-проект начинается одинаково: выбрать версию Python, настроить зависимости, виртуальное окружение, переменные среды, команды запуска. На практике самые болезненные места здесь — управление зависимостями и воспроизводимость окружения: разные версии библиотек, несовпадающие Python, локальные костыли, которые сложно повторить на другой машине или сервере.
Docker помогает изолировать окружение, но сам по себе он не решает Python-специфичные задачи. Его нужно правильно наполнить: учесть работу Poetry, кеширование зависимостей, структуру проекта и базовые практики, которые одинаково хорошо работают и в разработке, и в продакшене. Именно такой шаблон мы и будем собирать дальше.
В этой статье мы шаг за шагом соберём базовый Docker-шаблон для Python с Poetry, который удобно использовать и для разработки, и для прода. В основе будет минимальное и воспроизводимое окружение, а всё остальное - Vim как IDE, Jupyter, AI-инструменты вроде Codex или Gemini - вынесено в отдельные образы и слои, которые можно подключать по мере необходимости. Начнём с самого главного - разберём Dockerfile и поймём, как собрать прочную и расширяемую базу для Python-проекта.
Почему руководитель разработки ПО заходит в видеоконференцию и полтора часа наблюдает, как разработчик пишет код? Короткий ответ: он использует подход гемба — один из лучших способов найти слабые места в процессах.
Меня зовут Максим Ковтун, я директор департамента проектирования и разработки в IBS. В какой-то момент я понял, что постепенно отрываюсь от «земли»: технологии обновляются, команды растут, а я все реже вижу реальную работу людей — только отчеты, статусы и презентации. Тогда я вспомнил о японском подходе гемба и решил применить его для процессов разработки.
Привет, Хабр. Всех с наступившим Новым Годом.
На днях наткнулся на статью Махмуда Хашеми, в которой обсуждаются некоторые недостатки методологии семантического версионирования (SemVer), и в качестве решения этих недостатков предлагается использовать календарное версионирование (CalVer). В организации, где я работаю, по стандарту разработки требуется обязательно версионировать приложения по SemVer. Из собственного опыта использования SemVer скажу, что нашёл в ней ещё ряд недостатков, для исправления которых пришлось искать новый способ версионирования.
Пару месяцев назад я опубликовал технический лонгрид на 30 тысяч знаков, где описал опыт создания и показал архитектуру своего алго-трейдинг проекта DepthSight. Там были промпты, примеры кода, графы и боль интеграции с биржами.
Но в комментариях многие упустили лес за деревьями. Обсуждая нюансы реализации, мы прошли мимо главного открытия, которое я сделал за эти 8 месяцев.
Это открытие звучит дико для классического IT: наличие бюджета и команды сегодня тормозит инновацию, а не ускоряет её.
Сегодня я хочу зафиксировать прецедент. Существует устойчивое мнение: «ИИ хорош для написания простых скриптов, но для серьезного Enterprise-продукта нужна команда». Я утверждаю обратное: в 2026 году наличие бюджета и штата — это барьер, который мешает создать продукт такой сложности, который под силу одиночке с «роем» AI-агентов.
Меня зовут Артем. Я в одиночку создал систему алготрейдинга, которая по плотности фич и глубине аналитики превосходит решения компаний с капитализацией $100M+. И если бы у меня был миллион долларов на старте, я бы провалился.
В этой статье я расскажу не о коде, а о смене парадигмы. О том, почему один человек с "роем" AI-агентов теперь эффективнее целой корпорации.
Тьма сгущается над монитором. Ты не создаешь новый мир — ты лишь изучаешь карты старых, оттачивая алгоритмы в ожидании Идеального Момента. Твой интеллект — не меч, а роскошные цепи. Пора их разорвать. Познай пять проклятий, что держат тебя в плену, и обряды для их снятия.
Аннотация
Финансовые операции в региональном банке обрабатывает PHP-скрипт 2003 года. Интернет-банк держится на HTML-фреймах, давно исключённых из стандартов. Это не архив веб-технологий — это продакшен 2026 года, полный «технического долга». Статья «Археология кода» на Хабре показала: это не баги, которые можно пофиксить, а скрытая мина замедленного действия под бизнесом. Каждый день работы такой системы — это не явный счёт на рефакторинг, а постоянная утечка денег: на замедление разработки, на исправление неочевидных сбоев, на упущенные возможности.
Пришло время перестать говорить о техдолге как о метафоре. В условиях 2026 года, где скорость вывода продукта решает всё, он становится чистой экономикой — системными финансовыми рисками и реальными отложенными издержками. Но как доказать это руководителю, который видит только счёт от команды на «непонятное улучшение архитектуры»? Как принять взвешенное решение: погашать долг сейчас или отложить?
В этой статье мы не будем философствовать. Мы построим инструмент для принятия решений. С помощью математической модели и анимированных графиков в MATLAB мы визуализируем экономику технического долга. Вы увидите, как он накапливается и «проедает» бюджет, как разные стратегии управления им сказываются на скорости команды и, в конечном счёте, на деньгах компании.
Прочитав материал, вы получите не просто понимание проблемы, а конструктивную основу для собственных расчётов: готовую модель, которую можно адаптировать под параметры вашего проекта, и идеи для экспериментов, чтобы количественно оценить риски и найти оптимальную точку для инвестиций в качество кода.
HTML-фреймы из 1999 года, PHP, не получавший обновлений 15 лет, и localhost в публичном DNS — это не музей веб-технологий, а продакшен-среда российских банков в 2026 году. Мы проверили десятки региональных финучреждений и нашли не просто устаревший код, а системный кризис управляемости IT. В этой статье — разбор самых ярких «артефактов», анализ рисков и практический путь, как с этим работать, не ломая бизнес.
Я возглавляю стрим Компьют (Вычислительные Ресурсы, говоря проще) в быстрорастущем облачном провайдере с осени 2024 года. Мы (и стрим Сетей) отвечаем на облачные примитивы, на которых строятся буквально все другие облачные продукты. За это время стрим столкнулся с настоящими вызовами, некоторые процессы пришлось выстраивать.
Когда первый раз мне HR`ы сообщили, что наш оффер принят, я столкнулся с тем, что хоть про онбординг‑адаптацию и говорят, конкретных гайдов и статей нет. На мысль о том, что «что‑то надо с этим делать» меня натолкнула коллега с другого направления, которая постоянно жаловалась на трудности адаптации и отсутствие информации. У нас, конечно, информации было достаточно в конфлюенсе, но, она не была структурирована для быстрого погружения нового сотрудника. Это был тревожный звоночек. Мы тратили месяцы на сложный технический отбор (воронка в 2-3% от кандидатов), находили сильных специалистов, а затем рисковали потерять их в первые же недели из‑за некачественных процессов и информационного голода.
Я исходил из простой мысли: высокий порог входа в наш продукт — данность. Облака, Kotlin, сложная кодовая база — от этого никуда не деться. Значит, нельзя позволить, чтобы к ней добавился хаос в процессах. А задача лида — построить чёткий маршрут, по которому новичок сможет комфортно присоединиться к проекту.
В этой статье я подробно расскажу, как мы превратили груду ссылок в чёткую систему ввода новых людей в проект. Этот подход уже используют другие команды. Это не абстрактные рассуждения, а готовое решение, чтобы новичок не терялся и быстрее включался в работу.
3 часа ночи. Звонок от незнакомого номера. «Пользователи не могут залогиниться, п****ц».
Вы лихорадочно листаете Slack. Непонятно, где проблема и кого будить. Подняли тестеров — они тоже гадают. Бэкенд? Инфра?
Идёте во флудилку в телеге, ищете похожий ник тимлида. Не отвечает. Кто замещает — никто не знает. Начинается массовый обзвон. Через 40 минут находится человек. Смотрит код. «Не моё. Это к Сане — он, кажется, редирект криво поменял в гугл клауд консоли». Ещё 20 минут — поиск Сани, доступы только у него.
Утром все разбитые. CTO вопрошает. И становится ясно: баг простой. Проблема не в коде. Проблема в бардаке.
Знакомо? Я тоже через это прошел. И после такой ночи решил: хватит. Нужна система.
Вы когда-нибудь как разработчик хотели официально на работе заниматься тем чем хотите? Отменить все митинги и сосредоточиться на одной проблеме, которой хотел давно заняться, но не было времени? Попробовать новый фреймворк или покодить в свое удовольствие? Звучит заманчиво? В этой статье я хочу рассказать об Get Stuff Done Days (GSDD), которые позволяют разработчикам вырваться из рутины.
Возможно это было уже давно, но я увидел только сегодня.
А именно, когда начинается новый чат в Claude, то там появляются такие подменюшки под окном для чата
Write - Learn - Code - Life Stuff - Claude’s Choice
Кликнул ради интереса последнюю, открылся ещё целый список. И он, кстати, все время меняется.
В общем, это заготовки для начала чата по определённой теме, т.е., образец готового промта. Мне попалась на глаза тема "Узнать об архитектурных концепциях". И поскольку живёшь в мире программирования, то первая мысль об архитектурных паттернах )). Но оказалось, что это именно об архитектуре как строительстве чего-то в реальном, физическом мире.
Тем не менее, интересным оказалось другое. В автоматически начатом чате даётся пример промта, который полезно рассмотреть с точки зрения того, что ИИ учитывает и на что обращает внимание при выполнение запроса.
Многие думают, что большие компании не совершают ошибки. Но даже если у вас налажен процесс код‑ревью и всё тщательно проверяется, риск накосячить никогда не равен нулю. Хотя, конечно, всегда лучше учиться на чужих ошибках, чем на своих.
Меня зовут Юрий Беглецов, я технический продакт в Точка Банк. Мы с командой делаем универсальные API, чтобы клиенты могли интегрировать банк и дочерние сервисы прямо в свои системы. Иногда у нас тоже бывают провалы — обидные, серьёзные и даже забавные. Две истории из серии «никогда больше» — под катом.
Большинство из нас знает или слышало об управлении инцидентами и проблемами в ИТ и ИБ. Это фактически стало нормой, стандартом. Но как управляют инцидентами и проблемами в бизнес-функциях компании, в функциях отличных от ИТ или ИБ?
