Планирование, отслеживание и контроль
Представлен открытый мультиплатформенный проект GitHub Store. Это GitHub в виде магазина с приложениями — скачивать, обновлять и устанавливать ПО с платформы теперь можно, как из обычного магазина приложений:
все приложения ставятся в один клик;
установленные версии ПО сами обновляются;
есть тренды и топы по репозиториям;
работает на Android, Windows, macOS и Linux.
5 правил программирования Роба Пайка:
Правило 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).
Улучшаем моего агента. Часть 4
Это четвертая часть серии (первая — в чем идея, вторая — агент с нуля, третья — что внутри).
В таких цитатах я буду показывать конкретные запросы, которые он уже хорошо решает.
———————
Поехали ⤵️⤵️⤵️
💲 Ведет учет всех моих финансов
Подключён к моей финансовой табличке, которую я веду в 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 — чтобы мог сам читать переписки, мониторить каналы, готовить черновики ответов.
Тамагочи получается 🎮
«Просто добавь кнопку» и недели работы
Однажды заказчик пришёл с задачей, которая звучала как пара часов работы «Просто добавь кнопку — нажал, выгрузил данные, всё». Я открыла код и поняла, что эта кнопка стоит не пару дней, а недель — и это если повезёт..
Сложнее всего оказалось не сделать, а объяснить так, чтобы услышали.
С технической стороны всё понятно: сервис писался под дедлайн, архитектура не предусматривала роста, и каждое новое изменение тянет за собой минимум три соседних. Но заказчик смотрит на задачу и видит один экран. Кнопки ещё нет, но она же просто кнопка. Что тут может быть сложного?
Архитектурное объяснение я попробовала и оно не зашло. Слои, связи, зависимости: всё правильно, всё мимо.
Что работает вместо «красивого кода»
Я перестала объяснять как устроено и начала объяснять что произойдёт. Не «тут монолитная структура без инверсии зависимостей», а конкретно: — эта кнопка затрагивает три модуля, которые никто не трогал два года — если что‑то сломается, то мы не узнаем сразу, потому что тестов нет — следующая фича после этой будет стоить столько же в лучшем случае.
Заказчик услышал третий пункт. Именно его.
Нетехнический человек воспринимает разработку примерно так: «нажал кнопку → произошла магия → получил результат». Это не незнание — просто другая роль. Заказчик и не должен думать об архитектуре, это моя работа. Значит, говорить на его языке — тоже моя.
Как я считаю стоимость следующей фичи
Со временем сложился свой фреймворк. Не из учебника, а из разговоров, где меня не понимали, пока я не поменяла подход.
Три вещи, которые я оцениваю перед тем, как называть сроки: 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 и другие похожие форумы.
Теперь можно было нормально искать решение более-менее широко известных проблем по их примерному описанию и сразу получать примеры рабочего кода. Существенный рывок, значительно сокративший время на простые, рутинные задачи, и, одновременно, подаривший куче студентов возможность гуглить практически готовые лабораторные работы.
Фактически, именно в этот момент программирование стало общедоступным. А на первое место вышел навык комбинирования — умения собрать решение из похожих кусков кода, найденных в интернете.
Представлен обновлённый список из 200 ресурсов для поиска работы в мире. В нём 78 полезных платформ и инструментов и 122 компании с удалёнкой.
Приглашаем на вебинар по frontend разработке
26 марта эксперты AXENIX проведут вебинар, посвященный современной фронтенд архитектуре и гибким подходам к разработке.
🔘Разберем реализацию подхода Server Driven UI и рассмотрим, как эффективно интегрировать в него ИИ-агентов.
🔘Поговорим о долгосрочном здоровье проекта и преимуществах изоляции бизнес-логики от фреймворков на примере Feature-Sliced Design (FSD) и реальном опыте перехода на Effector.
🔘Проведем анализ гибридных решений: как из единой кодовой базы собирать и облачный сервис, и десктопное Electron-приложение с офлайн-режимом, преодолевая ограничения браузерной среды.
Участие в вебинаре бесплатное, необходимо только зарегистрироваться по этой сcылке и подключиться к нам 26 марта в 18:00.
Будет интересно!
10 бесплатных вебинаров марта для руководителей
Привет, Хабр. Делимся подборкой бесплатных уроков, которые пройдут в Отус в рамках набора на курсы. Опытные практики проведут занятия онлайн — на них вы сможете узнать больше о формате обучения и задать вопросы. Выбирайте тему и присоединяйтесь, чтобы пробустить свою карьеру.
12 марта 19:00
Лайфхаки трудоустройства продакт-менеджера
Открытый вебинар курса «Продуктовый менеджер ИТ-проектов»
12 марта 20:00
Командные конфликты – кто виноват и что делать?
Открытый вебинар курса «Руководитель DevOps»
18 марта 20:00
Сообщество как инструмент устойчивости бизнеса: создаем, развиваем и масштабируем
Открытый вебинар курса «DevRel (работа с сообществом разработчиков)»
18 марта 20:00
CTO (технический директор) как система: люди, процессы и ИТ для управления бизнесом
Открытый вебинар курса «CTO / Технический директор»
18 марта 20:00
Как построить аналитическую функцию в компании
Открытый вебинар курса «Data-driven (управление на основе данных)»
19 марта 19:00
Метрики удержания клиентов: Product Market Fit и Retention (соответствие продукта рынку и удержание пользователей)
Открытый вебинар курса «Продуктовый менеджер ИТ-проектов»
23 марта 20:00
Джедай или Ситх? Собираем идеального руководителя DevOps
Открытый вебинар курса «Руководитель DevOps»
24 марта 20:00
Как остаться умнее искусственного интеллекта в 2026 году?
Открытый вебинар курса «ИИ для решения рабочих задач»
26 марта 20:00
Метамодель TOGAF и модель организации
Открытый вебинар курса «Архитектура корпорации. Togaf 10»
31 марта 20:00
Этапы и артефакты 1С-проектов 2026: ИИ-интеграции и гибкая разработка
Открытый вебинар курса «Архитектор 1С»
Полный список бесплатных уроков марта по всем ИТ-направлениям смотрите в дайджесте.
СЕО 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. Ну и конечно, что попадает в интернет - остается в интернете, поэтому не забывайте про цифровую гигиену.
🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте | ⚡️Бустануть канал
Команда разработчиков языка программирования 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. В рамках проекта представлен сайт, на котором можно летать по «городу», где каждое здание это аккаунт разработчиков. Высота небоскребов = количеству коммитов. Летая по городу, можно искать интересные и популярные аккаунты, либо находить что-то новое и недооцененное.
А зачем покупаете WAF, который можно обойти?
С таким вопросом разработчиков периодически сталкиваюсь. Добавлю контекста. Работаю AppSec инженером в финтехе. Когда нахожу уязвимости — сообщаю разработчикам. Среди прочего - доношу мысль: если в данном случае можно смягчить потеницальные последствия угрозы через WAF — это не значит, что уязвимость не нужно исправлять в приложении. Нередко разработчики спорят. Примерный диалог:
— Ну, есть же WAF — на нём и делайте фикс, зачем нам-то в код лезть? WAF — он же для того и нужен, чтоб уязвимости устранять.
— WAF — не панацея: на нём мы сделаем правило. Но это не значит, что в самом приложении не нужно устранять.
— Почему?
— Например, потому, что практически любой WAF можно обойти.
— А зачем покупаете WAF, который можно обойти?
Отвечаю так: потому что WAF пишут такие же разработчики, как Вы, и они тоже иногда ошибаются (как и все люди). Некоторые особо настырные разработчики желают доказательств, что WAF можно обойти. В целом я солидарен, что практика "а ты докажи" в управлении уязвимостями - не очень хороша. Но, если есть под рукой на что можно быстро сослаться - можно это сделать. Я ссылаюсь на эту статью.
В моей практике были случаи, когда WAF из-за сбоя переставал применять правила на несколько дней. Т.е. трафик через него шёл, сервис за WAF продолжал быть доступным. Но, правила на WAF не работали — будто их и нет.
Эта история в очередной раз показывает: насколько бывают различны в оценке ситуации разработчики и "безопасники". Более интересный вариант — когда разработчики считают, что только они могут решать: что является уязвимостью, а что — нет (подробнее об этом я писал в статье "Как я зарегистрировал CVE и разозлил вендора").